Proszę się dokład­nie zapo­znać z poniż­szą tre­ścią, ten doku­ment opi­su­je stan­dar­do­wy spo­sób komu­ni­ka­cji w każ­dym moim projekcie.

Wprowadzenie

Podstawowym celem komu­ni­ka­cji jest dostar­cza­nie mi mate­ria­łów źró­dło­wych i recen­zo­wa­nie (uwa­gi do tre­ści) powsta­ją­cej lub aktu­ali­zo­wa­nej doku­men­ta­cji ana­li­tycz­no-pro­jek­to­wej: jest nią Analiza Biznesowa i Opis Techniczny Rozwiązania (dalej Specyfikacja). Dostawcą mate­ria­łów źró­dło­wych jest zawsze zespół orga­ni­za­cji ana­li­zo­wa­nej. Na eta­pie wybo­ru dostaw­cy roz­wią­za­nia, i póź­niej na eta­pie reali­za­cji, pyta­nia do tre­ści Specyfikacji zgła­sza tak­że Dostawca roz­wią­za­nia, autor Specyfikacji w odpo­wie­dzi aktu­ali­zu­je tę Specyfikację (usta­la­jąc to tak­że z eks­per­ta­mi opi­sa­nej w niej organizacji). 

Wymiana tre­ści jest w 100% pro­wa­dzo­na pisem­nie. Dokumenty (mate­ria­ły źró­dło­we) przyj­mu­ję wyłącz­nie w nie­edy­to­wal­nym for­ma­cie PDF lub jako wydru­ki oraz jako notat­ki po ewen­tu­al­nych spo­tka­niach (PDF). Przekazywanie mi doku­men­tów w innej for­mie wyma­ga zgo­dy i nie może powo­do­wać dodat­ko­wej pra­co­chłon­no­ści ani wyma­gać insta­la­cji lub dostę­pu do spe­cja­li­stycz­ne­go opro­gra­mo­wa­nia. W razie potrze­by orga­ni­zo­wa­ne są tele- lub video- kon­fe­ren­cje, jed­nak nie zastę­pu­ją one doku­men­to­wej for­my prze­ka­za­nia mi infor­ma­cji, spo­tka­nia słu­żą wyłącz­nie do pro­wa­dze­nia uzgod­nień, wyja­śnień, szkoleń.

Poniżej opis narzę­dzia sto­so­wa­ne­go do komu­ni­ka­cji oraz doku­men­tów jakie nale­ży mi prze­ka­zać i jakie ja przekazuję. 

Narzędzia i metody w projekcie

Podobnie jak wie­lu ana­li­ty­ków na świe­cie, zre­zy­gno­wa­łem z wywia­dów i cyklicz­nych gru­po­wych warsz­ta­tów w loka­li­za­cji klien­ta, na rzecz zdal­nej pra­cy opar­tej na prze­ka­za­nych mi mate­ria­łach (doku­men­tach) a tak­że (patrz: niska efek­tyw­ność spo­tkań i ich ogrom­ne kosz­ty), zaś stan­dar­do­wo zdal­na pra­ca (w tym tele kon­fe­ren­cje) w moich pro­jek­tach to obec­nie 100%. 

Dzięki temu łącz­na pra­co­chłon­ność (szcze­gól­nie po stro­nie kadr zama­wia­ją­ce­go) i koszt pro­jek­tu ana­li­tycz­ne­go, są nawet o 70% niż­sze, w porów­na­niu z cyklicz­ny­mi spo­tka­nia­mi i uży­wa­niem opro­gra­mo­wa­nia biu­ro­we­go (ema­il, edy­tor tek­stu, arkusz kal­ku­la­cyj­ny) do komu­ni­ka­cji i wymia­ny tre­ści! (prze­czy­taj też: Dlaczego nie uży­wam pocz­ty elek­tro­nicz­nej do prze­ka­zy­wa­nia mate­ria­łów).

Jeżeli Zamawiający orga­ni­zu­je spo­tka­nia i warsz­ta­ty są one roz­li­cza­ne jako dodat­ko­we zlecenia. 

Zrezygnowałem tak­że z pro­stych metod opi­so­we­go spe­cy­fi­ko­wa­nia wyma­gań bazu­ją­cych wyłącz­nie na wywia­dach z przy­szły­mi użyt­kow­ni­ka­mi, bo są to meto­dy nie­sku­tecz­ne, tak powsta­ją­ce spe­cy­fi­ka­cje są nie­kom­plet­ne, stwa­rza­ją ogrom­ne ryzy­ko dla pro­jek­tu .

W trak­cie pro­jek­tu nie uży­wam pakie­tów biu­ro­wych, nie two­rzę arku­szy kal­ku­la­cyj­nych ani doku­men­tów w edy­to­rach tek­stów. Produktem ​„do czy­ta­nia” (i do ewen­tu­al­ne­go dru­ku) jest doku­ment PDF sta­no­wią­cy peł­ną spe­cy­fi­ka­cję z dia­gra­ma­mi i opi­su­ją­cym je tek­stem. Jako pro­dukt pra­cy prze­ka­zu­ję tak­że edy­to­wal­ny plik źró­dło­wy w for­ma­cie XMI zawie­ra­ją­cy wszyst­kie opra­co­wa­ne mode­le i struk­tu­ry, wyra­żo­ne w nota­cjach BPMN i UML. 

Do zdal­nej pra­cy wyko­rzy­stu­ję, i udo­stęp­niam klien­tom, jed­no z naj­lep­szych narzę­dzi wspie­ra­ją­cych takie pro­jek­ty na ryn­ku: opro­gra­mo­wa­nie PostMania fir­my Visual-Paradigm, z któ­re­go korzy­sta­ją naj­więk­sze kon­cer­ny na świe­cie (lista i refe­ren­cje wybra­nych użyt­kow­ni­ków pakie­tu Visual-Paradigm, bez­pie­czeń­stwa wyko­rzy­sty­wa­ne­go repo­zy­to­rium VP). Visual-Paradigm to narzę­dzie CASE (ang. Computer Aided System Engineering, kom­pu­te­ro­we wspo­ma­ga­nie inży­nie­rii sys­te­mów). Stosuję go w całym pro­ce­sie ana­li­zy i mode­lo­wa­nia, oraz w toku two­rze­nia doku­men­ta­cji pro­jek­to­wej i zarzą­dza­nia nią. 

Wszystkie prze­sła­ne mi doku­men­ty są chro­nio­ne (kodo­wa­ne), ich kopie zapa­so­we są wyko­ny­wa­ne w try­bie dobo­wym. Powstające tre­ści są wer­sjo­no­wa­ne, wpro­wa­dza­ne zmia­ny są śle­dzo­ne i doku­men­to­wa­ne. Każda nowa treść lub jej zmia­na (zwa­na korek­tą – revi­sion) jest odno­to­wy­wa­na, ozna­czo­na w cza­sie i numerowana. 

Zapoznaj się z opi­sem: Visual Paradigm PostMania – Przewodnik Recenzenta.

Komunikacja

W wie­lu pro­jek­tach sto­so­wa­na jest zespo­ło­wa pra­ca z, wymie­nia­ny­mi np. mailem, doku­men­ta­mi w try­bie reje­stra­cji zmian (MS Word), co wyma­ga posia­da­nia opro­gra­mo­wa­nia MS Word. Pewnym uspraw­nie­niem jest dostęp do takie­go doku­men­tu on-line (repo­zy­to­rium MS Teams lub Sharepoint), to jed­nak wyma­ga posia­da­nia kon­ta Microsoft i dostę­pu do jed­nej z tych plat­form. Poważną wadą tego podej­ścia są: 1. brak moż­li­wo­ści sepa­ra­cji dostę­pu do tre­ści (uwa­gi i uzgod­nie­nia stron, osób, są widocz­ne dla wszyst­kich, co nie zawsze jest korzyst­ne), po wydru­ku lub zapi­sa­niu do PDF ma miej­sce brak moż­li­wo­ści jed­no­znacz­ne­go okre­śle­nia autor­stwa tre­ści doku­men­tu, oraz utra­ta wszel­kich uwag zgła­sza­nych w toku pra­cy nad doku­men­tem (wydruk papie­ro­wy lub do pdf nie zawie­ra histo­rii pośred­nich usta­leń i uwag). 

Dlatego zgła­sza­nie uwag do nie­edy­to­wal­ne­go doku­men­tu w posta­ci odręb­nych nota­tek, daje w efek­cie: pouf­ność uwag recen­zen­tów, wyni­ko­wy doku­ment mają­cy okre­ślo­ne­go auto­ra, histo­rię zgła­sza­nych uwag i komen­ta­rzy w posta­ci osob­nych doku­men­tów wraz z auto­ra­mi tych uwag i datą ich zgło­sze­nia (lub jed­ne­go doku­men­tu sta­no­wią­ce­go zapis uwag zgła­sza­nych przez recen­zen­tów). Postmania wspie­ra tę for­mę pracy. 

Dokumentowanie wyników analizy

W pro­jek­tach sto­su­ję z zasa­dy meto­dy zacho­wu­ją­ce autor­stwo doku­men­tów i uwa­gi w posta­ci odręb­nych pod­pi­sa­nych (autor i czas) nota­tek. Poniżej porów­na­nie tra­dy­cyj­nej meto­dy pra­cy pli­ko­wej i pra­cy on-line z uży­ciem plat­for­my komu­ni­ka­cyj­nej Postmania:

Po lewej tra­dy­cyj­na meto­da opra­co­wy­wa­nia ana­liz: powsta­je doku­ment, jego draft prze­ka­zy­wa­ny jest do recen­zji, po otrzy­ma­niu uwag nano­szo­ne ewen­tu­al­ne korek­ty. Przekazywany jest zawsze cały doku­ment. Gdy doku­ment jest recen­zo­wa­ny po jego opra­co­wa­niu, jego autor (ana­li­tyk) musi bez­czyn­nie cze­kać na uwa­gi recen­zen­tów. Jeden taki cykl recen­zji trwa nawet trzy tygo­dnie, bo za każ­dym razem wyma­ga ponow­nej pra­cy nad całym doku­men­tem. Po tym nastę­pu­ję nano­sze­nie korekt przez auto­ra, co tak­że trwa kil­ka dni. 

Po pra­wej stro­nie pra­ca on-line na bie­żą­co z poszcze­gól­ny­mi dia­gra­ma­mi i aka­pi­ta­mi opra­co­wa­nia. Treść Specyfikacji jest więc na bie­żą­co prze­glą­da­na przez recen­zen­tów i kory­go­wa­na przez auto­ra, draft cało­ści jest gene­ro­wa­ne ad-hoc na żąda­nie, wer­sja koń­co­wa w zasa­dzie nie wyma­ga już żad­nych dodat­ko­wych prac. Tą meto­dą osta­tecz­ny doku­ment powsta­je wie­lo­krot­nie szyb­ciej i znacz­nie taniej.

Wymiana treści między uczestnikami projektu

Wymiana infor­ma­cji w pro­jek­cie pole­ga na ite­ra­cyj­nym pro­ce­sie dostar­cza­nia infor­ma­cji i mate­ria­łów źró­dło­wych do ana­li­zy oraz zgła­sza­niu uwag i potrzeb zmian do powsta­ją­ce­go na ich pod­sta­wie opra­co­wa­nia: mode­li i ich opi­sów. UWAGA! Notatki ze spo­tkań sta­no­wią dostar­cza­ny mate­riał, więc z zasa­dy robi je i prze­ka­zu­je stro­na udzie­la­ją­ca infor­ma­cji.

Na eta­pie audy­tu i pro­jek­to­wa­nia, w pro­ce­sie tym bie­rze udział zespół pra­cow­ni­ków ana­li­zo­wa­ne­go pod­mio­tu. Po pod­pi­sa­niu umo­wy z dostaw­cą roz­wią­za­nia, tak­że zespół dostaw­cy. Od tego momen­tu zaczy­na się etap nad­zo­ru autor­skie­go pro­wa­dzo­ne­go przez Autora pro­jek­tu roz­wią­za­nia (Analityk) opi­sa­no na koń­cu tego doku­emn­tu. Proces komu­ni­ka­cji obra­zu­je poniż­szy diagram: 

1. Członkowie zespo­łu Zamawiającego, w odpo­wie­dzi na moje pyta­nia, odpi­su­ją lub prze­ka­zu­ją okre­ślo­ne infor­ma­cje w for­mie doku­men­to­wej (przy­kła­dy doku­men­tów, doku­men­ty źró­dło­we, opi­sy itp.), a następ­nie zgła­sza­ją swo­je uwa­gi do powsta­ją­cych sche­ma­tów blo­ko­wych i powią­za­nych z nimi opi­sów, tak powsta­ją kolej­ne roz­dzia­ły wyko­ny­wa­ne­go rapor­tu z audy­tu i spe­cy­fi­ka­cji wyma­gań (sche­ma­ty blo­ko­we i ich opi­sy), któ­re na bie­żą­co udo­stęp­niam do wery­fi­ka­cji człon­kom zespo­łu Zamawiającego (recen­zen­ci); na każ­de żąda­nie uczest­ni­ków pro­jek­tu, wysy­łam aktu­al­ny draft Opracowania w posta­ci peł­ne­go tek­stu jed­no­li­te­go (plik pdf).
2. Po zakoń­cze­niu eta­pu ana­li­zy i spe­cy­fi­ko­wa­nia roz­wią­za­nia wybie­ra­ny jest dostaw­ca Rozwiązania. Dostawca roz­wią­za­nia (inte­gra­tor, deve­lo­per), po otrzy­ma­niu Wymagań (pro­dukt Analizy Biznesowej), jeże­li potrze­bu­je dodat­ko­wych infor­ma­cji, zgła­sza takie pyta­nia, w odpo­wie­dzi otrzy­mu­je uzu­peł­nio­ne opra­co­wa­nie Analiza Biznesowa i Opis Techniczny Rozwiązania. Wszelkie uzu­peł­nie­nia powsta­ją z udzia­łem Podmiotu audy­to­wa­ne­go, opi­sa­ne­go w Wymaganiach.
3. Tak aktu­ali­zo­wa­ny doku­ment: Analiza Biznesowa i Projekt Techniczny, jest jedy­ną for­mą prze­ka­zy­wa­nia infor­ma­cji pod­mio­to­wi dostar­cza­ją­ce­mu roz­wią­za­nie. Dzięki temu Zamawiający ma sta­le aktu­ali­zo­wa­ną doku­men­ta­cję opi­su­ją­cą jego dzia­łal­ność, a Dostawca ma spój­ny i kom­plet­ny opis wyma­gań w posta­ci jed­ne­go zwar­te­go opisu. 
4. Dostawca na pod­sta­wie tre­ści doku­men­tu Analiza Biznesowa i Opis Techniczny, opra­co­wu­je swo­ją Koncepcję Wdrożenia. Ewentualne notat­ki spi­sy­wa­ne np. na spo­tka­niach przez Dostawcę, nie sta­no­wią sobą żad­nych uzgod­nień o wyma­ga­niach. Jedynym źró­dłem infor­ma­cji o pod­mio­cie audy­to­wa­nym jest Analiza Biznesowa i Projekt Techniczny, jako spój­ny, nie­sprzecz­ny i kom­plet­ny opis biz­ne­so­wy i opis wyma­gań Zamawiającego. 

Co jest produktem?

Na eta­pie trwa­nia prac ana­li­tycz­no-pro­jek­to­wych ope­ru­je­my dra­ftem opra­co­wa­nia. Zamawiający i recen­zen­ci mają dostęp ​„tyl­ko do odczy­tu”. Po prze­ka­za­niu doku­men­ta­cji Zamawiającemu (pra­wa mająt­ko­we wraz z pra­wem do two­rze­nia utwo­rów zależ­nych) kon­ty­nu­uje on sam pra­ce zwią­za­ne z aktu­ali­za­cją (wyma­ga to narzę­dzia do pra­cy z pli­kiem edy­to­wal­nym) lub pra­ce te reali­zu­je autor doku­men­ta­cji w ramach nad­zo­ru autor­skie­go (jako reali­za­cja autor­skich praw osobistych). 

Treści wymieniane w toku analizy

Wymagania biznesowe czyli potrzeby Zamawiającego

Po wyko­na­niu audy­tu i mode­lu pro­ce­sów biz­ne­so­wych oraz opra­co­wa­niu reko­men­da­cji ewen­tu­al­nych zmian, okre­śla­ne są Potrzeby Zamawiającego. Są to wyma­ga­nia wobec roz­wią­za­nia, wyra­żo­ne przez Zamawiającego języ­kiem natu­ral­nym z per­spek­ty­wy przy­szłe­go użyt­kow­ni­ka roz­wią­za­nia. Zarówno w sfe­rze popra­wy efek­tyw­no­ści na eta­pie ana­li­zy pro­ce­sów biz­ne­so­wych, jak i w sto­sun­ku do opro­gra­mo­wa­nia, jeże­li jego zakup i wdro­że­nie oka­żą wyma­ga­nym rozwiązaniem. 

Zamawiający co do zasa­dy dostar­cza mi mate­ria­ły źró­dło­we, jed­nak gorą­co odra­dzam samo­dziel­ne pro­jek­to­wa­nie roz­wią­za­nia infor­ma­tycz­ne­go czy­li spi­sy­wa­nie ​„co i jak sys­tem ma coś robić” albo, co gor­sza, samo­dziel­ne two­rze­nie sche­ma­tów blo­ko­wych i opi­sów pro­ce­sów czy sys­te­mów IT, gdyż przy­no­si to wię­cej szko­dy niż pożyt­ku: samo­dziel­ne opra­co­wy­wa­nie tych sche­ma­tów pro­sty­mi pro­gra­ma­mi biu­ro­wy­mi, przez nie­przy­go­to­wa­ne do tego i nie­do­świad­czo­ne oso­by, jest pra­co­chłon­ne a uzy­ska­ne efek­ty i tak zawsze wyma­ga­ją ana­li­zy i for­ma­li­za­cji przez ana­li­ty­ka . Lepiej więc, gdy Zamawiający zro­bi to co bar­dzo dobrze potra­fi: spi­sze swo­je potrzeby. 

Kluczowe poję­cie na tym eta­pie to

potrze­ba: funk­cja, któ­rej bra­ku­je (jest ocze­ki­wa­na) do osią­gnię­cia celu lub wyko­na­nia działania

Specyfikacja potrzeb – wymagania biznesowe

Wymagania biz­ne­so­we to zesta­wie­nie potrzeb wyra­żo­nych jako «potrze­by inte­re­sa­riu­szy». Zestawienie to nale­ży dostar­czyć w posta­ci tabeli:

Źródło wyma­ga­nia	Potrzeba	Obecny pro­blem
Dyrektor Logistyki	Zarzadzanie dosta­wa­mi nie­za­leż­nie dla każ­de­go zamówienia	Brak moż­li­wo­ści nad­zo­ru bie­żą­ce­go sta­nu czę­ścio­wej reali­za­cji zamówień
Dyrektor Handlowy	Dokumentowanie sprze­da­ży promocyjnej	Ręczne wsta­wa­nie do fak­tur cen innych niż katalogowe
Prezes	Bieżące śle­dze­nie war­to­ści przychodów	Brak wie­dzy o bie­żą­cej war­to­ści sprze­da­ży w okre­ślo­nym okresie

Specyfikacja potrzeb – User Story

Popularną, alter­na­tyw­ną, for­mą spi­sy­wa­nia potrzeb są tak zwa­ne ​„histo­ryj­ki użyt­kow­ni­ka” (ang. User Story). Są spi­sy­wa­ne przez biz­nes, widzia­ne z jego per­spek­ty­wy, wyra­ża­ne są w for­mie zdań: 

Czynność [nazwa]: Jako [nazwa wyko­ny­wa­nej roli roli] chcę stwo­rzyć [nazwa produktu/dokumentu] w celu [do cze­go ten pro­dukt jest dalej potrzebny]. 

To tak­że może być tak­że tabela:

ID	Nazwa	Rola (ja jako)	Produkt (two­rzę)	Adresat (dla)	Opis (opcjo­nal­nie)
001	Sprzedaż	Sprzedawca	Faktura	Klient	jako sprze­daw­ca chcę wysta­wić fak­tu­rę klientowi
002	Rejestracja zamó­wień	pra­cow­nik BOK	Zamówienie zaku­pu	Sprzedawca	Jako pra­cow­nik BOK chce reje­stro­wać zamó­wie­nia zaku­pu dla sprzedawców

Taka for­ma spi­sy­wa­nia wyma­gań zmu­sza ich auto­ra do wstęp­nej ich for­ma­li­za­cji, sta­no­wi bar­dzo dobry mate­riał dla pro­jek­tan­ta (ale Uwaga! To nie są funk­cje do bez­po­śred­niej imple­men­ta­cji). Forma ta jest tak­że przy­dat­na jako mate­riał wej­ścio­wy do mode­lo­wa­nia pro­ce­sów biz­ne­so­wych: są to aktyw­no­ści mają­ce pro­dukt i adre­sa­ta, któ­re w toku mode­lo­wa­nia pro­ce­sów biz­ne­so­wych są for­ma­li­zo­wa­ne do dia­gra­mów BPMN. 

Biznesowy cel projektu

Zalecanym uzu­peł­nie­niem jest okre­śle­nie biz­ne­so­we­go celu pro­jek­tu na tle misji i wizji orga­ni­za­cji (patrz: Audyt spój­no­ści wizji i misji orga­ni­za­cji z jej dzia­ła­nia­mi):

• misja: (jak sobie wyobra­ża­my nasz przy­szły rynek), 
• wizja: (nasz wkład w osią­gnię­cie powyż­sze­go sta­nu rzeczy),
• cel biz­ne­so­wy orga­ni­za­cji: (pla­no­wa­na pozy­cja na ryn­ku, fuzja, inne), 
• klu­czo­wy pro­blem: (co jest głów­nym powo­dem ini­cja­cji projektu).

Wymagania biz­ne­so­we są pod­sta­wą roz­po­czę­cia pro­jek­to­wa­nia rozwiązana. 

Uwagi do powstającej Analizy

Struktura organizacyjna

Powyższy sche­mat to sfor­ma­li­zo­wa­na struk­tu­ra orga­ni­za­cyj­na zobra­zo­wa­na jako ​„drze­wo zależ­no­ści przełożony-podwładny”. 

Przepływ pracy czyli procesy biznesowe

Na powyż­szym sche­ma­cie poka­za­no pro­ces biz­ne­so­wy: aktyw­no­ści oraz ich dane wej­ścio­we i wyj­ścio­we. Wszelkie dodat­ko­we deta­le nio­są doku­men­ty (sym­bo­le z zagię­ty­mi roga­mi na dia­gra­mie powy­żej), regu­ły biz­ne­so­we (spi­sy­wa­ne w posta­ci zesta­wie­nia w tre­ści opra­co­wa­nia lub na sche­ma­tach np. powy­żej: Budżetowanie. BR002).

Dokument i jego treść 

Struktury doku­men­tów są doku­men­to­wa­ne jako ich uprosz­czo­ne sza­blo­ny, np. jak ten poniżej:

Struktury doku­men­tów nio­są naj­wię­cej deta­licz­nych infor­ma­cji o prze­twa­rza­nych danych i związ­kach mie­dzy nimi. 

Biznesowy słownik pojęć

Podstawą zro­zu­mia­ło­ści i jed­no­znacz­no­ści doku­men­ta­cji jest jed­no­li­ty, spój­ny i kom­plet­ny słow­nik pojęć dla całe­go pro­jek­tu (gene­ral­nie doty­czy całej orga­ni­za­cji). Celem jest zapew­nie­nie jed­no­znacz­no­ści tre­ści nie tyl­ko doku­men­ta­cji pro­jek­to­wej ale też wszyst­kich ele­men­tów na mode­lach pro­ce­sów i sys­te­mu jakim jest opro­gra­mo­wa­nie. Co do zasa­dy słow­nik ma postać alfa­be­tycz­nej listy, jed­nak klu­czo­we dla zro­zu­mie­nia i inter­pre­ta­cji poję­cia, dodat­ko­wo wery­fi­ku­je­my z pomo­cą tak zwa­ne­go mode­lu poję­cio­we­go (dia­gram klas UML, lub model fak­tów SBVR, ). Jest to sche­mat blo­ko­wy, na któ­rym umiesz­cza­my klu­czo­we poję­cia i łączy­my je związ­kiem gene­ra­li­za­cji lub okre­ślo­nym fak­tem (pre­dy­kat). W ten spo­sób spraw­dza­my, czy poję­cia te two­rzą popraw­ne i praw­dzi­we zda­nia w języ­ku natu­ral­nym danej dzie­di­zny. Np. poniżej:

Powyższe czy­ta­my:

• kopia doku­men­tu i ory­gi­nał doku­men­tu to rodzaj (typ) dokumentu
• fak­tu­ra jest typem dokumentu
• sys­tem kan­ce­la­ryj­ny zapew­nia popraw­ny obieg dokumentów
• doku­ment jest przy­po­rząd­ko­wa­ny do sprawy

UWAGA! Ten dia­gram to nie jest pro­ces biznesowy!

Mechanizm działania systemu

Mogą sie poja­wić inne, uzu­peł­nia­ją­ce sche­ma­ty blokowe: 

Dokument (każ­dy obiekt lub kom­po­nent w sys­te­mie) mogą mieć sta­ny i sta­tu­sy, mode­lo­wa­ne jak poniżej:

Powyższe to tre­ści adre­so­wa­ne do pra­cow­ni­ków orga­ni­za­cji ana­li­zo­wa­nej. Są czę­ścią rapor­tu z Audytu Procesów Biznesowych Organizacji.

To co system ma robić czyli wymagania

Wymagania Zamawiającego (biz­ne­so­wy kon­tekst i oto­cze­nie pro­jek­tu) doku­men­to­wa­ne są jako model usług aplikacji:

Następująca po niej część doku­men­ta­cji, zaty­tu­ło­wa­na Opis Techniczny Oprogramowania, tak­że zawie­ra sche­ma­ty blo­ko­we, są to jed­nak spe­cja­li­stycz­ne mode­le adre­so­wa­ne do dostaw­cy opro­gra­mo­wa­nia, któ­ry skła­da­jąc ofer­tę musi oświad­czyć, że zna stan­dar­do­we tech­ni­ki ana­li­zy i mode­lo­wa­nia sys­te­mów infor­ma­cyj­nych (w tym sys­te­my nota­cyj­ne BPMN i UML). 

Spotkania

W ramach reali­zo­wa­nej usłu­gi odby­wa­ją się spo­tka­nia sta­tu­so­we (usta­le­nia pla­no­wa­nych dzia­łań w pro­jek­cie). Wszelkie dodat­ko­we warsz­ta­ty ini­cjo­wa­ne przez Zamawiającego sta­no­wią dodat­ko­we płat­ne spotkania. 

Spotkania są reali­zo­wa­ne jako video- i tele- kon­fe­ren­cje. Standardowo wysy­łam link do spo­tka­nia on-line. Jeżeli macie Państwo w swo­jej fir­mie wdro­żo­ny swój wła­sny sys­tem wide­okon­fe­ren­cyj­ny, może być on uży­wa­ny w pro­jek­cie. Jedynym ogra­ni­cze­niem jest brak koniecz­no­ści insta­lo­wa­nia dedy­ko­wa­ne­go opro­gra­mo­wa­nia na moim komputerze. 

Etap realizacji po wyborze dostawcy

Po wybo­rze Wykonawcy, opra­co­wu­je on doku­ment Koncepcja Wdrożenia, któ­ry zawie­ra opis spo­so­bu speł­nie­nia wyma­gań opi­sa­nych w doku­men­cie Analiza Biznesowa i Projekt Techniczny Oprogramowania (któ­ry pier­wot­nie sta­no­wił załącz­nik do Zapytania Ofertowego). 

Wszelkie wąt­pli­wo­ści Wykonawca wyja­śnia zada­jąc pyta­nia do tre­ści Analizy, któ­ra jest w ten spo­sób uzu­peł­nia­na. Opracowana i zaak­cep­to­wa­na Koncepcja Wdrożenia sta­no­wi (zawie­ra) szcze­gó­ło­wy zakres prac i har­mo­no­gram ich reali­za­cji. Od momen­tu jej zatwier­dze­nia, w toku reali­za­cji na bie­żą­co, ite­ra­cyj­nie, opra­co­wy­wa­ne są kolej­ne deta­le modu­łów, eta­pów, itp. to zna­czy: Wykonawca pyta o kolej­ne deta­le pro­jek­tu (wyma­gań), w odpo­wie­dzi dosta­je uszcze­gó­ło­wio­ną Analizę, na jej pod­sta­wie uzu­peł­nia Koncepcję Wdrożenia o kolej­ne deta­le reali­zo­wa­nej imple­men­ta­cji (wdro­że­nia), reali­zu­je to co zapla­no­wał w danym etapie.

W ten spo­sób, w dniu zakoń­cze­nia pro­jek­tu doku­ment Analiza sta­no­wi doku­ment opi­su­ją­cy fir­mę Zamawiającego na dzień zakoń­cze­nia wdro­że­nia, a doku­ment Koncepcja Wdrożenia sta­no­wi doku­men­ta­cję tech­nicz­ną powy­ko­naw­czą dostar­czo­ne­go rozwiązania. 

W całym pro­jek­cie narzę­dziem komu­ni­ka­cji jest Postmania. Inne narzę­dzia wyma­ga­ją uzgod­nie­nia, jed­nak sam pro­ces nie ule­ga zmianie. 

Źródła