Specyfikacja wyma­gań na opro­gra­mo­wa­nie powin­na odzwier­cie­dlać potrze­by zama­wia­ją­ce­go a nie moż­li­wo­ści dostaw­cy. Dostawca opra­cu­je dopie­ro ?Koncepcję wdro­że­nia? czy­li odpo­wie na pyta­nie jak pora­dzi­my sobie z wyma­ga­nia­mi zama­wia­ją­ce­go” (i czy w ogó­le). Czy moż­na wyce­nić coś co nie ist­nie­je? Tak, nie mając spe­cy­fi­ka­cji wyma­gań poproś o ofer­tę dostaw­cę goto­we­go oprogramowania. 🙂

Na pew­nej stro­nie prze­czy­ta­łem cie­ka­wy tekst, nie będę poda­wał źró­dła bo moim celem jest wska­za­nie pew­nych ogól­nych cech takich pro­jek­tów, nie jest moim celem rekla­ma stro­ny, z któ­rej tekst pocho­dzi ani fir­my jej wła­ści­cie­la J.

Tekst pod tytu­łem ?Czym jest ana­li­za przed­wdro­że­nio­wa?? dość dokład­nie opi­su­je co cze­ka nabyw­cę opro­gra­mo­wa­nia wspo­ma­ga­ją­ce­go zarzą­dza­nie, poka­zu­je tak­że pew­ne zało­że­nia jakie przyj­mu­ją dostaw­cy tego rodza­ju opro­gra­mo­wa­nia: pierw­szym jest to, że oce­na przy­dat­no­ści odbę­dzie się po zaku­pie tegoż opro­gra­mo­wa­nia i o tym napi­sze kil­ka słów. Ale po kolei?(cytaty ze stro­ny tego dostaw­cy ozna­czo­no kursywą)

Publikacja powsta­ła w opar­ciu o spe­cy­fi­kę wdro­żeń sys­te­mu XXX, jed­nak zawar­te tutaj stwier­dze­nia moż­na roz­sze­rzyć na ogól­nie rozu­mia­ne wdro­że­nia sys­te­mów informatycznych.

Ogólnie przy­ję­tym stan­dar­dem, któ­ry znaj­du­je zasto­so­wa­nie pod­czas wdro­żeń sys­te­mów infor­ma­tycz­nych jest reali­za­cja pro­jek­tu wg nastę­pu­ją­cych etapów:

1. Analizowanie potrzeb i wymagań,

2. Budowanie kon­cep­cji (wizji roz­wią­zań) dla systemu,

3. Stworzenie (imple­men­ta­cja) rozwiązań,

4. Wdrożenie opra­co­wa­nych rozwiązań.

Co do tego nie mam wąt­pli­wo­ści, zadam jed­nak pyta­nie: kie­dy (po któ­rym eta­pie) powi­nien nastą­pić wybór dostaw­cy i roz­wią­za­nia? Moim zda­niem po punk­cie 2. czy­li wie­my cze­go ocze­ku­je­my a więc pora na wizy­tę w skle­pie. Ktoś może powie­dzieć (i autor tek­stu tak­że tak sądzi), że dobry sys­tem może wszyst­ko więc spo­koj­nie moż­na go kupić od razu. Autor tek­stu (beda­ce­go ofer­tą tego sys­te­mu!) pisze:

Zakres per­so­na­li­za­cji sys­te­mu XXX pozwa­la na swo­bod­ne dosto­so­wy­wa­nie sys­te­mu do indy­wi­du­al­nych potrzeb fir­my. Gdy mowa o per­so­na­li­za­cji sys­te­mu, ter­min ten nale­ży rozu­mieć nie tyl­ko jako wła­ści­wą kon­fi­gu­ra­cję pod­sta­wo­wych para­me­trów w zakre­sie ist­nie­ją­cych rozwiązań.

Po kil­ku krot­nym prze­czy­ta­niu tego frag­men­tu jed­nak nie potra­fię pozbyć się myśli, że zda­nie dru­gie zaprze­cza pierw­sze­mu, co cie­kaw­sze są to fak­tycz­nie sąsia­du­ją­ce zda­nia. Skoro sys­tem pozwa­la swo­bod­ne dosto­so­wy­wa­nie sys­te­mu do indy­wi­du­al­nych potrzeb fir­my (pierw­sze zda­nie) to dla­cze­go jed­nak ozna­cza tyl­ko kon­fi­gu­ra­cję pod­sta­wo­wych para­me­trów w zakre­sie [tyl­ko, przyp.] ist­nie­ją­cych rozwiązań?

Zwracam tu uwa­gę na sfor­mu­ło­wa­nie w zakre­sie ist­nie­ją­cych roz­wią­zań czy­li jeśli cze­goś w roz­wią­za­niu nie ma to nie ma.

Powstanie zaak­cep­to­wa­ne­go doku­men­tu ana­li­zy przed­wdro­że­nio­wej [?]umoż­li­wia zbu­do­wa­nie har­mo­no­gra­mu prac oraz zde­fi­nio­wa­nie kosz­to­ry­su projektu.

Powyższe zda­nie jest dla mnie klu­czo­wym wyzwa­niem inte­lek­tu­al­nym, bo sko­ro tak to na jakiej pod­sta­wie nie­któ­rzy dostaw­cy opro­gra­mo­wa­nia skła­da­ją ofer­ty zawie­ra­ją­ce ter­min i koszt wdro­że­nia tegoż opro­gra­mo­wa­nia, mimo iż ana­li­za przed­wdro­że­nio­wa sta­no­wi pierw­szy punk ofer­ty? Zagmatwane? Jeszcze raz: jak oce­nić ofer­tę na dostar­cze­nie i wdro­że­nie opro­gra­mo­wa­nia, jeże­li ana­li­za przed­wdro­że­nio­wa wcho­dzi w zakres tej ofer­ty czy­li nie zosta­ła wykonana?

Czy mam rację? Otóż autor sam przy­zna­je, że pod­czas ana­li­zy przed­wdro­że­nio­wej i rapor­cie z niej:

nale­ży wymie­nić rów­nież te dzie­dzi­ny dzia­łal­no­ści fir­my, któ­re nie zosta­ną pokry­te przez stan­dar­do­we czy nawet roz­sze­rzo­ne (zmo­dy­fi­ko­wa­ne) modu­ły sys­te­mu XXX.

Jednak sys­tem nie robi wszyst­kie­go? autor zna jed­nak meto­dę docho­dze­nia do prawdy:

Bardzo waż­ny w doku­men­cie ana­li­zy jest opis ist­nie­ją­cych pro­ce­sów biz­ne­so­wych i wyma­gań pod­sta­wo­wych – nie­za­leż­nie od tego, czy obo­wią­zu­ją­cy model pra­cy zosta­nie zacho­wa­ny i odwzo­ro­wa­ny w nowym sys­te­mie czy będzie mody­fi­ko­wa­ny. Opis taki dostar­cza infor­ma­cji o powią­za­niach mię­dzy dzia­ła­mi, ist­nie­ją­cym spo­so­bie opi­su doku­men­tów, nad­rzęd­nych wymo­gach lub ograniczeniach.

Tak więc ten punkt jest w zasa­dzie obo­wiąz­ko­wy? nie­ste­ty wie­le firm pomi­ja go, tak­że nabyw­cy (!)opro­gra­mo­wa­nia, w sytu­acji gdy nale­ży ?obciąć budżet?, ale to jest powszech­nie nazy­wa­ne ?strza­łem we wła­sne kolano?.

wizje [wdro­że­nia – przyp. mój] two­rzy się aby opi­sać np. spo­sób odzwier­cie­dle­nia infor­ma­cji w sys­te­mie XXX lub pro­po­no­wa­ny model obie­gu dokumentów.

Chyba nie da się unik­nąć jed­ne­go: kon­sul­tan­ci dostaw­cy opro­gra­mo­wa­nia opra­cu­ją doku­men­ta­cję o tym ?jak wdro­żyć nasze opro­gra­mo­wa­nie? a nie o tym ?jakie­go opro­gra­mo­wa­nia potrze­bu­je klient?.

Tym samym doku­ment ana­li­zy przed­wdro­że­nio­wej sta­je się ele­men­tem, na któ­rym zosta­ją opar­te budżet i har­mo­no­gram projektu.

Pełna zgo­da, zno­wu jed­nak pyta­nie: w takim razie na jakiej pod­sta­wie przy­go­to­wa­no pier­wot­ną ofer­tę zawie­ra­ją­cą jako pierw­szy punkt tę ana­li­zę bez któ­rej kosz­to­ru wyko­nac nie moż­na? Wykonano jed­nak kosz­to­rys bez ana­li­zy? A jak?

W tym miej­scu nale­ży jed­nak zazna­czyć, że osią­gnię­cie ide­al­ne­go doku­men­tu ana­li­zy, obej­mu­ją­ce­go swym zakre­sem wszyst­kie wyma­ga­nia i skła­do­we pro­jek­tu jest bar­dzo trud­ne. Z naszej prak­ty­ki wyni­ka, że czę­sto wystę­pu­ją sytu­acje takie, gdzie nie wszyst­kie potrze­by zosta­ły wyar­ty­ku­ło­wa­ne lub zosta­ły przed­sta­wio­ne w nie­wła­ści­wym świe­tle – wie­le roz­wią­zań wyma­ga­ło bar­dziej zaawan­so­wa­nych prac niż było to pier­wot­nie zakła­da­ne. Tego typu sytu­acje pocią­ga­ją za sobą zmia­ny w zakre­sie prac, a tym samym przy­czy­nia­ją się do zmian przy­ję­tych har­mo­no­gra­mów i kosztorysów.

Jak widać nie jest to łatwe (lata wdro­żeń i nadal taka prak­ty­ka?), dla­te­go war­to zasta­no­wić się nad wyko­na­niem wia­ry­god­nej i mało ryzy­kow­nej ana­li­zy, ta jed­nak nie jest pro­stą ope­ra­cją pole­ga­ją­cą na wywia­dach z pra­cow­ni­ka­mi. Dobra ana­li­za to peł­ne zro­zu­mie­nie celu biz­ne­sow­go po kon­sul­ta­cjach z zarzą­dem i kadrą kie­row­ni­czą (tez pra­cow­ni­cy ale nie Ci sze­re­go­wi), rze­tel­na ana­li­za orga­ni­za­cji fir­my i jej mode­lu biz­ne­so­we­go. Oddolna wizja pra­cow­ni­ków fir­my rzad­ko kie­dy jest zgod­na z cela­mi biz­ne­so­wy­mi fir­my a skraj­nym (ale poucza­ją­cym) przy­kła­dem mogą być nie­któ­re związ­ki zawo­do­we. Czy wyobra­ża­my sobie pro­jekt wdro­że­nia sys­te­mu ERP, któ­re­go jed­nym z celów jest opty­ma­li­za­cja, opra­co­wa­ny na pod­sta­wie wywia­dów ze związ­ka­mi zawodowymi?

Wielu, może nawet więk­szość, dostaw­ców opro­gra­mo­wa­nia tak pod­cho­dzi do pro­jek­tów. Zapytałem jed­ne­go z nich dla­cze­go nie dzie­lą umo­wy z klien­ta­mi na dwie: umo­wa na ana­li­zę i umo­wa na wdro­że­nie? Na co usły­sza­łem: nie po to nasi han­dlow­cy pono­szą kosz­ty szu­ka­nia klien­tów by ryzy­ko­wać, że po ana­li­zie dosta­wę i wdro­że­nie zro­bi kto inny, do umo­wy wpi­su­je się taki koszt by zaro­bić na wszyst­ko o czym nie wie­my a klient jak usły­szy, że cze­goś nie moż­na to w koń­cu i tak zre­zy­gnu­je. Jest tak­że inna stra­te­gia, prze­tar­go­wa (kolej­ny cytat): Przetargi wygry­wa­my ceną, potem pod­czas ana­li­zy wywa­la­my z zakre­su pro­jek­tu wszyst­ko co pod­no­si kosz­ty żeby zmie­ścić się w budże­cie, klient zwią­za­ny umo­wa z regu­ły to kupu­je bo w pro­jek­cie czę­sto umiesz­cza sze­re­go­wych pra­cow­ni­ków a ci nie dyskutują.

Dlatego, war­to zacząć, od tego by przy­go­to­wać opis nada­ją­cy się do wyko­na­nia wyce­ny. Od dostaw­ców opro­gra­mo­wa­nia i pro­gra­mi­stów wiem, że pro­sta lista wypunk­to­wa­nych wyma­gań nie daje nic podob­nie jak kraw­co­wi nic nie da stwier­dze­nie ?mam 182 cm wzro­stu i chce czar­ny gar­ni­tur?. Dopiero szcze­gó­ło­we pomia­ry, wska­za­nie gatun­ku mate­ria­łu, jego wyma­ga­nej trwa­ło­ści, licz­by kie­sze­ni, odpor­no­ści na warun­ki atmos­fe­rycz­ne itp. pozwa­la na wyce­nę pro­duk­tu krawca.

Specyfikacja wyma­gań powin­na dokład­nie opi­sy­wać pro­ce­sy, to jakie dane i gdzie są potrzeb­ne, z jaki­mi inny­mi sys­te­ma­mi nale­ży się zin­te­gro­wać i wie­le innych, istot­nych z punk­tu widze­nia zama­wia­ją­ce­go i jego infra­struk­tu­ry oraz poten­cjal­nych kosz­tów. Teraz dopie­ro dostaw­ca może doko­nać rze­tel­nej wyce­ny a spe­cy­fi­ka­cja wyma­gań będzie odzwier­cie­dla­ła potrze­by zama­wia­ją­ce­go a nie moż­li­wo­ści dostawcy.

(Zainteresowanym prze­ślę przy­kła­do­we doku­men­ty analizy).

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.