Hämtmat: Värd Eric Kavanagh diskuterar IT-tillgångshantering med experterna Dez Blanchfield, Dr. Robin Bloor, Tom Bosch och Chris Russick.
Du är för närvarande inte inloggad. Logga in eller registrera dig för att se videon.
Eric Kavanagh: Mina damer och herrar, hej och välkomna återigen till Hot Technologies! Ja verkligen! Jag heter Eric Kavanagh. Jag kommer att vara din moderator för dagens evenemang, och folkens, vi har några spännande saker kartlagda för dig idag, jag kan berätta just nu. Detta är ett av de mer fascinerande områdena inom IT-hantering i allmänhet. Ämnet är "Keep It Simple: Best Practices for IT Portfolio Management." Vi kommer i hög grad att fokusera på datasidan av den ekvationen idag. Med andra ord, se till att dina data är rena eller så rena som möjligt när du försöker förstå landskapet på enheter över hela ditt företag.
Naturligtvis med din helt nya BYOD-värld, ta med din egen enhet - det finns din verkligen väldigt snabbt - vi har mycket heterogena landskap idag. Jag menar att er i stora organisationer känner till historierna. Det finns hela rum fyllda med servrar. Det finns applikationer som har körts i flera år. Det finns gamla IT-system som ingen har berört på tio år och alla är rädda för att stänga av för du vet aldrig vad som kommer att hända.
Så vi ska prata idag med ett par experter, i själva verket fyra experter totalt, om vad vi ska göra i det här utrymmet.
Hot Technologies, hela syftet med denna show är verkligen att gräva djupt i specifika typer av teknik och hjälpa vår publik att förstå hur saker fungerar, varför man använder den här typen av teknik, vad vissa bästa metoder är, vad du bör tänka på. Vi berättar några användningsfall ibland. Faktum är att Dez kommer att prata om en liten historia från hans erfarenhet av världen inom IT-tillgångshantering. Men återigen kommer vi att fokusera på datasidan eftersom det verkligen är våra vänner från BDNA. De är mästare för att hjälpa organisationer verkligen ta hand om vad de exakt har i sin miljö och hur man förstår var det är, vad det gör, vem som använder det, allt det där roliga grejer.
Här är våra paneldeltagare. Vi kommer att höra från Dez Blanchfield, vår nyligen uppfann dataforskare. Jag gillar att skryta med att Dez bokstavligen var en av de tio mest besökta LinkedIn-profilerna i Australien förra året. Det beror på att han aldrig sover. Vi har också Dr. Robin Bloor, vår egen chefanalytiker. Dr Bloor, för er som inte vet det, startade verkligen den IT-oberoende analytikerindustrin i Storbritannien för cirka 25 år sedan. Idag finns det en hel del. Det är nästan som jag säger en stugindustri. Det finns många oberoende IT-analytikerföretag. Vi har också Gartner, Foster, IDC och de stora killarna. Men det trevliga med de oberoende företagen är att ärligt talat är vi lite mer fria att tala uppriktigt om saker. Så ställ honom de svåra frågorna. Låt inte dessa killar enkelt. Du kan alltid ställa en fråga under showen genom att använda Q & A-komponenten på din webcastkonsol. Det är i det nedre högra hörnet eller så kan du chatta mig. Hursomhelst, jag försöker övervaka att chattfönstret alla är långt.
Med det låt oss introducera Dez Blanchfield. Dez, jag kommer att lämna dig nycklarna till Webex. Varsågod. Ta bort det.
Dez Blanchfield: Tack, Eric. Bra. Pojke, fantastisk intro.
Ämnet idag är något som jag har bott med för den bättre delen av mig, som trettio år, stor IT-miljö. De växer genom en organisk process. Som Eric sa, du startar små och du bygger dessa miljöer och de växer, och de växer organiskt i vissa fall. De kan växa på andra sätt som stora expansionsförvärv.
Jag kommer att dela en anekdot som berör alla de viktigaste sakerna vi pratar om idag, och i synnerhet, data och var data kommer från att göra och insamling av data för att göra IT-tillgångshantering. I det här fallet kommer jag att prata om ett stort arbete för en av de tre bästa förlagen i världen. De är inom radio, TV, tidning, tidning,, digital och en rad andra publiceringsutrymmen. Vi fick ett tre-månaders fönster för att köra det som i princip kallades en molnberedskapsbedömning, men det slutade vara en hel affärsövergripande molnstrategi som vi satt ihop. Vi fick denna grundläggande utmaning från CIO att minska datacentret med 70 procent inom tre år. Det var ganska uppenbart att göra detta var vi tvungna att göra en hel affärs-moln övergång. Vi hade tre månader att göra det här arbetet. Det täcker fyra olika regioner i fem länder. Det fanns sex separata affärsenheter som ingick och sju olika operatörer av statusleverantörer av statustjänster. Som titeln säger, slår inget det verkliga exemplet.
Vi kom fram till ganska snabbt att affärsmålen var uppriktigt intet annat än ett mirakel. De ville konsolidera sina egna datacenter. De ville utnyttja tredjeparts datacentermiljöer var nödvändiga, men i allmänhet ville de flytta till någon annans molninfrastruktur, särskilt offentligt moln eller virtuellt privat moln av nödvändiga säkerhetsskäl. Särskilt fokuserade Amazon Web Services och Azure på grund av att de var de mest försäkrade vid den tiden. De körde en blandning av Intel x86, 32/64-bitars plattform, IBM I-serien, AS-serien, AS / 400P-seriens stordator. De hade faktiskt två stordatorer, en för produktion och en för utvecklingen av katastrofåterhämtning. Sedan hela blandningen av operativsystem - Windows, Linux, AIX, Solaris och olika saker på bärbara datorer och stationära datorer.
Lagring var en av de största utmaningarna. De hade enorma mängder data eftersom de är en förläggare - allt från fotografier till videor till redigering av bilder till och innehåll. Genom dessa stora plattformar och olika lagringsformat fanns NetApp, Hitachi, IBM och EMC. Så extremt mångfaldig miljö för att försöka fånga och kartlägga de olika typerna av tjänster som finns där och bara få en bild av vad vi tar från nuvarande och privata datacentermiljöer till en molnmiljö.
Höjden på det vi pratar om idag kring IT-kapitalförvaltningen drivs av data i allt väsentligt och här är en karta över vad vi var tvungna att ta itu med just detta projekt, som jag delar anekdoten om. Vi hade många dataingångar. Tyvärr var ingen verkligen i mycket god form. Vi har en rad ofullständiga tillgångsregister. Det finns fem olika tillgångsregister som körs, så konfigurationshanteringsdatabaser, ITF-inmatningsformulär. Vi har olika datakällor som sträcker sig upp till nittio udda olika typer. Vi hade flera kärntjänstmodeller, motstridiga servicegrupper, en av de största samhället av intressenter som jag någonsin har behandlat i min karriär. Det var fyra hundra senior execs som ansvarade för dessa olika system. Under alla omständigheter hade vi för alla syften fullständigt inriktade affärsenheter - var och en av dem arbetade oberoende med sina egna miljöer och sin egen infrastruktur i vissa fall. Det var en utmaning.
Vi upptäckte detta inom ungefär den andra eller tredje dagen som vi just var "Kasta kroppar på det" fungerade inte. Så vi bestämde oss för att bygga ett system och vi kunde inte hitta det i detta skede som det var för ett antal år sedan - och vi kunde inte hitta de verktyg som passade vårt syfte och vi såg långt och hårt ut. Vi slutade bygga en SharePoint-plattform med ett antal databaser som matade den med en serie arbetsbelastningar i olika stadier. Vi gick tillbaka till grunderna bara för att få tillgång till data som var vettigt så att vi kunde validera, så vi använde en rad verktyg för att kartlägga de ekosystem som vi kör. Vi genomförde automatiserade revisioner av datacentret i fysisk och logisk infrastruktur. Vi gjorde automatiserade upptäcktsverktyg och kartlade tjänsterna som körs i dessa datacentermiljöer. Vi gjorde fullständiga genomsökningar av applikationer - letade efter allt från en applikation som körs i deras konfiguration medan portsystemen är på medan IP-adresserna är på. Vad vi gjorde är att vi byggde en ny enda källa till sanning eftersom var och en av de andra databaserna och informationssamlingarna de hade kring sin miljö och konfiguration och tillgångar bara inte var sanna och vi kunde inte kartlägga verkligheten tillbaka till den. Så vi slutade bygga en enda källa till sanning. Vi gick från att kasta kroppar på det till att kasta automatiserade verktyg på det. Vi började se lite ljus i slutet av denna tunnel. Så vi slutade med ett mycket sofistikerat system. Det gjorde några oerhört smarta saker från att fånga automatiserad loganalys till data som kastas mot oss från olika system, övervaka säkerhetskontroller, använda och logga lösenordskontroller, fysisk infrastrukturrevision, programrevision. Vi byggde en serie saker inuti för att sedan analysera dessa data med automatiserade poängkort. Vi producerade sedan rapporter kring lämplighet och procentuell rangordning, oavsett om applikationer passade eller inte passade för moln. Vi körde sedan en baslinje för det poängkortet över Amazon Web Services, med Azure- och VMware-modeller. Vi producerade en serie rapporter och finansiella instrumentpaneler om detta och tillät nästan aldrig någon manuell åsidosättning. Så vad vi fick poängen var sålunda ett automatiserat system som var självhållande och vi behövde verkligen inte beröra den här saken eller mycket sällan behövde vi åsidosätta dem manuellt. Den här saken växte mycket på egen hand och vi hade äntligen den enda källan till sanning och verkliga data som vi kunde borra ut till servicegrupperna, till tjänstesystemen som vi kör i applikationerna eller de data som använder dem och tjänster som levereras. Det var ganska spännande eftersom vi nu hade förmågan att fullfölja löften om denna projektsträng. Omfattningen av detta projekt - bara för att sätta lite nackdelar med det - är att vi hamnade, jag tror att det var ungefär 110 miljoner dollar från år till år skördes bort från botten, driften (inte hörbar), när vi slutförde detta övergång till att flytta huvuddelen av sin infrastruktur från sina egna datacenter till molnet. Så de är ett väldigt stort program. Vi fick detta fantastiska resultat för projektet. Men den verkliga frågan vi stötte på var att vi skapade ett hembakat system och det fanns ingen säljare bakom det i detta skede. Som sagt var detta för ett antal år sedan. Det finns ingen leverantör bakom det att fortsätta utveckla det och ge underhållsstöd för det. Det lilla teamet med cirka 30 personer som hjälpte till att utveckla det och samla all information och hastighet för detta monster övergick så småningom till andra projekt och två eller tre personer satt kvar. Men vi slutade med en situation där vi inte hade en materialhanterad IT-tillgångshanteringslösning. Vi hade ett engångsprojekt och verksamheten gjorde det mycket tydligt att de redan trodde att de hade konfigurationshanteringsdatabaser och ITSM-verktyg som kartlade världen trots att vi stod ovanpå en mycket stor tvålbox och skrek högst upp på vår röster om att den information som inte har någon mening. Vi demonstrerade genom att låta dem bygga verktygen runt projektet. Det olyckliga resultatet av denna spännande men tråkiga historia var att resultatet för projektet var mycket, mycket framgångsrikt. Det var en lyckad framgång. Vi drog hundra och en halv miljon dollar från deras slutlinje år över år. Vad vi har gjort är att vi skapade detta Frankenstein, detta riktigt kraftfulla system som kan samla in data och ge rapportering om det i realtid i vissa fall men det fanns ingen där för att underhålla dem. Affärssorten låt den bara köras ett tag tills slutligen data inte användes av någon och sedan kom ändringar till det och det kunde inte samla in data som stämde överens med förändringar. Så småningom på den tiden, detta hem-bakade systemet lämnades att dö tillsammans med data som fanns med det. Vi hade det här scenariot där de gick tillbaka till exakt vad de hade i första hand, som skiljer följare och de olika datauppsättningarna som såg mycket, mycket noggrant ut i en nischform i ett visst område av tjänster eller servicegrupper och löser sina problem, men de förlorade den organisationen brett. De har 74 olika tjänster i gruppen. De förlorade allt detta värde, och konstigt nog, två eller tre år senare, insåg de vad de har tappat, och var tvungna att titta på hur de löste problemet igen. Historiens moral är att om det var fallet, om det var en produkt som vi hade kunnat komma ut ur hyllan för ett antal år sedan, var vi tvungna att bygga en, men det är inte bara fallet längre. Det finns produkter där, som vi håller på att se, som kan göra det och de kan göra det på ett automatiserat sätt. De kan rensa upp all data, de kan ta flera datauppsättningar och slå samman dem och dupa dem. De kan ta riktigt uppenbara saker till människor och kalkylblad med saker som de skulle säga, marscherade version en punkt en, version en punkt noll punkt en, och bara kalla dem Microsoft. Då vi byggde det här verktyget var den typen av saker inte tillgänglig. därför var vi tvungna att göra mycket av denna förmåga. Jag letar efter samma detaljer om vad den här plattformen vi ska höra om idag gör för att jag bara önskar att vi hade den då. Vi kunde ha sparat oss mycket sorg och vi kunde ha sparat mycket tid och ansträngning och utveckling för en plattform som kan upprätthållas av någon som fortsätter att utveckla och växa den plattform som gör den tillgänglig som en allmän konsumtion. Med det kommer jag tillbaka till dig, Eric. Eric Kavanagh: OK. Jag ska överlämna det till Dr. Robin Bloor. Robin, ta bort den. Robin Bloor: Det är verkligen en intressant berättelse, Dez. Jag gillar det. Det är inte riktigt ovanligt för mig. Varje gång jag stötte på IT-tillgångshanteringsproblemet har det alltid funnits ett företag som faktiskt åkte hem och gjorde något med det och var tvungen att göra det, men det verkar aldrig som att du stötte på en organisation som har hela saken under kontroll. Ändå, så långt jag kan veta, om du inte hanterar dina IT-tillgångar bränner du pengar. Sedan Dez kom ut med den snygga skitna historien, tänkte jag att jag bara skulle göra översikten över, verkligen, vad som är IT-tillgångshantering. Vad betyder det egentligen? Detta är fågelperspektivet eller örnperspektivet. Tänk på en fabrik - särskilt organisationer som driver fabriker med avsikt att göra vinst. Allt möjligt görs för att maximera utnyttjandet av de dyra tillgångarna som används. Det är bara fallet. Tänk på ett datacenter, inte så mycket, i själva verket oftast inte alls. Då tänker du lite, hur mycket investeras de i datacentret? Du vet, om du faktiskt räknar ut det är det verkligen stora pengar. Ni sätter ihop, jag vet, de historiska ansträngningarna för alla som byggde systemet. Deras licenser betalas för programvaran och värdet på data och kostnaden för själva datacentret och naturligtvis all hårdvara, det kommer bara att vara tiotals miljoner. Det beror på hur stor organisationen är, men lätt tiotals miljoner i de flesta organisationer. Det här är en enorm investering som folk gör i IT och säkert i stora organisationer, det är enormt. Tanken på att du egentligen inte borde särskilt bry dig om att få ut maximalt värde av det och det ska drivas effektivt är uppenbarligen en absurditet, men som bransch finns det väldigt få platser som faktiskt har disciplin att verkligen verkligen hantera IT tillgångar. Detta är en modell jag har använt, antar jag inte, ganska många gånger, antar jag. Det är vad jag kallar diagram över allt. Om du tittar på en IT-miljö har den användare, den har data, den har programvara, den har hårdvara. Det finns en relation mellan alla dessa grundläggande enheter som utgör en IT-miljö. Den använder specifika programvaror eller relationer som har tillgång till specifika dataförhållanden. De använder specifika hårdvara resurser så det finns en relation där. Programvara och data är nära relaterade. Programvaran finns och körs på specifik hårdvara och där finns den dataspecifika hårdvaran. Så det finns alla dessa relationer. Om du vill veta var IT-tillgångarna är det bara att lämna handen över användarna eftersom det är väldigt lite att du kan kalla en IT-tillgång förutom förvärvade kunskaper och dess användare och det är allt annat. Då tittar du på det och du ser, hur många organisationer till och med har en inventering av all programvara som utfärdas i alla system som de använder? Hur har vi till och med en korrekt inventering av hårdvara som inkluderar alla nätverksfunktioner? Hur många har någon meningsfull inventering av uppgifterna? Svaret är inget. Att veta var saker är och att veta hur en förhåller sig till en annan kan vara mycket, mycket viktigt i vissa fall, särskilt i den typ av instans som Dez just beskrev var du ska plocka upp det och flytta allt eller plocka upp det och flytta det mesta. Det är inte bara en trivial sak och bara att veta vad som finns där är en stor sak. Att faktiskt veta hur en sak relaterar till en annan. Då är det andra att detta diagram gäller på den minsta graden av granularitet, kan du föreställa dig, den minsta programvaran. Du får åtkomst till den minsta mängden data du kan tänka dig att köra på en triviell maskinvararesurs upp till ett ERP-system med en enorm, massiv mängd olika databaser och datafiler som körs på flera hårdvara. Detta diagram generaliserar allt och det gäller alla nivåer av granularitet och denna pil med tiden går under indikerar bara att allt detta är dynamiskt. Det kan se ut som att det fortfarande är ett diagram, men det är det inte. Det rör sig. Allt förändras. Att hålla reda på det är ingen trivial sak. Jag menar att det bara inte är det. Du kan faktiskt utöka detta diagram och du kan säga, glömma datorer och bara göra det ännu bredare. Företag består av all data plus företagsinformation som kanske inte lagras elektroniskt. Olika faciliteter och det är inte nödvändigtvis datorelaterat. Olika affärsprocesser som inte nödvändigtvis är mjukvaruberoende eller delvis kanske oberoende som programvara. Många människor - inte bara användare av system utan personal, paneldeltagare, kunder och så vidare - som utgör ett företags ekosystem, och då har du faktiskt mänskligheten som helhet, människor. Det finns all information i världen. Det finns civilisation. Allt detta är vad vi kallar hårda saker och alla mänskliga aktiviteter. Detta är schemat över allt och allt. Det diagrammet ger dig en indikation på hur sammanhängande från den minsta samlingen av saker som gör någonting till det största för när det gäller mänskligheten finns det precis som hela Internet och de miljarder datorer som utgör det och alla enheter och så vidare. Det är ett stort antal saker och allt detta är uppenbart subjektivt för tidens pil. Det är fågelperspektivet. Jag listade just detta rakt upp från mitt huvud utan att ens tänka på det. Dimensioner på IT-förvaltningen. Det finns ett tillgångsregister, hårdvara, mjukvara, data och nätverk. Det finns tillgångsattribut fångat - har du all information relaterad till alla dessa saker? Tillgångsanvändning - varför finns det här alls? Kostnad för anskaffning av tillgångar och ägandekostnad - hur mycket kostar och därför hur mycket är ägandet och hur mycket ska jag ersätta från en bra idé? Det ger idéen om tillgångsavskrivningar. Jag pratar inte bara om hårdvaran. Vi pratar också om saker och eventuellt också uppgifterna. En komplett tillgångskarta som skulle vara att instansera diagrammet jag just diskuterade. Molntillgångar - saker som inte faktiskt är på parametrar men som faktiskt gör på ett eller annat sätt tillhör organisationen på grund av uthyrning och på grund av förnuft. Servicehanteringsmål och hur de relaterar till alla dessa speciella möjligheter. En av de saker som Dez pratade om är hans ansträngningar, en samling system från en plats till en annan plats som är, hur fungerade serviceledningen i termer av "träffade du målet som människorna förväntar sig i sina system ?" och så vidare. Det finns risk och efterlevnad - saker som på ett eller annat sätt de aktieägare som kan vara bekymrade för och regeringen själv kan vara bekymrade över och allt detta är en del av kapitalförvaltningen. Det finns anskaffning och licensiering av all programvara. Det finns affärsresultatmål. Det finns en hel tillgångsstyrning när det gäller vilka regler som organisationen kan fastställa för någon av dessa saker. Vi pratar om riktigt komplexa saker. Så frågan uppstår och det är så jag slutar - hur mycket av detta kan göras? Hur mycket av det borde faktiskt göras? Eric Kavanagh: Låt oss med det ta reda på vad experterna har att säga. Jag ska överföra det till Tom Bosch. Stå vid och ger dig nycklarna till Webex. Ta bort det. Tom Bosch: Webex titeln, ur vårt perspektiv, handlade om att hålla det enkelt och uppenbart bästa praxis för IT-portfölj eller IT-tillgångshantering. När du säger bästa praxis är det i slutändan en åsikt. Det är en strategi ur vårt perspektiv. I slutändan vad BDNA vill göra är att hjälpa många av de företag där ute som vi hittar fortfarande bara att få sina fötter våta ner igenom IT-resvägen. IT-tillgångshantering var ett hett ämne runt Y2K för några av er som har varit i branschen ett tag, och det främsta skälet är att jag måste förstå om den mjukvara jag har och de system som jag har till och med går att ersättas eller uppdateras eller kommer de att misslyckas när vi träffar det nya årtusendet? Jag tror att det vi alla levde igenom den konstiga kvällen för sexton år sedan var det faktum att faktiskt mycket lite gick ner i bakgrunden. Våra kraftverk stannade vid liv och tågen fortsatte att köra. Ljusen i New York och Sydney stannade kvar. Genom den processen började människor förstå att det fanns en enorm mängd information som behövdes samlas in och sammanföras. I slutändan var det uppgifterna bakom allt det som måste rengöras, som Dez sade tidigare, för att kunna fatta de typer av beslut som människor letade efter. Så det är kärnan i vår konversation idag. Jag tror att var och en av oss inser att vi varje dag går in i vår IT-avdelning, varje dag som vi går in i våra organisationer. Enterprise, informationsteknologi är nästan utan kontroll. Vad jag menar med det är att det finns nya servrar som tas med online. Det finns nya programvara som distribueras från avdelning till avdelning till avdelning över olika organisationer, oavsett om du är i tillverkningsbranschen, du är i en serviceorganisation, du är i detaljhandeln, var och en av våra organisationer idag är inte bara körs utan de drivs. IT håller på att bli produktionsmotor för många av de organisationer som vi arbetar i. Det blir inte tydligare genom att titta på lösningarna som används. Om vi bara fokuserar internt på datorns komplexitet precis inom IT-avdelningen - bara de applikationer som de används för att till slut stödja IT - har vi allt från leverantörshanteringssystem till IT-portföljhantering, upphandlingssystem, arkitektursäkerhetssystem, och ett av de viktigaste attributen som utvecklar detta är att de kan leda till att använda i huvudsak en inventering av vad du har i din miljö för att effektivt kunna driva lösningar inom deras specifika discipliner. Så att ha dessa tillgångar till hands är avgörande för nästan varje disciplin inom IT-organisationen. Men en av de saker som snabbt hittas när företag börjar försöka föra samman dessa olika system är att de inte talar samma språk och i slutändan det kommer till data. Som Dez påpekade tidigare var dålig information roten till projektet som de startade med, och mycket intressant statistik i företaget Gartner, att bokstavligen IT slösar bort mer än 25 procent av de pengar som de investerar i på årsbasis på grund av dålig data. Det kostar Tenex-projekt eftersom det i slutändan för de flesta företag handlar om att rensa upp dessa data manuellt. Återigen, som Dez sa, är det verkligen besvärande. Specifikt, kring kapitalförvaltningen själv och generellt över IT-projekt, konstaterade Gartner i princip att över 40 procent av alla IT-projekt misslyckas på grund av dålig data. Vi vet roten till problemet. Det är uppgifterna. Hur börjar vi hantera det? En av de saker som pågår är att ITAM blir viktigare än för organisationer av mer än bara en anledning - uppenbarligen det vi just pratade om och det är att vi måste få system som pratar med varandra. Vi måste förstå var systemen finns i vår organisation, så att vi kan göra enkla åtgärder som uppdatering eller uppgraderingar till bara de system som vi har på plats. För att ytterligare förbättra problemet i dagens miljö hittar många av programvaruutgivarna och tillverkarna det, vad vi kallar vad det är, låghängande frukt för dessa utgivare genom att komma in och helt enkelt tvinga klienter till en granskning eller göra upp. Bokstavligen 63 procent av Fortune 2000 genomgick åtminstone en enda revision 2015 enligt oberoende forskningsföretag. Dessa revisioner kostar företag i enorma mängder interna avgifter och extern uppräkningskostnad var som helst från hundra tusen till en miljon dollar, och Gartner kom väsentligen ut med en annan intressant statistik som inte finns i min presentation, men jag tog upp det tidigt här på morgonen att de betraktar den genomsnittliga kostnaden för en revision på någonstans runt en halv miljon dollar för en organisation. När vi talar om att 25 procent av de dollar som spenderas i IT slösas bort, är detta några av de exempel som pågår. Jag tror att fakta i alla dessa, så vad gör vi? Hur hanterar vi detta? Det börjar med att verkligen förstå vad denna resa är för de flesta organisationer. IT-tillgångshantering är en serie steg som i princip börjar med att upptäcka vad jag har fått på mina nätverk. De flesta har ett eller några eller många av dessa upptäcktsverktyg, troligen är ett av de vanligaste upptäcktsverktygen på marknaden SCCM. De flesta företag som har någon nivå av Microsoft- och Windows-centrerade miljöer använder SCCM för många ändamål, distribuerar applikationer och kan också användas för att ta bort data, men dessa data kommer tillbaka i ett lerigt rörigt format. Vi kommer att prata om det mer på bara en minut. Det finns många andra verktyg också. De flesta av ITSM-lösningarna, oavsett om det är BMC eller Service Now eller Nationale eller HP, har mycket bra upptäcktsverktyg och de kommer ofta in i spelet när du särskilt försöker samla informationen och beroendeförhållandet mellan dina servernätverk och nätverksenheter, eftersom det sista vi behöver är en situation där bokningssystemet för ett stort flygbolag går ner mitt på dagen och miljoner om inte miljarder dollar av intäkter går förlorade. Att förstå hur alla dessa saker är anslutna börjar igen genom att förstå tillgångarna som är associerade med det. Det andra steget eller det andra steget i denna process - jag fick alla dessa uppgifter, men vad betyder det och hur kan jag börja arbeta med det? Det steget kallas vanligtvis normalisering och det är det som vi kommer att fokusera på mycket idag, eftersom det i sin kärna är det enklaste och viktigaste steget för att gå mot en helt optimerad eller fullt mogna ITAM-resa. När du går igenom den processen för normalisering är det du försöker att i slutändan dra ihop alla olika upptäcktskällor du har och några av dessa kan helt enkelt vara applikationer och lösningar som vi talade om i en av de tidigare bilderna. Vi vill dupliceras. Vi vill minska allt surr och filtrera bort all information som inte är relevant. Vi kommer att prata om det mer när vi går. Därifrån är några av de logiska stegen ovanpå den låghängande frukten. När företag samlas och slås samman och går ut och förvärvar andra organisationer, börjar de utveckla dubblering i applikationerna som de använder. Ett mycket typiskt steg som människor tar när de förstod och landskapet med mjukvara och hårdvara som de har är att rationalisera eller ta bort dubbletter, redundanta enheter och redundant programvara i sin miljö. Till exempel kanske du upptäcker att om du går ut och tittar, kan du ha så många som tjugo eller tjugofem olika BI-verktyg som används i hela din miljö. De potentiella besparingarna där för ett företag att ta bort inte bara de som är associerade med specifika applikationer utan ännu viktigare de som har bredare räckvidd erbjuder enorma kostnadsbesparingar och potentiell riskreduktion. Vad gör organisationer? De tittar vanligtvis på dessa i en stor detalj och som Dez sa, fick du en massa kroppar kastade på det och de börjar räkna ut vad de behöver göra och hur fick de detta optimerade tillstånd, och jag såg att detta händer tid och igen. Jag har arbetat med hundratals företag under den bättre delen av det senaste decenniet med deras programförvaltning, och i slutändan vad som stoppar de flesta av dessa projekt eller vad som får de flesta av dessa projekt att misslyckas är att de försöker bita mer än de kan tugga och de tar inte tillbaka det till dess grundläggande rötter utan att i huvudsak skapa projekt som kräver enorma mängder förändringshantering, ledningstillstånd, utbildningsprogram och styrning som påverkar ett enormt utrymme i hela deras miljö. När du sätter dig ner med programmet eller ett projekt som de visar framför en ledande befattning ställs ofta frågan: "Är problemet verkligen så stort?" När jag har diskuterat detta mer detaljerat med många ledande befattningshavare säger de: ”Du vet, Tom, det kommer verkligen till tre saker för mig. Jag vill veta vad vi har. Jag vill veta att vi använder det vi köper. Det viktigaste av allt är att jag vill veta att det vi använder och vad vi distribuerar matchar det jag köpte. Med andra ord: "Har jag rätt till det jag använder eller har jag fått mig till ett piratkopiering om än inte avsiktlig piratkopiering? ” Dessa tre frågor kan faktiskt besvaras mycket enkelt genom att gå tillbaka och bara rensa upp data. Det är vad vi ska visa dig resten av vägen. Låt oss titta specifikt på uppgifterna och vilka problem som är av dessa upptäckta uppgifter. Det är irrelevant. Det är felaktigt. Det är inkonsekvent. Det är ofullständigt och i slutändan kostar det företag att överstiga 14 miljoner dollar årligen i dåligt beslutsfattande. Här är ett exempel på den typ av data som du kommer direkt ut ur ett upptäcktsverktyg som SCCM, det innebär en enorm mängd bokstavligen irrelevant data. I själva verket är 95 procent av uppgifterna irrelevant. Det inkluderar saker som körbara filer, korrigeringsfiler och snabbkorrigeringar och firmware och olika språkpaket och kunskapsbaspaket. Ett bra exempel är att ta en titt i inventeringen på en typisk dator i din miljö, leta efter något från Adobe. Ofta kan Adobe Acrobat ha en licensierbar kopia på din dator, men ändå kan det vara så många som nio eller tio av dessa kopior eller uppgradera kopior. Så med blotta ögat är du inte säker på om du har ansvar för nio olika kopior eller bara en produkt. Ett av de andra områdena, så att säga, är den inkonsekvens som sker. Detta är bara ett kort exempel på hur Microsoft kan namnges så många olika saker i en organisation. Detta är ett fokuserat område för BDNA. Jag tror att ett av de mest uttalande exemplen som vi kan ge är att precis runt ämnet SQL har vi funnit 16 000 olika varianter av hur SQL kan namnges i en inventering över hela vår kundbas. Överväg att sätta upp det på en konsekvent grund. Ett annat område är grundläggande brist på standarder. Till vilken nivå databas släpps, till vilken nivå av CAL, PV användning, av IBM kommer vi att hantera dessa data? Så detta är en del av svårigheterna och frågan om att hjälpa till att normalisera alla dessa råvaror, alla dessa rådata till en punkt där de är användbara. Tillsammans med det finns det en enorm mängd data som inte kan upptäckas, vilket också skulle vara mycket värdefullt för någon i en traditionell ITAM-miljö. Vi ger dig några exempel på det när vi fortsätter när vi täcker vissa användningsfall. Det enda som säkert är utan tvekan är det faktum att dessa data förändras dagligen. Om vi bara tittar på Microsoft ensam, introducerade Microsoft 2015 över 3 500 nya mjukvarutitlar och uppgraderade eller uppdaterade 9 800 olika programvara. Det är 14 000 förändringar bara hos Microsoft. BDNA hanterar detta dagligen. Weve har ett team av ingenjörer som håller uppe med detta och bokstavligen gör några ord på upp till en miljon förändringar i vår masterordbok och encyklopedi. Vi täcker det här mer i detalj när vi går.I slutändan tittar vi på den miljön som vi tittade på tidigare och oförmågan för alla dessa olika lösningar att prata med varandra är definitivt en fråga och det är där BDNA kommer på plats och BDNA-plattformen och dess kärnkomponent Technopedia tillåter oss att skapa en gemensam dataplattform. Hur det sker är faktiskt ganska enkelt. Vi samlar data som kommer från ett antal av dina olika upptäcktskällor. Dessa upptäcktskällor kan vara några av de som jag nämnde tidigare som SCCM eller ADDM eller HPUD. Det kan vara den här saken CMDB. Det kan faktiskt också vara de beställningssystem som du har från dina upphandlingssystem. Vi samlar det och vi tittar på kärnkomponenterna i hur saker listas och rationaliserar det och normaliserar det. Återigen, det är något som BDNA kallar Technopedia. Technopedia är världens största uppslagsverk av IT-tillgångar. Det används av några andra tjugo andra applikationer över hela världen utanför bara BDNA-användning för att skapa ett gemensamt språk igen. Verktyg som arkitektoniska verktyg, upphandlingsverktyg, verktyg för servicehantering - återigen idén är: "Låt oss tala ett vanligt språk på alla våra IPV: er." Vi lägger sedan till de specifika titlarna, 1,3 miljoner poster över 87 miljoner attribut. Dessa attribut kan vara något så enkelt som "Vad är hårdvaruspecifikationerna eller specifikationerna kring den enkla servern? Vilka är de fysiska dimensionerna? Vad är energiförbrukningen? Vad är energiklassificeringen? Vad använder VP av värme som genereras av alla saker som kan användas av våra arkitekter? " Det är bara ett exempel på många olika katalogtillägg som finns tillgängliga. Vi tar dina data. Vi förvärrar det. Vi kartlägger det i huvudsak, normaliserar det mot Technopedia-katalogen och levererar en normaliserad uppsättning data som sedan kan konsumeras i resten av din miljö. Vi matar in det i ett datalager internt som vi visar dig på bara några minuter, men vi har också standardintegrationer i många CMDB, ITSM och ytterligare verktyg som används över IT-miljön för att hjälpa dessa lösningar att bli mer värdefulla för du. Ett enkelt exempel på några av innehållspaketen, prissättning, hårdvaruspecifikationer, livscykel och support är förmodligen det vanligaste som ger dig saker som slutet av livet, slutet på support, virtualiseringskompatibilitet, Windows-kompatibilitet, och igen, Chris kommer att täcka några av det när vi rör oss. I en ny tecknad film som jag plockade upp, en Dilbert-tecknad film, hade han faktiskt blivit ombedd av sin chef att göra exakt samma sak. Så "Dilbert ger mig en lista över tillgångarna i vår organisation." Dilberts svar var: "Vem kommer att använda det om jag levererar det?" Användningen av IT-tillgångshanteringsdata, som vi talade om, kommer framöver här verkligen att nå en enorm mängd användning i hela din organisation. Detta är bara ett litet urval av olika discipliner inom en IT-organisation och hur de skulle använda det. Verkligheten är att det driver värde i organisationen och genom att ta några av de bästa autoritativa företagsdata hjälper BDNA i huvudsak företag att driva bättre affärsbeslut. När du går och sätter dig ner och letar efter ett förenklat sätt att hantera din ITSM-lösning, är vad BDNA i slutändan hjälper dig att driva enkelhet genom att rensa upp data och ge dig möjlighet att fatta bra affärsbeslut, och vi gör det snabbt. De flesta av våra kunder - faktiskt nästan 50 procent - har berättat för oss genom oberoende forskning att de fick en full ROI på sitt projekt på mindre än 30 dagar och bokstavligen 66 procent fick över 200 procent avkastning på det första året. Det är den typ av statistik som din CFO och din CIO säkert vill höra om du funderar på sätt att investera och förbättra din organisation. Vad vi ska göra nu är att jag ska överföra saker till Chris. Vi har fått en bättre andel av tretton eller femton minuter, vad vi ska göra är i huvudsak att gå igenom vissa användningsfall som är kritiska och några som vi talade om tidigare, i princip vad har jag installerat. Du har möjlighet att se vad jag använder så att de kan skörda dem igen. Är jag kompatibel med vad jag har installerat? Jag kanske vill titta på vilka enheter som är över tre år eftersom jag vill veta om jag kan uppdatera enheterna. Vilken mjukvara finns på dessa enheter så att jag kan planera för den uppdateringsprocessen? Och om jag vill ta en titt på säkerhetsrisken specifikt, vilka potentiella programvarukomponenter har en livslängd som antingen har överskridit eller kommer någon gång under de kommande trettio dagarna eller inom nästa år? Och vilka kan vara listade på National Institute of Securities Vulnerability List? Eric, vad jag vill göra nu är att skicka tillbaka det till dig, och om du skulle göra det, kan du snälla överlämna saker till Mr. Russick? Eric Kavanagh: Jag kommer att göra det, och Chris, du borde ha ordet nu. Gå vidare och dela din skärm och ta bort den. Chris Russick: Excellent. Tack, Tom. Tack, Eric. Jag uppskattar det. För vår demo idag skulle jag vilja presentera dig BDNA Analys. BDNA Analys är rapportsektionen för våra BDNA-produkter. Låt oss börja svara på några av de frågor som Tom tog med sig till bordet. Vad har vi? Vem använder eller använder vi våra produkter? Vad har vi rätt till och är vi säkra? Den första, låt oss prata om Microsoft-produkter, vad har vi installerat och för det kommer jag att börja med att överföra vårt program för installation av programvara. Därefter kommer jag att komma in och filtrera ner mjukvarutillverkare till Microsoft. Därefter kommer jag att överföra programvarunamnet för en fullständig introduktionstradition och låt oss bara börja med den stora versionen. Återigen är detta i grund och botten Microsofts lagerställning i både licensierbara och icke-licensierbara produkter. Där gummi möter vägen kommer verkligen att vara licensierade produkter. Låt oss filtrera ner det ytterligare till licensierbara produkter. Vi kommer att börja med att svara på vad som var, återigen vad vi började, vad är Microsoft-produktflödet. Det är en dyr titel och säga när den senast användes och av system och försök att återkräva vissa av dessa licenser genom att göra en mjukvara återuppskörd. Så nästa gång kommer vi att komma till sist använda, år, och vi kommer att filtrera det. Jag väljer 2012 och 2014. Jag tar också in SCCM: s uppmätta data. Vad vi kan göra just nu är att föra över till det senaste programvaran som använts. Slutligen kan vi komma till värdens namn och ta över det och vi kommer också att ta över den senaste fullständiga användarinloggningen. Från den här rapporten kan du helt enkelt gå till Mr Acme-användare och fråga dem: ”Ska du använda Microsoft-produkten i år? Det verkar som om du inte har använt sedan 2013. ”Exemplarrapporten konstaterade att det deltog i den och du kan återkräva licenserna. Nästa gång kommer jag att hoppa över till vår programvarukompatibel instrumentpanel. Jag har den här förinstallerade och den här innehåller till exempel Adobe - vilket program vi redan är kompatibla med och som vi inte följer och finns det en uppskattning av vad som ligger under dem med de frågor som Tom hade tagit upp tidigare . Baserat på din inköpsorderinformation och med den upptäckta informationen vi har in, finns det programvarutitlar, din rätt räknas, vad kostnaden är för det, vad som är installerat och om du är under eller inte. Genom att titta på denna rapport kan du svara på många av dessa frågor. Nästa jag vill hoppa över till är hårdvaruuppdateringen. Avsikten här är att bestämma vilken hårdvara som är föråldrad, vad som är mer än tre år gammal eller fyra år gammal, oavsett vad din organisation anser är viktig. Gå helt enkelt till ditt systemantal. I det här exemplet kommer vi att fokusera på stationära datorer. Jag kommer att komma hit till informationen om mjukvaruprodukter och vi tar in kategori, underkategori, och vi kommer bara att behålla stationära datorer. Härifrån tar vi över produktinformation, tillverkare och modellinformation. För dagens exempel kommer vi att fokusera på 790-talet. Anledningen till att jag behöver göra detta är för att vi vet att de är mer än tre år gamla men vi tar över hårdvara GA här. Om du ville hitta denna GA här, kan du säkert komma över den för alla hårdvaruunderkategoriprodukter. Slutligen, om du ska göra en uppgradering eller uppdatera till dessa enheter, hjälper det att ta reda på vad dessa enheter är. Återigen kan vi komma till värdnamnet och sedan är det bra att förstå vad som är installerat på dem. Så vi har ett mjukvaruinstallationsantal och det är här rapporten blir stor. Vi måste ta över programvarutillverkarna, mjukvarunamn och slutligen programvaruversion. Vi behöver inte en hårdvarukategori och en underkategori, så vi kan spara lite utrymme här. Här är en lista. Så för närvarande förstår vi att på den här värden har vi dessa produkter som måste uppgraderas som en del av hårdvaruuppdateringen. Just nu måste vi veta vad som är kompatibelt med operativsystemet så vi kommer att få en mjukvaruavtal. Det kommer att vara programvara Windows beredskap 64 bit. Vi ska gå till en 64-bitars miljö. Just nu har du verkligt handlingsbara data - vad som är installerat på vilken värd - men du måste uppgradera baserat på GA-data och dessutom kan du se om det är kompatibelt eller om det måste vara kompatibilitetskontroll eller helt enkelt inte kompatibelt. Detta ger dina team, vem som än kommer att göra detta, hur detta uppdaterar värdefull information och sparar tid på lång sikt. Slutligen, för säkerheten, finns det två säkerhetsdelar. De är oerhört hjälpsamma när man talar om hårdvara och mjukvarutillgångar och produktionsmiljöer. Först är slutdata. Visst vill du att alla dina korrigeringsfiler uppdateras och dina programvaror slutför livslängd upp till den senaste versionen av uppenbara skäl. Så vi kommer att ta itu med det först. Återigen börjar vi med mjukvaruinstallationsräkning. Vi kommer att ta över hela din miljö. Vi tar över din programvarutillverkare, programvarunamn och större version igen. Nästa vad vi ska göra är att komma ner och begränsa livslängdsdata till programvaran slutet av livstid. Vi kommer att föra omfattningen till detta. Vi kommer att göra det aktuella året - det föregående, säger vi två år och de kommande två åren - så vi kommer att göra en femårsskanning. Avsikten här är att svara på frågan om: "Vad behöver vi uppgradera i år? Vad borde vi ha uppgraderat under de senaste två åren? Och för att ligga före spelet, vad behöver vi planera för de kommande två åren? ” Vi tar med oss denna information och lägger dem över toppen med den uppdateringen. Rätt utanför fladderträdet kan du se att det 2014 finns 346 installationer av det som ser ut som BlackBerry-programvaran, personlig vDisk från Citrix, det finns 25 osv. Så det här är en bra rapport. Återigen vill vi gå igenom alla stegen, men du kan säkert bara välja skrivbordsprogramvaran eller "Keep Only" och sedan ta reda på dess värd där den är installerad. Du kan exportera dessa data till en CSC, PDF eller Excel. Därmed kan CSC ta med det till andra produkter också om du vill göra några uppgraderingar på ett automatiserat sätt och ur ett kundperspektiv kan du se exakt vad som måste göras i framtiden. Slutligen, en annan rapport som jag har skapat i vårt system använder BDNA Analys. Det är en systemrapport baserad på specifika CVE: er från NIST-databasen, National Institute Standards and Technology. Vad jag har gjort här är att jag riktade Apple iTunes och utropade specifikt några CVE under 2015 och jag har försökt skapa en rapport som letar efter den specifika versionen, hur många system vi har installerat och hur många system som påverkas och hur många mjukvarukomponenter som installeras baserat på dessa CVE: er. Återigen är det ett bra verktyg om du försöker få (ohörliga) saneringspunkter eller helt enkelt hjälpa till i säkerhetsavdelningen att bättre hantera sina IT-tillgångar och inventeringen. Just nu vill jag lämna tillbaka det till Tom och Eric för frågor och svar. Eric Kavanagh: Låt mig få fram analytikerna först och främst, Dez och Robin. Jag är säker på att du har några frågor. Det var förresten en fantastisk demo. Jag känner mig bara förvånad över hur mycket synlighet du kan komma in i den här miljön. Låt oss inse det, i detta riktigt heterogena ekosystem är den typen av synlighet vad du behöver ha om du ska förstå vad som händer där ute och om du kommer att möta en revision, vilket naturligtvis ingen vill göra , men Dez, jag antar att först ska jag överlämna det till dig för alla frågor du har. Dez Blanchfield: Man, jag kommer att gå i rutan själv eftersom jag bara kunde tillbringa dagen med att prata med dig om detta. Det är ett par saker som har kommit till mig genom frågor och produkter som jag också kommer att få till om du inte har något emot. Detta påminner mig om att skärmarna som du visar mig påminner mig om vilken typ av projekt som jag skulle ha älskat att prata om där vi bara gjorde en uppdatering av nitton-udda tusen maskiner för ett företag som heter Data EDI genom deras (oudläsbara) division och andra områden, och jag kan offentligt prata om det eftersom det är ett öppet projekt. Vad jag hittade var att det fanns tre separata skrivbordsuppdateringar och SOA-uppdateringar kördes parallellt av någon anledning och jag slutade bara att stoppa dem alla och börja från början med ett automatiserat verktyg. Vi pratar om skala och jag kommer tillbaka till dig med en fråga om en sekund. När vi gjorde något i den skalan, vad som hände var att jag kom ut från ingenjörsteamet och från CIO: s kontor och jag gick runt resten av verksamheten och sa: "Vi gör en granskning av allt i den här organisationen från skrivbordet ner. Vad vill du veta om det? " och ingen ställde egentligen några frågor. Så nu har jag några märkes-X-sessioner där jag fick dem i ett par styrelserum och sa "Låt mig bara ställa frågan igen." När det gäller ekonomi, låt mig veta berätta för varje programvara där du måste rapportera hur mycket vi betalar för och vad den typen av får slutet på livet och när du kan skriva det som dess off. Kan du få den till PNL och GL? Var är din kapitalförvaltning kring detta och hur hanterar vi budgetering för licensiering av programvara för nästa år? Glaserade ögonbollar, och jag gick igenom alla andra grupper, så jag är angelägen om att få lite inblick i vad du har sett på dessa platser där du uppenbarligen har ett fantastiskt verktyg som gör enorma mängder kraftfulla saker över bara kapitalförvaltning och tillgångsupptäckt. Vad är din reaktion på sådana scenarier där du har drivit ett projekt där du har fått en klient som har drivit ett projekt och plötsligt är det ekonomi och teknik och dev ops och säkerhet och efterlevnad och massor av saker och till och med lite skugga IT-miljöer poppar och säger: "Vi hade ingen aning om att det här var här och hur får vi tillgång till uppgifterna?" Jag skulle gärna höra om alla slags eureka-ögonblick för organisationer du har haft och vad de har gjort åt det. Tom Bosch: Jag kommer att kasta i en, Dez. Jag tror att det vi ser gång på gång, killar, finns det uppenbarligen alltid en startpunkt, eller hur? Det finns en grupp i en organisation som säger "Jag behöver skärmdata för ett användningsfall." Varje lösningsleverantör, det är vanligtvis där den kommer in och jag skulle säga förmodligen 65 eller 75 procent av året, ingångspunkterna för oss tenderar att vara runt kapitalförvaltning. De tenderar att vara runt IT. Vi är inte ett ITAM-verktyg. I slutet av dagen är det vi är ett datahanteringsverktyg. Vi matar ITAM-lösningar som de som finns inom tjänsten nu och andra mer komplexa lösningar som Sierra och Snow. I slutet av dagen, vad som börjar hända är när rena data har använts och presenterats i andra IT-organisationsmöten, människor går, “Var fick du det? Åh, det kom härifrån. ”” Verkligen? Kan jag ta en titt på det? ”Sedan när de upptäcker att du kan börja knyta till eller förbättra tillgångarna med ytterligare innehållsdata och det är något som är väldigt, mycket unikt för BDNA, är det när" aha "-stunderna börjar öppna sig . Så en av orsakerna till att vi gillar att visa säkerheten är att Verizon gjorde en studie för ett par år sedan och i princip kom de tillbaka och sa: "99,9 procent av alla hacks som finns i miljön kommer in genom programvara . De är föråldrade, har inte lappats och / eller är slut på livet. ”De flesta av dem är någonstans mellan tre månader och ett år föråldrade eller ur livet. Genom att ha den informationen i förväg kan säkerhetsavdelningarna nu vara proaktiva i sin strategi för att förhindra brott. Chris, har du något att presentera från dina resor? Chris Russick: Absolut, så vi spikade alla slags ett par historier tillsammans och pratar om hur de två "aha" ögonblicken är. Vi försöker förstå var de hämtar informationen från och många kunder inser inte bredden av data som finns tillgängliga där ute, oavsett om det kommer från en SCCM eller Casper, eller så väljer du verktygen. Avsikten där är att kunna få bra data från alla dina verktyg. Hur aggregerar du det, rätt, utan BDNA, och kanske det första "aha" ögonblicket är, "Wow, vi kan ta alla dessa data som vi har, aggregera dem tillsammans." Det är förmågan för människor att fatta verkligt handlingsbara beslut baserat på uppgifterna snarare än att försöka hitta stödjande information i uppgifterna för att stödja beslut som de redan har fattat. Jag hade en kund uppe i Tennessee-området som bokstavligen när de kunde utföra detta, jag tror att det var som om en vecka som de hade installerat detta, bokstavligen dansade på skrivbord och bås eftersom de inte visste det fulla andetaget av deras data och nu gör de det. Tillbaka till er. Dez Blanchfield: Berikningen är intressant för mig. Bara snabbt på det och sedan överlämnar jag det till Dr. Robin Bloor. Jag gjorde mycket arbete med banker och förmögenhetsföretag och det finns ett par viktiga saker som de gör sig själva regelbundet i sitt försök att hålla sig uppfyllda för de utmaningar som känner till din klient eller KYC. Det finns anti-penningtvätt, AML. Det jag tycker är dock många av dessa organisationer när de blir bra i KYC-processen och deras klientprocess, ofta än inte, tittar inåt och behandlar sig själva som en klient och jag ser att många av dem nu använder inte djupet att du kom hit men mycket hög nivå verktyg för att försöka kartlägga vem deras slutanvändare är med klienten och vad de använder på grund av anledningen till att du pratar om. Vissa människor har bara BYOD, andra har gamla versioner av programvara. De tar alltid dåliga saker med sig på jobbet. Har du haft specifika exempel på personer som tar de uppgifter du har fått på en tillämpad server på vilken resa du har haft och i vilken process de tar upp innehållet och matar dem till något annat? Det är kanske en kartläggning av vem som faktiskt använder systemet i första hand och vem som kartlägger det, till exempel HR som använder systemet som faktiskt är anställda och som ska vara i byggnaderna och andra exempel på hur något är i butik, hur finns det något i maskinen som de inte borde ha och hur man kan fånga in det igen? Har du några exempel där en annan del av verksamheten som du traditionellt inte skulle tro att skulle få värde ur uppgifterna har tagit en delmängd eller fått tillgång till dem och involverat dem att få ett till synes oberoende värde som de såg komma ut ur detta jobb? Chris Russick: Jag skulle vilja hoppa på den här först. Jag har nyckelkunder som jag tänker på specifikt. En ligger på sjukhus i ett medicinskt fält och de gör exakt det. Vi tar några berikningsdata mot deras upptäcktsdata genom att hämta in Active Directory, och sedan vet de vilka tillgångar som faktiskt hör till deras nätverk. Därifrån kan de bestämma vem som ska och inte bör lappas, vem som ska och inte ens ska vara i sitt nätverk och sedan hålla en lista över deras skrivbordstillträde och vad som inte. Den andra är faktiskt specifikt ett par olika kunder eller specifikt ta dessa data och jag har aldrig varit i företagets arkitekturvärld så det är relativt nytt för mig under de senaste två åren men det finns ett helt användningsfall för att kunna ta vår livslängdsdata eller andra tillgångsanrikade data och pumpar det ut i andra företagsarkitekturverktyg som kommer att göra företagskartläggningen och saker som företagsarkitekter gör och ärligt talat det är en del av branschen som har blivit mycket populär bland uppgifterna och Det har jag aldrig sett förut. Tom? Tom Bosch: Jag tänker att lägga till två användningsfall som jag tror har dykt upp ganska snabbt är både typ av och i HR. I grund och botten hjälper de att förstå vad de interna anställda i företaget använder - och jag tycker alltid att det är fantastiskt när klienter kommer tillbaka och det händer bokstavligen varje gång de kör förmodligen sin första normalisering är att de förmodligen kommer att hitta ett bra exempel på tolv eller fjorton olika Xbox-enheter som är anslutna till nätverket, som vanligtvis inte är sanktionerade enheter i affärsmiljön såvida du inte arbetar på Microsoft. Hitta enheter som inte borde vara i miljön, hitta programvara som inte borde vara i miljön och för det andra har jag sett HR snabbt använda detta för att värdera de investeringar som de måste göra i ombordstigningsprocessen med en ny anställd. De hade ingen aning om att den genomsnittliga anställda kanske var någonstans i närheten av 2500 till 3 000 dollar programvara och överstiger 5 000 dollar bara IT-investeringar. Dez Blanchfield: Detta är ett annat användningsfall. Det är inte så mycket en fråga. Det är bara en punkt att kasta ut för att dela. Jag har haft scenarier där vi har haft mycket, mycket stora granskningar av en miljö. Vi hittade arvssystem som folket ursprungligen satte dem på där människor som underhåller dem hade gått vidare och noterar att det är dokumenterat och noterar att det har kartlagts. I ett fall fann de en ståltillverkare som hade en gammal grupp av 486 stationära datorer anslutna till modem som brukade ringa upp till banken varje dag. Den här organisationen var en stålbiltillverkare på flera miljarder dollar här i Australien och de insåg inte att dessa 486 datorer gjorde (ohörligt) till bankuppringningen varje dag. Den andra, desto mer intressant, var det i en tågbyggare som tillverkar lagermiljö. De hade ett system som de trodde var en simulator för tågövervakning. Det visade sig att det faktiskt var live-systemet på en gammal AIX RS / 6000 IBM-maskin och lyckligtvis dör de sakerna bara för nästan ett decennium stötte ingen av de anställda som hade implementerat den, och hade faktiskt lämnat avdelningen efter stängs av, och de hade faktiskt börjat det köras. Tågen som kör runt på platsen och med den här saken pratar och fångar övervakning, men jag tror att det finns riktigt intressanta användningsfall som ganska ofta människor som ser fram emot kommer att ha en tendens att tänka på att om de börjar se bakåt ser de några väldigt intressanta saker också. Med det kommer jag att lämna tillbaka det till Robin eftersom jag tror att jag har tagit för mycket av din tid. Eric Kavanagh: Robin, ta bort den. Robin Bloor: Så vi har lite slut på tiden, så jag menar att en av de saker som intresserar mig är att köpa en produkt som denna - om du kan tala med det här, hur många som kommer till dig eller kommer till den här produkten, eftersom de har ett mycket specifikt problem på händerna? Hur många kommer faktiskt av strategiska skäl eftersom de bara inser att de faktiskt borde ha något liknande, eftersom det de faktiskt har är fragmenterade eller värdelösa. Det är en del av frågan. Den andra är, efter att ha antagit denna mycket specifika taktiska anledning, hur många människor gör det strategiskt då och då? Chris Russick: Det är en fantastisk fråga, Robin. Jag menar att jag tror att det är mänsklig natur att vara reaktiv. Jag måste säga att 95/100 gånger när kunder kommer till oss, reagerar det på en situation som har fått dem att skaffa en lösning. Den som helt enkelt driver företagens nötter i dag är revisionsprocessen. Jag har bokstavligen hört talas om kunder som fått räkningar från mjukvaruförsäljare på över en miljard dollar före revisionen och du kunde bara tänka dig vad en CIO eller CFO säger när de ser det. "Hur kunde detta ha hänt och varför har vi inte bättre kontroll över detta?" Människor blir mycket reaktiva på det. Nu kan jag också säga att i vissa av dessa situationer, när de väl har fått hand om vad de faktiskt hade, visar det sig att leverantörerna var lite aggressiva i sin inställning till vad de trodde var i miljön. I flera speciella fall har jag sett att kunderna går från mycket, mycket stora beräkningar av förhandsgranskningen till att inte ha skyldat leverantörerna några pengar alls. Mycket av det har att göra med att se till att de rensar upp dessa data och gör det på ett sätt som är systematiskt och standardiserat och standardiserat. Det finns många företag som försöker närma sig det här från en manuell process. Det konsumerar att traditionella revisioner tar ungefär tusen till femtonhundra man timmar att förbereda. Så vi kommer verkligen ner till frågan. Jag tror att många företag kommer till oss, majoriteten kommer till oss med ett hett problem. Då tror jag i slutändan när de blir mogenare i sin förståelse av vad de har och om de kan använda det, blir det mer strategiskt. Det är en av BDNA: s regler. När klienten hade gjort investeringen är att se till att de förstår och utnyttjar den investeringen över hela sin verksamhet. Eric Kavanagh: Låt mig kasta en sista fråga till dig eftersom det uppenbarligen finns existerande verktyg där ute i vissa organisationer och någon har redigerat mig just nu - finns det en naturlig process att migrera från flera system som redan finns för att använda din BDNA-lösning som en enda källa av sanning, så att säga. Hur ser det ut? Hur lång tid tar det? Det låter ganska utmanande, men du berättar. Tom Bosch: Chris, låt mig göra en snabb kommentar så kan du prata om den tekniska sidan av det, eller hur? Vi har sett klienter med så få som en eller två upptäcktslösningar för så många som 25 och för att få dem alla in och samla dem - det är vad den normaliserade komponenten i det verktygssatsen gör. Hur vi gör det är verkligen en kombination av standardiserad anslutning. I vissa fall måste vi sedan bygga ut vissa kundspårare. Chris, kan du kanske upprepa det och förklara för dem hur vi gör det? Chris Russick: Absolut, tack Tom. Vi har 54 out-of-the-box-extraktioner som vi använder för att dra det inventeringen ned data från dina befintliga lösningar och vi har en mängd alternativ för att få in några hemodlade lösningar potentiellt om du har fått dem i Excel eller någon annan databas. Den aggregeringsprocessen är verkligen inte så lång tid att ställa in och stå ut fysiskt, två till fyra veckor och vi har fått dina lösningar konfigurerade och du får data inte så långt ner på vägen och därefter, men vad vi slutade gör är efter aggregeringen och dupliceringen vi kommer att begränsa dessa data, den goda rena uppgifterna till Technopedia och berika det. Slutligen kommer vi att pumpa in det i en SQL- eller Oracle-datakub och den datakuben är då det som pumpas ut till var du än ser de data eller igen till BDNA Analys som det du såg idag. Återigen, med fokus på att vi inte försöker ersätta var du får datan, vi försöker inte ersätta där data går helt enkelt kring duplicering och berikning och sedan data av god kvalitet. Jag hoppas att det svarar på frågan. Om inte, vänligen fråga gärna mer. Eric Kavanagh: Det låter bra, folkens. Vi har gått lite över tiden här, men vi har alltid velat ha en fullständig konversation och folket från BDNA skickade just den här listan här. Jag lägger den här länken i chattfönstret, och du kan se att det finns en hel del begriplig lista över olika kontakter som jag har fått där. Så folk måste jag säga er, vi kommer att samlas upp här. Vi arkiverar naturligtvis alla dessa webbsändningar. Du kan gå till InsideAnalysis.com. Det går vanligtvis upp nästa dag. Vi kommer också att vidarebefordra några av de detaljerade frågorna som folk skickat in till oss. Vi skickar det till högtalarna idag. Känn dig gärna ut till dem eller naturligtvis din riktigt, du kan slå mig upp på @eric_kavanagh eller naturligtvis genom, eller. Stort tack till våra vänner från BDNA. Stort tack till våra vänner på Marketry för att hjälpa oss att ge dig detta innehåll och naturligtvis stort tack till Techopedia och Technopedia, eftersom Techopedia är den mediepartner som vi har fått, en underbar, underbar webbplats. Gå till Techopedia.com och Technopedia är webbplatsen för folket på BDNA sammansatt. Så detta är bra material, folkens. Tack så mycket för din tid och uppmärksamhet. Vi har många webbsändningar som kommer att komma de närmaste veckorna. Förhoppningsvis har du inte något emot att höra min röst för mycket. Med det kommer vi att säga dig farväl. Tack igen och vi pratar med dig nästa gång. Var försiktig folkens. Hejdå.