Antwoord.

Achtergrond van de vraag:

Automatisering van onconventionele of nieuw ontwikkelende bedrijfsprocessen werd lange tijd als een complexe taak beschouwd vanwege de afwezigheid van duidelijk gedefinieerde scenarios en hoge veranderlijkheid. Traditionele benaderingen van systeemanalyse zijn niet altijd geschikt en er is een flexibelere methodologie vereist.

Probleem:

Het belangrijkste probleem bij het werken met dergelijke processen is hun dynamiek: de beschrijving aan het begin weerspiegelt vaak niet de essentie van bepaalde operaties, en de eisen van klanten kunnen snel veranderen of verduidelijkt worden tijdens het werk.

Oplossing:

Om de eisen correct te identificeren en te beschrijven, worden iteratieve benaderingen (Agile, Lean) gebruikt, gegevens worden verzameld door observatie en snelle prototypes, gebruikers worden actief betrokken (bijvoorbeeld via workshops) en eisen worden vastgelegd in de vorm van user stories, aangevuld met levendige documentatie in Confluence, Miro, Figma, enz. Belangrijke kenmerken van de aanpak:

Continue feedback van gebruikers en het business team
Gebruik van prototyping en snelle MVP's om vage scenarios te concretiseren
Incrementele verfijning van eisen: we documenteren alleen wat levensvatbaar en herhaalbaar is

Achterhaalvragen.

Zijn de eisen aan het begin en aan het eind van de analyse van een onzekere proces hetzelfde?

Nee, na de analyse veranderen de eisen: sommige verouderen, terwijl andere pas na de toepassing van prototypes in de praktijk worden geformaliseerd.

Moet je het hele bedrijfsproces tegelijk vastleggen, als het verandert?

Nee, je moet alleen de geverifieerde en werkende fragmenten vastleggen, de rest — als hypothesen laten of verduidelijken naarmate het zich ontwikkelt.

Moet je alleen één methode voor het vastleggen van eisen kiezen?

Nee, het is belangrijk om verschillende kanalen te gebruiken: stand-up borden, elektronische concepten, prototypes — voor verschillende doelgroepen en fasen.

Typische fouten en anti-patronen

Poging om alle aspecten vooraf te detailleren (waterval)
Negeren van feedback van de gebruiker
Werken uitsluitend met al goedgekeurde documentatie of alleen mondelinge eisen, zonder levende voorbeelden

Voorbeeld uit het leven

Negatieve case:

Een bedrijf besloot een proces te automatiseren dat nog niet definitief was vastgesteld. De analist beschreef het proces strikt volgens de schema's, legde alles vast wat de medewerkers zeiden. Na de lancering veranderde het proces snel, en de systemen voldeden niet meer aan de nieuwe realiteit.

Voordelen:

Snelle integratie van bestaande schema's

Nadelen:

Proces is slechts gedeeltelijk geautomatiseerd, de meeste wijzigingen zijn niet in aanmerking genomen, dure aanpassingen

Positieve case:

De analist voerde gedeeltelijke documentatie uit van alleen stabiele fasen, bouwde een MVP met een minimale set functies, verzamelde feedback, verfijnde de eisen samen met de business en liet ruimte voor wijzigingen.