Do budże­tu Zamawiającego moż­na pod­cho­dzić na wie­le spo­so­bów, ale … tyl­ko mene­dżer (Zamawiający) wie (powi­nien) jaki ma cel w swo­im pro­jek­cie, ​„fra­zes” w rodza­ju ​„cel powi­nien być zna­ny i mie­rzal­ny” coś w sobie ma.

Niestety bar­dzo czę­sto budżet na wdro­że­nie IT jest usta­la­ny jest metodą:

1. prze­ko­naj­my decy­den­tów, że nasz pro­dukt jest super (nie będę się roz­pi­sy­wał o meto­dach przekonywania),
2. jak ich prze­ko­na­my to naszą wstęp­nie pro­po­no­wa­na war­tość (koszt pro­jek­tu) sys­te­mu zapla­nu­ją w przy­szłym roku,
3. sko­ro zapla­no­wa­li to i wyda­dzą (zro­bi­my wszyst­ko by u wyda­li nas).

Ten pro­ces to kosz­mar. Dlaczego? Bo nie ma nic wspól­ne­go z pla­no­wa­niem, to po pro­stu zupeł­ne pogwał­ce­nie zasad rachun­ku eko­no­micz­ne­go, a co cie­ka­we, dają się na to namó­wić (że tego rachun­ku eko­no­micz­ne­go się dla IT nie liczy) nawet oso­by odpo­wie­dzial­ne za finan­se. No i czym jest sytu­acja, gdy dostaw­ca nam pro­jek­tu­je budżet na swo­je produkty?

Nasz system jest najlepszy

Proces ten wyglą­da tak:

Dostawca ​„lob­bu­je”. Zapada decy­zja, o tym jaki pro­dukt zosta­nie wdro­żo­ny, potem ma miej­sce zbie­ra­nie wyma­gań (robi to czę­sto dostaw­ca, i ana­li­zą tego nie nazwę), kolej­ny etap to ​„wal­ka” czy­li dosto­so­wy­wa­nie sys­te­mu ERP do potrzeb użyt­kow­ni­ka (potocz­nie zwa­na kasto­mi­za­cją). Jest to kosz­tow­ny, mało prze­wi­dy­wal­ny pro­ces, któ­ry naj­czę­ściej dodat­ko­wo odci­na użyt­kow­ni­ka od przy­szłych uak­tu­al­nień ([[upgra­de opro­gra­mo­wa­nia]]), gdyż te znisz­czy­ły by te kasto­mi­za­cje (tu upgra­de rów­na się powtó­rze­niu całe­go wdro­że­nia). Jeżeli więc od razu cały ten pro­ces wyko­na dostaw­ca kon­kret­ne­go pro­duk­tu to w zasa­dzie nie mamy żad­nej wie­dzy na temat tego czy ów dostaw­ca (nawet skła­da­ją­cy ofer­tę w dobrej wie­rze) ma opty­mal­ne dla nas roz­wią­za­nie, bo może jest to coś naj­gor­sze­go i co gor­sza nigdy się tego nie dowie­my, bo nie mamy żad­ne­go porównania.

Jaką mamy alternatywę?

Przede wszyst­kim, zakup pro­duk­tu (opro­gra­mo­wa­nia ERP, CRM itp.) NA KOŃCU! Bo to mini­ma­li­zu­je ryzy­ko złe­go wybo­ru. Zaczynamy od planowania.

Dobrą prak­ty­ką wpro­wa­dza­nia zmian w fir­mie i ana­li­zy czy to ma sens, jest opi­sa­nie swo­je­go celu (wizja pro­jek­tu) jako sytu­acji ide­al­nej, a potem dopie­ro tego, co moż­na i jakim kosz­tem osią­gnąć (na ile jeste­śmy w sta­nie zbli­żyć się do tego celu) – wyko­nać ana­li­zę wyko­ny­wal­no­ści wła­sne­go pla­nu. Wtedy w ogó­le wie­my czy mamy szan­sę na 90% reali­za­cji pla­nu (wizji) czy tyl­ko na 20% … jeże­li ​„próg sen­su” to np. 75% to wie­my że reali­za­cja 78% jest dość ryzy­kow­na (plan na styk) a 86% daje duże szan­se na to, że pro­jekt się uda.

Tak więc budżet pro­jek­tu IT to pro­go­wy, sen­sow­ny koszt wpro­wa­dze­nia zmia­ny w fir­mie na lep­sze (zakła­dam, że nie jest celem sam fakt kupie­nia nowych zaba­wek). I ten koszt (mak­sy­mal­ny sen­sow­ny) powi­nien być fir­mie (jej zarzą­do­wi) zna­ny, bo powi­nien zostać wyli­czo­ny (okre­ślo­ny) jako [[RIO]] lub [[NPV]]. Oferty muszą się w nim zmieścić.

Zlecamy ana­li­zę, któ­rej pro­duk­tem będzie spe­cy­fi­ka­cja wyma­gań biz­ne­so­wych zawie­ra­ją­ca wyma­ga­nia funk­cjo­nal­ne, poza-funk­cjo­nal­ne oraz [[model dzie­dzi­ny sys­te­mu]]. Mamy teraz klu­czo­we infor­ma­cje o tym do cze­go goto­wy sys­tem ma paso­wać. Takie zapy­ta­nie wysy­ła­my ​„w rynek”, wybie­ra­my ofer­tę naj­le­piej pasu­ją­cą do naszych wymagań.

Jeżeli zosta­ły jakieś nie obsłu­żo­ne wyma­ga­nia to NIE ZGADZAMY SIĘ NA DOPASOWANIE. A co robi­my? Pytamy ile kosz­tu­je (dru­gie zapy­ta­nie, albo od razu taki waru­nek umiesz­cza­my w pierw­szym) wytwo­rze­nie bra­ku­ją­cych funk­cjo­nal­no­ści. Należy je zapro­jek­to­wać, wyko­nać i zin­te­gro­wać. Co cie­ka­we taką wła­śnie ścież­kę postę­po­wa­nia znaj­dzie­my w doku­men­tach o wdzięcz­nej nazwie ​„meto­dy­ka wdro­że­nia pole­ca­na przez pro­du­cen­ta sys­te­mu ERP” (komu z Państwa poka­za­no ten dokument???) .

Powinny do nas dotrzeć pro­po­zy­cje mówią­ce: ​„mamy pro­dukt, któ­ry w X% pasu­je do zapy­ta­nia, bra­ku­ją­ce rze­czy wyko­na­my za X zł w X cza­sie”. Mając te ofer­ty podej­mu­je się decyzję.

Brakujące funkcjonalności

Dobre sys­te­my, to sys­te­my mają­ce tak zwa­ne nie­za­leż­ne śro­do­wi­sko uru­cho­mie­nio­we (zwa­ne zależ­nie od posta­ci ser­we­rem apli­ka­cyj­nym lub fra­me­wor­kiem). Nowe funk­cjo­nal­no­ści nale­ży zapro­jek­to­wać i wytworzyć:

Jest to wygod­ne, bo wynik wyko­na­nej już ana­li­zy, nale­ży tyl­ko uzu­peł­nić o pro­jekt bra­ku­ją­cej w wybra­nym pro­duk­cie logi­ki biz­ne­so­wej, prze­ka­zać dostaw­cy sys­te­mu lub wybrać fir­mę spe­cja­li­zu­ją­cą się w two­rze­niu opro­gra­mo­wa­nia (nie­ste­ty prak­ty­ka poka­zu­je bar­dzo czę­sto, że dobrzy kon­sul­tan­ci od kasto­mi­za­cji ERP są bar­dzo zły­mi pro­gra­mi­sta­mi). Tak powsta­ły pro­dukt inte­gru­je­my z zaku­pio­nym wcze­śniej sys­te­mem. Jest bar­dzo dobrze, jeśli nowe funk­cje zosta­ną zaim­ple­men­to­wa­ne w natu­ral­nym dla nasze­go ERP śro­do­wi­sku (wię­cej pisa­łem o tym tu).

I po tym przy­dłu­gim i oczy­wi­stym wstępie

- z per­spek­ty­wy (uczci­we­go) dostaw­cy nie ma sen­su skła­da­nie ofer­ty ceno­wej, nie wie­dząc w ogó­le do cze­go i czy w ogó­le jest nasz pro­dukt potrzebny,

- z per­spek­ty­wy nabyw­cy nie ma sen­su ​„szu­ka­nie cze­goś faj­ne­go” z nadzie­ją, że coś w ogó­le z tego wyj­dzie, nawet jeśli ​„to coś faj­ne­go” mają inni.

Moim zda­niem budżet zama­wia­ją­ce­go to wie­dza zama­wia­ją­ce­go, któ­rej nie musi ujaw­niać. Skoro już jej nie ujaw­nia to powi­nien mieć kom­pe­ten­cje (wła­sne lub wyna­ję­te) pozwa­la­ją­ce po pierw­sze opi­sać pro­jekt, po dru­gie zde­fi­nio­wać (opi­sać) ​„to coś infor­ma­tycz­ne­go” co pomo­że mu ten pro­jekt zrealizować.

Wyjawienie przez Zamawiającego pla­nów i budże­tu dostaw­cy, to posta­wie­nie się pod ścia­nę w nego­cja­cjach z nim, to jak wejść do skle­pu z AGD i powie­dzieć gło­śno: mam 5 tys. na tele­wi­zor, co pro­po­nu­je­cie? Dlatego nie ma sen­su dopusz­cze­nie do sytu­acji gdy dostaw­ca pyta Zamawiającego o jego budżet. I nie ma tu zna­cze­nia uczci­wość tego dostaw­cy bo z per­spek­ty­wy klien­ta sprze­daw­ca na pro­wi­zji sta­no­wi duże ryzy­ko dla rze­tel­no­ści takiej oferty.

I na koniec:

napi­sa­nie tyl­ko ​„sys­tem ma wysta­wiać fak­tu­ry VAT” jako opis tego co chce­my kupić, nie ma żad­ne­go sen­su bo to sta­now­czo za mało by cokol­wiek wyce­nić i oce­nić.… ale też napi­sa­nie, że ​„kon­tra­hen­ta moż­na dodać do fak­tu­ry z roz­wi­ja­nej listy uru­cha­mia­nej pra­wym kla­wi­szem myszy”, jest jesz­cze więk­szym błę­dem, bo po pierw­sze nie raz narzu­ca wspo­mnia­ną kasto­mi­za­cję (a to pod­no­si koszt), a po dru­gie bywa­ją lep­sze spo­so­by roz­wią­za­nia tego pro­ble­mu. Dla goto­we­go sys­te­mu nie ma sen­su pisa­nie aż takich szcze­gó­łów, a dla dedy­ko­wa­ne­go robi się to zupeł­nie inaczej.