Slechte systemen & waarom het nooit aan het systeem ligt

Slechte systemen & waarom het nooit aan het systeem ligt

by | mei 5, 2019 | Artikelen

Slechte systemen en waarom het nooit aan het systeem ligt

Het is me nu al twee keer overkomen. Ben je in gesprek met een organisatie die een serieus probleem heeft met hun ICT-ondersteuning. Help je ze het probleem concreet te maken, het op de agenda te zetten, etc. Besluiten ze het systeem hele systeem te gaan vervangen. Slechte systemen, daar ligt het aan (volgens hen dan). Alsof het hele systeem vervangen de oplossing is. In dit artikel ga ik je uitleggen waarom het hele systeem vervangen volgens mij nooit de oplossing is.

Het hele systeem vervangen is nooit de oplossing!

Laat ik eerst maar eens uitleggen waarom mensen denken dat het hele systeem vervangen een goed idee is. Vaak wordt dat besloten op basis van de gedachte dat ander systeem misschien wel zal functioneren. Verkopers van de concurrent kunnen dat trouwens ook altijd heel aannemelijk maken. Overstappen naar hun systeem doet alle problemen als sneeuw voor de zon verdwijnen. Dat klinkt te mooi om waar te zijn en vaak is het dat ook. Voor nieuwe auto’s mag dat misschien opgaan, maar voor ICT werkt dat toch anders.

Neem van mij aan: slechte systemen verkopen niet. Dus als een systemen aangeboden wordt door een gezonde commerciële partij, dan kan het systeem gewoon normaal functioneren. Slechte systemen hebben namelijk binnen de kortste keren een slechte reputatie en dan is de handel over. Leveranciers van softwarepakketten hebben er alle belang bij om kinderziektes en onhandigheden voor gebruikers zo snel mogelijk op te lossen. En dat gebeurt dan ook. Dat het systeem de oorzaak van het probleem zou zijn is dus een fabeltje.

Het systeem is waarschijnlijk niet goed ingericht

Veel waarschijnlijker is het dat het systeem niet goed is ingericht of niet op de juiste manier gebruikt wordt. Ik acht de kans groot dat het probleem zit in de vertaling van de processen naar een geautomatiseerd systeem. Dat zit zo. Als je handmatige procedures hebt, dan kan elke medewerker hetzelfde doel op verschillende manieren bereiken. En kan iedereen er zijn eigen werkproces op nahouden. Zolang het resultaat maar goed is, is het voor de meeste organisaties goed genoeg. Als je dit gaat automatiseren, moet het opéén manier. En die manier is vrijwel nooit de jouwe. En vrijwel nooit van toepassing op alle gevallen. Er is altijd wel die ene uitzondering die niet gaat op de manier waarop het zou moeten. En dan loop je dus tegen de problemen aan. Dus al je het ene systeem vervangt door het andere, is de kans groot dat je dezelfde ellende krijgt als daarvoor.

Een klant van me had bijvoorbeeld zijn systemen voor HR en financiën niet goed ingericht. Dat was begonnen met een ZZP-er die ze in daarvoor in de arm hadden genomen. Op een gegeven moment werd dat overgenomen door een wat groter bedrijf en die hadden natuurlijk zo hun eigen ideeën over de inrichting van het systeem. En alles wat het niet goed deed, lag natuurlijk aan die verrotte inrichting. Daarna werd een nog professionelere partij ingehuurd, die ook weer doorbouwde op het oude systeem. Tot er iemand langskwam die het probleem bij de wortel aanpakte: laten we het systeem opnieuw inrichten. Wat denk je? Je kunt je voorstellen dat het HR/finance-pakket daar echt geen goede naam had. Maar ook hier lag het niet aan het systeem. Een ander systeem had het probleem net zo hard laten terugkomen, want het is het makkelijkste (en goedkoopste) om de inrichting van het oude systeem één op één over te nemen. Met behoud van ellende.

De 80/20 regel

Een goede inrichting van het systeem is vrijwel altijd de oplossing van dit soort problemen. Dat kost tijd en flink wat denkwerk. En veel overleg ook met de mensen die het systeem moeten gebruiken. Maar het is absoluut te doen. Ook hier gaat de 80/20-regel op. Door de basisprocessen goed in te richten kun je al 80% van de ellende oplossen. En dat is mijns inziens absoluut de moeite waard!

Wil je weten hoe jouw organisatie kan profiteren van onze kennis? Neem dan contact met ons op voor een afspraak. We helpen je graag verder!

Breng mij naar dit handboek
Reinout Martens

Reinout Martens

Eigenaar en oprichter van Kaderbreed B.V.

Toen Reinout een jaar of 21 was – hij studeerde nog – zat hij op een feestje, waar iemand vertelde dat er een interim manager bij haar bedrijf gestart was. Een botte boer die, zonder rekening te houden met zorgvuldig opgebouwde gewoontes, relaties, werkverhoudingen, etc. overal de bijl inzette en geen rekening leek te houden met wat dat met de mensen deed. Reinouts eerste gedachte was:

“dat kan anders en ik ga dat bewijzen”.

Breng mij naar dit handboek

ICT als steentje in je schoen

ICT als steentje in je schoen

by | apr 24, 2019 | Artikelen

ICT als steentje in je schoen

Ik wist al een tijdje dat haar organisatie met een probleem zat dat ik mogelijk kon oplossen. Ze had wel vaker geklaagd en ik had wel vaker aangeboden om te helpen. Maar iedere keer was er wel iets belangrijkers wat speelde binnen de organisatie en iedere keer was er wel een goede reden om de aanboden hulp uit te stellen. Dus trok ik de stoute schoenen aan om te vragen hoe groot het probleem nou werkelijk was. Kwantificeer het maar eens. En dat deed ze. Ik viel van mijn stoel van verbazing! En zo hadden we wederom te maken met slecht functionerende ICT-systemen.

10 tot 20 procent productiviteitsverlies voor de medewerkers die het werk moesten verzetten waarmee het geld werd verdiend! Keer zoveel omzet is… Wow, dat is een hoop geld! Een hoop geld op vele andere manieren wat nuttig besteed kan worden. Als daar geen positieve businesscase van te maken is, dan weet ik het niet meer.

Het is een probleem dat ik regelmatig tegenkom in gesprekken. Blijkbaar hebben we met elkaar geaccepteerd dat onze ICT matig functioneert en is het probleem niet groot genoeg op het op te lossen. En ik weet ook wel waarom: het is als het steentje in je schoen dat net niet lastig genoeg is om je schoen uit te trekken en het eruit te halen. Maar als je na lange tijd besluit er toch iets aan te doen, vraag je jezelf af waarom je dat niet veel eerder hebt gedaan.

En zo is het ook met ICT: het probleem is net niet groot genoeg om op lossen. Dat komt omdat ICT altijd ondersteunend is aan andere afdelingen. En die andere afdelingen rennen altijd het gat dicht dat ICT achterlaat. Denk maar aan die 10 tot 20 procent productiviteitsverlies van het voorbeeld hierboven. 10 tot 10 procent onproductieve uren! En niemand die er iets aan doet, want er zijn belangrijkere problemen om op te lossen. En de gefrustreerde medewerkers maar laten aanklooien met slecht functionerende ICT en de klappen laten opvangen. Zo gaat dat dus.

Natuurlijk vind ik dat dat zo niet langer kan. Hoog tijd dus om het steentje in de schoen te benoemen voor wat het is: iets dat je maar beter zo snel mogelijk op kan lossen, want je hebt er alleen maar last van. En het kan ook: schoen uittrekken, steentje eruit, klaar. Hoe moeilijk kan het zijn? Hetzelfde geld ook voor ICT. Kijk maar eens op onze website naar hoe makkelijk de meeste problemen met ICT op te lossen zijn. En we helpen je graag op weg.

Er zijn verschillende redenen waarom het probleem volgens mij opgelost moet worden. Die zal ik hieronder stuk voor stuk opnoemen.

  1. De eerste en belangrijkste reden is: het kost gewoon geld. Productiviteit gaat verloren, klanten haken af, dingen kosten drie keer zoveel tijd als nodig en die tijd kun je beter gebruiken voor andere zaken. We helpen je graag met dit rekensommetje compleet te krijgen in een persoonlijke gesprek. Hoeveel geld, dat verschilt per organisatie en van geval tot geval. Maar dat het geld kost, is zeker.
  2. Daarnaast leveren slecht functionerende ICT-systemen of -organisaties veel frustraties op bij de medewerkers die daarmee moeten (samen)werken. Dit heeft zijn weerslag op hun productiviteit. Het kan voor sommigen zelfs de druppel zijn om ontslag te nemen. Die gaan dan werken bij een concurrent waar het wel goed geregeld is. Heeft je concurrent er een uitstekende en goed ingewerkte kracht bij. En moet jij weer een wervingstraject opstarten, iemand inwerken en misschien ook weer meer salaris betalen. Mooi is dat!
  3. Niet in de laatste plaats worden de ICT’ers zelf buitengewoon ongelukkig van slecht functionerende (lees: slecht ingerichte) ICT-systemen en/of slecht functionerende organisaties. Een ICT’er is namelijk net als velen van u: hij of zij houdt ervan om mooi werk op te leveren en de mensen voor wie hij/zij het werk doet tevreden achter te laten. Slecht werk afleveren wordt echt niemand gelukkig van.
  4. Tot slot laat je echt een hele grote kans liggen op het gebied van innovatie, voorsprong op je concurrenten, je klanten beter bedienen, etc. Als de ICT-afdeling het huidige werk namelijk al niet aan kan, durft (bijna) niemand nog met goede ideeën te komen waarin een afhankelijkheid van ICT zit. En dat is echt dood- en doodzone! En op de lange duur gaat je bedrijf er misschien wel aan ten onder. Ik durf het bijna niet te zeggen, maar ik denk wel dat het zo is.

Heb je het gevoel dat ook maar één van bovenstaande gevolgen bij jouw organisatie aan de hand is, of dat je sowieso te maken hebt met slecht functionerende ICT-systemen? Laat ons dan eens langskomen. We helpen je graag verder.

Zoals het parkeerbedrijf dat we geholpen hebben met een significante verbetering van hun ICT-organisatie. Laatst moest ik in Den Haag zijn en wilde graag parkeren. Hoe cool zou het zijn om gewoon tijd en uren in te vullen, direct af te rekenen en bij aankomst gewoon door te rijden naar je gereserveerde parkeerplek. Het kan gewoon met de systemen. Maar iemand moet het verzinnen en tijd hebben om het uit te voeren. Daar worden wij zo blij van als dat lukt!

Kom eens praten, we helpen je graag verder.

Breng mij naar dit handboek
Reinout Martens

Reinout Martens

Eigenaar en oprichter van Kaderbreed B.V.

Toen Reinout een jaar of 21 was – hij studeerde nog – zat hij op een feestje, waar iemand vertelde dat er een interim manager bij haar bedrijf gestart was. Een botte boer die, zonder rekening te houden met zorgvuldig opgebouwde gewoontes, relaties, werkverhoudingen, etc. overal de bijl inzette en geen rekening leek te houden met wat dat met de mensen deed. Reinouts eerste gedachte was:

“dat kan anders en ik ga dat bewijzen”.

Breng mij naar dit handboek

ICT projecten, zo krijg je ze in control

ICT projecten, zo krijg je ze in control

by | feb 25, 2019 | Artikelen, Planning

ICT projecten, zo krijg je ze in control

 

ICT-projecten staan erom bekend dat ze altijd uitlopen. Het is nooit op tijd klaar en plannen is blijkbaar lastig. Toch geloof ik dat ICT-projecten – en ICT-taken met een langere doorlooptijd – veel beter planbaar zijn dan veel gevallen gedacht wordt. Daarom maar eens wat aandacht voor de planning van de grotere ICT-taken.

 Eerst even de feiten. Het klopt dat het neerzetten van niet-standaard ICT-oplossingen een creatief proces is. En dat het daardoor lastig om in te schatten hoeveel tijd iets kost. Tot zover is ICT – voor zover het niet standaard is – lastig te voorspellen. Maar dat is dan ook echt het enige waarin ICT niet planbaar is.

 In principe mag je verwachten dat elke professionele ICT’er globaal kan inschatten hoeveel tijd iets kost om te realiseren. En de meeste ICT’ers kunnen dat ook. De meeste ICT’ers kunnen prima inschatten of iets een kwartier, een uur, een dagdeel of een paar dagen kost. En voor langere trajecten moet je het werk in kleine brokjes verdelen. En dan kan dat ook – zij het met een bepaalde marge – ingeschat worden. Tot zover prima. Maar dan moeten er wel een aantal randvoorwaarden ingevuld worden.

 Als je ICT’ers vraagt naar deze randvoorwaarden zul je deze vaak ook krijgen. En als je niet duidelijk is wat de randvoorwaarden zijn of waarom dat randvoorwaarden zijn, vraag dan net zo lang door tot het wel duidelijk is. ICT’ers weten over het algemeen prima welke randvoorwaarden ingevuld moeten zijn om hun werk kunnen uitvoeren.

 De eerste randvoorwaarde die ingevuld moet worden is een aanspreekpunt om invulling te geven aan allerlei keuzes die in het creatieve proces gemaakt moeten worden. Omdat ICT-projecten altijd bedrijfsprocessen ondersteunt, is er iemand nodig uit dat bedrijfsproces om daarin de juiste keuzes te maken. Ook kan dit aanspreekpunt hem of haar voorzien van allerlei informatie die nodig zijn om het systeem met de juiste informatie te vullen. In Agile- en Scrum-achtige werkwijzen wordt dit aanspreekpunt ook wel Product Owner genoemd.

 Daarnaast is het belangrijke dat de betreffende ICT’er ongestoord zijn werk kan doen. Hoe je dat oplost heb ik in dit artikel beschreven.

 De laatste stap die je moet zetten om tot een planbaar geheel te komen is afspraken maken. Als alle randvoorwaarden ingevuld zijn, rest er niets anders dat het werk gewoon uit te voeren. Daar zal de gemiddelde ICT’er ook geen enkel bezwaar tegen hebben. Prima!

 Met die afspraken kun je vervolgens een leercurve opstarten, waarmee je planning steeds betrouwbaarder wordt. Vraag een ICT’er waarom hij een een planning niet gehaald heeft, en leer daaruit.

 Door de afspraken vervolgens te monitoren komt je drie dingen op het spoor:

  1. Elke ICT’er heeft een bepaalde (constante) factor waarmee hij of zij het werk te optimistisch inschat (of te pessimistisch, maar dat komt minder voor). Voor de volgende keer kun je die factor eroverheen zetten waardoor je planning steeds betrouwbaarder wordt.
  2. Verstoringen. Ze zullen blijven voorkomen. En door ernaar te vragen kom je ze op het spoor. En kan je maatregelen treffen om het aantal verstoringen steeds verder terug te dringen.
  3. Verkeerde inschattingen. Ook hier kan je een leercurve inzetten.
    Vraag een ICT’er waarom hij een een planning niet gehaald heeft, en leer daaruit.

 Door bovenstaande toe te passen kun je vaak binnen 2-5 slagen komen tot planningen die tot wel 80% betrouwbaar zijn. En dat is vele malen beter dan wat de gemiddelde ICT-afdeling heden ten dage presteert! Ga jij voor ICT-ontwikkeling?

 

 Wil je vaker dit soort artikelen lezen? Schrijf je dan hier in en ontvang maximaal eens per twee weken een nieuw artikel in de mailbox.

Breng mij naar dit handboek
Reinout Martens

Reinout Martens

Eigenaar en oprichter van Kaderbreed B.V.

Toen Reinout een jaar of 21 was – hij studeerde nog – zat hij op een feestje, waar iemand vertelde dat er een interim manager bij haar bedrijf gestart was. Een botte boer die, zonder rekening te houden met zorgvuldig opgebouwde gewoontes, relaties, werkverhoudingen, etc. overal de bijl inzette en geen rekening leek te houden met wat dat met de mensen deed. Reinouts eerste gedachte was:

“dat kan anders en ik ga dat bewijzen”.

Breng mij naar dit handboek

De doofpot die de ICT-organisatie heet

De doofpot die de ICT-organisatie heet

by | feb 12, 2019 | Artikelen, Heb ik een probleem?, Voor niet ICT-ers

De doofpot die ICT heet

Ze beent met grote stappen naar me toe. Nog nooit had ze zoveel moeite gedaan om alles op tijd klaar te krijgen en nu blijkt alles toch niet geregeld te zijn. Ze baalt als een stekker. Net nu de nieuwe manager – waar ze graag een goede indruk op had willen maken – vandaag aan de slag moet. Wat moet zij voor indruk krijgen van onze organisatie? En misschien nog wel specifieker: welke indruk moet zij krijgen van de ICT-organisatie die haar straks moet ondersteunen? En de kwaliteit van de mensen die er werken. Dat laatste raakt me, want de kwaliteit van mensen is niks mis mee. De organisatie kunnen we inderdaad nog wel wat aan verbeteren. En dat is precies de reden waarom ik er ben en waarom zij – gelukkig! – naar me toekomt.

Als ik zo naar de feiten kijk is het inderdaad helemaal niet gedaan zoals het zou moeten. Het formulier is op tijd ingeleverd (sic). En de beheerder die het formulier heeft verwerkt heeft echt wel zijn best gedaan: het formulier is keurig op tijd verwerkt en alle standaard instellingen zijn ingesteld. Alleen: het aangekruiste vakje “laptop” was over het hoofd gezien. En alle speciale rechten die de manager moest krijgen waren in de applicaties zelf waren vergeten. En daar moest die nieuwe manager natuurlijk precies mee aan de slag. Dus geen inwerken vandaag. Oei, dat is een duur foutje.

Hoe heeft deze situatie kunnen ontstaan? En waarom blijft deze situatie voorkomen? Terwijl elke manager aan zijn theewater voelt dat er iets niet pluis is hier. En misschien nog wel belangrijker hoe los je dit op? Daarover gaat dit verhaal. Over de doofpot die ICT-organisatie heet.

Hoe heeft dit kunnen ontstaan?

Het is niet eens zo heel lang geleden dat de ICT’ers “als hogepriesters om het mainframe heen liepen”. ICT was een afgeschermd specialisme, bevolkt door schaarse en moeilijk benaderbare mensen. Mannen in witte jassen die het altaar van hun onbegrijpelijke mainframes bewaakten. Een verzoek tot berekening van iets kon ingediend worden, en werd dan in de stapel ’te behandelen’ gelegd. Het resultaat kwam na verloop van tijd tot de aanvrager, die dan in geval van een volgende vraag (of wijziging van de invoergegevens) vervolgens een nieuw verzoek mocht doen. [Bron: Computable]

Vanuit die tijd is ICT steeds groter geworden. Via administratie, salarisadministratie, financiën, personeelszaken en operatie naar uiteindelijk het hele bedrijf. ICT is steeds meer doorgedrongen tot de kern van het bedrijf. En dat bedrijf is daarmee steeds afhankelijker geworden van goed functionerende ICT-organisatie. En een goed functionerende ICT-afdeling.

Maar de organisatie, procedures en aansturing – en misschien ook wel het tempo – van ICT zijn nog steeds gestoeld op de tijd van het mainframe. Tot op de dag van vandaag staan ICT’ers te boek als slechte communicatoren. Lees hier hoe je dat kunt veranderen. En voor een storing moet je vaak eerst een melding inschieten voordat ze aan de slag gaan.

Hoe wordt dit in stand gehouden? – De doofpot

Om te begrijpen hoe dit probleem in stand wordt gehouden, zijn er twee zaken die we moeten begrijpen: de houding van de ICT-manager in dit probleem en de houding van zijn collega-managers in het MT.

De ICT-manager vaak inhoudelijk gedreven. Hobbyisten die op een gegeven moment van hun hobby hun werk hebben gemaakt en van daaruit zijn doorgegroeid naar het management. Vaak zijn het de betere communicatoren, maar hun drijfveren zijn nog steeds om ICT-systemen zo goed mogelijk te laten draaien. Tot zover niks mis mee. En het raakt hun persoonlijk als een ICT-systeem niet werkt. Dan hebben zij iets niet goed gedaan. Dus spelen ze liever mooi weer naar buiten: maak je geen zorgen, het komt goed. Vooral omdat de rest van het bedrijf toch geen verstand van ICT heeft en bemoeienis van buiten de boel er alleen maar slechter op maakt. En zo wordt ICT een eiland waar niemand zich mee bemoeit (of durft te bemoeien). Die hun zaakjes het liefst zelf regelen. En omdat niemand er echt verstand van heeft, komt hij of zij (vaker een hij) daar nog mee weg ook.

De rest van de organisatie ziet ICT vaak als iets ingewikkelds. En elke keer als je denkt dat het simpel is, krijg je – dankzij slechte communicatie vanuit ICT – het gevoel dat het toch ingewikkelder is dan je denkt. En dus sluipt langzaam het gevoel binnen dat het ingewikkeld was, is gemaakt, is en voorlopig ook zal blijven. Het probleem is nooit groot genoeg om op te lossen. Innovatie kan morgen ook wel, en de operatie draait meestal toch wel door, ook zonder ICT-organisatie. En ze doen ook zo hard hun best, het zijn aardige jongens, ze staan altijd voor je klaar en meer van dat soort verzachtende excuses.

En zo ontstaat de doofpot die ICT-organisatie heet. Alle probleem verdwijnen er in en vervolgens hoor je er nooit meer wat van.

Hoe dit nu op te lossen?

De vraagt dringt zicht op hoe je dit probleem kunt oplossen. Communiceren natuurlijk! Maar iemand zegt “communiceren”, vraag ik altijd: wie dan, wat dan, waarmee dan, hoe dan, en wie?

Het begint in basis met alles wat voor de organisatie belangrijk is. Maak een prioriteitenlijstje. Vraag aan de organisatie op welke vlakken ICT nog niet voldoende ondersteunt op dit moment. En vraag wanneer dat wel voldoende zou zijn. Wat doen ze dan? Hoe ziet dat er dan uit? Waaraan kunnen we dat afmeten?

Door de prestaties van ICT-afdelingen meetbaar te maken in termen van wat de rest van de organisatie nodig heeft, weet ICT waar ze aan moeten voldoen.

Ga vervolgens met de ICT’ers om tafel zitten en houdt een brainstormsessie over wat er moet gebeuren om het gewenste niveau te bereiken. Als je dat een beetje structureert, dan heb je aan het eind van zo’n sessie in één dagdeel een plan om dat te bereiken. En vervolgens is het een kwestie van randvoorwaarden invullen om uitvoering te geven aan het plan. Uitvoeren. Klaar. Wat wil je nog meer?

Het oplossen van de doofpot die ICT vaak lijkt, hoeft niet ingewikkeld te zijn. Je moet weten wat je moet doen, dat gestructureerd doorvoeren en rekening houden met de mensen die het werk moeten uitvoeren. That’s all!

Wil je vaker dit soort artikelen lezen? Schrijf je dan hier in en ontvang maximaal eens per twee weken een nieuw artikel in de mailbox.


[tqb_quiz id=’19005′]

Breng mij naar dit handboek
Reinout Martens

Reinout Martens

Eigenaar en oprichter van Kaderbreed B.V.

Toen Reinout een jaar of 21 was – hij studeerde nog – zat hij op een feestje, waar iemand vertelde dat er een interim manager bij haar bedrijf gestart was. Een botte boer die, zonder rekening te houden met zorgvuldig opgebouwde gewoontes, relaties, werkverhoudingen, etc. overal de bijl inzette en geen rekening leek te houden met wat dat met de mensen deed. Reinouts eerste gedachte was:

“dat kan anders en ik ga dat bewijzen”.

Breng mij naar dit handboek

Hoe je een succesvolle herstelprocedure voor ICT-systemen opzet

Hoe je een succesvolle herstelprocedure voor ICT-systemen opzet

by | nov 5, 2018 | Artikelen, Storingen

Een succesvolle herstelprocedure voor ICT-systemen

Laat ik hem Mario noemen. Ik was net begonnen in mijn eerste week als interim-manager voor een callcenter met bereikbaarheidsdiensten. Je weet wel, zo’n bedrijf dat de telefoon voor je opneemt met: “Goedemorgen Kaderbreed, waarmee kan ik u van dienst zijn?” “Nee, de heer Martens is niet aanwezig. Kan ik een boodschap aannemen?” Dat werk dus.

Ze waren net verhuisd naar een nieuwe pand en volgens mijn voorganger was alles tip top geregeld. De servers waren allemaal dubbel uitgevoerd, er was een UPS die het eerste uur stroomuitval kon overbruggen en in de kelder stond een gloednieuwe noodgenerator die binnen 5 minuten automatisch zou opstarten en het zonder onderbreking kon overnemen. Niets kon ons gebeuren.

Het was een regulier overleg waarbij een periodieke checklist voor een milieucertificering werd doorlopen. En Mario zat erbij. Er werd een vraag gesteld over de noodgenerator. Waarop Mario zich achteloos liet ontvallen: “Oh, die staat al twee weken in storing.” Toen hem gevraagd werd wanneer hij dacht dat op te lossen, en zijn reactie niet de gewenste was, was het feest compleet: nog geen kwartier later kreeg ik van diverse kanten te horen wat er gebeurd was. Tijd voor actie dus.

Plan gemaakt

Het eerste wat ik deed was natuurlijk aan Mario vragen wat er gebeurd was. Mario’s weergave strookte volledig met de beschrijving die ik van eerdere personen kreeg. Inclusief zijn reactie. “Maar waarom reageerde je dan zo?” vroeg ik. Toen kwam het: hij wilde graag een goede oplossing neerzetten en niet in twee weken iets in elkaar knutselen om vervolgens drie maanden lang bezig te zijn met het goedklooien van iets dat in de basis al slecht was. En daar kon ik het natuurlijk alleen maar mee eens zijn. Vanaf dat moment hebben Mario en ik een pact gesloten: ik ging hem helpen goede oplossingen neer te zetten en hij ging mij helpen er een mooie afdeling van te maken.

Het vervolg was simpel. Wat heb je allemaal op je bordje liggen? Wat zou wat jou betreft de volgorde daarin moeten zijn? Welke stappen en werkzaamheden moet je uitvoeren om de stroomvoorziening wel goed in te richten? En in welke volgorde zou je dat willen uitvoeren? Er volgde een keurig overzicht van activiteiten en een plan van aanpak voor de stroomvoorziening. Vervolgens heb ik de communicatie op me genomen om dat gewoon uit te voeren, inclusief de keuze voor de dingen die we niet of later gingen doen.

En toen het plaatje compleet was, sprak ik de legendarische woorden “dan hoop ik maar dat we in de tussentijd geen stroomstoring krijgen.”

Stroomstoring

Dat had ik beter niet kunnen zeggen. Want die stroomstoring kwam er natuurlijk wel. Binnen een week om precies te zijn. De UPS deed gelukkig zijn werk, maar binnen 15 minuten lag alles plat. Het bood mij uitstekende informatie over de taakverdeling bij calamiteiten. Hoe de communicatie verliep (of niet verliep) . Wat er ontbrak. En wat er allemaal verbeterd kon worden. Door alles op te schrijven ontstond er vanzelf een stappenplan voor stroomstoringen, calamiteiten, uitwijk en eigenlijk al die plannen die je nodig hebt om de continuïteit van je ICT-systemen te waarborgen. Een van de zaken waar we achter kwamen was dat we een persoon nodig had die eens in de zoveel tijd een jerrycan met diesel ging vullen bij het tankstation. Gelukkig kon de noodgenerator na 15 minuten opgestart worden en konden daarna alle systemen een voor een opgestart worden. In 45 minuten waren we weer volledig operationeel en gelukkig was de storing tijdens een rustig moment, dus waren er er weinig klanten die last hadden gehad van de storing.

Nu was het een kwestie van een evaluatie uitvoeren met alle betrokkenen, verbeterpunten verzamelen, en daar acties aan koppelen en die te belegen. Uit de evaluatie kwam naar voren dat we met 2 maanden zover konden zijn dat we een test konden uitvoeren van de noodstroomvoorziening. De noodgenerator werd gerepareerd. De werking van UPS werd doorgrond. Er bleken ook nog eens de verkeerde batterijen in te zitten, dus die werden vervangen. Er werd een procedure voor het opnieuw opstarten van het alle servers geschreven. En uiteraard werd er een stappenplan voor de test zelf geschreven.

Noodstroomtest

En toen kwam natuurlijk de grote test: zou alles werken zoals het zou moeten? Met alle operationele managers werd een tijdstip gekozen voor het uitvoeren van de test. Alle personen die aanwezig moesten zijn werden ingepland. En toen moest het gebeuren. Een monteur van de elektrische installatie zou na afstemming van het plan de knop omzetten. Het plan werd met alle betrokkenen afgestemd en er werd afgesproken hoe te communiceren via de walkie talkies. En toen gebeurde het: de monteur deed de schakelaar om. En er gebeurde… helemaal niets!!!

Nu de noodstroomvoorziening succesvol getest was, waren we gewapend tegen noodstroomstoringen. De uitwijk was nog niet geregeld. Of in ieder geval: nog niet getest. En hierbij moet je niet alleen aan servers en een uitwijklocatie denken (al dan niet met back-ups om op te starten). Een callcenter heeft namelijk niet echt loyale klanten. De vorige storing was gelukkig tijdens lunchtijd, waardoor het nauwelijks klanten had gekost. Maar als je als callcenter niet binnen 24 uur weer volledig in bedrijf bent, zijn al je klanten uitgeweken naar je concurrenten en komen ze nooit meer terug. Dan ben je dus failliet.

Voorzieningen treffen

Een succesvolle herstelprocedure voor ICT-systemen begint met het treffen van de volgende voorzieningen.

  • Je moet servers op geografisch gescheiden locaties hebben, die het al dan niet automatisch over kunnen nemen;
  • Je moet over een procedure beschikken waarmee de functionaliteit op de uitwijklocatie voor klanten transparant of uitlegbaar beschikbaar komt;
  • En je moet een testplan maken wat eens in de zoveel tijd – gecontroleerd – daadwerkelijk uitgevoerd wordt.

Maar voor dit soort acties heb je dus niet alleen de ICT-afdeling nodig. Hiervoor moeten ook alle operationele afdelingen een plan hebben liggen. Als je het risico wil afdekken van brand, neerstortende vliegtuigen en ander onheil waarmee de locatie volledig onbeschikbaar raakt moet je ook binnen de tijd die je daarvoor stelt, werkplekken hebben of kunnen regelen voor het personeel dat je nodig hebt om als bedrijf operationeel te blijven.

Uiteindelijk zijn het allemaal afwegingen van risico, schade en kosten. Wat is de maximale tijd dat ik niet bereikbaar/operationeel mag zijn? Hoeveel bedragen de kosten van de verschillende alternatieven? En wat is mij welk risico waard? Het kan natuurlijk prima dat je zegt dat het risico gewoon wilt lopen. Dat de businesscase niet positief is . Maar dan heb je die afweging in ieder geval bewust gemaakt.

Conclusie

Het opzetten van een goede herstelprocedure hoeft niet ingewikkeld te zijn. Vaak weten de mensen die in het proces zitten prima wat er allemaal moet gebeuren. Je moet alleen de tijd vrijmaken om die acties allemaal uit te voeren en de hele procedure op een veilig moment testen. Dan pas ben je verzekerd van een goede herstelprocedure.

Wil je vaker dit soort artikelen lezen? Schrijf je dan hier in en ontvang maximaal eens per twee weken een nieuw artikel in de mailbox.

Breng mij naar dit handboek
Reinout Martens

Reinout Martens

Eigenaar en oprichter van Kaderbreed B.V.

Toen Reinout een jaar of 21 was – hij studeerde nog – zat hij op een feestje, waar iemand vertelde dat er een interim manager bij haar bedrijf gestart was. Een botte boer die, zonder rekening te houden met zorgvuldig opgebouwde gewoontes, relaties, werkverhoudingen, etc. overal de bijl inzette en geen rekening leek te houden met wat dat met de mensen deed. Reinouts eerste gedachte was:

“dat kan anders en ik ga dat bewijzen”.

Breng mij naar dit handboek

Afleiding. Zo komen ICT’ers wél aan hun echte werk toe

Afleiding. Zo komen ICT’ers wél aan hun echte werk toe

by | aug 28, 2018 | Artikelen, Planning, Simpele oplossingen

Afleiding. Zo komen ICT-ers wél aan hun werk toe

Afleiding. Iedereen heeft er last van. Kan je even dit, kan je even dat? En vervolgens keer je terug naar je werkzaamheden en vraag je je af: waar was ik ook al weer mee bezig? Het is bekend dat het maar liefst 20 minuten kost om écht weer de volle focus te hebben bij waar je mee bezig was. Multitasken kan de prestaties van een Harvard-masterstudent terugbrengen tot het niveau van een achtjarige (bron: Tony Crabbe – Nooit meer te druk). Daarom is het van belang dat je extra aandacht besteedt aan zo min mogelijk afleiding als je je ergens op moet concentreren. Bij ICT’ers is het een van de belangrijkste oorzaken waarom meldingen te laat opgelost worden en planningen uitlopen. Daarom hieronder een beschrijving hoe je dat probleem oplost.

De Afleiding van een ICT’er

De belangrijkste afleiding voor een ICT’er is de persoon waar hij of zij het allemaal voor doet: de gebruiker van zijn systemen. Of hij of zij nou langsloopt of belt via de telefoon, een gebruiker heeft in zijn ogen altijd een urgent probleem dat nu opgelost moet worden. En vaak moet dat het ook. Ook in de ogen van een ICT’er. Het is natuurlijk ook moeilijk – en niet de bedoeling – om de persoon waar je het allemaal voor doet af te poeieren met “nu even niet”. Dus wordt de gebruiker natuurlijk geholpen. Gelukkig maar. Maar ondertussen is dat klusje dat net even meer tijd kost wel onderbroken en duurt misschien wel 20 minuten voordat de ICT’er zich weer volledig kan concentreren op waar hij mee bezig was: die nieuwe gebruiker aanmaken, rechten geven op een applicatie, of kijken waarom een gebruiker niet kan inloggen.

Bazen

De tweede en ook moeilijk te weigeren afleiding zijn bazen. De baas van de afdeling van zijn gebruikers of zijn eigen baas. Kan je dit even tussen doordoen, want dit moet echt nu. Dit heeft prioriteit, vaak heeft het dat ook. De baas komt natuurlijk niet voor niks langs. En zeker tegen je eigen baas kan je moeilijk zeggen “wacht even, ik wil even dit klusje afmaken”. De afleiding heeft dan al plaatsgevonden. Zo ben je hup, weer 20 minuten verder.

Een volgende afleiding is een mede ICT’er. Dat is een moeilijke. Want samenwerking in een team is naar mijn mening erg belangrijk. Een collega wil je graag helpen. Er zijn dus hele goede redenen waarom je dat niet zou willen beperken. Die collega is ook bezig met iets dat vast moet gebeuren en waar iemand last van gaat krijgen als het niet gebeurt.

De laatste categorie is ook al weer zo’n begrijpelijke: een grote(re) verstoring. Bij een grotere verstoring kunnen meerdere gebruikers een bepaalde taak niet meer uitvoeren, bijvoorbeeld omdat een bepaalde applicatie eruit ligt. Of werkt voor iedereen een bepaalde functionaliteit niet zoals zou moeten: het netwerk is traag, mailen naar buiten kan niet meer, etc.. In dat geval is het alle hens aan dek . De telefoon gaat veelvuldig. En vaak moeten meerdere mensen van het team aan de bak. En ook dit wil je. Maar het klusje waart de ICT’er mee was blijft wel liggen!

Hoe dit op te lossen?

Als je bovenstaande opsomming ziet, lijkt het probleem lastig op te lossen. Want voor elke afleiding is een valide reden en je wilt niet dat het verzoek van de gebruiker, baas, ICT’er, of de verstoring de helft van de tijd afgedaan wordt met “nu even niet!”. Toch is de oplossing vrij simpel: maak een rooster.

Maak een rooster (in dagen, dagdelen of weken) waarin voor elk soort werkzaamheden voldoende capaciteit ingeroosterd wordt. Welke taken dat zijn beschrijf ik in dit artikel. Vervolgens maak je afspraken in het team wie het aanspreekpunt is/zijn. In grotere organisaties is dat vaak de helpdesk – met alle gevolgen van dien, maar daar hebben we het nu niet over. En maakt goede afspraken hoe je ervoor zorgt dat het aanspreekpunt als eerste aangesproken wordt, de telefoon opneemt, etc.. Misschien moet je iemand daarvoor op een een bepaalde plek zetten of op een andere manier duidelijk maken dat hij of zij het aanspreekpunt is.

Resultaat

In mijn ervaring wordt die manier het aantal afleidingen waar een ICT’er mee te maken heeft met 80% gereduceerd. En wordt van al die afleidingen iedere keer tot 20 minuten concentratie gewonnen. De gebruiker kan geholpen worden en is blij. De baas kan geholpen worden is is blij en de mede ICT’er kan geholpen worden. Dat wil je!

Het is een hele simpele oplossing, maar onderschat de impact ervan niet. Die kan enorm zijn. Denk maar aan het voorbeeld van de Harvard-student die opeens gereduceerd wordt tot achtjarige!

Wil je vaker dit soort artikelen lezen? Schrijf je dan hier in en ontvang maximaal eens per twee weken een nieuw artikel in de mailbox.