Product specificaties beheren: van chaos naar centraal product specificatie management

Wat zijn product specificaties?

Binnen een fabriek zijn er veel verschillende typen specificaties, bijvoorbeeld voor:

• grondstoffen

• halffabricaten

• eindproducten

• verpakkingsmaterialen

Daarnaast zijn er vaak ook specificaties voor niet-productgerelateerde materialen die wél invloed hebben op kwaliteit en veiligheid, zoals schoonmaakmiddelen, hulpstoffen, stoom, water en perslucht.

Een productspecificatie kan uiteenlopende gegevensgroepen bevatten, zoals:

• chemische / analytische parameters

• microbiologische gegevens

• organoleptische eigenschappen (smaak, geur, kleur, textuur)

• voedingskundige waarden

• claims en eigenschappen (kosjer, halal, GMO, allergenen, etc.)

• proces- en verpakkingsvoorschriften

• opslag- en distributievoorwaarden

• milieubelasting en sustainability-informatie

• gekoppelde documenten, afbeeldingen en etiketten

Een product specificatie management systeem zorgt ervoor dat al deze informatie gestructureerd, eenduidig en centraal beheerd wordt.

Waarom Product Specificatie Management steeds belangrijker wordt

Time-to-market verkorten

Nieuwe producten en varianten moeten steeds sneller op de markt komen. Bij productontwikkeling zijn meerdere afdelingen en externe partijen betrokken: R&D, QA, inkoop, marketing, productie, leveranciers, klanten.

Zonder centrale, digitale vastlegging van productspecificaties ontstaat er:

• veel heen-en-weer mailen met Excel- en Word-bijlagen

• risico op verschillende versies van dezelfde specificatie

• vertraging in besluitvorming en goedkeuring

Met een goed product specificatie systeem:

• verloopt communicatie papierloos en gecontroleerd;

• kunnen nieuwe producten sneller worden vrijgegeven;

• kunnen productgegevens automatisch worden doorgestuurd naar ERP, MES, LIMS en etiketteersystemen.

Dit verkort de time-to-market en reduceert fouten bij datainvoer.

Lagere inkoopkosten door harmonisatie

In veel organisaties kopen verschillende locaties grondstoffen met bijna dezelfde specificaties bij een groot aantal leveranciers.

Door product specificaties centraal te beheren, wordt zichtbaar:

• welke grondstoffen feitelijk gelijkwaardig zijn;

• waar harmonisatie mogelijk is;

• bij welke leveranciers volume geconcentreerd kan worden.

Dit kan leiden tot lagere inkoopkosten, betere contractvoorwaarden en minder complexiteit in de supply chain.

Externe informatievoorziening naar klanten en ketenpartners

De externe vraag naar productdata groeit snel, onder andere vanuit:

• handelspartners en retailers

• distributiebedrijven

• consumenten- en productdatabases

• overheid, NVWA, douane en certificerende instanties

Efficiënte informatievoorziening is alleen mogelijk als productdata in één centraal systeem worden beheerd en van daaruit via elektronische kanalen (bijv. GS1 Data Source) worden verspreid.

Lagere overheadkosten en minder fouten

Afdelingsgerichte systemen en losse documenten zorgen voor veel handmatig werk.

Met een integraal product specificatie systeem:

• vervallen dubbele registraties en lokale Excel-architecturen;

• zijn actuele specificaties online beschikbaar;

• vermindert de kans op werken met een verouderde versie;

• daalt het risico op afgekeurd product, rework en recalls.

Terminologie: receptuurbeheer, PDM en PLM

In het domein van product specificatie management komen verschillende termen voorbij:

• Receptuurbeheer – richt zich op recepten, samenstellingen en ingrediëntenverhoudingen; een onderdeel van de volledige productspecificatie.

• Product Data Management (PDM) – veel gebruikt in de maakindustrie (auto’s, vliegtuigen). Minder gangbaar als term in de voedingsindustrie.

• Product Lifecycle Management (PLM) – gaat over het beslisproces rondom de gehele levenscyclus van een product (intrede, groei, volwassenheid, uitfasering) en gebruikt data uit meerdere bronnen.

Product specificatie management richt zich op het beschrijven en beheersen van de inhoud van het product (receptuur, samenstelling, eigenschappen) en alle relevante specificaties, inclusief historie.

De geschiedenis van wijzigingen (wie heeft wat wanneer aangepast of goedgekeurd?) hoort thuis in het product specificatie systeem.

Productontwikkeling en de rol van productspecificaties

Een product is het resultaat van het werk van de afdeling productontwikkeling. Het ontwikkelproces is pas echt afgerond wanneer:

• alle relevante specificaties zijn vastgelegd;

• deze specificaties zijn goedgekeurd;

• de definitieve versie is overgedragen aan productie en ondersteunende systemen.

Productontwikkeling werkt meestal aan meerdere projecten tegelijk, in verschillende fasen (van idee tot marktintroductie).

Project- of portfolio-managementsystemen kunnen helpen bij het sturen van deze projecten, maar de inhoudelijke productspecificaties worden het best beheerd in een product specificatie systeem dat daar specifiek voor is ontworpen.

Product specificatie systemen: van basis tot advanced

Primair doel: productspecificaties beheren

Het primaire doel van een product specificatie systeem is het beheren van specificaties voor:

• grondstoffen

• halffabricaten

• eindproducten

• verpakkingsmaterialen

Voor de voedingsindustrie is het belangrijk dat de oplossing zijn oorsprong in deze sector heeft. Systemen uit andere sectoren kunnen flexibel zijn, maar missen vaak typische food-functies zoals:

• doorrekenen van ingrediënten, allergenen en voedingswaarden;

• genereren van labeldeclaraties en claims;

• ondersteuning van wettelijke etiketteringsregels.

Belangrijke verschillen tussen systemen

Systemen lijken op hoofdlijnen op elkaar, maar verschillen vaak sterk op onder meer:

• flexibiliteit (velden, templates, configuratie);

• versiebeheer (actieve versie, varianten, historisch overzicht);

• autorisatie (wie mag wat zien en wijzigen);

• workflow (wie keurt in welke volgorde goed);

• receptuurontwikkeling (simulaties, varianten, rework);

• audittrail (volledige wijzigingshistorie);

• interfaces (ERP, MES, LIMS, GS1);

• multi-site en multi-language ondersteuning.

Typische food-specifieke functionaliteit

Een product specificatie systeem voor de voedingsindustrie moet onder andere kunnen omgaan met:

• herverwerking en bijproducten;

• seizoensgebonden recepturen en alternatieve BOM’s;

• grondstoffen met wisselende samenstelling van actieve ingrediënten;

• multi-level BOM’s (grondstof → halffabricaat → eindproduct → verpakking);

• vocht- of massaverlies gedurende het proces;

• interne en externe specificaties (bijv. van meerdere leveranciers voor één grondstof).

Handige hulpmiddelen voor gebruikers

Het gebruiksgemak wordt mede bepaald door praktische tools, zoals:

• Zoekfuncties

  • In welke producten wordt deze grondstof gebruikt?

  • In welke specificaties komt dit allergeen voor?

• Vergelijken

  • Toon de verschillen tussen twee specificaties (bijvoorbeeld oude vs. nieuwe versie).

• Mass-update

  • Vervang een grondstof in één keer in meerdere producten, maar wel met controle.

• Receptoptimalisatie

  • Bereken varianten die bijvoorbeeld de laagste inkoopkosten opleveren.

• Kostprijsberekening

  • Maak een eerste kostprijsinschatting voordat het product in ERP wordt aangemaakt, ter voorkoming van vervuiling.

Belangrijke selectiecriteria voor een product specificatie systeem

Flexibiliteit en configuratie

Hoe makkelijk is het om:

• velden toe te voegen aan specificaties;

• templates aan te passen of nieuwe te maken;

• workflows te wijzigen?

Kunt u dit zelf doen of bent u afhankelijk van de leverancier? En hoe worden wijzigingen gecontroleerd doorgevoerd op bestaande, goedgekeurde specificaties?

Versiebeheer en audittrail

Er mag maar één versie van een specificatie actief en goedgekeurd zijn. Tegelijkertijd moet het mogelijk zijn om aan nieuwe varianten te werken.

Belangrijk:

• historie van alle versies;

• inzicht in welke versie actief was op een bepaald moment (bij klachten en audits);

• complete audittrail: wie heeft wanneer wat gewijzigd en goedgekeurd.

Workflow en autorisatie

Het opstellen, wijzigen en goedkeuren van specificaties raakt vaak meerdere afdelingen.

Een goede workflow ondersteunt:

• rol- en rechtenbeheer per type specificatie (grondstof, eindproduct, verpakking);

• configuratie van goedkeuringsroutes;

• automatische notificaties (bijv. per e-mail) van acties;

• inzicht in waar in het proces een specificatie “vast” staat.

Receptuurontwikkeling en labeldeclaraties

Voor productontwikkeling zijn functies belangrijk als:

• nieuwe recepturen en varianten ontwerpen;

• voorwaarden vastleggen vanuit opdrachtgevers of briefings;

• voedingswaarden automatisch doorrekenen;

• labeldeclaraties genereren volgens wetgeving;

• allergenen- en claimcontrole.

Interfaces met ERP, MES, LIMS en GS1

Data uit het product specificatie systeem worden gebruikt in:

• ERP (artikelen, BOM, kostprijs, logistieke data);

• MES (productie-instellingen, procesparameters);

• LIMS of kwaliteitssystemen (normen, limieten);

• GS1 Data Source (datastandaarden richting retail en ketenpartners).

Sommige systemen hebben standaardconnectoren, anderen werken met een generieke interfacetool of maatwerk. Interfaces bepalen voor een groot deel de toegevoegde waarde van het systeem.

Multi-site en multi-language

Voor bedrijven met meerdere vestigingen en internationale klanten is het belangrijk dat:

• meerdere sites met één systeem kunnen werken;

• toegang en zichtbaarheid per site ingesteld kunnen worden;

• specificaties in meerdere talen onderhouden en gepubliceerd kunnen worden;

• labeldeclaraties meertalig beheerd worden (incl. fallback bij ontbrekende vertalingen).

IT-technologie en prijsmodellen

De meeste oplossingen waren traditioneel client/server en draaiden on-premise. Steeds meer leveranciers bieden nu ook SaaS-oplossingen (cloud).

Belangrijke keuzes:

• on-premise vs. cloud;

• eenmalige licentie + jaarlijkse support vs. volledig abonnement (opex);

• extra kosten voor implementatie, interfaces, rapportages en training.

Prijsverschillen tussen systemen zijn groot en hangen nauw samen met functionaliteit, schaalbaarheid en licentiemodel.

Selectie van een product specificatie systeem: stappen in het traject

Oriëntatiefase

In de oriëntatiefase wordt:

• bepaald welke doelen u wilt bereiken;

• gekeken naar knelpunten in de huidige werkwijze;

• geïnventariseerd welke standaardoplossingen er zijn.

Eisen en wensen vastleggen

In een programma van eisen wordt vastgelegd:

• functionele eisen (inclusief typische cases uit uw bedrijf);

• technische eisen (architectuur, integraties, performance, security);

• profiel van de gewenste leverancier (sectorervaring, support, implementatieaanpak).

Betrek alle afdelingen die met productspecificaties werken (R&D, QA, inkoop, productie, logistiek, IT). Gebruikersscenario’s helpen om eisen concreet te maken en later weer te herleiden.

Shortlist en productdemo’s

Op basis van documentatie en gesprekken wordt een shortlist opgesteld van leveranciers die in principe kunnen leveren wat u nodig heeft. Deze leveranciers worden uitgenodigd om:

• een offerte uit te brengen;

• een productdemo te geven op basis van een demoscript met uw eigen scenario’s.

De demo focust niet alleen op harde eisen, maar ook op werkbaarheid, gebruiksgemak en snelheid.

Principekeuze en referentiebezoeken

Op basis van offertes en demo’s blijven één of twee kandidaten over. In deze fase:

• worden verdiepende workshops georganiseerd;

• vinden referentiebezoeken plaats bij vergelijkbare bedrijven;

• wordt een principekeuze voorbereid.

Een goede voorbereiding en gerichte vragenlijst helpen om referentiebezoeken maximaal waardevol te maken.

Contractonderhandeling en blauwdrukfase

In de contractfase worden prijzen, scope, verantwoordelijkheden, planning, opleiding en support vastgelegd. Vaak is een blauwdrukfase een verstandige stap:

• samen met de leverancier wordt een representatief deel van de gewenste functionaliteit in het systeem ingericht;

• fit/gap wordt in detail zichtbaar;

• scope, planning en kosten worden aangescherpt.

Op basis van de resultaten van de blauwdrukfase kan een definitieve go/no-go-beslissing worden genomen.

Veelvoorkomende valkuilen

• Te veel uitgaan van de huidige werkwijze in plaats van best practices.

• Gebrek aan een duidelijke IT-strategie en applicatielandschap.

• Het project benaderen als “afdelingsfeestje” in plaats van bedrijfsbreed programma.

• Medewerkers onvoldoende betrekken en impact op hun werk niet duidelijk maken.

• Overgangsfase onderschatten: tijdelijke workarounds, incomplete interfaces.

Implementatie: van gekozen applicatie naar succesvol gebruik

Projectorganisatie en veranderimpact

De invoering van een product specificatie systeem raakt vrijwel alle afdelingen. Het projectteam en de stuurgroep moeten:

• de scope bewaken;

• prioriteiten stellen;

• veranderingen begeleiden;

• risico’s en overgangsscenario’s managen.

Standaardisatie en artikelstructuur

Productspecificaties zijn opgebouwd uit meerdere niveaus:

• individuele gegevenselementen (chemische parameters, tekstblokken, eenheden);

• templates (hoe een specificatie eruitziet);

• complete specificaties per product.

Standaardisatie kan op elk van deze niveaus plaatsvinden. Hoe hoger het niveau van standaardisatie, hoe groter de voordelen.

De invoering van een product specificatie systeem is ook hét moment om de artikelstructuur tegen het licht te houden. Een goede structuur is cruciaal voor:

• consistent gebruik van specificaties;

• goede interfaces met ERP, MES, LIMS;

• rapportage en analyse.

Artikelcodering en “single source of truth”

Veel artikelcoderingen zijn in de loop van de jaren gegroeid en niet meer logisch of consequent. Nieuwe generaties medewerkers vertrouwen liever op systemen dan op ‘slimme’ artikelcodes.

Hoewel aanpassen van artikelcodering niet altijd noodzakelijk is, kan de implementatie van een product specificatie systeem een goed moment zijn om:

• naar kortere, betekenisloze codes over te stappen;

• rollen en systemen meer te laten bepalen “wat het is” in plaats van het nummer.

Interfaces als succesfactor

Het uitgangspunt: alle productgerelateerde data worden in het product specificatie systeem beheerd en van daaruit gevoed naar andere systemen.

Belangrijke vragen:

• Welke gegevens moeten naar welke systemen (ERP, MES, LIMS, GS1)?

• Op welk moment in het goedkeuringsproces worden gegevens doorgestuurd?

• Gebruiken alle systemen dezelfde artikelstructuur en codering?

Goede interfaces bepalen in hoge mate de daadwerkelijke winst van het nieuwe systeem.

Optimalisatie na livegang: voorkomen dat spreadsheets terugkomen

Als het project is afgerond en het team is ontbonden, begint de fase waarin het systeem echt “zijn waarde moet bewijzen”. Zonder aandacht en onderhoud ligt het risico op de loer dat:

• gebruikers workarounds bouwen;

• Excel-bestanden opnieuw ontstaan;

• de toegevoegde waarde van het systeem langzaam afneemt.

Periodieke systeemscan

Het is verstandig om periodiek (bijvoorbeeld jaarlijks) een scan te doen op:

• gebruik van het systeem vs. beoogde werkwijze;

• datakwaliteit en consistentie;

• mate van standaardisatie;

• aansluiting op nieuwe processen en eisen.

Nieuwe wensen en functionaliteit

Door intensiever gebruik én door veranderingen in markt en regelgeving komen nieuwe wensen naar voren. Deze moeten:

• geëvalueerd worden op businesswaarde;

• waar zinvol worden vertaald in nieuwe functionaliteit of inrichting;

• gepland worden in releases, in overleg met de leverancier.

Interfaces en workarounds

Na verloop van tijd ontstaan soms nieuwe datavelden of extra eisen in andere systemen. De neiging is dan snel om data “even handmatig” in te vullen buiten het product specificatie systeem om. Dit zijn ongewenste workarounds.

Blijf interfaces actueel houden om “één bron van waarheid” te behouden.

Bijscholing van medewerkers en supportcontract

Medewerkers zijn bij de invoering getraind, maar nieuwe collega’s of nieuwe rollen krijgen vaak alleen een korte uitleg van een collega. Daardoor:

• wordt slechts een deel van de functionaliteit gebruikt;

• ontstaan eigen methodes en Excel-lijsten;

• raakt de standaard werkwijze verwaterd.

Regelmatige bijscholing en het goed benutten van het supportcontract helpen om het systeem optimaal te blijven gebruiken.

Ondersteuning bij product specificatie management

Greywise heeft ruime ervaring met:

• het selecteren van product specificatie systemen;

• het inrichten en implementeren bij voedings- en procesbedrijven;

• het optimaliseren van bestaande oplossingen en applicatielandschappen.

Bent u benieuwd:

• welk systeem het beste past bij uw organisatie;

• hoe u product specificatie management kunt centraliseren;

• hoe u productdata slim kunt laten samenwerken met ERP, MES en LIMS?

Neem dan gerust vrijblijvend contact met ons op voor een verkennend gesprek.