Bardzo czę­sto spo­ty­kam się z pro­jek­ta­mi ini­cjo­wa­ny­mi przez śred­nie kadry kie­row­ni­cze dużych firm i urzę­dów, czę­sto mają one pew­ną wspól­ną cechę: ​„nie może­my nic zmie­niać w stra­te­gii orga­ni­za­cji ale chce­my uspraw­nić pra­cę w naszym wydzia­le”. To z regu­ły bar­dzo cen­na ini­cja­ty­wa ale tak­że dobra dro­ga do poraż­ki pro­jek­tu. W urzę­dach czę­sto na gra­ni­cy łama­nia pra­wa… a nie raz z jego łama­niem. 

Projekty w admi­ni­stra­cji publicz­nej mają dodat­ko­wą spe­cy­fi­kę: zasa­dy usta­la pra­wo­daw­ca a nie mene­dżer orga­ni­za­cji. Bardzo dobrze opi­sał to zja­wi­sko prof. Bolesław Szafrański wska­zu­jąc przy­czy­nę wie­lu pora­żek wdro­żeń w admi­ni­stra­cji. Opisał trzy-eta­po­wy refe­ren­cyj­ny (i zale­ca­ny) pro­ces wdra­ża­nia nowych roz­wią­zań, a na jego tle, w swo­im opra­co­wa­niu, wska­zał dostrze­żo­ne zanie­dba­nia administracji:

Cytuję to opra­co­wa­nie, bo model ten jest bar­dzo podob­ny do ogól­nej trój­war­stwo­wej kon­cep­cji orga­ni­za­cji. Prof Szafrański zwra­ca uwa­gę na to (z czym się zga­dzam), że kolej­ność podej­mo­wa­nia decy­zji i dzia­łań, powin­na być nastę­pu­ją­ca: opra­co­wa­nie nowej lub zmie­nio­nej stra­te­gii (Dokument stra­te­gicz­ny), opra­co­wa­nie tak­ty­ki dzia­ła­nia (Model ope­ra­cyj­ny dzia­ła­nia) oraz opra­co­wa­nie pla­nu wdro­że­nia IT (Fundament dzia­łal­no­ści, w kon­tek­ście Architektury Korporacyjnej). Oczywiście nic nie stoi na prze­szko­dzie, by ini­cja­ty­wa wyszła ​„od dołu”.

W swo­im opra­co­wa­niu prof. Szafrański wska­zu­je, że wdro­że­nie nowej stra­te­gii wyma­ga spraw­dze­nia i ewen­tu­al­ne­go opra­co­wa­nia nowych mecha­ni­zmów, pro­ce­dur, pra­wa, pozwa­la­ją­ce­go nie tyl­ko wdro­żyć nową stra­te­gię ale tak­że sku­tecz­nie ją ​„wymu­sić”.

Jeżeli powyż­szy model uogól­nić do posta­ci obra­zu­ją­cej zwią­zek pomię­dzy: stra­te­gią ryn­ko­wą orga­ni­za­cji, wewnętrz­ną tak­ty­ką reali­za­cji misji oraz tym jak zosta­ły one zaim­ple­men­to­wa­ne, to powsta­nie taki oto dia­gram (po pra­wej zna­ne od lat opra­co­wa­nie Business Process Trends):

Jeżeli pomiąć for­mę praw­ną, każ­da orga­ni­za­cja ma stra­te­gię i każ­da jakoś ją reali­zu­je (imple­men­tu­je: ma pra­cow­ni­ków a Ci umie­jęt­no­ści i zakre­sy obo­wiąz­ków). Mało któ­ra orga­ni­za­cja ma tak zwa­ny ​„model ope­ra­cyj­ny”, czy­li to co łączy stra­te­gię i ludzi z ich obo­wiąz­ka­mi i uzy­ski­wa­ny­mi efek­ta­mi pra­cy. Czym jest taki model? To model pro­ce­sów biz­ne­so­wych: środ­ko­wa ​„war­stwa” powyż­sze­go dia­gra­mu po prawej.

Rozwijające się ewo­lu­cyj­nie orga­ni­za­cje zawsze doku­men­tu­ją deta­le prac (infor­ma­cje w pro­ce­du­rach zarzą­dza­nia jako­ścią i tak zwa­nych doku­men­tach kadro­wych), czę­sto doku­men­tu­ją to, jaką rolą peł­ni orga­ni­za­cja w swo­im oto­cze­niu (misja, wizja, stra­te­gie itp.) i bar­dzo rzad­ko doku­men­tu­ją wewnętrz­ny łań­cuch war­to­ści czy­li pro­ce­sy biz­ne­so­we oraz, no naj­waż­niej­sze, logi­ka tego jak ​„to wszyst­ko dzia­ła” w środ­ku (i czy dzia­ła z sen­sem). Wadą więk­szo­ści tego typu pro­jek­tów, jakie obser­wu­ję, jest sku­pia­nie się na deta­lach i pomi­ja­nie pryn­cy­piów. W efek­cie pro­jekt pochła­nia wie­le pra­cy i nadal nie mamy zro­zu­mie­nia cało­ści (w lit. ang. ​„big pic­tu­re”), osią­ga­ne efek­ty są losowe. 

Pokażę na dość pro­stym przy­kła­dzie o czym mowa (pole­cam ww. opra­co­wa­nie prof. Szafrańskiego, opi­sał w nim błę­dy popeł­nio­ne w przy­pad­ku infor­ma­ty­za­cji Państwa). 

Poniższy dia­gram to uprosz­czo­ny model orga­ni­za­cji z zain­sta­lo­wa­nym sys­te­mem EOD (Elektroniczny Obieg Dokumentów) oraz zacho­wa­nym, nadal wyko­rzy­sty­wa­nym ​„po sta­re­mu” opro­gra­mo­wa­niem pocz­ty elektronicznej. 

Linie cią­głe to dro­ga jaką poko­nu­ją doku­men­ty z uży­ciem EOD. Linie prze­ry­wa­ne to pocz­ta elek­tro­nicz­na. Jeżeli zosta­nie w jakiejś orga­ni­za­cji zain­sta­lo­wa­ny EOD (celo­wo nie uży­wam sło­wa ​„wdro­żo­ny”) i nie zosta­nie z niej usu­nię­ty ema­il jako narzę­dzie alter­na­tyw­nej wewnętrz­nej komu­ni­ka­cji, to użyt­kow­nik będzie sam decy­do­wał, o tym któ­rym kana­łem prze­ka­że daną treść. W efek­cie EOD, któ­ry miał ​„mieć wszyst­ko” nie ma wszyst­kie­go, dane w EOD są nie­wia­ry­god­ne i nie­kom­plet­ne. Jeżeli jest to urząd, to metry­ka spra­wy w zasa­dzie nie ma sen­su, celem jej two­rze­nia była moż­li­wość odtwo­rze­nia peł­ne­go prze­bie­gu spra­wy, a tu urzęd­nik sam decy­du­je, któ­re infor­ma­cje i doku­men­ty prze­ka­zu­je kana­łem for­mal­nym (EOD), a któ­re ​„na boku”. Czy wszyst­ko musi być w EOD? Tak. Jeżeli nie jest, EOD jest tyl­ko uzna­nio­wym archi­wum dokumentów. 

Aby sku­tecz­nie wdro­żyć EOD nale­ży naj­pierw opra­co­wać nowy model ope­ra­cyj­ny dzia­ła­nia orga­ni­za­cji, model uwzględ­nia­ją­cy nowe narzę­dzie pra­cy, model któ­ry w spo­sób sys­te­mo­wy wyeli­mi­nu­je nie­po­żą­da­ne ele­men­ty ​„złe­go sta­re­go sys­te­mu”. Dla przy­kła­du powy­żej nale­ży wyeli­mi­no­wać kana­ły komu­ni­ka­cyj­ne ozna­czo­ne linią prze­ry­wa­ną. Domyślam się, że wie­lu czy­tel­ni­ków myśli teraz ​„no jak to tak bez maila?!”. Po wdro­że­niu EOD, wewnętrz­ny mail jest już nie potrzeb­ny (a nawet jest szko­dli­wy), a na zewnątrz nadal jest narzę­dziem komu­ni­ka­cji fir­ma-fir­ma (tak np. dzia­ła mój sys­tem komu­ni­ka­cji z klien­ta­mi). Bardzo czę­sto spo­ty­kam urzę­dy i fir­my, w któ­rych obieg ema­il i obieg ​„for­mal­ny” to uzna­nio­wość pra­cow­ni­ków. Te wdro­że­nia nie speł­nia­ją pod­sta­wo­wej roli sys­te­mów EOD: śle­dze­nie spraw, sta­ty­sty­ki zaję­to­ści pra­cow­ni­ków, wychwy­ty­wa­nie wąskich gar­deł, łatwe zastę­po­wa­nie się pra­cow­ni­ków, moż­li­wość skon­tro­lo­wa­nia i prze­ję­cia spra­wy w dowol­nym momen­cie, peł­na histo­ria wymia­ny informacji. 

Takie wdro­że­nia to wła­śnie bar­dzo czę­sto ini­cja­ty­wy na śred­nich szcze­blach, gdzie mogą powstać decy­zje o wyda­niu środ­ków na takie wdro­że­nie, ale nie ma żad­nych szans na decy­zje o opra­co­wa­niu i wdro­że­niu zmian ope­ra­cyj­nych w ska­li orga­ni­za­cji (np. aktu­ali­za­cja instruk­cji kan­ce­la­ryj­nej w urzę­dzie, bez cze­go wdro­że­ni EOD nie ma tu żad­ne­go sensu).

Celowo poda­łem ten przy­kład, bo typo­wym powo­dem nie­po­wo­dzeń wdro­żeń sys­te­mów EOD czy CRM (te sys­te­my mają naj­gor­szą sta­ty­sty­kę nie­po­wo­dzeń, a są bar­dzo podob­ne do sie­bie), jest brak opra­co­wa­ne­go i wdro­żo­ne­go sku­tecz­ne­go nowe­go ope­ra­cyj­ne­go mode­lu dzia­ła­nia orga­ni­za­cji ​„po wdro­że­niu”. Takim mode­lem są mode­le pro­ce­sów biz­ne­so­wych, ale nie w posta­ci mon­stru­al­nych ilo­ści deta­licz­nych dia­gra­mów (te są tu do nicze­go nie przy­dat­ne). Nie znam przy­pad­ku, by takie ​„obraz­ki” się do cze­go­kol­wiek przy­da­ły. Chodzi o mode­le sfor­ma­li­zo­wa­ne, o ści­śle usta­lo­nym pozio­mie gra­da­cji pro­ce­sów. Ile dia­gra­mów ​„powin­no być”? Tylko i aż tyle, ile trze­ba do roz­wią­za­nia pro­ble­mu… co opi­sa­łem mię­dzy inny­mi tu.

Powyższe ma tak­że inny istot­ny aspekt: pla­no­wa­nie i wdra­ża­nie zmian. Typowy roz­wój orga­ni­za­cji prze­bie­ga w spo­sób ewo­lu­cyj­ny, dość powol­ny. Nie wyma­ga żad­nych dodat­ko­wych zabie­gów poza prze­my­śla­nym wpro­wa­dza­niem nowych, poje­dyn­czych zarzą­dzeń czy drob­nych zmian orga­ni­za­cyj­nych. Jednak pró­by wdro­że­nia znacz­nych zmian w krót­kim cza­sie, z regu­ły skut­ku­ją nie­ocze­ki­wa­ny­mi efek­ta­mi, nie zawsze pożą­da­ny­mi. ​„Moda” na re-inży­nie­rię pro­ce­sów biz­ne­so­wych w latach 90-tych prze­mi­nę­ła tak szyb­ko jak się poja­wi­ła. Dzisiejszy sil­nie kon­ku­ren­cyj­ny rynek nie daje cza­su na powol­ne, ewo­lu­cyj­ne zmia­ny. Bezpieczne zaś wpro­wa­dza­nie takich zmian nie jest moż­li­we bez przy­go­to­wa­nia. Opisane powy­żej pla­ny ope­ra­cyj­ne i ich testy, to nic inne­go jak wła­śnie przy­go­to­wa­nie się do takich zmian. Mając dobrze opra­co­wa­ne mode­le pro­ce­sów i archi­tek­tu­ry IT (jako całość Architektura Biznesowa/Korporacyjna), może­my prze­wi­dzieć i prze­te­sto­wać, więk­szość skut­ków pla­no­wa­nych zmian, i powo­li ale coraz wię­cej firm to robi…