Wendbaarheid en standaard-IT

Uit reacties hoor ik vaak dat wendbaarheid en standaard software op gespannen voet met elkaar staan. Is dat wel zo? Ik maak vaak de vergelijking met mijn auto; een volstrekt standaardproduct, maar de wendbaarheid is dik in orde. De truc is natuurlijk dat een auto heel veel functionaliteit biedt waarmee je je eigen wensen kunt invullen (stuur, gas, navigatie, radio), maar ook die van je omgeving (rem 😊 ). Of vergelijk het met LEGO; een volstrekt standaardproduct, waarmee je toch vreselijk creatieve dingen kunt maken.

Het is dus helemaal niet moeilijk om met standaard spullen toch wendbaar te zijn. Persoonlijk spreekt mij dat erg aan. Iets te vaak wordt gedacht dat je voor externe wendbaarheid ook intern alles elke dag moet aanpassen. Dat is een fundamentele gedachtefout. Die gedachtefout leidt er toe, en dat doet mij echt verdriet, dat bedrijven en de medewerkers in een eindeloze, steeds harder draaiende carrousel terecht komen. Is dat nu werkelijk wat we willen?

We moeten niet steeds harder gaan werken. We moeten slimmer gaan werken. Met flexibele spullen, zodat je wel, elke dag weer, aan klantverwachtingen kunt voldoen. Maar daarnaast vooral dat je zelf ook nog een beetje leuk functioneel leven overhoudt.

Functioneel beheer bij standaard-IT

Steeds meer bedrijven maken uitsluitend gebruik van standaardsoft- en hardware. Vroeger was dat voorbehouden aan bedrijven met een omvang tot een paar honderd medewerkers. Langzamerhand zijn er ook organisaties met duizenden medewerkers die geen enkele software meer intern ontwikkelen. Alles wordt standaard ingekocht. Wordt als gevolg daarvan binnen een dergelijk bedrijf alles standaard? Zeker niet. Een tweede ontwikkeling is namelijk dat standaard software steeds flexibeler wordt; grote hoeveelheden parameters zorgen ervoor dat de match met de gewenste bedrijfsprocessen, producten, diensten en behoefte aan informatievoorziening zo goed mogelijk wordt gemaakt.

Gek genoeg gaan vrijwel alle discussies en boeken over Agile, Scrum, DevOps en wat al niet meer. Maar het overgrote deel van de organisaties waar ik elk jaar kom heeft daar dus nauwelijks mee te maken. En alle key-users, functioneel beheerders, informatiemanagers, i-adviseurs, informatiearchitecten en hun management dus logischerwijs ook niet. Ze oordelen dan ook dat BiSL op onderdelen kennelijk voor “andere bedrijven is bedoeld”. Maar dat zou niet zo moeten zijn.

Het lijkt mij een gat. Wordt het niet hoog tijd om eens een gedegen uitwerking te maken van hoe wij functioneel het beste om kunnen gaan met volstrekt standaard-IT binnen het bedrijf?  Waarbij we functioneel tegelijkertijd wel te maken hebben met een specifieke klantwensen? Hoe loopt dan een change traject? Daarnaast moeten we natuurlijk call-afhandeling, waarbij je bij standaard-IT veel afhankelijker bent van IT, niet vergeten. Of architectuur; in gemeenteland wordt niet voor niets steeds meer teruggegrepen op Gemma-2, een referentiearchitectuur waarbinnen elke gemeente toch zijn specifieke weg probeert te vinden. En zo zijn er talloze onderwerpen die bij standaard-IT er allemaal net even anders uitzien.

Mijn voorstel: zullen we in kleine stapjes (Agile? 😊 ) elk aspect van functioneel beheer (of BIM, als die omschrijving u meer aanspreekt) in een volstrekt standaard IT-omgeving gaan uitwerken? Het lijkt mij een goede zaak. Een soort “BiSL -light” of zoiets.

Ik gooi het bij deze in de groep… Graag uw reactie hieronder.

BiSL Next – Zijn BiSL en Agile te combineren?

Een vraag die steeds meer opduikt is of BiSL past binnen Agile, of de meest gebruikte werkwijze daarbinnen: Scrum. Dat is een gekke vraag. Echt een heel gekke vraag. In dit artikel wordt uitgelegd waarom.

BiSL vertrekt vanuit het perspectief van de klant. Je zou zeggen; de enig mogelijke vertrekroute. Agile is bedacht door IT’ers. Die aan de IT-zijde werk(t)en en een IT probleem wilden oplossen; waarom liepen veel IT-projecten niet zo goed als zou moeten? Vandaag de dag vertellen die IT’ers in volle zalen dat ieder bedrijf een Agile-bedrijf moet worden. Maar IT’ers die aan klanten gaan vertellen wat ze moeten doen, die moet je diep, diep wantrouwen.

De vraag of BiSL binnen de Agile mindset past is dus een vraag die verkeerd-om is gesteld. We starten immers bij de klant, dus met BiSL (of FSM, of MCTL, wat u wilt). Vandaaruit kunnen we met IT bekijken wat de beste route is voor de realisatie. En dat zou kunnen met Agile/scrum. Maar ook met een project zoals we dat al jaren kennen via Prince2. Of…

IT lijkt wel een gereedschapskist te hebben die zo klein is dat er maar één werkmethode in past. Vroeger projectmatig werken, nu scrum, en wat zal het over een paar jaar zijn? IT moet eens leren dat een fatsoenlijke gereedschapskist een aantal verschillende tools bevat en dat daar verschillende vaardigheden bij horen. Die je naast elkaar kunt gebruiken.

Het is feitelijk volstrekt idioot dat je zo naar Bunnik kunt bellen en een woontoren van 150 meter hoog kunt bestellen. Of een voetbalstadion. Tuurlijk zullen ze dan bij BAM (want dat bouwbedrijf zit in Bunnik), nog wel een heleboel vragen hebben over wat je als klant precies wil. Maar daarna wordt het gewoon gebouwd. Projectmatig. Als je naar IT toegaat en iets wilt, dan is het altijd moeilijk moeilijk en voor je het weet zitten ze op de klantstoel. En bepaalt IT hoe er gewerkt gaat worden. En moet je als klant dagelijks als “product owner” opdraven omdat het anders niet goed gaat.

We moeten als klant IT eens goed aanpakken. Stel dat wij een project willen omdat we onze externe klanten over een half jaar willen verrassen met een echt nieuw product. Zoals Apple dat ook doet met een mooie big-bang productlancering. IT sputtert meteen tegen en begint over een “minimum viable product”. Goed idee, maar in dit geval willen we die aanpak niet. Omdat we de concurrentie flink willen aftroeven, een enorme stap vooruit willen maken, in the picture willen komen. Er zijn duizend redenen te verzinnen waarom je als bedrijf in één keer met iets naar buiten wil komen. En niet een product in veel kleine stapjes creëren waarbij we weliswaar tussentijds kunnen leren, maar niet bereiken wat we willen. En de risico’s van het project? Die horen erbij.

Een volgende keer willen we juist wel met kleine stapjes een innovatief product ontwikkelen en zoveel mogelijk aan de hand van concreet gebruik ervan verbeteren. Dat klinkt toch heel erg Agile… En de keer daarop…

Als klant willen we gewoon een IT die kundig is. Kundig in verschillende werkwijzen om iets gerealiseerd te krijgen. Een mooie volle gereedschapskist. Is dat nu werkelijk teveel gevraagd?

IT heeft zijn zaakjes intern gewoon niet op orde. Vroeger liepen projecten niet goed, nu is al op veel plaatsen te beluisteren dat Agile ook niet lekker loopt… Ze moeten hun vak gewoon eens goed gaan uitwerken zodat de resultaten verbeteren en  niet de klant lastig vallen met steeds weer een nieuwe trend, hype, mindset of hoe het dan ook elke keer wordt herverpakt.

Moeten we ondertussen aan de klantzijde ook wat doen? Zeker. Aan de klantzijde is nog iets te vaak toch niet goed doordacht wat de werkelijke behoefte is. En wat meer standvastigheid tijdens de uitvoering, waardoor niet per dag de ene prioriteit wordt ingewisseld voor de andere, kan ook geen kwaad.

Conclusie: Ondanks de huidige populariteit van Agile/scrum moeten we niet vergeten dat ook dit binnen BiSL moet passen, en niet andersom. We zullen dan vanzelf gaan zien dat Agile/scrum soms vreselijk goed werkt, en soms ook helemaal niet. Dat is helemaal niet erg; met een goed gevulde IT-gereedschapskist kunnen we aan de klantzijde precies krijgen wat er nodig is. En dat is het enige wat telt.

Onze aanraders

Het basisboek “BiSL Next – in uitvoering” en de bijbehorende courseware kunnen wij van harte aanbevelen: