TKI project ‘4C in Bouwlogistiek’ WP2.1 Controltower Datumm:
14 mei 2015
Auteur(s)
Alexander de Vries Ricardo Rinsma Marcel Ludema
Aantal pagina's Aantal bijlagen
35 (incl. bijlagen) 3
WP2.1 Controltower
| 14 mei 2015
3 / 28
Inhoudsopgave 1
Samenvatting ........................................................................................................... 4
2
Inleiding .................................................................................................................... 6
3 3.1 3.2 3.3
De bouwlogistieke controltower ............................................................................ 8 Afstemming van bouwlogistiek met de bouwlogistieke controltower ......................... 8 Informatie en ICT als afstemmingsmechanisme ....................................................... 9 Afstemming van bouwlogistiek ................................................................................ 11
4 4.1 4.2 4.3 4.4 4.5
Opbouw van de bouwlogistieke controltower .................................................... 15 Inrichting van bouwlogistieke processen ................................................................. 15 Operationele bouwlogistieke processen .................................................................. 17 Aansturing van het bouwlogistieke proces .............................................................. 21 Bouwlogistieke informatie ........................................................................................ 23 Bouwlogistieke KPI’s ............................................................................................... 25
5
Aanbevelingen voor vervolg ................................................................................ 26
6
Bibliografie ............................................................................................................. 27 Bijlage(n) A Informatie inputs en outputs operationele logistieke bouwplaats processen B Definities informatie beschikbaar in het bouwproject C Prestatie-indicatoren voor project 4C in bouwlogistiek
WP2.1 Controltower
1
| 14 mei 2015
4 / 28
Samenvatting Het doel van dit rapport is het definiëren van een bouwlogistieke controltower en een kader op te stellen, waarbinnen de afstemming en informatievoorziening plaatsvindt op strategisch, tactisch en operationeel niveau. Een controltower is een regiecentrum van waaruit verschillende logistieke ketens gezamenlijk gecoördineerd worden. De bouwlogistieke controltower richt zich op afstemming in de bouwlogistieke keten, waarbij de focus ligt op een aantal gekozen proeftuinprojecten. Om een controltower te ontwerpen, zal eerst inzicht verkregen moeten worden op welke manier afstemming en informatievoorziening plaatsvindt in de bouwsector. Thompson (1967) geeft aan dat activiteiten binnen een bouwproces wederkerig afhankelijk zijn, wat betekent dat outputs van verschillende partijen inputs voor andere partijen bepalen. Dit zorgt voor problemen in de keten, die veroorzaakt worden bij de overgangspunten tussen verschillende organisaties of stappen in de bouwlogistieke keten (Xue, e.a., 2007). Elk bedrijf heeft zijn eigen werkwijzen, hulpbronnen en doelen, waardoor de werkwijzen in het project uitgelijnd moeten worden. In de huidige situatie wordt dit niet aangepast, aangezien bedrijven vaak projectmatig met elkaar samenwerken voor de duur van een bouwproject. Een bouwlogistieke controltower heeft betrekking op de operationele processen vanaf de voorraad van bouwmaterialen bij de leverancier (het klantorder ontkoppelpunt) tot de plaats van verwerking van de producten op de bouwplaats. De controltower richt zich op de materiaalstroom en de bijbehorende informatiestromen. Met behulp van een bouwlogistieke controltower kan in het voorbereidend proces worden geadviseerd over de inrichting van het logistieke netwerk voor bouwmateriaal van toeleveranciers naar de bouwplaats (-en). Voor de inrichting van het netwerk kan gebruik worden gemaakt van de huidige referentiebibliotheek en een nog verder te ontwikkelen beslissingsondersteunend bouwlogistiek rekenmodel. De typologische kenmerken van gebouwen bepalen welke bouwlogistieke optimalisaties theoretisch mogelijk zijn. Hiertoe kunnen scenario’s worden opgesteld die met het nog verder te ontwikkelen of een andere rekenmodel kunnen worden doorgerekend. Nadat het logistieke netwerk is ingericht kan de inrichting van de supply chain plaatsvinden. De basisprocessen die plaatsvinden in de bouw zijn relatief standaard logistieke processen, die ook in andere branches breed geaccepteerd zijn. Een uitzondering hierop is dat in de bouwlogistieke processen de specifieke planning van de aanvoer van materieel een belangrijk onderdeel is van de dagelijkse praktijk. Daarnaast is er geen sprake van een vaste verwekingsplaats van bouwmaterialen. Dit kan overal in de supply chain plaatsvinden. Om een bouwlogistieke controltower in te richten, dienen naast de standaard logistieke processen ook de retourstromen gecoördineerd te worden. Daarnaast kan er sprake zijn van het direct aanleveren van bouwmaterialen op de bouwplaats door een leverancier dan wel bij de poort of bij een opslaglocatie of op de daadwerkelijke plek van verwerking in het bouwproject.
WP2.1 Controltower
| 14 mei 2015
5 / 28
Operationele supply chain processen worden aangestuurd met informatie. Elke procescategorie heeft informatie inputs en outputs om het uiteindelijke werk uit te kunnen voeren. De belangrijkste outputs worden gevormd door de bouwplanning, voorraadbeheer en transportplanning. Het rapport beschrijft een ideaalbeeld met betrekking tot de afstemming in de bouwlogistieke processen door middel van een controltower. Hierin worden de bouwlogistieke processen dynamisch aangestuurd met toepassing van verregaande vorm van informatie-integratie en toepassing van geavanceerde informatie technologische toepassingen. Dit ideaalbeeld is niet direct te realiseren. Een nu wel reeds realiseerbare controltower heeft een statische vorm, waarbij de controltower een informatie-hub is waarbij met name prestatiemeting en monitoring wordt verzorgd. Hiertoe moet het gesprek aangegaan worden met diverse leveranciers van ICT met betrekking tot mogelijkheden en ook moet het gesprek aangegaan worden met betrokken partijen over de bereidheid om de informatie te delen en onder welke voorwaarden dit kan gebeuren. Verder onderzoek naar informatiebehoeften en de informatievoorziening in de aanleverende ketens is eveneens nodig om zo te komen tot het bepalen van de best passende manier om in de informatiebehoefte om te komen tot afstemming te voldoen.
WP2.1 Controltower
2
| 14 mei 2015
6 / 28
Inleiding De afgelopen decennia lag in de bouwsector de focus op het verduurzamen van het (te ontwerpen en te realiseren) bouwobject, en wel op het gebied van materialen, energieverbruik en levensduur (Duurzame Logistiek in de Bouw, 2013). De laatste jaren is de focus ook komen te liggen op de logistiek van het gehele bouwproces en in het bijzonder het toeleveringsproces aan de bouwplaats. Deze logistiek is de afgelopen vier jaar uitgebreid onderzocht in het kader van een SIA Raak-MKB-project door Hogeschool Rotterdam met inbreng van de leden van het Platform Logistiek in de Bouw, bestaande uit de kennisinstellingen Hogeschool Rotterdam, Hogeschool Utrecht, TNO en TU-Delft; de branchepartijen Bouwend Nederland, EVO, TLN; de overheden Gemeente Rotterdam en Rijkswaterstaat en de netwerkorganisatie Connekt. Het SIA Raak-MKB-onderzoek heeft geleid tot een aantal ‘best practices’ (Merrienboer, 2013), die vooral theoretisch zijn onderbouwd. Deze ‘best-practices’ dienden als basis voor het TKI-project ‘4C in Bouwlogistiek’, waarvan het doel is om bouwlogistieke oplossingen toe te passen, te testen, te evalueren en verder te ontwikkelen met ketenpartijen om uiteindelijk te komen tot een Cross Chain Control Center (4C), hier verder aangeduid met ‘controltower’. In een controltower kan een gecombineerde planning, bundeling en afstemming in de bouwlogistieke keten worden gerealiseerd. Het TKI-project ‘4C in Bouwlogistiek’ wordt gefinancierd door het Topconsortium Kennis en Innovatie in Logistiek (TKI). Wanneer het bouwlogistieke proces beter wordt georganiseerd kan dit leiden tot een efficiënter en effectiever bouwproces (zie factsheet, Platform Logistiek in de Bouw, 2013). Bankvall e.a. (2010) geven aan dat, om dit te bereiken de activiteiten op de bouwplaats vragen om een continue afstemming en aanpassing van plannen om met onvoorziene omstandigheden binnen het bouwproject om te kunnen gaan. De continue afstemming op de bouwplaats heeft een direct effect op de toeleveringsketen. De verschillende toeleveranciers die een bouwplaats beleveren, optimaliseren het afleverproces tussen verschillende bouwprojecten. Eén van de doelen van een controltower is het synchroniseren en optimaliseren van het afleverproces van verschillende toeleveranciers aan verschillende bouwprojecten van dezelfde of verschillende aannemers (Bankvall e.a., 2010). Dit rapport draagt bij aan het opzetten en implementeren van een bouwlogistieke controltower (WP.2.1.) in het kader van het TKI 4C in bouwlogistiek. Het doel van deze rapportage is het definiëren van een bouwlogistieke controltower en een kader op te stellen, waarbinnen de afstemming en informatievoorziening plaatsvindt op strategisch, tactisch en operationeel niveau. Dit rapport (WP2.1.) bestaat naast enkele al opgeleverde rapporten in het kader van het TKI 4C in bouwlogistiek, namelijk een beschrijving van een referentiebibliotheek (WP1.1.) en een rapport met een beschrijving van KPI’s voor het meten van prestaties in bouwlogistiek (WP2.2.). Naar beide documenten wordt in dit rapport verwezen. Opvolgend aan dit rapport zal een assessmenttool voor bouwlogistiek worden opgeleverd (WP2.3.). Op basis van de rapporten kan een bouwlogistieke controltower worden ingericht.
WP2.1 Controltower
| 14 mei 2015
7 / 28
Om de doelstelling van dit rapport te realiseren wordt in het eerste hoofdstuk de bouwlogistieke controltower vanuit een theoretisch kader beschreven. Daarnaast wordt ingegaan op de logistieke afstemming en de informatievoorziening in zijn algemeenheid en in de bouw. Het tweede hoofdstuk behandeld de opbouw van een bouwlogistieke controltower. Afsluitend wordt de conclusie weergegeven en worden aanbevelingen gedaan voor vervolgstappen en -onderzoek.
WP2.1 Controltower
3
| 14 mei 2015
8 / 28
De bouwlogistieke controltower Dit hoofdstuk beschrijft de bouwlogistieke controltower. In de eerste paragraaf wordt ingegaan op de logistieke controltower en de toepassing hiervan binnen de bouwsector. Het doel van de controltower is om afstemming tussen logistieke ketens naar bouwprojecten te realiseren. Hierom wordt in de tweede paragraaf ingegaan op de afstemming die in deze ketens kan plaatsvinden en de manier waarop informatie gedeeld moet worden om afstemming te bereiken. De toepassing hiervan voor de bouwsector wordt in de afsluitende paragraaf beschreven. Op basis hiervan kan in het opvolgende hoofdstuk de onderdelen van de bouwlogistieke controltower beschreven worden.
3.1
Afstemming van bouwlogistiek met de bouwlogistieke controltower Een beeldspraak voor afstemming in logistieke netwerken is een controle toren (controltower), zoals bij luchthavens, die het hele netwerk en de zich daar plaatsvindende activiteiten overziet. Door informatiedeling, planning en monitoring kunnen ketens en netwerken worden afgestemd op basis van de behoeftes van de verschillende partijen in de bouwketen. Goede en werkzame voorbeelden van ketenafstemming zijn bijvoorbeeld in de retailsector te vinden. Point-Of-Sale (POS) informatie die in de winkel (door het scannen van artikelen) voor betaling wordt gegeneerd, wordt geheel of gedeeltelijk met verschillende partijen in de keten gedeeld via ondersteunende technologieën. POS-informatie kan zowel batchgewijs op een bepaalde periode worden gedeeld of direct met (bepaalde) partijen worden gedeeld. Hiermee is het mogelijk de eigen schakel te optimaliseren alsook de afstemming naar andere schakels te verbeteren. Binnen het concept “Efficiënt Consumer Response” (zie bijvoorbeeld, van Riet e.a., 1999 en Balder e.a., 1999) wordt dit Supply Management genoemd. Het betreft in dit concept veelal een optimalisatie van de eigen keten in afstemming met toeleveranciers. Dit is echter nog geen controltower, waar ketens centraal worden geregisseerd. Door het delen van planningen, informatie en operationele situaties in ketens en netwerken kan tot een adequate regiefunctie worden gekomen. De commissie van Laarhoven (2008) ziet een controltower als “een regiecentrum van waaruit verschillende logistieke ketens gezamenlijk gecoördineerd worden met behulp van de modernste technologie, geavanceerde informatiedelingsconcepten en logistieke professionals; niet alleen met betrekking tot fysieke stromen, maar ook tot informatie en financiële stromen in ketens en netwerken.” In de White paper “Supply Chain Controltower” (Cape Group, 2013) wordt ingegaan op de kwaliteiten die een controltower zou moeten hebben. Genoemd worden: (1) zichtbaarheid over alle in beschouwing genomen ketens; (2) de mogelijkheid om te reageren en aan te passen op acute verstoringen; (3) proces orkestratie en samenwerking; op basis van voorspellingen en simulaties beslissingen nemen en (4) de keten dynamisch aansturen. Deze functies lijken nog erg gericht op de optimalisatie van één of enkele ketens, waarbij volgens de definitie die Dinalog aanhangt het voornamelijk gaat om het afstemmen van verschillende parallelle ketens (Dinalog, 2014).
WP2.1 Controltower
| 14 mei 2015
9 / 28
Verschillende bronnen (TNO, 2014; Cape Group, 2013; Lindert, 2013; Leitner, 2011) onderscheiden rollen op strategisch, tactisch en operationeel niveau. Op strategisch niveau kan de controltower beslissingen nemen of ondersteunen bij het nemen van beslissingen over het netwerkontwerp en de inrichting van distributiekanalen, op basis van verschillende scenario’s. Op het tactische niveau kan de controltower onder andere het transport optimaliseren. Op het operationele niveau kan de controltower de orders in het netwerk en eventuele verstoringen managen. Beschrijving van de bouwlogistieke controltower Zoals hierboven beschreven, is een cross chain control center in de meest verstrekkende vorm een regiecentrum waar meerdere complexe logistieke ketens afgestemd worden (TNO, 2013). Het TKI-project “4c in Bouwlogistiek” richt zich op afstemming in de bouwlogistieke keten middels informatievoorziening door de toepassing van een bouwlogistieke controltower. Binnen het TKI-project ‘4C in Bouwlogistiek’ wordt een controltower iets enger beschouwd. Binnen dit project ligt de focus op de ketens die binnen een aantal specifiek gekozen proeftuinprojecten kunnen worden onderscheiden. TNO (2014) geeft aan dat de voorgestelde bouwlogistieke controltower bedrijfsoverstijgende ketenprocessen en meerdere verschillende goederen- en personenstromen op elkaar afstemt. De bouwlogistieke 4C ondersteund bij het realiseren van inzicht en kan overzicht in deze ketenprocessen op basis van beschikbare informatie uit de integrale keten verspreiden onder alle ketenpartners. Het betreft hier een operationele integratie tussen de ketenpartijen in het bouwproject. De informatie die door de controltower gegenereerd wordt, dient voor zowel lange termijn strategische besluitvorming als korte termijn operationele planning en besturing van de bouwlogistieke ketenprocessen en/of het bouwproces. Hierbij zijn verschillende niveaus van regie te onderscheiden; dit kan plaats vinden op strategisch niveau (bijvoorbeeld samenwerking tussen partijen om bouwlogistieke te integreren bij de aanbesteding, bijvoorbeeld door eisen te stellen aan local sourcing, maar ook bij het plannen van ketens over een groter aantal bouwprojecten), maar ook op tactisch niveau (hoe en waar wordt de voorraad neergelegd, en sturing op die voorraad; denk aan een bouw consolidatiecentrum, of een speciale rol voor een bouwgroothandel) en op operationeel niveau (plannen van transport stromen van mensen, materieel en materiaal). De lange termijn strategische besluitvorming betreft de voorbereidende fases van één of meer bouwprojecten (initiatief tot en met werkvoorbereiding). In deze fase (met name de aanbesteding /vergunningen fase) is de grootste impact te behalen op de uiteindelijke inrichting en uitvoering van de bouwlogistieke ketenprocessen. De korte termijn operationele planning en besturing betreft de uitvoerende fasen van de ketenprocessen van een of meerdere bouwprojecten. Hierbij faciliteert de bouwlogistieke controltower dus de samenwerking tussen de verschillende partijen, binnen de vanuit het bouwproject op dat moment bestaande voorwaarden.
3.2
Informatie en ICT als afstemmingsmechanisme Om een controltower te ontwerpen moet eerst inzicht verkregen worden op welke manier afstemming en informatievoorziening vormgegeven kan worden. Hieronder wordt hiertoe inzicht gegeven in de manier waarop afstemming middels
WP2.1 Controltower
| 14 mei 2015
10 / 28
informatievoorziening en ICT in algemeenheid kan plaatsvinden in ketens en netwerken. Binnen en tussen organisaties zijn taken en organisatie onderdelen afhankelijk van 1 elkaar (Heijden, 1995). Om de afhankelijkheden te organiseren is afstemming tussen de verschillende taken en partijen noodzakelijk. Om afstemming tussen bedrijven te verbeteren wordt informatie en ICT-systemen gebruikt (Arshinder e.a., 2008; McAfee, 2002). Informatie en ICT-systemen worden ook wel aangemerkt als afstemmingsmechanismen (o.a. Arshinder e.a., 2008; Xue e.a., 2007; Hong, 2002). Om prestaties van ketens te verbeteren worden ICT-systemen toegepast die de bedrijfsgrenzen overschrijden. Deze ICT-systemen worden Inter-Organisationele Systemen (IOS) genoemd (Kumar & van Dissel, 1996; Arshinder e.a., 2008; McAfee, 2002). De manier waarop processen ondersteund worden met een IOS varieert van operationele informatie-uitwisseling tot strategische initiatieven (Saeed, Malhotra, & Grover, 2011). Bedrijven kunnen IOS op verschillende manieren gebruiken om processen te ondersteunen. Het zijn systemen die applicaties kunnen integreren op basis van compatibele data. Deze systemen bevatten mogelijkheden tot het analyseren en evalueren van gegevens en kunnen statusupdates geven (alertheid) ten behoeve van de aansturing (Saeed, Malhotra, & Grover, 2011). De mate waarin structuur aan te brengen is in de relatie beïnvloedt de mate waarin de relatie geprogrammeerd en vastgelegd kan worden in het IOS. De basis voor de structuur zijn verschillende vormen van afhankelijkheden en afstemming, welke elk om hun eigen toepassing van IOS vragen (Kumar & van Dissel, 1996). Kumar en van Dissel (1996) hebben op basis hiervan drie basis IOS-en opgesteld, namelijk: - Gedeelde informatiebron IOS, gerelateerd aan gedeelde afhankelijkheid en standaardisatie - Value/ supply chain IOS, gerelateerd aan opvolgende afhankelijkheid en plannen - Netwerk IOS, gerelateerd aan wederkerige afhankelijkheid en wederzijdse afstemming. Een netwerk IOS bevat ook karakteristieken van de minder complexe afhankelijkheidsvormen, dus value/ supply-chain alsook gedeelde informatiebronnen IOS en de value/ supply-chain IOS bevat ook karakteristieken van gedeelde informatiebronnen IOS (Kumar & van Dissel, 1996). In figuur 1 is bovenstaande samenvattend weergegeven.
1
Thompson (1967) onderscheidt drie vormen van afhankelijkheden, namelijk: 1) Gedeelde afhankelijkheid: Iedere speler heeft een eigen bijdrage aan het geheel en krijgt ondersteuning van het geheel. Standaardisatie wordt toegepast om dit soort afhankelijkheden af te stemmen. Het betreft coördinatie door een vooraf gedefinieerde set van regels. Situaties waarin standaardisatie kan worden toegepast moeten relatief stabiel en repetitief zijn om passende regels te kunnen opstellen; 2) Sequentiële afhankelijkheid: hierbij bestaat er een directe afhankelijkheid tussen de activiteiten omdat de output van één activiteit de input is voor de volgende activiteit. Plannen worden toegepast om deze afhankelijkheden af te stemmen. De organisatie-eenheden gebruiken vooraf gedefinieerde schema’s om de activiteiten te coördineren; 3) Wederkerige afhankelijkheid: elke partij is afhankelijk van de andere, waarmee verschillende outputs inputs zijn voor verschillende andere partijen. Wederzijdse afstemming wordt toegepast om dit soort afhankelijkheden af te stemmen. Deze vorm van afstemming impliceert dat de partijen hun gedrag tijdens de uitvoering van activiteiten zelf coördineren in plaats van het gebruiken van regels of planningen die zijn opgesteld voordat de uitvoering begint.
WP2.1 Controltower
| 14 mei 2015
11 / 28
Figuur 1, Interdependence, structure and potential for conflict (Kumar & van Dissel, 1996).
Om tot informatiedeling te komen tussen bedrijven of onderdelen van bedrijven zijn drie onderdelen van belang (Moberg, Cutler, Gross, & Speh, 2002), namelijk: - Informatie karakteristieken; Dit betreft de kwaliteit van de informatie. Informatie heeft weinig waarde als deze niet valide en betrouwbaar is. De voorwaarden voor kwalitatieve informatie zijn: accuraatheid, tijdigheid en het juiste format van informatie. - Organisationele karakteristieken; Dit karakteristiek betreft drie onderdelen: 1) Informatie technologie commitment: om elke weerstand tegen verandering weg te nemen. Het hoge management moet het commitment aan nieuwe technologieën uitdragen. 2) Organisatie omvang; grotere organisaties zijn overwegend meer divers en complex en hebben meer hulpbronnen beschikbaar. 3) Supply Chain Management commitment; Het geloof van het management in SCM principes. - De relatie tussen de bedrijven; Het is waarschijnlijker dat in sterke relaties de informatie wordt gedeeld tussen de bedrijven en dat de bedrijven bereid zijn om samen de keten af te stemmen voor het grotere goed van alle bedrijven die deelnemen. 3.3
Afstemming van bouwlogistiek De activiteiten van een bouwproject zijn wederkerig afhankelijk (Thompson, 1967), waarbij outputs van verschillende partijen inputs voor andere partijen bepalen. Verschillende aansturingsvormen en afhankelijkheden van de keten en het bouwproject ontmoeten elkaar op de bouwplaats. Dubois en Gadde (2000) beschrijven de netwerken waar bedrijven in de bouw zich in bevinden. Zij beschrijven de sterke afhankelijkheden tussen de activiteiten en
WP2.1 Controltower
| 14 mei 2015
12 / 28
hulpbronnen van ploegen uit verschillende bedrijven die aan een bouwproject werken. De ene partij kan het werk niet uitvoeren zonder de ondersteuning van de andere partijen. Daarom is gedurende het project sprake van een sterke samenwerking om met de afhankelijkheden om te gaan. Er zijn veel wijzigingen in de plannen door de hoge onvoorspelbaarheid van het bouwproces door veel verschillende factoren. Daarbij vinden ook op de bouwplaats nog wijzigingen plaats met gevolgen voor de hele keten. Zo kan bijvoorbeeld tijdens de bouw een gedeelte van het bouwwerk nog ontworpen worden of kunnen de te gebruiken materialen tijdens de bouw nog wijzigen. Dit vraagt om een continue afstemming en aanpassing van de plannen om zo met onvoorziene omstandigheden binnen het bouwproject om te gaan (Bankvall, e.a., 2010). Deze veranderingen hebben een direct effect op de toeleveringsketen. De continue wijzigingen van de plannen beïnvloeden alle activiteiten in de aanvoerketens. Hierdoor zijn er problemen in de planning voor de uitvoering van activiteiten op de bouwplaats en in de keten. Om met de onvoorspelbaarheid om te kunnen gaan, zijn de hulpbronnen in de keten flexibel, wat direct verklaart waarom er hoge buffers tussen de verschillende schakels in de keten aangehouden worden en waarom de efficiency en effectiviteit in de bouw en de bouwlogistieke ketens laag zijn (Bankvall, e.a., 2010). Betere planning, synchronisatie en flexibiliteit is nodig om hiermee om te gaan. Informatiebehoefte in de bouw Communicatie is van essentieel belang in bouwprojecten. De bouw wordt geconfronteerd met grote problemen in communicatie en ineffectief gebruik van ICT (Adriaanse & Voordijk, 2005). Problemen in de bouw zijn overwegend problemen in de keten, die veroorzaakt worden bij de overgangspunten tussen verschillende organisaties of stappen in de bouwlogistieke keten (Xue, e.a., 2007). De partijen in het bouwproces spreken echter allen een eigen taal en hebben elk hun eigen benadering. Het onderliggende probleem is de constante verandering van partijen die samenwerken in verschillende projecten en het gebrek aan standaarden voor informatiedeling, lange termijn visie op informatievoorziening en kennis (management). Elk bedrijf heeft zijn eigen werkwijzen, hulpbronnen en doelen, waardoor de werkwijzen in het project uitgelijnd moeten worden en de interorganisationele ICT veelal opgezet wordt voor slechts de loop van één project. Deze ICT is bedoeld als digitale coördinatie- en samenwerkingstool die gebruikt wordt om te communiceren en projectinformatie te delen tussen de partijen die betrokken zijn in een bouwproject. Doordat de ICT wordt opgezet voor de looptijd van één project zijn investeringen in ICT toepassingen voor interorganisationele communicatie beperkt, hebben een beperkte toegevoegde waarde en voldoen niet aan de verwachtingen (Adriaanse, Voordijk, & Dewulf, 2010). Digitalisering biedt voor de bouwlogistieke keten een mogelijkheid tot afstemming door informatie snel, simpel, bereikbaar en accuraat aan te bieden (Xue, e.a., 2002). Door een effectievere vorm van informatie integratie, verwerken van informatie en gebruik van informatie kan het bouwproces beter afgestemd worden en kan er gereageerd worden op mogelijke veranderingen in het proces (Viljamaa & Peltomaa, 2013). De variatie in technologie en de kennis van technologie van verschillende partijen werkzaam in een project is echter erg verschillend, waardoor mogelijk problemen
WP2.1 Controltower
| 14 mei 2015
13 / 28
ontstaan om het project te beheren en om tot integratie en gebruik van relevante procesgegevens te komen (Viljamaa & Peltomaa, 2013). Cus-Babic e.a. (2013) onderkennen bijvoorbeeld vele problemen bij het verbinden van bouw gerelateerde data in een CAD systeem met productie gerelateerde data in een ERP systeem doordat deze systemen verschillende manieren hebben om naar een bouwobject te kijken. Om te komen tot waardevolle geïntegreerde data voor het afstemmen van projecten, is het van belang dat gegevens van taken, planningen en hulpbronnen, geometrische ontwerpen, project financiën en bijgewerkte bouwprocesdata worden gedeeld (Viljamaa & Peltomaa, 2013). De huidige staat van ICT in de Bouw Er vinden in de bouw belangrijke ontwikkelingen plaats op het gebied van ICT. Momenteel wordt de ontwikkeling van BIM gezien als de belangrijkste ontwikkeling in de bouwsector (Adriaanse, 2014). De manier waarop momenteel voornamelijk met BIM wordt gewerkt is het gebruik in de ontwerpfase en de werkvoorbereidingsfase van bouwprojecten (Eadie, e.a., 2013; Miettinen & Paavola, 2014; Adriaanse, 2014) en is het gebruik van BIM in de uitvoeringsfase veel beperkter en in de beheer- en onderhoudsfase is het gebruik nog heel summier (Adriaanse, 2014). Naar informatie management in de bouw Cus-Babic e.a. (2013) geven aan dat samenwerking en uitwisseling van informatie tussen de partijen die betrokken zijn bij de bouw mogelijk is via een gedeeld (BIM) systeem. Er zijn verschillende mogelijkheden om planningen te koppelen aan een 3D model waarmee een visualisatie gemaakt kan worden van de opvolgende bouwprocesstappen (Irizarry, e.a., 2013). Volgens Cus-Babic e.a. (2013) kan een model hierbij de basis zijn voor de integratie waarbij ook ontwerp-, productie- en afleverprocessen van toeleveranciers afgestemd kunnen worden. Deze afstemming kan ervoor zorgen dat verspillingen en vertragingen op de bouwplaats en in de bouwlogistieke keten voorkomen kunnen worden. Ontwerpers, planners en bouwplaats medewerkers stemmen activiteiten af op basis van het model. Als een ontwerper het model aanpast, dan worden logistieke planners geïnformeerd waardoor zij planningen kunnen aanpassen. De bouwplaats medewerkers kunnen hiermee direct een overzicht krijgen van wijzigingen in de materiaalbeschikbaarheid en daarmee de bouwplaats activiteiten aanpassen. Dit vraagt om een koppeling van BIM aan bedrijfsmatige en logistieke systemen zoals ERP (Enterprise Resource Planning), WMS (Warehouse Management Systemen) en TMS (Transport Management Systemen). Door BIM te koppelen aan geografische informatiesystemen (GIS) wordt het ook mogelijk om het netwerk van toeleveranciers en onderaannemers in te richten en op operationeel vlak te monitoren zodat ingespeeld kan worden op verstoringen in het proces (Irizarry, e.a., 2013). De manier waarop dit monitoren plaatsvindt wordt bepaald door de configuraties van de bouwlogistieke ketens. De bouwplaats krijgt zowel Make-to-stock (MTS, zoals bouten en moeren), Make-to-order (MTO, zoals ramen en kozijnen) als Engineer-to-order (ETO, zoals installaties) goederen beleverd. Deze configuraties bepalen voor een belangrijk deel de aansturing van de partijen, het proces en de volgordelijkheid van activiteiten.
WP2.1 Controltower
| 14 mei 2015
14 / 28
Door te werken met RFID is het mogelijk om bouwelementen intelligent te maken, waarbij het bouwelement zelf kan melden dat deze geproduceerd is, de positie in de bouwlogistieke keten kan weergeven, kan aangeven waar het element zich onderweg bevindt en kan aangeven dat het element op de juiste plek in het bouwwerk is verwerkt (Adriaanse, 2014).
WP2.1 Controltower
4
| 14 mei 2015
15 / 28
Opbouw van de bouwlogistieke controltower In dit hoofdstuk wordt op basis van de beschrijving van de bouwlogistieke controltower en de manier waarop afstemming in de bouwlogistieke keten kan plaatsvinden, de opbouw van de bouwlogistieke controltower behandeld. De controltower heeft betrekking op de operationele processen vanaf de voorraad bij de leverancier (ontkoppelpunt) tot de plaats van verwerking van de producten op de bouwplaats. De controltower richt zich op de materiaal- en personeelsstroom en de informatiestromen daaromtrent. De bouwproject financiën en de financiële stromen tussen de partijen worden buiten beschouwing gelaten. Eerst wordt de inrichting van de supply chain behandeld, waarna in de tweede paragraaf wordt aangegeven welke operationele bouwlogistieke processen hierin voorkomen. Vervolgens wordt stilgestaan bij de operationele afstemming van deze ketens middels de controltower. Hierbij wordt ingegaan op de manier waarop verschillende schakels middels gegevensuitwisseling tot afstemming kunnen komen. Vervolgens wordt de soort informatie die gedeeld moet worden behandeld. Afsluitend worden kort de KPI’s beschreven, die de controltower zal monitoren om de prestaties te beoordelen en waar mogelijk het bouwlogistieke proces bij te sturen.
4.1
Inrichting van bouwlogistieke processen De eerste stap naar de invulling van de bouwlogistieke controltower is het kunnen geven van advies over de inrichting van het netwerk van toeleveranciers en de bouwplaats (-en). Dit advies kan worden gebaseerd op de toepassing van rekenmodellen en simulaties. Hiervoor kan de referentiebibliotheek (WP1.1) en een beslissingsondersteunend bouwlogistiek rekenmodel (onderdeel van WP 2.4., assessmenttool) als basis worden gebruikt. De typologische kenmerken van gebouwen, zoals beschreven in de referentiebibliotheek, bepalen voor een groot deel welke bouwlogistieke optimalisaties mogelijk zijn. Op basis hiervan kunnen scenario’s worden opgesteld welke, door middel van rekenmodellen worden doorgerekend. Hieronder worden de referentiebibliotheek en het beslissingsondersteunende bouwlogistieke rekenmodel kort behandeld. Referentiebibliotheek Op strategisch niveau binnen de controltower wordt de bouwlogistieke grondvorm bepaald (Hoekstra & Romme, 1993). Deze grondvorm is afhankelijk van de typologische kenmerken van het project, zoals deze in de referentiebibliotheek (WP 1.1.) zijn beschreven. De referentiebibliotheek geeft een beschrijving van typologische bouwprojecten waaraan in een verdere ontwikkeling bouwlogistieke kengetallen gekoppeld kunnen worden. Binnen de referentiebibliotheek zijn projecten naar vijf standaard criteria gecategoriseerd, namelijk omvang, locatie, industrialisatie, contractvormen en logistiek. Deze typologische kenmerken zijn van invloed op de logistieke aansturing. Door bouwprojecten op basis van typologische kenmerken te onderscheiden kunnen bouwprojecten worden gecategoriseerd. Elk type bouwproject heeft een aantal vaste typologische kenmerken die onlosmakelijk met het bouwproject zijn verbonden. Deze kenmerken zijn gegeven in
WP2.1 Controltower
| 14 mei 2015
16 / 28
de bouwopgave en staan hiermee vast. Het gaat hierbij om het type, de omvang en de hoogte van het project. Er is hierbij een onderscheid te maken tussen woningbouw, utiliteitsbouw en infrastructurele werken. Daarnaast zijn de bouwprojecten te onderscheiden naar kleine, middelgrote en grote projecten. De hoogte van het gebouw wordt gecategoriseerd op laag-, middelhoog- en hoogbouw. De andere vier typologische kenmerken zijn variabel. Deze kunnen binnen hun mogelijkheden worden veranderd om de logistieke keten vorm te geven. Het gaat hierbij om: - De locatie van het bouwproject: hierbij wordt onderscheid gemaakt tussen greenfield bouwen (buitenstedelijk bouwen) en brownfield bouwen (binnenstedelijk bouwen). Naast deze twee categorieën zouden bouwprojecten op industrieterreinen of aan de stadsrand als tussenvormen kunnen worden gezien. - De mate van industrialisatie van het bouwproject: om het bouwproces te industrialiseren maakt de bouwsector gebruik van prefabricage, wat kan worden gezien als een manier van bouwen, waarbij onderdelen van tevoren pasklaar gefabriceerd zijn. De uitersten in de mate van industrialisatie is volledig traditioneel bouwen of geheel geprefabriceerd bouwen. - De contractvormen: verschillende contractvormen geven de structuur en de verdeling van de risico’s weer. De meest voorkomende contact zijn het traditioneel contract, design & build contract en het Build, Operate & Transfer contract (Wamelink, 2009). De verschillende contractvormen kunnen worden weergegeven per bouwfase en per stakeholder. De stakeholders binnen het bouwproces hebben verschillende rollen in de bouwfases. - De logistieke inrichting van de keten: In het bouwproces zijn de drie basis klantorder ontkoppelpunten te herkennen, namelijk inkopen en maken op order (ETO; klantspecifieke producten), maken op order (MTO; planbare producten) en maken voor centrale voorraad (MTS; verbruiksartikelen). Omdat de bouw zelf een Engineer-To-Order proces betreft zijn alle drie de klantorder ontkoppelpunten in de bouw terug te vinden. Er ontstaan op deze manier logistieke varianten van de basis typologieën van bouwprojecten. De consequenties van het kiezen van één van deze typologische kenmerken kunnen uiteindelijk en indien er volgende gegevens voorhanden zijn met behulp van rekenmodellen worden geanalyseerd op aspecten van tijd, kosten en duurzaamheid. Aan de hand hiervan kan de optimale bouwlogistieke grondvorm worden bepaald, wat kan worden gezien als de eerste stap voor het ontwerpen van een controltower. Beslissingsondersteunend bouwlogistiek rekenmodel Een beslissingsondersteunend rekenmodel heeft tot doel dat de controltower beslissingen kan nemen of kan ondersteunen over het netwerkontwerp en de inrichting van distributiekanalen, op basis van verschillende typologische kenmerken en scenario’s. Het bouwlogistiek rekenmodel verschaft via het doen van simulaties, inzicht in de effecten van ingrepen in de bouwlogistiek op zowel stedelijk gebiedsniveau als voor de bouwketens (zoals bijvoorbeeld de selectie van leveranciers) benodigd voor een bouwopgave. Dit inzicht heeft als doel de essentie van samenwerking binnen de bouw(logistiek) bij alle betrokken partijen duidelijk te maken. Het rekenmodel dient daarmee ook als bewustwordingstool bij de betrokken
WP2.1 Controltower
| 14 mei 2015
17 / 28
partijen. Het rekenmodel gebruikt gegevens over het bouwwerk, de bouwplanning, de toeleveranciers en de vervoersmiddelen als input. Als basis voor een dergelijk beslissingsondersteunend bouwlogistiek rekenmodel kunnen onder andere de volgende, al bestaande modellen dienen: - Beslissingsondersteunend rekenmodel dat uit het SIA-RAAK MKB onderzoek is voortgekomen - Rekenmodel van TNO dat is ontwikkeld in het project Duurzame Bouwlogistiek Amsterdam (DBA) - Rekenmodel bouwverkeer en luchtkwaliteit van Gemeente Rotterdam, IGWR - Model verkeersvoorspeller van gemeente Amsterdam, IBA - Rekenmodel Logistiek centrum JuBi
4.2
Operationele bouwlogistieke processen Om de planningsprocessen, de operationele processen en de bijbehorende sturingsinformatie en KPI’s te beschrijven en een kader op te zetten voor de controltower, wordt het SCOR-model gebruikt. SCOR is de afkorting van Supply Chain Operations Reference en is ontwikkeld door de Supply Chain Council. Het SCOR-model beslaat de gehele keten, vanaf de leveranciers tot aan de uiteindelijke klant en kent een hiërarchische structuur bestaande uit verschillende niveaus (levels) van detail. Het SCOR-model bestaat op het eerste niveau (level 1) uit vijf basisprocessen, namelijk: Plan, Source, Make, Deliver en Return. Op het tweede niveau (level 2) vallen de basisprocessen uiteen in procescategorieën. Er wordt een onderscheid gemaakt in de Plan (P), Execution (Source, Deliver, Make en Return) en de ondersteunende Enable processen. Leidend in het bepalen van de procescategorieën, zijn voornamelijk de configuraties in productie, namelijk: Maketo-Stock (M1), Make-to-Order (M2) en Engineer-to-Order (M3). Deze klantorderontkoppelpunten geven het punt aan tot hoever een klantenorder doordringt in het productie- of distributieproces van de aanbieder van een product of dienst (Visser & van Goor, 2008). Op basis van deze configuratie is duidelijk van welk leverproces er sprake is, en zijn de aanvoerprocessen ook grotendeels bepaald. Voor het vaststellen van het kader voor een bouwlogistieke controltower zijn de bouwlogistieke processen uitgewerkt op level 2 van het SCOR-model. Zie figuur 2 voor een weergave van een processchema op level 2 niveau. Dit processchema beschrijft de bouwlogistieke processen bij een traditionele manier van het inrichten van de bouwprocessen, dus zonder toepassing van bouwlogistieke oplossingen. Daaronder volgt een toelichting op dit processchema. Level 1 bouwprocessen Het doel van level 1 van het SCOR-model is het in kaart brengen van de aanleverprocessen in het bouwproces, van leveranciers tot de verwerking van materialen op de bouwplaats. De basisprocessen die plaatsvinden zijn relatief standaard logistieke processen, die ook in andere branches breed geaccepteerd zijn. Een uitzondering hierop is dat in de bouwlogistieke processen de specifieke planning van de aanvoer van materieel een belangrijk onderdeel is van de dagelijkse praktijk. Met het SCOR-model kan deze aanvoer niet voldoende
WP2.1 Controltower
| 14 mei 2015
18 / 28
uitgelicht worden omdat er in het SCOR-model van uitgegaan wordt dat producten op een vaste verwerkingsplaats worden verwerkt. Dit is in de bouw niet het geval. Daarnaast is de huidige traditionele logistieke aansturing van bouwprojecten vaak versnipperd, aangezien iedere stakeholder zelf zorgt voor zijn/haar goederenstromen. Daarbij worden de producten, die door de stakeholders worden besteld ingekocht via de Incoterm ‘Delivered Duty Paid’ (Franco geleverd bij de besteller). Dit geeft aan dat de toeleverancier (verkoper) verantwoordelijk is voor het transport van de producten (Gelder & Rinsma, 2013). Leverancier MTS
Leverancier MTO
Leverancier ETO
Construction Site
P1
P2
P4
P2
P3
P4
P2
P3
P1
P4
P2
P3
P4
S1
M3
D3
S3
S2
S1
M1
D1
S1
S2
M2
D2
S2
M3 S1
S1
D1
D1
S1
S1
Sr
Figuur 2, Threaddiagram bouwlogistieke processen, SCOR level 2 (o.b.v. Gelder & Rinsma, 2013).
Level 2 bouwprocessen De level 2 procescategorieën zijn duidelijk te onderkennen binnen de bouwlogistieke keten, met name de uitvoerende, execution processen. Van de Plan activiteiten is in de huidige situatie vooral sprake van een projectplanning (P3, Plan Make) die leidend is voor de aansturing van de keten. Deze is gebaseerd op de P4 (Plan Deliver) van de bouwplaats, wat met name gericht is op het opleveren van het bouwwerk volgens afspraken die gemaakt zijn met de opdrachtgever. Dit is overwegend vastgelegd nog voor de aanbestedingsfase. Op basis van de projectplanning (P3) worden de P2 (Plan Source) voor de bouwplaats en daarmee de P3 (Plan Deliver) van de leveranciers bepaald. Zelden blijkt echter sprake te zijn van een proces Plan Supply Chain (P1). Vraag en aanbod bij de ketenpartners wordt overwegend niet of nauwelijks afgestemd. Zoals eerder aangegeven krijgt de bouwplaats vanaf de leveranciers zowel MTS (M1), MTO (M2) als ETO (M3) goederen beleverd, terwijl het gebouw doorgaans een ETO (M3) product betreft. Dit levert bouwspecifieke problemen op in de keten. Door de M1, M2 en M3 configuraties in de toeleverende ketens, zijn er drie soorten source processen te onderscheiden (Source MTS, S1; Source MTO, S2; Source ETO, S3). Deze Source processen zijn gekoppeld aan Deliver processen (Deliver
WP2.1 Controltower
| 14 mei 2015
19 / 28
MTS, D1; Deliver MTO, D2; Deliver ETO, D3). Hierbij kunnen leveranciers zowel arbeid, materieel en/of materiaal leveren. Dit betekent dat het Make proces, dat is geschetst bij de leveranciers van MTO en ETO producten ook op de bouwplaats kan plaatsvinden. Door de grote verschillen tussen de soorten producten worden deze stromen elk anders aangestuurd en uitgevoerd. Een ETO product vraagt dat de leverancier vroeger betrokken wordt in het bouwproces, terwijl voor MTS producten in veel gevallen geldt dat de leverancier op het laatste moment betrokken wordt. Omdat het gebouw een ETO product is waarbij vele onderaannemers en toeleveranciers opvolgend bij betrokken zijn, is het niet mogelijk om elk sourcemake-deliver proces apart te schetsen in een thread diagram. De weergave van de opvolgende processen op de bouwplaats in een thread diagram wordt zelfs bij het betrekken van slechts een beperkt aantal toeleveranciers complex. Het Make (M3) proces van bouwen is daarom in dit opzicht als een black-box beschouwd. Vanuit de bouwplaats ontstaan verschillende retourstromen. Dit betreft emballage materiaal (zoals kratten, bokken en pallets), goederen waarvan het verkeerde product geleverd wordt en goederen die teveel geleverd worden en aan het einde van het project over zijn. Onderzoek vanuit het Platform Logistiek in de Bouw (zie factsheet, Platform Logistiek in de Bouw, 2013) laat zien dat structureel 10%-20% teveel goederen worden besteld om fluctuaties af te dekken. Dit vraagt daarom om afstemming van zowel de aanvoer alsook de retourstromen vanaf de bouwplaats. Het eerste doel hierbij is om ervoor zorg te dragen dat de juiste goederen worden afgeleverd in de benodigde hoeveelheid, vervolgens is het van belang de restmaterialen zo efficiënt mogelijk af te voeren en waar mogelijk deze goederen alsnog te gebruiken (in hetzelfde bouwproject of terug te leveren bij de leverancier). Momenteel worden overgebleven goederen veelal vernietigd omdat deze goederen na oplevering van het project al zijn afgeschreven op het project. Een integrale aansturing op de retourstromen, zowel van emballagemateriaal alsook teveel of verkeerd geleverde producten vindt in de bouw niet plaats. Aanvullingen op het threaddiagram bij toepassing bouwlogistieke controltower. Zoals hierboven aangegeven betreffen de processen in het thread diagram en zoals beschreven, de processen zoals deze nu bestaan in de bouw. Bij toepassing van de controltower zullen deze operationele Supply Chain processen in basis gelijk blijven. Er zijn echter twee configuraties die voorgesteld worden om toe te voegen, namelijk: - Zoals aangegeven worden de retourstromen vanuit het bouwproject niet integraal aangestuurd. Een toevoeging voor de uitvoering van de controltower is daarmee een Plan Return (P5). De processen die deze plancategorie aanstuurt zijn de processen Source return defective product (SR1) en Source return excess product (SR3). SR2 is een categorie voor retourgoederen die gerepareerd moeten worden. Dit is een categorie die in de gebruiksfase relevant kan zijn, maar beperkt of niet tijdens de bouw zelf. - De Deliver processen stoppen volgens het SCOR-model fysiek bij de aflevering van de goederen. De source processen beginnen fysiek bij het in ontvangst nemen van de goederen en eindigen fysiek bij het op voorraad zetten van de goederen. Omdat er op de bouwplaats fysiek een groot verschil kan zijn tussen de interpretatie waar de goederen afgeleverd dienen te worden (afleveren bij de poort of afleveren op de plek van verwerking) en omdat hier per (soort) leverancier verschillende afspraken over zijn, is het
WP2.1 Controltower
| 14 mei 2015
20 / 28
van belang in de bouwlogistieke processen hier eenduidigheid over te hebben. Dit kan door de toevoeging van een Deliver proces dat volgens SCOR opvolgend gebruikt kan worden op D1 (Deliver MTS product), namelijk Deliver Retail (D4). Dit proces wordt alvolgt gedefinieerd: “Deliver Retail Products are the processes used to acquire, merchandise, and sell finished goods at a retail store. A retail store is a physical location that sells products (and services) direct to the consumer using a point of sale process (manual or automated) to collect payment. Merchandising at a store level is the stocking and restocking of products in designated storage locations to generate sales in a retail store.” In eerste instantie lijkt deze Deliver niet bruikbaar voor de bouwsector door de specifieke retail toepassing, maar op level 3 (het meest gedetailleerde niveau, de beschrijvingen van de operationele processtappen) kan het de koppeling vormen tussen het aanleveren op de bouwplaats door een leverancier bij de poort of een opslaglocatie en de daadwerkelijke plek van verwerking. Dit, aangezien het SCOR-model er normaliter vanuit gaat dat producten op een vaste verwerkingsplaats worden verwerkt, wat niet geldt voor een bouwplaats. Dit probleem wordt met deze Deliver ondervangen, zeker wanneer het interne transport van het product op de bouwplaats niet wordt uitgevoerd door de leverancier van de producten of degene die het zal verwerken, zoals bijvoorbeeld door een logistiek dienstverlener. Door toevoeging van dit proces wordt dit gedeelte van het bouwproces ook (beter) meetbaar. De toevoeging betreft dan voornamelijk de definitie en het gebruik van de specifieke operationele deelprocessen: - D4.2 Receive Product at Store: vgl. Ontvangen van het product op de bouwplaats (vanaf D1, D2 of D3) - D4.3 Pick Product from backroom: vgl. Het picken van het product van de tijdelijke opslag - D4.4 Stock Shelf: vgl. Het plaatsen van het product bij de plek van verwerking. Bovenstaande leidt tot het onderstaande thread diagram dat geldt voor de operationele bouwlogistieke controltower, waarbij de aanleverprocessen tot op het punt van verwerking zijn toegevoegd alsook de afhandeling van de retourstromen. De stippellijn geeft aan dat de mogelijkheid bestaat dat Deliver Retail Product overgeslagen wordt en dat de goederen direct op de plaats van verwerking worden geleverd. Dit is afhankelijk van de afstemming tussen leverancier en (onder)aannemer.
WP2.1 Controltower
Leverancier MTS
| 14 mei 2015
Leverancier MTO
21 / 28
Leverancier ETO
Construction Site
P1
P2
P4
P2
P3
P4
P2
P3
P1
P4
P2
P3
P4
P5
S1
M3
D3
D4
S3
S2
S1
M1
D1
D4
S1
S2
M2
D2
D4
S2
D4
S1
D4
S1
M3 S1
S1
D1
D1
Dr1
Dr1
Dr1
Sr1
Dr3
Dr3
Dr3
Sr3
Figuur 3, Threaddiagram bouwlogistieke processen controltower, SCOR level 2.
4.3
Aansturing van het bouwlogistieke proces In hoofdstuk 1 is beschreven hoe gekomen kan worden tot informatiemanagement in de bouw. Dit wordt in deze paragraaf gekoppeld aan de visie van de controltower binnen het TKI project ‘4C in Bouwlogistiek’, zoals is weergegeven in figuur 4. Zoals in hoofdstuk 1 aangegeven zijn de activiteiten van een bouwproject wederkerig afhankelijk (Thompson, 1967), waarbij outputs van verschillende partijen inputs voor andere partijen bepalen. Verschillende aansturingsvormen en afhankelijkheden van de keten en het bouwproject ontmoeten elkaar op de bouwplaats. De (wederkerige) afhankelijkheid op de bouwplaats vraagt om een continue afstemming en aanpassing van de plannen om zo met onvoorziene omstandigheden binnen het bouwproject om te gaan (Bankvall, e.a., 2010). Betere planning, synchronisatie en flexibiliteit is nodig om hiermee om te gaan. Hiervoor moeten partijen hun gedrag tijdens de uitvoering van activiteiten zelf coördineren omdat de regels of planningen die zijn opgesteld voordat de uitvoering begint aan verandering onderhevig zijn of niet tot in detail bekend zijn. Om deze afstemming te kunnen bereiken wordt ook in de controltower oplossing informatie en ICT gebruikt die bedrijfsgrenzen overschrijden (IOS). Het betreft een netwerk IOS waarbinnen gewerkt wordt met standaarden, regels, planningen en wederzijdse afstemming. Dit IOS dient de volgende karakteristieken in zich te hebben (o.b.v. Saeed e.a., 2011): - Applicatie integratie zodat verschillende systemen met elkaar in verbinding gebracht kunnen worden via web interfaces en/of EDI etc.; - Data comptabiliteit zodat de data vanuit het ene systeem bruikbaar is in het andere systeem; - Evaluatie mogelijkheden om met KPI’s het proces te kunnen monitoren;
WP2.1 Controltower
-
| 14 mei 2015
22 / 28
Analytische mogelijkheden om het proces te kunnen bijsturen op basis van de analyse resultaten; Responsiviteit om tijdig te kunnen reageren op veranderingen.
Informatie over het operationele bouwlogistieke proces is nodig om met de controltower deze processen af te kunnen stemmen (zie figuur 4, visualisatie controltower). Dit betreft, zoals in vorig hoofdstuk aangegeven informatie over taken, planningen, hulpbronnen, geometrische ontwerpen en bijgewerkte bouwprocesdata (Viljamaa & Peltomaa, 2013). Voor de controltower wordt financiële projectinformatie en financiële transacties buiten beschouwing gelaten. Voorwaarden aan het delen van de informatie zijn in het algemeen dat de betreffende informatie accuraat, tijdig en in het juiste format moet worden aangeleverd (Moberg, e.a., 2002). Met de controltower wordt beoogd dat afstemming plaatsvindt door een integratie van ontwerp-, productie- en afleverprocessen (zie figuur 3, visualisatie controltower). Hiertoe dienen 3D modellen in BIM gekoppeld te worden aan de bedrijfsmatige en logistieke systemen ERP (Enterprise Resource Planning), WMS (Warehouse Management Systemen) en TMS (Transport Management Systemen). Deze systemen geven inzicht in planningsinformatie op basis van taken, hulpbronnen en bijgewerkte bouwprocesdata (zoals wijzigingen in het bouwproces waardoor planningen aangepast worden). Het betreft planningsinformatie op de middellange en korte termijn die op deze manier aan elkaar worden gekoppeld. Veel bouwbedrijven werken al met een (vorm van een) ERP systeem, zoals bijvoorbeeld Microsoft Dynamics NAV (Navision) waarin planningen worden bijgehouden en wekelijks en dagelijks door de projectleider en/of de materieeldienst worden bijgewerkt. Toeleveranciers werken soms met een eigen ERP systeem in minder geavanceerde situaties met een WMS systeem voor de magazijn operaties of zonder een geautomatiseerd systeem. Via web interfaces (bijvoorbeeld middels API) of EDI (in het geval van strategische partners) kunnen gegevens van de systemen van de partijen gedeeld worden met de systemen van andere partijen. Zo kan bijvoorbeeld een wijziging tijdens de bouw vroegtijdig onderkend worden, waardoor leveranciers de productie en aanlevering kunnen aanpassen. Hierdoor kan de controltower verstoringen geconstateerd worden. Door een analyse op de consequenties kan de keten bijgestuurd worden. Dit kan op operationeel niveau door binnen de bestaande processen en in de keten te besluiten om de processen te vertragen of te versnellen, op tactisch/ strategisch niveau kan dit zelfs leiden tot aanpassingen van de bouwlogistieke keten, door bijvoorbeeld andere leveranciers, een ander product of een andere modaliteit te gebruiken. Bouwprocesdata kan in de dagelijkse operatie continu wijzigen door verstoringen in het proces. Deze dagelijkse processen kunnen worden aangestuurd door de controltower, waarbij voorspellingen en acute informatie er voor zorgen dat de keten dynamisch aangestuurd kan worden. Gegevens van taken, aangepaste activiteitenplanningen en hulpbronnen en bijgewerkte bouwprocesdata moet daarom ook real-time gedeeld worden. Dit kan door real-time informatie via push notificatieberichten naar betrokken partijen te delen. De informatie uit de bouw- en logistieke informatiesystemen is daarmee voor de betrokken partijen real-time zichtbaar en navolgbaar via tablets, mobiele telefoons en computer. De real-time informatie kan ontstaan door met RFID bouwelementen intelligent te maken, waarbij het bouwelement zelf kan melden dat deze geproduceerd is, de positie in
WP2.1 Controltower
| 14 mei 2015
23 / 28
de bouwlogistieke keten kan weergeven en kan aangeven dat het element op de juiste plek in het bouwwerk is verwerkt. Meer gedetailleerde real-time gegevens met betrekking tot de fysieke positie bij de aanlevering van de bouwplaats kan gegenereerd worden door geografische informatiesystemen (GIS) te gebruiken in het aanleverproces om te monitoren zodat ingespeeld kan worden op verstoringen in het proces. De manier waarop dit monitoren plaats vindt wordt bepaald door de categorieën van de bouwlogistieke ketens (ETO, MTO en MTS) omdat de categorie voor een belangrijk deel de relatie tussen de partijen, het proces en de volgordelijkheid bepaalt. Met het plaatsen van RFID-chips in tijdkritische producten (zoals bijvoorbeeld prefab betonelementen) zijn deze te volgen tijdens het transport waardoor een optimale afstemming tussen de aanleverketen en de bouwplaats mogelijk is (zoals bijvoorbeeld dat de kraan om de elementen te lossen precies op het juiste moment klaar staat als de vrachtwagen arriveert).
Figuur 4, Visualisatie controltower (Merriënboer, 2014)
4.4
Bouwlogistieke informatie Nu bekend is welke ketenprocessen de controltower aanstuurt en op welke manier dit kan gebeuren kan bepaald worden welke specifieke informatie gedeeld moet worden tussen de partijen. In deze paragraaf wordt daarom aan de hand van de operationele ketenprocessen (zie paragraaf 2.1) de benodigde informatie bepaald. Het betreft de informatie input en de informatie output van de processen, gebaseerd op het SCOR-model. Informatiestromen Een bouwlogistieke controltower vereist een goed inzicht in informatiestromen rondom een bouwproject, maar ook real-time toestandsinformatie van de
WP2.1 Controltower
| 14 mei 2015
24 / 28
operationele processen gekoppeld aan het bouwproces. Deze paragraaf beschrijft de informatiestromen en de afstemming hiervan binnen een traditionele situatie. De operationele supply chain processen welke in paragraaf 2.1 zijn beschreven, worden aangestuurd met informatie. Elk proces heeft informatie inputs en outputs om het uiteindelijke werk uit te kunnen voeren. Het SCOR-model definieert de inputs en outputs van de processen. Onderzoek van Hogeschool Rotterdam (2015) geeft aan welke informatie beschikbaar is binnen een bouwproject. Deze informatie is gekoppeld aan de in- en outputs van processen in het SCOR model. Hierbij gaat het om de Plan processen, Source processen en Make processen op de bouwplaats. Wanneer deze informatie beschikbaar is in de controltower, kan hiermee de keten worden afgestemd en aangestuurd. Niet alle informatie inputs van het SCOR-model zijn beschikbaar of van toegevoegde waarde binnen het bouwproject. Daarnaast wordt de beschikbare informatie niet of nauwelijks gedeeld met de ketenpartijen. Dit is echter wel essentieel voor een goede afstemming binnen de keten. In bijlage A zijn de informatie in- en outputs in tabelvorm weergegeven, gebaseerd op de SCOR procescategorieën. De belangrijkste informatie betreft Supply Chain Plan, Sourcing Plan, Delivery Plans, Production Plan, Scheduled Receipts, Inventory Availability, Production Schedule en Replenishment Signal. Deze outputs hebben namelijk de meeste invloed op andere processen, zoals is weergegeven in bijlage A. In figuur 5 zijn de in- en outputs van SCOR vertaald naar herkenbare begrippen voor de bouwsector. Deze informatie inputs en outputs zijn in bijlage B verder gedefinieerd. De in- en outputs corresponderen met figuur 4 in paragraaf 2.3, aangezien hier bouwplanningen, voorraadplanningen en transportplanningen worden benoemd als belangrijkste planningen voor de controltower. Hierbij zijn de eisen en wensen die door de opdrachtgever worden gesteld en de beschikbare middelen, leidend voor de Plan processen. De projectplanning hangt nauw samen met de bouwplanning. Beide zijn input voor de Source- en Make processen op de bouwplaats. Voor het Source proces is verder het afsluiten van contracten en het bestellen van producten of diensten belangrijk. Output informatie van Source, zoals voorraadbeschikbaarheid en ontvangstgegevens zijn onder andere inputinformatie voor Make. Verdere belangrijke inputs voor Make zijn bouwplanning, bouwmethoden, - procedures en -processen en de bouwactiviteiten.
WP2.1 Controltower
| 14 mei 2015
25 / 28
-Specificaties van de opdrachtgever -Beschikbare middelen (source en make) -Projectplanning -Bouwplanning (6 weken en weekplanning)
Plan
-Specificaties van de opdrachtgever -Beschikbare middelen (source en make) -Projectplanning -Bouwplanning (6 weken en weekplanning)
-Productspecificaties -Raamcontract -Aanleverschema &-specificaties Projectplanning -Bouwplanning (6 weken en weekplanning)
-Ontwerp -Oplevermoment (-en) -Projectplanning -Bouwplanning (6 weken en weekplanning) -Bouwmethoden, - procedures & -processen -Bouwactiviteiten -Voorraadbeschikbaarheid -Aanleverschema -Ontvangstgegevens -Afval- & retourenbeheer
Source
-Raamcontract -RFP/RFQ -Voorraadbeschikbaarheid -Inkooporder (bestellingen) -Ordergegevens -Aanleverschema -Ontvangstgegevens
Make
(
Deliver
)
-Projectplanning -Bouwplanning (6 weken en weekplanning) -Bouwmethoden, -procedures & -processen -Bouwactiviteiten -Inkooporder (bestellingen)
Figuur 5, input en output informatie van de bouwplaats in relatie tot de basisprocessen van de bouwplaats.
4.5
Bouwlogistieke KPI’s Voor de invulling van KPI’s is door het consortium een rapport WP2.2., ontwikkeling prestatie-indicatoren voor bouwlogistiek opgeleverd. Dit rapport geeft inzicht in de te ontwikkelen metingen in de bouwlogistieke processen. Om de processen daadwerkelijk te meten is informatie benodigd, zoals start- en stoppunten van een te meten proces alsook de informatie waarmee de KPI wordt gemeten, zoals hoeveelheden. Het rapport van WP2.2. geeft aanknopingspunten voor de benodigde informatie om de KPI’s te kunnen meten. Zie bijlage C voor een overzicht waarbij de categorie (o.b.v. SCOR Metrics), de betreffende KPI’s, de omschrijving en in de laatste kolom de benodigde informatie voor het kunnen meten van de KPI gegeven staan. In bijlage C is tevens een schets opgenomen van een bouwlogistieke keten, met daarin het gedeelte van het proces, waar de KPI’s betrekking op hebben. De controltower zal ook moeten kunnen voorzien in de informatie, benodigd voor deze metingen. Het betreft voornamelijk informatie met betrekking tot de leveringen en de kwaliteit van de leveringen, de producten, voorraden en klachtenregistratie (zie bijlage C voor verder gespecificeerde informatiebehoefte voor het meten van de KPI’s). De informatie voor het meten van KPI’s zal verder gespecificeerd worden in een nog op te leveren meetplan.
WP2.1 Controltower
5
| 14 mei 2015
26 / 28
Aanbevelingen voor vervolg Voorgaande paragraaf en hoofdstukken beschrijven hoe afstemming in de bouwlogistieke processen kan plaatsvinden. De beschrijving betreft het wensbeeld, waarin de controltower dynamisch de bouwlogistieke processen aanstuurt met toepassing van verregaande vorm van informatie-integratie en toepassing van geavanceerde informatie technologische toepassingen. Dit wensbeeld is niet direct te realiseren. Een eerste stap die gezet moet worden is daarom een nu realiseerbare controltower op te zetten. Dit zal een meer statische vorm zijn dan hierboven beschreven, waarbij de controltower mogelijk een informatie-hub zal zijn waarbij met name prestatiemeting en monitoring centraal zal staan. Om de mogelijkheden te onderzoeken kan vanuit het wensbeeld, zoals hierboven geschetst, met de partijen in het bouwproject het gesprek worden aangegaan of zij bereid zijn de betreffende informatie te delen en onder welke voorwaarden zij de informatie willen delen. Deze informatiedeling kan in eerste instantie eenvoudig worden opgezet door laagdrempelige technologie te gebruiken (zoals mail en telefoon). Vanuit het wensbeeld, waarbij hoogwaardige technologische toepassingen nodig zijn voor het mogelijk maken van de informatiedeling, zal het gesprek aangegaan moeten worden met diverse leveranciers van ICT (zoals ERP, WMS, TMS, BIM en communicatieplatformen). Ook zullen kritieke prestatie-indicatoren op afstemming en informatievoorziening tussen ketenpartijen moeten worden opgesteld. Op deze manier wordt inzicht verkregen in de mate van afstemming en informatievoorziening, omdat een gebrek aan deze afstemming leidt tot niet afgestemde processen en slechte prestaties van de bouwlogistieke ketens. Bottlenecks in de afstemming en informatievoorziening kunnen grote gevolgen hebben voor de operationele processen, die worden gemeten door de opgestelde operationele KPI’s en de mogelijke consequenties hiervan. De al geformuleerde KPI’s met betrekking tot de operationele processen (zie hoofdstuk 2) zal verder gespecificeerd moeten worden in een nog op te leveren meetplan. Hierin moet de benodigde informatie benodigd voor deze KPI verder gespecificeerd worden. Het wensbeeld bevat verregaande vormen van informatiedeling, maar nog niet bekend is welke aanvoerketens welke informatie precies nodig hebben. In aanvulling op de informatievoorziening op de bouwplaats is het daarom nodig verder onderzoek te doen naar informatiebehoeften en de informatievoorziening in de aanleverende ketens, waarna het van belang is te onderzoeken op welke manier het best passend in de informatiebehoefte kan worden voldaan.
WP2.1 Controltower
6
| 14 mei 2015
27 / 28
Bibliografie Adriaanse, A., & Voordijk, H. (2005). Interorganizational communciation and ICT in construction projects: A reveiw using metatriangulation. Construction innovation, 159-177. Adriaanse, A., Voordijk, H., & Dewulf, G. (2010). The use of interorganisational ICT in United States construction projects. Automation in Construction, 73–83. Altintas, A. (2013). Bouwlogistiek 2.0. Delft. Beleidscommissie Bouw Methoden en Technieken. (1993). NEN 2574. Tekeningen in de bouw - Indeling van gegevens op tekeningen voor gebouwen. Cape Group. (2013). White paper Supply Chain Control Tower. Cape Group. Commissie
van
laarhoven.
(2008).
Logistiek
en
Supply
Chains:
Innovatieprogramma. Commissie van Laarhoven. Cus-Babic, N., Rebolj, D., Nekrep-Perc, M., & Podbreznik, P. (2013). Supply-chain transparency within industrialized construction projects. Computers in Industry, 345–353. Derikx, S. (2012). De logistieke kostenverdeling binnen de bouw. Delft. Dijkhuizen, M. v., & Vrijhoef, R. (2015). Ontwikkeling van een set prestatie indicatoren voor bouwlogistiek. Utrecht. Dinalog.
(2014,
10
8).
Dinalog,
4C.
Opgehaald
van
Dinalog:
http://results.dinalog.nl/4c/orientation/ Donkervoort, R., Geurts, C., Klerks, S., & Kroon, J. d. (2009, maart 31). Prefabricage. Dubois, A., & Gadde, L. (2000). Supply Strategy and network effects, Purchasing behaviour in the construction industry. Purchasing & Supply management, 621-631. Duurzame Logistiek in de Bouw. (2013, november 29). Opgeroepen op september 4,
2014,
van
Innovatie-estafette:
http://www.innovatie-
estafette.nl/Doorbraken/2013/IE-2013Innovatiegids/article/10357/Duurzame-Logistiek-in-de-Bouw Engelbregt, J., & Kruijer, N. (2009). Warehousing en fysieke distributie. Amsterdam: Boom Onderwijs. Gelder, B. v., & Rinsma, R. (2013). Bouwlogistiek: een reflectie op het verleden, een visie op de toekomst. Rotterdam. Heijden, J. v. (1995). Towards organisational redesign in EDI partnerships, Naar organisatieherontwerp
in
EDI-samenwerkingsverbanden.
Erasmus Universiteit Rotterdam.
Rotterdam:
WP2.1 Controltower
| 14 mei 2015
28 / 28
Hoekstra & Romme. (1993). Op weg naar integrale logistieke structuren. Deventer: Kluwer. Hogeschool Rotterdam. (2015). Information flows within construction logistics. Rotterdam. Janssen, G., Amstel, W. P., Quak, H., Merrienboer, S. v., & Balm, S. (2012). Aan de slag met samenwerking in de logistiek. Klerks, S., Lucassen, I., Aa, S. v., Janssen, R., Merriënboer, S. v., Dogger, T., et al. (2012). Bouwlogistiek: Cruciaal in efficient en duurzaam bouwen. TNO Technologiecluster. Kolet, F. (2012). Naar een duurzame bouwlogistiek. Rotterdam. Kumar, K., & van Dissel, H. (1996). Sustainable collaboration, Managing conflict and cooperation in interorganizational systems. MIS Quarterly, 179-300. Logistiek, TKI. (2014). 4C in Bouwlogistiek. 2. Merrienboer, S. v. (2013). Best Practices in Bouwlogistiek. Delft: TNO. Moberg, C., Cutler, B., Gross, A., & Speh, T. (2002). Identifying antecedents of information exchange within supply chains. International journal of physical distribution & logistics, 755-770. Platform logistiek in de bouw. (2013). Factsheet bouwlogistiek. Saeed, K., Malhotra, M., & Grover, V. (2011). Interorganizational system characteristics and supply chain integration: An empirical assessment. Decision sciences, 7-42. Thompson, J. (1967). Organizations in Action. New York, NY: McGraw-Hill. TNO. (2011). Bouwlogistieke oplossingen voor binnenstedelijk bouwen. Delft. TNO. (2013). Project Plan en -aanvraag: 4C in bouwlogistiek. Delft. Viljamaa, A., & Peltomaa, I. (2013). Intensified construction process control using information integration. Automation in construction, 1-8. Visser, H., & van Goor, A. (2008). Werken met Logistiek. Groningen: WoltersNoordhoff. Vries, A. d. (2012, december). Logistics & SCM Bouwlogistiek. Rotterdam. Vrijhoef, R. (2011). Suppy Chain Integration in the building industry. Amsterdam: IOS Press. Wamelink, J. (2009). Inleiding Bouwmanagement. Delft: VSSD.
WP2.1 Controltower
A
| 14 mei 2015
Bijlage A | 1/3
Informatie inputs en outputs operationele logistieke bouwplaats processen De operationele supply chain processen worden aangestuurd met informatie. Elke procescategorie heeft informatie inputs en outputs om het uiteindelijke werk uit te kunnen voeren. Het SCOR model definieert de input en outputs van de processen, aan de hand van workflows. Onderstaande tabel geeft per proces (P1, P2, P3, P4, S1, S2, S3 en M3) uit het thread diagram (zie hoofdstuk 2), de informatie inputs en de outputs van dat proces. De afbakening is gemaakt in de processen van de bouwplaats en de informatie die beschikbaar is op de bouwplaats De inputs komen vanuit verschillende processen en de outputs zijn weer input voor andere processen. Zodoende is in onderstaande tabel in de eerste kolom het proces weergegeven (kolom 1) waarvoor informatie nodige is (input, kolom 2). Deze input komt vanuit verschillende andere processen (procescode, kolom 3). Het proces (kolom 1) genereert ook output informatie, deze is genoemd in kolom 4 (output). Deze outputs worden gebruikt als input bij andere processen (output proces, kolom 5). Van belang is op te merken dat inputs en outputs niet direct aan elkaar gekoppeld zijn, maar juist door het proces ontkoppeld worden. Na de weergave in tabelvorm is de informatie weergegeven in de structuur van het threaddiagram. Hierbij zijn de procesconfiguraties van de bouwplaats (P1, P2, P3, P4,S1, S2, S3 en M3) opgeknipt en zijn de inputinformatie en de outputinformatie weergegeven in relatie tot deze processen. Proces
P1
P2
P3
Input Customer Requirements
Input proces
Output
Output proces
Other
P5;P4;P3;P2
Delivery Plans
P4
Production Plans
P3
Supply Chain Plan Supply Chain Requirement Supply Chain resource
Shipments
D1
Sourcing Plans Supply Chain Requirements Supply Chain Resources
P2
Workflow
P1
Delivery Plan
P4
Product Requirement
P2
Product On Order
S3;S2;S1
Product Source
Product Requirement
P2
Sourcing Plan
P2 D3;D2;D1;S3;S2;S1; P5;P4;P3;P1
Product Source
P2
Workflow
P2
Production Plan Source Return requirements
P3
Supply Chain Plan
P1
Workflow (Approved) Staffing Plan
P2 Production Requirement
P3
P1 P1
P1 P1
P5
E4
WP2.1 Controltower
P4
| 14 mei 2015
Delivery Plan Production Requirement
P4 P3
Production Resources Return Production requirements
Production Resource
P3
Workflow
Production Schedule
M3;M2;M1
Production Plan
Sourcing Plan
P2
Supply Chain Plan
P1
Workflow Delivery Requirements Inventory Availability/ Delivery Date
P3
Production Plans
P3
Sourcing Plans
P2
Supply Chain Plans
P1
Workflow Load Information Delivery Requirements Receipt Verification
S1;S1
Scheduled Receipts
S1
P4
S3
P3 P3 P3 E4;P1;P2:P4;P5;M3; D3
Delivery Plans Delivery Requirements Delivery Resources and Capabilities Item Stocking Requirements
D3;M3;P5;P3;P2;P1
D3;M3;P5;P4;P2;P1
P4
Production Plan Stocking Requirements
D1;D2;D3
Workflow
P4
D1;D2
P4 P4 D4
D4
P4
S1
S2
Bijlage A | 2/3
Customer Replenish Signal Customer/Purchase Order Daily Replenishment Requirements Deliver Contract Terms Finished Product Release Procurement Signal (Supplier)
D1 D1 D4 D1 D3;D2;D1 Other
Product On Order
P2
Receipt Verification
S1;S1 D4;D1;M3;M1;S1
Receipt Verification Source Execution Data
S2
Scheduled Receipts Finished Product Release
M2
Inventory Availability
Sourcing Plans
P2
Other
Transferred Product
S2
Payment Information Procurement Signal (Supplier) Product On Order
P2
Receipt Verification
S2;S2
Scheduled Receipts
M3;M2
Transferred Product ETO Request for Proposal Finished Product Release
S1
D3;M3;P2;P1
D3;D2 D2;D2;M3;M2;P3;P2; P1
Other
ETO Spec or Design
Other
Other
Product
D3;D2;D1
Production Schedule
M3
Receipt Verification
S3
Inventory Availability Procurement Signal (Supplier)
Scheduled Receipts
S3
Product On Order
P2
Sourcing Plans
P2
Receipt Verification
S3;S3
D3
Other
WP2.1 Controltower
M3
| 14 mei 2015
Bijlage A | 3/3
Supplier Agreement
S3
RFQ/RFP
D3
Transferred Product
S3
Scheduled Receipts
M3;S3
Supplier Agreement
S3
Transferred Product
S3
Inventory Availability Methods, Procedures, Processes
D3;P3;P2;P1
Delivery Plans
P4
Engineering Design
Other
M3 D3;D3;M3;S3;S2;S1; P3
Information Feedback M3
Production Schedule
Inventory Availability Methods, Procedures, Processes
S3;S2;S1
Replenishment Signal S3;S3;S2;S2;S1;S1
M3
Workflow
Order Information
D3
Production Plans
P3
Production Schedule
M3
Scheduled Receipts
S3;S2;S1
Waste Produced
M3
Workflow
M3
M3
WP2.1 Controltower
B
| 14 mei 2015
Bijlage B | 1/4
Definities informatie beschikbaar in het bouwproject In figuur 5 zijn de informatie inputs en outputs weergegeven per proces. De definitie van deze informatie is hieronder gegeven. - Specificaties van de opdrachtgever: Eisen en wensen die door de opdrachtgever worden gesteld aan het te bouwen object. De exacte vorm van specificaties zijn afhankelijk van de contractvorm, waardoor het delen van deze specificaties in verschillende bouwfases kan voorkomen. - Beschikbare middelen (Source en Make): De middelen die beschikbaar zijn voor het te bouwen object op tactisch niveau, zowel binnen de bouwonderneming, als voor de leveranciers. Voor het make proces zijn dit onder andere de beschikbaarheid van materiaal, materieel en personeel in de tijd. - Projectplanning: De grove, overall planning van het project, waarin wordt aangegeven wanneer het project start en eindigt met daarin de verschillende bouwfases. - Bouwplanning (6 weken en weekplanning): De specifieke planning, waarin wordt aangegeven welke bouwactiviteiten moeten worden uitgevoerd. - Productspecificaties: Eisen die worden gesteld aan de op te leveren (deel)producten, zowel van het te bouwen object, als producten voor de leveranciers. - RFP/RFQ: Het commerciële inkoopproces start met specificeren van de producten, waarna een productvoorstel (RFP) en een prijsaanvraag (RFQ) wordt gedaan bij de leverancier. - Raamcontract: Het commerciële inkoopproces wordt afgesloten met het afsluiten van raamcontracten (contracteren) met leveranciers op basis waarvan in de operatie (logistieke inkoop) bestellingen worden geplaatst. - Aanleverschema & -specificaties: Op basis van de inkooporder worden aanleveringen ingepland. Hiermee is ook informatie beschikbaar over de aanlevering, waaronder soort en hoeveelheid van het product en afleverlocatie, -dag en –tijd. - Voorraadbeschikbaarheid: Gegevens over voorraden op de bouwplaats, bij de leverancier of elders in het distributieproces. - Inkooporder (bestellingen): Het logistieke inkoopproces start met het plaatsen van bestellingen voor het aanvullen van de voorraad of het aanleveren ten behoeve van directe verwerking in de bouw. - Ordergegevens: Gegevens van de inkooporder, waaronder soort en hoeveelheid van het product en afleverlocatie, -dag en –tijd. - Ontvangstgegevens: Gegevens over de ontvangen producten, zoals soort en hoeveelheid van het product, beschikbaarheid en opslaglocatie. - Ontwerp: Het ontwerp van het gebouw, weergegeven in bouwtekeningen en bestek en het ontwerpen van (deel)producten door leveranciers. - Oplevermoment (-en): oplevermoment zowel voor het gehele project alsook voor gedeeltes van het project of werk in onderaanneming. - Bouwmethoden, - procedures & -processen: De manier van bouwen en de te volgen procedures hierbij. - Bouwactiviteiten: De uitvoering van de bouw, waarbij de inzet van bouwpersoneel, -materiaal, en –materieel op detailniveau wordt gespecificeerd.
WP2.1 Controltower
-
| 14 mei 2015
Bijlage B | 2/4
Afval- & retourenbeheer: Het beheren van afvalstromen naar de afvalverwerker en het beheren van retourstromen terug naar de leveranciers (en eigen materieeldienst). In de huidige situatie van de bouw is dit voornamelijk gericht op retouren van materieel.
WP2.1 Controltower
C
| 14 mei 2015
Bijlage C | 3/4
Prestatie-indicatoren voor project 4C in bouwlogistiek Het monitoren gaat op basis van een aantal Key Performance Indicatoren (KPI’s). Deze bijlage geeft aan welke KPI’s gemeten zullen worden en in welke gedeelte van de supply chain deze zich bevinden. Voor het meten van KPI’s bestaat al een geüniformeerd model: Supply Chain Operations Reference Model, kortweg SCOR-model. Dit SCOR model gaat uit van 5 attributes met KPI’s daarbinnen: Reliability, Responsiveness, Agility, Costs, Assets. Opvallend is dat binnen dit model nog geen milieu attribute bestaat. Ook in de literatuur en bij projecten in met name Engeland zijn KPI’s voor bouwlogistiek te vinden. Deze zijn onder te verdelen in de 5+1 attributes van het SCOR-model. Het consortium heeft geïnventariseerd welke KPI’s de projectteams willen meten op de twee proeftuinen. Uit deze inventarisatie kwam een zeer lange lijst van wel meer dan 80 prestatie-indicatoren. Het is onmogelijk en ook niet wenselijk om alle prestatie-indicatoren te monitoren. Daarom geeft deze bijlage een selectie van KPI’s welke het consortium op de proeftuinen gaat meten. Categorie
Indicatoren
Leverbetrouwbaar- Percentage heid (reliability) leveringen op tijd 1
Percentage leveringen conform eisen 2 Snelheid (responsiveness)
Lostijden vrachtwagens op bouwplaats 3 Wachttijden bouwplaats voor transporten 4
Flexibiliteit (agility)
Kosten efficiëntie (costs)
Doorlooptijd afroep hub 5
Omschrijving Levering binnen tijdframe van +/- aantal minuten tov afgesproken tijd Leveringen waar niets/iets mee is, en aard van probleem Hoe lang moet een vrachtwagen wachten op materieel/personeel om gelost te worden Vice versa, hoe lang moet materieel/personeel wachten tot vrachtwagen gelost kan worden Hoe lang te voren moet een afroeporder geplaatst worden bij hub
Doorlooptijd leverancier 6
Hoe lang te voren moet een leverorder geplaatst worden bij leverancier
Afgelegde kilometers transport 7
Kilometers afgelegd voor project, kosten
Vermeden kilometers transport 8
Kilometers vermeden voor project, kosten
Wachttijd gedurende
Tijd verloren per transport, kosten
Benodigde informatie # Leveringen # Tijdig geleverd # Leveringen # foutloos geleverd Informatie over de afwijkingen # Leveringen Aankomsttijd Starttijd lossen Vertrektijd # Leveringen Aankomsttijd Starttijd lossen Vertrektijd Tijdstip order intake Tijdstip order verzending Tijdstip order ontvangst @ bouwplaats Verwerkingstijd order Tijdstip plaatsen order Tijdstip order verzending Tijdstip order ontvangst @ bouwplaats Verwerkingstijd order Locatie ophaalpunt Locatie tussenstops Locatie afleverpunt Kostprijs per kilometer Locatie ophaalpunt Locatie tussenstops Locatie afleverpunt # directe leveringen Kostprijs per kilometer # Leveringen Aankomsttijd
WP2.1 Controltower
| 14 mei 2015
transport, bouw, hub 9
Consolidatieen beladingsgraad (assets)
Consolidatiegraad hub 10
Aantal transporten
Voorraden op hub 11
Milieu en omgeving
beladingsgraad gewicht, met name ruwbouw 12
Aantal kg lading
beladingsgraad volume, met name afbouw 13
Aantal m3 lading
CO2 uitstoot 14
Hoeveelheid brandstofverbruik x factor CO2
Afvalreductie
Hoeveelheid minder afval, verpakking, materiaalverspilling, snijverlies a.g.v. hub Aantal klachten/ incidenten door parkeren, oponthoud, geluid, stank etc. a.g.v. bouwverkeer
15
Overlast van bouwverkeer naar bouwplaats 16 (Op basis van Dijkhuizen & Vrijhoef, 2015)
Bijlage C | 4/4
Starttijd lossen Vertrektijd # leveringen aan de HUB # leveringen aan de bouwplaats vanuit HUB # directe leveringen aan de bouwplaats # productsoorten op voorraad # producten op voorraad Omloopsnelheid van de producten Waarde van de voorraad # leveringen Locatie ophaalpunt Locatie tussenstops Locatie afleverpunt # Kg per levering, bestemd voor bouwproject # Kg per levering tussenstops # leveringen Locatie ophaalpunt Locatie tussenstops Locatie afleverpunt # M3 per levering, bestemd voor bouwproject # M3 per levering tussenstops Locatie ophaalpunt Locatie tussenstops Locatie afleverpunt # directe leveringen CO2 uitstoot gebruikte vervoersmiddel Hoeveelheid afval per productsoort (gewicht/ volume) Klachtenregistratie
