A második leckénk anyaga az üzletifolyamat-kezelés (Business Process Management = BPM) a Business Analysis 101 című MOOC képzésen belül, melyben ezúttal Micael Boyle végre nem csak elméletet mutatott, hanem diagramkészítést is. Ha elolvasod az összefoglalóm, akkor kiderül az is, mi köze az egésznek a villához és a medencékhez… (Fotó: deborahlewis)

swimming_pool_with_lane_ropes_in_place_cropped.jpg

A BPM kapcsán Peter Fingar gyakran a BPM három hullámáról beszél: az alapvető tanok és tanulmányok megjelenése az 1920-as években (pl. Frederik Taylor). A következő hullám az 1990-es években következett, mikor a szervezeti újjálakítás divatossá vált. A harmadik érett szakaszban pedig a vállalati skálázhatóság eszközeként jelent meg.

Az üzletifolyamat-kezelés egy olyan tudományág, amely az üzleti folyamatokat eszközként kezeli. Köze van a menedzsment folyamatokhoz, ezért menedzsment tudománynak nevezhetjük. A BPM az egyik kulcsa annak, hogyan működtetjük az üzletet. A folyamatok által bekapcsolódik a vállalat egészébe (end-to-end). Arról szól, hogy: Mit? Hol? Mikor? Miért? Hogyan? Ki felelős érte? Összességében a meghatározásának és a megvalósításának a célnak megfelelőnek vagy a használatra alkalmasnak kell lennie.

Stratégia szintjén a BPM-hez jelentős beruházásokra van szükség a belső üzleti kapacitások fejlesztéséhez, a vezetőség erős támogatása is kell a sikeres implementációhoz, és az új szerepeket is be kell vezetni a szervezeten belül.

Emellett pedig állandó változásokra van szükség, amelyben a menedzsment egy zárt hurok ciklusban van, a rendszerben állandóan visszajelzéseket kell adni, és a folyamat egységességét karbantartani.

A BPM-et úgy kell megtervezni, hogy hatékony, alkalmazható és megfelelően használható legyen. Illetve lehetővé kell tennie a folyamatos fejlesztést. Ezt a fejlesztést a “Process Maturity Curve” (folyamat érettségi görbe) határozza meg a cégen belül. Szóval bizonyos érettségi szintet is el kell érni a BPM használatához, és folyamatosan mérni kell az érettséget.

Az üzletifolyamat-kezelés nem egy előre megszabott keret, módszer vagy eszközkészlet, mert minden eszközt használnia kell az adott üzleti folyamathoz. Az implementációhoz szükség van technikai támogatásra is, de egy folyamati problémát nem technológiával kell megoldani, hanem magát a problémát kell megoldani (akár technológiával).

Folyamat modellezés

A modellnek nem kell mindig tartalmaznia a teljes folyamatot, hanem annak egy részletét is ábrázolhatjuk diagrammal, ha az szolgálja valamilyen célunkat. Egy üzleti elemző a következőkre használhatja a folyamat modellezést:

  • Rendszerezés: struktúrát kitalálni az összeállított tételekhez
  • Felfedezés: kutatni és megszerezni az információkat
  • Előrejelzés: hogyan nézhet ki egy jövőbeli szituáció
  • Számszerűsíteni néhány elemet
  • Leírni egy koncepciót vagy megközelítést
  • Ellenőrzés: megbizonyosodni, hogy a koncepció érthető
  • Megerősítés: a szükséglet és a képesség azonosítása az előrehaladáshoz

A folyamat leírja, hogy az emberek és a csoportok hogyan működnek együtt, illetve a munkát mennyi idő alatt végzik el. Összekapcsolja a tevékenységeket, amelyek a folyamattal kapcsolatosak. Megismételhető és az elvégzéséhez akár többféle mód is lehetséges.

A folyamat kiváltója egy esemény az adott üzleti területen (pl. termék eladása egy vásárlónak, egy senior szakértőtől információk kérése), amely kötődhet egy emberhez, kötelező tevékenységhez kapcsolódó szabályokhoz vagy egy időszakhoz. A folyamatot akkor tekinthetjük befejezettnek, ha elérte a célját.

A folyamat megértését segítheti a vizuális megjelenítés, amely tartalmazhatja hogyan halad előre a folyamat, milyen logika alapján működik, és hogyan menedzselik. A modell tartalmazhat manuális vagy automatizált tevékenységeket, illetve ezek kombinációját. Használható magasabb szintű, általános megértéshez vagy alacsonyabb szimulációhoz is. Ezentúl a modell megjeleníthet a cégen belül egy jelenlegi folyamatot vagy egy jövőbelit egyaránt.

A folyamatmodell főbb elemei:

  • jelölések: milyen ábrázolást használjunk hozzá, pl. folyamatábra, UML
  • tevékenységek: a munka lépései, amelyeket el kell végezni az üzleti folyamat megvalósításához; lehet egy egyszerű lépés vagy egy részfolyamattá is összeállhat
  • döntések: egy olyan “villa” a folyamatban, amely a folyamatot több folyamatra osztja vagy néha a különböző folyamatok eggyé válnak

business_card_holder_funky_fork_silver_1024x1024.jpg

  • események: a folyamat területén kívül történnek, talán a tevékenységek eredményei, megkapott üzenetek vagy bizonyos időszakok. Az események megszakíthatják a folyamatot vagy véget is vethetnek neki.
  • folyamat: a munkafolyamat lépéseinek irányát határozzák meg, általában diagrammokkal ábrázolják elejétől a végéig
  • szerepek: a személyek vagy csoportok egyfajta típusát jelenti, megegyezően a szervezeti modellel
  • “úszósávok és medencék”: a folyamatábrán belül a sávok lehetnek horizontális (egyenes, vízszintes) vagy vertikális (merőleges, függőleges) vonalak. Az előadó ennek szemléltetésére be is mutatott egy folyamatot a különböző szerepkörök közti cselekmények bemutatására. A “medencék” ezen belül a szervezeti határokat jelképezik, külön jelezhetjük a vásárlókat és a szervezeteket stb.

swim_lane_ba101.png

  • végpontok: a folyamat elejét és a végét jelképezik

 

Folyamatelemzés és tervezés

A következő lecke a “BPM Common Body of Knowledge” (CBOK) keretei között mutatta be a folyamatelemzést. Ez egy olyan módszer, ami a folyamat tevékenységeinek a megértését szolgálja és méri a tevékenységek eredményét összefüggésben a szervezeti célokkal.

  • A folyamat “miértje” segít megérteni a stratégiát, a hosszabb és rövidebb távú célokat, illetve a folyamatot szabályozó üzleti szabályokat.
  • A “hol” kérdésre adott válasszal látható, hogy a folyamat hol helyezkedik a nagyobb, kereszt-funkcionális folyamaton belül.
  • A “hogyan” méri a folyamat bemeneti és kimeneti elemeit.
  • A “ki” és a “mikor” méri a szerepköröket, és minden egyes folyamatrésznél az átadásokat.

A folyamatelemzés fejlesztő hatású is lehet, ha figyelünk a kiértékelésre és az erőforrás-kihasználtságra. A teljesítményadatok a folyamatot magát követik figyelemmel. A lehetőségek azonosításának összegzése pedig növeli a minőséget, a hatékonyságot és a kapacitást. A Folyamat Érettségi Modell segít azonosítani, hogy a folyamatunk milyen szinten áll. Michael Boyle ezt az IT és a Marketing együttműködésének példájával szemléltette, mikor az első szinten még fogalma sincs egyiknek, hogy mit csinál a másik; az utolsó szinten viszont már nem csak, hogy közös folyamatleírásuk van, de együtt is tudnak működni. A szintek a következők lehetnek: Tájékozott, Meghatározott, Összehangolt, Egységesített, Optimalizált.

A folyamattervezés arról szól, hogyan készítsünk specifikációt a folyamatunk jövőbeli állomásai számára, és hogyan bonyolítsuk le jobban. Tervezés során először is a folyamat jelenlegi állását kell leírni, utána következhet a megoldandó probléma, aztán hogy hogyan kellene a cégnek működnie.

Üzleti elemzői technikák

Szcenáriók és használati esetek

A két fogalom megkülönböztetésére vállalkozott a kurzus előadója a következő videóban. A megfogalmazott definíció szerint a szcenárió és a használati eset azt írja le, hogy a szereplők hogyan állnak kapcsolatban azokkal a megoldásokkal, amelyek egy vagy több célunk elérését szolgálják, vagy csak választ adnak egy szituációra.

Szcenárió

Használati eset

Csak egy módot ír le, hogy egy szereplő hogyan érhet el egy speciális célt.

Minden lehetséges eredményt leír.

Lépések sorozata, melyet a szereplőnek megtesz; leírja a megoldást, amelyet a szereplőnek meg kell tennie a cél eléréséhez

Számos szcenáriót ismertet.

Nincs formai megkötése

Elsődleges és alternatív folyamatleírásokból áll. Előbbi a legegyszerűbb módot írja le a cél eléréséhez. Utóbbi a többi lehetséges módszert.

 

Mindkettőre jellemző, hogy a következő összetevőket tartalmazza:

  • Név: A lényeg, hogy következetesen minden egyes munkához ugyanazt a névkonvenciót kell használni. A szcenáriók és a használati esetek gyakran együtt egy “történetet” mesélnek el, amihez tisztázottnak kell lenni a dokumentumok közötti kapcsolatnak és az elrendezésüknek. Mivel gyakran valamilyen tevékenységről esik szó bennük, ezért érdemes igét használni a névben.
  • Szereplő(k): Minden szereplő nevének egyedinek kell lenni a dokumentumon belül. Nem egy munkaköri elnevezésnek kell lennie, de főleg nem egy személy nevének, mert a személyt eltávolíthatják a történetből és annak továbbra is érthetőnek kell maradnia. Ezen kívül egy személy egyszerre több szerepet is elláthat a különböző szcenáriókban vagy használati esetekben.
  • Előfeltételek: Valami, aminek meg kell lennie annak érdekében, hogy a szcenárió vagy a használati eset megvalósuljon. Pl. tevékenység előtt az illetőnek be kell lépnie a rendszerbe
  • Az esemény folyamata: Lehetnek elsődleges és alternatív megoldásai, és mindig akadnak kivételek is.
  • Utólagos feltétel: Ez írja le, hogy mit várhatunk a folyamat végén, a hatás az eredmény és a folyamat az oka.
  • Kapcsolat: A használati esetek és a szereplők közti kapcsolatot írja le, csak annyit ír le, hogy az adott esetben leírt funkcionalitáshoz a szereplőnek mennyi hozzáférése van.

Adatfolyam diagram

Végre elérkeztünk az előadás során a diagramokhoz, amit már nagyon vártam! Először az adatfolyam (dataflow) diagramok jellemzőinek bemutatását hallgathattuk meg. Ezekben megjelenik az információ bemenete, a feldolgozása, a tárolása és a kilépése a rendszerből. Szavak helyett megmutatja hogyan kell elképzelnünk az információ útját.

A diagram részei lehetnek:

  • Külső entitások: szervezeten kívüli szereplők, akik adatot szolgáltatnak számunkra
  • Aktuális folyamatok: a beérkező adatokat átalakítják kimenő adatfolyamokká
  • Adattárak: ahol az adatot aktuálisan tároljuk
  • Adatfolyamok: mutatják, hogy az adat hogyan mozog a külső entitások, a folyamatok és az adattárak között

Az adatfolyam diagramokat különböző beágyazott rétegek közé rajzolhatjuk az egyszerű jelzéstől a bonyolult, kiterjesztett diagramokig. Először a Kontextus diagrammal (vagyis 0. szintű diagrammal) érdemes kezdeni, amely meghatározza az egész rendszer általános funkcióit a külső entitásokkal kapcsolatban.

dataflow_diagram_01.jpg

Majd ezt a rajzot követhetik az adatfolyam diagramok többféle rétegei (Data Flow Diagram = DFD). Az első szint mutatja meg a rendszer fő folyamatait. Minden egyes folyamat megszakítható további folyamatokkal a tervezés során.

dataflow_diagram_02.jpgAz adatfolyam diagramok a strukturált elemzési megközelítés részei, amelyek segítik az adatok áramlásának a megértését. Előnyei közé tartozik például, hogy könnyű megérteni és egy jó elemzés a programozók számára is hasznos lehet. Viszont a gyengesége, hogy nem derülnek ki belőle a munka elvégzésének felelősei, és nem mutat alternatív útvonalakat az adott folyamaton belül. 

Állapot diagram

A következő diagram-típus az állapot diagram, amely azt mutatja, milyen átmenet szükséges a következő szakaszba lépéshez. Ennek a lényeges elemei a következők:

  • Egyszerre nem lehetünk két helyen
  • Az elemeknek jól, tisztán definiáltnak és egyedinek kell lenniük
  • Minden útnak van egy kiindulópontja
  • Nincs megkötés, hogy egy úton hány megállónk lehet, csak arról kell meggyőződni, hogy az út összefüggő.
  • Az egyik állomásról a másikra való átmenethez valamilyen “kioldóra” van szükség (pl. a rendszerben megnyomunk egy gombot)

state_diagram_03.jpg

Vállalati folyamatmenedzsment

A folyamatátalakítás akkor tekinthető sikeresnek, ha érint minden elemet a cégen belül, és változásokat eredményez a munkában. Az átalakítás olykor költséges, rizikós és kaotikus. A folyamatos folyamatfejlesztés előfeltétele, hogy a cég bizonyos érettségi szintet elérjen. Az érettség szintjei a következők lehetnek (Capability Maturity Model Index, melyet a Carnegie Mellon University-n fejlesztettek ki):

  • 0. szint: Nem létező: próbálunk kísérletet tenni a folyamatok felfedezésére
  • 1. szint: Ad-hoc: készítettünk néhány mérést néhány folyamathoz
  • 2. szint: Megismételhető: különböző mérési eljárásokat ismerünk a különböző ágazatokban
  • 3. szint: Meghatározott: elkezdjük mérni a folyamatok eredményét, nem csak a folyamatokat
  • 4. szint: Megmért: a folyamatokon belül mérjük a főbb töréspontokat, úgy, hogy a mérés valós idejű vagy legalábbis közel van hozzá
  • 5. szint: Optimalizált: a cég a következő fejlesztési lehetőségeket keresi

A vállalati folyamatmenedzsment (ha már kialakult), akkor az ágazatokon belüli egyedi folyamatoktól az ágazatokon átívelő folyamatokig mindenre kiterjed. Az előadó szerint a folyamatcentrikus szervezet kialakítása lehet a cél.

A skálázhatóság ezen belül az a képesség, amely az üzletet gyorsan tudja fokozni. Ahogy a jelenlegi technológia lehetővé teszi a skálázhatóságot, látni fogjuk a különbséget az érett és a nem érett cégek között. A cloud computing ami minden eddiginél jobban lehetővé teszi, hogy egy virtuális cégen belül létezzünk.

Az üzleti elemzőre mindez úgy van hatással, hogy jobban meg tudja érteni a szervezeti víziót, misszót és stratégiát. Jobban átláthatja az aktuális helyzetet, annak minden folyamatával együtt. Meg tudja állapítani a szervezet érettségét a CMMI alkalmazásával. Értékelni tudja, hogy milyen változtatásokra van szükség, hol kell elkezdeni és hogyan lehet mértni. Össze tudja gyűjteni a követelményeket és meg is érti, hogy ezek közül mindet követelményként kell kezelni. Megállapítja a különböző megoldási lehetőségeket, és ezek alapján a legjobb megoldást ajánlja.

A bejegyzés trackback címe:

https://habosvilla.blog.hu/api/trackback/id/tr557118611

Kommentek:

A hozzászólások a vonatkozó jogszabályok  értelmében felhasználói tartalomnak minősülnek, értük a szolgáltatás technikai  üzemeltetője semmilyen felelősséget nem vállal, azokat nem ellenőrzi. Kifogás esetén forduljon a blog szerkesztőjéhez. Részletek a  Felhasználási feltételekben és az adatvédelmi tájékoztatóban.

Nincsenek hozzászólások.
süti beállítások módosítása