5 tips voor implementatie van CPM software

De laatste jaren lijkt de spreadsheetdominantie af te nemen en overwegen veel ondernemingen de inzet van specifieke planningssoftware. Men kan en wil niet meer afhankelijk zijn van dat complexe model in Excel, dat alleen die ene persoon kan onderhouden en waarvan de toegankelijkheid voor andere medewerkers beperkt is.

Voorbeelden van leveranciers die planningssoftware aanbieden zijn onder andere Business Objects, Cognos, Infor, Oracle/Hyperion en SAP/Outlooksoft. Deze leveranciers integreren deze software in een suite van modules die Corporate Performance Management (CPM) ondersteunen:
• modelleren en simuleren;
• strategisch management;
• plannen, budgetteren en prognose;
• financiële consolidatie;
• rapportage en analyse.

1. Beheers de invoering met een gedegen plan van aanpak
Voor veel ICT-projecten geldt dat de datum voor oplevering van de applicatie vaak wordt overschreden en ontwikkelkosten hoger zijn dan gebudgetteerd:
– het gevraagde product ligt vast en de hiervoor benodigde tijd niet;
– de tijd is vooraf vastgelegd en het gewenste product is maar ten dele vastgelegd;
– vaak is niet op voorhand duidelijk of in de gestelde tijd alle wensen kunnen worden gerealiseerd.

Slechts een beperkt aantal projecten blijkt een succes te zijn (op tijd, binnen budget, tegen afgesproken kwaliteit). Zowel opdrachtgevers, projectmanagers als ICT-specialisten onderschatten vrijwel altijd de omvang en complexiteit van het werk, mede onder interne en externe tijdsdruk. Projecten worden niet te laat opgeleverd, maar veel te vroeg beloofd; het is dan begrijpelijk dat projecten uitlopen. Een implementatie van planning software moet worden beheerst als een project of als projectfase binnen een breder project. In beide gevallen dient vooraf een plan van aanpak (projectplan of faseplan) opgesteld te worden met de onderstaande onderwerpen:
– achtergrond (aanleiding, historie, context);
– doelstelling of probleemstelling (‘SMART’ gedefinieerd bedrijfsdoel);
– projectopdracht en projectresultaat (het op te leveren ‘eindproduct’);
– scope en afbakening (wat is het projectresultaat dus niet!);
– uitgangspunten en randvoorwaarden (organisatie, tijd, geld, kwaliteit, functionaliteit enzovoort);
– relaties met andere projecten (afhankelijkheden met betrekking tot systemen, functies, producten enzovoort);
– projectorganisatie (stuurgroep, opdrachtgever, opdrachtnemer, werkgroepen, teamleden);
– projectaanpak (wat is de aanpak qua projectfasering, -werkwijze, informatie en rapportage?);
– uit te voeren activiteiten (wat moet er worden gedaan?);
– op te leveren producten (wat moet er worden opgeleverd?);
– kwaliteitsmanagement (kwaliteitseisen, -controle en -bijsturing);
– beheersing van tijd, geld en kwaliteit (procedures, richtlijnen, rapportages);
– planning en begroting (detailplanning, kosten/batenanalyse);
– risicoanalyse (risicomanagement).

Dit (deel)project past in de totale visie en de implementaties van softwarecomponenten sluiten nauw aan bij de (incrementele) procesverbeteringen die in het totale programma worden uitgevoerd.

2. Zorg voor een stevig projectleiderschap
Veel projecten struikelen door de inzet van een onervaren projectmanager. De business en IT dient bij voorkeur direct vanuit één hand te worden aangestuurd. Dit is cruciaal wanneer gedurende het project de applicatie nog verder ontwikkeld moet worden. De wijze waarop de projectmanager functioneert is tevens een belangrijke succesfactor voor de succesvolle implementatie. De projectleider moet bewezen inzicht hebben in de complexiteit van de op te lossen problematiek en de samenhang met andere projecten. Tevens moet hij het totaaloverzicht houden en niet verzanden in details. Strikte projectbeheersing moet worden toegepast, op basis van realistische planningen.

Goede communicatieve vaardigheden zijn wezenlijk. De projectleider moet in staat zijn om relaties te onderhouden en als gesprekspartner kunnen optreden voor het management, contacten en aansturing van vertegenwoordigers van softwareleveranciers en kunnen schakelen op operationeel niveau.

####

3. Ontwikkel applicaties iteratief
Bij ieder ICT-project is de inbreng van gebruikers cruciaal. Nog steeds maken organisaties de fout om gebruikers en andere belangenpartijen niet, onvoldoende of te laat in het project te betrekken. Daarnaast zijn dikwijls de gebruikerseisen onduidelijk en aan veranderingen onderhevig door ‘voortschrijdend inzicht’. Ook wil men tijdens het project vaak meer dan oorspronkelijk de bedoeling (en gepland) was. Miscommunicatie tussen ontwikkelaars en gebruikers heeft een nadelige invloed op het verloop van de softwareontwikkeling. Strakke projectbeheersing is op dit punt onontbeerlijk.

Een gebruiker of gebruikersgroep kan vaak niet in één keer aangeven wat hij wil. Het besef hoe het systeem eruit zal gaan zien groeit in de tijd. Het is hierbij van belang dat de eerste resultaten via een werkende oplossing zichtbaar worden. De functionaliteit van de applicatie zal via meerdere iteraties worden ontwikkeld en in stappen c.q. releases aan de organisatie beschikbaar worden gesteld. Daarbij dienen de opvolgende releases aan te sluiten bij de implementatievisie zoals deze reeds eerder is uiteengezet.

De totstandkoming van iedere release of versie van de applicatie doorloopt doorgaans de volgende stappen.
– Functioneel ontwerp: de functionele of businesseisen waaraan het systeem moet voldoen.
– Technisch ontwerp: het functioneel ontwerp wordt nader gedetailleerd en vertaald naar technische eisen, zodat de ontwikkelaar in de volgende stap precies weet wat er moet worden gebouwd.
– Programmeren: de programma’s van het systeem worden geschreven volgens de technische specificaties die in de vorige fase zijn vastgelegd.
– Testen: de ontwikkelde (deel)programma’s worden in samenhang getest.
– Conversie en invoering: de gegevens van het oude systeem worden omgezet en geschikt gemaakt voor het nieuwe systeem.
– Gebruik en beheer van het systeem: de beheersorganisatie neemt het systeem in gebruik en beheert het.

Elke stap bevat een mijlpaalproduct. Dat houdt in dat na elk fase een tussenproduct wordt opgeleverd. Het mijlpaalproduct wordt beoordeeld en dan wordt er een besluit genomen of de volgende fase ingezet kan worden: go/no go. Bij go gaat het project verder met de volgende stap. Bij no go kan het mijlpaalproduct of de fase worden verbeterd of het (sub)project zelfs worden stopgezet.

De evolutionaire benadering van de ontwikkeling van de applicatie heeft grote voordelen. Tussentijdse opleveringen van daadwerkelijk bruikbare (deel)systemen maken het mogelijk op grond van praktische ervaringen het systeem bij te sturen. Specificaties van de functionaliteit kunnen zonder al te veel moeite nog worden aangepast, mede doordat de beeldvorming over de toepasbaarheid zich snel ontwikkelt. Gebruikers blijven betrokken en enthousiast en er groeit commitment en eigenaarschap van de applicatie.

Verder is het van belang dat het ontwikkelteam bestaat uit een adequate mix van personen met business- en ICT-skills, aangevuld met gebruikers en softwarespecialisten van de leveranciers.

4. Zorg voor inbedding van de applicatie in de bestaande infrastructuur
Door de jaren heen is er bij veel organisaties een complexe situatie ontstaan van tientallen tot soms wel honderden ICT-systemen waarvan onduidelijk is hoe ze exact werken en op welke manier deze systemen aan elkaar gekoppeld zijn. Voor ieder aandachtsgebied (marketing, verkoop, productie, service, financiën), voor ieder nieuw product (verzekering, zorgdienst, tijdschrift, telefoonabonnement), voor iedere processtap (informeren, offreren, contracteren, service) en voor ieder contactkanaal (website, e-mail, telefoon, balie, automaat) is steeds weer een nieuw systeem gebouwd. De invoering van de vele geïntegreerde ERP-systemen heeft dit probleem maar ten dele opgelost.

Al deze ICT-systemen zijn door verschillende leveranciers en softwareontwikkelaars op verschillende manieren gebouwd, waarbij steeds weer andere hulpmiddelen zijn gebruikt. Vaak ontbreken systeemdocumentatie en gebruikershandleidingen en worden deze ‘legacy’-systemen voortdurend aangepast aan veranderende eisen waardoor de onderhoudbaarheid verder afneemt.

De nieuwe applicatie moet in deze infrastructuur worden geïntegreerd. Dit vraagt specifieke aandacht voor de informatielogistiek tussen de transactiesystemen en de planningsapplicaties. Een datawarehouse kan hierin een belangrijke rol vervullen. Bovendien dient de applicatie te worden geïnstalleerd conform de richtlijnen van de organisatie in termen van security, database settings, sizing, setting proxy servers, regional settings, DBMS-softwareversies, internet specificaties enzovoort. Een audit van de infrastructuur door de leverancier kan hiervoor nodig zijn, zodat de applicatie aan deze eisen kan voldoen.

5. Implementeer ICT in lijn met de roll out strategie: think big, start small
De implementatie is op verschillende manieren mogelijk. Er kan sprake zijn van een proefperiode met fall-back mogelijkheid. Een andere mogelijkheid is om als eerste stap te kiezen voor een volledige in productie name, eventueel ook nog met gehele of gedeeltelijke fall-back mogelijkheid. Voor de roll out moet de organisatie onderstaande keuzes maken:
– ingebruikname: big bang, gefaseerd, parallel, gecombineerd?
– organisatorisch: per business unit, afdeling, team?
– functioneel: marketing, verkoop, klantenservice?
– procesmatig: demand planning, supply chain management, R&D planning, financial forecasting, budgettering
– combinaties hiervan?

Het adagium ‘think big, start small’ blijkt hierbij goed te werken. Met andere woorden: beperk de scope en bouw leerervaringen op. Evalueer na iedere implementatiestap en neem de leerpunten mee in de volgende fase.

Verder is het wezenlijk om het ontwikkelteam inclusief de vertegenwoordigers van de organisatie en de leverancier actief te betrekken in de eerste fasen van de uitrol. Dit team verzorgt de dagelijkse ondersteuning van de eindgebruikers tijdens de eerste periode van ingebruikname van het systeem. Dit kan een doorslaggevende factor voor het succes van de implementatie zijn. Verder moet de organisatie zorgen voor de contracten en service level agreements met interne en externe leveranciers voor processupport, first en second line support.

Door: Ing Martin Daudey & ir. P. Tullemans, EyeOn Planning & Control Solutions

Mis deze checklist niet: In 7 stappen beter rapporteren