• Produkt: Opis Przedmiotu Zamówienia (opra­co­wa­nie spe­cy­fi­ka­cji SWS) zawie­ra­ją­cy zarów­no udo­ku­men­to­wa­ny Model Biznesowy Organizacji jak i Projekt Techniczny Rozwiązania, reali­zo­wa­ny jest tak­że nad­zór autor­ski nad realizacją.
• Korzyści: ochro­na know-how Zamawiającego, kom­plet­ne i spój­ne wyma­ga­nia wyra­żo­ne jako pro­jekt tech­nicz­ny, obiek­ty­wi­za­cja prac wykonawcy.

Wymagania

Wymagania mają dwa wymiary: 

• biz­ne­so­we wyma­ga­nia wobec roz­wią­za­nia (któ­re tu jest czar­ną skrzynką) 
• tech­nicz­ne wobec roz­wią­za­nia (któ­re tu są mode­lem mecha­ni­zmu dzia­ła­nia roz­wią­za­nia, czę­sto zwa­ne bia­łą skrzynką)

Norma IEEE tak defi­niu­je wymaganie:

1. waru­nek lub zdol­ność potrzeb­na użyt­kow­ni­ko­wi do roz­wią­za­nia pro­ble­mu lub osią­gnię­cia celu
2. waru­nek lub zdol­ność, któ­re muszą być speł­nio­ne lub posia­da­ne przez sys­tem lub kom­po­nent sys­te­mu w celu speł­nie­nia wymo­gów umo­wy, stan­dar­du, spe­cy­fi­ka­cji lub inne­go for­mal­nie narzu­co­ne­go doku­men­tu
3. udo­ku­men­to­wa­na repre­zen­ta­cja warun­ku lub moż­li­wo­ści jak w (1) lub (2)

(źr.: nor­ma IEEE1998)

Pierwsze to wyma­ga­nia biz­ne­so­we, dru­gie to już pro­jekt roz­wią­za­nia. Czym jest ​„udo­ku­men­to­wa­na repre­zen­ta­cja”? Tu mamy wybór: może to być opis w języ­ku natu­ral­nym i ochro­ni go pra­wo autor­skie, a może to być pro­jekt tech­nicz­ny wyra­żo­ny w usta­lo­nej stan­dar­do­wej for­mie. Jeżeli jest to for­ma algo­ryt­mów, wzo­rów mate­ma­tycz­nych, sfor­ma­li­zo­wa­nych sche­ma­tów blo­ko­wych, to nie tyl­ko chro­ni go pra­wo autor­skie, ale dodat­ko­wo tak­że pra­wo doty­czą­ce paten­tów i wzo­rów prze­my­sło­wych, taki doku­ment sta­je się tak­że wie­dzą chro­nio­ną jako know-how (patrz Ochrona war­to­ści inte­lek­tu­al­nych i know-how w orga­ni­za­cji).

Jednak same wyma­ga­nia to nie jedy­ny pro­dukt na eta­pie ​„zbie­ra­nia wyma­gań”. Udokumentowana repre­zen­ta­cja zawie­ra (powin­na) opis logi­ki zbie­ra­nia i prze­twa­rza­nia infor­ma­cji, a dostaw­ca powi­nien dostać udo­ku­men­to­wa­na repre­zen­ta­cję tego co ma dostarczyć. 

Rolą dostaw­cy opro­gra­mo­wa­nia jest dostar­cze­nie i wdro­że­nie opro­gra­mo­wa­nia zgod­ne­go z przed­sta­wio­ny­mi mu wyma­ga­nia­mi i zapew­nie­nie jego jako­ści, a nie ana­li­za wyma­gań kupu­ją­ce­go na tle moż­li­wo­ści ofe­ro­wa­ne­go przez sie­bie pro­duk­tu. Dlatego wyma­ga­nia i logicz­ny pro­jekt roz­wią­za­nia powin­ny być opra­co­wa­ne przed wybo­rem jego dostaw­cy.

Dlatego koniecz­ny jest etap ana­li­zy i pro­jek­to­wa­nia, jego pro­duk­ty poka­za­no poniżej:

Na eta­pie ana­li­zy i pro­jek­to­wa­nia (reali­zu­je to ana­li­tyk-pro­jek­tant sys­te­mów) orga­ni­za­cja dostar­cza doku­men­ty do ana­li­zy nio­są­cę wie­dze o niej. Dlaczego nie wywia­dy? Niestety, meto­dy bazu­ją­ce na zaufa­niu w moc wywia­dów z pra­cow­ni­ka­mi i burz mózgów, w ​„wie­dzę” wie­lo­let­nie­go pra­cow­ni­ka i doświad­cze­nie dostaw­cy okre­ślo­ne­go opro­gra­mo­wa­nia, stwa­rza­ją pro­ble­my z wdra­ża­niem sys­te­mów ERP. Wiele nie­uda­nych pro­jek­tów koń­czy się sło­wa­mi: ​„Problem pole­gał na tym, że dostar­czo­no nam dokład­nie to co chcie­li­śmy, a nie to co jest nam potrzeb­ne. „. Spisywanie wyma­gań w języ­ku natu­ral­nym to ogrom­ne ryzy­ko nie­spój­no­ści i niekompletności:

Niestety same spi­sa­ne funk­cjo­nal­no­ści pro­gra­mu czy­li spe­cy­fi­ka­cja (lista) wyma­gań funk­cjo­nal­nych to wyłącz­nie idea jego powsta­nia (wyrok SA w Poznaniu z dnia 4 stycz­nia 1995 r. I ACr 422/94). Precyzję opi­su, dają­cą ochro­nę w posta­ci peł­ne­go pra­wa do powsta­łe­go pro­duk­tu, uzy­sku­je się dopie­ro opra­co­wu­jąc pro­jekt jego kon­struk­cji, struk­tur danych i mecha­ni­zmu dzia­ła­nia, sto­su­jąc wzo­ry mate­ma­tycz­ne, algo­ryt­my, uni­kal­ne struk­tu­ry i sche­ma­ty blo­ko­we.

Dlatego popraw­nym pro­duk­tem ana­li­zy sys­te­mo­wej przed­się­bior­stwa jest pro­jekt archi­tek­tu­ry i logi­ki dzia­ła­nia roz­wią­za­nia a nie kon­kret­ne oprogramowanie!

Udokumentowanie pro­ble­mu, dostęp­nych roz­wią­zań i pla­nu dostar­cze­nia war­to­ści pozwa­la wszyst­kim osią­gnąć suk­ces. Przynajmniej w ten spo­sób sta­je się jasne, jaki pro­blem ty i twój zespół pró­bu­je­cie roz­wią­zać i jakie roz­wią­za­nia są dostęp­ne i któ­re z nich wybra­łeś, spra­wia, że jest jasne dla każ­de­go, kto to czy­ta (zespół, inte­re­sa­riu­sze, zarząd, klient), w jaki spo­sób zamie­rzasz dostar­czyć war­tość. Jeśli nie możesz tego zapi­sać i uzy­skać zgo­dy inte­re­sa­riu­szy, i tak musisz wyko­nać tę pra­cę: po pro­stu zanur­ku­jesz w kodo­wa­nie mając nadzie­ję, że wszyst­ko się uło­ży. Jednak nadzie­ja nie jest dobrą strategią.

Warsztaty

Czy orga­ni­za­cja (jej pra­cow­ni­cy) powin­na sama opi­sać swo­je potrze­by? Prawo Conway’a mówi, że orga­ni­za­cje same pro­jek­tu­ją sys­te­my, któ­re odzwier­cie­dla­ją ich wła­sną struk­tu­rę komu­ni­ka­cyj­ną. Nazwa pocho­dzi od pro­gra­mi­sty kom­pu­te­ro­we­go Melvina Conwaya, któ­ry wpro­wa­dził tę ideę w 1967 r.. Jego ory­gi­nal­ne sfor­mu­ło­wa­nie brzmiało:

Każda orga­ni­za­cja, któ­ra pro­jek­tu­je sys­tem (zde­fi­nio­wa­ny sze­ro­ko), wytwo­rzy pro­jekt, któ­re­go struk­tu­ra jest kopią struk­tu­ry komu­ni­ka­cyj­nej organizacji.

(źr.: http://​www​.mel​con​way​.com/​H​o​m​e​/​C​o​n​w​a​y​s​_​L​a​w​.​h​tml)

Innymi sło­wy:

orga­ni­za­cje w któ­rych wyma­ga­nia na sys­tem infor­ma­tycz­ny są spi­sy­wa­ne przez ich pra­cow­ni­ków i zara­zem przy­szłych użyt­kow­ni­ków tego sys­te­mu, dosta­ną sys­tem, któ­ry utrwa­la stan obec­ny, a nie zmie­nia go na lepsze. 

Metoda ta ma tak­że inne wade: opis taki jest bar­dzo czę­sto nie­jed­no­znacz­ny, dość ogól­ny i w żaden spo­sób nie chro­ni know-how i dorob­ku zamawiającego:

Niekompletność jest typo­wym pro­ble­mem, któ­ry poja­wia się, gdy inte­re­sa­riu­sze (np. eks­per­ci dome­ny) posia­da­ją pew­ne infor­ma­cje i uzna­ją je za ogól­nie zna­ne, i nie wspo­mi­na­ją o nich ana­li­ty­ko­wi. Model opar­ty na nie­kom­plet­nych wyma­ga­niach cier­pi z powo­du bra­ku­ją­cych obiek­tów, wła­ści­wo­ści lub relacji.

Dzieje się tak nie dla­te­go, że ludzie ci mają złą wolę, a dla­te­go że sto­so­wa­nie intu­icji w miej­scu gdzie nale­ży użyć twar­dych reguł i fak­tów, pra­wie zawsze pro­wa­dzi do błę­dów .

Tworzenie sys­te­mów zawie­ra­ją­cych opro­gra­mo­wa­nie obej­mu­je wie­le pozio­mów abs­trak­cji, pro­wa­dzą­cych od wyma­gań do kodu. Posiadanie abs­trak­cyj­nych kon­cep­cji poma­ga zde­fi­nio­wać kod i upew­nić się, że kom­po­nen­ty opro­gra­mo­wa­nia zacho­wu­ją się w ocze­ki­wa­ny spo­sób. Istnieje luka, któ­ra nie może być zamknię­ta przez zwy­kłe meto­dy pro­gra­mo­wa­nia, ale któ­ra może być zamknię­ta, jeśli pro­gra­mo­wa­nie jest wspie­ra­ne przez odpo­wied­nie ramy modelowania.

Dlatego zaan­ga­żo­wa­nie do tego celu ana­li­ty­ka-pro­jek­tan­ta z zewnątrz i sfor­ma­li­zo­wa­nie doku­men­ta­cji jest klu­czo­we, tak­że dla­te­go, że stan­dar­do­wo pro­wa­dzi on tak­że nad­zór autor­ski nad pra­ca­mi wykonawcy.

ZARZĄDZANIE PROJEKTEM WE WŁASNYM ZAKRESIE JEST KRYTYCZNE: Integratorzy sys­te­mów mogą być cen­nym ele­men­tem cyfro­wej trans­for­ma­cji, ale nigdy nie powin­ni mieć cał­ko­wi­tej, nie­kon­tro­lo­wa­nej wła­dzy nad całym przedsięwzięciem.

(źr. PORAŻKA CYFROWEJ TRANSFORMACJI W FIRMIE HERTZ, oryg. : 4 LESSONS FROM THE HERTZ VS. ACCENTURE DISASTER)

Systemy ERP

Skrót ERP to Planowanie Zasobów Przedsiębiorstwa (ang. ERP, Enterprise Resource Planning). Oznacza to zin­te­gro­wa­ne zarzą­dza­nie głów­ny­mi pro­ce­sa­mi biz­ne­so­wy­mi, czę­sto w cza­sie rze­czy­wi­stym i za pośred­nic­twem opro­gra­mo­wa­nia i tech­no­lo­gii. ERP jest zwy­kle okre­śla­ne jako kate­go­ria opro­gra­mo­wa­nia do zarzą­dza­nia przed­się­bior­stwem – zazwy­czaj pakiet zin­te­gro­wa­nych apli­ka­cji – któ­re orga­ni­za­cja może wyko­rzy­sty­wać do gro­ma­dze­nia, prze­cho­wy­wa­nia, zarzą­dza­nia i inter­pre­to­wa­nia danych z wie­lu dzia­łań biz­ne­so­wych. Integracja ta może odby­wać się poprzez współ­dzie­le­nie jed­nej bazy danych lub poprzez wymia­nę danych na pozio­mie logi­ki biznesowej. 

Wspólna współ­dzie­lo­na baza danych czy­ni taki sys­tem mono­li­tem nie­podat­nym na zmia­ny (a ich ewen­tu­al­ne wpro­wa­dza­nie – kasto­mi­za­cja sys­te­mu – jest bar­dzo kosz­tow­ne i ryzy­kow­ne). Dlatego, przy obec­nym pozio­mie tech­no­lo­gii, inte­gra­cja spe­cja­li­zo­wa­nych sys­te­mów jest znacz­nie efek­tyw­niej­sza i nie wyma­ga kosz­tow­nych kasto­mi­za­cji. Tradycyjne sys­te­my ERP budo­wa­ne na jed­nej cen­tral­nej bazie danych są obec­nie uwa­ża­ne za star­szą technologię.

Wielu dostaw­ców star­szych tech­no­lo­gii, inte­gru­ją­cych funk­cje z pomo­cą jed­nej wspól­nej bazy danych, pro­mu­je tezy takie jak ta:

„W przy­pad­ku opro­gra­mo­wań zamknię­tych część funk­cji sys­te­mu jest sztyw­na, a fir­ma wdra­ża­ją­ca je w swo­je struk­tu­ry musi liczyć się ze zmia­ną wła­snych pro­ce­dur w taki spo­sób, by dopa­so­wać się do wymo­gów opro­gra­mo­wa­nia. […] Niestety, poraż­ka jest nie­unik­nio­na, jeśli fir­ma chce zarów­no wdro­że­nia nowe­go sys­te­mu, jak i pozo­sta­nia przy wcze­śniej­szym spo­so­bie funk­cjo­no­wa­nia. W przy­pad­ku sys­te­mu ERP takie zało­że­nie się wyklucza.”

Jest to kon­se­kwen­cja mono­li­tycz­nej, nie­podat­nej na zmia­ny, archi­tek­tu­ry. W bar­dzo wie­lu przy­pad­kach suge­stia, że nabyw­ca ma porzu­cić swój wypra­co­wa­ny lata­mi ope­ra­cyj­ny styl pra­cy, dla­te­go bar­dzo wie­le wdro­żeń mono­li­tycz­nych ERP koń­czy sie poraż­ką , bywa, że upór wdra­ża­ją­cych jest dro­gą do biz­ne­so­we­go samobójstwa.

Podstawowym celem wdro­żeń sys­te­mów ERP jest popra­wa funk­cjo­no­wa­nia orga­ni­za­cji, osią­ga­my ją poprzez stan­da­ry­za­cję i opty­ma­li­za­cję. Standaryzacja ma sens tam, gdzie stan­da­ry­za­cję narzu­ca pra­wo, dobre prak­ty­ki itp., naj­czę­ściej jest to obszar admi­ni­stra­cji. Optymalizację wpro­wa­dza­my wszę­dzie tam, gdzie to my decy­du­je­my o kształ­cie pro­ce­sów i procedur. 

Poniżej zna­ny od lat, tak zwa­ny model wewnętrz­ne­go łań­cu­cha war­to­ści Portera .

Obszar sza­ry to obszar stan­dar­do­wych pro­ce­sów i pro­ce­dur, w tej czę­ści prak­tycz­nie każ­da orga­ni­za­cja pra­cu­je tak samo, to obszar w zna­ko­mi­tej więk­szo­ści regu­lo­wa­ny pra­wem. Dlatego obszar sza­ry stan­da­ry­zu­je­my i tu ma sens ​„ERP z pół­ki, a w zasa­dzie tyl­ko jego stan­dar­do­we modu­ły FK. 

Obszar ozna­czo­ny kolo­ra­mi to klu­czo­wy obszar two­rzą­cy ryn­ko­wą war­tość doda­ną i prze­wa­gę kon­ku­ren­cyj­ną: to tu ​„sie­dzi” know-how orga­ni­za­cji. Ten obszar opty­ma­li­zu­je­my, i tu ​„wiel­kie ERP” jako ​„mono­li­ty na jed­nej bazie danych”, nie­ste­ty nie mają abso­lut­nie nic do zaofe­ro­wa­nia poza ​„wyrów­na­niem w dół do resz­ty kon­ku­ren­tów”, a prak­tycz­nie każ­da pró­ba kasto­mi­za­cji ERP w tym obsza­rze koń­czy się kosz­tow­ną poraż­ką .

Dlatego naj­pierw nale­ży wyko­nać audyt pro­ce­sów biz­ne­so­wych i ziden­ty­fi­ko­wać w orga­ni­za­cji jej ​„kolo­ro­wy obszar”. Należy bar­dzo dobrze prze­ana­li­zo­wać go od stro­ny infor­ma­cji jaki­mi tu zarzą­dza­my (opro­gra­mo­wa­nie nie zastę­pu­je ludzi ani maszyn, ono TYLKO zarzą­dza dany­mi na ich temat!), wynik ana­li­zy (w tym ewen­tu­al­ne stan­da­ry­za­cje i opty­ma­li­za­cje!) udo­ku­men­to­wać jako wyma­ga­nie, i teraz dopie­ro dobrać na ryn­ku pasu­ją­ce roz­wią­za­nia (nie raz dla każ­de­go dzie­dzi­no­we­go obsza­ru osob­no) i zin­te­gro­wać. I takie podej­ście daje wyni­ki nie raz nawet po roku i nie raz o rząd wiel­ko­ści mniej­szym kosztem.

Owszem bywa, że potrzeb­ne są dedy­ko­wa­ne roz­wią­za­nia… wte­dy są one imple­men­ta­cją logi­ki biz­ne­so­wej udo­ku­men­to­wa­nej w wyni­kach ana­li­zy biznesowej.

W dal­szej czę­ści opi­sa­łem po kolei jak to zrobić.

Idealizacja jako metoda

Idealizacja to meto­da opra­co­wa­nia wyma­gan na real­ne roz­wią­za­nie. Polega na opra­co­wa­niu rapor­tu z audy­tu orga­ni­za­cji, okre­śle­nia biz­ne­so­we­go celu pro­jek­tu i na tej pod­sta­wie, okre­śle­niu doce­lo­wej posta­ci (mecha­ni­zmu dzia­ła­nia) orga­ni­za­cji czy­li jej doce­lo­we­go mode­lu. Pośrednim eta­pem jest model ide­al­nej posta­ci doce­lo­wej oraz stu­dium wyko­nal­no­ści tego ide­ału . Produktem osta­tecz­nym jest kom­pro­mis poka­za­ny poniżej:

Pierwszym eta­pem jest więc okre­śle­nie sta­nu ide­al­ne­go, dru­gim, oce­na moż­li­wo­ści jego osią­gnię­cia i pod­ję­cie decy­zji o osta­tecz­nym zakre­sie pro­jek­tu (to wyma­ga­nia na roz­wią­za­nie). Ideał jest czę­sto wyma­ga­niem, stan moż­li­wy to Koncepcja Wdrożenia opra­co­wa­na przez dostaw­cę (to on opra­co­wu­je stu­dium wyko­nal­no­ści wymagań).

Podstawowym narzę­dziem w toku prac jest tak zwa­ne mode­lo­wa­nie. Stosuję stan­dard doku­men­ta­cyj­ny zna­ny jako MDA/MDE (ang. Model Driven Architecture, Model Driven Engineering, więc w MDA…). Wszystkie śred­nie i duże pro­jek­ty reali­zu­ję meto­da ite­ra­cyj­no-przy­ro­sto­wą (patrz tak­że opis poję­cia sto­żek niepewności).

Etapy projektu

Projekt reali­zo­wa­ny zgod­nie z MBSE (Model Driven System Engineering) ma nastę­pu­ją­cą strukturę:

Nazwy i cele klu­czo­wych eta­pów pra­cy Analityka Projektanta :

Praktycznie wszyst­kie moje pro­jek­ty mają podob­ny scenariusz:

1. Analityk jest w pro­jek­cie infor­ma­tycz­nym jak archi­tekt w pro­jek­cie budow­la­nym . Produktem Analizy Biznesowej jest model, któ­ry opi­su­je cel pro­jek­tu, mecha­nizm dzia­ła­nia orga­ni­za­cji, ale bez zbęd­nych deta­li. Stanowi sobą pew­ną ide­ali­za­cję orga­ni­za­cji . Produktem są Wymagania Biznesowe .
2. Na pod­sta­wie Wymagań Biznesowych okre­śla­ny jest zakres pro­jek­tu (Przypadki uży­cia) i powsta­je Opis Techniczny Rozwiązania zwa­ny tak­że PIM , zawie­ra­ją­cy mię­dzy inny­mi model reali­za­cji logi­ki biz­ne­so­wej i prze­twa­rza­nia infor­ma­cji oraz archi­tek­tu­rę inte­gra­cji sys­te­mu . Projekt ten jest wyma­ga­niem (PIM) wobec opro­gra­mo­wa­nia .
3. Wybór dostaw­ców.
4. Nadzór autor­ski w toku prac wdro­że­nio­wych Wykonawcy.

CIM (Computation Independent Model) Audyt i Model Biznesowy organizacji

CIM to model biz­ne­so­wy abs­tra­hu­ją­cy od tech­no­lo­gii. Jego celem jest zro­zu­mie­nie mecha­ni­zmów dzia­ła­nia orga­ni­za­cji. Stosowane prze­ze mnie meto­dy opar­te są na ana­li­zie fak­tów (doku­men­tów) i opra­co­wa­niu mode­lu ich powsta­nia (pro­ce­sy biz­ne­so­we) .

Ten etap jest reali­zo­wa­ny jako audyt oraz pro­jekt ana­li­zy i reor­ga­ni­za­cji. Został opi­sa­ny osob­no jako Analiza i opra­co­wa­nie Architektury Biznesowej orga­ni­za­cji.

PIM (Platform Independent Model) Opracowanie Projektu Technicznego czyli projektowanie rozwiązania

Przypadki Użycia to opis z per­spek­ty­wy użyt­kow­ni­ka, ich spe­cy­fi­ka­cja to model PIM: opis tech­nicz­ny. Jest to model opi­su­ją­cy archi­tek­tu­rę i logi­kę dzia­ła­nia wyma­ga­ne­go roz­wią­za­nia (dedy­ko­wa­ne­go modu­łu). Tak opra­co­wa­na doku­men­ta­cji chro­ni tak­że know-how Zamawiającego.

Projektowanie archi­tek­to­nicz­ne jest dzia­łal­no­ścią inte­lek­tu­al­ną, w któ­rej archi­tekt prze­cho­dzi od abs­trak­cji do rze­czy­wi­sto­ści. W tym pro­ce­sie, abs­trak­cja repre­zen­tu­je logicz­ne rozu­mo­wa­nie w jaki spo­sób for­ma archi­tek­to­nicz­na jest skon­fi­gu­ro­wa­na lub ustruk­tu­ry­zo­wa­na, pod­czas gdy rze­czy­wi­stość odno­si się do osta­tecz­nej for­my fizycz­nej. Diagramy sta­ją się inte­gral­ną czę­ścią pro­jek­tu kon­cep­cyj­ne­go ponie­waż pośred­ni­czą pomię­dzy tymi dwo­ma sferami. 

Od daw­na wia­do­mo, że rosną­ca zło­żo­ność opro­gra­mo­wa­nie nie daje już szans czło­wie­ko­wi na napi­sa­nie kodu pro­gra­mu bez­błęd­nie za pierw­szym razem. Luka pomię­dzy wyma­ga­nia­mi a dzia­ła­ją­cym kodem rośnie i będzie rosła. Dlatego od daw­na lukę tę wypeł­nia się eta­pem mode­lo­wa­nia, któ­re nie narzu­ca tech­no­lo­gii imple­men­ta­cji, uwzględ­nia moż­li­wość mie­sza­nia dostęp­nych na ryn­ku goto­wych kom­po­nen­tów, a na eta­pie pro­to­ty­po­wa­nia jest wie­lo­krot­nie tań­sze tań­sze od kodowania,

Projekt rozwiązania jako Specyfikacja Wymagań

?First, solve the pro­blem. Then, wri­te the code. ? ? John Johnson

Najpierw powsta­je tak zwa­na Architektura Wysokiego Poziomu (ang. HLD, High-Level Design) dla cało­ści pro­jek­tu. Tam gdzie wyma­ga­ne będa dedy­ko­wa­ne modu­ły, pro­jekt jest uzu­peł­nia­ny o Architekturą Niskiego Poziomu (amg. LLD, Low-Level Design) czy­li pro­jekt tech­nicz­ny (nadal tyl­ko logi­ka). Są to dwie co naj­mniej iteracje. 

Etap pro­jek­to­wa­nia roz­wią­za­nia jest więc reali­zo­wa­ny zawsze (jest zale­ca­ny), gdy celem jest wdro­że­nie opro­gra­mo­wa­nia. Także dla­te­go, że może sie oka­zać, że więk­szość, a bywa że 100%, tego co potrze­bu­je­my (wie­my co bo mamy już model) moż­na już kupić na ryn­ku. Taki model sta­je wyma­ga­niem dla dostaw­cy systemu. 

Tu zno­wu przy­to­czę dia­gram obra­zu­ją­cy kolej­ne war­stwy mode­lo­wa­nia :

Mając już model biz­ne­so­wy (w tym mode­le pro­ce­sów biz­ne­so­wych) i wyma­ga­nia biz­ne­so­we (enter­pri­se con­text) spe­cy­fi­ku­je­my wyma­ga­ne usłu­gi apli­ka­cyj­ne (busi­ness servi­ces). Powstaje zakres pro­jek­tu. Jest doku­ment opi­su­ją­cy usłu­gi apli­ka­cji, zawie­ra­ją­cy: spe­cy­fi­ka­cję usług, powią­za­nych z nimi doku­men­tów, mapo­wa­nie ich na model pro­ce­sów biz­ne­so­wych, reali­zo­wa­ne wyma­ga­nia biz­ne­so­we (dostar­czo­ne przez zama­wia­ją­ce­go). Produktem tego eta­pu jest opra­co­wa­nie zgod­ne ze spe­cy­fi­ka­cją Model Driven Architecture/Computation Independent Model (źr. www​.omg​.org/​m​da/), etap ten (jako opra­co­wa­nie) sta­no­wi wynik trans­for­ma­cji mode­lu biz­ne­so­we­go na usłu­gi apli­ka­cyj­ne (jej przy­pad­ki użycia).

Usługi apli­ka­cji to kon­tekst sys­te­mu wyra­żo­ny jako opis jako czar­nej skrzyn­ki, co mode­lu­je­my jako przy­pad­ki uży­cia sys­te­mu. Praktyka poka­zu­je, że sam opis czar­nej skrzyn­ki nie sta­no­wi spe­cy­fi­ka­cji sys­te­mu, dla­te­go w inży­nie­rii (opro­gra­mo­wa­nia tak­że) sto­su­je się zasa­dę: model jako spe­cy­fi­ka­cja (MBSE: ang. Model-Based System Engineering) . Innymi sło­wy spe­cy­fi­ko­wa­nie wyma­gań na sys­tem pole­ga na jego zapro­jek­to­wa­niu, a pro­jekt ten jest odpo­wie­dzią na wyma­ga­nia biznesowe. 

Projekt sys­te­mu to model opi­su­ją­cy struk­tu­rę (archi­tek­tu­rę) i zacho­wa­nia. Zachowania sys­te­mu to jego reak­cje na bodź­ce z zewnątrz, to jego przy­pad­ki użycia. 

Dane to informacje dla człowieka

Kluczowym ele­men­tem tego opi­su są struk­tu­ry doku­men­tów wyra­żo­ne w spo­sób sformalizowany: 

Zawierają one opis spo­so­bu reali­za­cji więk­szo­ści wyma­gań biz­ne­so­wych (np. jeże­li ​„sys­tem ma pozwa­lać na kon­tro­le wyko­rzy­sta­nia urlo­pów” to zna­czy, że wnio­sek urlo­po­wy powi­nien zawie­rać dane: typ urlo­pu oraz licz­ba dni, co nale­ży udo­ku­men­to­wać jak wyżej). Więcej w arty­ku­le Dokumentowani przy­pad­ków uży­cia.

Jeżeli oka­że się, że nie zaofe­ro­wa­no pro­duk­tu ist­nie­ją­ce­go już na ryn­ku (lub nie speł­nia­ją one wyma­gań w 100%), to zna­czy że powsta­ną dedy­ko­wa­ne kom­po­nen­ty. Jest to sytu­acja, w któ­rej mecha­nizm (logi­ka biz­ne­so­wa) wybra­ne­go obsza­ru dzia­ła­nia orga­ni­za­cji jest uni­kal­na, bar­dzo czę­sto mecha­nizm ten sta­no­wi chro­nio­ny know-how tej orga­ni­za­cji. W takiej sytu­acji powsta­je pro­jekt tech­nicz­ny tego kom­po­nen­tu, a od wyko­naw­cy ocze­ki­wa­na jest ofer­ta na wyko­na­nie implementacji. 

(Dalsza część jest prze­zna­czo­na tak­że dla dostaw­ców i wyko­naw­ców oprogramowania)

Programming is not sole­ly abo­ut con­struc­ting software?programming is abo­ut desi­gning software. 

(Programowanie nie doty­czy wyłącz­nie kon­stru­owa­nia opro­gra­mo­wa­nia – pro­gra­mo­wa­nie doty­czy pro­jek­to­wa­nia opro­gra­mo­wa­nia. , więc od nie­daw­na jestem programistą 🙂 )

Poprzedzanie pro­gra­mo­wa­nia pro­jek­to­wa­niem jest klu­czo­wym eta­pem obni­ża­ją­cym ryzy­ko pro­jek­tu .

„Niezależnie od tego ile prze­pro­wa­dzisz roz­mów z mistrza­mi gry w bilar­da i ile godzin fil­mów nakrę­cisz nad sto­łem bilar­do­wym, nie zbli­żysz się nawet do stwo­rze­nia dość dobrej gdy w bilar­da. Jednak wystar­czy, poświę­cić czas na zro­zu­mie­nie i zapi­sa­nie praw fizy­ki rzą­dzą­cych ruchem kul na sto­le bilar­do­wym, by napi­sać grę dosko­na­łą”.  

Projekt archi­tek­tu­ry apli­ka­cji to tak­że wyma­ga­nie: wyma­ga­my dostar­cze­nia tego co zapro­jek­to­wa­no. Nie jest to deta­licz­ny pro­jekt opro­gra­mo­wa­nia czy pro­ce­dur, jest to opis archi­tek­tu­ry opro­gra­mo­wa­nia (sys­te­mu IT), ocze­ki­wa­nej (ide­ali­za­cja) logi­ki biz­ne­so­wej mecha­ni­zmu jego działania. 

Co do zasa­dy pro­jek­to­wa­na jest tak zwa­na archi­tek­tu­ra wyso­kie­go pozio­mu (model PIM wg. OMG​.org/​MDA), czy­li sys­tem zło­żo­ny z dzie­dzi­no­wych kom­po­nen­tów, ich inte­gra­cja, model infor­ma­cyj­ny. Model infor­ma­cyj­ny to opis zawar­to­ści (struk­tur) doku­men­tów ujaw­nio­nych w pro­ce­sach w Analizie Biznesowej, logi­ka popraw­no­ści danych na doku­men­tach oraz logi­ka wią­żą­ca doku­men­ty mię­dzy sobą. 

Dedykowane moduły – add-on’s

Wdrożenie w fir­mie jed­ne­go mono­li­tu, czy­li sys­te­my ERP speł­nia­ją­ce­go wszyst­kie wyma­ga­nia, jest prak­tycz­nie nie­moż­li­we, a jego kasto­mi­za­cja są naj­czę­ściej kata­stro­fal­ne dla nie­go. Dlatego powszech­na prak­ty­ką jest inte­gro­wa­nie z nim dedy­ko­wa­nych modu­łów kupo­wa­nych na ryn­ku lub reali­zo­wa­nych jako dedykowane:

Czym jest moduł dodat­ko­wy w sys­te­mie ERP? W skró­cie, jest to skład­nik opro­gra­mo­wa­nia, któ­ry zapew­nia dodat­ko­we moż­li­wo­ści, któ­re roz­sze­rza­ją i inte­gru­ją się z pakie­tem pod­sta­wo­wym ofe­ro­wa­nym przez dostaw­cę ERP. Czasami orga­ni­za­cje wybie­ra­ją modu­ły dodat­ko­we od róż­nych dostaw­ców, co jest uwa­ża­ne za naj­lep­sze podejście.

https://​www​.pano​ra​ma​-con​sul​ting​.com/​w​h​a​t​-​i​s​-​a​d​d​-​o​n​-​m​o​d​u​l​e​-​i​n​-​e​rp/

W przy­pad­ku gdy na rynek nie ofe­ru­je goto­we­go roz­wią­za­nia (wie­le firm ma swo­ją spe­cy­fi­kę) pozo­sta­je zapro­jek­to­wa­nie go i implementacja. 

Programowanie nie pole­ga już wyłącz­nie na pisa­niu kodu, pro­gra­mo­wa­nie pole­ga na pro­jek­to­wa­niu. .

Projekt dedy­ko­wa­ne­go opro­gra­mo­wa­nia to tak zwa­ny Opis Techniczny Rozwiązania to tak zwa­ny model PIM (ang. Platform Independent Model) i jest to – ten pro­jekt – wyma­ga­nie. Stanowi on spe­cy­fi­ka­cję usług jakich ocze­ku­je się od opro­gra­mo­wa­nia oraz opis logi­ki jaką ma ono reali­zo­wać (dokład­niej­szy opis w tek­ście Analiza Biznesowa i Opis Techniczny Oprogramowania Dedykowanego).

Przypadki uży­cia, wypro­wa­dza­ne z mode­li pro­ce­sów biz­ne­so­wych, są dodat­ko­wo doku­men­to­wa­ne z uży­ciem sce­na­riu­szy, te zaś wyko­rzy­stu­ją kom­po­nen­ty reali­zu­ją­ce logi­kę biz­ne­so­wą (tak zwa­ny model dzie­dzi­ny). Poniżej struk­tu­ra mode­li (per­spek­ty­wy) jakie powsta­ją (patrz tak­że pro­ces OMG SPEM):

Model logi­ki apli­ka­cji poka­za­ny powy­żej to zgod­ny z podej­ściem MDA/MDE, jest to pro­jekt logi­ki i archi­tek­tu­ry przy­szłej apli­ka­cji (w nota­cji UML). Całość jest wyko­na­na w czy­tel­ny dla adre­sa­ta spo­sób (niu­an­se nota­cji musi znać autor dia­gra­mów, ich odbior­com wystar­czy opi­sa­na legen­da symboli).

Tworzenie kodu obej­mu­je wie­le pozio­mów abs­trak­cji, pro­wa­dzą­cych od wyma­gań do kodu. Posiadanie abs­trak­cyj­nych kon­cep­cji mode­lo­wa­nia dostęp­nych jako wyso­ko­po­zio­mo­we kon­struk­cje pro­gra­mi­stycz­ne poma­ga zde­fi­nio­wać kod i upew­nić się, że kom­po­nen­ty opro­gra­mo­wa­nia zacho­wu­ją się w ocze­ki­wa­ny spo­sób. Istnieje luka, któ­rej nie moż­na wypeł­nić zwy­kły­mi meto­da­mi pro­gra­mo­wa­nia, ale któ­rą moż­na wypeł­nić, jeśli pro­gra­mo­wa­nie jest wspie­ra­ne przez odpo­wied­nie ramy mode­lo­wa­nia (meto­dę pro­jek­to­wa­nia i ana­li­zy oraz język).

Metody obiek­to­we mają ogrom­ne zale­ty, są zna­ne od lat, są sto­so­wa­ne… są mało popu­lar­ne bo są trud­ne … ale ja robię to od 20 lat… 

Opis bar­dziej tech­nicz­ny oraz przy­kła­do­wą spe­cy­fi­ka­cję znaj­dzie­cie Państwo na stro­nie Analiza, wyma­ga­nia i uspraw­nia­nie orga­ni­za­cji czy­li MBSE. Omówiony przy­kład OPZ dla admi­ni­stra­cji publicz­nej na stro­nie Generator Ofert. Przykładowy doku­ment pro­jek­to­wy i to jak powsta­wał na stro­nie Biblioteka.

Podsumowanie

• wyma­ga­nia funk­cjo­nal­ne są doku­men­to­wa­ne jako usłu­gi apli­ka­cji (jej przy­pad­ki uży­cia) i for­mu­la­rze (patrz Projekt apli­ka­cji)
• w opi­sach for­mu­la­rzy i doku­men­tów posłu­gu­ję się stan­dar­do­wo ich tre­ścią i struk­tu­rą (XML),
• komu­ni­ka­cja ze mną w toku nad­zo­ru autor­skie­go i roz­wo­ju odby­wa się z pomo­cą moje­go repo­zy­to­rium: Postmania.
• osta­tecz­ne decy­zje i szcze­gó­ły powsta­ją w toku Nadzoru Autorskiego (patrz Nadzór Autorski)

(na pod­sta­wie: P.Sienkiewicz, L.Koźmiński, P.Miller, OMG​.org)

Sku­tecz­ny opis wyma­gań to spe­cy­fi­ka­cja wyra­żo­na języ­kiem o skoń­czo­nej licz­bie pojęć, pozwa­la­ją­ca pro­gra­mi­stom ?wlać? ją do kolej­nej ?for­mal­nej for­my? jaką jest język pro­gra­mo­wa­nia. (patrz: Logika wnio­sko­wa­nia deduk­cyj­ne­go czy­li czym jest popraw­na ana­li­za i mode­lo­wa­nie)

Tu pole­cam refe­rat na temat pro­jek­to­wa­nia: jak i po co. 

Wybór dostawców i umowa

Ten etap to ogło­sze­nie (roze­sła­nie) zapy­ta­nia ofer­to­we­go. Standardowo w pierw­szym kro­ku ogła­szam RFI (zapy­ta­nie o goto­wość do zło­że­nia ofer­ty) bez poda­nia danych Zamawiającego, na moich pro­fi­lach w mediach spo­łecz­no­ścio­wych (mam kil­ka tysię­cy obser­wu­ją­cych osób i firm). Firmy, któ­re zgło­si­ły się w tym eta­pie są oce­nia­ne przez Zamawiającego, któ­ry wybie­ra kil­ka. Wybranym fir­mom prze­ka­zy­wa­ne jest peł­ne zapy­ta­nie RFP z Opisem Przedmiotu Zamówienia Przedmiotem Zamówienia są okre­ślo­ne w zapy­ta­niu usłu­gi (np. wdro­że­nie, szko­le­nia itp.) oraz wynik Analizy Biznesowej i Opis Techniczny Oprogramowania) . Wybierany jest Wykonawca, któ­ry zło­żył naj­ko­rzyst­niej­szą ofer­tę, kry­te­ria­mi są zawsze cena, kom­pe­ten­cje i doświad­cze­nie oraz zaofe­ro­wa­na technologia.

Na tym eta­pie, zgod­nie z Art.634 KC, Wykonawca powi­nien zgło­sić wszel­kie ewen­tu­al­ne swo­je zastrze­że­nia do mate­ria­łów (doku­men­ta­cja) jakie otrzy­mał, i robić to na bie­żą­co tak­że w toku reali­za­cji pro­jek­tu, jeże­li otrzy­ma jakie­kol­wiek nowe materiały.

Ogłoszenia i zapy­ta­nia ofer­to­we moich klien­tów (w tym tak­że Opis Przedmiotu Zamówienia) stan­dar­do­wo wysy­łam na listę sub­skry­ben­tów moje­go ser­wi­su.

Podpisanie Umowy i nadzór autorski

Wyma­ga­nia na począt­ku pro­jek­tu nie są osta­tecz­nym pro­duk­tem analityka

Wszystkie deta­le tech­no­lo­gicz­ne opra­co­wu­je Wykonawca, któ­ry skła­da­jąc ofer­tę zade­kla­ro­wał, że dostar­czy roz­wią­za­nie zgod­ne z Projektem Technicznym, a w swo­im doku­men­cie, jakim jest Koncepcja Wdrożenia, Wykonawca powi­nien opi­sać to, jak zre­ali­zu­je pro­jekt z uży­ciem tech­no­lo­gii jaką zaoferował.

Koncepcja nad­zo­ru autor­skie­go zakła­da, że pro­jek­tant (autor), na zle­ce­nie inwe­sto­ra, pro­jek­tu­je roz­wią­za­nie a następ­nie, po wybo­rze wyko­naw­cy, nad­zo­ru­je reali­za­cję roz­wią­za­nia i uzu­peł­nia treść pro­jek­tu o wyma­ga­ne szcze­gó­ły, odpo­wia­da­jąc na pyta­nia zarów­no inwe­sto­ra jak i wyko­naw­cy. Dokumentacji pro­jek­to­wej nie da się ​„zamro­zić” na czas trwa­nia nie raz wie­lo­mie­sięcz­ne­go pro­jek­tu. Dlatego więk­sze pro­jek­ty są reali­zo­wa­ne kom­po­nent po kom­po­nen­cie w pętli iteracyjno-przyrostowej.

Po zakoń­cze­niu imple­men­ta­cji, uzu­peł­nia­ne w toku pro­jek­tu, powią­za­ne z sobą Projekt roz­wią­za­nia (uzu­peł­nia­ny w toku nad­zo­ru autor­skie­go) i Opis imple­men­ta­cji (uzu­peł­nia­ny przez Wykonawcę), sta­no­wią kom­plet­ną doku­men­ta­cję dostar­czo­ne­go pro­duk­tu. Całość zobra­zo­wa­no na poniż­szym diagramie:

Dostawca roz­wią­za­nia nie robi żad­nej swo­jej ana­li­zy przed-wdro­że­nio­wej. Na pod­sta­wie otrzy­ma­nych mate­ria­łów opra­co­wu­je Koncepcję Wdrożenia, któ­rą reali­zu­je w toku projektu. 

Praktyka poka­zu­je, że pro­ble­my z wdro­że­niem sys­tem ERP są powo­do­wa­ne, przez zało­że­nie kupu­ją­ce­go, że dostaw­ca ma doświad­cze­nie i wie jak wdro­żyć swój sys­tem. Problem w tym, że dostaw­ca w dobrej wie­rze, wdro­ży to co ma, osob­ną kwe­stia jest upew­nie­nie się, że to co ma jest tym cze­go potrze­bu­je­my. To dla­te­go wybór dostaw­cy roz­wią­za­nia powi­nien być ostat­nim, a nie pierw­szym eta­pem pro­jek­tu przy­go­to­wa­nia do wdro­że­nia. Istotne jest tak­że, co poka­za­no na powyż­szym dia­gra­mie, ści­słe roz­dzie­le­nie kodu licen­cjo­no­wa­ne­go od wytwo­rzo­ne­go w toku wdro­że­nia (patrz: Kastomizacja).

Polecam tak­że arty­kuł Wymagania umar­ły…^?1?

Dodatek: Podmioty publiczne i PZP

Na zakoń­cze­nie kil­ka słów o zamó­wie­niach publicz­nych, sku­pię jed­nak wyłącz­nie na kwe­stiach usług jakie oso­bi­ście ofe­ru­ję. Jestem gorą­cym zwo­len­ni­kiem poniż­szej tezy:

Kryteria poza­ce­no­we nazy­wam pozor­ny­mi, dla­te­go, że na eta­pie oce­ny ofert są one w zasa­dzie nie­moż­li­we do zwe­ry­fi­ko­wa­nia Niestety w prze­tar­gach na usłu­gi IT kry­te­ria poza­ce­no­we czę­sto nicze­mu nie słu­żą, a osta­tecz­nie i tak decy­du­je cena.

(mec Monika Wandzel, źr.: Jak zwe­ry­fi­ko­wać jakość ofe­ren­tów?)

Dlatego zga­dzam się z opi­nia­mi mówią­cy­mi, że naj­sku­tecz­niej­szą meto­dą wyra­ża­nia wyma­gań na roz­wią­za­nie jest pro­jekt tego roz­wią­za­nia, a nie opis jego cech. 

Od wie­lu lat moimi zle­ce­nio­daw­ca­mi są tak­że pod­mio­tu publicz­ne (mię­dzy inny­mi: PFRON, Urząd Miasta Warszawy, PSE, KGHM SA, Żandarmeria Wojskowa, Kancelaria Senatu). Przetargi publicz­ne z zasa­dy są pro­jek­ta­mi okre­śla­ny­mi jako ​„fixed-pri­ce” (cał­ko­wi­ty koszt okre­śla­ny w momen­cie zamó­wie­nia) co czy­ni je trud­niej­szy­mi na eta­pie przy­go­to­wa­nia. Pojawiają się publi­ka­cje na temat sto­so­wa­nia ​„zwin­nych metod w admi­ni­stra­cji publicz­nej”, fir­mo­wa­ne nawet przez zna­ne kan­ce­la­rie praw­ne, jed­nak prak­ty­ka poka­zu­je, że two­rze­nie OPZ w posta­ci ​„otwar­te­go zarzą­dzal­ne­go zakre­su pro­jek­tu” nie roz­wią­zu­je prak­tycz­nie żad­nych pro­ble­mów, za to stwa­rza ogrom­ne ryzy­ko prze­ję­cia zarzą­dza­nia zakre­sem pro­jek­tu przez dostaw­cę („dosta­niesz to co chce Ci dostar­czyć dostaw­ca a nie to cze­go potrze­bu­jesz”), Jeden z moich komen­ta­rzy na ten temat tu: Agile w PZP (2017).

W Czerwcu 2020 roku, Urząd Zamówień Publicznych opu­bli­ko­wał doku­ment: POSTĘPOWANIE O UDZIELENIE ZAMÓWIENIA PUBLICZNEGO NA SYSTEM INFORMATYCZNY. We wstę­pie auto­rzy piszą: 

Zakup sys­te­mów infor­ma­tycz­nych to zło­żo­ny pro­ces, któ­ry wyma­ga od zama­wia­ją­cych rze­tel­ne­go przy­go­to­wa­nia. Istotny wpływ na powo­dze­nie zamie­rze­nia inwe­sty­cyj­ne­go zwią­za­ne­go z zama­wia­nym sys­te­mem IT ma wie­le czyn­ni­ków, wśród któ­rych przy­kła­do­wo moż­na wymie­nić zna­jo­mość roz­wią­zań IT wystę­pu­ją­cych na ryn­ku, aktu­al­ność posia­da­nych przez zama­wia­ją­ce­go w tym zakre­sie infor­ma­cji, czy też świa­do­mość co do moż­li­wo­ści wła­snych zama­wia­ją­ce­go w zakre­sie pra­wi­dło­we­go i wyczer­pu­ją­ce­go przy­go­to­wa­nia postę­po­wa­nia na zakup sys­te­mu IT. Prawidłowe przy­go­to­wa­nie zama­wia­ją­ce­go do prze­pro­wa­dze­nia postę­po­wa­nia, tj. na eta­pie jesz­cze przed wsz­czę­ciem postę­po­wa­nia o udzie­le­nie zamó­wie­nia publicz­ne­go, pozwa­la mini­ma­li­zo­wać pro­ble­my, jakie mogą wystą­pić w pro­wa­dzo­nym w przy­szło­ści postę­po­wa­niu, a tak­że w trak­cie reali­za­cji oraz eks­plo­ata­cji przed­mio­tu zamó­wie­nia, szcze­gól­nie w przy­pad­ku naby­wa­nia zło­żo­nych roz­wią­zań technologicznych.

Jak widać zwra­ca się szcze­gól­ną uwa­gę na kom­pe­ten­cje wyma­ga­ne do opra­co­wa­nia nie­zbęd­nej doku­men­ta­cji oraz na wewnętrz­ne przy­go­to­wa­nie do przy­szłe­go wdro­że­nia i eks­plo­ata­cji sys­te­mu infor­ma­tycz­ne­go. Autorzy zwra­ca­ją uwa­gę, że:

…choć obo­wią­zek prze­pro­wa­dze­nia ana­li­zy potrzeb i wyma­gań, o któ­rej mowa w art. 83 usta­wy PZP doty­czy tyl­ko nie­któ­rych zama­wia­ją­cych i postę­po­wań (tzn. nie doty­czy zamó­wień o war­to­ściach nie­prze­kra­cza­ją­cych pro­gów unij­nych oraz zamó­wień sek­to­ro­wych), to jed­nak prze­pro­wa­dze­nie ana­lo­gicz­ne­go pro­ce­su może być uza­sad­nio­ne tak­że w wypad­kach, w któ­rych nie jest on obligatoryjny.

Ważny zapis:

W nowej usta­wie PZP okre­ślo­ny został próg war­to­ścio­wy wyzna­cza­ją­cy obo­wią­zek sto­so­wa­nia przez zama­wia­ją­ce­go prze­pi­sów tej usta­wy. Obowiązek ten powsta­je, jeże­li war­tość zamó­wie­nia osią­gnie ten próg. Zgodnie z prze­pi­sem art. 2 ust. 1 pkt 1 usta­wy PZP, jej prze­pi­sy sto­su­je się, co do zasa­dy, do udzie­la­nia zamó­wień publicz­nych oraz orga­ni­zo­wa­nia kon­kur­sów, któ­rych war­tość jest rów­na lub prze­kra­cza kwo­tę 130 000 zł, przez zama­wia­ją­cych publicznych.

W dal­szej czę­ści doku­men­tu czytamy: 

Zamawiający powi­nien zwe­ry­fi­ko­wać kom­pe­ten­cje wła­sne­go zespo­łu i spraw­dzić, czy dys­po­nu­je spe­cja­li­sta­mi, któ­rzy: (-) przy­go­tu­ją opis przed­mio­tu zamó­wie­nia w spo­sób wystar­cza­ją­co pre­cy­zyj­ny i dokład­ny, a tak­że uwzględ­nia­ją­cy ade­kwat­ne potrze­by zama­wia­ją­ce­go, naj­now­sze stan­dar­dy i wytycz­ne, nor­my bran­żo­we, w tym tak­że w zakre­sie cyber­bez­pie­czeń­stwa sys­te­mów IT, (-) zapew­nią spraw­ną reali­za­cję postę­po­wa­nia zamó­wie­nio­we­go (np. w zakre­sie odpo­wie­dzi na pyta­nia wyko­naw­ców, oce­ny ofert,) (-) zapew­nią nale­ży­tą reali­za­cję umo­wy zawar­tej w ramach zamówienia.

Przygotowanie do prze­tar­gu (ana­li­za potrzeb i opra­co­wa­nie OPZ), wspar­cie w toku postę­po­wa­nia oraz rocz­ny nad­zór autor­ski (wie­le wdro­żeń sys­te­mów infor­ma­tycz­nych, jakie pro­wa­dzi­łem, mie­ści sie w gra­ni­cach roku od pod­pi­sa­nia umo­wy z dostaw­cą), to w moim przy­pad­ku, to usłu­ga o war­to­ści bar­dzo czę­sto poni­żej 130 tys. zł, wraz z kosz­tem. Oznacza to, że może­cie Państwo zle­cić mi taką usłu­gę (przy­go­to­wa­nie do prze­tar­gu) bez stra­ty cza­su na kon­kur­sy (bez nad­zo­ru autor­skie­go jest to koszt 40 tys. zł). Wystarczająca jest oce­na dorob­ku, kom­pe­ten­cji i doświad­cze­nia oraz (co bar­dzo waż­ne) pod­pi­sa­nie oświad­cze­nia o bra­ku kon­flik­tu interesu: 

Zamawiający musi więc pamię­tać o tre­ści art. 85 oraz art. 108 ust. 1 pkt 6 usta­wy PZP, któ­re naka­zu­ją prze­ciw­dzia­łać sytu­acji, w któ­rej udział dane­go wyko­naw­cy w przy­go­to­wa­niu postę­po­wa­nia zakłó­ci kon­ku­ren­cję, a jeże­li tego zakłó­ce­nia wyeli­mi­no­wać się nie da, naka­zu­ją wyklu­czyć z postę­po­wa­nia wyko­naw­cę, któ­ry był zaan­ga­żo­wa­ny przy przy­go­to­wa­niu postępowania.

Autorzy zale­ceń piszą także:

Wobec dyna­mi­ki zmian zacho­dzą­cych w zakre­sie roz­wią­zań infor­ma­tycz­nych, zama­wia­ją­cy powi­nien szcze­gól­nej uwa­dze pod­dać aktu­al­ność posia­da­nych infor­ma­cji. Mając na uwa­dze powyż­sze, istot­ne jest rów­nież to, aby zama­wia­ją­cy pla­no­wał prze­pro­wa­dze­nie postę­po­wa­nia w taki spo­sób, aby zapo­bie­gać prze­wle­kło­ści pro­ce­su zaku­po­we­go, gdyż powo­du­je ona ryzy­ko dez­ak­tu­ali­za­cji opra­co­wa­nej dokumentacji.

Jednak ​„część for­mal­na SWZ” powin­na być przy­go­to­wa­nia przez Zamawiającego i jego służ­by praw­ne. Autorzy zwra­ca­ją tu uwa­gę, że: 

Nie moż­na też zapo­mnieć o tre­ści pro­jek­to­wa­nych posta­no­wień umo­wy ? ich przy­go­to­wa­nie bez dogłęb­nej wie­dzy o przed­mio­cie zamó­wie­nia oraz prze­bie­gu jego reali­za­cji, jest błę­dem, na któ­ry nie może sobie pozwo­lić żaden zamawiający.

Poniżej treść oma­wia­ne­go dokumentu:

Polecam lek­tu­rę powyż­sze­go doku­men­tu w całości. 

Dodatek: Opis odwoływania się, w Koncepcji Wdrożenia, do wymagań

Każdy dostaw­ca roz­wią­za­nia, jako pierw­szy pro­dukt w reali­za­cji Umowy (lub na eta­pie ofer­to­wa­nia) musi (powi­nien) opra­co­wać doku­ment Koncepcja Wdrożenia (stu­dium wyko­nal­no­ści, ana­li­za fit-gap, lub odpo­wied­nik), opi­su­ją­cy to jak pro­po­nu­je, wdra­ża­jąc ofe­ro­wa­ny pro­dukt, zre­ali­zo­wać Wymagania Zamawiającego.

„Analiza Biznesowa i Projekt Techniczny Rozwiązania” (dalej Analiza) zawie­ra mię­dzy inny­mi roz­dzia­ły: Model Procesów Biznesowych oraz Model Kontekstowy Systemu IT (Zamawiającego). Pierwszy zawie­ra opis dzia­ła­nia orga­ni­za­cji, dru­gi zawie­ra zakres wdro­że­nia w posta­ci listy wyma­ga­nych usług apli­ka­cyj­nych (wyra­żo­nych jako przy­pad­ki uży­cia UML oraz ich spe­cy­fi­ka­cje, to wyma­ga­nia wyra­żo­ne meto­dą MDA/MBSE).

Opis każ­dej wyma­ga­nej usłu­gi apli­ka­cji w Analizie (przy­pad­ki uży­cia) zawiera: 

• kon­tekst i celu jej uży­cia i wska­za­nie jej akto­ra (pra­cow­nik, klient, inny sys­tem itp..),

• sza­blon for­mu­la­rza ekranowego/wydruku i wali­da­cję pól,

• archi­tek­tu­rę i logi­kę reali­za­cji wymia­ny danych z inny­mi for­mu­la­rza­mi i inny­mi apli­ka­cja­mi, jeże­li to wyma­ga­ne (inte­gra­cja).

Dostawca roz­wią­za­nia w tre­ści pro­po­no­wa­nej Koncepcji Wdrożenia (to pro­dukt dostawcy): 

1. albo orga­ni­zu­je ten doku­ment w taki spo­sób, że wska­zu­je w nim jak zre­ali­zu­je każ­dą wyma­ga­ną usłu­gę apli­ka­cji (wte­dy pod­sta­wą spi­su tre­ści Koncepcji Wdrożenia są wyma­ga­ne usłu­gi aplikacji),
2. albo orga­ni­zu­je ten doku­ment w taki spo­sób, że wska­zu­je (przy­wo­łu­je) w np. stan­dar­do­wym opi­sie dostar­cza­ne­go roz­wią­za­nia (np. Instrukcja Obsługi) miej­sca (np. funk­cje apli­ka­cji w menu), któ­re reali­zu­ją okre­ślo­ną, wyma­ga­ną usłu­gę apli­ka­cji (wte­dy pod­sta­wą spi­su tre­ści Koncepcji Wdrożenia jest opis funk­cjo­nal­ny dostar­cza­nej aplikacji). 

Pierwszy przy­pa­dek np.: ​„wyma­ga­na usłu­ga [nazwa usłu­gi: przy­pad­ku uży­cia ] jest reali­zo­wa­na przez [tu wska­za­nie, któ­re stan­dar­do­we funk­cje dostar­cza­ne­go opro­gra­mo­wa­nia ją reali­zu­ją i jak]”.

Drugi przy­pa­dek: ​„Nasze opro­gra­mo­wa­nie ma funk­cje [tu nazwa i opis tej funk­cji], któ­ra reali­zu­je potrze­by opi­sa­ne jako [tu nazwa usłu­gi apli­ka­cji – przy­pa­dek uży­cia – w Analizie]”.

Jeżeli dostar­czo­ne opro­gra­mo­wa­nie w wer­sji stan­dar­do­wej nie reali­zu­je jakiejś wyma­ga­nej w Analizie usłu­gi, powin­na się poja­wić taka infor­ma­cja wraz z pro­po­zy­cją meto­dy roz­sze­rze­nia funk­cjo­nal­no­ści stan­dar­do­wej wer­sji dostar­cza­ne­go opro­gra­mo­wa­nia. Tak zor­ga­ni­zo­wa­ny doku­ment Koncepcji Wdrożenia jest tak­że czę­sto nazy­wa­ny ​„ana­li­zą fit-gap” , tak­że: , , . Patrz tak­że powy­żej: Idealizacja jako meto­da.

Źródła

Zapytanie