Dlaczego nie używam poczty elektronicznej do komunikacji w projektach

Wstęp

Od lat spo­ty­kam się w lite­ra­tu­rze z zakre­su zarzą­dza­nia, z kry­ty­ką pocz­ty elek­tro­nicz­nej jako narzę­dziem zarzą­dza­nia czym­kol­wiek (patrz: Sabotaż…2013). Poczta elek­tro­nicz­na (podob­nie jak pakie­ty biu­ro­we w ogó­le) jest typo­wym przy­kła­dem mak­sy­my: uła­twie­nie nie zawsze jest ulep­sze­niem. W klien­cie pocz­ty elek­tro­nicz­nej zarów­no treść jak i spo­sób adre­so­wa­nia (co i do kogo, kopia, itp.) nie pod­le­ga żad­nej stan­da­ry­za­cji ani restryk­cji (pocz­ta elek­tro­nicz­na czę­sto słu­ży do wypro­wa­dza­nia danych z fir­my). Jak dodać do tego fakt, że załącz­ni­ki są nie­wi­docz­ne w narzę­dziach do lokal­ne­go wyszu­ki­wa­nia, że mamy na ser­we­rach fil­try anty­spa­mo­we któ­rych regu­ły nie pod­da­ją się kon­tro­li użyt­kow­ni­ków, że nie panu­je­my nad tym co inni mają w swo­ich skrzyn­kach pocz­to­wych, to mamy obraz abso­lut­ne­go bra­ku pano­wa­nia nad infor­ma­cją w orga­ni­za­cji i chaosu. 

Swego cza­su dr Paweł Litwiński, praw­nik, napi­sał kry­tycz­ny arty­kuł o zasto­so­wa­niu pocz­ty elek­tro­nicz­nej przez adwo­ka­tów. Jego tekst był sze­ro­ko cyto­wa­ny przez wie­lu auto­rów, tu jeden z takich arty­ku­łów. Wybrałem kil­ka waż­nych kwestii:

Praktyka poka­zu­je, że wie­lu adwo­ka­tów i rad­ców praw­nych korzy­sta z dar­mo­wych skrzy­nek, tak­że tych wprost zastrze­ga­ją­cych sobie pra­wo do ska­no­wa­nia korespondencji. […]

Konflikt pomię­dzy obo­wiąz­kiem ochro­ny infor­ma­cji a warun­ka­mi narzu­co­ny­mi w regu­la­mi­nach dar­mo­wych usług to jed­no. Czym innym są kwe­stie bezpieczeństwa.[…]

? Na logi­kę, lepiej żeby o mate­ria­łach obję­tych tajem­ni­cą adwo­kac­ką nie dowie­dział się żaden dostaw­ca, ale z dru­giej stro­ny, rzad­ko któ­rej kan­ce­la­rii praw­nej uda się samo­dziel­nie skon­fi­gu­ro­wać ser­wer pocz­to­wy tak, aby był rów­nie bez­piecz­ny i nie­awa­ryj­ny, jak infra­struk­tu­ra np. Gmaila. Oczywiście, moż­na zle­cić to zewnętrz­nej pol­skiej fir­mie, ale wte­dy mamy ten sam pro­blem z zaufa­niem, co w przy­pad­ku korzy­sta­nia z ser­we­rów np. Google ? zwra­ca uwa­gę Piotr Konieczny, eks­pert ds. cyber­bez­pie­czeń­stwa z ser­wi­su Niebezpiecznik​.pl. ? Abstrahując więc od aspek­tów praw­nych, roz­pa­tru­jąc pro­blem wyłącz­nie na płasz­czyź­nie bez­pie­czeń­stwa, tj. ochro­ny skrzyn­ki przed ata­ka­mi, moim zda­niem praw­ni­kom nie­dy­spo­nu­ją­cym budże­tem na bez­pie­czeń­stwo takim, jaki posia­da­ją pro­fe­sjo­nal­ni dostaw­cy usług pocz­to­wych, lepiej i pro­ściej było­by wyko­rzy­stać infra­struk­tu­rę np. Google?a ? doda­je. Jego zda­niem praw­ni­cy powin­ni przede wszyst­kim roz­wa­żyć moż­li­wość szy­fro­wa­nia kore­spon­den­cji. Wtedy zarów­no dar­mo­wy, jak i płat­ny dostaw­ca usług nie będzie w sta­nie jej podej­rzeć. Szyfrowanie jest bez wąt­pie­nia naj­bez­piecz­niej­szym spo­so­bem, ale wią­że się z koniecz­no­ścią dostar­cze­nia klu­cza czy hasła odbior­cy, a ten nie zawsze godzi się na takie nie­do­god­no­ści. Co wię­cej, klien­ci kan­ce­la­rii sami czę­sto korzy­sta­ją z dar­mo­wych skrzy­nek. ? I nie rozu­mie­ją, dla­cze­go pouf­ne infor­ma­cje nie powin­ny być na nie prze­sy­ła­ne. Moim obo­wiąz­kiem jest wów­czas poin­for­mo­wać takie­go klien­ta o zagro­że­niach z tym zwią­za­nych. Oczywiście jeśli mimo tego będzie chciał uży­wać takiej skrzyn­ki do kore­spon­den­cji ze mną, to nie mogę mu tego zabro­nić ? zwra­ca uwa­gę dr Paweł Litwiński. ? Z dru­giej stro­ny są rów­nież klien­ci, któ­rzy wręcz wyma­ga­ją, by w kore­spon­den­cji z nimi uży­wać jedy­nie skrzy­nek zało­żo­nych na ich ser­we­rach. Tak restryk­cyj­ną mają poli­ty­kę bez­pie­czeń­stwa. Chcąc dla nich pra­co­wać, adwo­kat czy rad­ca musi przy­stać na te warun­ki ? doda­je ekspert.

(patrz: Darmowe e‑maile nie dla praw­ni­ków. Dostawca pocz­ty ska­nu­je jej zawar­tość – Forsal​.pl)

W 2013 roku pisałem:

W więk­szo­ści przy­pad­ków treść umiesz­cza­na jest w tre­ści ema­il??a lub w załącz­ni­ku (załą­czo­ne doku­men­ty). Jeżeli treść ema­ila nie jest szy­fro­wa­na (a gene­ral­nie nie jest, o ile sami o to nie zadba­my, co jed­nak, jak poka­zu­je cyto­wa­ny Niebezpiecznik, nie jest try­wial­ne) nasza kore­spon­den­cja, prze­cho­dząc przez publicz­ne łącza sie­ci Internet, jest jaw­na i łatwa do pod­słu­chi­wa­nia. Jak uczy­nić naszą kore­spon­den­cję (bar­dziej) niejawną?

(Patrz: Bezpieczny jak ema­il czy­li wca­le – Jarosław Żeliński IT-Consulting – Systemy Informacyjne)

Przypomnę klu­czo­we tezy powyż­sze­go arty­ku­łu. Generalnie waż­nych doku­men­tów nie nale­ży prze­sy­łać jako załącz­ni­ki z dwóch powo­dów: nie wie­my co sie z nimi dzie­je po dro­dze, nie wie­my czy zosta­ły dostar­czo­ne, i kie­dy, gdyż bar­dzo wie­lu użyt­kow­ni­ków ema­il ma wyłą­czo­ne auto­ma­tycz­ne ode­sła­nie potwier­dze­nia w swo­jej poczcie, co skut­ku­je tym, że po pro­stu jest to nie­wia­ry­god­na for­ma potwier­dza­nia. Poniżej sche­mat poka­zu­ją­cy dro­gę pocz­ty email: 

Droga pocz­ty elektronicznej.

Środkowa część (Internet) to tak­że poten­cjal­ne kolej­ne pośred­ni­czą­ce ser­we­ry, nie wie­my co sie na nich dzie­je. Tak więc dwie klu­czo­we wady ema­il to poten­cjal­ne ska­no­wa­nie tre­ści po dro­dze oraz brak kon­tro­li nad dorę­cze­niem. Czy moż­na ina­czej? Owszem: do prze­ka­zy­wa­nia doku­men­tów moż­na użyć repo­zy­to­rium (ser­we­ra pli­ków) z kon­tro­lo­wa­nym dostę­pem. Poniżej sche­mat blo­ko­wy archi­tek­tu­ry nie­ma­ją­cej ww. wad prze­sy­ła­nia doku­men­tów mailem:

Dokumenty prze­ka­zy­wa­ne za pośred­nic­twem repozytorium

Dokumenty w dro­dze” nie opusz­cza­ją repo­zy­to­rium: z nasze­go kom­pu­te­ra ładu­je­my je na ser­wer wska­zu­jąc ewen­tu­al­nie okre­ślo­ne­go adre­sa­ta (lub robi to mecha­nizm obsłu­gu­ją­cy wymia­nę tre­ści pomię­dzy uczest­ni­ka­mi), okre­ślo­na oso­ba dosta­je mailem infor­ma­cje, że jest dla niej doku­ment, żeby go pobrać musi się zalo­go­wać do repo­zy­to­rium. W efek­cie treść (plik) nie jest nigdzie nara­żo­na na ska­no­wa­nie, podej­rze­nie go itp. Tu ema­il słu­ży wyłącz­nie do moni­to­wa­nia fak­tu, że jest doku­ment do nas adre­so­wa­ny i że moż­na do pobrać, co zosta­nie odnotowane.

Mając nawet pro­ste, dostęp­ne przez inter­net, repo­zy­to­rium, moż­na umie­ścić tam dowol­ny plik i mailem poin­for­mo­wać adre­sa­ta (wcze­śniej zakła­da­my mu tam kon­to), że powi­nien pobrać plik. Serwer reje­stru­je zarów­no moment zała­do­wa­nia pli­ku jak i jego pobra­nia, co jest gwa­ran­to­wa­nym zna­kiem cza­su nada­nia i dorę­cze­nia. Minus takie­go roz­wią­za­nia to ręcz­na obsłu­ga całe­go pro­ce­su, plus to pano­wa­nie nad wszyst­kim i bezpieczeństwo.

Sprawdzonym, od daw­na, na ryn­ku pomy­słem jest sys­tem work­flow z udo­stęp­nia­nym repo­zy­to­rium, auto­ma­ty­zu­ją­cy cały ten proces: 

Architektura sys­te­mu wymia­ny danych z Repozytorium.

Uogólniając moż­na go przed­sta­wić jako ser­wer usług:

System work­flow ste­ro­wa­ny regułami

System dorę­czeń to tak napraw­dę funk­cjo­nal­ność apli­ka­cji typu work­flow zorien­to­wa­ne­go na zada­nia (task mana­ger), mają­cej moż­li­wość udo­stęp­nie­nia jej kon­tra­hen­tom. Funkcjonalność taką ma wie­le sys­te­mów CRM, sys­te­mów help­desk, wie­le repo­zy­to­riów pozwa­la na skon­fi­gu­ro­wa­nie sub­skryp­cji zda­rzeń powią­za­nych z doku­men­ta­mi. Zbudowanie takie­go sys­te­mu opar­te­go na regu­łach, zamiast na macier­zach praw dostę­pu do doku­men­tów, zna­ko­mi­cie uprasz­cza całość i dodat­ko­wo pod­no­si bez­pie­czeń­stwo (bar­dzo uła­twia wdra­ża­nie RODO) . Ciekawą funk­cjo­nal­no­ścią jest moż­li­wość blo­ko­wa­nia moż­li­wo­ści pobra­nia doku­men­tu na lokal­ny dysk, dozwo­lo­ne jest jedy­nie prze­glą­da­nie tre­ści w prze­wi­ja­nym oknie (ofe­ru­ją to nie­któ­re tego typu systemy).

Systemy tego typu są tak­że wdra­ża­ne jako zamien­nik pocz­ty elek­tro­nicz­nej wewnątrz orga­ni­za­cji. Tam gdzie pod­sta­wo­wym wewnętrz­nym sys­te­mem komu­ni­ka­cji jest pocz­ta elek­tro­nicz­na pro­ble­mem są giną­ce doku­men­ty oraz brak dostę­pu do doku­men­tów (skrzy­nek) osób nie­do­stęp­nych, będą­cych poza fir­mą (chro­ba, dele­ga­cja itp.). Generalnie pocz­ta jako skład doku­men­tów” ma tę pod­sta­wo­wą wadę, że doku­men­ty są roz­pro­szo­ne i zarza­dza­nie nimi w jed­no­li­ty spo­sób jest nie­moż­li­we. Stosowanie współ­dzie­lo­nych dys­ków nie roz­wią­zu­je cał­ko­wi­cie pro­ble­mu, bo po pierw­sze nie da się budo­wać reguł dostę­pu, po dru­gie wymia­na doku­men­tów z oso­ba­mi spo­za fir­my jest bar­dzo trud­na (np. wyma­ga uru­cho­me­nia VPN co jest trud­ne, wyma­ga inge­ren­cji w cudzy kom­pu­ter, i coraz czę­ściej nie jest to moż­li­we w wie­lu firmach).

Tak więc pocz­ta elek­tro­nicz­na, jako swo­bod­na komu­ni­ka­cja mię­dzy ludź­mi owszem, jest przy­dat­na. Jednak jako narzę­dzie do zarzą­dza­nia komu­ni­ka­cją, prze­pły­wem tre­ści, doku­men­tów ich wydań i dorę­czeń, jest bar­dzo zawod­na. A war­to wie­dzieć, że praw­na ochro­na know-how w UE, czy­li w Polsce tak­że, to przede wszyst­kim obo­wią­zek ochro­ny tre­ści przez pod­miot chro­nią­cy (udo­stęp­nia­ją­cy) takie dane. Dlatego dość kurio­zal­nie wyglą­da każ­da fir­ma, któ­ra wysy­ła­jąc mailem umo­wę o pouf­no­ści (NDA) wysy­ła potem tak­że mailem te pouf­ne” dokumenty…

Na zakończenie

Rozwiązań, reali­zu­ją­cych opi­sa­ne wyżej funk­cje, nie bra­ku­je. Główną blo­ka­dą ich wdra­ża­nia jest przy­zwy­cza­je­nie do swo­bo­dy. Jednak pocz­ta elek­tro­nicz­na jest kla­sycz­nym przy­kła­dem tego, że uła­twie­nie nie zawsze jest ulep­sze­niem. O wdra­ża­niu sys­te­mów work­flow, panu­ją­cych nad komu­ni­ka­cją i jej pouf­no­ścią, mówi się podob­nie jak o sys­te­mach kopii zapa­so­wych: fir­my dzie­lą się na te, któ­re wdro­ży­ły sku­tecz­ny work­flow i na te któ­re wdrożą.

Kilka przy­kła­dów (nie ofe­ru­ję tych sys­te­mów, to nie są reko­men­da­cje a przykłady):

  • Biuro księ­go­we, któ­re mnie obsłu­gu­je, ode­szło od pro­ste­go sys­te­mu FK i komu­ni­ka­cji mailo­wej (prze­ka­zy­wa­nie doku­men­tów kosz­to­wych, wysy­ła­nie klien­tom dekla­ra­cji podat­ko­wych, rapor­tów itp.), obec­nie korzy­sta z podat​ki​po​dat​ki​.pl.
  • Zaczynałem jak wie­lu od pocz­ty elek­tro­nicz­nej, po kil­ku przy­go­dach z doku­men­ta­mi w pro­jek­tach (kto, co, kie­dy i komu) szyb­ko wdro­ży­łem dar­mo­wy, potem sup­por­to­wa­ny osTicket (na począ­tek bar­dzo dobry i łatwy we wdrożeniu). 
  • Z uwa­gi na spe­cy­fi­kę mojej pra­cy (pra­ca pole­ga­ją­ca na zbie­ra­niu danych i two­rze­niu rapor­tów z ana­liz, ich recen­zo­wa­nie przez klien­tów) uży­wam obec­nie do komu­ni­ka­cji bar­dziej zaawan­so­wa­ne­go opro­gra­mo­wa­nia PostMania.
  • U wie­lu klien­tów spo­ty­kam, popu­lar­ny w ser­wi­sach i fir­mach IT, Mantis.
  • Do zarzą­dza­nia pro­ce­sem nego­cjo­wa­nia i pod­pi­sy­wa­nia umów, wie­le firm i ich praw­ni­ków uży­wa opro­gra­mo­wa­nia Pergamin.
  • No i powszech­ny, z uwa­gi na pra­wo, ePUAP.

Polecam roz­wa­że­nie rezy­gna­cji z pocz­ty elek­tro­nicz­nej do prze­ka­zy­wa­nia doku­men­tów pro­jek­to­wych, nie tyl­ko z uwa­gi na ich bez­pie­czeń­stwo ale głów­nie z uwa­gi na zarzą­dza­nie nimi i kon­tro­le w całym cyklu życia dokumentu. 

Źródła

Paschke, A., & Kozlenkov, A. (2008). A Rule-based Middleware for Business Process Execution. 13.

Kto winien porażki projektu? Zamawiający!

Od cza­su do cza­su jestem pro­szo­ny o audy­ty doku­men­ta­cji pro­jek­tów. Ma to miej­sce, albo gdy jestem anga­żo­wa­ny do pro­jek­tu będą­ce­go kolej­nym podej­ściem do wdro­że­nia, albo w spo­rach przed­są­do­wych mię­dzy dostaw­cą opro­gra­mo­wa­nia i zama­wia­ją­cym. Tu razem kil­ka spo­strze­żeń z tych analiz.

Na mar­gi­ne­sie. W spo­rach przed­są­do­wych i sądo­wych wynik eks­per­ty­zy abso­lut­nie nie może być zamó­wio­ny”, cze­go nie­ste­ty czę­sto ocze­ku­ją, nie raz wręcz żąda­ją pod groź­bą odmo­wy zapła­ty za tę usłu­gę, zama­wia­ją­cy takie eks­per­ty­zy. Bywa to tym bar­dziej żenu­ją­ce, że rosz­cze­nia takie wysu­wa­ją praw­ni­cy zle­ca­ją­cych, czy­li oso­by zna­ją­ce pra­wo i – teo­re­tycz­nie – sto­su­ją­cy zasa­dy ety­ki w swo­jej pracy.

Wiele lat uwa­ża­łem, że win­ni są dostaw­cy, któ­rzy powin­ni wyka­zać się moż­li­wie naj­wyż­szym pro­fe­sjo­na­li­zmem, a tego nie robią. Jakiś czas temu zmie­ni­łem jed­nak zda­nie (nie o pro­fe­sjo­na­li­zmie dostawców). 

Poza reali­zo­wa­ny­mi pro­jek­ta­mi, pro­wa­dzę tak­że szko­le­nia oraz zaję­cia ze stu­den­ta­mi stu­diów nie­sta­cjo­nar­nych i pody­plo­mo­wych: to nie raz doświad­cze­ni prak­ty­cy. Na wykła­dach i ćwi­cze­niach sta­ram się poka­zać jak to robić dobrze”, jed­nym z ele­men­tów tego jak to robić dobrze” jest jak nie robić tego źle” i dys­ku­sje na ten temat. 

Dlaczego zmie­ni­łem zda­nie? I wła­sne doświad­cze­nie i dys­ku­sje ze stu­den­ta­mi prze­ko­na­ły mnie, że gene­ral­nie celem dostaw­cy jest mak­sy­ma­li­za­cja zysków. Co mi sta­le mówią uczą­cy się u mnie prak­ty­cy? Klient nasz pan, mamy robić wszyst­ko co chce klient bo on za to pła­ci, a to, czy to co klient chce ma sens, nie ma zna­cze­nia bo to pro­blem klien­ta (chy­ba każ­dy pro­gra­mi­sta sły­szy to od swo­je­go prze­ło­żo­ne­go raz dziennie). 

Jak klient nie wie cze­go chce, to na jego koszt pró­bu­je­my.

W 2018 arty­kuł o poraż­ce wdro­że­nia w LID koń­czy­łem słowami: 

Dziwi mnie, że wszyst­kie te, doświad­czo­ne poraż­ką, fir­my mają dostęp do tej samej wie­dzy co np. ja, a mimo to zarzą­dy tych firm wie­rzą bez­gra­nicz­nie dostaw­com opro­gra­mo­wa­nia i wie­rzą, że opi­sy­wa­ne od lat przy­czy­ny pora­żek u nich nie wystą­pią? (źr.: Porażka za 2 mld zł. Lidl wyco­fu­je się z wdro­że­nia SAP – Jarosław Żeliński IT-Consulting)

więc win­ny jest zamawiający… 

Ten arty­kuł to krót­ka ana­li­za warun­ków praw­nych i prak­tycz­nych reali­za­cji pro­jek­tów wdrożeniowych. 

Umowa efektu a staranne działanie

Poniższy tekst, to treść, któ­rą w róż­nych for­mach umiesz­czam jako wstęp do ekspertyz. 

W pra­wie cywil­nym wyróż­nio­no dwie pod­sta­wo­we for­my świad­cze­nia zamó­wio­nej usługi:

  1. Umowa o dzieło
  2. Umowa zle­ce­nia

Scharakteryzowane zosta­ły w nastę­pu­ją­cy sposób:

Umowa o dzieło

Art. 627. Przez umo­wę o dzie­ło przyj­mu­ją­cy zamó­wie­nie zobo­wią­zu­je się do wyko­na­nia ozna­czo­ne­go dzie­ła, a zama­wia­ją­cy do zapła­ty wynagrodzenia.

Zlecenie

Art. 734. § 1. Przez umo­wę zle­ce­nia przyj­mu­ją­cy zle­ce­nie zobo­wią­zu­je się do doko­na­nia okre­ślo­nej czyn­no­ści praw­nej dla dają­ce­go zlecenie.

§ 2. W bra­ku odmien­nej umo­wy zle­ce­nie obej­mu­je umo­co­wa­nie do wyko­na­nia czyn­no­ści w imie­niu dają­ce­go zle­ce­nie. Przepis ten nie uchy­bia prze­pi­som o for­mie pełnomocnictwa.

.

W powszech­nej i utrwa­lo­nej opi­nii praw­ni­ków i w orzecz­nic­twie przyj­mu­je się, że:

Umowa zle­ce­nia jest umo­wą sta­ran­ne­go dzia­ła­nia. Zleceniobiorca zobo­wią­zu­je się do sta­ran­ne­go dzia­ła­nia i za to wła­śnie odpo­wia­da, a nie, jak w przy­pad­ku umo­wy o dzie­ło, za rezul­tat pra­cy. W umo­wie nale­ży więc dokład­nie opi­sać czyn­no­ści, jakie ma wyko­ny­wać zle­ce­nio­bior­ca, by póź­niej moż­na było oce­nić, czy zle­ce­nie zosta­ło wyko­na­ne oraz czy zosta­ło wyko­na­ne w spo­sób sta­ran­ny.” . A tak­że, że „…moż­na stwier­dzić, iż w zobo­wią­za­niach sta­ran­ne­go dzia­ła­nia dłuż­nik zobo­wią­zu­je się jedy­nie do doło­że­nia nale­ży­tej sta­ran­no­ści w zmie­rza­niu do usta­lo­ne­go celu, z tym że jego osią­gnię­cie pozo­sta­je poza tre­ścią sto­sun­ku zobo­wią­za­nio­we­go. Natomiast w przy­pad­ku zobo­wią­za­nia rezul­ta­tu na dłuż­ni­ku cią­ży powin­ność osią­gnię­cia ozna­czo­ne­go z góry, spre­cy­zo­wa­ne­go rezul­ta­tu, przy czym ten rezul­tat to okre­ślo­ny fakt, w nastą­pie­niu któ­re­go wie­rzy­ciel jest zain­te­re­so­wa­ny, praw­ny i eko­no­micz­ny sku­tek ozna­czo­ny w tre­ści zobo­wią­za­nia, nie zaś sama czyn­ność, któ­rą dłuż­nik powi­nien pod­jąć.” .

Podsumowując moż­na stwier­dzić, że

  1. Umowa o dzie­ło to umo­wa, w któ­rej dają­cy zamó­wie­nie z góry opi­su­je to co chce otrzy­mać (dzie­ło), a przyj­mu­ją­cy zamó­wie­nie zobo­wią­zu­je się to dostar­czyć (wyko­nać dzieło).
  2. Zlecenie to umo­wa, w któ­rej przyj­mu­ją­cy zle­ce­nie dzia­ła w imie­niu dają­ce­go zle­ce­nie, w kon­se­kwen­cji za efekt zle­co­nej pra­cy odpo­wia­da dają­cy zlecenie.

Znakomita więk­szość umów na dostar­cze­nie opro­gra­mo­wa­nia to, umo­wy sta­ran­ne­go dzia­ła­nia, a tak zwa­ne umo­wy agi­le” mają taki cha­rak­ter z zasa­dy. Tu za uzy­ska­ny efekt zawsze odpo­wia­da Zamawiający.

A jeże­li dostaw­ca jest nie­rze­tel­ny? Jest takie ryzy­ko, jed­nak odpo­wie­dzial­no­ścią zama­wia­ją­ce­go jest tak­że nad­zór na pra­ca­mi wykonawcy!

Proces dostarczenia oprogramowania

Inżynieria opro­gra­mo­wa­nia, na tle innych obsza­rów inży­nie­rii, jest mło­dą dzie­dzi­ną, któ­ra nie wykształ­ci­ła dedy­ko­wa­ne­go pra­wo­daw­stwa, tak jak np. inży­nie­ria budow­la­na, któ­ra ma swo­je” pra­wo budow­la­ne. Z tego też powo­du, jedy­nym źró­dłem opi­sów postę­po­wa­nia są tak zwa­ne dobre prak­ty­ki, stan­dar­dy oraz ana­lo­gie, sto­so­wa­ne tak­że – w obsza­rze inży­nie­rii – do pra­wa budowlanego.

Na diagramie 'Iteracyjno-przyrostowy proces tworzenia oprogramowania' zobrazowano standardowy proces dostarczania rozwiązania jakim jest oprogramowanie (Dennis et al., 2012). Obecnie, z uwagi na tempo zmian w gospodarce, zaleca się by jedna 'pętla iteracyjna rozwoju i utrzymania' nie przekraczała w czasie jednego roku budżetowego, jednak preferowanym okresem jest pół roku z uwagi na to, że sztywne uzależnianie wdrażania oprogramowania wspomagającego zarządzanie, od rygorów rocznych okresów budżetowych było by znaczącym utrudnienie w toku wdrażania zmian w firmach. Projekty małe to projekty będące pojedynczą iteracją. Dobrą praktyką postępowania dla projektów większych jest dzielenie ich na przyrostowe iteracje (w kolejnych cyklach pętli iteracji wdrażane są kolejne funkcjonalności lub moduły) (Larman, 2004). Z reguły robi to wtedy wykonawca przyjmujący zamówienie(Maciaszek, 2001). Co do zasady, za specyfikowanie wymagań i jakość tej specyfikacji, w każdym rodzaju inżynierii, odpowiada zamawiający (Hay, 2003). Zamawiający jest jedynym tu podmiotem, znającym swój cel biznesowy, jako podmiot zamawia u dostawcy produkt a nie efekt biznesowy jaki ma zamiar osiągnąć (Ackoff i in., 2007). W tym miejscu, należy zwrócić uwagę na bardzo ważny fakt, że w przypadku umowy efektu, kolejne iteracje to uszczegółowienie i implementacja funkcjonalności opisanych w umowie, a nie kolejne nowe funkcjonalności.
Iteracyjno-przy­ro­sto­wy pro­ces two­rze­nia oprogramowania

Na dia­gra­mie «Iteracyjno-przy­ro­sto­wy pro­ces two­rze­nia opro­gra­mo­wa­nia» zobra­zo­wa­no stan­dar­do­wy pro­ces dostar­cza­nia roz­wią­za­nia jakim jest opro­gra­mo­wa­nie . Obecnie, z uwa­gi na tem­po zmian w gospo­dar­ce, zale­ca się by jed­na «pętla ite­ra­cyj­na roz­wo­ju i utrzy­ma­nia» nie prze­kra­cza­ła w cza­sie jed­ne­go roku budże­to­we­go, jed­nak pre­fe­ro­wa­nym okre­sem jest pół roku z uwa­gi na to, że sztyw­ne uza­leż­nia­nie wdra­ża­nia opro­gra­mo­wa­nia wspo­ma­ga­ją­ce­go zarzą­dza­nie, od rygo­rów rocz­nych okre­sów budże­to­wych było by zna­czą­cym utrud­nie­nie w toku wdra­ża­nia zmian w fir­mach. Projekty małe to pro­jek­ty będą­ce poje­dyn­czą ite­ra­cją. Dobrą prak­ty­ką postę­po­wa­nia dla pro­jek­tów więk­szych jest dzie­le­nie ich na przy­ro­sto­we ite­ra­cje (w kolej­nych cyklach pętli ite­ra­cji wdra­ża­ne są kolej­ne funk­cjo­nal­no­ści lub modu­ły) . Z regu­ły robi to wte­dy wyko­naw­ca przyj­mu­ją­cy zamó­wie­nie . Co do zasa­dy, za spe­cy­fi­ko­wa­nie wyma­gań i jakość tej spe­cy­fi­ka­cji, w każ­dym rodza­ju inży­nie­rii, odpo­wia­da zama­wia­ją­cy . Zamawiający jest jedy­nym tu pod­mio­tem, zna­ją­cym swój cel biz­ne­so­wy, jako pod­miot zama­wia u dostaw­cy pro­dukt a nie efekt biz­ne­so­wy jaki ma zamiar osią­gnąć, za efekt efekt biz­ne­so­wy z zasa­dy odpo­wia­da biz­nes” 

W tym miej­scu, nale­ży zwró­cić uwa­gę na bar­dzo waż­ny fakt: w przy­pad­ku umo­wy efek­tu, kolej­ne ite­ra­cje to uszcze­gó­ło­wie­nie i imple­men­ta­cja funk­cjo­nal­no­ści opi­sa­nych w umo­wie, a nie kolej­ne nowe funk­cjo­nal­no­ści. Nowe funk­cjo­nal­no­ści powsta­ją w toku roz­wo­ju JUŻ WDROŻONEGO I POPRAWNIE DZIAŁAJĄCEGO oprogramowania. 

Podsumowanie

Projekty wdro­że­nio­we (dostar­cza­nie opro­gra­mo­wa­nia) mogą być reali­zo­wa­ne przez bie­żą­ce zle­ca­nie kon­kret­nych prac usłu­go­daw­cy, lub poprzez opi­sa­nie ocze­ki­wa­ne­go efek­tu jako wyma­ga­ne­go roz­wią­za­nia i zawar­cie Umowy o dzie­ło z przyj­mu­ją­cym zamó­wie­nie, co zobra­zo­wa­no na dia­gra­mie Podsumowanie sta­nu wie­dzy. W obu przy­pad­kach Zamawiający pono­si skut­ki swo­jej decy­zji bo:

  1. jako zle­ce­nio­daw­ca (umo­wy T&M) sam usta­la co i jak ma zostać wykonane,
  2. jako zama­wia­ją­cy okre­ślo­ny efekt (umo­wy o dzie­ło), sam usta­la ocze­ki­wa­ny efekt (pro­dukt) w dniu zawar­cia umo­wy (jako opis przed­mio­tu zamówienia).

Odpowiedzialność przyj­mu­ją­ce­go zamó­wie­nia pole­ga albo na sta­ran­nym dzia­ła­niu, albo na zgod­no­ści tego co dostar­czy z tym co zamó­wio­no, w rozu­mie­niu ocze­ki­wa­ne­go efek­tu. Jeżeli przed­mio­tem zamó­wie­nia jest opro­gra­mo­wa­nie, czy­li narzę­dzie pra­cy zama­wia­ją­ce­go, tyl­ko zama­wia­ją­cy pono­si odpo­wie­dzial­ność za skut­ki wdro­że­nia tego co zamó­wił . Dostawca odpo­wia­da wyłącz­nie za przed­miot umo­wy .

Tak więc zama­wia­ją­cy zawsze dosta­nie to co chce, ale nie koniecz­nie to co jest mu fak­tycz­nie potrzeb­ne. Innymi sło­wy, na ryn­ku rzą­dzo­nym przez docho­dy i zyski, dostaw­ca opro­gra­mo­wa­nia zawsze będzie pra­co­wał pod dyk­tan­do zama­wia­ją­ce­go (lub za jego zgo­dą) i będzie to robił do wyczer­pa­na budże­tu zamawiającego. 

Bardzo cie­ka­we są blo­gi dostaw­ców opro­gra­mo­wa­nia. Wielu ich auto­rów fak­tycz­nie sta­ra się, ale cóż… jeden z cie­kaw­szych wpi­sów na ten temat jest zaty­tu­ło­wa­ny The art (and scien­ce) of col­lec­ting requ­ire­ments: top 3 mista­kes ven­dors make”. Autor z per­spek­ty­wy dostaw­cy, zwra­ca uwa­gę na trzy klu­czo­we przy­czy­ny pora­żek: uzna­nie, że to użyt­kow­nik odpo­wia­da za wyma­ga­nia, mie­sza­nie wyma­gań z pomy­sła­mi na ich reali­za­cję, nie­do­ce­nia­nia macie­rzy śla­do­wa­nia. To, popeł­nia­nie tych błę­dów, nie­ste­ty jest naj­czę­ściej spo­ty­ka­ną cechą ana­liz pro­wa­dza­nych wła­śnie przez dostaw­ców opro­gra­mo­wa­nia, a za wszyst­ko i tak pła­ci nabyw­ca. W bar­dziej nauko­wy spo­sób (szcze­gól­nie kry­ty­ku­jąc wyma­ga­nia pisa­ne języ­kiem natu­ral­nym przez zama­wia­ją­ce­go) opi­sa­li to bar­dzo dokład­nie Šenkýř i Kroha .

Konkluzja jest taka, że za nie­uda­ne wdro­że­nia odpo­wia­da zawsze zamawiający. 

Główną winą zama­wia­ją­ce­go jest to, że zama­wia usłu­gi, któ­rych isto­ty nie rozu­mie więc pozo­sta­wia wyko­naw­cę prak­tycz­nie bez nad­zo­ru, odda­jąc mu nie­mal­że nie­ogra­ni­czo­ne upraw­nie­nia co do zakre­su pro­jek­tu. Pierwszym zaś samo­bój­czym kro­kiem jest zle­ce­nie ana­li­zy wyma­gań i pro­jek­to­wa­nie wybra­ne­mu wcze­śniej dostaw­cy opro­gra­mo­wa­nia. Biorąc pod uwa­gę ryn­ko­wy kon­flikt inte­re­su dostaw­cy i odbior­cy (zama­wia­ją­cy mak­sy­ma­li­zu­je żąda­nia a dostaw­ca mak­sy­ma­li­zu­je zysk), jest to pro­sta dro­ga do poraż­ki, jaką jest tak­że znacz­ne przepłacenie. 

Pytani pra­cow­ni­cy dostaw­ców zawsze odpo­wia­da­ją, że prze­cież celem jest dowie­zie­nie pro­jek­tu”, nie­ste­ty nie jest jed­nak żad­ną sztu­ką w koń­cu dostar­czyć opro­gra­mo­wa­nie”. Sztuką jest to zro­bić zgod­nie z obiet­ni­cą daną pierw­sze­go dnia pro­jek­tu, a z wła­sne­go wie­lo­let­nie­go doświad­cze­nia wiem, że to moż­li­we. Sztuką jest tak­że to, by dal­szy roz­wój i utrzy­ma­nie nie były naj­droż­szym pro­jek­tem świata.

Szanowni pań­stwo: pod­pi­su­jąc z dostaw­cą opro­gra­mo­wa­nia umo­wę czas i mate­riał”, i zle­ca­jąc temu dostaw­cy tak­że ana­li­zę wyma­gań, kopie­cie sobie grób. 

Za co odpo­wia­da dostaw­ca? Za sta­ran­ne dzia­ła­nie, jed­nak sto­so­wa­nie nie­ade­kwat­nych metod nie jest dzia­ła­niem nie­sta­ran­nym, i dla­te­go w sądach z regu­ły prze­gry­wa­ją zama­wia­ją­cy a nie dostaw­cy opro­gra­mo­wa­nia. Wykazanie sta­ran­ne­go dzia­ła­nia przez dostaw­cę opro­gra­mo­wa­nia jest bar­dzo pro­ste: comie­sięcz­ne opła­co­ne fak­tu­ry za pra­cę” dostaw­cy opro­gra­mo­wa­nia są tak napraw­dę uzna­niem jego sta­ran­ne­go dzia­ła­nia przez zama­wia­ją­ce­go. Pozostaje tu jedy­nie kwe­stia ety­ki dostaw­cy, ale to temat na osob­ne opracowanie. 

Tak więc podej­mu­jąc decy­zję o wdro­że­niu pomy­śl­cie Państwo o ryzyku:

ryzyko, popper, decyzje
Karl Popper Ryzyko i decyzje

Kontynuacja wąt­ku: Myślenie życze­nio­we.…

Źródła

Wiegers, K. E., & Beatty, J. (2013). Software requ­ire­ments (Third edi­tion). Microsoft Press, s divi­sion of Microsoft Corporation.
Wolak, G. J. (2019). Umowa o dzie­ło jako zobo­wią­za­nie rezul­ta­tu. https://​doi​.org/​1​0​.​3​4​6​9​7​/​2​451 – 0807-SP-2019 – 1‑006
Larman, C. (2005). Applying UML and pat­terns: an intro­duc­tion to object-orien­ted ana­ly­sis and design and ite­ra­ti­ve deve­lop­ment (3rd ed). Prentice Hall PTR, c2005.
Agaronian, A., Freyer, C. W. S., Bierbooms, C. G., Hoeijmakers, T. P. H., Jansen, T., Kafoe, T., Makantasis, I., Mankevic, K., Sinx, R. D., & Smits, I. M. (2019). Software Requirements Document. 133.
Šenkýř, D., & Kroha, P. (2019). Problem of Incompleteness in Textual Requirements Specification: Proceedings of the 14th International Conference on Software Technologies, 323 – 330. https://​doi​.org/​1​0​.​5​2​2​0​/​0​0​0​7​9​7​8​0​0​3​2​3​0​330
Ackoff, R. L., Magidson, J., Addison, H. J., & Ehrlich, A. (2007). Projektowanie ide­ału: kształ­to­wa­nie przy­szło­ści orga­ni­za­cji. Wyższa Szkoła Przedsiębiorczości i Zarządzania im. Leona Koźmińskiego : Wydawnictwa Akademickie i Profesjonalne.
Dennis, A., Wixom, B. H., & Roth, R. M. (2012). Systems ana­ly­sis and design (5th ed). John Wiley.

Od docflow do workflow, czyli o skutecznym modelowaniu i czynnikach warunkujących sukces wdrożenia

Od lat nie cich­nie dys­ku­sja na temat prze­pły­wu pra­cy i doku­men­tów oraz zarzą­dza­nia pro­ce­sa­mi biz­ne­so­wy­mi zacho­dzą­cy­mi w fir­mach. Nierzadko wie­le pojęć z tego zakre­su sto­su­je­my błęd­nie, dla­te­go war­to usys­te­ma­ty­zo­wać sobie wie­dzę o nich, wska­zać róż­ni­ce mię­dzy nimi i osta­tecz­nie odpo­wie­dzieć na pyta­nie, czy opro­gra­mo­wa­nia wspo­ma­ga­ją­ce ten obszar moż­na z suk­ce­sem wdro­żyć we wszyst­kich przed­się­bior­stwach. To klu­czo­we, jeśli chce­my sku­tecz­nie zarzą­dzać pro­ce­sa­mi w firmie.

Dokumenty i procesy

Demagogią jest twier­dze­nie, że koszt prze­cho­wy­wa­nia doku­men­tu elek­tro­nicz­ne­go to tyl­ko kil­ka mikro­me­trów dys­ku i koszt tego miniob­sza­ru. Prawdziwym kosz­tem prze­cho­wa­nia takie­go doku­men­tu jest bowiem koszt całej infra­struk­tu­ry wraz z jej zabez­pie­cze­niem. Gdyby było ina­czej, każ­dy z nas miał­by już w fir­mie elek­tro­nicz­ne superarchiwum.

Co wię­cej, obieg doku­men­tów to nie ? jak się myl­nie sądzi ? zarzą­dza­nie pro­ce­sa­mi. Dokumenty są tyl­ko jed­nym z ele­men­tów mapy pro­ce­sów orga­ni­za­cji, a zatem sys­te­my obie­gu doku­men­tów to wspar­cie zarzą­dza­nia zorien­to­wa­ne­go na pro­ce­sy, nie zaś sys­te­my zarzą­dza­nia pro­ce­sa­mi biznesowymi.

Wielu utoż­sa­mia poję­cie obie­gu doku­men­tów, obie­gu infor­ma­cji z pro­ce­sa­mi biz­ne­so­wy­mi i ich zarzą­dza­niem. Jest to moim zda­niem klu­czo­we nie­po­ro­zu­mie­nie, żeby nie powie­dzieć błąd.

Proces biz­ne­so­wy to dzia­ła­nie cha­rak­te­ry­zu­ją­ce się przede wszyst­kim wno­sze­niem war­to­ści doda­nej i posia­da­nie papie­ru czy doku­men­tu w wer­sji elek­tro­nicz­nej nie ma tu nic do rze­czy. Na mapie pro­ce­sów biz­ne­so­wych doku­men­ty i ich kolej­ne wer­sje sta­no­wią pro­duk­ty pro­ce­sów (nie­je­dy­ne zresz­tą). Proces pole­ga­ją­cy na pod­ję­ciu decy­zji to pra­ca czło­wie­ka nio­są­ca dużą war­tość doda­ną, ale nie obieg doku­men­tów będą­cych śla­da­mi po nie­któ­rych tyl­ko pro­ce­sach w fir­mie. Dla przy­kła­du pro­ce­sem jest wypro­du­ko­wa­nie pod­ze­spo­łu i nie ma to nic wspól­ne­go z sys­te­mem obie­gu doku­men­tów. Gdzieś po dro­dze powsta­nie doku­men­ta­cja tech­nicz­na, ale jeden z ele­men­tów sys­te­mu zarzą­dza­nia pro­ce­sa­mi w fir­mie, jego podsystem.

Systemy obie­gu doku­men­tów i obie­gu infor­ma­cji są waż­ny­mi ele­men­ta­mi w każ­dej orga­ni­za­cji, ale są to tyl­ko pro­duk­ty i to nie wszyst­kie na mapie pro­ce­sów biz­ne­so­wych fir­my, dla­te­go wła­śnie nazy­wa­nie sys­te­mów, zali­cza­nych do kla­sy work­flow, sys­te­ma­mi BPM (Business Process Management) uwa­żam za poważ­ne nadużycie.

Kolejną śle­pą ulicz­ką jest trak­to­wa­nie sys­te­mów kla­sy work­flow jako narzę­dzi ści­słej kon­tro­li poczy­nań pra­cow­ni­ków. Nie znam przy­pad­ku wdro­że­nia sys­te­mu zakoń­czo­ne­go suk­ce­sem, któ­re­go głów­nym celem było kon­tro­lo­wa­nie pra­cow­ni­ków (np. cza­su ich pra­cy). Znacznie sku­tecz­niej­sze są sys­te­my infor­ma­tycz­ne zapro­jek­to­wa­ne tak, by poma­ga­ły pra­cow­ni­kom osią­gać ich cele. Takie nie­ja­ko wdra­ża­ją się same. Z kolei sys­te­my kon­tro­li i restryk­cji, nawet jeże­li uda­je się je wdro­żyć, są bar­dzo kosz­tow­ne i czę­sto boj­ko­to­wa­ne przez pracowników.

Jednak coś w tym jest, że obieg doku­men­tów (infor­ma­cji) cza­sa­mi sta­je się mode­lem procesów.

Kiedy i co modelować

Jeżeli cze­goś nie moż­na nary­so­wać, to zna­czy, że to nie ist­nie­je! To stwier­dze­nie odno­si się do isto­ty pro­ce­sów i zarzą­dza­nia nimi. Aby czym­kol­wiek zarzą­dzać, nale­ży to naj­pierw opi­sać, czy­li udo­ku­men­to­wać. Takim opi­sem będzie mapa pro­ce­sów biz­ne­so­wych, któ­ra sta­no­wi model fir­my z per­spek­ty­wy jej funk­cjo­no­wa­nia. Jak ją pra­wi­dło­wo wykonać?

Model fir­my powi­nien w spo­sób jasny i zro­zu­mia­ły dla jej pra­cow­ni­ków opi­sy­wać fir­mę, jej cel ryn­ko­wy oraz wszel­kie jej aktyw­no­ści wewnętrz­ne i zewnętrz­ne. Jest on nie­zbęd­ny do prze­wi­dy­wa­nia zacho­wań fir­my, ale tak­że do przy­go­to­wa­nia jej na wdro­że­nia sys­te­mów informacyjnych.

Cała publi­ka­cja w ostat­nim nume­rze Informacja Zarządcza 18/2019

Czy wdrożenie zawsze wymaga reorganizacji?

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:

(źr. na podst.: Bolesław Szafrański, Wydział Cybernetyki, Wojskowa Akademia Techniczna, Architektura kor­po­ra­cyj­na ? pro­ble­my nie tyl­ko pojęciowe”)

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… 

Dokumenty czy niedokumenty.… czyli zarządzanie informacją i jej standaryzacja

Nie raz tu już pisa­łem, że ana­li­zy i pro­jek­ty zwią­za­ne bez­po­śred­nio z wyma­ga­nia­mi na opro­gra­mo­wa­nie to tyl­ko” ok. 3/4 moich pro­jek­tów. Jednak nawet, jeże­li pro­jekt nie jest nazwa­ny” infor­ma­tycz­nym, to zawsze jest infor­ma­cyj­ny” w rozu­mie­niu zarzą­dza­nia infor­ma­cją (tak­że zarzą­dza­nie wie­dzą). Tym razem kil­ka słów na temat doku­men­tów. Stanowią one pod­sta­wo­wą jed­nost­kę infor­ma­cji (i danych) w każ­dym sys­te­mie biz­ne­so­wym. Są tak­że źró­dłem danych dla hur­tow­ni danych.

Wstęp

Wiele pro­jek­tów zwią­za­nych z doku­men­ta­mi jest spro­wa­dza­nych do problemu:

jakie mamy doku­men­ty i co z nimi robimy?”

Zaniedbuje się bar­dzo waż­ny ele­ment: odpo­wiedź na pytanie:

czy nasze obec­ne doku­men­ty, ich ilość i treść, są właściwe?”

Otóż prak­ty­ka poka­zu­je, że dość czę­sto pro­ble­mem są doku­men­ty opra­co­wa­ne kie­dyś tam”. Inicjuje się pro­jekt z róż­ny­mi wyma­ga­nia­mi ale niko­mu nie przy­cho­dzi do gło­wy by zasta­no­wić się nad tym czy obec­ne doku­men­ty, w ich obec­nej posta­ci, są dobrym pomy­słem i powin­ny takie pozostać.

Czy doku­men­ty są nie­zmie­nial­nym bytem? Nie, nie są.

Każda orga­ni­za­cja obra­ca skoń­czo­ną licz­bą doku­men­tów, są to róż­ne­go rodza­ju for­mu­la­rze, w naj­ogól­niej­szym przy­pad­ku doku­men­tem jest po pro­stu każ­da treść, tak­że zwy­kła pro­za” np. notat­ka. Warto jed­nak zwró­cić uwa­gę na to, że nawet ona ma pew­ną struk­tu­rę: np. auto­ra, adre­sa­ta, temat, datę i treść. Dokumenty to okre­ślo­na kon­kret­na treść utrwa­lo­na z okre­ślo­ne­go powo­du (w prze­ciw­nym wypad­ku doku­ment nie by powstał). Osiem lat temu opi­sy­wa­łem kwe­stie róż­ni­cy mię­dzy doku­men­tem, wie­dzą, infor­ma­cją a danymi:

Czy baza danych to wie­dza?[?] Model jaw­nie poka­zu­je, że bez­po­śred­ni zwią­zek z Bazą Danych mają Dane. Dalej już są wyłącz­nie nie­ma­te­rial­ne poję­cia czym więc jest Zarządzanie Wiedzą (mil­czą­co zakła­dam, że zarzą­dzać moż­na czymś mate­rial­nym)? Jest to ?prze­cho­wy­wa­nie danych jed­no­znacz­nie zro­zu­mia­łych, opi­su­ją­cych okre­ślo­ne i ogra­ni­czo­ne licz­bą fak­ty inter­pre­to­wa­ne jako poj­mo­wal­na przez adre­sa­ta infor­ma­cja?. (Źródło: Potrzeby infor­ma­cyj­ne fir­my ? Zarządzanie wie­dzą | Jarosław Żeliński IT-Consulting)

Dzisiaj co nie­co o tym, dla­cze­go od cza­su do cza­su war­to się pochy­lić nad wzo­ra­mi doku­men­tów i czy cza­sem nie zmie­nić nie­co podej­ścia do nich.

Dokumenty w organizacji

Swego cza­su u jed­ne­go z moich klien­tów odkry­łem” cie­ka­wy doku­ment. Była to fak­tu­ra z doda­nym zesta­wem danych odpo­wia­da­ją­cym doku­men­tom WZ oraz ana­lo­gicz­nym zesta­wie­niem doty­czą­cym opa­ko­wań zwrot­nych. Ten super doku­ment był pomy­słem z przed wie­lu lat oso­by odpo­wie­dzial­nej za wyda­wa­nie i zarzą­dza­nie opa­ko­wa­nia­mi zwrot­ny­mi w maga­zy­nie. Uzasadnienie brzmia­ło: na jed­nym doku­men­cie będą wszyst­kie infor­ma­cje zwią­za­ne z kon­kret­ną sprze­da­żą i dosta­wą. Brzmi ład­nie jed­nak: prak­tycz­nie każ­dy kto miał z tym doku­men­tem do czy­nie­nia, w toku obsłu­gi zamó­wie­nia, dosta­wał nad­mia­ro­we dane, nie raz nie­jaw­ne (nie­któ­re) ceny, szcze­gó­ły zawar­to­ści paczek, war­tość towa­ru (po co ta wie­dza kie­row­com), ilo­ści i sal­da (tak) opa­ko­wań zwrot­nych (jak się oka­za­ło doku­ment nie raz poma­gał w nad­uży­ciach, nie­któ­rzy pra­cow­ni­cy zaś zama­zy­wa­li cza­sa­mi część danych prze­ka­zu­jąc doku­ment dalej, by ich nie ujaw­niać). Ale naj­więk­szym pro­ble­mem było to, że ta oso­ba uczy­ni­ła z tego wzo­ru doku­men­tu wyma­ga­nie wobec opro­gra­mo­wa­nia ERP. Jak się nie trud­no domy­śleć, żaden ryn­ko­wy sys­tem nie ma takie­go doku­men­tu stan­dar­do­wo, dostaw­ca ERP uznał to wyma­ga­nie bez zastrze­żeń, co przy­czy­ni­ło się do wie­lu mody­fi­ka­cji opro­gra­mo­wa­nia tak­że w innych miej­scach, znacz­ne­go wzro­stu budże­tu (współ­dzie­lo­na baza danych pro­pa­gu­je zmia­ny prak­tycz­nie na całą apli­ka­cję). Nie będę tu opi­sy­wał dal­szych losów tego wzo­ru doku­men­tu bo celem moim było jedy­nie poka­za­nie pro­ble­mu na real­nym przykładzie.

Każdy pro­jekt, czy to wdro­że­nie nowych zasad zarzą­dza­nia czy nowe­go opro­gra­mo­wa­nia, zwią­za­ny z zarzą­dza­niem orga­ni­za­cją, to (powi­nien być) tak­że co naj­mniej prze­gląd doku­men­tów i ich obie­gu. Kluczowym ele­men­tem tego prze­glą­du powin­na być ana­li­za tre­ści tych doku­men­tów, ich opty­mal­ność, nie tyl­ko obie­gu ale tak­że tre­ści i jej struk­tu­ry. Owszem, wie­le doku­men­tów ma narzu­co­ną struk­tu­rę np. w odpo­wied­niej usta­wie, jed­nak są to mini­mal­ne zawar­to­ści (np. fak­tu­ra) nie ma zaka­zu uzu­peł­nie­nia tej struk­tu­ry i np. doda­nia do fak­tu­ry nume­ru zamó­wie­nia, z któ­rym jest związana.

Ogólnie moż­na okre­ślić pew­ne pra­wi­dło­wo­ści: jeże­li doku­men­ty są prze­cią­ża­ne tre­ścią, czy­li idzie­my w kie­run­ku małej ilo­ści doku­men­tów zawie­ra­ją­cych dużo danych, rośnie zło­żo­ność reguł pra­cy z takim doku­men­tem. Jeżeli zaś idzie­my w kie­run­ku doku­men­tów bar­dzo pro­stych”, rośnie ilość ich typów i rośnie licz­ba reguł koja­rzą­cych te doku­men­ty ze sobą w celu ich uży­cia. Ogólnie obra­zu­je to poniż­szy diagram:

Liczba dokumentów vs ilośc treści na nich

Tak więc skraj­nym roz­wią­za­niem będzie stwo­rze­nie jed­ne­go doku­men­tu, na któ­rym będą wszyst­kie infor­ma­cje np. zwią­za­ne z danym zamó­wie­niem. Drugą skraj­no­ścią jest podzie­le­nie infor­ma­cji na odręb­ne małe nie­po­dziel­ne już grup­ki, jak to ma miej­sce w znor­ma­li­zo­wa­nych rela­cyj­nych bazach danych. Jeżeli mega­do­ku­men­ty to raczej bar­dzo rzad­kie zja­wi­sko, to przy­pa­dek dru­gi jest dość powszech­ny. To co nazy­wa­my czę­sto doku­men­tem to tu tak na praw­dę nie­ist­nie­ją­cy byt w rela­cyj­nej bazie danych, gene­ro­wa­ny ad-hoc w locie” z sze­re­gu roz­drob­nio­nych tablic danych. Innymi sło­wy nie są to sta­łe struk­tu­ry” a pew­na okre­ślo­na zło­żo­na logi­ka, two­rzą­ca z pro­stych danych pobie­ra­nych z tablic, kon­kret­ne zesta­wy infor­ma­cji np. fak­tu­ry (to dla­te­go czę­sto w języ­ku dostaw­cy” fak­tu­ra to raport a nie doku­ment!). Ta zło­żo­na logi­ka reali­zo­wa­na jest (wyko­ny­wa­na w pamię­ci kom­pu­te­ra) za każ­dym razem gdy odwo­ła­my się do takie­go dokumentu.

Optymalna sytu­acja to rodzaj kom­pro­mi­su pomię­dzy zło­żo­no­ścią logi­ki two­rze­nia i korzy­sta­nia z doku­men­tu a jego zawar­to­ścią. Na powyż­szym dia­gra­mie jest to obszar sta­no­wią­cy oko­li­ce mini­mum krzy­wej opi­su­ją­cej zależ­ność pomię­dzy licz­bą doku­men­tów a zło­żo­no­ścią ope­ro­wa­nia nimi. Nie ma pro­stej regu­ły na opra­co­wy­wa­nie i opty­ma­li­za­cje tre­ści i licz­by doku­men­tów jed­nak są pew­ne spraw­dzo­ne dobre prak­ty­ki, a mia­no­wi­cie jeden doku­ment, o okre­ślo­nej struk­tu­rze, powi­nien zawie­rać dane o okre­ślo­nym zda­rze­niu w okre­ślo­nym kon­tek­ście [powsta­je teraz publi­ka­cja na ten temat, wyda­je się moż­na to jed­nak zde­fi­nio­wać, przyp auto­ra 2019]. Dokumenty te, podob­nie jak fak­ty któ­re doku­men­tu­ją, mogą mieć każ­dy wła­sny i róż­ny od innych cykl życia, dla­te­go czę­sto bywa bar­dzo szko­dli­we roz­dzie­la­nie” ich na pola bazy danych i pozby­cie się redundancji.

Przykładem mogą być: zamó­wie­nie jako udo­ku­men­to­wa­nie fak­tu zawar­cia umo­wy na dosta­wę, fak­tu­ra jako udo­ku­men­to­wa­nie fak­tu sprze­da­ży (prze­nie­sie­nia wła­sno­ści) oraz doku­ment WZ doku­men­tu­ją­cy fakt wyda­nia z maga­zy­nu okre­ślo­nych pro­duk­tów. Bardzo czę­sto spe­cy­fi­ka­cja tego co wyda­no z maga­zy­nu nie jest toż­sa­ma z tre­ścią fak­tu­ry (sprze­da­no odku­rzacz a wyda­no odku­rzacz i zapa­so­we wor­ki), na zamó­wie­niu mógł być wyszcze­gól­nio­ny odku­rzacz, wor­ki oraz wyma­ga­ne koń­ców­ki (któ­re są np. u pro­du­cen­ta pako­wa­ne w stan­dar­dzie więc nie ma ich ani na fak­tu­rze ani na WZ). Dlatego ma głę­bo­ki sens by te doku­men­ty były jed­nak osob­ny­mi doku­men­ta­mi” a nie zacho­wy­wa­ny­mi w bazie danych dany­mi jako odręb­ne pola pozba­wio­ne redun­dan­cji, wyma­ga­ją­ce skom­pli­ko­wa­nej logi­ki (pole­ce­nia SQL) by je (te doku­men­ty”) poka­zać na ekra­nie czy wydrukować.

To dość try­wial­ny przy­kład, bo opi­sa­ne doku­men­ty są wyma­ga­ne prze­pi­sa­mi jako dowo­dy księ­go­we, jed­nak każ­da więk­sza orga­ni­za­cja ma swo­je wewnętrz­ne doku­men­ty, na któ­rych ilość i treść ma peł­ny wpływ. Po dru­gie nawet te doku­men­ty są czę­sto wła­śnie zapi­sy­wa­ne w rela­cyj­nych bazach danych jako roz­pro­szo­ne po małych tabe­lach dane, wyma­ga­ją­ce skom­pli­ko­wa­nych ope­ra­cji łącze­nia w jeden doku­ment”, każ­do­ra­zo­wo przy pró­bie jego uży­cia. Tu zacho­dzi bar­dzo duże ryzy­ko, że postać i treść takie­go doku­men­tu ule­gnie zmia­nie np. po reor­ga­ni­za­cji bazy danych. Takich doku­men­tów” nie da się (w tej posta­ci) pod­pi­sać elek­tro­nicz­nie, bo one po pro­tu fizycz­nie na praw­dę nie istnieją.

A jak ina­czej? Nie ma żad­ne­go pro­ble­mu by dowol­ny doku­ment sta­no­wił sobą jed­no­li­ty byt np. zestaw danych w for­ma­cie XML, sko­ja­rzo­ny ewen­tu­al­nie ze swo­ją posta­cią goto­wą do dru­ku albo np. plik PDF sko­ja­rzo­ny z meta­da­ny­mi opi­su­ją­cy­mi go (wybór jest na praw­dę duży). Nie nale­ży zapo­mi­nać, że poza doku­men­ta­mi, któ­re są two­rzo­ne w orga­ni­za­cji ope­ru­je­my doku­men­ta­mi obcy­mi, otrzy­ma­ny­mi z zewnątrz i wypa­da­ło by mieć taki doku­ment w posta­ci takiej jaką prze­słał nam ich twór­ca. Owszem poja­wia się redun­dan­cja danych ale ona nie sta­no­wi sobą nic złe­go. Ogromną korzy­ścią takie­go podej­ścia jest roz­wią­za­nie pro­ble­mu pole­ga­ją­ce­go na nie­moż­no­ści roz­dzie­le­nia doku­men­tów” i logi­ki ope­ro­wa­nia nimi jeże­li są zapi­sa­ne w posta­ci odręb­nych pól w rela­cyj­nej bazie danych. Np. sta­je się nie­moż­li­we pozo­sta­wie­nie fak­tur i wynie­sie­nie doku­men­tów maga­zy­no­wych do odręb­ne­go sys­te­mu (w tym zmia­na ich struk­tu­ry) co ma miej­sce nie raz przy wdra­ża­niu sys­te­mów WMS (sys­te­my logi­stycz­no-maga­zy­no­we). Takie ope­ra­cji pra­wie żaden duży zin­te­gro­wa­ny ERP nie wytrzy­ma (usły­szy­my raczej, że my dosto­su­je­my do Państwa potrzeb nas moduł magazynowy…).

Podejście takie ma tak­że inna cie­ka­wą zale­tę: jeże­li udo­ku­men­tu­je­my osob­no struk­tu­ry doku­men­tów i logi­kę ope­ro­wa­nia nimi (tak­że ich two­rze­nia), to otrzy­ma­my obiek­to­wy model orga­ni­za­cji: model poka­zu­ją­cy wza­jem­ną współ­pra­cę obiek­tów biz­ne­so­wych (doku­men­tów) odpo­wie­dzial­nych za prze­cho­wy­wa­nie infor­ma­cji, obiek­tów odpo­wie­dzial­nych za reje­stro­wa­nie tych infor­ma­cji, obiek­tów mają­cych wie­dzę jak ope­ro­wać tymi infor­ma­cja­mi, obiek­tów udo­stęp­nia­ją­cych to wszyst­ko zgod­nie z okre­ślo­ną logi­ką. Poniżej obiek­to­wy model na któ­rym od pra­wej mamy: doku­men­ty z ich tre­ścią oraz logi­kę ich two­rze­nia i udo­stęp­nia­nia (repo­zy­to­ria czy­li kuwet­ki na doku­men­ty), logi­kę korzy­sta­nia z infor­ma­cji w repo­zy­to­riach, tak­że ich wza­jem­ne­go koja­rze­nia (samo­dziel­ne usłu­gi) oraz logi­kę dostę­pu do tego sys­te­mu (reali­za­cja sce­na­riu­szy przy­pad­ków uży­cia). Jeżeli w toku ana­li­zy uzna­my, że jakieś ele­men­ty tej logi­ki to zada­nia pod­da­ją­ce się w 100% algo­ryt­mi­za­cji, to poniż­szy model jest jed­no­cze­śnie mode­lem logi­ki apli­ka­cji i nazy­wa­my go Modelem Dziedziny Systemu. Nie jest to abso­lut­nie żad­na baza danych, poniż­sze repo­zy­to­ria nicze­go nie współ­dzie­lą (moż­na je w dowol­nym momen­cie zamie­niać na inne bez kon­se­kwen­cji dla resz­ty systemu).

Obiektowy model dziedziny Zasada SOLID

Model ten powstał z uży­ciem blo­ków funk­cjo­nal­nych wzor­ca BCE (opi­sa­łem go tu: Wzorzec ana­li­tycz­ny Boundary Control Entity). Dla wyja­śnie­nia: powyż­szy dia­gram to w peł­ni popraw­ny Model dzie­dzi­ny wyko­na­ny z uży­ciem dia­gra­mu klas UML, kla­sy mają ste­reo­ty­py boun­da­ry, con­trol i enti­ty (powy­żej od lewej do pra­wej), ste­reo­ty­py te są repre­zen­to­wa­ne sym­bo­la­mi opi­sa­ny­mi (iko­na­mi) w BCE. (Źródło: Krzywe i kosz­ty? archi­tek­tu­ry | | Jarosław Żeliński IT-Consulting

Prawie zawsze obser­wu­ję, że pod­sta­wo­wym domyśl­nym zało­że­niem wdro­żeń sys­te­mów wspo­ma­ga­ją­cych zarzą­dza­nie, jest uzna­nie a prio­ri nie­zmien­no­ści struk­tu­ry i wzo­rów dokumentów. 

Z doświad­cze­nia mogę powie­dzieć, że ana­li­za i opty­ma­li­za­cja tre­ści doku­men­tów wewnętrz­nych może przy­nieść bar­dzo duże korzy­ści prze­kła­da­ją­ce się na duży wzrost wewnętrz­nej efek­tyw­no­ści i jako­ści pra­cy, a w przy­pad­ku wdro­żeń opro­gra­mo­wa­nia wspo­ma­ga­ją­ce­go zarzą­dza­nie, pozwa­la nie raz cał­ko­wi­cie unik­nąć bar­dzo kosz­tow­nych i ryzy­kow­nych kasto­mi­za­cji. Zaryzykuje tezę, że kil­ka pro­jek­tów w ten spo­sób wręcz uratowałem… 

ECM i EOD czyli od mody do realiów

Obydwa te, spo­ty­ka­ne czę­sto w pra­sie, skró­ty mają wie­le wspól­ne­go: ozna­cza­ją apli­ka­cje zarzą­dza­ją­ce obie­giem infor­ma­cji i jej maga­zy­no­wa­niem (ECM – Electronic Content Management czy­li zarzą­dza­nie tre­ścią w posta­ci elek­tro­nicz­nej oraz EOD – Elektroniczny Obieg Dokumentów). Cechą zawar­tą nie wprost” w tych nazwach jest zarzą­dza­nie tak­że skła­do­wa­niem i prze­pły­wem tej infor­ma­cji. Osiem lat temu pisa­łem o kwe­stiach poję­cio­wych (czym jest wie­dza, jej prze­twa­rza­nie, czym są dane):

Problematyka infor­ma­cji w fir­mach, jej kolek­cjo­no­wa­nia i prze­twa­rza­nia jest czę­stym tema­tem arty­ku­łów w pra­sie spe­cja­li­stycz­nej jak i opi­sem zakre­sów pro­jek­tów IT. Termin ten jest jed­nak nie raz nad­uży­wa­ny. W pra­sie moż­na pozwo­lić sobie na pew­ną dowol­ność jego inter­pre­ta­cji jed­nak w opi­sie zakre­su pro­jek­tu ana­li­tycz­ne­go pozy­cja o nazwie ?Zdefiniowanie potrzeb infor­ma­cyj­nych fir­my? może rodzić poważ­ne kło­po­ty z odbio­rem tej czę­ści pro­jek­tu gdyż tu na dowol­ność inter­pre­ta­cji nie powin­no być miej­sca. (Źródło: Zarządzanie Wiedzą | Jarosław Żeliński IT-Consulting)

Niedawno, 26 stycz­nia 2016, mia­łem refe­rat na kon­fe­ren­cji pod hasłem Business Process Management:

W trak­cie refe­ra­tu zwró­ci­łem uwa­gę na to, że to co czę­sto nazy­wa­my zarzą­dza­niem pro­ce­sa­mi (popu­lar­ny skrót [[BPM]]) biz­ne­so­wy­mi, tak na praw­dę jest zarzą­dza­niem prze­pły­wem pra­cy, zarzą­dza­niem infor­ma­cją i nad­zo­ro­wa­niem tych aktyw­no­ści. Tu zwró­cę uwa­gę na to, że prze­pływ pra­cy odwzo­ro­wy­wa­ny jest w apli­ka­cji jako ciąg rapor­tów i notatek:

prze­ło­żo­ny dowia­du­je się o wyko­pa­niu rowu nie z wła­snej obser­wa­cji a z rapor­tu swo­je­go podwładnego 

dla­te­go opro­gra­mo­wa­nie może ope­ro­wać wyłącz­nie udo­ku­men­to­wa­ny­mi fak­ta­mi a nie zja­wi­ska­mi w real­nym świe­cie: to są zapi­sy jaki­mi zarzą­dza opro­gra­mo­wa­nie zarzą­dza­ją­ce sze­ro­ko poję­tą tre­ścią. Tak więc

zarzą­dza­nie pro­ce­sa­mi biz­ne­so­wy­mi to nic inne­go jak zbie­ra­nie infor­ma­cji, prze­twa­rza­nie ich i decy­do­wa­nie o kolej­nych pra­cach do wyko­na­nia, infor­mu­jąc o tym wyko­naw­ców tych kolej­nych prac.

Aplikacja wspie­ra­ją­ca prze­pływ pra­cy to opro­gra­mo­wa­nie, któ­re pozwa­la na two­rze­nie for­mu­la­rzy (i zasad wery­fi­ka­cji ich popraw­no­ści) spe­cy­ficz­nych dla każ­de­go zada­nia, reguł biz­ne­so­wych narzu­ca­ją­cych opcjo­nal­ność i kolej­ność reali­za­cji zadań (aktyw­no­ści), kate­go­ry­zo­wa­nie tre­ści i zadań, udo­stęp­nia­nie powsta­łych treści:

ECM EOD Przypadki Użycia

Powyższy dia­gram przy­pad­ków uży­cia moż­na w zasa­dzie uznać za refe­ren­cyj­ny”, każ­da apli­ka­cja tego typu tak mogła by wyglą­dać, czy to wystar­czy dostaw­cy opro­gra­mo­wa­nia? Nie, bo cała wie­dza o kon­kret­nym wdro­że­niu tkwi w szcze­gó­łach. Gdzie one są? Pisałem o tym pra­wie rok temu:

Tu war­to na począ­tek wró­cić do kla­sy­fi­ka­cji wyma­gań. W arty­ku­le Inżynieria wyma­gań opi­sa­łem trzy ich rodza­je: (1) funk­cjo­nal­ne czy­li usłu­gi apli­ka­cji (przy­pad­ki uży­cia tej apli­ka­cji), (2) poza-funk­cjo­nal­ne czy­li cechy jako­ścio­we, (3) dzie­dzi­no­we czy­li logi­ka biz­ne­so­wa. I teraz bar­dzo waż­na rzecz: któ­re ele­men­ty archi­tek­tu­ry opro­gra­mo­wa­nia, za reali­za­cję któ­rych wyma­gań odpo­wia­da­ją? (Źródło: Gdzie są te cho­ler­ne szcze­gó­ły | | Jarosław Żeliński IT-Consulting)

Jak widać, klucz tkwi w mode­lu dzie­dzi­ny sys­te­mu czy­li w spe­cy­fi­ce bran­ży, kon­kret­nej fir­my lub orga­ni­za­cji. Powyższe przy­pad­ki uży­cia, jak wyżej, to opis dowol­ne­go ECM/EOD”. Referencyjna archi­tek­tu­ra takie­go sys­te­mu mogła by mieć taką postać:

EOD BPM Architektura referencyjna

Dlaczego tak? Komponent zarzą­dza­ją­cy pro­ce­sa­mi odpo­wia­da za logi­kę kolej­no­ści prze­twa­rza­nia tre­ści. Repozytorium odpo­wia­da za zacho­wy­wa­nie i udo­stęp­nia­nie tre­ści. Dodano tu kom­po­nent Filesystem, gdyż oso­bi­ście jestem zwo­len­ni­kiem podej­ścia, w któ­rym doku­men­ty elek­tro­nicz­ne są skła­do­wa­ne nie w bazie danych (tak zwa­ne BLOB) a na dys­kach, a logi­ka zarzą­dza­nia nimi to odręb­ne opro­gra­mo­wa­nie (patrz euro­pejk­sie zale­ce­nia Moreq). Dzięki temu utra­ta lub zmian apli­ka­cji (i bazy danych) nie powo­du­je utra­ty zasobów.

Na czym więc pole­ga ana­li­za biz­ne­so­wa przed wdro­że­niem EOD/ECM? Czym są tu wyma­ga­nia? Są nimi regu­ły biz­ne­so­we, wzo­ry doku­men­tów i słow­ni­ki pojęć (danych). To tu tkwi naj­więk­sze ryzy­ko wdro­że­nia, klu­czem jest tu zawsze tak zwa­ny model poję­cio­wy. Powyższa archi­tek­tu­ra jest prze­ze mnie trak­to­wa­na jako refe­ren­cyj­na, gdyż gwa­ran­tu­je moż­li­wość odwzo­ro­wa­nia dowol­ne­go sys­te­mu zarzą­dza­nia infor­ma­cją”, taką lub podob­ną zale­ca­ną archi­tek­tu­rę moż­na spo­tkać w wie­lu opra­co­wa­niach na temat ECM.