E-business platform bouw- en installatiesector Eindrapport

Transcriptie

1 E-business platform bouw- en installatiesector Eindrapport Auteurs : Lars de Laat, Ali Sassi Bedrijf : Garansys Versie : 1.4 Datum : 14 oktober 2013

2 Inhoudsopgave 1 Inleiding Managementsamenvatting Advies Optimalisatie elektronische communicatie Huidige problematiek Antwoorden op de onderkende problemen Sector-brede hub De sector over een hub als oplossing Randvoorwaarden hub Conclusies en advies Conclusies Advies Bijlage A: Workshop-opzet en uitkomsten A.1 Workshop aannemers en installateurs A.2 Workshop groothandel en fabrikanten A.3 Workshop ERP leveranciers Bijlage B: Toelichting concept hub Eindrapport E-business platform bouw- en installatiesector

3 1 Inleiding In de bouw- en installatiesector wordt steeds meer gebruik gemaakt van elektronische berichtuitwisseling (EDI) volgens de Voor de uitwisseling van elektronische orders, orderbevestigingen, pakbonnen en facturen wordt veelal gebruik gemaakt van . Ook andere uitwisselingsvormen van web services komen voor. Tevens komt er een groeiend aantal serviceproviders die (een deel van) de uitwisseling van elektronische berichten faciliteren. Dit kan leiden tot verschillende berichtformaten en meer kans op fouten alsmede hogere kosten voor het realiseren van koppelingen. Vanuit de achterban van in de Bouw/ETIM & 2BA is de laatste tijd steeds vaker de vraag gekomen naar de mogelijkheden rond een onafhankelijk e-business platform voor de uitwisseling van berichten (verder: hub). De diverse problemen rond berichtenverkeer werden hierbij als voornaamste reden gegeven. Om deze wens te toetsen en om vast te stellen aan welke eisen een dergelijke hub zou moeten voldoen is onder begeleiding van Garansys een workshopserie georganiseerd met een afvaardiging uit de bouw- en installatiesector. Dit rapport beschrijft de terugkoppeling uit de branche en het advies dat in de bouw, 2BA en Garansys hieraan verbindt. Eindrapport E-business platform bouw- en installatiesector 1

4 2 Managementsamenvatting Vanuit de achterban van in de Bouw/ETIM & 2BA is de vraag ontstaan welke positieve bijdrage een onafhankelijk e-business platform (hub, zie bijlage voor een schematische weergave) voor de uitwisseling van berichten heeft binnen de branche. Dit adviesrapport geeft antwoord op de volgende hoofdvragen. 1. Is er daadwerkelijk behoefte aan een gecentraliseerde hub binnen de branche? 2. Aan welke voorwaarden dient een hub te voldoen? 3. Dient gebruik gemaakt te worden van één aanbieder van een hub of meerdere? Voor het achterhalen van de behoefte van de verschillende partijen in de branche zijn een drietal workshops gehouden. Deze workshops zijn opgedeeld in de drie groepen; Groothandel en fabrikanten, Aannemers en installateurs, ERP leveranciers. Alle partijen zijn bezig met integratie van hun IT-systemen met leveranciers en klanten. De complexiteit van de koppelingen verschilt binnen de branche. Zo zijn er partijen die nog bilateraal koppelen en er zijn partijen die al een toepassing hebben van een eigen (in-house) hub. De belangrijkste problematiek die door de diverse partijen naar voren wordt gebracht betreft de grote hoeveelheid verschillende koppelingen die gemaakt moeten worden, het werken met verschillende versies van de berichtenstandaard, interpretatieverschillen binnen de berichtenstandaard, het kunnen ondersteunen van berichtenstandaards uit aanpalende branches en het af kunnen leveren van berichten wanneer een partij niet (elektronisch) bereikbaar is. De aannemers en installateurs en ERP leveranciers zien de voordelen van het implementeren van een sectorbrede hub. De meerderheid van voornamelijk de grotere groothandel en een enkele fabrikant zien geen voordeel in het implementeren van een sector-brede hub. Deze laatste groep heeft al geïnvesteerd in een eigen in-house hub met de bijbehorende koppelingen naar hun belangrijkste klanten. Het inzetten op een hub is alleen een haalbare oplossing als voldoende partijen uit de hele keten hieraan meewerken. Als we kijken naar de terugkoppeling op de vraag of partijen zich aan zouden sluiten bij een hub wanneer deze eenmaal gerealiseerd is, zien we dat er een breed draagvlak is. Ook partijen die geen eigen voordeel zien zouden aansluiten overwegen. De omvang en daaraan gerelateerde kosten zijn hierbij een belangrijke factor. Een uitzondering hierbij vormt de grotere groothandel, die aangeeft niet mee te willen doen met dit initiatief. 2.1 Advies Wij adviseren om de efficiëntie in de elektronische communicatie te vergroten door een sector-brede hub te implementeren. Een gecentraliseerde hub leidt tevens tot een nog betere adoptie van de berichtenstandaard van in de bouw. Deze hub zou aangeboden moeten worden door één hub-provider, vanuit de branche georganiseerd, via een constructie zonder winstoogmerk. Daar het voordeel voor de aannemers en installateurs het grootst is, adviseren wij dat deze groep trekker wordt van het initiatief tot het implementeren van de hub in de branche. Eindrapport E-business platform bouw- en installatiesector 2

5 3 Optimalisatie elektronische communicatie 3.1 Huidige problematiek In alle workshops is de probleemstelling rondom de huidige elektronische communicatie besproken. Hierna volgen de problemen die op dit moment ondervonden worden in de elektronische communicatie door de verschillende partijen: 1. Veel verschillende (soorten) koppelingen maken en onderhouden 2. Interpretatieverschillen over de standaarden die er zijn (zelfs binnen de zelfde versie) 3. De standaard kent twee versies: de actuele en de voorlaatste. Beide worden onderhouden, maar er zijn partijen die nog voorgaande versies gebruiken. 4. We hebben te maken met berichtenstandaards uit aanpalende branches 5. Er treden problemen op met berichtafhandeling bij partijen die niet bereikbaar zijn Alhoewel er overeenstemming is over het feit dat de elektronische communicatie efficiënter kan verlopen, bleek in de workshops dat de impact verschillend beleefd wordt en dat er over de oplossingsrichting duidelijk verschillende ideeën bestaan. 3.2 Antwoorden op de onderkende problemen Bij het bepalen van de antwoorden is ook gekeken hoe dit binnen andere branches is opgelost. Over het algemeen is het antwoord op deze problemen in andere branches: Onderkend probleem Veel verschillende koppelingen Veel verschillende koppelingen, versies van de standaard, berichtenstandaards uit aanpalende branches Veel verschillende koppelingen, berichtafhandeling wanneer partij niet bereikbaar is Interpretatieverschillen binnen de standaard Oplossingsrichting Terugbrengen van het aantal berichtformaten bij voorkeur tot één standaard maar vaak een beperkt aantal (denk aan huidige en de versie daarvoor). Branche-brede transformatie inrichten (via een hub) Centrale hub als communicatieknooppunt Testportaal wat toegankelijk is voor iedereen; na aanmelding kan een partij een koppeling tot stand brengen, controleren of een berichtformaat voldoet. Uit de workshops kwamen de volgende oplossingsrichtingen naar voren vanuit de deelnemers: Sector-brede hub implementeren (eventueel met transformatie) Sterker promoten van één berichtenstandaard Eindrapport E-business platform bouw- en installatiesector 3

6 4 Sector-brede hub Vanuit vragen die bij in de Bouw/ETIM & 2BA binnen kwamen over een centraal e-business platform is het gesprek met de sector gestart met de vraag of een sector-brede hub een verbetering in de elektronische communicatie zou opleveren die voor alle partijen interessant is. 4.1 De sector over een hub als oplossing In de workshops is aan alle aanwezigen gevraagd of een sector-brede hub voor hen voordelen biedt in het streven om de elektronische communicatie te verbeteren. Omdat een hub verschillende functies kan vervullen en sommige functies meer gewenst kunnen zijn dan andere, is in de bespreking van de hub apart gekeken naar de verschillende functies die een hub voor de sector zou kunnen vervullen (zie onderstaande tabel). De functies lossen ieder andere delen op van de probleemcomponenten zoals beschreven in paragraaf 3.1. Functies van de hub Hub-vorm/functionaliteit Gericht op Probleemcomponent Basis postkantoor Eenvoudig distribueren naar meerdere partijen (minder 1 soorten koppelingen maken en onderhouden) + buffering Gegarandeerde aflevering 5 + validatie berichten Afleveren van bericht met juiste syntax 2 + transformatie Ondersteunen van meerdere formaten met omzetting 2, 3, 4 naar S@les-ETIM standaard + aangetekend Beveiligd afleveren (afgeschermd voor de buitenwereld) randvoorwaarde Voordelen en nadelen van een hub Uit de workshops bleek dat bij de aannemers, installateurs en ERP leveranciers de hub (in verschillende vormen) door alle aanwezigen als een gewenste oplossing werd gezien. Dit was veel minder het geval bij de groothandel en fabrikant. Een nagestuurde vragenlijst over het voordeel van een sector-brede hub levert het volgende beeld op: Eindrapport E-business platform bouw- en installatiesector 4

7 (*) Scores op basis van antwoorden van 6 aannemers / installateurs, 4 groothandels / fabrikant en 7 systeemhuizen. Dit overzicht geeft een bevestiging van het beeld dat uit de workshops naar voren kwam: aannemers, installateurs en ERP leveranciers verwachten veel voordeel te hebben van een sector-brede hub, terwijl groothandel en fabrikant in meerderheid geen voordeel verwachten. De volgende belangrijke voordelen van het hebben van een centrale hub zijn genoemd: Besparingen (hogere doelmatigheid) o Niet het wiel steeds opnieuw uitvinden o Lagere onderhoudskosten o Neemt werk uit handen van softwareleveranciers o Software hoeft minder formaten en protocollen te ondersteunen Snellere implementatie elektronische communicatie afnemer-leverancier mogelijk Eén communicatiekanaal je kunt verwijzen naar een centrale hub Standaard wordt beter nageleefd De volgende belangrijke nadelen van het hebben van een centrale hub zijn genoemd: Een hub introduceert extra kosten Een hub verdoezelt het niet gebruiken van de standaard (indien de hub transformatie verzorgt) Een hub creëert een extra schakel waar we afhankelijk van worden Hierbij moet aangemerkt worden dat in de groep groothandels / fabrikant het aansluiten van nieuwe partijen als een minder groot probleem wordt ervaren. Dit lijkt voort te komen uit (een combinatie van): Het aansluiten beschouwen als een gewenst contactmoment met een klant Veel verkeer loopt nu via andere kanalen (web shop) Partijen hebben zelf al een vorm van een hub geïmplementeerd waardoor het aansluiten vergemakkelijkt is Eindrapport E-business platform bouw- en installatiesector 5

8 Participatiebereidheid We hebben ook de bereidheid getoetst van partijen om zich aan te sluiten bij een sector-brede hub mocht dit initiatief opgepakt worden. De uitkomsten daarvan zijn als volgt: Hieruit blijkt dat de meerderheid van de respondenten zou participeren aan een sector-brede hub, onder de voorwaarde (voor partijen die weinig of geen voordeel zien) dat deze hub in een minimale vorm wordt uitgevoerd met minimale of geen extra kosten tot gevolg. Partijen die voordeel zien van een sector-brede hub geven de voorkeur aan een functioneel breder vormgegeven versie. 4.2 Randvoorwaarden hub Met die partijen die een sector-brede hub als oplossing beschouwen is dieper ingegaan op de randvoorwaarden waar een eventueel te realiseren hub aan zou moeten voldoen. Punten die naar voren zijn gebracht: De hub dient in de branche georganiseerd te worden via een constructie zonder winstoogmerk Eindrapport E-business platform bouw- en installatiesector 6

9 De branche moet invloed houden op (de ontwikkeling van) de hub (hierbij is de suggestie naar voren gebracht om met meerdere leveranciers te gaan werken). Kostenmodel zodanig dat het interessant is voor kleine en grote bedrijven (basisbedrag vs bedrag per bericht) o Vooral voor kleine partijen is een instap-fee vaak een te grote drempel De vertrouwelijkheid van de berichten moet goed geborgd zijn De hub moet een hoge beschikbaarheid hebben S@les in de Bouw wordt het common data format in de hub o Er moet een mechanisme zijn in (de dienstverlening van) de centrale hub waarmee het breder implementeren van de berichtenstandaard wordt ondersteund (bijvoorbeeld hogere kosten als er een transformatie plaats moet vinden). Eindrapport E-business platform bouw- en installatiesector 7

10 5 Conclusies en advies 5.1 Conclusies Verschillende meningen in één keten Opmerkelijk is dat verschillende partijen in de keten een duidelijk andere mening hebben over hoe hun elektronische communicatie verbeterd kan worden. Er is een duidelijke tweedeling te herkennen met de meerderheid van de aannemers en installateurs en ERP leveranciers die voordelen zien van het implementeren van een sector-brede hub en een meerderheid van voornamelijk de grotere groothandel en een enkele fabrikant die geen voordeel zien in het implementeren van een sector-brede hub. Voor deze laatste groep geldt dat zij al hebben geïnvesteerd in technische koppelingen naar hun klanten en leveranciers. Het inzetten op een hub is alleen een haalbare oplossing als voldoende partijen uit de hele keten hieraan meewerken. Als we kijken naar de terugkoppeling op de vraag of partijen zich aan zouden sluiten bij een hub wanneer deze eenmaal gerealiseerd is, zien we dat er een breder draagvlak is. Ook partijen die geen eigen voordeel zien zouden aansluiten overwegen. De omvang en daaraan gerelateerde kosten zijn hierbij een belangrijke factor. Ook hier geldt dat de grotere groothandel aangeeft niet mee te willen doen met dit initiatief. Sector brede hub vs. basis hub Partijen die veel voordeel zien van een hub hebben voorkeur voor een hub met veel functionaliteit (sector brede hub) terwijl partijen die geen of weinig voordeel zien van een hub alleen iets zien in een hub met minimale functionaliteit (basis hub) waar geen of minimale kosten mee gemoeid zijn. Sector brede hub functionaliteit, die door de meeste voorstanders wordt gevraagd: Basis postkantoor, met Buffering van berichten Validatie van berichten Transformatie van en naar de standaard Garantie op vertrouwelijkheid en versleuteling van berichten Basis hub functionaliteit, gezien door de partijen die weinig voordeel zien in een hub en alleen aansluiten bij een minimale versie (als ze zich al aan zouden sluiten): Basis postkantoor alleen doorgeef luik van berichten Buffering van berichten Garantie op vertrouwelijkheid en versleuteling van berichten Het is belangrijk om na te gaan of en waar er een omslagpunt is rond de kosten / en kostenmodel en de bereidheid van de groothandel om mee te doen. Eindrapport E-business platform bouw- en installatiesector 8

11 Voor wat betreft de ondersteuning van transformatie is hierbij een belangrijk discussiepunt naar voren gekomen: hoe werkt een sector-brede hub in op het streven om binnen de sector met één standaard berichtenformaat te gaan werken? Een goede reden om deze transformatiefunctionaliteit toe te voegen aan de hub is dat daarmee partijen aan de elektronische communicatie deel kunnen nemen die (op korte of langere termijn) niet in staat zijn om volgens de standaard te communiceren. Daarbij komt van de ERP leveranciers overigens wel de aanvulling dat zij bij veel aansluitingen met leveranciers (ook bij de grote) toch altijd weer tegen kleine varianten van de standaard aanlopen. Dat is dus juist waar zij vanaf willen. De vrees is echter dat dergelijke functionaliteit de prikkel zal wegnemen om naar de standaard te gaan. Dat kan eventueel worden ondervangen door in de kostprijs mee te nemen dat partijen die voldoen aan de standaard minder betalen dan partijen die juist behoefte hebben aan deze transformatie. Hiermee zou een stimulans kunnen ontstaan om de standaard eerder te adopteren. Eigendom van de hub De meeste partijen die voordelen verwachten van een sector-brede hub, stellen dat deze vanuit de branche georganiseerd dient te worden via een constructie zonder winstoogmerk. Hierbij zijn verschillende mogelijkheden benoemd, zowel voor de realisatie als het beheer van een hub. De branche kan als contractpartij optreden en de realisatie en het beheer van de hub overlaten aan 1 of meer geselecteerde leveranciers. (volledige aan- en uitbesteding) De branche kan een branche-organisatie selecteren of opzetten die de realisatie en het beheer van de hub voor haar rekening neemt. (Realisatie en exploitatie in eigen beheer) De branche kan als contractpartij optreden voor de realisatie van de hub en vervolgens het beheer voor haar rekening nemen via een branche-organisatie (te selecteren of op te zetten). (Realisatie aanen uitbesteed; exploitatie in eigen beheer) Eén of meerdere hub aanbieders Door deze discussie heen speelt nog de vraag of de branche nu voor één of meerdere hubs zou moeten kiezen. Er zijn partijen die verwachten dat de innovatie lager is en het risico op ongewenste vendor lock-in hoger wanneer er maar één hub-leverancier is. Er zijn ook partijen die verwachten dat de standaarden makkelijker worden losgelaten wanneer er meerdere aanbieders zijn. Alle partijen zijn het echter over eens dat het doel moet zijn om naar meer standaardisering te komen. Dit pleit in eerste instantie voor één aanbieder van de hub waarbij het risico op vendor lock-in afgevangen moet worden. Dit is overigens goed te realiseren door in de aanbesteding heldere eisen en een gelimiteerde periode neer te leggen en een contractvorm te kiezen waarbij de macht in handen blijft van de branche. Eindrapport E-business platform bouw- en installatiesector 9

12 Kosten van de hub De kosten van de hub vallen uiteen in de volgende posten: Kosten aanschaf hub software (bijv. Biztalk, Sonic, Tibco, Websphere, WSO2, etc.) Eenmalige inrichting van de architectuur binnen de hub Hardware eventueel in cloud oplossing Exploitatie: o Instandhouding, oplossing incidenten o Aanpassingen / innovatie o Aansluiting van individuele partijen (inrichten transformaties / mappings) Men zou een maximalisatie van de opbrengst kunnen afspreken met de partij die de hub exploiteert, indien men ook een prijs per bericht model hanteert. Het kostenvoordeel dat optreedt wanneer meer partijen zich aansluiten moet in elk geval voor een deel terugvloeien naar de gebruikers. Voor de financiering zijn modellen te overwegen op basis van: Aansluit-fee Abonnement Kosten per bericht Alle drie te variëren met een basis tarief en een opslag voor partijen waarvoor maatwerk dient te worden verricht. Eindrapport E-business platform bouw- en installatiesector 10

13 5.2 Advies Het is duidelijk dat meerdere partijen bezig zijn om een (in house) hub of een vorm van een hub te implementeren. Dit zorgt nog steeds voor veel bilaterale werkzaamheden. Partijen hoeven alleen hun eigen aansluiting met de hub te regelen. Wanneer een partij is aangesloten kan hij op basis van identificatienummer eenvoudig communiceren met nieuwe leveranciers of klanten. Het bericht voldoet immers al aan de standaard en de koppeling is al gerealiseerd. Het koppelen gebeurt één keer en wordt meerdere keren gebruikt. Wij adviseren om de efficiëntie in de elektronische communicatie te vergroten door een sector-brede hub te implementeren met de volgende kenmerken: Scope De hub moet minimaal als basispostkantoor fungeren. Met minimaal bedoelen we dat partijen ervoor kunnen kiezen om zich aan te sluiten bij een basisvorm van de hub. Daarnaast zou de hub buffering, validatie en transformatie moeten aanbieden voor partijen die daar behoefte aan hebben. Techniek Technisch stellen we de volgende randvoorwaarden aan de hub: Standaardisatie op actuele en laatst voorgaande versie van in de bouw en installatie. Partijen die dat zelf ook gebruiken vallen daarmee automatisch in een basis tarief. Zekerheid / continuïteit: o de te kiezen technologie dient proven te zijn o het systeem dient bij een ernstige fout (niet functioneren) te kunnen schakelen naar een back-up omgeving vice versa o de hub dient voorzien te worden van pro-actieve monitoring Schaalbaar: niet alleen op hardware niveau waar de hub op draait, maar juist de processen binnen de hub. Auditable: de gekozen oplossing dient door een onafhankelijke partij ge-audit te (kunnen) worden op beveiliging Breed inzetbaar: beschikbaar hebben van diverse adapters; Excel, SAP, ASCII, EDI, EDIFACT, Toekomstgericht: Cloud ready & proven Laagdrempelig: voorzien van portaalfunctionaliteit waar partijen hun eigen berichtenverkeer kunnen controleren Opmerking bij testportaal: bijvangst van deze functionaliteit is dat dit voor beginnende partijen een logisch startpunt vormt om koppelingen te ontwikkelen waardoor het gewenst berichtformaat automatisch gekozen wordt. Vanuit technisch oogpunt adviseren wij om één hub te kiezen beheerd door één partij. Meerdere hubs leidt tot: inzichtverschillen en daarmee formaatverschillen verhoogde inrichtingscomplexiteit indien berichten over meerdere hubs moeten (wat het geval zal zijn als sommige partijen aangesloten zijn op hub 1 en andere partijen op hub 2) Eindrapport E-business platform bouw- en installatiesector 11

14 lagere beschikbaarheid door afhankelijkheid van meerdere schakels in de communicatie (voorbeeld: twee hubs met ieder een beschikbaarheid van 98% brengen de ketenbeschikbaarheid terug naar 96%). Juridisch Wij adviseren om de realisatie en het beheer van de sector-brede hub uit te besteden aan één gespecialiseerde (ICT-)partij. Deze dient via een aanbestedingsproces geselecteerd te worden waarbij bijzonder veel aandacht moet worden gegeven aan de mogelijkheden van de sector om invloed te houden op de ontwikkeling en toegepaste prijsmodel van de hub. Financieel Het prijsmodel van de hub zou zodanig opgebouwd moeten worden dat het: tot minimale kosten leidt voor partijen die de basisvorm van de hub gebruiken. basis tarief oplevert voor Partijen die werken met INSBOU (actuele of laatst voorgaande versie). Alle anderen krijgen de kosten voor omzettingen doorbelast in hun tarief. Hiermee moet ook de verdere adoptie van INSBOU worden gestimuleerd voor partijen met laag volume tot lage of geen vaste kosten leidt (prijs bij gebruik) voor partijen met hoog volume ook interessant blijft (staffels / afkopen met vaste fee) Om tot een definitief prijsmodel te komen dient onderzoek gedaan te worden in andere branches. Vervolgstappen Daar het voordeel voor de aannemers en installateurs het grootst is, adviseren wij dat deze groep trekker wordt van het initiatief tot het implementeren van de hub in de branche. Eindrapport E-business platform bouw- en installatiesector 12

15 Bijlage A: Workshop-opzet en uitkomsten In drie workshops met: 1. Aannemers en installateurs 2. Groothandel en fabrikanten 3. ERP-leveranciers voor bouw en installatie Is de vraag Heeft de sector behoefte aan een centrale hub-functionaliteit? besproken. Waar het antwoord ja luidde is ook de vorm en de rol van de sector besproken. Bij nee is er over mogelijke alternatieven gesproken. De workshops hadden plaats op bij Syntens in Nieuwegein, met de volgende deelnemers: 16 mei, aannemers en installateurs: Bastiaan de Bevere Siem Buitelaar Thomas Kraan Björn Smeets Alex Knechten Marcel Linssen Joost Cremers John Vink Peter Zwakhals BallastNedam BAM Coöperatieve Inkoopvereniging DGC u.a. DuraVermeer HVL KWS Van Dorp dienstencentrum bv Weboma Uneto-VNI 17 mei, groothandel en fabrikanten: Henk Peter van Hagen Johanna Mansvelder Chi Shing Chang Cees Trip Eddy Geurts Remko Pottinga Willem Siebelink Ron Kessels Bruni Giebels Gerard Kamsteeg Henk van Leussen Robert Landman Michan Katerbarg Marc den Dobbelaere CRH Destil Jongeneel Leeuwbouw Oosterberg Pont Meyer Rensa St.Gobain Stiho Technische Unie Van Buuren Veris Wavin Zevij Eindrapport E-business platform bouw- en installatiesector 13

16 23 mei, ERP-leveranciers: Jules Hollebrandse Anders Bartels Dick Eskes Henk Koops Hugo Vonk Leon Stok Jeroen Ingberg Peter van de Sande Hans Walrave Gert-Jan Gelderblom Ron Hardenberg Dorus Stoop Rienk Niewland Vincent van Mourik Robert Landsman 4PS Bartels Centric Compano Gilde Kraan Kraan MSG Syntess Unit4 Unit4 Unit4 Van Meijel Van Meijel Veris Eindrapport E-business platform bouw- en installatiesector 14

17 A.1 Workshop aannemers en installateurs Herkent deze groep de probleemstelling dat de huidige wijze waarop het elektronische berichtenverkeer in de sector is georganiseerd leidt tot een onoverzichtelijke situatie met kans op fouten en/of onnodige kosten? Ja. Is er in deze groep behoefte aan een centrale hub als oplossing voor dit probleem? Ja. Wat zijn de voordelen van een centrale hub? Leidt tot minder koppelingen en daarmee minder onderhoud Standaard berichtenformaat is beter af te dwingen, waarmee een bredere implementatie van de standaard tot stand komt Continuïteit van het berichtenverkeer is beter te organiseren (beter 1x goed vanuit breed initiatief dan veel lokale initiatieven) Zijn er nadelen aan een centrale hub? Als er één hub ontstaat is de marktwerking beperkt. Dit kan de innovatie beïnvloeden en brengt een risico van afhankelijkheid met zich mee. o Te onderzoeken optie: beperkt aantal hubs die samenwerken Randvoorwaarden / obstakels van een hub: In de branche organiseren via een constructie zonder winstoogmerk Hoge eisen aan continuïteit Kostenmodel zodanig dat het interessant is voor kleine en grote bedrijven (basisbedrag vs bedrag per bericht) Partijen moeten bekend zijn / een GLN identificatie hebben De vertrouwelijkheid van de berichten moet goed geborgd zijn De volgende functionaliteiten van een hub zijn besproken: Basis postkantoor : berichten juist afleveren Valideren van binnenkomende berichten Berichten transformeren in formaat Buffering van berichten Ondersteunen van versleuteld berichtenverkeer Aangetekend versturen NIET: verrijken van gegevens ( geen manipulatie met data in de hub ) Hoe zou een vervolg eruit moeten zien? Vanuit de brancheorganisaties uitwerken van de mogelijkheid om het in de markt te beleggen met één of beperkt aantal (2-3) voorkeursleveranciers óf het helemaal in de branche beleggen. Eindrapport E-business platform bouw- en installatiesector 15

18 A.2 Workshop groothandel en fabrikanten Herkent deze groep de probleemstelling dat de huidige wijze waarop het elektronische berichtenverkeer in de sector is georganiseerd leidt tot een onoverzichtelijke situatie met kans op fouten en/of onnodige kosten? Ja. Is er in deze groep behoefte aan een centrale hub als oplossing voor dit probleem? Nee. Alternatieve oplossingen die naar voren zijn gebracht: Huidige afhandeling van elektronisch verkeer kan efficiënter en zekerder. De routes die besproken zijn: Berichtstandaard verder implementeren oplossing zoeken richting ERP leveranciers en eigen implementatie o Suggestie: volledige aanbieding vanuit S@les in de Bouw richting branchepartijen om zo de implementatie van de standaard te vergroten, bestaande uit recht op gebruik standaard + gecertificeerd softwarehuis voorstellen die adapter levert naar standaard in de branche Communicatie standaardiseren (hiervoor loopt al een werkgroep web services ) Zorgen voor gegarandeerde aflevering (kan ook afgevangen worden via de route van web services) Zo min mogelijk financiële drempels introduceren Genoemde argumenten waarom een centrale hub hiervoor geen oplossing is: Een hub lost de kern niet op; de kern is dat de standaard niet wordt gehanteerd Een hub introduceert extra kosten (berichtafhandeling / hub moet gefinancierd worden) De functionaliteit hebben we goeddeels zelf al geregeld Veel kleine afnemers gaan via onze webshops Principiële beslissing: we willen geen klant-specifieke informatie zoals condities, nettoprijsinfo e.d. over een tussenschakel We willen zo min mogelijk afhankelijk zijn van andere partijen (hub introduceert een extra afhankelijkheid) Hoe zou een vervolg eruit moeten zien? Het grootste deel van de groep heeft voorkeur voor een focus op bredere implementatie van de berichtenstandaard in de branche. Hiervoor wordt het idee geopperd om partijen hier beter in te begeleiden / sturen door ze een pakket aan te bieden van recht op het gebruik van de standaard, gekoppeld aan een advies voor een pakket met adapter. Verder wordt veel verwacht van de ERP leveranciers. Zij moeten de standaard oppakken en implementeren. Eindrapport E-business platform bouw- en installatiesector 16

19 A.3 Workshop ERP leveranciers Herkent deze groep de probleemstelling dat de huidige wijze waarop het elektronische berichtenverkeer in de sector is georganiseerd leidt tot een onoverzichtelijke situatie met kans op fouten en/of onnodige kosten? Ja. Waar lopen jullie / jullie klanten tegenaan bij het ondersteunen van de berichtuitwisseling tussen afnemers en aanbieders? Interpretatieverschillen van inhoud van berichten / velden Partijen in de markt volgen de standaard niet (na-ijlen) Partijen aan de rand / buiten de branche waarmee uitwisseling nodig is Grote leveranciers en bouwers maken gebruik van pakketten waarin de standaard niet wordt ondersteund Verschillende uitwisselingsprotocollen in de markt Is er in deze groep behoefte aan een centrale hub als oplossing voor dit probleem? Ja. Genoemde voordelen van een centrale hub: Vanuit leveranciersoogpunt: we hoeven dan minder connectoren te realiseren. Genoemde randvoorwaarden / obstakels: We zien teveel partijen die niet aan willen haken en / of willen investeren (leveranciers/fabrikanten en kleine aannemers/zzp-ers) De kosten moeten zeer laagdrempelig zijn vooral voor kleine partijen is een instap-fee vaak een te grote drempel S@les in de Bouw wordt het common data format in de hub Er moet een mechanisme zijn in (de dienstverlening van) de centrale hub waarmee het breder implementeren van de berichtenstandaard wordt ondersteund (bijvoorbeeld hogere kosten als er een transformatie plaats moet vinden). Hoe zou een vervolg eruit moeten zien? Het grootste deel van de groep gelooft in een stap voorwaarts richting een hub vanuit een kopgroep die een positieve business case kan realiseren met een centrale hub. De verwachting is dat een groot deel van de branchepartijen volgt indien een dergelijk initiatief in productie is. Eindrapport E-business platform bouw- en installatiesector 17

20 Overige kanttekeningen: De vraag is hoe lang het duurt tot de markt zelf de problematiek in de communicatie opgelost heeft (door verdere standaardisatie / web services). Daarmee is het de vraag hoeveel tijd we winnen met een hub-initiatief uit de branche. Op het vlak van berichtenuitwisseling tussen aannemers en onderaannemers is meer te winnen dan tussen aannemers en leveranciers. Op het eerste vlak is nu nog weinig geregeld en gaat veel mis. Van Meijel heeft samen met KWS Infra een hub ontwikkeld. Deze zou beschikbaar gemaakt kunnen worden voor de branche (KWS heeft dit afgedwongen in de overeenkomst met Van Meijel). Eindrapport E-business platform bouw- en installatiesector 18

21 Bijlage B: Toelichting concept hub De hub kan vertaald worden als een postkantoor dat berichten tussen verschillende partijen aflevert. Termen die gebruikt worden in de IT-markt voor deze oplossing zijn o.a. Middleware, ESB (Enterprise Service BUS), Portal. In dit document zullen we verder de term hub gebruiken. De technieken die men in de markt hiervoor ziet zijn o.a. Microsoft Biztalk, Sonic, Tibco, Mule ESB, IBM Websphere en WSO2. De hub is een architectuur die ontwikkeld is om de communicatie tussen partijen te vereenvoudigen en te standaardiseren. Een hub bevat een aantal functionaliteiten en componenten die hier verder worden toegelicht. We beperken ons hierbij tot de functionaliteit en componenten die in de scope passen van het voorgestelde onderzoek. Routeren; het afhandelen van berichten en routeren naar de juiste ontvanger Interfaces; de hub kan meerdere interfaces leveren; voorbeelden hiervan zijn webservices en SMTP ( ) Transport protocollen; de hub kan meerdere (beveiligde) transport protocollen voorbeelden hiervan zijn HTTP(S), FTP, REST, SOAP, JSON. Beveiliging; de beveiliging kan naast op protocol ook op de hub zelf geregeld worden middels authenticatie/identificatie (gebruiker/wachtwoord) Queuing; tijdelijke berichten opslag (queue) indien afnemer van het bericht niet verbonden is; garantie dat berichten niet kwijtraken tijdens transport. Transformatie van berichten; de hub kan berichten in een bepaald formaat transformeren naar het formaat wat de ontvangende partij verwacht. Voorbeeld zijn CSV bericht transformeren naar bijvoorbeeld XML bericht Schaalbaarheid; indien nodig kunnen bepaalde componenten van een hub opgeschaald worden zodat de performance, stabiliteit en continuïteit gewaarborgd blijven. Foutafhandeling; het afhandelen van foutieve (syntaxis) berichten. Het inzetten van een hub wordt pas nuttig indien er meerdere partijen zijn die met elkaar communiceren. Indien een partij maar één of enkele koppelingen heeft met andere partijen zou een bilaterale koppeling (één op één) ook kunnen voldoen. Uiteraard dient men bij de keuze dan zelf zaken als foutafhandeling, beveiliging, interfaces zelf te ondervangen en te onderhouden. Eindrapport E-business platform bouw- en installatiesector 19

22 Schematische weergave HUB Eindrapport E-business platform bouw- en installatiesector 20