Veranderingstrajecten brengen nieuwe risico’s met zich mee

Veranderingstrajecten, het tempo waarin de wereld verandert is groter dan ooit. Vroeger reed bus 52 jaren achtereen dezelfde route, inmiddels is de busonderneming al drie keer gefuseerd en bus 52 is opgesplitst in de lijnen 124, 126 en 136. Gemiddeld om de twee jaar wijzigt de dienstregeling en men is nog niet tevreden. De computertechnologische ontwikkelingen nemen ook in een snel tempo toe. Toen IBM halverwege de jaren 80 de PC introduceerde kon men nog niet vermoeden welke veranderingen dit zou betekenen. Met name het steeds krachtiger worden van computers biedt steeds meer nieuwe toepassingen voor gebruikers. Het einde is voorlopig nog niet in zicht. Tegelijkertijd verandert ook het werk van de gebruiker. Deze veranderingen noemen we Technology-driven en komen met name voor in bedrijven die zich vanuit een concurrentiepositie niet kunnen veroorloven achter te blijven, ze zijn eigenlijk verplicht om voorop te lopen.

Externe factoren bij veranderingstrajecten

Aan de andere kant zijn er organisaties die moeten veranderen omdat de buitenwereld verandert. Dit stelt andere aan hen. Bij deze veranderingstrajecten zoeken we naar technologieën die deze eisen het beste ondersteunen. Het ligt voor de hand om hiervoor de nieuwste, doch beproefde technologieën te kiezen zodat ze hiervan zolang mogelijk kunnen profiteren.

De momenten waarop veranderingen zich aandienen hebben alleen marktleiders enigszins in de hand. Hoelang een bedrijf marktleider is blijft in de software-industrie echter een onzekere factor. Veranderingen die we doorvoeren aan de hand van politieke besluitvormings­pro­cessen zijn veel grilliger en zijn ook moeilijk te plannen. We moeten daarom zoeken naar methoden om de veranderingsprocessen te beheersen.

Veranderingstrajecten aanpakken met Business Analyse

Het is niet noodzakelijk om voor iedere verandering een Busisness analyse te maken. Soms liggen de veranderingen zo voor de hand dat we al direct een kleine wijziging in een program­ma kunnen doorvoeren. Bij meer complexe wijzigingen moeten we een ontwerp maken, vaak vooraf gegaan door een Informatie Analyse.

Een Business analyse maken we als de wijzigingen zeer complex zijn en inzicht nodig is in het aantal uit te voeren projecten en de looptijd daarvan. De Business analyse geeft inzicht in de werkzaamheden en veranderingstrajecten van minimaal drie jaar en vormt eveneens de basis voor een investeringsplan. In veel organisaties is het de gewoonte om elke drie jaar een Business analyse te maken. Zo borgen we de vooruitgang van het bedrijf en voorkomen we ook paniekacties. Daarbij stippelen we een beleid uit voor de geleidelijke vervanging van (delen van) informatiesystemen. De Business analyse geeft aan welke informatiebehoeften er zijn/gaan ontstaan. Hij sluit aan op de overige ontwikkelingen binnen de organisatie. Bij goedkeuring van het plan door het manage­ment is de weg vrij voor gestructureerde investeringen. Dit zonder telkens uitleg op begrotin­gen te hoeven geven.

Business analyse stuurt veranderingstrajecten aan

Een Business Analyse moet een volledig inzicht geven. Per situatie kan de diepgang van een Business analyse echter verschillen. Als al voor een platform is gekozen en men is daar tevreden over, hoeven we dit niet uit te werken. Het is echter wel zaak om zo’n beslissing in het rapport te vermelden. Anders is niet duidelijk is op welk platform we nieuwe projecten gaan realiseren.

In de Business analyse komen een aantal vaste onderwerpen voor die we hier nader toelichten:

Analyse huidige situatie als input voor veranderingstrajecten

In veel veranderingstrajecten slaan automatiseerders een analyse van de huidige situatie over. Ze beginnen, ten onrechte, direct al met een analyse van de gewenste situatie. Hieruit vloeit dan vaak een ideaalbeeld voort dat we later aan de praktijk moeten aanpassen. Als we beginnen met een analyse van de huidige situatie zijn direct alle praktische problemen in beeld. Zodoende kunnen we toekomstig werk besparen. De resultaten van deze activiteit dienen duidelijkheid te geven over de volgende vragen :

• Zijn alle huidige functies binnen de organisatie in beeld gebracht?
• Is de huidige werkwijze in beeld gebracht?
• Zijn alle gebruikte (handmatige)informatiesystemen in kaart gebracht.
• Komen alle knelpunten in de informatievoorziening boven water?
• Zijn alle gebruikte informatiesystemen in beeld gebracht.

Taakstelling en verwachtingen

Een verandering binnen een bedrijf vindt zijn oorsprong in een veranderde taakstelling voor dat bedrijf. Daarbij verandert tevens de taakstelling van medewerkers. De gewenste situatie komt tot stand doordat mensen zich daarvan een voorstelling maken, een verwachting. Zolang hiervan geen nauwkeurige analyse op papier is gezet zal de verwachting van mens tot mens verschillen. En daarmee de verwarring. De resultaten van deze activiteit dienen daarom duidelijkheid te geven over de volgende vragen :

• Is de toekomstige werkwijze in beeld gebracht?
• Is de gewenste informatievoorziening per bedrijfsfunctie in beeld gebracht?
• Zijn alle (mogelijke) bedrijfswijzigingen beeld gebracht?
• Is vastgesteld welke informatie nodig is om de concurrentie voor te blijven?
• Is in beeld gebracht welke informatiebehoeften het toekomstig management zal hebben?

Organisatie informatievoorziening

Voor een veranderingstraject dienen we vast te leggen hoe informatievoorziening georganiseerd is. Op basis van deze beschrijving kunnen we projecten in gang zetten. De volgende zaken dienen te zijn beschreven :

• De binnen de organisatie tot standaard verheven hard- en software omgeving.
• Een SaaS en cloud-first strategie aanwezig?
• Eisen waaraan de aan de hard- en software omgeving (in de toekomst) moeten voldoen.
• De organisatie van de ontwikkeling en invoeren van programmatuur.
• De wijze waarop de apparatuur over de organisatie is verdeeld (centraal of decentraal).

Het onderkennen van informatiesystemen (die geraakt kunnen worden in veranderingstrajecten)

Aan de hand van de vastgestelde toekomstige informatiebehoeften en taakver­deling binnen de organisatie kunnen we de verschillende informatiesystemen onderkennen. Bij deze analyse dienen we de be­staande informatiesystemen niet automatisch als apart systeem te onderkennen. We moeten eerst een objectieve verdeling maken, de inpassing van bestaande systemen kan hierna plaatsvinden. Deze activiteiten om dienen inzicht te geven in de volgende vraagstukken:

• Is er sprake van centrale of decentrale informatievoorziening?
• Is rekening gehouden met het gemeenschappelijk gebruik van gegevens?
• Zijn alle bedrijfsprocessen over de onderkende informatiesystemen verdeeld?
• Is ook rekening gehouden met de mogelijke koppeling van systemen?
• Is aangegeven welke systemen (en hun eisen) minimaal per bedrijfsfunctie nodig zijn?

Het onderscheiden van entiteitgroepen

Bij het gebruik een omvangrijke database met gegevens is mogelijk om verschil­lende informatiesystemen daarvan tegelijkertijd gebruik te laten maken. Zo zien we bijvoorbeeld steeds vaker in een centrale database met relaties waaruit alle informa­tiesystemen kunnen putten. De volgende vragen t.a.v. entiteitgroe­pen moeten we in de Business analyse beantwoorden :

• Welke gegevens zijn per informatiesysteem nodig?
• Welke gegevens hebben informatiesystemen gemeenschappelijk?
• Hoelang en hoe moeten de gegevens bewaard blijven?
• Op welke plaats dienen we de data fysiek op te slaan?

Het onderkennen van projecten voor veranderingstrajecten

Aan de hand van de inventarisatie van de informatiesystemen en entiteitgroepen kunnen we diverse automatiseringsprojecten afleiden. In dit traject vergelijken we de huidige- en de gewenste situatie met elkaar. Tevens bepalen we welke veranderingstrajecten we moeten inplannen. Het onderkennen van de aard van de projecten vindt plaats aan de hand van de volgende afwegingen :

• Kan het huidige informatiesysteem de toekomstige functies voldoende ondersteunen?
• Kunnen we (delen) van de bestaande informatiesystemen hergebruiken?
• Hoe hoog zijn de kosten van het informatiesysteem?
• Vormt het te automatiseren gebied een afgebakend geheel?
• Hoe complex wordt het te starten project?
• Zijn de projectambities niet al te groot?
• Is de keuze voor een project wel gerechtvaardigd ten opzichte van de te verwachten levensduur?
• Hoe belangrijk is het project voor de strategische activiteiten van de organisa­tie?
• Is de samenhang tussen de verschillende projecten in kaart gebracht?

Het plannen van projecten

De onderkende projecten dienen we nu in te plannen over de looptijd van de Business analyse. Bij het inplannen moeten we rekening houden met een aantal uitgangspunten. Deze uitgangspunten zijn :

• Er moet voldoende budget zijn voor de realisatie als het project start. We willen immers weten of we een project wel succesvol kunnen afronden.
• Er moet voldoende capaciteit binnen de organisatie zijn, want we willen het project zelf kunnen begeleiden.
• Projecten met de hoogste prioriteit gaan eerst.
• Projecten die het hoogste rendement opleveren krijgen voorrang.
• Van elkaar afhankelijke projecten staan in de juiste volgorde.
• De tijd waarbinnen we een project denken te realiseren is realistisch.

Het onderkennen van in de Business analyse gesignaleerde projectrisico’s

Het rapport Business analyse leggen we ter goedkeuring voor aan de directie en dient daarom ook verschillende alternatieven te bevatten. Door bepaalde knelpunten te vermijden kunnen weer andere knelpunten ontstaan. Tevens dienen we de directie te wijzen op de risico’s die men per project loopt. Ze kunnen immers nu nog een keuze maken. De hoge projectrisico’s van bepaalde projecten vallen echter weg tegen de lage risico’s van de meeste andere projecten. Door ook projecten met een hoog projectrisico in te plannen kunnen we de organisatie op een hoger plan tillen. We onderkennen de volgende projectrisico’s:

• De verwachte baten van het informatiesysteem blijven uit.
• De ontwikkelkosten overschrijden het budget.
• Het ontwikkeltraject loopt uit de planning.
• De prestaties van het systemen blijven achter bij de verwachtingen.
• Eindgebruikers accepteren het systeem niet.
• De te ontwikkelen functies blijken moeilijk op het gekozen platform te realiseren.
• Functionaliteit komt dubbel in de organisatie voor.

Discussieer mee op LinkedIn.