Een roestig scheermes?

Een ouderwets programma van eisen is als een roestig scheermes

In deze blog schrijf ik wat gedachten van me af over het fenomeen “Programma van Eisen”. Niet met de illusie om hierin volledig te zijn. Maar wel een uitnodiging om over de verschillende invalshoeken van dit document van gedachten te wisselen. Dus be my guest, en schiet er eens op. Samen worden we slimmer!

Inleiding

Bij het aanschaffen of bouwen van software maken organisaties bijna allemaal gebruik van een programma van eisen (PvE) om te specificeren wat de software precies moet kunnen. Het doel van een PvE is om het selectieproces van bedrijfssoftware op de eigen bedrijfsvoering aan te sluiten met specifieke functionaliteiten die vereist of gewenst zijn. Software producten worden onderling vergelijkbaar en worden vergelijkbaar met wat de organisatie nodig heeft, nu en in de toekomst. Een PvE is daarnaast ook een prima instrument voor contractering, om zeker te stellen dat je krijgt wat je hebt gevraagd.

Voor business software is een PvE het document dat door de opdrachtgever wordt gemaakt en dat beschrijft hoe software de bedrijfsprocessen van de organisatie moet ondersteunen. De eisen en wensen kan je vaak onderverdelen in meerdere categorieën, zoals weergegeven in het plaatje.

PvE achterhaald idee?

Maar het concept van een PvE moet zelf inmiddels ook aan nieuwe eisen voldoen, gezien de snelle ontwikkelingen op het gebied van bedrijfsvoering, informatiemanagement en ICT van de laatste jaren. De ouderwetse lange lijst van eisen en wensen voldoet niet meer. Vroeger had je nog wel eens wensen als “het totale factuurbedrag exclusief transport toeslag moet links onderaan in het grijs worden weergegeven in ons scherm.” Met dergelijke eisen schiet je natuurlijk het doel helemaal voorbij en diskwalificeer je allerlei producten die uw bedrijf perfect hadden kunnen ondersteunen.

Meer dan software

Een modern programma van eisen beschrijft niet alleen wat de software allemaal moet kunnen, maar gaat ook nader in op de dienstverlening rond de software en op de organisatie die deze dienstverlening levert. Welke vragen rijzen bij u als u denkt aan leveranciers-eisen? Continuïteit? Medewerkerstevredenheid? Marktfocus? Bijhouden van ICT-ontwikkelingen? Allemaal zaken die belangrijk zijn om de juiste partner te kiezen.

Ook de eigen organisatie langs de maatlat

Het gaat dus om software die een optimale ondersteuning biedt aan uw bedrijfsdoelstellingen. Maar het implementeren en beheren van software is altijd een coproductie van ICT-leverancier, eigen ICT-afdeling en de gebruikersafdelingen. Dus ook aan uw eigen organisatie moeten eisen gesteld worden! En als u dit vraagt aan uw ICT-leverancier, dan heeft die talloze voorbeelden waarin de volwassenheid van de klant een probleem in de praktijk vormt. Kerngebruikers die niet procesgericht kunnen denken. Ondoordachte besluiten die later worden herroepen. Mensen onvoldoende vrijgemaakt voor het project. Geen ICT-beleid of applicatiearchitectuur. En zo kunnen we nog een tijdje doorgaan.

Maar toch speelt de ICT leverancier een rol bij de (on)volwassenheid van de klant. Natuurlijk is het niet handig om te kritisch te zijn als je een opdracht wil scoren. Maar het omgekeerde “eerst scoren en daarna zien we wel verder” is op de lange termijn voor niemand goed. Een volwassen leverancier mag (moet) dus eisen stellen aan de opdrachtgever, met wie hij samen een werkende software oplossing gaat realiseren.

“Ja, het kan”. Maar hoe dan?

Bij veel gevraagde functionaliteiten uit een PvE zullen alle aanbieders reageren dat het mogelijk is met hun software. Ten eerste omdat ze door willen naar de short list en ten tweede omdat het inderdaad kan. Maar het is dan niet duidelijk is hoe het kan in de software. En vooral in dit laatste zitten veel verschillen, bijvoorbeeld qua gebruikersvriendelijkheid of efficiency.

Ja, het kan. Maar waarom dan?

Uiteindelijk draait software om het ondersteunen van processen, de implementatie van de strategie van de organisatie en van de gebruikers in hun dagelijks werk. Deze 3 hoofdstukken (proces, strategie en gebruikers) moeten daarmee beschreven worden in het PvE, als context bij de opsomming van benodigde functionaliteiten. ICT is het middel; proces & strategie vormen het doel. Gebruikers en managers zijn de doelgroep.

Vaak is het nuttig om een soort interne versie van het PvE te maken, waarin ook wordt beschreven wat het doel van een eis of wens eigenlijk is. Waarom is deze functionaliteit zo belangrijk voor de organisatie? En – niet onbelangrijk – gaat de functionaliteit ook echt gebruikt worden? Gaan de gebruikers de administratieve discipline opbrengen om het systeem met de gevraagde informatie te vullen? Gaat de manager sturen op de nieuw beschikbare informatie, of wordt het een grafiekje in de bureaulade? Het gezegde wordt dan: “bezint eer ge verzint”. Hiermee kan je ook een beter onderscheid maken tussen een subjectieve vraag naar informatie en een objectieve behoefte aan informatie.

Statisch of dynamisch?

Voorheen was een PvE een eenmalig document, dat de complete benodigde functionaliteit beschreef en daarna een lange en statische lijst was. Maar tegenwoordig is zo’n oud type PvE een roestig scheermes geworden: een pijnlijke exercitie met een slecht resultaat. Met de nieuwe ontwikkelmethoden Scrum/ Agile en met de gegroeide dynamiek in organisatieveranderingen moet een PvE op een andere manier beschreven worden. Voor standaard business software kan u de eisen en wensen opsplitsen in huidige en toekomstige eisen of wensen. Voor toekomstige eisen geldt dat ze niet nu nodig zijn, maar bijvoorbeeld over een jaar. De functionaliteit mag dan ook in een “roadmap” van het software product benoemd worden, oftewel een functionele beschrijving van een toekomstig te realiseren functionaliteit. Check dan wel in hoeverre de leverancier zijn roadmap beloften van het verleden betrouwbaar is nagekomen!

Omdenken over PvE

Software stelt ook eisen aan de timmerman die met het gereedschap werkt. Als software slecht wordt gebruikt of slecht wordt onderhouden, dan zal de waarde ervan snel afnemen. En daarmee eindigt het rendement op investering niet zelden dik onder de nulwaarde.

Dit geldt niet alleen voor de fasen van beheer en optimalisatie, maar ook voor de implementatiefase. Als de organisatie zelf niet aan bepaalde eisen voldoet, is de software implementatie gedoemd te mislukken en eindigt u met SOFtware. En wie krijgen bijna altijd de schuld? U raadt het al… de software en de leverancier.

Een goede opdrachtgever geeft de beoogd leverancier de ruimte om ook eisen aan de opdrachtgever te stellen. En een goede leverancier neemt deze taak zeer serieus en blijft verre van de “u vraagt wij draaien” mentaliteit. Een goede leverancier en goede klant zijn kritisch op elkaar en geven elkaar hier ook de ruimte voor. Net als in een goed huwelijk dus…

Wat vindt u eigenlijk?

Ik ben benieuwd wat u ervan vindt, en of u aanvullende invalshoeken heeft op het Programma van Eisen anno 2014. Dus uw kritiek, vragen, aanvullingen zijn van harte welkom! Laat het ons weten. Neem contact met ons op.

ERP Gerrit Vixseboxse.