Ik ben langzamerhand steeds meer tot de conclusie gekomen dat twee concepten van Systems Engineering zoals in de GWW sector worden gehanteerd enige aanpassing verdienen. Dit zijn de eisenboom en de objectenboom. Ik ben benieuwd naar je reactie!
Eisenboom
Allereerst denk ik dat het hele concept ‘eisenboom’ zoals in de ‘Leidraad SE‘ helemaal is uitgewerkt, niet goed werkt. De termen boven- en onderliggende eisen lijken er op te wijzen dat onderliggende eisen inderdaad afgeleid kunnen zijn van bovenliggende eisen. Echter, op steeds ‘diepere lagen’ komen er óók eisen aan het licht die niet afgeleid zijn van ‘bovenliggende’ eisen. Met wat gekunstel kun je het dan wel aan een bovenliggende eis koppelen, maar soms ook eigenlijk niet en komt de eis gewoon van een persoonlijke voorkeur of ervaring o.i.d. Denk aan een eis als ‘de leuningen moeten blauw van kleur worden’. Ik ben steeds meer aan het denken aan een eisen- en objectennetwerk. Ik weet nog niet hoe dat vorm gegeven of weergegeven moet worden, maar ik wordt er wel steeds enthousiaster over.
Ik heb het nog niet gedaan, maar ik denk aan de volgende oplossing: Als je het plaatje van de twee pyramides (eisenboom en objectenboom) zou integreren met elkaar en minder hiërarchisch zou maken, dan krijg je om en om een laag van eisen, dan een laag objecten, dan weer een laag eisen en dan weer objecten. Mijn oplossing/suggestie is één structuur waarin beide zijn gecombineerd.
In onderstaand figuur uit de eerste leidraad SE is dit ook eigenlijk weergegeven. Let in de figuur op de locatie van het woord “Afleiden”.
Mijn uitleg bij de figuur is: Vanuit een bepaald ontwerp(keuze) (Lees: object) ga je nieuwe eisen opstellen. Dit hoeft niet per sé vanuit eisen te zijn, het kan dus ook vanuit een eerste gedachte over een object komen. Je gaat immers pas eisen aan een fundering stellen als er een fundering moet komen en niet eerder.
De reden hiervoor is dat als je een keus hebt gemaakt voor een bepaald systeem/object, dat je dan pas nieuwe eisen kunt afleiden voor de laag eronder. Die nieuwe eisen zorgen voor een oplossingsgebied met een keus voor een oplossing (=object). Aansluitend kun je weer de nieuwe eisen aan het onderliggende object benoemen. Op die manier is ook duidelijker tot waar je als opdrachtgever gaat in het zoeken (=medeontwerpen) naar oplossingen. Of andersom is het voor de opdrachtnemer beter om te zien tot waar de opdrachtgever is gebleven.
Een bijkomend voordeel is dat je op deze wijze mogelijk ook sneller ‘vanaf de plank’ oplossingen kunt aandragen. Een oplossing die aan alle eisen van de opdrachtgever voldoet en al eerder eens is toegepast, kan mogelijk snel geverifieerd worden en ingezet worden in het ontwerp. Ook dit wil ik nog nader onderzoeken.
Objectenboom
Daarnaast denk ik dat de boomstructuur van met name objecten minder hiërarchisch, maar meer als netwerk moeten worden weergegeven. We moeten duidelijker maken welke objecten relaties met elkaar hebben. Soms hebben objecten/systemen van verschilende diepteniveau’s namelijk een nauwe relatie met elkaar. In dat geval kun je ook een relatie tussen die twee objecten in een eis formuleren en duidelijker maken waaraan de oplossing dient te voldoen. Dit model zal de “raakvlakkenmatrix” vervangen.
Reacties!
Ik ben nog in de experimentele fase over het denken van deze beide concepten en heb het nog niet toegepast, maar ik ben benieuwd naar jouw meningen hierover.
Hoewel dit artikel al redelijk oud is, niet minder relevant.
In de beslissingstheorie heeft een vergelijkbare ontwikkeling al plaatsgevonden en bestaan ‘hierarchie’ en ‘netwerk’ als methoden inmiddels naast elkaar.
Mocht je daarmee bekend zijn of in willen verdiepen dan is het interessant om het gebruik van de beslissingsmethoden Analytic Hierarchy Process (AHP) en Analytic Network Process (AHN) naast elkaar te zien. Er zijn al ruim voldoende vergelijkingen beschikbaar (zoek op “AHP AHN”). Ik denk dat lessen daaruit ook zeker toepasbaar zijn op een eventuele meer netwerkgeörienteerde manier van werken met objecten/eisen binnen SE.
Zonder referentiekader bestaat niet. Een mens heeft altijd houvast aan zijn individualiteit. Die individualiteit ontstaat als hij aannames, theorie toetst aan eigen zijn eigen waarneming.
Helaas is het zo dat we in een maatschappij leven waarbij zelfs afgestudeerde ingenieurs roepen ‘dat het te abstract is’.
Een mens verschilt van het dier door zijn eigen idee. Inzicht is alleen mogelijk door de aan het eigen referentiekader getoetste aanname.
In de vraag ligt het antwoord opgesloten. Een domme vraag verdient een dom antwoord.
Wegen worden al lang aangelegd en onderhouden, en vroeger wist men nog waarom. Nu is die waarom-vraag ‘te abstract’.
Stop met het bouwen en onderhouden van de Nederlandse infrastructuur, totdat we collectief (weer) weten waarom!
Sinds 2011 is deze problematiek alleen maar heftiger te worden. Toch wordt er niet op deze stelling gereageerd. Jammer!
Ik ben het met de stelling eens, en ga nog verder:
Stel je doelen en stel geen eisen!
Eisen stel je omdat je doelen wilt bereiken.
Je gaat nadenken en engineeren omdat je dat ‘doelbereiken’ niet zelf, zonder PDCA of andere beheersing, afkunt zonder al te veel schade op te lopen.
Het begint dus met een doel. Waarom?
En dan ga je systematisch, logisch verder. Eisen houden verband met risico’s. Eisen stel je als je kans op schade loopt. Schade die je wilt voorkomen of beperken als je je doel wilt bereiken.
Een ondernemer kijkt naar de opbrengsten en haalt daar de kosten af, zodat hij kan zien wat de winst is. Hij denkt in kansen en risico’s, tegelijk. Zijn toets is meestal eenvoudig: marge, winst. Wat houd ik over?
Wat weerhoudt ons ervan om ondernemer te zijn?
Ik ken geen ondernemer die op tactisch niveau met een eisenboom of een objectenboom werkt. Veel te ingewikkeld. Maar vraag hem naar zijn doelen, en je krijgt een helder antwoord, geformuleerd in resultaat.
Meer weten over de DET (DOEL-EIS-TOETS)?
Het is niet meer dan logisch in mijn optiek. SE leent zich het beste wanneer ‘from scratch’ kan worden gestart. Mooiste is wanneer er geen (gerelateerde) ervaringen zijn met het te ontwikkelen product (object)(b.v. bij NASA). Helaas is dat in de praktijk en civiele techniek in het bijzonder vaak niet zo. Daar moet een Opdrachtnemer volgens contract vaak verschillende oplossingen aandragen (middels SE) en laten zien (in b.v. een tradeoff matrix)welke oplossing volgens hem de beste is om te kiezen. Het gekunstel begint daar duidelijk vorm te krijgen omdat de oplossing(en) reeds is/zijn verwoord in de gegeven eisen (men kan wel maar mag niet anders voor wat betreft mogelijke oplossingen). Daarnaast worden er jaar en dag wegen aangelegd van veelal hetzelfde type. Hierdoor is het niet altijd zinvol te werken volgens de SE methodiek. Men hierdoor dus eigenlijk niet ‘form scratch’. Wellicht dat kengetallen / catalogie meer op zijn plaats zijn in met name de infracstructuur. Hoeft overigens niet te betekenen dat er niets ‘from scratch’ kan en mag worden ontwikkeld. Het is echter wel van belang de uitvraag aan de markt dan ook als zodanig in te richten!