Wymagania na oprogramowanie ERP a analiza przedwdrożeniowa – gdzie różnica?

Pół roku temu napisałem:

Tak więc: naj­pierw ana­li­za tego co i jak robi­my. Potem podział tego na obsza­ry stan­dar­do­we, któ­re obsłu­ży­my narzę­dziem uni­wer­sal­nym, i pozo­sta­łe (któ­rych z regu­ły jest bar­dzo mało ale są bar­dzo waż­ne dla nas) i zrób­my je po swo­je­mu ale nie pakuj­my się w niszo­we lub prze­sta­rza­łe tech­no­lo­gie. Nie dawaj­my tak­że wia­ry w to, że kup­no tego co ma (powie­le­nie tego co robi) nasz kon­ku­rent uczy­ni nas bar­dziej kon­ku­ren­cyj­ny­mi bo prak­ty­ka poka­zu­je coś zupeł­nie odwrot­ne­go. (czy­taj Wymagania na opro­gra­mo­wa­nie ERP wspo­ma­ga­ją­ce zarzą­dza­nie: dwie kup­ki).

Pojawia się jed­nak wie­le kon­tro­wer­sji w samej defi­ni­cji: czym jest pro­jekt o nazwie Analiza wyma­gań na opro­gra­mo­wa­nie a czym pro­jekt Analiza przed­wdro­że­nio­wa oprogramowania?

Kupujemy buciki

Krótki przy­kład z dzie­dzi­ny, któ­rą wie­lu z nas (może nawet więk­szość) zna. Aby kupić buty małe­mu dziec­ku z wie­lu powo­dów nie cią­gnie­my malu­cha po cen­trach han­dlo­wych. Jak jed­nak kupić te buty i nie żało­wać? Rozwiązaniem jest przy­go­to­wa­nie patycz­ka o dłu­go­ści rów­nej dłu­go­ści sto­py dziec­ka od pię­ty do koń­ca duże­go pal­ca (pisze dla pew­no­ści ;)). Z tym patycz­kiem uda­je­my się do skle­pu i szu­ka­my buci­ków. Aby doko­nać tego wybo­ru dys­po­nu­je­my dwo­ma pod­sta­wo­wy­mi narzę­dzia­mi: paty­czek oraz ogra­ni­cze­nie (tu nasze doświad­cze­nie), któ­re mówi nam, że bucik będzie dobry jeśli patyk się zmie­ści, może być mały luz (np. maks. 5 mm) ale abso­lut­nie nie dopusz­cza­my fak­tu, że mógł­by się nie zmie­ścić. Drugim ogra­ni­cze­niem jest budżet: pla­nu­je­my wydać na buci­ki np. 90zł. Doskonale wie­my dla­cze­go tak, a nie ina­czej postę­pu­je­my: bucik zbyt duży będzie po pro­tu nad­mia­ro­wym zaku­pem, któ­re­go i tak nie wyko­rzy­sta­my zaś bucik zbyt mały po pro­tu nie ma sen­su z powo­dów oczy­wi­stych. Cel ogra­ni­cze­nia war­to­ści tego wydat­ku chy­ba nie wyma­ga komen­ta­rza (po pro­stu na tyle nas stać). Tak więc mamy sku­tecz­nie okre­ślo­ne wyma­ga­nia: paty­czek jako model (uprosz­cze­nie) sto­py dziec­ka i ogra­ni­cze­nia na jego uży­cie: zakaz zaku­pu zbyt małe­go i umiar w zaku­pie zbyt dużego.

Wyobraźmy sobie, że tak wypo­sa­że­ni tra­fi­my na sprze­daw­cę, któ­ry powie, że ma super buci­ki, kupu­ją je dzie­ci zna­nych akto­rów i poli­ty­ków, ale musi­my tro­szecz­kę skró­cić paty­czek i pogo­dzić się z wiel­ka cho­lew­ką w zamian ;), kre­dyt (są znacz­nie droż­sze nią pla­no­wa­li­smy) on tak­że załatwi.

Ciekawostka: jeże­li wyśle­my pocz­tą nasz paty­czek i nasze ogra­ni­cze­nia do skle­pu to ryzy­ko, że tak zamó­wio­ne buci­ki będą złe jest bli­skie zeru! Dlaczego? Unikamy nie­uczci­wej per­swa­zji sprzedawcy …

A teraz wymagania na system ERP.

Już widzę uśmie­chy na twa­rzach czy­tel­ni­ków :). Tak, dobra meto­da to mieć model i dodat­ko­we ogra­ni­cze­nia oraz nie dać sobie wci­snąć cze­goś cze­go nie potrze­bu­je­my. Niestety bez tych dwóch pierw­szych (model i ogra­ni­cze­nia) nie mamy żad­nej bro­ni ani przed sobą samym (np. emo­cje) ani przed dostaw­cą – jeste­śmy bar­dzo podat­ni na zakup cze­goś zupeł­nie nie­po­trzeb­ne­go. Niektórzy opi­su­ją paty­czek kolo­rem, pozio­mem wygła­dze­nia, orna­men­ty­ką, skom­pli­ko­wa­ną pro­ce­du­rą jego uży­cia i wie­lo­ma inny­mi cecha­mi jed­nak tak na praw­dę maja one zni­ko­my wpływ na sku­tecz­ność doko­na­ne­go wybo­ru: liczą się w 99% dłu­gość patycz­ka i ogra­ni­cze­nie: paty­czek musi wejść.

Czy tak można z oprogramowaniem?

Oczywiście! Wystarczy mieć model naszej orga­ni­za­cji oraz ogra­ni­cze­nia nało­żo­ne na uży­cie tego mode­lu. Czy mając paty­czek jest moż­li­wa jakaś per­swa­zja ze stro­ny sprze­daw­cy butów? Nie! A bez patycz­ka? Kto dał sobie sprze­dać nie­co za małe buty w swo­im życiu i czy je potem nosił (cza­sem tak, bo pie­nią­dza na buty wyda­no i dru­gich nie na razie kupi­my)? Czego nie lubią nie­uczci­wi sprze­daw­cy butów? Nie zno­szą klien­tów z patycz­kiem! Są nawet tacy, któ­rzy wma­wia­ją, że paty­czek nale­ży wyrzu­cić bo buci­ki są super i się roz­cho­dzą, w skraj­nym przy­pad­ku wytnie­my otwór na pal­ce (kasto­mi­za­cja goto­we­go bucika).

Jak wykonać patyczek?

Tu poja­wia się moja nie­ukry­wa­na nie­chęć do metod pole­ga­ją­cych na pro­stym spi­sy­wa­niu wyma­gań na opro­gra­mo­wa­nie meto­dą spi­sy­wa­nia expli­ci­te kon­kret­nych funkcjonalności.

Co będzie sku­tecz­niej­szym zamó­wie­niem: boga­ty opis tego do cze­go moż­na użyć kor­by bez jej pro­jek­tu (rysun­ku) czy raczej jej rysunek?

W przy­pad­ku ana­li­zy wyma­gań na opro­gra­mo­wa­nie, nawet jeśli będą to warsz­ta­ty, spo­tka­nia nawet wszyst­kich pra­cow­ni­ków i wiel­kiej burzy mózgów, nic z tego nie będzie (w sen­sie sku­tecz­no­ści) mimo, że powsta­ją kosz­tow­ne mega-doku­men­ty. Skoro każ­dy z nas jest w sta­nie pomi­nąć coś istot­ne­go przy­go­to­wu­jąc listę kil­ku­na­stu spra­wun­ków idąc do skle­pu to jak zagwa­ran­to­wać by bra­ków takich nie było w podob­nie wyko­na­nej spe­cy­fi­ka­cji wyma­gań liczą­cej nawet set­ki pozycji?

Należy przy­go­to­wać nie opis buci­ka a paty­czek (nie opis pla­no­wa­nych zasto­so­wań kor­by a jej rysu­nek)! Ma same zale­ty: ryzy­ko złe­go wybo­ru jest bli­skie zeru, jest poręcz­ny, moż­na go nawet wysłać do skle­pu pocz­tą i spo­dzie­wać się mimo to dobrych bucików.

Jak nie trud­no się domy­śleć mowa o mode­lo­wa­niu biz­ne­so­wym. Patyczek jest mode­lem sto­py a rysu­nek kor­by jej mode­lem. Jak wyko­nać mini­mal­ny sku­tecz­ny model orga­ni­za­cji? Jest to trud­ne jed­nak nie nie­moż­li­we. Paradoksalnie zaś, prak­ty­ka poka­zu­je, opra­co­wa­nie mode­lu jest tań­sze niż pro­wa­dze­nie wywia­dów i opra­co­wy­wa­nie boga­tej spe­cy­fi­ka­cji, że nie wspo­mnę o ryzy­ku uży­cia każ­dej z tych metod. Chyba naj­gor­szym wyj­ście jest zafun­do­wa­nie sobie doku­men­tu wyma­gań w posta­ci listy na kil­ka tysię­cy (tak są takie!) pozy­cji. Tego NIKT NIE CZYTA!

Co zawiera taki model?

Organizację defi­niu­ją skutecznie:

  1. to co i kto i po co robi (w tym [[model biz­ne­so­wy]] całej organizacji)
  2. to jakie kom­pe­ten­cje (umie­jęt­no­ści) musi mieć ten ktoś
  3. to co jest w orga­ni­za­cji prze­twa­rza­ne (zmie­nia­ne)
  4. to cze­go nie wol­no (ogra­ni­cze­nia)
  5. to jaki­mi się powyż­sze rzą­dzi prawami

Jak to poka­zać a nie opi­sy­wać? Nie da się (nie sądzę) stwo­rzyć jed­ne­go mega-mode­lu. Powinny powstać osobno:

  1. [[model pro­ce­sów biz­ne­so­wych]] by poka­zać: kto, co i po co robi a tak­że w odpo­wie­dzi na co (co ini­cju­je każ­de działanie)
  2. [[struk­tu­ra orga­ni­za­cyj­na]], któ­ra poka­że kto i co może robić i od kogo zależy
  3. [[regu­ły biz­ne­so­we]], inny­mi sło­wy [[ogra­ni­cze­nia sys­te­mu]] czy­li [[model poję­cio­wy]] oraz [[sys­tem war­to­ści progowych]].

Dobrze wyko­na­ny model nie zawie­ra infor­ma­cji nad­mia­ro­wych, któ­re zawsze pod­no­szą koszt wyko­na­nia mode­lu a nie raz sta­no­wią zbęd­ne ogra­ni­cze­nia. Dobry model powsta­je z uży­ciem stan­dar­do­wych nota­cji: [[BPMN]] w obsza­rze mode­lo­wa­nia pro­ce­sów oraz [[UML]] w pozo­sta­łych obsza­rach. Używanie for­mal­nych nota­cji pozwa­na zagwa­ran­to­wać wery­fi­ko­wal­ność popraw­no­ści modeli.

Użycie takie­go mode­lu jako narzę­dzia wybo­ru sys­te­mu ERP jest bar­dzo sku­tecz­ne: wystar­czy go roze­słać do dostaw­ców i zapy­tać: po pierw­sze czy ich sys­tem pasu­je do nie­go, ile kosz­tu­je ten pro­dukt rok po roku.

Z takim mode­lem kupu­ją­cy nie musi udo­wad­niać, że jego ocze­ki­wa­nia mają sens (co nie raz zda­ją się pod­wa­żać dostaw­cy) a to dostaw­ca musi zde­kla­ro­wać i wyka­zać, że jego pro­dukt pasu­je do tego mode­lu (czy­li do naszej fir­my). Lepiej: model jest dosko­na­łym narzę­dziem testo­wa­nia dostar­czo­ne­go produktu.

Użycie nota­cji nie­stan­dar­do­wych, bez zde­fi­nio­wa­nych reguł, pro­wa­dzi do powsta­nia nie­we­ry­fi­ko­wal­nych mode­li a to cał­ko­wi­cie dys­kwa­li­fi­ku­je ich sku­tecz­no­ści meto­dy i jej przy­dat­ność. Tak wyko­na­ne mode­le są nie­we­ry­fi­ko­wal­ne i niejednoznaczne.

Tak więc ana­li­za wyma­gań to jest pra­ca wyko­na­na by opi­sać cze­go ocze­ku­je­my i doko­nać wybo­ru. Analiza przed­wdro­że­nio­wa to pra­ca wyko­ny­wa­na przez dostaw­cę, któ­re­go wybra­no, w celu opra­co­wa­nia spe­cy­fi­ka­cji prac jakie nale­ży wyko­nać by wdro­żyć dany pro­dukt. Zapoznaj się z opi­sem Metodyki.

A co gdy żaden mega pro­dukt nie pasu­je co jest bar­dzo praw­do­po­dob­ne? O tym w kolej­nej części.

P.S.

Na bazie tego tek­stu opu­bli­ko­wa­łem tak­że arty­kuł w COMPUTERWORLD:

https://​www​.com​pu​ter​world​.pl/​n​e​w​s​/​O​d​-​c​z​e​g​o​-​z​a​c​z​a​c​-​w​d​r​o​z​e​n​i​e​,​3​7​2​0​4​7​.​h​tml

Inne artykuły na podobny temat

Komentarze

  1. Mateusz Kurleto 21 stycznia 2011 at 00:31

    Polecam jako lek­tu­rę obo­wiąz­ko­wą każ­de­mu pla­nu­ją­ce­mu jakie­kol­wiek (nie tyl­ko ERP) wdrożenie.
    Polecam też aby następ­nie prze­ana­li­zo­wał czy lep­szy jest bucik naj­tań­szy, któ­ry się roz­sy­pie po 2 tygo­dniach, czy może ręcz­nie szy­ty, skó­rza­ny któ­ry wytrzy­ma lata. Tutaj istot­ną kwe­stią – jak i przy buci­ku – jest doj­rza­łość klien­ta. Dziecku nie zawsze opła­ca się kupić super buty, bo szyb­ko wyro­śnie. Ale jak noga rosnąć szyb­ko prze­sta­je oka­zu­je się, że kupu­jąc bucik tań­szy musi­my go zmie­niać, bądź napra­wiać tak czę­sto, że przez 2 lata wyda­my wię­cej na posia­da­nie obu­wia niż kosz­tu­ją dobre buty wytrzy­mu­ją­ce lat 3 i wię­cej jeśli się je pastu­je (main­te­nan­ce).

  2. Jakub Mendys 21 stycznia 2011 at 08:50

    Kolejny dobry arty­kuł. Ma Pan dar łatwe­go opi­sy­wa­nia trud­nych rze­czy – jak na ana­li­ty­ka przystało.

    W powyż­szym opi­sie zabra­kło mi wzmian­ki o jed­nej rze­czy. Mądra orga­ni­za­cja trak­tu­je wdro­że­nie nowe­go sys­te­mu jako część wpro­wa­dza­nia zmia­ny w jej funk­cjo­no­wa­niu (a nie utrwa­le­nia sta­nu obec­ne­go). W takim wypad­ku model pro­ce­sów, struk­tu­ry orga­ni­za­cyj­nej (rza­dziej reguł) powi­nien uwzględ­niać ocze­ki­wa­ny stan przy­szły, a nie obecny.

    • Jarek Żeliński 21 stycznia 2011 at 10:18

      Słuszna i bar­dzo mądra uwa­ga a odpo­wiedź jest zawo­alo­wa­na w tym arty­ku­le i w jed­nym z poprzed­nich:). Model bez uprosz­czeń (ale z ogra­ni­cze­nia­mi) to model opi­su­ją­cy natu­rę, więc wszel­kie zmia­ny w tym mode­lu są tak samo moż­li­we jak w natu­rze, któ­rą ten model przed­sta­wia (mode­lu­je). Druga ukry­ta praw­da” to czas życia roz­wią­za­nia”. Skoro dziec­ko szyb­ko rośnie nie ma eko­no­micz­ne­go sen­su kupo­wa­nie buci­ków zbyt dro­gich. Nie ma sen­su tak­że kupo­wa­nie nad­mier­nie uni­wer­sal­nych… Słuszna uwa­ga: model powi­nien uwzględ­niać stan ocze­ki­wa­ny i przy­szły. Co z tym zro­bić? Czy stan obec­ny to ten jed­no­dnio­wy, rok budże­to­wy, pięć lat stra­te­gii? Nie ma to pro­stej odpo­wie­dzi (o ile w ogó­le jest taka). Dlatego pozo­sta­je uznać fak­ty (nikt nic nie wie) i sta­rać się two­rzyć mode­le natu­ral­ne”. Model któ­ry wytrzy­ma pró­bę cza­su to model uwzględ­nia­ją­cy rze­czy zmien­ne i nie­zmien­ne. Zmienne to naj­czę­ściej regu­ły biz­ne­so­we ale tak­że np. struk­tu­ra orga­ni­za­cyj­na. A co jest nie­zmien­ne? To, że pra­ce wyko­nu­ją ludzie, to że zawsze mają jakieś kom­pe­ten­cje, to że reagu­ją wza­jem­nie na swo­je zacho­wa­nia itp. Innymi sło­wy: las żyje, zwie­rzę­ta w nim tak­że ale nie zna­czy to, że nie da się zamo­de­lo­wać lasu. Po pro­tu model musi uwzględ­niać ten fakt: las żyje i zmie­nia się. Z orga­ni­za­cja­mi jest tak samo. Czy to łatwe? Nie :), czy moż­li­we? Sądzę że tak (trze­ba się sta­rać). Po co? Bo dobry model pro­wa­dzi do powsta­wa­nia dobrych systemów 🙂

    • Jakub Mendys 21 stycznia 2011 at 11:54

      Skoro dziec­ko szyb­ko rośnie nie ma eko­no­micz­ne­go sen­su kupo­wa­nie buci­ków zbyt dro­gich. Nie ma sen­su tak­że kupo­wa­nie nad­mier­nie uniwersalnych?”

      Ekonomia inwe­sty­cji w IT to osob­ny temat zbyt czę­sto zanie­dby­wa­ny i pomi­ja­ny. W ilu przy­pad­kach na 100 pada pyta­nie o ren­tow­ność inwe­sty­cji w IT? Najczęściej wyglą­da to tak: ope­ra­cje czy sprze­daż chcą auto­ma­ty­za­cji by ogra­ni­czać swo­je kosz­ty, IT jest dobre i dro­gie (bo dro­gie IT jest dobre) więc dostar­cza faj­ne” roz­wią­za­nia, a cała fir­ma tra­ci bo koszt roz­wią­za­nia (jego amor­ty­za­cja i utrzy­ma­nie) jest nie­ade­kwat­na do korzy­ści któ­rych dostar­cza i kosz­tów wdrożenia.

    • Jarek Żeliński 21 stycznia 2011 at 14:12

      Niestety tezę, że nie liczy się ren­tow­no­ści IT bo ono musi być”, lan­su­ją nie­któ­rzy dostaw­cy tegoż IT… cie­ka­we dlaczego…

  3. Marek Kuszneruk 21 marca 2012 at 10:53

    Metafora patycz­ka – pro­ste i na temat. Bezcenne.

Dodaj komentarz

Twój adres email nie zostanie opublikowany

Komentuj i zadawaj pytania autorowi.

Identyfikator *
E-mail *
Witryna internetowa

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