Aż 60% klien­tów dekla­ru­je, że ich doświad­cze­nie zaku­po­we było nega­tyw­ne lub nie speł­ni­ło ich ocze­ki­wań, korzy­ści. Gartner zapy­tał o powo­dy rozczarowania:

• Niewystarczająca komu­ni­ka­cja
• Olbrzymia ilość opcji do rozważenia

Interesujące jest to, że klien­ci zamiast naci­skać na więk­sze inte­rak­cje z zespo­ła­mi sprze­da­żo­wy­mi, wole­li­by je mini­ma­li­zo­wać. Zdecydowana więk­szość (95 proc.) respon­den­tów wyra­zi­ło pre­fe­ren­cję dla w peł­ni cyfro­we­go, inter­ne­to­we­go i zdal­ne­go pro­ce­su doświad­cze­nia zakupowego.?

Jest opis dla każ­dej fir­my podej­mu­ją­cej (lub pla­nu­ją­cej) ze mną współ­pra­cę. 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 pro­jek­cie. W tek­ście tym opi­su­ję dla­cze­go pra­cu­ję na doku­men­tach i jakich narzę­dzi uży­wam do pro­wa­dze­nia komu­ni­ka­cji i wymia­ny treści.

Wymagane mate­ria­ły źró­dło­we zosta­ły opi­sa­ne poni­żej i ozna­czo­ne sza­rym tłem. Rolą człon­ków zespo­łu Zamawiającego jest nie tyl­ko dostar­cza­nie mate­ria­łów źró­dło­wych ale tak­że aktyw­ny udział w roli recen­zen­tów powsta­ją­cych tre­ści, dla­te­go poni­żej opi­sa­no pod­sta­wo­we typy i cele two­rze­nia okre­ślo­nych sche­ma­tów blo­ko­wych, legen­dy uży­tych sym­bo­li oraz przy­kła­dy ich uży­cia. Opisano tak­że narzę­dzie słu­żą­ce do komu­ni­ka­cji. Wystarczającą umie­jęt­no­ścią recen­zen­ta jest czy­ta­nie tych sche­ma­tów, ich opi­sów i zgła­sza­nie mery­to­rycz­nych uwag (co jest nie­praw­dą, cze­go brakuje). 

Wszelkie wąt­pli­wo­ści są wyja­śnia­ne na cyklicz­nych spo­tka­niach statutowych. 

Metody i narzędzia komunikacji w projekcie

Narzędzia:

• mój adres ema­il: j.zelinski@it-consulting.pl lub info@jaroslawzelinski.biz,
• doku­men­ta­cja pro­jek­to­wa on-line: Postmania (powia­do­mie­nia przy­cho­dzą z adre­su: support@visual-paradigm.com),
• ofer­ty, zamó­wie­nia i roz­li­cze­nia: FreshBook (powia­do­mie­nia przy­cho­dzą z adre­sów: mail@fb02.freshbooks.com, mail@fb05.freshbooks.com, welcome@fb02.freshbooks.com).

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 (tu Recenzent). 

Powyższa pętla to raz kil­ka godzin a raz natych­mia­sto­wa odpo­wiedź. Jest to typo­wa tak zwa­na komu­ni­ka­cja asyn­chro­nicz­na. Uczestnicy piszą lub odpi­su­ją w dogod­nym dla sie­bie momen­cie, co nie zabu­rza ich nor­mal­nej codzien­nej pra­cy i obo­wiąz­ków. Tak powsta­ją­ca i aktu­ali­zo­wa­na doku­men­ta­cja pro­jek­to­wa (ana­li­za biz­ne­so­wa, spe­cy­fi­ka­cja wyma­gań) to tak zwa­na ​„Żyjąca doku­men­ta­cja” .

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 (Visual-Paradigm oraz w uni­wer­sal­nym for­ma­cie XMI) zawie­ra­ją­cy wszyst­kie opi­sy, opra­co­wa­ne mode­le i struktury. 

Dodatkowe spo­tka­nia i warsz­ta­ty na życze­nie Zamawiającego (nie doty­czy spo­tkań sta­tu­so­wych) są roz­li­cza­ne jako dodat­ko­we pra­ce T&M.

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ń­stwo 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ą na ser­we­rze 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.

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), może on two­rzyć jej kolej­ne wer­sje (prze­ka­zu­ją pra­wa tak­że do two­rze­nia utwo­rów zależ­nych) lub pra­ce te reali­zu­je autor doku­men­ta­cji w ramach zle­co­ne­go mu nad­zo­ru autor­skie­go i nad­zo­ru mery­to­rycz­ne­go nad pra­ca­mi dostaw­ców systemów. 

Przykładowe pro­duk­ty mojej pra­cy na stro­nie: BIBLIOTEKA

W dal­szej czę­ści opi­sa­no powsta­ją­ce w toku ana­li­zy i pro­jek­to­wa­nia pro­duk­ty i wyma­ga­ne mate­ria­ły źró­dło­we (ozna­czo­na sza­rym tłem).

Analiza biznesowa – materiały źródłowe i produkty analizy 

Na tym eta­pie powsta­ją: opi­sy biz­ne­so­wych celów pro­jek­tu, model struk­tu­ry orga­ni­za­cyj­nej, mode­le pro­ce­sów biz­ne­so­wych, opi­sy doku­men­tów biz­ne­so­wych, biz­ne­so­wy słow­nik pojęć. Podstawowym mate­ria­łem źró­dło­wym są wszel­kie wewnętrz­ne i zewnętrz­ne regu­la­mi­ny i zasa­dy, przy­kła­do­we doku­men­ty i opi­sy, wypeł­nio­ne ankiety. 

Biznesowy cel projektu

Zalecanym począt­kiem ana­li­zy 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).

Materiał źró­dło­wy:

Dokumenty sta­tu­to­we orga­ni­za­cji, udo­ku­men­to­wa­ne opi­sy stra­te­gii ryn­ko­wej i pokrew­ne powią­za­ne doku­men­ty (jeśli istnieją).

Struktura organizacyjna

Podstawą zro­zu­mie­nia dzia­ła­nia orga­ni­za­cji jest jej struk­tu­ra orga­ni­za­cyj­na. Jest ona tak­że słow­ni­kiem ról i kom­pe­ten­cji na mode­lach pro­ce­sów biz­ne­so­wych. Dokumentowana jest poniż­szą metodą:

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­żo­ny-pod­wład­ny” (lub komór­ka nad­rzęd­na pod­rzęd­na). «Unit» ozna­cza komór­kę lub rolę (odpo­wie­dzial­ność).

Materiał źró­dło­wy:

Udokumentowana struk­tu­ra orga­ni­za­cyj­na w dowol­nej formie

Przepływ pracy i dokumentów czyli procesy biznesowe

Definicja pro­ce­su biz­ne­so­we­go brzmi: 

zde­fi­nio­wa­ny zestaw dzia­łań biz­ne­so­wych, któ­re repre­zen­tu­ją kro­ki wyma­ga­ne do osią­gnię­cia celu biz­ne­so­we­go, obej­mu­je prze­pływ i wyko­rzy­sta­nie infor­ma­cji oraz zasobów.

Notacja BPMN, Glossary 

Dlatego model pro­ce­sów to dia­gram obra­zu­ją­cy łań­cuch aktyw­no­ści i ich celów (doku­men­ty jako infor­ma­cje). Zasoby są repre­zen­to­wa­ne przez role wyko­naw­ców. Detale każ­dej aktyw­no­ści, jeże­li są wyma­ga­ne, doku­men­to­wa­ne są osob­no jako komen­ta­rze i ich pro­ce­du­ry (patrz opis: Proces a pro­ce­du­ra)

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

Model pro­ce­sów biz­ne­so­wych zawie­ra nazwy doku­men­tów. Ich struk­tu­ry nio­są deta­licz­ne infor­ma­cje o prze­twa­rza­nych danych i związ­kach mię­dzy nimi, są dodat­ko­wo doku­men­to­wa­ne jako sza­blo­ny, np. jak ten poniżej:

Struktury te uzu­peł­nia­my regu­ła­mi ich popraw­no­ści (regu­ły biz­ne­so­we), defi­ni­cje pól i obsza­rów to ele­ment biz­ne­so­we­go słow­ni­ka pojęć (zawie­ra mię­dzy inny­mi nazwy wszyst­kich klu­czo­wych ele­men­tów na dia­gra­mach opi­su­ja­cych doku­men­ty i formularze). 

Materiał źró­dło­wy:

Treść regu­la­mi­nów, roz­po­rzą­dzeń, pro­ce­dur, instruk­cji sta­no­wi­sko­wych, wzo­ry i przy­kła­dy wytwa­rza­nych doku­men­tów i for­mu­la­rzy wraz z opi­sem reguł ich poprawności.

Biznesowy słownik pojęć – ontologia

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, doku­men­tach (for­mu­la­rzach) i ekra­nach 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 poję­cia dzie­dzi­no­we, 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 wybra­ne 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ą para­mi popraw­ne i praw­dzi­we zda­nia w języ­ku natu­ral­nym danej dzie­dzi­ny wie­dzy. 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 biz­ne­so­wy! To model onto­lo­gicz­ny sto­so­wa­ny do mode­lo­wa­nia i wery­fi­ka­cji słow­nic­twa dzie­dzi­no­we­go, podob­ny jak te budo­wa­ne w sys­te­mach sztucz­nej inteligencji.

Materiał źró­dło­wy:

Wykorzystywane są te same mate­ria­ły, któ­re słu­ża do ana­ly­zy i mode­lo­wa­nie celów i pro­ce­sów biznesowych.

Wymagania na oprogramowanie

Wymaganiem na opro­gra­mo­wa­nie jest treść opi­su jego dzia­ła­nia: Opis Techniczny Oprogramowania (patrz: pro­ces ICONIX). Poniżej jego klu­czo­we opi­sa­no ele­men­ty. Jednak gorą­co odra­dzam tu samo­dziel­ne spi­sy­wa­nie ​„co i jak sys­tem ma coś robić” albo, co gor­sza, samo­dziel­ne two­rze­nie nie­sfor­ma­li­zo­wa­nych 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 .

Usługi systemu czyli Co system ma robić

Każde opro­gra­mo­wa­nie (apli­ka­cja) moż­na opi­sać skoń­czo­ną listą usług jakie to opro­gra­mo­wa­nie świad­czy ele­men­tom swo­je­go oto­cze­nia (użyt­kow­nik i inne apli­ka­cje). Jeżeli to opro­gra­mo­wa­nie jest dopie­ro pla­no­wa­ne do zaku­pu, to lista taka jest zbio­rem wyma­gań wobec tego nowe­go opro­gra­mo­wa­nia. Na tym eta­pie nie ma zna­cze­nia to czy będzie to opro­gra­mo­wa­nie stan­dar­do­we czy dedykowane.

Do zbu­do­wa­nia takiej listy moż­na użyć burzy mózgów, jed­nak z powo­dów opi­sa­nych na począt­ku, znacz­nie efek­tyw­niej­szą meto­dą jest ana­li­za biz­ne­so­wa i wska­za­nie na mode­lach pro­ce­sów aktyw­no­ści, któ­re chce­my wes­przeć opro­gra­mo­wa­niem (trans­for­ma­cja mode­lu pro­ce­sów na model wyma­ga­nych usług apli­ka­cji). W efek­cie powsta­je pro­sty dia­gram (dia­gram przy­pad­ków uży­cia UML), sta­no­wią­cy zobra­zo­wa­nie usług apli­ka­cji jakich ocze­ku­je­my od nowe­go oprogramowania:

Materiał źró­dło­wy:

Model pro­ce­sów biz­ne­so­wych oraz wypra­co­wa­na decy­zja o obsza­rze i zakre­sie wdrożenia.

Potrzeby Zamawiającego czyli wymagania biznesowe

Kolejny etap to zebra­nie listy potrzeb przy­szłych użyt­kow­ni­ków. Są to wyra­żo­ne języ­kiem biz­ne­so­wym (natu­ral­nym) ocze­ki­wa­nia wobec tych usług.

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

Wymagania biz­ne­so­we (tak­że capa­bi­li­ty requ­ire­ment) to zesta­wie­nie potrzeb wyra­żo­nych jako «potrze­by inte­re­sa­riu­szy». Sa one przy­pi­sy­wa­ne do usług apli­ka­cji (przy­pad­ki uży­cia, poprzed­ni roz­dział). Zestawienie to nale­ży dostar­czyć w posta­ci zestawienia:

Materiał źró­dło­wy:

Potrzeby użyt­kow­ni­ków spi­sa­ne w punk­tach, każ­dy punkt w posta­ci: - potrzeba/cel (wysta­wia­nie fak­tur) - jej uza­sad­nie­nie (doku­men­to­wa­nie sprze­da­ży) - zało­że­nia (auto­ma­tycz­ne pod­po­wia­da­nie danych z zamó­wie­nia) - waga (1‑niezbędny, 2‑oczekiwany, 3‑pomocny) - wła­ści­ciel (oso­ba zgłaszająca).

Mechanizm działania systemu

Każda usłu­ga apli­ka­cji cechu­je się okre­ślo­nym mecha­ni­zmem jej reali­za­cji. Standardowo przy­pi­su­je się jej okre­ślo­ny doku­ment z mode­lu pro­ce­sów a ona sama sta­no­wi osob­ny kom­po­nent systemu. 

Stany i statusy dokumentów

Na eta­pie doku­men­to­wa­nia usług apli­ka­cji mogą sie poja­wić inne, uzu­peł­nia­ją­ce sche­ma­ty blokowe: 

Poszczególne dokumenty/formularze mogą mieć sta­ny i sta­tu­sy. Modelowane są one jak poniżej:

Materiał źró­dło­wy:

Model pro­ce­sów biznesowych

Architektura systemu

Na eta­pie opi­su wyma­gań nie wia­do­mo, któ­re usług apli­ka­cji zre­ali­zu­je wybra­ne opro­gra­mo­wa­nie (np. ERP). Aplikacje dedy­ko­wa­ne wyma­ga­ją opi­sa­nia archi­tek­tu­ry HLD i LLD. Z uwa­gi na spe­cy­fi­kę każ­dej orga­ni­za­cji wyma­ga­ne jest tak­że zapro­jek­to­wa­nie inte­gra­cji sys­te­mów. Jednak adre­sa­tem tych doku­men­tów są inży­nie­ro­wie dostaw­ców, nie są one recen­zo­wa­ne przez Zamawiającego. 

Materiał źró­dło­wy:

Uzgodniony model przy­pad­ków uży­cia, lista potrzeb i mode­le pro­ce­sów biznesowych.

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, na pod­sta­wie doku­men­tu Analiza Biznesowa i Opis Techniczny Systemu (Analiza), Wykonawca opra­co­wu­je doku­ment Koncepcja Wdrożenia, któ­ry zawie­ra opis spo­so­bu speł­nie­nia wyma­gań opi­sa­nych w Analizie (pier­wot­nie sta­no­wi ona załącz­nik do Zapytania Ofertowego). Dotyczy to każ­de­go Wykonawcy z osob­na: mode­le inte­gra­cji są w Analizie. 

Wszelkie wąt­pli­wo­ści doty­czą­ce tre­ści Analizy (bra­ku­ją­ce deta­le, nie­jed­no­znacz­no­ści itp.) Wykonawca wyja­śnia zada­jąc pyta­nia do tre­ści Analizy (pyta­nia prze­ka­zu­je auto­ro­wi Analizy lub Zamawiającemu). Po wypra­co­wa­niu odpo­wie­dzi po stro­nie Zamawiającego Analiza jest aktu­ali­zo­wa­na i prze­ka­zy­wa­na wyko­naw­cy jako odpo­wiedź na zada­ne pyta­nia. Co do zasa­dy Analiza jest jedy­nym doku­men­tem źró­dło­wym dla Wykonawcy. 

Koncepcja Wdrożenia, sta­no­wi szcze­gó­ło­wy opis tego co wyko­na i dostar­czy Wykonawca. W toku reali­za­cji jeże­li Wykonawca pyta o kolej­ne potrzeb­ne mu deta­le, w odpo­wie­dzi dosta­je uszcze­gó­ło­wio­ną Analizę. Na tej pod­sta­wie aktu­ali­zu­je Koncepcję Wdrożenia o kolej­ne deta­le reali­zo­wa­nej imple­men­ta­cji (wdro­że­nia). W takim cyklu postę­pu­ją kolej­ne pra­ce wdrożeniowe.

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ę powy­ko­naw­czą dostar­czo­ne­go roz­wią­za­nia . W całym pro­jek­cie Analiza i Koncepcja Wdrożenia, to jedy­ne for­mal­ne doku­men­ty pro­jek­to­we. Pisemne wnio­ski o ich uzu­peł­nie­nie sta­no­wią wyłącz­nie histo­rię przy­czyn zmian, załączniki. 

W całym pro­jek­cie pod­sta­wo­wym narzę­dziem komu­ni­ka­cji jest sys­tem Postmania. Inne narzę­dzia wyma­ga­ją uzgod­nie­nia, jed­nak sam pro­ces nie ule­ga zmia­nie: jedy­nym źró­dłem infor­ma­cji dla Wykonawcy jest ana­li­za, wszel­kie inne robo­cze doku­men­ty (notat­ki ze spo­tkań i roz­mów) sta­no­wią mate­riał źró­dło­wy do aktu­ali­za­cji Analizy. 

Źródła