Antwoord.

Geschiedenis van de vraag:

In de vroege stadia van automatisering van bedrijfsprocessen bleek vaak dat de opdrachtgever niet volledig begreep of belangrijke niet-formeel gedocumenteerde bedrijfsregels over het hoofd zag. Het ontbreken van een duidelijke vastlegging van dergelijke regels leidde tot logische fouten, onvoorspelbare situaties en geschillen tussen de business en IT.

Probleem:

Verborgen of impliciete bedrijfsregels zijn moeilijk te identificeren: alleen ervaren medewerkers kennen ze, ze kunnen alleen op papier zijn vastgelegd, of helemaal niet gedocumenteerd. Dit vergroot de risico's op bugs en conflicten, en maakt het testen en implementeren van het product moeilijker.

Oplossing:

De systeemanalist past de volgende methoden toe:

• Interviews met sleutelgebruikers en experts
• Analyse van incidenten en uitzonderlijke situaties
• Bestudering van reglementen, gerelateerde processen, archieven van berichten en correspondentie
• Door middel van modellering van scenario's en het maken van BPMN/UML-diagrammen identificeert hij hiaten.

Na het verzamelen van de regels formaliseert de analist ze met behulp van sjablonen voor bedrijfsregels, besluitmatrixen, toestand- en voorwaardendiagrammen. Hij actualiseert de documentatie voortdurend bij wijziging van vereisten.

Belangrijke kenmerken:

• Actieve betrokkenheid van experts voor validatie van de geïdentificeerde regels
• Toepassing van sjabloonformaten voor beschrijving (bijvoorbeeld, Besluitentabel)
• Afstemming en goedkeuring van alle bedrijfsregels met de opdrachtgever

Misleidende vragen.

Kun je stellen dat alle regels die de opdrachtgever in het begin noemt, uitputtend zijn?

Nee, vaak is een deel van belangrijke informatie verborgen of wordt als vanzelfsprekend beschouwd. Diepgaand onderzoek en aanvullende uitwerkingen zijn nodig.

Moeten de regels die alleen door bepaalde medewerkers bekend zijn altijd in het project worden opgenomen?

Nee, alleen als deze regels goedgekeurd en bevestigd zijn door de zakelijke kant en niet in strijd zijn met strategische doelen. Anders kan dit bronnen van tegenstrijdigheden opleveren.

Is het genoeg om een bedrijfsregel gewoon te documenteren in de technische documentatie?

Nee, deze moet ook geverifieerd worden met experts, uitzonderingen beschreven, formuleringen afgestemd en geïmplementeerd worden in de testdocumentatie.

Typische fouten en anti-patronen

• Gemiste of verkeerd begrepen regels leiden tot herhaalde aanpassingen.
• Te technische beschrijving van bedrijfsregels zonder verwijzing naar gebruikersscenario's.
• Ontbreken van goedkeuring van de documentatie door de zakelijke opdrachtgever.

Voorbeeld uit het leven

Negatief geval: De analist noteerde bedrijfsregels van de opdrachtgever zonder verduidelijkende vragen en feedback van deskundige gebruikers. In productie kwamen ze tegen niet-geëvalueerde uitzonderingen (bijvoorbeeld, speciale betalingsgevallen). Voordelen:

• Snelle voorbereiding van analytische documentatie. Nadelen:
• Groot aantal bugs, urgente aanpassingen.

Positief geval: De analist voerde sessies met deskundige gebruikers, gebruikte besluittabellen voor alle scenario's en synchroniseerde de uiteindelijke formuleringen met meerdere stakeholders. Voordelen:

• Volledige dekking van scenario's.
• Minimalisatie van conflicten bij implementatie. Nadelen:
• Hoge tijdsinvestering voor voorbereiding en afstemming.