Ile jest tych wymagań na system ERP

W maju tego roku mia­łem refe­rat na kon­fe­ren­cji doty­czą­cej sys­te­mów ERP. Jego tytuł to Modele wdra­ża­nia i zarzą­dza­nia pro­jek­ta­mi ERP”. Był to naj­wy­żej oce­nio­ny przez publicz­ność, refe­rat. Tezą prze­wod­nią refe­ra­tu było stwier­dze­nie, że:

Wymagania na ERP

Kluczowe tezy

?Powodem wie­lu pora­żek i nie­uda­nych pro­jek­tów wdro­że­nio­wych jest:

?zbyt wie­le naci­sków dostaw­cy na kom­pro­mi­sy pod­czas wdra­ża­nia goto­we­go, para­me­try­zo­wa­ne­go opro­gra­mo­wa­nia w posta­ci jed­ne­go zin­te­gro­wa­ne­go pakie­tu: opro­gra­mo­wa­nie sta­je mało przydatne

?zbyt wie­le naci­sków kupu­ją­ce­go na dopa­so­wa­nie (kasto­mi­za­cję): znacz­nie rosną kosz­ty i odsu­wa się ter­min jego wdro­że­nia a nadal nie ma gwa­ran­cji powodzenia.

?Wiele spe­cy­fi­ka­cji jakie obser­wu­ję to lista setek pozy­cji, opi­su­ją­cych jak ma ?ten pro­gram dzia­łać?, typo­we efekty:

?Lista cech duże­go sys­te­mu ERP to ponad 6000 pozycji

?Optymistycznie patrząc moż­na liczyć na zgod­ność wła­snej takiej listy z goto­wym pro­duk­tem na ryn­ku w 80%

?Pozostaje więc 20% cech bra­ku­ją­cych, to jest 1200 cech

?Jedna nowa funk­cjo­nal­ność to opty­mi­stycz­nie licząc dwa dni pra­cy kon­sul­tan­ta i pro­gra­mi­sty, przy kosz­cie 1200zł/dzień wycho­dzi 2,88 mln.

?Kupując opro­gra­mo­wa­nie goto­we nie pro­jek­tu­je­my go, a spe­cy­fi­ku­je­my to, do cze­go będzie uży­wa­ne: wska­zu­je­my któ­re pro­ce­sy sys­tem ma obsłu­żyć i jakie­go pro­duk­tu pro­ce­su oczekujemy.

?Kluczowe wyda­je się wydzie­le­nie tych pro­ce­sów, któ­re są naj­istot­niej­sze dla fir­my a ich wpar­cia nie ofe­ru­je goto­we opro­gra­mo­wa­nie, pozo­sta­je rezy­gna­cja lub umie­jęt­ne zapro­jek­to­wa­nie ich jako apli­ka­cji dedykowanej.

Wymagania na zło­żo­ne sys­te­my, zde­fi­nio­wa­ne jako zestaw testów są znacz­nie efek­tyw­niej­sze i bez­piecz­niej­sze, niż deta­licz­na spe­cy­fi­ka­cja pro­stych funk­cji. Tworzenie testów wyma­ga jed­nak okre­śle­nia biz­ne­so­we­go celu wdro­że­nia i zro­zu­mie­nia tego jak orga­ni­za­cja funk­cjo­nu­je (opra­co­wa­nie modeli).

Praktyka poka­zu­je, że koszt ana­li­zy i opra­co­wa­nia takich testów jest znacz­nie niż­szy niż nie­pla­no­wa­ny dodat­ko­wy koszt pro­jek­tów opar­tych na deta­licz­nych spe­cy­fi­ka­cjach wyma­gań (śred­nie prze­kro­cze­nie budże­tu, spo­wo­do­wa­ne złą spe­cy­fi­ka­cją wyma­gań, to ponad 60%).

Kompletna pre­zen­ta­cja uży­ta pod­czas tego refe­ra­tu: Modele wdra­ża­nia i zarzą­dza­nia pro­jek­ta­mi ERP

Inne artykuły na podobny temat

Komentarze

  1. Ewa 31 października 2013 at 12:18

    Bardzo mi się podo­ba takie podej­ście, jest takie zdro­wo­roz­sąd­ko­we. Ciekawa jestem, na ile uda­je się to zaob­ser­wo­wać i sto­so­wać w życiu.

    • Jaroslaw Zelinski 31 października 2013 at 14:48

      To zale­ży, czy klient – a są z regu­ły jed­nak kon­for­mi­sta­mi – wytrzy­ma napór oto­cze­nia”. Metoda się sprawdza…

  2. Dam Koszty 31 października 2013 at 23:29

    Jest jesz­cze jed­na zasad­ni­cza wada listy wyma­ga­nych cech. Bardzo łatwo pomi­nąć albo nie dopre­cy­zo­wać. Jako przy­kład podam obsłu­gę pli­ków w for­ma­cie XYZ”. Dostarczone narzę­dzie może fak­tycz­nie obsłu­gi­wać takie pli­ki, ale tyl­ko jed­no­kie­run­ko­wo (tyl­ko import albo eks­port), a my potrze­bu­je­my peł­nej obsługi.

    Specyfikacja jako testy ilo­ścio­we i jako­ścio­we jest znacz­nie wygod­niej­sza dla wszyst­kich, ale fak­tycz­nie wyma­ga kon­kret­nej kon­cep­cji dzia­ła­nia, a nie podej­ścia dawaj­cie wszyst­ko, może się kie­dyś przydać”.

  3. jacek2v 1 listopada 2013 at 22:30

    Bardzo mi się podo­ba pode­ście poprzez pisa­nie testów do wybo­ru sys­te­mu. Świetna koncepcja.
    Stosujemy ją na co dzień w pro­gra­mo­wa­niu – nazy­wa się TDD (Test-dri­ven deve­lop­ment) i jest ele­men­tem stra­te­gii Agile przy budo­wa­niu projektów.
    I mogę potwier­dzić, że spraw­dza się – tro­chę boli” na początku 🙂

    • Jaroslaw Zelinski 1 listopada 2013 at 23:37

      Nie wiem od kie­dy to TDD to Agile ale niech tam :). TDD jako meto­da defi­nio­wa­nia wyma­gań ma tak­że pew­ną wadę: nic nie mówi o tym jak je speł­nić. W przy­pad­ku szu­ka­nia” goto­we­go opro­gra­mo­wa­nia do wyko­rzy­sta­nia ma moim zda­niem głę­bo­ki sens, jed­nak jako wyma­ga­nie dla apli­ka­cji dedy­ko­wa­nej nie zawsze: pro­szę sobie wyobra­zić, że daję kil­ka (a nawet kil­ka­set) przy­kła­do­wych wyni­ków sys­te­mu sco­rin­go­we­go, na bazie któ­rych zama­wiam napi­sa­nie sys­te­mu sco­rin­go­we­go. Obawiam się, że odtwo­rze­nie” (w koń­cu trze­ba zapro­gra­mo­wać meto­dę podajWynikScoringu(a,b,c,d,e) będzie raczej mało praw­do­po­dob­ne. TDD to testy, jed­nak wszel­kie nie­try­wial­ne meto­dy trze­ba jesz­cze udo­ku­men­to­wać, bez tego sam test jest niczym. Inżynieria wstecz­na” wzo­rów mate­ma­tycz­nych itp. to wiel­kie wyzwa­nie, dla­te­go nie nale­ży zapo­mi­nać o wyma­ga­niach dzie­dzi­no­wych (jaw­nie poda­na na tacy logi­ka dzia­ła­nia jako wyma­ga­nie). W prze­ciw­nym wypad­ku nie raz deve­lo­per sta­je przed wyzwa­niem roz­gry­za­nia zasad gry w bry­dża na pod­sta­wie kil­ku­na­stu zapi­sa­nych par­tii, życzę powodzenia ;). 

      Tak więc testy na pew­no mają sens jako dowód speł­nie­nia wyma­ga­nia, jed­nak jako jedy­na doku­men­ta­cja wyma­gań, w przy­pad­ku two­rze­nia opro­gra­mo­wa­nia dedy­ko­wa­ne­go, nie raz same testy to sta­now­czo za mało. 

  4. jacek2v 2 listopada 2013 at 00:33

    TDD to nie Agile, ale jeden z jej elementów/technik: http://​www​.agi​le​da​ta​.org/​e​s​s​a​y​s​/​t​d​d​.​h​tml
    Zgadzam się, że testy mogą nic nie mówić jak speł­nić wyma­ga­nia. Testy na te same wyma­ga­nia moż­na napi­sać róż­nie. Wszystko zale­ży od tego co chce się testo­wać – co chce się mieć pod kontrolą.
    Testy nie słu­żą do inży­nier­ni wstecz­nej, ani roz­gry­za­nia” tyl­ko do weryfikacji.
    Trudność w zro­zu­mie­niu TDD pole­ga na tym, że jest w tej meto­dzie spo­ro ele­men­tów moty­wa­cyj­nych i pod­no­szą­cych jakość pro­jek­tów poprzez roz­wi­ja­nie ludzi pro­wa­dzą­cych pro­jekt (np. DRY-Don’t Repeat Yourself, ele­men­ty Kaizen).

    Tak zga­dzam się, same testy to za mało. Ale nadal to świet­na kon­cep­cja – pozo­sta­je kwe­stia realizacji 🙂

    • Jaroslaw Zelinski 2 listopada 2013 at 10:22

      To praw­da, na pew­no sto­so­wa­nie testów jest o nie­bo lep­sze niż pró­ba opi­sa­nie wyma­ga­nia samy­mi cecha­mi bez testów. Pisanie testów gene­ral­nie zmu­sza do zro­zu­mie­nia celu jaki się osią­gnąć, pisa­nie (pro­jek­to­wa­nie) imple­men­ta­cji to roz­wią­zy­wa­nie pro­ble­mu ale test to kie­ru­nek i świa­teł­ko w tune­lu. Na pozio­mie wyma­gań biz­ne­so­wych pozwa­la eli­mi­no­wać wszel­kie nad­mia­ro­we wyma­ga­nia i nie pomi­nąć tych istot­nych. Ta cecha meto­dy powo­du­je, że w pro­jek­tach poli­tycz­nych” jest to meto­da «groź­na» 🙂

      Jedna uwa­ga: link http://​www​.agi​le​da​ta​.org/​e​s​s​a​y​s​/​t​d​d​.​h​tml poka­zu­je nie­ste­ty bar­dzo złą meto­dę roz­wią­zy­wa­nia pro­ble­mów meto­dą prób i błę­dów”. Ten diag­gram http://​www​.agi​le​da​ta​.org/​i​m​a​g​e​s​/​t​d​d​S​t​e​p​s​.​jpg może nie mieć koń­ca (nie licząc koń­ca budże­tu lub czasu).

  5. jacek2v 2 listopada 2013 at 16:43

    To, że pro­ces jest nie­skoń­czo­ny jest zamie­rzo­ne – na tym opie­ra się Agile, na cią­głym dosko­na­le­niu. Oczywiście nie­któ­re pro­jek­ty (a może i więk­szość) powin­ny się koń­czyć, ale warun­ki koń­ca moż­na wyznaczyć.

    To nie jest meto­da prób i błę­dów” to jest meto­da wali­da­cji testu, tzn. upew­nie­nia się, że test na pew­no spraw­dza wystę­po­wa­nie kon­kret­ne­go błę­du. Oczywiście nale­ży zasta­no­wić się jak zaim­ple­men­to­wać takie dzia­ła­nie dla spe­cy­fi­ka­cji wyma­gań. Takie podej­ście w nie­któ­rych meto­dy­kach (tak­że Agile) jest też nazy­wa­ne faza Learning & Conclusions, czy­li ucze­nia się i popra­wia­nia swo­je­go dzia­ła na przy­szłość – bar­dzo dobra tech­ni­ka zwłasz­cza w insty­tu­cjach czę­sto zama­wia­ją­cych usłu­gi, czy oprogramowanie.

    • Jaroslaw Zelinski 2 listopada 2013 at 19:17

      Niewątpliwie dosko­na­le­nie same­go pro­ce­su wytwór­cze­go ma ma sens, ale wyma­ga­nia to są kon­kre­ty”. Projekt się koń­czy w momen­cie gdy pro­dukt speł­nia wyma­ga­nia (prze­cho­dzi testy), wyma­gań jest nie raz wie­le więc moż­na je pogru­po­wać i odda­wać pro­dukt modu­ła­mi”, ale te naj­pierw trze­ba zapro­jek­to­wać. Ja też uwa­żam, że pro­jek­ty powin­ny się (kie­dyś) koń­czyć 😉 i naj­le­piej by data koń­ca tak­że była ele­men­tem planowania.

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.