Als we praten over innovatie van beheer, hebben we het meestal over vernieuwingen van de beheerde systemen zelf of van de organisaties die het beheer doen. Migraties naar nieuwe technologieën, outsourcing, out-tasking, off-shoring, etc. Voorbeelden van innovaties met een beheerd systeem als onderwerp. De omgeving waarin het beheer plaatsvindt, komt echter niet vaak in aanmerking voor vernieuwing. Zo komt een nieuw, efficiënter en goedkoper, versiebeheersysteem vaak pas in aanmerking als het beheerde systeem gemigreerd wordt naar een ander platform of als de regie voor het systeem overgedragen wordt aan een andere partij.
Gedurende een periode van beheer wordt echter niet of nauwelijks gekeken naar innovaties van de tools, de processen of de methodiek en dat terwijl het gonst van de innovaties in die gebieden. Microsoft komt tegenwoordig bijna ieder jaar uit met een nieuwe ontwikkelomgeving, nieuwe processen tonen steeds meer efficiëntie aan en integraties tussen de verschillende disciplines van een methodiek worden steeds serieuzer bruikbaar. En dit geldt niet alleen voor omgevingen waarin nieuwe systemen worden ontwikkeld; dit geldt, tenminste dat zou zo moeten, vooral ook voor situaties waarin bestaande systemen worden beheerd.
Ter illustratie: er worden overal en nergens nog erg veel applicaties beheerd die gebaseerd zijn op het zogenaamde Visual Basic 6-platform van Microsoft, dat in 1998 voor het eerst uitkwam. De meeste van deze applicaties worden anno 2008 nog steeds beheerd met behulp van de oorspronkelijke ontwikkelsoftware. Negen van de tien keer worden ook dezelfde processen van toen nog gehanteerd. Efficiëntie is enkel gebaseerd op de jarenlange ervaringen van het beheerteam, maar dat kan factoren beter maken als bijvoorbeeld gebruik gemaakt zou worden van noviteiten als een webinterface voor issue tracking, automatisch testen en promoveren van de software, agile-processen, etc. Zaken die we als ‘gewoon' bestempelen bij ontwikkeling van nieuwe systemen.
Beheeromgevingen moeten zelfs vooraan staan bij het toepassen van innovaties. In een beheeromgeving heb je een beter beeld van de huidige benchmarks en heb je minder te maken met de intrinsieke innovatie van een nieuw systeem. Misschien moeten we innovaties alleen nog maar op beheeromgevingen promoten en ze als commodity toepassen op ontwikkelomgevingen. Geeft de ontwikkelaar van een nieuw systeem ook meteen ruimte om zijn innovatieve aandacht volledig op dat systeem te richten, in plaats van te verdelen over het nieuwe systeem en de (volgende) nieuwe omgeving.
Weer mooie woorden uit de koker van de witte boordenfabriek. Kom eens uit de mooie ivoren toren en praat eens met de mensen op de werkvloer!
Bij je stuk komen meteen twee dingen naar voren.
1. Als het systeem na 10 jaar nog nog steeds goed werk met de goede processen. Waarom zou je het dan helemaal op de schop gooien als dat niet nodig is. Don’t fix if it ain’t broken! En als het dan wel gemigreerd wordt, doe het dan meteen goed en upgrade dan meteen naar een up-to-date versie.
2. Komen we gelijk bij punt 2. Als er dan geupgrade wordt dan gebeurd dat meestal door de persoon met de meeste ervaring met het programma en de kennis van het processen. Of je moet natuurlijk eerst iemand inwerken in het oude systeem om toch de volledige innovatieve aandacht te krijgen van de ontwikkelaar met de meeste kennis. En resources zijn op dit moment schaars, tenzij je natuurlijk voor een niet nader te noemen grote Franse / Nederlandse detacheerder werkt….
Theoretisch een mooi verhaal, maar een praktijk een luchtkasteel wat waarschijnlijk sneller verdampt dan water in de woestijn. Keep on dreaming!
De reactie van “Martijn” bevestigt de stelling van de schrijver dat er te weinig aandacht is voor het innoveren van de beheer-omgeving. Kees stelt juist dat als een systeem na 10 jaar nog goed werkt, je misschien niets hoeft te doen aan innovatie op dat systeem zelf, maar dat dat niet wil zeggen dat de beheeromgeving niet mag veranderen. In het voorbeeld van VB6 in het artikel kan ik me voorstellen dat ik – op de werkvloer – het niet erg zou vinden verlost te worden van de Sourcesafe repository die 10 jaar geleden is ingericht, en dat de sources ondergebracht worden in het nieuwe Team Foundation Server; dat we op ook met het oude VB6 systeem meeliften met het proces van continuous integration (automatisch testen) waar de mannen verderop zoveel profijt van hebben; dat we Best Practices van nieuwe ontwikkelprocessen adopteren; …
Ach, het systeem zelf zou ook wel een poetsbeurt mogen hebben, maar wachten met innoveren op de omgeving tot er een case is voor migratie van VB6 naar Oslo/Azure/… vind ik, met Kees, niet wijs.
Wat mij betreft dus geen theorie, geen luchtkasteel, geen toren, en ook geen manier om schaarse of niet-schaarse resources aan het werk te krijgen, maar juist een Call for Action om ook bestaande systemen onder beheer gelegenheid te geven productiever te worden.
Ik zou niet weten waarom een beheerorganisatie afwijkt van elke andere organisatie en dus niet zou hoeven optimaliseren en innoveren. Uit concurrentie overweging is een beheerorganisatie net als elk ander dienstverlenend bedrijf genoodzaakt om kosten te verlagen en prestatie te verhogen. Dit geldt ook voor interne IT providers om outsourcing van beheer financieel onaantrekkelijk te maken. In praktijk blijkt het helaas vaak lastig om een goede business case te formuleren en te verkopen.
Ik vind “beheer” een hele brede term dat net als “management” ook keer op keer wordt gebruikt voor het aanduiden van andere doelgroepen.
Zelf zit ik in de Data Center beheer hoek en daar worden administrators bedolven onder de tools waarmee met hun omgeving kan “beheren” Denk dan aan nieuwe technologien als Diverse OS’en, Blades, Virtualisatie Netwerk devices, Power, etc
Dit is inmiddels zo’n wildgroei aan het worden dat de prijs van het beheer tov de aanschaf van hardware ongeveer 7:1 is (source IDC)En daar valt dus nog veel te kosten te besparen. Vele (grote) bedrijven hebben inmiddels tooling commissies ingesteld om dit te reguleren en zodoende een beter beeld te hebben van wat er nu daadwerkelijk wordt gebruikt voor het beheer. Binnen deze tools is er zeker een vorm van innovatie van technologieen, daar de industrie niet stil staat.
Wat ik mis in het verhaal en in de reacties die er tot nu toe staan en dat is wat “innovatie” eigenlijk is. Iets nieuws is niet per definitie iets innovatiefs en iets innovatiefs is niet per definitie iets nieuws. Deze termen worden ten onrechte door elkaar gebruikt. Vliegverkeer “aanvliegen” met het businenss model voor busreizen bracht ons de “prijsvechters” in de lucht. Beide niets nieuws maar als combi innovatief. Er kan pas sprake zijn van innovatie als het “idee” vermarkt kan worden en succesvol blijkt te zijn. Het “beste idee van Nederland” heeft dat ook weer laten zien. Prachtige ideeen maar vaak niet te vermarkten. ITSMF heeft jaren een innovatie award uitgereikt en deed dat ook een aantal jaren niet. Dit jaar werd EXIN verblijdt met de innovatie award en vorig jaar was dat Quint Wellington Redwood. Allebei organisaties in het Service Management werkveld. EXIN kreeg de award voor het certificeringsprogramma ISO20000. En dat heeft alles met beheer(processen) te maken. Vorig jaar werd OSMF ge?ntroduceerd, een “Open Source” beheer methodiek. Mogelijk gaat OSMF het gelijk nog krijgen en vind er daadwerkelijk een “innovatie” plaats van processen. Processen en Open Source: allebei niets nieuws maar als combi wel innovatief. Net als busreizen door de lucht.
Ik signaleer in mijn aandachtsgebied veeraleer een overvloed aan “innovatie” – of eigenlijk: wens om allerlei mooie, prachtige, nieuwe beheersoftware te implementeren. Vaak nog voordat de vorige producten ?cht goed zijn ge?mplementeerd. Natuurlijk moet er aandacht zijn voor innovatie van beheer, maar dan wel om de juiste redenen. Goede redenen zijn bijvoorbeeld verhoging van kwaliteit en/of effici?ntie en verlaging van kosten. Foute redenen zijn vaak vermomd. Te vaak ontbreekt een echt goede business case voor het invoeren van een nieuw beheerpakket en hierdoor wordt de implementatie ook een drama. Verleid door mooie GUI?s en beloftes van verkopers wordt besloten om dan maar nieuw pakket x aan te schaffen in plaats van de implementatie van pakket y te voltooien. Want met pakket x wordt alles beter. Terwijl vaak pakket y helemaal zo slecht niet is, maar door het ontbreken van een business case, goede architectuur en ontwerp en een breed gedragen implementatieplan gedoemd is tot mislukken.
Innovatie van beheer kan veel opleveren. In de praktijk komt het er echter niet snel van omdat nieuwe omgevingen/functionaliteiten sneller in gebruik moeten worden genomen en beheerd moeten worden dan eigenlijk wenselijk is. De omgeving van beheer vernieuwd regelmatig waarbij het beheer achter de feiten aanloopt. Zolang het management niet overtuigd is van innovatie binnen het beheer en beheer niet kan aantonen (kwalitatief en/of financieel) wat de baten kunnen zijn zal deze cirkel dus niet worden onderbroken. Waarom laten beheerders het eigenlijk zover komen ? Ik denk dat iedere beheerder voldoende punten aan kan dragen wat er allemaal beter kan maar op de een of andere manier zijn deze technische experts niet in staat het belang hiervan op juiste manier aan te kaarten bij het management. Wellicht dat een training “Effectief onderhandelen” in dit kader meer op kan leveren dan de zoveelste technisch georienteerde training.
Op zich is het begrijpelijk dat beheer zo’n moeite heeft met innovatie. Voor echte innovatie moet je immers durven loslaten, ruimte geven. Beheer is van nature gestructureerd, op voorspelbaarheid en continuiteit gericht.
Echter, zoals Aad terecht aangeeft, kan innovatie ook zitten in het slimmer of goedkoper doen van bestaande dingen, via creatieve combinaties of oplossingen. Beheer heeft immers uniek inzicht in de bestaande omgeving en de mogelijkheden voor innovatie, kostenbesparing en smart sourcing.
Toch blijven deze mogelijkheden te vaak onbenut. Soms door gebrek aan commitment op de juiste niveaus, geen budget, of misschien wel te weinig ondernemingskracht en verantwoordelijkheidsgevoel. Of een combinatie hiervan. Voorop staat dat beheer wel degelijk aan innovatie kan, nee, moet doen. Hoe dan? Door een pragmatische maar realistische business case te maken voor de gewenste verandering en deze door de Service Manager intern te laten verkopen. Eenvoudig? Zeker niet, probeer de business maar eens te overtuigen van de noodzaak voor migratie van Oracle 8 naar 10, dit gaat om serieus geld. De noodzaak is er, nu de uitvoering nog.
Hoog tijd dat beheer eens wat meer aan zijn eigen marketing gaat doen.
Zolang de IT-producenten er in slagen het stuurwiel en de pedalen steeds op een andere plek te plaatsen, zullen beheerders zich moeten aanpassen. We zijn dan altijd te laat. Er komt weinig van innovatie op beheergebied. Die wordt pas echt mogelijk als elementaire beheerfuncties onderdeel worden van de oplossing en er niet met veel moeite tegen aangeplakt. zie ook https://www.computable.nl/artikel/ict_topics/beheer/2726496/1277800/is-outofthebox-beheren-een-utopie.html
Innovatie vindt doorgaans plaats als er een probleem is wat opgelost moet worden. Dat kan ook zijn als iemand een droom heeft en het een probleem is dat deze droom nog niet is verwezenlijkt. Als de verouderde beheeromgeving een probleem is, by all means: innoveer. Als het echter prima werkt en niemand heeft er last van, blijf er dan van af.
Ik denk dat de eerste innovatie binnen beheer moet zijn: hoe zorgen we er voor dat beheer meer afstand kan nemen van de dagelijkse beslommeringen om zo gelegenheid te krijgen andere problemen op te lossen?