Oppnåelse av datamodning: en organisatorisk balansegang

Av Techopedia Staff, 8. november 2017

Takeaway: Vert Eric Kavanagh diskuterer modenhet og organisatorisk modenhet med Jen Underwood fra Impact Analytix og Ron Huizenga fra IDERA.

Du er ikke logget inn for øyeblikket. Logg inn eller registrer deg for å se videoen.

Eric Kavanagh: OK, mine damer og herrer. Hei og velkommen igjen. Det er onsdag klokka 4 øst, som betyr at det er på tide med Hot Technologies. Ja absolutt. Jeg heter Eric Kavanagh; Jeg vil være din vert for showet vårt i dag, som virkelig er definert, designet for å definere visse typer teknologi i visse tilstander som er i en datatyrings verden. Og emnet vårt i dag er "Oppnå datamatur: en organisasjonsbalanselov." Så det er stedet om ditt virkelig, slo meg opp på Twitter, @eric_kavanagh. Jeg retweet alltid hvis du nevner meg, og jeg vil prøve å følge tilbake også. Det er et bra sted å dra for å få informasjon om hva som skjer i verden. Jeg elsker det formatet. Korte tegn, 140 tegn - eller mer i disse dager. Så send meg en tweet, så følger jeg tilbake.

Dette året er selvfølgelig varmt. Vi snakker alt om datamodning i dag, og her er oppstillingen, med din virkelig i toppen. Vi har en ny analytiker i dag; Jeg er veldig spent på å ha Jen Underwood fra Impact Analytix. Hun er ganske ekspert på forretningsinformasjon og analyse og datavisualisering og alle disse flotte emnene. Og selvfølgelig datamodning. Og vår gode kompis Ron Huizenga ringer inn fra IDERA. Så først hører vi fra Jen og deretter fra Ron. Og så får vi en fin runddiskdiskusjon.

Når jeg skyver dette neste lysbildet opp her, vil jeg bare si et par kjappe ord. Forvaltning av dataadministrasjon har vært et tema en stund nå. Åpenbart i historien må du komme deg til et bestemt punkt før du begynner å tenke på modenhet, og det har blitt utviklet mye livssykluser - eller sykluser - for å prøve å finne ut hvor du er i kurven. Er du en tidlig fase? Er du tenåring? Er du moden? Og så videre.

Og jeg tror mange organisasjoner er enten i tenårene eller i slutten av tenårene eller begynnelsen av tjueårene når det gjelder modenhet. Og det sier ikke noe nedslående. Det er bare det at vi fortsatt er slags i de første dagene av å kunne administrere data som en strategisk eiendel. Og ting har endret seg raskt. Spesielt i løpet av de siste fem til syv årene, da vi har flyttet fra små data til big data, og de prøver å forene disse ganske forskjellige verdener og nye teknologier med gamle teknologier. Så arven er der ute, den er overalt.

En av vitsene jeg hørte for mange år siden, er at arven er et system som er i produksjon. I det øyeblikket et system går i produksjon, teknisk sett er det arv. Og på en måte som er sant. Men poenget er at vi har alle disse systemene som har eksistert lenge og vi må finne en måte å forstå hvor vi er i vår egen modenhetskurve for å kunne maksimere og optimalisere verdien av data som en eiendel . Og selvfølgelig er det noen overholdelsesproblemer, noen forskrifter vi trenger å bekymre oss for, avhengig av hvilken bransje vi er i. Og da må vi selvfølgelig også bekymre deg for hacking. I det siste har vi snakket om styring av data og hvordan det virkelig er en del av sikkerhet og bare forstå roller og ansvar for å bruke data og sørge for at vi får den beste verdien av det.

Og så med det, skal jeg overlevere nøklene til Jen Underwood, og hun kan fortelle oss sitt perspektiv på datamodning. Jen, ta den bort.

Jen Underwood: Takk, Eric, og takk for at du inviterte meg. Så i dag skal jeg dekke noen få forskjellige temaer, og så skal jeg introdusere Ron med IDERA, og han kommer til å grave dypere i noen andre områder av akkurat dette emnet. Jeg vil si det er en kritisk rolle i den digitale epoken eller den digitale transformasjonen som vi er inne i akkurat nå, og som Eric hadde sagt, det er en utviklingstid. Noen morsomme statistikker fra EDM-rådet, det var en referanseportefølje for datahåndtering. Den er nesten to år gammel, men den er fremdeles ganske relevant og vil avsløre noen av de faktiske faktoiene i seg selv når de er tenåringer i dette rommet. Jeg skal snakke litt om datamodning og pilarene for styring, per se.

I dette temaet for den digitale epoken eller digital transformasjon som du hører overalt, skjer dette virkelig akkurat nå. Et av de interessante fakta som jeg har samlet når jeg har fulgt bransjen hver dag, var et poeng av Gartner i deres topp ti strategiske teknologitrender. Og de hadde sagt innen 2020 - så vi er bare noen år borte fra det - informasjon vil bli brukt til å gjenoppfinne, digitalisere og automatisere eller eliminere 80 prosent av prosessene vi har hatt fra et tiår tidligere.

Og jeg har sett dette på en stund, jeg tror at her ser du forskjellige typer mennesker som sier, du vet, "Data er den nye oljen, " og de slags ting. Jeg liker å si at data nå er digitalt gull. Og hvis du tenker på programvare og programvareinvolvering, var jeg en verdensomspennende produktsjef for Microsoft i det siste, og til og med endringen i karrieren fra, du vet, ville vi virkelig fokusere på programvare til nå er vi fokusert på brukere samle inn dataene og tenke på inntektsgenerering av dataene.

Vi går inn i denne epoken hvor data er digitalt gull, og du begynner å se at med fremveksten av det som kalles sjefdateansvarlig, og de er, har de, du vet, to primære oppdrag - og sikkert noen få andre - å sørge for at dataene er trygge og sikre, og også finne måter å maksimere verdien av data internt - og til og med eksternt - som den digitale eiendelen. Så disse typene ting som kanskje ikke har vært, eller kanskje ikke har virket viktige for organisasjonen din i det siste, data får endelig plass ved C-nivå bordet med CDO og vil bli tatt mye mer seriøst fremover.

Hvis du tenker på datahåndtering og modenhet, er det to forskjellige temaer som jeg har på dette lysbildet her. Det første er, du vet, datahåndtering i seg selv. Det handler mer om forretningsfunksjonene som utvikler og skaper data og datastrømmer, noen av policyene og praksisene der. Og når du tenker over datastyringens modenhet, er det organisasjonens evne til å definere, enkelt integrere, vet du, utnytte de dataene de har igjen til interne eller eksterne formål, for eksempel datapenger. Og et av de store temaene - og det har vært morsomt, tidligere i min karriere, og jeg faktisk utnyttet noen av IDERAs verktøy og dataarkitekturprosjekter - var hele metadata-konseptet og vi tenker på metadata, og da ble det ikke snakket omtrent i lang, lang tid. Endelig ser jeg at metadata er kul igjen. Det er egentlig ganske viktig å samhandle med forskjellige grupper, forstå hvor dataene dine er, hva dataene er. Spesielt i ting som en datasjø. Endelig blir det endelig interessant.

Nå lovet jeg at jeg hadde noen statistikker her fra en referanseindeksrapport. Denne var fra 2015 for EDM-rådet. Det handler om å modernisere datakvalitet og styring, og det er noen morsomme faktoider i akkurat denne. Så her inne har mer enn 33 prosent av organisasjonene et aktivt, formelt datahåndteringsprogram på et eller annet nivå i organisasjonen - bare 33. Så det er veldig interessant i og for seg selv. Av de 50 prosentene som har, virkelig har formalisert, vi ønsker å administrere data, innser vi at dette er en veldig viktig ressurs i organisasjonen vår, akkurat som mennesker har menneskelige ressurser. Bare 50 prosent av dem hadde programmer som var eldre enn ett år. Så dette er igjen et voksende område, det er egentlig ganske interessant i det vi har blitt mer og mer viktig, spesielt med ting som noen av bransjeforskriftene som kommer ut.

Så på det punktet, mange ganger - og det er interessant å ha vært i teknisk salg og roller gjennom karrieren min - var det egentlig ikke, "Åh, vi kan spare penger som ville motivere en organisasjon" - det er vanligvis frykt. Det er mer av, “Herregud, vi må sørge for at vi blir dekket. Vi ønsker ikke å miste jobben. ”Og absolutt ting som hacking og datasikkerhet og lekker data, det er virkelig interessante referansestudier på dette. Verizon gjør en hvert år, og det er sannsynligvis en av favorittene mine som skal vurderes. Det du nesten alltid ser er en utilsiktet, det er ikke nødvendigvis forsettlig misbruk av dataene eller feil ledelse av dataene som resulterer i en lekkasje. Og ofte - de har ikke denne statistikken for akkurat denne økten - men det er fascinerende at disse tilfeldige lekkasjene av feilstyring av tillatelser og lignende. For å gjøre ting litt enklere, går disse lekkasjene ut. Og vanligvis til personer som er sidebeskjedne eller eksterne for organisasjonen din, og det er ikke det du ønsker.

Så det er typene når du tenker på å ha et sikkerhets- og styringsprogram for dataadministrasjon. Du vet ikke bare dårlige beslutninger og spare penger, men også sørge for at du vet at du er sikker, at du overholder lovgivningen om personvern og sikkerhet. Du er i stand til å tjene penger på data i denne digitale epoken, og selvfølgelig, du vet, vil du gjøre ting effektivt og gjenbruke data og ha den velsignede kopien og ha det - jeg hater når folk sier, og jeg er i analyse og jeg Jeg har vært i analyse lenge, en versjon av sannheten. Det er vanligvis, du vet, det er vanligvis flere versjoner av sannheten, bare fra forskjellige perspektiver. Men egentlig ønsker du at dataene skal være pålitelige som du baserer beslutninger på.

En av de største driverne som jeg ser - og det er bra, det er bra at det blir kult igjen - er hele konseptet med EUs GDPR. Og la meg snakke litt om det. Så hvis du ikke kjenner GDPR, kommer du til å høre mye om det i løpet av året. Det er ny lovgivning som skjer i mai. Det vil bli håndhevet i mai 2018, og det har noen store straffer for feilbehandling av informasjon. Du har kanskje hørt dette snakket om i andre former - kanskje ikke å bruke begrepet GDPR - du har kanskje hørt eller sett dette skrevet om som retten til å bli glemt, noe som betyr at du kan nå ut og be leverandører om å fjerne dataene dine. Igjen, tidligere dataarkitekter, ville de ikke fjerne data. Vi ville endre det, vi ville gjøre det inaktivt i datalager-scenarier. Vi har aldri slettet dataene våre. Vi hadde ikke prosesser for det. Så det er, du vet, ting som vil berøre alle aspekter av organisasjonen din og forskjellige måter og prosesser du kanskje aldri har vurdert å bygge din applikasjon eller datavarehus. Så hvis du ser ting om GDPR å tenke på, ganske snart trenger du et juridisk grunnlag for å rettferdiggjøre innsamling og behandling av personopplysninger.

Så dette er mest på personlig nivå, så samtykke må fritt gis: spesifikk, informert, entydig. Og det kommer til å påvirke mange områder av kunstig intelligens og datavitenskap - det er det jeg dekker mest i disse dager, er datavitenskapelige implikasjoner, og bare sørge for at det er litt åpenhet i modellene i seg selv - så vel som mange andre områder fra din selvbetjening BI, datavarehuset ditt, masterdatadministrasjonen din, til og med kundene dine 360 ​​prosjekter, til personalisering og til og med din forretningsgrensesnitt. Så dette er noe som kommer til å berøre hver del av orgelen din. Og i motsetning til personvernlovgivningen i andre jurisdiksjoner, vil GDPR være gjeldende for enhver organisasjon som er lokalisert i eller utenfor EU. Og samsvarsbøtene er igjen betydelige. Det er din organisasjon som kan bli bøtelagt med opptil fire prosent av den totale brutto årlige - jeg tror det kalles omsetning - inntekt per se.

Forhåpentligvis har jeg oppmerksomheten din, og dette er ting du bør legge merke til. Hvis selskapet ditt allerede følger noen av disse praksisene og bransjestandardene med PCI, er det kanskje en ISO - jeg er ikke sikker på om jeg kommer til å si det riktig - 27001. Hvis du gjør noen av disse allerede, burde det ikke ' t være for overveldende, men det er noe du absolutt skal være klar over. Så mens du forbereder deg på dette, er det et par områder, spesielt innen datastyring, og en av de første tingene er å ha en katalog og klassifisere dataene dine - å vite hvor dataene dine ligger. Og i en verden, en hybridverden, der data bor overalt: Det er i skyen; det er i disse appene; det er i salgsstyrken; Det er i et annet tilfeldig program som markedsføring bruker også, du vet, kundesystemene dine eller lagersystemene dine - alle disse typer steder. Vet du hvor dataene dine er og den enkleste tingen å gjøre - og dette har vært et veldig morsomt område for datastyring. Er dette konseptene i disse datakatalogene som har intelligens, selv klassifisering av maskinlæring er noe av informasjonen.

Og igjen, metadata - jeg nevnte at metadata begynner å bli kul igjen, så tenker virkelig på metadata og ikke gloser over det viktige emnet når du begynner å designe datasjøer og de slags ting, og selvfølgelig å styre og overvåke disse. Så overvåkningen kommer til å bli mye viktigere når du må gå tilbake og noen fra GDPR, for eksempel, kan be deg bevise hvor gikk disse dataene, hvem har den, hvem som hadde tilgang til den, osv. Fordi du faktisk må vise myndighetene de slags ting.

For å hjelpe deg med datastyringens modenhet, er det faktisk noen få tanker, og jeg tror - jeg er ikke 100 prosent sikker - jeg tror jeg så på Rons dekk at han kommer til å dekke noen få av disse, så en at jeg Jeg skal snakke om i dag er fra CMMI. Og denne, dette er tilgjengelig for folk; den dekker seks forskjellige kategorier av databehandling, 25 prosessområder, 414 praksisuttalelser og 596 forskjellige arbeidsprodukter. Så når du tenker på nettopp alle tingene du gjør, som at du administrerer og arkiverer data, 596 funksjonelle arbeidsprodukter, skjønte du ikke hvor mye du gjorde, ikke sant? Eller hva du egentlig ikke gjør. Når jeg ser på et slikt nummer, er det en av tingene som virkelig stikker i tankene mine. Så i dette, og det jeg liker med akkurat denne, er det arkitektur og teknologinøytralt. Så det betyr at hvis du har, og de fleste av de større organisasjonene som jeg har konsultert med eller jobbet og implementert gjennom årene, vet du, de har alle slags forskjellige teknologier der. Så du vil, vet du, oversette hva betyr DMM for plattformene og teknologiene du bruker i ditt spesifikke miljø. Det er også bransjeuavhengig, så det er ikke nødvendigvis spesifikt for helsevesenet. Det er sikkert at helsevesenet har - enten det er BAA eller forskjellige typer klassifiseringer, må du oversette eller se på forskjellige typer ting når du setter sammen programmet ditt eller planen din for å forbedre nivået på datastyring i organisasjonen din.

Hva er dette hvis det ikke er noen av de tingene? I hovedsak er det å definere hva, men ikke fortelle deg spesifikt hvordan du gjør det. Etter å ha vært en veldig type A-personlighet mesteparten av karrieren min, likte jeg da folk ga meg et mål og jeg kunne finne ut hvordan jeg skulle komme til det målet og ikke, si, mikromane tiden min, hvordan jeg skulle komme dit. Det er slik datahåndteringens modenhet, og disse prosessene med CMMI, det gir deg målene og det gir deg hvordan du måler deg selv på noen av disse forskjellige områdene. Og de vil gi deg et nivå. Det er forskjellige måter du kan score og måle deg selv på, enten det er nivå en helt opp til nivå fem, noe som betyr at du har optimalisert det og at du har et veldig sterkt program på plass.

Og for bare å gi deg en følelse av hva som egentlig betyr, har jeg en liten oversikt over hva det kan bety. Så her inne, når du tenker på å ha en databehandlingsmodellets livssyklus, har den støtteprosessene på plass, av alt fra krav, risikostyring, du må støtte prosesser der, til datastyring og jeg er snill å gloser over det, men egentlig er styring av data et helt program i seg selv. Å ha en virksomhetsordliste, vi har snakket om virksomhetsordliste og dataarkitekter for alltid - dette skal være noe du har i organisasjonen din. Noen av disse katalogteknologiene der ute, lager de, utvikler en virksomhetsordliste med massevis av informasjon og tar og hva ikke, og vet du, legger koblinger i dokumenter til forskjellige perspektiver på de samme dataene, i datafeltet, eller versjon av dataene når de endres gjennom hele livssyklusen til verdien.

Dette er typen ting som har blitt mye bedre siden jeg begynte i karrieren. Vi pleide å utvikle hjemmevokste systemer i det siste for å gjøre denne typen ting. Så vi ser på helheten og det store bildet, det er strategien og deretter alle de forskjellige brikkene her fra ledelsen til kvaliteten i styring. Og en ting om datakvalitet, det er interessant etter hvert som industrien blir mer automatisert, og vi har, igjen, disse digitale prosessene med automatisert beslutningstaking. Jeg jobber mye i datavitenskapens rom der vi har noen av disse verktøyene automatisere beslutninger og oppdaterer prediktive modeller på farten. Mange av disse verktøyene og algoritmene krever og antar at dataene er gode. Det trenger at dataene skal være gyldige for å gi deg en god automatisert beslutning. Så når du tenker på, vet du, kanskje er datakvalitet vanligvis en av de tingene folk børster til side og tar det ikke så veldig alvorlig. Men når du begynner å automatisere beslutninger i modeller for prediktiv modellering og maskinlæring, blir datakvalitet veldig viktig.

Noen måter å måle fremgangen din her på er - og jeg lar Ron snakke med dette, han har et herlig lysbilde på dette i sin økt også - jeg vil bare gi deg en rask sniktopp på, du vet, disse forskjellige nivåene i dette. I hovedsak er det en egenvurdering, ikke sant? Så du vil undersøke din datastyring og hva du tror du har noe på plass i det hele tatt. Og ikke bli flau hvis du ikke gjør det. Som jeg sa, det er bare 33 prosent av organisasjonene som til og med har begynt å gjøre denne typen ting. Selv om, du vet, har disse programmene vært i det minste - jeg har vært i bransjen i over 20 år, og sikkert gjorde jeg denne typen ting for mange år siden, vi har kanskje ikke bare kalt det dette. CMMI, de har en øvelse som du selv kan vurdere og du kan gå gjennom og se på og lage dine egne - i dette tilfellet denne typen radarkart - vurdert alle disse forskjellige vinklene eller tingene. Og hver organisasjon, som jeg har gjort annerledes, vet du. Når jeg pleide å konsultere og implementere disse prosjektene, vet du, hver organisasjon er unik. Det vil være områder som vil være veldig, veldig viktige for dem. Kanskje, du vet, det er prosessledelse eller kvalitetsstyring eller risikoer - avhenger av hva det er, men du vil se og lage et mål eller en grunnlinje, og deretter også tenke på hva som definerer suksessen.

Når du tenker på å måle og styre denne typen ting, vil du først sikre deg noen utøvende sponsing for et program som dette. Dette er noe som vil være tverrfunksjonell i hele organisasjonen, så selv om Susie Q og John Smith bestemmer de, "Jøss, la oss gjøre dette. Vi trenger å gjøre dette, " de kan ikke gjøre det i en silo i organisasjonen deres, eller til og med om det er IT. Du må virkelig ha det innkjøpet fra virksomheten og ekspertene for databehandlere. De trenger å ha litt tid. De vil ikke at det bare skal være en ekstra oppgave. Hvis du noen gang har jobbet med - tror jeg at jeg har utført noen masterdatahåndteringsoppgaver, prosjekter før og datakvalitet - og vanligvis, vet du, kommer du til virksomheten og de, “Åh, datastyring.” Det er ikke noe de er spent på. Og de er som: "Å, nei. Vi må ha tid til dette, ”og det gjør de. Så du vil ønske deg litt tid. Du må ha den velsignelsen fra toppen. Du vil at den skal være tverrfunksjonell.

Igjen, dette er noe som virkelig berører mange områder i organisasjonen. Og med GDPR, bør det gjøre det litt enklere fordi, igjen, lovene fra GDPR og der personopplysningene blir brukt for kundene dine og brukt i hele organisasjonen, det burde være litt enklere hvis du bruker det, hvis du har å holde seg til GDPR. Blir tunget bundet her. Det skal være lettere for deg å gjøre. Du vil tilordne noe ansvar og så se på, du vet, du kommer til å tilpasse disse. Så du ser alltid på denne typen veiledning som disse organisasjonene gir, og det er vanligvis hva de er: De er retningslinjer for deg og du kommer til å implementere for kulturen din i organisasjonen din.

Å ha jobbet i styring har virkelig vært en veldig viktig, en av tingene som noen av produktene som jeg utviklet da jeg var verdensomspennende produktadministrasjon hos Microsoft, var selvbetjenings BI og gjorde det mulig for forretningsbrukeren og den ikke-tekniske databrukeren å leke med data og lage sine egne rapporter, og mange ganger vil IT presse tilbake. Så jeg har brukt mye tid på denne styringen og sørget for at produktene vil ha de riktige funksjonene og revisjonen og loggføringen, og du vet det, slik at de ikke ville få ned databasen per se. Men det er en ramme som, du vet, jobber gjennom årene på dette spesielle temaet for denne typen ting som også er ekte som datahåndtering. Du ønsker å ha den stiftelsen som er opprettet med utøvende sponsing for dette, og du vil ønske det engasjementet mellom virksomhet og IT.

Så det gjør, igjen, vi snakket om budsjett / tidsfordeling og å utvikle nye prosesser. Det vil være en kulturendring når du gjør noen av disse tingene, vet du, begynner å se på data. Men du vet, det er veldig viktig fra et strategisk perspektiv, igjen. Og for å gi deg en følelse, her er et eksempel, og jeg renset det fra et av mine gamle prosjekter fra mange år siden om denne typen ting. Og igjen, dette er sannsynligvis mer fra det generiske styringsmessige synspunktet, men kan sikkert brukes på nytt for disse typer prosjekter med å styre og utvikle databehandlingsprosessene dine og styre dem. Du har ekspert på forretningsemner, vi har datatilitsatte her, IT-fageksperter, du vet, for forskjellige bransjer. Mange bedrifter som er større, vil ha forretningsstandardbrettet ditt og bedriftsarkitektene og dataarkitektene og modellene der inne. Så det vil være noen forskjellige fageksperter fra forskjellige nivåer. Og igjen, mange av disse - jeg hater å ha det som et eksempel - de vil tilpasses organisasjonen din og kulturen din.

En av tingene når du jobber med disse prosjektene, igjen er det mange ganger sannsynligvis ikke det mest spennende prosjektet i organisasjonene, ikke så visuelt som folk ønsker. Det er morsomt, det er en av de tingene som når konsulentfirmaet kommer inn i eller til og med i din egen IT-gruppe eller BI-kompetansesenteret ditt, eller analysesenteret for dyktighet kommer inn og vi jobber med data kvalitet og datahåndtering modenhet, de er kanskje ikke utrolig glade for å gjøre det. Men du må finne måter å motivere dem på, og ta det med i målingene deres. Så når du tenker på hva det skal være, er det en ting å gjøre denne øvelsen en gang, og du får folk om bord. Og du finner ut at de elsket datakatalogen, eller at de elsker noen av disse tingene fordi det gjør livet deres enklere og de kan finne hva dataene betyr eller forstå det, og de kan legge sitt eget perspektiv til det. Og tingen, datakataloger er sannsynligvis et av de største prosjektene for å hjelpe folk virkelig å bli forelsket i dette.

Så neste ting er å holde dem engasjert. Hvordan holder du noen engasjert som kanskje ikke bryr seg om dette? Det er å definere noen beregninger og inkludere det, måling av dem i og deretter gi litt læring for når det er brudd og en viss bevissthet om at "Hei, vi hadde det veldig bra en stund og ikke så bra etter en stund." Så de er typer ting å tenke på for å fortsette. Og når du tenker på å score, og dette er et eksempel fra CMMI, er det slik de scorer det. Igjen skal du ha dine egne dashboards, dine egne KPI-er, du vet, forskjellige måter folk måles i en organisasjon. Men du har forskjellige måter å score og måle din egen suksess. Mitt viktigste poeng om at du bør ta bort fra dette, eller en krok for å ta fra dette, er å sørge for at du har en måte å måle suksess på, og at du også kan feire suksessene dine.

Så med det setter jeg pris på at du har hengt deg inn i dette spennende emnet, og jeg kommer til å vende meg til Ron, det kommer til å grave litt dypere.

Ron Huizenga: Tusen takk, Jen. Og takk, alle sammen, for at du ble med oss ​​i dag. Jeg skal nå ta et par fasetter av det Jen snakket om og gå litt dypere på bestemte områder. Men det jeg også skal gjøre er å gi en slags oppsummering av hvordan du i det minste kan ha en slags selvvurdering på høyt nivå av noen av disse områdene også. For som du så med CMMI-modellene og den typen ting, kan du gå veldig dypt veldig raskt med mange forskjellige indikatorer. Så det vi virkelig ønsker å komme til er noe slik at du kan få en god følelse av hvor organisasjonen din er på et ganske høyt nivå og deretter begynne å bore inn i de andre. Så med det skal jeg snakke om organisatorisk effektivitet. Og jeg kommer til å basere det på CMMI og noen av de andre standarder eller kunnskapsorganer som har blitt fremkommet av det gjennom årene. Og så skal jeg snakke om noen av forfallsindikatorene for datamodning og prosessmodenhet fordi, når vi går gjennom dette, vil du se at de går hånd i hånd. Og støtter perspektiver, snakket Jen om styring på ett område. Og jeg skal også snakke om bedriftsarkitektur litt også. Og så skal vi oppsummere det og komme til selve rundbordet.

Hvis vi ser på det, er det mange standarder og BOKer - som selvfølgelig er kunnskapskilder - som har blitt publisert gjennom årene. Mange av disse har virkelig kommet fra evnen til modenhetsmodell. Og det er her CMMI som Jen snakket om, kom fra. Selve CMM-modellen var faktisk i 1998. Den ble faktisk startet av en herre ved navn Watts Humphrey da han var sammen med IBM. Han hadde en 27 år lang karriere hos IBM. Men hans virkelige aktive utvikling av den aktuelle modellen startet da han var på Carnegie Mellon, og den ble bestilt av det amerikanske forsvarsdepartementet. Mange andre standarder har blitt brukt for å utlede dette. Og noe som er veldig bra å vite om bransjen når vi snakker om dette i noen av de andre standardene, er at når vi ser på tidspunktet for dette, er det også på bakgrunn av ting vi så i industrien generelt. Dette var da kvalitetsbevegelsen virkelig begynte å ta grep, spesielt innen industri, og som snurret til andre områder. Der vi så på måter å forbedre produksjonsprosessene på, gjøre ting som total kvalitetsstyring, just-in-time produksjon og andre ting. Og mye av filosofiene som kom ut av det, kom inn i hele kvalitetsarbeidet.

Og det er virkelig et slags hoppested som mange av disse tingene startet fra. Det startet i den generelle bransjen og tok seg også inn i IT og data og prosess- og informasjonssystemer. Andre standarder som vi ser som er mer nærstående eller mer spesifikke for noen av de tingene vi snakker om, er selvfølgelig datamodellen, som Jen snakket litt om. Det finnes også modenhetsmodellen for forretningsprosesser fra Object Management Group. Og en rekke andre standarder som du kanskje har sett at organisasjonen din kanskje kaster seg med eller brukes til forskjellige virksomhetsområder, spesielt IT-drevet, for eksempel COBIT, som er kontrollmål for informasjon og teknologi, ITIL, som generelt er infrastruktur -fokusert, noe mange av dere kanskje har taklet. Igjen, total kvalitetsstyring. Og spesielt når du kommer inn på ting som beregninger og alt annet, kan det hende du har sett ting som statistisk prosesskontroll spille inn. Og så er selvfølgelig noen av kunnskapene som vi arbeider med informasjon eller IT-fagfolk. Datahåndteringsorganet av kunnskap av.

Det er også, tilsvarende det, en virksomhetsanalyse av kunnskap. Og prosjektledelsen kunnskap. Du kan ha flere eller flere av disse tingene som brukes av forskjellige interessenter i organisasjonen din samtidig. Men la oss slags filtrere ut gjennom BOK-ene og la oss gå tilbake og si, hva er modenhet? Og vi lister definisjonen av moden fordi når du spør hva modenhet er, når du slår den opp i ordboken, sier den faktisk "du er moden." Så å bruke ordet "moden", betyr det virkelig å ha nådd en avansert utviklingsstadium - selvfølgelig veldig generisk. Men det vi virkelig ser på her, er å fremme det vi gjør til et høyere og høyere prestasjonsnivå når vi går gjennom. Og når du ser på mange standarder, som du vil se, spesielt CMMI og modenhetsmodellen virkelig baserte ting på en fem-punkts skala, så det gir oss en gradvis måte å se og si, hvordan er vi utvikler oss faktisk på denne skalaen i hvordan vi vokser?

Når vi ser på modenhet, må vi imidlertid være i balanse når det gjelder å oppnå organisatorisk modenhet i de tingene vi er interessert i. Du må oppnå datamodning, og vi skal snakke om noen av kriteriene du må gjøre der, men du må oppnå prosessmodning samtidig. De er to sider av den samme mynten, og de må gå hånd i hånd. Du kan ikke gå fra, for eksempel, null til fem på en datamodningsskala uten å øke prosessen din modenhet, og det samme er tilfelle med prosess modenhet. De er begge satt sammen, og de drar hverandre med på turen mens du faktisk utvikler deg gjennom de forskjellige stadiene. Og jeg skal snakke om det litt mer i et fremtidig lysbilde her. De andre tingene vi må innse er å oppnå både data og prosessmodning er grunnleggende for bedriftsarkitektur og grunnleggende for noen av styringssakene Jen også snakket om. Vi gjør det mulig for dem gjennom å oppnå modenhet i noen av disse tingene som vi prøver å gjøre.

Nå inn på lysbildet som Jen sa at jeg skulle snakke om mer detaljert. Jeg har tatt bare noen få kategorier, og bruker CMM-skalaen her, og jeg har faktisk min egen, legger jeg faktisk til et null i form av, på toppen av skalaen fordi det kan være visse tilfeller der du faktisk ikke har laget noe trekkverk i det hele tatt. Så dette er bare måter å gjenkjenne det som skjedde. Så hvis vi ser spesielt på styring av data, kan du starte på null fordi du ikke har noen program for styring av data. Når du begynner å modnes gjennom de forskjellige områdene, når du først har introdusert det på prosjektnivå, deretter et programnivå, gjennom divisjoner og til slutt hele virksomheten, er det slik at du fra et styringsperspektiv faktisk modnes og vokser som en organisasjon mens du gjør dette.

Andre fasetter av det, for eksempel masterdatahåndtering, kan du starte på null uten formelle klassifiseringer av materiedata. Så kommer du til, vokser du til et punkt der du er klar over at du har stamdata og du begynner å klassifisere, men det er ikke integrert. Så begynner du å jobbe mot integrerte og delte depot. Når du kommer inn i et standardisert miljø, er det når du ser på å tilby tjenester for datastyring. Og når du går videre der oppe, kommer du til å etablere mesterdatatyrmenn og etter hvert et datatilsynsråd som virkelig ser på dette alvorlig hele tiden. Når du ser på det tekniske miljøet og applikasjonene og databasene du har fra et dataintegrasjonsperspektiv, igjen, i et umodent miljø, vil du ha et antall ad hoc, punkt-til-punkt-grensesnitt og den typen ting. Og når du vokser gjennom, begynner du å introdusere noen vanlige verktøy og standarder. Så begynner du å se på vanlige integrasjonsplattformer når du vokser ut. Når du blir standardisert, jobber du med standardisert mellomvare og mulige enkle ting som enterprise service busser, kanonisk modell, kategorisere alle dataene i organisasjonen din, og også knytte deg til ting som forretningsregler i depotet ditt og den slags av ting. Og så gå enda lenger der du får det fullt integrert i organisasjonskulturen. Og selvfølgelig er kvalitet viktig. Som Jen snakket om, mange av beslutningene og mange verktøyene som er der oppe, antar du at du har data av høy kvalitet som du jobber med. Så datakvalitet er noe som er et grunnleggende grunnlag for å oppnå datamodning.

Igjen, når du ser på dataene, kan du ha mye siloer og spredte data i umodne omgivelser. Du kan ha uoverensstemmelser som blir akseptert. Og så begynner du å jobbe med det, gjenkjenne det inkonsekvente og så begynne å se på planlegging. Og hvis du ser på styrte miljøer her, er noe veldig viktig her datarensing ved forbruk for å kunne bruke dataene i beslutninger. Så det vi egentlig snakker om der er datarensing, der vi skal laste det inn i datavarehus og andre beslutningsstøtteverktøy. Og dette er analogt med det vi pleide å se i dataproduksjonstypen industri der folk ville bygge produkter, de ville komme seg ned langs samlebåndet og på slutten av det, ville du inspisere produktet og gå, “Åh, Vi har mangler her. ”En gang du aldri kan gjøre er at du aldri kan forbedre et produkts kvalitet ved å inspisere det på slutten. Du kan se problemene med det, og så kan du iverksette tiltak for å forbedre de neste og andre som kommer etter linjen etter det, men du kommer aldri til å forbedre det ved å inspisere det på slutten. Så det er her du når du beveger deg fremover, spesielt i data, beveger deg mer fra en inspeksjon og et rensende synspunkt på forbruksstedet der du begynner å prøve å bygge det inn ved kilden, rett der du fanger data, prosessene som påvirker disse dataene, og sikrer at dataene er nøyaktige og passer for konsum på alle prosesser gjennom veien. Når du utvikler deg videre, begynner du å utvikle deg og få KPIer av høy kvalitet og virkelig begynne å utvikle den forebyggende tilnærmingen til datakvalitet når du går fremover.

Når det gjelder organisasjonsatferd eller ting du ser er at hvis du ikke tror at du har et problem eller at du ikke er klar over det, kan du være en fornektelsesfase i organisasjonen din, som forteller meg at du er nede et nivå null eller potensielt flytte inn i et. Hvis det er mye kaos rundt dataene dine og prøver å løse disse uoverensstemmelsene, er du sannsynligvis på et nivå. Når du fremdeles er i en reaktiv modus, går du over til administrert, men du kommer ikke til å bli standardisert før du faktisk har et veldig stabilt datamiljø som omfatter både styring, kvalitet, styring av masterdata og data integrasjon, for bare å nevne noen av punktene. Og igjen, når du først er kommet forbi det, er det når du begynner å bli virkelig proaktiv styringsstiler. Hvis du kommer til den delen der du har en veldig forutsigbar oppførsel, og også analysene for å sikkerhetskopiere den og KPIene for å sikkerhetskopiere den i organisasjonen din, når vi ser på dette og legger over et par ting, er det noen andre ting vi kan se om organisasjoner og hvor de er. La oss se på det primære IT-fokuset i en organisasjon. Hvis det primære fokuset ditt innen IT fremdeles er på teknologi og infrastruktur, er du sannsynligvis nede mot den mindre modne enden av skalaen. Men når du virkelig fokuserer på informasjon og muliggjør strategisk muliggjøring av virksomheten, kommer du nærmere den modne enden av skalaen. Også når du ser på det fra et dataperspektiv, hvis du er i den lave enden, har du høy datarisiko, og hvis du er i den høye enden, har du senket risikoen knyttet til data. Og baksiden av det er verdiskaping av organisasjonen. Lavere datamodning betyr at du sannsynligvis har et relativt lavt verdi generering, spesielt med tanke på dataene du har i organisasjonen din. Og når du går opp skalaen, får du en generasjon med høy verdi.

La oss se på dette når det gjelder datamodellering i seg selv. Noen ganger har datamodellering blitt det rødhodede stebarnet. Og datamodellering er grunnleggende for å oppnå datamodning. Så jeg vil bare snakke om noen få tegn på hvordan datamodellering binder seg inn i dette. Hvis det bare blir brukt til dokumentasjon eller enkel, fysisk databasegenerering for små apper og den typen ting, er du sannsynligvis nede på et nivå når det gjelder datamodning. Når du begynner å omfavne og gjenkjenne de forskjellige typene modeller, inkludert konseptuell, den logiske modellen og den fysiske modelleringen der det også er, vet du, i utgangspunktet driver du opp designet. Du bruker det virkelig som et designmessig standpunkt, så er du på et nivå.

Når du begynner å se på det fra et mer bedriftsnivå, inkludert å bygge ut bedrifts- eller kanoniske modeller, introdusere konseptene og knytte inn flere modeller, datalinje og bygge styringsmetadata rett inn i modellene dine, begynner du å komme til nivå tre, og deretter gå videre til metadata for full styring, integrering av virksomhetsordliste, osv. Å se på livssyklusen og verdikjeden for data er når du virkelig kommer til et nivå fire. Og igjen, fullt integrert modellering med virksomhetsordliste, metadata, å kunne drive ting som selvbetjent analyse, det er virkelig når du har oppnådd en ganske moden tilstand.

Som en del av det, vil jeg snakke om dataets livssyklus veldig kort. Og grunnen til at jeg vil snakke om det, er data livssyklus dessverre blir ofte ignorert. Og hva det handler om, det beskrev virkelig hvordan et dataelement opprettes, leses, oppdateres eller slettes, og prosessene som virker på det i hele organisasjonen din. Så de av oss som har vært i bransjen i lang tid, refererer til dette som CRUD fordi det er opprette, lese, oppdatere og slette. Men vi må forstå dette på et grunnleggende nivå når vi arbeider med dataene i organisasjonen vår. Mange faktorer kommer inn. Hva er forretningsreglene som handler etter det? Hva er forretningsprosessene som bruker, produserer eller endrer dataene? Hva er applikasjonene som faktisk implementerer disse forretningsprosessene slik at du kan gjøre det? Alt som spiller inn når det gjelder livssyklusen til data.

Og igjen, Jen henviste til dette tidligere - det kan ikke nødvendigvis være en kilde til sannhet. Og det kan være flere måter et bestemt dataelement blir opprettet. Og det kan hende du faktisk må komme inn, forskjellige ting kommer inn gjennom flere systemer eller flere inntak som du må forene og løse for å finne ut hva den rette datakilden er for den bestemte beslutningen på det tidspunktet. Det kan være flere varianter av dataene for forskjellige formål i en organisasjon. For å kunne oppnå dette, må du være i stand til å modellere forretningsprosess, datalinje som inkluderer datastrømmene, integrasjon og som inkluderer ting som ETL, så trekke ut, transformere og laste for datavarehuset ditt, datamart og iscenesettelsesområder og selvfølgelig datakoblinger på big data-siden også spiller inn. Når du drar denne informasjonen ut av datasjøen, må du vite hvordan du bruker den og hvordan du bruker den. Når det gjelder selve livssyklusen, er det virkelig hvordan vi oppretter eller samler inn nye data, hvordan vi klassifiserer det - fordi du må klassifisere det for å forstå og jobbe med det effektivt - hvordan du lagrer det, hvordan du bruker du det, hvordan du endrer det til den forretningsprosessen, der den deles i organisasjonen - og veldig viktig: oppbevaring og arkivering. Hvor lenge beholder du dataene? Når arkiverer du det? Når ødelegger du til slutt dataene? Alle disse tingene må tas i betraktning i din datalivssyklus, og du må gjøre alle disse for å oppnå et høyt datamodningsnivå i organisasjonen din.

Nå er baksiden, igjen, jeg sa at de er lik tvillinger der du trenger å snakke om prosessmodning i forbindelse med datamodning - de går hånd i hånd. Igjen, jeg har noen få forskjellige ting her, og - ikke bekymre deg for at jeg ikke kommer til å lese gjennom alle disse, men bare en slags sjekkliste, så igjen kan du begynne å selv vurdere hvor organisasjonen din er i av prosessmodning. La oss se på ting fra begynnelsen til høyre gjennom de optimaliserte sidene igjen. Igjen bruker vi den samme fempunktsskalaen som ble avledet fra modenheten for evnenes modenhet. Hvis du ser på ting som fokus, hvis du er på et lavere nivå eller det innledende nivået av prosessmodning, kan du finne i organisasjonen din at folk virkelig er avhengige av sine egne metoder for å fullføre arbeidet sitt. Og du kan se noen helter og den typen ting for å kunne få ting gjort. Så begynner du å komme til et punkt der du er mer proaktiv med det, der ledelsen tar ansvar for arbeidsenhetene og ytelsen. Deretter begynner du å utvikle standard integrerte prosesser. Deretter prosessstabilitet og gjenbruk. Så begynner du å se mer av en kultur for veiledning og statistisk styring for å beregne beregninger og KPI-er angående disse prosessene og til slutt til full optimaliseringsnivå.

Når du ser på arbeidsstyringen, kan det hende du vil gå etter, du kommer til å gå fra et område der du har inkonsekvente nivåer av arbeidsstyring til mer styrt, der du balanserer minst på et høyere nivå dine forpliktelser til ressurser. Så til et punkt der du har en mer tilpasningsdyktig eller smidig organisasjon slik at du kan standardisere prosessene dine, men skreddersy dem til det beste som brukes under forskjellige omstendigheter i organisasjonen. Og når du kommer til avansert, er det her empowerment er veldig viktig, og det betyr at hva alle intuitivt forstår hva som skjer, og personalet har prosessdataene, slik at de kan evaluere og styre sitt eget arbeid.

Igjen, med å gå tilbake til produksjonsanalogien - da vi så at da vi begynte å modernisere samlebåndene våre og alt slikt i industrien, begynte vi å snakke om den totale kvaliteten og makten til arbeidere selv på samlebåndet, hvor hvis noen så noe galt i et hvilket som helst bestemt produksjonsstadium, fikk folk fullmakt til at de kan trykke på den store røde knappen og slå av hele samlebåndet til problemene var løst før ting gikk videre. Og det er den typen mentalitet og en slags kultur som vi ser etter data i prosessene våre for å sikre at vi faktisk optimaliserer dataene og prosessene våre i organisasjonen.

Andre indikatorer på kulturen din - er din kultur stillestående når det gjelder ikke noe identifiserbart grunnlag for reelt engasjement i forbedring av forretningsprosessene dine? Er det en delegasjon av ansvar, som vi ser lenger opp i skalaen? Og når du går videre, kan det hende du fortsatt har siloer, men når du begynner å gå opp med tanke på kulturen og tingene du gjør i forretningsprosessen, bryter du også ned de forskjellige virksomhetssiloene og utnytter prosesser på tvers av organisasjonen din. Det er veldig viktig at når du kommer til arrangementsfasen, er det du virkelig baserer deg på, snarere enn magefølelse, at du faktisk samler kvalitetsberegninger, og at du har beregninger på plass for å forutsi din evne til å utføre virksomheten din. operasjoner, og det er ekstremt viktig.

Når det gjelder arkitektur, la oss snakke om det fordi mange av oss her er innen IT eller alltid ser på IT. Igjen, samme type ting som vi så i dataene. Vi har desperate IT-systemer hvis du virkelig er nede i de første stadiene av prosessmodning. Når du begynner å styre prosessene dine, kommer du til å se at noen tjenester blir satt opp der du virkelig bruker mer av en tjenestebasert tilnærming. Hvis du blir standardisert, vil du se mer av en full-service-adopsjon når det gjelder data og tjenester og prosesstjenester og den typen ting, helt frem til hvor du kommer til en fullservice eller en ny arkitektur. Og så til slutt til en full prosessdrevet bedrift som bruker dataene dine.

Igjen, de samme typene skalaer når vi ser på dette. Når det gjelder produktivitet, på et lavt nivå av prosessmodenhet, vil du se lave nivåer av produktivitet og høy prosessmodning, og du vil se mye høyere produktivitet. Og kvalitet går hånd i hånd med det også. Samme som med dataene - hvis du er på et lavt modenhetsnivå, vil du se et høyt nivå av risiko og også et høyt nivå av avfall. Men jo høyere modenhetsnivå du vil redusere risikoen og redusere avfallet betydelig. Når det gjelder noen av tingene du kan se som slags symptomer eller indikatorer i en organisasjon, hvis den primære filosofien er basert på kostnadskutt, er du sannsynligvis nede på et lavt nivå av prosessmodenhet. Deretter kommer den til å gradere seg og gå oppover mot å se på effektiviteten nærmere i organisasjonen din, og når du kommer til et veldig modent nivå, kommer du til å fokusere på verdiskaping igjen.

Fra et organisasjonsledelsesperspektiv, hvis kaos hersker, er det vanligvis et symptom på, igjen, organisasjoner med lav prosessmodning. Men du begynner å fokusere på det jeg kaller mer en ledelsesmentalitet der - og det kan være litt ledelse ved vedtak, eller å pålegge ting - der du virkelig er da, når du kommer til de mer modne nivåene, oversetter ledelsen din til mer av ledelse. Med andre ord, filosofien om forbedring er innebygd i kulturen og fra administrerende direktør og ned, de fremmer hele filosofien om å forbedre prosesser og kontinuerlig, kontinuerlig forbedring i organisasjonen din som helhet.

Når det gjelder prosessmodell - og jeg skal gå igjennom disse tingene ganske raskt her - la oss igjen se på prosessmodeller når de binder seg inn i selve prosessmodenheten. Igjen, veldig lik de tingene vi så på datamoden, hvor du på lave nivåer eller nivå en bare kan dokumentere prosesser eller den nåværende tilstandsprosessen, men du bruker virkelig ikke den når det gjelder å føre ting fremover. Når du begynner å bli moden, skal du bruke forretningsprosessmodellering for å øke faktisk forretningsprosessstyring i organisasjonen, og deretter utvikle seg videre der du bruker den og kontinuerlig oppdatere modellene for å forbedre prosessforbedring til der du til slutt komme til prosessdesign. Og når du blir full moden, eller, du vet, hva du vanligvis ser i magre eller organisasjoner som har tatt i bruk programmer av høyere kvalitet, for eksempel Sigma, er det igjen der du har den kontinuerlige forbedringsmentaliteten og den er inngrodd rett i modelleringen av din organisasjon. Så akkurat som vi bruker tekniske tegninger for å bygge produkter, enten det er fly eller bygninger og skyskrapere og den typen ting, er vi avhengige av at modellene våre faktisk driver virksomheten videre, fordi det er designelementet som faktisk driver organisasjonselementene våre fremover .

Nå, igjen, skal jeg ikke gå igjennom dette og hvert eneste ord her i detalj. Det jeg har gjort, er at jeg har tatt de to enklere rutenettene, og jeg har valgt en rekke ord som ble brukt i noen av de andre deskriptorene både for datamodning og prosessmodenhet. Så når du ser på dette etter faktum, kan du begynne å tenke på noen av ordene du ser kommer ut i dine egne interne kulturer når det gjelder ting som blir sagt. Og det vil hjelpe deg å begynne å klassifisere hvor vi som en samlet organisasjon begynner å passe på denne modenhetsskalaen totalt sett. Så hvis du ser ting som inkonsekvens eller stillestående eller ineffektivitet dukker opp ganske ofte eller kaos, vil du vanligvis være i den nedre enden av skalaen. Når du begynner å tenke på ting som kontinuerlig forbedring, strategisk justering, en forebyggende tilnærming til mangler og kvalitet og den typen ting, full integrasjon og du snakker om beste praksis i konkurransefortrinn, er det når du skal se deg selv opp ved optimalisatoren, høyere ende av skalaen.

Igjen, noe jeg også vil påpeke at når du begynner å se på datastyring, spesielt når du ser på bunnen av skalaen, er i begynnelsen, kan datastyring bare innføres på individuelle prosjektnivåer. Du må utvikle seg til et punkt der datastyringen og det spesielle målet er fra prosjektdatastyring og har utviklet seg gjennom programstyring og divisjonsstyring av data, hvor det igjen er virksomhetsomfattende og innebygd i organisasjonen som helhet.

Jeg har snakket om at dette faktisk er tvillinger som fungerer sammen når det gjelder datamoditet og prosessmodning. Når du oppnår den modenheten, er det på hver side av skalaen en reise, og du kan ikke hoppe skritt. Hvis du er i null, må du utvikle deg gjennom trinn en, to, tre, fire og til slutt komme til fem. Og det er veldig få organisasjoner i verden som faktisk er på en fem. Så mange organisasjoner er mer enn glade for å være på et punkt der de er på et tre og deretter kunne bruke det som et springbrett fremover. Og igjen, du kan ikke gå, du kan ikke være på fire fra en datamodning og en på en prosessmodenhet. Det fungerer bare ikke fordi de er så sammenvevd at du må forstå og ha et godt håndtak på dataene og prosessene dine i forbindelse med hverandre.

En god analogi til å tenke på dette som det er, på din reise mot organisert modenhet, la oss anta at teamet ditt består av to personer: Den ene er prosessmodenhet, og den andre er datamodenhet. Du kjører en hinderløype og er bundet sammen med et kort tau. Og for å komme til slutten av dette kurset, betyr det at dere begge må komme deg gjennom, ikke bare alle hindringene, men du må komme deg gjennom alle hindringene nesten på samme tid eller veldig nærme hverandre. kunne gå videre og komme til neste hinder. Det er en veldig god måte å tenke på å balansere prosessmoden og datamodulen. Så med andre ord, du kan være noe prosessentrisk og du kan være noe datasentrisk, men det kommer til å være en ledende indikator, og det kan ikke være mye gap for å faktisk føre deg opp gjennom nivåene.

Og når vi ser på det igjen fra datastyring, er en av tingene jeg ønsket å påpeke i tilfelle du ikke var klar over, DAMA faktisk ga ut Data Management Body of Knowledge Volume Two tidligere i år, og av de tingene som endret det er selve DAMA-hjulet. Og jeg representerte det faktisk litt annerledes, der datastyringen er i sentrum og de ti forskjellige kategoriene rundt det forskjellige hjulet. Noe som er veldig viktig å se her er datamodellering og design har faktisk sine egne områder på rattet nå - det var slags blandet inn i de andre, tidligere. Noe av det som er et veldig grunnleggende poeng her, er datamodellering spesielt viktig for alle disse andre aspektene, fordi enten vi driver med datamodellering av databasene våre eller metadataene vi har å gjøre med, har datamodellering en rolle å spill i alle disse andre brikkene som vi snakker om. Og prosessmodellering har også en rolle å spille i mange av disse tingene, for i tillegg til å forstå dataene i seg selv, må vi forstå hvordan de brukes, og det er slik prosessmodellering virkelig hjelper oss å gjøre det.

La oss nå bytte tannhjul litt og snakke om bedriftsarkitektur. Og modeller er også avgjørende for bedriftsarkitektur. Og jeg baserer dette på eksempel, og dette er Zachman-rammen som jeg viser her veldig raskt. Og når du ser på dette, ser du flere ting her. Du ser hva, hvordan, hvor, hvem, når og hvorfor er slags skala øverst. Og så går du gjennom mer detaljerte nivåer av utdyping, hvis du vil, med tanke på typene modellering eller typer ting du utdyper når det gjelder bedriftsarkitektur fra et veldig høyt kontekstuelt nivå helt ned til et detaljert nivå, inkludert fysisk gjennomføring. Hvis du ser på de første kolonnene, er det som er veldig datakrevende og data involvert. Hvordan er veldig prosessdrevet. Og hvis du ser på de andre aspektene, kommer du til å bruke en kombinasjon av prosess- og datamodellering når det gjelder å kjøre opp resten av informasjonen. Du kommer til å ha data om alle disse forskjellige tingene, og prosessmodellene dine vil også binde ting inn, som hvor ting skjer, ansvaret. Og også når det gjelder prosessmodellering som vi også gjør i verktøyene våre, kan du begynne å knytte dette inn i målene og forholdene og forretningsreglene som driver disse forskjellige tingene du gjør.

Fra et overordnet perspektiv av Zachman-rammen, er en av de gode måtene å tenke på dette også at du er modelldrevet og faktisk går gjennom de forskjellige nivåene. Så du begynner med et høyt nivå omfang og det kontekstuelle. Deretter utvikler du deg mot forretningsmodeller, ned i systemmodeller, deretter teknologimodeller, og deretter din veldig detaljerte fremstilling av de tekniske modellene også. Og igjen representerer data hva prosessen er hvordan og det er virkelig en kombinasjon av data og prosessinteraksjon som driver alle de andre egenskapene her.

Basert på det er det ikke tilfeldig at måten vi ser på ideen om bedriftsarkitektur er basert litt annerledes enn noen andre kan. Ganske ofte vil du høre om de fire søylene i bedriftsarkitektur er data, anskaffelse, forretnings- og teknisk arkitektur. Vi ser på det litt annerledes enn det. Vi ser på dataarkitektur som det grunnleggende fundamentet som driver all virksomhetsarkitektur av to grunner. Det ene, det var der det startet. Til og med ting som Zachman-rammeverket vokste først og fremst ut av dataarkitektur, og vokste deretter til å omfavne de andre aspektene ved arkitektur også. Og to, fordi det grunnleggende båndet mellom prosess og data. Derfor ser vi forretningsarkitekturen som den sentrale pilaren i bedriftsarkitektur. Og så kompletteres det selvfølgelig med applikasjonsarkitektur og teknisk arkitektur, som er absolutte nødvendighetsaktiverere, for å tillate oss å drive ekte virksomhetsinnsats. Når vi ser på det når det gjelder ER Studio Enterprise Team Edition, vår integrerte modelleringsplattform, er det slik det kommer inn. Og dette er et kontektsdiagram på høyt nivå av noen av modelleringene som vi gjør og noen av de grunnleggende grunnene. Og dette blir faktisk kjørt inn, dette er faktisk skjemaet ut i et prosessdiagram. Så når vi ser spesielt på databasearkitekturen vår og forretningsarkitekturen nedenfor, leverer vi rollebaserte verktøy.

Og når du ser på forretningsarkitektverktøyet nede i nedre venstre hjørne, er det der typisk forretningsanalytikere og forretningsarkitekter jobber. Og de fokuserer vanligvis på noen av forretningsprosessene og begynner å drive dem ut. Men de er også fokusert på hva. Så da begynner vi å gjøre noe konseptuell datamodellering og den typen ting. Vi kan utnytte og bringe de konseptuelle modelleringskomponentene inn i datamodelleringsverktøyet og til dataarkitekten, der de videreutvikles til logiske datamodeller og selvfølgelig til slutt de fysiske modellene slik at vi kan generere de fysiske databasene. Og vi kan også skyve tilbake slik at de konseptuelle modellene også blir oppgradert i forretningsarkitekturområdet. En veldig viktig ting her er at vi støtter de forskjellige typene modellering. Så, igjen, BI er veldig viktig og datasjøer og den typen ting, så vi gjør faktisk litt modellering også, og også som en del av det, gjør vi avstamningsmodellering. Så ikke bare ETL når det gjelder hvordan du kartlegger fra fysiske modeller til dimensjonsmodeller for datavarehus eller til og med henter inn ting fra datasjøene og ser hvordan de kartlegger, vi kan knytte alle disse tingene sammen. Samt videresending av reverse engineering fra andre modelleringsplattformer, fra big data plattformer.

Og så også ting som ETL-verktøy, slik at vi faktisk kan begynne å hente ut avstamningsdiagrammer rett fra ETL-spesifikasjoner som du måtte ha i ditt eget miljø. Det er også veldig viktig å vite at vi har måttet utvide utover relasjonsmodellering. Vi har visse plattformer som Hive og spesielt MongoDB, vi begynner nå å snakke om dokumentbutikker, der vi har konsepter som innebygde objekter og matriser. Vi har faktisk utvidet notasjonen for å kunne imøtekomme de typene modellene også fordi det er et ikke-relasjonelt konsept. Alt vi skapte i dataarkitektverktøyet med tanke på dataartefakter, enten det er logiske enheter eller fysiske tabeller og deres attributter, kan deretter skyves tilbake til modelleringen for forretningsprosessering. Så når du utdyper forretningsprosessmodellene fra et høyt nivå og kommer deg ned til et lavere nivå, kan du faktisk koble inn de faktiske dataelementene. Så du kan handle, vi kan spesifisere CRUD-matriser for hva som faktisk skjer. Så det gir deg den datalivssyklusen som jeg snakket om med opprette, lese, oppdatere og slette på prosessnivå. Og vi gjør full BPM-prosessmodellering der med vårt eget sett med overlegg også, slik at du kan begynne å knytte forretningsstrategier, forretningsmål. Vi kan også knytte inn applikasjonene som implementerer disse forretningsprosessene, alt fra modellstyrt synspunkt.

Andre ting er ekstremt viktig er også i våre datamodeller. Datastyringskarakteristikkene eller datakvalitetskarakteristikkene mestrer og styrer. Du kan definere og bygge dine egne metadata der for de egenskapene du ønsker å spore, og det betyr at du nå bruker modellen som blåkopi for å drive det gjennom hele organisasjonen, til metadata-lagringene og alt annet. Og selvfølgelig, en av begrensningene ved modellering, for mange år siden da mange av oss startet i bransjen med å gjøre dette, er at vi ville produsere disse modellene. Hva ville vi gjort? Vi ville skrevet dem ut, vi satt dem på en vegg, muligens for teammedlemmer å dele og den typen ting. Den sanne verdien av dette er å kunne dele og samarbeide i våre organisasjoner. Så det er derfor vi har en depotdrevet tilnærming for hvor vi sjekker inn og sjekker ut modellene og arbeidsområdene våre. Og vi deler dem med våre bestanddeler som er organisasjonen, enten de er andre tekniske interessenter, forretningsbrukere og den typen ting. Og knyt det også til vår samarbeidsplattform som heter Team Server.

Så vi snakket om tidligere virksomhetsordlister og betingelser og viktigheten av det og å utvikle det ordforrådet for virksomheten. Det hele har vært i Team Server, der brukere, forretningsbrukere kan samarbeide om disse vilkårene. De er synlige, kan brukes i dataarkitekt, for eksempel i nærheten av datamodeller, og selvfølgelig kommer mange av disse virksomhetsordlistene ofte fra noen av dataordbøkene som vi har laget i datamodellene våre. Vi kan skyve dem ut etter - Også fra dataarkitektverktøyene er utgangspunktet virksomhetsordlisten, der de kan foredles videre, og alt sammen med endringsledelse rundt det.

Det var mye. Bare for å oppsummere, et par ting vi snakket om er å prøve en ekte organisatorisk modenhet, trenger du en balansert tilnærming som består av datamodning og prosessmodenhet. Du kan ikke oppnå den ene uten den andre. Igjen, grunnleggende, må du ha begge deler og trenger å stole på dette, spesielt datamodellering og prosessmodellering for både bedriftsarkitektur og datastyring og prosessstyring i organisasjonene dine. Bedriftsarkitektur knytter det virkelig sammen når det gjelder å se på disse forskjellige fasettene og perspektivene. Du trenger et solid fundament for dataarkitektur for å gjøre det, og du trenger integrerende prosessmodellering for å gi den forretningsmessige konteksten og slik at du kan drive forretningsprosessen og dataforbruket ditt fremover. Igjen, viktigere enn noen gang før. Jeg kan si, det som er gammelt, er nytt igjen. Så datamodellering, prosessmodellering, avstamning, metadata og ordliste er grunnleggende for å kunne oppnå dette, og ER / Studio Enterprise Team Edition er en samarbeidsplattform som bringer alt dette sammen.

Og med det kan vi gå videre til spørsmålene.

Eric Kavanagh: OK.

Ron Huizenga: Vi drar til deg, Eric.

Eric Kavanagh: Ron, jeg må tippe hatten til deg for all innsatsen du legger ned for å dokumentere disse forskjellige prosessene og rammene. Det er mye materiale du har fått der. Jeg antar at det store spørsmålet jeg har er hvem som skal ha tilsyn med disse tingene i en organisasjon, fordi du berører så mange forskjellige ting. Du regner prosesser, det kommer til å være en sjef for driften eller en operasjonsperson. Data livssyklus, tror du kanskje det kommer til å bli en sjef for dataansvarlig. Du berører så mange forskjellige deler og så mange forskjellige komponenter i virksomheten. Hvordan finner du riktig person eller gruppe mennesker, og er det en styringsgruppe? Hva er det? Hva kan du fortelle oss om hvem som skal gjøre dette i en organisasjon?

Ron Huizenga: Du vet, det er et interessant spørsmål. Vi kan faktisk bruke en dag på å diskutere fordelene ved forskjellige tilnærminger der. Men noe jeg absolutt så, vet du, mens jeg konsulterte før jeg kom inn i produktstyringsrollen, er at når jeg så på organisering, har det vært en del av problemet å få eierskapet og få folk til å ta eierskap til dette. Og når vi ser på fagområdene som vår datamodellering og til og med vår forretningsprosessmodellering, eller i de første dagene, til og med, datastrømskjemaer og slike ting, vokste den typen ut av IT. Men etter hvert som vi har kommet videre, og jeg tror nå erkjenner vi mer og mer at dette virkelig må være forretningsdrevet. Så du vil virkelig at eierskapet for at dette skal være i virksomheten.

Og jeg kommer til å fornærme noen IT-folk her, men jeg er overbevist om at grunnen til at vi har sett utviklingen av sjefen for dataansvarlig, er CIO-rollen har mislyktes i dette i de fleste organisasjoner. Og det er fordi mange av CIO'ene er teknisk fokuserte i stedet for data- og prosessfokuserte. Så jeg tror at du virkelig trenger å ha det, du sannsynligvis kommer til å trenge en slags styringsgruppe i de større organisasjonene. Men dette må virkelig eies av virksomheten. Jeg vil argumentere for at virksomheten din, din prosessmodellering, din datamodellering, alle trenger å høre hjemme i virksomheten, fordi det gir deg muligheten til å sikre at IT, hvem som er forvalter av dataene og implementerer prosessene gjennom det de du lager, du har den hammeren for å sikre at den skjer hvis den faktisk eies av virksomheten.

Eric Kavanagh: Ja, jeg tror jeg vil være enig i det. Men Jen, hva er tanken din om det?

Jen Underwood: Så det er virkelig interessant. Det var det jeg henviste til da jeg sa at å få folk til å bry seg og være interaktive er sannsynligvis en av de viktigste tingene. På et tidspunkt, jeg hadde skrevet en hvitbok om, var det selvbetjent BI-styring som er veldig lik dette. Det gjelder å få til det, finne en måte å motivere folk på, forretningsverdiens side av det, og få dem til å bry seg om det. Og så når de ser, eller de finner, om det er datakatalogiseringen eller hvilken vinkel det tar. Kanskje det reduserer forsendelseskostnadene, legger noe som noen har stått til ansvar for i organisasjonen, det er slik du kan få det til å ta vare. Og ja, virksomheten absolutt. Ekspertene til forretningsemner kommer til å lage eller ødelegge det.

Eric Kavanagh: Det er vanskelig. Jeg tror du alltid vil ha dette konsortiet av interessenter fra hele organisasjonen. Du ønsker selvfølgelig ikke analyse-lammelser. Du vil ikke ha byråkrati for byråkratiets skyld. Det du ønsker er at organisasjonen skal ha en handlingsplan og få disse tingene dokumentert. Du vet, jeg tror når du begynte å snakke om forretningsprosessmodellering, det var varmt for 25 år siden, men det var stort sett løsrevet fra selve virksomheten. Jeg tror i hvert fall i noen bransjer kan du trekke mye av den prosessen ut av den faktiske programvaren som kjører ting. Men jeg tror, ​​i disse dager må vi finne en måte å balansere de to verdenene på, ikke sant, Ron? Du vil ha prosessmodeller som er aktuelle og oppdaterte og gjenspeiler hva som faktisk skjer. Så du vil ikke ha det bare være en egen øvelse der den er, den sitter på en hylle et sted. Men det er, det blir litt utfordrende, ikke sant? Fordi ikke alle operative systemer er på linje med den typen kjørbare koder. Men hva tror du?

Ron Huizenga: Absolutt. Og det er interessant fordi en av tingene jeg ser på er når folk, du vet, vi har blitt et øyeblikkelig tilfredsstillelsessamfunn. Folk tenker: "Åh, vi vil bare gå og kjøpe noen verktøy og få dette til å fungere for oss." Det er som om du ikke skal kjøpe prosessmodning. Du har ikke tenkt å kjøpe datamodning. Det er hardt arbeid. Du må rulle opp ermene, og du må få det til. Og mekanismen for å få det til er modelleringen. Det er for komplisert til ikke å ha en visuell fremstilling av, ikke bare den nåværende tilstanden du jobber med, men også for å kunne utforme hvordan du skal forbedre de forskjellige forretningsprosessene. Du trenger det visuelle rammeverket for å kunne forstå hvilken innvirkning disse endringene kommer til å gjøre.

Eric Kavanagh: Det er virkelig - jeg bare twitret; Jeg tweeter dette akkurat nå - "Du kommer ikke til å kjøpe prosessforfall, du kommer ikke til å kjøpe datamoditet." Jeg kan bare være helt enig med begge disse tingene. Og Jen, jeg vil ta deg inn for tankene dine. Og jeg vil kaste et nytt spørsmål på toppen av det. En av de fremmøtte spør: hva menes med prosessstyrt foretak eller prosessmodning? Jen, kan du snakke med det?

Jen Underwood: Jeg kan faktisk snakke litt bedre til det forrige spørsmålet. Når jeg tenker på, sies sannheten, er det den første du vet kjøper verktøy. Det var en så stor, flott kommentar fordi det er så sant. Men det jeg vil si, det er ganske mye bedre. Så jeg gjennomgår mange løsninger og ser forskjellige rom og tester dem. Det som blir bedre er å oppdage data, tagge og i det minste gi deg en massiv løpende start og også gjøre dette, når jeg sier mindre vondt, det er nesten morsomt. Så forestill deg at en datakatalog eller et MDM-prosjekt er morsomt. Det er, og du har folk i en organisasjon som bruker disse dataene i, enten det er rapportering eller andre typer ting, og jeg tror noen til og med på linjen hadde sagt, hei får folk som bryr seg om deres individuelle utviklingsplan. Ja, til og med ta det opp enda et nivå. Det tar disse tingene og sier nå at vi har redusert feilproduserte forsendelser med 30 prosent, og det er hvor mye penger som ble spart. Det er bare å administrere dataene våre bedre. Det er disse typene ting, og du legger penger rundt det, og du gjør det morsomt. Eller så gjør du det interessant og relevant for det de gjør. Det er slags magi, tror jeg, det mangler i mange av disse engasjementene som folk prøver å gjøre dette i en organisasjon, og det er stoppet.

Eric Kavanagh: Ja, det er et godt poeng. Og, Ron, tilbake til kommentaren din for noen øyeblikk siden rundt viktigheten av å ha en visuell ramme, jeg tror det er helt sant, fordi mange ganger, hvis folk ikke kan se noe, er det virkelig vanskelig å pakke hodet rundt det det betyr, og absolutt når du begynner å snakke om komplekse prosesser med gjensidig avhengighet og kontrollpunkter og alle disse tingene, må du kartlegge det et sted på et tidspunkt, og ideelt sett gjør du det med programvare som har funksjonalitet innebygd i det å katalogisere, for eksempel, hvilke transformasjoner som skjedde ved bruk av forskjellige linjer fra dette punktet til det punktet. Eller hva som er tilgjengelig på dette kontrollpunktet. Og jeg refererer på en måte historien min innen risikostyring der, der et kontrollpunkt er noe poeng i en prosess eller et hvilket som helst alternativ eller individuell eller programvare hvor du faktisk kan endre noe, ikke sant? Det er det de kaller et kontrollpunkt. Og for meg er det virkelig verdifullt at du får den visuelle rammen. For da kan du se og slags gå gjennom, og det tar bare tid. Det tar menneskelig hjerne tid å håndtere det og virkelig forstå det og derfor optimalisere det, ikke sant?

Ron Huizenga: Absolutt. Og for å bruke en annen analogi som jeg tror setter den i perspektiv: Jeg er litt av en luftfartnøtt, vil jeg si, hvis du prøver å tenke på dette på en parallell måte, bør du tenke på å bygge en 747 - eller en Airbus 380, så jeg velger ikke den ene leverandøren over den andre - tenk på hvor vanskelig det ville være å gjøre det basert på dokumenter som bare er sammensatt av tekst, heller enn tegningene og 3-D CAD-tegningene og alt om hvordan som faktisk er satt sammen.

Eric Kavanagh: Ja, det vil være grovt. Og Jen må snakke også.

Ron Huizenga: Virksomheten er den samme, ikke sant?

Eric Kavanagh: Ja, nei det stemmer. Jen må snakke med et av de varme områdene du liker å studere, som er visualisering. Du må kunne visualisere noe for å forstå det fullt ut, ser det ut til for meg.

Jen Underwood: Mange mennesker gjør det, ja. Og til og med bare en visualisering snakker, hva er ordtaket, tusenvis av ord eller noe sånt. Når de ser det, kan de tro det. Og de får det til.

Eric Kavanagh: Jeg er enig. Og jeg elsker, Ron, slik du har dratt dette sammen. Jeg bare antar at jeg bare spør meg selv igjen, du trenger en mester i organisasjonen og som vil være der ute, fungere som bindeledd for forskjellige grupper. Datatilitsvalgte er noe vi snakker om ofte - jeg tror det er i, en veldig viktig rolle, og jeg føler at det er en rolle som har fått mye mer oppmerksomhet de siste tre eller fire årene, da vi slags har satt pris på verdien av data styresett, ikke sant? At datatilitsvalgt er noen som kan snakke med virksomheten, men også forstå systemene, forstå livssyklusen til data, hele bildet. Og jeg antar at den personen kan og burde være under konsernsjefens styre, ikke sant?

Ron Huizenga: Ja, og du trenger et multifunksjonelt team, ikke sant? Så du kommer til å trenge folk som består av et team som gjør det eller som kommer fra de forskjellige områdene som representerer den tekniske siden, du vet, de forskjellige forretningsområdene. Avhengig av hvilken organisasjon du er, vet du, hvis du har et prosjektledelseskontor og mange av initiativene du gjør blir drevet av en PMO, vil du forsikre deg om at du har PMO involvering i tillegg bare for å holde enhver form for harmoni og synkronisere måten de jobber med ting på.

Eric Kavanagh: Jøss, og du vet, en siste ting, jeg legger dette siste lysbildet, styringsrammen. Vi spurte en deltaker, mangler det ikke data fra det lysbildet? Er det implisitt av data i lysbildet eller hva du synes om kommentaren om data som mangler fra lysbildet?

Jen Underwood: Nei, og dette er bare en generisk styringsramme. I hovedsak kommer dette fra BI-plassen med selvbetjening, så data impliseres i mye av dette. Det kom bare fra vinkelen og perspektivene mine, og ikke så fokusert på datasiden i å sette dette sammen. Men data vil absolutt være, når du tenker på alle disse brikkene, vil det være data. Enten det er grunnlaget for data, ansvarlighet ved bruk av data gjennom hele prosessen og gjennom hele rammen.

Eric Kavanagh: Ja, nei, det er fullstendig fornuftig. Og jeg antar at jeg bare kaster et siste spørsmål til deg når vi slutter her, Ron. Hvis jeg tenker på hvor mye mer informasjon og hvor mye mer data vi bruker i disse dager og hvor vidt spredte organisasjoner er, hva er viktigheten av økosystemer i disse dager mellom kanalpartnere og hvordan vi kan dele informasjon på tvers av disse partnerskapene og i et lite rask referanse av blockchain til dette - for ikke å få ting for kompliserte. Hovedpoenget er at vi er i stadig mer datadrevet sammenkoblet verden, både fra et forretningsmessig perspektiv og bare fra vårt daglige liv. Og for meg er det bare å øke innsatsen for at organisasjoner virkelig tar en hard titt på hva du foreslår her, som er deres modenhet, hvor de står og hvor langt de er i forhold til kurven og å være ærlig med seg selv om det, ikke sant? For hvis du ikke vet bedre, kan du ikke gjøre det bedre, og hvis du ikke reflekterer over ting, vil du ikke vite bedre, ikke sant?

Ron Huizenga: Nøyaktig. Og jeg antar at en setning som jeg vil bruke er at du sannsynligvis ikke er så god som du tror du er. Det kan høres litt tøft ut, men folk kan være ganske optimistiske når det gjelder dette, men hvis du ser veldig hardt på det og en virkelig god, kritisk egenvurdering, tror jeg enhver organisasjon vil finne, vet du, betydelige hull som de trenger å adressere.

Eric Kavanagh: Jeg må være enig. Og en av kollegene våre der ute kommenterte viktigheten av metadata, dataene om data. Det er det ingen tvil om. Metadata er limet som holder alle disse systemene sammen, og vi har fremdeles aldri engang helt knekt den koden og med god grunn, ærlig talt, fordi metadata endres. Det er forskjellig fra system til system. Du vet, jo mer du prøver å normalisere dataene dine, jo mindre nøyaktig tror jeg det blir.

Så vi er liksom i denne rare verdenen akkurat nå, og kanskje antar jeg at jeg vil utvide deg til et spørsmål til Jen, fordi du nevnte datakataloger et par ganger. Jeg elsker denne nye bevegelsen av datakatalogteknologi som automatisk skanner informasjonssystemene dine, konstaterer metadatasøylenavn, så videre og så videre, og hjelper deg trinnvis å bygge opp det strategiske synet på dataene dine og metadataene i systemene dine. For å manuelt gjøre det, er det bare for mye. Og du kommer aldri til å komme til toppen av den høyden før skredet kommer ned på deg, og du vet, du har enten normalisert til det punktet å spille deiggrått, eller du har ikke normalisert nok til hvor du virkelig ikke vet ikke hva som skjer. For meg bruker maskiner, læring av maskiner som vi fortsetter å snakke om, det vil være nøkkelen i fremtiden for å hjelpe oss i det minste å få et tau rundt nok av dataene til å ha en god forståelse av hva som er der ute, høyre Jen ?

Jen Underwood: Ja, det gjør jeg. Jeg elsker disse teknologiene. De er veldig, veldig kule. Og så tenker du på det, det gir deg den enorme løpsstarten. Og så kan du skaffe deg masse. Du har dine datatilitsatte, du vet, trekker fremover, enten de legger til sin egen dokumentasjon eller dette er perspektivet der ute, dette er endringene. Du vet, og sier at dette er de sertifiserte datakildene som skal brukes til rapportering. Folk kan søke og finne riktige data. Det er egentlig, egentlig ganske fint. Og hjelper også til - når jeg tenker på forretninger og hvor kryptisk bedriftsdatahåndtering var da jeg var da jeg holdt på med DBA-ting - vi brukte utvidede egenskaper og SQL Server og skanne med verktøy som IDERA-er, ikke sant? For å prøve å lage en datakatalog. Men i DBA eller dataarkitektenes versjon av, vet du, uansett hvilken verdi det var eller den kolonnen eller feltet var, stemte det sikkert ikke med hva virksomheten var. Så nå å ha virksomheten i stand til å virkelig enkelt, du vet, gå inn og finne og administrere og få alt til å være målbasert, det er virkelig, jeg skulle ønske vi hadde hatt dette for lenge siden, helt ærlig. Så det blir mye bedre.

Eric Kavanagh: Det er morsomt. Vi har fått en ny kommentar fra et publikummedlem, og sier at blockchain kanskje vil være det mest verdifulle å sette et stempel av autentisering til metadata. Det er et godt poeng, og du vet, blockchain er virkelig fantastisk teknologi. Jeg ser på det som et slags sammenhengende fundament for å koble mange punkter mellom systemer og applikasjoner og så videre. Og du vet, vi er i de tidlige stadiene av blockchain-utvikling, men vi ser nå at det er spunnet av, selvfølgelig, fra dette punktet opprinnelig der det kom frem, og nå har du fått IBM til å jobbe veldig hardt på blockchain-teknologier. SAP har kjøpt inn alt dette. Og egentlig er det, det gir en mulighet for et dypere fundament og rammeverk for å koble sammen alle disse systemene og alle disse prikkene.

Så folkens har brent godt over en time. Takk for at du har vært sammen med oss ​​i dag, men vi liker alltid å svare på spørsmålene dine og komme til alle kommentarer. Vi arkiverer alle disse webcastene for senere visning, så hopp online til insideanalysis.com, hvor du kan finne lenken til det. Den skal være oppe i løpet av få timer, typisk etter hendelsen. Og vi henter deg neste gang. Vi har et par flere arrangementer som kommer opp i løpet av neste uke - mange ting skjer. Men det vil ta farvel, folkens. Takk for tiden din. Ha det fint. Buh-bye.