Pakketselectie via Europese aanbesteding

Bij een pakketselectie kiest u een bestaand softwarepakket voor uw bedrijfsvoering, zoals een ERP-oplossing, e-HRM-systeem, financieel systeem, zaaksysteem of belastingapplicatie. U ontwerpt het systeem dus niet zelf, maar kiest uit oplossingen die elk hun eigen standaardfunctionaliteit, werkwijze en implementatieaanpak hebben. 

Emtio begeleidt gemeenten en andere overheden, onderwijs- en zorginstellingen, veiligheidsregio’s en nutsbedrijven bij de Europese aanbesteding van die pakketten: van functionele behoeftestelling tot gunning en overdracht naar de implementatie. Met onze kennis van IT, inkoop en recht zorgen we dat leveranciers aantonen dat hun pakket past, zodat u een oplossing kiest die daarna ook goed wordt ingevoerd en gebruikt.

Neem contact op met een adviseur

Direct naar:

1. Geen programma van eisen met honderden vinkjes
2. De standaard van het pakket is het vertrekpunt
3. De Lichtblauwdruk beschrijft de behoefte
4. Fit-gap-analyse: waar zit de echte fit?
5. Pakketselectie: wat laat de oplossing zien?
6. Hoe beoordelen we de kwaliteit?
7. Pakketselectie voor e-HRM, financiële systemen, zaaksystemen en ERP
8. Het implementieplan bij pakketselectie
9. De SLA van de leverancier als vertrekpunt
10. De juiste aanbestedingsprocedure kiezen
11. De verificatie is geen reparatieronde
12. Na gunning begint het detailwerk
13. Wat willen we bij gunning weten?

Geen programma van eisen met honderden vinkjes

Emtio werkt al lange tijd bij voorkeur met een functionele behoeftestelling in plaats van een omvangrijk programma van eisen. Eisen blijven daarbij essentieel. Voor informatiebeveiliging, privacy, toegankelijkheid, architectuur, gegevensuitwisseling en continuïteit zijn harde eisen vaak gewoon nodig.

Maar een lange lijst met functionele eisen waarop iedere leverancier bijna overal ‘ja’ invult, helpt meestal niet om de verschillen tussen pakketten te zien. De vraag is niet alleen of een functie aanwezig is. Het gaat er ook om hoe die functie werkt, hoeveel configuratie nodig is, of aanvullende modules nodig zijn en wat de gevolgen zijn voor beheer, implementatie, gebruik en kosten. We brengen eerst scherp in beeld wat de organisatie nodig heeft. Daarbij kijken we naar de processen die ondersteund moeten worden, de informatie die nodig is, de belangrijkste businessregels en de koppelingen met andere systemen. Ook bepalen we waar echt geen ruimte is voor afwijking en waar juist aangesloten kan worden bij de standaard van het pakket.

De standaard van het pakket is het vertrekpunt

Veel bedrijfsapplicaties worden als SaaS geleverd. De leverancier gebruikt bij verschillende klanten in belangrijke mate dezelfde programmatuur, dezelfde beheerorganisatie en vaak ook dezelfde implementatiemethode. Dan heeft het in onze opvatting weinig zin om iedere leverancier tijdens de aanbesteding een compleet nieuwe oplossing op papier te laten ontwerpen.

Het is ook van belang in te zien in welke situatie de opdrachtgever terechtkomt. Is een leverancier makkelijk inwisselbaar voor een ander of haalt u een monopolist in huis? Een inwisselbare leverancier is per definitie ook een monopolist gedurende de looptijd van een contract.

Wij draaien het liever om: 

• De opdrachtgever beschrijft op functionele wijze wat nodig is en welke randvoorwaarden gelden
• De leverancier laat zien hoe zijn standaardoplossing daarop aansluit

Als een leverancier een proces anders ondersteunt dan de opdrachtgever vooraf voor ogen had, hoeft dat geen probleem te zijn. Het kan juist een betere werkwijze opleveren. Bij standaardsoftware moet voorkomen worden dat oude werkwijzen zonder goede reden één-op-één worden nagebouwd. Dat betekent niet dat de standaard van de leverancier altijd gevolgd moet worden. Soms is een afwijking gewoon nodig, bijvoorbeeld vanwege interne controle, informatiebeveiliging of een noodzakelijke koppeling.

De Lichtblauwdruk beschrijft de behoefte

Bij pakketselecties werken we vaak met een Lichtblauwdruk. Daarin beschrijven we de processen en de context waarin het nieuwe systeem gebruikt gaat worden. De Lichtblauwdruk is geen gedetailleerd ontwerp van het toekomstige pakket. We beschrijven bijvoorbeeld het gewenste resultaat van een proces, de belangrijkste processtappen, rollen, gegevens, koppelingen en uitzonderingen. Maar als het aangeboden pakket hetzelfde resultaat op een andere en goede manier bereikt, willen we dat juist weten.

De leverancier kan dan aangeven: ‘dit herkennen wij, maar onze standaardoplossing ondersteunt dit proces anders’. Dat is relevante informatie. We kijken daarbij ook naar de gevolgen voor gebruikers en beheerders. Een oplossing kan functioneel prima zijn, maar minder passend als de werkwijze onnodig ingewikkeld is of veel extra handelingen vraagt.

Fit-gap-analyse: waar zit de echte fit?

Om duidelijk te krijgen hoe een pakket werkelijk aansluit, werken we met een productfit- of fit-gapoverzicht. Daarbij maken we bijvoorbeeld onderscheid tussen:

• Standaard beschikbaar
• Beschikbaar via configuratie
• Aanvullende standaardmodule
• Koppeling of integratie nodig
• Generieke extensie of low-code/no-code
• Roadmap
• Niet beschikbaar

Bij afwijkingen maken we concreet wat daarvan de gevolgen zijn. Denk aan een extra module, aanvullende kosten, afhankelijkheid van een derde partij of gevolgen voor beheer, upgrades en planning. Daarmee wordt snel duidelijk waar de echte verschillen tussen oplossingen zitten. Een leverancier hoeft geen lang verhaal te schrijven over iets wat gewoon standaard in het pakket aanwezig is. De aandacht gaat naar de punten waar daadwerkelijk iets te kiezen of te beoordelen valt.

Pakketselectie: wat laat de oplossing zien?

Bij een pakketselectie is aantonen dat een oplossing werkt echt van belang. Daarom gebruiken we praktijktesten met voor alle leveranciers dezelfde cases. Die cases zijn gebaseerd op processen en situaties die voor de opdrachtgever echt relevant zijn. 

Bij een eHRM-oplossing kan het bijvoorbeeld gaan om een medewerker die zelf een mutatie doorvoert, een leidinggevende die een workflow afhandelt of een functioneel beheerder die een workflow aanpast.

Bij een financieel systeem kan het gaan om een volledig financieel proces, inclusief autorisaties, controles, rapportage en audittrail.

Bij ERP kan een case over meerdere onderdelen tegelijk lopen: van bestelling en ontvangst tot projectboeking, factuur, grootboek en rapportage.

We beoordelen niet hoe goed iemand presenteert, maar wat de aangeboden oplossing daadwerkelijk laat zien. Ook gebruiksgemak telt mee. Een pakket dat logisch werkt en goed te beheren is, is meestal ook makkelijker in gebruik te nemen. Een PowerPoint of filmpje is geen vervanging voor ontbrekende functionaliteit. En iets wat nog ontwikkeld moet worden, is niet hetzelfde als iets wat al beschikbaar is.

Hoe beoordelen we de kwaliteit van een pakket?

Artificial Intelligence maakt het voor leveranciers eenvoudiger om omvangrijke en overtuigend geformuleerde offertes te produceren. Daardoor wordt het nog minder zinvol om kwaliteit vooral af te leiden uit lange schriftelijke antwoorden. De beoordeling moet zich richten op aantoonbare productfit, werkende functionaliteit, concrete afwijkingen, realistische implementatie en de mensen die de opdracht daadwerkelijk uitvoeren.

Emtio gebruikt daarom praktijktesten, productfit- en fit-gapanalyses, voorlopige uitwerkingen, gesprekken en verificatie. Een leverancier moet niet alleen goed kunnen beschrijven dat zijn oplossing past, maar dat waar mogelijk ook laten zien en onderbouwen. Zo blijft de beoordeling gericht op verschillen die voor de opdrachtgever werkelijk relevant zijn.

Pakketselectie voor e-HRM, financiële systemen, zaaksystemen en ERP

Een eHRM-systeem is iets anders dan een ERP-oplossing die Finance, projecten, logistiek en andere bedrijfsprocessen ondersteunt. Daarom gebruiken we niet voor iedere pakketselectie hetzelfde aanbestedingsdocument. Bij een relatief afgebakende SaaS-oplossing ligt de nadruk vooral op productfit, gebruiksgemak, configureerbaarheid, implementatie en dienstverlening. Bij complexere SaaS-oplossingen worden migratie, gegevenskwaliteit, integraties, beheer en governance belangrijker. Bij ERP gaat dat nog verder. Dan moet niet alleen duidelijk zijn dat functies aanwezig zijn, maar ook dat de verschillende onderdelen goed samenwerken. Architectuur, gegevensstromen, koppelingen, migratie en ketenverantwoordelijkheid krijgen dan een veel grotere rol. Ook de invoering raakt bij ERP vaak een groter deel van de organisatie. Nieuwe processen, nieuwe rollen en een andere manier van werken vragen meer van medewerkers en beheer.

Een pakketselectie voorbereiden?

Neem contact op met een adviseur

Het implementatieplan bij pakketselectie

Leveranciers van volwassen pakketten hebben meestal een eigen implementatiemethode. Die is gebaseerd op eerdere implementaties en sluit aan op hun product. Wij vragen daarom liever hoe die standaardaanpak eruitziet en wat voor deze opdrachtgever anders of extra nodig is. Bij een eenvoudige implementatie kan dat vrij compact. Bij ERP verwachten we vanzelfsprekend meer: fasering, migratie, interfaces, ketentesten, cut-over, benodigde capaciteit van de opdrachtgever en belangrijke projectrisico’s.

We kijken ook naar de voorbereiding op de ingebruikname. De leverancier moet duidelijk maken hoe key-users, functioneel beheerders, leidinggevenden en eindgebruikers worden meegenomen, welke trainingen en ondersteuning worden geboden en hoe de begeleiding rond en na livegang is geregeld.

Dat is zowel de verantwoordelijkheid van de leverancier als van de opdrachtgever. De opdrachtgever moet mensen beschikbaar maken, keuzes tijdig nemen en zorgen dat beheer en eigenaarschap goed geregeld zijn. Daarom kijken we bij de implementatie naast de vraag of het systeem technisch kan worden opgeleverd ook naar of de organisatie er daadwerkelijk mee kan gaan werken. Het definitieve implementatieplan hoeft vóór gunning niet volledig te zijn uitgewerkt. Dat gebeurt samen met de gekozen leverancier. Wel moet vóór gunning duidelijk zijn of de aanpak realistisch is en welke inzet, kosten en afhankelijkheden daarbij horen.

De SLA van de leverancier als vertrekpunt

Een SaaS-leverancier heeft normaal gesproken een bestaande beheerorganisatie en standaard-SLA. Het heeft weinig zin om tijdens een aanbesteding een volledig nieuwe SLA te laten schrijven als die niet aansluit op de manier waarop de leverancier normaal werkt.

Daarom nemen we de standaard-SLA van de leverancier als vertrekpunt. Die leggen we naast de eisen van de opdrachtgever. Afwijkingen worden expliciet gemaakt. Waar de standaard al voldoet, hoeft niets opnieuw te worden bedacht. Waar een harde eis geldt, moet de leverancier die wel accepteren. Bij complexe oplossingen kijken we niet alleen naar de beschikbaarheid van één applicatie. Ook interfaces, subcontractors, incidentregie en de werking van de totale keten kunnen onderdeel van de afspraken zijn.

De juiste aanbestedingsprocedure kiezen

De inhoud van de pakketselectie en de aanbestedingsprocedure horen bij elkaar. Emtio kiest daarom niet automatisch voor een openbare of niet-openbare procedure. We kijken eerst naar de aard van de opdracht en naar de vraag hoeveel inhoudelijke interactie met leveranciers nodig is.

Mededingingsprocedure met onderhandeling bij pakketselectie

Bij complexe pakketselecties gebruiken we regelmatig de mededingingsprocedure met onderhandeling, als de wettelijke voorwaarden daarvoor aanwezig zijn. Een belangrijk voordeel is dat we dan niet in één keer van aanbestedingsdocument naar definitieve inschrijving gaan. Na de selectiefase vragen we de geselecteerde leveranciers eerst om een voorlopige inhoudelijke uitwerking. De prijs hoeft in die fase nog niet centraal te staan. Daarna bestuderen we die uitwerkingen en spreken we afzonderlijk met de leveranciers.

Eerst bespreken, daarna definitief inschrijven

In de gesprekken bespreken we onduidelijkheden en aannames uit de voorlopige inschrijving. We kijken concreet naar:

• de aangeboden oplossing en eventuele afwijkingen
• de mate waarin functionaliteit standaard beschikbaar is
• relevante afhankelijkheden, bijvoorbeeld van koppelingen of derde partijen
• de inzet die de implementatie vraagt van de opdrachtgever

De opdrachtgever kan daarbij toelichten wat met een behoefte of randvoorwaarde is bedoeld. Op basis van die gesprekken scherpen de leveranciers hun definitieve inschrijving aan.

De concurrentie blijft volledig in stand: iedere geselecteerde leverancier krijgt binnen dezelfde procedure dezelfde mogelijkheid om zijn aanbod te verbeteren. Het grootste voordeel is dat belangrijke misverstanden niet pas na gunning boven tafel komen.

De verificatie is geen reparatieronde

Na de beoordeling volgt vaak nog een verificatiefase met de voorlopig winnende leverancier. Daarin controleren we of de aanbieding goed is begrepen en uitvoerbaar is. We lopen de productfit en afwijkingen nogmaals door, controleren belangrijke aannames en zorgen dat contract, SLA, prijsafspraken en aanbieding goed op elkaar aansluiten. Ook bespreken we de voorwaarden voor implementatie en ingebruikname, zoals migratie, beschikbaarheid van key-users, opleidingen en beheerinrichting.

Maar de verificatie is geen tweede kans om een slecht passende oplossing alsnog passend te maken. Een wezenlijk ontbrekende functie kan niet na de beoordeling ineens worden toegevoegd. De winnaar mag na afloop van de competitie niet alsnog een wezenlijk betere aanbieding maken.

Na gunning begint het detailwerk

Pas nadat leverancier en pakket zijn gekozen, wordt de inrichting verder uitgewerkt. Dan wordt bepaald hoe standaardprocessen precies worden ingericht, welke configuratiekeuzes worden gemaakt, hoe autorisaties worden opgebouwd, hoe gegevens worden gemigreerd en hoe koppelingen worden gerealiseerd. Ook wordt dan concreet gemaakt hoe gebruikers en beheerders worden voorbereid op de nieuwe werkwijze. Wij noemen dat bijvoorbeeld een Configuratie- en Implementatieblauwdruk.

De aanbesteding verdwijnt daarmee niet in een la. De uitkomsten worden gebruikt bij de uitvoering. Productfit, geaccepteerde afwijkingen, implementatie-uitgangspunten, afspraken over opleiding en ingebruikname, SLA, prijsafspraken en eventuele architectuurafspraken vormen de basis voor de implementatie.

Wat willen we bij gunning weten?

Bij gunning moet het volgende duidelijk zijn:

• wat het pakket daadwerkelijk kan
• waar de afwijkingen zitten en welke gevolgen die hebben
• wat de implementatie vraagt van leverancier en opdrachtgever
• of gebruikers en beheerders met de oplossing uit de voeten kunnen
• hoe de dienstverlening na ingebruikname is geregeld

Bij een complexe oplossing willen we daarnaast weten of de architectuur klopt, de koppelingen beheersbaar zijn en de leverancier verantwoordelijkheid kan nemen voor de hele keten. Als die vragen goed zijn beantwoord, kan een opdrachtgever een bewuste keuze maken.

Een pakketselectie of ERP-aanbesteding voorbereiden?

Emtio ondersteunt overheden en andere organisaties bij Europese aanbestedingen voor bedrijfsinformatiesystemen: van aanbestedingsstrategie en functionele behoeftestelling tot aantoonbare productfit, beoordeling, contractering, verificatie en overdracht naar de implementatie. Heeft uw organisatie zelf al een aanpak, uitvraag of beoordelingsmodel voorbereid, dan kan Emtio deze ook onafhankelijk toetsen.

Wilt u weten welke aanpak en aanbestedingsprocedure past bij uw pakketselectie? Neem contact op met Emtio en plan een gesprek in met onze adviseurs.