..oraz nowe wdrożenia

Pewnego razu w pew­nej dys­ku­sji, pewien Pan napisał:

W teo­rii infor­ma­cji od dzie­siąt­ków lat zwra­ca się uwa­gę na feno­men pole­ga­ją­cy na tym, że naj­waż­niej­sze zmia­ny w rze­czy­wi­sto­ści publicz­nej nie mają wiel­kiej lub zgo­ła żad­nej publicz­nej nośno­ści, ponie­waż nie wią­żą się z żad­nym kon­kret­nym zda­rze­niem, któ­re moż­na dobrze sprzedać

Odpowiedziałem:

Zwrócił Pan uwa­gę na waż­ną rzecz i ma ona dość pro­ste wyja­śnie­nie, tak­że na grun­cie teo­rii informacji:

• infor­ma­cja to wia­do­mość o zaist­nie­niu faktu
• war­tość (mia­ra) okre­ślo­nej infor­ma­cji jest odwrot­nie pro­por­cjo­nal­na do praw­do­po­do­bień­stwa wystą­pie­nia fak­tu jaki opi­su­je (teo­ria komunikacji)
• ludzie są wyczu­le­ni na infor­ma­cje ​„war­to­ścio­we”
• dla­te­go powol­ne zmia­ny (infor­ma­cje o nich) nigdy nie są war­to­ścio­we i nośne bo nie są żad­nym zaskoczeniem

Powyższe ma tak­że zna­ną meta­fo­rę, jaką jest tak zwa­ne goto­wa­nie żaby: nie jest dla niej zasko­cze­niem powo­li nara­sta­ją­ca tem­pe­ra­tu­ra wody, zasko­cze­niem było by wrzu­ce­nie jej znie­nac­ka od razu do gorącej.

Tak samo dzia­ła powol­ne ​„doje­nie” Zamawiającego w toku wdro­że­nia i eks­plo­ata­cji sys­te­mu ERP, bo odby­wa sie na iden­tycz­nej zasa­dzie: mie­siąc po mie­sią­cu reali­zo­wa­ne są kolej­ne drob­ne popraw­ki i wyma­ga­nia, nadal nic nie dzia­ła jak powin­no, i nagle po kil­ku latach goto­wa­nia, żaba zwa­na Nabywcą Systemu ERP odkry­wa, że jest ugo­to­wa­na i chce iść do sądu, rzecz w tym, że jest już za póź­no, ….. bo jest już ugotowana. 

Wprowadzenie

Bardzo czę­sto mówi się, że przy­czy­ną pora­żek jest brak codzien­ne­go zaan­ga­żo­wa­nia ze stro­ny osób decy­zyj­nych. Jeżeli wdro­że­nie odby­wa się ​„zwin­nie” i bez przy­go­to­wa­nia, fak­tycz­nie sta­łe zaan­ga­żo­wa­nie osób decy­zyj­nych jest nie­zbęd­ne. Jeżeli wdro­że­nie jest przy­go­to­wa­ne, nie. Zarząd jest wyma­ga­ny tyl­ko do zatwier­dze­nia doku­men­tu audy­tu, ana­li­zy i pro­jek­tu, potem już tyl­ko obser­wu­je. Kogo stać na zaan­ga­żo­wa­nie Zarządu w bie­żą­ce pra­ce wdrożeniowe?

Najczęstszą przy­czy­ną kło­po­tów jest uzna­nie, że dostaw­ca opro­gra­mo­wa­nia sam wyko­na ana­li­zę przed­wdro­że­nio­wą, opra­cu­je wyma­ga­nia i potem wdro­ży sys­tem. To jest myśle­nie życze­nio­we. Uznanie zaś, że jeden sys­tem nada­je sie do wszyst­kie­go w fir­mie, jest w obec­nych cza­sach nie do obro­ny.

Niestety pro­ble­ma­tycz­ne wdro­że­nia sys­te­mów ERP nie są rzad­ko­ścią. Wiele moich zle­ceń od klien­tów to wypro­wa­dza­nie ich z impa­su spo­ru z dostaw­cą a potem kon­ty­nu­acja wdro­że­nia lub zmia­na sys­te­mu bo cza­sa­mi naj­lep­sze oka­zu­je sie wyj­ście z posiadanego/wdrażanego sys­te­mu ERP z mini­mal­ny­mi stratami. 

Jak wyglądają ​„typowe” wdrożenia

Naturalnym sta­nem więk­szo­ści firm jest ​„sta­bil­na pra­ca bez poża­rów” pole­ga­ją­ca na tym, że po latach drob­nych, ewo­lu­cyj­nych zmian fir­ma, jako ​„sys­tem naczyń połą­czo­nych”, jakoś dzia­ła i to nawet nieźle.

Problem w tym, że taką fir­mę potra­fi zabić nawet dro­biazg wywo­łu­ją­cy ​„efekt moty­la” w fir­mie. Niejedna fir­ma upa­dła, z powo­du ​„drob­nej złej decy­zji”, złej bo pod­ję­tej bez ana­li­zy jej wpły­wu na resz­tę orga­ni­za­cji. Dlaczego tak się dzie­je? Bo do bez­piecz­ne­go podej­mo­wa­nia decy­zji o zmia­nach trze­ba mieć model fir­my, i nie są to set­ki stron zapi­su wywia­dów z pra­cow­ni­ka­mi. Każda zmia­na sys­te­mu infor­ma­tycz­ne­go to tak­że taka zmia­na, i to nie mała. 

Powszechnie uwa­ża się, że wyma­ga­nia na opro­gra­mo­wa­nie to efekt spi­sa­nych wywia­dów i wyma­gań z pra­cow­ni­ka­mi. Niestety wyka­za­no, że nic bar­dziej błęd­ne­go! Takie doku­men­ty są nie­kom­plet­ne, wewnętrz­nie sprzecz­ne i nie­spój­ne, są jed­ną z klu­czo­wych przy­czyn pora­żek pro­jek­tów w bran­ży infor­ma­tycz­nej .

Model pro­ce­so­wy orga­ni­za­cji to kil­ka­na­ście, rza­dziej kil­ka­dzie­siąt, sche­ma­tów blo­ko­wych na odpo­wied­nio dobra­nym pozio­mie ogól­no­ści (abs­trak­cji). Taki doku­ment albo da się prze­czy­tać w jeden dzień w dniu jego zatwier­dza­nia, albo jest nie­przy­dat­ny. Później powi­nien słu­żyć jak ​„ency­klo­pe­dia wie­dzy o orga­ni­za­cji”: zaglą­da­my w okre­ślo­ne miej­sce, mając zaufa­nie, że całość jest spój­na, kom­plet­na i nie­sprzecz­na (a jest, jeże­li doku­ment jest, po jego powsta­niu, aktu­ali­zo­wa­ny) .

Jednym z głów­nych powo­dów powsta­wia­nia pro­ble­mów wdro­żeń mono­li­tycz­nych sys­te­mów ERP jest ich kasto­mi­za­cja (inge­ren­cja w kod): czę­sto jed­na zmia­na powo­du­je nega­tyw­ne skut­ki w kil­ku innych miej­scach, powo­dem jest to, że nikt (czę­sto nawet fir­ma wdra­ża­ją­ca!) nie rozu­mie w peł­ni dzia­ła­nia tego sys­te­mu, bo jego archi­tek­tu­ra jest ​„tajem­ni­cą pro­du­cen­ta”, zaś bez dobrej mapy pro­ce­sów nie mamy poję­cia jak jeden dział fir­my (i moduł) wpły­wa na inny. 

Nie raz jestem pro­szo­ny o audy­ty doku­men­ta­cji pro­jek­tów na eta­pie spo­rów przed­są­do­wych mię­dzy dostaw­cą opro­gra­mo­wa­nia i zama­wia­ją­cym. Często bywa, że wdro­że­nie trze­ba zarzu­cić, a zdo­by­te doświad­cze­nie wyko­rzy­stać w pro­wa­dzo­nym od nowa pro­jek­cie. Kilka spo­strze­żeń na ten temat w arty­ku­le: Kto winien poraż­ki projektu?

Jak skutecznie zaplanować i przeprowadzić wdrożenie oprogramowania – idealizacja

Szkielet każ­dej sku­tecz­nej meto­dy­ki pro­wa­dze­nia ana­liz przed­wdro­że­nio­wych i wdro­żeń, zarów­no goto­wych sys­te­mów ERP, już dostęp­nych na ryn­ku, jak i pro­jek­to­wa­nia i wdra­ża­nia roz­wią­zań dedy­ko­wa­nych to: prze­pro­wa­dzić audyt, opra­co­wać model pro­ce­sów biz­ne­so­wych i zapla­no­wać ewen­tu­al­ne ich uspraw­nie­nia, okre­ślić tak zwa­ną lukę czy­li wska­zać obszar, któ­re­go stan­dar­do­wa wer­sja pla­no­wa­ne­go do wdro­że­nia opro­gra­mo­wa­nia nie obsłu­gu­je. Typowy, zale­ca­ny spo­sób postę­po­wa­nia przy two­rze­niu mode­li pro­ce­sów :

1. Zebranie arte­fak­tów (doku­men­ty operacyjne),
2. Zidentyfikowanie i opi­sa­nie mecha­ni­zmów ich powstania,
3. Umiejscowienie (mapo­wa­nie) tych mecha­ni­zmów w archi­tek­tu­rze orga­ni­za­cji i sys­te­mu IT,
4. Zidentyfikowanie skut­ków nie­ty­po­wych przypadków,
5. Ocena speł­nie­nia wyma­gań przez pro­jek­to­wa­ną archi­tek­tu­rę systemu,
6. Ocena wza­jem­ne­go wpły­wu wymagań,
7. Ocena kosztów/korzyści pla­no­wa­nej nowej architektury.

Mając już taki model nale­ży wska­zać na nim wszyst­kie miej­sca, któ­re mają być wspie­ra­ne przy­szłym opro­gra­mo­wa­niem: to zakres pro­jek­tu wdro­że­nio­we­go. Pozostaje już tyl­ko zapro­jek­to­wa­nie tego sys­te­mu, zna­le­zie­nie dostaw­cy i wdro­że­nie pod wła­snym nadzorem. 

Innymi sło­wy każ­dy taki pro­jekt wyma­ga: (1) ana­li­zy i opra­co­wa­nia mode­lu pro­ce­sów biz­ne­so­wych orga­ni­za­cji w celu zro­zu­mie­nia mecha­ni­zmu jej dzia­ła­nia (wię­cej w arty­ku­le: Audyt orga­ni­za­cji i opty­ma­li­za­cja pro­ce­sów biz­ne­so­wych), (2) odwzo­ro­wa­nie tego mecha­ni­zmu w posta­ci pro­jek­tu tech­nicz­ne­go opro­gra­mo­wa­nia (wię­cej w arty­ku­le: Analiza i Opracowanie Wymagań na Oprogramowanie).

Projekty takie obec­nie reali­zu­je się meto­dą ite­ra­cyj­no-przy­ro­sto­wą („od ogó­łu do szcze­gó­łu”), dla­te­go każ­dy z ww. dwóch klu­czo­wych eta­pów, nie powi­nien trwać dłu­żej niż trzy mie­sią­ce, deta­le są opra­co­wy­wa­ne na bie­żą­co w toku wdro­że­nia (nad­zór autor­ski). Co do zasa­dy nale­ży uni­kać kasto­mi­za­cji goto­we­go kodu (to nisz­czy inte­gral­ność goto­we­go już opro­gra­mo­wa­nia i powo­du­je, że przy­szłe upgra­de­’y będą wyma­ga­ły powtó­rze­nia prac wdro­że­nio­wych). Brakujące funk­cjo­nal­no­ści to obszar two­rze­nia dedy­ko­wa­nych modu­łów tam gdzie to oka­że sie wyma­ga­ne (patrz: Ochrona war­to­ści inte­lek­tu­al­nych i know-how w orga­ni­za­cji). Znakomita więk­szość potrzeb może zostać obsłu­żo­na goto­wy­mi, dostęp­ny­mi na ryn­ku, roz­wią­za­nia­mi a ich inte­gra­cja, przy obec­nym pozio­mie tech­no­lo­gii i stan­da­ry­za­cji, nie sta­no­wi żad­ne­go pro­ble­mu – jest wie­lo­krot­nie tań­sza niż kasto­mi­za­cja dużych systemów. 

Kluczowe przyczyny problemów wdrożeniowych

Praktyka poka­zu­je (patrz Chaos Report), że klu­czo­wą przy­czy­ną jest łama­nie powyż­szych zasad i pró­by reali­za­cji wdro­że­nia ​„dro­gą na skró­ty”, czy­li bez przy­go­to­wa­nia (patrz: słyn­ne poraż­ki wdro­żeń ERP).

Typowy sys­tem ERP to milio­ny linii kodu pro­gra­mu i set­ki sko­ja­rzo­nych wza­jem­nie tabel baz danych. Takie sys­te­my powsta­ją lata­mi, testo­wa­nie ich u pro­du­cen­ta trwa mie­sią­ca­mi. Każda inge­ren­cja w struk­tu­rę tego kodu i tabel baz danych to ryzy­ko zabu­rze­nia sta­bil­no­ści sys­te­mu i ogrom­na pra­co­chłon­ność usu­wa­nia skut­ków tych ingerencji. 

Bardzo czę­sto przy­ta­cza­ną przy­czy­ną nie­uda­ne­go wdro­że­nia, poza niskiej jako­ści spe­cy­fi­ka­cją wyma­gań, jest brak mery­to­rycz­ne­go nad­zo­ru nad pra­ca­mi dostaw­ców. Dostawca opro­gra­mo­wa­nia ma ogrom­ną prze­wa­gę kom­pe­ten­cyj­ną nad użyt­kow­ni­ka­mi swo­ich pro­duk­tów (doty­czy to zresz­tą każ­de­go zaawan­so­wa­ne­go tech­no­lo­gicz­nie pro­duk­tu). Oznacza to, że nabyw­ca, bez wspar­cia, nie jest w sta­nie mery­to­rycz­nie nad­zo­ro­wać prac dostaw­cy (patrz: Kto win­ny poraż­ki pro­jek­tu) .

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

Warto tak­że wska­zać przy­czy­nę poza mery­to­rycz­ną, jaką jest komu­ni­ka­cja w pro­jek­cie: korzy­sta­nie z pocz­ty elek­tro­nicz­nej i pro­stych narzę­dzi biu­ro­wych, korzy­sta­nie z dużej licz­by drob­nych nie­zin­te­gro­wa­nych, to zmo­ra zarzą­dza­nia pro­jek­ta­mi: roz­pro­szo­ne i nie­kon­tro­lo­wa­ne doku­men­ty, brak jed­no­li­te­go i kon­tro­lo­wa­ne­go dostę­pu do nich, powo­du­je, że bar­dzo szyb­ko zarzą­dza­nie pro­jek­tem sta­je się serią przy­pad­ko­wych kon­tak­tów. Niekontrolowany wspól­ny dysk sie­cio­wy (jeże­li jest) szyb­ko sta­je się ​„śmiet­ni­kiem”.

Jak wyjść z impasu w projekcie?

Typowym ele­men­tem spo­rów z dostaw­ca­mi sys­te­mów jest kwe­stia pra­co­chłon­no­ści i roz­li­czeń. Dlatego pierw­szym eta­pem ​„rato­wa­nia” jest zawsze audyt doku­men­tów pro­jek­to­wych (umo­wa, bie­żą­ce zle­ce­nia i ich roz­li­cze­nia). Ten etap ma na celu usta­le­nie sta­nu fak­tycz­ne­go i wypra­co­wa­nie tak zwa­ne­go bilan­su otwar­cia bez oce­nia­nia któ­rej­kol­wiek ze stron. 

Kolejny etap to opra­co­wa­nie klu­czo­wych zale­głych doku­men­tów (patrz począ­tek tego arty­ku­łu). Ich szcze­gó­ło­wość zale­ży od aktu­al­ne­go sta­nu doku­men­ta­cji pro­jek­to­wej. Tu powsta­je tak­że tak zwa­na ana­li­za luki (ana­li­za ​„fit-gap”), czy­li okre­śle­nie na ile aktu­al­ny stan odbie­ga od sta­nu pożą­da­ne­go. Ten etap koń­czą reko­men­da­cje do dal­sze­go toku prac, jest to opra­co­wa­nie nowe­go har­mo­no­gra­mu i zasad współ­pra­cy (aneks do aktu­al­nej umo­wy lub nowa umo­wa na wdro­że­nie). W skraj­nym przy­pad­ku nale­ży się liczyć z zanie­cha­niem kon­ty­nu­acji pro­jek­tu, ponow­nym roz­po­czę­ciem wdro­że­nia tego same­go pro­duk­tu lub wybo­rem i wdro­że­niem inne­go (patrz: LIDL, PUE, HERTZ).

A może inaczej: mediacje

Są dwa klu­czo­we momen­ty rato­wa­nia wdro­że­nia opro­gra­mo­wa­nia: 1. zarza­dza­nie ryzy­kiem na eta­pie pla­no­wa­nia pro­jek­tu oraz 2. media­cje na eta­pie kon­flik­tu stron umo­wy na wdro­że­nie. Mediacje są defi­nio­wa­ne jako: pośred­ni­cze­nie w spo­rze mają­ce na celu uła­twie­nie stro­nom doj­ście do poro­zu­mie­nia. Kolejny fakt: <10% pro­jek­tów śred­nich i dużych koń­czy się w pla­no­wa­nym ter­mi­nie i budże­cie .

To zna­czy, że ponad 90% wdro­żeń to spo­ry! W zna­ko­mi­tej więk­szo­ści jest tu już spór o treść umo­wy na eta­pie jej zawie­ra­nia, mię­dzy Zamawiającym a Dostawcą oprogramowania. 

Celem wdro­że­nia opro­gra­mo­wa­nia jest (powin­na być) satys­fak­cja obu stron, a nie tyl­ko tej, któ­ra przy­ję­ła wyna­gro­dze­nie i nie ponie­sie skut­ków ewen­tu­al­nej poraż­ki (tu zawsze prze­gry­wa tyl­ko kupujący). 

Co to zna­czy? To zna­czy, że war­to już na samym począt­ku roz­wa­żyć umo­wę trój­stron­ną. Może ona nie mieć w nazwie sło­wa Mediacje, cel jest ten sam: obie stro­ny dążą do ugo­dy jaką jest spraw­ne i płyn­ne wdro­że­nie. Przedmiotem ​„spo­ru” jest kon­flikt inte­re­su, czy­li zakres pro­jek­tu i spo­sób jego reali­za­cji: kupu­ją­cy chce jak naj­wię­cej za jak naj­mniej zaś dostaw­ca chce dostar­czyć jak naj­mniej za jak najwięcej. 

Więc anga­żu­je­my trze­cią stro­nę i współ­pra­ca ta jest dobro­wol­nym zobo­wią­za­niem stron, w ramach któ­re­go zain­te­re­so­wa­ni zapew­nia­ją się nawza­jem, iż będą dąży­li do wypra­co­wa­nia kom­pro­mi­su zado­wa­la­ją­ce­go w rów­nym stop­niu obie stro­ny kon­flik­tu. Kto poma­ga ten kom­pro­mis osią­gnąć? Niezależny ana­li­tyk-pro­jek­tant roz­wią­za­nia, któ­re­go celem jest pogo­dze­nie stron mają­cych ww. kon­flikt inte­re­su: to on, wraz z Nabywcą opro­gra­mo­wa­nia opra­co­wu­je Wymagania czy­li Zakres Projektu, a potem bie­rze udział w oce­nie Koncepcji Wdrożenia jaka przed­sta­wia Dostawca. Od tego momen­tu pra­cu­je na rzecz suk­ce­su wdro­że­nia czy­li na rzecz obu stron.

Wdrożenie tego podej­ścia pole­ga na opra­co­wa­niu wyma­gań (tu jest to pro­jekt roz­wią­za­nia) jako załącz­ni­ka do umo­wy na wdro­że­nie, a potem na wpi­sa­niu pro­jek­tan­ta jako ​„media­to­ra”, do umo­wy na wdro­że­nie jako człon­ka zespo­łu po stro­nie zespo­łu Zamawiającego. 

Jeżeli pro­ble­ma­tycz­ne wdro­że­nie jest już w toku, to po audy­cie i ​„bilan­sie otwar­cia”, reali­zo­wa­ne są wyżej opi­sa­ne dzia­ła­nia po stro­nie Zamawiającego. Albo cza­sa­mi wła­śnie zawie­ra­na jest umo­wa trój­stron­na: Zamawiający, Dostawca i Mediator. Tu czę­sto kosz­ty media­to­ra dzie­lo­ne są po poło­wie mie­dzy Zamawiającego a Dostawcę: Mediator tu to pro­jek­tant sys­te­mu mają­cy nad­zór autorski. 

W swo­jej karie­rze mia­łem trzy takie umo­wy: dwie zawar­te na eta­pie poważ­ne­go spo­ru o jakość wdro­że­nia, jed­na zawar­ta już na eta­pie pro­ble­mów z pod­pi­sa­niem umo­wy na wdro­że­nie, co cie­ka­we na wnio­sek dostaw­cy opro­gra­mo­wa­nia. Wszystkie trzy pro­jek­ty skoń­czy­ły się suk­ce­sem wdro­że­nia. Polecam!

Oferta

Polecam opis: Jak wyjść z dłu­gu tech­no­lo­gicz­ne­go jakim jest cen­tral­ny mono­li­tycz­ny sys­tem.

Umowa ze mną obej­mu­je w takich przy­pad­kach najczęściej:

1. audyt: opra­co­wa­nie mode­li pro­ce­sów biz­ne­so­wych fir­my i wska­za­nie na nich wyma­gań biz­ne­so­wych i zakre­su wdrożenia,
2. ana­li­za fit-gap: oce­nić róż­ni­cę pomię­dzy pla­no­wa­nym sta­nem, ​„ide­al­nym” a aktu­al­nym fak­tycz­nym, opra­co­wa­nie pro­jek­tu rozwiązania,
3. usta­le­nie z dostaw­cą for­my zamknię­cia aktu­al­ne­go sta­nu: anek­su lub nowej umo­wy na dal­sze pra­ce (załącz­ni­kiem jest co do zasa­dy pro­dukt pierw­sze­go i dru­gie­go eta­pu powy­żej: model pro­ce­sów biz­ne­so­wych i pro­jekt roz­wią­za­nia jako wymaganie),
4. prze­ję­cie zarzą­dza­nia zakre­sem pro­jek­tu (wyma­ga­nia i pro­jek­to­wa­nie ich reali­za­cji): (mój) nad­zór autor­ski na bazie opra­co­wa­nej mapy pro­ce­sów i wyma­gań, dostaw­ca reali­zu­je wyłącz­nie imple­men­ta­cję i wdro­że­nie pod dyk­tan­do Zamawiającego (czy­li tak­że moje).
5. może to być umo­wa z dowol­ne ze stron lub wyżej opi­sa­na umo­wa trójstronna. 

Praktycznie każ­dy dostaw­ca opro­gra­mo­wa­nia bro­ni tezy, że tyl­ko on jest w sta­nie mery­to­rycz­nie nad­zo­ro­wać wdro­że­nie swo­ich pro­duk­tów. Teza ta jest nie do obro­ny z kil­ku powodów:

1. dostaw­ca ma wie­dzę o tym co wdra­ża, ale wie­dzę o klien­cie też musi zdobyć,
2. dostaw­ca, reali­zu­jąc sam ana­li­zę wyma­gań, ma ogrom­ny kon­flikt inte­re­su: z zasa­dy pre­fe­ru­je swo­je meto­dy, tech­no­lo­gie i roz­wią­za­nia, dają­ce mu naj­wyż­szą mar­że (rolą Dostawcy jest opra­co­wa­nie dopie­ro kon­cep­cji wdro­że­nia w odpo­wie­dzi na wyma­ga­nie przed­sta­wio­ne przez Zamawiającego)
3. po trze­cie pozo­sta­je pro­blem autor­skich praw mająt­ko­wych do wszel­kich nowo­pow­sta­łych funk­cjo­nal­no­ści, któ­re czę­sto sta­no­wią know-how zama­wia­ją­ce­go i nie­ste­ty, jeże­li ich auto­rem jest dostaw­ca, pra­wa te pozo­sta­ją przy nim. 

Dlatego na całym świe­cie poja­wia­ją się zale­ce­nia, by do pro­jek­tów anga­żo­wać ana­li­ty­ków-pro­jek­tan­tów nie­za­leż­nych od dostaw­ców, jako trze­cia stro­na wdro­że­nia. Nie jest praw­dą, że mają oni niż­sze kom­pe­ten­cje od dostaw­ców, jest dokład­nie odwrot­nie (10 lat wdra­ża­łem sys­te­mu ERP pra­cu­jąc u jed­ne­go z naj­więk­szych inte­gra­to­rów sys­te­mów ERP, od 20 lat mam kon­takt z kil­ko­ma fir­ma­mi, wdro­że­nia­mi i sys­te­ma­mi ERP rocz­nie, dostaw­ca sys­te­mu prak­tycz­nie zna tyl­ko swo­je rozwiązanie).

Patrz tak­że Ekspertyzy, rola bie­głe­go.

Rzecz w tym, że w bran­ży IT narzę­dzia pro­gra­mi­stycz­ne nigdy nie były pro­ble­mem, pro­ble­mem zawsze są źle zapro­jek­to­wa­ne aplikacje …

Źródła

Na zakończenie

Spory w pro­jek­tach wdro­że­nio­wych opro­gra­mo­wa­nia wspo­ma­ga­ją­ce­go zarzą­dze­nie są nie­ste­ty nadal nor­mą. Większość uda­je są roz­wią­zać polu­bow­nie mię­dzy stro­na­mi (media­cje), czę­sto jed­nak stra­ty i opóź­nie­nia są tak duże, że anga­żo­wa­ni są eks­per­ci z zewnątrz w celu ich minimalizowania. 

Jeżeli więc Państwo uzna­cie, że potrzeb­ne Wam jest mery­to­rycz­ne wspar­cie, chęt­nie pomo­gę ofe­ru­jąc doświad­cze­nie zdo­by­te w cią­gu 30 lat pra­cy nad pro­jek­to­wa­niem i wdra­ża­niem takich sys­te­mów, jak i kil­ku­na­stu lat pra­cy nauko­wej w obsza­rze inży­nie­rii sys­te­mów. Poniżej pro­sty for­mu­larz, któ­ry pomo­że sfor­mu­ło­wać Wasze ocze­ki­wa­nia i pyta­nie do mnie.

Zapytanie