Er is sprake van een groot aantal verschillende specificaties. Bijvoorbeeld specificaties voor grondstoffen, halffabricaten, eindproducten en verpakkingsmaterialen. Hoewel niet direct productgerelateerd hebben veel bedrijven ook specificaties voor de verschillende materialen die in de productie-omgeving worden gebruikt, zoals schoonmaakmiddelen, chemicaliën, stoom, water, perslucht, etc.
Een specificatie kan veel verschillende groepen van gegevens bevatten, zoals: chemisch/analytisch, microbiologisch, organoleptisch, voedingskundig, claims (kosjer, GMO, allergenen, etc.), proces- en verpakkingsvoorschriften, opslag- en distributiegegevens, milieubelasting en gekoppelde afbeeldingen en documenten.
Steeds vaker en steeds sneller moeten nieuwe producten worden geïntroduceerd. Een korte Time-to-Market wordt een belangrijk concurrentiewapen. Bij de ontwikkeling van een product zijn meerdere afdelingen en externe partijen betrokken. Alleen met een papierloze en gecontroleerde communicatie tussen alle partijen kan kostbare tijd worden gewonnen.
Als een productiebedrijf overschakelt op een nieuw product of een nieuwe productvariant dan moeten de bijbehorende productgegevens in de verschillende productie-ondersteunende systemen, zoals ERP, LIMS en MES, worden ingevoerd. Er wordt veel tijd gewonnen en er worden minder fouten gemaakt als de gegevens automatisch in die systemen ingevoerd worden.
Verschillende locaties kopen grondstoffen met bijna dezelfde specificaties bij een groot aantal verschillende leveranciers. Harmonisatie van de specificaties en het beperken van het aantal leveranciers kan tot substantiële inkoopvoordelen leiden.
De behoefte aan productinformatie bij handelspartners neemt zeer snel toe. Hierbij kan men denken aan leveranciers, distributiebedrijven, retailorganisaties, consumentendatabases, overheid, douane, etc.
Deze informatieverschaffing kan alleen efficiënt gebeuren als productinformatie in één systeem wordt opgeslagen en beheerd en van daaruit langs elektronische weg wordt verspreid.
De huidige afdelingsgerichte systemen vereisen veel handmatige arbeid. Kwaliteitsprocedures, die weer apart worden onderhouden, bepalen hoe de uitwisseling van gegevens tussen deze systemen dient te gebeuren. Bij een integraal systeem vervalt deze inspanning. De productspecificaties zijn online beschikbaar waardoor de kans op het gebruik van niet actuele specificaties en daarmee de kans op af te keuren of her te verwerken product vermindert.
In het domein van product specificatie management worden ook andere begrippen gehanteerd.
Voorbeelden zijn:
Receptuurbeheer dekt niet de gehele lading van product specificaties; in feite is het recept een onderdeel van de productspecificatie.
Product Data Management wordt vooral gebruikt in de technische industrie, zoals bij de productie van auto’s of vliegtuigen. In de voedingsindustrie is deze term minder gebruikelijk.
Product Lifecycle Management is een duidelijk ander proces dan product specificatie management. PLM is een besluitvormingsproces over de levenscyclus van een product, waarbij gebruik wordt gemaakt van een grote hoeveelheid gegevens die uit verschillende bronnen kunnen komen, zoals verkoopstatistieken, concurrentieanalyse en trendinformatie.
De “geschiedenis” van de samenstelling of verpakking van een product (wanneer is wat door wie veranderd?) is wel te vinden in het product specificatie systeem.
Een product is het resultaat van de inspanning van de afdeling productontwikkeling. Het ontwikkelproces is pas geheel afgesloten als alle specificaties zijn vastgelegd en goedgekeurd en zijn overgedragen aan productie.
Productontwikkeling werkt tegelijkertijd aan meerdere projecten die elk in een andere fase van de besluitvorming kunnen zijn (van idee, tot goedgekeurd product).
Er zijn applicaties waarmee de voortgang van de projecten en het besluitvormingsproces kan worden ondersteund. Deze worden op deze site niet behandeld, maar er zijn leveranciers die naast product specificatie systemen ook project management systemen leveren.
E-book
In Nederland zijn er tal van leveranciers van Product Specificatie Management Systemen. Als onafhankelijke adviseur hebben wij al meerdere bedrijven met het selecteren van de juiste leverancier geholpen . De ervaringen en expertise die wij hebben opgebouwd, delen we graag met jou.
Mocht je benieuwd zijn welke leverancier de beste oplossing voor jouw probleem heeft, neem gerust vrijblijvend contact met ons op.
Op het gebied van Product Lifecycle Management zou je contact kunnen opnemen met deze leverancier: SyncForce – SyncForce
Neem dan geheel vrijblijvend contact met ons op.
Welke applicatie het beste bij uw organisatie past is afhankelijk van de doelstellingen van uw bedrijf. Het formuleren van de doelstelling (welk probleem willen we oplossen?) en het vaststellen van de gewenste functionaliteit en technische kenmerken is dan ook altijd de eerste stap.
Er zijn veel systemen die dit kunnen, maar voor de voedingsindustrie is het essentieel dat het systeem zijn oorsprong heeft in deze industrie. Systemen die hun oorsprong hebben in een andere sector, bv. vliegtuig- of autoindustrie, zijn wellicht flexibel in te richten, maar missen de specifieke functies die nodig zijn in de voedingsindustrie, zoals bijvoorbeeld het doorrekenen van ingrediënten en allergenen en het maken van labeldeclaraties.
De systemen die voortkomen uit de voedingsindustrie vertonen veel overeenkomsten, maar ook een groot aantal verschillen.
De overkomst is dat ze allemaal in staat zijn om specificaties te beheren van grondstoffen, halffabricaten, eindproducten en verpakkingsmaterialen.
Punten waarop ze kunnen verschillen zijn bijvoorbeeld:
Hoe eenvoudig is het om een bepaald veld aan een specificatie toe te voegen? Kunt (wilt) u dit zelf doen of bent u hiervoor afhankelijk van uw leverancier? Hoe kan deze wijziging op een gecontroleerde manier worden doorgevoerd op reeds goedgekeurde specificaties?
Er is slechts één versie van een specificatie goedgekeurd en in gebruik. Tegelijkertijd kan er ook al gewerkt worden aan een of meerdere varianten van deze specificatie, waarvan er een op een later tijdstip kan worden goedgekeurd. De specificatie die goedgekeurd was krijgt nu de status ‘vervallen’, maar blijft bewaard. Dit laatste is belangrijk om in geval van een klacht terug te kunnen zien welke specificatie actief was op het moment dat het product gemaakt is.
Niet iedereen kan zomaar een specificatie van status veranderen. Bepaalde medewerkers hebben de bevoegdheid gekregen om dit te doen voor een bepaald type specificatie, bijvoorbeeld een grondstofspecificatie. Dit kunnen ze weer niet voor bijvoorbeeld een eindproductspecificatie; die mogen ze alleen inzien, maar niet wijzigen.
Afhankelijk van de omvang van uw bedrijf zijn bij het proces van opstellen, wijzigen en goedkeuren van specificaties meerdere of een groot aantal medewerkers betrokken. Als het aantal medewerkers groter wordt is het essentieel dat het besluitvormingsproces goed door het systeem ondersteund wordt. Dan is het belangrijk om per type specificatie een autorisatie workflow te kunnen configureren, waarin wordt vastgelegd wie (en in welke volgorde) de specificatie moet goedkeuren. De betrokkenen worden er met een bericht, bv. email, op attent gemaakt dat van hun een actie in het systeem verwacht wordt. Er is een goed overzicht in welke stap van de goedkeuring het proces zich bevindt, m.a.w. op wie de goedkeuring staat te wachten.
Het maken van nieuwe recepturen of varianten op huidige recepturen wordt door veel product specificatie systemen ondersteund. Vanuit product ontwikkeling is het wenselijk om met nieuwe grondstoffen te werken en voorwaarden in te stellen die vanuit de opdrachtgever of de product ontwikkeling briefing zijn geformuleerd. Ook het doorrekenen van de voedingswaarden en het opstellen van labeldeclaraties zijn functionaliteiten die door product specificatie systemen worden ondersteund.
Het wordt steeds belangrijker dat wijzigingen in een specificatie worden vastgelegd en gedocumenteerd. Ook moet terug te vinden zijn wie, wanneer de status van een specificatie heeft veranderd.
De gegevens die in het systeem worden vastgelegd worden ook gebruikt in andere bedrijfssystemen zoals ERP, MES en LIMS. Sommige systemen bieden voor de communicatie met de grotere ERP systemen standaard “connectoren” aan. Andere hebben een flexibel te configureren interface tool en bij sommige systemen is maatwerk noodzakelijk.
Een bekend voorbeeld van een extern systeem is GS1 Data Source. Het zou natuurlijk handig zijn als de leverancier van het product specificatie management systeem er ook meteen voor kan zorgen dat de juiste data in het juiste formaat naar GS1 gestuurd kunnen worden.
Als uw bedrijf meerdere productievestigingen heeft (die verschillende type producten maken), dan heeft het voordelen om gebruik te maken van één product specificatie management systeem. In sommige situaties kan het gewenst zijn dat een medewerker van een vestiging niet alles kan zien van de andere vestigingen. Dit moet met de Autorisatie functie op te lossen zijn.
U kunt klanten of productievestigingen hebben in meerdere landen. Dan is het belangrijk dat de specificaties in de taal van het land te onderhouden, maar vooral te lezen zijn. Sommige systemen bieden hiervoor een uitgebreide functionaliteit die het mogelijk maakt met een druk op de knop van taal te wisselen. Een product specificatie systeem kan op meerdere niveau’s meertalig zijn, bijvoorbeeld op het interface niveau, maar ook op template niveau of op specificatie niveau. Bij het opstellen van de labeldeclaraties is het wenselijk om de uitkomst van de labeldeclaraties in meerdere talen te kunnen bewaren. Hoe gaat het systeem om met ontbrekende vertalingen, valt het terug op de standaard taal of krijgt de gebruiker een notificatie?
Bepaalde aspecten zijn inherent aan de processen in de voedingsindustrie. Een product specificatie management systeem moet hiermee om kunnen gaan. Enkele voorbeelden zijn:
Het gebruikersgemak van een systeem wordt mede bepaald door handige hulpmiddelen, zoals:
Er zijn grote verschillen in de kosten van de licenties voor de verschillende product specificatie management systemen. Voor een groot deel verklaarbaar uit de mogelijkheden die de systemen bieden. Daarnaast zijn er verschillen in de manier van afrekenen. Bij de meeste pakketten is dat een bedrag bij aanschaf en jaarlijks terugkerende support kosten. Andere pakketten hanteren alleen een bepaald bedrag per jaar.
Naast de kosten van de licentie voor het gebruik van de software moet rekening gehouden worden met de kosten van de implementatie. Bijvoorbeeld voor de ondersteuning die de leverancier biedt bij het inrichten van het systeem of het maken van interfaces of specifieke rapporten.
De meeste applicaties zijn client/server applicaties en draaien op servers bij u in het bedrijf of op servers bij uw IT partner. Steeds vaker komen er SaaS oplossingen (Software as a Service), die volledig draaien op de servers van de leverancier. In de Cloud dus.
Het selectieproces bestaat uit verschillende fasen:
In de oriëntatiefase wordt vastgesteld welke doelen men wil bereiken en wordt gekeken naar de knelpunten in de huidige processen. Welke standaard oplossingen zijn beschikbaar en wat zijn globaal de mogelijkheden.
In het programma van eisen wordt vastgelegd aan welke functionele en technische eisen de applicatie moet voldoen. De functionele eisen worden aangevuld met cases waarin bepaalde voor uw bedrijf typische problematiek is beschreven.
Ook wordt vastgesteld wat het profiel is van de leverancier die het beste bij uw bedrijf past.
Tijdens het opstellen van de eisen en wensen, moeten alle afdelingen die te maken krijgen met het product specificatie systeem betrokken worden.
Het opstellen van gebruikersscenario’s zorgt ervoor dat de betrokkenen een beeld krijgen van de functionaliteiten van een product specificatie systeem en zorgt ervoor dat later in het proces de eisen eenvoudiger zijn te herleiden tot hun oorsprong.
Aan de hand van de beschikbare informatie wordt een shortlist opgesteld van leveranciers die in principe in staat zouden moeten zijn de gewenste applicatie te leveren en te implementeren. Deze leveranciers worden uitgenodigd om een aanbieding te maken op het programma van eisen.
Door middel van de product demo zijn de betrokkenen beter in staat een beeld te vormen van het product specificatie systeem. Het voornaamste doel van een product demo is dan ook om niet de harde eisen, maar de werkbaarheid te toetsen. Voelt het systeem intuïtief aan? is het snel en eenvoudig of traag en ouderwets. Zaken die niet direct uit een PvE op te maken zijn. Een opstellen van een goed demoscript maakt het mogelijk de product demo’s objectief met elkaar te kunnen vergelijken.
Aan de hand van de offertes en de presentaties van de leveranciers blijven één of twee leveranciers over. Deze leveranciers kunnen gevraagd worden dieper op een aantal zaken in te gaan, bijvoorbeeld door een aantal workshops te organiseren. Ook het inplannen van referentiebezoeken kan in deze fase helpen om tot een juist oordeel te komen en op basis daarvan een definitieve keuze te maken. Bereid het bezoek goed voor en stel vooraf een vragenlijst op.
Hierin gaat het uiteraard over de prijs, maar nog belangrijker is helderheid over de omvang van de levering is, wie welke verantwoordelijkheid en taken heeft en hoe wordt omgegaan met bijvoorbeeld scope aanpassingen. In het contract worden ook zaken vastgelegd als documentatie, training, go-live ondersteuning, automatische data-conversie en het support contract.
De huidige manier van werken is voor een groot deel bepaald door de mogelijkheden (of beter: beperkingen) van de bestaande IT systemen. Taken liggen nu bij een bepaalde persoon of afdeling omdat dat beter past bij de applicaties die gebruikt worden. Het is beter om te kijken naar de mogelijkheden van de nieuwe applicaties die vaak gebaseerd zijn op “best practice” werkwijzen.
De huidige werkwijze in een nieuwe applicatie dwingen leidt in de regel tot veel maatwerk, sub-optimale oplossingen, duur onderhoud en levert de organisatie nooit de maximale voordelen.
Een product specificatie management systeem is het centrale systeem waaruit andere IT systemen gevoed worden met product gerelateerde data. Dit is een goed uitgangspunt. Maar in de praktijk wordt er vaak van afgeweken vanwege persoonlijke voorkeuren of afdelingsbelangen. Een sterke visie en aansturing is een voorwaarde om het maximale uit het nieuwe product specificatie management systeem te halen.
De afdeling die de klantspecificaties onderhoudt loopt tegen de grenzen aan van de huidige applicaties (vaak Excel of Word). Klanten beginnen te klagen en er gaan te veel zaken fout. De afdeling wil een nieuwe applicatie om hun probleem op te lossen. Dit kan natuurlijk, maar de organisatie laat veel kansen liggen wanneer niet over de afdeling heen wordt gekeken. Denk hierbij aan grondstof- en verpakkingsspecificaties, kwaliteitsnormen, verpakkingsspecificaties, procesvoorschriften, logistieke specificaties, etc.
Het kan wenselijk zijn om voor een aantal betrokkenen na te gaan wat de impact is van een nieuw systeem op de dagelijkse werkzaamheden. Als betrokkenen het gevoel krijgen dat ze meer werk moeten gaan doen, of dat hun werkzaamheden grotendeels vervallen kan dit op weerstand stuiten. Met een impact analyse wordt het voor de betrokkenen duidelijker wat er gaat veranderen.
Nadat er een product specificatie systeem gekozen is, zal er een periode van overgang zijn. Het is wenselijk om de risico’s van deze overgang in kaart te brengen. De koppelingen met de huidige systemen zullen niet vanaf dag één gereed zijn, waardoor er tussentijdse oplossingen nodig zijn. Terwijl het systeem verder wordt uitgebreid moet de continuïteit van de bedrijfsvoering gewaarborgd blijven.
Bij het implementeren van een product specificatie systeem spelen een aantal factoren een rol. Er worden hier een aantal kritieke factoren genoemd:
Het invoeren van een product specificatie systeem zal veranderingen met zich mee brengen. Het is de taak van het projectteam en de stuurgroep om dit in goede banen te leiden.
Een groot aantal factoren bepalen het succes van het project:
Zoals voor elk project is ook hier projectmanagement van groot belang. Hierover is voldoende interessante literatuur te vinden en er zijn ook goede trainingen beschikbaar. Het noemen waard is de aanpak die wordt aangereikt door de Critical Chain Project Management methode die gebaseerd is op de theorieën van E. Goldratt.
Afhankelijk van de doelstellingen en de omvang van de onderneming kan standaardisatie op verschillende niveaus worden nagestreefd. Dit kan omdat een specificatie ook uit meerdere niveaus is opgebouwd.
Allereerst wordt vastgelegd uit welke gegevenselementen een specificatie kan bestaan. De benaming, de codering en de definities worden vastgelegd van de verschillende elementen. Hierbij kan men denken aan de voedingskundige parameters, de chemische parameters, de microbiologische parameters, standaard teksten, de eenheden, etc.
Standaardiseert men uitsluitend op het niveau van de elementen, dan is men er in ieder geval zeker van dat alle vestigingen dezelfde benaming en definities hanteren. Hierdoor kunnen medewerkers uit andere vestigen de specificaties ook lezen en juist interpreteren.
Een stap verder is de standaardisatie van de template. Hierbij is niet alleen gestandaardiseerd op de gegevenselementen, maar ook op de inhoud en de layout van de specificatie. Elke vestiging heeft nu nog de mogelijkheid om voor elk product zijn eigen specificatie op te stellen op basis van de gestandaardiseerde template.
Op het hoogste niveau is ook de specificatie zelf gestandaardiseerd en gebruiken meerdere vestigingen dezelfde specificatie voor hetzelfde product. Het zal duidelijk zijn dat de meeste voordelen voor een bedrijf te behalen zijn bij deze vorm van standaardisatie.
Bij grotere organisaties met meerdere vestigingen is het belangrijk dat er iemand wordt aangewezen die dit standaardisatieproces in goede banen gaat leiden. Een strakke aansturing is belangrijk; het algemeen belang moet zwaarder wegen dan lokale inzichten en verworvenheden.
De consumenteneenheid gaat in een omdoos. Soms gaan verschillende consumenteneenheden gemixt in een grotere verpakking, die zelf ook weer een consumenteneenheid is. Omdozen gaan op een pallet. De pallet gaat als geïdentificeerde eenheid de logistieke keten in.
De consumenteneenheid is opgebouwd uit meerdere grondstoffen en halffabricaten. Die halffabricaten kunnen ook weer opgebouwd zijn uit grondstoffen en andere halffabricaten. Dit resulteert in een geneste structuur die meerdere lagen diep kan zijn. Bepaalde halffabricaten worden in meer dan één consumenteneenheid gebruikt.
De invoering van een product specificatie systeem is een goed moment om ook de artikelstructuur tegen het licht te houden. Deze is in de loop der jaren ontstaan en vaak bepaald door de beperkingen van de bestaande informatiesystemen. Een goede artikelstructuur bepaalt in hoge mate de effectiviteit van het product specificatie systeem en is een voorwaarde voor de gegevensuitwisseling met interne en externe systemen.
Bij veel bedrijven is de huidige artikelcodering in de loop van de jaren ontstaan. In het verleden was het belangrijk dat de magazijnmedewerker en operator aan het artikelnummer moesten kunnen zien om welk materiaal het ging. In sommige gevallen kon men zelfs de samenstelling van het product er uit aflezen. Dit heeft geleid tot lange artikelnummers en door groei van uw organisatie, uitbreidingen en overnames is de consistentie verloren gegaan. Nieuwe medewerkers zijn niet meer zo geneigd de artikelnummers van buiten te leren. Het zijn er te veel geworden en de nieuwe generatie zegt steeds vaker “daar hebben we systemen voor”.
Het streven is tegenwoordig om artikelnummers “betekenisloos” te laten zijn, waarbij we misschien aan het eerste cijfer nog mogen zien om welk type materiaal het gaat.
Nu is in de regel het aanpassen van de artikelcodering geen noodzakelijke voorwaarde bij de implementatie van een product specificatie management systeem, maar wel een goed moment om er eens kritisch naar te kijken.
Het uitgangspunt is dat alle product gerelateerde gegevens in het product specificatie systeem worden beheerd. Dit zijn bijvoorbeeld ook de gegevens die iets zeggen over de kwaliteitseisen waar het product aan moet voldoen. De resultaten van de analyses worden vaak in een kwaliteitssysteem of LIMS opgeslagen en beoordeeld. Het is dan handig dat de gegevens automatisch vanuit het specificatie management systeem naar het kwaliteitssysteem of LIMS worden doorgegeven op het moment dat de specificaties van het product zijn goedgekeurd. Zo zullen bijvoorbeeld ook gegevens nodig zijn in het ERP systeem en in MES.
De juiste gegevens moeten op het juiste moment aan de andere systemen worden doorgegeven. Welke gegevens zijn dit? Wat is het juiste moment? Welke technieken gebruiken we hiervoor? Gebruiken we alle systemen dezelfde artikelstructuur en de juiste artikelcodering?
Kortom, goede interfaces bepalen voor een groot deel de toegevoegde waarde van het nieuwe product specificatie management systeem.
De invoering zal gepaard gaan met veranderingen. Zoals we al gezien hebben wijzigt wellicht de artikelstructuur en de artikelcodering. Vestigingen zullen moeten wennen aan de nieuwe inhoud en vorm van de specificaties. Werk dat vroeger in spreadsheets gedaan werd zal vervallen. Interfaces maken handmatige invoer overbodig en taken zullen misschien bij een andere afdeling of medewerker komen te liggen. Van de start van het project zal er veel aandacht moeten zijn voor het in goede banen leiden van deze veranderingen.
Als een project is afgerond, het project team ontbonden is en de gebruikers aan de slag zijn dan is het van belang een goede opvolging te geven. Worden de gebruikers aan hun lot overgelaten dan ontstaan creatieve work arounds, verschijnen de eerste spreadsheets weer en zal de toegevoegde waarde van het product specificatie systeem steeds meer afnemen.
Daarom is het aan te bevelen periodiek, bijvoorbeeld eenmaal per jaar, een scan uit te laten voeren op het systeem om het optimale gebruik te garanderen.
Door het intensiever werken met het systeem en soms nieuwe ontwikkelingen in het bedrijf of in de markt komen nieuwe wensen naar boven. Deze zullen moeten worden beoordeeld en waar nodig zou dit moeten leiden tot nieuwe functionaliteit.
Een goede leverancier is continu bezig zijn product aan te passen en uit te breiden om zo goed mogelijk te voldoen aan de wensen van zijn klanten, nieuwe wet- en regelgeving en veranderende marktomstandigheden. In samenwerking met de leverancier kan worden bekeken of de nieuwe functionaliteit toegevoegde waarde levert voor het bedrijf. Als dit zo is kan worden besloten deze functionaliteit in te voeren.
Na een tijd blijkt dat er een extra veld nodig is in de logistieke stamdata in het ERP systeem. Dit extra veld kan nog eenvoudig worden toegevoegd in de specificatie in het product specificatie systeem. Wel blijkt dat de aanpassing van de interface wat prijzig is of niet tijdig door de ICT-afdeling wordt opgepakt. Dan wordt om praktische reden besloten dit ene veldje dan maar handmatig in het ERP in te vullen. Weer een ongewenste work around.
Medewerkers zijn tijdens de invoering getraind in het gebruik van het systeem. In de regel wordt daar de meest noodzakelijk functionaliteit behandeld die nodig is voor de uitvoering van de dagelijkse werkzaamheden. Dat het systeem nog meer mogelijkheden heeft is onvoldoende bekend en er worden weer work arounds verzonnen voor zaken die ook standaard met het systeem zouden kunnen.
Aan het einde van het project is met de leverancier een contract afgesproken waarin is vastgelegd welke ondersteuning de leverancier biedt, binnen welke tijd en onder welke voorwaarden. Na een zekere tijd moet geëvalueerd worden of de leverancier zijn verplichtingen volgens afspraak is nagekomen of het contract niet bijgesteld kan worden.
E-book
