Onafhankelijk Advies in Supply Chain & Digitale Transformatie

DANGA doorbreekt de ruis rondom digitale transformatie. Als adviseur verbind ik uw upstream en downstream supply chain‑strategie aan de juiste architectuur en enterprise‑systemen. Geen leverancierspraatjes, maar senior regie die miljoenenverliezen bij implementaties voorkomt.

Showing posts with label EDI. Show all posts
Showing posts with label EDI. Show all posts

EDI — the silent layer that carries everything

For years, EDI has been dismissed as a relic from a bygone era.
A protocol that was once useful, but now supposedly overshadowed by APIs, platforms, and “real-time” ambitions.

Anyone working in retail, logistics, or supply chain knows better.
EDI is very much alive.

Every day, millions of transactions run over EDI connections.
It links suppliers to retailers who won’t tolerate a single second of delay.
It moves orders, inventory, deliveries, invoices, and transport data without anyone posting or talking about it.

That silence creates a persistent misconception: that APIs will replace EDI.

They won’t.

APIs are integration technology.
EDI is a data standard and a governance model.
One does not replace the other — they complement each other.

Retailers add APIs alongside EDI because stability matters more than elegance,
and predictability matters more than innovation.

The real movement in the market is quiet.
It doesn’t show up in press releases, but in contracts, obligations, legislation, and supply-chain pressure.

More retailers are mandating EDI compliance.
More countries are requiring electronic reporting.
More suppliers must connect just to be allowed to do business.
More message types are being added to existing flows.
More cloud-EDI and managed services are absorbing the complexity.

The volume grows.
The visibility doesn’t.

And that’s exactly why EDI is so often underestimated.

EDI is not a choice.
It’s a requirement.

For anyone operating in retail or supply chain, it’s the gateway.
You’re in — or you’re not.

The importance of EDI never decreases.
It simply shifts from “technology” to “infrastructure.”
From “project” to “prerequisite.”
From “innovation” to “continuity.”

And PEPPOL only reinforces that movement.

The mature perspective

Those who dismiss EDI aren’t lacking vision, they’re lacking experience with real supply-chain dynamics:

  • • Never seen true retail volumes
  • • Never experienced a chain where an ASN is ten minutes late
  • • Never felt the dependencies between DCs, carriers, suppliers, and stores
  • • And never witnessed how a single error in a single message can halt an entire chain

EDI isn’t exciting. Not new. Not visible.
And yet: it carries everything.

And that makes it more important than ever.
You only understand that when you’ve seen the practice up close.

EDI — de stille laag die alles draagt

Al jaren wordt EDI weggezet als een reliek uit vervlogen tijden.
Een protocol dat ooit nuttig was, maar nu in de schaduw staat van API’s, platforms en “real‑time” ambities.

Wie in retail, logistiek of supply chain werkt, weet beter.
EDI is springlevend.

Elke dag draaien er miljoenen transacties over EDI‑verbindingen. Het verbindt leveranciers met retailers die geen seconde vertraging accepteren. Het stuurt orders, voorraden, leveringen, facturen en transporten zonder dat iemand erover post of praat.

Juist die stilte zorgt voor een hardnekkig misverstand: dat API’s EDI zouden vervangen.

Dat klopt niet.

API’s zijn integratietechnologie.
EDI is een datastandaard en governance‑model.
Het ene vervangt het andere niet — het vult het aan.

Retailers voegen API’s toe naast EDI, omdat stabiliteit belangrijker is dan elegantie en voorspelbaarheid belangrijker dan innovatie.

De beweging in de markt is stil.
Ze zit niet in persberichten, maar in contracten, verplichtingen, wetgeving en ketendruk.

Meer retailers stellen EDI‑compliance verplicht.
Meer landen eisen elektronische rapportage.
Meer leveranciers moeten aansluiten om überhaupt zaken te mogen doen.
Meer berichttypen worden toegevoegd aan bestaande stromen.
Meer cloud‑EDI en managed services nemen de complexiteit over.

Het volume groeit.
De zichtbaarheid niet.

En precies daarom wordt EDI zo vaak onderschat.

EDI is geen keuze.
Het is een voorwaarde.

Voor wie in retail of supply chain opereert, is het de toegangspoort.
Je doet mee, of je doet niet mee.

Het belang van EDI neemt nooit af.
Het verschuift alleen van “technologie” naar “infrastructuur”.
Van “project” naar “voorwaarde”.
Van “innovatie” naar “continuïteit”.

En PEPPOL versterkt die beweging alleen maar.

Het volwassen perspectief

Wie EDI wegwuift, verraadt geen visie, maar gebrek aan ervaring met echte ketendynamiek:

  • • Nooit echte retailvolumes gezien
  • • Nooit een keten meegemaakt waar een ASN 10 minuten te laat is
  • • Nooit de afhankelijkheden gevoeld tussen DC’s, transporteurs, leveranciers en winkels
  • • En nooit meegemaakt dat één fout in één bericht een hele keten stillegt

EDI is niet spannend. Niet nieuw. Niet zichtbaar.
En toch: het draagt alles.

En dat maakt het belangrijker dan ooit.
Dat weet je wanneer je de praktijk van dichtbij hebt meegemaakt.

Slimme ketens werken met ritme, niet verrassing

Veel supply chains draaien nog op het oude model: bestellen, wachten, bijsturen... hopen. Dat werkt zolang volumes laag blijven en de keten overzichtelijk is. Maar zodra de complexiteit stijgt, wordt dat oude recept een bron van chaos.

Dan heb je ritme nodig.

Ritme in de keten: van losse orders naar afspraken

Scheduling agreements brengen dat ritme in de keten. Geen losse orders, maar structurele afspraken over:

  • • totale afnamehoeveelheid
  • • periode waarbinnen geleverd wordt
  • • prijs- en contractafspraken
  • • geplande leveringsmomenten

De planning wordt daarna verfijnd via schedule lines of call-offs, vaak automatisch via EDI.
Je bestelt dus niet steeds opnieuw — je bevestigt en stuurt bij binnen een vaste structuur.

Het resultaat is rust, voorspelbaarheid en grip.

Wat levert het op?

  1. 1. Minder administratie: geen stapels orders of bevestigingen, maar één lopende afspraak.
  2. 2. Betere planning: productie draait op echte vraag, niet op hoop of inschatting.
  3. 3. Transparantie en vertrouwen: data stroomt continu door de keten, afwijkingen worden eerder gezien én opgelost.
  4. 4. Logistieke rust: geen ad-hoc leveringen of last-minute brandjes. Het ritme draagt de operatie.
  5. 5. Basis voor AI: structuur maakt voorspellen, leren en verbeteren pas echt mogelijk.

Hoe werkt dit in SAP?

Scheduling agreements bestaan aan beide kanten van de keten:

  • MM (Inkoop): afspraken met leveranciers over materialen en onderdelen
  • SD (Verkoop): afspraken met klanten over vaste leverpatronen

Synchronisatie gebeurt via DELFOR/DELJIT (EDI).

SAP genereert leveringsvoorstellen (VL10) op basis van vervaldatums — leveringen en facturen volgen vervolgens het ritme van de afspraken.

Dit is procesdiscipline in softwarevorm.

Voor wie is dit waardevol?

  • • Maakindustrie
  • • Automotive
  • • High-tech
  • • Food & FMCG
  • • Logistiek dienstverleners
  • • Distributiebedrijven met hoge volumes en repeterende leveringen

Waar volumes hoog zijn, betrouwbaarheid cruciaal is en supply chain geen gokspel mag zijn — daar hoort ritme bij.

Ook kleinere bedrijven kunnen profiteren: structuur schaalt namelijk omhoog én omlaag.

Veelgehoorde misvattingen

“Dat doen we later wel.”
Als volumes groeien, groeit de chaos sneller dan de structuur.

“Tools lossen dit op.”
Tools versterken wat er is. Zonder discipline geen voordeel.

“We hebben geen tijd voor procesafspraken.”
Dan komt die tijd vanzelf — tijdens escalaties. Kies waar je in investeert.

Wat heb je nodig?

  • • Heldere masterdata en artikelnummers
  • • Gedeelde datadefinities
  • • Basisdiscipline in planning
  • • EDI of andere automatische berichtuitwisseling
  • • Een business die begrijpt dat voorspelbaarheid een strategisch voordeel is

Slotgedachte

Scheduling agreements zijn geen technische truc. Ze zijn de brug naar vertrouwen, schaalbaarheid en voorspelbaarheid in de keten.
SAP noemt ze zo, maar het idee is universeel. Oracle, Dynamics, Blue Yonder – allemaal bouwen ze aan ritme, elk met hun eigen taal.

Wie ritme brengt in zijn supply chain, bouwt geen systeem dat reageert.
Je bouwt een keten die vooruitdenkt.

Swiss AviationSoftware en Aeroxchange gaan samenwerken

Swiss AviationSoftware en Aeroxchange kondigen lancering van de EDI-interface tussen AMOS en AeroRepair aan

De interface maakt het mogelijk om digitale uitwisseling van reparatieorders voor operators met AMOS, met AeroRepair als uitwisselingsplatform.

Swiss AviationSoftware (Swiss-AS) en Aeroxchange zijn verheugd om vandaag (14 oktober 2024) de release van een nieuwe interface voor elektronische gegevensuitwisseling (EDI) aan te kondigen tussen hun respectieve systemen, AMOS en AeroRepair [1] [2].

Swiss Aviation Software, onderdeel van het Lufthansa Technik Digital Tech Ops Ecosystem, is een toonaangevende leverancier van software voor onderhoudsbeheer voor de luchtvaart. Het vlaggenschipproduct, AMOS, wordt wereldwijd gebruikt door luchtvaartmaatschappijen, MRO-providers en OEM's om hun onderhouds-, engineering- en logistieke behoeften te beheren. Swiss-AS is toegewijd aan het leveren van oplossingen die de operationele efficiëntie en naleving van de regelgeving verbeteren.

Aeroxchange biedt een uitgebreid pakket producten dat efficiënte en veilige zakelijke transacties tussen luchtvaartmaatschappijen en hun partners in de toeleveringsketen mogelijk maakt. AeroRepair is een compleet reparatieorderbeheer- en volgsysteem dat de bedrijfsefficiëntie verhoogt door inzicht te geven in de levenscyclus van de reparatieorder. Met functies zoals updates voor realtime status, robuuste goedkeuringshiërarchieën en gedetailleerde rapportage, helpt AeroRepair kopers betere beslissingen te nemen en de kosten te verlagen die gepaard gaan met informatiefouten en vertragingen.

Deze samenwerking zal de efficiëntie verbeteren en het proces voor het beheer van reparatieorders voor operators en MRO-providers stroomlijnen.

De interface maakt het mogelijk om digitale uitwisseling van reparatieorders voor operators met AMOS, met AeroRepair als uitwisselingsplatform. Deze integratie biedt gebruikers volledige zichtbaarheid en controle vanaf het eerste verzoek tot factuur, gebruikmakend van de mogelijkheden voor reparatieorderbeheer van AeroRepair. AMOS-gebruikers profiteren van functies zoals updates voor realtime status, verzendmeldingen, gedetailleerde afbraakrapporten en beheer van opties voor meerdere noten.

Aeroxchange is een van de eerste partners die een native integratie heeft gebouwd met het nieuwe AMOS-framework AMOShub voor veilige berichtuitwisseling. Deze implementatie toont de flexibiliteit en functionaliteit van AMOS bij het verbeteren van de samenwerking en interoperabiliteit in de luchtvaartonderhoudsindustrie.

Vanaf versie 23.12 profiteren de klanten van AMOS via AMOShub van de EDI-interface. Het is een van de eerste productieproducten in AMOShub, naast het Lufthansa Technik Digital Tech Ops Ecosystem-aanbod van Aviatar en Flydocs, waarin onze toewijding wordt benadrukt om oplossingen te bieden die voldoen aan de veranderende behoeften van de luchtvaartindustrie.

Lees meer

  • [1] Swiss-AS and Aeroxchange Announce Launch of EDI Interface between AMOS and AeroRepair
  • SPS Commerce neemt de SAP B1 Integration Technology tak van Vision33 over

    SPS Commerce, de Amerikaanse specialist op het gebied van Cloud-diensten voor de detailhandel, heeft begin van de maand (april 2024) de overname aangekondigd van de SAP B1 Integration Technology group van Vision33.

    SPS Commerce werd opgericht in 1987 onder de naam St. Paul Software. In 2000 verkocht het bedrijf zijn software-tak aan Tie Kinetix en richtte het bedrijf zich, onder de naam SPS Commerce (2001), op het aanbieden van internet gebaseerde Business-to-Business (B2B) gegevensuitwisselingen aan detailhandelaren en fabrikanten.

    🤔 Daarna volgde een reeks van overnames van bedrijven die B2B / EDI gerelateerde diensten en oplossingen bieden zoals Direct EDI, Edifice, CovalentWorks, Data Masons, GCommerce, InterTrade.

    🎆 Met als klap op de vuurpijl de overname van Tie Kinetix (TIE Kinetix is now SPS Commerce) in september 2023.

    Zie aankondiging: SPS Commerce Completes Acquisition of TIE Kinetix

    😎 Met de overname van de SAP B1 Technologietak van Vision33 breidt SPS Commerce zijn leiderschap op het gebied van full-service EDI met systeemautomatisering voor leveranciers en hun handelspartners verder uit. Vision33 SAP B1 Technologie stelt SPS Commerce in staat om zijn SAP B1-klanten volledig onder één dak te bedienen.

    “We zijn blij de SAP B1 SPS-integratiemedewerkers van Vision33 te mogen verwelkomen in ons groeiende team van retailmanagementexperts”, — aldus Chad Collins, CEO van SPS Commerce.

    “De complexe omgeving van vandaag betekent dat het voor retailers en leveranciers van cruciaal belang is om een veerkrachtige toeleveringsketen op te bouwen – en automatisering is daarbij een belangrijk onderdeel.

    Met het nieuws van vandaag hebben klanten van SPS en Vision33 toegang tot markt-leidende verbeterde retail- en systeemexpertise om de automatisering van hun workflows en bedrijfsprocessen te stimuleren, waardoor ze klaar zijn voor succes, wat de toekomst ook brengt.”

    Lees de aankondiging: SPS Commerce Announces Purchase of Vision33’s SAP Business One (SAP B1) SPS Integration Technology

    De Australische Freight Data Standard

    In september 2020 heeft de Australische Logistics Council (ALC) haar nieuwe Freight Data Standard gelanceerd. Deze standard borduurt voort op internationale standaarden zoals de GS1 Freight Labelling guides, GS1 EPCIS, GS1 SSCC, etc.

    Ik wordt vaak benaderd door bedrijven: van groothandels, fabrikanten tot retailers die op zoek zijn of gaan naar een Enterprise Supply Chain Management oplossing. Niet zomaar een ERP met WMS maar een omgeving voor ondersteuning van wereldwijde Supply Chain activiteiten.

    Het gaat dan gauw over complexe hybride Supply Chain architecturen waarover diepgaande kennis bij bedrijven niet aanwezig is, laat staan dat men de impact begrijpt. Gelukkig onderkennen (sommige) bedrijven dat zij business / logistieke / IT specialisten nodig hebben. In mijn netwerk zitten een aantal die voldoende kilometers hebben afgelegd en dagelijks hard bezig zijn de snelheid van innovatie bij te houden.

    ERP leveranciers van deze wereld zitten niet stil en komen elke maand met een nieuwe en meer mogelijkheden. En niche spelers, zoals Manhattan, door Gartner bestempeld als Leider in visie en uitvoeringsvermogen, zetten de trend.

    De SSCC Serial Shipping Container Code is zo'n staaltje van complexiteit. Vooral als het gaat over hoe krijg ik die data, die complexe verppakingstructuur (kan inclusief container zijn) in en uit mijn Enterprise - SC oplossing. Dat vraagt een sterk staaltje integratie over de hele keten en in het eigen bedrijf, een gedegen kennis van verpakkingstructuren, -data en tools. En als je naar het plaatje kijkt, dan hoor ik velen denken, hoe moeilijk kan het zijn!

    Niet makkelijk, tenzij je het al een keer gedaan heb van scratch - de definitie van de structuur, het DESADV / X12 856 bericht, de registratie van handling units, ...,/p>

    Ik zie de vraag naar uitgebreide WMS mogelijkheden de laatste jaren alleen maar toenemen, vooral bij bedrijven die global gaan. Nou heb ik de afgelopen maanden een aantal ERP oplossingen - Oracle NetSuite, SAP S/4Hana, D365 FSCM - onderzocht op tal van functionaliteiten en deze met elkaar vergeleken. En Ja, ze ontlopen elkaar echt niet veel, er zijn wel een paar kleine verschillen.

    Zoals op het gebied van verpakkingsstructuren loopt SAP S/4Hana sterk voorop. NetSuite heeft me echter aardig verrast met al haar functionaliteiten van OMS, WMS tot/met TMS. En Microsoft timmert hard aan de weg.

    Kostentechnisch, begrijp ik uit de markt dat Microsoft en SAP niet voor elkaar onderdoen. Naar de positie van NetSuite ben ik dan wel benieuwd.

    En bij the way: de documentatie van deze drie partijen is online beschikbaar - challenge jezelf, zoek het uit, en challenge je implementatiepartners.

    Tags: EDI, Supply Chain, EDIFACT

    Are you hesitating to implement P2P, O2C and eInvoicing with SAP?

    I often hear from companies that they have not been able to realize the intended objectives and cherished expectations from the ERP solution they implemented.

    This is especially evident in the number of activities still executed manually and the many labor intensive procedures designed to support the unique characteristics / processes of the company.

    Apparently the solution implemented did not match the company sufficiently.

    Seems in the preliminary phase too little attention was paid to identifying the real business requirements of the company and solving the existing organizational problems. We all - business experts - know you better not start an ERP implementation when there are too many organizational challenges lying around. Unfortunately there are still managers that believe they can use an ERP implementation as a lever to remove obstacles in the organization.

    But also in many cases the organization is / was insufficiently prepared, the right resources were not made available permanently, and deep insight in business processes and data flows was missing. The managers just left the implementation over to the implementation partner

    "Who is here to blame!"

    "Think it through before you start" is my motto. Often what I see is that the managerial involvement is limited to the kick-off of the implementation.

    Without leadership and involvement, every adventure ends in a personal drama. Vision, passion, conviction and trust are what companies need to be successful - and yes, a little luck helps too.

    Another important point of attention is that we should see automation as a continuous process of change. Go-live is the starting point for continuous small and medium improvements / changes.

    However, most companies usually do not reach this point because they made too many concessions during the implementation and the organization has been knocked down.

    electronic data exchange with customers, suppliers and between branches

    One of those continuous improvements is the establishment of electronic data exchange with customers, suppliers and between branches. I know from experience that this can bring huge savings. Sometimes up to a few FTEs yearly, although those FTEs do not really disappear, but can finally focus on providing added value for the customer, supplier or internal organization.

    Notwithstanding this positive outlook, I notice a lot of reluctance during conversations with companies. From a business point of view, they particularly are concerned about the consequences that increasing transparency can entail for their partners. And some companies are not at all interested in investing heavily in forming close partnerships.

    The biggest obstacles, however, are the technological complexity and the fear of compromising flexibility.

    Flexibility, a good excuse for companies that do not have their internal processes and data management properly in place. These companies lack structure and clear agreements. And rightly a good excuse because the success of these processes is largely determined by how well the internal data management is structured. Is there a good methodology for coding articles, materials and raw materials? For identifying partners and the different partner roles.

    The lack of digital integration facilities in ERP solutions is the most valid argument. Many suppliers of ERP solutions still struggle with whether or not to offer standard integration options. We can't get around it, for years, integration has been the cash cow of these suppliers and it's hard to say goodbye to it. By the way, this argument does not apply to all suppliers. A few - I'll name just a few - SAP, JDE, Oracle, MFG/Pro have been supporting O2C, P2P and product data data exchange processes for decades.

    True in the past years more and more solution providers started offering integration out of the box.

    the costs of technology and changes discourage companies

    Down the line the costs of technology and the changes to be made prevent companies from taking these steps.

    electronic ordering and invoicing at the purchasing side

    If we look at P2P / eProcurement, in particular electronic ordering and invoicing, companies do achieve significant cost savings and process improvements. For finance departments, the number of invoices processed without human intervention is a measure of efficiency of the invoice handling process - 'touchless accounting'. The aim is to process as many invoices as possible with fewer people.

    BUT Straight Through Processing (STP) provides much more insight. It is an indicator for the efficiency and maturity of the total purchasing process. The more the purchasing process is automated and information systems work together in an integrated manner, the more lead times and operational costs can be reduced, the less errors will be made.

    It will come as no surprise that this also applies to the processing of customer orders.

    And these are - in addition to increasing revenue by strengthening relationships with customers or suppliers - the savings incremental continuous improvements deliver.

    Why hesitate to put P2P and O2C on track ?

    Sure it costs money, we can all agree, but it pays off - better structured processes, improved internal data management, higher degree of Straight-Through processing (STP), strengthened relationships with internal and external partners, and for some companies it is no longer an option but an obligation.

    Since April 2019, Governments and Institutions are obliged to comply with the Regulation 2014/55/EU that states they must be able to receive electronic invoices. All companies that provide goods and services to them will have to send structured invoices electronically, now or in the near future.

    SAP as a backbone

    Assuming a company has SAP as a backbone, I dare to say that it is possible to connect a fairly high percentage of suppliers in a limited period of time by:

  • following a differentiated strategy where you provide multiple channels to present purchase orders and/or receive invoices including a supplier portal, direct integration (EDI) or integration through an intermediary
  • maintaining a clear strategy towards applying and using standards and agreements for the identification of products and locations, including GS1 GLN & GLN
  • using a limited set of data exchange standards and agreements, including PEPPOL, OASIS UBL, OAGI, ANSI X12
  • using standard SAP integration facility
  • follow a structured Supplier onboarding approach
  • What have we learned from the past years?

    Companies automating P2P and O2C processes have had less positive experiences in the past years due to:

  • lack of clear goals and demarcation of the scope of the project
  • outsourcing the implementation to a third party that favors a much too technical approach and pays too little attention to the collaborative processes
  • pressure of implementation-specialists for the use of customization because standard interfaces supposingly are not available or do not perform
  • low level of maturity of B2B integration partners and their solutions
  • My experience as a Project Manager of ERP and eProcurement / eCommerce projects is that solutions such as SAP, MFG/Pro and JDE have enough standard facilities BUT it does require that implementation specialists really dig deep into the solution to understand how it works and what the maker intended.

    From 2010 to mid 2015, I implemented P2P and O2C processes with technical wholesalers in the Netherlands / Europe (EDIFACT, UBL, PEPPOL, openTrans) for the Muelink & Grol Group and in the USA (ANSI X12) for Duravent.

    Honoustly I can tell from this experience that without much customization, the standard SAP IDOC interface can be your best friend, but only if you go really dig deep.

    SAP Cloud Platform Integration Suite

    Today, with the SAP Cloud Platform Integration Suite, integration has become even much more easier. The SAP Cloud Platform Integration Suite, residing in the Cloud, is SAP’s strategic integration platform as a service to simplify and accelerate the integration of SAP as well as non-SAP applications in heterogenous landscapes.

    I wrote an article in 2017 (SEE link below) about how the SAP eDocument Framework and PEPPOL simplifies eInvoicing and eProcurement with out-of-the-box functionality. Since then SAP only improved their offering by becoming a certified PEPPOL Access Point, which enables you to communicate directly out of SAP with your partners using PEPPOL.

    For a recent overview of the eDocument Solution go to the article on SAPSPOT (April 2018).

    But SAP is not the only one with an integrated integration solution

    JDE: In 2016 I have been working for Kaemingk, seasons decorations defining and setting up EDI integrations with a large number of European and US Wholesalers.

    QAD / Philips: My journey in eBusiness started here. We were ahead of time at Philips where we automated all communications between suppliers and customers using the Philips COPS standard and the back-to-back ordering functionality (QAD Enterprise Material Transfer). Read more about it in my articles "Ketenintegratie: hoe gegevens stromen doorheen een ecosysteem" en "Ketenintegratie, leuker en uitdagender kan werken niet zijn" (SEE links below).

    AND NOW, ROLL UP your sleeves

    Now the big question is when will you start with electronic data exchange with your customers, suppliers or between branches?

    More articles:

  • July 2020: Ketenintegratie, leuker en uitdagender kan werken niet zijn!
  • September 2018: Ketenintegratie: hoe gegevens stromen doorheen een ecosysteem ?
  • September 2018: PEPPOL BIS Post-Award Scenario's
  • June 2017: SAP EDI simplifies eInvoicing, eProcurement and eReporting
  • October 2016: Running O2C / P2P in and with SAP or any other ERP
  • July 2016: What processes add value for the customer?
  • February 2016: How EPCIS and RFID are changing E2E Visibility and Traceability in the Supply Chain
  • December 2015: Take the most sustainable responsible road to electronic invoicing!
  • Tags: EDI, ERP, PEPPOL, SAP, e-Invoicing

    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

    SAP EDI simplifies eInvoicing, eProcurement and eReporting

    Over recent years we see that internationaly, in Europe and nationally via Law and Regulations obligations arise to exchange information electronically with Business Partners, Public Administrations and Tax Authorities.

    Especially the savings at the side of the Government, the care for the environment and the fight against Tax fraud have led to these obligations. It is all about the use of specific electronic message standards for invoicing, purchasing, sales and reporting. Think about PEPPOL BIS UBL formats, the Italian FatturaPA XML, the Electronic Tax Document (DTE) in Chile and the increased usage of SAF-T in several European countries.

    The past years SAP started supporting companies that need to comply with all of these complex forms of data exchange with the SAP ERP option for eDocument processing - SAP ERP eDocument framework (SAP Note: 2378414).

    The SAP ERP eDocument framework supports the creation and handles the processing of outbound and inbound documents and provides users a comprehensive dashboard / Cockpit.

    This makes the implementation of eProcurement and eInvoicing a lot easier compared to using the SAP IDOC EDI interface. This is mainly due to the support of country-specific standards and message transport protocols.

    There are two versions available: the eDocument Full Solution and the eDocument Basic Enablement.

    For the basic version the purchase of the AIF Application Interface Framework is not needed, it is used under the hood.

    Moreover the SAP HANA Cloud Platform Integration service (HCI) is needed to handle the communication with external systems.

    The eDocument basic version has customer and country-specific interfaces.

    Think at following country-specific interfaces:

  • The use of the PEPPOL (Pan European Public Procurement Online) system of agreements and standards.
  • eInvoicing in Turky: the creation and processing of invoices in the obliged UBL-TR format.
  • eInvoicing in Italy: the creation and processing of invoices in FatturaPA XML.
  • eDocuments in Peru and in Columbia (description of the outbound and inbound eInvoicing process)
  • Electronic Tributary Documents (DTEs) (invoices, credit notes, debit notes and waybill) in Chili: these documents need to be sent to the Chilean Tax Autoriteit SII (Servicio de Impuestos Internos)
  • SAF-T (Standard Audit File for Tax Purposes - as implemented in a lot of countries (Poland, Portugal, Spain, Austria, Norway, Luxembourg, Hongary ...)
  • ..... and many more applications are available

    The eDocument framework of SAP makes it companies and Governments much easier to provide out-of-the-box the requested standards and protocols.

    Tags: EDI, ERP, PEPPOL, SAP, e-Procurement, e-Invoicing

    SAP EDI vereenvoudigt eInvoicing, eProcurement en eReporting

    We zien internationaal, in Europa en landelijk dat vanuit Wet- en Regelgeving de afgelopen jaren verplichtingen (zijn) ontstaan om gegevens in de keten van inkoop en verkoop elektronisch uit te wisselen met business partners, publieke administraties en Tax autoriteiten.

    Vooral de besparingen aan de kant van de Overheid, de zorg voor het milieu en het bestrijden van Tax fraude zijn aanleiding voor deze verplichtingen. Het gaat over het gebruik van specifieke berichtstandaarden voor facturatie, inkoop, verkoop en reporting. Denk daarbij ondermeer aan PEPPOL BIS UBL formaten, het Italiaanse FatturaPA XML, de Electronic Tax Document (DTE) in Chili en het toenemend gebruik van SAF-T in verschillende Europese landen.

    De voorbije jaren is SAP bedrijven die de aldus complexe vormen van gegevensuitwisseling moeten ondersteunen tegemoet gekomen met de SAP ERP optie voor eDocument verwerking add-on - het SAP ERP eDocument framework (SAP Note: 2378414).

    Het SAP ERP eDocument framework verzorgt de generatie en handelt de verwerking van de uitgaande en inkomende documenten netjes af en ondersteunt gebruikers met een overzichtelijke dashboard / Cockpit.

    Hierdoor wordt de implementatie van eInvoicing en eProcurement een stuk eenvoudiger dan bij het gebruik van de SAP IDOC EDI interface. Dit zit vooral in de ondersteuning van de land-specifieke berichtstandaarden en transportprotocollen.

    Er zijn twee versies beschikbaar: de eDocument Full Solution en de eDocument Basic Enablement.

    Voor de basis versie is de aanschaf van het AIF Application Interface Framework niet nodig, deze wordt wel gebruikt onder de motorkap.

    Verder is voor de communicatie met externe systemen de SAP HANA Cloud Platform Integration (HCI) service nodig.

    Bij de landspecifieke interfaces moeten we denken aan:

  • Het gebruik van het PEPPOL (Pan European Public Procurement Online) stelsel van afspraken en standaarden.
  • eInvoicing in Turkije: het genereren en verwerken van facturen in het verplichte UBL-TR formaat.
  • eInvoicing in Italië: het genereren en verwerken van facturen in FatturaPA XML.
  • eDocuments in Peru en in Columbia (beschrijving van het outbound en inbound eInvoicing process)
  • Electronic Tributary Documents (DTEs) (invoices, credit notes, debit notes en waybill) in Chili: deze documenten moeten verstuurd worden naar de Chileense Tax Autoriteit SII (Servicio de Impuestos Internos)
  • SAF-T (Standard Audit File for Tax Purposes - zoals geïmplementeerd in een aantal landen (Polen, Portugal, Spanje, Oostenrijk, Norwegen, Luxemburg, Hongarije ...)
  • ..... nog veel meer toepassingen zijn beschikbaar

    Het eDocument framework van SAP maakt het bedrijven en overheden veel eenvoudiger om out-of-the-box aan de gevraagde standaarden en protocollen te voldoen.

    Tags: EDI, ERP, PEPPOL, SAP, e-Procurement, e-Invoicing

    EDI implementation from Initiation to Go-Live

    For those considering (or already started) implementing EDI here are some friendly advices.

    "EDI is not something you (should) do overnight"

    "Your Business should adapt to e-Business"

    Your B2B or ERP solution provider will say "we will relieve you from all concerns"

    Read one of my other posts (in Dutch) about this relieve "Wij nemen u alle technische en functionele uitdagingen ( lees: problemen) uit handen en zorgen dat het goed komt"

    The approach that works and embeds EDI into daily business practice

    In a typical Order-to-Cash (O2C) process there are 4 business documents exchanged:
    - Purchase Order
    - Purchase Order Acknowledgement
    - Advanced Ship Notice
    - Invoice

    Additionally master data can be exchanged / synchronized between trading partners on a regular basis containing:
    - Product information
    - Price data
    - Product characteristics e.g. weights
    - Address locations

    [Want to know more about master data, read "Supply Chain collaboration - the battle for data".]

    The best scenario for implementing EDI business documents with partners consists of a phased-based approach. The overall goal of this approach is to realize a complete and smooth exchange of all agreed business documents and data.

    During each phase in the implementation scenario one business document is fully implemented. The implementation phases will overlap to ensure a continuous implementation process.

    Phase 0: contains master data alignment
    • product information (GTIN – UPC)
    • geographic locations (GLN – UPC)
    • price data
    • product characteristics

    Phase 1: implementation of order & order response

    Phase 2: contains implementation of shipping notification

    Phase 3: contains implementation of invoice

    Requirements analysis & agreement phase

    Before starting the implementation phases there is a requirements analysis and agreements phase during which following activities are performed:

    Collaboratively:
    1. Gather and analyze the EDI requirements (documents, data and process steps)
    2. Agree upon the business documents, the data exchanged and alignment of process steps
    3. Agree upon the communication protocol used
    4. Agree upon the implementation scenario

    Internally:
    5. Estimate the impact on a technical level (registration and processing of data)
    6. Estimate the impact on a business level (working instructions for order entry, invoicing and shipment)

    The joint deliverables of this phase are:
    - EDI Trading Partner Data Sheet
    - EDI Message Specifications
    - Agreed communication protocol
    - Agreed list of business documents, data exchanged and process steps
    - Agreed implementation scenario

    The internal deliverables of this phase are:
    - Technical impact: overview of issues and resolutions
    - Business impact: enhanced working instructions

    Implementation phases

    For each agreed business document the implementation will go through 3 stages:
    - Setup & test
    - Parallel processing
    - Consolidate

    To be successful the implementation of EDI need to be managed on a day-to-day basis and requires availability of several specialists: EDI Message expert, ERP integration and process experts and B2B Service Provider.

    Setup & Test Stage

    Technical activities:
    - Setup the connection with the EDI environment of the customer
    - Implement transformation mappings at B2B Service Provider
    - Test the connectivity with EDI environment of the customer
    - Verify the syntax and semantics of the EDI message(s) exchanged

    Business activities:
    - Validate the document created in ERP and check the working instructions
    - Agree upon procedures for handling and monitoring the exchange of the business document

    Deliverable(s):
    - B2B message mapping delivery
    - EDI connection both test and production
    - Agreed upon internal working instructions and external procedures

    Parallel stage

    During the parallel phase both business partners will check the completeness and correctness of the EDI-message for a period of 1 month.

    EDI documents are leading during this phase. Non-EDI documents are exchanged until both business partners are completely satisfied that the EDI system is performing well.

    Consolidate Stage

    During the consolidate stage it is important to gather all issues reported and measures taken and come to an agreement with the customer about the way forward.

    Organize a User Acceptance Meeting (UAM) with representatives of the customer and the internal organization. During this meeting finalize the list of issues reported and decide whether or not / when the message can go into operation. After the GO/NO Go decision start with the setup of the operational environment (master data, EDI connectivity, working instructions, …)

    As a last step before going live inform the organization formally when the EDI message will be taken into operation and what is expected of all people involved.

    Deliverables are:
    - User Acceptance Document
    - Updated issue and resolution list
    - Working EDI and ERP environment
    - Adapted working instructions

    Operation phase

    Activities to be performed are:
    - Monitor communications to ensure EDI documents continue to flow
    - Respond to inquiries from business partners as issues arise
    - Report on business partner activity
    - Make updates to translation maps and/or communication protocols as new documents are added

    Deliverables are:
    - Updated issue- and priority list
    - Performance overview report
    Number of messages received / sent
    Number of issues reported and solved
    Number of changes requested and performed

    My focus areas are business processes, business information systems (ERP, CRM, BPM, ...) and integration of business processes and systems over the boundaries of companies AND not to forget Open Source business applications.

    If you have an opinion about the implementation or use of EDI then do not hesitate to react. If you agree with the fundamentals then share it with others.

    Tags: e-Business, e-Invoicing, e-Procurement, e-Commerce, EDI

    Running O2C / P2P in and with SAP or any other ERP

    With the growing interest in sustainability, future-robustness and maneuverability buyers and sellers demand their business partners to increase collaboration, to become more agile and to contribute heavily in sharing data electronically. They see real benefits in automating their interactions with business partners.

    But although gains can be huge they do not come without a cost. So business partners are often very reluctant to jumping on this bandwagon. Moreover gains not always come in hard dollars but often manifest themselves in different ways - stronger bond with customers or suppliers - improved and aligned business processes - higher customer service. Business partners however not always see these gains to their advantage since they are more concerned about the costs of implementation.

    People / businesses often think establishing electronic data sharing and process collaboration is difficult to accomplish / requires much customization effort. A few years ago that was fully true but today we see that many ERP systems provide support out of the box.

    Some ERP systems provided that already for years - for example SAP, QAD, ... - If you are using SAP you have a wealth of functionality at your fingertips to make it work smoothly.

    There is a lot of documentation available online to get it done without years of experience in SAP. At least I learned to work and configure SAP without training - just in depth knowledge of business processes and occasionally some help is sufficient.

    But something you can not learn is what you want or need (business-wise) and how you want it. And as with everything in business, things do not happing overnight. You cannot go to the grocery and buy a cup of O2C or P2P and then poor it out over your Supply Chain.

    However with the right approach, the right people on board and willingness / commitment of your own organization and business partners will get it up and running in a few months.

    BUT ONLY when you have your data and processes aligned with proven business practices.

    Data alignment

    Data alignment is about talking the same language as your business partners. Ensure your products, your locations, your delivery and payment conditions are understood.

    SAP provides a lot of ways to set up cross references with your internal language and the language of your business partners such as translation of partner address codes and products. Even without customization most of the data provided in electronic documents can be stored for replication later in the process.

    I dealt with complex data requirements of large wholesalers and retailers without having to build new forms or extend tables. OK Yes! some user exits - hooks into the standard SAP functionality - had to be used to change the behavior slightly.

    But a lot (you) can (do) be done by adopting GS1 Global Location Numbers (GLN) or D&B D‑U‑N‑S Number, and GS1 Global Trade Item Number (GTIN) - the EAN codes or Universal Product Code (UPC). And also implement standardized delivery terms (Incoterms) and payment terms.

    Supporting product data classification - on the other hand - is still a major issue. The classification system of SAP is not equiped for handling the product data models of UNSPSC, ETIM, GS1 GPC. Manual setup is unfeasible due to the increased changeability of these models. That is where others tools are really needed to complement SAP.

    Process alignment

    How difficult can it be to align processes! There are a lot of reference models available for different industries:

    SCOR Framework APQC's Process Classification Framework®(PCF) Business Process Framework (eTOM)

    But yes, these are too generic! And we may not forget that each company has unique characteristics. That is why there is a lot to do before you are able to use these reference models.

    What about simple models? Like these for goods and services processes.

    Here you see the documents that are exchanged between buyers and sellers as well as the internal activities that happen to process or generate these documents. And for product manufacturers you see we talk about deliveries. While for companies delivering services it can be a combination of both models.

    Now aligning business processes is not something you do inhouse. It requires sitting together with your business partners and go through all the scenario's you share. Then put them all in a decent process modeling tool, herewith generating already a part of the documentation for future use. Thereafter decide together which processes are good candidates to start with.

    See for example: the quote-to-cash process of a bike manufacturer.

    Or the process of an OEM manufacturer:

    Common sense is the most important aspect here, you do not have to be an architect or IT specialist. You just have to talk business! That is difficult enough.

    But apart from using standard SAP functionality, is there another way?

    There are integration tools out there that can act as intelligent buffer for the outside world and your internal environment. Model-driven tools that not only help you collaborate with your business partners but also enable you to build some small extensions to your SAP system.

    These tools help businesses that unfortunately or luckily do not have SAP but some other ERP.

    See my post: Integration essential for online retailers

    Let me know if you are intested in learning more about how you can establish business-to-business collaboration with your partners.

    Tags: EDI, ERP, PEPPOL, SAP, e-Procurement, e-Invoicing, e-Ordering

    Is 'ontzorgen' het toverwoord van de huidige ICT dienstverlener?

    En gelooft u dat dienstverleners u gaan ontzorgen?

    Begrijpt u hoe / wanneer / waarmee / waarom ?

    Hoe vaak heeft u in het afgelopen jaar aanbieders van oplossingen of diensten (in de Cloud) horen roepen "Wij gaan u ontzorgen!" ?

    Misschien wilt u deze vraag liever niet beantwoorden! Dat is uw goed recht. Toch is het goed - het lucht op - om af en toe uw ervaringen te delen met anderen en hen te behoeden voor teveel vertrouwen in de zin "Wij gaan u ontzorgen!".

    Voor beleidsmakers en beslissingsnemers is het woord "ontzorgen" het toverwoord om hen over de streep te helpen. Het hoort bij het standaard sales jargon voor het sluiten van deals.

    Als intermediair heb ik beslissingsnemers van bedrijven weleens gevraagd hoe deze ontzorgd wilde worden en of uit het aanbod van een leverancier viel op te maken dat dit zou gaan gebeuren.

    Wat is ontzorgen ?

    Zoek maar eens de Engelse vertaling op bij linguee.nl.

    U vindt dan verschillende vertalingen van Nederlandse zinnen met daarin het woord ontzorgen van vooraanstaande Nederlandse bedrijven. Dit hoeft weinig toelichting maar toch - enerzijds: er is geen echt Engels woord voor ontzorgen in de context zoals deze vaak in een Nederlandse zin wordt gebruikt, een beperkt aantal bedrijven gebruiken de woorden burden of unburden maar dat klinkt dan veel minder professioneel; anderzijds: zie je dat in het Engels de bedrijven wat duidelijker vertellen wat ze doen of wat ze beloven.

    Of Google eens naar de zin 'Ontzorgen in de ICT' en u vindt zomaar een paar uitspraken van IT bedrijven:

    "Wij zorgen dat u goed kunt slapen en dat uw medewerkers of business partners meteen geholpen worden wanneer er een probleem is"

    "Wij ontzorgen en stellen klanten centraal."

    "Uw probleem is ons probleem. Wij helpen u graag door u te Ontzorgen."

    SAMENVATTEND:

    Wij nemen u alle technische en functionele uitdagingen ( lees: problemen) uit handen en zorgen dat het goed komt.

    De woorden "Alle" en "Het" schijnen het verschil te maken voor verantwoordelijken binnen bedrijven.

    Het antwoord van bedrijven op de vraag over ontzorgen

    "Ze hebben gezegd dat ze ons op alle gebieden gaan ontzorgen en beloven dat alles vlekkeloos gaat werken." Dat was het antwoord dat ik van beslissingsnemers kreeg. Waarop ik reageerde - in aanwezigheid van beoogde aanbieders - 'ontzorgen tot aan de deur'. Wat niet ontkent noch bevestigd werd maar achteraf wel bewaarheid werd.

    De essentie is dat aanbieders uitgaan van hun eigen interne kracht, de systemen of applicaties die ze aanbieden en die ze door en door kennen. Ze veronderstellen dat bedrijven over eenzelfde interne kracht beschikken. Beiden kunnen elkaar alleen maar versterken waarna het ontzorgen kan beginnen.

    Ontzorgen lijkt voor aanbieders alleen betrekking te hebben op de situatie na implementatie. De invoering van een oplossing zelf valt schijnbaar buiten het ontzorgingsgebied.

    Wij (ikzelf en een aantal anderen) zijn van mening dat ontzorgen begint bij het eerste gesprek.

    De drempel tussen twee of meer omgevingen is vaak veel hoger dan het beeld dat betrokkenen daarvan hebben en daarom moet vanaf het begin gestreefd worden naar duidelijkheid. De drempel gaat over 'weerstand', 'interpretatieverschillen', 'ontbrekende gegevens', 'gebrek aan kennis en ervaring', 'onduidelijke bedrijfsprocessen' en nog veel meer. U kunt hier vast nog wel een aantal drempels bij verzinnen.

    Belangrijk is te weten hoe het met uw interne kracht gesteld is: zijn uw processen op orde, zijn uw mensen flexibel en capabel om veranderingen aan te gaan, heeft u uw data huishouding goed voor elkaar, kent u uw business partners wel voldoende.

    De vraag is uiteindelijk wie gaat wie (wie allemaal) en wanneer ontzorgen en wie heeft nog heel wat huiswerk te verrichten.

    BELANGRIJKER NOG:

    "hoe wilt u ontzorgd worden?"

    Een vraag die wij = ikzelf en een aantal anderen, graag beantwoord zien. Met deze antwoorden willen we bepalen waar bedrijven behoefte aan hebben. Maar vooral of dit aansluit bij wat wij denken en willen aanbieden.

    De vraag aan u:

    Hoe wilt u ontzorgd worden in volgende gevallen en wat hebt u daarvoor over:

    - wanneer u Cloud oplossingen in gebruik neemt voor bepaalde bedrijfsprocessen

    - wanneer u belangrijke transactiegegevens, denk aan orders, facturen, producten, leveringen met uw klanten of leveranciers wil delen

    - wanneer u kiest voor een best-of-breed of hybride architectuur-landschap (hybride = combinatie van best-of-breed bestaande uit on-premise en in-the-cloud applicaties)

    - wanneer u bedrijfsprocessen wil automatiseren

    Mijn aandachtsgebieden zijn bedrijfsprocessen, bedrijfsinformatiesystemen (ERP, CRM. BPM, ...), integratie van bedrijfsprocessen en systemen over de grenzen van bedrijven EN niet te vergeten Open Source bedrijfsapplicaties.

    Als u een mening of visie heeft over het omgaan met veranderingen aarzel dan niet om deze hier kenbaar te maken. Als u zich kunt vinden in het artikel of de herkenning groot is dan deel het met anderen.

    Tags: BPM, EDI, ERP, ETIM, GS1

    A glimp into the future of e-invoicing

    Vision on electronic invoicing (business) in the future
    The most important theme on the agenda of companies and government bodies at this moment is electronic invoicing. Many companies see electronic invoicing as an instrument to realize cost savings and to improve the socially responsible undertaken - image. Not always will electronic invoicing lead to cost savings but generally it is assumed it will.

    My advice is to conduct a thorough investigation of the impact on the organization, systems, applications, processes and information. Such a study should provide a view on the vision on electronic invoicing within the company and deliver information for drawing up the Business Case. Do not forget Electronic Invoicing is part of the end-to-end trade process (Electronic Business). The study will have to mind the overall trade process including purchase-to-pay and order-to-cash.

    In addition Electronic Business refers to Exchange Services (exchange of messages) between customers and suppliers. An activity that takes place in the Exchange Domain, the domain area with focus on interoperability and not on the purchase and sales process.

    Based on several investigation and implementation projects combined with extensive study of technological developments and innovative business concepts a vision emerged on the future of Electronic Business, more specific Electronic Invoicing.

    “My vision on Electronic Invoicing is of an electronic business highway located in the cloud above us.”

    My vision on Electronic Invoicing is of an electronic business highway in the cloud above us. Emerging technologies and growing electronic business networks are shaping the future of Electronic Business into an open an intelligent information service highway wherein Electronic Invoicing fits as a tiny little exchange instance that enables smart and fast reach to connected partners.

    Actually I mean that intelligent instances on the electronic business highway make it possible to exchange information and establish processes to work together with others that are also using the highway. Companies will focus more and more on the reason of their existence and move core-functions like generate and send, receive and process invoices to the outside or transfer to third parties whom are specialized therein.

    The electronic business highway will become a shielded area of the Internet or another IP-network comparable to Internet telephony (Voice over IP). The electronic business highway will be an open and for everyone accessible instance that is in no way identical to the Value Added Network (VAN) from the EDI age.

    Three possible scenario's for the emergence of the electronic business highway
    It is my expectation that the emergence of the electronic business highway will follow the same scenario's as developed by the World Economic Forum for the Digital Ecosystem. The Digital Ecosystem is about the digital space - the convergence between IT, Telecommunications, Media and Entertainment - where users evolve from mere consumers to active participants and governments face major policy and regulatory challenges.

    Full version: Digital Ecosystem Convergence between IT, Telecoms, Media and Entertainment: Scenarios to 2015

    Three scenarios are developed to gain a better understanding of the possible outcomes of the Digital Ecosystem in the near future. These scenarios deal with answers around two critical questions that influence the realization and adoption of the electronic business highway.

    Firstly, will social and economic value creation be industry controlled and led, or organic and community-led. Secondly, will the digital business environment evolve toward a more open or closed system.

    To the year 2015 three possible roads will be followed to arrive at the Digital Ecosystem:

    1) Safe Havens describes a digital world in which the industry plays an important role and responds by vertically integrating to create secure walled environments that provide all digital services and is based on closed standards.

    2) Middle Kingdoms describes a digital world in which consumers, governments and forward-looking businesses push for interoperability, enabling the emergence of a Digital Ecosystem dominated by intermediaries that effectively connect users to like-minded individuals and highly specialized suppliers that can best meet their needs. In the middle of the space between consumers and suppliers lie the kingdom where the power lies.

    3) Youniverse describes a digital world in which the rise of organic grassroots communities as powerhouses of economic value turns traditional business thinking on its head. This leads to the rise of new organizational structures and to digital experiences that are highly personalized. This digital world will mainly be based on common standards and open systems. The line between users and producers will be further blurred as open source supporting software and collaborative community structures become more sophisticated.

    Who is going to build the electronic business highway ?
    The electronic business highway will evolve from safe havens to middle kingdoms whereby governments, communities and/or market sectors will play an important role in the realization of the superhighway. It is clear that in the coming years not everyone need to start building its own electronic business highway but that one umbrella highway will emerge to which every enterprise and existing electronic business (invoicing) network (e-hub) can connect.

    It will still take several years before we are that far but this highway will surely be established. Currently suppliers of e-business (invoicing) networks already are confronted with questions from customers to connect trading partners that are not on their network.

    Much attention arise for the phenomenon roaming that a number of players in the domain area define as “Roaming is interconnecting networks to provide real cross border reach, in a way that an operator can reach another operator’s users directly, nationally and internationally”.

    In other words realizing the interoperability between the e-business (invoicing) networks, the régime of fees that form the basis for the usage of each others services / networks and the way the taxation takes place to the customer / client. Universal reach for clients is one of the most important drivers to realize interoperability between networks and will ultimately lead to a network of networks AND something or someone will in time grab the role of super administrator.

    When are you ready for the electronic business highway ?
    Many around us have presumably been thinking about going for gmail, yahoo-mail or live-mail abandoning their own e-mail server. A number of companies will take this step in the coming years. In my opinion the predominant argument is “why pull in complexity when others can do it better and cheaper”. I believe that in the near future G-invoicing or Y-invoicing or M-invoicing has much possibility to be successful. Yahoo, Google and Microsoft have the power-to-execute and are able to realize the dream of the electronic business highway.

    Why pull the complexity of Electronic Invoicing into your own organization and systems when the only goal you have is “send, receive and process invoices” ? Electronic Invoicing is non-intrusive, in fact the invoicing process will not be hampered, and around us there are strong players that made Electronic Business their core-competence. Perhaps you ask yourself when you will be ready for Electronic Invoicing and where you stand at this moment. The evolution path of Electronic Business (e-Business) provides a notion on the growth and future of Electronic Invoicing.

    “Technology is shaping the future e-invoicing world” and demands a growing understanding of technology, standards, data security and control. It should be clear to everyone that Electronic Business goes through a shift from “tightly coupled to loosely coupled systems” .

    From left below to right above Electronic Business evolves from Traditional to Synchronization.

    1) Traditional: phone, fax, EDI and paper
    Paper is still the most important medium for the transmission of an invoice while e-mail has taken up a strong position for the exchange of product information and order data. However the amended European regulations will strongly stimulate the use of e-mail in the next coming years.

    Electronic Data Interchange, in the last years became synonym for the exchange of documents via Value Added Networks based on non-XML standards such as EDIFACT and ASC X12. Especially international companies and certain industry sectors have embraced EDI in the past although this not always leaded to the desired success. Nevertheless Electronic Data Interchange For Administration, Commerce and Transport (EDIFACT) is still heavily employed in the automotive and retail industry.

    2) Communication: e-mail, online web presentment
    Invoices - like other documents - will be transmitted using e-mail in PDF or other format but at the same time Electronic Invoice Presentment solutions are further being implemented. These solutions enable us to present invoices in HTML format in a personalized environment. In addition it is possible to download the invoice in different formats. The said means of communication distinguish themselves in the way the invoice is offered to the customer. When using e-mail the invoice is send to the customer - push-mechanism - while when using online presentment a pull-oriented approach is followed. The customer receives a notification message, e-mail or sms, when there is an invoice available that can be downloaded.

    3) Integration: XML standards and web-oriented architectures
    The rise of the eXtensible Markup Language (XML) drifted the world of Electronic Business more apart. This seems a contradiction to those that scream XML is the Esperanto of the future. However the different industry-specific XML-based vocabularies that have been developed (OAGI, UBL, PIDX, CIDX, RosettaNet, ...) the past years lead to the well-known interoperability question, the lack of information (data) interoperability. These XML-vocabularies define business information-elements in the context of the industry as such that everyone can understand and process them. The XML-language takes care of defining the structure and the industry-specific methodology for modeling and representing the semantics, the meaning of the information elements.

    In the EDIFACT era industry-specific subsets were developed to further restrict the number of data elements. The basis for these subsets is/was the EDIFACT syntax and semantics as defined in the EDIFACT directories (libraries).

    The XML-vocabularies on the other hand are based on different methodologies (semantics) and have different structures (syntax). Ultimately these create the luxury problem that most companies wrestle with, “the business standards dilemma”. Enterprises are not able to make a choice between the multitude of standards.

    Standardization is one of the biggest hurdles for global adoption of Electronic Business (invoicing) but not the end of Electronic Business. The interoperability question is in fact about systems and people not having a common understanding of the meaning of the underlying data because there is no shared grammar and library on which the meaning is based.

    A few international initiatives are started that should lead to one universal grammar library:
    - The UN/CEFACT Core Components Technical Specification (CCTS) is a syntax-neutral methodology for the development of a common set of semantic building blocks of information-elements. The Core Components Technical Specification is based on the ISO Standard 150000-5 (ebXML Core Components Technical Specification ebCCTS). More information can be found on the website of SAP, the driving force behind the CCTS, under Message Definition Languages.

    - The Open Group Universal Data Element Framework (UDEF) is a method for categorizing information-elements by means of an alphanumeric key (tag) and assigning a simple name to an element.

    Those initiatives will not directly solve the interoperability question because none of these will be implemented on short notice in all the available XML-vocabularies. The luxury problem will continue to exist for a while.

    4) Collaboration: a process-centric approach stimulated by business processes that interact using standardized B2B protocols containing message-formats, transport protocols and business process management components.

    This stage of Collaboration where companies apply all kinds of integration to realize Electronic Business goes through interconnected networks. Especially the e-business (invoicing) networks that support the exchange of messages between trading partners constitute the most important link in this stage.

    5) Synchronization: pure peer-to-peer networks that have no central control and where data gets replicated. Further away in the future Ecosystem oriented architectures will evolve. This stage in the evolution path will not obtain the required level of maturity in the next few years to enable major adoption.

    What influence do distribution models have ?
    The last years several distribution models emerged or were identified by institutions. For simplicity I will identify four models whereby the difference is mostly based on the position of the trading partners.

    1) Seller Direct Model
    In this model the seller is the dominant party and makes the invoice available to customers via an online presentment environment, web-portal, in different formats (EDI, XML, CSV, PDF, ...). Invoices can also be transmitted in PDF format via e-mail.

    The model is most appropriate from the perspective of the seller because of the opportunity to tighten the connection with customers (vendor lock-in), at the same time the seller can recommend more products and services (cross- and up selling) and strengthen its brand name. Moreover the invoice has the same look-and-feel as the paper invoice.

    2) Buyer Direct model
    In this model the buyer is the dominant party and forces the supplier to enter or deliver the invoice via the online environment or via EDI / XML.

    The model is most appropriate from the perspective of the buyer because of the opportunity to tighten the connection with suppliers (buyer lock-in) and reduce the administrative burden when the seller delivers the invoice in a standardized format in the online environment. When this online environment is integrated with the financial system the buyer is able to automatically process the invoice. More benefits can be achieved if the sellers retrieve the purchase orders from the same online environment and also confirm delivery dates and pricing.

    The choice for one of these distribution models is partly determined by the bargaining or market power, and the desired wish of flexibility of involved parties. When the power is concentrated in the begin of the supply chain, on the selling side, the result will most often be a Seller Direct model while a dominating customer result in a Buyer Direct Model. Both models benefit from a limited number of standards and transport protocols, leading the highest possible interoperability.

    Soon or later both customers and suppliers are confronted with the digital spaghetti architecture.

    This structure evolves from the growing number of point-to-point connections and requires increasing efforts to connect new trading partners.

    The Seller and Buyer Model in time will not increase the reach of trading partners and certainly not when buyers and sellers are faced with strong dominating partners. For most small and medium-sized companies, but also for dominating buyers and sellers willing to establish electronic business the Consolidator Model is the best fit and less intrusive.

    3) Consolidator model
    In the consolidator model a third party, a service provider, facilitates the exchange of documents between sellers and buyers providing various exchange services among web-enabled presentment environments and all kind of methods and standards for exchanging messages.

    This model is most appropriate for small and medium-sized companies because the provider takes the complexity of different electronic standards out-of-their hands. There is a one time costs for connecting to the network of the consolidator and a transaction or monthly fee for the use of the service depending on the agreements made.

    The main advantage for enterprises lies in the speed of connecting a large group of partners that already use the network of the consolidator. Especially when the service provider is running an extensive network of companies in the same market sector. Such an e-business (invoicing) network can be decisive in the choice of a service provider.

    A provider who understands the problems in an industry sector is able to respond faster and provide additional services closely related to the business domain. For example in the world of Telecommunications and Utilities (energy, water,waste) Expense Management Solutions will add significant value to connected users.

    The increasing number of e-business (invoicing) networks requires extra efforts from these network operators (consolidators) to ensure reach of trading partners over these networks. This gave rise to the networked environments (multiple connected hubs). The networked environments enable hub-owners to respond quickly to requests for exchanging messages with partners that use another network.

    The network operators are now facing the same challenges that originally, not so long ago, gave birth to the e-business (invoicing) networks and are still the main reasons for their existence. E-business (invoicing) networks need to ensure widespread interoperability and interconnectivity to better serve - and keep on serving - senders and receivers.

    Main aspects to address are cross-network addressing and routing, (message) content standards and transformation rules (format conversion), authenticity of origin and integrity of content. Answers are needed for questions such as how can a sender and receiver be uniquely identified, which message standard or grammar will be used as the common library, and how to ensure authenticity of origin, integrity of content and security.

    Currently e-business (invoicing) network providers are tackling these questions by establishing bilateral agreements to ensure interoperability and interconnectivity. The Hub Alliance, an affiliation of Business-to-Business e-Trading Service Providers (or ‘hubs’) who have implemented a ground breaking initiative to interconnect different hubs ensuring that electronic trading is easier for all the hub users. Participants are a few of the big players in Europe: Certipost, Basware, Burns Business Exchange, Liaison, Causeway and Asite.

    The Alliance was established to enable hub-to-hub interoperation and to encourage the wider use of electronic messaging between businesses. Members are currently prohibited from charging additionally for documents that are processed between hub members. Message standards, communications protocols, service levels and responsibilities are all defined by the membership and are intended to be as broad as possible to encourage the ease and speed of interconnectivity.

    4) Four Corner model
    The last model is the Four Corner model where the banking world will take care of the exchange of invoices between customers and suppliers. The already mentioned benefits of a consolidator apply and additionally banks provide possibilities to directly issue the payment of an invoice. There is not yet a working example of this model but it probably will not take years.

    Mapping the distribution models on the evolution path ?
    Now that the distribution models passed the revue let us look on how these models are plotted on the evolution path.

    Some valuable and informative business and technological considerations to take into account.
    Small, medium-sized and large companies should carefully investigate the business models and technologies of available solutions and service providers. The current e-business (invoicing) service providers are coming from many different backgrounds. Some players literally are involved in the gaming industry like B2Boost, the leader in transaction management.

    Others rolled into the game of e-business and e-invoicing because paper-based invoices in the future are no longer an option:
    - Output and Document Management Solution providers: StreamServe, Bringing Documents to Life, and Bottomline Technologies.

    - Document and Information Logistics companies: TNT Post, the Dutch mail and logistic company, Certipost, the former Belgian Post company and Itella Corporation, formerly the Finland Post Corporation.

    Even companies that have been providing B2B and EDI solutions for ages are Jumping on the Bandwagon of the e-business (invoicing) networks: Axway, Tie Commerce and SEEBURGER.

    What all of these players have in common is that during the past years they developed solutions for solving the lack of interoperability between their clients with the objectives to reduce the amount of spaghetti. These solutions are based on different architectures, standards and types of software.

    Two architectural approaches are generally followed:
    1) Firstly, the use of a Common Information Model as the backbone for the solution.

    The standards and models from clients are transformed into the common information model in the middle which is mostly based on a proprietary standard. Data is stored in a relational database or in an XML file system or database.

    2) Secondly, the digital spaghetti structure is transferred into the solution

    The existing point-to-point connections between trading partners are restated in the solution. There is no common information model and the power resides in the transformation capabilities of the underlying software. For each information flow between supplier and customer two transformation mappings are developed.

    Not the most cost effective and efficient approach to solve the lack of interoperability between trading partners. As long as these providers can live up to their promises and ensure 100% client satisfaction this approach will work.

    Will XML solve the business standards dilemma ?
    Once again it is a misunderstanding that XML is the solution, the Esperanto of the future. Some people even say XML is just plain text and does nothing. XML was created to structure, store and transport information. The XML-language takes care of defining the structure, the syntax, and the industry-specific methodology for modeling and representing the semantics, the meaning of the information elements.

    The biggest challenge for all of us is solving the lack of interoperability between XML-based vocabularies and EDI libraries. True global electronic data interoperability requires more than an XML-based vocabulary.

    For establishing global electronic collaboration and information exchange there must be a common understanding of the underlying data, the semantics of business information elements should be based on a standardized grammar, commonly available for everyone.

    Many industry consortia and standardization committees have defined specific XML-based vocabularies. All of these vocabularies are based on different methodologies for representing the semantics of the business information elements. As such similar information elements in vocabularies are designed and named differently. This makes it hard to automatically translate these elements from one vocabulary to the other instead a mapping definition is required.

    Due to the many XML-based vocabularies this becomes difficult and expensive, often identified as the business standards dilemma.

    Standardization of the Content is not the breaking stone. It is not about speaking the same language but about understanding what we speak. Therefore standardization should focus on grammar, transformation rules and tools as such that both humans and machines are able to understand and work with it.

    Initiatives that have been launched are:
    - the UN/CEFACT Core Components Technology Specification (ISO 15000-5 ebCCTS)
    - the Open Group Universal Data Element Framework

    Adoption and incorporation of the UN/CEFACT CCTS methodology is agreed upon by most international standards committees but real cross-use of core components is not yet visible. Furthermore the UN/CEFACT CCTS is becoming a bit too complex with the extensive object-oriented approach propagated by the UN/CEFACT standardization committee.

    Nevertheless it is the best initiative available at this moment and when the focus is brought back to the right perspectives, simply grammar, things will work out fine. The best architecture for an e-business (invoicing) network solution that has no problem with the business standards dilemma in the communication with other networks looks as follows:

    This will also be the underlying architecture framework for the electronic business highway.

    Will the electronic business highway fulfill the interoperability requirements ?
    First of all it is imperative that the electronic business highway provides access to all sending and receiving trading entities and allows for inclusion of different e-business (invoicing) network providers.

    Moreover there are common and open technology standards needed for message content and transport protocols including transformation and/or format conversions. These could best be based on a shared grammar and library such as the UN/CEFACT Core Components Technology Specification. These standards should be globally available to everyone without restriction and cost, or for a reasonable fee, ‘en principe’ no enterprise should feel excluded.

    On top of these requirements enterprises need a smooth transition path from their existing integration approach to the new vibrating driving-experience on the electronic business highway. This demands ease of use, the ability to accommodate different existing and new solutions and free choice of service provider.

    The road to Middle Kingdoms requires ‘government’ policies promoting innovation and competition, measures to encourage the industry to voluntarily contribute their best technology and to participate in the development of open standards.

    Governments on a pan-European and international level with support of international standardization committees need to develop Common User Identifiers for addressing that are portable across Europe, similar to telephone numbers, open and independent from a service or network need to be developed. Two initiatives to mention are: the OASIS Customer Information Quality Technical Committee (OASIS CIQ TC) and the eGreen Pages Association.

    The OASIS CIQ TC develops a set of XML specifications for defining, representing, interoperating and managing “PARTY (Person or Organization) CENTRIC INFORMATION” that are truly open, vendor neutral, industry and application independent, and importantly “Global” (ability to represent international data formats such as different types of party names and addresses used in 241+ countries).

    Basware and Itella Information Oy are establishing a centralized directory containing messaging profiles and electronic addresses of ebusiness partners used for automated discovery and pairing of partners and routing of messages. The Open Initiative for Global Address Book in B2B Messaging - eGreen Pages - will be run by an open, non-profit e-invoicing operator association.

    Is there a Business Case for e-business (invoicing) ?

    Stay on board, more will come in a few days

    Tags: EDIFACT, EDI, Interoperability-Frameworks, UBL, UDEF, e-Invoicing

    [Last update: 26-11-2011]