Ik vergelijk de it-wereld wel eens met de wereld van onze parlementsleden. Op het moment dat er een nieuwe regering wordt aangesteld, waait er weer een frisse wind door Den Haag en worden meteen alle werkkamers opnieuw ingericht en van een nieuw kleurtje verf voorzien. In de it is dat niet anders.
Zodra er een nieuwe it-manager wordt aangesteld wordt de bezem door de aanwezige tooling gehaald en wordt er een nieuw pak aan requirements opgesteld om alles nog beter en efficiënter in te richten. Er is natuurlijk niks mis met een frisse wind en een nieuwe, kritische blik, maar over de efficiency van deze aanpak valt natuurlijk wel te twisten.
Niet alleen een nieuwe it-manager is vaak aanleiding voor nieuwe tooling, ook onvrede met de oude tool is reden om op zoek te gaan naar een nieuwe oplossing. Teveel klikken of functionaliteit die niet aansluit op processen zijn veelgehoorde klachten die het gebruik van de tooling belemmeren. Gevolg is dat de tooling niet oplevert waarvoor het is ingezet en onvoldoende bijdraagt aan het resultaat van de business. Kortom: of er nu een frisse wind of tegenwind waait, de tooling krijg de schuld.
Productselectie is vaak een uitvoerig en zeer gedetailleerd project. Alle wensen en behoeften van it worden in een uitgebreid programma van eisen benoemd en gespecificeerd. Dit om te voorkomen dat er iets aan de nieuwe tooling ontbreekt en dat aan alle mogelijke functionaliteit wordt voldaan. In de proof of concept worden vervolgens alle functies door en door getest en afgevinkt. Resultaat is een applicatie met een veelheid aan functionaliteit , zonder dat er is gekeken naar welke functionaliteit nu echt nodig is. En daarmee is de cirkel rond. Veel bedrijven hebben na één jaar slechts 15 procent van de tool waar ze in de selectie zo kritisch over waren ingericht. En veelal houdt de inrichting daar ook op. De tool voldoet vervolgens binnen afzienbare tijd al niet meer aan de eisen van de gebruikers, met onvrede als onomkeerbaar effect. Hoe kunnen it’ers die cirkel doorbreken? En hoe zorgen ze ervoor dat de wind niet telkens uit een andere richting waait?
De kunst is om de focus bij toolselectie te verleggen van het zoveel mogelijk (benutten van) technische functionaliteit naar een focus op processen. Dat is de basis voor een goede toolvisie. Als je kijkt naar it-dienstverlening dan zouden it service management (itsm-)processen leading moeten zijn in de keuze voor de tooling en de bepaling van de functionaliteiten. Zo wordt er bij de inrichting van de tooling bijvoorbeeld vaak niet nagedacht over wat er uiteindelijk gerapporteerd moet worden. In veel gevallen is met een matige inrichting goede rapportage zelfs niet eens mogelijk. De crux is om al vóór de start van het selectieproject de procesinrichting tegen het licht te houden of deze op z’n minst mee te nemen in het project.
Dat betekent niet dat je de bestaande processen weer één op één moet overnemen in de nieuwe toolinrichting. Dan wordt het oude wijn in nieuwe zakken. Een goede toolvisie vraagt om gedegen inzicht in processen. Niet alleen van de it-afdeling zelf. Ook van it in relatie tot de business. Bovendien zou rapportage, of het nu operationeel is of richting het management, de basis moeten vormen voor de inrichtingskeuzes van de tooling. Op die manier kan it de zo gewenste faciliterende rol voor de business gaan spelen en kan de wind in de zeilen gaan waaien.
A fool with a tool is still a fool.
Een goed stuk wat de vinger m.i. op de zere plek legt door te stellen dat er niet gekeken moet worden naar de techniek maar de processen en de service. Helaas komen veel tools mee met de techniek of worden ze gekozen door techniek. Wat natuurlijk logisch is omdat je techniek wel kunt automatiseren en de processen meestal niet (zo eenvoudig).
Een goede toolselectie vraagt dus eerst een vertaling van processen naar technische parameters. Rapporteren op beschikbaarheid of prestatie van een applicatie? Prima, maar kwantificeer deze eisen dan wel zodat ze ook meetbaar worden. Wie die vertaling gemaakt heeft zal zien dat veel tools de benodigde informatie al hebben alleen zit deze vaak nog verstopt.
Ingesloten in de vele repositories die elk een stukje van de infrastructuur bewaken. Ontsluiten hiervan kan met ’tool leverage’ door data te exporteren en te correleren. En hergebruik beperkt niet alleen wildgroei aan tools maar voorkomt ook verspilling aan capaciteit van resources. Het ophalen van gegevens uit de infrastructuur belast namelijk netwerk, servers en opslag. En verzwakt mogelijk de beveiliging omdat veel tools administratieve rechten nodig hebben.
In enkele eerdere opinies schreef ik hier ook over en eigenlijk hebben we het gewoon over het maken van een Service Knowledgde Management System. Iets wat nu vaak nog adhoc en met Excel gedaan wordt.
Op het gevaar af belerend of beledigend over te komen:
Is het niet beter om te beginnen met het antwoord op de vraag wat er geautomatiseerd moet worden?
Het model ISO-FCAPS is daarvoor een zeer bruikbaar referentie kader. Hoewel van oorsprong gericht op telecom is het ook bruikbaar voor andere technieken zoals servers, storage en zelfs applicaties.
Een onderwerp dat ik in dit artikel mis is “flexibiliteit” van een tool!
Een tool kan in het begin voldoen aan eisen die processen stellen. Maar de processen kunnen in de loop van de tijd veranderen. Je kan te maken krijgen met een omgeving waar niet alleen de bestaande processen regelmatig gewijzigd worden maar ook de nieuwe processen ingevoerd moete worden. Een voorbeeld van dit soort omgeving is bij gemeenten (nieuwe wetten of verandering in de bestaand wetten)
De vraag is of een tool met dit soort veranderingen binnen zijn life cycle kan meebewegen! Kan een tool die circa 2 jaar geleden aangeschaft is en prima aan alles voldeed, nu een antwoord geven op de behoefte vanuit de (gebruikers)organisatie, business, (IT)ontwikkelingen etc? Als we weten dat we in een omgeving werken waar de processen en regels steeds veranderd worden, wat zou ons beleid moeten zijn voor het aanschaffen van een tool? Afgezien van de komst va de nieuwe manager, hoe zorg je ervoor dat de investering in een tool geen desinvestering over 2 jaar wordt?
Naast de functionaliteit van de tool wordt het gedrag van de medewerkers die de betreffende tool moeten gebruiken vaak onderbelicht. Een proces werkt pas echt als drie componenten kloppen namelijk 1. Procedures / afspraken. 2. Tooling 3. Gedrag.
Vaak hebben medewerkers geen zin in moeilijke veranderingen en blijft men keer op keer verzanden in discussie omtrent functionaliteit en procedures.
Afspraak is afspraak en of je dit vastlegt binnen exel of welke tool dan ook topdesk, trinicom……….
Maw focus ook op de zachte kant van tooling.
Mooie reacties. Er is inderdaad een hoop te melden rondom dit onderwerp. In eerdere artikelen beschrijf ik ook de uitdagingen van de de organisatie en gedrag bij het inrichten en optimaliseren van IT service management. Met mijn NLP achtergrond ben ik ook van plan om daar nog meer over de schrijven in de nabije toekomst daar dit stuk vaak is onderbelicht.
Flexibiliteit is inderdaad een belangrijk onderdeel van het Programma van Eisen (PvE). Daarom is het des te belangrijker om te kijken in welke fase een organisatie zich begeeft en daar de eisen op aan te passen. Dit onderstreep m.i. de boodschap van dit artikel: eerst goed nadenken over de doelstelling van de organisatie, processen en toepassing, daarna een solide pakket selectie opstarten.