SOA: Czy to już nadchodzący koniec zintegrowanych ERP?

Przewiduję powol­ne odcho­dze­nie od idei sys­te­mów zin­te­gro­wa­nych. Dotychczasowa ich zale­ta czy­li peł­na inte­gra­cja prze­sta­je być zale­tą a sta­je się gar­bem. System zin­te­gro­wa­ny moż­na już ?skle­ić? ze spe­cja­li­zo­wa­nych apli­ka­cji, kom­po­nen­tów. Technologia obiek­to­wa bar­dzo ten pro­ces uła­twi­ła. Drugim powo­dem prze­wi­dy­wa­ne­go odej­ścia od tej idei są ogrom­ne kło­po­ty z oce­ną ren­tow­no­ści wdro­że­nia sys­te­mu ERP. Nie raz jest to po pro­stu wręcz nie­moż­li­we z powo­du bra­ku moż­li­wo­ści oce­ny jakim kosz­tem wspie­ra­my poje­dyn­czy pro­ces biz­ne­so­wy bo trud­no z jed­ne­go ogrom­ne­go sys­te­mu wykro­ić koszt wspar­cia poje­dyn­cze­go pro­ce­su. Z tego też powo­du rośnie zain­te­re­so­wa­nie sys­te­ma­mi typu mid­dle­wa­re. Do tej pory były wyko­rzy­sty­wa­ne rzad­ko i dużych fir­mach, głów­nie w sek­to­rze finan­so­wym, głow­nie z uwa­gi na ich koszt. Obecnie roz­wią­za­nie to sta­je się coraz popu­lar­niej­sze. Dlatego?

Pojawienie się stan­dar­dów w mode­lo­wa­niu, usta­no­wie­nie mode­lo­wa­nia peł­no­war­to­ścio­wym eta­pem pro­jek­tu (a nie eks­tra­wa­gan­cją), otwie­ra­nie się tech­no­lo­gii, poja­wia­cie się stan­dar­dów wymia­ny meta­da­nych i mode­li toru­ją dro­gę do znacz­ne­go obni­że­nia kosz­tów i uspraw­nie­nia two­rze­nia sys­te­mów opar­tych o kom­po­nen­ty. To wszyst­ko powo­du­je, że nie trze­ba jed­ne­go wiel­kie­go sys­te­mu zin­te­gro­wa­ne­go. Wystarczy tak zwa­ny motor pro­ce­sów biz­ne­so­wych i spe­cja­li­zo­wa­ne sys­te­my, mogą one pocho­dzić od róż­nych pro­du­cen­tów i pra­co­wać na róż­nych platformach.

Jedyne cze­go trze­ba prze­strze­gać to pra­ca od samej góry: model biz­ne­so­wy orga­ni­za­cji, model pro­ce­sów biz­ne­so­wych, struk­tu­ra work­flow (sce­na­riu­sze dzia­łań czy­li wewnętrz­ny opis pro­ce­sów), lista ocze­ki­wa­nych usług sys­te­mu IT i sam sys­tem skła­da­ny z kom­po­nen­tów. Tak to widzę. Te trzy ele­men­ty: model biz­ne­so­wy, model pro­ce­sów, usłu­gi IT sta­no­wią pew­ną całość. Ubranie opi­su usług w cia­ło to wła­śnie obiek­to­we tech­no­lo­gie w IT, archi­tek­tu­ra SOA i MDA, języ­ki i nota­cje BPEL, BPMN, UML, XMI, obiek­to­we języ­ki programowania.

Koniec quasimonopolu dostawców systemów

No i oka­za­ło sie, że stan­dar­dy spraw­dzo­ne same się bro­nią. Microsoft W BizTalk Server będzie sup­por­to­wał BPEL (Business Proces Execution Language, opar­ty na XML język skryp­to­wy opi­su pro­ce­sów mię­dzy inny­mi w sys­te­mach BPM i work­flow mana­ge­ment uży­wa­ny już mię­dzy inny­mi w nie­któ­rych sys­te­mach CASE). Oracle tak­że ?rozu­mie? BPEL. Modelowanie sta­je się nor­mą a otwar­tość stan­dar­dem. Notacje UML i BPMN sta­ją się stan­dar­dem modelowania.

Co to zna­czy? Moim zda­niem to, że powo­li sta­je się coś o czym pisa­łem swe­go cza­su na stro­nach IT-Consulting. Monopolistę zaczę­li doga­niać kon­ku­ren­ci. Monopolista zaczy­na czuć poko­rę: już nie wyzna­cza sam stan­dar­dów de’fac­to (np. for­ma­ty pli­ków doku­men­tów, narzę­dzia pro­gra­mi­stycz­ne, inter­fej­sy komu­ni­ka­cyj­ne). Tracąc powo­li rynek na rzecz roz­wią­zań kon­ku­ren­cji dostrzegł, że to co było prze­wa­gą ryn­ko­wą (zamknię­te roz­wią­za­nia) sta­ło się w dal­szej per­spek­ty­wie hamul­cem. Przyszła pora na otwar­tość i kon­ku­ro­wa­nie jako­ścią a nie szan­taż ponad 80% udzia­łem w ryn­ku (vide współ­pra­ca Microsoft i Novell).

Kierunki rozwoju systemów IT

Albo ana­li­za pro­ce­so­wa i obiek­to­wa albo na mar­gi­nes życia. Coraz powszech­niej­sze zro­zu­mie­nie idei zorien­to­wa­nia na pro­ce­sy, inte­ro­pe­ra­cyj­no­ści (w tym zarzą­dza­nie łań­cu­cha­mi dostaw), archi­tek­tu­ry SOA (któ­ra moim zda­niem dosko­na­le się wpa­so­wu­je w meto­dy zarzą­dza­nia zorien­to­wa­ne­go na pro­ce­sy i reor­ga­ni­za­cję w fir­mach) powo­du­je sta­wia­nie takich wyma­gań tak­że dostaw­com roz­wią­zań IT. Te któ­re się do tego nie dosto­su­ją, moim zda­niem odej­dą z rynku.

Model biz­ne­so­wy fir­my, infor­ma­cje i dane jakich fir­ma wyma­ga do spraw­ne­go funk­cjo­no­wa­nia to już jeden orga­nizm. Stało się fak­tem, że żad­na fir­ma na ryn­ku już nie będzie w sta­nie kon­ku­ro­wać bez spraw­ne­go zarzą­dza­nia infor­ma­cją. Do zarzą­dza­nia infor­ma­cją i prze­twa­rza­nia danych zaś potrzeb­ne są spraw­nie dzia­ła­ją­ce i przede wszyst­kim łatwe w ich roz­wi­ja­niu sys­te­my. Warunek taki speł­nia­ją obec­nie zorien­to­wa­ne na pro­ce­sy sys­te­my two­rzo­ne w tech­no­lo­giach obiektowych.

Drugi waru­nek spraw­no­ści orga­ni­za­cji to opty­ma­li­za­cja jej wewnętrz­nej wydaj­no­ści. Tu wkra­cza­my dla odmia­ny w zarzą­dza­nie i jego pro­ce­so­wą natu­rę. Jak to pogo­dzić? Postrzegam tu wła­śnie miej­sce dla archi­tek­tu­ry SOA. Firmę i jej miej­sce w ryn­ko­wym łań­cu­chu war­to­ści moż­na, moim zda­niem, jed­no­znacz­nie opi­sać tyl­ko za pomo­cą mode­lu pro­ce­so­we­go zorien­to­wa­ne­go na pro­duk­ty. Zasoby (tu sys­tem IT) potrzeb­ne do reali­za­cji tej stra­te­gii ana­li­zu­je­my już obiektowo.

Namiastką takich opi­sów i ana­liz były pro­ce­du­ry w księ­gach jako­ści ISO. Do peł­nej ana­li­zy wyma­ga­ny jest jed­nak opis (mapa pro­ce­sów) uwzględ­nia­ją­cy cały obraz fir­my. SOA to archi­tek­tu­ra wska­zu­ją­ca natu­ral­ny pro­ces pro­jek­to­wa­nia sys­te­mów IT: model pro­ce­so­wy fir­my (orga­ni­za­cji), ana­li­za pro­ce­sów z per­spek­ty­wy zaso­bów IT jaki­mi mogą być wspie­ra­ne, na bazie tej ana­li­zy powsta­je lista usług na rzecz pro­ce­sów biz­ne­so­wych jakich ocze­ku­je­my od nowe­go systemu.

Następnie w pro­ce­sie ana­li­zy obiek­to­wej usłu­gi te trans­po­no­wa­ne są na model obiek­to­wy przy­szłe­go sys­te­mu IT. Analiza obiek­to­wa powin­na dać jako pro­dukt tak­że opis dzie­dzi­ny sys­te­mu czy­li repre­zen­ta­cję rze­czy­wi­stych obiek­tów w sys­te­mie. Jest to pod­sta­wa mode­lu danych dla powsta­ją­ce­go sys­te­mu. Kolejne eta­py to już pro­jekt obiek­to­we­go pro­gra­mu (apli­ka­cji) i jego implementacja.

A na grzyba mi to modelowanie!

Na począ­tek histo­ryj­ka: Konsultant uma­wia się z Prezesem fir­my na spo­tka­nie. Sprawa waż­na bo Prezes zle­cił mu wdro­że­nie nowe­go sys­te­mu wyna­gro­dzeń i pre­mio­wa­nia. Na spo­tka­niu kon­sul­tant po krót­ce opo­wie­dział, że to wyjąt­ko­wo waż­na spra­wa dla fir­my. Poprosił potem o wyzna­cze­nie kil­ku osób ze ści­słe­go kie­row­nic­twa, któ­re wraz z nim opra­cu­ją wyma­ga­nia na nowy sys­tem płac, któ­ry to potem kon­sul­tant opra­cu­je i wdro­ży w fir­mie. Prezes odrzekł: to są pła­ce dla moich pra­cow­ni­ków, ja nie mam cza­su, pro­szę się umó­wić z nimi, prze­pro­wa­dzić ankie­ty i niech oni Panu okre­ślą jak chcą być wyna­gra­dza­ni i ile chcą zara­biać. To w koń­cu to dla nich te pieniądze.”

Już widzę uśmie­chy na Waszych twa­rzach. I…

Sytuacja nie do wyobra­że­nia, chy­ba żaden Prezes by tak nie postą­pił. Tylko Zarząd fir­my ma wie­dzę na temat celów fir­my i jej stra­te­gii oraz wie­dze o kosz­tach, wiec tyl­ko Zarząd ma pod­sta­wy by okre­ślać jak się ma koszt pra­cy do potrzeb fir­my w kwe­stii wyko­ny­wa­nia tej pra­cy. Że nie wspo­mnę jak by wyglą­da­ły pła­ce usta­na­wia­ne przez płacobiorców.

Jednak nie­ste­ty takie sytu­acje są nagmin­ne! Bo czym od poprzed­niej róż­ni się ta histo­ryj­ka: Konsultant uma­wia się z Prezesem fir­my na spo­tka­nie. Sprawa waż­na bo Prezes zle­cił mu wdro­że­nie nowe­go sys­te­mu wspie­ra­ją­ce­go zarzą­dza­nie fir­mą. Na spo­tka­niu kon­sul­tant po krót­ce opo­wie­dział, że to wyjąt­ko­wo waż­na spra­wa dla fir­my, nale­ży usta­lić cele biz­ne­so­we a potem wyma­ga­nia na sys­tem IT itp.. Poprosił o wyzna­cze­nie kil­ku osób ze ści­słe­go kie­row­nic­twa, któ­re wraz z nim opra­cu­ją wyma­ga­nia na nowy, tak waż­ny sys­tem, któ­ry to potem kon­sul­tant przy­go­tu­je lub wybie­rze na ryn­ku i wdro­ży. Prezes odrzekł: to jest sys­tem dla moich pra­cow­ni­ków, ja nie mam cza­su, pro­szę się umó­wić z nimi, prze­pro­wa­dzić ankie­ty i niech oni Panu okre­ślą jak chcą żeby on wyglą­dał i co robił. To w koń­cu dla nich to nowe narzę­dzie pracy.”

I jak teraz wyglą­da­ją Wasze miny? Dla mnie obie histo­ryj­ki są takie same w kwe­stii sku­tecz­no­ści obu pro­jek­tów dla firmy.

Więc jak to jest z tymi wyma­ga­nia­mi? Jak je wyspecyfikować?

Po pierw­sze każ­dy nowy zasób czy reor­ga­ni­za­cja fir­my, powin­ny być efek­tem jakie­goś celu biz­ne­so­we­go. System IT to nic inne­go jak kolej­ny nowy zasób w fir­mie, nowe narzę­dzie pra­cy. Więc wła­ści­wa kolej­ność sama się nasuwa:

  1. Opracowanie celów biz­ne­so­wych i planów
  2. Opracowanie stra­te­gii reali­za­cji pla­nów i listy wyma­ga­nych zasobów
  3. Określenie wyma­gań na te zaso­by (tu sys­tem IT)
  4. Znalezienie pro­duk­tu lub usłu­gi oraz ich dostaw­cy speł­nia­ją­cych tak okre­ślo­ne wyma­ga­nia (wska­za­nie wyma­ga­nych w nowym sys­te­mie funkcjonalności),
  5. Wdrożenie, w tym nano­sze­nie zmian na pro­jekt, jeże­li tyl­ko oka­że się, że w trak­cie wdro­że­nia zaszły zmia­ny na ryn­ku, uza­sad­nia­ją­ce zmia­ny w projekcie.

Jak zebrać wyma­ga­nia, sko­ro nie ankietami?

Ankiety to, ich treść, jak wie­lo­krot­nie sły­sza­łem, to tak zwa­ne poboż­ne życze­nia”. Sam ten epi­tet o czymś już świad­czy. Tak wiec ja uwa­żam, że nale­ży ich uni­kać. Moim zda­niem sku­tecz­niej­szą dro­gą, zapew­nia­ją­cą dużo mniej­sze ryzy­ko pomi­nię­cia istot­nych cech i chro­nią­ce wła­śnie przed poboż­ny­mi życze­nia­mi” jest wyko­na­nie mode­lu firmy.

Model taki budu­je­my meto­dą od ogó­łu do szcze­gó­łu”. Modelem orga­ni­za­cji naj­le­piej wspie­ra­ją­cym kolek­cjo­no­wa­nie wyma­gań na sys­tem IT jest mapa pro­ce­sów biz­ne­so­wych. Model taki przy oka­zji może posłu­żyć do pew­nej reor­ga­ni­za­cji fir­my. Nie zapo­mi­naj­my, że wdra­ża­ny sys­tem to nowe narzę­dzie pra­cy więc zawsze wdro­że­nie wią­że się z reor­ga­ni­za­cją w fir­mie. Modelowanie zaś, pro­wa­dzo­ne w pewien spe­cy­ficz­ny spo­sób bar­dzo uła­twia wychwy­ty­wa­nie w orga­ni­za­cji wszel­kich nie­lo­gicz­no­ści, zbyt kosz­tow­nych pro­ce­sów, zbęd­nych czyn­no­ści. Jak?

Część ana­li­ty­ków uży­wa mode­lo­wa­nia tyl­ko do udo­ku­men­to­wa­nia zasta­ne­go oraz pla­no­wa­ne­go sta­nu rze­czy jed­nak mode­lo­wa­nie może przy­nieść dale­ko więk­sze korzy­ści poza pro­jek­ta­mi infor­ma­tycz­ny­mi. Jak przy­nieść oszczęd­no­ści samym tyl­ko wyko­na­niem mode­lu? Jak osią­gnąć korzy­ści z mode­lo­wa­nia odkła­da­jąc na zakoń­cze­nie pro­jek­tu wyko­na­ny model na pół­kę? Historia zna wie­le przy­pad­ków, że samo wyko­na­nie mode­lu fir­my, oczysz­cze­nie go z nie­lo­gicz­no­ści, zbęd­nych czyn­no­ści itp. powo­do­wa­ło obni­że­nie kosz­tów nawet o 30%! Oczyszczenie fir­my tyl­ko z nie­po­trzeb­nych, nie wno­szą­cych war­to­ści pro­ce­sów, może istot­nie skró­cić czas obsłu­gi klien­tów a to już nic inne­go jak pod­nie­sie­nie kon­ku­ren­cyj­no­ści w czy­stej postaci.

Tworząc model pro­ce­sów moż­na oprzeć się na teo­rii łań­cu­cha war­to­ści i nało­żyć na pro­ces mode­lo­wa­nia pew­ne wyma­ga­nia. Ogólnie pole­ga to na przy­ję­ciu zasa­dy, że każ­dy mode­lo­wa­ny ele­ment (pro­ces) musi powięk­szać war­tość wno­szo­ną do całe­go łań­cu­cha pro­ce­sów (łań­cu­cha war­to­ści), w któ­rym uczest­ni­czy. Jako przy­kład podam pozor­nie pro­sty model orga­ni­za­cyj­ny fir­my, któ­ry moż­na ana­li­zo­wać podob­nie a jest łatwiej­szy do poka­za­nia tej zasady.

Jeżeli chce­my takim sche­ma­tem zapre­zen­to­wać tyl­ko wolę Zarządu fir­my w kwe­stii orga­ni­za­cji fir­my to może on mieć dowol­ną postać zgod­ną z życze­niem decy­den­ta. Możemy jed­nak poku­sić się o posta­wie­nie sobie inne­go zada­nia: uspraw­nie­nie orga­ni­za­cji i jej opty­ma­li­za­cja. W takim przy­pad­ku narzu­ca­my pew­ne zasa­dy na two­rze­nie sche­ma­tu orga­ni­za­cyj­ne­go. Nazwiemy go teraz mode­lem orga­ni­za­cji zaso­bów ludz­kich firmy.

Taką zasa­dą może być np. zało­że­nie, że każ­dy każ­dy pra­cow­nik ma tyl­ko jed­ne­go prze­ło­żo­ne­go, oraz każ­dy kie­row­nik ma co naj­mniej dwóch pod­wład­nych. Bo jaką rolę speł­nia oso­ba, któ­ra ma jed­ne­go sze­fa i jed­ne­go pod­wład­ne­go? Jedną z ról mene­dże­ra (kie­row­ni­ka) jest orga­ni­za­cja pra­cy pod­wład­nych jed­nak trud­no mówić, że orga­ni­zu­je­my coś lub koor­dy­nu­je­my sko­ro mamy tyl­ko jed­ne­go pod­wład­ne­go? Jaką wiec war­tość wno­si w hie­rar­chii oso­ba mają­ca tyl­ko jed­ne­go pod­wład­ne­go? Tą meto­dą skon­stru­uje­my bar­dzo przy­dat­ny sche­mat orga­ni­za­cyj­ny, pro­po­nu­je spró­bo­wać same­mu. Taki sche­mat jest w zasa­dzie wyma­ga­ny jako lista zaso­bów (ról) np. w sys­te­mie ERP

Modelując pro­ce­sy moż­na poczy­nić kil­ka tego rodza­ju zało­żeń i oka­zu­je się, że samo mode­lo­wa­nie, czy­li zasta­no­wie­nie się nad logi­ką każ­de­go ele­men­tu fir­my, przy­no­si już korzy­ści. Mając model pro­ce­sów upo­rząd­ko­wa­ny, opra­co­wa­ny na nowo, oczysz­czo­ny z błę­dów orga­ni­za­cyj­nych” robi­my listę pro­ce­sów, któ­re chce­my wes­przeć nowym sys­te­mem i mamy listę ocze­ki­wa­nych funk­cjo­nal­no­ści. Jest to lista dosko­na­le nada­ja­ca się np. do wyko­na­nia dia­gra­mu przy­pad­ków uży­cia, tez zaś spo­koj­nie moż­na udo­ku­men­to­wać wspo­ma­ga­jąc się wywia­da­mi ale dopie­ro teraz.

Metodyka ta jest zgod­na z mode­lem SOA (ang. Service Oriented Application, Aplikacje zorien­to­wa­ne na usłu­gi), któ­re­go to mode­lu popu­lar­ność rośnie od pew­ne­go cza­su (wię­cej na stro­nie www​.omg​.org). Metodyka ta jest zgod­na tak­że z [[meto­dą pod­no­sze­nia efek­tyw­no­ści orga­ni­za­cji Rummlera-Brache’a]].

Firma jako taka jest pro­ce­sem w ryn­ko­wym łań­cu­chu war­to­ści w jakim funk­cjo­nu­je. Przykład: na jed­nym koń­cu łań­cu­cha mamy kopal­nię węgla a na dru­gim np. mój kalo­ry­fer w domu. Po dro­dze jest np. elek­tro­cie­płow­nia opa­la­na węglem. Mamy więc łań­cuch pro­ce­sów takich jak: wydo­by­cie węgla, trans­port węgla, wytwa­rza­nie pary, trans­port pary do miesz­kań. To sa pro­ce­sy, któ­re moż­na dekom­po­no­wać i będzie­my w tedy mode­lo­wa­li poszcze­gól­ne fir­my. Biznesami są: kopal­nie, kolej, elek­tro­cie­płow­nie. Możliwe są np. trzy pro­ce­sy wydo­by­cia, trans­por­tu i pro­ces wytwa­rza­nia pary mogą sta­no­wić jeden biz­nes np. Turoszów. Tak więc moż­na spo­koj­nie według mnie przy­jąć, że powsta­nie pro­duk­tu (gdzie pro­duk­tem pro­ce­su może być tak­że stan nazwa­ny: węgiel dowie­zio­ny do celu) jest celem pro­ce­su. Co do celu mode­lu dla mnie jest tyl­ko jeden: udo­ku­men­to­wa­nie przed­mio­tu i wyni­ków ana­li­zy oraz testo­wa­nie hipo­tez a to pro­sta dro­ga do obni­że­nia ryzy­ka przy­ję­cia hipo­te­zy we wdro­że­niu. I po to głow­nie modelujemy.

złożoność złożony system skomplikowany http://hikingartist.files.wordpress.com/

Ile zapłaciłeś za wykonanie SIWZ na system ERP?

złożoność złożony system skomplikowany http://hikingartist.files.wordpress.com/Niedawno pew­na fir­ma IT otrzy­ma­ła zapy­ta­nie ofer­to­we na sys­tem ERP i popro­si­ła mnie o wspar­cie w przy­go­to­wa­niu ofer­ty. Zapytanie zawie­ra­ło tabe­lę zawie­ra­ją­cą 1480 wyma­ga­nych i opcjo­nal­nych cech sys­te­mu. Na czym to moje wspar­cie mia­ło pole­gać? Ano na usto­sun­ko­wa­niu się do zapy­ta­nia. Nie będę się wgłę­biał w szcze­gó­ły tym bar­dziej, że to tajem­ni­ca han­dlo­wa jed­nak tknę­ło mnie te 1480 pozy­cji i ich treść. Otóż coraz czę­ściej widu­ję takie i podob­ne zapy­ta­nia. Są one do sie­bie bar­dzo podob­ne, żeby nie powie­dzieć, że cza­sa­mi toż­sa­me. I nie cho­dzi tu o samą listę wyma­gań i jej szcze­gó­ło­wość ale tak­że o koszt wyko­na­nia same­go SIWZ (Specyfikację Istotnych Warunków Zamówienia, ang RFP: Request For Proposal)) . Ile to kosz­tu­je? Kto za stan­dar­do­wą listę wyma­gań zapła­cił wię­cej niż $1000 naj­praw­do­po­dob­niej przepłacił.

Jak zro­bić SIWZ/OPZ?

Nie raz zda­rza mi się opra­co­wy­wać wyma­ga­nia na sys­tem IT. Dzielę je zawsze na dwie gru­py (dwa obsza­ry): wyma­ga­nia stan­dar­do­we i nie­stan­dar­do­we. Moim zda­niem szcze­gól­nej pra­cy wyma­ga­ją te nie­stan­dar­do­we bo one w więk­szo­ści decy­du­ją o prze­wa­dze ryn­ko­wej fir­my. Wymagania stan­dar­do­we to z regu­ły cechy opro­gra­mo­wa­nia narzu­co­ne przez usta­wo­daw­stwo, róż­ne­go rodza­ju stan­dar­dy (ERP, SCOR itp.) oraz uzna­ne za stan­dard dostęp­ne na ryn­ku pro­duk­ty gotowe.

Tu nie przed­sta­wię szcze­gó­ło­wej recep­ty na SIWZ bo takiej moim zda­niem nie ma, ale suge­ru­je tę pra­cę podzie­lić na podprojekty:

  1. Analiza wyko­ny­wal­no­ści zakoń­czo­na mode­lem biz­ne­so­wym i opi­sem (lub wycią­giem) stra­te­gii ryn­ko­wej fir­my. Powinna taka ana­li­za zawie­rać wła­śnie dwa obsza­ry wdro­że­nia: stan­dar­do­wy opar­ty na wzor­cach oraz dokład­nie zde­fi­nio­wa­ny obszar budo­wa­nia prze­wa­gi konkurencyjnej.
  2. Obszar stan­dar­do­wy opi­su­je­my stan­dar­do­wym wzor­cem (o czym dalej) a obszar spe­cy­ficz­ny dla fir­my nale­ży szcze­gó­ło­wo prze­ana­li­zo­wać i opra­co­wać model pro­ce­sów biz­ne­so­wych (ale raczej bez szcze­gó­ło­wych opi­sów czyn­no­ści co jest moim, i nie tyl­ko, zda­niem nie­po­ro­zu­mie­niem na eta­pie ana­li­zy przed­wdro­że­nio­wej, zapra­szam na szko­le­nie z mode­lo­wa­nia pro­ce­sów biz­ne­so­wych).
  3. Na bazie wyko­na­nej ana­li­zy wyod­ręb­nić z niej listę wyma­gań for­mal­nych ale mie­rzal­nych, czy­li nie może tam być (co nagmin­nie spo­ty­kam) wyma­gań w rodza­ju: sys­tem ma dru­ko­wać mie­sięcz­ny raport sprze­da­ży w moż­li­wie krót­kim cza­sie, sys­tem ma pozwa­lać na wysta­wie­nie fak­tu­ry w akcep­to­wal­nym dla klien­tów cza­sie (co to zna­czy?). Sugeruje raczej: sys­tem ma pozwa­lać na wyge­ne­ro­wa­nie rapor­tu zawie­ra­ją­ce­go listę trans­ak­cji sprze­da­ży z podzia­łem na regio­ny, sprze­daw­ców oraz gru­py pro­duk­tów w cza­sie nie dłuż­szym niż 5 minut.

Oferty ryn­ko­we

Co do czę­ści stan­dar­do­wej moż­na zro­bić to same­mu korzy­sta­jąc z tanich ofert dostęp­nych w sie­ci np. http://​rfp​-buil​der​.com/ (Ready-to-use RFI/RFP Templates Designed by expert ana­ly­sts for any softwa­re selec­tion pro­ject) gdzie moż­na nabyć gotow­ce. Przytoczę tu kil­ka goto­wych pro­duk­tów do wykorzytania:

  • Zapytanie o sys­tem finan­so­wy (4122 cechy funk­cjo­nal­ne): $395 (to nale­ży uzu­peł­nić spe­cy­fi­ka naszej usta­wy o rachunkowości)
  • Zapytanie o sys­tem Wspomagania Podejmowania Decyzji (1357 cech funk­cjo­nal­nych): $495
  • Zapytanie o sys­tem wspo­ma­ga­ją­cy zarzą­dza­nie pro­ce­sa­mi biz­ne­so­wy­mi (610 cech funk­cjo­nal­nych) $295
  • Zapytanie o sys­tem CRM w obsza­rze finan­sów i ubez­pie­czeń (1839 cech funk­cjo­nal­nych): $595
  • Zapytanie o typo­wy sys­tem CRM (1140 cech funk­cjo­nal­nych): $595
  • Zapytanie o sys­tem ERP dla pro­duk­cji dys­kret­nej (3477 cech funk­cjo­nal­nych): $495
  • Zapytanie o stan­dar­do­wy sys­tem ERP (3324 cechy funk­cjo­nal­ne): $495
  • Zapytanie o sys­tem zarzą­dza­nia łań­cu­chem dostaw SCM (2232 cechy funk­cjo­nal­ne): $745

Doliczyć nale­ży kosz­ty tłu­ma­cze­nia. Pytanie inne brzmi: czy ma sens tak szcze­gó­ło­wa specyfikacja?

Warto też zwró­cić uwa­gę na bar­dzo cie­ka­wy, szyb­ko roz­wi­ja­ją­cy się wor­tal decy​zje​-IT​.pl (www​.decy​zje​-it​.pl). Jest on part­ne­rem kana­dyj­skiej fir­my Technology Evaluation Centers nale­żą­cej do czo­łów­ki firm kon­sul­tin­go­wych na świe­cie, a naj­więk­szej ofe­ru­ją­cej roz­wią­za­nia kon­sul­tin­go­we on-line. Dostępne w wor­ta­lu decy​zje​-IT​.pl roz­wią­za­nia pozwa­la­ją nie tyl­ko na pobra­nie odpo­wied­nich RFP (zapy­ta­nia o ofer­tę, czę­ścio­wo już w języ­ku pol­skim), ale rów­nież umoż­li­wia­ją oce­nę sys­te­mów wspie­ra­ją­cych zarzą­dza­nie w opar­ciu o zde­fi­nio­wa­ne przez użyt­kow­ni­ka klu­czo­we wyma­ga­nia. Znaczna część usług jest przy tym bez­płat­na. Istnieje moż­li­wość udo­ku­men­to­wa­nia oce­ny szcze­gó­ło­wym rapor­tem i wykre­sa­mi. Całość bazy zawie­ra oko­ło tysią­ca róż­nych sys­te­mów z całe­go świa­ta, w tym wie­le dostęp­nych w Polsce.

Notatka: (uzu­peł­nio­ny 2006-12-06, $199 kosz­tu­je dość dokład­ne roz­po­zna­nie ryn­ku i zrę­by SIWZ w języ­ku polskim)

Przypadki użycia i UML: jak modelować

Moim zda­niem błę­dem wie­lu pro­jek­tan­tów pro­gra­mów (sys­te­mów) jest mnie­ma­nie, że pro­jek­tu­ją biz­nes”. Nie! Projektują narzę­dzie biz­ne­su a to jest istot­na róż­ni­ca. Krawiec nie mode­lu­je i nie szy­je czło­wie­ka tyl­ko pro­jek­tu­je i szy­je to, co czło­wiek na sie­bie zało­ży, dla­te­go dobry gar­ni­tur musi mieć roz­po­rek ale już nie koniecz­nie kie­szeń na papier toa­le­to­wy. Jednak ten mane­kin musi być taki jak czło­wiek”, model biz­ne­su w opro­gra­mo­wa­niu także.

Kiedy i po co modelują?

Co to są te przy­pad­ki uży­cia? Najogólniej to lista czyn­no­ści, któ­re opi­su­je­my tak by pro­gra­mi­sta na ich pod­sta­wie wie­dział jakie funk­cjo­nal­no­sci ma reali­zo­wać pro­gram. Moja pra­ca nie raz doty­czy wyko­na­nia spe­cy­fi­ka­cji wyma­gań na sys­tem IT a to czę­sto są wła­śnie przy­pad­ki uży­cia. Praca moja na przy­pad­kach uży­cia się koń­czy. Dalej już pro­gra­mi­ści a ja nim nie jestem. Ale do rze­czy. Opis przy­pad­ków uży­cia jest tak na praw­dę zbio­rem pod­sta­wo­wych wyma­gań funk­cjo­nal­nych i musi być jed­no­znacz­ny, spój­ny i kompletny.

Jak ja sobie z tym radzę? 

Po wie­lu podej­ściach do two­rze­nia przy­pad­ków uży­cia uzna­łem, że nale­ży naj­pierw opi­sać co jest w ogó­le celem two­rze­nia tego sys­te­mu, co on ma wspo­ma­gać lub auto­ma­ty­zo­wać. Jak? Należy naj­pierw zamo­de­lo­wać tę wspo­ma­ga­ną czyn­ność w zupeł­nym ode­rwa­niu od sys­te­mów. Jak już zde­fi­niu­je­my i zop­ty­ma­li­zu­je­my samą czyn­ność moż­na zabie­rać się do wyszcze­gól­nia­nia przy­pad­ków uży­cia czy­li tak na praw­dę zapro­jek­to­wać tę dru­ga stro­nę lustra”.

Jak ja to robię? 

Tworzę model pro­ce­sów (uży­wam nota­cji i meto­dy­ki BPMN ale w prost­szych przy­pad­kach może to być np. dia­gram czyn­no­ści UML), od któ­re­go pro­po­nu­ję zacząć. Potem wska­zu­ję (wybie­ram) te czyn­no­ści, któ­re będą kom­pu­te­ry­zo­wa­ne” (bo nie koniecz­nie wszyst­kie). W meto­dy­ce któ­rą sto­su­ję jest poję­cie czar­nej skrzyn­ki. Jest to np. pro­jek­to­wa­ny jesz­cze hipo­te­tycz­ny sys­tem. Tworząc model pro­ce­sów łączę czar­ną skrzyn­kę z wybra­ny­mi czyn­no­ścia­mi (pro­ce­sa­mi) i opty­ma­li­zu­je tak powsta­ły model. Prosty przy­kład poniżej:

Proszę zwró­cić uwa­gę, że prze­ry­wa­ne linie od mode­lu do czar­nej skrzyn­ki to kom­plet­na lista przy­pad­ków uży­cia. Wystarczy je tyl­ko zebrać i udo­ku­men­to­wać np. tak jak w RUPie opi­so­wo za pomo­cą tabel lub struk­tu­ral­ne­go tak­stu. Podejście to wyma­ga trosz­kę wię­cej pra­cy ale ryzy­ko pomi­nię­cia cze­goś istot­ne­go jest mini­mal­ne dla­te­go war­to ten czas poświę­cić. Po dru­gie klient może łatwo taki model zwe­ry­fi­ko­wać i zatwier­dzić bo jest zro­zu­mia­ły dla nie­fa­chow­ców. Kto choć raz zetknął z odbio­rem sys­te­mu ten wie jak to ważne.

_______

2012: obec­nie sto­su­ję meto­dę prost­szą, ozna­cza­nie czyn­no­ści zakwa­li­fi­ko­wa­nych jako przy­pad­ki uży­cia, zamiast budo­wa­nia zło­żo­ne­go dia­gra­mu zawie­ra­ją­ce­go pulę System. Więcej o przej­ściu z mode­lu pro­ce­su na przy­pad­ki uży­cia.