A követelmény-elemzés befejezése után - a hagyományos szoftver-fejlesztési utat követve - a tervezés során pontosítjuk, formalizáljuk (egy szóval modellezzük) a készülő rendszerünket. Ez így is van rendjén, amíg csak egy adott funkciót ellátó szoftver vagy egy segédfeladatot (pl. számlák nyomtatását) végző rendszer kifejlesztésével foglalkozunk. Azonban a vállalat működését több ponton támogató és egymással összefüggő funkciókat, területeket kiszolgáló komplex informatikai rendszerek esetén rendkívül fontos a folyamattervezést is végigcsinálni, mert esetleges későbbi módosítások esetén rengeteg időt és pénzt takaríthatunk meg.

A folyamattervezés célja az, hogy modellezzük meglevő vagy elképzelt üzleti tevékenységünket. Ilyen szempontból a folyamattervezés a Business Process Reengineering (BPR) egyik fázisa, és természetesen így is hatékonyan használható. Az alábbiakban röviden bemutatásra kerülő OOBPM (Object-Oriented Business Process Modeling) objektum-orientált folyamatmodellezési módszertan azonban inkább az informatikai oldalra helyezi a hangsúlyt, sőt a módszertan utolsó része kiemelten foglalkozik a létrehozott folyamatok implementálásával és az ezeket kiszolgáló kliens alkalmazások megtervezésével. A módszertan legfőbb alapelve, hogy a folyamat-logikát és az alkalmazás-logikát élesen elhatároljuk egymástól, figyelembevéve azonban, hogy a kettő együtt integránsan alkotja a rendszerünket. A folyamat-logika segítségével (vagyis a folyamat-térben) írjuk le az üzleti folyamatainkat, az ezeket felépítő tevékenységeket és a hozzájuk kapcsolódó erőforrásokat. Az alkalmazás-térben az előbbi folyamatokat, illetve tevékenységeket támogató szoftvereket írjuk le, illetve modellezzük. A két "tér" megfelelő szétválasztása esetén nem okoz problémát, ha egy folyamat megváltozik (pl. a "Megrendelés" nevű folyamatban bevezetjük a rendelés főnök általi jóváhagyását, ha annak összértéke túllépi az egymillió forintot), vagy ha egy kliens alkalmazást cserélünk le (pl. verzióváltás miatt). Mindkét esetben csak az adott "teret" kell módosítani, míg ha a szétválasztást nem tettük meg az elején, akkor az előbb leírt folyamat megváltoztatása a kliens szoftverek módosítását is jelentené, ami lényegesebben költségesebb munka.

A folyamat (process) tevékenységek sorozata, amelyeket üzleti erőforrások hajtanak végre információs erőforrások felhasználásával. Az üzleti erőforrások az embereket (mint dolgozókat) és gépeket, szoftvereket (mint automatikus munkavégző rendszereket - pl. számlázó rendszer) takarja, míg az információs erőforrások alatt a papír vagy elektronikus formában rendelkezésre álló termék-, szolgáltatás- és ügyfél-információkat, illetve egyéb dokumentumokat, adat- és tudásbázisokat értjük. A folyamatot, illetve a vele ekvivalens használati esetet az UML egyik atyja, Jacobson a következőképpen definiálja: "munkaegységek (tevékenységek) olyan sorozata, amely az üzlet egy aktora számára mérhető értéket produkál". Az üzleti aktorok azok az üzletet használók (érdekeltek), akiknek termékeket vagy szolgáltatásokat biztosítunk.

Az OOBPM négy fő fázisból áll - amelyek egyenként több lépésből tevődnek össze -, ezek a következők: Üzleti folyamat modellezés, Üzleti erőforrás modellezés, Üzleti architektúra modellezés, Üzleti folyamat specifikáció. A modellezés minden részletre kiterjed, ezért a folyamat iteratív jellegű és az egyes fázisok között sok a függőség. Ennek ellenére fő vonalakban mégis a megadott sorrendben haladunk végig az egyes fázisokon, de természetesen visszacsatolások, elágazások előfordulhatnak (ez természetesen a konkrét esettől is függ). Az OOBPM a szoftverfejlesztésben de facto szabványnak számító Unified Modeling Language (UML) jelölésrendszerét használja, így kompatibilis az - életciklusban utána következő - tervezéssel, sőt a tervezés első lépéseit már itt elvégezhetjük. Természetesen - ahogyan a tervezésben is, úgy a folyamattervezés során is - végig hatékonyan alkalmazhatunk egy modellező eszközt.

Az OOBPM menete