A legtöbb jóváhagyási folyamat egyszerűnek tűnik: valaki beküld valamit, egy vezető rábólint, kész. A valóságban hamar előjön a helyettesítés, a több lépcsős döntés, a határidő, a módosítás, az elutasítás utáni újraküldés és az a kérdés, hogy később ki tudja bizonyítani, mi történt.

1. Előbb az állapotokat tervezd meg

Mielőtt flow-t építesz, legyen világos, milyen állapotokon mehet végig az ügy. Beküldve, jóváhagyás alatt, visszaküldve, elutasítva, lezárva: ezek ne csak e-mail szövegek legyenek, hanem tárolt üzleti állapotok.

✓ egyértelmű státuszmodell✓ ki a következő döntéshozó✓ visszaküldés és újraküldés✓ lezárt állapot

2. A jóváhagyásnak legyen saját nyoma

A Teams- vagy e-mailértesítés kényelmes felület, de az üzleti döntés ne csak ott létezzen. Tárold a döntést, az időpontot, a döntéshozót és szükség esetén a megjegyzést is.

✓ döntéshozó✓ döntés időpontja✓ komment✓ előző és új állapot

3. Helyettesítés és határidő nélkül előbb-utóbb megáll

Szabadság, betegség vagy szervezeti változás esetén a folyamat nem függhet egyetlen személy postaládájától. A helyettesítést, emlékeztetést és eszkalációt ugyanúgy meg kell tervezni, mint az első jóváhagyási kérést.

✓ delegálás vagy helyettes✓ automatikus emlékeztető✓ eszkaláció✓ lejárt feladat kezelése

4. Több lépcsőnél ne másold egymás mögé ugyanazt a logikát

Összetettebb folyamatnál érdemes a jóváhagyási szabályokat adatalapon kezelni. Így összeghatár, szervezeti egység vagy ügytípus alapján más útvonal választható anélkül, hogy minden változtatásnál a teljes flow-t át kellene rajzolni.

✓ összeghatár✓ szervezeti egység✓ szerepkör✓ konfigurálható routing

5. Kritikus folyamatnál a monitoring nem opcionális

Ha a jóváhagyás számlát, beszerzést vagy szerződést tart fel, akkor tudni kell, ha a flow hibára futott. A csendes hiba drágább, mint maga a technikai hiba.

✓ központi naplózás✓ hibariasztás✓ korrelációs azonosító✓ üzleti státusz és technikai státusz külön