• Produkt: Rekomendacje stan­da­ry­za­cji i cyfry­za­cji zarzą­dza­nych tre­ści i doku­men­tów w posta­ci sza­blo­nów i archi­tek­tu­ry baz danych.
• Korzyści: Podniesienie efek­tyw­no­ści zarzą­dza­nia infor­ma­cją, obni­że­nie ryzy­ka biz­ne­so­we­go (wymia­na infor­ma­cji z part­ne­ra­mi). Wdrożenie elek­tro­nicz­nej wymia­ny doku­men­tów wewnątrz orga­ni­za­cji i z part­ne­ra­mi biznesowymi. 

Usługa ta sta­no­wi sobą audyt tre­ści i struk­tu­ry doku­men­tów w pro­ce­sach biz­ne­so­wych oraz opra­co­wa­nie mode­lu archi­tek­tu­ry IT w celu mapo­wa­nia doku­men­tów na apli­ka­cje, w któ­rych powsta­ją i są wyko­rzy­sty­wa­ne (inte­gra­cja). Są to wyłą­czo­ne i połą­czo­ne razem pierw­sze eta­py usług Audyt orga­ni­za­cji, pod­no­sze­nie efek­tyw­no­ści oraz Analiza i Opracowanie Wymagań na Oprogramowanie. Jednym z głów­nych celów i pro­duk­tów jest opra­co­wa­na stra­te­gia cyfry­za­cji i archi­wi­za­cji doku­men­tów w orga­ni­za­cji oraz zarzą­dza­nia ich treścią.

Wprowadzenie

Zazwyczaj pierw­szym powo­dem do zasta­na­wia­nia się nad obec­ną orga­ni­za­cją fir­my są: spa­da­ją­ce przy­cho­dy, lep­sze wyni­ki kon­ku­ren­tów, ujaw­nio­ne infor­ma­cje sta­no­wią­ce tajem­ni­cę przed­się­bior­stwa, tak­że nie­uda­ne pró­by popra­wy sytu­acji pro­sty­mi meto­da­mi, taki­mi jak np. ​„więk­sze zdy­scy­pli­no­wa­nie”, ​„zwięk­szo­ny nad­zór” czy ​„jesz­cze dłuż­sza umo­wa o zacho­wa­niu poufności”. 

Proste meto­dy popra­wy 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 kore­spon­den­tó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: ?nowy doku­ment??.. 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).

Jeżeli uni­wer­sal­ne stan­dar­do­we pakie­ty biu­ro­we i pocz­ta elek­tro­nicz­na obsłu­gu­ją wię­cej niż 20% czyn­no­ści w pro­ce­sach biz­ne­so­wych Twojej fir­my, masz tak­że poważ­ny pro­blem z dużym ryzy­kiem cią­gło­ści dzia­ła­nia fir­my i nad­mier­ne koszty!

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 firm, 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­cje ich przetwarzania.

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­do­ku­men­ty.?)

Brak w RODO wyma­gań for­mal­nych w zakre­sie pro­wa­dze­nia doku­men­ta­cji prze­twa­rza­nia danych oso­bo­wych na wzór nie­obo­wią­zu­ją­ce­go już roz­po­rzą­dze­nia mini­stra spraw wewnętrz­nych i admi­ni­stra­cji z dnia 29 kwiet­nia 2004 r. w spra­wie doku­men­ta­cji prze­twa­rza­nia danych oso­bo­wych (?) nie ozna­cza, że od 25 maja 2018 r. admi­ni­stra­tor nie jest zobo­wią­za­ny do pro­wa­dze­nia doku­men­ta­cji w któ­rej okre­ślo­ne były­by zasa­dy i pro­ce­du­ry doty­czą­ce prze­twa­rza­nia danych oso­bo­wych zgod­nie z przy­ję­ty­mi roz­wią­za­nia­mi praw­ny­mi, orga­ni­za­cyj (źr.: Aktualności – UODO) 

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).

Korzyści z cyfry­za­cji sys­te­mu infor­ma­cyj­ne­go, 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 ich wdrażania. 

Analiza i projektowanie cyfryzacji

Po pierw­sze nale­ży sobie odpo­wie­dzieć na pyta­nie po 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 nawet 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 biz­ne­so­wy zawsze two­rzy doku­ment jako pro­dukt. Cyfryzacja to nie tyl­ko usu­wa­nie ​„papie­ru” z pro­ce­sów, to przede wszyst­kim struk­tu­ra­li­za­cja tre­ści doku­men­tów i jej kate­go­ry­za­cja .

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ą­za­ne. Na tej pod­sta­wie 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. 

Należy odkryć i opi­sać mecha­nizm dzia­ła­nia orga­ni­za­cji. Jednak zwy­kle, deta­licz­ne spi­sy­wa­nie, w toku wywia­dów, zacho­wań pra­cow­ni­ków i two­rze­nie na tej pod­sta­wie deta­licz­nych ​„map pro­ce­sów”, ma taki sens jak wyko­na­nie serii foto­gra­fii zega­ra i twier­dze­nie, że to opis mecha­ni­zmu jego dzia­ła­nia. Tak zbie­rze­my tyl­ko ogrom przy­pad­ko­wych infor­ma­cji, któ­re nadal nicze­go nie tłu­ma­czą. Nikt tego nie czy­ta i do nicze­go to nie słu­ży. Analiza i mode­lo­wa­nie nie na tym polegają… 

Model powi­nien być sche­ma­tem poka­zu­ją­cym mecha­nizm dzia­ła­nia orga­ni­za­cji, logi­kę pro­ce­sów a nie wszyst­kie zna­ne czyn­no­ści i scenariusze:

Ok. 60% prac nie moż­na opi­sać pro­ce­du­rą, gdyż są one reali­zo­wa­na wg. naj­lep­szej wie­dzy wyko­naw­cy (lub zespo­łu) w danej sytu­acji. Rolą kie­row­ni­ka jest sta­ła opty­ma­li­za­cja obcią­że­nia takie­go ​„zaso­bu”. 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 ś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 scenariusza”. 

Rozwiązanie i jego 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ą popraw­ne­go mode­lu jest (powi­nien być) jego ogra­ni­czo­ny poziom szcze­gó­ło­wo­ści. Należy zre­zy­gno­wać z nad­mia­ru szcze­gó­łów, któ­re i tak są opi­sa­ne w zakre­sach obo­wiąz­ków pra­cow­ni­ków i instruk­cjach użyt­kow­ni­ka każ­dej apli­ka­cji. Na te ele­men­ty się powo­łu­je­my w mode­lu, nie prze­pi­su­je­my 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.

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) 

ZAMÓW

---

1. ^?*?
   http://​www​.bptrend​sas​so​cia​tes​.com/​t​r​a​i​n​i​n​g​/​o​v​e​r​v​i​ew/

Źródła

Ostatnia aktu­ali­za­cja: gru 6, 2021 @ 02:27