Directe link:
Directe link:
Een schaalbaar en gezond bedrijf moet gebouwd worden als een systeem. Dat kunnen we van Michael Gerber leren. Een bedrijf moet een samenstel van processen zijn die het gewenste en consistente resultaat geven waar de klant op zit te wachten.
Deze processen kunnen en moeten natuurlijk continu worden verbeterd. Daartoe heeft Gerber het Business Development-proces beschreven. Dit gaat dus niet over externe relaties, zoals we Business Development over het algemeen beschrijven, maar over de ontwikkeling van het bedrijf zelf. Gerber’s Business Development proces zorgt ervoor dat de prestaties van het bedrijf worden gemeten en dat processen worden aangepast. Waarna de prestaties opnieuw worden gemeten.
Een geborgd proces zonder ondersteuning vanuit ICT is inmiddels onmogelijk en onwenselijk. ICT levert de middelen waarmee processen sneller gedaan kunnen worden. En meetbaar, beter afgestemd en inzichtelijk voor de klant; essentieel voor het onderscheidend vermogen van bedrijven de komende jaren!
Van die professionele ICT-wereld kunnen we wat leren. Want ICT wordt in Releases uitgebracht, van alfa via beta naar productie-releases. Als het goed is, getest en wel in een OTAP-reeks: ontwikkeling, test, acceptatie en productie. Er is een aparte omgeving, afgeschermd, waar de ontwikkeling (O) wordt gedaan. Dan volgt een aparte omgeving waar de testen (T) van het nieuwe product of de features worden gedaan. Vervolgens een aparte omgeving waar de acceptatie (A) door de klant kan worden gedaan. En pas na acceptatie gaat de nieuwe functionaliteit live in de productieomgeving (P).
Stel dat bedrijven als geheel gaan werken in Releases en met OTAP. Dus niet alleen voor de ICT maar ook voor de organisatie, de processen en de procesbeschrijvingen. Zodat het hele bedrijf op een vast punt in de tijd wordt gewijzigd. Laten we zeggen: ieder kwartaal. En dat er tussentijds geen wijzigingen worden doorgevoerd om de noodzakelijke stabiliteit en rust te houden.
Alle mogelijke problemen en ideeën worden besproken in teams die met voorstellen voor nieuwe processen en verbeterde ICT komen (O). Na ontwikkeling worden de veranderingen met een aantal personeelsleden getest (T). Als dat naar behoren is verlopen, wordt een proefafdeling gevraagd proef te draaien met het nieuwe proces. Pas als deze afdeling akkoord is, wordt het geaccepteerd (A), en kan het bij een volgende ‘release’ live worden gezet, oftewel bedrijfsbreed worden ingevoerd en gecommuniceerd.
Een verbetering die niet door de testen of acceptatie komt, kan in een volgende release opnieuw worden meegenomen. Een Business Development manager of COO houdt overzicht over het ritme en het geheel. Ieder kwartaal presenteert hij/zij een bulletin met de proceswijzigingen en de achterliggende redenen en doelen. Zichtbaar voor iedereen. Geen eilanden meer.
Wat zijn daarvan de voordelen? Iedereen in het bedrijf is zich bewust van de geldende processen en van het moment dat eventuele wijzigingen doorgevoerd kunnen worden.
Er zijn geen afstemmingsproblemen meer omdat wijzigingen in het ene proces een effect hebben op het andere proces in de organisatie. Of onverwachte bij-effecten.
Tenslotte, voedt het de organisatie op met het idee dat de processen het centrale deel van de organisatie zijn. Niet de mensen dus. Gerber is er duidelijk over: met buitengewone mensen kun je geen betrouwbaar bedrijf bouwen. Niet de mens centraal, maar het proces. Wat overigens een mens niet degradeert tot productiemiddel a la ‘modern times’ maar hem de ruimte geeft om zijn talent en creativiteit toe te passen. Uiteraard moeten processen gebruik maken van de veelzijdigheid van ieder mens. Maar niet van iemand in het bijzonder. Maak nooit de bijzonderheden van mensen leidend voor je proces, hoe getalenteerd ze ook zijn!
Het nadeel van het werken in releases? De organisatie moet met meer rigor en discipline met zijn veranderingen omgaan en kan niet meer ad-hoc en opportuun wat wijzigen. Ook niet tussentijds. Al zou dat laatste in een noodgeval natuurlijk altijd blijven kunnen net als een tussentijdse release om ‘hacks’ te dichten. Dit nadeel van rigor en discipline is, denk ik, eigenlijk een voordeel.