ERP a zwrot z inwestycji – czy ROI na sens?

Niezmiennie od lat emo­cje budzą dys­ku­sje na temat sen­sow­no­ści i ren­tow­no­ści wdro­żeń opro­gra­mo­wa­nia. Szczególnie gorą­ce są one w toku skła­da­nia ofert przez dostaw­ców opro­gra­mo­wa­nia. Jedenaście lat temu napi­sa­łem, że…

Nie zawsze podo­ba­ją mi się wskaź­ni­ki ROI, TCO, NPV. Dlaczego? Bo one nie raz nie­wie­le mówią! […] …bada­nia lide­rów gospo­dar­czych w poszcze­gól­nych kra­jach pro­wa­dzo­ne na całym świe­cie wska­zu­ją jasno, że nie ma żad­nej kore­la­cji pomię­dzy miej­scem na liście lide­rów ryn­ku a tym jakich sys­te­mów IT ci lide­rzy uży­wa­ją. Za to jest zwią­zek z tym jak są te fir­my zarzą­dza­ne. Liderzy ryn­ku nie naśla­du­ją kon­ku­ren­cji i nie ści­ga­ją się z nią tyl­ko two­rzą. Zresztą kogo lider miał­by gonić sko­ro jest lide­rem. I tu oka­zu­je się, że ist­nie­je para­doks: lider czę­sto pozo­sta­je lide­rem mimo, że niko­go nie naśla­du­je, nie kopiu­je naj­lep­szych prak­tyk, nie uży­wa bench­mar­kin­gu do roz­wo­ju, co naj­wy­żej do kon­tro­li tego jak dale­ko jest za nim kon­ku­ren­cja. A co to ma do sys­te­mów IT? Okazuje się, że dużo. Otóż lide­rzy ryn­ku mają stra­te­gię i ją wdra­ża­ją, sys­tem IT zaś jest narzę­dziem reali­za­cji tej stra­te­gii. Jeżeli dla kogoś stra­te­gią ryn­ko­wą jest wdro­że­nie sys­te­mu np. ERP jako takie­go to ma kło­po­ty bo to nie jest to stra­te­gia fir­my tyl­ko plan inwe­sty­cji. Inwestycje może­my trak­to­wać taki­mi wskaź­ni­ka­mi jak ROI, TCO, NPV ale czym zmie­rzyć sto­pień reali­za­cji stra­te­gii? [1]

Przede wszyst­kim posta­wić nale­ży pyta­nie: czy zakup opro­gra­mo­wa­nia to inwe­sty­cja a jeże­li tak to jaka lub w co?

Słownik języ­ka pol­skie­go mówi:

inwe­sty­cja 1. ?prze­zna­cze­nie środ­ków finan­so­wych na powięk­sze­nie lub odtwo­rze­nie zaso­bów mająt­ko­wych? 2. ?część dóbr wytwo­rzo­nych, któ­ra nie jest prze­zna­czo­na do bez­po­śred­niej kon­sump­cji? 3. ?przed­miot będą­cy efek­tem inwe­sto­wa­nia? 4. ?prze­zna­cze­nie środ­ków finan­so­wych i cza­su na (czy­jeś) kształ­ce­nie z myślą o korzy­ściach w przy­szło­ści? [2]

Innymi sło­wy, każ­dy wyda­tek powięk­sza­ją­cy mają­tek to inwe­sty­cja, samo sło­wo inwe­sty­cja nie ozna­cza korzy­ści (ta może być nietrafiona).

Literatura eko­no­micz­na podaje:

Inwestycje- to wyko­rzy­sta­nie środ­ków finan­so­wych w celu naby­cia skład­ni­ków mająt­ko­wych, finan­so­wych środ­ków mająt­ko­wych oraz nie­ma­te­rial­nych war­to­ści akty­wów trwa­łych. To tak­że akty­wa naby­wa­ne w celu uzy­ska­nia korzy­ści eko­no­micz­nych, któ­re są efek­tem przy­ro­stu z ich war­to­ści, uzy­ska­nia odse­tek, dywi­dend lub innych źró­deł w tym tak­że z trans­ak­cji han­dlo­wych. Inwestycje to zaan­ga­żo­wa­nie finan­so­we w dane przed­się­wzię­cie w celu uzy­ska­nia korzy­ści pole­ga­ją­ce przede wszyst­kim na prze­zna­cze­niu zaso­bów finan­so­wych, [3]

Tu poja­wia się poję­cie korzy­ści eko­no­micz­nych” co suge­ru­je, że per sal­do inwe­stor będzie na plu­sie” czy­li wydat­ki ponie­sio­ne na inwe­sty­cje zwró­cą się w jakimś okre­ślo­nym cza­sie. Pojęcia zwro­tu z inwe­sty­cji i wskaź­ni­ka tego zwro­tu defi­nio­wa­ne są tak:

Wskaźnik ren­tow­no­ści inwe­sty­cji ROI (z ang. return on inve­st­ment) to sto­su­nek zysku ope­ra­cyj­ne­go opo­dat­ko­wa­ne­go do nakła­dów inwe­sty­cyj­nych (w nie­któ­rych opra­co­wa­niach: sto­su­nek zysku net­to do akty­wów ogó­łem). Wartość ROI poka­zu­je, jaki jest dla naszej fir­my mak­sy­mal­ny koszt dłu­gu (opro­cen­to­wa­nie), przy któ­rym opła­ca się z nie­go korzy­stać, zakła­da­jąc, że siła zarob­ko­wa akty­wów nie ule­gnie zmia­nie. Jako meto­da pro­sta, ROI ma zasto­so­wa­nie głów­nie pomoc­ni­cze na wstęp­nym eta­pie oce­ny pro­jek­tu inwe­sty­cyj­ne­go. [4]

Wzór na wyli­cze­nie ROI:

a) wynik w procentach
ROI = (P-I)/I * 100%
b) wynik w stosunku liczbowym
ROI = P / I
Gdzie: P ? zysk ; I ? inwestycje

To wyli­cze­nie wyma­ga zało­że­nia okre­ślo­ne­go cza­su po jakim ten zwrot ma nastą­pić (dla­te­go bar­dziej mia­ro­daj­nym wskaź­ni­kiem jest NPV [5] ). 

Takie defi­nio­wa­nie inwe­sty­cji ma jed­nak pew­ną wadę: odno­si się wyłącz­nie do przed­mio­tu inwe­sty­cji co jest moim zda­niem ogrom­nym uprosz­cze­niem i zawę­że­niem pro­ble­mu. Każda orga­ni­za­cja to sys­tem zło­żo­ny z wie­lu ele­men­tów, któ­re razem dopie­ro sta­no­wią całość. Dział HR to koszt, czy ktoś roz­sąd­ny podej­mie pró­bę oce­ny pro­stej ren­tow­no­ści wydat­ków na ten dział? Podobnie księ­go­wość. Oprogramowanie to jed­no­ra­zo­wy wyda­tek na zakup i wdro­że­nie ale potem tak­że na utrzy­ma­nie i roz­wój. Jakie licz­by wsta­wi­my do wzo­ru na ROI” sko­ro wydat­ki są sta­łe czy­li nie koń­czą się dopó­ki mamy to oprogramowanie?

Czy zakup opro­gra­mo­wa­nia to inwe­sty­cja? Jak widać z defi­ni­cji chy­ba jed­nak nie! To koszt sta­ły poprze­dzo­ny pew­ną kwo­tą zwią­za­ną z pier­wot­nym uruchomieniem. 

W swo­im arty­ku­le opi­sa­łem pro­sty przy­kład tego co nazy­wa się (pole­cam lek­tu­rę całe­go tego artykułu):

…sce­na­riu­szo­we meto­dy oce­ny ren­tow­no­ści. Inwestycje oce­nia się nie po jej kosz­tach jed­nost­ko­wych w sto­sun­ku do sta­no­wisk pra­cy ale w kon­tek­ście cał­ko­wi­tych skut­ków reor­ga­ni­za­cji fir­my po wdro­że­niu. Te skut­ki to np. skró­ce­nie cza­su przy­go­to­wy­wa­nia ofert, obni­że­nie ryzy­ka, nowy inter­ne­to­wy kanał sprze­da­ży. Drugi bar­dzo waż­ny i jesz­cze rzad­ko zauwa­ża­ny czyn­nik to war­tość doda­na do pro­duk­tu fir­my jaką wpro­wa­dza wdro­żo­ny sys­tem. [1]

W skró­cie oce­na zasad­no­ści zaku­pu powin­na pole­gać na porów­na­niu dwóch cało­ścio­wych sta­nów rze­czy: mamy to opro­gra­mo­wa­nie oraz nie mamy tego opro­gra­mo­wa­nia. Jedna z metod reali­zo­wa­nia takich ana­liz jest budo­wa­nie budże­tu fir­my dla oby­dwu tych sce­na­riu­szy. Możemy nie mieć moż­li­wo­ści bez­po­śred­nie­go wska­za­nia, któ­ra część zysków to efekt wdro­że­nia opro­gra­mo­wa­nia, ale jeste­śmy w sta­nie oce­nić czy EBITDA fir­my się popra­wi czy pogor­szy po takim wdro­że­niu. Wdrażanie opro­gra­mo­wa­nia i oce­na korzy­ści z tego, to pro­blem zbli­żo­ny do tego, któ­ry opi­su­je sta­ra aneg­do­ta o kosz­tach rekla­my: wie­my że poło­wa pie­nię­dzy na rekla­mę to pie­nią­dze wyrzu­co­ne w bło­to, rzecz w tym, że nie wie­my któ­ra to. W naszym przy­pad­ku wdra­ża­jąc opro­gra­mo­wa­nie w takiej ska­li jak to ma miej­sce w przy­pad­ku ERP, doty­ka­my od razu wie­lu sfer i obsza­rów dzia­ła­nia fir­my i prak­tycz­nie nie ma moż­li­wo­ści oce­ny któ­ra z nich daje korzy­ści a któ­ra nie.

I tu poja­wia się dru­gi pro­blem: czy ma sens kom­plek­so­we wdro­że­nie jakie­go­kol­wiek zin­te­gro­wa­ne­go opro­gra­mo­wa­nia? Pierwsza wada: ogro­my jed­no­ra­zo­wy wyda­tek. Druga wada: im bar­dziej cało­ścio­we wdro­że­nie tym bar­dzie nie wie­my co się zwró­ci­ło” a co nie… 

Powyższe pro­ble­my zilu­stru­ję, pew­ną opi­nią, któ­ra jest w moich oczach repre­zen­ta­tyw­na dla takich dyskusji:

Opinie odno­śnie sza­co­wa­nia zwro­tu z inwe­sty­cji w sys­tem ERP są podzie­lo­ne. Niektórzy dostaw­cy wprost poka­zu­ją klien­tom wyli­cze­nia mają­ce dowieść kon­kret­nych oszczęd­no­ści, jakie fir­ma uzy­ska po wdro­że­niu sys­te­mu wspie­ra­ją­ce­go zarzą­dza­nie przed­się­bior­stwem. Firmy, któ­re korzy­sta­ją z ERP mają jed­nak na kwe­stię ROI odmien­ny pogląd. […]
Aby wyli­czyć ROI, fir­my posłu­gu­ją się zazwy­czaj dwie­ma meto­da­mi. Najprostszym roz­wią­za­niem jest poli­cze­nie, w jakim cza­sie zwra­ca się inwe­sty­cja w sys­tem. Im dłuż­szy jest ten czas, tym inwe­sty­cja sta­je się bar­dziej ryzy­kow­na i mniej atrak­cyj­na. Podobnie, im więk­sza inwe­sty­cja począt­ko­wa, tym dłuż­szy czas zwro­tu z inwe­sty­cji. Według danych Panorama Consulting tyl­ko w co 4 przy­pad­ku koszt wdro­że­nia zwró­cił się w cią­gu pierw­szych dwóch lat. Dlatego Wojciech Różalski z DEFRO zale­ca na począt­ku wdro­że­nie stan­dar­do­wych modu­łów sys­te­mu, dopie­ro wów­czas, gdy fir­ma dobrze pozna jego moż­li­wo­ści, war­to pomy­śleć o rozbudowie.

Według innej i bar­dziej cza­so­chłon­nej meto­dy, ROI wyli­cza się roz­wa­ża­jąc alter­na­tyw­ne meto­dy inwe­sty­cji. Przychody gene­ro­wa­ne po wdro­że­niu sys­te­mu ERP porów­nu­je się z inny­mi roz­wią­za­nia­mi, któ­re w tym cza­sie fir­ma mogła zasto­so­wać ? choć­by ban­ko­we­go depo­zy­tu, czy inwe­sty­cji w park maszy­no­wy. Ta meto­da też jed­nak ma swo­je ograniczenia. […]

W fir­mach, któ­re roz­wi­ja­ją się bar­dzo szyb­ko ? tak jak Defro ? trud­no jest odwzo­ro­wać, jakie fak­tycz­nie ERP przy­nio­sło korzy­ści. Oczywiście, łatwo stwier­dzić co się zmie­ni­ło na lep­sze, trud­no jed­nak to prze­kuć na licz­by ? zwra­ca uwa­gę Sławomir Kuźniak z fir­my BPSC, któ­ra ma na swo­im kon­cie ponad 700 zre­ali­zo­wa­nych wdro­żeń sys­te­mu ERP. […]

opi­nia Konrada Krychowiaka ? Nie wyobra­żam sobie rapor­to­wa­nia i pro­wa­dze­nia tak duże­go przed­się­bior­stwa jak DGS bez ERP opar­te­go o rela­cyj­ną bazę danych. Bez sys­te­mu nawet pro­sta ana­li­za cze­go­kol­wiek była­by nie­moż­li­wa. ERP to rów­nież fun­da­ment do budo­wy roz­wią­zań kom­ple­men­tar­nych, np. ety­kie­to­wa­nia towa­rów w opar­ciu o dane z ERP ? tłu­ma­czy Konrad Krychowiak z Guala Closures DGS Poland. (Źródło: ERP a zwrot z inwe­sty­cji – czy w ogó­le war­to liczyć ROI?)

Teraz na zakoń­cze­nie kil­ka uwag i komentarzy:

  1. Skoro: Najprostszym roz­wią­za­niem jest poli­cze­nie, w jakim cza­sie zwra­ca się inwe­sty­cja w sys­tem. Im dłuż­szy jest ten czas, tym inwe­sty­cja sta­je się bar­dziej ryzy­kow­na i mniej atrak­cyj­na. Podobnie, im więk­sza inwe­sty­cja począt­ko­wa, tym dłuż­szy czas zwro­tu z inwe­sty­cji.” to zna­czy, że im droż­sze i bar­dziej kom­plek­so­we roz­wią­za­nie tym więk­sze sta­no­wi ryzyko.
  2. Metody sce­na­riu­szo­we to wła­śnie roz­waż­ne alter­na­tyw­ne meto­dy inwe­sty­cji. Przychody gene­ro­wa­ne po wdro­że­niu sys­te­mu ERP porów­nu­je się z inny­mi roz­wią­za­nia­mi”, pro­blem w tym, że taka ana­li­za wyma­ga posia­da­nia wdro­żo­ne­go sys­te­mu kon­tro­lin­gu i budżetowania. 
  3. Twierdzenia, że W fir­mach, któ­re roz­wi­ja­ją się bar­dzo szyb­ko ? tak jak Defro ? trud­no jest odwzo­ro­wać, jakie fak­tycz­nie ERP przy­nio­sło korzy­ści. ” to w moich oczach jaw­ne przy­zna­nie się, że decy­zja o sen­sow­no­ści zaku­pu to czy­ste spekulacje. 
  4. Niestety ostat­nie z przy­to­czo­nych zdań: Nie wyobra­żam sobie rapor­to­wa­nia i pro­wa­dze­nia tak duże­go przed­się­bior­stwa jak DGS bez ERP opar­te­go o rela­cyj­ną bazę danych. ” to już czy­stej wody, niczym nie popar­ta rekla­ma i spe­ku­la­cja. Opieranie opi­nii eks­perc­kich na wyobraź­ni” mnie oso­bi­ście kłu­je w oczy. Tezy, że musi to (roz­wią­za­nie) być koniecz­nie rela­cyj­na baza danych” to w dzi­siej­szych cza­sach raczej obro­na skan­se­nu. Z powo­dów nie tyl­ko, wska­za­ne­go wyżej, ogrom­ne­go ryzy­ka jakim jakim jest wdro­że­nie od razu cało­ścio­we­go mono­li­tu jakim są ERP, wdro­że­nia są coraz czę­ściej roz­kła­da­ne w cza­sie na zakup odręb­nych dzie­dzi­no­wych pod­sys­te­mów. Wynika to tak­że z tego, że nie da się w obec­nych cza­sach przy­jąć zało­że­nia, że w okre­sie 3 do 5 lat wdro­że­nia (typo­we dla wdro­żeń zin­te­gro­wa­nych ERP) nie ule­gnie zmia­nie sytu­acja ryn­ko­wa i tak­ty­ka ryn­ko­wa firmy…

Bibliografia

[1]
J. Zelinski, ?ROI, TCO, NPV czy zawsze mówią praw­dę? Może jed­nak sce­na­riu­sze?,? Jarosław Żeliński IT-Consulting, 09-Jan-2006. [Online]. Available: https://it-consulting.pl//2006/01/09/roi-tco-npv-czy-zawsze-mowia-prawde-moze-jednak-scenariusze/. [Accessed: 21-Aug-2017]
[2]
S. SJP, ?inwe­sty­cja – defi­ni­cja, syno­ni­my, przy­kła­dy uży­cia,? SJP. [Online]. Available: https://​sjp​.pwn​.pl/​s​z​u​k​a​j​/​i​n​w​e​s​t​y​c​j​a​.​h​tml. [Accessed: 21-Aug-2017]
[3]
?Inwestycje,? Encyklopedia Zarządzania. [Online]. Available: https://​mfi​les​.pl/​p​l​/​i​n​d​e​x​.​p​h​p​/​I​n​w​e​s​t​y​cje. [Accessed: 21-Aug-2017]
[4]
?Wskaźnik ren­tow­no­ści inwe­sty­cji,? Encyklopedia Zarządzania. [Online]. Available: https://mfiles.pl/pl/index.php/Wska%C5%BAnik_rentowno%C5%9Bci_inwestycji. [Accessed: 21-Aug-2017]
[5]
?NPV,? Encyklopedia Zarządzania. [Online]. Available: https://​mfi​les​.pl/​p​l​/​i​n​d​e​x​.​p​h​p​/​NPV. [Accessed: 21-Aug-2017]

Rentowność projektu czyli jego wizja i wykonywalność – należy planować

dashboard

W arty­ku­le o szko­le­niu i ana­li­zie na bazie stan­dar­du IIBA i BABoK napi­sa­łem, że war­to pla­no­wać, pro­jek­to­wać i ana­li­zo­wać, bo wte­dy pro­jek­ty są prze­wi­dy­wal­ne zamiast być lote­rią.” (źr. IIBA czy­li ?jak to nie­któ­rzy robią w Ameryce? | Jarosław Żeliński – rynek IT, ana­li­za biz­ne­so­wa i pro­jek­to­wa­nie sys­te­mów.)

Pisząc to mam świa­do­mość tego, że przy­tła­cza­ją­ca więk­szość dostaw­ców opro­gra­mo­wa­nia wma­wia swo­im klien­tom, że oce­na ren­tow­no­ści jest nie­moż­li­wa w pro­jek­tach IT i nale­ży kupić co dają a nie jęczeć. Niestety wie­lu kupu­ją­cych w to wie­rzy i inwe­stu­je nie raz wie­lo­krot­nie wię­cej niż mia­ło by to eko­no­micz­ny sens.

(moja uwa­ga rok 2019: teraz mogę oce­nić, że więk­szość opro­gra­mo­wa­nia jakie audy­to­wa­łem, mia­ła nawet o rząd wiel­ko­ści wię­cej kodu niż mogła­by mieć!) 

Popatrzmy więc na pierw­szy etap ana­li­zy biz­ne­so­wej, budo­wę wizji pro­jek­tu i oce­nę wyko­ny­wal­no­ści. Pierwszy etap to ana­li­za strategiczna.

Analiza stra­te­gicz­na dzia­łal­no­ści to ana­li­za rela­cji pomię­dzy cela­mi biz­ne­so­wy­mi a biz­ne­so­wy­mi funk­cja­mi wspie­ra­ją­cy­mi je. Wizja roz­wią­za­nia powin­na odno­sić się do szan­sy biz­ne­so­wej i celu biz­ne­so­we­go. Tak więc powin­na powstać wizja reali­za­cji celu biz­ne­so­we­go (a naj­pierw sam cel oczy­wi­ście). Wizja ta naj­czę­ściej jest pew­nym ide­ałem, któ­ry nie zawsze jeste­śmy w sta­nie zre­ali­zo­wać (i czę­sto tak jest). Jednak ide­ał ten nale­ży zde­fi­nio­wać bo sta­no­wi on nasze zro­zu­mie­nie celu biz­ne­so­we­go, celu do któ­re­go fir­ma dąży.

Jak zapew­ne pamię­ta­my z pod­staw mar­ke­tin­gu: wizja fir­my do stan (swój lub swo­je­go oto­cze­nia ryn­ko­we­go), któ­ry postrze­ga­my jako ide­al­ny, misja fir­my to spo­sób dąże­nia do osią­gnię­cia tego celu.

Projekt roz­wo­ju ana­lo­gicz­nie, powi­nien mieć wizję (ide­al­ne roz­wią­za­nie), plan (osią­gal­ne roz­wią­za­nie) i stra­te­gię osią­gnię­cia tego pla­nu. Całość powin­na być osa­dzo­na w budże­cie fir­my i jej rachun­ku prze­pły­wów gotów­ko­wych. I nie cho­dzi jedy­nie o umiesz­cze­nie kosz­tów pro­jek­tu w budże­cie i oce­nę czy fir­ma to wytrzy­ma (meto­da bar­dzo czę­sto for­so­wa­na przez sprze­daw­ców roz­wią­zań IT). Chodzi o to by powią­zać te kosz­ty z odpo­wia­da­ją­cy­mi im przy­cho­da­mi oce­nić zasad­ność ich ponoszenia.

Tak więc mamy trzy ele­men­ty projektu:

  1. stan obec­ny,
  2. wizję
  3. oraz pla­no­wa­ny zakres projektu

W ramach ana­li­zy biz­ne­so­wej powi­nien naj­pierw powstać opis sta­nu obec­ne­go. Opis ten nie musi być kosz­tow­nym mode­lem pro­ce­sów biz­ne­so­wych na stan dzi­siej­szy”. Opracowanie szcze­gó­ło­we­go i kosz­tow­ne­go opi­su sta­nu obec­ne­go nie wie­le wno­si do pro­jek­tu a jest bar­dzo kosz­tow­ne. Stan obec­ny, tak zwa­ny opis as-is, to efekt tego jak poszcze­gól­ni mene­dże­ro­wie zarzą­dza­ją swo­imi zaso­ba­mi, a to zaś jest efek­tem zadań jakie im posta­wio­no. Pastwienie się nad tym bar­dzo rzad­ko wno­si war­to­ści do projektu.

Ważnym ele­men­tem pro­jek­tu jest zde­fi­nio­wa­nie po co to robi­my” i nie powi­nien to być argu­ment bo inni mają”. Benchmarking na tym eta­pie, pole­ga­ją­cy na porów­na­niu zaso­bów jest złym pomy­słem. Porównanie wskaź­ni­ków (czy­li wła­śnie bench­mar­king) nie jest porów­na­niem zaso­bów! Porównując się np. z kon­ku­ren­cją porów­nu­je­my cudze osią­gi z wła­sny­mi, jeże­li mamy taką moż­li­wość, to poza przy­cho­da­mi tak­że kosz­ty itp. Ale porów­na­nie takie to nie jest oce­na czym oni jeż­dżą” a oce­na jak oni jeżdżą”.

Po dru­gie kolej­na mar­ke­tin­go­wa zasada: 

nie da się sko­pio­wać cudze­go biz­ne­su, moż­na co naj­wy­żej usta­wić się obok. To jak w spo­rcie, goniąc kogoś może­my co naj­wy­żej iść po cudzych śla­dach za kimś, ale to nie to samo co zaję­cie cudzej pozy­cji bo to nie moż­li­we tą meto­dą. Wyprzedzanie pole­ga na zmia­nie toru ruchu by obejść konkurenta!

Tak więc pierw­szy krok to wizja. Drugi krok to ana­li­za wyma­gań, trze­ci to usta­le­nie zakre­su pro­jek­tu czy­li opra­co­wa­nie stu­dium wyko­ny­wal­no­ści. Dalej ma miej­sce uszcze­gó­ło­wie­nie pla­nu w zakre­sie projektu.

Określenie obsza­ru ren­tow­no­ści pro­jek­tu. Należy to zro­bić na samym począt­ku przy oka­zji budże­to­wa­nia i ana­li­zy prze­pły­wów gotów­ko­wych. To tu są dane o tym jakim kosz­tem i jakie korzy­ści chce­my osiągnąć.

Gdybyśmy mie­li wstęp­ną spe­cy­fi­ka­cję wyma­gań biz­ne­so­wych, to z każ­dym kolej­nym wyma­ga­niem przy­ra­sta łącz­ny koszt imple­men­ta­cji cało­ści. Korzyści poja­wia­ją się dopie­ro od pew­ne­go miej­sca, pew­ne mini­mum musi być zaim­ple­men­to­wa­ne, żeby sys­tem w ogó­le był przy­dat­ny. Idąc dalej osią­ga­my próg mini­mal­ny: korzy­ści zre­kom­pen­so­wa­ły nakła­dy. W mia­rę imple­men­ta­cji kolej­nych wyma­gań rosną korzy­ści jed­nak od pew­ne­go momen­tu ten wzrost się zała­mu­je. Dalsze ulep­sze­nia powo­du­ją, że koszt ulep­szeń zja­da” powsta­ją­ce korzy­ści. Osiągamy gór­ny próg rentowności.

Po wyko­na­niu takiej ana­li­zy wska­zu­je­my opty­mal­ny zakres pro­jek­tu: miej­sce gdzie bilans korzy­ści jest naj­ko­rzyst­niej­szy. Jest to stan to-be czy­li zapla­no­wa­ny świa­do­mie zakres projektu.

Jak prowadzić taką analizę?

Po pierw­sze nale­ży opra­co­wać spe­cy­fi­ka­cję wyma­gań biz­ne­so­wych. Każde z tych wyma­gań powin­no uzy­skać prio­ry­tet, np.:

  1. Bez nie­go potrze­by biz­ne­so­we nie zosta­ną zrealizowane
  2. Bez nie­go roz­wią­za­nie będzie mia­ło ogra­ni­czo­ną użyteczność
  3. Bez nie­go roz­wią­za­nie zre­ali­zu­je potrzeb­ny w pod­sta­wo­wej, pro­stej formie

To pozwo­li odrzu­cić wyma­ga­nia, któ­re powo­du­ją prze­kro­cze­nie budże­tu ren­tow­no­ści, a któ­re nie powo­du­ją zbyt duże­go pomniej­sze­nia osią­ga­nych korzyści.

Proces ten jest ite­ra­cyj­ny, mając jako model finan­so­wy rachu­nek prze­pły­wów gotów­ko­wych, może­my testo­wać wpływ wyma­gań na koszt pro­jek­tu i jego ren­tow­ność. Aby było to moż­li­we nale­ży w całym pro­ce­sie ana­li­zy wyma­gań pro­wa­dzić testy pro­jek­tu. Polegają one na tak zwa­nym śla­do­wa­niu. Cechy użyt­ko­we roz­wią­za­nia muszą się mapo­wać na potrze­by (cele) biz­ne­so­we. Stałe testo­wa­nie tego mapo­wa­nia to wła­śnie śla­do­wa­nie”. Zakres pro­jek­tu to w efek­cie lista cech pla­no­wa­nych do reali­za­cji w pro­jek­cie (wyma­ga­nych do reali­za­cji wizji). Śladowanie to, w całej doku­men­ta­cji obej­mu­je spraw­dza­nie mapowania:

Potrzeby biz­ne­so­we <?> Cechy użyt­ko­we wizji i zakre­su <?> Wymagania <?> Specyfikacja

Projekt ana­li­zy wyma­gań na każ­dym eta­pie jest testo­wa­ny, wali­do­wa­ny. Walidacja to spraw­dze­nie czy wyma­ga­nia są wła­ści­we. Kolejnym kro­kiem jest wyspe­cy­fi­ko­wa­nie roz­wią­za­nia. Zależnie od pro­jek­tu (może to być pro­jekt zmian orga­ni­za­cyj­nych, pro­jekt wdro­że­nia nowe­go opro­gra­mo­wa­nia) wali­do­wa­ne są wyma­ga­nia np. na nowy, pro­ce­so­wy sys­tem zarzą­dza­nia fir­mą (np. wyma­ga­nia w sto­sun­ku do nowej struk­tu­ry orga­ni­za­cyj­nej) albo na nowe opro­gra­mo­wa­nie wspo­ma­ga­ją­ce zarzą­dza­nie (np. ERP). Weryfikacja to testo­wa­nie roz­wią­za­nia, okre­śle­nie czy roz­wią­za­nie speł­nia wymagania.

Walidacja wymagań

Walidacja pole­ga na prze­te­sto­wa­niu czy nasze wyma­ga­nia zaspo­ka­ja­ją reali­za­cję celu biz­ne­so­we­go. Aby taki test prze­pro­wa­dzić, nale­ży zbu­do­wać model fir­my, któ­ry będzie­my testo­wa­li (raczej nie ma sen­su robie­nie tego na żywym cie­le”, było by to bar­dzo kosz­tow­ne). Te mode­le tu, to nic inne­go jak mode­le pro­ce­sów biz­ne­so­wych. Jednak model pro­ce­su to nie model wszyst­kie­go co się dzie­je”. Model pro­ce­su do testów to wewnętrz­ny model prze­pły­wu wartości”.

Modelujemy wyłącz­nie pro­ce­sy (prze­pływ pra­cy), nie pro­ce­du­ry, nie zakre­sy obo­wiąz­ków i nie kom­pe­ten­cje czy regu­ły biz­ne­so­we. Pozostałe szcze­gó­ły to obszar zarzą­dza­nia zaso­ba­mi czy zakre­sa­mi kom­pe­ten­cji (tu wię­cej o mode­lo­wa­niu). Mając popraw­ny model pro­ce­sów, może­my prze­te­sto­wać każ­de wyma­ga­nie i jego wpływ na procesy.

Biznesowa spe­cy­fi­ka­cja wyma­gań opi­su­je tak zwa­ną czar­ną skrzyn­kę”, czy­li nie zna­ne nam od środ­ka roz­wią­za­nie. Wymagania na tym eta­pie to tak zwa­ne przy­pad­ki uży­cia. Walidacja pole­ga wyłącz­nie na mapo­wa­niu (śla­do­wa­niu) celów biz­ne­so­wych na te wymagania.

Weryfikacja roz­wią­za­nia

Kolejny, ostat­ni etap ana­li­zy biz­ne­so­wej to wer­sy­fi­ka­cja roz­wią­za­nia. Mając tak zwa­li­do­wa­ną listę wyma­gań (tak zwa­ną Specyfikację Wymagań Biznesowych) może­my zabrać się za wery­fi­ka­cję roz­wią­za­nia. Tu sce­na­riusz wyglą­da tak:

  1. zapra­sza­my do skła­da­nia ofert dostaw­ców goto­we­go opro­gra­mo­wa­nia prze­ka­zu­jąc im spe­cy­fi­ka­cje wymagań,
  2. dostaw­ca pra­cu­jąc nad ofer­tą wery­fi­ku­je na ile jego roz­wią­za­nie speł­nia wyma­ga­nia (wyko­nu­je tak zwa­ną [[ana­li­zę gap/fit]]), powi­nien przed­sta­wić listę tak lub nie speł­nia­nia wyma­gań i swo­ją wycenę,
  3. jeże­li na tym eta­pie, ofer­ty są nie­sa­tys­fak­cjo­nu­ją­ce, opra­co­wu­je­my spe­cy­fi­ka­cję każ­dej funk­cjo­nal­no­ści (każ­de­go wyma­ga­nia) czy­li pro­jek­tu­je­my roz­wią­za­nie, któ­re­go nie zna­leź­li­śmy na rynku.

Na tym eta­pie zapa­da decy­zja o archi­tek­tu­rze roz­wią­za­nia: podział na ele­men­ty (pod­sys­te­my) goto­we i dedy­ko­wa­ne. Dedykowane muszą zostać zapro­jek­to­wa­ne. Projekty te (mode­le) są tak­że wery­fi­ko­wa­ne.

Kolejny etap to zapy­ta­nie o ofer­ty na reali­za­cję zapro­jek­to­wa­nych pod­sys­te­mów. W przy­pad­ku pro­jek­tów IT kom­plet­ne wyma­ga­nia to: przy­pad­ki uży­cia, regu­ły biz­ne­so­we, ogra­ni­cze­nia (wyma­ga­nia poza­funk­cjon­la­ne). Zaleca się (nie umiesz­czo­no na dia­gra­mie) uzu­peł­nie­nie mode­lu pro­ce­sów o tak zwa­ną taksonomię.

Jeżeli poja­wi się potrze­ba zapro­jek­to­wa­nia dedy­ko­wa­ne­go roz­wią­za­nia, poja­wi się model dzie­dzi­no­wy sys­te­mu wraz z uszcze­gó­ła­wia­ją­cy­mi go dia­gra­ma­mi sta­nów. Weryfikacja tej czę­ści spe­cy­fi­ka­cji pole­ga na tak zwa­nym testo­wa­niu bia­łej skrzyn­ki” czy­li pro­jek­tu roz­wią­za­nia. Tu są to dia­gra­mu sekwen­cji UML.

Całość pro­ce­su ana­li­zy i wery­fi­ka­cji bazu­je na opi­sa­nej już wcze­śniej Analizie Systemowej. Jeżeli zaś ktoś pro­po­nu­je jako wynik ana­li­zy wyma­gań, nie­we­ry­fi­ko­wal­ne wie­lo­stro­ni­co­we opi­sy w rodza­ju user sto­ry lub wypunk­to­wa­ne listy jako wyni­ki wywia­dów, burzy mózgów czy sesji JAD, to war­to mieć świa­do­mość, że to bar­dzo ryzy­kow­ne, bo nie­we­ry­fi­ko­wal­ne i nie­te­sto­wal­ne dokumenty.

Specyfikacja zawie­ra­ją­ca set­ki wypunk­to­wa­nych szcze­gó­ło­wo wyma­gań to nic inne­go jak nie­zro­zu­mie­nie fak­tu, że lista taka nie pod­da­je się żad­nym wali­da­cjom, a dla dostaw­cy goto­we­go opro­gra­mo­wa­nia jest bez­war­to­ścio­wa z uwa­gi na zbyt­nią szcze­gó­ło­wość. Z taka listą ana­li­za gap/fit wyka­że pra­wie cał­ko­wi­tą nie­zgod­ność z tym co ma w ofer­cie i u zde­spe­ro­wa­ne­go dostaw­cy wyge­ne­ru­je ofer­tę na tak zwa­ne kasto­mi­za­cje, te zaś zabi­ją budżet projektu.

Czy to warte zachodu

Praktyka takich ana­liz poka­zu­je, że pro­por­cje pro­jek­tów: ana­li­za i pro­jek­to­wa­nie vs. reali­za­cja, mają nastę­pu­ją­cą postać (dane sko­ry­go­wa­ne dla pro­jek­tów zna­nych auto­ro­wi w Polsce):

1. Czasowo: 50/50% (dane z USA: 75/25),

2. Kosztowo: 20 – 30/80 – 70% (dane z USA: 50/50, roz­rzut zale­ży od stop­nia zło­żo­no­ści dzie­dzi­ny systemu),

(zależ­nie od spe­cy­fi­ki pro­jek­tu i jego zło­żo­no­ści mogą poja­wić się pew­ne odstęp­stwa). Tak więc jak bume­rang wra­ca ta sama war­tość pro­go­wa pro­jek­tów, dla któ­rych war­to takie ana­li­zy robić. Jeżeli uzna­my, że opi­sa­na tu ana­li­za wyma­ga pew­nych nie­ma­łych kom­pe­ten­cji i doświad­cze­nia oraz pew­ne­go mini­mal­ne­go cza­su jaki nale­ży poświę­cić na zba­da­nie i opra­co­wa­nie mode­lu fir­my to jej koszt zaczy­na się od kil­ku­na­stu tysię­cy, daj­my na to 15 tys. W takim razie budżet całe­go pro­jek­tu powi­nien wymo­ści co naj­mniej 5 x 15 = 75 tys. zł. (pamię­ta­my, że koszt ana­li­zy to 20% war­to­ści pro­jek­tu). Analiza taka (dla tego nie­skom­pli­ko­wa­ne­go przy­pad­ku) wraz z pro­jek­to­wa­niem trwa, bio­rąc pod uwa­gę czas ocze­ki­wa­nia na przy­go­to­wy­wa­nie danych przez fir­mę ana­li­zo­wa­ną, ok. jed­ne­go miesiąca.

Ktoś może zarzu­cić powyż­szej kal­ku­la­cji nie­re­ali­zo­wal­ność wdro­że­nia w takim cza­sie. Odpowiem z prak­ty­ki tak: wdro­że­nia sys­te­mów ERP pozba­wio­ne eta­pu tak zwa­nej kasto­mi­za­cji” są bar­dzo spraw­ne. Koszty kasto­mi­za­cji zaś to nawet 75% kosz­tów całe­go wdro­że­nia (war­to popa­trzeć na ofer­ty, a moż­na tych kosz­tów uniknąć!).

Firmy pro­gra­mi­stycz­ne mają­ce dobry pro­jekt reali­zu­ją go i odda­ją do użyt­ku z regu­ły już w pierw­szym podej­ściu. Tak zwa­ne pro­to­ty­py, testy, odkry­wa­nie wyma­gań itp. to cechy pra­cy na źle, zbyt ogól­nie i bez testo­wa­nia (np. tak zwa­ne user sto­ry) okre­ślo­nych wyma­ga­niach. Jeżeli pro­jekt jest już wyko­na­ny i prze­te­sto­wa­ny na eta­pie ana­li­zy i wery­fi­ka­cji, fir­ma pro­gra­mi­stycz­na musi tyl­ko wyko­nać implementacje.

Jeżeli ktoś mimo to zaprze­cza powyż­sze­mu to musi mieć świa­do­mość, że negu­je potwier­dzo­ne doko­na­nia ostat­nich 20 lat wie­lu dobrych firm ana­li­tycz­nych na świe­cie, a od nie­daw­na tak­że w Polsce. Działalność IIBA i jej człon­ko­wie są na to żywym dowo­dem (na dowód mam tak­że swo­je referencje).

Dlaczego takich ana­liz wyko­nu­je się mało? No cóż, nie są one w inte­re­sie dostaw­cy, któ­ry twier­dzi, że jego sys­tem np. ERP jest na pew­no dobry”. Po dru­gie wie­le firm kupu­ją­cych opro­gra­mo­wa­nie uzna­je, że ich nie doty­czy ryzy­ko pro­jek­to­we i pomi­ja­ją ana­li­zy, a te są prze­cież niczym innym jak obni­że­niem ryzy­ka nie­po­wo­dze­nia takich pro­jek­tów. Pamiętajmy, że ponad 80% pro­jek­tów wdro­że­nio­wych w IT to pro­jek­ty z sil­nie prze­kro­czo­ny­mi budże­ta­mi i ter­mi­na­mi, część z nich (sza­cu­je się je na ok. 16%) to pro­jek­ty zanie­cha­ne z tego powodu.

Każdy z Państwa sam musi sobie odpo­wie­dzieć na pyta­nie: czy 20% budże­tu jest war­te tego by chro­nić pozo­sta­łe 80%.

(źr. bada­nia Cortex), dostęp 2011)

ROI, TCO, NPV czy zawsze mówią prawdę? Może jednak scenariusze?

variaNie zawsze podo­ba­ją mi się wskaź­ni­ki ROI, TCO, NPV. Dlaczego? Bo one nie raz nie­wie­le mówią! O ren­tow­no­ści sys­te­mów infor­ma­tycz­nych zapi­sa­no kilo­gra­my papie­ru więc dla­cze­go miał­bym i ja cze­goś nie dopi­sać. Tym bar­dziej, że bada­nia lide­rów gospo­dar­czych w poszcze­gól­nych kra­jach pro­wa­dzo­ne na całym świe­cie wska­zu­ją jasno, że nie ma żad­nej kore­la­cji pomię­dzy miej­scem na liście lide­rów ryn­ku a tym jakich sys­te­mów IT ci lide­rzy uży­wa­ją. Za to jest zwią­zek z tym jak są te fir­my zarzą­dza­ne. Liderzy ryn­ku nie naśla­du­ją kon­ku­ren­cji i nie ści­ga­ją się z nią tyl­ko two­rzą. Zresztą kogo lider miał­by gonić sko­ro jest lide­rem. I tu oka­zu­je się, że ist­nie­je para­doks: lider czę­sto pozo­sta­je lide­rem mimo, że niko­go nie naśla­du­je, nie kopiu­je naj­lep­szych prak­tyk, nie uży­wa bench­mar­kin­gu do roz­wo­ju, co naj­wy­żej do kon­tro­li tego jak dale­ko jest za nim konkurencja.

A co to ma do sys­te­mów IT? Okazuje się, że dużo. Otóż lide­rzy ryn­ku mają stra­te­gię i ją wdra­ża­ją, sys­tem IT zaś jest narzę­dziem reali­za­cji tej stra­te­gii. Jeżeli dla kogoś stra­te­gią ryn­ko­wą jest wdro­że­nie sys­te­mu np. ERP jako takie­go to ma kło­po­ty bo to nie jest to stra­te­gia fir­my tyl­ko plan inwe­sty­cji. Inwestycje może­my trak­to­wać taki­mi wskaź­ni­ka­mi jak ROI, TCO, NPV ale czym zmie­rzyć sto­pień reali­za­cji strategii?

Przykład. Pewna fir­ma pra­co­wa­ła na tak zwa­nych sys­te­mach dzie­dzi­no­wych, mia­ła maga­zy­nów­kę”, efkę” i jakiś tam mały CRM. Ogólnie spa­dek po powol­nej, eta­po­wej infor­ma­ty­za­cji jak wie­le firm. Zarząd fir­my zde­cy­do­wał, że dal­szy roz­wój fir­my wyma­ga zmia­ny jej stra­te­gii i pew­nej reor­ga­ni­za­cji. Opisano dokład­nie fir­mę, zbu­do­wa­no opis pro­ce­sów biz­ne­so­wych, prze­pro­wa­dzo­no ana­li­zę łań­cu­cha war­to­ści i porów­na­no z kon­ku­ren­cją (tu bench­mar­king jako narzę­dzie do wyzna­cze­nia warun­ków brzegowych).

Przebudowano pro­ce­sy i zde­fi­nio­wa­no nową stra­te­gię ryn­ko­wą. Strategia ta nasta­wio­na była na jakość i satys­fak­cję klien­tów (czy­li tu jesz­cze nic nowe­go). Jednak szcze­gó­ły tej stra­te­gii zosta­ły okre­ślo­ne po wyko­na­niu mode­lu biz­ne­so­we­go. Wygląda to tak: wyko­na­no szcze­gó­ło­wą seg­men­ta­cję ryn­ku, zde­fi­nio­wa­no klu­czo­we cechy odróż­nia­ją­ce tę fir­mę od kon­ku­ren­cji i sku­pio­no się na war­to­ści doda­nej wła­śnie w tak zde­fi­nio­wa­nym obszarze.

Teraz dopie­ro powsta­ło pyta­nie co musi­my mieć w fir­mie, żeby ta stra­te­gia dała się sku­tecz­nie zre­ali­zo­wać. Okazało się, że trze­ba: zbu­do­wa­ny model fir­my zapre­zen­to­wać całej zało­dze żeby każ­dy zro­zu­miał swo­ją role w fir­mie. Przeprowadzić reor­ga­ni­za­cję tak, by każ­dy pra­cow­nik wie­dział co się w fir­mie zmie­ni, po co i jaki on ma w tym udział. Na koń­cu okre­ślo­no jaki­mi cecha­mi powi­nien się cha­rak­te­ry­zo­wać nowy sys­tem poza tym, że ma być zin­te­gro­wa­ny. Powstał opis głów­nych pro­ce­sów zwią­za­nych bez­po­śred­nio z łań­cu­chem war­to­ści któ­re­go ele­men­tem jest nasza fir­ma. Nie two­rzo­no szcze­gó­ło­we­go opi­su czyn­no­ści na każ­dym sta­no­wi­sku bo to i tak zosta­nie usta­la­ne w trak­cie wdro­że­nia (w koń­cu jesz­cze nie wiem jesz­cze jakim narzę­dziem wes­prze­my tę naszą pracę).

Wymagania na [[sys­tem ERP]] okre­ślo­no wiec na bazie potrzeb pra­cow­ni­ków i opi­su pro­ce­sów oraz łań­cu­cha war­to­ści na ryn­ku. System wybra­no i wdro­żo­no. Jedną z jego klu­czo­wych cech była moż­li­wość prak­tycz­nie natych­mia­sto­we­go uzy­ski­wa­nia takich infor­ma­cji jak: zdol­no­ści pro­duk­cyj­ne, ren­tow­ność poszcze­gól­nych pro­duk­tów, kosz­ty poszcze­gól­nych pro­ce­sów oraz pro­gnoz zapo­trze­bo­wa­nia na zaso­by przy zada­nym zapo­trze­bo­wa­niu na produkty.

Przed wdro­że­niem sys­te­mu ERPII (bo o taki tu cho­dzi) wyko­na­nie ofer­ty na nie­ty­po­we zapy­ta­nie o dużą par­tię pro­duk­tów wyma­ga­ło ponad tygo­dnia ana­liz finan­so­wych, kon­sul­ta­cji z kie­row­ni­ka­mi pro­duk­cji ren­tow­no­ści i ryzy­ka. Po wdro­że­niu sys­te­mu (jego koszt ok. 500.000zł) dane takie moż­li­we są do uzy­ska­nia w cią­gu nawet kil­ku­na­stu minut.

Pewnego razu Prezes tej fir­my, jak to zwykł czy­nić, spo­tkał się z pre­ze­sem innej fir­my, poten­cjal­ne­go odbior­cy ich pro­duk­tów. W trak­cie roz­mo­wy został zapy­ta­ny czy jest w sta­nie zre­ali­zo­wać dosta­wę dużej par­tii towa­ru w cią­gu nad­cho­dzą­ce­go roku. Kłopot pole­gał na tym, że ten­że Prezes był w trak­cie nego­cja­cji kon­trak­tu eks­por­to­we­go i musiał mieć wia­ry­god­ną i wią­żą­ca odpo­wiedź w cią­gu godzi­ny. Jeden tele­fon do fir­my wystar­czył, by nasz Prezes otrzy­mał w cią­gu kil­ku­na­stu minut potrzeb­ny raport i symu­la­cję dosta­wy z jej kosz­ta­mi i ryzy­kiem nie­do­trzy­ma­nia ter­mi­nów. Złożył ofer­tę i zawarł umo­wę. Zysk na tym kon­tak­cie prze­kra­czał 1.000.000zł.

System zwró­cił się w cią­gu godziny!

Nie jest to baj­ka i nie trze­ba chy­ba niko­go do tego prze­ko­ny­wać. Przypadek co praw­da eks­tre­mal­ny ale obra­zu­je inną oce­nę ren­tow­no­ści. Wskaźniki takie jak ROI, TCO, NPV nic nam tu nie pomo­gą. Można nimi pró­bo­wać oce­nić inwe­sty­cje w sys­tem IT w kate­go­riach np. pod­no­sze­nia wydaj­no­ści pra­cy i auto­ma­ty­za­cji itp. ale nie w kate­go­riach jego roli we wspie­ra­niu stra­te­gii ryn­ko­wej fir­mie. Często jest tak, że nowy sys­tem nicze­go nie popra­wia w kate­go­riach wydaj­no­ści ale jego rola jest nie­oce­nio­na w fir­mie. Proszę spró­bo­wać w pro­sty mate­ma­tycz­ny spo­sób poli­czyć [[ROI dla hur­tow­ni danych]].

Powyższy przy­kład to tak zwa­ne [[sce­na­riu­szo­we meto­dy oce­ny]] ren­tow­no­ści. Inwestycje oce­nia się nie po jej kosz­tach jed­nost­ko­wych w sto­sun­ku do sta­no­wisk pra­cy ale w kon­tek­ście cał­ko­wi­tych skut­ków reor­ga­ni­za­cji fir­my po wdro­że­niu. Te skut­ki to np. skró­ce­nie cza­su przy­go­to­wy­wa­nia ofert, obni­że­nie ryzy­ka, nowy inter­ne­to­wy kanał sprze­da­ży. Drugi bar­dzo waż­ny i jesz­cze rzad­ko zauwa­ża­ny czyn­nik to war­tość doda­na do pro­duk­tu fir­my jaką wpro­wa­dza wdro­żo­ny system.

Zwróćmy uwa­gę, że wdro­że­nie przez fir­mę kurier­ska dla klien­tów sys­te­mu śle­dze­nia prze­sy­łek on-line nie ma nic wspól­ne­go z auto­ma­ty­za­cją ani oszczęd­no­ścia­mi. Jednak ten koszt istot­nie pod­no­si war­tość doda­ną (postrze­ga­ną war­tość użyt­ko­wą) usłu­gi dla klien­tów. W efek­cie koszt nie prze­li­czal­ny wprost na ROI czy NPV zaowo­co­wał wzro­stem mar­ży, popra­wił satys­fak­cję klien­tów z usłu­gi, zmniej­szył licz­bę klien­tów odcho­dzą­cych do kon­ku­ren­ci itp.

Na koniec

Po co ten tekst? Po to by zwró­cić Państwa uwa­gę na tak zwa­ne mięk­kie” aspek­ty oce­ny ren­tow­no­ści inwe­sty­cji w nowe tech­no­lo­gie. Nie moż­na już nią patrzeć jak na kolej­ną maszy­nę w hali pro­duk­cyj­nej. Należy patrzeć na IT tak jak na szko­le­nia kadry. System IT czy wzrost kom­pe­ten­cji pra­cow­ni­ków to czyn­ni­ki two­rzą­ce war­tość fir­my jako cało­ści. Dobry sys­tem IT jest tak­że ele­men­tem stra­te­gii zarzą­dza­nia wie­dza w fir­mie ale to już inny temat. Generalnie nowe tech­no­lo­gie to narzę­dzia pra­cy, zaso­by fir­my a nie źró­dła suk­ce­su. Nie zapo­mi­naj­my, że naj­lep­szy pędzel i far­by nie uczy­nią z pacy­ka­rza artysty.

Zarządzanie IT w czasach nowych wyzwań rynkowych

Diagnoza sta­nu obec­ne­go i nie­da­le­kiej historii. 

Kryzys na ryn­ku opro­gra­mo­wa­nia to naj­więk­szy pro­blem z jakie­go się wydo­sta­ją zarów­no twór­cy i dosta­wy opro­gra­mo­wa­nia jak i jego odbiorcy.

Odbiorcy bory­ka­ją się z nie­uda­ny­mi wdro­że­nia­mi, mniej­szą od ocze­ki­wa­nej wydaj­no­ścią kadr korzy­sta­ją­cych z zaku­pio­ne­go opro­gra­mo­wa­nia. Dostawcy cier­pią z powo­du rosną­cej nie­chę­ci do pono­sze­nia przez kupu­ją­cych ogrom­nych kosz­tów wdro­żeń i bra­nia całe­go ryzy­ka na sie­bie. Poniższy dia­gram obra­zu­je wizję pro­ce­su ewo­lu­cji opro­gra­mo­wa­nia wraz z pro­gno­zą na naj­bliż­sze lata.

Ewolucja opro­gra­mo­wa­nia to natu­ral­ny pro­ces roz­wo­ju usług na ryn­ku IT. Długoterminowo to odbior­cy tych tech­no­lo­gii mają decy­du­ją­cy wpływ na kształt i funk­cjo­nal­ność tech­no­lo­gii IT gdyż tak na praw­dę to oni są głów­ny­mi inwe­sto­ra­mi w fir­my inte­gra­tor­skie. Każdy duży pro­jekt infor­ma­tycz­ny to tak napraw­dę pro­jekt inwe­sto­wa­nia w fir­mę wdra­ża­ją­cą przez odbior­cę wdra­ża­ne­go roz­wią­za­nia. Mając to na uwa­dze łatwo zro­zu­mieć dla­cze­go nowe tren­dy wyge­ne­ro­wa­ne przez inno­wa­cyj­ne fir­my nie zawsze znaj­du­ją swój dal­szy ciąg. Bywa, że poja­wia­ją się za wcze­śnie a bywa, że tak na praw­dę potrze­ba wykre­owa­na przez taką inno­wa­cyj­na fir­mę jest fał­szy­wą potrze­bą. To zna­czy, potrze­ba ist­nie­je ale jej zaspo­ko­je­nie przy­no­si efek­ty dale­ko mniej­sze od ofe­ro­wa­nych. Tak było z dotcomm?ami, w dużym stop­niu tak­że z sys­te­ma­mi MRP/ERP czy CRM (kil­ka firm w Polsce zban­kru­to­wa­ło z powo­du bra­ku ocze­ki­wa­ne­go zwro­tu z inwe­sty­cji w sys­tem infor­ma­tycz­ny). Jednym z pod­sta­wo­wych mier­ni­ków oce­ny takich inwe­sty­cji sta­ją się TCO, ROI, bench­mar­king. Jeżeli trud­no jest oce­nić zwrot z inwe­sty­cji (ROI) moż­na porów­nać (bench­mar­king) swój pro­jekt z inny­mi spraw­dzo­ny­mi w innych podob­nych fir­mach. Przed zaku­pem oce­nić kosz­ty posia­da­nia (TCO) sys­te­mu infor­ma­tycz­ne­go obec­nie eks­plo­ato­wa­ne­go i pla­no­wa­ne­go do wdrożenia.

Koszty sys­te­mów infor­ma­tycz­nych są bar­dzo duże, dla­te­go fir­my two­rzą­ce opro­gra­mo­wa­nie poświę­ca­ją nie mało środ­ków na to, by ich pro­duk­ty były tań­sze we wdro­że­niach i w eks­plo­ata­cji. Największe kosz­ty pono­szo­ne były swe­go cza­su na zapew­nie­nie wymia­ny danych pomię­dzy użyt­ko­wa­ny­mi sys­te­ma­mi pocho­dzą­cy­mi od róż­nych pro­du­cen­tów. Systemy pośred­ni­czą­ce w wymia­nie danych pomię­dzy apli­ka­cja­mi nie­jed­no­krot­nie były droż­sze od tych apli­ka­cji. Dlatego ewo­lu­cja opro­gra­mo­wa­nia zmie­rza w stro­ną total­nej kom­pa­ty­bil­no­ści. Obserwujemy rosną­cą popu­lar­ność tech­no­lo­gii XML (uni­wer­sal­ne inter­fej­sy do wymia­ny danych), sys­te­my SAN i NAS czy­li współ­dzie­lo­nych zaso­bów pamię­ci maso­wych. Motory baz danych (RDBMS) już są na tyle uni­wer­sal­ne, ze więk­szość apli­ka­cji może korzy­stać z dowol­ne­go, dostęp­ne­go na ryn­ku pro­duk­tu tego typu. W efek­cie sys­te­my infor­ma­tycz­ne jako zaso­by będą na tyle uni­wer­sal­ne i kom­pa­ty­bil­ne mie­dzy sobą, że poszcze­gól­ne typy zaso­bów będą w danym sys­te­mie wystę­po­wa­ły tyl­ko raz i będą dostęp­ne dla każ­dej potrze­bu­ją­cej ich aplikacji.

Największy boom cze­ka roz­wią­za­nia bazu­ją­ce na inter­fej­sie WWW. Jest to obec­nie naj­bar­dziej uni­wer­sal­ny inter­fejs za pomo­cą któ­re­go może­my mieć dostęp do potrzeb­nych apli­ka­cji. Jak już wyżej napi­sa­łem, użyt­kow­ni­cy pre­fe­ru­ją pła­ce­nia za to co przy­no­si bez­po­śred­nie korzy­ści. Dlatego pro­ces two­rze­nia i roz­wo­ju sys­te­mów sta­je się wła­sno­ścią dostaw­cy opro­gra­mo­wa­nia. Nadwieszą war­tość ma sama apli­ka­cja a tak na praw­dę funk­cjo­nal­ność jaką ofe­ru­ję. Drugim waż­nym czyn­ni­kiem jest bez­pie­czeń­stwo prze­twa­rza­nych danych. Udział pozo­sta­łych kosz­tów jest powo­li mar­gi­na­li­zo­wa­ny u kupu­ją­cych. W efek­cie daje się zaob­ser­wo­wać to o czym wspo­mnia­łem: inwe­stor bie­rze na sie­bie ryzy­ko przy­dat­no­ści i póź­niej­sze­go użyt­ko­wa­nia sys­te­mu infor­ma­tycz­ne­go, ryzy­ko two­rze­nia i roz­wo­ju pozo­sta­je po stro­nie dostaw­cy. Poniższy dia­gram obra­zu­je pro­ces rosną­ce­go zna­cze­nia jako­ści apli­ka­cji (wytwo­rzo­nej war­to­ści) nad pra­cą jaką poświę­ca na to jej dostawca.

Kolejną tech­no­lo­gią prze­zy­wa­ją­cą boom jest są bez­prze­wo­do­we sys­te­my dostę­po­we. Zdalny dostęp a w kon­se­kwen­cji peł­na mobil­ność to pod­sta­wo­we cechy nowo­cze­sne­go sys­te­mu infor­ma­tycz­ne­go. Podstawowe korzy­ści jakie nie­sie ze sobą mobil­ność to łatwość wyko­na­nia potrzeb­nej pra­cy w dowol­nym miej­scu. Rzecz w tym, że pro­ce­sy biz­ne­so­we wspo­ma­ga­ne przez tech­no­lo­gie IT były do tej pory zwią­za­ne z zaso­ba­mi infor­ma­tycz­ny­mi, któ­re je wspie­ra­ły. W efek­cie wydaj­ność pra­cy nie zawsze mogła rosnąć lub kosz­ty nie­któ­rych pro­ce­sów były wie­sze. Podstawowym pro­ble­mem jest dostęp do infor­ma­cji i jej aktu­al­ność. Wielu pra­cow­ni­ków firm znacz­ną część cza­su prze­by­wa poza fir­mą, w miej­scach gdzie tra­dy­cyj­ny dostęp do zaso­bów IT macie­rzy­stej fir­my jest nie­moż­li­wy. Pierwszym ele­men­tem roz­wią­zu­ją­cym ten pro­blem w czę­ści jest sieć Internet, dzię­ki któ­rej może­my mieć dostęp do zaso­bów fir­my z każ­de­go miej­sca w któ­rym jest dostęp do sie­ci Internet. Jednak te wła­śnie miej­sca do tej pory były zwią­za­ne fizycz­nie z punk­tem ich insta­la­cji (biu­ra innych firm, kawia­ren­ki inter­ne­to­we itp.). Technologie bez­prze­wo­do­we uwal­nia­ją nas od tych ogra­ni­czeń. Przemieszczanie się z kom­pu­te­rem w ręku prze­sta­je ozna­czać brak dostę­pu do fir­mo­wej sie­ci. Rozwój tele­fo­nii komór­ko­wej i sprzę­tu prze­no­śne­go powo­li pro­wa­dzi do uwol­nie­nia zależ­no­ści tech­no­lo­gii infor­ma­tycz­nych od miej­sca pobytu.

Podsumowanie

Systemy infor­ma­tycz­ne sta­ją się coraz bar­dziej uni­wer­sal­ne patrząc na nie od stro­ny kom­pa­ty­bil­no­ści baz danych czy miejsc ich skła­do­wa­nia. W efek­cie moż­na już je podzie­lić na nie­za­leż­ne zbio­ry prze­twa­rza­nych danych oraz apli­ka­cje słu­żą­ce do wpro­wa­dza­nia, prze­twa­rza­nia i wypro­wa­dza­nia tych danych.

Firmy infor­ma­tycz­ne, szcze­gól­ne twór­cy opro­gra­mo­wa­nia muszą zacząć szcze­gól­nie dbać o jakoś dostar­cza­nych pro­duk­tów, gdyż ryzy­ko wyni­ka­ją­ce z ich jako­ści i przy­dat­no­ści coraz czę­ściej jest zrzu­ca­ne wła­śnie na nich. Odbiorcy sys­te­mów (spon­so­rzy pro­jek­tów) zaczy­na­ją wymu­szać w umo­wach rów­no­mier­ne roz­kła­da­nie ryzy­ka na obie stro­ny kontraktu.

Jednym z efek­tów tego pro­ce­su jest coraz czę­ściej spo­ty­ka­na meto­da opłat za roz­wią­za­nia infor­ma­tycz­ne na zasa­dzie ?za zuży­cie? a nie jako zakup na wła­sność. Jednym z tych tren­dów jest out­so­ur­cing. Opłacalny jest szcze­gól­nie tam, gdzie zaso­by infor­ma­tycz­ne są wyko­rzy­sty­wa­ne w spo­sób trud­ny do szcze­gó­ło­we­go zapla­no­wa­na albo w spo­sób bar­dzo nie­rów­no­mier­ny w cza­sie (np. wydru­ki fak­tur na koniec okre­su roz­li­cze­nio­we­go). Obserwujemy zarów­no zmia­ny w sys­te­mach opłat licen­cyj­nych za opro­gra­mo­wa­nie (cyklicz­ne opła­ty za okres użyt­ko­wa­nia opro­gra­mo­wa­nia zamiast jed­no­ra­zo­wej przy zaku­pie) jak i w sys­te­mach opłat za usłu­gi kon­sul­tin­go­we (poja­wia się skład­nik par­ty­cy­pa­cji finan­so­wej w efek­tach takiej pracy).

? Jarosław Żeliński (Źródło dia­gra­mów: mate­ria­ły kon­fe­ren­cyj­ne IDC., kon­fe­ren­cja odbę­dzie się w dniach 29 i 30 Września 2003. Koszt Udziału to 1.940 EUR w przy­pad­ku reje­stra­cji do koń­ca Lipca, 2.300 EUR po tym ter­mi­nie, szcze­gó­ły i for­mu­larz reje­stra­cyj­ny na stro­nach Konferencja Managing IT in Challenging Times).

Notatka: IDC orga­ni­zu­je w dniach 29 – 30 Września 2003r. corocz­ne spo­tka­nie dla CEO/CIO. W tym roku poświę­co­ne ono będzie temu jak tech­no­lo­gie IT mogą pomóc oso­bom zarzą­dza­ją­cym w cza­sie nowych ryn­ko­wych wyzwań.

Trzy pod­sta­wo­we tema­ty zosta­ły potrak­to­wa­ne jako priorytety:
– zasto­so­wa­nia tech­no­lo­gii IT
– sys­te­my pra­cu­ją­ce w opar­ciu o WWW
– sys­te­my mobil­ne i bezprzewodowe

Zwrot z inwestycji w IT: prawda czy mity

Inwestycje w tech­no­lo­gie IT[1] muszą pod­le­gać takim samym regu­łom oce­ny, jak wszyst­kie inne: muszą mieć eko­no­micz­ne uza­sad­nie­nie. Stanowią one kosz­ty i jako takie muszą się zwra­cać. W prze­ciw­nym wypad­ku zasad­ność pono­sze­nia tych kosz­tów jest wąt­pli­wa. Jak oce­nić czy dana inwe­sty­cja w tech­no­lo­gię się zwra­ca czy nie, a jeśli tak to po jakim cza­sie? Aby móc to oce­nić koniecz­ne jest stwo­rze­nie mode­lu, któ­ry poka­że jaką nową war­tość wno­si do fir­my ta tech­no­lo­gia i jakim kosztem.

Celem tego arty­ku­łu nie jest opi­sa­nie nowej meto­dy oce­ny ren­tow­no­ści inwe­sty­cji. Celem arty­ku­łu jest wska­za­nie spo­so­bu pozy­ska­nia danych, któ­re pozwo­lą na sko­rzy­sta­nie ze zna­nych w świe­cie finan­sów metod oce­ny inwe­sty­cji. Podstawą do doko­na­nia wyce­ny jest zro­zu­mie­nie roli jaką odgry­wa­ją tech­no­lo­gie infor­ma­tycz­ne w firmach.


[1] ang. Information Technology, tech­no­lo­gie prze­twa­rza­nia infor­ma­cji, nie mylić z infor­ma­ty­ką jako wie­dza inżynierską.

Pobierz kom­plet­ne opracowanie:

Jakie są wykorzystywane wskaźniki do oceny zwrotu z inwestycji w informatyzację

us_dollarW ostat­nich tygo­dniach nasi­li­ły się pyta­nia o to jak oce­nić inwe­sty­cje infor­ma­tycz­ne, szcze­gól­nie zaś jak osza­co­wać okres zwro­tu takiej inwe­sty­cji. Padają nawet pyta­nia jakich uży­wać do tego wskaźników.

Co do wskaź­ni­ka to naj­pro­ściej zacząć od sta­re­go i dobre­go [[ROI (Return of Investment)]]. Sztuka poli­cze­nia zwro­tu z inwe­sty­cji leży jed­nak nie we wskaź­ni­ku a w zde­fi­nio­wa­niu i wyli­cze­niu ocze­ki­wa­nych korzy­ści. A oce­nia się nie tyle inwe­sty­cję w sen­sie pro­duk­tu jakim jest pakiet zin­te­gro­wa­ny czy sys­tem bazodanowy.

Oceniać nale­ży jakość uzy­ska­nej zmia­ny (ulep­sze­nia) pro­ce­su czy tez pro­ce­sów, któ­re są wspo­ma­ga­ne zaku­pio­nym (lub pla­no­wa­nym do zaku­pu) pro­duk­tem. Koszty zaś to suma skła­do­wych typu nowy kom­pu­ter, licen­cje na opro­gra­mo­wa­nie, szko­le­nia, kosz­ty reor­ga­ni­za­cji w fir­mie itp. Nie da się w pro­sty spo­sób poli­czyć kie­dy zwró­ci się sys­tem infor­ma­tycz­ny za 500.000zł. Ale moż­na się przy­ło­żyć i poli­czyć, że np. jakaś czyn­ność lub pro­ces gene­ru­je kosz­ty np. 50.000zł mie­sięcz­nie. Unowocześnienie tego pro­ce­su pozwo­li na zmniej­sze­nie tego kosz­tu do pozio­mu 30.000zł mie­sięcz­nie. Czyli zysku­je­my mie­sięcz­nie 20.000zł. Koszt narzę­dzia: 500.000zł (np. sys­tem MRPII) . W takim ukła­dzie narzę­dzie zwró­ci się po 25 mie­sią­cach bo zmniej­szy­my np. kosz­ty zapa­sów. To w tele­gra­ficz­nym skrócie.

A … nie­uda­ne wdro­że­nia bio­rą się czę­sto wła­śnie z powo­du zaku­pu sys­te­mu infor­ma­tycz­ne­go w nie­wia­do­mym celu. Nie wia­do­mym bo nie poli­czo­no na czym ma pole­gać zysk z zaku­pu nowej tech­no­lo­gii i gdzie upa­tru­je­my korzy­ści z jego wdro­że­nia. Ja oso­bi­ście nie wie­rzę w nie­wy­mier­ność inwe­sty­cji w infor­ma­ty­kę. Raczej jest to pro­blem wewnętrz­ny fir­my z nie­moż­li­wo­ścią oce­ny kosz­tów i tru­dem we wska­za­niu ich źró­deł. To uza­sad­nia czę­sto dora­dza­ne prze­ze mnie roz­wią­za­nie: zanim zain­we­stu­jesz w cokol­wiek kup na począ­tek naj­prost­szy zin­te­gro­wa­ny sys­tem wspie­ra­ją­cy zarzą­dza­nie rachun­ko­wo­ścią z opcja­mi kontrolingu.

Po wdro­że­niu takie­go sys­te­mu moż­na się brać za inne inwe­sty­cje bo są one moż­li­we do wyce­ny i oce­ny. W takim celu wdro­żo­ny mały” sys­tem na pew­ne się zwró­ci. W jakim cza­sie? Trzeba sobie zno­wu szyb­ko poli­czyć lub osza­co­wać jakie oszczęd­no­ści przy­nie­sie szcze­gó­ło­wa kon­tro­la kosz­tów. Następnie zorien­to­wać się w ofer­cie ryn­ko­wej sys­te­mów tego typu. Policzyć odwrot­nie” sto­pę zwro­tu czy­li wyzna­czyć sobie mak­sy­mal­ny okres zwro­tu i obli­czyć ile może­my wydać na taki sys­tem. Po kil­ku ite­ra­cjach da się osią­gnąć kom­pro­mis. Bardzo przy­dat­ny­mi wskaź­ni­ka­mi są [[NPV (Net Present Value)]] oraz [[IRR (Internal Return Rate)]]. Najlepszym chy­ba spo­so­bem jest pro­jek­to­we podej­ście do pla­no­wa­ne­go wdro­że­nia: trze­ba okre­ślić kosz­ty pro­jek­tu i war­tość doda­ną w zło­tów­kach jaką ma wnieść nowy system.

Tu zwró­cę uwa­gę na jesz­cze jed­ną rzecz: coraz czę­ściej moż­na się spo­tkać z opi­nia­mi, że sku­tecz­ność wdro­że­nia pole­ga tak na praw­dę na zdol­no­ści fir­my do dopa­so­wa­nia się do nowej meto­dy zarzą­dza­nia a nie do wywie­ra­nia naci­sku na dostaw­cę apli­ka­cji by dopa­so­wy­wał ją do fir­my. Są to opi­nie gło­szo­ne nie tyl­ko przez fir­my kon­sul­tin­go­we po uda­nych wdro­że­niach ale tak­że przez użyt­kow­ni­ków. Zgadzam się z tą opi­nią w 100%.