Folyamatdokumentáció-sablon: hogyan dokumentáljunk egy folyamatot úgy, hogy be is tartsák (2026)

A folyamatdokumentáció annak írásos leírása, hogyan halad át egy munka a szervezeten, az elindító eseménytől az lezáró eredményig: a szakaszok sorrendben, az egyes szakaszok felelős szerepköre, mi kerül át az egyik szerepkörtől a másikhoz, mit hagy maga után minden szakasz, és mi történik, ha a szokásos út elakad. A folyamatdokumentáció-sablon az a rögzített váz, amelybe ezek a szavak kerülnek, hogy a tizedik folyamat is úgy olvasódjon, mint az első, és aki egyet elolvasott, mindegyikben eligazodjon.

A legtöbb folyamat valahol már dokumentált: egy két évvel ezelőtti workshop diagramján, egy wikioldalon, amelyet senki sem nyit meg, vagy annak az egy embernek a fejében, aki az elejétől fogva csinálja. A gond ritkán az, hogy a dokumentum nem létezik. Hanem az, hogy nem tartják be, és ennek három oka minden szervezetben ugyanaz. Ez az útmutató először a mesterségről szól: mi a folyamatdokumentum és mi nem, mi a szokásos formátum, itt a másolható sablon és egy kidolgozott példa. Utána jön a három ok és mindegyik megoldása, majd az, hogy a dokumentum és az átbeszélése hol él azokban az eszközökben, amelyeket a csapat már használ, és mit kap az a kolléga, aki más nyelven olvassa. Mert a folyamatdokumentumot azon a reggelen mérik le, amikor egy új ügyfélkapcsolati vezetőnek, egy új ápolónak vagy egy új forgalmazó ügyintézőjének át kell adnia valamit a következő embernek, és nem tudja, ki az.

Mi a folyamatdokumentum – és mi nem

Három dokumentum írja le, hogyan készül el a munka folyamatszinten, és gyakran összekeverik őket egymással és az alattuk lévő eljárásokkal:

A térkép a kép; a folyamatdokumentum a szöveg, amely használhatóvá teszi a képet; az SOP-k a részletek az egyes dobozok alatt. Ez a megkülönböztetés dönti el a terjedelmet: az a folyamatdokumentum, amely elmagyarázza, hogyan kell az egyes lépéseket megkattintani, olyan kézikönyv, amelyet senki sem olvas, a szöveg nélküli folyamattérkép pedig olyan kép, amelyet mindenki másként értelmez. Az SOP-ról, a sablonjáról és a felülvizsgálati ciklusáról az SOP-sablon és a hogyan írjunk SOP-t cikk szól; ez az útmutató az fölöttük lévő szintről szól, arról, amelyik megmondja, hol kellenek SOP-k, és ki kinek mit ad át.

A folyamatdokumentum nem is annak a leírása, hogyan szokták csinálni a munkát. Ez a megegyezés szerinti út, gazdával, verzióval és felülvizsgálati dátummal. Ezért az a szakasz, amelyet senki sem követ, vagy módosítandó szakasz, vagy megbeszélendő kérdés, nem pedig egy mondat, amelyet bent lehet hagyni.

Mit tartalmazzon: a szokásos formátum

A használható folyamatdokumentum egy fejlécből és nyolc szakaszból áll. Az interneten található sablonok többsége a célt, a lépéseket és egy diagramot tartalmazza, és megáll ennyinél. Ezért olvassa el a legtöbb folyamatdokumentumot az ember egyszer, aztán soha többé:

A fejléc – a dokumentum azonosítója, öt mező egy sorban: egy hivatkozható azonosító („PR-HR-02"), egy verzió („v1.3"), a gazda, egyetlen megnevezett személy, aki az egész folyamatért felel, nem egy osztály, a hatálybalépés dátuma és a következő felülvizsgálat dátuma. Az a folyamat, amelynek nincs felülvizsgálati dátuma, akkor kerül felülvizsgálatra, amikor valami elromlik.

1. Cél és eredmény. Egy-két mondat: mit ad a folyamat, kinek, és milyen az, ha jó – számmal, ha van. „Az új munkatársnak az első napon van fiókja, eszköze, terve és megnevezett mentora, a 30. napig pedig lezajlik a 30 napos értékelése."
2. Kiváltó esemény és végállapot. Az esemény, amely elindítja a folyamatot, és az eredmény, amely lezárja. „Akkor indul, amikor az aláírt szerződés bekerül a HR-mappába; akkor ér véget, amikor rögzítik a 30 napos értékelést." Ami e két mondat között van, az a folyamat; ami rajtuk kívül, az másik dokumentum. Ha a folyamatnak nincs egyértelmű vége, akkor két folyamat.
3. Hatókör. Mikor vonatkozik a folyamat, és mikor nem, a szomszédos folyamatokat azonosítóval megnevezve. „A velünk szerződéses jogviszonyban álló munkatársak, bármely országban. Nem: külső vállalkozók (PR-HR-04); nem: belső áthelyezések (PR-HR-06)."
4. Szerepkörök. Minden szerepkör, amely megjelenik a szakaszokban, azzal, amiért felel – szerepkörök, nem nevek, hogy a dokumentum túlélje az új felvételt. Egyikük a folyamatgazda, aki az egész folyamatért felel, azokért az átadásokért is, amelyeknek alapból senki sem a gazdája.
5. Szakaszok és átadások. A dokumentum szíve: a szakaszok sorrendben, mindegyikhez a végző szerepkör, ami megérkezik (bemenet), ami távozik és hol rögzítik (kimenet), kihez kerül, és a határidő. Az átadást kifejezetten le kell írni – „kinek: IT, a −5. napig" –, mert az átadásnál buknak el a folyamatok: mindkét fél azt hiszi, hogy a másiknál van.
6. Kivételek és eszkaláció. Az ideális úttól eltérő ágak: mi történik, ha az engedély késik, a hitelellenőrzés megbukik, a gazda távol van. Minden kivétel megnevez egy szerepkört vagy személyt, aki dönt, sosem azt, hogy „kérdezzen meg valakit". Az utolsó sor azt fedi le, amit nem vettünk észre: „Minden, amit itt nem szabályozunk: a folyamatgazda dönt, és az esetet a következő felülvizsgálaton felvetik."
7. Mérőszámok. Két-három szám, amelyet a gazda figyel – átfutási idő a kiváltó eseménytől a végállapotig, ügyek száma havonta, a kivételbe futók aránya. Nem dashboard; azok a számok, amelyek jelzik a gazdának, hogy a folyamat elcsúszik, még mielőtt valaki panaszkodna.
8. Kapcsolódó dokumentumok és verziótörténet. Az egyes szakaszok alatti SOP-k, a szabályzat, amelyet a folyamat megvalósít, a térkép linkje; majd verziónként egy sor – dátum, mi változott, ki hagyta jóvá. A történet az, ami megakadályozza, hogy ugyanazt a hibát újra bevezessék egy új verziószám alatt.

Ami kimarad: az egyes szabályok indoklása (ez a szabályzat dolga), egy szakasz kattintásról kattintásra menő leírása (ez az SOP dolga), és minden, amivel az ember nem tud mit kezdeni. „Nagyra értékeljük a zökkenőmentes onboardingot" egy érzés, nem szakasz.

Hogyan dokumentáljunk egy folyamatot úgy, hogy be is tartsák

Három ok magyaráz meg szinte minden be nem tartott folyamatdokumentumot, és mindegyikre van megoldás, amely az íráshoz tartozik, nem valamilyen későbbi kikényszerítéshez.

Első ok: a folyamatot úgy írja le, ahogy megtervezték, nem úgy, ahogy futtatják. A dokumentumot egy workshopon írták azok, akik a munkát irányítják, a munkát végzők pedig egy másik változatot ismernek – az oldalt futó táblázattal és azzal a kollégával, akit a 3. szakaszban felhívnak. A megoldás: az írás előtt feltérképezni a folyamatot bizonyítékokból. Kövessünk végig három valós esetet a kiváltó eseménytől a végállapotig, és jegyezzük fel, mi történt valójában: az e-mailek, az üzenetek, az űrlapok, a várakozások. Ha a folyamat egy csoportos csevegésben él – a forgalmazók rendelései WhatsAppon érkeznek, a műszakcseréket egy Telegram-csoportban egyeztetik –, akkor a csevegés a bizonyíték, és az átbeszélés a története alapján indul: hogy mit ad az Export chat és hol ér véget, azt a hogyan exportáljunk WhatsApp-csevegést cikk írja le. Ahol a három eset eltér, ott van a dokumentum létjogosultsága; minden eltérésnél döntsük el, hogy a szövegben javítandó szakasz-e, vagy a csapattal megbeszélendő kérdés.

Második ok: senki sem találja a jelenlegi verziót. A dokumentum egy negyvenedmagával teli mappában van, egy másolat valakinek az asztalán, egy harmadik verzió a wikiben, és akinek kedd reggel szüksége van rá, inkább megkérdez egy kollégát. A megoldás: ott közzétenni, ahol a csapat amúgy is olvas, látható fejléccel. Egyetlen hely, legelöl a jelenlegi verzió, felül a gazda neve és a felülvizsgálat dátuma – hogy az „ez még helyes?" kérdésre a fejléc válaszoljon, ne a körbekérdezés. A szakaszok pedig szerepkörök közötti átadásokként vannak megírva, hogy mindenki egy percen belül megtalálja a saját szakaszát és a két szomszédosat.

Harmadik ok: megváltozott, és akiknek a szakasza módosult, azoknak senki sem szólt. Egy felülvizsgálat a hitelellenőrzést a komissiózás elé tette, vagy új lépést vezetett be az áthelyezett munkatársakra, a dokumentumot frissítették – de a raktár és a felvételt végző vezetők továbbra is a régi módon dolgoztak. A megoldás: átbeszélni a folyamatot azokkal, akik működtetik, és minden változást a megváltozott sorokkal közzétenni. Az átbeszélés egy meeting: a gazda és szerepkörönként egy ember, a jelenlegi verzió mindenki képernyőjén, minden szakaszt az olvas fel, aki végzi, és minden átadást mindkét fél megerősít. Amit az átbeszélés módosít, az új verzió lesz egy sorral a történetben, a megváltozott három sor pedig még aznap eljut azokhoz, akiknek a szakaszát érintik, ott, ahol amúgy is olvasnak. Az a döntés, amely nem szakaszt, hanem szabályt változtat, a döntési naplóba is bekerül, a bejegyzésben a folyamat azonosítójával.

A sorrend tehát: válasszunk egy egyértelmű kezdettel és véggel rendelkező folyamatot; kövessünk végig három valós esetet; írjuk meg először a szakaszokat a sablonban, kifejezett átadásokkal; töltsük ki a kivételeket abból, amit az esetek megmutattak; beszéljük át szerepkörönként egy emberrel; tegyük közzé ott, ahol a csapat olvas, a gazda nevével és a felülvizsgálat dátumával a fejlécben; és vegyük fel a felülvizsgálat dátumát a naptárba. Az így elkészült dokumentumot azért tartják be, mert igaz, megtalálható és közzétett – ezt a három tulajdonságot a sablon önmagában nem adja meg.

Folyamatdokumentáció-sablon

[Folyamat azonosítója] — [Folyamat neve]
Verzió: [n.n] · Gazda: [név, szerepkör] · Hatályos: [dátum] · Következő felülvizsgálat: [dátum]

1. Cél és eredmény
[Egy-két mondat – mit ad a folyamat, kinek, és milyen az, ha jó, számmal, ha van.]

2. Kiváltó esemény és végállapot
Akkor indul, amikor: [az esemény] · Akkor ér véget, amikor: [az eredmény, amely ekkor már létezik]

3. Hatókör
Kiterjed: [esetek, telephelyek, ügyfelek, országok] · Nem terjed ki: [amit másik folyamat kezel, az azonosítójával]

4. Szerepkörök
Folyamatgazda: [az az egy személy, aki az egész folyamatért felel]
[Szerepkör] — [miért felel ebben a folyamatban]
[Szerepkör] — [miért felel ebben a folyamatban]

5. Szakaszok és átadások
5.1 [Szakasz] — [szerepkör] — be: [ami megérkezik] — ki: [ami távozik, hol rögzítik] — kinek: [következő szerepkör] — határidő: [időkorlát]
5.2 [Szakasz] — [szerepkör] — be: … — ki: … — kinek: … — határidő: …
5.3 [Szakasz] — [szerepkör] — be: … — ki: … — kinek: … — határidő: …

6. Kivételek és eszkaláció
Ha [feltétel]: [mi történik, ki dönt]
Ha [feltétel]: [mi történik, ki dönt]
Minden, amit itt nem szabályozunk: [szerepkör] dönt; az esetet a következő felülvizsgálaton felvetik.

7. Mérőszámok
[Két-három szám, amelyet a gazda figyel – átfutási idő, ügyek száma havonta, a kivételbe futók aránya – és hol olvassák le őket.]

8. Kapcsolódó dokumentumok és verziótörténet
SOP-k: [azonosítók, szakaszonként egy, ahol szükséges] · Megvalósítja: [szabályzat] · Térkép: [link a diagramhoz]
v[n.n] — [dátum] — [mi változott] — jóváhagyta: [név]
v[n.n] — [dátum] — [mi változott] — jóváhagyta: [név]

A sablon egyszerű szöveg félkövér címkékkel, ezért átformázás nélkül beilleszthető Word-fájlba, Google Docba, wikioldalra, Slack canvasba vagy csevegési jegyzetbe. A két leggyakrabban üresen hagyott rész az átadás – „kinek, mikorra" – és a felülvizsgálat dátuma; ez a kettő dönti el, hogy egy év múlva a folyamatot még úgy futtatják-e, ahogy a dokumentum mondja.

Kidolgozott példa: új munkatárs onboardingja az aláírt szerződéstől a 30. napig

Egy hatvanfős cég, három országban lévő munkatársakkal; a folyamat négy szerepkört érint, és akkor ér véget, amikor rögzítik a 30 napos értékelést.

PR-HR-02 — Új munkatárs onboardingja
Verzió: 1.3 · Gazda: Működési vezető, Inés M. · Hatályos: 2026. okt. 1. · Következő felülvizsgálat: 2027. ápr. 1.

1. Cél és eredmény — Az új munkatársnak az első napon van működő fiókja, eszköze, első havi terve és megnevezett mentora, a 30. napig pedig rögzített 30 napos értékelése, bármelyik országban kezd is.
2. Kiváltó esemény és végállapot — Akkor indul, amikor: az aláírt szerződés bekerül a HR-mappába. Akkor ér véget, amikor: a 30 napos értékelést rögzítik a munkatárs aktájában.
3. Hatókör — A velünk szerződéses jogviszonyban álló munkatársak, bármely országban, irodában vagy távmunkában. Nem: külső vállalkozók (PR-HR-04); belső áthelyezések (PR-HR-06).
4. Szerepkörök — Folyamatgazda: működési vezető. HR: az akta, a dokumentumok, a bérszámfejtés, a üdvözlőcsomag. IT: fiókok, eszközök, hozzáférések. Felvételt végző vezető: a terv, a mentor, a egyeztetések. Pénzügy: a bérszámfejtés beállítása.

5. Szakaszok és átadások
5.1 Az akta megnyitása — HR — be: az aláírt szerződés — ki: az onboarding-nyilvántartás a kezdés dátumával, országgal, vezetővel, nyelvvel; a munkatárs nyelvén elküldött üdvözlőcsomag — kinek: IT és a felvételt végző vezető — határidő: két munkanappal az aláírás után
5.2 Fiókok és eszközök — IT — be: a nyilvántartás — ki: létrehozott fiókok, a munkatárs címére elküldött laptop, a szerepköri profil szerinti hozzáférések; visszaigazolás a nyilvántartásban — kinek: HR — határidő: öt munkanappal a kezdés dátuma előtt
5.3 Dokumentumok és bérszámfejtés — HR, majd pénzügy — be: a nyilvántartás, a munkatárs dokumentumai (munkavállalási engedély vagy regisztráció, ahol az ország megköveteli) — ki: a munkatárs a bérszámfejtésben, a dokumentumok az aktában — kinek: a felvételt végző vezető — határidő: a kezdés dátuma
5.4 Az első hónap megtervezése — felvételt végző vezető — be: a nyilvántartás — ki: 30 napos terv az aktában, megnevezett mentor, az első hét a munkatárs naptárában, a csapattal lefoglalt üdvözlő hívás — kinek: a munkatárs, az első napon — határidő: a kezdés előtti nap
5.5 Az első nap — felvételt végző vezető és mentor — be: a terv — ki: megtartott üdvözlő hívás, átbeszélt terv, a munkatárs nyitott kérdései naplózva a csapat csatornájában — kinek: a munkatárs — határidő: az első nap vége
5.6 Egyeztetések — felvételt végző vezető — be: a terv, a naplózott kérdések — ki: egy 7. napi és egy 30. napi egyeztetés, a 30 napos értékelés rögzítve az aktában — kinek: HR, a nyilvántartás lezárásához — határidő: a 30. nap

6. Kivételek — Az engedély vagy a regisztráció nem készül el a kezdésig: a munkatárs azokon a feladatokon kezd, amelyeket a vezető engedélyezettként jelöl meg nélküle; a követés a HR-hez tartozik, a dátum bekerül a nyilvántartásba. A laptop nem érkezik meg a −2. napig: az IT az iroda készletéből kölcsönlaptopot küld; a működési vezetőt még aznap értesítik. A munkatárs olyan országban kezd, ahol még nem vettünk fel senkit: az 5.3 szakasz szünetel; a működési vezető három munkanapon belül dönt a közvetítő munkáltatós (employer-of-record) megoldásról (PR-HR-05).
7. Mérőszámok — Munkanapok az aláírástól a kész fiókokig (cél ≤ 7); azon munkatársak aránya, akiknek a 30. napig rögzítették a 30 napos értékelését (cél 100 %); az első héten naplózott kérdések, amelyeket a negyedéves felülvizsgálaton olvasnak át, hogy kiderüljön, melyik szakasz termeli őket újra és újra.
8. Kapcsolódó — SOP-IT-03 „Új fiókok és hozzáférések"; SOP-HR-08 „Bérszámfejtés beállítása országonként"; Onboarding-szabályzat 2. pont; térkép: a sávos diagram a HR-mappában.
v1.3 — 2026. okt. 1. — az üdvözlőcsomagot mostantól a munkatárs nyelvén küldjük; 7. napi egyeztetés hozzáadva — jóváhagyta: Inés M.
v1.2 — 2026. jún. 3. — a laptop szállítása a kezdés előtt öt napra került két késett kézbesítés után — jóváhagyta: Inés M.

Figyeljük meg, mit csinál a példa. Minden szakasz megnevezi a szerepkört, azt, ami megérkezik, ami távozik és hol rögzítik, kihez kerül tovább és mikorra – így az elmaradt átadás üres helyként látszik a nyilvántartásban, nem meglepetésként az első napon. Minden kivétel megnevezi, ki dönt. A mérőszámok három szám, nem dashboard. A történet pedig megmagyarázza, miért olyanok a szakaszok, amilyenek: az 5.2 szakasz azért kapta a határidejét, mert két laptop késett, a 7. napi egyeztetés pedig azért létezik, mert a 30. napi értékelésen újra és újra olyan kérdések merültek fel, amelyekre az első héten kellett volna választ kapni.

Egy rövidebb második példa, egy exportőr értékesítési folyamatának alakja forgalmazókkal:

PR-SA-01 — Rendeléstől a szállításig · Gazda: Exportvezető · Akkor indul, amikor: megérkezik egy forgalmazó rendelése · Akkor ér véget, amikor: a szállítás visszaigazolva és a számla elküldve
1. Rendelés ellenőrzése — ügyfélkapcsolati felelős — be: a rendelés — ki: a rendelés visszaigazolva a rendszerben, vagy kérdés vissza a forgalmazónak — kinek: pénzügy — határidő: egy munkanap
2. Hitelellenőrzés — pénzügy — be: a visszaigazolt rendelés — ki: felszabadítva, vagy indoklással visszatartva — kinek: raktár — határidő: egy munkanap
3. Komissiózás és csomagolás — raktár — be: a felszabadított rendelés — ki: becsomagolva, a csomagjegyzékkel — kinek: logisztika — határidő: három munkanap
4. Dokumentumok és szállítás — logisztika — be: a becsomagolt rendelés — ki: lefoglalt szállítmány, a célország dokumentumai csatolva, nyomkövetés a rendszerben — kinek: pénzügy és az ügyfélkapcsolati felelős — határidő: egy munkanap
5. Számlázás és visszaigazolás — pénzügy, majd az ügyfélkapcsolati felelős — be: a szállítmány — ki: számla elküldve; szállítás visszaigazolva a forgalmazóval és rögzítve — Ha a hitel vissza van tartva: az ügyfélkapcsolati felelős egy munkanapon belül felhívja a forgalmazót; az exportvezető dönt a felszabadításról vagy az előrefizetésről.

Tizenkét sor, és a forgalmazó új ügyintézője és a raktár új embere egyaránt tudja, kire vár.

Hol él a folyamatdokumentum és az átbeszélése az Ön által már használt eszközökben

Maga a dokumentum ott él, ahol a csapat dokumentumai: egy Word-fájl egy megosztott könyvtárban, egy Google Doc, egy wikioldal, egy canvas egy csatornában. Az átbeszélés egy meeting, és minden platformnak van helye annak, amit az átbeszélés maga után hagy; mindegyik máshol áll meg. Csak dokumentált működés, a gyártók saját oldalairól, az oldal ellenőrzésének hónapjával:

Két dolog mindenhol ugyanaz. A folyamatdokumentum egyetlen nyelven, azon, amelyen megírták, létező fájl, és aki más nyelven olvas, az ezt olvassa vagy egy másolatot, amelyet valaki készített; és amit az átbeszélés megváltoztatott, az csak akkor kerül a dokumentumba, ha utólag valaki beírja, ugyanazon a nyelven. Az ezen programcsomagok által dokumentált fordítás a híváshoz tartozik, nem a dokumentumhoz: a Microsoft a Teams meetingeken az élő fordított feliratokat dokumentálja, ha a szervező Teams Premium vagy Microsoft 365 Copilot licenccel rendelkezik, a Google pedig a Meet fordított feliratait a jogosult Workspace csomagokon (mindkettő ellenőrizve 2026 augusztusában) – hogy mindegyik mit fed le és hol áll meg, azt a Microsoft Teams élő fordítás és a Google Meet élő fordítás cikk írja le. A folyamat, amelyet az új ügyintéző kedden megnyit, és az átbeszélés, amely módosította, más objektumok, mint ezek a feliratok, és azon a nyelven olvashatók, amelyen beírták őket.

Hogyan maradnak olvashatók a folyamat, az átbeszélése és a története minden tag számára

Az InterMIND egy kommunikációs tér, ahol a csapat munkája egy csatornában él, ezért a kész folyamatdokumentumnak magától értetődő otthona van: a folyamatot futtató csapat csatornája – egy csatorna a HR, az IT, a pénzügy és a felvételt végző vezetők számára, akik mind egy-egy szakasz gazdái. Jegyzetként közzétéve – formázott szöveges üzenet fejlécekkel és számozott listákkal, amelyet később a saját menüjéből lehet szerkeszteni – minden tag a saját nyelvén olvassa, az eredetire egy kapcsolóval lehet váltani, és kitűzhető, hogy a jelenlegi verzió legyen az első, amit egy új kolléga talál; bekapcsolt szerkesztési előzmények mellett egy megváltozott szakasz korábbi szövege az aktuális szöveg fölött jelenik meg szószintű különbségként, időbélyeggel. Fájlként feltöltve – PDF vagy Word-dokumentum – minden csomagon tartalmaz egy MI-összefoglalót az olvasó nyelvén, minden pontot ahhoz a bekezdéshez kapcsolva, amelyből származik, így az egyoldalas olvasmány már létezik, mielőtt bárki megírta volna; a fizetős csomagokon maga a fájl is lefordítva nyílik meg az olvasó nyelvén (30 nyelv a dokumentumokhoz). Ha a mesterpéldány egy dokumentumeszközben marad, a frissítései e-mailben érkeznek a csatornába: a csatorna házigazdája külön címet ad neki, és az oda küldött üzenet rendes üzenetként jelenik meg, a feladó neve és a csatolmányok megtartásával.

Az átbeszélés ebből a csatornából indul. A hívás alatt a jelenlegi verzió a videócsempék mellett kerül mindenki képernyőjére a Share to conference funkcióval – egy jegyzet, vagy a csevegésben linkelt Google Docs- vagy OneDrive-dokumentum –, és minden résztvevő egymástól függetlenül görget benne és a saját nyelvén olvassa; a megosztott jegyzetet a megosztó élőben szerkeszti, miközben a terem nézi, hogyan alakul a módosított átadás. Amikor a hívás véget ér, az összefoglaló magából a meetingből készül – egy összefoglaló, a megállapodottként, nyitottként vagy vitatottként jelölt pontok, az action items felelősökkel, minden sor megtartja az időbélyegét –, és a munkamenet alatt megosztott dokumentumok összefoglalói is hozzájárulnak a elhangzottak mellé. E-mailben érkezik, üzenetként a csatornában és linkként a naptáresemény­ben, és minden bejelentkezett tag a saját nyelvén olvassa: a feljegyzés olvasónként van lefordítva, nem egyszer, azon a nyelven megírva, amelyet a terem épp használt. Bármely tag szerkesztheti, minden szerkesztés megtartja a szerzőt és a változattörténetet, a csatorna pedig megőrzi minden korábbi munkamenet összefoglalóját – így a v1.3-at létrehozó átbeszélés egyetlen kattintásra van a v1.3-at tartalmazó jegyzettől. A tag saját asszisztense – Claude, ChatGPT, Copilot vagy Gemini, az MCP-összekötőn keresztül csatlakoztatva – egyetlen kérdéssel keres az összefoglalókban, átiratokban, csevegésekben és a megosztott fájlok szövegében: „miért megy a laptop a kezdés előtt öt nappal?", és magát a dokumentumot is elolvassa; ez az MI-funkciókat bekapcsoló szervezeteknél működik. A fenti táblázat mellé téve a különbség egyszerű ténymegállapítás: az ezen programcsomagok által dokumentált feliratok a hívást fordítják, amíg az tart; itt a folyamat, az átbeszélése és a története egyetlen feljegyzés, amelyet minden tag a saját nyelvén olvas.

A folyamatban részt vevők nem mindig munkatársak. Egy forgalmazó rendelésfelvevője, egy másik országbeli bérszámfejtő szolgáltató, egy külső vállalkozó, aki egy szakasz gazdája: a csatorna külső tagja e-mailen keresztül, ingyenes fiókkal csatlakozik, és a folyamatot és a történetét ugyanúgy olvassa, mint mindenki más; a fiók nélküli személy egyetlen meeting vendége – hivatkozással csatlakozik az átbeszélésre, telefonról, ingyen, élőben hallja a saját nyelvén, és utána nem kap feljegyzést. A házigazda biztosítja a teret, és fizetős csomagon csak az elmúlt 28 napban aktív tagok után fizet – aki csatlakozott meetinghez, írt csevegésben vagy megkérdezte az asszisztenst; azok a tagok, akik elcsendesednek, ingyen megtartják a hozzáférésüket.

• Nyisson meg egy teljes összefoglalót — valódi feljegyzés, ugyanazzal a kóddal megjelenítve, amely a sajátját írja.
• Próbálja ki az élő demót — regisztráció nélkül; beszéljen, és hallja, ahogy a termet hallgatónként lefordítják.

A folyamatdokumentálás mint mesterség minden eszközt túlél: valakinek még mindig végig kell követnie három valós esetet, a szakaszokat olyan átadásokként kell megírnia, amelyeket egy második ember ellenőrizni tud, és az egészet át kell beszélnie szerepkörönként egy emberrel. Ami nem kell, hogy túlélje, az a második munka – minden verzió lefordított másolatának kézi karbantartása, és az átbeszélés által megváltoztatottak újragépelése egyetlen nyelven olyanok számára, akik másokat olvasnak.

GYIK

Mi a folyamatdokumentáció?

A folyamatdokumentáció annak írásos leírása, hogyan halad át egy munka a szervezeten, az elindító eseménytől a lezáró eredményig: a szakaszok sorrendben, az egyes szakaszok felelős szerepköre, mi kerül át az egyik szerepkörtől a másikhoz, mit hagy maga után minden szakasz, a szokásos úttól eltérő kivételek és ki dönt róluk, valamint az a néhány szám, amelyet a gazda figyel. A folyamattérkép – a diagram – és az SOP-k között helyezkedik el, amelyek leírják, hogyan végzik el az egyes szakaszokat lépésről lépésre.

Mit tartalmazzon a folyamatdokumentáció?

Egy fejlécet az azonosítóval, verzióval, gazdával, hatálybalépés dátumával és a következő felülvizsgálat dátumával; a célt és az eredményt; a kiváltó eseményt és a végállapotot; a hatókört, benne azt is, amire a folyamat nem terjed ki; a szerepköröket, egy megnevezett folyamatgazdával; a szakaszokat sorrendben, mindegyikhez a szerepkört, a bemenetet, a kimenetet és hogy hol rögzítik, a következő szerepkört és az időkorlátot; a kivételeket és az eszkalációt, mindegyikhez egy döntéshozóval; két-három mérőszámot; végül a kapcsolódó SOP-kat, a szabályzatot, amelyet megvalósít, és egy verziótörténetet.

Hogyan dokumentáljunk egy folyamatot lépésről lépésre?

Válasszunk egy egyértelmű kiváltó eseménnyel és végállapottal rendelkező folyamatot. Kövessünk végig három valós esetet az elejétől a végéig, és jegyezzük fel, mi történt valójában, az ágakat is beleértve. Először a szakaszokat vázoljuk fel a sablonban, mindegyiket átadásként – szerepkör, bemenet, kimenet, következő szerepkör, időkorlát. Adjuk hozzá az esetek által feltárt kivételeket, mindegyikhez a döntéshozóval. Töltsük ki a célt, a hatókört, a szerepköröket és a fejlécet. Beszéljük át a dokumentumot szerepkörönként egy emberrel, mindenki a saját szakaszát olvassa fel hangosan és erősíti meg az átadásokat. Tegyük közzé ott, ahol a csapat már olvas, a gazda és a felülvizsgálat dátuma láthatóan, és vegyük fel a felülvizsgálat dátumát a naptárba.

Mi a különbség a folyamatdokumentáció és az SOP között?

A folyamatdokumentáció azt írja le, hogyan halad a munka szerepkörök és csapatok között – szakaszok, átadások, amit minden szakasz maga után hagy –, folyamatonként egy oldal szintjén. Az SOP azt írja le, hogyan végzi el ezek egyik szakaszát egy szerepkör, lépésről lépésre, egészen az egyes lépések eredményéig. A folyamatdokumentum megmondja, hol kellenek SOP-k és ki kinek mit ad át; egy SOP egy embernek mondja meg, mit kell tennie kedd reggel. Ha egy egész csapatokon átívelő folyamathoz írunk SOP-t, az egy olyan kézikönyvet eredményez, amelyet senki sem nyit meg; ha egy folyamatdokumentumot SOP-részletességgel írunk, az ugyanezt.

Melyek a folyamatdokumentáció példái?

Bármely ismétlődő, szerepköröket átfogó folyamat egyértelmű kezdettel és véggel: egy új munkatárs onboardingja az aláírt szerződéstől a 30. napig; egy forgalmazó rendelése a visszaigazolt szállításig és számláig; egy ügyfélpanasz a beérkezéstől a lezárásig; egy beteg a beutalótól az első vizitig; egy új termék a jóváhagyott briefből a katalógusban való szereplésig; a hó végi zárás a munkaidő-nyilvántartásoktól az elküldött számlákig. Az útmutató kidolgozott példája a munkatársak onboardingja – hat szakasz négy szerepkörön át, három kivétel, három verzióból álló történet –, utána egy rövidebb rendeléstől a szállításig példával.

Van folyamatdokumentáció-sablon Wordben vagy Google Docsban?

Az útmutatóban található sablon egyszerű szöveg félkövér címkékkel, ezért átformázás nélkül beilleszthető Word-dokumentumba, Google Docba, wikioldalra, Slack canvasba vagy csevegési jegyzetbe. A formátum fontosabb, mint a fájl: bármi tartja is a dokumentumot, kell hozzá a fejléc a gazdával és a felülvizsgálat dátumával, a kiváltó esemény és a végállapot, a szerepkörök közötti átadásokként megírt szakaszok időkorláttal, minden kivételhez egy megnevezett döntéshozó és egy verziótörténet – és ott kell élnie, ahol a folyamatot működtetők már olvasnak.

Ki írja a folyamatdokumentációt?

A folyamatgazda – egyetlen megnevezett személy, aki az egész folyamatért felel, általában annak a területnek a vezetője, amelyen a folyamat nagyrészt halad – az egyes szakaszt végző szerepkörök egy-egy képviselőjével. A gazdánál van a toll és a felülvizsgálat dátuma; a szakaszokat végzők társszerzők, mert a róluk, nem velük írt dokumentum a megtervezett folyamatot írja le, miközben a valódi a fejükben él. Az újonc a tesztelő: ha egy percen belül megtalálja a saját szakaszát és a két szomszédosat, a dokumentum működik.

Milyen gyakran kell frissíteni a folyamatdokumentációt?

A fejlécében megadott felülvizsgálati dátumon – hat vagy tizenkét havonta szokásos, rövidebb időközzel ott, ahol a folyamat szabályozott –, és korábban, ha négy dolog egyike bekövetkezik: egy átadás elbukott és senki sem volt a gazdája, megváltozott egy eszköz vagy űrlap, amelytől egy szakasz függ, megváltozott a szabály, amelyet a folyamat megvalósít, vagy elmozdultak a mérőszámok. Minden frissítés új verzió, egy sorral a történetben, amely megmondja, mi változott és ki hagyta jóvá; a régi verziót megőrzik, és akiknek a szakasza megváltozott, azokat még aznap értesítik a megváltozott sorokkal.

Források: Microsoft — Jegyzetelés a Microsoft Teams meetingjein; Microsoft — Élő feliratok használata a Microsoft Teams meetingjein; Zoom — A Meeting Summary használata az AI Companionnal; Google — Calendar- és Meet-beállítások a „Take notes for me" funkcióhoz; Google Meet — „Take notes for me" a Google Meetben; Google Meet — Fordított feliratok használata; Slack — Meeting agenda sablon (canvas). A Microsoft, a Google és a Slack meetingjegyzet- és sablonoldalai ellenőrizve 2026 októberében; a Zoom meeting-összefoglaló oldala, valamint a Teams és a Meet feliratoldalai ellenőrizve 2026 augusztusában. A gyártók idővel változtatják a csomagokat, funkciókat és nyelvlistákat; az aktuális állapotért ellenőrizze az oldalaikat.