• Produkt: On-line dostęp­ny model orga­ni­za­cji opi­su­ją­cy mecha­nizm jej dzia­ła­nia w tym: pro­ce­sy biz­ne­so­we, powią­za­ne z nimi pro­ce­du­ry i sys­te­my infor­ma­tycz­ne. Raporty: dedy­ko­wa­ne doku­men­ty mode­le na żądanie. 
• Korzyści: Możliwość natych­mia­sto­we­go podej­mo­wa­nia decy­zji wyma­ga­ją­cych aktu­al­nej wie­dzy o orga­ni­za­cji fir­my, a co za tym idzie obni­że­nie ryzy­ka biz­ne­so­we­go (zmia­ny orga­ni­za­cyj­ne, zmia­ny lub wdro­że­nia sys­te­mów IT, infor­ma­cja dla nowych pra­cow­ni­ków i part­ne­rów biznesowych, …). 

Transformacja cyfro­wa to cią­gły pro­ces stra­te­gicz­nej odno­wy, któ­ry wyko­rzy­stu­je postę­py w tech­no­lo­giach cyfro­wych do budo­wa­nia moż­li­wo­ści, któ­re odświe­ża­ją lub zastę­pu­ją model biz­ne­so­wy, podej­ście do współ­pra­cy i kul­tu­rę organizacji.

Wprowadzenie

Podstawą spraw­ne­go zarzą­dza­nia jest aktu­al­na infor­ma­cja źró­dło­wa. Wiedza o tym jak dzia­ła fir­ma, co od cze­go w niej zale­ży, kto co robi, za co odpo­wia­da, jakie doku­men­ty i gdzie powsta­ją, jakich narzę­dzi infor­ma­tycz­nych się do tego uży­wa i jak są one ze sobą połą­czo­ne, jest bez­cen­na w podej­mo­wa­niu bie­żą­cych decy­zji w fir­mie. Raz są to decy­zje orga­ni­za­cyj­ne a raz koniecz­ność szyb­kie­go poka­za­niu komuś: co i jak dzia­ła w fir­mie, gdzie jest jego miej­sce, z kim ma się kon­tak­to­wać. Sam sche­mat orga­ni­za­cyj­ny to dzi­siaj sta­now­czo za mało. 

Wewnętrzna struk­tu­ra orga­ni­za­cyj­na, archi­tek­tu­ra pro­ce­sów biz­ne­so­wych i sys­te­mów infor­ma­tycz­nych, są bar­dzo czę­sto tajem­ni­cą przed­się­bior­stwa bo jest ona dorob­kiem wie­lu lat doświad­czeń orga­ni­za­cji. Dorobkiem, któ­ry cza­sa­mi war­to chro­nić przed sko­pio­wa­niem. Dlatego ope­ro­wa­nie całą tą wie­dzą w jed­nym doku­men­cie stwa­rza ogrom­ne zagro­że­nie że cała ta wie­dza zacznie się roz­cho­dzić w spo­sób niekontrolowany. 

Co ofe­ru­ję? Najpierw ana­li­zę i opra­co­wa­nie aktu­al­ne­go mode­lu dzia­ła­nia fir­my. A następ­nie: utrzy­ma­nie czy­li aktu­ali­za­cje, kon­tro­lo­wa­ne i roz­li­cza­ne udo­stęp­nia­nie tre­ści ade­kwat­nej do potrzeb adre­sa­ta (a nie całe­go opi­su), co moc­no ogra­ni­cza moż­li­wość wypro­wa­dze­nia tej wie­dzy poza fir­mę. Także przy­go­to­wy­wa­nie ad-hoc wycią­gów z tre­ści na uży­tek part­ne­rów han­dlo­wych, dostaw­ców IT itp. Integralną czę­ścią tej usłu­gi jest natu­ral­ny nad­zór mery­to­rycz­ny na tre­ścią i jako­ścią tej dokumentacji.

Jeżeli uwa­żasz, że budże­to­wa­nie i rapor­to­wa­nie zwa­ne con­trol­lin­giem, poma­ga w bie­żą­cym zarzą­dza­niu finan­sa­mi, to obie­cu­je, że aktu­al­ny model pro­ce­sów i sys­te­mów IT tak samo poma­ga w zarzą­dza­niu pozo­sta­łym obsza­rem firmy. 

Elektronizacja przepływu dokumentów

To czę­sto pierw­szy i zna­czą­cy ruch w ramach pod­no­sze­nia efek­tyw­no­ści fir­my. Proste meto­dy popra­wy jako­ści pra­cy naj­czę­ściej jedy­nie pod­no­szą kosz­ty a nicze­go nie popra­wia­ją, np. szyb­ka decy­zja o wdro­że­niu nowe­go sys­te­mu infor­ma­tycz­ne­go tyl­ko dla­te­go, że mają taki kon­ku­ren­ci albo zatrud­nie­nie praw­ni­ka by szyb­ko opra­co­wał nowe wzo­ry regu­la­mi­nów i umów. Mijają kolej­ne dwa lub trzy lata, kolej­ne kosz­ty i żad­nej popra­wy, a bywa, że pogor­sze­nie. Dlaczego tak jest?

Jakie są naj­częst­sze pro­ble­my w nie­uda­nych pro­jek­tach? [?] 83% pro­jek­tów korzy­sta z doku­men­tów tek­sto­wych oraz arku­szy kal­ku­la­cyj­nych do prze­cho­wy­wa­nia wyma­gań, 40% pro­jek­tów korzy­sta z e‑maili do zbie­ra­nia wyma­gań i komu­ni­ka­cji z klien­tem. (wię­cej na stro­nie: Sabotaż doku­men­ta­cyj­ny). 

…oso­bi­ście uwa­żam, że naj­pro­ściej i bez ​„ucze­nia part­ne­rów” cze­go­kol­wiek, jest posia­da­nie ​„strze­żo­ne­go” repo­zy­to­rium i uży­wa­nie maila tyl­ko w celu wysy­ła­nia enig­ma­tycz­nych moni­tów: ​„masz nowy doku­ment do prze­czy­ta­nia”.. w moich oczach, trak­to­wa­nie skrzyn­ki ema­il jako repo­zy­to­rium tre­ści jest co naj­mniej naiw­ne (wię­cej na stro­nie: Bezpieczny jak ema­il).

Problem naj­czę­ściej tkwi w wadli­wym mecha­ni­zmie pra­cy całej fir­my i wie­rze w to, że samo prze­ka­zy­wa­nie infor­ma­cji mailem, a nie na papie­rze, to już cyfry­za­cja. Mechanizm dzia­ła­nia fir­my to: zakre­sy obo­wiąz­ków, regu­ły postę­po­wa­nia, meto­dy pra­cy i zarzą­dza­nie infor­ma­cją. Decydują one o tym jak spraw­nie funk­cjo­nu­je fir­ma . Nie przy­pad­kiem te wła­śnie infor­ma­cje są klu­czo­wym, chro­nio­nym zaso­bem wie­lu spraw­nie dzia­ła­ją­cych fir­mach, nazy­wa­nym know-how. Cyfryzacja zaś ozna­cza, że doku­men­ty (ich treść) nie tyl­ko ma postać ​„elek­tro­nicz­ną”, ale też ich struk­tu­ra i spo­sób zapi­su pozwa­la­ją na auto­ma­ty­za­cję ich prze­twa­rza­nia (samo ska­no­wa­nie doku­men­tów to jesz­cze nie cyfryzacja).

Cyfryzacja czyli zmiana paradygmatu

Czy cyfro­wa trans­for­ma­cja jest koniecz­na? Tak, a powód jest pro­sty: zmie­nia sie para­dyg­mat pra­wa w obsza­rze dokumentów:

• Paradygmat «przy­ję­ty spo­sób widze­nia rze­czy­wi­sto­ści w danej dzie­dzi­nie, dok­try­nie itp.»
• sta­ry para­dyg­mat: nośnik infor­ma­cji umoż­li­wia­ją­cy zapo­zna­nie się z jej tre­ścią (USTAWA z dnia 23 kwiet­nia 1964 r. Kodeks cywil­ny)
• nowy para­dyg­mat: sta­no­wią­cy odręb­ną całość zna­cze­nio­wą zbiór danych upo­rząd­ko­wa­nych w okre­ślo­nej struk­tu­rze wewnętrz­nej i zapi­sa­ny na infor­ma­tycz­nym nośni­ku danych (na podst. USTAWA z dnia 17 lute­go 2005 r. o infor­ma­ty­za­cji dzia­łal­no­ści pod­mio­tów reali­zu­ją­cych zada­nia publicz­ne)

Oznacza to, że trans­for­ma­cja cyfro­wa jest koniecz­no­ścią! Powyższe to nie tyl­ko stan praw­ny ale ​„nowa logi­ka”: nale­ży zmie­nić mecha­nizm dzia­ła­nia aplikacji. 

• cyfro­wa trans­for­ma­cja to nie jest wdra­ża­nie nowych technologii,
• cyfro­wa trans­for­ma­cja to zro­zu­mie­nie tego czym są dane, czym infor­ma­cja a czym jej nośnik,
• cyfro­wa trans­for­ma­cja to zmia­na para­dyg­ma­tu zarzą­dza­nia infor­ma­cją w organizacji,
• cyfro­wa trans­for­ma­cja to zapla­no­wa­nie wyko­rzy­sta­nia dostęp­nej tech­no­lo­gii do wdro­że­nia nowej – cyfro­wej – posta­ci dokumentów!
• cyfro­wa trans­for­ma­cja to ewo­lu­cyj­ne wyj­ście z sys­te­mów ​“lega­cy” powsta­łych w sta­rym paradygmacie!

Analiza i opracowanie modelu firmy

Problemem więk­szo­ści orga­ni­za­cji na ryn­ku jest podej­mo­wa­nie decy­zji orga­ni­za­cyj­nych ​„intu­icyj­nie”, czy­li na bazie tyl­ko wła­sne­go doświad­cze­nia i bez peł­nej wie­dzy o przy­czy­nach i skut­kach obec­ne­go sta­nu rze­czy, co powo­du­je że ryzy­ko tych decy­zji nie jest zna­ne. Kolejnym pro­ble­mem jest koniecz­ność prze­pro­wa­dza­nia tak zwa­nej ana­li­zy przed-wdro­że­nio­wej i ana­li­zy wyma­gań za każ­dym razem, gdy roz­po­czy­na­ny jest kolej­ny pro­jekt zwią­za­ny z reor­ga­ni­za­cją i (lub) roz­bu­do­wą posia­da­ne­go sys­te­mu IT. (wię­cej na stro­nie: Architektura Biznesowa – Audyt orga­ni­za­cji i budo­wa jej mode­lu | Jarosław Żeliński IT-Consulting) 

Kluczowym eta­pem pro­jek­tów popra­wy sytu­acji, zwią­za­nych z cyfry­za­cją, jest opra­co­wa­nie poli­ty­ki zmian pro­ce­sów biz­ne­so­wych i ści­śle z nią zwią­za­nej stra­te­gii roz­wo­ju IT, w szcze­gól­no­ści archi­tek­tu­ry infor­ma­cyj­nej apli­ka­cji (patrz tak­że: Dokumenty czy nie-doku­men­ty.?)

Standardowe podej­ście to ana­li­za posia­da­nych sys­te­mów IT, doku­men­tów i ich struk­tur i pro­ce­sów biz­ne­so­wych. Celem jest zro­zu­mie­nie sta­nu fak­tycz­ne­go, ana­li­za kon­se­kwen­cji tego sta­nu oraz doku­ment reko­men­da­cji (wyma­ga­nia):

Całość powin­na być opra­co­wa­na w for­mie mode­li, bo:

Modelowanie przed­się­bior­stwa stwa­rza dobrą moż­li­wość ana­li­zy oraz kształ­to­wa­nia pro­ce­sów dzia­ła­nia. Dzięki temu moż­na unik­nąć pro­ble­mów przy wpro­wa­dza­niu zmian. (Hubert H. Zimmermann).

Po pierw­sze nale­ży sobie odpo­wie­dzieć na pyta­nie co zmie­nia­my: stra­te­gię ryn­ko­wą, stra­te­gię zarzą­dza­nia infor­ma­cją i jej prze­pły­wem, może archi­tek­tu­rę biz­ne­so­wą. Odpowiedź na to pyta­nie uzy­ska­my w toku tak zwa­nej ana­li­zy sys­te­mo­wej orga­ni­za­cji. Rekomendacje po takiej ana­li­zie mogą wska­zy­wać na potrze­bę reor­ga­ni­za­cji, opty­ma­li­za­cję pro­ce­sów biz­ne­so­wych lub uspraw­nie­nie okre­ślo­nej pracy.

Każda reor­ga­ni­za­cja, a cyfry­za­cja infor­ma­cji też nią jest, to naj­po­waż­niej­szy i naj­bar­dziej ryzy­kow­ny zabieg w orga­ni­za­cji. Wiąże się z wpro­wa­dza­niem zmian logi­ki i orga­ni­za­cji pro­ce­sów czy­li inge­ru­je­my w to ​„co i po co robi­my”. Optymalizacja poszcze­gól­nych pro­ce­sów, to obszar logi­ki biz­ne­so­wej, tego ​„jak to robi­my”. Dlatego zbu­do­wa­nie mode­lu orga­ni­za­cji jest klu­czo­wym eta­pem każ­dej reor­ga­ni­za­cji i wdra­ża­nia zmian.^?*?

Najpierw nale­ży opty­ma­li­zo­wać celo­wość prac, w szcze­gól­no­ści to, czy każ­dy etap cze­muś słu­ży a jeśli tak to cze­mu. Na tym pozio­mie opty­ma­li­zu­je­my pro­ce­sy biz­ne­so­we a nie ich efek­tyw­ność: opty­ma­li­zu­je­my ich logi­kę i treść doku­men­tów. 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 opty­mal­na, ana­li­zu­je­my poszcze­gól­ne pra­ce (pro­ce­du­ry, regu­ły biz­ne­so­we, zada­nia ludzi) i zasta­na­wia­my się czy ich efek­tyw­ność jest wystar­cza­ją­ca (a nie naj­lep­sza) w danej sytu­acji, czy pozwa­la osią­gnąć cel jakim jest pro­dukt pro­ce­su o okre­ślo­nej jakości. 

Proces biznesowy zawsze tworzy dokument jako produkt. Cyfryzacja to nie tylko usuwanie "papieru" z procesów, to przede wszystkim strukturalizacja treści dokumentów i ich  kategoryzacja . 

Kolejny etap, po opra­co­wa­niu pro­ce­sów biz­ne­so­wych, to opra­co­wa­nie mode­lu infor­ma­cyj­ne­go. Polega na ana­li­zie pro­ce­sów biz­ne­so­wych i zebra­niu wie­dzy o obiek­tach biz­ne­so­wych (ich wej­ścia i wyj­ścia czy­li doku­men­ty i ich treść) oraz o tym, czy i jak są ze sobą logicz­nie powiązane. 

Pojawia sie pro­blem sys­te­mów ​„lega­cy” czy­li sta­rych tech­no­lo­gii nio­są­cych dług tech­no­lo­gicz­ny. Transformacja cyfro­wa to tak­że migra­cja z sys­te­mów ​„lega­cy” do nowych technologii.

Na pod­sta­wie ana­liz opra­co­wy­wa­na jest archi­tek­tu­ra sys­te­mu IT zorien­to­wa­na na usłu­gi (zawie­ra dzie­dzi­no­we apli­ka­cje i model inte­gra­cji cało­ści). Celem tego eta­pu jest takie zapro­jek­to­wa­nie doce­lo­wej archi­tek­tu­ry IT, by poszcze­gól­ne apli­ka­cje – prze­twa­rza­ją­ce okre­ślo­ne, dzie­dzi­no­we infor­ma­cje – popraw­nie wymie­nia­ły mię­dzy sobą dane (nale­ży pamię­tać, że inte­gra­cja poprzez współ­dzie­le­nie baz danych rodzi ogrom­ne pro­ble­my z mie­sza­niem kon­tek­stów: np. czym innym jest towar i jego cechy, w tym poło­że­nie, w maga­zy­nie a czym innym jest towar jako pozy­cja z jej kosz­tem naby­cia, sprze­da­żą i podat­kiem z tym zwią­za­nym). Błędy w inte­gra­cji wymia­nie danych hamu­ją (nie raz wręcz blo­ku­ją) roz­wój orga­ni­za­cji i poten­cjal­ne zmia­ny w niej. Istotne jest to by moż­li­wa była zmia­na funk­cjo­nal­no­ści apli­ka­cji, a nawet wymia­na wybra­nych apli­ka­cji, bez potrze­by rewo­lu­cyj­nej wymia­ny (lub reor­ga­ni­za­cji) cało­ści lub więk­szo­ści zaso­bów IT . Dlatego migra­cja powin­na być dobrze zapla­no­wa­na i być warun­ko­wa­na potrze­ba­mi biz­ne­so­wy­mi a nie ogra­ni­cze­nia­mi technologii.

Wdrożenie

Kluczowym eta­pem pro­jek­tów zwią­za­nych z reor­ga­ni­za­cją, lub nawet tyl­ko z mały­mi zmia­na­mi, jest opra­co­wa­nie poli­ty­ki zmian pro­ce­sów biz­ne­so­wych i ści­śle z nią zwią­za­nej stra­te­gii roz­wo­ju IT, w szcze­gól­no­ści archi­tek­tu­ry apli­ka­cji. Korzyści z wpro­wa­dza­nych tą meto­dą zmian, czę­sto są tak duże, że zwrot kosz­tu takie­go pro­jek­tu bywa noto­wa­ny nawet już w pierw­szym kwar­ta­le po zakoń­cze­niu pro­jek­tu, a w przy­pad­ku sys­te­mów IT już na eta­pie wdrażania.

Strategia orga­ni­za­cji to dłu­go­ter­mi­no­we cele i poli­ty­ka ich reali­za­cji, kon­kret­ne rocz­ne czy kwar­tal­ne dzia­ła­nia to tak­ty­ki a nie stra­te­gia? Co więc robić? Przede wszyst­kim opi­sać stra­te­gię i poli­ty­kę jej reali­za­cji (stra­te­gia to plan ale poli­ty­ka to regu­ły dzia­ła­nia a nie opis dzia­łań). Polityka ta powin­na wyzna­czać tak­że spo­sób budo­wy AK (Architektury Korporacyjnej), któ­ra musi pozwo­lić na reali­zo­wa­nie stra­te­gii. Mając poli­ty­kę, zbu­do­wać AK w zgo­dzie mię­dzy inny­mi z zasa­dą, że ?archi­tek­tu­ra kor­po­ra­cyj­na powin­na być zamknię­ta na zmia­ny i otwar­ta na roz­sze­rze­nia?. (Źródło: Zarządzanie zmia­na­mi biz­ne­so­wy­mi | Jarosław Żeliński IT-Consulting).

Tak więc do zarzą­dza­nia orga­ni­za­cją potrzeb­ny jest jej upo­rząd­ko­wa­ny peł­ny model zawie­ra­ją­cy:

1. mecha­nizm dzia­ła­nia orga­ni­za­cji na ryn­ku czy­li pro­ce­sy biz­ne­so­we, ich pro­duk­ty oraz wza­jem­ne ich powią­za­nia na pozio­mie biznesowym,
2. opis zaso­bów takich jak apli­ka­cje wspie­ra­ją­ce pro­ce­sy biz­ne­so­we i śro­do­wi­ska tych apli­ka­cji, to jak są one zin­te­gro­wa­ne i jakie usłu­gi świad­czą oraz komu,
3. całość jest powią­za­na logicz­nie z misją i wizją oraz stra­te­gią, któ­rej reali­za­cję powin­ny pro­ce­sy biz­ne­so­we i zaso­by wspierać.

Struktura takiej doku­men­ta­cji (mode­lu) ma nastę­pu­ją­ca postać:

Kluczową cechą poprawnego modelu jest (powinien być) jego ograniczony poziom szczegółowości. Należy zrezygnować z nadmiaru szczegółów, które i tak są opisane w zakresach obowiązków pracowników i instrukcjach użytkownika każdej aplikacji. Na te elementy się powołujemy w modelu, nie przepisujemy ich do niego. 

Każdy pro­jekt zwią­za­ny z wpro­wa­dza­niem zmian (nie tyl­ko pro­jekt wdro­że­nia np. nowe­go sys­te­mu ERP ale każ­da zmia­na w cało­ści sys­te­mu IT) to koniecz­ność oce­ny wpły­wu tego wdro­że­nia na orga­ni­za­cję oraz potrze­ba opi­sa­nia wyma­gań na to roz­wią­za­nie (wdra­ża­ny pro­dukt). Model Biznesowy (albo tak zwa­na Architektura Biznesowa), jako model dzia­ła­nia orga­ni­za­cji, to nic inne­go jak sta­le aktu­ali­zo­wa­ny opis dzia­ła­nia fir­my i wyma­ga­nia (np. nowe, prze­my­śla­ne usłu­gi aplikacji).

Po opra­co­wa­niu mode­li pro­ce­sów biz­ne­so­wych, opra­co­wy­wa­na jest reko­men­do­wa­na archi­tek­tu­ra IT, w szcze­gól­no­ści poli­ty­ka jej two­rze­nia i roz­wo­ju oraz podział na kom­po­nen­ty. Tu jako wzo­rzec i naj­lep­sze prak­ty­ki sto­so­wa­ne są archi­tek­tu­ra zorien­to­wa­na na usłu­gi i kom­po­nen­to­we meto­dy ana­li­zy i pro­jek­to­wa­nia sys­te­mów. Celem jest jak naj­lep­sze zhar­mo­ni­zo­wa­nie cykli życia pro­ce­sów biz­ne­so­wych z cykla­mi życia apli­ka­cji je wspomagających.

Źródła

Zapytanie