Waarom is ICT altijd zo moeilijk?

Waarom is ICT altijd zo moeilijk?

Waarom wordt er altijd zo moeilijk gedaan over ICT? Waarom heerst er altijd een vorm van onvrede rondom ICT? Waarom is op de kwaliteit van het geleverde altijd iets aan te merken en nemen de kosten van ICT steeds meer toe?

Het zijn rake vragen, die ik keer op keer hoor bij mijn klanten. En de antwoorden blijven heel vaak uit. Of liever gezegd: de echte antwoorden blijven vaak uit. Want het riedeltje excuus-antwoorden is namelijk iedere keer hetzelfde: ICT is nou eenmaal ingewikkeld, complex, lastig. Het is overal zo, dus zal het wel moeilijk zijn. Ze werken heel hard. Ze doen ongelofelijk hun best. Ik heb er weinig verstand van. ICT’ers zijn schaars. En ga zo maar door.

Terwijl als we eerlijk zijn en de boel nuchter beschouwen, dan weten we dat het ook anders kan. En dat het ook anders moet. ER blijft altijd een zacht stemmetje op achtergrond zeggen dat het allemaal niet zo ingewikkeld hoeft te zijn. Dat we het gewoon ingewikkeld gemaakt hebben, zonder dat dat nodig is.

Maar hoe zijn we dan toch in die ingewikkeldheid beland? Hoe is dat dan zo gekomen? Het is een vraag die in mijn ervaring alleen maar afleid van wat er werkelijk nodig is om dit probleem op te lossen. Want je weet hoe het simpel kan. En als je gewoon in je geheugen graaft, komt dat heus wel terug. Dus ook daar ligt het niet aan.

Durf ik het dan gewoon niet te zeggen? Ligt het gevoelig? Is het cultuur? Waarschijnlijk allemaal waar. Maar ook dat is weer afleiding. Het ligt aan de cultuur! Ik durf het gewoon niet! Het ligt ‘gewoon’ gevoelig! Allemaal donder goede redenen om er helemaal niks aan te doen. Het probleem is en blijft: je kunt er wel iets aan doen.

Maar hoe dan? Nou, gewoon, door terug te gaan naar de basis: Waarom wilden we dit ook alweer? Welk probleem zijn we aan het oplossen? Wat willen we voor elkaar krijgen? En wanneer is goed goed genoeg? Dát zijn de vragen die je helpen om bovenstaande problemen op te lossen.

Is het dan echt zo simpel? Ja en Nee. Dit zijn wel de vragen die ertoe doen. Maar inmiddels is iedereen wel in een patroon (sleur) terechtgekomen waarin het verdomd comfortabel zonder verantwoordelijkheid is geworden. Dus niet iedereen staat te springen om er nu wél iets van te maken. Je krijgt dus te maken met weerstand. En dat moet je als zodanig herkennen en daar de juiste actie tegenover zetten. Anders ga je nat. Maar in basis: ja, zo simpel kan het zijn. Iedereen kan tegenwoordig een boek bij bol.com bestellen. Dus iedereen kan verzinnen hoe ICT zijn of haar werk beter, makkelijker, efficiënter, effectiever, etc. kan maken. Als dat helder is, moet ICT het gewoon gaan maken.

Maar waarom lukt het dan zo vaak niet? Goede vraag. Omdat mensen ICT liever aan ICT’ers laten. En, met alle respect, dan gaat het fout. ICT’ers zijn namelijk graag met techniek bezig. En willen je graag verder helpen met de nieuwste oplossingen. State Of The Art. Sommige managers lopen er zelfs mee te pronken. Maar dan wordt ICT inderdaad ingewikkeld. Wat de meeste ICT-oplossingen hoeven helemaal niet ingewikkeld te worden. En dat moet je dus niet laten gebeuren. Stel de vragen. Welk probleem lossen we op? En is deze oplossing dan het meest passend? Daag ze uit. Blijf kritisch. En neem alleen genoegen met antwoorden die je begrijpt.

Maar Reinout, er is toch vast meer nodig om ICT succesvol te krijgen? Ja, dat klopt. Er is structuur nodig. Er is communicatie nodig. En er is ander gedrag nodig. Zowel door de ICT’ers als door de mensen waarvoor zij ICT maken, leveren, aanpassen en verder ontwikkelen. Maar dat kan je pas goed inrichten, als je eerst met elkaar bepaald hebt wat ICT voor je kan/moe betekenen. Daarna volgt inderdaad nog een flink set met organisatorische punten.

Bij Kaderbreed zijn we echt experts in het stellen van dit soort vragen. Wij kunnen je dus als geen ander helpen met het stellen van de juiste vragen. En de zin van de onzin onderscheiden. Het zal een verademing voor je zijn. Hèhè, eindelijk die ICT weer eens simpel voor me maakt. Die mijn taal spreekt. En mij begrijpt. Iemand die ICT kan uitdagen om de juiste dingen te doen. En mij kan helpen de structuur, organisatie en communicatie op gang te brengen zodat het gaat vliegen.

Dus als je de volgende keer weer eens bij een eindeloos saaie opsomming van technische termen zit, denk dan eens aan ons. Wij kunnen je verlossen van het oeverloos gezever. Van de eindeloze spreadsheets met het zoveelste plan van aanpak. Het gaat je niet helpen. Het levert alleen maar meer ballast op. Waardoor ICT’ers nog minder aan hun werk toekomen. En de mensen die hen moeten voeden met de juiste input. Het is allemaal zo zonde. Zo zonde van het geld, de tijd, de inspanning, de motivatie. En van mensen die hun stinkende best doen. Mensen die iedere keer gefrustreerd raken, omdat de resultaten uitblijven. Omdat de complimenten uitblijven.

Dus pak die telefoon en ga voor die klinkende resultaten. Het kan gewoon! Het kan beter! Het kan goedkoper! ICT kan wel degelijk een succes worden. Dat wil jij toch ook? Daar wil jij toch onderdeel van zijn? Dat wil je toch niet aan je neus voorbij laten gaan?

Dus laat ons je vertellen hoe we je verder kunnen helpen:

Hij was er al 5 jaar op aan het wachten

Hij was er al 5 jaar op aan het wachten

Een mooi voorbeeld van digitalisering. Niet zozeer omdat klanten nu iets konden, wat ze voorheen niet konden. Maar omdat hij iets kon, wat hij daarvoor niet kon: zijn verantwoordelijkheid nemen door helder zicht te krijgen op de cijfers die voor hem belangrijk waren. Dus besluiten nemen op basis van feiten in plaats van op indrukken.

En, zoals ik al zei, hij was er al 5 jaar op aan het wachten. Toch was het uiteindelijk niet moeilijk om het door hem gewenste dashboard te implementeren.

Maar waarom lukt het nu wel? En al die andere keren de afgelopen 5 jaar niet? Wat maakte het verschil. Het verschil zit hem in een viertal dingen.

De eerste stap die wel namen was het op papier zetten welke informatie dat dashboard moest bevatten. Welke meters moeten erin? En waar halen we die gegevens vandaan? En hoe berekenen we dan vervolgens die meters? Het klinkt logisch, en dat is het ook. Maar geloof mij: er zijn hele volksstammen die deze stap gewoon niet nemen. En dit kostte echt wel een paar meetings van een uur of langer om dit helder te krijgen. Pas als je dingen concreet gaat maken, blijkt het lastig om het precies te weten.

Toen we wisten wat we wilden hebben, zijn we gaan kijken naar de oplossing die erbij hoort. De eerste schattingen van de IT-specialisten kwamen uit op 2 tot 3 ton. Dat was veel te duur voor een simpel dashboard. Pas toen we de juiste vraag aan de IT-specialisten stelden, kwamen ze met een voorstel dat wel betaalbaar was. Dat zien we vaker. Dat er een aantal aannames gedaan worden, die helemaal niet relevant zijn. 24 uur beschikbaarheid bijvoorbeeld. Of alle gegevens centraal in een database. Allemaal niet relevant. En veel te duur. Of een automatische import. Voor een keer maand?

Toen we wisten wat we nodig hadden en hoe de oplossing eruit moest zien, was het tijd om de juiste mensen erbij te halen. In dit geval een BI-specialist. Nu zijn die er in veel soorten en maten. En de meesten hadden ruime ervaring bij banken en verzekeringsmaatschappijen. En zaten in een technische omgeving. Met technische mensen. Over technische zaken te praten. Vast heel kundig. En ervaring genoeg in Power BI. Dat zeker. Maar wij hadden iemand nodig die met management kon praten. Die kon luisteren. Die hun wereld kon begrijpen en begrijpen wat zij belangrijk vonden. En vooral hen kon adviseren, wat met zijn of haar ervaring nog meer belangrijk kon zijn. En die vonden we.

Als laatste zetten we een overlegstructuur neer, waarmee voortdurende bijsturing kon plaatsvinden. De Sprint Review en Dagstart uit Scrum in dit geval. Als een soort zeilboot die voortdurend op koers gehouden moet worden. Hierdoor ontstond een steile leercurve. Zowel voor gebruikers als techneut.

Zoals je ziet is er niet veel nodig voor een succesvol digitaliseringstraject. In ieder geval geen superzwaar IT-project dat tonnen met geld gaat kosten.

Wil je weten hoe we bij Kaderbreed jouw digitalisering simpel kunnen maken? Neem dan contact met ons op. Als jij ons vertelt wat je wilt en wat je al gedaan hebt, kunnen wij je precies vertellen wat je mist. En het eerste gesprek is geheel vrijblijvend!

Zo werk je effectief samen met je IT-organisatie

Zo werk je effectief samen met je IT-organisatie

De kern van elke effectieve IT-organisatie en elk succesvol IT-project wordt gevormd door een effectieve samenwerking tussen de mensen die die IT moet maken/inrichten/leveren en de mensen die dit IT uiteindelijk moeten gaan gebruiken.

Een goede opdrachtomschrijving

Dat begint al met een goede opdrachtomschrijving. Wat moet het uiteindelijk opleveren? In onze ervaring zijn de volgende elementen van belang:

  • Aanleiding: Waarom doen we dit eigenlijk? Welke ervaring of gebeurtenis heeft ons doen besluiten om dit te gaan doen?
  • Doelstelling: Wat willen we uiteindelijk hiermee bereiken?
  • Resultaten: Wanneer zijn we succesvol?
  • Scope: Wat hoort er allemaal wel bij en – vooral – wat niet?
  • Betrokken partijen: Wie zijn er allemaal betrokken bij dit traject? Wie moeten het maken? Wie vertellen of het goed (genoeg) is? Wie gaan het straks allemaal gebruiken? Wie moeten op de hoogte gehouden worden? En wie gaan de effecten van wat we doen straks allemaal merken?

De juiste mensen

De tweede stap is de juiste mensen erbij betrekken. Aan de kan van de gebruikers is dat iemand die goed kan communiceren met de rest van de gebruikers en namens hen beslissingen kan en mag nemen. Meer daarover in dit artikel. Aan de kant van IT is dat iemand die niet alleen verstand heeft van IT maar ook goed kan communiceren. Die de voordelen en nadelen van elke oplossing goed kan uitleggen in gewone mensentaal. En die open staat voor meerdere wegen naar Rome. En vooral bezig is met gebruikers gelukkig maken in plaats van mooie IT-systemen te bouwen

Regelmatig overleg

De derde stap is regelmatig overleg tussen de juiste mensen. Bespreek wekelijks de voortgang en haal daarin vooral feedback van de gebruikers op. De Sprint Review is daar een mooi format voor. Wat hebben we gemaakt, wat is er goed aan en wat kan er beter? Wat zijn de keuzes en wat zijn de voordelen en nadelen ervan? Waarom kiezen we voor het een en niet voor het ander? Op die manier leren IT’ers steeds beter wat van belang is en wat niet.

Wil je vaker dit soort dit soort nuttige informatie ontvangen? Schrijf je dan in voor onze wekelijkse kennismail. Je ontvangt dan wekelijks een mail waarin we onze belangrijkste inzichten van de afgelopen week met je delen.

Waarom alleen IT’ers rapportagetools bedienen

Waarom alleen IT’ers rapportagetools bedienen

Binnenkort staan we weer voor de uitdaging een Business Intelligence-oplossing neer te zetten. Power BI in dit geval.

Bij Kaderbreed proberen we dat altijd zo in te richten dat de software gaat werken zoals bedoeld is. In het geval van BI is dat een eindgebruiker die een eindeloze hoeveelheid rapportages kan maken op basis van een goed opgezette dataset.

Nu blijf ik mij verbazen dat BI-tools (Power BI, Tableau, Qlikview) voornamelijk bediend worden door IT’ers en vergelijkbare functies. Dat is al zo sinds mijn eerste kennismaking met dit soort oplossingen in 2000.

Daarom vroeg ik op LinkedIn: Waarom denken jullie dat het zo moeilijk is voor eindgebruikers om een rapportagetool zelf te bedienen?

Het regende reacties. Hieronder de belangrijkste conclusies.

Waar het niet aan ligt (meestal):

  • de keuze van het softwarepakket;
  • de kennis en vaardigheden van de IT-afdeling;
  • de capaciteiten van je medewerkers;
  • het besluit over te stappen naar professionele software.

Waar het wel aan ligt (meestal):

  • de manier waarop het softwarepakket ingericht is: werkstromen, structuur van de gegevens, aansluiting op het werkproces, etc.;
  • de werkprocessen voor de invoer en bewerking van, en rapportages over de gegevens in het systeem;
  • te weinig betrokkenheid van gebruikers bij de inrichting van het softwarepakket;
  • geen duidelijkheid over de doelen van de invoering van het softwarepakket: welk probleem willen we hiermee oplossen of welke (nieuwe) mogelijkheden willen we hiermee creëren?
  • kwaliteit van de gegevens waarmee gestart wordt;
  • geen of te weinig opleiding van de gebruiker hoe de software te gebruiken;
  • geen of te weinig sturing en/of betrokkenheid vanuit het management; vaak is een verandering nodig in de organisatie en/of de werkprocessen om het softwarepakket succesvol te implementeren.

Zo zie je: de belangrijkste oorzaken van slechte IT-systemen liggen buiten IT. Die liggen meestal op de afdeling waar de software wordt gebruikt. De manager van die afdeling heeft dus de meeste invloed op het succes van de software. Maar dan moet je wel weten hoe je dat moet doen.

Wil je een keer vrijblijvend met ons hierover sparren? Neem dan contact met ons op. We voorzien je graag van enkele concrete adviezen waarmee je software al een stuk effectiever kan worden. We horen graag van je!

Zo ga je om met je afhankelijkheid van IT

Zo ga je om met je afhankelijkheid van IT

We worden steeds afhankelijker van IT. De huidige pandemie toont eens te meer aan hoe afhankelijk we van IT-systemen geworden zijn. Het wordt tegenwoordig domweg niet meer geaccepteerd dat IT-systemen niet voorbereid zijn op zoiets onverwachts als het wereldwijde Covid-19. Dat blijkt ook wel uit de analyse die het ministerie van VWS heeft laten uitvoeren op de IT-keten voor de bestrijding van de Corona. Omdat iedereen tegenwoordig weet wat IT voor hen kan betekenen, worden mindere oplossingen niet meer geaccepteerd. Niet door klanten, niet door gebruikers en niet door de Nederlandse burger.

Iemand schreef op tweakers.net: “Goed, maar als vorig jaar de overheid een groot IT-project gestart had om een fenomenaal schaalbare infrastructuur voor een pandemie te maken had iedereen het hier belachelijk gevonden.” In een reactie op mijn post schreef iemand op LinkedIn daarover: “Net als de Deltawerken moet IT aan lage kans hoog risico-eisen voldoen. Dus zou een pandemie altijd onderdeel moeten zijn van de beschikbare software voor gezondheidszorg.”

Dat is de spijker op zijn kop. Zo moet je omgaan met je afhankelijkheid van IT. Breng je risico’s in kaart. Bij Kaderbreed werken we vaak met Failure Modes and Effects Analysis (FMEA).

De basis hiervoor kan je in 1 uur leggen:

  • Houd een gestructureerde brainstorm waarin een team van mensen nadenkt over wat er fout kan gaan met IT. Breng mensen samen uit verschillende werkomgevingen en disciplines. FMEA werkt het beste in een samenstelling uit zoveel mogelijk disciplines;
  • Breng van elke mogelijke fout in kaart (bijvoorbeeld op een schaal van 1 tot 5):
    • hoe ernstig ze zijn;
    • hoe vaak ze voorkomen;
    • hoe waarschijnlijk het is dat ze worden opgemerkt als ze zich voor doen;
  • Richt verbeterinitiatieven op de fouten die het vaakst voorkomen, ernstig zijn als ze zich voordoen, en waarvan het onwaarschijnlijk is dat ze worden herkend.

Bij Kaderbreed zetten we zo’n FMEA uiteraard graag voor je op. Inclusief voorbereiding is dat met één consultant in een dag te doen. Hoe dat in zijn wek gaat is hier beschreven.

De kracht van een goede Product Owner

De kracht van een goede Product Owner

Het was een drukbezochte sessie. Uit alle hoeken van het land waren ze bijeen gekomen om het ontwerp van hun nieuwe website bij te wonen. Niet zomaar een website. De website die een belangrijk deel van hun werkzaamheden ging vervangen. We konden dus behoorlijk wat kritische vragen verwachten.

De Product Owner, het brein achter de website en de maker van het ontwerp hadden zich goed voorbereid. De 10 meest voor de hand liggende vragen hadden ze stuk voor stuk doorgenomen, voorzien van een antwoord en die vooraf geoefend. Maar natuurlijk kon je niet alle vragen vooraf bedenken. En dat geeft ook niet. Als je je werk goed gedaan hebt, hoef je daar ook helemaal niet bang voor te zijn.

Het begon met de presentatie van het ontwerp. Daarna gelegenheid voor vragen. De eerst vraag: waarom hebben jullie niet zo en zo gekozen, in plaats van hoe het nu is? Het antwoord: daar hebben we over nagedacht. En heel bewust niet voor gekozen. Om nadeel a, b en c te voorkomen. Volgende vraag. Waarom niet def gekozene in plaats van pqr? Zelfde soort antwoord: daar hebben we over nagedacht en bewust niet voor gekozen. Op de derde vraag kwam een vergelijkbaar antwoord en toen verstomde de kritiek. De toon van de vragen werd anders en er werd meer geïnformeerd over het waarom van bepaalde keuzes. Na drie kwartier waren zo’n beetje alle vragen beantwoord en ging iedereen overtuigd van het nieuwe ontwerp weer naar huis.

De kracht van een goede Product Owner

Bovenstaande is een goed voorbeeld van wat ik noem: de kracht van een goede Product Owner. “Om te kunnen slagen als Product Owner, moet de gehele organisatie zijn of haar beslissingen respecteren” (Scrum Gids™, juli 2013). En dat is precies wat in bovenstaand voorbeeld het geval was. Daarom was de sessie succesvol – los van een goede voorbereiding natuurlijk.

Te vaak zien we voorbeelden van Product Owners die lukraak beslissingen nemen vanuit wat zij denken dat goed is. Of vanuit hun eigen ervaring in het werkveld. Of nog erger: een IT’er die naar voren wordt geschoven als vertegenwoordiger van de gebruikers. Bij gebrek aan beschikbaarheid van een echte Product Owner. Hetzelfde gebeurt met functioneel beheerders zonder acceptatie van de gebruikers. Dan heb je als organisatie echt een probleem.

Norman Maier zei het al in 1963: Effectiviteit = Kwaliteit x Acceptatie. Dus het effect van je IT is gelijk aan de kwaliteit van je keuzes x de acceptatie door gebruikers. Daarom is het zo belangrijk om te overleggen met je gebruikers. Want zowel de kwaliteit als de acceptatie stijgt erdoor.

Bij Kaderbreed we altijd veel aandacht aan de juiste man (m/v) op de juiste plek. Zeker als het gaat om de Product Owner. Want als de beslissingen op de juiste plek belegd worden, krijg betere besluiten. Die beter geaccepteerd worden. En daarmee dus effectieve besluiten. Met de juiste besluiten wordt de juiste IT ontwikkeld. En daarmee de IT die een organisatie nodig heeft. Organisatie blij, IT’ers blij, wij blij.