Tag: analiza

Wymagania na oprogramowanie ERP a analiza przedwdrożeniowa – gdzie różnica?

7 komentarzy

Pół roku temu napisałem:

Tak więc: naj­pierw ana­li­za tego co i jak robi­my. Potem podział tego na obsza­ry stan­dar­do­we, któ­re obsłu­ży­my narzę­dziem uni­wer­sal­nym, i pozo­sta­łe (któ­rych z regu­ły jest bar­dzo mało ale są bar­dzo waż­ne dla nas) i zrób­my je po swo­je­mu ale nie pakuj­my się w niszo­we lub prze­sta­rza­łe tech­no­lo­gie. Nie dawaj­my tak­że wia­ry w to, że kup­no tego co ma (powie­le­nie tego co robi) nasz kon­ku­rent uczy­ni nas bar­dziej kon­ku­ren­cyj­ny­mi bo prak­ty­ka poka­zu­je coś zupeł­nie odwrot­ne­go. (czy­taj Wymagania na opro­gra­mo­wa­nie ERP wspo­ma­ga­ją­ce zarzą­dza­nie: dwie kup­ki).

Pojawia się jed­nak wie­le kon­tro­wer­sji w samej defi­ni­cji: czym jest pro­jekt o nazwie Analiza wyma­gań na opro­gra­mo­wa­nie a czym pro­jekt Analiza przed­wdro­że­nio­wa oprogramowania?

Kupujemy buciki

Krótki przy­kład z dzie­dzi­ny, któ­rą wie­lu z nas (może nawet więk­szość) zna. Aby kupić buty małe­mu dziec­ku z wie­lu powo­dów nie cią­gnie­my malu­cha po cen­trach han­dlo­wych. Jak jed­nak kupić te buty i nie żało­wać? Rozwiązaniem jest przy­go­to­wa­nie patycz­ka o dłu­go­ści rów­nej dłu­go­ści sto­py dziec­ka od pię­ty do koń­ca duże­go pal­ca (pisze dla pew­no­ści ;)). Z tym patycz­kiem uda­je­my się do skle­pu i szu­ka­my buci­ków. Aby doko­nać tego wybo­ru dys­po­nu­je­my dwo­ma pod­sta­wo­wy­mi narzę­dzia­mi: paty­czek oraz ogra­ni­cze­nie (tu nasze doświad­cze­nie), któ­re mówi nam, że bucik będzie dobry jeśli patyk się zmie­ści, może być mały luz (np. maks. 5 mm) ale abso­lut­nie nie dopusz­cza­my fak­tu, że mógł­by się nie zmie­ścić. Drugim ogra­ni­cze­niem jest budżet: pla­nu­je­my wydać na buci­ki np. 90zł. Doskonale wie­my dla­cze­go tak, a nie ina­czej postę­pu­je­my: bucik zbyt duży będzie po pro­tu nad­mia­ro­wym zaku­pem, któ­re­go i tak nie wyko­rzy­sta­my zaś bucik zbyt mały po pro­tu nie ma sen­su z powo­dów oczy­wi­stych. Cel ogra­ni­cze­nia war­to­ści tego wydat­ku chy­ba nie wyma­ga komen­ta­rza (po pro­stu na tyle nas stać). Tak więc mamy sku­tecz­nie okre­ślo­ne wyma­ga­nia: paty­czek jako model (uprosz­cze­nie) sto­py dziec­ka i ogra­ni­cze­nia na jego uży­cie: zakaz zaku­pu zbyt małe­go i umiar w zaku­pie zbyt dużego.

Wyobraźmy sobie, że tak wypo­sa­że­ni tra­fi­my na sprze­daw­cę, któ­ry powie, że ma super buci­ki, kupu­ją je dzie­ci zna­nych akto­rów i poli­ty­ków, ale musi­my tro­szecz­kę skró­cić paty­czek i pogo­dzić się z wiel­ka cho­lew­ką w zamian ;), kre­dyt (są znacz­nie droż­sze nią pla­no­wa­li­smy) on tak­że załatwi.

Ciekawostka: jeże­li wyśle­my pocz­tą nasz paty­czek i nasze ogra­ni­cze­nia do skle­pu to ryzy­ko, że tak zamó­wio­ne buci­ki będą złe jest bli­skie zeru! Dlaczego? Unikamy nie­uczci­wej per­swa­zji sprzedawcy …

A teraz wymagania na system ERP.

Już widzę uśmie­chy na twa­rzach czy­tel­ni­ków :). Tak, dobra meto­da to mieć model i dodat­ko­we ogra­ni­cze­nia oraz nie dać sobie wci­snąć cze­goś cze­go nie potrze­bu­je­my. Niestety bez tych dwóch pierw­szych (model i ogra­ni­cze­nia) nie mamy żad­nej bro­ni ani przed sobą samym (np. emo­cje) ani przed dostaw­cą – jeste­śmy bar­dzo podat­ni na zakup cze­goś zupeł­nie nie­po­trzeb­ne­go. Niektórzy opi­su­ją paty­czek kolo­rem, pozio­mem wygła­dze­nia, orna­men­ty­ką, skom­pli­ko­wa­ną pro­ce­du­rą jego uży­cia i wie­lo­ma inny­mi cecha­mi jed­nak tak na praw­dę maja one zni­ko­my wpływ na sku­tecz­ność doko­na­ne­go wybo­ru: liczą się w 99% dłu­gość patycz­ka i ogra­ni­cze­nie: paty­czek musi wejść.

Czy tak można z oprogramowaniem?

Oczywiście! Wystarczy mieć model naszej orga­ni­za­cji oraz ogra­ni­cze­nia nało­żo­ne na uży­cie tego mode­lu. Czy mając paty­czek jest moż­li­wa jakaś per­swa­zja ze stro­ny sprze­daw­cy butów? Nie! A bez patycz­ka? Kto dał sobie sprze­dać nie­co za małe buty w swo­im życiu i czy je potem nosił (cza­sem tak, bo pie­nią­dza na buty wyda­no i dru­gich nie na razie kupi­my)? Czego nie lubią nie­uczci­wi sprze­daw­cy butów? Nie zno­szą klien­tów z patycz­kiem! Są nawet tacy, któ­rzy wma­wia­ją, że paty­czek nale­ży wyrzu­cić bo buci­ki są super i się roz­cho­dzą, w skraj­nym przy­pad­ku wytnie­my otwór na pal­ce (kasto­mi­za­cja goto­we­go bucika).

Jak wykonać patyczek?

Tu poja­wia się moja nie­ukry­wa­na nie­chęć do metod pole­ga­ją­cych na pro­stym spi­sy­wa­niu wyma­gań na opro­gra­mo­wa­nie meto­dą spi­sy­wa­nia expli­ci­te kon­kret­nych funkcjonalności.

Co będzie sku­tecz­niej­szym zamó­wie­niem: boga­ty opis tego do cze­go moż­na użyć kor­by bez jej pro­jek­tu (rysun­ku) czy raczej jej rysunek?

W przy­pad­ku ana­li­zy wyma­gań na opro­gra­mo­wa­nie, nawet jeśli będą to warsz­ta­ty, spo­tka­nia nawet wszyst­kich pra­cow­ni­ków i wiel­kiej burzy mózgów, nic z tego nie będzie (w sen­sie sku­tecz­no­ści) mimo, że powsta­ją kosz­tow­ne mega-doku­men­ty. Skoro każ­dy z nas jest w sta­nie pomi­nąć coś istot­ne­go przy­go­to­wu­jąc listę kil­ku­na­stu spra­wun­ków idąc do skle­pu to jak zagwa­ran­to­wać by bra­ków takich nie było w podob­nie wyko­na­nej spe­cy­fi­ka­cji wyma­gań liczą­cej nawet set­ki pozycji?

Należy przy­go­to­wać nie opis buci­ka a paty­czek (nie opis pla­no­wa­nych zasto­so­wań kor­by a jej rysu­nek)! Ma same zale­ty: ryzy­ko złe­go wybo­ru jest bli­skie zeru, jest poręcz­ny, moż­na go nawet wysłać do skle­pu pocz­tą i spo­dzie­wać się mimo to dobrych bucików.

Jak nie trud­no się domy­śleć mowa o mode­lo­wa­niu biz­ne­so­wym. Patyczek jest mode­lem sto­py a rysu­nek kor­by jej mode­lem. Jak wyko­nać mini­mal­ny sku­tecz­ny model orga­ni­za­cji? Jest to trud­ne jed­nak nie nie­moż­li­we. Paradoksalnie zaś, prak­ty­ka poka­zu­je, opra­co­wa­nie mode­lu jest tań­sze niż pro­wa­dze­nie wywia­dów i opra­co­wy­wa­nie boga­tej spe­cy­fi­ka­cji, że nie wspo­mnę o ryzy­ku uży­cia każ­dej z tych metod. Chyba naj­gor­szym wyj­ście jest zafun­do­wa­nie sobie doku­men­tu wyma­gań w posta­ci listy na kil­ka tysię­cy (tak są takie!) pozy­cji. Tego NIKT NIE CZYTA!

Co zawiera taki model?

Organizację defi­niu­ją skutecznie:

  1. to co i kto i po co robi (w tym [[model biz­ne­so­wy]] całej organizacji)
  2. to jakie kom­pe­ten­cje (umie­jęt­no­ści) musi mieć ten ktoś
  3. to co jest w orga­ni­za­cji prze­twa­rza­ne (zmie­nia­ne)
  4. to cze­go nie wol­no (ogra­ni­cze­nia)
  5. to jaki­mi się powyż­sze rzą­dzi prawami

Jak to poka­zać a nie opi­sy­wać? Nie da się (nie sądzę) stwo­rzyć jed­ne­go mega-mode­lu. Powinny powstać osobno:

  1. [[model pro­ce­sów biz­ne­so­wych]] by poka­zać: kto, co i po co robi a tak­że w odpo­wie­dzi na co (co ini­cju­je każ­de działanie)
  2. [[struk­tu­ra orga­ni­za­cyj­na]], któ­ra poka­że kto i co może robić i od kogo zależy
  3. [[regu­ły biz­ne­so­we]], inny­mi sło­wy [[ogra­ni­cze­nia sys­te­mu]] czy­li [[model poję­cio­wy]] oraz [[sys­tem war­to­ści progowych]].

Dobrze wyko­na­ny model nie zawie­ra infor­ma­cji nad­mia­ro­wych, któ­re zawsze pod­no­szą koszt wyko­na­nia mode­lu a nie raz sta­no­wią zbęd­ne ogra­ni­cze­nia. Dobry model powsta­je z uży­ciem stan­dar­do­wych nota­cji: [[BPMN]] w obsza­rze mode­lo­wa­nia pro­ce­sów oraz [[UML]] w pozo­sta­łych obsza­rach. Używanie for­mal­nych nota­cji pozwa­na zagwa­ran­to­wać wery­fi­ko­wal­ność popraw­no­ści modeli.

Użycie takie­go mode­lu jako narzę­dzia wybo­ru sys­te­mu ERP jest bar­dzo sku­tecz­ne: wystar­czy go roze­słać do dostaw­ców i zapy­tać: po pierw­sze czy ich sys­tem pasu­je do nie­go, ile kosz­tu­je ten pro­dukt rok po roku.

Z takim mode­lem kupu­ją­cy nie musi udo­wad­niać, że jego ocze­ki­wa­nia mają sens (co nie raz zda­ją się pod­wa­żać dostaw­cy) a to dostaw­ca musi zde­kla­ro­wać i wyka­zać, że jego pro­dukt pasu­je do tego mode­lu (czy­li do naszej fir­my). Lepiej: model jest dosko­na­łym narzę­dziem testo­wa­nia dostar­czo­ne­go produktu.

Użycie nota­cji nie­stan­dar­do­wych, bez zde­fi­nio­wa­nych reguł, pro­wa­dzi do powsta­nia nie­we­ry­fi­ko­wal­nych mode­li a to cał­ko­wi­cie dys­kwa­li­fi­ku­je ich sku­tecz­no­ści meto­dy i jej przy­dat­ność. Tak wyko­na­ne mode­le są nie­we­ry­fi­ko­wal­ne i niejednoznaczne.

Tak więc ana­li­za wyma­gań to jest pra­ca wyko­na­na by opi­sać cze­go ocze­ku­je­my i doko­nać wybo­ru. Analiza przed­wdro­że­nio­wa to pra­ca wyko­ny­wa­na przez dostaw­cę, któ­re­go wybra­no, w celu opra­co­wa­nia spe­cy­fi­ka­cji prac jakie nale­ży wyko­nać by wdro­żyć dany pro­dukt. Zapoznaj się z opi­sem Metodyki.

A co gdy żaden mega pro­dukt nie pasu­je co jest bar­dzo praw­do­po­dob­ne? O tym w kolej­nej części.

P.S.

Na bazie tego tek­stu opu­bli­ko­wa­łem tak­że arty­kuł w COMPUTERWORLD:

https://​www​.com​pu​ter​world​.pl/​n​e​w​s​/​O​d​-​c​z​e​g​o​-​z​a​c​z​a​c​-​w​d​r​o​z​e​n​i​e​,​3​7​2​0​4​7​.​h​tml

Luka komunikacyjna

Komunikacja czyli analiza i projektowanie oraz jak to zostanie odebrane

2 komentarze

Pisząc dok­to­rat posta­no­wi­łem zacząć tu cykl arty­ku­łów na temat ana­li­zy, mode­lo­wa­nia i pro­jek­to­wa­nia czy­li tego jak od pierw­szej roz­mo­wy dobrnąć do … no wła­snie. Słowo „[[wyma­ga­nia]]” poja­wia się tak czę­sto w inży­nie­rii opro­gra­mo­wa­nia i jest na tak wie­le spo­so­bów uży­wa­ne, że dodam coś od sie­bie. Szczególnie dla­te­go, że poza pro­jek­ta­mi czę­sto bio­rę udział w dys­ku­sjach (nie raz na eta­pie skła­da­nia ofer­ty na usłu­gi ana­li­tycz­ne) na te tema­ty, wymie­niam się poglą­da­mi i z prak­ty­ka­mi i z teo­re­ty­ka­mi, że nie wspo­mnę o stu­den­tach. Będzie więc o tym jak prze­ka­zać wyko­naw­cy (pro­gra­mi­stom) ​„to co ma powstać”. Nie wiem ile arty­ku­łów mi to zaj­mie 🙂 ale, w mia­rę cza­su, będzie się coś tu na ten temat poja­wia­ło a w razie pytań jak zawsze odpowiem.

Model

Na począ­tek kil­ka słów o tym ​„na czym pole­ga pro­blem” czy­li co nie­co o komu­ni­ka­cji. Otóż pro­blem pole­ga na tym, by prze­ka­zać jakiś ​„obraz” (wyobra­że­nie) np. wyko­naw­cy oprogramowania.

[sin­gle­pic id=61 w=640h=240 float=]

Co my tu mamy powy­żej. Zacznijmy od tego, że na koń­cach dia­gra­mu są dwa obra­zy: rze­czy­wi­sty i ode­bra­ny. Problem w tym, by jako nadaw­ca ​„zapa­no­wać” nad tym co zosta­nie ode­bra­ne, a w każ­dym razie by wypra­co­wać meto­dę dają­ca jak naj­więk­sze praw­do­po­do­bień­stwo zgod­no­ści obra­zu odtwo­rzo­ne­go z pier­wot­nym (rze­czy­wi­stym). Tu nale­ży dodać, że pod poję­ciem obra­zu rze­czy­wi­sto­ści mam na myśli to co ​„widzi (lub sły­szy)” nadaw­ca komu­ni­ka­tu: raz jest to coś, co widzi­my przed sobą innym razem to, co sobie wyobra­ża­my (np. pro­jekt przy­szłe­go sys­te­mu lub jego części).

Diagram przed­sta­wia dwóch akto­rów tego pro­ce­su: nadaw­cę i odbior­ce komu­ni­ka­tu. Tu pierw­sze zało­że­nie: opi­su­ję dwóch akto­rów gdyż uwa­żam, że wpro­wa­dza­nie więk­szej ich licz­by dra­stycz­nie zmniej­sza jakość prze­ka­zu (zgod­ność obra­zu odtwo­rzo­ne­go z rze­czy­wi­stym). Zjawisko to, podob­nie jak i bar­dzo zabaw­ną grę towa­rzy­ską, popu­lar­nie nazy­wa­my ​„głu­chy telefon”.

Nieco teorii komunikacji społecznej

Mamy tu nadaw­cę i odbior­cę komu­ni­ka­tu oraz kanał komu­ni­ka­cyj­ny jakim tu jest doku­men­ta­cja (dia­gram). Nie nazy­wam tu obra­zu pier­wot­ne­go ​„obra­zem prze­ka­zy­wa­nym” gdyż sama [[per­cep­cja]] jest już pierw­szą inter­pre­ta­cją. Tak więc Nadawca komu­ni­ka­tu nie opi­su­je rze­czy­wi­sto­ści a to co ​„ode­brał” (zro­zu­miał lub zin­ter­pre­to­wał zależ­nie od sytu­acji) i ​„ma w gło­wie”. Tak więc pierw­szym eta­pem tego głu­che­go tele­fo­nu jest sama per­cep­cja oto­cze­nia przez nasze­go pierw­sze­go aktora.

W wyni­ku tej per­cep­cji powsta­je obraz ​„zro­zu­mia­ny”. Powstaje on na bazie inter­pre­ta­cji zoba­czo­ne­go obra­zu (lub wysłu­cha­nej opo­wie­ści). Ten obraz jest zło­że­niem odbie­ra­nej rze­czy­wi­sto­ści i doświad­cze­nia obser­wa­to­ra. W jego ​„gło­wie” powsta­nie tyl­ko obraz tego co potra­fił zin­ter­pre­to­wać. Interpretacja to kolej­ny, dru­gi etap tego pro­ce­su, tu ​„rzą­dzi” [[semio­ty­ka]]. Obraz zro­zu­mia­ny (ode­bra­ny, zin­ter­pre­to­wa­ny) to efekt tego jak ode­bra­ne zosta­ły poszcze­gól­ne ele­men­ty tego co zoba­czo­no (usły­sza­no). Ja patrząc na poru­sza­ją­cy się szyb­ko i hała­su­ją­cy kawał żela­za na kołach zoba­czę (doznam) samo­chód, busz­men praw­do­po­dob­nie zoba­czy smoka.

Pora na papier lub np. ścia­nę jaski­ni:) ([[jaski­nia Platona]]). Chcę prze­ka­zać (opo­wie­dzieć) to co zoba­czy­łem. Muszę więc to jakoś utrwa­lić by ktoś inny, Odbiorca komu­ni­ka­tu, mógł ​„zoba­czyć” to co ja widzia­łem. Narysuję (opi­szę) to co zro­zu­mia­łem w spo­sób jaki potra­fię (moja zdol­ność opi­sy­wa­nia) to opi­sać. Powstaje utrwa­lo­ny zapis, tu Diagram, ale może to być opis (lub rysu­nek naskal­ny). Do zapi­su (opo­wie­ści) uży­łem zesta­wu zna­ków (słów) języ­ka komu­ni­ka­cji. Słownik jakim się posłu­żę to nic inne­go jak wła­śnie [[seman­ty­ka]] tego języ­ka komu­ni­ka­cji. Składanie pojęć słow­ni­ka (budo­wa zdań) tak­że nie­sie infor­ma­cję. Istotne jest nie tyl­ko to, jakie­go sło­wa (zna­ku) uży­to ale też jakie inne go ota­cza­ją (jak są ze sobą połą­czo­ne). To (dopusz­czal­ność i zna­cze­nia połą­czeń) opi­su­je [[syn­tak­ty­ka]] języ­ka (czy­li jego gramatyka).

Pora na odbior­cę. Ten, na bazie posia­da­nej zna­jo­mo­ści języ­ka uży­te­go do nada­nia komu­ni­ka­tu (obra­zu), coś ​„zro­zu­mie” czy­ta­jąc (oglą­da­jąc) zapis i odtwo­rzy ​„sobie” w gło­wie obraz ziter­pre­to­wa­ny, będzie on tym co zro­zu­miał odbior­ca. Jak nie­trud­no się tu domy­ślić, to co zro­zu­miał odbior­ca w 100% zale­ży od jego zna­jo­mo­ści języ­ka komu­ni­ka­cji. Wymagana więc tu wie­dza to: [[seman­ty­ka]], [[syn­tak­ty­ka]] i dodat­ko­wo [[prag­ma­ty­ka]] języ­ka uży­te­go do prze­ka­zu. Wiemy już czym jest seman­ty­ka (słow­nik pojęć) i syn­tak­ty­ka (gra­ma­ty­ka), zaś prag­ma­ty­ka to zna­cze­nia pojęć (a poję­cia słow­ni­ka mogą być wie­lo­znacz­ne) wyni­ka­ją­ce z kon­tek­stu (np. ten sam trój­kąt w zeszy­cie do lek­cji geo­me­trii zna­czy coś inne­go niż na drzwiach kory­ta­rza hote­lu). Interpretację zaś zna­ków opi­su­je [[semio­ty­ka]].

Ostatni etap komu­ni­ka­cji to to, co na bazie pozy­ska­nej z zapi­su ​„wie­dzy” odtwo­rzy (utrwa­li) Odbiorca komu­ni­ka­tu. Tu uwi­dacz­nia się głu­chy tele­fon. Czujny czy­tel­nik zapew­ne zauwa­żył, że ten etap w zasa­dzie nie róż­ni się, powie­dział bym nawet, że jest powtó­rze­niem pierw­sze­go eta­pu. Jednak gdy uzna­my, że Odbiorca na bazie prze­ka­zu musi coś stwo­rzyć (w myślach, prze­żyć to), jakąś repre­zen­ta­cję tego o czym się dowie­dział … ale o tym za chwilę.

Jak to się ma do inżynierii oprogramowania

Nazwijmy teraz Nadawcę komu­ni­ka­tu Analitykiem a Odbiorcą Wykonawcą. Pierwszy para­doks pole­ga na tym, że ana­li­tyk nie musi znać się na tym co widzi ale musi umieć to opi­sać. Wiem, wiem, że wie­lu ludzi się z tym nie zga­dza (wyma­ga­nie: ​„ana­li­tyk ma mieć wie­dzę bran­żo­wą”). W czym pro­blem? W seman­ty­ce. Semantyka to słow­nic­two (zestaw pojęć i ich defi­ni­cje). Tak więc by opi­sać cokol­wiek w spo­sób zro­zu­mia­ły wystar­czy, że potra­fię popraw­nie zin­ter­pre­to­wać i potem nazwać wszyst­ko to co sły­szę, widzę (wyobra­żam sobie) i chce prze­ka­zać dalej (zapi­sać).

Klasycznym przy­kła­dem tego para­dok­su jest malarz. Jeżeli potra­fi wier­nie nama­lo­wać to co widzi (wyobra­ża sobie) oglą­da­ją­cy bez pro­ble­mu ​„odbie­rze” ten komu­ni­kat. Mamy z tym zja­wi­skiem kon­takt z jed­nej stro­ny przy por­tre­cie z natu­ry albo, w nie­co trud­niej­szym wyda­niu, przy two­rze­niu por­tre­tów pamię­cio­wych poszu­ki­wa­nych osób. Przykładem bliż­szym naszej dzie­dzi­ny jest archi­tekt czy pro­jek­tant wnętrz. Żaden z nich raczej nie potra­fi dobrze zbu­do­wać domu czy wyre­mon­to­wać łazien­ki, jed­nak potra­fi patrząc lub wyobra­ża­jąc go sobie, opi­sać go tak by wyko­naw­ca zre­ali­zo­wał pro­jekt i stwo­rzył to co wyobra­ził sobie (zoba­czył gdzie indziej) pro­jek­tant. Co jest tu potrzeb­ne? Tylko jed­na rzecz: wspól­ny język komu­ni­ka­cji i zro­zu­mie­nie kontekstu.

To jed­nak nie wszyst­ko. W przy­pad­ku inży­nie­rii opro­gra­mo­wa­nia Obrazem rze­czy­wi­stym jest sytu­acja zasta­na lub ocze­ki­wa­na (to co chce­my uzy­skać) u zama­wia­ją­ce­go opro­gra­mo­wa­nie. Obrazem odtwo­rzo­nym jest opro­gra­mo­wa­nie jakie powsta­ło (ma powstać) będą­cy tym co zamó­wił (swo­im języ­kiem) Zamawiający.

I tu powo­li wyła­nia się (moja) wizja pro­ce­su ana­li­zy wyma­gań oraz ich reali­za­cji. Analityk:

  1. musi jak naj­le­piej (naj­wier­niej) zro­zu­mieć to co widzi,
  2. musi umieć to utrwa­lić by prze­ka­zać Wykonawcy.

Wykonawca:

  1. musi popraw­nie to odczytać,
  2. musi to umieć zin­te­pre­to­wać i wykonać.

Co mamy. Praktyka poka­zu­je, że zama­wia­ją­cy opro­gra­mo­wa­nie ma swo­ja, biz­ne­so­wą, wizje roz­wią­za­nia. Jest nią to co chce uzy­skać. Nie raz jed­nak nie potra­fi zapro­jek­to­wać sto­sow­nych zmian, tu potrzeb­ne jest wspar­cie w posta­ci ana­li­zy biz­ne­so­wej i reko­men­da­cji. Kolejny krok to, po wybo­rze jed­ne­go z reko­men­do­wa­nych roz­wią­zań, wdro­że­nie pomy­słu. Jeżeli tym reko­men­do­wa­nym roz­wią­za­niem jest ​„jakieś opro­gra­mo­wa­nie” poja­wia się potrze­ba opi­sa­nia ​„co ma powstać”. Tu pora na polemikę :).

Skoro głu­chy tele­fon jest ryzy­kow­ny to nale­ży mini­ma­li­zo­wać jego wpływ, eli­mi­nu­jąc ogni­wa pośred­nie w komu­ni­ka­cji. Najczęściej spo­ty­ka­ne podej­ście to:

  1. ana­li­za i spe­cy­fi­ka­cja potrzeb,
  2. pro­jek­to­wa­nie rozwiązania,
  3. wyko­na­nie.

Tradycyjnie pierw­sze robi ana­li­tyk wyma­gań (albo nie­ste­ty sam zama­wia­ją­cy), pozo­sta­łe dwa wyko­naw­ca. Problem w tym, że trud­no jest (zary­zy­ku­ję twier­dze­nie, że jest to NIEMOŻLIWE) prze­ka­zać wyma­ga­nia jako listę potrzeb. Dlaczego? Bo nie ist­nie­je język opi­su potrzeb na tyle seman­tycz­nie jed­no­znacz­ny by inter­pre­ta­cja zapi­su potrzeb była tak­że jed­no­znacz­na! Dalej: zama­wia­ją­cy powie co chce uzy­skać ale nie powie ​„kim jest” (opis tego ​„co” będzie przed­mio­tem, na któ­rym te potrze­by będą realizowane).

Jak można (próbować) rozwiązać problem?

[sin­gle­pic id=62 w=640 h=640 float=center]
Przypomnę opi­sa­ne wcze­śniej trzy eta­py projektu:
  1. ana­li­za i spe­cy­fi­ka­cja potrzeb
  2. pro­jek­to­wa­nia (kon­cep­cji) rozwiązania
  3. wyko­na­nie

Dać wyko­naw­cy pro­jekt (kon­cep­cję) roz­wią­za­nia a nie opis potrzeb. Co z tego wyni­ka? Analiza i pro­jekt roz­wią­za­nia to pra­ca dla jed­nej oso­by (kasu­je­my głu­chy tele­fon). Diagram powy­żej (pierw­szy) poka­zu­je typo­we roz­wią­za­nie: Zamawiający zapi­su­je swo­je potrze­by swo­im języ­kiem. Zapis ten otrzy­mu­je wyko­naw­ca, inter­pre­tu­je go i two­rzy obraz tego co ​„mia­ło powstać” (a raczej było ocze­ki­wa­ne przez Zamawiającego). W sumie nie­wiel­kie ma tu zna­cze­nie to, czy Zamawiający opo­wia­dał a zapi­sy­wał Wykonawca czy Zamawiający zapi­sał i prze­ka­zał zapis Wykonawcy. Problem komu­ni­ka­cyj­ny jest dokład­nie taki sam: pro­jekt i wyko­na­nie leży po stro­nie Wykonawcy a prze­kaz infor­ma­cji wyko­na­no języ­kiem nie­zna­nym jed­nej ze stron.

Czy czy­tel­nik, po lek­tu­rze tek­stu o teo­rii komu­ni­ka­cji widzi już w czym pro­blem? Pewnie więk­szość już go widzi. System poję­cio­wy Zamawiającego i sys­tem poję­cio­wy Wykonawcy to inne sys­te­my! Przekaz nie może być wier­ny! Wykonawca tu, to wła­śnie busz­men słu­cha­ją­cy opi­su samo­cho­du Zamawiajacego.

Rozwiązaniem jest rola Analityka. Analityk to taki osob­nik, któ­ry ani nie potra­fi być (nie jest lub nie chce) dobrym pre­ze­sem fir­my ani dobrym pro­gra­mi­stą ale posłu­gu­je się spraw­nie dwo­ma języ­ka­mi i zna kon­tekst pra­cy obu stron. Dokładnie tak jak archi­tekt czy pro­jek­tant: nie jest pre­ze­sem fir­my inwe­sto­ra ale rozu­mie co i o czym on mówi. Nie jest maj­strem budow­la­nym ale potra­fi opi­sać (zapro­jek­to­wać i nary­so­wać) co nale­ży zbudować.

Na zakończenie

Wiele firm pro­gra­mi­stycz­nych ma eta­to­wych, tak zwa­nych ana­li­ty­ków wyma­gań, jed­nak oni z regu­ły nadal nie są pro­jek­tan­ta­mi. Raczej zapi­su­ją, w z góry usta­lo­ny spo­sób, to co mówi Zamawiający (z regu­ły zresz­tą bez peł­ne­go zro­zu­mie­nia co powie­dzia­no). Bywa, że pro­jek­tan­ta lub pro­gra­mi­stę wysy­ła się w roli ana­li­ty­ka. To też nie dzia­ła z tych samych powo­dów komu­ni­ka­cyj­nych, co potwier­dza praktyka.

Czy wyko­naw­ca może mieć dobre­go ana­li­ty­ka pro­jek­tan­ta? Może mieć, nie­je­den nawet ma ale… z jakie­goś powo­du uzna­no, w znacz­nie star­szej niż inży­nie­ria opro­gra­mo­wa­nia, bran­ży budow­la­nej, że Wykonawca nie powi­nien być auto­rem tego co nale­ży wyko­nać dla Zamawiającego. Zamawiający tak­że nie powi­nien być pro­jek­tan­tem. Dlaczego? Każda fir­ma (jej Prezes) dąży do mak­sy­ma­li­za­cji swo­je­go zysku (tu ren­tow­no­ści nasze­go pro­jek­tu), inte­re­sy Zamawiającego i Wykonawcy są więc sprzecz­ne dla­te­go wyma­ga­na jest trze­cia rola: nie­za­leż­ny pro­jek­tant. I tak wła­snie to wyglą­da w pro­jek­tach budow­la­nych, w któ­rych archi­tekt to osob­ny pod­miot. Zachowuje on tak­że pra­wo nad­zo­ru autor­skie­go nad reali­za­cją swo­je­go pro­jek­tu by tak­że na eta­pie reali­za­cji pano­wać nad nim. W trak­cie reali­za­cji nadal inte­re­sy Zamawiającego i Wykonawcy sprzecz­ne – Zamawiający mak­sy­ma­li­zu­je funk­cjo­nal­ność czy­li for­su­je wzrost kosz­tów to zaś nisz­czy zysk Wykonawcy, któ­ry sta­ra się tę funk­cjo­nal­ność minimalizować.

Często moż­na usły­szeć, że Zamawiający nie wie­dzą cze­go chcą. Otóż z regu­ły wie­dzą dosko­na­le ale nie są rozu­mia­ni przez przy­szłe­go wyko­naw­cę bo ten ope­ru­je innym języ­kiem (Z: chciał bym mieć moż­li­wość bez­piecz­ne­go korzy­sta­nia z danych w sys­te­mie part­ne­ra, W: czy potrzeb­na jest Państwa baza pośred­nia [[SQL]]?).

Wielu Wykonawców wpi­sa­ło już sobie w meto­dę pra­cy ten brak komu­ni­ka­cji i nazy­wa swo­ją meto­dy­kę „[[prototyp]]owaniem”. Innymi sło­wy, sko­ro raczej nie zro­zu­mia­łem tego, cze­go ocze­ku­je Zamawiający, będę mu pod­su­wał kolej­ne pro­to­ty­py tego co zro­zu­mia­łem, Zamawiający będzie mówił co nale­ży zmie­nić by osią­gnąć cel i może jakoś się uda.

A czy moż­na od razu zapro­jek­to­wać to co ma powstać? Można.

O czym będzie dalej? O ana­li­zie, pro­jek­to­wa­niu i mode­lo­wa­niu. Analiza to słu­cha­nie i zapi­sy­wa­nie tego co usły­sza­no i zro­zu­mia­no. Projektowanie to two­rze­nie opi­su tego co ma powstać. Modelowanie czy­li jak spraw­dzić czy nasz opis odda­je rze­czy­wi­stość i jak spraw­dzić czy pro­jekt jest tym czym ma być. O nota­cjach czy­li o tym jak na eta­pie ana­li­zy i pro­jek­to­wa­nia nale­ży zapi­sy­wać to, co nale­ży przekazać.

c.d.n.

Moda na BPM to odgrzana prehistoria

Dodaj komentarz

Procesy zna­my od dwu­stu lat, biz­nes rozu­mie­my od dwu­dzie­stu i nadal paprze­my wdro­że­nia. Dlatego chy­ba nale­ży dopro­wa­dzić już do tego by o wdro­że­niach sys­te­mów IT nie decy­do­wa­li juz wię­cej dostaw­cy tych technologii.

?Dawniej zakład sprze­da­wał dziś reali­zu­je pro­ces sprze­da­ży. Przedtem pro­du­ko­wał ? dziś wyko­nu­je pro­ces pro­duk­cyj­ny. Zarząd podej­mo­wał decy­zje ? teraz opty­ma­li­zu­je pro­ces decy­zyj­ny. I tak dalej… Czy w takim razie w sądzie toczy sie pro­ces pro­ce­so­wy?? Tak napi­sa­ła Redaktor Naczelna pew­ne­go perio­dy­ku zaj­mu­ją­ce­go się sys­te­ma­mi dla przed­się­biorstw we wstę­pie do jed­ne­go z numerów.

Moda na pro­ce­sy, zarzą­dza­nie zorien­to­wa­ne pro­ce­so­wo, out­so­ur­cing pro­ce­sów biz­ne­so­wych itp. to nie moda. Moim zda­niem to kolej­ny etap zro­zu­mie­nia tego co się woko­ło nas dzie­je bo w sadzie nie ma pro­ce­su pro­ce­so­we­go. W sądzie ma miej­sce pro­ces docho­dze­nia do pozna­nia praw­dy i wyda­nia spra­wie­dli­we­go sądu.

Oczywiście nad­uży­wa­nie sło­wa pro­ces to kolej­ny buz­zword czy­li sło­wo wytrych. Mam jed­nak wra­że­nie, że naj­czę­ściej szer­mu­ją nim sprze­daw­cy BPM i dobrze jest jak je rozumieją.

Pojęcie pro­ce­su nie jest nowe. Pojawia się w zarzą­dza­niu nie­mal­że od począt­ku ist­nie­nia tej nauki, co naj­mniej od cza­sów Taylora. Procesy pro­duk­cyj­ne i ich uspraw­nia­nie to przed­miot badań już od XIX wie­ku. Co więc jest nowego?

Jak na mój rozum po pro­stu nic. Może tyl­ko to, że nauka powo­li opusz­cza budyn­ki uczel­ni (cze­mu dopie­ro teraz??). Skąd taka moda na pro­ce­sy, tak­że w infor­ma­ty­ce? Moim zda­niem więk­szość ludzi uwa­ża, że jak nie ma kło­po­tów to nie ma co się zasta­na­wiać nad tym co sie robi. Są kło­po­ty szu­ka się magicz­ne­go środ­ka na to by im zaradzić.

Czasy gdy pro­duk­cja nada­wa­ła ton eko­no­mii a infor­ma­ty­ka była biz­ne­sem z trzy­cy­fro­wą mar­żą już chy­ba bez­pow­rot­nie minę­ły. Teraz o sprze­da­ży decy­du­je odbior­ca a mar­że w IT spa­dły nawet do jed­no­cy­fro­wych. Efekt? Może by tak zapy­tać tych śmiesz­nych uczo­nych co oni na to?

Informacja to wartość rynkowa i źródło jej przewagi

No i teraz ktoś powie, że to tru­izm. Owszem jed­nak cie­ka­we jest to, że jest to tru­izm a jed­no­cze­śnie naj­czę­ściej sło­wo ?rynek? i jego odmia­ny są naj­czę­ściej usu­wa­ne z ofert i ana­liz przy­go­to­wy­wa­nych przed wdrożeniami.

Dlaczego czę­sto widu­ję zapi­sy ?sys­tem ma umoż­li­wić spraw­ne wysta­wia­nie fak­tur VAT? (cie­ka­we co to tak na praw­dę zna­czy?) a raczej nie widu­ję zapi­sów o tre­ści ?sys­tem ma umoż­li­wiać wysta­wia­nie fak­tur w cza­sie co naj­mniej tak krót­kim jak w innych fir­mach naszej bran­ży i umoż­li­wiać wysy­ła­nie ich auto­ma­tycz­nie dro­gą elektroniczną??

Wytłumaczenie moim zda­niem jest bar­dzo pro­ste: sko­ro zama­wia­ją­cy chce wdro­żyć nowy sys­tem IT bo mówi mu to bench­mar­king (nota bene kolej­ny nad­uży­wa­ny buz­zword) a nie oce­na np. ren­tow­no­ści czy pomysł na nowy pro­dukt czy usłu­gę, fir­ma nie ma wła­snej stra­te­gii tyl­ko kopiu­je cudze, ana­li­zę przed­wdro­że­nio­wą z regu­ły pro­wa­dzi fir­ma, któ­ra sys­tem następ­nie wdro­ży to skąd ma się poja­wić jaki­kol­wiek sens w takim wdrożeniu?

Niedawno byłem na kon­fe­ren­cji, gdzie po moim refe­ra­cie na temat potrze­by pro­wa­dze­nia ana­liz i opra­co­wa­nia wyma­gań w ramach odręb­ne­go pro­jek­tu z sali padło pyta­nie: ?Jak mamy ufać nie­za­leż­nym kon­sul­tan­tom, sko­ro ostat­nio jeden z naszych klien­tów dał nam taką ana­li­zę i oka­za­ło, że nasi wdro­że­niow­cy mie­li duże z nią pro­ble­my i w koń­cu musie­li­śmy prze­pro­wa­dzić wła­sna?. Moja odpo­wiedź brzmia­ła: ?Nie znam doku­men­tu ana­li­zy ani szcze­gó­łów Państwa pro­jek­tu jed­nak moż­li­we są dwa sce­na­riu­sze: (1) ana­li­za była z łej jako­ści i fak­tycz­nie nale­ża­ło ją powtó­rzyć, (2) ana­li­za była popraw­nie wyko­na­na jed­nak Państwa sys­tem nie speł­niał wyma­gań opi­sa­nych w ana­li­zie i dopro­wa­dzi­li Państwo do pozby­cia sie nie­wy­god­ne­go dla Was doku­men­tu.? I dzi­wić się, że wie­le firm IT mnie nie lubi.

To powszech­nie obser­wo­wa­ne prze­ze mnie zja­wi­sko: ana­li­zy przed­wdro­że­nio­we pro­wa­dzo­ne prze fir­my IT mają na celu przede wszyst­kim okre­ślić jak za wszel­ką cenę wdro­żyć tam ich sys­te­my. Dlatego bro­nią sie te fir­my ręka­mi i noga­mi przez wszel­ki­mi nie­za­leż­ny­mi ana­li­za­mi. Inna spra­wa, co stwier­dzam z ubo­le­wa­niem, to to, że jakość wie­lu ana­liz tak­że posta­wia wie­le do życze­nia (nie­ste­ty). Są robio­ne przez ludzi bez żad­ne­go przy­go­to­wa­nia i doświad­cze­nia, nie­jed­no­krot­nie nie mają­cy­mi nawet wie­dzy z dzie­dzi­ny zarządzania.

Procesy biznesowe i analiza systemowa

Powszechnym błę­dem ludzi IT (i nie tyl­ko) jest utoż­sa­mia­nie sło­wa sys­tem ze sło­wa­mi ?sys­tem infor­ma­tycz­ny? co jest dużym błę­dem. System to:

System to jaki­kol­wiek obiekt fizycz­ny lub abstrakcyjny/myślowy, w któ­rym może­my wyróż­nić jakieś wza­jem­nie powią­za­ne dla obser­wa­to­ra części/elementy/(inne sys­te­my, sta­no­wią­ce jego pod­sys­te­my). W tym sen­sie podział cze­goś na sys­te­my jest względ­ny i zale­ży od tego kto przy pomo­cy cze­go i do cze­go podzielił/poklasyfikował jakiś zbiór na sys­te­my. Dlatego też ele­men­ty jed­ne­go sys­te­mu mogą sta­no­wić skład­ni­ki innych systemów.

Systemem takim są więc mię­dzy inny­mi pań­stwo, orga­ni­za­cja spo­łecz­na, przed­się­bior­stwo, pro­gram kom­pu­te­ro­wy i wszel­kie kom­bi­na­cje wymie­nio­nych. Czym wiec jest ana­li­za systemowa?

?Analiza sys­te­mo­wa to dzia­ła­nie mają­ce na celu dostar­cze­nie wska­zó­wek do pod­ję­cia decy­zji, poprzez gene­ro­wa­nie i odpo­wied­nie przed­sta­wia­nie infor­ma­cji zwią­za­nej z zagad­nie­niem, któ­re­go decy­zja doty­czy. Podstawowe poję­cia ana­li­zy sys­te­mo­wej: cele, warian­ty, kosz­ty, mia­ry jako­ści, kry­te­ria wybo­ru, modele.?

Jak widać sama defi­ni­cja nie ma nic wspól­ne­go z sys­te­ma­mi IT! To tyl­ko jed­ne z wie­lu sys­te­mów. O co więc chodzi?

Chodzi o to, że np. pod­ję­cie decy­zji o wdro­że­niu nowe­go sys­te­mu infor­ma­tycz­ne­go i jego wybo­rze dobrze jest wes­przeć wła­śnie ana­li­zą sys­te­mo­wą. Polega ona tu na: wyko­na­niu mode­lu orga­ni­za­cji, w któ­rej to wdro­że­nia ma mieć miej­sce, wska­za­niu tych jej miejsc, któ­re chce­my np. uspraw­nić, okre­śle­niu pożą­da­nych cech przy­szłe­go sys­te­mu infor­ma­tycz­ne­go (okre­śle­nie wyma­gań). To wszyst­ko jed­nak wyma­ga jed­ne­go: okre­śle­nia celu biz­ne­so­we­go jakim może być np. pod­nie­sie­nie kon­ku­ren­cyj­no­ści oraz okre­śle­nie pro­gu ren­tow­no­ści takie­go projektu.

Gdzie tu model pro­ce­sów biz­ne­so­wych? Otóż model taki jest czę­sto naj­lep­szym mode­lem tej­że orga­ni­za­cji do celów prze­pro­wa­dze­nia tej ana­li­zy. Robienie mapy pro­ce­sów ot tak tyl­ko dla jej zro­bie­nia to mar­no­tra­wie­nie pieniędzy.

Informacja i łańcuch wartości

Teoria łań­cu­cha war­to­ści ryn­ko­wej Michaela E. Portera to moim zda­niem jed­no z naj­do­nio­ślej­szych odkryć w dzie­jach mar­ke­tin­gu. Pozwala budo­wać mode­le biz­ne­so­we, zro­zu­mieć rynek i two­rzyć sku­tecz­ne stra­te­gie ryn­ko­we w spo­sób zro­zu­mia­ły a nie na zasa­dzie ?robi­my tak, bo więk­szość lide­rów tak robi?.

Nie będę tu opi­sy­wał całej teo­rii, zain­te­re­so­wa­nych odsy­łam do ?Przewaga kon­ku­ren­cyj­na?, M.E. Porter. Kluczowym jej ele­men­tem jest war­tość w łań­cu­chu sprze­da­ją­cy – kupu­ją­cy. Co praw­da czę­sto sły­szy sie o war­to­ści doda­nej ale jest tyl­ko frag­men­ta­rycz­ne postrze­ga­nie tej teo­rii. Szermowanie poję­ciem war­to­ści doda­nej dla klien­ta bez zro­zu­mie­nia całej teo­rii pro­wa­dzi czę­sto do błęd­nych wnio­sków w rodza­ju: musi­my coś wnieść do odprze­da­wa­ne­go towa­ru i będzie ok. Możliwe, jed­nak gdzie tkwi błąd? W tym, że nie cho­dzi o to by wnieść ?jakąś? war­tość do pro­duk­tu, nale­ży go wzbo­ga­cić o coś co ma real­ną war­tość dla kupu­ją­ce­go. Prostym testem jest to czy mamy klien­tów 🙂 za cenę jaką zaoferowaliśmy.

Gdzie tu miej­sce dla IT? Otóż IT ma sens moim zda­niem tyl­ko wte­dy gdy poma­ga tę war­tość two­rzyć, przy­po­mi­nam war­tość ryn­ko­wą. Jak to mówią kom­pu­ter sam z sie­bie do nicze­go nie słu­ży cho­ciaż podob­no nie­któ­rzy sprze­daw­cy potra­fią sprze­dać śnie Eskimosowi. Jeżeli to praw­da to jest to poważ­ne zagro­że­nia nie tyl­ko dla IT 🙂 a już dla opi­nii o IT na pewno…

Dobra mapa pro­ce­sów biz­ne­so­wych jest odzwier­cie­dle­niem wewnątrz fir­mo­we­go łań­cu­cha war­to­ści. Technologie, w tym IT, są zaso­ba­mi wspie­ra­ją­cy­mi te pro­ce­sy. Na stro­nach tego ser­wi­su powta­rzam to do znu­dze­nia ale to tyl­ko efekt tego, że nie potra­fię zna­leźć zamiennika :).

Stąd już bli­sko to sys­te­mu IT, wyma­gań na nie­go i jego ren­tow­no­ści: (1) obrać cel biz­ne­so­wy, (2) opi­sać fir­mę pro­ce­sa­mi, (3) wska­zać pro­ce­sy mają­ce wpływ na reali­za­cję celu biz­ne­so­we­go, (3) oce­nić war­tość jaką wno­szą te pro­ce­sy, (4) okre­ślić mak­sy­mal­ny akcep­to­wal­ny pro­go­wy koszt osią­gnię­cia zde­fi­nio­wa­ne­go celu biz­ne­so­we­go (tu otrzy­mu­je­my próg ren­tow­no­ści pro­jek­tu), (5) spi­sać pro­ce­sy któ­re wes­prze­my tech­no­lo­gią IT i opi­sać jak chce­my to wspar­cie zre­ali­zo­wać (tu otrzy­ma­my wyma­ga­nia funk­cjo­nal­ne). To tele­gra­ficz­ny skrót ana­li­zy sys­te­mo­wej pro­wa­dzą­cej do pod­ję­cia decy­zji o wdro­że­niu, moż­na to w tym przy­pad­ku nazwać tak­że ana­li­zą wykonywalności.

Kilka wskazówek

Teraz przy­to­czę kil­ka cie­ka­wych wska­zó­wek dla firm pla­nu­ją­cych jakie­kol­wiek inno­wa­cje IT:

  1. Oceń nasi­le­nie infor­ma­cji w branży
  2. Określ rolę tech­ni­ki infor­ma­cyj­nej w struk­tu­rze sektora
  3. Rozpoznać i usze­re­go­wać spo­so­by uzy­ska­nia prze­wa­gi kon­ku­ren­cyj­nej dzię­ki tech­ni­ce informacyjnej
  4. Zbadać, w jaki spo­sób tech­ni­ka infor­ma­cyj­na mogła­by sie przy­czy­nić do naro­dzin nowych dzie­dzin działalności
  5. Opracować plan wyko­rzy­sta­nia tech­ni­ki informacyjnej

A co jest tu dziw­ne i zaska­ku­ją­ce? To, że M.E Porter napi­sał powyż­sze wska­zów­ki w 1985 roku! Dlatego chy­ba nale­ży dopro­wa­dzić do tego by o wdro­że­niach sys­te­mów IT nie decy­do­wa­li już wię­cej dostaw­cy tych technologii

Klucz do sukcesu: doradztwo

Dodaj komentarz

Wychodzenie z kry­zy­su, któ­re sta­ło się fak­tem tak­że w naszej gospo­dar­ce, stwa­rza nowe szan­se roz­wo­ju. Także dla firm infor­ma­tycz­nych. Jednak rece­sja wyedu­ko­wa­ła mene­dże­rów. Oni już nie chcą kupo­wać kom­pu­te­rów, Oni ocze­ku­ją biz­ne­so­we­go wspar­cia. Jeszcze nie­daw­no kupo­wa­ne były kom­pu­te­ry i pro­gra­my. Można było nie raz prze­czy­tać o dużych kon­trak­tach wdro­że­nio­wych, nie­ste­ty nie wie­le mniej razy moż­na było prze­czy­tać o poraż­kach tych wdro­żeń. Wiele z nich to były i nie raz nadal są wdro­że­nia o prze­kro­czo­nym budże­cie a nawet wdro­że­nia nie­ukoń­czo­ne. Nikt nie wie ile z tych sys­te­mów w ogó­le się zwróciło.

Powody więk­szo­ści z tych nie­po­wo­dzeń są od nie­daw­na zna­ne. Wiele z tych pora­żek to wynik bra­ku biz­ne­so­we­go powią­za­nia pomię­dzy inwe­sty­cja­mi w nowe tech­no­lo­gie a pro­ce­sa­mi w fir­mie. Wdrażanie sys­te­mu infor­ma­tycz­ne­go tyl­ko po to by uspraw­nić już funk­cjo­nu­ja­ce w fir­mie pro­ce­sy to jeden z naj­częst­szych błę­dów jakie popeł­nia­ją zarów­no dostaw­cy jak i odbior­cy. Sam, sto­sun­ko­wo zresz­tą nie duży, wzrost wydaj­no­ści oraz zasy­pa­nie zarzą­du fir­my nawet naj­lep­szą nową infor­ma­cją (np. z hur­tow­ni danych) nie prze­kła­da się wprost na zwięk­sze­nie kon­ku­ren­cyj­no­ści czy wzrost zysków.

Firma odno­si suk­ces tyl­ko wte­dy gdy powięk­szy zyski. A jak powięk­szyć zyski sko­ro jedy­ną rze­czą jakiej ocze­ku­je się od ​„kom­pu­te­ra” to szyb­sze prze­twa­rze­nie, wię­cej infor­ma­cji, lep­sze rapor­ty, wię­cej rapor­tów.….? Czy to jest jakaś nowa war­tość? Nie, to tyl­ko popra­wa wydaj­no­ści i wię­cej informacji.

Wzrost zysków to nowy pomysł na sprze­daż, zwięk­sze­nie sku­tecz­no­ści sprze­da­ży, zmia­na mode­lu biz­ne­so­we­go, zmia­na ofer­ty na bar­dziej kon­ku­ren­cyj­ną, odkry­cie nowej niszy na ryn­ku itp. Ogólnie spo­so­bem na zwięk­sze­nie zysków jest stwo­rze­nie nowej war­to­ści w łań­cu­chu, w któ­rym funk­cjo­nu­je firma.

Ten pro­blem został dostrze­żo­ny i szyb­ko zare­ago­wa­li na to wiel­cy inte­gra­to­rzy na ryn­ku IT. Najwięsze fir­my IT, dostaw­cy kom­plek­so­wych roz­wią­zań zro­zu­mie­li, że muszą swo­im klien­tom naj­pierw dora­dzić jak uspraw­nić fir­mę a dopie­ro potem moż­na zaofe­ro­wać sys­tem infor­ma­tycz­ny, któ­ry będzie wspie­rał te zmia­ny na lepsze.

Jak? W pro­sty spo­sób: nale­ży zbu­do­wać w fir­mie dział dorad­czy. Budowa od zera jest trud­na dla­te­go, nie­któ­re fir­my, te któ­re było na to stać, po pro­tu szyb­ko kupi­ły fir­my dorad­cze lub ich wyspe­cja­li­zo­wa­ne dzia­ły. Teraz takie fir­my jak IBM, HP, EDS i kil­ka innych są już w sta­nie świad­czyć kom­plek­so­wą usłu­gę pole­ga­ja­cą na zapo­cząt­ko­wa­niu pro­ce­su współ­pra­cy z klien­tem od doradz­twa stra­te­gicz­ne­go. W wyni­ku tej pra­cy powsta­je zmo­dy­fi­ko­wa­ny lub nowy model biz­ne­so­wy fir­my. Dochodzi do pew­nych ele­men­tów restruk­tu­ry­za­cji, rein­ży­nie­rii pro­ce­sów a dopie­ro po tym pro­ce­sie ma miej­sce u klien­ta pro­jek­to­wa­nie i wdra­ża­nie sys­te­mu infor­ma­tycz­ne­go któ­ry to szyst­ko ​„ogar­nie”.

Taka kolej rze­czy ma na pew­no dużo więk­sze szan­se powo­dze­nia. Tym bar­dziej, że coraz czę­ściej odbior­cy żąda­ją od dostaw­ców współ­udzia­łu w ryzy­ku całe­go projektu.