První generace BPMS

Na následujícím obrázku vidíme životní cyklus procesních změn, tak jak jsou většinou ještě dnes realizovány:

Celkové cíle jsou postupně upřesňovány a zadávány jednotlivým odborným útvarům. V případě, že vyvolají potřebu změny pracovních toků, je buď přímo provedena věcná specifikace a ta předána k realizaci IT, nebo za pomocí procesních specialistů je vytvořeno procesní zadání.

Na úrovni IT pak dochází k analýze požadavku z hlediska požadované funkcionality. Funkční specifikace je buď předána přímo ke customizaci IS nebo k vývoji v příslušném IDE, nebo je zde doplněn mezistupeň, kdy funkční specifikace je v nástroji typu CASE strukturovaně analyzována, dekomponována a nově navržena.

Po realizaci požadavku v IS, tvorbě uživatelské dokumentace a příslušném testování je nový postup prakticky realizován a nepřímo měřen prostřednictvím controllingu, v lepším případě doplněného i o klíčové nefinanční ukazatele.

Odborné útvary pak až v praxi porovnávají požadovanou a skutečnou funkcionalitu resp. podporu svých procesů s případnými opravnými smyčkami. Na úrovni TOP managementu je pak výsledek posuzován zcela nepřímo podle splnění zadaných vesměs finančních cílů.

Význam BPM je tedy okrajový, slouží jen jako nástroj k procesně-funkční dekompozici s důrazem spíše na provázanost a pokrytí dalších dimenzí procesu, např. organizační (nové role resp. organizační struktury ap.). V praxi je procesní modelování velmi často obcházeno (odborní uživatele kontaktují se svými požadavky přímo IT), protože odborným útvarům přináší jen malé porozumění podstatě jejich problému a pro IT představuje jen komplikaci, protože zanáší nové požadavky do funkčně-orientovaných řešení ve stávajících aplikacích.