Veel organisaties die software gebruiken om hun ict-omgeving te beheren, doen dat verkeerd of onvolledig. Dat zeggen experts die deelnemen in het Computable-panel Beheer. Ze beamen daarmee de uitkomsten van een rapport van Forrester Research. Daarin wordt geconcludeerd dat ict-beheersoftware vaak weggegooid geld is. Toch wijzen veel experts op de voordelen die goed toegepaste ict-beheer met zich meebrengt.
'Ik zie vaak slecht geïmplementeerde tools of tools waarvan slechts een klein deel van de functionaliteit wordt gebruikt', meldt consultant Aad Brinkman van Aranea Apreton. Ook Paul Leenards van Getronics Consulting is die mening toegedaan. 'Slechts een beperkt deel van de mogelijkheden van beheersoftware wordt gebruikt. Een beperkter deel wordt gebruikt om de bedrijfsdoelstellingen te realiseren. Daarmee is de investering wel effectief, maar niet efficiënt.'
Als de beheersoftware wel goed is toegepast, zijn volgens de experts wel degelijk voordelen te behalen. 'Het levert kostenreductie, hogere beschikbaarheid en betere beveiliging', zegt it-architect Sjaak Laan van Logica. Bovendien creëer je binnen de ict-afdeling ruimte voor innovatie, vult Morteza Esteki van Quest Software aan. Matthé Smit van Kaseya: 'Beheersoftware die taken geautomatiseerd uitvoert, doet dit vaak sneller, met minder fouten, en is beter controleerbaar dan de mensen die hetzelfde werk proberen uit te voeren. Hiermee is de investering snel terugverdiend.'
Te ambitieus
'Organisaties koesteren echter vaak onjuiste verwachtingen', vertelt Arvid Elstrodt van HP. 'Dat wordt in de hand gewerkt door te rooskleurige verkoopverhalen, waardoor te ambitieuze projecten worden opgestart. Het is niet correct om dan de software de schuld te geven. De fout ligt vrijwel altijd uitsluitend bij de implementatie: men wil vaak te veel in te weinig tijd.'
'Een veelgemaakte denkfout is dat men probeert een organisatorisch issue op te lossen met een technische oplossing', zegt Antoine Jansen van Priox tot slot. 'En dan past het vaak dus niet.'
Ben het eens met de opmerkingen van Arvid Elstrodt en Antoine Jansen, “de fout ligt vrijwel altijd uitsluitend bij de implementatie” resp. “men probeert een organisatorisch issue op te lossen met een technische oplossing”.
Maar veel leveranciers en opdrachtgevers nemen genoegen met “slecht geïmplementeerde tools of tools waarvan slechts een klein deel van de functionaliteit wordt gebruikt”. En dat “een beperkter deel wordt gebruikt om de bedrijfsdoelstellingen te realiseren”
Die leveranciers zijn niet meer dan een dozenschuivers.
Ben het er ook wel mee eens.
Het justificeren van de aankoop is meestal eenvoudig door besparing op FTE’s aan te geven.
Dat is ook te realiseren met goed gebruik.
Maar Nederlandse organisaties zijn vaak minder goed om te implementeren en de baten te effectueren, En daardoor blijven de dingen gaan zoals ze gingen.
Eens, dat SW niet optimaal effectief benut wordt, en kennelijk is er geen gunstige ROI voor de exploitatie van die onbenutte functionaliteit.
De stelling dat men een organisatorisch probleem technisch probeert op te lossen is mede het gevolg van het gedrag van leveranciers die niet oplossinggericht tegengas geven, alleen maar omzet willen maken en de problematiek vertalen naar hun standaardoplossing, “the best fit”, daarbij voorbijgaand aan de probleeemgebieden die zij niet oplossen, en soms additioneel veroorzaken.
De perceptie bij de eindgebruiker t.a.v. het implementatietraject (die zelf ook een eigen verantwoordelijkheid heeft zich goed te laten informeren) wordt mede gevoed en beinvloed door de leverancier.
Het is dan ook mede aan de leverancier om de eindgebruiker een juiste perceptie te bieden.
De leverancier wordt geacht kennis van zaken te hebben en op een professionele wijze de eindgebruiker te begeleiden.
M. Barkey
Ik ben het eens met de “voorlopige” conclusie dat implementaties veelal niet (volledig) effectief zijn en niet-efficiënt zijn (met een meetbare ROI dus) omdat het vaak organisatorisch fout gaat.
Beheer, onderhouw en monitoring van ICT-systemen is alsmaar meer complex geworden. “Meten is weten” wordt vaak genoemd en “if you can’t measure it, you can’t manage it” is ook zo’n bekende uitspraak.
Meten is een essentieel onderdeel van een cyclus waarin je iets plant (welke doelen, welke eisen, welke randvoorwaarden), uitvoert en vervolgens controleert (meten t.o.v. referentiewaarde of een trend bepaling) waarna je weer corrigerend/sturend optreedt. Niet voor niets heeft Deming ooit het kwaliteitswiel Plan, Do, Check, Act “bedacht”. Ook daar moet je dus meten.
Maar je moet dan wel weten WAT je moet meten en in welke vorm, tijdigheid en juistheid de informatie ook daadwerkelijk bruikbaar is. Welke informatie je nodig hebt, is uiteindelijk terug te voeren tot de SLA’s, KPI’s en KSF’s die gelden voor een organisatie.
’s Nachts een SMSje ontvangen omdat een harde schijf gecrasht is, is technisch geen probleem, maar menselijk wel natuurlijk. en welke informatie krijg je dan eigenlijk in je 160 karakter grote SMS bericht te zien. Je kunt niet meteen doorklikken naar een console o.i.d. en je wordt er waarschijnlijk toch al niet wakker van als je standby dienst draait.
Beter beheren en beheersen van ICT begint bij een organisatiebrede bewustwording van de noodzaak voor toepassing van tooling op basis van de wens om de effectiviteit en efficiëntie van de ICT te verbeteren. Meestal vereist dit expliciete kennen ten aanzien van de te beheren ICT (het domein) en de inrichting van de tooling. Simpelweg een servertje installeren met een gratis beheer- en monitoringtool is dan geen oplossing. Die landt namelijk niet in de organisatie. De gehele keten van eisen vertaald naar meetbare entiteiten en het oppakken van verkregen informatie vereist commitment van ICT-management en DMU’s binnen de organisatie.
Vaak is een cultuuromslag binnen een organisatie noodzakelijk… en is de techniek niet de belemmerende factor.
Service management tools worden al te vaak geïmplementeerd om al bestaande eigen procesgang te ondersteunen terwijl ze gemaakt zijn voor standaard (Vaak ITIL) proces oplossingen.
Bedrijven kiezen er dan voor toch het bestaande proces in het tool te zetten zonder kritisch te kijken of de eigen procesgang wel goed is, en er dus maatwerk aanpassingen op het tool nodig zijn. Ook kijkt men vaak niet naar het groei scenario voor toekomstig gebruik waardoor bij de start verkeerde inrichtingskeuzes gemaakt worden.
De beste implementaties van beheer ( service management) tools zijn die implementaties waarbij men naast de Tool óók oog heeft voor proces inrichting en proces herontwerp.
Bij een dergelijke aanpak dient een goede begeleiding van de mensen die hun gedrag en werkwijze moeten aanpassen te worden ingezet om de drie-eenheid, Mensen, Tools en Processen goed samen te laten werken om het beoogde resultaat te behalen.
Ik ben het dan ook met Gert Kiewiet eens dat er een (cultuur) omslag nodig is bij beheerders en dat het meestal geen oorzaak is van een ondeugdelijk tool.
Op zich als stelling wel aardig, maar wat meer voorbeelden zouden wel prettig zijn. Wat doet men dan verkeerd? Het implementeren, maar dat is geen antwoord.
En als het dan wel goed kan, wat moet er dan gebeuren? Als de schrijver dat weet, zet het dan in het artikel. Ik ben hier namelijk razend benieuwd naar!
@Ton Strik:
Zie voor tien tips bij de keuze van beheersoftware het artikel Standaardpakket werkt niet bij beheersoftware
Weer een artikel in de serie ‘open deuren’.
Ik lees:
“Als de beheersoftware wel goed is toegepast, zijn volgens de experts wel degelijk voordelen te behalen. ‘Het levert kostenreductie, hogere beschikbaarheid en betere beveiliging”.
Die uitspraken lees ik vaker maar ik zie ze nooit gekwantificeerd. Pas dan kun je de Deming cirkel rond maken…
Volledig akkoord Gert, alles start met meten. Ik zie dikwijls dat het daar al fout loopt. Meet- en monitoring systemen worden vaak niet redundant en zelfcontrolerend opgebouwd met onaangename gevolgen; geen of foutieve alarmen.
Ton kijk eens naar http://www.alarm4it.com daar staan enkele voorbeelden op van wat kan foutlopen. Een degelijke audit is de basis van goede monitoring.
Beheerssoftware is sowieso een tweede stap en kan alleen maar in kleine stukjes gebeuren. Grote ambitieuze projecten falen steeds. Mijn ervaring alleszins.