Tak więc nie raz dedy­ko­wa­ne roz­wią­za­nie jest lep­sze mimo, że może być kosz­tow­niej­sze ale tu wra­ca jak bume­rang to cze­go pra­wie nikt nie robi przy pro­jek­tach IT: ana­li­za stra­te­gicz­na fir­my i budo­wa sce­na­riu­szy roz­wo­ju a potem dopie­ro wyma­ga­nia na sys­tem IT.

Swego cza­su popeł­ni­łem arty­kuł o dedy­ko­wa­nych sys­te­mach zaty­tu­ło­wa­ny [[Schyłek epo­ki kraw­ców]]. Była to pole­mi­ka z wypo­wie­dzią Prezesa jed­nej z firm IT, któ­ry oświad­czył: „[[Powoli odcho­dzi się od roz­wią­zań szy­tych na mia­rę. Dawniej byli kraw­cy i im zle­ca­ło się robie­nie gar­ni­tu­rów. Teraz po pro­stu kraw­ców już nie ma]]”. I nadal uwa­żam (mimo, że arty­kuł uzy­skał dość niska oce­nę u czy­tel­ni­ków), że epo­ka kraw­ców nie ode­szła! Dzisiaj będzie o stra­te­gii fir­my. Najogólniej rzecz ujmu­jąc ([[A.A. Thompson, A.J. Strickland 1996]]) Strategia jest: 1) pla­nem dzia­ła­nia; 2) odzwier­cie­dla wzo­rzec zarzą­dza­nia w sfe­rze ryn­ku; 3) wska­zu­je jak wypeł­nić misje i osią­gnąć zało­żo­ne cele.

Ja nadal uwa­żam, że lide­rzy ryn­ku to fir­my korzy­sta­ją­ce z usług ​„kraw­ców”!

Na forach inter­ne­to­wych i blo­gach poja­wia­ją się dys­ku­sje na temat ana­liz wyma­gań, jako­ści opro­gra­mo­wa­nia, pro­jek­to­wa­nia sys­te­mów itp. Motorem tych dys­ku­sji są poja­wia­ją­ce się od cza­su do cza­su infor­ma­cje o kolej­nych nie­uda­nych pro­jek­tach zarów­no tych wdro­że­nio­wych jak tych stra­te­gicz­nych (w sen­sie doradz­twa strategicznego).

Ostatnimi cza­sy przy­by­wa zwo­len­ni­ków teo­rii, że sys­te­my dedy­ko­wa­ne dla biz­ne­su odej­dą w nie­byt. Ciekawe jest jed­nak to, że lan­su­ją tę teo­rię tyl­ko dostaw­cy goto­wych, ewen­tu­al­nie tak zwa­nych para­me­try­zo­wa­nych sys­te­mów wdra­ża­nych zresz­tą tak­że nie małym wysił­kiem i współ­two­rzą­cych tak­że tę nie­chlub­ną czar­ną sta­ty­sty­kę nie­uda­nych pro­jek­tów IT.

Ale co to jest ten sys­tem dedy­ko­wa­ny? Pisany od zera? Nie! Dziś nikt roz­sąd­ny nie pisze sys­te­mów dla biz­ne­su od zera czy­li nie star­tu­je od puste­go ekra­nu. Jak rozu­mie­my poję­cie sys­te­mu dedy­ko­wa­ne­go? System dedy­ko­wa­ny moim zda­niem to taki, któ­ry powstał z myślą o kon­kret­nej fir­mie. Czy trze­ba go pisać od zera?

Specyfiką fir­my są dane i ich ​„inność” wyni­ka­ją­ca np. z mode­lu biz­ne­so­we­go czy np. spe­cjal­nie opra­co­wa­nej meto­dy współ­pra­cy z kon­tra­hen­ta­mi. Może to być spe­cy­fi­ka roz­li­czeń z kon­tra­hen­ta­mi, dedy­ko­wa­ny model samo­ob­słu­gi przez sieć i wie­le innych. Specyfiką fir­my jed­nak (raczej) nie jest to, że się fak­tu­ry wysta­wia czy to, że jest maga­zyn. Te modu­ły czy kom­po­nen­ty z regu­ły są już kie­dyś zro­bio­ne, pisa­nie ich jesz­cze raz nie ma sen­su, i dzi­siaj żad­na roz­sąd­na fir­ma z doświad­cze­niem nie two­rzy tych ele­men­tów sys­te­mu od zera. Ma swo­je lub kupio­ne i spraw­dzo­ne biblio­te­ki, kom­po­nen­ty, te któ­re z wie­lu powo­dów są powta­rzal­ne (np. usta­wa o rachun­ko­wo­ści jasno pre­cy­zu­je jak i jaką wysta­wić fak­tu­rę). Powtarzalne są tak­że ele­men­ty zapew­nie­nia bez­pie­czeń­stwa, inter­fejs użyt­kow­ni­ka itp. Niektóre nowe sys­te­my ​„goto­we” to tak na praw­dę taka wła­śnie ​„kupa biblio­tek i kom­po­nen­tów” z ​„moto­rem sys­te­mu”, któ­ry jest czymś pomię­dzy sys­te­mem goto­wym a pisa­niem go ​„od zera”.

Więc jak?

Ano, nie ma moim zda­niem jedy­nie słusz­nej decy­zji. Firma musi sobie sama odpo­wie­dzieć na ile jest spe­cy­ficz­na i na ile ma sens wdra­ża­nie goto­we­go sys­te­mu albo po pro­stu zatrud­nić ana­li­ty­ka i wyko­nać ana­li­zę i projekt.

Stale dzi­wi mnie to, że tak wie­le firm podej­mu­je decy­zje o zaku­pie tak zwa­ne­go goto­we­go sys­te­mu nie mając ana­li­zy wyma­gań i oce­ny pro­gu ren­tow­no­ści. Na jakiej pod­sta­wie ta decy­zja? Rozsądniej było by może:

1. prze­pro­wa­dzić ana­li­zę biz­ne­so­wą, okre­ślić zakres projektu,
2. prze­pro­wa­dzić ana­li­zę wyma­gań i opi­sać nie tyl­ko ocze­ki­wa­nia w sto­sun­ku do sys­te­mu ale tak­że cel jaki fir­ma chce osią­gnąć z pomo­cą nowe­go sys­te­mu by oce­nić próg ren­tow­no­ści projektu,
3. prze­pro­wa­dzić wybór dostaw­cy pyta­jąc ile będzie kosz­to­wa­ło osią­gnie­cie powyż­szych wyma­gań nie decy­du­jąc z góry czy ma to być sys­tem goto­wy czy dedy­ko­wa­ny bo skąd gwa­ran­cja, któ­ry będzie mniej korzystny.

Mój ostat­ni pro­jekt deve­lo­per­ski plus kil­ka ana­li­tycz­nych (mode­le pro­ce­sów i wyma­ga­nia) potwier­dza­ją moje wcze­śniej­sze przy­pusz­cze­nia. Niektóre fir­my mają sku­tecz­ną stra­te­gię ryn­ko­wą pole­ga­ją­cą na sta­łym powięk­sza­niu luki do lide­ra (ich dystans do kon­ku­ren­cji). Ogólnie rzecz bio­rą pole­ga to na tym, by utrud­nić kon­ku­ren­cji szyb­kie sko­pio­wa­nie nasze­go pro­duk­tu. Jak? Jeżeli ele­men­tem tego pro­duk­tu jest np. spo­sób świad­cze­nia usłu­gi to:

• sys­tem stan­dar­do­wy czy­li dostęp­ny na ryn­ku może kupić nie­mal­że natych­miast każ­dy konkurent,
• sys­tem dedy­ko­wa­ny jest trud­ny lub nawet nie­moż­li­wy do szyb­kie­go sko­pio­wa­nia (cho­dzi o uzy­ska­ną dedy­ko­wa­ną funk­cjo­nal­ność), szcze­gól­nie jeśli ktoś z zewnątrz wyko­na ana­li­zę, pro­jekt i prze­ka­że pra­wa mająt­ko­we do tak powsta­łe­go dzie­ła (tak ja wła­śnie robię).

Inaczej rzecz ujmu­jąc, zbu­do­wa­nie sys­te­mu dedy­ko­wa­ne­go (co by to nie mia­ło tu zna­czyć) daje dużą szan­sę, że kon­ku­ren­cja będzie mia­ła duży pro­blem z szyb­kim jego ​„zmał­po­wa­niem” czy­li uży­ciem stan­dar­do­we­go, dostęp­ne­go na ryn­ku sys­te­mu i co jesz­cze gor­sze, refe­ren­cyj­nych roz­wią­zań. Zakup takie­go ​„gotow­ca” to nic inne­go jak pod­kła­da­nie się, bo kon­ku­rent pocze­ka na efek­ty i kupi to samo na ryn­ku bez więk­sze­go wysił­ku. Powiem wię­cej, dostaw­ca takie­go gotow­ca, jak tyl­ko skoń­czy go wdra­żać sam pobie­gnie do naszych kon­ku­ren­tów ofe­ru­jąc im ​„bran­żo­we, pre­kon­fi­gu­ro­wa­ne roz­wią­za­nia do szyb­kie­go wdro­że­nia”.

Implementacja dedy­ko­wa­ne­go systemu

Moje doświad­cze­nie wska­zu­je mię­dzy inny­mi na to, że naj­więk­szej ​„odkry­tych” pod­czas wdro­że­nia ​„nowych potrzeb” doty­czy danych i ich for­ma­tów oraz dedy­ko­wa­nych pro­ce­dur. Dlatego w śro­do­wi­sku deve­lo­pe­rów coraz czę­ściej sły­szy sie o ana­li­zach i wdro­że­niach (two­rze­niu) nowych sys­te­mów zorien­to­wa­nych na model dzie­dzi­ny, któ­ra to wła­śnie naj­czę­ściej kry­je tę ​„spe­cy­fi­ką” fir­my a wyko­na­nie takiej cało­ścio­wej ana­li­zy zabez­pie­cza przed takim ​„odkry­cia­mi” nie­mal zupełnie.

Spotkać moż­na w lite­ra­tu­rze i nie tyl­ko opis czte­ro­war­stwo­we­go mode­lu apli­ka­cji gdzie dru­ga od dołu war­stwa to wła­śnie war­stwa mode­lu dzie­dzi­ny. To tu zawar­ta jest spe­cy­fi­ka mode­lu biz­ne­so­we­go, prze­twa­rza­ne infor­ma­cje i regu­ły biz­ne­so­we. Jest to tak­że naj­waż­niej­sza war­stwa apli­ka­cji i pro­jek­tu zara­zem. Tak więc powie­le­nie jej w kolej­nej fir­mie, u kolej­ne­go klien­ta, wraz z goto­wym sys­te­mem, czym jest?

Jestem zwo­len­ni­kiem tezy, że to [[model biz­ne­so­wy jest źró­dłem prze­wa­gi na ryn­ku]] a nie uży­te narzę­dzia czy same pro­duk­ty. Jednak sys­tem infor­ma­cyj­ny fir­my wspie­ra ten model (no tak powin­no być). Wśród wie­lu wzor­ców pro­jek­to­wych, opi­sa­nych mię­dzy inny­mi przez Fowlera, jest jeden bar­dzo sku­tecz­ny i zale­ca­ny: wzo­rzec mode­lu dzie­dzi­ny. Szczegóły w jego książ­ce, ogól­nie rzecz pole­ga na tym, że pro­jekt sys­te­mu zaczy­na­my od wyko­na­nia ana­li­zy sys­te­mo­wej i mode­lu biz­ne­so­we­go fir­my, nad któ­rym dopie­ro nad­bu­do­wu­je­my apli­ka­cję. Ale temat wzor­ców pro­jek­to­wych i dedy­ko­wa­nych sys­te­mów to już inny arty­kuł ;), poja­wi się niedługo.…