vrijdag 21 januari 2011

Als het past, dan past het...

...en zo niet, dan niet! 


APS pakketten komen in verschillende soorten en maten. Deze wereld is grofweg op te delen in drie soorten. Ten eerste zijn er de kant en klare pakketten, dan zijn er de maatwerk oplossingen, en ten slotte zit daar tussenin nog iets wat je frameworks, bouwpakketten of toolbox oplossingen kunt noemen. Elk type systeem heeft voor en nadelen die in ogenschouw dienen te worden genomen bij het selecteren van een APS systeem. 

Het kiezen van een APS systeem is geen gemakkelijke opgave, er zijn veel factoren waarmee rekening moet worden gehouden. Het systeem moet de gewenste functionaliteit afdekken, moet gebruiksvriendelijk zijn, moet goed onderhoudbaar zijn, moet goed kunnen aansluiten op anderen systemen, moet zich bewezen hebben in vergelijkbare situaties, en ga zo maar door. Ook de leverancier speelt een belangrijke rol. Deze moet financieel gezond zijn, een toekomstvisie hebben die aansluit bij jouw visie en moet betrouwbaar zijn. En natuurlijk speelt de prijs een belangrijke rol. Maar zelfs als je weet wat je belangrijk vindt bij het maken van je keuze is het nog niet eenvoudig om een goede keuze te maken, simpel weg omdat elke leverancier haar uiterste best zal doen om aan te tonen dat haar product aan alle criteria voldoet. En vanuit functioneel perspectief is dat in veel gevallen ook niet ver bezijden de waarheid. Echter, de tijd en energie die het kost om een oplossing werkend te krijgen kan sterk verschillen. Om te voorkomen dat een implementatie onnodig veel tijd, energie en geld kost is het zaak om in elk geval een type oplossing te kiezen dat past bij jouw situatie. En dat is relatief eenvoudig.  

Elk van de type oplossingen heeft zijn voor en nadelen. Pakket oplossingen hebben het voordeel dat ze sterk gestandaardiseerd zijn. Elke gebruiker heeft dezelfde installatie en daarmee dezelfde functionaliteit. Je kan er dus vanuit gaan dat als er veel gebruikers zijn de software ook voldoende getest is en de kinderziektes eruit zijn. De keerzijde hiervan is de beperkte flexibiliteit. Als je iets wilt wat niet in de software zit is het vaak een kostbare en tijdrovende aangelegenheid om het toch voor elkaar te krijgen. Kortom: als het past dan past het, zo niet, dan niet. En dan zijn er alternatieven.

Het extreme andere uiterste is de maatwerk oplossing. Je begint met en blanco vel en gaat van de grond af aan iets opbouwen. Je hebt alle gelegenheid om precies voor elkaar te krijgen wat je wilt. Echter, vaak is het helemaal niet zo eenvoudig om compleet te zijn in je wensen, je moet verdomde goed weten wat je voor ogen hebt. Veel tijd gaat zitten in het specificeren van de functionaliteit, het realiseren hiervan en vervolgens het testen. 

Tussen de maatwerk oplossing en het pakket zit de framework oplossing. Deze kan gezien worden als een bouwpakket met allemaal handige bouwblokken die eenvoudig gestapeld kunnen worden om tezamen een werkend systeem te vormen. Hiermee kan veel sneller ontwikkeld worden dan in een maatwerkomgeving, en de flexibiliteit is vergelijkbaar. Toch zijn de frameworks ook niet de heilige graal, de nadelen van maatwerk oplossingen gelden ook voor de frameworks. Oplossingen zijn uniek, dus niet bewezen en gevoelig voor fouten. Ook de ontwerpuitdaging is vergelijkbaar.  

Een standaardpakket implementatie kan relatief snel plaatsvinden. De uitdaging zit in dit geval vooral in de organisatie zelf: zijn de processen op orde, is data beschikbaar en van goede kwaliteit, zijn gebruikers voldoende capabel.  Een maatwerk implementatie is vaak heel tijdrovend, met name door de vele iteraties die nodig zijn om te komen tot een volledig ontwerp en een foutloos systeem. De framework oplossingen hebben de voordelen van beide extremen, maar ook enkele nadelen. Met name het noodzakelijke specificeren en testen kan een implementatie fors uit de hand laten lopen. Ook de onderhoudbaarheid laat vaak te wensen over, en de kwaliteit van het eindresultaat is heel sterk afhankelijk van de kundigheid en ervaring van het team dat het systeem ontwikkelt. Dit traject is alleen aan te raden als de pakket implementatie echt geen optie is. Conclusie: past een pakket, zoek niet verder. Zijn wensen of processen zo speciefiek dat pakketten niet passen, kijk dan naar de frameworks. Als dat om wat voor reden dan ook tot niets leidt (vaak is prijs een issue), grijp dan eventueel naar maatwerk. 

Is het met deze vuistregel op zak nu duidelijk in welke hoek de ideale oplossing gezocht moet worden? Het antwoord is helaas nee. De vraag die nog beantwoord moet worden is: past het of past het niet? En juist bij de beantwoording van die vraag werken leveranciers vaak niet mee. De maatwerkleveranciers zullen namelijk altijd alles in het werk stellen om aan te tonen dat jouw situatie werkelijk uniek is (ook als dat niet zo is), terwijl de pakketleveranciers alles zullen doen om aan te tonen dat jouw wereld precies aansluit op wat het pakket kan (ook als dat niet zo is). De framework leverancier zal argumenteren dat elke organisatie uniek is, en dat jouw interpretatie van regelgeving en specifieke business rules die alleen gelden in jouw organisatie maken dat je echt niet blij gaat worden van die standaard pakketten die niet flexibel zijn en je dwingen om je proces aan te passen aan de keuzes is in de software gemaakt zijn. De pakketleverancier zal beargumenteren dat de software zo flexibel en goed parametriseerbaar dat ze nog nooit hebben meegemaakt dat ze een proces niet kunnen ondersteunen. En natuurlijk ligt de waarheid in het midden. 

Tijdens een implementatie van een standaardpakketoplossing ga je ongetwijfeld wel eens een concessie moeten doen, bijvoorbeeld aan de manier waarop een planning grafisch wordt gepresenteerd. De vraag die je je moet stellen is of die specifieke zaken die afwijken van wat bij al die andere gebruikers van de software anders gaat werkelijk bijdragen aan het maken van een betere planning en daarmee bij het bereiken van de organisatiedoelstellingen. Als het antwoord niet overtuigend JA is, is mijn advies om vooral te kiezen voor de standaard oplossing. Als het antwoord echter wel JA luidt, twijfel dan ook niet, en kies eieren voor je geld.   

Standaardisatie is prima. Ondanks dat alle organisaties met een planningsuitdaging in beginsel uniek zijn, is het voor een aantal planningsprocessen  heel wel mogelijk om te standaardiseren. Best practices zijn er om te worden hergebruikt, en standaardisatie leidt ook tot optimalisatie, zolang gebruikers kritische blijven. Een heel duidelijk voorbeeld van een standaard planningsproces waar maatwerk of frameworks echt de verkeerde keuze zijn is dienstroosterplanning. Een rooster is een rooster is een rooster is een rooster. Dienstroosters maken is moeilijk, en er komen heel veel regels bij kijken die goed door een systeem moeten worden ondersteund. Bestaande standaardpakketten hebben over de afgelopen 10 tot 20 jaar ervaring opgebouwd en hun oplossing verfijnd. Het is niet realistisch om in korte tijd iets te bouwen van vergelijkbare kwaliteit. Ik heb meerdere voorbeelden van mislukte implementaties van DRP systemen, en een van de oorzaken is altijd dat er te weinig functionaliteit standaard beschikbaar is.

Tot slot: Het verschil tussen standaard pakketten en frameworks wordt langzaam kleiner. Frameworks werken aan verticals of industry solutions, deeloplossingen waarop kan worden voortgeborduurd. Een goede stap, maar de volwassenheid van deze verticals haalt het over het algemeen niet bij die van de standaard pakketten. De pakketleveranciers werken op hun beurt hard aan de flexibiliteit van hun systemen, om nog beter te kunnen aansluiten bij de klant die steeds veeleisender wordt. Bij het maken van je keuze, laat je goed informeren en laat je geen zand in de ogen strooien. En onthoud: als het past, dan past het, en zo niet, dan niet. 

Geen opmerkingen:

Een reactie posten