ekenen blplju, HEEK Bnu wdiensi Rijkswaterstaal Postbus LA Utrecht BIBLIOTHEEK BOUWDIENST RIJKSWATERSTAAT .& >.VA

b l p L J U , HEEK Bnu wdiensi Rijkswaterstaal Postbus 20.000 3502 LA Utrecht

BIBLIOTHEEK BOUWDIENST RIJKSWATERSTAAT NR

^

.&£>.VA

ekenen lechri echnisch

VISIE TECHNISCH REKENEN BIJ DE BOUWDIENST

Pagina 2/16

Visie Technisch Rekenen bij de Bouwdienst

ekenen lechr^l echnisch VISIE TECHNISCH REKENEN BIJ DE BOUWDIENST

definitief

Opsteller Rapport d.d.

: Niels Meijer - I&A-• Technisch Rekenen : BS 2000-00027 : 01/02/2001

Acceptatie

:

Principaal: Hans Hendriks d d

- tgfc//wi

Bevoegd gezag: Hans Jongedijk dd

a

c

paraaf:

- u faltat

Programmaleider: Niels Meijer

Bouwdienst Rijkswaterstaat

/

paraaf:

.

J paraaf:

b

w .

;

-"7""

2001


Pagina 3/16

1. INLEIDING

4

2. UITGANGSPUNTEN

5

3. BESCHOUWING ENGINEERING

7

4. CIVIEL TECHNISCHE ONTWIKKELINGEN

10

5. ICT TRENDS EN ONTWIKKELINGEN

10

6. INVULLING DOOR TECHNISCH REKENEN

13

7. SAMENVATTESG. CONCLUSIE EN AANBEVELINGEN

15

Op de omslag: Een grafische representatie van een klassieke rekenmethode om extreme belastingen met bijbehorende voertuigstanden op een brug of viaduct te bepalen. Deze rekenmethode draagt de exotische naam Auswertung en wordt nog steeds gebruikt bij het ontwerpen van bruggen en viaducten. Tevens wordt deze methode ingezet bij bepalen van de toelaatbaarheid van speciale transporten op bestaande bruggen en viaducten.


2001


Pagina 4/16

1. Inleiding Deze adviesnota geeft aan waar de accenten binnen het I&A aandachtsveld Technisch Rekenen de komende 4 jaar moeten komen te liggen. De omgeving verandert. Het 66n en ander wordt duidelijk wanneer het VisieTraject RWS (met o.a. marktbenutting) wordt geanalyseerd. Ook het StrategischPlan Bouwdienst 2001-2005 met daarin "discipline-deskundigheid leveren in extern gevormde projectteams" geeft aan dat er een verandering op komst is dan wel is ingezet. Enkele vragen die opkomen zijn dan: 'Wat is de impact op het engineeringswerk van de Bouwdienst ?', 'Wat zijn de middelen die daarvoor nodig zijn ?', 'Wat zijn de kennis & kunde aspecten die hier een rol spelen ?'. Om antwoord op bovenvermelde vragen te krijgen zijn er in mei tot en met September 2000 negen interviews gehouden met de engineeringsafdelingen van de Bouwdienst (DIT, DIU, DIZ, NIC, NIS, NIW, WBN, WBR en BSW). In het totaal hebben 22 (onder)afdelingshoofden deelgenomen aan de interviews die per stuk ongeveer twee tot twee en een half uur duurden. Verslagen van deze interviews zijn teruggekoppeld aan de geinterviewden. Achtereenvolgens komen aan de orde: • Uitgangspunten; • Beschouwing engineering; • Civiel Technische ontwikkelingen; • ICT trends en ontwikkelingen; • Invulling door Technisch Rekenen; • Samenvatting, conclusies en aanbevelingen. Nota bene: Volgens hedendaagse theorieen over proces verbetering moeten de bijbehorende initiatieven aan drie voorwaarden voldoen, namelijk moeten, kunnen en willen. Daarover het volgende: Deze adviesnota is op gezet met het 'Wat moeten we ?' als drijfveer, aangezien het 'Wat kunnen we ?', zijnde de ICT-techniek en middelen, steeds rninder een bottle-neck is. Hettijdperkvan de zogenaamde technology-push hebben we achter ons gelaten. Het kunnen, het operationeel maken van de rekentools, is overigens geen 'eitje'. Integendeel, goede intuitieve betrouwbare technische rekentools zijn niet eenvoudig te maken of te vinden. Essentieel voor het operationeel maken van rekentools is een intensieve dialoog met gebruikers en het werken met kundige leveranciers. Dit zijn dan ook primaire voorwaarden voor succes ! Blijft over het willen; in hoeverre zijn medewerkers gemotiveerd om de aangeboden tools te gebruiken. Voor rekentools geldt dat naast het gebruiksgemak, het vertrouwen in de resultaten een belangrijke rol speelt. Deze 'vertrouwenskwestie' bepaalt in hoge mate de motivatie van medewerkers om bepaalde rekentools in te zetten. Praktisch komt het hier op neer dat er een intensief after-sales traject moet worden opgestart bij de introductie van nieuwe rekentools. Een after-sales invulling bestaat dan uit opleiding, training-on-the-job, inhoudelijke ondersteuning (know-how) en een dialoog met de gebruikers. :•,


2001


Pagina 5/16

2. Uitgangspunten Tijdens de interviews zijn er enkele noodzakelijke uitgangspunten vastgesteld. Leidend hierin zijn geweest het VisieTraject RWS en het Strategisch Plan 2000-2004. Wat wil de Bouwdienst ? Kernvraag is eigenlijk: Waar gaan we naar toe als Bouwdienst ? 1. Opereren als ingenieursbureau; of 2. Initierend en controlerend deskundig ingenieursbureau; of 3. Alleen maar organiserend ingenieursbureau a la een Rail Infra Beheer of een Bouw en Woning Toezicht, alle inhoudelijke (voorontwerp/ontwerp/bestek/uitvoering) en controlerende taken uitbesteden. RWS Visie Traject in ogenschouw genomen lijkt een keuze voor 2, het initierend en controlerend deskundig ingenieursbureau. het meest opportuun voor de komende 4 a 5 jaar. Deze keuze sluit ook goed aan bij het begrip deskundig opdrachtgeverschap. De Bouwdienst is niet meer het productiebedrijf van weleer. De meerwaarde van de Bouwdienst zou dan moeten zitten in: • Het kundig kunnen aansturen van publieke bouwwerken; de regisseursfunctie; • Het kundig kunnen afwegen van alternatieven (de goede technische/economische keuzes maken); • Voortraject, planstudie, verkenning en globaal ontwerpen; • Als neutrale partij ingenieursbureaus, diensten/directies en aannemers laten samenwerken; • Adviezen aan hogere en lagere overheden, discipline deskundigheid t.b.v. externe projectteams; • Civiel technisch noviteiten inzetten, innovatie stimulerenen de risico's te calculeren; • Senioriteit hebben, kortom boven de materie staan, een kundig gesprekspartner zijn • Het gemeenschappelijk belang met de opdrachtgever (overheidsbelang); • Lifecycle-optimalisatie van infrastructuur gericht op optimalisatie van het maatschappelijk rendement. Hoe komt de Bouwdienst aan de juiste expertise ? Er zijn grofweg twee mogelijkheden om aan deze expertise te komen: Het kopen van de kennis (het zgn. Barcelona model) of jonge ingenieurs opleiden tot deskundige engineers die in de vele aandachtsgebieden van de Bouwdienst zijn in te zetten (het zogenaamde Ajax model). Eigenlijk is men het unaniem eens om het Ajax model toe te passen. De motivatie daarvoor is: • • • • •

Beste garantie m.b.t. instandhouding van deskundig opdrachtgeverschap; De juiste cultuur kan worden bewerkstelligd; Samenhang tussen de mensen; Negatief effect op vergrijzing van de organisatie; De slechte beschikbaarheid van externe deskundigen en de potentiele prijs die het heeft (inkoop moeilijk, duur en eindig); • Positieve uitstraling, trots en herkenbaarheid.


2001


Pagina 6/16

Voorwaarden hiervoor zijn: • Kweekmogelijkheid hebben; • Voldoende werk; • Voldoende uitdaging in het werk; • Jong talent kunnen aannemen en een scout mogelijkheid; • Voldoende doorstroming; • Arbeidssatisfactie; • 'Club'liefde. Gegeven het voorgaande, kan als primair Bouwdienst doel worden geformuleerd: Het op peil houden van de juiste engineerings expertise om het aankomende werkpakket kundig te kunnen uitbesteden en kundig te kunnen controleren. Aangezien er tussen engineerings expertise en TR-middelen een belangrijke relatie ligt is met dit uitgangspunt deze nota opgezet. , Nota bene:

:

Het is vaak die passieve kennis & kunde van engineering die de huidige projectleiders (en managers) succesvol laat opereren. Kortom als we praten over engineeringswerk, waaronder technisch rekenwerk valt, praten we over werk waarmee cruciale kennis wordt opgedaan ! Het blijkt dat kennis & kunde voor een belangrijk deel wordt opgebouwd in een intensieve interne opleiding binnen de Bouwdienst.


2001


Pagina 7/16

3. Beschouwing engineering Wat wordt verstaan onder engineering ? Alle technische activiteiten die nodig zijn om de specificaties van een (civiel) kunstwerk vast te leggen en/of te toetsen v66r en na realisatie. Technisch Rekenen in de engineering. Onderkende technische activiteiten voorafgaand aan realisatie zijn: • Opstellen programma van eisen (lopende het project zo nodig actualiseren); • Risico analyse (lopende het project regelmatig actualiseren) (TR); • Bepaling functioneel ontwerp (CAD + TR); • Prijsbepaling (lopende het project van globaal naar gedetailleerd); • Bepaling vormgeving en geometrie (CAD + TR); • Dimensioneringsberekening (voor)ontwerpfase (TR); • (Voor)ontwerptekeningen (CAD); • Dimensioneringberekeningen Voorbereidingsfase (TR); • Bestekstekeningen (CAD); • Bestek; • Detailberekeningen (TR); • Detailtekeningen (CAD). Tijdens deze activiteiten is optimalisatie en innovatie mogelijk, gedacht moet worden aan: • Nieuwe mate rial en; • Nieuwe constructies en vormen; • Schaal vergroting; • Life-cycle aspecten. In de diverse engineerings fases wordt van grof naar fijn gewerkt, de zogenaamde: voorontwerp-, ontwerp-, besteks- & detailtekeningen & berekeningen. Technisch Rekenen tijdens de engineering staat voor: • Veiligheid van constructies; • Betrouwbaarheid & verantwoordelijkheid; • Innovatie. Kijkend naar de formatie opbouw van een ontwerpburo ligt de capaciteitsverdeling voor een gemiddeld Bouwdienst project (kunstwerk) ongeveer als volgt: Regel- en administratiefwerk / tekenwerk / rekenwerk = 50% / 30% / 20%


2001


Pagina 8/16

Engineering vindt plaats in alle fasen voor, gedurende en na realisatie van een kunstwerk.In elke fase heeft de engineering zijn eigen karakteristiek.

Voortraiect In het voortraject zitten engineerings activiteiten zoals het maken van haalbaarheid studies en het opstellen van programma's van eisen. Over het algemeen gaat het om het toepassen en combineren van opgedane engineeringskennis. Schetsen en kleine rekensommetjes maar ook risicoanalyses zijn noodzakelijk om te komen tot een referentie ontwerp. Indien het gaat om het meer visueel uitwerken van varianten wordt dit, over het algemeen, voorontwerp genoemd. Ook de activiteiten benodigd om PPS-en in gang te zetten zitten in het voortraject. Uitbesteding van bijbehorend rekenwerk ligt minder voor de hand.

Voorontwerpfase Kan primair worden gezien als een ondersteunende activiteit aan het voortraject. Zo kan een referentieontwerp gezien worden als een voorontwerp. Het doel bij voorontwerpen is het kundig uitwerken van varianten. Het gaat hier om visualisatie (3D), eenvoudige rekensommen (meestal ID, denk ook aan het sigarenkistje rekenen) en het toepassen van ontwerpen vuistregels. Soms is het nodig om op een detail in te zoomen, echter 3D tekenen is hier overigens niet automatische 3D rekenen. De voorontwerpfase doet luchtigjes aan, maar er wordt in werkelijkheid zeer veel expertise ingezet ! De expertise die nodig is, meestal opgedaan in jaren lange ervaring in het ontwerp-, voorbereiding- en beheer & onderhoudsfase. Ook de zogenaamde noviteiten kennis (net ontwikkelde kennis) wordt hier toegepast. Het voorontwerp werk gebeurt nu eigenlijk op een 'houtje-touwtje' manier en kan omschreven worden als een creatieve chaos. Essentieel is vakbekwaamheid; kortom voorontwerp is het domein van deskundige engineers ! Uitbesteding van rekenwerk ligt ook hier minder voor de hand. Voorontwerp is overigens meer conceptueel


2001


Pagina 9/16

ontwerpen en minder construeren ! Het starten en formuleren van eventuele Build & Design opdrachten vindt over het algemeen vanuit deze fase plaats. Ontwerpfase & voorbereidingsfase (besteksfase) Deze traditionele taken lopen tot en met het besteksgereed maken van bouwwerken. Het doen van een beperkte hoeveelheid van dit soort werk wordt essentieel geacht in de Ajax-gedachte; het is namelijk de kweekvijver van de Bouwdienst engineers. Uit deze kweekvijver ontstaan de kundige projectleiders, de kundige managers, de kundige specialisten en de kundige (voor)ontwerpers. De stelling van alle afdelingen is dat een gedeelte van dit soort werk moet blijven worden gedaan om expertise op te bouwen en te behouden. Over het algemeen worden perjaar een project per soort per afdeling uitgewerkt (DI en Nl). Voor WB ligt dit anders, echter ook hier leeft de gedachte dat er een kritieke grens is tussen zelf doen en uitbesteden, men moet dan denken aan een 20%-80% verhouding. Gevolg van het beperkt zelf doen is, dat met deze activiteiten financieel gezien niet geconcurreerd kan worden met het bedrijfsleven. Tijdens het zelf doen breekt voor de Bouwdienst medewerkers het moment aan om te leren, m.a.w. kennis ontwikkeling, de kweekvijver. In deze kweekvijver moet zelfs ruimte zijn voor het maken van rekenmodellen om het gevoel voor gedrag van kunstwerken in de 'vingers' te krijgen. Realisatiefase Ook wel uitvoering genoemd en gebeurt door de aannemer. In deze fase is de hoeveelheid rekenwerk voor de Bouwdienst tot een minimum beperkt. Alleen in het geval van calamiteiten wordt een beroep gedaan op de Bouwdienst engineers. In die gevallen moeten alle registers kunnen worden opengetrokken. Uiteraard zijn vaak ook controletaken noodzakelijk; die zijn echter apart als taak benoemd. Uitbesteding van het calamiteitenrekenwerk is niet echt aan de orde i.v.m. vereiste snelheid van rekenen en gevoeligheid van bijbehorende informatie. Beheer & Onderhouds fase De beheer- en onderhoudsfase van civiele kunstwerken behoort tot op heden en ook in de nabije toekomst tot de verantwoordelijkheid van de Regionale Directies, deze roepen echter t.b.v. rekenwerk aan deze kunstwerken de Bouwdienst in. Gedacht moet worden aan vragen over uitbreidingen, reparatie, speciale transporten en calamiteiten. In dit soort werk zitten veel leermomenten (life-cycle). Ook dit is het domein van de ervaren engineers. Kennis ontwikkelen en kennis toepassen zijn hier aan de orde. Ook hier vindt uitbesteding plaats, belangrijk is wel dat er intensief contact is tussen de partijen opdat de ontwikkelde kennis kan worden gedeeld. Bij voorkeur zouden dit soort activiteiten intern moeten gebeuren gezien, de bovenvermelde kennis ontwikkeling. Controle taak Ook wel toetsen genoemd. In de controlewerkzaamheden zitten alle activiteiten die nodig zijn om het uitbestede engineeringswerk te toetsen op juiste constructieve aannames, uitgangsspunten, juiste berekening en het juiste norm gebruik. Ook komt het voor dat rekenwerkzaamheden, die tijdens de uitvoering plaats vinden, moeten worden gecontroleerd (denk aan bekistings- en montage berekeningen). Deze werkzaamheden kunnen als core business worden opgevat in een markt-denken. Essentieel is dat deze activiteit onafhankelijk kan gebeuren, het gaat hier om de veiligheid van een kunstwerk. De tijd die nodig is voor dit soort werkzaamheden is ongeveer 10% tot 15% van de tijd die het ingenieursbureau nodig had om het


2001


Pagina 10/16

engineeringswerk uit te voeren. Ook in de EKB aanpak zullen (deel)product-toetsen moeten worden uitgevoerd. 4. Civiel Technische Ontwikkelingen 4.1. Intern: Productstrategiee'n De productstrategieen leveren een zeer beperkt aantal directe aanknopingspunten. Deze aanknopingspunten zijn met name te vinden in nieuw te ontginnen disciplines, er wordt echter vaak verwezen naar standaard te verkrijgen software. Indirect zijn er meer aanknopingspunten (middels de proces benadering, met als gevolg accent verschuiving in engineerings-takenpakket). De indirecte aanknopingspunten zijn verwerkt in het vorige hoofdstuk; beschouwing engineering. 4.2. Extern: Civiel Technische noviteiten De volgende civiel technische ontwikkelingen met een relatie naar Technisch Rekenen zijn onderkent: • Verbeterde materialen (met name Hoge Sterkte Beton); • Nieuwe materialen (met name kunststof, aluminium); • Nieuwe bouwmethoden (met name boren van tunnels); • Verbeterde bouwmethoden; • Risicoanalyse van kunstwerken (betrouwbaarheid, foutenbomen); • Materiaal- en belastingnormen conform Eurocode (Europese regelgeving); • Verbeterde ontwerptechnieken. Benodigde aanpassingen in TR software worden vaak via de CUR en gebruikersgroepen in de Nederlandse TR software doorgevoerd. Deze aanpassingen gaan echter in evolutionair tempo. Van oudsher draagt de Bouwdienst op diverse niveaus bij aan de aanpassing van de GWWrekensoftware. Ook in de toekomst zal er een beroep worden gedaan op de Bouwdienst, er zal wellicht een andere rol moeten worden aangenomen, in een markt-denken namelijk 'De Bouwdienst initieert en stimuleert de markt'. Speciaal aandachtsaspect bij dit soort ontwikkelingen zal de controleerbaarheid van resultaten betreffen. (ref. controle taak)

5. ICT trends en ontwikkelingen 5.1 Internet Meest 'Hot' in deze hoek is E-business; voor Bouwdienst TR zou dit alleen slaan op het digitaal uitwisselen van bestanden en de daarbij benodigde gebruik van defacto standaarden. Wat voor impact (voordelen) zou 'the World Wide Web* verder op TR kunnen hebben: • Eenvoudig kunnen zoeken en vinden van (nieuwe) speciale/specifieke tools; • De neutrale Graphical User Interface (GUI). Vroeg of laat draait alles via een browser (bv Netscape) en is locatie van applicaties geen issue meer (zie volgende punt); • Applicaties remote (niet op de huidige locatie) gebruiken via zogenaamde Application Service Providers; • Eenvoudig kunnen uitwisselen van modellen (E-business) en 'concurrent engineering"', (met meerder mensen tegelijk, onafhankelijk van locatie aan een model werken). Dit laatste is echter meer op CAD werkzaamheden van toepassing; • Vakspecifieke (wereldwijde) discussiegroepen, -> kennis opbouw/deling;


2001


Pagina 11/16

• Virtueel leren, ook wel E-learning of distance learning, van het gebruik van een TR applicatie (video techniek/multimedia), kortom een cursus Just in Time; • Web-Help, elektronische Helpdesks; • Alleen nog maar elektronische handleiding; • Betaal wat gebruikt wordt (net als vroeger !). Punten die de voordelen ietwat zullen afremmen, dan wel nuanceren: • Performance over het net, wellicht in de toekomst met internet2 opgelost; • Welke kwaliteit/betrouwbaarheid heeft de gebruikte software ?; • Hoe krijgt men het vertrouwen in de te gebruiken TR-applicatie (opleidingsaspect); • De betalingsproblematiek. Het moge duidelijk zijn dat er nu en in de toekomst met name in de faciliterende en ondersteunende sfeer veel meer mogelijk zal zijn. Echter het remote gebruiken van TR-software zal een louter economisch en technisch vraagstuk zijn. Diversiteit in gebruik kan toenemen, maar zal vanwege de 'vertrouwenskwestie' (vertrouwen in resultaten) geen gigantische vormen aannemen. TR-software zal langzaam migreren naar een nieuwe Web-enabled softwaregeneratie. 5.2 Platformen Onder een platform wordt verstaan een computer met het daarbij behorende besturingssysteem (b.v. een PC met Windows 95) Een ander belangrijk issue is de integratie van platformen. Bij CAD is dit (nog) zo'n punt, bij TR is dit al vijf jaar geleden opgelost. Door het juist inzetten van connectivity tools kunnen alle TRgereedschappen vanaf een standaard Bouwdienst PC worden gedraaid. Ook in de toekomst zal dit een aandachtspunt blijven. 5.3 Document Management Systems Een ander item zijn Document Management Systems (DMS). Het CAD functioneel deelgebied heeft een dergelijk systeem, onder de noemer CADOBE, reeds ingevoerd en houdt met dit systeem het tekeningen productieproces onder controle. Gedacht moet worden aan vragen als 'Welke versie van de tekening is de juiste versie?, Welke documenten horen bij deze tekening?'. Voor technisch rekenen zou een DMS een heel ander doel hebben, meer gericht op het verleden (de Beheer & Onderhouds taak), 'Welke uitgangspunten zijn er gebruikt bij de berekening van de brug', 'Hoe hebben we de constructie toen geschematiseerd'. Niet het hergebruik van data staat centraal maar welke (reken) informatie kan ik onttrekken aan dat gene wat reeds geengineerd is (leerpunten). In het vakjargon wordt de sprekende term 'corporate memory' gebruikt. 5.4 Workflow Management De essentie van workflowmanagement, of in het Nederlands "werkstroombesturing", ligt in de scheiding die wordt gemaakt tussen de uitvoering en de besturing van operationele activiteiten. In de logistieke dienstverlening wordt het al jaren toegepast. Workflow kijkt vanuit een logistieke invalshoek naar gegevensverwerkende processen. Aangezien bij de uitvoering van rekenwerk vaak maar 6en individu betrokken is, is het voor rekenwerk sec geen issue. Alleen in het totaal van de engineerings activiteiten is de werkstroombesturing van belang. Er ligt geen TR focus op dit fenomeen.


2001


Pagina 12/16

5.5 Rekensoftware in de markt Wanneer de ontwikkeling van de belangrijkste Bouwdienst TR programma's in een 'bollenschema', met een as general-purpose versus special-purpose en een as junior engineer versus senior engineer, worden geplaatst ontstaat het volgende plaatje: ' - Special-purpose

General-purpose

Wat kunnen we hier uit afleiden ? Over het algemeen kan worden gesteld dat special-purpose (TR-software voor een specifiek engineeringsfenomeen) de focus is van de TR-software ontwikkel markt. Duidelijk is ook dat er voor de verschillende producten een grotere afstand bestaat tot het predikaat special-purpose. Bijvoorbeeld Plaxis maakt nu op basis van zijn generieke op grondmechanica gerichte eindige elementen methode programma een PLAXIS 3D Tunnel special. Overigens sluit special-purpose software, over het algemeen, beter aan bij de kweekvijver gedachte, het vertrouwen in dit soort software wordt sneller gecreeerd omdat er simpelweg minder mogelijkheden zijn. Het leren wordt versneld, de engineer krijgt meer aandacht voor de constructieve know-why dan voor de applicatie gerelateerde know-how ! Verder is bij de Nederlandse softwarebouwers samenwerking de trend. Zo is er o.a. samenwerking in tussen SCIA W+B en GeoDelft, TNO en Plaxis bv en SCIA W+B en TNO. Het gaat hier niet om fusies maar om het gezamenlijk op de markt brengen van producten. Tot nog toe zijn er nog geen producten van betekenis gelanceerd. Wel zijn er merkbaar Gentlemen's agreements en onderlinge verkoopkanaal benutting. Verder kan gemeld worden dat de aanpassing van TR-software aan nieuwe computeromgevingen en besturingssystemen zeer traag verlopen. Een voorbeeld: Windows 95 bestaat al ruim vijf jaar, echter dit jaar pas kunnen we beschikken over belangrijke rekenprogramma's die volledig gebruik maken van alle mogelijkheden van het vermelde Operating System (OS). Bij deze mogelijkheden moet gedacht worden aan grafisch interactief bewerken en verwerken van gegevens en het eenvoudig uitwisselen van deze gegevens binnen de (TR) applicaties draaiend op het OS.

5.6 Integrated Engineering Ook wel aangeduid met CAE, Computer Aided Engineering. Gei'ntegreerd rekenen en tekenen is altijd veel belovend geweest, succesvol in met name sectoren met hoge productieaantallen. Op de Nederlandse markt bestaan voor het GWW werk geen tools op dit gebied. Dit soort tools zijn


2001


Pagina 13/16

echter wel te vinden in de staal prefab industrie en werktuigbouwkundige / scheeps-bouwkundige sector. Deze tools zijn over het algemeen niet generiek toepasbaar. Met name Solid Modelling met geintegreerde 3D 'reken-solvers' worden ingezet in de werktuigbouwkundige sector, toepassingen op betongebied zijn nog niet gerealiseerd. Dit heeft waarschijnlijk te maken met de niet-homogene materiaal eigenschappen van beton. Echt CAE is vaak maatwerk en er is meestal een (business) proces redesign op touw gezet om het e.e.a. in te passen in de organisatie. Kenmerk van de bedrijven die CAE inzetten is operational excelence en maatwerkbedrijven (ref. model Treacy & Wiersema) met een laat 'ontkoppelpunt' (prefab industrie). Altijd aan de orde zijn grote productie aantallen. Binnen de Bouwdienst ontwerpbureaus lijkt er weinig geloof in de mogelijkheden van integrated engineering. Gewezen wordt op het feit dat we geen productie organisatie (meer) zijn. Een andere technische reden waarom getwijfeld wordt aan de kracht van integrated engineering, is dat het niveau van detailleren in tekeningen altijd anders is, dan benodigd voor het rekenwerk. Voor het civiel rekenwerk zijn alleen hart- en systeemlijnen nodig. Tevens neigt dit soort software naar een hoog black-box gehalte, wat door velen als onwenselijk wordt ervaren (weten wat er gebeurt). Het voorgaande in ogenschouw genomen zal integrated engineering bij TR met name draaien om basale data uitwisseling tussen tekenen en rekenen, voor complete geintegreerde maatwerk producten lijkt vooralsnog in het ontwerp/besteksdomein geen plaats. Integrated engineering zal, in een breder perspectief, wellicht wel in het voorontwerp een belangrijk issue kunnen worden. Gedacht moet dan worden aan ontsluiten van kentallen van de bedrijfsbureaus en het aanwenden van reken/teken vuistregels. Tegelijkertijd is het daarmee veel minder traditioneel Technisch Rekenen. 6. Invulling door Technisch Rekenen Producten specifiek: Hoe kunnen de benodigde TR-middelen getypeerd worden op basis van de geschetste engineeringstaken en toegekende 'gewichten': • Voorontwerp/voortraject: lichte (integrale) rekentools (neergeslagen kennis) vuistregels/ontwerpregels koppeling met bedrijfsbureau-gegevens + 3D visualisatie mogelijkheid en de mogelijkheid om op een onderdeel in te zoomen; • Ontwerp: Markt conforme generieke tools met het accent op het educatieve element en indien mogelijk samenwerken met grote ingenieursbureaus om deze tools te verwezenlijken (een goed educatief tool draagt in zich een goede controle mogelijkheid); • Uitvoering, Beheer & Onderhoud: lichte generieke maar ook zware minder generieke tools (calamiteiten); • Controle: dedicated, snelle, liefst eenvoudige tools (special purpose) met accent op het educatieve element.


2001


Pagina 14/16

Producten algemeen: • Software met een laag black-box gehalte; • Software met een korte leercurve; • Met name risicoanalyse (milieu/constructies) zit veel ontwikkeling; • Ontwikkeling samen doen met de grote bedrijven in GWW sector; geen eigenaar worden van producten; • Basale data-uitwisseling tussen tekenwerk en rekenwerk moet een aandachtspunt zijn bij aanschaf en nieuwbouw van CAD en TR applicaties; • Markt stimuleren. Facilitering (Kennis & Kunde) Zoals al eerder aangegeven is de engineerings kennis ontwikkeling essentieel voor kundig opereren in het enigneeringsveld als projectleider of disciplineleider in diverse stadia van een bouwproject. De verantwoordelijkheid hiervoor ligt primair bij de ontwerp afdelingen. Het is echter wel zo dat vanuit het programmabureau Technisch Rekenen faciliterend kan worden opgetreden. Gedacht moet worden aan: • • • • • • • • • • • • •

Introductie nieuwe TR-applicaties; Organiseren opleidingen bestaande en nieuwe TR-applicaties; Organiseren Know-How sessies; Technische Voorlichtingen m.b.t. engineeringsaspecten van diverse projecten. Niet alleen de noviteiten; Inhoudelijke ondersteuning van gebruik TR applicaties op de werkplek; Opgang brengen van communicatie tussen TR-gebruikers; 'In de lucht' houden cruciale TR-software; Ondersteunen bij expliciteren van ontwerpregels naar vuistregels; Faciliteren bij het ontwikkelen van 'eigen' modellen t.b.v. kennis behoud en ontwikkeling (Mathcad, Excel, Visual Basic for Applications, etc.); Wie weet waarvan; expertise kunnen vinden {Yellow Pages); Wanneer is iets eerder gedaan (corporate memory); Stimuleren van kennis deling (b.v. een boekenbon voor de spreker op een Technische Voorlichting); Marktontwikkelingen volgen.

Algemene aandachtspunten Bouwdienst: • Niet alleen vanuit defensieve houding bodyshoppen naar HSL/WST en eventueel bedrijfsleven (onderzoek mogelijkheden); • Waardering engineer, de autodidact en de kennisdeler; • Ontwerp uitgangspunten vastleggen; • Inspirerende werkomgeving; • Een kundig projectleider huur je niet makkelijk in ! Een rekenaar of tekenaar (engineer) daarentegen wel. Echter een kundig projectleider ontwikkelt de Bouwdienst zelf uit een ervaren engineer !; • Job-rotation over de verschillende afdelingen van de dienst (bijv. NI-PD en DI-PD, WB-PD); • Ontwikkel een standpunt over zware mechanica & numerieke analyses.


2001

Visie Technisch Rekenen bij de Bn »rii .« ll

m

Pagina 15/16 7. Samenvatting, conclusie en aanbevelingen e

D

e ™ ^ ^

als core business worden beschouwd in

klant) het kundig u i t v o e r e n T a n £ f S S f S ™ < ™erwaarde voor de Primair moeten worden ^ I r Z i T ^ Z T . u T 7™ ^ ^ n t e n t i e zal venueuwde 6 ^ ^ ^ ^ ^ ^ ° ^ s t a k e n . Kortom, om de traditioneel e n g i n e e r i n g ^ —Iheid met primair met 'productie ogen' moet worden ' h S l langnjk is echter dat dit werk moet worden 'bekeken'(opbouw ^ o r Z Z kenmsI ^ 7? "S" ' traditionele werk moet theoretische kenrnsom ezet worde I kerncompetentie). In dit actie-reactie gevoel bij kunstwerken 2 ^ ^ ^ ^ " u. duidelijk dat de TR-middelen hierbij een b ^ j S ^ T e i ^ ^ ° k

p

e

t

e

n

t

i

e

de

k e r n c o

^r^XS^ &

C

c

W

n d e r h

h

Be

6 d U C a t i e V e

£

k

e

M

i

S

e

m o e t

S e n i

e r

r i t e i t

De relatie tussen het Bouwdienst doel-

leenngstaken kan nlat ™ en de engmeenngstaken kan als als vvolgt w o3 rI ^ v e e T g ^ y ^

s

e w

' °l ren.

con r

e

Kundig controlcren

(

Kundig uitbesteden

De kennis & kunde cycle van de engineering^ ~ d e voor ^ T ^ ****** *** ** "' kenms ontwikkeling & borging plaats in de * vindt met name plaats in de activiteiten C 6 n t r a a l

& kunde. Voo'r de J ^ ^ activiteiten IJI JJJ, kennis IV,V, VI en VII. e n

P

^ ^ toZ^S

S

m

g

^

c o m b i n a t

^

^

e

I

d

k e n

S

H

e

t


Pagina 16/16

Voor Technisch Reken middelen zijn de belangrijkste aandachtspunten de komende jaren de voorontwerpen controle tools. Ten behoeve van de ontwerp/bestek en beheer & onderhouds taken luidt het devies: gereedschappen consolideren en markt/omgevingen volgen. Ten behoeve van kennis & kunde ontwikkeling van de engineers zal actieve ondersteuning en opleiding tot de kernactiviteiten van het programmabureau Technisch Rekenen moeten behoren. De voeding voor civieltechnische noviteiten zal via Speurwerk & Ontwikkeling verlopen en het toekomstig op te richten Innovatie Advies Punt (IAP). Uitgewerkt levert dit de volgende speerpunten op: • Faciliteer ontwerp & besteks en beheer & onderhouds rekenen, uit oogpunt van kennis ontwikkeling en uitwisseling (senioriteit); • Thema van rekenen naar voorontwerpen, (what-if, expertise, kentallen, life-cycle benadering, prijsfje), plaatje, archief, kosten-bewust engineeren); • Thema efficiente controleprogrammatuur, stimulering special-purpose programma's; • Ten behoeve van ontwerp & besteks en beheer & onderhouds rekenen, zet Nederlandse defacto TR software (markt) in en stimuleer de ontwikkeling daarvan, maar ga geen exclusieve ontwikkeltrajecten in; • Ten behoeve van kennis vastlegging, sluit aan bij het in wording zijnde Bouwdienst Document Management Systeem. Kijk voornamelijk naar de archief functie (inclusief classificatie en ontsluiting) en zorg voor een goede, geschikte zoek mogelijkheid; • Volg en stimuleer GWW software ontwikkeling; • Richt een steunpunt mechanica & numerieke analyse op t.b.v. kennis opbouw en kennis deling. Is er in de toekomst extra geld nodig ? Nee, niet zo maar, het gaat hier om een betere focus op wat moet! Wel zal duidelijk zijn dat er voldoende capaciteit nodig is om een hoogwaardige facilitering 'in de lucht' te houden.


2001

ekenen blplju, HEEK Bnu wdiensi Rijkswaterstaal Postbus LA Utrecht BIBLIOTHEEK BOUWDIENST RIJKSWATERSTAAT .& >.VA

Recommend Documents