Jednym z głów­nych pro­ble­mów wie­lu pro­jek­tów ana­li­tycz­nych (i nie tyl­ko) jest komu­ni­ka­cja i doku­men­to­wa­nie działań.

Projekty ana­li­tycz­ne mają to do sie­bie, że opi­su­ją orga­ni­za­cję bene­fi­cjen­ta pro­jek­tu. Tworzenie jej mode­li wyma­ga sprzę­że­nia zwrot­ne­go” bene­fi­cjent-ana­li­tyk. Jednak nie cho­dzi o to, by się codzien­nie spo­ty­kać a o to, by na bie­żą­co konsultować.

Od lat, jako ana­li­tyk, sto­su­ję z powo­dze­niem meto­dę pra­cy pole­ga­ją­cą na stu­dio­wa­niu i ana­li­zie doku­men­tów. Są to twar­de dane o życiu fir­my, nio­są więk­szość wie­dzy o tym co i po co się dzie­je. Praktyka poka­zu­je, że nie szcze­gó­ły powsta­wa­nia tych doku­men­tów są istot­ne (nie licząc eta­pów powsta­wa­nia) na eta­pie mode­lo­wa­nia pro­ce­sów (nie pro­ce­dur, te trze­ba bez­względ­nie oddzie­lać od pro­ce­sów!). Istotne jest zro­zu­mie­nie co i dla­cze­go się dzie­je (albo dla­cze­go się nie dzie­je a powinno…).

Przebieg takie­go pro­jek­tu ana­li­tycz­ne­go, jego szkie­let, wyglą­da jak poni­żej (wywiad to kon­sul­ta­cje a nie spowiedź):

Tu i w każ­dym ina­czej (inna meto­dą) pro­wa­dzo­nym pro­jek­cie, poja­wia się pro­blem, gdy do komu­ni­ka­cji uży­wa­my spo­tkań lub pocz­ty elek­tro­nicz­nej. W przy­pad­ku spo­tkań, ich nad­miar para­li­żu­je orga­ni­za­cję ana­li­zo­wa­ną. W przy­pad­ku spo­tkań i nota­tek po nich poja­wia się pro­blem gdzie jest aktu­al­na wer­sja”. Rozwiązaniem jest np. Biuro Projektu, jed­nak to kolej­ny koszt. Z per­spek­ty­wy wiel­ko­ści pro­jek­tów ana­li­tycz­nych, bywa ono nie raz jed­nak pew­nym nad­mia­ro­wym zaso­bem (koszt takie­go biu­ra vs. koszt pro­wa­dzo­nej analizy).

A pocz­ta elek­tro­nicz­na? Po pierw­sze jeże­li po stro­nie bene­fi­cjen­ta pra­cu­je wię­cej niż jed­na oso­ba w zasa­dzie nikt nie ma kom­ple­tu aktu­al­nych doku­men­tów – każ­dy ma tyl­ko listy do sie­bie i przez sie­bie wysła­ne. Po dru­gie brak moż­li­wo­ści spój­ne­go wer­sjo­no­wa­nia doku­men­tów pro­jek­to­wych bar­dzo szyb­ko pro­wa­dzi do utra­ty pano­wa­nia nad doku­men­ta­cją. Po trze­cie zgła­sza­nie uwag do poszcze­gól­nych dia­gra­mów (mode­li) w for­mie doku­men­tów nota­tek, jest prak­tycz­nie nie do wyeg­ze­kwo­wa­nia, a cyklicz­ne spo­tka­nia tyl­ko w tym celu, powo­du­ją szyb­ko rosną­ce kosz­ty spe­cja­li­stów po obu stro­nach i para­liż organizacyjny.

Dokumentów i dia­gra­mów jest dużo, stan­dar­do­wa ścież­ka w tak pro­wa­dzo­nym projekcie:

Najpierw nale­ży zrzu­cić” gdzieś doku­men­ty na eta­pie kolek­cjo­no­wa­nia danych źró­dło­wych. Mogą mieć one swo­je kolej­ne wer­sje. Dalej: powsta­ją dia­gra­my – mode­le pro­ce­sów, trze­ba je na bie­żą­co śle­dzić i wery­fi­ko­wać. Dalej mamy mode­le dzie­dzi­ny sys­te­mu, tu użyt­kow­nik biz­ne­so­wy ma mniej­szy udział, jeże­li zama­wia­ją­cym jest fir­ma dostar­cza­ją­ca opro­gra­mo­wa­nie, jest czy­tel­ni­kiem całej i tej części.

W zasa­dzie mamy tyl­ko jeden spo­sób na sku­tecz­nie (czy­li nie gene­ru­ją­ce nad­mier­nej pra­co­chłon­no­ści i ryzy­ka): auto­ma­ty­za­cja i sys­tem pra­cy gru­po­wej: wor­flow. Powyższy ite­ra­cyj­ny pro­ces ana­li­tycz­ny moż­na wes­przeć narzę­dziem, które:

  1. zarzą­dza pli­kiem pro­jek­tu pakie­tu CASE (plik z modelami),
  2. zarzą­dza inny­mi pli­ka­mi, sko­ja­rzo­ny­mi doku­men­ta­mi pro­jek­to­wy­mi: notat­ki, pli­ki doku­men­ta­cji ana­li­zo­wa­nej, doku­men­ty pdf, inne,
  3. nad­zo­ru­je publi­ka­cję dia­gra­mów i komen­ta­rze do nich,
  4. auto­ma­tycz­nie wer­sjo­nu­je wszyst­kie pliki,
  5. pozwa­la to robić w dowol­nej gru­pie osób.
  6. pozwa­la śle­dzić pro­ces: powsta­nie tre­ści, oce­na tre­ści, korek­ta i ulep­sze­nie, zatwier­dze­nie (dzia­ła­nie ite­ra­cyj­ne aż do skutku).
Poniżej sche­mat komu­ni­ka­cji w tak pro­wa­dzo­nym projekcie:

Do tego nale­ży dorzu­cić zarzą­dza­nie wyma­ga­nia­mi, har­mo­no­gra­mem, bie­żą­cy­mi zada­nia­mi i spra­wa­mi. Jak to dzia­ła? Potrzebne są narzę­dzia: repo­zy­to­rium pli­ków z moż­li­wo­ścią wymu­sze­nia wer­sjo­no­wa­nia, zin­te­gro­wa­ne narzę­dzie pra­cy gru­po­wej pozwa­la­ją­ce bene­fi­cjen­to­wi na bie­żą­co prze­glą­dać i komen­to­wać (zgła­szać uwa­gi) dia­gra­my, sys­tem wspie­ra­ją­cy zarzą­dza­jąc har­mo­no­gra­mem i sko­ja­rzo­ny­mi z nim zada­nia­mi i doku­men­ta­mi pro­jek­to­wy­mi. Beneficjent powi­nien być odpo­wie­dzial­ny za swo­je tre­ści ale też nie nale­ży go obcią­żać (czas pra­cow­ni­ków bene­fi­cjen­ta) zada­nia­mi zarzą­dza­nia pro­jek­tem (nie licząc czę­ści pro­jek­tu po stro­nie beneficjanta).

Jak to dzia­ła i czy dzia­ła? Wystarczy zawrzeć ze mną umo­wę by się przekonać ;)…

Korzyści dla zama­wia­ją­ce­go analizę:

  1. ludzie pra­cu­ją głów­nie zdal­nie w dogod­nych dla sie­bie porach dnia,
  2. każ­dy ma dostęp do spój­ne­go zaso­bu danych, nikt nicze­go nie traci,
  3. prze­cho­wy­wa­na jest histo­ria postę­pów projektu,
  4. ana­li­tyk zapew­nia kopie zapa­so­we całej dokumentacji,
  5. wia­do­mo kto, co i kie­dy zrobił.

I tyl­ko trze­ba chcieć ten pro­jekt zrealizować 😉

Jarosław Żeliński

Jarosław Żeliński: autor, badacz i praktyk analizy systemowej organizacji: Od roku 1991 roku, nieprzerwanie, realizuje projekty z zakresu analiz i projektowania systemów, dla urzędów, firm i organizacji. Od 1998 roku prowadzi samodzielne studia i prace badawcze z obszaru analizy systemowej i modelowania (modele jako przedmiot badań: ORCID). Od 2005 roku, jako nieetatowy wykładowca akademicki, prowadzi wykłady i laboratoria (ontologie i modelowanie systemów informacyjnych, aktualnie w Wyższej Szkole Informatyki Stosowanej i Zarządzania pod auspicjami Polskiej Akademii Nauk w Warszawie.) Oświadczenia: moje badania i publikacje nie mają finansowania z zewnątrz, jako ich autor deklaruję brak konfliktu interesów. Prawa autorskie: Zgodnie z art. 25 ust. 1 pkt. 1) lit. b) ustawy o prawie autorskim i prawach pokrewnych zastrzegam, że dalsze rozpowszechnianie artykułów publikowanych w niniejszym serwisie jest zabronione bez indywidualnej zgody autora (patrz Polityki Strony).

Dodaj komentarz

Witryna wykorzystuje Akismet, aby ograniczyć spam. Dowiedz się więcej jak przetwarzane są dane komentarzy.