Av Techopedia Staff, 29. april 2016
Takeaway: Vert Eric Kavanagh diskuterer IT-kapitalforvaltning med ekspertene Dez Blanchfield, Dr. Robin Bloor, Tom Bosch og Chris Russick.
Du er ikke logget inn for øyeblikket. Logg inn eller registrer deg for å se videoen.
Eric Kavanagh: Mine damer og herrer, hei og velkommen igjen til Hot Technologies! Ja absolutt! Jeg heter Eric Kavanagh. Jeg vil være din moderator for dagens begivenhet, og folkens, vi har noen spennende ting kartlagt for deg i dag, jeg kan fortelle deg akkurat nå. Dette er et av de mer fascinerende områdene innen IT-ledelse generelt. Temaet er "Keep It Simple: Best Practices for IT Portfolio Management." Vi kommer til å fokusere i stor grad på datasiden av den ligningen i dag. Med andre ord: Forsikre deg om at dataene dine er rene eller så rene som mulig når du prøver å forstå landskapet til enheter over hele bedriften.
Selvfølgelig, med denne helt nye verdenen av BYOD, ta med din egen enhet - der er din virkelig veldig raskt - vi har veldig heterogene landskap i disse dager. Jeg mener at dere i store organisasjoner kjenner historiene. Det er hele rom fylt med servere. Det er applikasjoner som har kjørt i mange år. Det er gamle IT-systemer som ingen har rørt på ti år, og alle er redde for å slå seg av fordi du aldri vet hva som kommer til å skje.
Så vi skal snakke i dag med et par eksperter, faktisk fire eksperter totalt, om hva vi skal gjøre på dette rommet.
Hot Technologies, hele hensikten med dette showet er virkelig å grave dypt ned i spesifikke typer teknologi og hjelpe publikum til å forstå hvordan ting fungerer, hvorfor vi bruker denne typen teknologier, hva noen av de beste praksisene er, og hva du bør vurdere. Vi vil fortelle noen brukssaker av og til. Faktisk skal Dez snakke om en liten historie fra hans erfaring i verden av IT-kapitalforvaltning. Men igjen, vi vil liksom fokusere på datasiden fordi det virkelig er ekspertisen til vennene våre fra BDNA. De er mestere i å hjelpe organisasjoner med å få tak i hva de har i miljøet sitt og hvordan de kan forstå hvor det er, hva det gjør, hvem som bruker det, alt det slags morsomme ting.
Her er våre paneldeltakere. Vi får høre fra Dez Blanchfield, vår nyoppfunnet dataforsker. Jeg liker å skryte av at Dez bokstavelig talt var en av de ti mest besøkte LinkedIn-profilene i Australia i fjor. Det er fordi han aldri sover. Vi har også Dr. Robin Bloor, vår helt egen sjefanalytiker. Dr. Bloor, for de av dere som ikke kjenner, startet virkelig slags IT-uavhengige analytikerindustri i Storbritannia for omtrent 25 år siden. I disse dager er det ganske mange. Det er nesten som jeg sier en hytteindustri. Det er mange uavhengige IT-analytikerfirmaer. Vi har også Gartner, Foster, IDC og de store gutta. Men det fine med de uavhengige firmaene er at vi ærlig talt er litt mer fri til å snakke ærlig om ting. Så still ham de harde spørsmålene. Ikke la disse gutta lett. Du kan alltid stille et spørsmål under showet ved å bruke spørsmål og svar-komponenten på webcast-konsollen. Det er i nedre høyre hjørne, eller du kan chatte meg. Uansett prøver jeg å overvåke at nettpratvinduet hele vises.
La oss presentere det med Dez Blanchfield. Dez, jeg skal gi deg nøklene til Webex. Der går du. Ta den bort.
Dez Blanchfield: Takk, Eric. Flott. Gutt, fantastisk intro.
Temaet i dag er noe jeg har levd med for den bedre delen av meg, som tretti år, stort IT-miljø. De vokser gjennom en organisk prosess. Som Eric sa, du starter opp i det små og bygger disse miljøene og de vokser, og de vokser organisk i noen tilfeller. De kan vokse gjennom andre midler som for eksempel anskaffelse av store utvidelser.
Jeg skal dele en anekdote som berører alle de viktigste tingene vi snakker om i dag, og spesielt data og hvor dataene kommer fra å gjøre og innsamling av data for å gjøre IT-kapitalforvaltning. I dette tilfellet skal jeg snakke om et stort stykke arbeid for en av de tre beste utgiverne i verden. De er i radio, TV, magasin, avis, trykk, digital og en rekke andre publiseringsrom. Vi fikk et tre-måneders vindu for å kjøre det som egentlig ble kalt en beredskapsvurdering, men som endte med å være en hel forretningsomfattende skystrategi som vi satte sammen. Vi fikk denne grunnleggende utfordringen fra CIO om å redusere datasenterets fotavtrykk med 70 prosent i løpet av tre år. Det var ganske nærliggende å gjøre dette, vi måtte gjøre en hel virksomhetssky-overgang. Vi hadde tre måneder på å gjøre dette arbeidet. Det dekker fire forskjellige regioner i fem land. Det var seks separate forretningsenheter som var inkludert og syv forskjellige etablerte leverandører av statustjenester. Som tittelen sier, er ingenting som slår det virkelige eksemplet.
Vi kom til den konklusjon at de forretningsmessige målene ærlig talt ikke var annet enn et mirakel. De ønsket å befeste sine egne datasentre. De ønsket å utnytte tredjeparts datasentermiljøer som var nødvendige, men generelt ønsket de å flytte til en annens skyinfrastruktur, spesielt offentlig sky eller virtuell privat sky av nødvendige sikkerhetsgrunner. Spesielt var Amazon Web Services og Azure fokusert på fordi de var den mest forsikrede den gangen. De kjørte en blanding av Intel x86, 32/64-biters plattform, IBM I-serien, AS-serien, AS / 400P-seriens hovedramme. De hadde faktisk to hovedrammer, en for produksjon og en for utvikling av katastrofegjenoppretting. Deretter hele blandingen av operativsystemer - Windows, Linux, AIX, Solaris og forskjellige ting på bærbare datamaskiner og stasjonære maskiner.
Lagring var en av de største utfordringene. De hadde enorme datamengder fordi de er en utgiver - alt fra fotografier til videoer til redigering av bilder til tekst og innhold. Gjennom disse store plattformene og forskjellige lagringsformater var NetApp, Hitachi, IBM og EMC. Så ekstremt mangfoldig miljø for å prøve å fange opp og kartlegge de forskjellige typer tjenester som var der, og bare få et syn på hva vi tok fra nåværende og private datasentermiljøer til et skymiljø.
Høyden på det vi snakker om i dag rundt IT-forvaltningsstykket er drevet av data i det vesentlige, og her er et kart over hva vi måtte håndtere med dette prosjektet, som jeg deler anekdoten om. Vi hadde mye datainnganger. Dessverre var ingen egentlig i veldig god form. Vi har en rekke ufullstendige eiendeleregistre. Det kjøres fem forskjellige aktiviseregistre, så konfigurasjonsadministrasjonsdatabaser, ITF-inndataformer. Vi har forskjellige datakilder som spenner opp til nitti forskjellige forskjellige typer. Vi hadde flere kjernetjenestemodeller, motstridende tjenestegrupper, et av de største interessentene jeg noen gang har jobbet med i min karriere. Det var fire hundre senior execs som hadde ansvaret for disse forskjellige systemene. Under alle omstendigheter hadde vi helt feiljusterte forretningsenheter - hver av dem opererte uavhengig med sine egne miljøer og sin egen infrastruktur i noen tilfeller. Det var en ganske utfordring.
Vi oppdaget dette i løpet av den andre eller tredje dagen vi nettopp var
De "kaste kroppene på det" fungerte ikke. Så vi bestemte oss for å bygge et system, og vi kunne ikke finne det i dette stadiet, da dette var for flere år siden - og vi kunne ikke finne verktøyene som passet til vårt formål, og vi så lange og harde ut. Vi endte med å bygge en SharePoint-plattform med en rekke databaser som mate den med en serie arbeidsmengder i forskjellige stadier. Vi gikk tilbake til det grunnleggende bare for å få tilgang til data som var fornuftige slik at vi kunne validere, så vi brukte en rekke verktøy for å kartlegge økosystemene vi kjører. Vi kjørte automatiserte tilsyn med datasenteret i fysisk og logisk infrastruktur. Vi gjorde automatiserte oppdagelsesverktøy, og kartla tjenestene som kjører innenfor disse datasentermiljøene. Vi gjorde full søking av applikasjoner - og lette etter alt fra ett program som kjører i konfigurasjonen deres mens portsystemene er på, mens IP-adressene er på.
Det vi gjorde var at vi bygde en ny enkel kilde til sannhet fordi hver av de andre databasene og informasjonssamlingene de hadde rundt omgivelsene og konfigurasjonene og eiendelene deres ikke bare stemte og vi ikke kunne kartlegge virkeligheten tilbake til den. Så vi endte opp med å bygge en eneste kilde til sannhet. Vi gikk fra å kaste kropper på den til å kaste automatiserte verktøy på den. Vi begynte å se litt lys i enden av denne tunnelen. Så vi endte opp med et veldig sofistikert system. Det gjorde noen enormt smarte ting fra å fange opp automatisert logganalyse til data som blir kastet mot oss fra forskjellige systemer, overvåking av sikkerhetskontroller, bruk og logging av passordkontroller, fysisk infrastrukturrevisjon, revisjon av applikasjoner. Vi bygde en rekke ting inne for å analysere disse dataene med automatiserte poengsumskort. Deretter produserte vi rapporter rundt egnethet og prosentvis rangering, enten applikasjoner var eller ikke passet godt for skyen.
Vi kjørte deretter en baseline av det poengkortet over Amazon Web Services, med Azure- og VMware-modeller. Vi produserte en serie rapporter og økonomiske dashbord på dette, og nesten aldri tillot vi noen manuell overstyring. Så det vi fikk poenget var egentlig et automatisert system som var vedlikeholdende, og vi trengte virkelig ikke å berøre denne tingen, eller veldig sjelden har vi noen gang må overstyre dem manuelt. Denne tingen vokste mye på egenhånd, og vi hadde endelig den ene kilden til sannhet og ekte data som vi kunne bore ut til tjenestegruppene, til servicesystemene vi kjører i applikasjonene eller dataene som bruker dem og tjenester som blir levert.
Det var ganske spennende fordi vi nå hadde muligheten til å levere løftet fra denne prosjektstrengen. Omfanget av dette prosjektet - bare for å sette litt sammenheng rundt det - er at vi endte opp, jeg tror det var rundt $ 110 millioner år for år som ble skåret ut av bunnlinjen, driften (uhørbar), når vi fullførte dette overgang til å flytte majoriteten av infrastrukturen fra egne datasentre til skyen. Så de er et veldig storskala program.
Vi fikk dette flotte resultatet for prosjektet. Men det virkelige problemet vi løp inn var at vi opprettet et hjemmebakt system og det var ingen leverandør bak det på dette stadiet. Som sagt, dette var for flere år siden. Det er ingen leverandør bak det som kan fortsette å utvikle det og gi vedlikeholdsstøtte for det. Det lille teamet på rundt 30 personer som hjalp til med å utvikle det og samle alle dataene og hastigheten til dette monsteret, ble etter hvert videre til andre prosjekter, og to eller tre personer satt igjen med det. Men vi endte opp med en situasjon der vi ikke hadde en materialstyrt IT-forvaltningsløsning. Vi hadde et engangsprosjekt og virksomheten gjorde det veldig tydelig at de allerede trodde de hadde konfigurasjonsadministrasjonsdatabaser og ITSM-verktøy som kartla verden til tross for at vi hadde stått på toppen av en veldig stor såpekasse og skrek på toppen av vår stemmer om at dataene som ikke gir mening.
Vi demonstrerte ved å få dem til å bygge verktøyene rundt prosjektet. Det uheldige resultatet av denne spennende, men triste slutningen, var at utfallet for prosjektet var veldig, veldig vellykket. Det var en rungende suksess. Vi trakk hundre og en halv million dollar av bunnlinjen året over år. Det vi har gjort er at vi opprettet denne Frankenstein, dette virkelig kraftige systemet som kan samle inn data og gi rapportering om det i sanntid i noen tilfeller, men det var ingen der for å vedlikeholde dem. Forretningstypen bare la den gå en stund til slutt dataene ikke ble brukt av noen, og endringer kom til det og det var ikke i stand til å samle inn data som var i samsvar med endringene. Etter hvert den gangen, ble dette hjemmebakte systemet overlatt til å dø sammen med dataene som fulgte med det.
Vi hadde dette scenariet hvor de gikk tilbake til nøyaktig hva de hadde i utgangspunktet, som skiller tilhengere og de forskjellige datasettene som ser veldig, veldig tett i en nisjeform inn i et bestemt område av tjenester eller tjenestegrupper og løser problemene deres, men de mistet den organisasjonen bredt. De har 74 forskjellige tjenester i gruppen. De mistet all den verdien, og merkelig nok, noen to eller tre år senere, innså de hva de har mistet, og måtte se på hvordan de løste problemet igjen.
Moralen i historien er at hvis det var tilfelle, hvis det var et produkt som vi kunne ha kommet ut av sokkelen for flere år siden, måtte vi bygge en, men det er ikke bare tilfelle lenger. Det er produkter der ute, som vi skal se, som kan gjøre dette, og de kan gjøre det på en automatisert måte. De kan rydde opp i alle dataene, de kan ta flere datasett og slå dem sammen og dupe dem. De kan ta virkelig åpenbare ting til mennesker og regneark med ting som de vil si, marsjert versjon en prikk en, versjon en prikk null punkt en, og bare kalle dem Microsoft. Da vi bygde dette verktøyet, var den slags ikke tilgjengelig; derfor måtte vi gjøre mye av den muligheten. Jeg ser etter de samme detaljene om hva denne plattformen vi skal høre om i dag gjør fordi jeg bare skulle ønske at vi hadde den den gang. Vi kunne ha spart oss for mye sorg, og vi kunne spart mye tid og krefter og utvikling for en plattform som kan opprettholdes av noen som fortsetter å utvikle og vokse plattformen som gjør den tilgjengelig som en generelt forbruk.
Med det skal jeg levere tilbake til deg, Eric.
Eric Kavanagh: OK. Jeg overlater det til Dr. Robin Bloor. Robin, ta den bort.
Robin Bloor: Det er faktisk en interessant historie, Dez. Jeg liker det. Det slår meg ikke så spesielt uvanlig. Hver gang jeg fikk problemer med IT-kapitalforvaltningen, har det alltid vært et selskap som faktisk dro hjem og gjorde noe med det og måtte, men det ser ikke ut til at du kjørte inn i en organisasjon som har hele saken under kontroll. Likevel, så brenner jeg penger, hvis jeg ikke kan vite, hvis du ikke forvalter IT-eiendelene dine. Siden Dez kom ut med den pisete, gryne historien, tenkte jeg at jeg bare ville gjøre oversikten over, vel egentlig, hva som er IT-kapitalforvaltning. Hva betyr det egentlig? Dette er fugleperspektivet eller ørnesynet.
Vurder en fabrikk - spesielt organisasjoner som driver fabrikker med den hensikt å tjene penger. Alt mulig gjøres for å utnytte de dyre eiendelene som brukes. Det er bare tilfelle. Tenk på et datasenter, ikke så mye, faktisk stort sett ikke i det hele tatt. Så tenker du, vel, hvor mye investeres de i datasenteret? Vel du vet, hvis du faktisk ordner det, er det virkelig store mengder penger. Du satt sammen, jeg vet, den historiske innsatsen til alle som bygde systemet. Lisensene deres blir betalt for programvaren og verdien av dataene og kostnadene for selve datasenteret og selvfølgelig all maskinvaren, det viser seg bare å være titalls millioner. Det kommer an på hvor stor organisasjonen er, men lett titalls millioner i de fleste organisasjoner. Dette er en enorm investering folk gjør i IT og absolutt i store organisasjoner, det er massivt. Ideen om at du egentlig ikke burde bry deg særlig om å få maksimal verdi ut av den og den skal kjøres effektivt, er åpenbart en absurditet, men som bransje er det veldig få steder som faktisk har disiplin til å virkelig virkelig styre IT eiendeler.
Dette er en modell jeg har brukt, jeg vet ikke, ganske mange ganger, antar jeg. Det er det jeg kaller diagrammet for alt. Hvis du ser på et IT-miljø, har det brukere, det har data, det har programvare, det har maskinvare. Det er et forhold mellom alle disse grunnleggende enhetene som utgjør et IT-miljø. Den bruker spesifikke programvare eller relasjoner som har tilgang til spesifikke dataforhold. De bruker spesifikke maskinvareressurser, så det er et forhold der. Programvare og data er nært relatert. Programvaren er bosatt og utføres på spesifikk maskinvare, og der er den dataspesifikke maskinvaren. Så det er alle disse forholdene. Hvis du vil vite hvor IT-eiendelene er, bare legg hånden over brukerne fordi det er veldig lite som du kan kalle en IT-eiendel bortsett fra ervervede ferdigheter og dets brukere, og det er alt annet.
Så ser du på det, og du ser vel, hvor mange organisasjoner har til og med en oversikt over all programvaren som er utgitt i alle systemene de bruker? Hvordan har vi til og med et skikkelig lager av maskinvare som inkluderer alle nettverksfunksjonene? Hvor mange har noen meningsfylt oversikt over dataene? Svaret er ingen. Å vite hvor tingene er og å vite hvordan man forholder seg til en annen kan være veldig, veldig viktig i noen tilfeller, spesielt i den typen forekomst som Dez nettopp beskrev hvor du skal hente det og flytte det hele eller plukke det opp og flytte det meste. Det er ikke bare en bagatellmessig ting, og bare å vite hva som er det, er en stor sak. Å vite hvordan en ting forholder seg til en annen.
Så er den andre tingen at dette diagrammet gjelder på det minste granularitetsnivået, du kan forestille deg, det minste stykke programvare. Få tilgang til den minste datamengden du kan forestille deg å kjøre på en triviell del av maskinvareressursen helt opp til et ERP-system med enorme, enorme mengder distinkte databaser og datafiler, som kjører på flere maskinvarestykker. Dette diagrammet generaliserer alt, og det gjelder hvert nivå av granularitet, og denne pilen av tid går under bare indikerer at alt dette er dynamisk. Dette kan se ut som om det fremdeles er et diagram, men det er det ikke. Det er rørende. Alt er i endring. Å holde oversikt over det er ingen bagatellmessig ting. Jeg mener det bare ikke er det. Du kan faktisk utvide dette diagrammet, og du kan si, glem datamaskiner og bare gjøre det enda bredere. Virksomheter består av all data pluss forretningsinformasjon som kanskje ikke lagres elektronisk. Ulike fasiliteter, og det er ikke nødvendigvis datamaskinrelatert. Ulike forretningsprosesser som ikke nødvendigvis er programvareavhengige eller delvis kanskje uavhengige som programvare.
Mange mennesker - ikke bare brukere av systemer, men ansatte, paneldeltakere, kunder og så videre - som utgjør økosystemet til en virksomhet, og da har du faktisk også menneskeheten, mennesker. Det er all informasjon i verden. Det er sivilisasjonen. Alt dette er det vi kaller harde ting og alle menneskelige aktiviteter. Dette er diagrammet over alt og alt. Dette diagrammet gir deg en indikasjon på hvor sammenhengende fra den minste samlingen av ting som gjør noe til det største, for når det gjelder menneskeheten, er det akkurat som hele Internett og milliarder datamaskiner som utgjør det og alle enhetene og så videre. Det er et stort utvalg av ting, og alt dette er åpenbart subjektivt for tidens pil. Det er fugleperspektivet.
Jeg listet dette rett ut fra hodet uten å tenke på det. Dimensjoner på IT-kapitalforvaltning. Det er et eiendeleregister, maskinvare, programvare, data og nettverk. Det er ressursattributtet fanget - har du alle dataene relatert til alle disse tingene? Kapitalbruk - hvorfor eksisterer det i det hele tatt? Anskaffelseskost og eierkostnader - hvor mye skal koste og derfor hvor mye er eierskapet og hvor mye å erstatte fra en god idé? Det bringer ideen om avskrivninger på eiendeler. Jeg snakker ikke bare om maskinvaren. Vi snakker også om ting og muligens også dataene. Et komplett aktivakart som ville være å formidle diagrammet jeg nettopp diskuterte. Cloud-eiendeler - ting som faktisk ikke er på parametere, men som faktisk gjør på en eller annen måte tilhører organisasjonen i kraft av utleie og i kraft av fornuft. Tjenestestyringsmål og hvordan de forholder seg til alle disse spesielle mulighetene. En av tingene som Dez snakket om er innsatsen hans, en samling av systemer fra et sted til et annet sted som er, hvordan fungerte serviceledelsen i form av "traff du målet folk forventer i sine systemer ?" og så videre. Det er risiko og overholdelse - ting som på en eller annen måte aksjonærene som kan være bekymret for og regjeringen selv kan være bekymret for, og alt dette er et aspekt av kapitalforvaltningen. Det er anskaffelse og lisensiering av all programvare. Det er forretningsmessige resultatmål. Det er en hel del av kapitalforvaltningen når det gjelder hvilke regler organisasjonen kan sette for noen av disse tingene. Vi snakker om veldig komplekse ting.
Så spørsmålet oppstår, og dette er hvordan jeg avslutter - hvor mye av dette kan gjøres? Hvor mye av det som egentlig bør gjøres?
Eric Kavanagh: La oss finne ut hva ekspertene har å si med det. Jeg skal overføre den til Tom Bosch. Stå ved og gi deg nøklene til Webex. Ta den bort.
Tom Bosch: Tittelen på Webex, fra vårt perspektiv, handlet om å holde det enkelt og åpenbart beste praksis for IT-portefølje eller IT-kapitalforvaltning. Når du sier beste praksis, er det til syvende og sist en mening. Det er en tilnærming fra vårt perspektiv. Til syvende og sist hva BDNA ønsker å gjøre er å hjelpe mange av selskapene der ute som vi finner fremdeles bare å få føttene våte tilbake på IT-reiseveien. IT-kapitalforvaltning var et varmt tema rundt Y2K for noen av dere som har vært i bransjen en stund, og den viktigste grunnen til at jeg er nødt til å forstå om programvaren jeg har og systemene jeg har, til og med går for å bli erstattet eller oppdatert, eller vil de mislykkes når vi treffer det nye årtusenet?
Jeg tror at det vi alle levde gjennom den rare kvelden for noen seksten år siden, var det faktum at veldig lite gikk ned i bakgrunnen. Kraftverkene våre holdt seg i live og togene fortsatte å kjøre. Lysene i New York City og Sydney ble stående på. Gjennom denne prosessen begynte folk å forstå at det var en enorm mengde informasjon som måtte samles og samles. Til syvende og sist var det dataene bak alt dette som måtte renses, som Dez sa tidligere, for å kunne ta de slags beslutninger som folk lette etter. Så det er kjernen i samtalen vår i dag. Jeg tror hver og en av oss innser at hver dag vi går inn i IT-avdelingen vår, hver dag som vi går inn i organisasjonene våre. Enterprise, informasjonsteknologi er nesten nesten utenfor kontroll. Det jeg mener med det, er at det er nye servere som blir brakt på nettet. Det er nye programvarestykker som blir distribuert fra avdeling til avdeling til avdeling på tvers av organisasjoner, enten du er i produksjonsbransjen, du er i en tjenesteorganisasjon, du er i detaljhandel, hver eneste en av våre organisasjoner i dag er ikke bare å bli kjørt, men de blir drevet.
IT blir produksjonsmotor for mange av organisasjonene som vi jobber i. Det blir ikke tydeligere ved å se på løsningene som blir satt i bruk. Hvis vi bare fokuserer internt på datakompleksiteten rett innenfor IT-avdelingen - bare applikasjonene de blir brukt for til slutt å støtte IT - har vi alt fra leverandørstyringssystemer til IT-porteføljestyring, anskaffelsessystemer, arkitektursikkerhetssystemer, og en av de viktigste egenskapene som utvikler seg, er at de kan føre til å benytte seg av en oversikt over hva du har i miljøet for å effektivt kunne drive løsninger i deres spesifikke fagområder. Så å ha disse eiendelene for hånden er avgjørende for nesten alle fagområder innen IT-organisasjonen. Men en av tingene som raskt blir funnet når selskaper begynner å prøve å bringe disse forskjellige systemene sammen, er at de ikke snakker det samme språket, og til slutt koker det ned til dataene.
Som Dez påpekte tidligere, var dårlige data roten til prosjektet de startet med, og noen veldig interessante statistikker i selskapet Gartner, om at bokstavelig talt IT sløser med over 25 prosent av pengene de investerer på årlig basis på grunn av dårlig data. Det koster Tenex-prosjekter fordi det til syvende og sist for de fleste selskaper handler om å rydde opp i disse dataene manuelt. Igjen, som Dez sa, det er virkelig plagsomt. Spesielt rundt kapitalforvaltning selv og generelt på tvers av IT-prosjekter, konkluderte Gartner i utgangspunktet at over 40 prosent av alle IT-prosjekter mislykkes på grunn av dårlige data. Vi kjenner roten til problemet. Det er dataene. Hvordan begynner vi å håndtere det? Noe av det som skjer er at ITAM blir viktig da for organisasjoner av mer enn bare en grunn - åpenbart det vi nettopp har snakket om, og det er at vi trenger å få systemer til å snakke med hverandre. Vi må forstå hvor systemene finnes i organisasjonen vår, slik at vi kan utføre enkle operasjoner som oppdatering eller oppgradering til bare systemene vi har på plass.
For å forbedre problemet ytterligere i dagens miljø, er det mange av programvareforlagene og produsentene som finner ut at det, det vi kaller hva det er, er lite hengende frukt for disse utgivere ved å komme inn og ganske enkelt tvinge klienter til en revisjon eller gjøre opp. Bokstavelig talt gikk 63 prosent av Fortune 2000 gjennom minst en revisjon i 2015 ifølge uavhengig forskningsselskap. Disse revisjonene koster selskaper med enorme interne gebyrer og ekstern oppregningskostnad alt fra hundre tusen til en million dollar, og Gartner kom i hovedsak ut med en annen interessant statistikk som ikke er i presentasjonen min, men jeg plukket den opp tidlig formiddag at de vurderer gjennomsnittlig kostnad for en revisjon til et sted rundt en halv million dollar for en organisasjon.
Når vi snakker om at 25 prosent av dollar som blir brukt på IT blir kastet bort, er dette noen av eksemplene som skjer. Jeg tror at fakta i alle disse, så hva gjør vi? Hvordan takler vi dette? Det starter med å virkelig forstå hva denne reisen er for de fleste organisasjoner. IT-kapitalforvaltning er en serie trinn som i utgangspunktet starter med å oppdage hva jeg har fått ut i nettverkene mine. De fleste har ett eller noen eller mange av disse funnverktøyene, sannsynligvis er et av de vanligste funnverktøyene på markedet SCCM. De fleste selskaper som har et hvilket som helst nivå av Microsoft- og Windows-sentriske miljøer, bruker SCCM til mange formål, distribuerer applikasjoner, og kan også brukes til å kutte data, men at dataene kommer tilbake i et gjørmete rotete format. Vi snakker om det mer på bare et minutt. Det er mange andre verktøy også. De fleste av ITSM-løsningene enten det er BMC eller Service Now eller Nationale eller HP har veldig gode oppdagelsesverktøy, og de kommer ofte i spill når du spesielt prøver å samle informasjonen og gjensidig avhengighet mellom servernettverk og nettverksenheter, fordi det siste vi trenger er en situasjon der reservasjonssystemet for et stort flyselskap går ned midt på dagen og millioner om ikke milliarder av dollar inntekter går tapt. Å forstå hvordan alle disse tingene er koblet sammen starter igjen ved å forstå eiendelene som er knyttet til det.
Det andre trinnet eller det andre trinnet i denne prosessen - jeg fikk alle disse dataene, men hva betyr det og hvordan kan jeg begynne å jobbe med det? Dette trinnet er vanligvis referert til som normalisering, og det er det vi vil fokusere på mye i dag, fordi det i kjernen er det enkleste og viktigste trinnet i å gå mot en fullt optimalisert eller fullt moden ITAM-reise. Når du går gjennom normaliseringsprosessen, er det du prøver å gjøre, til sammen å samle alle de forskjellige oppdagelseskildene du har, og noen av disse kan ganske enkelt være applikasjonene og løsningene som vi snakket om i en av de tidligere lysbildene. Vi ønsker å bli duplisert. Vi ønsker å redusere all buzz og filtrere ut alle dataene som ikke er relevante. Vi snakker om det mer når vi går sammen.
Derfra er noen av de logiske trinnene på toppen av den lite hengende frukten. Når selskaper kommer sammen og fusjonerer og går ut og skaffer seg andre organisasjoner, begynner de å utvikle duplisering i applikasjonene de bruker. Et veldig typisk skritt som folk tar når de forstår og landskapet til programvare og maskinvare som de har, er å rasjonalisere eller fjerne dupliseringen, overflødige enheter og overflødig programvare i miljøet. For eksempel kan du oppleve at hvis du går ut og ser, kan du ha så mange som tjuefem forskjellige tjuefem forskjellige BI-verktøy i bruk i miljøet ditt. De potensielle besparelsene der for et selskap å fjerne ikke bare de som er assosiert med spesifikke applikasjoner, men enda viktigere de som har bredere rekkevidde, tilbyr enorme kostnadsbesparelser og potensiell risikoreduksjon.
Hva gjør organisasjoner? De tar vanligvis en titt på disse i en stor detalj, og som Dez sa, du fikk mange kropper kastet på det og de begynte å finne ut hva de trenger å gjøre og hvordan fikk de denne optimaliserte tilstanden, og jeg så på at dette skjedde og igjen. Jeg har jobbet med hundrevis av selskaper over den bedre delen av det siste tiåret med programvareforvaltningen deres, og til slutt det som stopper de fleste av disse prosjektene, eller det som får de fleste av disse prosjektene til å mislykkes, er at de prøver å bite mer enn de kan tygge, og de tar det ikke tilbake til kjernen uten å lage prosjekter som krever enorme endringsledelser, styringsfullmakter, utdanningsprogrammer og styring som påvirker et enormt rom i miljøet.
Når du setter deg ned med programmet eller et prosjekt som de viser foran en toppleder, stilles ofte spørsmålet: "Er problemet virkelig så stort?" Etter hvert som jeg har diskutert dette mer detaljert med mange toppledere, sier de: “Du vet, Tom, det koker virkelig ned til tre ting for meg. Jeg vil vite hva vi har. Jeg vil vite at vi bruker det vi kjøper. Det viktigste er at jeg vil vite at det vi bruker og det vi bruker samsvarer med det jeg kjøpte. "Med andre ord:" Har jeg rett til det jeg bruker, eller har jeg satt meg inn i en piratkopiering riktignok ikke-tilsiktet piratkopiering? ”
Disse tre spørsmålene kan faktisk besvares veldig enkelt ved å gå tilbake og bare rydde opp i dataene. Det er det vi skal vise deg resten av veien. La oss se nærmere på dataene og hva noen av problemene er som kommer ut av disse oppdagede dataene. Det er uten betydning. Det er unøyaktig. Det er inkonsekvent. Det er ufullstendig, og til slutt koster det selskaper godt utover 14 millioner dollar årlig i dårlig beslutningstaking.
Her er et eksempel på typen data du kommer direkte ut av et funnverktøy som SCCM, det innebærer en enorm mengde bokstavelig talt irrelevante data. Faktisk er 95 prosent av dataene uten betydning. Den inkluderer ting som kjørbare filer, oppdateringer og hurtigreparasjoner og firmware til enheter og forskjellige språkpakker og kunnskapsbase-pakker. Et godt eksempel er å ta en titt i inventaret på en typisk PC i miljøet, se etter noe fra Adobe. Ofte kan Adobe Acrobat ha en lisensierbar kopi på PC-en, men det kan likevel være så mange som ni eller ti av disse kopiene eller oppgradere kopiene. Så med det blotte øye er du ikke sikker på om du har ansvar for ni forskjellige eksemplarer eller bare ett produkt.
Et av de andre områdene i, så å si, er inkonsekvensen som finner sted. Dette er bare et kort eksempel på hvordan Microsoft kan navngis så mange forskjellige ting i en organisasjon. Dette er et fokusert område for BDNA. Jeg tror at et av de mest fortellende eksemplene som vi kan gi er at rett rundt temaet SQL har vi funnet på tvers av kundebasen vår 16.000 forskjellige varianter av hvordan SQL kan navngis i en varebeholdning. Vurder å legge det opp på en jevn basis. Et annet område er grunnleggende mangel på standarder. Til hvilket nivå database utgivelser, til hvilket nivå av CAL, PV bruk, av IBM skal vi administrere disse dataene? Så dette er en del av conundrum og problemet med å hjelpe normalisere alle disse råvarene, alle disse rå data til et punkt der det er brukbart. Sammen med det er det en enorm mengde data som ikke kan oppdages, som også vil være veldig verdifulle for noen i et tradisjonelt ITAM-miljø. Vi vil gi deg noen eksempler på det når vi går sammen når vi dekker noen brukssaker.
Det ene elementet som absolutt er uten tvil, er det faktum at disse dataene endres daglig. Hvis vi bare ser på Microsoft alene, introduserte Microsoft i 2015 over 3500 nye programvaretitler og oppgraderte eller oppdaterte noen 9.800 forskjellige programvare. Det er 14.000 endringer hos Microsoft alene. BDNA klarer dette på daglig basis. Vi har et team av ingeniører som følger med dette og bokstavelig talt lager noen ord på opptil en million endringer i vår mesterordbok og leksikon. Vi vil dekke det her mer detaljert når vi går sammen. Til syvende og sist tar vi en titt på det miljøet som vi så på tidligere, og manglende evne til å alle disse forskjellige løsningene å snakke med hverandre er definitivt et problem, og det er der BDNA kommer på plass, og BDNA-plattformen og dens kjernekomponent Technopedia tillater oss å lage en felles dataplattform.
Hvordan det foregår er faktisk ganske enkelt. Vi samler dataene som kommer fra en rekke forskjellige funnkilder. Disse oppdagelseskildene kan være noen av de jeg nevnte tidligere som SCCM eller ADDM eller HPUD. Det kan være denne tingen CMDB. Det kan faktisk også være innkjøpsordresystemene du har fra anskaffelsessystemene dine. Vi bringer det sammen, og vi ser på kjernekomponentene i hvordan ting er listet opp og rasjonaliserer det og normaliserer det. Igjen, det er noe som BDNA kaller Technopedia. Technopedia er verdens største leksikon av IT-eiendeler. Det brukes av noen andre tjue andre applikasjoner over hele kloden utenom bare BDNA-bruk for å skape et felles språk igjen. Verktøy som arkitektoniske verktøy, anskaffelsesverktøy, verktøy for tjenesteadministrasjon - igjen ideen er: "La oss snakke et vanlig språk på tvers av alle våre IPV-er." Deretter legger vi til de spesifikke titlene, 1, 3 millioner oppføringer over 87 millioner attributter. Disse egenskapene kan være noe så enkelt som: "Hva er maskinvarespesifikasjonene eller spesifikasjonene rundt den enkle serveren? Hva er de fysiske dimensjonene? Hva er energibruken? Hva er energiregningen? Hva bruker VP av varme generert av alle ting som kan brukes av arkitektene våre? " Det er bare ett eksempel på mange forskjellige katalogtillegg som er tilgjengelige. Vi tar dataene dine. Vi forverrer det. Vi kartlegger det i det vesentlige, normaliserer det mot Technopedia-katalogen og leverer et normalisert sett med data som deretter kan konsumeres i resten av miljøet.
Vi fører det inn i et datavarehus internt som vi viser deg på bare noen få minutter, men vi har også standardintegrasjoner i mange CMDB, ITSM og tilleggsverktøy som brukes over hele IT-miljøet for å hjelpe disse løsningene å bli mer verdifulle for du. Et enkelt eksempel på noen av innholdspakkene, priser, maskinvarespesifikasjoner, livssyklus og support er sannsynligvis det vanligste som gir deg ting som slutt på livet, slutt på support, virtualiseringskompatibilitet, Windows-kompatibilitet, og igjen, Chris vil dekke noen av det når vi beveger oss sammen.
I en nylig tegneserie jeg plukket opp, en Dilbert-tegneserie, hadde han faktisk blitt bedt av sjefen sin om å gjøre akkurat den samme saken. Så, "Dilbert gir meg en liste over eiendelene i organisasjonen vår." Dilberts svar var: "Hvem kommer til å bruke det hvis jeg leverer det?" Bruken av IT-kapitalforvaltningsdata, som vi snakket om, fremover her, vil virkelig nå en enorm mengde bruk i hele organisasjonen. Dette er bare et lite utvalg av de forskjellige fagområdene i en IT-organisasjon, og hvordan de vil bruke dem. Realiteten er at den driver verdi i organisasjonen, og ved å ta noen av de beste autoritative bedriftsdataene, hjelper BDNA i hovedsak bedrifter med å få bedre forretningsavgjørelser. Når du går og setter deg ned og leter etter en forenklet måte å takle ITSM-løsningen på, er det BDNA til slutt hjelper deg med å drive enkelhet ved å rydde opp i dataene og gi deg muligheten til å ta gode forretningsavgjørelser, og vi gjør det fort.
De fleste av våre kunder - faktisk nesten 50 prosent - har fortalt oss gjennom uavhengig forskning at de fikk full avkastning på prosjektet på mindre enn 30 dager og bokstavelig talt 66 prosent fikk over 200 prosent avkastning det første året. Dette er den typen statistikk som din finansdirektør og administrerende direktør sikkert vil høre om du vurderer måter å investere og forbedre organisasjonen på.
Det vi skal gjøre nå er at jeg skal overføre ting til Chris. Vi har den bedre andelen på tretten eller femten minutter, det vi skal gjøre er å gå gjennom noen brukssaker som er kritiske, og noen som vi snakket om tidligere, i grunnen hva har jeg installert. Du har en mulighet til å se hva jeg bruker, slik at de potensielt kan høste av dem. Er jeg kompatibel med det jeg har installert? Kanskje jeg vil se på hvilke enheter som er over tre år gamle fordi jeg vil vite om jeg kan oppdatere disse enhetene. Hvilken programvare er det på disse enhetene, slik at jeg kan planlegge for den oppdateringsprosessen? Og hvis jeg ønsker å se nærmere på sikkerhetsrisiko, hvilke potensielle programvarekomponenter har en levetid som enten har overskredet eller kommer en gang i løpet av de neste tretti dagene eller i løpet av det neste året? Og som kan være oppført på National Institute of Securities Vulnerability List?
Eric, hva jeg ønsker å gjøre nå er å gi det tilbake til deg, og hvis du vil, kan du snakke overlevere ting til Mr. Russick?
Eric Kavanagh: Jeg vil gjøre det, og Chris, du skulle ha gulvet nå. Gå videre og del skjermen din og ta den bort.
Chris Russick: Utmerket. Takk, Tom. Takk, Eric. Jeg setter pris på at.
For vår demonstrasjon i dag, vil jeg presentere BDNA Analyse. BDNA Analyse er rapportseksjonen av våre BDNA-produkter. La oss begynne å svare på noen av de spørsmålene Tom førte til bordet. Hva har vi? Hvem bruker eller bruker vi produktene våre? Hva har vi rett til og er vi sikre?
Den første, la oss snakke om Microsoft-produkter, hva har vi installert og for det kommer jeg til å begynne med å overføre antallet installasjonsprogrammer. Deretter skal jeg komme inn og filtrere programvareprodusenter til Microsoft. Neste gang skal jeg overføre programvarenavnet for en fullstendig introduksjonstradisjon, og la oss bare begynne med hovedversjonen. Igjen, dette er i utgangspunktet Microsofts lagerstilling i både lisenser og ikke-lisenser.
Hvor gummien møter veien, vil virkelig være lisenser som kan godkjennes. La oss filtrere det enda lenger ned til lisenser som kan godkjennes. Vi kommer til å begynne med å svare på hva som var, igjen hva vi begynte å gjøre, og hva er Microsoft-produktfeeden. Det er en kostbar tittel og si når den sist ble brukt og av system, og prøv å få tilbake noen av disse lisensene ved å gjøre en programvare på nytt høst. Så neste vi kommer til å bli brukt, år, og vi vil filtrere det. Jeg velger 2012 og 2014. Jeg henter også inn SCCMs måledata. Det vi kan gjøre på dette tidspunktet, er å overføre programvaren sist brukt. Endelig kan vi komme til navnet til verten og ta det over, og vi vil også ta med den siste fullstendige brukerpåloggingen.
Fra denne rapporten kan du ganske enkelt gå til Mr. Acme-brukeren og spør dem: "Skal du bruke Microsoft-produktet i år? Det ser ut til at du ikke har brukt siden 2013. ”Eksempelrapporten bemerket at den ble fulgt av den, og at du kan gjenvinne lisensene. Neste gang skal jeg hoppe over til programvarekompatibelt dashbord. Jeg har denne forhåndsinnlastet, og denne inneholder for eksempel Adobe - hvilket program vi allerede er kompatible med og som vi ikke er kompatible med, og er det et estimat på hva som er under dem med spørsmålene som Tom hadde reist opp tidligere . Basert på innkjøpsordreinformasjonen din og med den oppdagede informasjonen vi har hentet inn, er det programvaretitler, din rettighet teller, hva kostnadene er for det, hva som er installert og om du er under eller over. Ved å se på denne rapporten kan du svare på mange av disse spørsmålene.
Det neste jeg vil hoppe over til er maskinvareoppdateringen. Hensikten her er å bestemme hvilken maskinvare som er utdatert, hva som er mer enn tre år gammel eller fire år gammel, uansett hva organisasjonen anser er viktig. Bare flytt til systemtellingen. For dette eksemplet skal vi fokusere på stasjonære maskiner. Jeg kommer hit til informasjonen om programvareprodukter, så tar vi inn kategori, underkategori, og vi vil bare beholde stasjonære maskiner. Herfra overfører vi informasjon om produkt, produsent og modell. For dagens eksempel skal vi fokusere på 790-tallet. Årsaken til at jeg trenger å gjøre dette er fordi vi vet at disse er mer enn tre år gamle, men vi tar over maskinvaren GA her. Hvis du ønsket å finne denne GA her, kan du absolutt overføre den for alle maskinvareprodukter i underkategorien.
Til slutt, hvis du skal gjøre en oppgradering eller oppdatere til disse enhetene, er det nyttig å finne ut hva disse enhetene er. Igjen kan vi komme ned på vertsnavnet, og videre er det nyttig å forstå hva som er installert på dem. Så vi har en installasjon av programvare, og det er her rapporten blir stor. Vi må overføre programvareprodusentene, programvarenavn og til slutt programvarens store versjon. Vi trenger ikke en maskinvarekategori og underkategori, så vi kan spare litt plass her. Her er en liste. Så på dette tidspunktet forstår vi at på denne verten har vi disse produktene som må oppgraderes som en del av maskinvareoppdateringen. På dette tidspunktet må vi vite hva som er kompatibelt med operativsystemet, så vi kommer til å inngå en avtale om programvareberedskap. Det kommer til å være programvare Windows beredskap 64 bit. Vi skal til et 64-biters miljø. På dette tidspunktet har du virkelig handlingsdyktige data - hva som er installert på hvilken vert - men du trenger å oppgradere basert på GA-data, og dessuten kan du fortelle om det er kompatibelt eller det må være kompatibilitetssjekk eller ganske enkelt ikke kompatibelt. Dette gir teamene dine, hvem som helst som skal gjøre dette, hvordan dette frisker opp verdifull informasjon og sparer dem tid på lang sikt.
Til slutt, for sikkerheten, er det to deler av sikkerhet. De er enormt nyttige når vi snakker om maskinvare- og programvareverdier og produksjonsmiljøer. Først er livets sluttdata. Det er klart at du vil at alle oppdateringene dine skal oppdateres og programvarene som er utgått av livstid opp til den nyeste versjonen av åpenbare grunner. Så vi takler det først. Igjen, vi starter med installasjon av programvare. Vi kommer til å overføre hele ditt miljø. Vi overfører programvareprodusenten din, programvarenavnet og hovedversjonen igjen. Det neste vi kommer til å gjøre er å komme ned og begrense levetidsdataene til programvarens sluttår. Vi vil bringe omfanget til dette. Vi skal gjøre inneværende år - det forrige, vi sier to år og de neste to årene - så vi skal gjøre en fem-års skanning. Hensikten her er å svare på spørsmålet om: “Hva trenger vi å oppgradere i år? Hva skal vi ha oppgradert de siste to årene? Og for å være i forkant av spillet, hva trenger vi å planlegge for de neste to årene? ”
Vi tar med disse dataene og legger dem over toppen med den oppdateringen. Rett utenfor flaggermusen, kan du se at i 2014 er det 346 installasjoner av det som ser ut som BlackBerry-programvare, personlig vDisk fra Citrix, det er 25 osv. Så dette er en god rapport. Igjen, vi ønsker å gå gjennom alle trinnene, men du kan absolutt velge bare skrivebordsprogramvaren eller "Keep Only" og deretter finne ut hvor det er installert. Du kan eksportere disse dataene til en CSC, PDF eller Excel. Dermed kan CSC bringe det inn i andre produkter også hvis du vil gjøre noen oppgraderinger på en automatisert måte og fra et klientperspektiv, kan du se nøyaktig hva som må gjøres i fremtiden.
Endelig bruker en annen rapport som jeg har laget i systemet vårt BDNA Analyse. Det er en systemrapport basert på spesifikke CVEer fra NIST-databasen, National Institute Standards and Technology. Det jeg har gjort her er at jeg målrettet Apple iTunes og ropte spesifikt ut noen CVE-er i 2015, og jeg prøvde å lage en rapport som ser etter den spesifikke versjonen, hvor mange systemer vi har installert, og hvor mange systemer som er berørt og hvordan mange programvarekomponenter som er installert basert på disse CVE-ene.
Igjen, det er et flott verktøy hvis du prøver å få (uhørbart) utbedringspunkt eller bare hjelpe i sikkerhetsavdelingen å bedre styre IT-eiendelene og varelageret. På dette tidspunktet ønsker jeg å overføre det til Tom og Eric for spørsmål og svar.
Eric Kavanagh: La meg først og fremst hente inn analytikerne, Dez og Robin. Jeg er sikker på at du har noen spørsmål. Det var en fantastisk demo, forresten. Jeg finner meg bare overrasket over hvor mye synlighet du kan komme inn i dette miljøet. La oss innse det, i disse virkelig heterogene økosystemene er den slags synlighet det du trenger å ha hvis du skal forstå hva som skjer der ute, og hvis du vil møte en revisjon, noe som selvfølgelig ingen vil gjøre, men, Dez, antar at jeg først vil overføre det til deg for spørsmål du har.
Dez Blanchfield: Mann, jeg har tenkt å bokse meg selv fordi jeg bare kunne bruke dagen på å snakke med deg om dette. Det er et par ting som har kommet til meg gjennom spørsmål og produktmeldinger som jeg også kommer til hvis du ikke har noe imot det. Dette minner meg om at skjermbildene du viser meg, minner meg om hva slags prosjekt som jeg gjerne ville ha snakket om der vi bare gjorde en oppdatering av nitten tusen maskiner for et selskap som heter Data EDI gjennom deres (uhørbare) divisjon og andre områder, og jeg kan offentlig snakke om det fordi det er et åpent prosjekt. Det jeg fant ut var at det var tre separate desktop-oppdateringer og SOA-oppdateringer som ble løpt parallelt av en eller annen grunn, og jeg endte opp med å bare stoppe dem alle og starte fra bunnen av med et automatisert verktøy.
Vi snakker om skala, og jeg kommer tilbake til deg med et spørsmål om et sekund. Da vi gjorde noe i den skalaen, skjedde det som skjedde, at jeg kom ut av ingeniørteamet og ut av CIOs kontor, og jeg gikk rundt resten av virksomheten og sa: "Vi gjennomfører en revisjon av alt i denne organisasjonen fra desktop down. Hva vil du vite om det? " og ingen stilte egentlig noen spørsmål. Så nå har jeg noen merkevare-X-økter der jeg fikk dem i et par tavlerom og sa "La meg bare stille spørsmålet igjen." I finans, la meg vite å fortelle deg hver eneste programvare hvor du måtte rapportere hvor mye vi betaler for og hva den slags får slutten på livet og når du kan skrive det som det er av. Kan du få det til PNL og GL? Hvor er kapitalforvaltningen din rundt dette, og hvordan administrerer vi budsjettering for programvarelisenser for neste år? Glaserte øyeboller, og jeg gikk gjennom alle de andre gruppene, så jeg er opptatt av å få litt innsikt i hva du har sett på disse stedene hvor du tydeligvis har et flott verktøy som gjør enorme mengder kraftige ting på tvers av kapitalforvaltning og eiendomsfunn.
Hva er din reaksjon på slike scenarier der du har kjørt et prosjekt der du har hatt en klient som har kjørt et prosjekt, og plutselig er det økonomi og ingeniørvirksomhet og utstyr og sikkerhet og etterlevelse og mange ting og til og med litt skygge IT-miljøer spretter og sier: "Vi ante ikke at dette var her, og hvordan får vi tilgang til dataene?" Jeg vil gjerne høre om alle slags eureka-øyeblikk med organisasjoner du har hatt og hva de har gjort med det.
Tom Bosch: Jeg skal kaste inn en, Dez. Jeg tror det vi ser gang på gang, folkens, er åpenbart at det alltid er et inngangspunkt, ikke sant? Det er en gruppe i en organisasjon som sier: "Jeg trenger skjermdata for en brukssak." Enhver løsningsleverandør, det er vanligvis der den kommer inn, og jeg vil si sannsynligvis 65 eller 75 prosent av året, inngangspunktene for oss pleier å være rundt kapitalforvaltning. De pleier å være rundt IT. Vi er ikke et ITAM-verktøy. På slutten av dagen er det vi er et datahåndteringsverktøy. Vi leverer ITAM-løsninger som de som er innen service nå og andre mer komplekse løsninger som Sierra og Snow.
På slutten av dagen begynner det å skje når rene data blir brukt og presentert på andre IT-organisasjonsmøter, folk går: “Hvor har du det? Åh, det kom herfra. ”“ Egentlig? Kan jeg se på det? ”Så når de finner ut at du kan begynne å knytte eller forbedre eiendelene med tilleggsinnholdsdata, og det er noe som er veldig, veldig unikt for BDNA, det er da" aha "-øyeblikkene begynner å åpne seg . Så en av grunnene til at vi liker å vise sikkerheten er fordi Verizon gjorde en studie for et par år siden, og i utgangspunktet kom de tilbake og sa: "99, 9 prosent av alle hacks som foregår i miljøet kommer inn gjennom programvare . De er utdaterte, har ikke blitt oppdatert og / eller er i slutten av livet. ”De fleste av dem er et sted mellom tre måneder og et år utdatert eller ute av livet.
Ved å ha den informasjonen på forhånd, kan sikkerhetsavdelinger nå være proaktive i sin tilnærming for å forhindre brudd. Chris, har du noe å presentere fra dine reiser?
Chris Russick : Absolutt, så vi alle spikret et par historier sammen og snakket om hvordan de to "aha" -øyeblikkene er. Vi prøver å forstå hvor de henter dataene fra, og mange kunder skjønner ikke bredden av data som er tilgjengelig der ute, enten det er fra en SCCM eller Casper, eller du velger verktøyene. Intensjonen der er å kunne få gode data fra alle verktøyene dine. Hvordan aggregerer du det, riktig, uten BDNA, og kanskje det første "aha" -øyeblikket er, "Wow, vi kan ta alle disse dataene som vi har, samle dem sammen."
Det er muligheten for folk å ta virkelig handlingsrike beslutninger basert på dataene i stedet for å prøve å finne støtteinformasjon i dataene for å støtte beslutninger de allerede har tatt. Jeg hadde en kunde oppe i Tennessee-området som bokstavelig talt når de var i stand til å utføre dette, jeg tror det var som om en uke de hadde installert dette, bokstavelig talt danset på pultene og avlukkene deres fordi de ikke visste full pust av dataene sine, og nå gjør de det.
Tilbake til dere.
Dez Blanchfield: Berikelsesstykket er interessant for meg. Bare raskt på det og så overlater jeg det til Dr. Robin Bloor. Jeg jobbet mye med banker og formuesforvaltningsfirmaer, og det er et par viktige ting som de gjennomfører regelmessig i sitt forsøk på å holde seg etter de mange utfordringer som kjenner kunden din, eller KYC. Det er anti-hvitvasking, AML. Det jeg finner er imidlertid mange av disse organisasjonene når de blir gode i KYC-prosessen og deres klientprosess, oftere enn ikke, ser innover og behandler seg selv som en klient, og jeg ser at mange av dem bruker nå ikke dybden at du kom hit men veldig høye nivåer verktøy for å prøve å kartlegge hvem sluttbrukere er med klienten og hva de bruker på grunn av grunnen til at du snakker om. Noen mennesker har nettopp BYOD, noen har gamle versjoner av programvare. De har alltid dårlige ting med seg på jobb.
Har du hatt spesifikke eksempler på at du har tatt dataene du har hatt på den anvendte serveren på reisen du har hatt, og i hvilken prosess de deretter tar innholdet av dataene og mater det til noe annet? Kanskje det er en kartlegging av hvem som faktisk bruker systemet i utgangspunktet, og hvem som kartlegger det, for eksempel HR som folk som bruker systemet, faktisk er ansatt og antas å være i bygningene og andre eksempler på hvordan noe er i vente, hvordan er det noe i maskinen som de ikke burde ha, og hvordan gjenerobre det? Har du noen eksempler der en annen del av virksomheten som du tradisjonelt ikke ville tro at ville få verdi ut av dataene har tatt en undergruppe eller fått tilgang til den og involvert dem til å få en tilsynelatende ikke relatert verdi som de så komme ut av denne jobben?
Chris Russick: Jeg vil gjerne hoppe på denne først. Jeg har nøkkelkunder som jeg tenker spesielt på. Den ene er på et medisinsk feltsykehus, og de gjør akkurat det. Vi tar noen berikelsesdata mot oppdagelsesdataene deres ved å hente inn Active Directory, og deretter vet de hvilke eiendeler som faktisk hører hjemme i nettverket deres. Derfra kan de bestemme hvem som skal og ikke skal lappes, hvem som bør og ikke bør være på nettverket sitt, og deretter føre en liste over deres tilgang til skrivebordet og hva ikke. Den andre er faktisk spesifikt et par forskjellige kunder eller spesifikt tar disse dataene, og jeg har aldri vært i virksomhetsarkitekturverdenen, så det er relativt nytt for meg de siste to årene, men det er en hel brukssak for å kunne ta vår levetidsdata eller andre ressursanrikede data og pumpe det ut til andre verktøy for bedriftsarkitektur som vil gjøre foretakskartleggingen og ting som bedriftsarkitekter gjør, og helt ærlig, det er en del av bransjen som har blitt veldig populær blant dataene og Det har jeg aldri sett før. Tom?
Tom Bosch: Jeg tenker å legge til at to brukssaker som jeg synes har dukket opp ganske raskt, begge er slags i og rundt HR. I utgangspunktet hjelper de å forstå hva de interne ansatte i selskapet bruker - og jeg synes alltid det er fantastisk når klienter kommer tilbake og dette bokstavelig talt skjer hver gang de kjører sannsynligvis sin første normalisering, er at de sannsynligvis vil finne et godt eksempel på tolv eller fjorten forskjellige Xbox-er som er koblet til nettverket, som vanligvis ikke er sanksjonerte enheter i forretningsmiljøet med mindre du jobber hos Microsoft. Å finne enheter som ikke skal være i miljøet, finne programvare som ikke skal være i miljøet, og så har jeg sett HR raskt bruke dette til å verdsette investeringene de må gjøre i ombordstigningsprosessen med en ny ansatt. De ante ikke at den gjennomsnittlige ansatte kanskje var et sted i nærheten av 2500 til 3000 dollar programvare og i overkant av 5000 dollar bare IT-investering alene.
Dez Blanchfield: Dette er en annen brukssak. Det er ikke så mye spørsmål. Det er bare et poeng å kaste ut for å dele. Jeg har hatt scenarier der vi har hatt veldig, veldig store revisjoner av et miljø. Vi fant gamle systemer som menneskene opprinnelig satte dem på plass der folk som opprettholdt dem hadde flyttet videre og merket at det er dokumentert og bemerker at det er kartlagt. I ett tilfelle fant de en stålprodusent som hadde en gammel gruppe på 486 stasjonære PC-er koblet til modemer som pleide å ringe opp til banken hver dag. Denne organisasjonen var en multibillion dollar stålprodusent her i Australia, og de var ikke klar over at disse 486 PC-ene gjorde (uhørlig) med bankoppringningen hver dag.
Den andre, desto mer interessant, var det i et jernbanetogger som produserer lagermiljø. De hadde et system som de trodde var en simulator for togovervåking. Det viste seg at det faktisk var live-systemet på en gammel AIX RS / 6000 IBM-maskin, og heldigvis dør de tingene bare for i nesten et tiår var det ingen av de ansatte som hadde implementert den som støttet den, og hadde faktisk forlatt avdelingen etter å ha blitt lagt ned, og de hadde faktisk startet den. Toget kjører rundt på stedet og med denne tingen og snakker og fanger overvåkning, men jeg synes det er veldig interessante brukssaker som ganske ofte folk som gleder seg kommer til å tenke på at hvis de begynner å se bakover, ser de noen veldig interessante ting også. Med det vil jeg levere det tilbake til Robin fordi jeg tror jeg har tatt for mye av tiden din.
Eric Kavanagh: Robin, ta den bort.
Robin Bloor: Så vi går litt ut av tid, så jeg mener en av de tingene som interesserer meg er kjøp av et produkt som dette - hvis du kan snakke med dette, hvor mange som kommer til deg eller kommer til dette produkt, fordi de har fått et veldig spesifikt problem på hendene? Hvor mange som faktisk kommer av strategiske grunner fordi de bare innser at de faktisk burde ha noe slikt fordi det de faktisk har, er fragmentert eller ubrukelig. Det er en del av spørsmålet. Den andre er, etter å ha tatt i bruk denne helt spesifikke taktiske grunnen, hvor mange som gjør det strategisk fra da av?
Chris Russick: Det er et flott spørsmål, Robin. Jeg mener jeg tror det er menneskelig natur å være reaktiv. Jeg må si at 95/100 ganger når klienter kommer til oss, reagerer det på en situasjon som har fått dem til å skaffe seg en løsning. Den som bare driver bedrifter nøtt i disse dager er revisjonsprosessen. Jeg har bokstavelig talt hørt om kunder som mottok regninger fra programvareleverandører på over en milliard dollar før tilsyn, og du kunne bare forestille deg hva en finansdirektør eller finansdirektør sier når de ser det. "Hvordan kunne dette ha skjedd, og hvorfor har vi ikke bedre kontroll over dette?" Folk blir veldig reaktive på det.
Nå kan jeg også fortelle deg at i noen av disse situasjonene, når de først har fått hendene rundt det de faktisk hadde, viser det seg at leverandørene var litt aggressive i sin tilnærming til det de trodde var i miljøet. I flere spesielle tilfeller har jeg sett at kunder går fra veldig, veldig store estimater før revisjon til ikke å skylde leverandørene i det hele tatt penger. Mye av det har å gjøre med å sørge for at de rydder i disse dataene og gjør det på en måte som er systematisk og standard og standardisert. Det er mange selskaper som prøver å tilnærme seg denne tingen fra en manuell prosess. Det koster at tradisjonelle revisjoner tar omtrent tusen til femten hundre mann timer å forberede seg på. Så vi kommer virkelig helt til spørsmålet. Jeg tror mange selskaper kommer til oss, flertallet kommer til oss med et hett problem. Da tenker jeg til slutt når de blir mer modne i forståelsen av hva de har og om de kan utnytte det, blir det mer strategisk. Det er en av BDNAs regler. Når klienten hadde gjort investeringen, er det å sørge for at de forstår og utnytter investeringen på tvers av driften.
Eric Kavanagh: La meg kaste et siste spørsmål til deg fordi det åpenbart er eksisterende verktøy der ute i noen organisasjoner, og noen har sendt meg tekst akkurat nå - er det en naturlig prosess å migrere fra flere systemer som allerede er på plass for å bruke din BDNA-løsning som den eneste kilden til sannhet, så å si. Hvordan ser det ut? Hvor lang tid tar det? Det høres ganske utfordrende ut, men du forteller meg det.
Tom Bosch: Chris, la meg komme med en rask kommentar, og du kan snakke om den tekniske siden av det, ikke sant? Vi har sett kunder med så få som en eller to oppdagelsesløsninger til så mange som 25 og for å få dem alle sammen og samle dem - det er hva den normaliserte komponenten i det verktøyet gjør. Hvordan vi gjør det er egentlig en kombinasjon av standardisert tilkobling. Da må vi i noen tilfeller bygge ut noen kundesporere. Chris, kan du kanskje gjenta det og forklare dem hvordan vi gjør det?
Chris Russick: Absolutt, takk Tom. Vi har 54 ut-av-boksen-ekstraksjoner som vi bruker for å trekke det lageret ut dataene fra eksisterende løsninger, og vi har et utall alternativer for å få inn noen hjemmelavede løsninger potensielt hvis du har fått dem inn Excel eller annen database. Denne aggregeringsprosessen er egentlig ikke så lang til å konfigurere og skille seg ut fysisk, to til fire uker, og vi har fått løsningene dine satt opp, og du får data ikke så langt nede og deretter, men det vi endte opp med å gjøre er etter samlingen og dupliseringen vi kommer til å begrense dataene, den gode rene dataen opp til Technopedia og berike det. Til slutt vil vi pumpe det inn i en SQL- eller Oracle-datakube, og den datakuben er det som blir pumpet ut til hvor enn annet du ser de dataene eller igjen til BDNA Analyse som det du så i dag. Igjen, med fokus på at vi ikke prøver å erstatte hvor du får dataene, prøver vi ikke å erstatte der dataene bare går rundt duplisering og berikelse og deretter data av god kvalitet. Jeg håper det svarer på spørsmålet. Hvis ikke, kan du gjerne spørre mer.
Eric Kavanagh: Det høres bra ut, folkens. Vi har gått litt over tid her, men vi har alltid likt å ha en fullstendig samtale og folkene fra BDNA sendte meg akkurat denne listen her. Jeg la denne lenken i chat-vinduet, og du kan se at det er mye forståelig liste over forskjellige kontakter som jeg har fått der.
Så folk må jeg fortelle deg, vi kommer til å slå opp her. Vi arkiverer selvfølgelig alle disse webcastene. Du kan gå til InsideAnalysis.com. Det går typisk opp dagen etter. Vi vil også videreføre noen av de detaljerte spørsmålene som folk sendte til oss. Vi vil overføre det til høyttalerne i dag. Ta gjerne kontakt med dem eller selvfølgelig din virkelig, du kan slå meg opp på Twitter @eric_kavanagh eller selvfølgelig via e-post, smedia.com eller.
Stor takk til vennene våre fra BDNA. Stor takk til vennene våre på Marketry for at du hjalp oss med å gi deg dette innholdet, og selvfølgelig en stor takk til Techopedia og Technopedia, fordi Techopedia er mediasamarbeidspartneren vi har fått, en fantastisk, flott webside. Gå til Techopedia.com og Technopedia er nettstedet til folkene på BDNA satt sammen. Så dette er bra materiale, folkens. Tusen takk for din tid og oppmerksomhet. Vi har mange webcasts som kommer de neste par ukene. Forhåpentligvis har du ikke noe imot å høre stemmen min for mye.
Med det kommer vi til å ta farvel. Takk igjen, så snakker vi med deg neste gang. Ta vare folkens. Ha det.
