Wat gebeurt er als de productnaam bij verkoop niet overeenkomt met de naam in het magazijn en de webshop nog de foto van vorig jaar toont? Iemand bestelt het verkeerde artikel. Een koper vraagt om details die niemand kan vinden en medewerkers moeten spreadsheets, oude e-mails, pdf's van leveranciers en vijf verschillende systemen controleren om een eenvoudige vraag te beantwoorden. Welkom bij een nieuwe kennisupdate van M365, FMI, OT, MD, MO Peters en vandaag behandelen we Dynamics 365 productinformatiebeheer, kortweg PIM genoemd. Aan het einde begrijp je hoe het eengedeeld productrecord bijhoudt, hoe producten in verschillende vormen kunnen voorkomen en hoe die informatie de bedrijfsonderdelen bereikt die het nodig hebben. Eén productrecord voor het hele bedrijf. Een product lijkt voor buitenstaanders misschien eenvoudig. Gewone naam, een prijs en misschien een afbeelding. Achter de schermen raakt datzelfde product bijna elk onderdeel van een bedrijf.

Hier is hoe dat in de praktijk werkt. Inkoop heeft leveranciersdetails en eenheden nodig, terwijl magazijnteams informatie nodig hebben om artikelen te ontvangen, op te slaan en te verzamelen. Verkoop heeft duidelijke namen nodig. Financiën heeft de juiste instellingen nodig en de webshop heeft nauwkeurige foto's en beschrijvingen nodig. Elk team bekijkt hetzelfde product vanuit een andere invalshoek. Zonder één gedeelde plek voor die informatie maken mensen vaak hun eigen kopieën. Het productteam houdt een spreadsheet bij. Verkoop voert een kortere naam in het systeem in. Het magazijn gebruikt een artikelnummer met een andere omschrijving en marketing slaat afbeeldingen op in een gedeelde map, terwijl de klantenservice oude e-mails doorspit. Die aanpak creëert eerst kleine verschillen en daarna verspreiden die verschillen zich. Stel je een bedrijf voor dat een geïsoleerde waterfles verkoopt.

De leverancier wijzigt deze van 500 milliliter naar 750 milliliter. Het inkoopteam krijgt de nieuwe details, maar de webshop toont nog steeds de oude inhoud. Verkoop stuurt klanten het verkeerde specificatieblad en magazijnmedewerkers zien een productlabel dat niet overeenkomt met de bestelling. Niemand had de bedoeling om een probleem te veroorzaken. Elk team werkte simpelweg met een andere kopie. Dynamics 365 productinformatiebeheer geeft het bedrijf één centrale productdefinitie. Zie het als een gedeeld archief voor productinformatie. In plaats van dat elke afdeling een eigen map bijhoudt, hoort het productrecord de plek waar de afgesproken details staan. Mensen gebruiken die definitie in het hele bedrijf in plaats van steeds opnieuw dezelfde informatie in te typen. Het productnummer vormt het hart van dat record. Het helpt het bedrijf om het product consistent te identificeren, zelfs als verschillende teams er verschillende termen voor gebruiken.

Naast dat nummer sla je de naam en beschrijving op en identificeer je of het een fysiek item is dat je kunt voorradig houden of een dienst die het bedrijf levert. Het record bevat ook de eenheden die mensen gebruiken wanneer ze het product kopen, verkopen, opslaan of tellen. Een doos, een stuk, een kilogram, een liter of een pallet kunnen in het dagelijkse werk heel verschillende dingen betekenen. Wanneer die eenheden duidelijk zijn, hebben inkoop- en magazijnwerk een veel beter uitgangspunt. Productinformatie kan ook afbeeldingen, bijlagen, categorieën, kenmerken en vertalingen voor namen en omschrijvingen bevatten. Het record kan dus meer bevatten dan alleen een label. Het kan het leveranciersdocument bevatten dat een product uitlegt, een foto die helpt bij de herkenning, vertaalde omschrijvingen voor teams of klanten die in een andere taal werken, en details zoals materiaal, merk- of verwerkingsinstructies.

De gedeelde definitie gaat vooraf aan lokaal gebruik. Een bedrijf definieert een product één keer en laat vervolgens verschillende bedrijfsonderdelen het gebruiken wanneer dat nodig is. Het gedeelde record houdt algemene feiten bij elkaar, terwijl elk gebied later zijn eigen bedrijfsinstellingen toepast. Je hoeft het product niet telkens vanaf nul op te bouwen wanneer een ander team het nodig heeft. Dat is een veel nettere manier van werken, maar een naam en omschrijving vertellen nog niet het volledige productverhaal. Een enkele spijkerbroek kan veranderen in vele artikelen zodra kleur en maat in beeld komen. Productmasters en varianten, de stamboom. Dus wanneer wordt één product vele producten? Denk aan een spijkerbroek. Je ziet een broek waarschijnlijk als één product, maar het magazijn kan niet zomaar een willekeurig exemplaar pakken als een bestelling vraagt om zwart in maat large. En verkoop kan geen blauwe spijkerbroek in extra smal beloven als die combinatie niet echt bestaat.

Dat is waar Dynamics 365 tussen beiden komt met een simpel idee. Het scheidt een basisproduct van een productmaster. Een simpel product is één vast artikel. Stel je een doos printerpapier voor die in één maat één kleur en één formaat wordt verkocht. Het heeft zijn eigen productrecord omdat er geen keuzes zijn die veranderen wat het artikel is. Een productmaster werkt anders. Het is het hoofdrecord voor een hele productfamilie. Het bevat de gedeelde details en de regels voor de keuzes die afzonderlijke artikelen creëren. Zo werkt het. De productmaster voor spijkerbroeken bevat de naam, basisomschrijving en algemene informatie voor elke broek in die reeks. Vervolgens identificeren individuele varianten de exacte broek die iemand koopt, opslaat, produceert of verzendt. Een variant is het specifieke verkoopbare artikel. Voor spijkerbroeken kan blauw en medium één variant zijn. Zwart en large kan een andere zijn.

Ze behoren tot dezelfde productfamilie, maar ze zijn niet uitwisselbaar. De één kan in het magazijn liggen terwijl de ander is uitverkocht. De één kan een ander label gebruiken. De één kan een eigen barcode hebben. Die ouder- en kindstructuur is het kernidee. Het productmaster bestand definieert de familie. Productvarianten zijn de individuele leden. In plaats van steeds dezelfde basisgegevens in te voeren, start u met het master bestand en maakt u de werkelijke combinaties die uw bedrijf nodig heeft. Laat ik u een concreet voorbeeld geven. Stel je voor dat een reeks jeans verkrijgbaar is in blauw, zwart en bruin. Het is ook verkrijgbaar in de maten extra small, small, medium, large, extra large en double extra large. Als elke kleur in elke maat beschikbaar was, zou je 18 combinaties hebben. Maar bedrijven verkopen zelden elke mogelijke combinatie. Misschien is blauw alleen verkrijgbaar in extra small tot en met medium.

Zwart is verkrijgbaar in medium tot en met extra large. Bruin begint bij large. Dynamics 365 kan elke toegestane combinatie als een eigen variant behandelen. Wanneer iemand een spijkerbroek aan een bestelling toevoegt, kiest diegene de dimensies die het exacte product identificeren. Kleur en maat vertellen het systeem welke variant de klant wil. Geen gegok meer welk paar in de doos moet. Die keuzes worden productdimensies genoemd. Dynamics 365. Supply Chain Management bevat er 5. Namelijk kleur, maat, stijl, configuratie en versie. Een bedrijf kiest de dimensies die bij een productfamilie passen en groepeert ze vervolgens voor dat productmaster bestand. Laten we ze snel doornemen. Kleur is eenvoudig. Blauw, zwart, bruin, rood. Maat is ook bekend. Small, medium, large of een schoenmaat. Stijl kan producten scheiden die dezelfde naam delen, maar er anders uitzien. Een overhemd kan verkrijgbaar zijn in regeler fit en slim fit.

Een stoel kan een standaard frame of een andere afwerking hebben. Configuratie beschrijft een gekozen opbouw of opzet. Bijvoorbeeld, een machine heeft mogelijk een specifieke motor, spanning of set onderdelen nodig. De configuratiedimensie identificeert die keuze. Versie houdt wijzigingen aan een product in de loop van de tijd bij. Dit is vooral belangrijk voor fabrikanten. Stelt u zich een onderdeel voor dat hetzelfde doel dient, maar verandert na een goedgekeurde technische update. Met Versie kan het bedrijf versie 1 onderscheiden van versie 2 terwijl deze door de toeleveringsketen beweegt. Niet elk productmaster bestand heeft alle vijfde dimensies nodig. Een t-shirt heeft wellicht alleen kleur en maat nodig. Een apparaat heeft wellicht configuratie en versie nodig. De dimensie groep fungeert als een regelblad voor de productfamilie. Het vertelt Dynamics 365 welke keuzes van toepassing zijn bij het creëren en identificeren van varianten.

Die beslissing vormt het product vanaf het begin. U vraagt zich misschien af hoe het zit met gewicht, hoogte, lengte, breedte of volume. Die details beschrijven een fysiek product, maar ze creëren geen variantie. Een spijkerbroek kan een bepaald gewicht of verpakkingsformaat hebben dat het niet in een ander artikel verandert zoals kleur of maat dat wel doet. Fysieke afmetingen beschrijven het product. Productdimensies identificeren een specifieke variant. Het gescheiden houden van die twee ideeën voorkomt later verwarring. Als het magazijn moet weten hoeveel ruimte een doos inneemt, helpen fysieke afmetingen. Als een bestelling zwarte jeans in grote productdimensies vereist, vindt dan de juiste variant. Er is één vroege keuze die alles daarna beïnvloedt. Hoe zal het bedrijf die productvarianten aanmaken en beheren? En dat is precies wat we hierna behandelen. Producten configureren zonder chaos te creëren.

Het kiezen van dimensies vertelt Dynamics 365 hoe een variant te identificeren. Maar het bedrijf moet nog steeds beslissen hoe die varianten worden aangemaakt. Die keuze hangt af van het product. Supply Chain Management ondersteunt driehoofdbenaderingen. Vooraf gedefinieerde varianten, dimensie gebaseerde configuratie en configuratie op basis van beperkingen. De namen klinken technisch, dus laat ik ze in begrijpelijke taal uitleggen. Vooraf gedefinieerde varianten passen bij producten met een bekende, beperkte set combinaties. Stel je die retailer voor die de zojuist besproken jeanscollectie verkoopt. Het bedrijf weet al welke kleuren en maten het zal inkopen, op voorraad houden en verkopen. Blauw komt in extra small, small en medium. Zwart komt in medium, large en extra large. Bruin komt in large, extra large en double extra large. Die negen keuzes kunnen vooraf als afzonderlijke varianten worden aangemaakt.

Het bedrijf heeft niet elke mogelijke combinatie van kleur en maat nodig. Het maakt alleen de combinaties aan die daadwerkelijk bestaan. Dat houdt de catalogus overzichtelijk en voorkomt dat iemand bruine jeans in extra small bestelt terwijl niemand dat item maakt. Vooraf gedefinieerde varianten werken goed wanneer het assortiment voorspelbaar blijft. Een kledingbedrijf, een distributeur met vaste verpakkingsgroottes, een bedrijf dat standaard meubelkleuren verkoopt. Ze kunnen allemaal de items voorbereiden die ze verwachten te verwerken. Elke variant bestaat als een bekend item voordat er een bestelling binnenkomt, zodat inkoop, magazijn, teams en verkoopmedewerkers met duidelijke productkeuzes kunnen werken. De volgende benadering is dimensiegebaseerde configuratie. Deze zie je vaak in de productie. Stel je een bedrijf voordat industriële pompen bouwt. Een pompmodel kan veel dezelfde onderdelen gebruiken, maar de klant kan een bepaalde configuratie kiezen.

Die keuze beïnvloedt welke onderdelen in de voltooide pomp thuishoren. Dynamics 365 kan de configuratiedimensie gebruiken om dat te sturen. Het product gebruikt één gedeelde stuklijst, oh, vaak een pom, genoemd. Een stuklijst is simpelweg de onderdelenlijst voor het bouwen van iets. Binnen die ene lijst zijn sommige onderdelen alleen van toepassing wanneer de klant een specifieke configuratie kiest. Bijvoorbeeld, een pomp gebouwd voor één voltage heeft mogelijk één motor nodig. Een ander voltage vereist een andere motor. In plaats van een aparte onderdelenlijst voor elke mogelijke pomp bij te houden, houdt het bedrijf één gedeelde lijst aan. Het markeert welke regels bij welke configuratie horen. Wanneer de gekozen configuratie de planning of productie bereikt, gebruikt Dynamics 365 alleen de onderdelen die bij die keuze passen. Dat bespaart veel dubbel instelwerk. Het geeft fabrikanten ook een duidelijkere manier om een productfamilie te beheren die qua constructie grotendeels hetzelfde is, maar op gecontroleerde wijze verschilt.

De dimensies identificeren het gekozen product. De stuklijst bepaalt welke onderdelen bij die opbouw horen. Dan is er nog de op beperkingen gebaseerde configuratie. Deze aanpak is geschikt voor producten waarbij klanten uit veel opties kunnen kiezen. Maar niet elke optie werkt met elke andere optie samen. Denk aan een machine op maat, laboratoriumapparatuur of een product dat uit vele onderdelen is samengesteld. Een klant kan het type stroomvoorziening, de behuizing, de motor, de veiligheidsoptie en het bedieningspaneel kiezen. Sommige combinaties werken, andere werken simpelweg niet. Een bepaalde behuizing past wellicht niet bij een grotere motor. Een voltage vereist mogelijk een specifiek bedieningspaneel. Een veiligheidskap werkt misschien alleen bij één machineformaat. Zonder regels kan een verkoper een combinatie selecteren die de fabriek niet kan bouwen. Op beperkingen gebaseerde configuratie zet die regels in een productconfiguratie model.

Het model beschrijft de mogelijke keuzes en de regels die deze beperken. Wanneer iemand het product configureert, leidt het systeem hen naar geldige opties. Het voorkomt keuzes die met elkaar in conflict zijn. Dat stopt een onmogelijke bestelling nog voordat deze de productie bereikt. Ik wil hier even bij stilstaan, want dit is een vroege ontwerpbeslissing. Een bedrijf moet de configuratie technologie kiezen die bij zijn bedrijfsproces past voordat de productfamilie wordt opgebouwd. Dynamics 365 zet een product achteraf niet zomaar om van het ene configuratie model naar het andere. Een retailer die een vast assortiment verkoopt, moet dus geen ingewikkeld aangepast productmodel opzetten alleen omdat het flexibel klinkt. En een fabrikant die apparatuur op bestelling maakt, moet niet elke mogelijke opbouw in een lange lijst van vooraf gedefinieerde varianten dwingen als de keuzes afhankelijk zijn van regels.

Begin bij het echte inkoop, verkoop en productieproces. Stel een simpele vraag. Kennen we elke productcombinatie voordat de bestelling binnenkomt? Of creëert de klant de productkeuze via een set toegestaane opties? Het antwoord wijst het bedrijf in de richting van de juiste aanpak. Zodra het bedrijf weet wat een product kan zijn, heeft het een manier nodig om dit duidelijk te beschrijven en die informatie georganiseerd te houden. Categorieën, kenmerken en beheer van productinformatie. Een productnaam vertelt je hoe iets heet, maar dat helpt je niet om het in te kopen, op te slaan, te verkopen of aan een klant uit te leggen. Dat is waar categorieën in beeld komen. Denk bij categorieën aan de gangpaden in een goed georganiseerde winkel. Een bedrijf kan producten groeperen op basis van wat ze zijn. Ook kleding in het ene gangpad, gereedschap in het andere, kantoorbenodigdheden in een derde.

Of ze groeperen ze op basis van het soort werk dat mensen moeten doen. Hoe dan ook, het doel is hetzelfde. Producten makkelijker vindbaar en beheerbaar maken. Neem een accuboormachine. Een verkoopteam moet deze kunnen vinden onder elektrisch gereedschap. Een productteam plaatst deze wellicht in een categorie voor apparatuur op batterijen. En dit is het punt. Een product kan tegelijkertijd in meerdere categorieën staan als die categorieën verschillende bedrijfsbehoeften dienen. Het is niet de bedoeling om elk product in één perfecte map te dwingen. Categorieën bieden het bedrijf een gestructureerde manier om productinformatie te ordenen, producten te zoeken en met groepen verwante artikelen te werken. Ze helpen mensen ook om de juiste informatie toe te passen op producten die bij elkaar horen. Nu doen categorieën veel, maar ze kunnen niet elk detail bevatten. Dat is waar kenmerken van pas komen.

Voor een waterfles kunnen kenmerken zijn materiaal, inhoud, type deksel, isolatie, merk- en onderhoudsinstructies. Voor een machine onderdeel kunnen dat afmetingen, stroomverrijsten, temperatuurbereik of een technische standaard zijn. Kenmerken veranderen een algemeen label in nuttige productinformatie. Precies het soort informatie dat u echt nodig heeft voor uw werk. Categorieën kunnen kenmerken bevatten die logisch zijn voor de producten die erin zitten. Kleding heeft stof, pasvorm en wasvoorschriften nodig. Elektronische apparatuur heeft voltage, garantiedetails en compatibiliteitsinformatie nodig. Dat betekent dat niemand willekeurige velden hoeft te bedenken voor elk productrecord. Ze gebruiken gewoon de details die bij de productgroep passen. Afbeeldingen en bijlagen voegen een extra laag toe. Een foto helpt een magazijnmedewerker, verkoper of klant om het item te zien waar ze over praten.

Een bijlage kan ondersteunend materiaal bevatten, zoals een leveranciersdocument, een specificatieblad of ander papierwerk. Soms is de geschreven naam alleen niet genoeg. Vertalingen zijn belangrijk wanneer het bedrijf in verschillende talen werkt. Productnamen en beschrijvingen kunnen worden vertaald, zodat mensen in verschillende markten informatie krijgen die voor hen begrijpelijk is. Het product blijft hetzelfde, maar de bewoordingen kunnen worden aangepast aan het publiek. Een bedrijf heeft ook controle nodig over wie deze informatie mag wijzigen. Niet elke medewerker moet elk productrecord kunnen bewerken, een item kunnen hernoemen of details kunnen veranderen waar andere teams van afhankelijk zijn. Met Dynamics 365 kunt u toegangsregels voor productgegevens toepassen op categorie-niveau of voor een individueel product. Het team dat verantwoordelijk is voor industriële apparatuur werkt bijvoorbeeld met die categorie, terwijl een andere groep consumentenproducten beheert.

Een beperkt product heeft wellicht striktere controle nodig dan gewone kantoorbenodigdheden. Het bedrijf bepaalt wie met elk onderdeel van zijn productgegevens kan werken. Dat beschermt de informatie waarop mensen vertrouwen. Het dossier kan nu de juiste details, documenten, categorieën en controles bevatten. Maar er is nog steeds goedkeuring nodig voordat de onderdelen van het bedrijf die het inkopen, verkopen, opslaan of produceren het daadwerkelijk kunnen gebruiken. Producten vrijgeven aan rechtspersonen. Een voltooide productdefinitie is nu klaar, automatisch klaar voor iedereen om te gebruiken. Oh, nog niet. Een bedrijf opereert vaak via verschillende rechtspersonen, die afzonderlijke bedrijven zijn binnen de grotere onderneming. De ene entiteit kan een product in Duitsland kopen en op voorraad houden. Een andere verkoopt hetzelfde product in de Verenigde Staten. Een derde produceert het.

Ze kunnen allemaal beginnen met dezelfde gedeelde productdefinitie. In Dynamics 365 wordt die gedeelde definitie een vrijgegeven product zodra het bedrijf het goedkeurt voor gebruik door een specifieke rechtspersoon. Zie vrijgaven als het geven van toestemming aan die bedrijfseenheid om het product in haar eigen dagelijkse werkzaamheden op te nemen. Het product verandert niet van identiteit. De algemene naam, beschrijving, categorie, afmetingen en andere gedeelde details blijven verbonden met de centrale definitie, maar elke rechtspersoon kan de instellingen toevoegen die nodig zijn voordat het product wordt besteld, verkocht, opgeslagen of geproduceerd. Het ene bedrijf koopt het product mogelijk in bij een leverancier. Een ander verkoopt het wellicht alleen. Een productiebedrijf heeft productieinstellingen nodig, terwijl een distributiebedrijf magazijn en voorraadinstellingen nodig heeft.

Verkoopdetails verschillen per entiteit. Lokale bedrijfsregels verschillen ook. Vrijgaven stelt elke rechtspersoon in staat het product voor te bereiden op het eigen werk zonder een volledig aparte productdefinitie aan te maken. Stel je een bedrijf voor dat dezelfde waterfles in verschillende landen verkoopt. Het productteam creëert één centrale productdefinitie. Vervolgens geeft het bedrijf het vrij aan de rechtspersoon in het Verenigd Koninkrijk. En die entiteit voegt de instellingen toe die nodig zijn om de fles in te kopen en op te slaan. Later wordt hetzelfde product vrijgegeven aan de Canadese rechtspersoon, waar mensen de instellingen voor lokale verkoop en voorraad voltooien. Beide bedrijven gebruiken hetzelfde product. Ze hoeven niet opnieuw te beginnen met de naam, beschrijving en details van de productfamilie. Ze vullen alleen de informatie aan die bij hun eigen entiteit hoort.

De scheiding houdt gedeelde feiten en lokaal bedrijfswerk op de juiste plek. Een gedeelde productdefinitie beantwoordt de vraag, wat is dit product? Een vrijgegeven product beantwoordt. Hoe zal dit specifieke bedrijf het gebruiken? Het is een klein verschil in bewoording, maar het voorkomt veel dubbelwerk wanneer een bedrijf actief is via meerdere rechtspersonen. Dynamics 365 kan producten tegelijkertijd aan één of meerdere rechtspersonen vrijgeven. Dat helpt wanneer een bedrijf een standaard assortiment introduceert bij vele bedrijfseenheden. Toch is vrijgaven nu niet langer een kwestie van één klik en vergeten. Elke rechtspersoon heeft mogelijk extra details nodig voordat teams veilig met het product kunnen werken. De werkruimte onderhoud vrijgegeven producten helpt mensen dit proces te bewaken. Het toont recent vrijgegeven producten en controleert of de vereiste instellingen voor die rechtspersoon volledig zijn.

Als er nog productenmerken, categorieën, instellingen voor orders of vertalingen moeten worden toegevoegd, biedt de werkruimte een plek om dat werk te vinden en de relevante productpagina's te openen. Het helpt teams ook om onvoltooide productwijzigingsaanvragen te identificeren. Dat is belangrijk omdat een product er vanuit het centrale overzicht klaaruit kan zien terwijl lokale instellingen onvolledig zijn. De werkruimte biedt de rechtspersoon een praktische lijst met producten die aandacht vereisen, in plaats van mensen door lange lijsten te laten zoeken. Vrijgaven kopieert een product dus niet naar een afzonderlijke wereld. Het koppelt één goedgekeurde productdefinitie aan een rechtspersoon en geeft die entiteit de ruimte om eigen operationele details toe te passen. Zodra dat gebeurt, kan de productinformatie worden gebruikt voor werkzaamheden rondom orders, voorraad en klantbehoeften.

Dus hoe PIM het werk rondom een product verbindt. Hoe verbindt productinformatiebeheer het werk rondom een product nu eigenlijk? Hier is de eenvoudigste definitie. PIM voert niet elk bedrijfsproces zelf uit. In plaats daarvan levert het de productinformatie die deze processen nodig hebben. Zie het als een centrale archiefkast voor productgegevens. Een inkoper moet het juiste artikel op een inkooporder vinden. Het magazijnteam heeft het juiste artikel nodig bij het ontvangen of verzamelen van voorraad. Het verkoopteam heeft de productdetails nodig die op een offerte of order thuishoren. En andere Dynamics 365 apps hebben mogelijk ook productgegevens nodig. PIM biedt al die teams één gemeenschappelijk uitgangspunt, een enkele bron van waarheid. Waar komen die productgegevens nu vandaan? Productdefinities kunnen beginnen in Dynamics 365 Supply Chain Management. Dat werkt goed wanneer het bedrijf productinformatie vanaf het begin daar beheert.

Maar veel bedrijven gebruiken al een ander systeem voor productontwikkeling of productgegevens. Productgegevens kunnen bijvoorbeeld afkomstig zijn uit een productlevencyclusbeheersysteem, vaak PLM genoemd. Een PLM-systeem helpt teams bij het beheer van een product tijdens het ontwerp en de ontwikkeling. Er is ook productdatabeleer of PDM dat productgegevens en gerelateerde documenten verwerkt. Sommige bedrijven gebruiken zelfs een afzonderlijk PIM-systeem voordat productinformatie in Supply Chain Management wordt ingevoerd. Dit is het goede nieuws. Dynamics 365 kan productdefinities uit die systemen importeren. Dat betekent dat u niet dezelfde productdetails opnieuw hoeft in te voeren alleen omdat het product van ontwerp naar de Supply Chain fase gaat. Supply Chain Management kan ook de plek worden die de stamgegevens van producten voor andere instanties bevat. Dit is van belang in grotere bedrijven met meer dan één instantie.

Eén instantie beheert de centrale productdefinities en exporteert en importeert die gegevens naar de andere. Microsoft biedt dataentiteiten voor dit type uitwisseling, gestructureerde manieren om gedefinieerde data tussen systemen te verplaatsen. Maar er is meer. Microsoft Dataverse breidt dat distributiepad uit. Dataverse is Microsoft's gedeelde cloud data service die door veel bedrijfsapplicaties wordt gebruikt. Supply Chain Management kan productdefinities exporteren naar Dataverse, zodat andere bedrijfsapplicaties zoals Dynamics 365 sales die productdata kunnen gebruiken. Dat betekent nu niet dat elke app plotseling hetzelfde werk doet. PIM organiseert en onderhoudt productinformatie. Dynamics 365 sales handelt verkoopwerkzaamheden af. Andere apps handelen hun eigen klantenservice, commerce, financiën, productie of operationele taken af. Ze kunnen gerelateerde productdata gebruiken, maar elke app behoudt zijn eigen doel.

Laten we eens kijken naar een praktisch proces. Het productteam maakt of importeert een nieuwe productdefinitie. Het bedrijf geeft deze vrij aan de juridische entiteiten die deze nodig hebben. Die entiteiten voltooien hun lokale instellingen. Inkoop kan werken met het goedgekeurde artikel. Magazijnmedewerkers kunnen het ontvangen en verwerken. Verkoop kan verwijzen naar het juiste product in plaats van zelf een versie te bedenken. Het resultaat is zichtbaar op alledaagse momenten. Een koper bestelt het juiste artikel. Een klant ziet de juiste details. Een magazijnmedewerker kan een order matchen met de voorraad die voor hen ligt. Wanneer productinformatie wijzigt, hebben teams een duidelijker pad om de actuele, goedgekeurde details te gebruiken in plaats van oude kopieën na te jagen. Dit vermindert bestelfouten, verouderde informatie en retourzendingen door incorrecte productdetails. Productinformatiebeheer is het onderdeel dat de productdefinitie georganiseerd houdt, terwijl de rest van het verbonden platform die informatie inzet.

Conclusie Een gedeeld productverhaal in Dynamics 365 productinformatiebeheer verandert een productidee in één beheertrecord dat juridische entiteiten en bedrijfsteams kunnen gebruiken in hun eigen werk. Dat is jouw kennis nugget voor vandaag. Abonneer je op je favoriete podcastplatform en deel dit met iemand die Dynamics 365 leert. Ga dan door naar de volgende aflevering om te zien hoe alle bouwstenen met elkaar verbonden zijn in de