Het digitaliseren van ontwerpprocessen is een heet hangijzer, dit is bij Arcadis niet anders dan bij andere bedrijven. Door de jaren heen ben ik erachter gekomen dat er een paar belangrijke en verschillende argumenten zijn tégen digitaliseren. Vaak wordt het black box-gevaar gezien: het gevaar dat de mogelijkheden tot verificatie van de berekening verloren gaat en daarmee ook het constructeursgevoel. Ook de (on)mogelijkheid om nieuwe medewerkers op te leiden door het maken van ontwerpsommetjes hoor ik als argument. Dit zou niet meer mogelijk zijn door automatisering. Of het argument dat een ontwerptool door een enkeling wordt gemaakt, met als goedbedoeld doel deze over de gehele afdeling uit te rollen. Het afwezig zijn van tussentijdse reflectie op ontwikkelingen is dan een zorg.

Ongeveer een jaar geleden besloot ik me, na een korte motivatiecrisis in mijn eigen digitaliseringswerk, te storten op de wereld van Agile Scrum. Deze managementvorm lijkt een deel van de oplossing te zijn voor de bovenstaande argumenten. Vooral omdat hij specifiek geschikt is voor waardegedreven software development. Kort gezegd gaat het erom dat je in een team van ontwikkelaars (dus zeker niet alleen!) samenwerkt aan een digitale ontwikkeling. Rollen zijn de Product Owner (een soort technisch manager), een Scrum Master (een procesmanager) en een groep ‘belanghebbenden’ – bijvoorbeeld zij die jouw product uiteindelijk willen gebruiken.

De perfecte kans om de Product Owner-rol op te pakken deed zich vorig jaar voor, toen Arcadis besloot in te zetten op het automatiseren van het voorontwerp van industriële gebouwen. We willen goed doordacht een programma van eisen in elkaar zetten door vele varianten te analyseren. Omdat een groot deel van de kosten van een industriegebouw in de draagstructuur zit, willen we deze vlot, maar ook graag als geheel kunnen beschouwen. U begrijpt dat hiervoor flink wat bierviltjes benodigd zijn, zeker als we ook duurzaamheidsaspecten en een kosteninschatting mee willen nemen.

Daar komt bij dat dit een mondiale ontwikkeling is. Onze belanghebbende eindgebruikers (constructeurs) hebben elk hun eigen ideeën over het ontwerpen van een industrieel gebouw en hoe je dit rapporteert, afhankelijk van de regio waarin zij werken. Des te belangrijker is het om ze in het ontwikkelingsproces te betrekken. Werken met Agile Scrum is hiervoor een goede oplossing.

Allereerst bracht ik het team en de belanghebbende constructeurs samen om de wensen en eisen in kaart te brengen. Vervolgens zijn we in zogenaamde tweewekelijkse Sprint Cycli stap voor stap gaan bouwen aan de ontwikkeling. Daarbij hoort ook het presenteren van de voortgang en het geven van demonstraties. Dit kost extra inspanning, maar heeft als voordeel dat er constant bijgestuurd kan worden op de inhoud van de ontwikkeling. Ik ervaar dit als een uitstekend mechanisme om ideeën over hoe je constructies ontwerpt mondiaal te delen en tevens vormt het de business justification – de reden waarom we mogelijkheden aan de tooling blijven toevoegen.

Nadelen zijn er ook. Zo zijn de meeste van onze collega’s niet gewend om in tweewekelijkse sprints met een deadline te werken. Dit botst nog wel eens met het lopende projectwerk. Afspraken maken is daarom noodzakelijk. Het team van ontwikkelaars bestaat uit constructeurs die niet specifiek zijn opgeleid om te programmeren. Wel wordt het steeds gemakkelijker om te leren programmeren. We kunnen het met betrekkelijk eenvoudige code aanpakken en er zijn platforms beschikbaar waarop applicaties eenvoudig kunnen worden gedeeld. Ook weten programmerende constructeurs goed wat ze graag in een geautomatiseerd berekeningsrapport willen zien. Dit vormt gelijk de oplossing van het black box-probleem en het verlies van constructeursgevoel. Uitgebreide rapportages met alle beschouwde onderdelen zijn namelijk mogelijk – maar ook het uitlichten van een kritiek constructiedeel kan. Hiermee is het nalopen van de krachtafdracht dus erg gemakkelijk. Deze rapportages komen echter wel uit op A4-formaat en niet op een rond stukje karton, aan jou om te besluiten of dat problematisch is.

Is er dan geen plaats meer voor een ontwerpberekening? Ik denk van wel. Het blijft een goede gewoonte om door en door begrip te hebben van je ontwerp. Een ontwerpberekening helpt daarbij. Daarnaast blijven speciale oplossingen bij een goede generieke digitale ontwikkeling buiten schot, omdat dit te specifiek is om te automatiseren. Hier mag u voorlopig zelf de tanden nog in zetten. Voor alle overige ontwerpberekeningen kunt u wat mij betreft het bierviltje in de trofeeënkast zetten, naast het sigarenkistje.