ACM (1) Acumatica (1) Adobe XML Data Package (XDP) (1) agility (2) Archimate (1) Audit File Logistics (1) AZURE (1) B2MML (1) BIM (1) blockchain (3) BPM (11) BPMN (21) BPMN2 (1) Bruggenbouwer (2) Business Ecosystem (1) Business Leadership (10) CCTS (5) CDBC (1) CDE (1) CEN/BII (1) Change Management (6) cloud computing (5) CMMN (1) composable architecture (6) Consultancy (16) CRM (2) crypto (1) customs (1) D365 BC (1) D365 FSCM (16) DAM (5) data mapper (1) data mapping tool (3) data pools (4) DE&I (3) Design Thinking (1) desktop tools (1) Digital Leadership (21) Digital Manufacturing (1) Digital Thread (1) digital transformation (6) Digital Twin (1) DMN (3) DOM (1) DSDM (6) e-Business (18) e-Commerce (10) e-Factureren (3) e-Fulfillment (1) e-Invoicing (34) e-Ordering (2) e-Procurement (11) eclipse (6) Economics (1) EDI (10) EDIFACT (10) electronic data interchange (21) enterprise service bus (8) Environment (1) ERP (94) ESG (3) ETIM (3) European Commission (11) Fashion (2) flexibility (1) Food & Beverage (1) Government (3) GS1 (3) HR-XML (9) Hybrid Work (1) IDEAS (2) IIoT (2) Infor (1) Innovation (1) Interoperability-Frameworks (8) IoT (1) ISA-95 (1) Kwartiermaker (1) Legal (1) Leiderschap (4) MACH (8) mashups (1) MBEE (2) MES (3) metaverse (1) mind mapping (1) modeling frameworks (1) MOM (3) multi-tenancy (1) NetSuite (5) NEWS (5) NFT (1) nimbleness (1) O2C (1) Office Open XML (OOXML) (1) OMS (1) Open Document Format (ODF) (1) open source (2) Open Supply Hub (1) Overheid (5) PEPPOL (6) PIM (10) PLM (15) Politics (1) Portfolio Management (1) Prince2 (4) Process Mining (1) Process Modeling (17) Project Management (22) PropelPLM (2) Prosci ADKAR (3) Ramco (1) resilience (2) Retail (8) robustness (1) Rootstock (2) Salesforce (2) SAP (12) Security (1) service-oriented technologies (2) SITG (2) Smart Industry (2) Social (1) Supply Chain (31) Sustainability (14) Technology (1) ToolsGroup (5) UBL (12) UDEF (8) UN/CEFACT (6) Unified Commerce (5) Unit4 (1) Wholesale (3) WMS (8)

the future of data exchange in the construction and installation sector

In recent years the construction and installation sector have been working closely together to define uniform standards for the building industry. The industry associations are well aware of the benefits and savings that can be achieved by the electronic exchange and provision of data.

In the past, the communication with customers and suppliers could easily be done manually – by email, post or via fax. Today we see in other sectors that electronic business is increasingly being adopted. Companies in the building industry more often receive requests from customers and suppliers to exchange data electronically and to provide product data in a standard format.

Industry associations have delivered an important contribution to this change of mentality by developing standards and providing facilities for sharing product data.

In 2012 ETIM and S@les in de Bouw under guidance of GS1 defined a common XML standard for the construction and installation sector. On June 1, 2015 the ETIM Building classification was officially published as an extension to the international ETIM standard for classification of product information in the installation sector. A development that sets the construction and installation sector closer together and offers benefits to all companies in the building industry.

It is important that continuous efforts are made to reduce the thresholds for participation. This requires commitment of all those involved in the building industry, from manufacturers to construction companies and calls for a director who encourages and monitors the use of standards.

What can we learn from electronic invoicing?

When I make a trip to the world of electronic invoicing, we see there that despite all standardization efforts the adoption in the past 10 years has been limited. That has, in my view, four major causes.

First of all, the perpetual debate over the preferred global standard, UBL or UN/CEFACT, and the emergence of various variants on these standards. That must/may not happen in the construction and installation sector.

In addition, the large growth of providers of B2B solutions with their own standards and networks. These providers solved the spaghetti-problem of EDI but managed to create a new problem that slowed down (still does) the adoption of electronic invoicing. The explosive growth of B2B providers brought the interoperability problem between providers – the lack of interoperability between the systems of information providers – one spaghetti problem went away and another one came in its place. Luckily (one would say) the providers invented the interoperability agreements (roaming). But these rather have a commercial purpose than that they really live up to what is promised due to the absence of uniform standards between providers and the improper interest in the own network.

Third, there is the one-sided attention for the electronic invoice leaving only the receiver of an invoice to fully enjoy the benefits of automated processing. In other words the lack of the supply chain thinking.

Last but not least – the starting point: what do we mean by electronic in other words is digital the same as electronic. A discussion that takes place quite often. Let me formulate my position as follows: I'm happy with the standard electronic messages of the construction and installation sector and I believe that integration of systems in the future can not be done without these standards.

Do companies in the building industry suffer from similar problems?

Indeed there are companies that experience such problems and we must prevent this.

Installation companies are urged by several parties to retrieve and exchange data electronically. These companies have to do with suppliers, customers and centralized product data pools that each have their own way of data exchange.

For these companies it becomes impractical over time to facilitate the technical and functional requirements of all these parties.

Let's look at what an average installation company has to deal with. An installation company in the building industry retrieves materials from wholesalers and from suppliers that deliver their products to the building and installation sector or to both. In turn they receive purchase orders from customers and must supply data to participate in major construction projects.

First of all, the company gets to do with the product-data pool from the installation sector (2BA or through and from the construction sector (EZ-base). Further, the company has a number of vendors, each with its own EDI/XML Message Broker or B2B provider which should be connected.

How can we make life a lot easier for this company and others!

(How can we help companies to start exchanging electronic data and/or retrieve product data)

There are two routes that could be followed here:

Route 1: the construction and installation sector picks up the role of director and provides a platform/infrastructure – an information highway for companies to exchange messages and information with each other.

Compare it with the PEPPOL project (= Pan-European Public Procurement Online) of the European Commission. This project is aimed at simplifying Procurement between Government and businesses both national and cross-border.

Only (in my opinion) individual companies should be able to connect their information systems easier and faster. With PEPPOL this now is mainly done through service providers that act as Access Point providers. An authorized Access Point has to comply with all kinds of technical and functional requirements for which certification must be gained.

A Business Process Management system consisting of a process, a data, integration and service layer can greatly simplify the process of connecting and exchanging data. When participants through search-and invite can link with one another it would significantly reduce the threshold for participation. The challenge is then with the providers of information systems (ERP, PLM, and others) to open up their systems.

If we look at BPM systems (Pegasystems, E2E Bridge, ...) we see that they already have links to many existing information systems. When information systems offer their functionality as services then connecting on the information highway is pretty simple to accomplish.

Route 2: the company itself implements a BPM system and connects with the different providers of their customers and vendors. Here it is important that the BPM system can be implemented without high cost, is flexible and can quickly respond to new and changed requirements of customers or suppliers. But also that the existing B2B/EDI Providers offer these companies the possibility of free of charge data exchange with partners on their network.

By the way: I shouted years ago (2009) that Google, Yahoo or Microsoft should set up such a highway. In the meantime there are plenty of other players like Facebook and Linkedin who could do this.

Side Note:

I have spent the past weeks writing articles about the realization of process-driven and model-based information systems which are all covering the way the intermediate platform can be established and what systems can be used for this purpose:

Kunnen we proces-gedreven informatiesystemen ontwikkelen met BPMN2? [soon to be translated]

BPM systemen helpen bedrijven van hun maatwerk af [soon to be translated]

Process-driven value networks change electronic business

It would be nice to organize a discussion with all parties concerned or with companies who want to start with exchange of data and see what we can achieve. Visit: Electronic Business Knowledge Village on Linkedin.

Tags: Process Modeling, BPMN, e-Business, e-Invoicing, e-Procurement, enterprise service bus, datapool


de toekomst van gegevensuitwisseling in de bouw- en installatiesector

De bouw en installatiesector werken de laatste jaren intensief samen om te komen tot uniforme standaarden voor de bouwkolom. De brancheorganisaties zijn zich zeer goed bewust van de voordelen en besparingen die behaald kunnen worden door het elektronisch uitwisselen en beschikbaar stellen van gegevens.

In het verleden konden bedrijven de communicatie met klanten en leveranciers gemakkelijk handmatig verzorgen – via email, per post of via de fax. De laatste jaren zien we in andere branches dat elektronisch zakendoen meer en meer wordt geadopteerd. Ook bedrijven in de bouwkolom vragen steeds vaker aan hun klanten en leveranciers om gegevens elektronisch uit te wisselen en productgegevens in een standaard formaat beschikbaar te stellen.

Brancheorganisaties hebben een belangrijke bijdrage geleverd aan deze mentaliteitsverandering door het ontwikkelen van standaarden en het beschikbaar stellen van voorzieningen voor het delen van artikelgegevens.

In de bouw- en installatiesector is door ETIM en S@les in de Bouw onder begeleiding van GS1 in 2012 een gemeenschappelijke XML standaard gedefinieerd. Op 1 juni 2015 is de ETIM Bouw classificatie officieel gepubliceerd als een uitbreiding op de internationale ETIM standaard voor de classificatie van productgegevens in de installatiesector. Een ontwikkeling die de bouw- en installatiesector dichter bij elkaar brengt en ten goede komt aan alle bedrijven in de bouwkolom.

Het is wel belangrijk dat blijvend inspanningen worden geleverd om de drempels voor deelname te verlagen voor bedrijven. Dit vraagt inzet van alle betrokkenen in de bouwkolom, van producenten tot bouwbedrijven en vraagt om een regisseur die het gebruik van standaarden stimuleert en bewaakt.

Wat kunnen we leren van elektronisch factureren?

Wanneer ik een uitstapje maakt naar de wereld van elektronisch factureren dan zien we daar dat ondanks alle standaardisatie-inspanningen de adoptie in de afgelopen 10 jaar beperkt is geweest. Dat heeft in mijn optiek een viertal belangrijke oorzaken.

Allereerst de eeuwigdurende discussie over welke wereldwijde standaard, UBL of UN/CEFACT, de voorkeur kreeg/krijgt en het ontstaan van verschillende varianten op deze standaarden. Dat kan / mag dus / niet gebeuren in de bouw- en installatiesector.

Daarnaast de grote opkomst van aanbieders van B2B oplossingen met eigen standaarden en netwerken. Deze aanbieders losten het spaghetti-probleem van EDI op maar veroorzaakten een nieuw probleem die vertragend heeft gewerkt (en nog steeds) voor de adoptie van elektronisch factureren. Door de explosieve groei van aanbieders ontstond het interoperabiliteitsprobleem tussen aanbieders – het ontbreken van informatie interoperabiliteit tussen de systemen van providers – het ene spaghetti-probleem verdween en een ander kwam daarvoor in de plaats. Gelukkig zou je zeggen hebben de aanbieders daarvoor de interoperability agreements (roaming) bedacht. Maar deze hebben eerder een commercieel doel dan dat ze werkelijk worden waar gemaakt bij gebrek aan uniforme standaarden tussen aanbieders en het belang van het eigen netwerk.

Als derde is er de eenzijdige aandacht voor de elektronische factuur waardoor alleen de ontvanger van een factuur kan genieten van volledig geautomatiseerde verwerking. Anders gezegd het ontbreken van de ketengedachte.

Als laatste maar niet onbelangrijk – het uitgangspunt: wat verstaan we onder elektronisch ofwel is digitaal hetzelfde als elektronisch. Een discussie die heel vaak en nog steeds wordt gevoerd. Laat me mijn standpunt als volgt formuleren: ik ben blij met de elektronische berichtenstandaard van de bouw- en installatiesector en ik geloof dat integratie van systemen in de toekomst niet zonder deze standaarden kan.

Hebben bedrijven in de bouwkolom last van soortgelijke problemen?

Inderdaad er zijn bedrijven en daar moeten we over waken die nu al dergelijke problemen ervaren.

Installatiebedrijven worden door allerlei partijen in de keten gevraagd om elektronisch gegevens op te halen en uit te wisselen. Deze bedrijven hebben te maken met leveranciers, klanten en centrale product-datapools die allen hun eigen manier van gegevensuitwisseling hanteren.

Voor deze bedrijven wordt het na verloop van tijd ondoenlijk om aan al de technische en functionele eisen van deze partijen te voldoen.

Laten we eens kijken naar waar een gemiddeld installatiebedrijf mee te maken krijgt. Een installatiebedrijf in de bouwkolom betrekt materialen bij groothandels en leveranciers die leveren aan de bouw- of aan de installatiesector of aan beiden. Op hun beurt ontvangen ze orders van klanten en moeten ze gegevens aanleveren voor deelname aan grote bouwprojecten.

Allereerst krijgt het bedrijf te maken met de product-datapool van de installatiesector (2BA of via en van de bouwsector (EZ-base). Verder heeft het bedrijf een aantal leveranciers met elk een eigen EDI/XML Message Broker of B2B provider waarop aangesloten dient te worden.

Hoe kunnen we het leven een stuk eenvoudiger maken voor dit bedrijf en anderen!

(Hoe kunnen we bedrijven helpen om elektronisch gegevens te gaan uitwisselen en/of productgegevens op te halen)

Er zijn twee routes die hier gevolgd zouden kunnen worden:

Route 1: de bouw- en installatiesector pakt de rol van regisseur en zorgt voor een platform / infrastructuur – een informatie-snelweg waarover bedrijven berichten en gegevens met elkaar kunnen uitwisselen en delen.

Vergelijk het met het PEPPOL-project (=Pan-European Public Procurement Online) van de Europese Commissie. Dit project is gericht op het vereenvoudigen van Procurement tusssen Overheid en bedrijven zowel nationaal als grensoverschrijdend.

Alleen (in mijn optiek) zouden individuele bedrijven eenvoudiger in staat moeten zijn om hun informatiesystemen aan te sluiten. Bij PEPPOL gebeurt dit nu voornamelijk via service providers die als Access Point providers fungeren. Een geautoriseerd Access Point moet aan allerlei complexe technische en functionele vereisten voldoen en daarvoor gecertificeerd worden.

Een Business Process Management Systeem bestaande uit een proces-, een gegevens-, integratie- en servicelaag kan het proces van aansluiten en gegevensuitwisseling sterk vereenvoudigen. Wanneer deelnemers via search- en invite verbindingen met elkaar in stand kunnen brengen zou dat de drempel voor participatie sterk verlagen. De uitdaging ligt dan bij de aanbieders van informatiesystemen (ERP, PLM, e.a.) om hun systemen open te stellen.

Als we kijken naar BPM systemen (Pegasystems, E2E Bridge, …) dan zien we dat deze al beschikken over koppelingen voor veel bestaande informatiesystemen. Wanneer informatiesystemen hun functionaliteiten als services beschikbaar kunnen stellen is het aansluiten op de informatie-snelweg vrij eenvoudig te realiseren.

Route 2: het bedrijf implementeert zelf een BPM systeem en sluit de verschillende providers van hun klanten en leveranciers aan op het systeem. Hier is het van belang dat het BPM systeem zonder hoge kosten ingevoerd kan worden, flexibel is en snel kan inspelen op nieuwe en gewijzigde eisen van klanten of leveranciers. Maar ook dat de bestaande B2B / EDI Providers deze bedrijven de mogelijkheid bieden om kosteloos gegevens uit te wisselen met de partners die op hun netwerk zijn aangesloten.

By the way: ik heb het jaren geleden (2009) al geroepen dat Google, Yahoo of Microsoft een dergelijke snelweg zou moeten opzetten. Ondertussen zijn er genoeg andere spelers zoals Facebook en Linkedin die dit zouden kunnen doen.

Ik heb de afgelopen weken een aantal artikelen geschreven over de realisatie van proces-gedreven en modelgebaseerde informatiesystemen die allen betrekking hebben op de wijze waarop het intermediair platform vorm gegeven kan worden en welke systemen daarvoor gebruikt kunnen worden:

Kunnen we proces-gedreven informatiesystemen ontwikkelen met BPMN2?

BPM systemen helpen bedrijven van hun maatwerk af

Procesgedreven waardenetwerken veranderen elektronisch zakendoen

Het zou mooi zijn om hier met alle betrokkenen of met bedrijven die willen starten met het uitwisselen een discussie over te voeren en te kijken wat we kunnen realiseren. Bezoek het platform eZakendoen op Linkedin.

Tags: Process Modeling, BPMN, e-Business, e-Invoicing, e-Procurement, enterprise service bus, datapool


What is an online platform without the power of integration?

The online Cloud-based sales, purchase and supply chain solutions are increasingly in vogue. These environments often are a solution for a particular domain area within companies such as sales (CRM, Marketing), purchase (contract management, catalog management,) or distribution (transport management).

With the rise of these Cloud-based solutions there is a growing need for flexible integration solutions. Not only is integration with the backend systems of companies, customers and suppliers crucial for an optimal connection with business processes. But another form of integration arises – a Cloud-2-Business-2-Cloud integration.

When companies support their CRM process with a Cloud-based solution data from this solution (customer, product and order information) will be funneled to the corporate sales and production system.

For products that are manufactured by a company there will be a need for components that have to be purchased through the Cloud-based purchase environment.

When it comes to products that a company buys from third parties the sales orders from the online CRM solution should be channelled to the online purchase environment.

The complexity of all connections that companies have to handle increases with the emergence of more and more service-oriented solutions – in a private or public cloud or on-premise.

The foundation to keep all of this up and running in the coming years are process-driven and model-based integration solutions with a small server and memory footprint. Solutions which do not require a fast processor and much internal memory. This calls for solutions that do not need a Web server (Apache Tomcat, JBoss, etc) but run as a virtual machine on operating systems without interruption.

A little spider in the network of applications a company uses which ensures that everything is and remains constantly connected. When a connection goes down still holds the data (no loss of information), continues to support the work of other applications, and waits for the line to become operational again to transmit the preserved data.

Integration Process Modeler = the modeling tool used to model business processes - supply chain processes from a high level (descriptive) to a low level (executable). With the modeling tool business processes are modeled using BPMN2 and DMN, data models and integrations with UML and screens with user interface diagrams. The services provided by the Servants are associated with the process elements during modeling.

Process Engine = a small server – memory footprint engine that runs the models defined using the modeling tool and makes the operational results of the process visible through a web-based monitor. This gives direct insight in the performance of each process step, the input and output parameters of each step and the bottlenecks – lead times of processes.

Servants = are building blocks for initializing the features available in the Library and make them available as services. During modeling the functions of different providers can be selected from the Libary. The initialization consists of activating the function of a provider and ensuring that the input and output parameters are delivered or processed from whithin the process flow.

Libray = the library of functions of different solution providers. A function is not a complete ERP system but just the functionality to create a sales order and the data model that belongs to a sales order. It is in principle possible for the creation of an order to use the function of provider X and for the delivery of the order the function of provider Y.

The number of process-driven and model-based integration solutions with a small server and memory footprint is limited. On request I can tell you more about it.

Side note: Banks in recent years have noticed that the guarantee of continuous availability with solutions that depend on Web servers or virtual machines is not easy. The performance of Web servers have to be monitored and updated continuously. These solutions impose heavy demands on the hardware, networks and software. A small footprint integration solution reduces this dependency.

Transport companies and also retailers need to interface with technical systems such as on-board computers and POS systems. The presented integration solutions not only handle the integration of business applications but can in principle provide integrations between all kinds of systems.

Tags: Process Modeling, BPMN, e-Business, e-Invoicing, e-Procurement, enterprise service bus


Wat is een online platform zonder de kracht van integratie?

De online Cloud-gebaseerde verkoop-, inkoop- en ketenoplossingen raken steeds meer in zwang. Deze omgevingen fungeren vaak als oplossing om een bepaald domeingebied binnen bedrijven te ondersteunen zoals verkoop (CRM, Marketing), inkoop (contract management, catalog management, ) of distributie (transport management).

Met de opkomst van deze oplossingen is meer en meer behoefte ontstaan naar flexibele integratieoplossingen. Niet alleen is integratie met de backend systemen van bedrijven, klanten en leveranciers noodzakelijk voor een optimale aansluiting met de bedrijfsprocessen. Maar er ontstaat eveneens een ander vorm van integratie – de Cloud-2-Business-2-Cloud integratie.

Wanneer bedrijven hun CRM proces ondersteunen met een Cloud-gebaseerde oplossing zullen gegevens vanuit deze oplossing (klant-, product- en ordergegevens) naar het bedrijfseigen verkoop- en productiesysteem gesluisd worden.

Als het gaat om artikelen die door een bedrijf worden geproduceerd zullen vanuit productie behoeften ontstaan naar onderdelen die op hun beurt weer worden ingekocht via een Cloud-gebaseerd inkoopomgeving.

Als het gaat om artikelen die een bedrijf inkoopt bij derden zullen de orders vanuit de online CRM-oplossing doorgesluisd moeten worden naar de online inkoopomgeving.

De complexiteit van al de verbindingen waarmee bedrijven te maken krijgen neemt met de opkomst van meer en meer service-georiĆ«nteerde oplossingen – in een private of public cloud of on-premise alsmaar toe.

De basis om dit alles in de komende jaren draaiende te houden zijn proces-gedreven en modelgebaseerde integratieoplossingen met een small server en memory footprint . Oplossingen die geen snelle processor en veel intern geheugen nodig hebben. Dit vraagt om oplossingen die geen webserver (Apache Tomcat, JBoss, e.a.) nodig hebben maar als een virtuele machine draaien op operating systemen en continue zonder onderbrekingen operationeel zijn.

Een spinnetje in het netwerk van alle applicaties waar een bedrijf gebruik van maakt en ervoor zorgt dat alles met elkaar verbonden is en blijft. En als de verbinding met een applicatie verbreekt, de gegevens vasthoudt (geen verlies aan informatie), de werkzaamheden van de andere applicaties blijft ondersteunen, en wacht tot het lijntje weer operationeel is om de opgespaarde gegevens door te geven.

Integration Process Modeler = het modelleergereedschap waarmee bedrijfsprocessen - ketenprocessen gemodelleerd worden van een hoog niveau (beschrijvend) tot een laag niveau (uitvoerend - executable). Met het modelleergereedschap worden bedrijfsprocessen met BPMN2 en DMN gemodelleerd, gegevensmodellen en integraties met UML en schermen met gebruikersinterface diagrammen. De services geleverd door de Servants worden gekoppeld aan de proceselementen tijdens het modelleren.

Process Engine = een small server – memory footprint engine die de modellen gedefinieerd met het modelleergereedschap uitvoert. En de operationele resultaten van de procesvoortgang zichtbaar maakt via een web-gebaseerde monitor. Hiermee wordt direct inzicht verkregen in de performance van elke processtap, de input- en output parameters van elke stap en de bottlenecks – doorlooptijden van processen.

Servants = zijn bouwstenen waarmee de functies die beschikbaar zijn in de Library ingericht / gemodelleerd kunnen worden en als services beschikbaar gesteld worden. Tijdens het modelleren kunnen de functies van verschillende aanbieders uit de Libary geselecteerd en ingericht worden. De inrichting bestaat uit het activeren van de functie van een aanbieder en het zorgen dat vanuit de procesflow de input en output parameters worden aangeleverd of verwerkt.

Libray = de bibliotheek van functies van verschillende aanbieders van oplossingen. Bij een functie denken we niet aan een ERP systeem maar aan de functionaliteit voor het aanmaken van een verkooporder en het gegevensmodel dat bij een verkooporder hoort. Het is in principe mogelijk om voor de aanmaak van een order de functie van aanbieder X in te richten en voor het uitleveren van de order de functie van aanbieder Y.

Het aantal proces-gedreven en modelgebaseerde integratieoplossingen met een small server en memory footprint is beperkt. Op verzoek kan ik hier meer over vertellen.

Kanttekening: Banken hebben in de afgelopen jaren gemerkt dat het garanderen van continue beschikbaarheid met oplossingen die afhankelijk zijn van webservers of virtuele machines niet eenvoudig is. De performance van de webservers moet continue gevolgd en bijgesteld worden. Deze oplossingen stellen zware eisen aan de hardware, netwerken en software. Een small footprint integratieoplossing vermindert deze afhankelijkheid.

Transportondernemingen maar ook Retailbedrijven moeten interfacen met technische systemen zoals boordcomputers en kassasystemen. De geschetste integratieoplossingen gaan niet enkel over de integratie van bedrijfsapplicaties maar kunnen in principe integraties verzorgen tussen allerlei systemen.

Tags: Process Modeling, BPMN, e-Business, e-Invoicing, e-Procurement, enterprise service bus