Tag: framework

Target Operating Model, 7S framework i i nne

Dodaj komentarz

Od cza­su do cza­su jestem pyta­ny o róż­ne ​„fra­me­wor­ki” i meto­dy­ki doty­czą­ce ​„cało­ścio­we­go opi­su fir­my”. Można spo­tkać wie­le róż­nych, lep­szych lub gor­szych mode­li i sza­blo­nów, ram (fra­me­wor­ków), jed­nak moim zda­niem, podej­ście mini­ma­li­stycz­ne (patrz [[brzy­twa Ockhama]]) jest naj­lep­sze. Zmusza do zro­zu­mie­nia isto­ty rze­czy, bez masko­wa­nia nie­wie­dzy nowy­mi i, nie raz, sztucz­ny­mi poję­cia­mi. Drugim powo­dem, któ­ry moim zda­niem leży u pod­staw pomy­słów na ​„nowe mode­le”, jest pra­wo autor­skie. Opracowanie uni­kal­ne­go ​„fra­me­wor­ka” czy­ni z auto­ra takie­go dzie­ła ​„wła­ści­cie­la meto­dy”, za któ­rą ma pra­wo pobie­rać opła­ty licen­cyj­ne (przy­kła­dem jest np. TOGAF i nota­cja ArchiMate chro­nio­ne pra­wem autor­skim przez komer­cyj­ną orga­ni­za­cję The Open Group).

Takich ​„fra­me­wor­ków” jest wię­cej, tu dwa inne przy­kła­dy na popar­cie mojej tezy, TOM:

TOMTarget Operating Model (TOM). Once you’ve arti­cu­la­ted your stra­te­gy, one of the next things to do is to design the orga­ni­sa­tion to deli­ver it. This is usu­al­ly expres­sed in the form of a Target Operating Model (TOM). The gene­ral appro­ach is to defi­ne the people, pro­ces­ses and tech­no­lo­gy requ­ired to deli­ver the stra­te­gy. (za How to design a Target Operating Model (TOM)).

albo ten nazwa­ny 7s:

McKinsey7-SMcKinsey and Co’s 7S fra­me­work pro­vi­des a use­ful fra­me­work for ana­ly­sing the streng­ths and weak­nes­ses of an orga­ni­sa­tion (see also 7 Essential Strategy Analysis Tools). The McKinsey Consulting Firm iden­ti­fied stra­te­gy as only one of seven ele­ments exhi­bi­ted by the best mana­ged com­pa­nies. (za McKinsey 7‑S).

Osobiście sto­su­ję (i nie ja jeden) dar­mo­wy i dobrze opi­sa­ny (moim zda­niem znacz­niej lepiej niż powyż­sze) spój­ny zestaw sys­te­mów poję­cio­wych rodem z OMG (www​.omg​.org, dostęp publicz­ny, nie wyma­ga­ją­cy żad­nych opłat licen­cyj­nych). Powyższe ​„potrze­by” czy­li połą­cze­nie pojęć: ludzie, zaso­by, wie­dza, pro­ce­sy, połą­cze­nie w jeden mecha­nizm, wyglą­da­ją tak:

Jak opisać firmę wewnątrz: model procesów biznesowych

(opra­co­wa­nie wła­sne auto­ra na bazie spe­cy­fi­ka­cji nota­cji OMG​.org)

Łącznikiem jest abs­trak­cja, jaką jest pro­ces biz­ne­so­wy. Proces biz­ne­so­wy jako byt, nie ma w orga­ni­za­cji zma­te­ria­li­zo­wa­nej posta­ci, jed­nak jest ele­men­tem (poję­ciem) łączą­cym wie­dzę (doku­men­ty), ludzi i ich umie­jęt­no­ści, ich struk­tu­rę oraz regu­ły rzą­dzą­ce tym jak powsta­ją pro­duk­ty pro­ce­sów. Proces biz­ne­so­wy to mecha­nizm łączą­cy poję­cia opi­su­ją­ce orga­ni­za­cję. Są to takie poję­cia jak: wie­dza, regu­ły biz­ne­so­we, pro­ce­du­ry, ludzie i ich struk­tu­ra orga­ni­za­cyj­na, narzę­dzia pra­cy (w tym opro­gra­mo­wa­nie). Całość jest powią­za­na razem (o tych powią­za­niach pisa­łem w arty­ku­le Modelowanie w pro­jek­tach inte­gra­cyj­nych). Dysponujemy kom­ple­tem nota­cji pozwa­la­ją­cych opi­sać orga­ni­za­cję ​„od stóp do głów”: [[BMM]] w sfe­rze moty­wa­cji biz­ne­so­wej, [[BPMN]] w sfe­rze prze­pły­wu pra­cy oraz [[UML]] w sfe­rze sys­te­mów. Opisałem to w arty­ku­le Architektura kor­po­ra­cyj­na z OMG​.org.

Tak więc po co mno­żyć byty? Profesjonalne narzę­dzia CASE, pozwa­la­ją na wyko­rzy­sta­nie opi­sa­nych tu nota­cji (tych chro­nio­nych pra­wa­mi autor­ski­mi nota­cji, raczej nie obsłu­gu­ją albo robią to za dodat­ko­wą opła­tą), OMG dba bar­dzo dobrze o ich spój­ność poję­cio­wą (opi­sa­na w arty­ku­le o SOA). Wydaje mi się, że ​„nowe sys­te­my i fra­me­wor­ki” nie wno­szą żad­nej nowej war­to­ści, budu­ją jed­nak – gdy ich użyć – pew­ne uza­leż­nie­nie od ich twórców.

IFS Open Information Architecture

Frameworks Introduction – czyli jak się psuje dobre ERP

1 komentarz

Swego cza­su bra­łem udział w burz­li­wiej dys­ku­sji (zresz­tą nie­jed­nej) na temat sen­su prac ana­li­tycz­nych i pro­jek­to­wych przy oka­zji wdra­ża­nia sys­te­mów ERP, czy­li goto­we­go opro­gra­mo­wa­nia (prze­czy­taj arty­kuł). Większość dostaw­ców tego opro­gra­mo­wa­nia, z jaki­mi mie­wam kon­takt, uwa­ża, że ana­li­za owszem ale w celu opra­co­wa­nia kon­cep­cji wdro­że­nia, czy­li doku­men­tu mówią­ce­go jak dosto­so­wać sys­tem ERP do potrzeb klien­ta z naci­skiem na sło­wo kom­pro­mis. Pojawia się prę­dzej czy póź­niej świę­te sło­wo kasto­mi­za­cja, któ­re po pro­tu ozna­cza naj­czę­ściej prze­ra­bia­nie goto­we­go pro­duk­tu (nie raz bar­dzo dobre­go do momen­tu gdy się go nie popsu­je tymi prze­rób­ka­mi, prze­czy­taj i ten arty­kuł).

Niedawno pisa­łem, że

goto­we opro­gra­mo­wa­nie nale­ży zosta­wić nie­tknię­te (nie licząc okie­nek kon­fi­gu­ra­cji) a bra­ku­ją­ce funk­cjo­nal­no­ści opra­co­wać, zapro­jek­to­wać i zin­te­gro­wać.

Z regu­ły jak tyl­ko wypo­wiem tę kwe­stię, lecą na mnie gro­my ze stro­ny kon­sul­tan­tów dostaw­ców ERP. Jednak war­to te meto­dę sto­so­wać co potwier­dza­ją nie tyl­ko moje doświadczenia:

Eksperci pod­kre­śla­ją bowiem, że więk­szość kosz­tów gene­ro­wa­nych przez pro­jekt wdro­że­nio­wy nie ma nic wspól­ne­go z kosz­tem same­go opro­gra­mo­wa­nia. ?Średnio trzy czwar­te budże­tu pochła­nia­ją kosz­ty wdro­że­nia, mody­fi­ka­cji stan­dar­do­wej funk­cjo­nal­no­ści oraz moder­ni­za­cji sprzę­tu? ? czy­ta­my w rapor­cie Panorama Consulting Group. […] O sys­te­mach kla­sy ERP coraz czę­ściej mówi się, że są zbyt roz­le­głe, ocię­ża­łe i ogra­ni­cza­ją moż­li­wo­ści biz­ne­su, od któ­re­go wyma­ga się zwin­no­ści i ela­stycz­no­ści. Czy cza­sy takich sys­te­mów już prze­mi­ja­ją?? (źr. IDG, 2010r)

Stale śle­dzę to co się dzie­je na ryn­ku sys­te­mów IT wspo­ma­ga­ją­cych zarzą­dza­nie obser­wu­ję taki wła­snie kie­ru­nek rozwoju:

Systemy zin­te­gro­wa­ne ERP będą pew­ny­mi zesta­wa­mi goto­wych funk­cjo­nal­no­ści, zbu­do­wa­ny­mi w opar­ciu o szkie­le­ty opro­gra­mo­wa­nia zaś inte­gra­cja będzie bazo­wa­nia nie na współ­dzie­le­niu danych a na wymia­nie ich pomię­dzy modu­ła­mi i zewnętrz­ny­mi sys­te­ma­mi na rów­nych pra­wach. Rozwój sys­te­mu w takim przy­pad­ku pole­ga na two­rze­niu nowych modu­łów tym śro­do­wi­sku a nie na mody­fi­ka­cji już istniejących.

Kierunek ten już widać od ok. dwóch lat na ryn­ku (ja o tym pisze od ponad pię­ciu), pra­ce te więc trwa­ją zapew­ne znacz­nie dłu­żej. Widać to na stro­nach nie­któ­rych dostaw­ców, lide­rów na rynku:

Dynamics AX 2009. Framework (szkie­let, przyp. mój) to zestaw wzor­ców pro­jek­to­wych, inter­fej­sów, goto­wych biblio­tek i innych narzę­dzi. Elementy te dają wspar­cie pro­gra­mi­stom. Najlepszą prak­ty­ką jest się­ga­nie do tych zaso­bów i wyko­rzy­sty­wa­nie ich zamiast two­rzyć wła­sne podob­ne. Tu opi­sa­no fra­me­work, pod­sys­te­my i funk­cjo­nal­no­ści Microsoft Dynamix AX (źr. Frameworks Introduction).

Obecnie stan­dar­dem jest sto­so­wa­nie w fra­mer­wor­kach, prze­zna­czo­nych do two­rze­nia opro­gra­mo­wa­nia biz­ne­so­we­go w śro­do­wi­sku prze­glą­da­rek WWW, (i nie tyl­ko) wzor­ca pro­jek­to­we­go MVC:

Wzorzec MVC poma­ga two­rzyć apli­ka­cje roz­dzie­la­jąc trzy róż­ne aspek­ty opro­gra­mo­wa­nia: inter­fejs użyt­kow­ni­ka, logi­kę biz­ne­so­wą oraz zacho­wa­nie sys­te­mu, poprzez zacho­wa­nie mini­mal­nych wza­jem­nych zależ­no­ści. Wzorzec opi­su­je gdzie każ­dy z ele­men­tów tej logi­ki umiesz­czać. Interfejs użyt­kow­ni­ka obsłu­gu­je widok (view). Sterowanie apli­ka­cją obsłu­gu­je kon­tro­ler (con­trol­ler). Logika biz­ne­so­wa zawar­ta jest w mode­lu (model). Ta sepa­ra­cja poma­ga zarzą­dzać zło­żo­no­ścią opro­gra­mo­wa­nia pod­czas jego two­rze­nia, ponie­waż poma­ga sku­pić się w danym momen­cie na jed­nym tyl­ko aspek­cie pro­ble­mu. (źr. MSDN MVC Overwiew)

Inny przy­kład podej­ścia do otwar­cia się:

IFS Open Information Architecture

Tu mamy coś w rodza­ju fasa­dy ([[wzo­rzec pro­jek­to­wy fasa­da]]) dla IFS Application (mate­ria­ły z publicz­nej stro­ny WWW), któ­re­go nowa wer­sja to już nie śro­do­wi­sko pro­ce­dur w Oracle DBMS a ser­wer apli­ka­cyj­ny Java J2EE (cie­ka­we ilu pro­gra­mi­stów Java mają na eta­tach dostaw­cy IFS’a). Zapewne powyż­sze to nie jedy­ne przy­kła­dy tego rodza­ju roz­wią­zań ERP na ryn­ku (fir­my chcą­ce uzu­peł­nić ten arty­kuł mogą mi prze­słać sto­sow­ne materiały).

Tak więc da się, trze­ba nie tyl­ko chcieć ale i potra­fić. Tu mała łyż­ka dzieg­ciu do gar­nusz­ka inte­gra­to­rów i dostaw­ców ERP: naj­czę­ściej nie potra­fią i mam wra­że­nie, że nie chcą bo, jak już w poprzed­nim arty­ku­le pisa­łem, nie jest to w ich inte­re­sie.

Model biz­ne­so­wy dostaw­ców goto­we­go opro­gra­mo­wa­nia to w więk­szo­ści przy­pad­ków brak kosz­tów two­rze­nia wła­sne­go pro­duk­tu i jego roz­wo­ju i budo­wa­nie mar­ży na cudzym pro­duk­cie. Oferowany jest cudzy pro­dukt wraz usłu­gą jego wdro­że­nia. Firma taka sta­no­wi kanał sprze­da­ży pro­du­cen­ta tego opro­gra­mo­wa­nia. Problem w tym, że od pew­ne­go cza­su rynek się zmie­nia: goto­we pro­duk­ty bez mody­fi­ka­cji nie mają tu (zarzą­dza­nie) racji bytu a mam wra­że­nie, że dostaw­cy ERP sta­ra­ją się za wszel­ka cenę uni­kać dosto­so­wań. Dlaczego? Bo ich model biz­ne­so­wy wła­snie w więk­szo­ści przy­pad­ków nie prze­wi­du­je utrzy­my­wa­nia bar­dzo kosz­tow­ne­go zespo­łu ana­li­ty­ków, pro­jek­tan­tów i programistów.

Czy mam rację? Przejrzałem co nie­co ogło­szeń o pra­ce dostaw­ców ERP, z tego co zebra­łem skom­pi­lo­wa­łem naj­czę­ściej powta­rza­ją­ce się oczekiwania:

Konsultant sys­te­mów ERP
Osoba będzie człon­kiem zespo­łu bio­rą­ce­go udział w pro­ce­sie wdra­ża­nia sys­te­mu ERP (ana­li­za, kon­fi­gu­ra­cja, szko­le­nia) oraz zapew­nia­ją­ce­go bie­żą­cą obsłu­gę i ser­wis ist­nie­ją­cych wdrożeń.
Opis sta­no­wi­ska pracy
  • współ­pra­ca z klien­tem oraz doradz­two merytoryczne
  • udział w ana­li­zach wdrożeniowych
  • zaawan­so­wa­ne wspar­cie dla obec­nych klien­tów systemów
  • udział we wdra­ża­niu systemów
  • prze­pro­wa­dza­nie pre­zen­ta­cji pro­duk­tów u klienta
  • pro­wa­dze­nie szko­le­nia dla klientów
  • wspar­cie użyt­kow­ni­ków systemu
  • pro­wa­dze­nie doku­men­ta­cji technicznej,
  • zarzą­dza­nie zmia­na­mi w systemie,
  • szko­le­nie koń­co­wych użytkowników,
Oczekujemy:
  • 2 – 3 let­nie­go doświad­cze­nia we wdro­że­niach sys­te­mów kla­sy ERP
  • zdol­no­ści ana­li­tycz­ne­go myślenia
  • umie­jęt­no­ści roz­wią­zy­wa­nia problemów
  • doświad­cze­nie we wdra­ża­niu systemów
  • ogól­na orien­ta­cja w pro­ce­sach biz­ne­so­wych i chęć pogłę­bia­nia tej wiedzy,
  • zna­jo­mość meto­dy­ki zarzą­dza­nia pro­jek­ta­mi wdrożeniowymi
  • zna­jo­mo­ści SQL

To ostat­nie (SQL) poja­wia się od cza­su do cza­su, to kom­pe­ten­cja wyma­ga­na do two­rze­nia nowych rapor­tów w sys­te­mie. Gdzie tu jest inży­nie­ria opro­gra­mo­wa­nia? Czy w pań­stwa wdro­że­niach poza kon­sul­tan­ta­mi bra­li udział ana­li­ty­cy pro­jek­tan­ci i pro­gra­mi­ści czy tyl­ko kon­sul­tan­ci wpa­da­ją­cy po to by pozmie­niać coś w sys­te­mie (powo­du­jąc nie raz uszko­dze­nia w innych jego częściach)?

Tak więc co mogę pora­dzić? Bardzo dokład­ne przy­glą­da­nie się roz­dzia­łom ofer­ty pod tytu­łem Dostosowanie sys­te­mu, Koncepcja wdro­że­nia oraz ile ocze­ki­wa­nych przez Państwa funk­cjo­nal­no­ści to te, któ­rych sys­tem w swej wer­sji stan­dar­do­wej nie ofe­ru­je. Powinny one być po dokład­nej ana­li­zie, zapro­jek­to­wa­ne i zaimplementowane.

Jeżeli Konsultanci zaczy­na­ją nego­cjo­wać rezy­gna­cję z czę­ści ocze­ki­wań lub ofe­ru­ją coś podob­ne­go w sys­te­mie, to pierw­szy sygnał, że powi­nien ktoś im zacząć patrzeć na ręce, i nie mam tu na myśli ich przełożonego.

Na zakoń­cze­nie list jed­ne­go z moich klien­tów, nazwał bym to typo­wym problemem:

Planujemy wdro­że­nie nowe­go opro­gra­mo­wa­nia, chce­my tym razem unik­nąć pre­sji ze stro­ny dostaw­cy opro­gra­mo­wa­nia. Poprzednim razem dostaw­ca opro­gra­mo­wa­nia uprasz­czał sobie pra­cę, już na eta­pie ana­li­zy, któ­rą wyko­ny­wał sam. Analiza wyma­gań pole­ga­ła na wywia­dach i warsz­ta­tach gru­po­wych, skoń­czy­ła się zwy­kłym opi­sem, tabel­ka­mi i kil­ko­ma nie­czy­tel­ny­mi sche­ma­ta­mi. Podczas ana­li­zy i wdro­że­nia sta­le wma­wia­no nam, że ​„tego nie moż­na”, ​„to nale­ży upro­ścić” albo ​„tak się nie robi” my zaś nie potra­fi­li­śmy tego oce­nić. Wiele naszych potrzeb odkry­wa­li­śmy dopie­ro pod­czas insta­la­cji kolej­nych pro­to­ty­pów, zaś dostaw­ca uni­kał wpro­wa­dza­nia zmian i obie­ca­nych dosto­so­wań. Dostaliśmy w efek­cie nie­przy­dat­ne i nie­zgod­ne z biz­ne­so­wy­mi potrze­ba­mi opro­gra­mo­wa­nie. Czy może nam Pan tym razem pomóc?

P.S.

Nie jestem w żaden spo­sób zwią­za­ny z dostaw­ca­mi pro­duk­tów wymie­nio­ny­mi w arty­ku­le. Ich nazwy zosta­ły wska­za­ne wyłącz­nie z sza­cun­ku dla praw autor­skich cyto­wa­nych treści.

Diagram klas ? czyli ?reinżynieria? analizy biznesowej c.d. model dziedziny

5 komentarzy

Przyszła w koń­cu pora na model dzie­dzi­ny sys­te­mu i model sekwen­cji dla przy­pad­ków uży­cia. Wspomnę tak­że o wyma­ga­niach nie­funk­cjo­nal­nych? W poprzed­nim arty­ku­le: Diagram klas ? czy­li ?rein­ży­nie­ria? ana­li­zy biz­ne­so­wej c.d. Przypadki uży­cia i gra­ni­ce sys­te­mu opi­sa­łem pro­ces do powsta­nia opi­su przy­pad­ków uży­cia. Mamy za sobą pod­sta­wo­wą pra­cę z dzie­dzi­ny jaką jest [[ana­li­za sys­te­mo­wa]]. Postawiliśmy pro­blem do roz­wią­za­nia: jakie opro­gra­mo­wa­nie powin­no powstać. Pod poję­ciem jakie nale­ży rozu­mieć: co powin­no ono robić. Opracowano model, prze­te­sto­wa­no go. Oceniono dwa warian­ty (w dużym skró­cie ;)), w dru­gim warian­cie obsłu­ga płat­no­ści zosta­ła zle­co­na part­ne­ro­wi ([[out­so­ur­cing]]) i pod­ję­to racjo­nal­ną decy­zje o wybo­rze tego wariantu.

Po tej decy­zji mamy zamknię­ty zakres wyma­gań: sys­tem ma reje­stro­wać zamó­wie­nia i pozwa­lać na natych­mia­sto­we doko­na­nie płat­no­ści. Wiemy tak­że, że nasz sys­tem jest czę­ścią więk­szej cało­ści. Outsourcing to decy­zja hipo­te­tycz­ne­go spon­so­ra pro­jek­tu na bazie otrzy­ma­nych infor­ma­cji. Koniec ana­li­zy biznesowej.

Pora iść dalej. Tym razem pro­blem brzmi: kto i w jakiej tech­no­lo­gii ma wyko­nać to opro­gra­mo­wa­nie. Znowu przy­da­ły by się warian­ty czy­li róż­ne ofer­ty wyko­na­nia tego opro­gra­mo­wa­nia. Czego nam bra­ku­je by ofer­ty były porów­ny­wal­ne? Modelu tego co nale­ży wyko­nać! Czy moż­na jako ele­ment takie­go zapy­ta­nia dać model przy­pad­ków uży­cia? Z jed­nej stro­ny moż­na powie­dzieć, że owszem. W koń­cu mamy dokład­ny opis tego, jaki­mi cecha­mi (funk­cjo­nal­no­ści) ma się cha­rak­te­ry­zo­wać to co otrzy­ma­my. I robi tak więk­szość firm. Gdzie widzę kło­pot? Zapewne część czy­tel­ni­ków zauwa­ży­ła już, że pomi­ną­łem wyma­ga­nia poza-funkcjonalne.

Dygresja budowlana – pouczająca przygoda

Wyobraźmy sobie, że chce­my zle­cić budo­wę domu. Jego funk­cjo­nal­no­ści to mię­dzy inny­mi: oddziel­ne miej­sca do spa­nia oraz czy­ta­nia i oglą­da­nia tele­wi­zji (tak zwa­ny salon). Kuchnia złą­czo­na z salo­nem. Łazienka na każ­dym pię­trze. Wejście z zewnątrz do salo­nu poprzez mały przed­po­kój. Garaż połą­czo­ny z przed­po­ko­jem. I jesz­cze wie­le innych. Wymagania poza-funk­cjo­nal­ne, tych może być ogrom! Dom ma być ład­ny, nie może być podob­ny do domu sąsia­da, musi speł­niać wyma­ga­nia pra­wa budow­la­ne­go, kolo­ry­sty­ka dachu powin­na być sko­re­lo­wa­na z ele­wa­cją, bie­żą­ce kosz­ty ogrze­wa­nia powin­ny być moż­li­wie jak naj­niż­sze, dom powi­nien dać się w przy­szło­ści łatwo roz­bu­do­wać o dwa nowe pomiesz­cze­nia. Dom powi­nien być przy­go­to­wa­ny do poten­cjal­nej insta­la­cji kom­pu­te­ra w każ­dym poko­ju. Powinno być moż­li­we zain­sta­lo­wa­nie kli­ma­ty­za­cji w cią­gu trzech lat od zakoń­cze­nia inwestycji.

Taki doku­ment może mieć dzie­siąt­ki stron, wery­fi­ka­cja jego tre­ści (spój­ność, tech­nicz­na nie­sprzecz­ność, inne) może być trud­na. Opracowanie go w gro­nie np. czte­ro­oso­bo­wej rodzi­ny będzie wyzwa­niem już tyl­ko w kate­go­riach nego­cja­cji ;). Żeby zabez­pie­czyć się przed ​„inter­pre­ta­cją” wyko­naw­cy doku­ment będzie obra­stał w szcze­gó­ły, ale takie o któ­rych pomy­ślą auto­rzy doku­men­tu: rodzi­na. Jakie mają w tym doświad­cze­nie? Większość tych ocze­ki­wań to wła­snie poza funk­cjo­nal­ne życzenia!.

Jak unik­nąć tej bene­dyk­tyń­skiej pra­cy, któ­rej ryzy­ko rośnie wraz z roz­ro­stem doku­men­tu? Idziemy do archi­tek­ta. Nasza rodzi­na idzie do archi­tek­ta, ten na bazie powyż­szych opo­wie­ści dopro­wa­dza do jakiejś kon­cep­cji roz­wią­za­nia (pro­jekt wstęp­ny, kon­cep­cyj­ny). W momen­tach spo­ru peł­ni role media­to­ra (łazien­ka ma być przy salo­nie czy przy poko­ju dzie­ci), poka­zu­je na mode­lu (pro­jekt kon­cep­cyj­ny, któ­ry ewo­lu­uje w trak­cie takiej roz­mo­wy) wady i zale­ty obu roz­wią­zań, pozwa­la rodzi­nie pod­jąć świa­do­mą decy­zje. Zaletą wizy­ty u archi­tek­ta, zanim zapy­ta­my jakie­go­kol­wiek deve­lo­pe­ra, jest to, że archi­tekt jest wol­ny od jakich­kol­wiek uprze­dzeń czy przy­zwy­cza­jeń. W każ­dej dzie­dzi­nie inży­nie­rii wyko­naw­cy są wyspe­cja­li­zo­wa­ni, jeśli damy im wybór, będą sto­so­wa­li tech­no­lo­gie naj­mniej ryzy­kow­ne dla sie­bie (naj­le­piej pozna­ne) a nie opty­mal­ne dla inwe­sto­ra i to jest oczy­wi­ste.

Dlatego war­to naj­pierw iść do archi­tek­ta, ten nie­ska­żo­ny tech­no­lo­gia­mi (bo nie ma w tym żad­ne­go inte­re­su), opra­cu­je nam pro­jekt funk­cjo­nal­ny, ale zawie­ra­ją­cy pew­ne szcze­gó­ły roz­wią­zań (np. zabro­ni budo­wy beto­no­wej ścia­ny w miej­scu gdzie my ocze­ku­je­my przy­szłej roz­bu­do­wy). Popatrzymy na coś, co potra­fi­my szyb­ko oce­nić nie tyl­ko od stro­ny wyma­gań funk­cjo­nal­nych (musz­la pod pół­ką speł­nia sta­wia­ne jej wyma­ga­nia ale czy jest to wygod­ne?) Na pro­jek­cie od razu wychwy­ci­my, cze­go w tek­ście opi­su raczej nigdy: ele­men­ty este­ty­ki, wygo­dy, pod­ję­te kom­pro­mi­sy będą dla wszyst­kich zro­zu­mia­łe i nie będą w przy­szło­ści podważane.

Diagram klas czy model dziedziny – co ma powstać?

(pro­gra­mi­ści mogą to pominąć)

Otóż [[dia­gram klas]] ([[UML]]) to narzę­dzie podob­ne do rysun­ku tech­nicz­ne­go. Ważne jest to co on przed­sta­wia i to nale­ży naj­pierw zde­fi­nio­wać (dopó­ki nie wiem czy mam napi­sać: książ­kę czy roz­dział pod­ręcz­ni­ka, nie wiem co mam w tym języ­ku wyra­zić). Tak więc coś nale­ży zało­żyć. Podstawowym zało­że­niem jakie tu przyj­mę jest: nie two­rzy­my opro­gra­mo­wa­nia od zera. A wiec od cze­go? Wiele firm pro­gra­mi­stycz­nych uży­wa goto­wych szkie­le­tów opro­gra­mo­wa­nia, tak zwa­nych [[framework]]ów. Są to goto­we, naj­czę­ściej dzie­dzi­no­we (adre­so­wa­ne dla kon­kret­nej dzie­dzi­ny zasto­so­wań) biblio­te­ki pod­pro­gra­mów (klas w tech­no­lo­giach obiektowych).

Obejmują zazwy­czaj typowe,uniwersalne funk­cjo­nal­no­ści takie jak logo­wa­nie, wyświe­tla­nie tre­ści na ekra­nie, zapis do bazy danych (a tak na praw­dę utrwa­la­nie, bo baza danych to nie jedy­ny spo­sób) , ste­ro­wa­nie zacho­wa­niem się apli­ka­cji, ele­men­ty bez­pie­czeń­stwa i wie­le innych. Funkcjonalności więk­szo­ści biz­ne­so­wych apli­ka­cji moż­na podzie­lić na trzy gru­py: ste­ro­wa­nie pro­gra­mem, obsłu­ga inter­fej­su użyt­kow­ni­ka oraz funk­cjo­nal­no­ści spe­cy­ficz­ne dla dzie­dzi­ny (miej­sca) zasto­so­wa­nia. Mamy więc dzie­dzi­nę pro­ble­mu, inter­fejs użyt­kow­ni­ka i ste­ro­wa­nie cało­ścią. Innymi sło­wy mamy: Model, View (wido­ki), Controller (ste­ro­wa­nie) czy­li naj­po­pu­lar­niej­szy obiek­to­wy wzo­rzec pro­jek­to­wy apli­ka­cji o wdzięcz­nej nazwie [[MVC]].

Wniosek z tego taki, że jeśli zało­ży­my, że taki szkie­let zosta­nie uży­ty (a może­my to zapi­sać w wyma­ga­niach poza-funk­cjo­nal­nych dla wyko­naw­cy) to pozo­sta­je po zakoń­czo­nej ana­li­zie biz­ne­so­wej doko­nać ana­li­zy obiek­to­wej i zapro­jek­to­wać [[model dzie­dzi­ny sys­te­mu]]. Narzędziem do jego poka­za­nia jest wła­śnie dia­gram klas nota­cji UML.

Model dziedziny systemu Zamówienia

Tak więc wszyst­ko jasne 🙂 wiec do robo­ty. Pierwszy etap to opra­co­wa­nie listy obiek­tów biz­ne­so­wych. Tu wkra­cza kolej­na meto­da, któ­ra sto­su­ję: obiek­ty dzie­li­my na narzę­dzia i przed­mio­ty prze­twa­rza­ne z pomo­cą tych narzę­dzi, pamię­ta­my, że tego wszyst­kie­go ktoś uży­wa: nasz aktor. Prosty przy­kład: Do wysta­wie­nia fak­tu­ry potrzeb­ne są: for­mu­larz fak­tu­ry (oczy­wi­ste) i fak­tu­rzy­sta (ktoś musi wie­dzieć co nale­ży zro­bić). Pierwszy sto­pień inno­wa­cji: kal­ku­la­tor dla fak­tu­rzy­sty. Kolejny sto­pień to elek­tro­nicz­ny for­mu­larz. Obiekty biz­ne­so­we: wzór for­mu­la­rza fak­tu­ry, kal­ku­la­tor, fak­tu­rzy­sta oraz oczy­wi­ście kuwet­ka na wysta­wio­ne fak­tu­ry. Dlaczego tak?

Kolejna meto­da ana­li­zy i pro­jek­to­wa­nia powią­za­na z wzor­cem MVC: [[Domain Driven Design]] (pro­jek­to­wa­nie opro­gra­mo­wa­nia bazu­ją­ce na mode­lu dzie­dzi­ny sys­te­mu) czy­li DDD. O co tu cho­dzi? Ogólnie o to by pro­jek­to­wać opro­gra­mo­wa­nie dość wier­nie symu­lu­jąc (a raczej odwzo­ro­wu­jąc) pozna­ną rze­czy­wi­stość. Dlaczego? Bo osią­ga­my bar­dzo waż­ną korzyść: nawet jeże­li nie uda nam się odkryć sen­su ist­nie­nia jakie­goś obiek­tu, mimo wszyst­ko mode­lu­je­my go bez uprosz­czeń, dzię­ki temu w przy­szło­ści, roz­wi­ja­jąc sys­tem, nie nadzie­je­my się na pro­blem wywo­ła­ny takim uprosz­cze­niem gdyż takie począt­ko­we uprosz­cze­nie sta­je się nie raz poważ­nym ogra­ni­cze­niem. Druga zale­ta: model taki jest rela­tyw­nie łatwiej­szy do per­cep­cji niż model z uprosz­cze­nia­mi, w szcze­gól­no­ści total­nie nie­straw­ny dla zwy­kłych ludzi (czy­ta: nie­we­ry­fi­ko­wal­ny przez zama­wia­ją­ce­go) [[model rela­cyj­ny w trze­ciej posta­ci nor­mal­nej]]. Tu bar­dzo prze­pra­szam czy­tel­ni­ków biz­ne­so­wych, że uży­łem nie­zro­zu­mia­łych zapew­ne dla nich pojęć, ale to wła­śnie poka­zu­je, że na tym eta­pie zama­wia­ją­cy tra­ci kon­takt (zro­zu­mie­nie) z wyko­naw­ca tego co sam zamó­wił zamawiający.

Z mode­lu pro­ce­su dowia­du­je­my się, że nastę­pu­ją­ce obiek­ty bio­rą udział w reali­za­cji potrzeb­nych nam funk­cjo­nal­no­ści: Formularz Zamówienia i koniec! Na pew­no? Nie 🙂 bo chce­my by jed­nak by był to auto­ma­tycz­ny sys­tem inter­ne­to­wy, wiec potrzeb­ny jest Zarządca. On wie: jak przyj­mo­wać Zamówienia oraz skąd brać dane i gdzie je wysy­łać. Klient (zama­wia­ją­cy) jest tu akto­rem i nie jest on abso­lut­nie obiek­tem biz­ne­so­wym do imple­men­ta­cji. Mamy więc dwa obiek­ty biz­ne­so­we: Zarządca i FormularzZamówienia. Do tego mamy inter­fej­sy dla ERP i do Płatności. A gdzie baza danych? Nie ma! Co robić? Wiem! Kuwetka :), potrzeb­na mi kuwet­ka. Baza danych to dla biz­ne­su sło­wo obrzy­dli­we i nie uży­wa­my go. Mamy więc: Zarządca, Kuwetka, FormularzZamówienia, .… aaaaaaaa, a same Zamówienia? :). Komplet:

  1. FormularzZamówienia
  2. GeneratorDruczków
  3. Kuwetka
  4. Zarządca
  5. Zamówienia

Nie zapo­mi­na­my, że mamy Framework i inter­fej­sy (ERP i Płatności). Pojawił się jesz­cze GeneratorDruczków. Skąd się wziął? Kolejna meto­da pro­jek­to­wa­nia: [[Role, odpo­wie­dzial­ność, współ­pra­ca]]. Otóż, war­to Zarządcę zwol­nić z obo­wiąz­ku posia­da­nia wie­dzy o aktu­al­nych wzo­rach doku­men­tów. Te wie­dzę o aktu­al­nie sto­so­wa­nych wzo­rach doku­men­tów (i rolę) posia­da GeneratorDruczków. I mógł by ktoś powie­dzieć, że nie­po­trzeb­nie kom­pli­ku­je pro­gram. Owszem, skom­pli­ko­wał się. Jeśli jed­nak w pro­gra­mie poja­wią się kie­dyś nowe funk­cjo­nal­no­ści, inni Zarządcy, wszy­scy będą pobie­ra­li drucz­ki z jed­ne­go miej­sca bez zasta­na­wia­nia się czy są wła­ści­we bo mamy tyl­ko jed­no ich źró­dło, któ­re odpo­wia­da za to by zawsze były właściwe.

Jak wyglą­da dia­gram klas:

Diagram klas, model dziedziny systemu

Tak więc co my tu mamy, po kolei: Klient (nasz aktor) kon­tak­tu­je się wyłącz­nie z Zarządcą, któ­ry go obsłu­gu­je. Zarządca korzy­sta z usług GeneratoraDruczków, Kuwetki, zewnętrz­nych sys­te­mów poprzez inter­fej­sy. Koniec. Co dalej? Ano wypa­da­ło by poka­zać jak Zarządca, zda­niem pro­jek­tan­ta (:)) reali­zu­je nasz przy­pa­dek uży­cia. Na potrze­by usys­te­ma­ty­zo­wa­nia pro­jek­tu przy­to­cze jesz­cze raz sce­na­riusz w fir­mie trosz­kę sformalizowanej:

uc_scenariusz

Taka postać sce­na­riu­sza (dia­log) pozwa­la upew­nić się, że zama­wia­ją­cy i pro­jek­tant myślą tak samo. Mały komen­tarz: Klient ma przed sobą Ekran Startowy i wybie­ra opcję (pole­ce­nie) Nowe Zamówienie. System pyta o NIP, Klient wpi­su­je NIP i potwier­dza. Możliwe jest nie wpi­sa­nie NIP. System wyświe­tla for­mat­kę nowe­go zamó­wie­nia. Formatka ma wypeł­nio­ne dane Zamawiającego lub nie, jeśli nie poda­no NIPu albo nie zna­le­zio­no go na liście kon­tra­hen­tów. Klient wpro­wa­dza dane poprzez zazna­cze­nie tego co chce zamó­wić, wpi­su­je ilo­ści itp. na koniec potwier­dza. System spraw­dza i wyświe­tla kom­plet­ne zmó­wie­nie. Klient zatwier­dza lub rezy­gnu­je (pomi­ną­łem, ewen­tu­al­ną edy­cję dla uprosz­cze­nia, jeże­li fir­ma ofe­ru­je tysią­ce pro­duk­tów tak­że będzie inaczej :)).

W tym momen­cie Klient ma jed­no lub wię­cej zamó­wień do opła­ce­nia, w kolej­nym przy­pad­ku uży­cia może zazna­czyć zamó­wie­nia do opła­ce­nia i wybrać opcję Inicjacja Płatności, System przy­go­tu­je nie­zbęd­ne dane i prze­ka­że ste­ro­wa­nie do Systemu obsłu­gi Płatności. Nie będzie tu tego opi­su, celem arty­ku­łu jest poka­za­nie meto­dy a nie wyko­na­nie kom­plet­ne­go projektu.

Powyższy sce­na­riusz posłu­ży teraz do prze­te­sto­wa­nia i uzu­peł­nie­nia mode­lu dzie­dzi­ny i uzu­peł­nie­nia go (ten etap nazy­wa­ny jest czę­sto [[pro­of-of-con­cept]]). Narzędziem do testo­wa­nia będzie dia­gram sekwencji:

[sin­gle­pic id=73 w=320 h=240 float=center]

Samo wyko­na­nie powyż­sze­go dia­gra­mu pozwa­la na spraw­dze­nie popraw­no­ści pomy­słu i jego logi­ki oraz od razu daje nam moż­li­wość wery­fi­ka­cji atry­bu­tów i ope­ra­cji. Po tym teście (opra­co­wa­nie tego dia­gra­mu jest testem kon­cep­cji) uzu­peł­nia­my model dzie­dzi­ny o atry­bu­ty i ope­ra­cje. Diagram klas to sta­tycz­ny opis, któ­ry sam z sie­bie nicze­go nie mówi o współ­pra­cy obiek­tów. Jego popraw­na inter­pre­ta­cja (nie licząc sys­te­mu pojęć) jest nie­moż­li­wa bez tego mode­lu dyna­mi­ki (dia­gram sekwen­cji to model dyna­mi­ki sys­te­mu). Zaryzykował bym nawet tezę, że sam dia­gram klas nie nie­sie pra­wie żad­nej infor­ma­cji wykonawcy.

Model dzie­dzi­ny wzbo­ga­cił się:

model-dziedziny_0

Podsumowanie

Przytoczę ponow­nie cyto­wa­ny dia­gram klas:

uml2_diagram_klas6_modelowaniewordpresscom

Powyższy dia­gram w moim mnie­ma­niu jest raczej pew­nym mode­lem poję­cio­wym. Bez kil­ku słów o meto­dy­ce pro­jek­to­wa­nia trud­no go w ogó­le oce­niać dla­te­go poka­za­łem swój dia­gram klas, i spo­sób w jaki powstał. Kluczowe różnice:

  1. W moim mode­lu typ płat­no­ści będzie atry­bu­tem Zamówienia
  2. Obiekt Zamówienie, poza zawar­to­ścią dru­ku zamó­wie­nia, obsłu­gu­je tak­że inne dodat­ko­we zada­nia (pamię­ta­nie o spo­so­bie płat­no­ści, przy­go­to­wa­nie seria­li­za­cji XML do ​„wsa­dze­nia” obiek­tu do ERP, może coś jeszcze…)
  3. Klient w ogó­le się nie poja­wia, chy­ba już wia­do­mo dlaczego…
  4. Pozycja zamó­wie­nia zosta­ła ​„ukry­ta” w zamó­wie­niu, zależ­nie od kon­cep­cji były by to ele­men­ty agre­ga­tu (pozy­cje­za­mó­wie­nia u mnie były by w rela­cji kom­po­zy­cji do obiek­tu bazo­we­go DrukZamówienia), nie ma kla­sy Produkt (maga­zyn), jest to obiekt za któ­ry odpo­wia­da sys­tem ERP.
  5. U mnie poja­wia się Kuwetka, obiekt odpo­wie­dzial­ny za skła­do­wa­nie Zamówień, pyta­nia o kon­kret­ne Zamówienie, ostat­nie zamó­wie­nie, zesta­wie­nie zamó­wień za okres to poten­cjal­ne ope­ra­cje obiek­tu Kuwetka.
  6. Pojawia się tak­że Zarządca, obiekt odpo­wie­dzial­ny za obsłu­gę przy­pad­ku uży­cia (byc może tak­że innych). Na dia­gra­mie sekwen­cji poja­wi­ła się kla­sa System obsługi…jest to abs­trak­cja ele­men­tu View wzor­ca MVC.

Powyższy pro­jekt jest bar­dzo uprosz­czo­ny i na pew­no ma wie­le wad, kil­ka ite­ra­cji pro­jek­to­wa­nia i testów war­to by jesz­cze prze­pro­wa­dzić. Celem moim jed­nak było poka­za­nie samej meto­dy ana­li­zy i pro­jek­to­wa­nia, tego do cze­go moż­na użyć nota­cji UML. Pokazać, że moż­na zapro­jek­to­wać logi­kę opro­gra­mo­wa­nia i ją prze­te­sto­wać nie pisząc nawet linij­ki kodu.

Na koniec chcia­łem poka­zać, że w pro­jek­tach dedy­ko­wa­nych, jeże­li jest nawet cień ryzy­ka, że wyko­naw­ca będzie błą­dził reali­zu­jąc nasz pro­jekt (nie ocze­kuj­my od pro­gra­mi­stów, że będą zna­li i rozu­mie­li naszą fir­mę, nie taka jest ich rola) war­to wyko­nać taki wła­śnie pro­jekt. Po pierw­sze prze­te­stu­je­my nasze życze­nia, po dru­gie powsta­nie mate­riał, na bazie któ­re­go kil­ku wyko­naw­ców doko­na wyce­ny z nie­wiel­kim błę­dem i bez dużych narzu­tów na nie­spo­dzian­ki. Czy takie pro­jek­ty robią deve­lo­pe­rzy? Ich o to pytaj­cie. Czy ma to sens? Testowanie dia­gra­mów jest co naj­mniej o rząd wiel­ko­ści tań­sze niż testo­wa­nie pro­to­ty­pów przez programistów.

Kto powi­nien opra­co­wać taki pro­jekt? Osobiście uwa­żam, że nie powi­nien to być wyko­naw­ca pro­jek­tu. Powodem jest po pierw­sze to, o czym wspo­mnia­łem: każ­dy się spe­cja­li­zu­je w jakiejś jed­nej tech­no­lo­gii. Po dru­gie w przy­pad­ku jakich­kol­wiek pro­ble­mów Zamawiający, jako nie­spe­cja­li­sta, nie ma żad­nej moż­li­wo­ści mery­to­rycz­nej oce­ny wyko­naw­cy, nawet gdy­by był szko­dli­wy dla zama­wia­ją­ce­go. Nie twier­dzę, że wszy­scy deve­lo­pe­rzy to nie­kom­pe­tent­ni nacią­ga­cze ale też nie dam gło­wy, że takich nie ma. Sugeruję naśla­do­wa­nie ryn­ku budow­la­ne­go: zarzą­dza­nie ryzy­kiem czy­li oddzie­le­nie pro­jek­to­wa­nia od wykonania.

Developer tak­że odno­si tu pew­ną korzyść: jest zwol­nio­ny z odpo­wie­dzial­no­ści i posą­dza­nia go o kom­bi­no­wa­nie, zysku­je dodat­ko­wo media­to­ra pomię­dzy sobą i zama­wia­ją­cym. Minus jest taki, że wyna­gro­dze­nie za ana­li­zę i pro­jekt nie wpły­nie do jego kie­sze­ni ale cóż… to koszt kom­for­tu pra­cy ale z regu­ły nie prze­kra­cza on 10 – 20% budże­tu na powsta­nie oprogramowania.

Podsumowanie drugie

Czy to ma sens w przy­pad­ku goto­wych ERP? Moim zdaniem:

  1. Ingerencja (tak zwa­na kasto­mi­za­cja) w goto­we opro­gra­mo­wa­nie ERP koń­czy się bar­dzo czę­sto desta­bi­li­za­cją pier­wot­nie dobre­go oprogramowania.
  2. Jeżeli sys­tem ERP jest zamknię­ta bry­łą (z regu­ły świad­czy o tym fakt pra­cy na rela­cyj­nej, znor­ma­li­zo­wa­nej bazie danych) nie war­to go kastro­mi­zo­wać bo to kosz­tow­ny i bar­dzo ryzy­kow­ny pro­ces, do tego pozba­wia­my się moż­li­wo­ści pro­ste­go jego upgrade’owania.

Brakujące w fir­mie funk­cjo­nal­no­ści lepiej two­rzyć osob­no, jako dedy­ko­wa­ne pro­jek­ty bo to po pierw­sze chro­ni inwe­sty­cję w ERP, po dru­gie z regu­ły kosz­tu­je znacz­nie mniej i znacz­nie szyb­ciej jest goto­we do uży­cia (stwo­rze­nie małe­go opro­gra­mo­wa­nie jest dużo prost­sze niż mody­fi­ka­cja duże­go). Po dru­gie poja­wia­ją się już sys­te­my ERP mają­ce struk­tu­rę wła­snie szkie­le­tu opar­te­go na wzor­cu MVC i zapro­jek­to­wa­nie nowej funk­cjo­nal­no­ści pole­ga na ana­li­zie i pro­jek­to­wa­niu takim jak wyżej opi­sa­ne, z tą róż­ni­cą że imple­men­ta­cja ma miej­sce w śro­do­wi­sku tego ERP a nie w śro­do­wi­sku odręb­ne­go narzę­dzia pro­gra­mi­stycz­ne­go. Tak więc, paradoksalnie,

powyż­sze ana­li­za i pro­jek­to­wa­nie powin­ny być zawsze pierw­szym eta­pem pro­jek­tu pro­gra­mi­stycz­ne­go nie­za­leż­nie od tego czy ma powstać nowe opro­gra­mo­wa­nie czy tyl­ko nowe funk­cjo­nal­no­ści do ist­nie­ją­ce­go.

A gdzie się podzia­ły wyma­ga­nia pozafunkcjonalne?

Generalnie w mojej meto­dy­ce są one ogra­ni­cze­nia­mi doku­men­to­wa­ny­mi dla każ­de­go przy­pad­ku uży­cia indy­wi­du­al­nie. Powstaje repo­zy­to­rium ogra­ni­czeń i mapo­wa­nie ich na przy­pad­ki uży­cia. Bardzo restryk­cyj­ne ogra­ni­cze­nia (np. wyso­ka dostęp­ność) mogą być wydzie­lo­ne z ich przy­pad­ka­mi uży­cia do osob­ne­go pod­sys­te­mu i imple­men­to­wa­ne nawet na osob­nej plat­for­mie jeśli taka będzie potrze­ba zwią­za­na z ren­tow­no­ścią. To jed­nak temat na osob­ny artykuł :).

Konkluzja biz­ne­so­wa: Nowy sys­tem infor­ma­tycz­ny to inte­rak­cja fir­my i opro­gra­mo­wa­nia, musi być trak­to­wa­na łącz­nie jako jeden sys­tem zło­żo­ny z ludzi i narzę­dzi w ich oto­cze­niu. Dlatego decy­zja biz­ne­so­wa o out­so­ur­cin­gu płat­no­ści i inte­gra­cji z ERP powin­na być moim zda­niem inte­gral­ną czę­ścią i pro­duk­tem ana­li­zy biz­ne­so­wej w pro­jek­cie informatycznym.