SIPOC

SIPOC je nástroj pro hrubý náhled (high level) na proces, tj. používáme ho před detailnějším mapováním procesu. Jedná se o akronym z anglických slov (Suppliers, Inputs, Process, Outputs, Customers). Pomáhá nám ujasnit si, o jakém procesu (nebo jeho části) mluvíme, kde začíná a kde končí, co je vstupem a co výstupem a co se na něm zhruba vlastně děje (což popisujeme v první fázi cca 5-7 kroky). Pozor, mluvíme o procesu, tj. o opakované výrobě stejného výrobku nebo opakované dodávce stejné služby.

Příklady procesů:

  • Přeměna nazaplacené faktury na zaplacenou fakturu/peníze na účtě dodavatele
  • Přeměna požadavku na nákup na dodání zboží
  • Příjmu jednoho pacienta se zdravotním problémem na pacienta po operačním zákroku
  • Přeměna jedné stížnosti na vyřízení reklamace
  • Přeměna obchodní nabídky na její realizaci
  • Přeměna surovin na jeden polotovar/finální výrobek
  • atd

Dodavatelé (S = Suppliers) jsou ti, kteří do konkrétního kroku dodávají vstupy ( =Inputs), zákazníci (C = Customers), jsou ti, kterým se z konkrétního kroku dodávají výstupy (O=Outputs).

Můžeme se s ním setkat pod různými názvy:

  • SIPOC diagram
  • SIPOC tabulka
  • SIPOC analýza
  • SIPOC mapa

My na optimalizačních projektech používáme SIPOC relativně často. Kromě hrubého pohledu na proces jím  totiž také ohraničujeme oblast mandátu project managera pro zlepšování, kterou potřebujeme definovat v Project Charteru (Pověřovací mandát) ve fázi DEFINE. Zrovna tak tím bráníme nikdy nekončícím projektům, kde se má ještě optimalizovat něco dalšího. SIPOCem dáváme jasně najevo, kde v procesu začínáme a kde končíme.

SIPOC se dá dělat mnoha způsoby. My pro mandát oblasti zlepšování používáme nejčastěji dva z nich a neobejdeme se bez brainstormingu s lidmi, kteří na tomto procesu pracují.  Zjednodušený je SIPOC ve formě písmene Z, do kterého dáváme minimální možné množství informací, které stačí pro pochopení procesu. Pro jeho sestavení sledujeme základní větev = zlatou cestu, ignorujeme větve alternativní a chybové (těm se věnujeme, až při detailním mapování  procesu).

Někdy se jedná o jednoduchý proces, pro který je celkem snadné SIPOC sestavit. Např. tento ukázkový proces (lépe řečeno jeho část) se týká prvního příkladu (viz. výše), a to jednoho zaplacení jedné faktury. 

Pro podnikatele je zaplacení faktury několikaminutová záležitost, kterou provede často on sám. 

V případě „bílých továren“ = center sdílených služeb, které spravují platby svých zákazníků v několika tisícovém počtu denně/týdně/měsíčně, se jedná o přesně stanovený proces plný ověřování a schvalování a na zaplacení jediné faktury se podílí několik lidí.

Při sestavování SIPOCu postupujeme v tomto pořadí : O, C P, I, S:

  1. Co je výstupem z procesu? Zaplacená faktura (reprezentuje peníze zaslané na účet)
  2. Pro koho je určená, kdo je „zákazníkem“? Dodavatel , kterému jsme ji proplatili
  3.  Co je potřeba udělat k tomu, aby byla faktura zaplacená? Zaplatit fakturu.
  4. A co tomu předchází: Zaúčtovat fakturu, spustit workflow, schválit správnost faktury, potvrdit dodávku zboží a  odblokovat fakturu.
  5. Co spouští první krok, tj. zaúčtování faktury? Ověřená faktura.
  6. Od koho přijde ověřená faktura? Od verfikačního týmu, který zkontroloval, že byl obrázek faktury v PDF formátu správně převeden na ASCII znaky (čísla a písmena).

K jeho vytvoření je třeba cca 30 – 45 minut a používáme k tomu post-ity.

U služeb může být sestavení SIPOCu složitější než u výroby. Procesem totiž prochází často něco nehmatatelného, co se postupně přeměňuje. Co je vstupem? Požadavek na zaplacení faktury nebo nezaplacená faktura nebo něco jiného? A co je výstupem? Příkaz k úhradě faktury nebo zaplacená faktura nebo opět něco jiného? My jsme se rozhodli sledovat proces od nezaplacené (ověřené) faktury po zaplacenou fakturu.

Tímto jsme si jasně oddělili, že se chceme ve firmě věnovat části procesu, který začíná již ověřenou fakturou, tj. nezajímá nás, co se děje před tím, než do k týmu ABC dorazí od Verifikačního týmu faktura, a zrovna tak končíme tím, že se dá pokyn na zaplacení faktury. Co se děje v procesu dál, nesledujeme.  Jsme totiž přesvědčeni, že problém, který řešíme, nastává právě v této části procesu.

Někdy je proces natolik jednoduchý, že si s takto jednoduchým SIPOCem pro mapování vystačíme. Většinou ale používáme složitější SIPOC, u kterého doplňujeme i kolonku R (Responsible = ten, kdo krok provádí), na základě které víme, koho potřebujeme mít v našem projektovém týmu a od koho se dozvíme bližší informace, jak to na procesu funguje.

Pozn. Business konzultanti, jejichž běžnou prací je modelování procesů podle notace BPMN (Business Process Modeling Notation), používají místo písmena „R“  často písmeno „A“ (Actor = Aktér). My dáváme přednost písmenu „R“, aby se nám nepletlo při definování zodpovědností s pojmem „Accountable“. Pojmy většinou kvůli pohodlnosti necháváme v anglickém jazyce, „Responsible“ je ten, kdo práci vykonává (většinou operátor), „Accountable“ je ten, kdo je zodpovědný, že byla práce vykonána (většinou manažer).

V tomto SIPOCu máme hrubě popsaný tentýž proces (viz výše), pouze podrobněji. 

Při sestavování  tohoto SIPOCu postupujeme podobně, pouze doplňujeme další informace:

  1. Co je výstupem z procesu? Zaplacená faktura (reprezentuje peníze zaslané na účet).
  2. Pro koho je určená, kdo je „zákazníkem“? Dodavatel, kterému jsme ji proplatili
  3.  Co je potřeba udělat k tomu, aby byla faktura zaplacená? Zaplatit fakturu.
  4. Kdo má na starosti krok „Zaplatit fakturu“? Tým PB. Poznámka: Už víme, že až budeme mapovat proces do detailu, budeme potřebovat člena týmu PB, který zná do detailu postup při kroku „Zaplatit fakturu“.
  5. Co se děje před krokem „Zaplatit fakturu“? Je potřeba odblokovat fakturu.
  6. Kdo to má na starosti? To udělá automaticky systém SAP.
  7. Na základě čeho to udělá SAP? Co je vstupem k tomu kroku? Spárovaná faktura s objednávkou.
  8. atd.

Pomocí našeho SIPOCu jsme jasně určili hranice našeho zlepšovacího projektu. Řešíme problém na procesu, který začíná příjmem ověřené faktury a končí zaplacenou fakturou. 

Nepředpokládáme totiž, že by byl problém způsobený někde jinde (u verifikačního týmu, u dodavatele, atd.).

Někdy se na projektech stává, že v průběhu projektu musíme SIPOC rozšířit, protože zjistíme kořenovou příčinu problému na předcházejících krocích procesu (v našem případě např. u Verifikačního týmu).

V některých případech je proces velmi složitý a je pro nás ve spolupráci s projektovým týmem těžké ujasnit si, co všechno do procesu vstupuje a co všechno z procesu vystupuje. Ve většině případů k tomu dochází, když řešíme problém na úrovni velké části nebo celé firmy a hledáme úzké místo.

V takovém případě začínáme se SIPOCem, který má trošku podobou myšlenkové mapy, a teprve poté se snažíme postupně vyrobit nějaký systém. Princip si ale ukážeme (pro snazší pochopení) opět na stejném příkladě:

SIPOC potřebujeme i při návrhu nového procesu (viz DFSS). Např. v případě návrhu procesu pro výrobu může mít takovouto podobu: