DANGA: Diehard consultants Are Not Globally Available

Simulatie van het verloop van een verkooporderproces met Mida - Camunda

Een paar dagen geleden liep ik tegen het project MIDA van de University of Camerino aan.

MIDA (Multiple Instances and Data Animator) is het resultaat van een onderzoeksproject van de School of Science and Technology, Computer Science Division.

MIDA is een simulator die door middel van tokens laat zien hoe een proces doorlopen wordt. Onderstaande video laat als voorbeeld de simulatie van het ordering proces tussen een groothandel en leverancier zien. Dit proces wordt later in het artikel verder uit de doeken gedaan.

MIDA is een uitbreiding van de Camunda Modeler (bpmn.io) Token Simulation plugin.

MIDA kan zonder problemen geïnstalleerd worden. Ga naar de website http://pros.unicam.it/mida/ en selecteer download. Unzip het bestand en start dan de executable Mida.exe.

Simulatie ordering proces wholesaler - supplier

De Token Simulation plugin visualiseert de voortgang van activiteiten in een BPMN collaboration diagram door middel van tokens die zich voortbewegen in het procesmodel. De verwerking van gegevens en het uitwisselen van berichten worden niet ondersteund door de plugin zoals gezien kan worden in onderstaande simulatie van een procesmodel.

In dit procesmodel worden berichten uitgewisseld tussen een groothandel (lane: wholesaler) en een leverancier - fabrikant (lane: supplier).

[Note: lane wholesaler = bovenste swimlane, lane supplier = onderste swimlane]

MIDA, daarentegen, maakt het wel mogelijk om de gegevensstromen tussen deelnemers (swimlanes) aan het proces zichtbaar te maken en te laten zien wanneer nieuwe proces-instanties worden gestart.

[Note: een procesmodel is een beschrijving van / een blueprint van een proces, een procesinstantie (process instance) is de concrete uitvoering van een model. Op hetzelfde moment kunnen meerdere instanties van een proces actief zijn.]

Het zijn de gegevens in berichten tussen deelnemers die het gedrag van het proces beïnvloeden. De gegevens worden opgeslagen in data objecten die mede bepalen welke stappen daarna worden uitgevoerd.

In het bovenstaande procesmodel geeft de taak "Send purchase order" aan dat er een bericht (een inkooporder) van de groothandel naar de leverancier wordt gestuurd. Het bericht bevat onder andere volgende gegevens: ordernummer (PO_number), regelnummer (POLine_itemNumber), verzoek tot het ontvangen van een orderbevestiging (PO_confirmation), de identificatiecode van de inkopende organisatie - GTIN / EAN of UPC code (PO_buyerID). Deze gegevens worden overgedragen aan het data object "purchase order" en zijn input voor de taak "Validate order".

et veld PO_confirmation beantwoordt later de vraag die gesteld wordt door de exclusive gateway "Confirm order ?".

MIDA verplicht je om uitgebreider na te gaan denken over hoe informatie wordt overgedragen in het samenspel tussen verschillende participanten, hoe participanten samenwerken en hoe gegevens doorheen het model stromen. Wanneer de initialisatie van gegevensvelden en de overdracht van deze gegevens aan taken niet goed zijn gedefinieerd leidt simulatie van het model tot errors.

MIDA simulatie ordering proces wholesaler - supplier.

Wanneer de processimulatie start zien we in het logging-overzicht links onder dat er 1 instantie van het proces is gestart. Dit is het proces in de bovenste swimlane - het proces van de groothandel.

Create purchase order

Het proces in de bovenste swimlane start met een vraag of wens vanuit de organisatie voor een product, materiaal of grondstof. Deze behoefte leidt tot de creatie van een inkooporder.

Rechtsboven onder de drop down Data Panel zijn de gegevens zichtbaar van de behoefte en de inkooporder.

Send purchase order

Wanneer de purchase order wordt verstuurd worden de gegevens via het gele informatie-token met nummer 1 doorgezet naar de message start event in het proces van de supplier.

Gelijktijdig wordt het token doorgestuurd naar de event based gateway waar het zal wachten op een antwoord vanuit het proces van de leverancier. Bij aankomst van het eerste token bij de event based gateway krijgt het token een rode kleur. Deze kleur zal het token houden tot de melding komt of de order geaccepteerd is of niet.

Receive purchase order

Bij ontvangst van de purchase order in de swimlane van de leverancier start een tweede procesinstantie, het proces van de leverancier.

Validate order

Na validatie van de order in de onderste flow heeft de variabele orderAccepted de waarde True gekregen en gaat het tweede token naar de taak "Enter order".

Enter order

Tijdens de uitvoering van de taak "Enter order" wordt een verkooporder aangemaakt in het ERP-systeem van de leverancier.

Send acceptance

Nadat de order is vastgelegd in het ERP-systeem van de leverancier wordt de acceptatie van de order gemeld aan de groothandel via het gele informatie-token met nummer 2.

Het tweede token in de onderste flow vervolgt zijn weg naar het kruispunt - de exclusive gateway "Confirm order ?". Het antwoord op deze vraag is meegestuurd met de gegevens van de inkooporder in het veld PO_confirmation en opgeslagen in het veld SO_confirmation van de verkooporder in het ERP-systeem van de leverancier.

Gateway Wait for confirmation

Het eerste token in de bovenste flow verandert van kleur na het ontvangen van de melding dat de order is geaccepteerd. Daarna gaat het token verder naar het kruispunt - de exclusive gateway "Wait for confirmation ?". Het antwoord op deze vraag is opgeslagen in het veld PO_confirmation van de inkooporder.

Het tweede token in de onderste flow vervolgt zijn weg naar het kruispunt - de exclusive gateway "Confirm order ?". Het antwoord op deze vraag is meegestuurd met de gegevens van de inkooporder in het veld PO_confirmation en opgeslagen in het veld SO_confirmation van de verkooporder in het ERP-systeem van de leverancier.

Send confirmation

Wanneer de groothandel om bevestiging van levertijd (PO_confirmation = true) vraagt gaat het tweede token naar de taak "Confirm order". Deze taak verstuurt de orderbevestiging naar de groothandel via het informatie-token nummer 2.

Receive confirmation

Op het moment dat de order confirmation wordt ontvangen in de bovenste flow licht de taak "Receive confirmation" groen op en vervolgt het eerste token zijn weg naar de taak "Receive delivery".

In de onderste flow gaat het tweede token verder naar de taak "Create shipment".

Create shipment

Ship order

De taak "Ship order" zorgt dat de goederen fysiek worden verstuurd en informeert de groothandel via het gele informatie-token met nummer 2 over de inhoud van de levering.

In de bovenste flow kleurt het eerste token rood omdat het proces wacht op de ontvangst van de levering.

Receive delivery

Na ontvangst van het gele informatie-token met de informatie over de levering licht de taak "Receive delivery" groen op en vervolgt het eerste token zijn weg naar de taak "Receive invoice".

Ondertussen is in de onderste flow de taak "Create invoice" uitgevoerd en zal ik de volgende stap de factuur verzonden worden naar de groothandel.

Send invoice

Ook hier kleurt het eerste token rood omdat het proces wacht op de ontvangst van de factuur.

Receive invoice

Wanneer het gele informatie-token met de factuur is verwerkt door de taak "Receive invoice" licht deze processtap groen op en eindigt het onderste proces zoals linksonder te lezen valt.

Einde proces

Aan het einde van het proces zien we rechts dat beide instanties 1 en 2 beëindigd zijn.

Data panel

Tijdens de simulatie geeft het data panel een overzicht van de gegevens die worden uitgewisseld.

Simulation log

De simulation log geeft een overzicht van de stappen en de tijdstippen waarop deze doorlopen zijn.

Tags: BPMN, O2C

Continue!

High level verkoopproces in BPMN en Archimate

Een probleemloze ERP implementatie vraagt om inzicht in meer dan de (huidige - oude) processen en informatiestromen.

Het bestaande informatie- en applicatielandschap heeft een grote invloed op de haalbaarheid van ERP - misschien is het nodig om één ander te rationaliseren.

Ik raad bedrijven aan om toekomstige processen "ERP - applicatie neutraal" te beschrijven. Hierbij verplicht je gebruikers om na te denken over wat ze echt nodig hebben.

Zelf gebruik ik hiervoor een scala aan modelleertools en -talen - alle modellen binnen BPMN, Archimate, DMN. Dagelijks merk ik weerstand voor deze aanpak maar deze verdwijnt vrij snel wanneer de organisatie betrokken wordt in het beschrijven.

Learning-by-doing: leg samen interne processen en afhankelijkheden met applicaties vast

Welk tool (Signavio, Bizagi, Cawemo, Camunda, ...) gebruiken of welke taal (BPMN, Archimate) is niet echt relevant.

Ultimo gaat het om het proces van bewustwording aan de kant van de gebruiker.

Archimate of BPMN, voor high-level procesbeschrijvingen kan beiden zoals je hierna kunt zien: BPMN

BPMN

Archimate

Tags: BPMN, Archimate

Continue!

Gaan een taakstellend budget en een Agile implementatiemethodiek wel samen ?

Steeds vaker stellen implementatiepartners van bedrijfsinformatiesystemen (ERP, CRM, PLM, ...) hun klanten voor om te werken met een taakstellend budget welke gecombineerd wordt met een Agile implementatiemethodiek. De gewenste resultaten worden ondergeschikt gemaakt aan het budget. Het is in de optiek van de leverancier immers onmogelijk om deze resultaten vooraf te bepalen. Bovendien komen gaandeweg het project de teams van leverancier en klant tot andere inzichten. De leverancier gaat de omgeving van de klant beter begrijpen en de klant gaat de mogelijkheden van de oplossing doorzien.

Het mag echter duidelijk zijn dat een aanpak waarbij "Less Thinking & Designing Upfront" minder garanties biedt dat de wensen en eisen van de klant gerealiseerd gaan worden. Nog minder aandacht / ruimte is er voor het realiseren van de 'gain points' - de winstpunten - en het elimineren van de 'pain points' - pijnpunten - van de klant.

En laten we realistisch zijn, het zijn deze beloftes die gebruikers over de streep trekken om een bijdrage te leveren. Ja, we gaan participeren als we er ook wat voor terug krijgen.

Hoe haaks staat het idee van een taakstellend budget op deze aanpak?

Laten we beginnen met "wat is een taakstellend budget ?" De term wordt makkelijk in de mond genomen maar als we zoeken op Google zijn er weinig definities te vinden. Uit de zoekresultaten heb ik volgende definities geselecteerd:

1) Taakstellend budgetteren is een methode waarbij het budget wordt afgestemd op de te bereiken resultaten.

2) Taakstellend budgetteren gaat uit van het realiseren van vooraf afgesproken resultaten en het aanvaarden van de consequenties van het niet realiseren van deze resultaten.

3) Een taakstellend budget is een budget voor het realiseren van de van-tevoren afgesproken resultaten.

Uit al deze definities kunnen we een paar belangrijke zaken afleiden: allereerst de gewenste resultaten zijn vooraf in kaart gebracht en vastgesteld, het budget is afgestemd op deze resultaten en het kan zijn dat sommige resultaten niet gerealiseerd worden.

Nu weten we dat in een zuivere Agile benadering de resultaten van iteraties voorafgaande niet bekend zijn en dat de hoeveelheid werk die verzet kan worden beperkt wordt door het beschikbare budget.

Is een taakstellend budget met een Agile implementatiemethodiek niet een aanpak om te verdoezelen dat gebruikers (gebruikersorganisatie) niet gaan krijgen wat ze willen ? Er is immers een veel groter budget nodig om aan al de wensen en eisen van de klant te voldoen, om zoals dat zo mooi heet "de stip op de horizon" te realiseren.

De ervaring leert dat het merendeel van de implementatieprojecten die een zuivere Agile aanpak volgen leiden tot budget en scope discussies, tot ontevreden gebruikers, tot halfbakken oplossingen, en tot oplevering van minder functionaliteiten dan voorheen beschikbaar waren.

De oplossing ligt in een hybride aanpak bestaande uit een traditionele Business blue print fase, een Agile realisatiefase en een traditionele deployment - go-live fase.

Tijdens de Business blue print fase wordt de bestaande en toekomstige situatie geïdentificeerd, de gewenste resultaten beschreven / gemodelleerd en geprioritiseerd, en het benodigde budget daarop afgestemd.

Tijdens de Agile realisatiefase wordt de technische en functionele invulling van de gewenste resultaten door een multi-functioneel team vorm gegeven, de baseline gedefinieerd en in iteraties de gain- en pain-points weggewerkt. Voortschrijdend inzicht van leverancier en klant zorgt dat met minder kosten meer resultaten kunnen worden gerealiseerd.

Deze hybride aanpak voorkomt - mijns inziens op basis van actuele ervaring - dat het project een speelbal wordt van scope- en budgetdiscussies.

Tags: ERP, PLM, agility

de Auteur

Mijn aandachtsgebieden zijn: de uitdagingen waar bedrijven / managers en directeuren voor staan, het bieden van hulp bij de zoektocht naar antwoorden op deze uitdagingen, de technologische ontwikkelingen die de verhoudingen op zijn kop gaan zetten in de komende maanden / jaren, het begeleiden van adviestrajecten van concept tot realisatie.

Mijn passie ligt bij het integreren en innoveren van bedrijfsprocessen, informatiestromen, systemen en organisaties zodat medewerkers en bedrijven zich volledig kunnen richten op hun kerntaken en bedrijven hun ambities kunnen waarmaken onder het motto "Giving control back to Business".

Ik heb 30 jaar ervaring in de Maakindustrie, Bouw- en Installatiebranche bij internationale bedrijven op het gebied van proces-, project- en implementatiemanagement, ketenintegratie, ERP selectie en implementatie, stroomlijnen en implementatie van O2C en P2P processen.

Continue!

Ketenintegratie: hoe gegevens stromen doorheen een ecosysteem ?

Wanneer ik u vraag “Waar gaat ketenintegratie over ?” dan roept u “koppelen van interne en externe informatiesystemen”, “beheersen van goederen- en informatiestromen”, “verkorten van doorlooptijden”, en “delen van informatie”.

Ketenintegratie - voor mij - gaat over het leggen van een “breed fundament voor samenwerking”, over het-huis-op-orde-brengen (processen, informatiestromen, organisatiestructuur en -cultuur, systemen), zodat bedrijven klaar zijn voor co-creatie en co-productie.

In traditionele voortbrengingsketens ligt de nadruk bij ketenintegratie op het automatiseren van informatiestromen tussen klanten, leveranciers en logistieke dienstverleners. We hebben het over Wie, Wat, Waar, Wanneer, Hoe, Hoeveel en tegen Welke prijs.

Met Industrie 4.0 gaan fysieke systemen – slimme machines, apparaten en componenten – deelnemen aan de keten en krijgen bedrijven toegang tot enorme volumes aan data. De complexiteit van transacties neemt door al de data-context die beschikbaar komt exponentieel toe. Omgevingsvariabelen: temperatuur, luchtvochtigheid en frequentie van gebruik alsook onderhoudsgegevens en condities van producten – kortom alle gegevens over de levensduur van producten.

Niet alleen slimme schakels maar ook Digital Twin’s, de virtuele (digitale) replica’s van fysieke systemen, drukken een stempel op ketenprocessen. Het speelveld breidt gigantisch uit met autonome systemen waarvan de identiteit niet altijd eenduidig vaststaat.

  • Wie is de eigenaar van die drankenautomaat die om onderhoud vraagt ?
  • Wat wil die zelf-rijdende auto die met pech langs de kant staat ?
  • Wat moeten we met die robots die op zoek zijn naar meer werk ?
  • We kunnen ons nog niet voorstellen hoe complex de wereld van (keten)integratie er straks uit gaat zien ? Maar één ding is zeker de Smart Industrie / Industrie 4.0 kan niet zonder (keten)integratie, kan niet zonder een “breed fundament voor samenwerking”.

    de vraag dringt zich op waar staan we met zijn allen ?

    Al een aantal decennia vormen MRP en ERP oplossingen de ruggengraat van bedrijven ongeacht de grootte of industrie. Met de komst van MRP I en MRP II, respectievelijk in de jaren ’70 en ’80, en ERP in de jaren ’90 nam de behoefte aan samenwerking en het delen van gegevens tussen bedrijven een enorme vlucht.

    Getuige daarvan zijn de vele EDI standaarden die in de periode van MRP (1970 – 1990) en ERP (1990) zijn ontstaan.

  • Industry global: ANSI X12 (US 1979), EDIFACT (1987)
  • In de Automotive industrie: ODETTE (INT 1984 / 1986), GALIA (Frankrijk 1984), VDA (Duitsland 1978)
  • In de Retail industrie: TRADACOMS (UK 1982 – 1995), EANCOM (INT 1990), SEDAS (Duitsland 1977), EANCOM (INT 1987), VICS (US 1986)
  • In de Steel industrie: AISI COMPORD (US 1980), EDISIDEL (EUR 2000)

    De adoptie van EDI en de invoering van ERP heeft het tijdperk van Supply Chain Integration oftewel ketenintegratie ingeleid. Ketenintegratie richt zich op het optimaliseren van goederen- en informatiestromen tussen schakels in de keten. Ketenintegratie heeft als doel het verkorten van doorlooptijden en het verlagen van transactiekosten in de keten.

    In de beginjaren ging dat vooral over het uitwisselen van inkooporders, orderbevestigingen, leveringen en facturen. De focus lag op integratie van informatiestromen en processen binnen de domeinen Financiën, Verkoop en Logistiek.

    Een aantal ERP oplossingen uit die tijd zoals SAP en MFG/Pro boden functionaliteiten voor ketenintegratie in de vorm EDI interfaces – SAP IDoc interface en MFG/Pro eCommerce interface.

    Documenten werden niet langer meer via email, post of fax verstuurd maar in een afgesproken elektronisch formaat.

    Binnen bedrijven zijn de hierboven genoemde domeinen verder uitgesplitst naar volgende functies:

    Traditioneel houdt ketenintegratie zich niet bezig met wat er binnen de muren van bedrijven gebeurd. Van oudsher zijn de bedrijfsfuncties Manufacturing en Research & Development (Engineering) vooral intern gericht.

    We zien in bedrijven dat deze afdelingen met elkaar communiceren via email of telefoon en dat informatiesystemen die de activiteiten van medewerkers ondersteunen vaak geïsoleerde oplossingen zijn.

    ontwikkelingen in Research & Development

    Met de toegenomen aandacht voor duurzaamheid (3P's) en de belangen van de klant is in Research & Development deze houding in de afgelopen decennia verandert.

    In de Bouw zien we hoe BIM (Building Information Model / Management) flink opmars maakt en er wordt gewerkt aan het vormgeven van Common Data Environments voor het delen van informatie in de keten. Terwijl in de Machine-, Apparatenbouw en High Tech industrie MBD (Model Based Definition) verder ingeburgerd raakt en de eerste stappen naar Model Based Extended Enterprises (E-PLM) worden gezet.

    Deze ontwikkelingen zorgen dat alle belanghebbenden in elke fase van de levensduur over alle relevante gegevens kunnen beschikken en sneller beslissingen kunnen nemen.

    De levenscyclus van een gebouw en machine komt aardig met elkaar overeen: van ontwerp, constructie, beheer & onderhoud tot ontmanteling en hergebruik van materialen. In deze industrieën zijn grote winsten te behalen door verregaande integratie en optimalisatie van processen als informatie. Vooral bij overdracht van ontwerp naar productie en van installatie naar onderhoud & beheer is het belangrijk zorg te dragen voor beschikbaarheid van aanwezige en bekende gegevens.

    Bij veel bedrijven wordt tijdens deze overdrachtsmomenten informatie gewoon over de schutting gegooid met de alom bekende boodschap hier-moet-je-het-maar-mee-doen en bij-vragen-weet-je-ons-wel-te-vinden.

    Het streven is om deze informatie met partners in de buitenwereld en intern te delen via een Platform – Ecosystem georiënteerde benadering.

    In de bouw met BIM heeft men het over de CDE = Common Data Environment = "an online place for collecting, managing and sharing information". De CDE kan gezien worden als de virtuele plek waar alle informatie / modellen beschikbaar komen. Verschillende modellen en informatiebronnen worden samengebracht in een 'Federated BIM Model'.

    In de Machine-, Apparatenbouw en High Tech industrie met MBD heeft men het over:

  • MBE = Model-Based Enterprise = "an integrated and collaborative environment, founded on 3D product definition shared across the enterprise, enabling rapid, seamless, and affordable deployment of products from concept to disposal"
  • MB(E)E = Model-Based Extended Enterprise = "a fully integrated and collaborative Model Based environment across the product development lifecycle and the extended supply chain"
  • Meer over BIM en MBD kunt u lezen in mijn artikel “Wat hebben BIM-CDE en MBD-MBEE (Extended PLM) met elkaar gemeen ?”.

    wat gebeurt er in Manufacturing ?

    Na jaren van verwoede inspanningen om klantorders volledig elektronisch door te sluizen naar de werkvloer verschuift met de komst van nieuwe technologieën de aandacht naar het verkleinen van de afstand tussen klant en fabrikant.

    Aan de ene kant gaan slimme machines en apparaten rechtstreeks met klanten en met elkaar communiceren wat leidt tot kortere doorlooptijden. Aan de andere kant neemt de invloed van de klant op het ontwerp en op de fabricage verder toe met hogere klanttevredenheid als gevolg.

    Met deze veranderingen wordt het steeds belangrijker om de levensduur van een product of dienst van idee tot/met ontmanteling integraal te managen. Product Life Cycle Management gaat de brug moeten slaan tussen de klant-gerichte en de product gerichte keten.

    De beloftes van de nieuwe digitale technologieën die aan de basis staan van Industrie 4.0 zijn levensecht. Zij geven bedrijven de kans om productiviteit, kwaliteit, flexibiliteit, snelheid en veiligheid te verbeteren.

    Maar alhoewel bedrijven al flink wat stappen hebben gezet – veel productiewerkplekken zijn voorzien van beeldschermen en computers in fabrieken zijn ook al geen uitzondering meer – moeten er nog wel muren worden geslecht.

    In tegenstelling tot wat wordt gedacht vormt niet technologie de beperkende factor maar belemmeren organisatiestructuur en bedrijfscultuur de ambities van bedrijven.

    Van nature zijn medewerkers / bedrijven terughoudend in het delen van kennis, hebben managers weinig vertrouwen in samenwerking met partners en willen organisaties niet veranderen.

    Industrie 4.0 vraagt bereidheid om continue te veranderen, om ‘echt’ samen te werken en kennis te delen met alle belanghebbenden, om verbindingen te leggen over grenzen heen, om je bedrijf opnieuw uit te vinden en durven te experimenteren, en om nieuwe competenties en vaardigheden te ontwikkelen.

    Industrie 4.0 vraagt om een open en dynamische bedrijfscultuur.

    Dit stelt veel bedrijven voor behoorlijk wat uitdagingen bij het automatiseren van interne processen en informatiestromen.

    integratie interne bedrijfsprocessen vanaf de jaren '60

    Voor velen onder ons lijkt het alsof op het gebied van gegevensuitwisseling tussen kantoor- en productieomgevingen weinig gestandaardiseerd is. Niets is minder waar.

    De International Society of Automation (ISA), een non-profit organisatie, houdt zich al tientallen jaren bezig met het ontwikkelen van standaarden en leidraden voor integratie van interne processen en informatiestromen in industriële omgevingen.

    De belangrijkste raamwerken voor aansturing van industriële processen zijn vastgelegd in de ISA-95, ISA-88 en ISA-99 standaarden.

  • ISA-88: Batch Control
  • ISA-95: Enterprise-Control System Integration
  • ISA-99: Security for Industrial Automation and Control Systems
  • ISA-95: Enterprise-Control System Integration

    De Enterprise-Control System Integration standaard – ISA-95, ook bekend als IEC/ISO 62264, beschrijft de besturingsniveaus, functies, activiteiten en gegevensstromen die in productiebedrijven onderkend worden.

    ISA-95 onderscheidt 5 hiërarchische levels (besturingsniveaus):

  • Level 4: Business Planning & Logistics domain (ERP, SCM);
  • Level 3: Manufacturing Operations Management domain (MES, MOM);
  • Level 2: Supervisory Control & Monitoring domain (SCADA, DCS);
  • Level 1: Machine Control (Sensors, PLC) domain;
  • Level 0: Machines & Physical processes domain.
  • ISA-95 zich richt voornamelijk op de beschrijving van de samenhang tussen levels 3 en 4 van het hiërarchische model en gaat uit van de gedachte dat alle informatie vanuit ERP komt. Dit is echter al heel wat jaren achterhaald.

    Eigenlijk zijn er twee levels bijgekomen. Level 5: Data Management & Integration (PLM, PIM, MPM) en Level 6: Digital Twins.

    ISA-95 onderscheidt functies die activiteiten uitvoeren en informatie met elkaar uitwisselen. Grafisch worden de informatiestromen tussen de functies weergegeven in het Functional Enterprise / Control Model. De activiteiten worden in detail per functie beschreven in de ISA-95.00.01 standaard.

    Binnen het Manufacturing Operations Management domain (L3: Factory Control Level) zien we applicaties als MES en MOM die volgende functies (met sub-functies die per organisatie kunnen verschillen) ondersteunen:

  • Production Scheduling
  • Production Control
  • Material and Energy Control
  • Quality Assurance
  • Product Inventory Control
  • Binnen het Business Planning & Logistics domain (L4: Business Level) zien we applicaties als ERP en SCM die volgende functies (met sub-functies die per organisatie kunnen verschillen) ondersteunen:

  • Order Processing
  • Production Scheduling
  • Material and Energy Control
  • Procurement
  • Quality Assurance
  • Product Inventory Control
  • Product Cost Accounting
  • Product Shipping Admin
  • In onderstaand plaatje bevat het oranje deel de functies en informatiestromen in het Business Planning & Logistics domein en het blauwe deel deze uit het Manufacturing Operations Management domein.

    Bron: ANSI/ISA-95.00.01 CDV3 2008

    Laten we eens kijken hoe binnen de 2 genoemde domeingebieden integratie door invoering van ERP en MES zich heeft ontwikkeld in de afgelopen 50 jaar.

    De komst van ERP en MES systemen hebben ervoor gezorgd dat informatiestromen in productiebedrijven meer en meer geïntegreerd zijn in de dagelijkse operationele activiteiten. Deze integratie was / is noodzakelijk om te kunnen blijven voldoen aan de eisen die de markt stelt aan snelheid, wendbaarheid en betrouwbaarheid.

    Business Level – ERP

    In het midden van de jaren ’60 zagen bedrijven dat het financieel niet langer mogelijk was om grote hoeveelheden grondstoffen en componenten aan te houden. Dit leidde rond de periode 1959 en 1961 tot de ontwikkeling van de principes van MRP I (Material Requirements Planning) en later tot implementatie van het eerste mainframe systeem voor het onderhouden van stuklijsten en het berekenen van materiaalbehoeftes (Joe Orlicky en Gene Thomas bij het bedrijf J.I. Case fabrikant van tractoren).

    Omstreeks 1972 introduceerde IBM het – voor een aantal onder ons – bekende COPICS (Communication-Oriented Production Information and Control System). COPICS werd tot het eind van de jaren ’80 in Nederland gebruikt door Philips – zelf heb ik nog in 1990 met COPICS gewerkt. COPICS werd later overgedragen aan voormalig medewerkers van IBM die het bedrijf “System Analysis and Program Development” hadden opgericht (beter bekend als SAP).

    In maart 1975 publiceerde Joe Orlicky het boek “Material Requirements Planning”.

    In 1980 ging MRP II (Manufacturing Resource Planning een stapje verder en voegde aan MRP I de planning en bewaking van productiemiddelen zoals mensen en machines toe.

    Daar waar MRP I en II zorgde voor integratie en besturing van voorraden, planning, capaciteit, productie en inkoop binnen bedrijven bracht ERP in de jaren ’90 al de processen, gegevens en functies samen onder één dak, in één geïntegreerd systeem met één centrale database.

    ERP gaat over de integrale besturing van een onderneming, vaak over meerdere vestigingen heen, en omvat de operationele en ondersteunende processen. Grofweg bestaan deze uit: Verkoop, Inkoop, Productie, Logistiek (verzending, ontvangst en voorraden), Financiën (debiteuren, crediteuren, boekhouding), Productontwikkeling en Informatiemanagement.

    Door het verbinden van alle bedrijfsprocessen en informatiestromen kunnen bedrijven efficiënter werken en sneller inspelen op vragen van klanten. Het accent ligt bij ERP op de financiële, logistieke en planningsprocessen.

    Wanneer we kijken naar hoe machines en apparaten in de fabriek worden aangestuurd dan zien we dat dit nog veelal handmatig gebeurt. Dit komt doordat ERP op een niveau opereert waar in termen van maanden en weken wordt gedacht terwijl machines real-time aansturing vragen.

    Iemand in de organisatie – de werkvoorbereider, de operator – vertaalt productieopdrachten naar activiteiten van weken naar dagen, van uren naar real-time en voert deze gegevens handmatig in via de bedieningspanelen van de machines (HMI = Human Machine Interface).

    Factory Control Level – MES / MOM

    Sinds een aantal jaren zien we in de procesindustrie en bij discrete productiebedrijven het gebruik van MES = Manufacturing Execution Systemen of ook bekend als MOM = Manufacturing Operations Management systemen toenemen.

    Toch blijft het aantal bedrijven dat een MES of MOM heeft geïmplementeerd relatief beperkt. Veel bedrijven gebruiken een Shop Floor Control systeem (SFC), een module in ERP of een losstaande applicatie.

    MES / MOM / SFC systemen richten zich op de beslissingen die genomen worden op het niveau van de werkvloerbesturing. Deze beslissingen gaan over de efficiëntie en transparantie van productieprocessen, de beschikbaarheid van machines en de kwaliteit van het eindproduct.

    Zowel bij MES of MOM als de losstaande SFC systemen werden in het verleden gegevens handmatig vanuit ERP overgebracht. Deze gegevens bestaan uit machines, mensen, gereedschappen, materialen, producten, processen, productie schedules, BOM, …

    In 2002 heeft de World Batch Forum (WBF) de B2MML (Business To Manufacturing Markup Language) ontwikkeld. B2MML is een XML standaard die gebruikt wordt om de integratie tussen bedrijfsinformatiesystemen (level 4) en productiesystemen (level 3) te realiseren op basis van de ISA-95 data-modellen (ANSI/ISA-95.00.01 en ANSI/ISA-95.00.02).

    De XML standaard is gebaseerd op de UN/CEFACT Core Components Technical Specification (ISO 15000-5) – een syntax-neutrale aanpak voor het ontwikkelen van berichtdefinities op basis van semantische bouwstenen.

    De eerste implementatie van B2MML vond plaats in 2003 in de Deense fabriek voor melk-ingrediënten van Arla Foods en had als doel productieorders vanuit ERP (SAP) naar MES over te brengen.

    Process Control Level – SCADA / DCS

    SCADA (Supervisory Control And Data Acquisition) en DCS (Distributed Control Systems) zijn monitoring en controle systemen. Zij zorgen dat productieprocessen soepel verlopen en machines volgens gewenste instellingen functioneren.

    Niettegenstaande data SCADA en DCS op hetzelfde level opereren zijn er toch verschillen in benadering.

    SCADA is event-gedreven en gericht op het verzamelen van gegevens. SCADA systemen reageren op gebeurtenissen en presenteren de veranderingen aan procesoperators die dan actie kunnen ondernemen. SCADA systemen worden ingezet voor sturing van productieprocessen in verschillende locaties.

    DCS systemen zijn proces-gedreven en direct verbonden met machines en apparaten. DCS systemen werken autonoom en volgen de veranderingen in proces-variabelen.

    Het grote vraagstuk voor de komende jaren is:

    Hoe verbinden we alle spelers in het integratieveld met elkaar zodat informatie in een vloeiende beweging doorheen het uitdijende ecosysteem stroomt ?

    Tags: ERP, MES, MOM, B2MML, ISA-95, SUPPLY CHAIN

    de Auteur

    Mijn aandachtsgebieden zijn: de uitdagingen waar bedrijven / managers en directeuren voor staan, het bieden van hulp bij de zoektocht naar antwoorden op deze uitdagingen, de technologische ontwikkelingen die de verhoudingen op zijn kop gaan zetten in de komende maanden / jaren, het begeleiden van adviestrajecten van concept tot realisatie.

    Mijn passie ligt bij het integreren en innoveren van bedrijfsprocessen, informatiestromen, systemen en organisaties zodat medewerkers en bedrijven zich volledig kunnen richten op hun kerntaken en bedrijven hun ambities kunnen waarmaken onder het motto "Giving control back to Business".

    Ik heb 30 jaar ervaring in de Maakindustrie, Bouw- en Installatiebranche bij internationale bedrijven op het gebied van proces-, project- en implementatiemanagement, ketenintegratie, ERP selectie en implementatie, stroomlijnen en implementatie van O2C en P2P processen.

    Continue!

    Aarzelt u nog om P2P, O2C of eFactureren op de rit te zetten met SAP ?

    Regelmatig hoor ik van bedrijven die de afgelopen decennia een ERP oplossing hebben geïmplementeerd dat ze er niet zijn in geslaagd om de beoogde doelstellingen en gekoesterde verwachtingen te realiseren.

    Dat uit zicht vooral in veel activiteiten die nog altijd handmatig worden uitgevoerd en arbeidsintensieve procedures die zijn bedacht om de unieke kenmerken / processen van het bedrijf te ondersteunen.

    De geïmplementeerde oplossing sluit kennelijk toch onvoldoende aan bij het bedrijf. En/of in het voortraject is te weinig aandacht besteed aan het in kaart brengen van de Business Requirements en aan het oplossen van bestaande problemen. En/of de organisatie is / was onvoldoende voorbereid, niet de juiste resources zijn permanent vrijgemaakt, te weinig inzicht in bedrijfsprocessen en gegevensstromen, en daarom / daardoor heeft men de implementatie maar overgelaten aan de implementatiepartner.

    "Who is here to blame! OF 'Wie treft hier dan schuld!"

    Verzint eer gij begint is hier mijn motto. Wat ik vaak zie is dat de bestuurlijke betrokkenheid van het management zich over het algemeen beperkt tot de aftrap van de implementatie.

    Zonder leiderschap en betrokkenheid eindigt elk avontuur in een persoonlijk drama. Visie, passie, overtuiging en vertrouwen is wat bedrijven nodig hebben om succesvol te zijn - en ja een beetje geluk helpt ook wel mee.

    Een ander belangrijk aandachtspunt is dat we automatisering moeten zien als een continu veranderingsproces. Go-live is het startpunt van continue kleine of middelgrote verbeteringen / veranderingen.

    Echter de meeste bedrijven komen hier meestal niet aan toe doordat ze tijdens de implementatie al teveel concessies hebben gedaan en de organisatie als het ware 'murw geslagen is'.

    elektronisch gegevensuitwisseling met klanten, leveranciers en onderling tussen vestigingen

    Één van die continue verbeteringen is het inrichten van elektronische gegevensuitwisseling met klanten, leveranciers en onderling tussen vestigingen. Uit ervaring weet ik dat dit enorme besparingen oplevert. Soms wel enkele FTE's op jaarbasis, alhoewel die FTE's dan niet werkelijk verdwijnen maar zich eindelijk kunnen gaan richten op het leveren van toegevoegde waarde voor de klant, leverancier of interne organisatie.

    Niettegenstaande deze positieve vooruitzichten merk ik veel terughoudendheid tijdens gesprekken met bedrijven. Zakelijk zien ze vooral op tegen de gevolgen die het verhogen van transparantie naar hun partners met zich mee kan brengen. En sommige bedrijven zien het helemaal niet zitten om flink te investeren in het aangaan van hechte samenwerkingsverbanden.

    De grootste belemmeringen zijn echter wel de technische complexiteit en de angst om in te leveren op flexibiliteit.

    Flexibiliteit is een goed excuus voor bedrijven die hun interne processen en gegevenshuishouding niet goed op de rit hebben. Het ontbreekt die bedrijven aan structuur en heldere duidelijke afspraken. En het is terecht een goed excuus want het succes van deze trajecten wordt grotendeels bepaald door hoe goed de interne gegevenshuishouding op orde en gestructureerd is. Is er een goede methodiek voor het coderen van artikelen, materialen en grondstoffen ? Voor het identificeren van partners en de verschillende partnerrollen. Binnenkort publiceer ik een artikel over ketenintegratie en daarin vertel ik hoe Philips dat doet / deed en hoe GS1 en Dun & Bradstreed daarbij vandaag kunnen helpen.

    Het ontbreken van technische voorzieningen aan de kant van ERP oplossingen is wel het meest valide argument. Veel leveranciers van ERP oplossingen worstelen nog steeds met het wel of niet aanbieden van standaard integratiemogelijkheden. We kunnen er niet omheen. Jarenlang is integratie de melkkoe geweest van veel leveranciers en het is moeilijk om daarvan afscheid te nemen. Dit argument geldt trouwens niet voor alle leveranciers. Een aantal - ik noem er slechts een paar - SAP, JDE, Oracle, MFG/Pro ondersteunen al decennia-lang O2C, P2P en product data gegevensuitwisselingsprocessen.

    de kosten van techniek en veranderingen weerhouden bedrijven

    Onderaan de streep zijn het dus de kosten van de techniek en van de door te voeren veranderingen die bedrijven ervan weerhouden om deze stappen te nemen.

    elektronisch bestellen en facturen aan de Inkoopkant

    Kijken we naar P2P / eProcurement met name elektronisch bestellen en factureren aan de inkoopkant dan bereiken bedrijven hier wel significante kostenbesparingen en procesverbeteringen mee. Voor financiële afdelingen is het aantal facturen dat automatisch zonder menselijke tussenkomst verwerkt kan worden een graadmeter voor de efficiëntie van het factuurverwerkingsproces -'touchless accounting'. Het streven is dan ook om zoveel mogelijk facturen automatisch te verwerken met minder mensen.

    Maar Straight Through Processing (STP) geeft veel meer inzicht, het is een indicator voor de efficiëntie en volwassenheid van het totale inkoopproces. Hoe meer het inkoopproces geautomatiseerd wordt en informatiesystemen van bedrijven geïntegreerd samenwerken hoe meer doorlooptijden en operationele kosten gereduceerd kunnen worden.

    Het zal je niet verbazen dat dit eveneens opgaat voor de afhandeling van klantorders.

    En dit zijn - naast het verhogen van omzet door versterking van de relaties met klanten of leveranciers - de besparingen die incrementele continue verbeteringen kunnen opleveren.

    Waarom nog langer aarzelen om P2P en O2C op de rit te zetten ?

    Het kost geld daar kunnen we het met elkaar over eens zijn maar het levert flink wat op - beter gestructureerde processen, verbeterde interne gegevenshuishouding, hogere graad van Straight-Through processing (STP), versterkte relaties met interne en externe partners EN sommige bedrijven moeten toch over stag voor April 2019.

    Immers vanaf April 2019 zijn Overheden en instellingen verplicht om te voldoen aan de Regelgeving 2014/55/EU die stelt dat ze in staat moeten zijn om elektronische facturen te ontvangen. Bedrijven die diensten of producten aan hen leveren zullen dan facturen elektronisch moeten sturen.

    SAP als backbone

    Wanneer ik uitga van een bedrijf met SAP als backbone durf ik stellen dat het mogelijk is om een vrij hoog percentage leveranciers aan te sluiten in een beperkte tijdspanne door:

  • het aanbieden van een gedifferentieerde strategie met keuze uit alleen facturen of ook orders en leveringen, met keuze uit verschillende kanalen waaronder een leveranciersportaal, directe integratie of integratie via een intermediair
  • een duidelijke strategie op het gebied van het hanteren van standaarden en afspraken rondom product en locatie-identificatie
  • gebruik te maken van standaard SAP integratie voorziening
  • goed ingerichte processen en gegevensvastlegging
  • hanteren van een beperkte set van gegevensuitwisselingsstandaarden en afsprakenstelsels waaronder PEPPOL, SimplerInvoicing, UBL, UN/CEFACT
  • een gedegen leveranciers-onboarding aanpak
  • De minder positieve ervaringen van bedrijven in de afgelopen jaren hebben vooral te maken met:

  • het gebrek aan duidelijke doelen en afbakening van de scope
  • het uit handen geven van de implementatie aan externe partijen die een veel te technische benadering voorstaan en te weinig aandacht hebben voor samenwerkingsprocessen en de inrichting van de gegevensvastlegging
  • de push van implementatiespecialisten voor maatwerkoplossingen omdat standaard interfaces zogenaamd niet voldoen
  • het volwassenheidsniveau van B2B integratiepartners en hun oplossingen
  • Mijn ervaring als Project Manager van ERP en eProcurement / eCommerce trajecten is dat oplossingen zoals SAP, MFG/Pro en JDE over genoeg standaard voorzieningen beschikken MAAR het vraagt wel dat implementatiespecialisten echt diep in de huid van de oplossing kruipen om te begrijpen hoe het werkt en wat de maker had bedoeld.

    Van 2010 tot midden 2015 heb ik P2P en O2C processen geïmplementeerd met technische groothandels in Nederland en Amerika en vestigingen onderling. En ik kan vertellen dat zonder veel maatwerk de standaard SAP IDOC interface je beste vriend kan zijn maar alleen als je echt heel diep gaat.

    SAP Hana Cloud Platform Integration (HCI)

    Met SAP Hana Cloud Platform Integration (HCI) en het SAP eDocument Solution is een rechtstreeks koppeling vanuit SAP met PEPPOL mogelijk voor uitgaande facturen.

    Voor JDE waar ik in 2016 even heb aan mogen ruiken geldt eigenlijk hetzelfde.

    Nu de grote vraag wanneer start u met elektronische gegevensuitwisseling met uw klanten, leveranciers of onderling tussen vestigingen ?

    Tags: EDI, ERP, PEPPOL, SAP

    Continue!

    vindt oplossingen voor uw bedrijf met design thinking

    De MOOC "Design Thinking" is de eerste in een serie van vijf uit de MicroMaster "Design Thinking" van het Rochester Institute of Technology in New York. De MicroMaster behandelt alle aspecten van design thinking en legt uit hoe design thinking te gebruiken voor het vinden van oplossingen voor uw problemen en uitdagingen.

    De stappen die doorlopen worden in het Design Thinking proces zijn:

    Describe Initial Problem

    Research

    Research technology:

    Research user and market:

    Research business:

    Reframe Problem Description

    Ideate and synthesize

    Prepare for ideation:

    Tags: BPMN2, Design Thinking

    Mijn aandachtsgebieden zijn: de uitdagingen waar bedrijven / managers en directeuren voor staan, het bieden van hulp bij de zoektocht naar antwoorden op deze uitdagingen, de technologische ontwikkelingen die de verhoudingen op zijn kop gaan zetten in de komende maanden / jaren, het begeleiden van adviestrajecten van concept tot realisatie.

    Continue!