Het totale systeem

In mijn vorige column stipte ik een aantal voorbeelden aan waarin ontwerpers de mens over het hoofd hebben gezien als onderdeel van een systeem. Een systeemengineeringtraining van Australiër Robert Halligan heeft me enkele jaren geleden geleerd dat ontwerpers wel vaker iets vergeten. Hij illustreerde zijn eigen systeemengineeringaanpak met een voorbeeld dat hij had ontleend aan zijn ervaringen bij de Australische defensie: een drijvend radiobaken dat onderzeeërs naar de oppervlakte kunnen sturen.

Een van de eerste dingen die hij deed, was een systeemdecompositie maken. Daarin zaten uiteraard de drijver, de radio en de antenne van het baken en geheel volgens de regels van de logica voegde hij ook de verbindingskabel tussen boot en baken toe, alsmede de behuizing voor het baken in de romp. Tot verrassing van de deelnemers verschenen echter ook de gebruikershandleiding, de productiehandleiding en de bakenproductieworkshop op het whiteboard. Halligans uitleg was heel logisch: het ontwerp van het baken beïnvloedt al deze zaken; bovendien vormen ze de brug naar de eisen van een aantal stakeholders die snel worden vergeten.

Een aantal jaren, projecten en architectuurassessments verder heb ik kunnen zien wat er gebeurt als dit soort items, die op het eerste gezicht geen onderdeel uitmaken van het product en dus niet van het systeem, worden vergeten. Een paar voorbeelden. Een leverancier van satellietonderdelen ziet mechanische filters (buisjes die alleen bepaalde golflengtes doorlaten) als zijn belangrijkste product. Al het rekenwerk dat aan de constructie voorafgaat, zit in een onoverzichtelijke verzameling van zo‘n tachtig spreadsheets en Fortran-programma‘s. Knutselwerk van veelal fysici, over een periode van dertig jaar. Het is even schrikken als vlak voor het pensioen van de laatste der Mohikanen onder deze fysici blijkt dat vrijwel alle IP van het bedrijf in die software zit.