Doorlooptijd van een PIM implementatie: realistische planning per scope

Hoe lang duurt een PIM implementatie?

Een PIM implementatie duurt ongeveer 3 tot 18 maanden, afhankelijk van de scope, als schatting van PIMvendors. De bandbreedtes hieronder komen uit de trajecten die PIMvendors heeft gezien. Het zijn planningswaarden, gemarkeerd als schatting.

Het aantal producten telt minder zwaar dan veel mensen denken. Een catalogus van 100.000 eenvoudige producten met schone ERP-data kan sneller over dan 10.000 configureerbare producten met data verspreid over spreadsheets. De complexiteit per product, het aantal bronnen en het aantal outputs bepalen de inspanning.

De pijler over PIM implementatie beschrijft de fasen achter deze bandbreedtes. Op deze pagina lees je wat een project binnen zijn bandbreedte laat schuiven en hoe je een planning toetst voordat je tekent.

Gebruik de bandbreedtes als realiteitscheck. Een partner die vier maanden voorstelt voor een enterprise-scope, heeft een heel smalle eerste release of optimistische aannames. Vraag welke van de twee. Een partner die 18 maanden voorstelt voor een afgebakende scope, plant voor problemen die hij nog niet heeft benoemd.

Wat bepaalt de doorlooptijd van een PIM implementatie?

Zes factoren bepalen de doorlooptijd, en vier daarvan liggen aan de kant van de klant. Elk ervan kun je verkleinen voordat de implementatie start.

De gereedheid van het datamodel heeft het grootste effect. Daarom bevat het selectieproces van PIMvendors van 12 weken werk aan het datamodel. Een koper die met een getekend datamodel aan de implementatie begint, slaat het grootste deel van de ontwerpdiscussie over.

De snelheid van besluiten is de meest onderschatte factor. Een bouwsprint die twee weken wacht op een besluit over de variantstructuur, verliest die twee weken. Leg in de projectopdracht een beslisoverleg en een maximale reactietijd vast.

Hoe lang duurt elke fase van de implementatie?

Bij een middelgrote scope duurt elke fase een paar weken tot een paar maanden, waarbij de migratie parallel aan de bouw loopt. De doorlooptijden hieronder zijn schattingen van PIMvendors.

De parallelle sporen verkorten de kalender en verhogen de coördinatielast. Migratierepetities tijdens de bouw leggen gaten in het datamodel vroeg bloot, wat per saldo tijd bespaart. Ze vragen ook data stewards die tijdens de bouw beschikbaar zijn, en veel planningen vergeten dat.

Training hoort laat, dicht bij de livegang. Gebruikers die drie maanden voor hun start een training volgen, zijn het meeste weer kwijt. Plan rolgerichte training in de laatste weken van het testen, en train key users eerder zodat zij collega's kunnen helpen.

Hoe ziet een realistische PIM-planning eruit?

Een realistische planning benoemt de releases, de repetities en de beslismomenten, en de data volgen daaruit. Het illustratieve voorbeeld hieronder is een samengesteld praktijkpatroon uit meerdere projecten.

Illustratief voorbeeld: een middelgrote fabrikant met 30.000 producten, zes talen, een koppeling met ERP en DAM en drie kanalen.

De planning bevat drie volledige repetities en een getekend datamodel vóór de bouw. Ze eindigt met hypercare, die doorloopt tot maand 8 of 9. Release 2, bijvoorbeeld met extra markten, volgt daarna.

De gids over PIM datamigratie legt uit hoe je repetities plant en afstemt.

Hoe toets je de planning van een implementatiepartner?

Toets een planning door de aannames over jouw data, jouw mensen en jouw besluiten te testen. De meeste optimistische planningen verstoppen hun aannames in die drie gebieden.

Vraag de partner om schriftelijk vast te leggen:

• De datakwaliteit die bij de start van de migratie wordt aangenomen, en de bron van die aanname.
• Het aantal volledige migratierepetities, met data.
• Het aantal uren per week dat van de eigenaar van productdata en de stewards wordt verwacht.
• De maximale reactietijd die voor besluiten van de klant wordt aangenomen.
• De integratieaanpak per systeem en wie elke kant bouwt.
• De planningsbuffer en wie daarover beschikt.

Leg de antwoorden naast je eigen capaciteit. Een planning die uitgaat van twee stewards voor 50 procent, terwijl die stewards de dagelijkse operatie draaien, gaat schuiven. PIMvendors stelt als schatting 15 tot 20 procent centrale buffer voor bij middelgrote implementaties.

Scoor de realiteitszin van de planning onder methodiek in de partner-scorekaart. Neem afgesproken data en acceptatiecriteria op in zowel het partner- als het platformcontract. De gids over PIM-kosten laat zien hoe wijzigingen in de doorlooptijd de totale kosten raken.

Wat doet een harde deadline met de planning?

Een harde deadline maakt van de planning een scopevraag: wat moet er op de datum live staan, en wat kan daarna. Wettelijke data en einddata van contracten zijn de gebruikelijke bronnen van harde deadlines.

Regelgeving zet harde data. De PPWR geldt algemeen vanaf 12 augustus 2026, en daaruit volgen verplichtingen voor verpakkingsdata. Moet verpakkingsdata op een wettelijke datum beheerd en gerapporteerd worden, plan dan een eerste release rond die data. De overige scope volgt daarna.

Einddata van contracten spelen mee als je een PIM vervangt. Opzegtermijnen in het oude contract bepalen het laatste beslismoment. Voor clouddiensten beperkt de EU Data Act de opzegtermijn van de klant tot twee maanden. Daarna volgt een overgangsperiode van maximaal 30 kalenderdagen. De gids je PIM vervangen behandelt de exitkant.

Plan bij elke vaste datum terug:

1. Bepaal de minimale release die aan de verplichting voldoet.
2. Plan cutover en hypercare vóór de datum.
3. Plan de repetities terug vanaf de cutover.
4. Controleer of ontwerp en bouw in de resterende tijd passen.

Past de minimale release niet, besluit dan vroeg over een tussenoplossing. Wie het gat pas tijdens het testen ontdekt, heeft geen opties meer.