V svoji karieri sem opravil precej prenove poslovnih procesov in največja težava, ki se mi zdi, je vedno enaka: poslovni procesi z odprto zanko. Procesi z odprto zanko se pojavljajo predvsem zato, ker je odgovornost razdeljena na več ljudi in pogosto na več oddelkov. Pretok informacij, ki se začne na področju raziskav in razvoja z zahtevo za nov kos opreme, lahko potuje skozi finance in nabavo, preden gre zunaj organizacijskih meja do prodajalca (kjer bo po vrsti odšel skozi več oddelkov), nato pa sčasoma nazaj v prejem in , z srečo skupina za raziskave in razvoj, ki je sprožila pretok.
Na vsakem koraku obstaja možnost, da je komunikacija motena in vodje projektov morajo ta tveganja ublažiti. Če pretoki informacij, vgrajeni v poslovni proces, niso izrecno strukturirani tako, da jih lahko ujamejo in nato obravnavajo kakršne koli izjeme, napako zaznamo šele kasneje ali morda sploh ne. Medtem ko nekatere napake pri pretoku informacij zgolj povzročijo, da sorazmerno nepomembni predmeti niso naročeni ali dostavljeni pravilno, lahko druge napake organizacije stanejo velike vsote denarja ali pa naložijo zamude pri kritičnih dejavnostih.
Za ponazoritev bom najprej govoril o veliki farmacevtski organizaciji, ki je plačevala davke na stotine milijonov dolarjev opreme, ki ji ni več mogla slediti, in je želela odstraniti te nepotrebne stroške. Naš projekt je odkril številne temeljne napake v postopku, vse skupaj pa je pomenilo več deset milijonov dolarjev nepotrebnih davkov na leto in še toliko več, da smo večkrat pomotoma naročili iste stvari.
Kot vse velike organizacije so bile odgovornosti v silosih. Nekdo v predelovalnih dejavnostih potrebuje opremo X, zato o tem obvesti Finance in ustvari se naročilnica. Naročanje pošlje naročilo prodajalcu. Do enega leta v prihodnosti X prejme in sprejme sprejemnik. Prejemanje obvesti proizvajalce in finance. Finance izdajo oznako sredstva, ki jo Prejemanje klofut na X. X postavijo v proizvodno linijo in vse je v redu.
Razen vse ni v redu. Za začetek zaposleni prihajajo in odhajajo in naročiti X je enostavno, ne da bi se zavedali, da je nekdo drug v isti vlogi naročil X pred devetimi meseci. Finance nimajo pojma, da je to naročilo dvojnik: domnevajo, da preprosto potrebujete še en X, zato se ustvari drugo naročilo in odda novo naročilo. Poleg tega, tudi če slučajno ne naročite preveč, hitro izgubite občutek, kaj imate.
Predpostavimo, da je X kompleksen del opreme, morda črta za polnjenje. Sestavljen je iz 20 glavnih sestavnih delov, ki bodo v življenjski dobi večkrat zamenjani. Oznaka sredstva, naključno udarjena na del X, bo zaradi obrabe izginila. Še huje pa je, da se oznaka sredstva morda niti ne uporabi, ker ne pride pravočasno do prejema. Po tem nihče več nima pojma, kako slediti Xu, in zato tudi pojma, kako ga razgraditi ob koncu življenjske dobe. Z davčnega vidika je X še vedno delujoča davčna postavka.
V 20+ letih bi to začelo škodovati bistvu na nepomemben način. Poleg tega Finance uporabljajo en del svojega ERP sistema z enim nizom označevalcev sredstev, medtem ko Manufacturing uporablja popolnoma ločen ERP modul z drugačnim naborom označevalcev sredstev. Konec leta nihče ne more uskladiti obeh številk, revizorji pa se sprašujejo, zakaj imate glede kapitalske opreme več deset ali sto milijonov dolarjev neskladja.
To so klasične težave, ki izhajajo iz nabora odprtih poslovnih procesov. Odprta zanka je, kadar vzdolž črte toka procesa ne vgradite eksplicitnih potrditvenih točk. V zgornjem primeru je bilo toliko procesov z odprto zanko, da je bila okvara zagotovljena.
Evo, kako smo se lotili težave. Modelirali smo vsak pomemben procesni proces od začetka do konca. Identificirali smo vse odprte zanke. Nato smo zasnovali preproste načine zapiranja teh zank, enega za drugim, od samega začetka.
Predelovalne dejavnosti potrebujejo X, zato prosijo Finance, da odprejo organizacijo proizvajalcev. Finance zdaj za preverjanje preveri pri Manufacturing, pri čemer navede podrobnosti o prejšnjih naročilih za X, ki se vračajo 24 mesecev nazaj. Nenamernemu podvajanju naročil se izognemo.
Proizvodnja zagotavlja financam razčlenitev komponent X, ki bodo zamenjane med življenjsko dobo. Finance ustvarijo oznake sredstev za vsako komponento in potrdijo s proizvodnjo. Oba ERP modula sta polna z ujemajočimi se oznakami sredstva na komponento, kar omogoča sledenje v celotnem življenjskem ciklu sredstva.
Prejemanje obvesti Finance, ta pa proizvodnjo. Namestitev oznak sredstev opravi odgovorna stranka v predelovalnih dejavnostih, da zagotovi, da je vsaka oznaka nameščena na pravilni komponenti. Vse oznake / komponente se nato ponovno potrdijo za dva modula ERP.
Vsakokrat, ko komponento zamenjate, Manufacturing obvesti Finance, pri čemer jo izdela in označi novo sredstvo za to komponento ter nato potrdi v obeh modulih ERP. Nato Finance začnejo postopek odstranjevanja stare komponente iz knjig, medtem ko proizvodnja poteka skozi postopek razgradnje Vodnika dobre prakse (GMP). Na koncu razgradnje Manufacturing o tem obvesti Finance, da se sredstvo lahko odstrani iz poslovnih knjig.
Podrobnosti so nekoliko bolj zapletene od tega poenostavljenega primera, vendar je bistvo jasno: na vsaki stopnji na cesti so izrecna preverjanja in potrditve.
V drugem projektu so me prosili, naj servisnemu podjetju pomagam izboljšati stopnjo zadovoljstva strank. Njihova dejavnost je bila le obdelava zahtevkov in zaskrbljeni so bili, ker niso uspeli pridobiti ponudb. Poleg tega je zaradi zmagovalnih ponudb zaradi nezadovoljstva strank njihov delež izgubljenih računov previsok.
Le nekaj dni je trajalo, da smo ugotovili bistvo problema, ki je bil spet odprt postopek. Ko je potencialna stranka zaprosila za ponudbo, bi upravitelj računa uporabil njihov notranji sistem, da bi osebi, odgovorni za sestavo ponudbe, poslal povzetek zahteve stranke. Ustvarjalec ponudbe bi nato ustvaril ponudbo in jo poslal stranki. Upajmo, da se bo stranka sčasoma odzvala, običajno z želenimi spremembami, ki jih je ustvarjalec ponudb vgradil v naslednjo različico. Na neki točki bi stranka sprejela ponudbo in z računovodstvom bi ustvarili nov račun stranke, dvignili račun in seznanili ekipo za vkrcanje.
Prva težava je bila v tem, da ustvarjalec ponudb ni izrecno potrdil upravitelja računa, zato včasih ponudbe niso bile ustvarjene in poslane pravočasno, za to pa ni nihče vedel. To je bilo mogoče, ker notranji sistem ni imel polja, ki bi prikazovalo rok zapadlosti ponudbe, in ker je bil ustvarjalec ponudb nenehno preobremenjen, je prišlo do prepoznega oddajanja ponudb. Zaradi slabega pretoka informacij v poslu se te situacije niso nikoli pojavile.
Po tem spremembe ponudbe niso bile posredovane upravitelju računa. To je bilo pomembno, ker je bil upravitelj računa tisti, ki je sestavil ekipo, ko se je stranka končno podpisala na pikčasto črto. Pogosto je osnutek temeljil na začetnem razumevanju upravitelja računa in ne na ponudbi, ki jo je stranka dejansko sprejela.
Ko se je zaroka začela, bodo prispeli dokumenti stranke in jih poslali tistemu članu skupine v predelovalnem področju, ki je bil v tem tednu dodeljen za njihovo obravnavo. Ker ni bilo izrecne potrditve prejema, so lahko dokumenti izginili, ne da bi se kdo zavedal tega, dokler se stranka ni začela spraševati, zakaj ne prejema rezultatov obdelave.
Ko so bili obdelani dokumenti poslani stranki, potrditve ob prejemu ni bilo, zato so bili izgubljeni dokumenti izgubljeni, dokler se nekdo ni začel pritoževati nad njihovo odsotnostjo.
V vsakem koraku postopka zbiranja ponudb smo vgradili izrecne potrditve. Ustvarili smo rešitve za sistemske pomanjkljivosti, tako da so bile zajete vse ključne informacije, vključno z datumom, ki ga zahtevajo nadaljnje spremembe ponudb. Izvedli smo eksplicitne preglede in potrditve za ves pretok informacij v poslovanju znotraj podjetja ter med podjetjem in stranko.
Na primer, ko je stranka poslala paket dokumentov, bo zdaj upravitelju računa odjemalca poslala e-poštno sporočilo, da jim bo to sporočila. Upravitelj računa stranke bi to posredoval odgovorni stranki pri obdelavi zahtevkov. Če dokumentov ne bi prejeli v treh dneh, bi sprožili opozorilo. Ko so bili dokumenti prejeti, je stranka prejela e-poštno sporočilo s potrditvijo prejema. Tudi obratno je veljalo, ko je podjetje naročniku poslalo obdelane dokumente.
Ker je večina strank uporabljala ameriško pošto za premeščanje papirnatih kopij dokumentov naprej in nazaj, so postopki zaprtega kroga z izrecnim preverjanjem na vsakem koraku pomenili, da je mogoče hitro prepoznati izgubljene dokumente in sprejeti ukrepe za odpravo situacije.
Da bi ugotovili, kako je mogoče postopke za obravnavo izjem izdelovati na razmeroma lahek, a učinkovit način, si bomo ogledali še en resničen primer, s katerim sem se srečal v svoji karieri, ko sem bil direktor tehnične službe v znanstvenoraziskovalni organizaciji, ki se je osredotočala na preiskovanje vzrokov staranje in sprožilci starostnih bolezni.
Vse Financira NIH raziskovalni inštituti vsebujejo veliko posameznih laboratorijev, od katerih vsak vodi glavni preiskovalec (PI), v njem pa sodelujejo različni podrejeni znanstveniki in post-doktorji. Na neki točki potrebuje PI nov večkomorni pladenj za reagente, zato od enega od post-dokumentov zahtevajo, da ustvari potrebno zahtevo. Post-doc ustvari zahtevo in jo po elektronski pošti pošlje Finance, da zahteva dvig naročilnice, pri čemer pošlje PI, da se prepriča, da je bila zahteva poslana. Medtem ima PI samodejno koledarsko obvestilo, ki ga opozori, naj preveri stanje zahteve, če do določenega datuma ni prejel potrditve. To zagotavlja mehanizem za varno delovanje, če post-doc pozabi ustvariti ali poslati potrebno zahtevo.
Zdaj ima post-doc tudi samodejno koledarsko obvestilo, da se prijavi pri financah, če v določenem roku ne prejme potrditve dviga naročila. Ko Finance povišajo naročilo, post-doc po e-pošti prejme potrditev, da je bilo poslano prodajalcu, post-doc pa to potrditev posreduje PI.
Na tej stopnji bodisi PI bodisi post-doc nastavi drugo samodejno koledarsko obvestilo, da zagotovi, da če prodajalec v določenem roku nič ne sliši, se nekdo pri prodajalcu preveri, ali je prejel naročilo in poslal pošiljko. oprema, ki je bila naročena.
Ob predpostavki, da prodajalec potrdi prejem naročila in pošlje artikel skupaj z obvestilom o odpremi, se ta preusmeri na PI ali post-dok. Nato določijo končno koledarsko obvestilo za tri dni po predvidenem datumu prejema, da bi zagotovili, da če se artikel ne prikaže, vedo, da se obrnejo na prodajalca, da bi izsledili, kaj se je zgodilo, in da je bil artikel pravilno dostavljen. Če element prispe po načrtih, post-doc obvesti Finance in če organizacija uporablja oznake sredstev, potem lahko začnete ta niz postopkov.
Na vsakem koraku je potrebna izrecna potrditev in na voljo je podproces, ki zagotavlja, da pride do sanacijskih ukrepov, če je glavni tok procesa prekinjen. Nič ni ostalo visečega, nepotrjenega ali nepodprtega. Začasna dejanja niso potrebna, ker vsi vedo, kaj je potrebno in kaj storiti, če gre kaj narobe.
Bistvo dobrega postopka je zelo podobno načinu, kako so bile relacijske zbirke podatkov, ki temeljijo na SQL, zasnovane tako, da zagotavljajo doslednost transakcij. Vsako dejanje je treba potrditi, da se lahko šteje za zaključeno. Vse dvosmerne komunikacije potrebujejo izrecno potrditev, ki je vgrajena kot del procesa, in podrejeni procesi, razviti, da se zagotovi, da če potrditev ni prejeta, se izvedejo pravilni ukrepi. Uspešni vodje projektov bi morali ustvariti zaprte procese za izboljšanje pretoka informacij v podjetju in prihraniti organizacijam veliko časa in denarja.
Primer postopka z odprto zanko je izpolnjena zahteva brez potrditve ustreznim zainteresiranim stranem. Če zadevne stranke niso obveščene o izpolnjeni zahtevi, to ustvarja možnosti za napačno komunikacijo.
Postopek z zaprto zanko je tak, da se izvedejo vsi ukrepi, ki jih postopek zahteva, in se vse zainteresirane strani ob ustreznem času obvestijo o zaključku teh ukrepov.
Pretok informacij v organizaciji je vsa komunikacija med oddelki, zaposlenimi in sistemi, ki je potrebna za pravilno delovanje podjetja.
Informacije se pretakajo od vira do sprejemnika ali cilja prek neke oblike medija, kot so izgovorjena beseda, e-pošta, sporočilo IM itd.
Analiza pretoka informacij je postopek analiziranja pretoka informacij znotraj danega sistema. Ta analiza lahko pomaga izboljšati pretok informacij v poslu.