Coraz czę­ściej spo­ty­kam się z pyta­nia­mi na temat mode­lo­wa­nia pro­ce­sów biz­ne­so­wych w kon­tek­ście ich opty­ma­li­za­cji. Pojawiają się tak­że przy tej oka­zji, pyta­nie o symu­la­cje. Widuje wie­le lep­szych i gor­szych pomy­słów. Moim zda­niem, po pierw­sze nale­ży sobie odpo­wie­dzieć na pyta­nie co w danym momen­cie opty­ma­li­zu­je­my: wewnętrz­ną stra­te­gię fir­my czy wydaj­ność (efek­tyw­ność) w okre­ślo­nej sytuacji.

Optymalizacja ma dwa pozio­my: poziom ​„co i po co robi­my” oraz poziom ​„jak to robi­my”. Ten dru­gi jest ​„poni­żej” pierw­sze­go, to bar­dziej szcze­gó­ło­we uję­cie mode­lu. Najpierw nale­ży jed­nak opty­ma­li­zo­wać celo­wość prac, w szcze­gól­no­ści to, czy każ­dy etap cze­muś słu­ży. Na tym pozio­mie opty­ma­li­zu­je­my pro­ce­sy biz­ne­so­we a nie ich efek­tyw­ność. Tu ​„wal­czy­my” z ich logi­ką. Tu mamy pro­ce­sy biz­ne­so­we jako ​„coś co two­rzy pro­dukt”. Po upew­nie­niu się, że logi­ka tych pro­ce­sów, słusz­nie nazy­wa­na ​„wewnętrz­nym łań­cu­chem war­to­ści doda­nej”, jest popraw­na, ana­li­zu­je­my poszcze­gól­ne pra­ce (zada­nia, czyn­no­ści) i zasta­na­wia­my się czy ich efek­tyw­ność jest naj­lep­sza jaką może­my osiągnąć.

Etap pro­ce­sów mode­lu­je­my, że tak powiem, kla­sycz­nie. Te mode­le opi­su­je tu bar­dzo czę­sto. Problem zaczy­na się przy mode­lo­wa­niu szcze­gó­łów czynności.

Swego cza­su zafun­do­wa­łem sobie szko­le­nie z zakre­su „[[Lean Management]]”. Były to dwu­dnio­we warsz­ta­ty z obsza­ru opty­ma­li­za­cji pra­cy, głów­nie tak zwa­nej ​„biu­ro­wej”. Lean to obszar ​„jak to robi­my”. Tu prze­ko­na­łem się, że każ­dy pro­blem nale­ży trak­to­wać indy­wi­du­al­nie. Jednym jed­nak z klu­czo­wych pro­ble­mów jakie napo­tka­li­śmy było udo­ku­men­to­wa­nie ​„sta­nu rze­czy”. Okazało się, że gdy pra­ca wre, czę­sto nie jest to ​„pro­ces” a dyna­micz­nie zmie­nia­ją­ce się śro­do­wi­sko. Nie raz moż­na użyć pro­ce­du­ry na opi­sa­nie tego co kto robi, jed­nak nie zawsze jest to moż­li­we: czę­sto sil­nie obcią­żo­ne ​„eta­py pra­cy”, to co jest czyn­no­ścią na mapie pro­ce­su, to mały zespół z jego kie­row­ni­kiem, rolą kie­row­ni­ka jest sta­ła opty­ma­li­za­cja obcią­że­nia tego zespo­łu. Próby zapi­sa­nia tego jako mapy pro­ce­su idą w kie­run­ku algo­ryt­mi­za­cji tych prac i to jest nie­ste­ty bar­dzo czę­sto śle­pa ulicz­ka: powsta­ją mon­stru­al­ne, nigdy nie ukoń­czo­ne, dia­gra­my, bo zawsze jest ​„jesz­cze jeden wariant sce­na­riu­sza”. Co robić? Tu nale­ży wybrać ​„wła­ści­wy spo­sób” doku­men­to­wa­nia dla każ­de­go indy­wi­du­al­ne­go przy­pad­ku. W zasa­dzie mamy trzy możliwości:

1. pro­ce­du­ra (sce­na­riusz)
2. regu­ły biz­ne­so­we i decyzyjne
3. mapa sytu­acyj­na (np. plan pomiesz­cze­nia i biurek)

Pierwsza meto­da to ​„algo­ryt­mi­za­cja” pra­cy, opra­co­wu­je­my naj­lep­szy sce­na­riusz wyko­na­nia zada­nia i czy­ni­my go jedy­nym dopusz­czal­nym. Jedna pro­ce­du­ra powin­na opi­sy­wać pra­cę jed­nej oso­by (ato­mo­wa czynność/zadanie), spo­sób opi­su to może być dia­gram ale lepiej jest użyć punk­to­wa­nej listy, gdyż taka pro­ce­du­ra musi być czy­tel­na i przy­stęp­na dla tej oso­by. Tu idzie­my w kie­run­ku taśmy pro­duk­cyj­nej, pra­ca taka musi być w 100% przewidywalna.

Druga meto­da to spo­sób na roz­wią­za­nie pro­ble­mu efek­tyw­no­ści tam, gdzie warun­ki pra­cy się zmie­nia­ją zależ­nie od pory dnia, roku, sezo­nu, koniunk­tu­ry. W tym przy­pad­ku mamy np. mały zespół i jego kie­row­ni­ka. Rolą kie­row­ni­ka jest podej­mo­wa­nie decy­zji o obcią­że­niu pra­cą człon­ków zespo­łu i nad­zo­ro­wa­niu prze­strze­ga­nia reguł biz­ne­so­wych. W sytu­acjach nie obję­tych regu­ła­mi, kie­row­nik podej­mu­je sam decy­zje lub eska­lu­je pro­blem do prze­ło­żo­ne­go (zależ­nie od posia­da­nych upraw­nień co tak­że nale­ży udokumentować).

Trzecia meto­da to meto­da pole­ga­ją­ca na deta­licz­nym opi­sa­niu pra­cy w okre­ślo­nej prze­strze­ni np. usta­lo­na tra­sa poru­sza­nia się wóz­ków widło­wych po maga­zy­nie albo miej­sca przy biur­kach zaj­mo­wa­ne przez pra­cow­ni­ków dzia­łu księ­go­wo­ści opty­ma­li­zu­ją­ce prze­ka­zy­wa­nie doku­men­tów mie­dzy sobą. Tu nie zawsze roz­wią­za­niem pro­ble­mu jest elek­tro­nicz­ny obieg doku­men­tów, bo w wie­lu przy­pad­kach nie da się wyeli­mi­no­wać (takie pró­by bywa­ją nawet cza­sem zabój­cze dla wydaj­no­ści) uży­cia papie­ro­wych doku­men­tów (nie tyl­ko sądy tak pra­cu­ją). Ta meto­da jest jed­nak opcjo­nal­nym uzu­peł­nie­niem dwóch poprzednich.

Popatrzmy na frag­ment pew­ne­go arty­ku­łu o Lean:

Mapa pro­ce­su

Jest to już dość skom­pli­ko­wa­ny doku­ment, któ­ry bazu­je na wie­lu danych wej­ścio­wych, któ­re nale­ży zebrać.Generalnie meto­da two­rze­nia mapy pro­ce­su jest następująca:

1) Określamy pro­ce­sy, któ­re będzie­my chcie­li zop­ty­ma­li­zo­wać (naj­le­piej okre­ślić poszcze­gól­ne sta­no­wi­ska pra­cy, np. cen­trum obrób­cze nr 1, 2, itd., sta­no­wi­sko mon­ta­żo­we nr A1, A2, B1, B2, itd., sta­no­wi­sko napraw­cze, spa­war­ka nr 1, 2…)

2) Określamy pro­duk­ty, któ­re są wyko­ny­wa­ne na poszcze­gól­nych stanowiskach.

3) Zbieramy dane o dostęp­no­ści stanowisk/urządzeń w okre­ślo­nym okre­sie cza­su (np. zmiana/doba).

4) Określamy czas stan­dar­do­wy, w jakim jest wytwa­rza­ny dany pro­dukt na danym sta­no­wi­sku, w roz­bi­ciu na setup (prze­zbro­je­nie) i czas wyko­na­nia 1 sztu­ki pro­duk­tu. Przezbrojenie też war­to roz­bić na część wyko­ny­wa­ną w cza­sie masko­wa­nym (gdy maszy­na wyko­nu­je detal, może­my przy­go­to­wy­wać jakiś etap prze­zbro­je­nia) i cza­sie zatrzy­ma­nia maszy­ny (na przy­kład wymia­na narzę­dzi w maga­zyn­ku obra­biar­ki). Czas wyko­na­nia 1 sztu­ki też war­to roz­bić na czas pra­cy maszy­ny i czas pra­cy czło­wie­ka (na przy­kład każ­dą część nale­ży ogra­do­wać po zdję­ciu z maszyny).

5) Określamy jaką część naszych pro­duk­tów będzie­my musie­li napra­wiać (pro­cen­to­wo).

Są to dane wej­ścio­we, któ­re nale­ży jesz­cze obro­bić. Robimy to przy pomo­cy matry­cy wyko­na­nej na przy­kład w MS Excellu.

(WCM, Lean Manufacturing, TPM, IFM… ale o co cho­dzi?: Mapa procesu).

Bardzo dobry przy­kład pro­ble­mu. Mamy tu co praw­da pomie­sza­nie pojęć pro­ces i zada­nie (nie­ste­ty bar­dzo powszech­ne) oraz pro­dukt i faza, ale widać pro­blem. Pierwsze co nale­ży zro­bić, to podzie­lić ele­men­tar­ny ato­mo­wy pro­ces na ato­mo­we, nie­po­dziel­ne zada­nia (czyn­no­ści). Upewnić się, że w danym momen­cie (jeden model) ope­ru­je­my poje­dyn­czym pro­ce­sem a nie ich zlep­kiem – co jest wręcz klu­czem powo­dze­nia takiej ana­li­zy. Niestety tu waśnie widać błąd w powyż­szym opi­sie: sta­no­wi­sko pra­cy nie zawsze jest pro­ce­sem, raczej jest poje­dyn­czym zda­niem. Pamiętajmy, że pro­ces two­rzy pro­dukt. Stanowisko, na któ­rym ktoś wyko­nu­je tyl­ko dwa otwo­ry wier­tar­ką to zada­nie a nie pro­ces. Procesem jest np. kom­plet­ne zmon­to­wa­nie obu­do­wy cze­goś tam.

Co robić? Po pierw­sze oddzie­lić ​„gru­bą kre­ską” pro­ce­sy od zadań. Proces to jed­no zada­nie lub seria zadań (czyn­no­ści). Model takie­go pro­ce­su poka­zu­je kolej­ność tych zadań, ewen­tu­al­ne warian­ty tej kolej­no­ści. Jeżeli ma to być ​„mapa”, pro­ces musi być deter­mi­ni­stycz­ny (prze­wi­dy­wal­ny w 100%). Jeżeli tyl­ko oka­że się, że licz­ba warian­tów zaczy­na nam w toku ana­liz rosnąć, jest to sygnał, że nale­ży zre­zy­gno­wać z pisa­nia pro­ce­du­ry i przejść na meto­dę ​„zespół z kie­row­ni­kiem”. Taki nie­po­dziel­ny zespół jest repre­zen­to­wa­ny na mode­lu pro­ce­sów jako rola w oso­bie kie­row­ni­ka tego zespo­łu (lub jako nazwa tego zespo­łu). Dokumentacja ​„wnę­trza” spro­wa­dza się do listy reguł biz­ne­so­wych oraz okre­śle­nia liczeb­no­ści zespołu.

Optymalizacja pro­ce­du­ry może być pro­wa­dzo­na ​„na sucho” z pomo­cą symu­la­cji. Tu suge­ru­je jed­nak zamiast exce­la, użyć pro­gra­mu pozwa­la­ją­ce­go stwo­rzyć model sce­na­riu­sza i przy­pi­sać do każ­dej czyn­no­ści czas trwa­nia, zaso­by i licz­bę instan­cji (czy­li np. rów­no­cze­snych wyko­naw­ców). Optymalizacja pra­cy ​„zespo­łu” to jed­nak bie­żą­ce ​„pla­no­wa­nie, obser­wa­cja i kory­go­wa­nie”. To rola kie­row­ni­ka. Tu, jako meto­dy doku­men­ta­cji, są w uży­ciu listy reguł i pla­ny sytuacyjne.

Kilka lat temu opra­co­wy­wa­łem dla PWPW opty­ma­li­za­cję pro­ce­su obsłu­gi wnio­sków o kar­ty do elek­tro­nicz­nych tacho­gra­fów i wyda­wa­nie kart kie­row­ców do nich. Tu model pro­ce­su (BPMN) opi­sy­wał tyl­ko wyma­ga­ne usta­wą i regu­la­mi­nem eta­py (np. czyn­ność przy­po­rząd­ko­wa­nia wpła­ty do wnio­sku). To jak naj­szyb­ciej wpro­wa­dzać wnio­ski do opro­gra­mo­wa­nia zarzą­dza­ją­ce­go nimi, jak przy­po­rząd­ko­wać wpła­ty, w tym te nie­zi­den­ty­fi­ko­wa­ne, czy jak zor­ga­ni­zo­wać przy­ję­cie ster­ty papie­ro­wych wnio­sków z pocz­ty, to były szki­ce sytu­acyj­ne, roz­miesz­cze­nie mebli, zespo­ły zada­nio­we i ich kie­row­ni­cy (zmien­ne ilo­ścio­wo, stu­den­ci przyj­mo­wa­ni ad-hoc na uowe zle­ce­nie). Całość spi­nał model tego pro­ce­su ale poszcze­gól­ne czyn­no­ści były mode­lo­wa­ne (doku­men­to­wa­ne) róż­ny­mi meto­da­mi zależ­nie od tego ​„na czym pole­gał problem”.

W przy­pad­ku pro­ble­mu z iden­ty­fi­ko­wa­niem pro­ce­sów i zadań, gorą­co ogra­dzam podej­ście opi­sa­ne poniżej:

Umiejętność dekom­po­no­wa­nia zadań uwa­żam za klu­czo­wą jeśli cho­dzi o zarzą­dza­nie cza­sem. W róż­nych momen­tach pro­wa­dze­nia szko­le­nia z tego tema­tu, sta­ra­łem się for­mu­ło­wać mniej lub bar­dziej zja­dli­we pro­ce­du­ry do prze­pro­wa­dza­nia owej dekom­po­zy­cji. W koń­cu mnie oświe­ci­ło i wpa­dłem na tę, jak sądzę, naj­prost­szą, ele­ganc­ką i skuteczną:)

Definiuj zada­nia mak­sy­mal­nie czte­ro­go­dzin­ne (źr. Touching the Void: Dekomponowanie zadań).

Jest to moim zda­niem jed­na z naj­gor­szych metod, gdyż zakła­da nie­ist­nie­nie zadań mogą­cych trwać dłu­żej, w efek­cie pro­wa­dzi to sztucz­ne­go, niczym nie­uza­sad­nio­ne­go podzia­łu – wpro­wa­dza­nia sztucz­nych eta­pów pra­cy. Podobnie błęd­ne podej­ście to dzie­le­nie zadań zawsze gdy pro­ce­du­ra prze­kro­czy okre­ślo­ną licz­bę kro­ków albo dzie­le­nia ​„skom­pli­ko­wa­nych przy­pad­ków uży­cia” na mniej­sze tyl­ko dla­te­go, że sce­na­riusz prze­kro­czył dopusz­czal­na licz­bę kro­ków. Tak pro­ces biz­ne­so­wy jak i przy­pa­dek uży­cia, są defi­nio­wa­ne w swo­ich gra­ni­cach zda­rze­niem na wej­ściu i fak­tem wytwo­rze­nia pro­duk­tu, dzie­le­nie ich na ​„kawał­ki” to fał­szo­wa­nie, wpro­wa­dza­nie sztucz­nej, nie­ist­nie­ją­cej złożoności.