Strategieën en een methode ter verbetering van de bedrijfszekerheid en beschikbaarheid in een herontwerp


ir. Dmitri Horowitz rtd.

versie 1.0: augustus 1997
in HTML: januari 1999


De auteur schreef dit artikel als thesis ter afsluiting van zijn post-doctorale studie aan het Institute for Advanced Industrial Design Engineering van de Technische Universiteit Delft, onder begeleiding van prof. ir. J.L. Spoormaker en dr.ir. P.V. Kandachar.

Jus'que ici tout va bien...
motto uit de film La Haine (Frankrijk, 1996)

Als een produktiemachine ten gevolge van een defect niet, of niet goed functioneert, brengt dit grote geldelijke verliezen met zich mee: produkten die niet geproduceerd worden, of mislukken, kunnen immers niet verkocht worden. Men wenst dat deze situatie zo min mogelijk voorkomt, en als het toch gebeurt, dat ze dan zo snel mogelijk verholpen kan worden. Kortom, het gaat om bedrijfszekerheid en beschikbaarheid. Naar aanleiding van een case waarbij deze zaken een belangrijke rol speelden zijn een aantal strategieën bedacht, om deze problematiek aan te pakken. Daarbij is een methode ontwikkeld om, op basis van deze strategieën, op systematische wijze oplossingen te zoeken en toe te passen in een herontwerp.


Toegepaste methodologische principes

Bij de in dit artikel beschreven methode wordt gebruik gemaakt van een aantal principes, die ontleend zijn aan de ontwerpmethodologie. In dit kader worden ze toegelicht.

Iteratie bij ontwerpen

De meeste beschrijvende modellen van ontwerpprocessen zijn terug te voeren op een cyclus, de zogenaamde basis-ontwerpcyclus.

Fig. 4. basis-ontwerpcylcus

Bij ontwerpen wordt vaak iteratief te werk gedaan: deze cyclus wordt dan meerdere keren achter elkaar uitgevoerd, waar bij de output van de voorgaande cyclus dient als input voor de volgende cyclus.

Dit principe komt in deze context meerdere keren naar voren:

  • In een aantal opeenvolgende cycli is het probleem van de case geanalyseerd en werden er strategieën bedacht, en met die als uitgangspunt secundaire strategieën: de oplossingen voortkomende uit een cyclus, werden steeds de problemen die opgelost moesten worden in de opvolgende cyclus.
  • De in dit artikel beschreven methode is op een vergelijkbare wijze tot stand gekomen. Met de in eerste instantie bedachte aanpak werd eerst een pilot uitgevoerd, om erachter te komen, of de methode praktisch bruikbaar was en tot het gewenste resultaat (bruikbare oplossingen) leidde: dit bleek over het algemeen het geval te zijn. Naar aanleiding van de pilot werden er wel enige kleine aanpassingen gedaan om de bruikbaarheid in de praktijk te vergroten.
  • Bij de bedachte oplossingscombinaties worden de daaruit voortgekomen problemen geïnventariseerd, en daar worden in een opvolgende cyclus nieuwe oplossingen voor gezocht.

Volgens het model van de klassieke ontwerpmethodologie stelt men aan het begin van de cyclus criteria vast, en toetst men het ontwerp daar aan het einde van de cyclus. In dit geval is een aanpak gevolgd die in strijd is met dit principe: pas als er oplossingen gevonden zijn gaat men tot het stellen van criteria over. Voor deze aanpak is bewust gekozen, omdat van te voren niet bekend was in welke richtingen de oplossingen gezocht moeten worden, men niet wist welk resultaat men zou kunnen bereiken, en er gestreefd werd naar een optimum. Het gebrek aan toetsings- en controlemogelijkheden werd hierbij geaccepteerd.

Fig.5a. Werkwijze volgens conventionele methode...

Fig. 5b. ...en bij de case gevolgde werkwijze

Systematisch werken

Als middel om de kans te verkleinen dat er problemen en oplossingen over het hoofd gezien worden wordt er op systematische wijze gewerkt. Hierbij wordt gebruik gemaakt van checklists.

Herformulering van het probleem

Een principe waarmee ontwerpproblemen kunnen worden opgelost is het herformuleren van het probleem op een hoger abstractieniveau: dit opent nieuwe richtingen naar de oplossing. Met dat als uitgangspunt kan men het probleem weer op een lager abstractieniveau brengen, zodat de afstand tussen het probleem en de oplossing als het ware verkleind wordt, en het vinden van oplossingen vergemakkelijkt wordt.

Dit principe wordt hier twee keer toegepast:

  • Het probleem van de case werd geanalyseerd door het verhogen van het abstractieniveau ("Waar gaat het om?"), en vervolgens strategieën bedacht door het verlagen van het abstractieniveau (Bijvoorbeeld: "Hoe kan de kans op falen verkleind worden?"). Het bedenken van de secundaire strategieën was de volgende stap waarbij het abstractieniveau verlaagd werd.
  • Een oplossingsrichting bij het voorkomen van falen was de falende component elimineren, door diens functie op een andere wijze te vervullen. ("Hoe kan deze functie vervuld worden?").

Scheiding tussen genereren en beoordelen van ideeën

Bij veel ontwerpmethodes een strikte scheiding aangehouden tussen twee fases in het proces:

  • In de divergente fase wordt een aantal ideeën gegenereerd, waarbij geen selectie plaatsvindt. Men spreekt van divergentie, omdat het aantal ideeën hierbij toeneemt. Dit is gebaseerd op het principe, dat bij een grote hoeveelheid ideeën de kans op goede ideeën toeneemt, en dat door het achterwege laten van selectie de creativiteit niet wordt gehinderd.
  • Nadat op deze wijze een groot aantal ideeën is verkregen, volgt de convergente fase. hierbij vindt pas beoordeling en selectie. Men spreekt van convergentie, omdat het aantal ideeën hierbij wordt gereduceerd. Het principe hierbij is, dat men oplossingen slechts goed kan beoordelen indien men het geheel overziet.

In de beschreven methode is er sprake van divergentie tot aan het combineren van oplossingen. Convergentie vindt hoofdzakelijk pas plaats bij het schiften van de oplossingscombinaties.

Fig. 6. Principe van divergente en convergentie

De case

Het bedrijf Frank Data exploiteert het CycloMedia-systeem, een betrekkelijk nieuwe methode voor het verwerven en administreren van geografische informatie. Het kent momenteel twee toepassingen: landmeting, en digitale beeldarchieven.

Het werkt als volgt:

  • Klanten (bedrijven en instanties die geografische informatie gebruiken) bestellen bij Frank Data CycloMedia-beelden (gedigitaliseerde panoramische opnames) van de betreffende locaties. Frank Data maakt op deze locaties met de CycloMedia Recorder (een speciale camera op een auto) fish-eye-opnames op film.
  • Deze opnames worden vervolgens in een laboratorium met de CycloMedia Scanner (een speciale scanner die een circulaire beweging over de fish-eye-opname maakt) omgezet naar panoramische digitale beelden. Deze worden op DAT-cassette aan de klant verkocht.
  • Daarbij verkoopt Frank Data speciale software, waarmee de klant met de beelden op de computer de geografische informatie verder kan verwerken.

Frank Data is van plan het CycloMedia-systeem in de toekomst ook in het buitenland te gelde maken. Hiertoe zal het partner-bedrijven zoeken, om daar de Recorder en de Scanner aan te verkopen, zodat zij voor lokale klanten beelden kunnen produceren.

Problematiek

De case betreft de CycloMedia Scanner, kortweg CMS genaamd. Dit is in feite een apparaat voor het automatisch produceren van digitale beelden. Het is een complex geheel van fijnmechaniek, elektronica en software, en wordt bestuurd en bediend vanuit een PC met speciale software. Gezien de aard en de complexiteit van het apparaat zijn storingen niet ondenkbeeldig. Deze zouden in de hier geschetste situatie grote exploitatieverliezen met zich meebrengen: beelden die niet geproduceerd of mislukt zijn, kunnen immers niet verkocht worden. Daarbij komen nog de gevolgen van het niet halen van deadlines: schadeclaims van klanten en verlies van een goede reputatie.

Stilstand vanwege storingen moet dus zoveel mogelijk voorkomen worden, en als het toch gebeurt, zo snel mogelijk verholpen zijn. De moeilijkheid hierbij is echter dat de Scanner zich wellicht in een ver buitenland bevindt (er is al belangstelling getoond vanuit Australië): een servicemonteur daarheen sturen zou een kostbare en langdurige aangelegenheid zijn. Eventuele reparaties zouden daarom ter plaatse door de bediener verricht moeten kunnen worden. De bediener is echter wel een betrekkelijke leek. De huidige versie van de Scanner is een prototype, dat enkele malen verbeterd en verbouwd is: er bestaan twee exemplaren van, die beide door Frank Data voor de produktie van CycloMedia-beelden worden gebruikt. Met de zoëven geschetste problematiek was tot dan toe nog geen reden gehouden, en men zag daarom aanleiding een nieuwe versie te laten ontwerpen voor deze situatie.


De Strategieën

Analyse van de problematiek

Bij het bedenken van strategieën moet men zich in de eerste plaats de vraag stellen: waar gaat het de gebruiker van het systeem om? In de case is dat de exploitant van de CMS, en die wenst zo min mogelijk exploitatieverlies. We hadden al geconstateerd, dat stilstand ten gevolge van falen van het systeem dit ongewenste gevolg met zich meebrengt, omdat er dan niet geproduceerd kan worden. Deze stilstand kan het gevolg zijn van:

  • een defect
  • wachttijden voor aanvang van reparatie: zolang het defect niet verholpen is kan de CMS niet produceren. Bovendien moet men rekening houden met het feit, dat de CMS îs nachts onbemand doorproduceert: als een defect optreedt in die situatie, kan er pas de volgende morgen ingegrepen worden: intussen heeft de CMS geen scans geproduceerd.
  • wachten tijdens reparaties
  • periodiek onderhoud (In tegenstelling tot reparaties bij defecten, geldt dat hiervoor een gunstig moment gekozen kan worden, zodat de gevolgen van stilstand hier beperkt blijven.)
  • mislukte scans: deze moeten worden overgedaan. De CMS kan intussen geen andere scans produceren.

Daarnaast is er kans op extra financiële schade, waarvan de omvang moeilijk te voorspellen is: verlies van een goede naam en daarmee (ontevreden) klanten, en schadeclaims vanwege het overschrijden van deadlines. Mislukte scans zijn hier verraderlijker dan stilstand: dat laatste wordt altijd geconstateerd. Als mislukkingen echter moeilijk waarneembaar zijn, bestaat de kans dat ze pas ontdekt worden na aflevering bij de klant, met alle gevolgen van dien.

Het gaat hier dus om bedrijfszekerheid: defecten en mislukken van scans moeten zo weinig mogelijk optreden. Daarnaast gaat het om beschikbaarheid: stilstand mag zo min mogelijk optreden, en als die toch optreedt, moet die zo snel mogelijk verholpen kunnen worden. Deze begrippen overlappen elkaar dus in deze context.

Het is verleidelijk om in dit verband te spreken van mean time between failure en mean time to repair. Een gemiddelde ("mean") zegt in dit verband echter weinig: een dagelijks voorkomende storing die slechts een minuut duurt is veel minder schadelijk dan een storing die eens per jaar voorkomt, maar een maand kost om te repareren. Dit soort grootheden zijn hier dus niet relevant.

Primaire strategieën

Om gericht oplossingen te vinden, om in het herontwerp te kunnen toepassen, werden er algemene oplossingsrichtingen, oftewel strategieën bedacht. Om deze te vinden moet men zich de vraag stellen: Hoe kan men de bedrijfszekerheid en/of de beschikbaarheid van het systeem vergroten?

De bij de case bedachte strategieën worden hier toegelicht.

Een faalgebeurtenis voorkomen door het ontwerp te wijzigen.

Dit kan door, het wegnemen van de oorzaak van het falen, of het elimineren van de component die kan falen, bijvoorbeeld door diens functie op een andere wijze te laten vervullen. De functie van een ventilator kan bijvoorbeeld worden overgenomen door convectiekoeling, die niet defect kan raken.

Men kan het falen niet voorkomen, maar wel de kans erop verkleinen, door het kiezen van oplossingen met een kleinere faalkans. Men kan bijvoorbeeld microswitches vervangen door inductiesensoren.

Een faalgebeurtenis voorkomen door een procedure

Dit zou preventieve vervanging kunnen zijn, bijvoorbeeld van een projectielamp. De procedure zou kunnen worden uitgevoerd door een servicemonteur, bij de door Frank data uit te voeren jaarlijkse servicebeurt, of door de gebruiker zelf.

De gevolgen van een faalgebeurtenis beperken

Deze strategie heeft zin wanneer het falen nog ergere gevolgen heeft dan het niet werken van de CMS als geheel zelf, bijvoorbeeld schade of gevaar. In dat geval is er een passieve beveilig, bijvoorbeeld een sper die te ver bewegen van een bewegend deel voorkomt, of actief ingrijpen door het systeem, bijvoorbeeld het stoppen van het filmtransport als de film breekt.

Deze strategie heeft ook zin, wanneer het falen leidt tot mislukking van scans, die moeilijk op te merken is. Dit kan bijvoorbeeld door de scans te onderwerpen aan automatische testen.

De faalgebeurtenis corrigeren

Dit kan gebeuren door vervanging of reparatie van de gefaalde component. Deze strategie heeft zin, indien het falen opgetreden en geconstateerd is.

secundaire strategieën

Voor het realiseren van oplossing op basis van bovengenoemde primaire strategieën zijn soms aanvullende oplossingen nodig om ze te kunnen realiseren. De secundaire strategieën worden afgeleid van de primaire strategieën, en geven de richting aan voor deze oplossingen. Hier worden ze toegelicht per primaire strategie.

Een faalgebeurtenis voorkomen door het ontwerp te wijzigen.

Hierbij heeft men geen secundaire strategie nodig.

Een faalgebeurtenis voorkomen door een procedure

Voor het uitvoeren van deze procedures, is het nodig, dat men kan voorspellen of signaleren, dat het tijd is om deze procedure uit te voeren. Dit kan bijvoorbeeld door het bijhouden van de bedrijfstijd van de component.

De gevolgen van een faalgebeurtenis beperken

Voor ingrijpen door het systeem ter voorkoming van erger, is het nodig dat het systeem het falen kan signaleren. Breuk van de film kan bijvoorbeeld gedetecteerd worden door te controleren of de snelheden van de op- en afwikkelhaspels met elkaar overeenstemmen.

Voor het signaleren van mislukkingen is nodig dat de bediener kan constateren dat er sprake is van mislukking, om te voorkomen, dat het te laat wordt opgemerkt. Het preventief testen van de werking van de CMS aan het begin van een scansessie, of het automatisch controleren van de scans of de werking van de CMS tijdens de scansessie, kan ook tot deze strategie gerekend worden.

De faalgebeurtenis corrigeren

Vanwege de situatie, dat Frank Data zich op grote afstand bevindt, en alleen periodiek preventieve servicebeurten wenst uit te voeren, is het niet alleen nodig dat de bediener de correctieve handelingen kan uitvoeren, maar ook te weten moet kunnen komen, welke handelingen uitgevoerd moeten worden. Dit zou op verschillende manieren kunnen geschieden, bijvoorbeeld door diagnose op afstand, waarbij Frank Data als help desk fungeert en telefonisch aanwijzingen geeft, een ingebouwd diagnosesysteem in de CMS, of een handleiding, die op grond van de symptomen aanbevelingen doet. Let wel: het is hier niet van belang om te weten welke component gefaald heeft, maar slechts om te weten wat men moet doen om het falen te corrigeren.


 

De Methode

Met behulp van de bedachte strategieën kan er gericht naar oplossingen worden gezocht om toe te passen in het herontwerp. Om dit op gestructureerde wijze te kunnen uitvoeren is naar aanleiding van de case een methode ontwikkeld, die hier wordt beschreven.

Globaal werkt de methode als volgt: het faalgedrag van het systeem wordt geanalyseerd, en de resultaten daarvan worden systematische gecombineerd met de strategieën. Hieruit komen oplossingen voort, die nader geanalyseerd worden, en vervolgens geselecteerd en uitgewerkt tot een voorstel voor een herontwerp.

Het draait hierbij om twee vragen: Wat kan er falen? en Wat kan daar aan gedaan worden?

Fig. 1. Vereenvoudigde schematische voorstelling van de methode

Wat kan er falen?

Met deze vraag begeven wij ons op het terrein van de bedrijfszekerheidsleer. Die kent een aantal methodes voor het analyseren van systemen op faalgedrag. Eerst een aantal constateringen bij de case:

  • De persoonlijke veiligheid speelt geen rol: faalgedrag bij de CMS kan hoogstens leiden tot materiële schade.
  • Vrijwel alle faalgebeurtenissen die bij de componenten in het systeem kunnen optreden zijn kritiek: als een afzonderlijke component faalt, faalt het hele systeem.
  • De faalkans per afzonderlijke component is betrekkelijk klein. Maar er zijn veel componenten die kunnen falen, en tezamen maken die de kans op falen van het systeem als geheel groot.
  • Er zijn wat faalgedrag van de CMS betreft vrijwel geen gegevens uit de praktijk: het systeem bestaat pas een paar jaar en er zijn er maar twee exemplaren van gebouwd, dus veel heeft er nog niet kunnen gebeuren.
  • Van de meeste ingekochte componenten zijn geen kwantitatieve faalgegevens beschikbaar. De fabrikant heeft ze gewoonlijk niet, of is niet bereid ze bekend te maken.
  • Over bepaalde onderdelen (bijvoorbeeld elektronische componenten) bestaan er handboeken met faalgegevens. Deze gegevens zeggen echter weinig over de situatie in de praktijk. Faalgedrag is vaak terug te voeren op andere zaken dan slechts het in bedrijf zijn van het apparaat. Bij fabricage, transport, onderhoud en reparatie krijgt het apparaat het veel zwaarder te verduren, en kwantitatieve faalgegevens met betrekking tot deze situaties zijn niet voorhanden.

Een kwantitatieve analysemethode is hier niet bruikbaar bij gebrek aan de daarvoor benodigde gegevens. Afgezien daarvan zijn kwantitatieve vragen hierbij ook niet aan de orde. De vraag is niet: Hoe groot is de kans op falen? of Welk faalprobleem heeft de hoogste prioriteit? Het gegeven dat er faalgebeurtenissen zijn die kunnen optreden, dat is op zich al ernstig genoeg, en tegen al het mogelijke falen moet dan ook iets gedaan worden. Daarom wordt hier een kwalitatieve methode gebruikt.

Wat is FMEA?

FMEA, voluit Failure Mode and Effect Analysis is een analyse, waarbij voor iedere faalvorm (failure mode) van een onderdeel in een (deel)systeem wordt nagegaan wat het falen ervan voor effect heeft op het functioneren van dit (deel)systeem.

Voor deze problematiek leent zich het beste een causale evaluatiemethode: er wordt geredeneerd vanuit de oorzaak, en daarvan worden de gevolgen afgeleid. De bekendste causale analysemethode is FMEA. Een variant hiervan wordt bij de voor de case ontwikkelde methode toegepast.

Allereerst wordt hierbij een inventarisatie gemaakt van de componenten in het systeem, en worden hun functies benoemd. Vervolgens wordt per component bekeken welke faalgebeurtenissen daarbij kunnen optreden. Opdat hierbij geen mogelijke gebeurtenissen over het hoofd zouden worden gezien wordt hierbij een checklist van mogelijke aanleidingen gehanteerd. In de eerste plaats kan een component "uit zichzelf" falen. Er zijn verschillende gronden waarop men faalgedrag kan voorspellen:

  • In de component treden processen op die aanleiding kunnen geven tot falen (faalmechanismes zoals bijvoorbeeld slijtage of thermische degradatie).
  • Men weet uit ervaring dat de component een beperkte levensduur heeft, of behoort tot een categorie, waarvan bekend is dat daarbij faalgedrag kan optreden (bijvoorbeeld een lamp of een elektromotor).

Een component kan echter ook falen door factoren van buitenaf. Dat kunnen zijn:

  • factoren uit de omgeving die op het systeem of de component inwerken: deze moeten dus worden ge´nventariseerd;
  • handelingen die met het systeem of de component worden verricht: deze kunnen worden ge´nventariseerd door middel van een procesboom.

Op basis hiervan krijgt men een lijst van mogelijke faalgebeurtenissen, die voor de volgende stap in de analyse worden gebruikt.

Fig. 2. Principe van causale analyse

Per faalgebeurtenis worden een aantal gegevens geanalyseerd dan wel ge´nventariseerd, die kunnen helpen bij de volgende fase, het zoeken van oplossingen. Bovendien verkrijgt men hierdoor meer inzicht in de problematiek van de afzonderlijke faalgebeurtenis. Het gaat om de volgende zaken:

  • de wijze van optreden van de faalgebeurtenis: plotseling, geleidelijk, periodiek, continu;
  • de gevolgen en mogelijke gevolgen van de gebeurtenis wat betreft de werking van het systeem
  • de ernst van de gebeurtenis: stilstand, mislukken van scans, extra schade etcetera; (Dit is mede bepalend voor de toe te passen strategie)
  • de symptomen van de gebeurtenis (Deze kunnen van nut zijn bij het stellen van diagnoses.)

Wat kan eraan gedaan worden?

Na het analyseren van het systeem op mogelijke faalgebeurtenissen en het verzamelen van aanvullende gegevens kan er overgegaan worden tot het zoeken van de oplossingen.

De oplossingen worden gericht gezocht door het systematisch combineren van twee lijsten: de faalgebeurtenissen en de primaire en secundaire strategieën: de in de analyse verzamelde gegevens kunnen hierbij helpen.

Hieruit verkrijgt men een verzameling oplossingen. Daarmee worden bruikbare combinaties gezocht van oplossingen op basis van de primaire en secundaire strategieën.

De op deze wijze oplossing verkregen oplossingscombinaties worden vervolgens geëvalueerd. Hiertoe wordt per oplossingscombinatie bekeken welke problemen er bij eventuele implementatie zouden kunnen optreden:

  • Er kunnen problemen ontstaan door de beperkingen die de gebruikssituatie oplegt. (Bijvoorbeeld: het vervangen van een component ter correctie van falen is te moeilijk om door de bediener te laten uitvoeren.)
  • Het implementeren van de oplossing brengt zelf problemen met zich mee, (bijvoorbeeld technische problemen).
  • De oplossing brengt nieuwe problemen met zich mee. Wat dit betreft moet er vooral aandacht besteed worden aan mogelijk nieuw faalgedrag, opdat het middel niet erger worde dan de kwaal. Hiertoe kan men de hierboven beschreven faalanalyse toepassen en op basis van de resultaten daarvan aanvullende oplossingen bedenken.

Het gegeven dat een oplossing problemen met zich meebrengt, betekent niet dat deze niet toegepast moet worden. Er moet echter wel bij verdere uitwerking rekening mee gehouden worden.

Op basis van de naar voren gekomen knelpunten kan een eerste schifting van oplossingscombinaties worden gemaakt. Dit kunnen redenen zijn om een oplossing niet verder uit te werken:

  • de oplossing is triviaal of reeds toegepast in het systeem
  • de oplossing is evident niet uitvoerbaar
  • de oplossing is als middel erger dan de kwaal (men denke aan de gevolgen voor de bedrijfszekerheid)
  • een andere oplossing is evident beter.

Er zijn een aantal redenen om het selecteren van oplossingen tot dit stadium uit te stellen:

  • Hoewel men bij oplossings-strategieën vaak een algemene voorkeur kan uitspreken (voorkomen van falen is bijvoorbeeld in het algemeen beter dan corrigeren), wil dat niet zeggen, dat dat ook altijd voor de hieruit voortkomende individuele oplossingen geldt. Soms is een oplossing van een minder geprefereerde strategie effectiever dan diens geprefereerde tegenhanger. In sommige gevallen is de geprefereerde strategie niet eens mogelijk: een volledig faalvrij systeem bestaat niet. Dit alles kan pas beoordeeld worden, nadat de oplossingen zijn bedacht.
  • Oplossingen zijn vaak te combineren, of sluiten elkaar juist uit: ook dit is pas te beoordelen als de mogelijke oplossingen met hun problemen bekend zijn.
  • Deze werkwijze is bevorderlijk voor de creativiteit. (Zie "Scheiding tussen genereren en beoordelen van ideeën" in het kader.)

De overblijvende oplossingen worden nader onderzocht, uitgewerkt, verder geselecteerd en verwerkt in het herontwerp, rekening houdende met de naar voren gekomen problemen

Bij deze werkzaamheden kunnen gangbare ontwerpmethodes toegepast worden. Overigens was bij de case de problematiek in dit stadium tot een zodanige eenvoud teruggedrongen, dat verder met een intuïtieve werkwijze kon worden volstaan.

Fig.3. Schematische voorstelling van de methode


Literatuur

Spoormaker, J.L.: Inleiding ontwerpen op bedrijfszekerheid voor IO, Delft, Technische Universiteit Delft, 1995.

Klaassen, K.B.; Peppen, J.C.L. van; Bossche, A.: Bedrijfszekerheid - theorie en praktijk, Delft, Delftse Uitgevers Maatschappij, 1988.

Eekels, J.; Rozenburg, N.; Nijhuis, W.: Ontwerpmethodologie, Delft, Technische Universiteit Delft, 1988.

Cross, N.: Engineering Design Methods, Milton Keynes (UK), John Wiley & sons, 1989.

 

Het resultaat bij de case

Door toepassing van de hier beschreven methode kwam een groot aantal oplossingen naar voren; deze waren niet alleen mechanisch of elektronisch van aard, maar ook software-matig, procedureel, of een combinatie van deze vier. Veel oplossingen waren triviaal of onbruikbaar, maar er bleven er nog voldoende geschikte over: deze zijn verwerkt in een herontwerp-voorstel. Hierbij werd ook gebruik gemaakt van het gegeven dat een PC tot de uitrusting van de CMS behoort. Het voorstel omvatte onder meer het volgende:

  • diverse vereenvoudigingen van mechanische constructies en elektronica, wat de kans op falen verkleint, vanwege de vereenvoudiging zelf, en door het elimineren van componenten (Wat er niet is kan niet falen.)
  • verbetering van mechanismes, constructies en procedures om onderhoud en reparatie door de bediener mogelijk te maken;
  • preventieve vervangingsprocedures, en een functie in de PC voor het bijhouden van een onderhoudsschema;
  • diverse automatische testfuncties in de software, die zowel voorafgaande aan een scansessie, als tijdens het scannen zelf, de werking van het systeem en het produkt (de scans) controleren;
  • procedures voor diagnose en correctie van falen, en informationele en technische hulpmiddelen: onder andere een diagnose-hulpprogramma in de PC en testgereedschappen.

Toepassingsmogelijkheden

Toepassing van de hier beschreven strategieën en methode hoeft niet beperkt te blijven tot de CycloMedia Scanner. In principe kunnen ze gebruikt worden voor alle systemen waarbij een grotere beschikbaarheid en bedrijfszekerheid gewenst is. Men hierbij denke niet alleen aan produktiemachines, maar ook aan voertuigen, computersystemen, energievoorziening, etcetera.

Hier zijn nog enige aanwijzingen voor het gebruik:

  • De methode werkt met behulp van checklists, en die zijn nooit uitputtend. Wellicht moeten ze voor andere cases aangepast worden. De checklists zijn bedoeld als hulpmiddel om geen mogelijkheden over het hoofd te zien, maar in geen geval als beperking. Als men ideeën heeft die niet in het stramien van deze methode passen, moet men dan ook zeker niet nalaten ze te benutten.
  • Bij deze case werd het systeem onderverdeeld tot het niveau van componenten. Er zijn echter ook andere onderverdelings-niveaus mogelijk. Als men alleen op onderdelen-niveau oplossingen zoekt en hogere niveaus buiten beschouwing laat, ziet men wellicht oplossingen over het hoofd. Het is daarom wellicht raadzaam deze methode op meerdere niveaus uit te voeren.

Tot slot zijn hier nog twee kritische kanttekeningen.

De eerste kanttekening betreft de methode zelf. Hierbij worden vooraf geen criteria geformuleerd, en er vindt dan ook geen toetsing daaraan achteraf plaats: er ontbreekt dus een controle-instrument. Bovendien zijn de gegevens die bij de deze methode worden gebruikt zijn noch gekwantificeerd, noch op basis van feiten verkregen. Het is daarom niet zonder meer te zeggen of door een op deze wijze tot stand gekomen daadwerkelijk een grotere beschikbaarheid of bedrijfszekerheid gerealiseerd wordt, laat staan in welke mate. Anderzijds is in elk geval de kans op substantiële verbetering groot, omdat men hierbij oplossingen vindt voor problemen waaraan tot dan toe niets gedaan is.

De tweede kanttekening betreft de toepassing van deze werkwijze in het algemeen. Ook bij het ontwikkelen van systemen geldt het principe, dat voorkomen beter is dan genezen. Het zou beter zijn, als men reeds bij aanvang van het ontwikkelingsproces met zaken als bedrijfszekerheid en beschikbaarheid rekening zou houden. "Puinruimen" achteraf bij het maken van een herontwerp is kostbaar, en wellicht ook minder effectief. •