Ik ken een organisatie waar op een kleine 200 locaties medewerkers dagelijks volgens een rooster werken. Om de roosters sneller en beter te kunnen maken werd gekozen voor APS systeem. APS systemen kunnen kortweg worden verdeeld in twee groepen. Enerzijds zijn er de pakket oplossingen, dit zijn kant en klare systemen die initieel redelijk passen op de gevraagde oplossing en door configuratie verder kunnen worden ingericht. Anderzijds zijn er de framework oplossingen, bestaande uit een grote hoeveelheid bouwblokjes die op een slimme manier zo kunnen worden samengevoegd dat het geheel uiteindelijk de gewenste oplossing vormt. Deze organisatie koos voor een framework oplossing, enthousiast geworden door de onbegrensde flexibiliteit.
Initieel was de scope van het project duidelijk; er moesten roosters komen voor alle medewerkers waarmee de vraag naar werk zo goed mogelijk wordt afgedekt, en die aansloten bij de contracten van de medewerkers. Ver in de ontwerp fase, aangespoord door het ogenschijnlijke gemak waarmee de applicatie werd gebruikt, begon de wens wat te schuiven, en besloten ze om de scope wat uit te breiden richting aanpalende systemen. Zo werd er eerst besloten om de werkelijk gewerkte uren na afloop van de roosterperiode weer in het planningssysteem in te voeren, daarna werd besloten om contractgegevens van medewerkers bij te houden (ook uit het verleden), weer later werd een belangrijk deel van de financiële afhandeling toegevoegd. Argument was: waarom zouden we dit in het onderhoudsonvriendelijke ERP houden als we nu zo een mooi en flexibel nieuw APS hebben? Aan het einde van een hele lange rit zaten ze met een systeem dat niet meer performde, veel te veel hardware gebruikte en vele malen meer had gekost dan oorspronkelijk gedacht.
Wat ging er fout? Een van de nadelen van een framework oplossing is dat er vrijwel geen functionaliteit kant en klaar beschikbaar is; alles moet eerst beschreven worden voordat het gemaakt kan worden. En ondanks alle hulp van adviseurs is het uiteindelijk toch de klant die de specificaties aanlevert. Dit had deze klant zich maar half gerealiseerd toen ze begonnen aan het toevoegen van ERP functionaliteit. Voordat het gedrag van het nieuwe systeem exact zo was als dat van het oude systeem waren er een paar lange maanden verstreken. Een ander nadeel (dat overigens door leveranciers altijd als een voordeel wordt uitgelegd) is dat er vrijwel geen beperkingen zijn aan functionele mogelijkheden; Tot op zekere hoogte is de oplossing een maatwerkoplossing. Hierin schuilt echter ook een groot risico: bij alle functionaliteit die je toevoegt moet je het grote plaatje, de totale applicatie, niet uit het oog verliezen als het gaat om functionaliteit, performance en geheugengebruik.
Uiteindelijk denk ik dat deze organisatie zichzelf een plezier had kunnen doen door zich goed te laten adviseren bij het maken van de keuze voor de APS oplossing. De enorme flexibiliteit van de gekozen oplossing is geweldig, met name als er een proces ondersteund moet worden waarvoor geen standaard oplossingen bestaan. Als er echter standaard oplossingen beschikbaar zijn, en dat is voor roosteren typisch het geval, is het het overwegen waard om een deel van de flexibiliteit in te leveren voor een stuk stabiliteit en functionaliteit. Zo zijn er pakketoplossingen die prima roosters maken en bovendien beschikken over modules voor tijdregistratie en verloning. Wat geen enkel van deze oplossingen helaas kan is het terugdraaien van de tijd.
