Gedurende het verificatie- en validatieproces van it-componenten (IT-service management volgens ITIL, P. Jansen, 9043006769) komt het geregeld voor dat niet alle bevindingen opgelost kunnen cq. hoeven te worden. Deze worden getypeerd als de zogenaamde known error. De redenen kunnen divers zijn. Gebrek aan tijd of het vermoeden tot weinig impact op het bedrijfsproces of het onderhavige bedrijfsproces waar de bevinding in is geconstateerd wordt in productie op een later moment pas daadwerkelijk gebruikt.
De definitie van een bedrijfsproces is: Een bedrijfsproces is een geheel van activiteiten dat zich afspeelt tussen de vraag naar een dienst of product en het leveren daarvan. Onder een Known Error wordt volgens ISO/IEC 20000 verstaan: ‘a problem that has an identified root cause or a method of reducing or eliminating its impact on a service by working around it’. Vrij vertaald is de essentie dat de oorzaak van het probleem bekend is maar dat het probleem zelf niet acuut hoeft te worden opgelost omdat er een workaround is.
Known errors kunnen vanuit verschillende activiteiten ontstaan. Zoals al eerder aangegeven vanuit het verificatie- en validatieproces. Echter, de ervaring is dat ook tijdens demo’s of trainingen bevindingen kunnen worden gedaan waarbij de gebruiker aangeeft dat de praktijk anders functioneert. Uiteraard kunnen vanuit productie-incidenten ook known errors ontstaan. Deze zullen op dezelfde wijze worden beoordeeld als de potentiële known errors vanuit het verificatie- en validatieproces. Vaak ontbreekt de tijd om de bevinding structureel op te lossen. Vandaar dat door een team van architecten, programmeurs, testers en ontwerpers onderzocht wordt wat het effect is van de bevinding op de bedrijfsprocessen in productie.
Scenario’s
Bij de uitwerking van de impact moet de toekomstige organisatie betrokken worden. Er zijn een aantal scenario’s te onderscheiden.
De eerste is dat de impact toch groter is dan aanvankelijk gedacht. Bijvoorbeeld meer onderdelen van het systeem worden geraakt door de bevinding. De bevinding wordt geen known error, maar moet opgelost worden alvorens live gegaan kan worden.
Een tweede mogelijkheid is dat softwarematig de impact klein is, maar de impact op de bedrijfsprocessen groot. Denk daarbij aan het feit dat het afhandelen van posten veel meer tijd kost dan aanvankelijk is afgesproken, waardoor deadlines niet meer gehaald worden. Of er moeten zoveel extra mensen ingehuurd worden dat de kosten te hoog oplopen. De potentiële known error raakt niet één klant, maar een grote groep klanten. Redenen waarom de bevinding niet tot een known error verheven kan worden.
De derde mogelijkheid is dat de impact op de software en het bedrijfsproces klein is en dat een sluitende workaround aanwezig is. Indien dit het geval is, kan na akkoord van alle betrokken partijen de workaround gevalideerd worden. Dat betekent dat in een productielike omgeving het bedrijfsproces opnieuw wordt uitgevoerd met daarin opgenomen de workaround. De toekomstige gebruikers valideren de workaround. Na akkoord zal de workaround opgenomen moeten worden in handleidingen, werkinstructies en breed gecommuniceerd moeten worden naar alle partijen, inclusief het beheer. De workaround zal vervolgens in de portfolio (Portfolio management: Theory and application, J. Farrel, W Reinhart, 1997 MacGraw-Hill 0070200823) moeten worden opgenomen om in een volgende release, sprint of patch definitief te worden opgelost.
Afhankelijk van de kosten en de impact op de organisatie zal de prioriteit van de release bepaald worden. Bij het definitief oplossen van de workaround moet rekening worden gehouden dat gebruikers de reguliere situatie uitgelegd cq. getraind krijgen. Dat alle eerder genoemde producten, productrisico’s en testware aangepast worden en dat beheer is geïnformeerd. Al deze zaken bepalen bij elkaar de prioriteit van de oplossing.
Geen probleem
Ik heb in het kort het ontstaan van known errors beschreven. Wat ermee te doen en welke afwegingen gemaakt kunnen worden met betrekking tot het vervolg. Belangrijkste conclusie is dat een known error geen probleem hoeft te zijn mits er een gevalideerde en geaccepteerde workaround beschikbaar is. Er zijn verschillende oorzaken aan te geven waarom een bevinding tot een known error wordt verheven. Zo gauw de prioriteiten het toelaten moet de known error definitief verholpen worden.
Kortom, de keuze om een bevinding niet op te lossen heeft een aantal consequenties die niet onderschat mogen worden. Een op het oog simpele bevinding kan voor de business veel impact hebben!
Wees flexibel maar blijf nadenken!
@Jos
Een ‘known error’ wordt vaak niet opgelost omdat een workaround rendabeler is zagen we ook met notarissen die Diginotar besluit aanvochten omdat ze ineens gedwongen werden om gebruik te maken van snail-mail. En een ander voorbeeld gaf ik in opinie ‘Wie ben ik?’ met burgerservicenummer (BSN) dat gebruikt wordt als BTW-nummer en digitale identiteitsfraude faciliteert.
Je belangrijkste conclusie dat een known error geen probleem hoeft te zijn mits er een gevalideerde en geaccepteerde workaround beschikbaar is heeft twee kanten. Tenslotte is de definitie ervan door technologische ontwikkelingen achterhaald en in de software-industrie is er niet eens overeenstemming aangaande definities voor bug, defect, fout of falen.