Zarządzanie zmianami biznesowymi

Na blo­gu prof. Andrzeja Sobczaka uka­zał się kolej­ny cie­ka­wy arty­kuł, w któ­rym auto­ra zauwa­ża, że:

Presja na uzy­ski­wa­nie jak naj­lep­szych wyni­ków w jak naj­krót­szym cza­sie powo­du­je bar­dzo duży nacisk na tzw. Time 2 Market (T2M) ? czy­li jak naj­szyb­sze wpro­wa­dza­nie pro­duk­tu na rynek (biz­nes coraz czę­ściej godzi się, że będzie to pro­dukt nie do koń­ca prze­te­sto­wa­ny, dopra­co­wa­ny,? ? ale będą dzię­ki temu pierw­si na ryn­ku i wyprze­dzą w ten spo­sób kon­ku­ren­cję ? zgod­nie z zasa­dą ?kto nie ryzy­ku­je, ten nie pije szampana?).

Dążenie do skró­ce­nia T2M powo­du­je, że zmia­ny reali­zo­wa­ne w orga­ni­za­cjach (czy to biz­ne­so­we, czy też tech­no­lo­gicz­ne) mają cha­rak­ter nie­sko­or­dy­no­wa­ny, punk­to­wy, meto­dą ?na sznur­ki?. Skutkuje to tym, że reali­za­cja tych zmian pro­wa­dzi do upra­wie­nia reali­za­cji frag­men­tu pro­ce­su biz­ne­so­we­go, pozwa­la na wpro­wa­dze­nie nowe­go pro­duk­tu na rynek, dostar­cza nowej funk­cjo­nal­no­ści dla departamentu/linii biz­ne­so­wej. Ale orga­ni­za­cja roz­pa­try­wa­na jako całość tra­ci na tym. Po pierw­sze rosną kosz­ty utrzy­ma­nia tak wdro­żo­nych roz­wią­zań (czy to orga­ni­za­cyj­nych, czy też IT). Po dru­gie coraz wię­cej cza­su poświę­ca­ne jest na koordynację/uzgadnianie/wyjaśniania ele­men­tów, któ­re od same­go począt­ku powin­ny ?skła­dać się? w jed­ną całość. Wreszcie orga­ni­za­cja postrze­ga­na holi­stycz­nie zmniej­sza swo­ją ela­stycz­ność (rośnie jej entro­pia) (Źródło: Manifest nowe­go ładu zarzą­dza­nia zmia­na­mi biz­ne­so­wy­mi | Architektura Korporacyjna)

Myślę, że naci­ski na skra­ca­nie T2M to tyl­ko czyn­nik narzu­ca­ją­cy wyma­ga­nia. SJP mówi, że stra­te­gia to ?prze­my­śla­ny plan dzia­łań w jakiejś dzie­dzi­nie?. Czym jest więc archi­tek­tu­ra kor­po­ra­cyj­na (AK) dla stra­te­gii? A może czym powin­na być stra­te­gia dla AK? AK zawie­ra w sobie archi­tek­tu­rę apli­ka­cji, któ­re są jej ? AK- czę­ścią. Jeżeli uzna­je­my (jeże­li) pryn­cy­pia takie jak ?apli­ka­cja powin­na być zamknię­ta na zmia­ny i otwar­ta na roz­sze­rze­nia?, to dla­cze­go by nie uznać, że ?archi­tek­tu­ra kor­po­ra­cyj­na (tak­że) powin­na być zamknię­ta na zmia­ny i otwar­ta na roz­sze­rze­nia?? Wtedy stra­te­gia orga­ni­za­cji sta­no­wi­ła by rodzaj poli­ty­ki two­rze­nia i roz­sze­rza­nia AK. Oczekujemy zwin­no­ści od apli­ka­cji, ocze­kuj­my tez od AK?.

Czy to się da? Myślę, że tak. W koń­cu dowol­nie zło­żo­ny sys­tem IT moż­na spro­wa­dzić do rela­tyw­nie małej licz­by kom­po­nen­tów (to tyl­ko kwe­stia pozio­mu her­me­ty­za­cji szcze­gó­łów). Z dru­giej stro­ny podział sys­te­mu na odręb­ne apli­ka­cje jest sztucz­ny, wyni­ka wyłącz­nie z zakre­su pro­jek­tu ich dostaw­ców. To zna­czy, że poszcze­gól­ne kom­po­nen­ty moż­na podzie­lić na te wol­no-zmien­ne klu­czo­we, tak zwa­ne dome­no­we, kom­po­nen­ty obsłu­gu­ją­ce sce­na­riu­sze biz­ne­so­we oraz te obsłu­gu­ją­ce dia­log użyt­kow­ni­ka z sys­te­mem i ofe­ru­ją­ce użyt­kow­ni­kom usłu­gi apli­ka­cyj­ne (np. por­ta­le intra­ne­to­we). Szybkozmienny biz­nes nie raz wymu­si nowe usłu­gi, to czy będzie to zmia­na w ist­nie­ją­cym czy nowy kom­po­nent to poli­ty­ka budo­wy i zarzą­dza­nia zmia­ną AK, powin­na ona pomóc pod­jąć decy­zje czy będzie on zamiast wpro­wa­dza­nia kolej­nej (po co??) mody­fi­ka­cji, efe­me­ry­dą reali­zu­ją­cą okre­ślo­ną logi­kę biz­ne­so­wą w okre­ślo­nym, mają­cym począ­tek i koniec, okre­sie czasu.

Strategia orga­ni­za­cji to dłu­go ter­mi­no­we cele i poli­ty­ka ich reali­za­cji, kon­kret­ne rocz­ne czy kwar­tal­ne dzia­ła­nia to tak­ty­ki a nie stra­te­gia… Co więc robić? Przede wszyst­kim opi­sać stra­te­gię i poli­ty­kę jej reali­za­cji (stra­te­gia to plan ale poli­ty­ka to regu­ły dzia­ła­nia a nie opis dzia­łań). Polityka ta powin­na wyzna­czać tak­że spo­sób budo­wy AK, któ­ra musi pozwo­lić na reali­zo­wa­nie stra­te­gii. Mają poli­ty­kę, zbu­do­wać AK w zgo­dzie mię­dzy inny­mi z zasa­dą, że ?archi­tek­tu­ra kor­po­ra­cyj­na powin­na być zamknię­ta na zmia­ny i otwar­ta na rozszerzenia?.

Kim jest product owner?

Wczoraj pod­czas spo­tka­nia, mia­łem cie­ka­wą roz­mo­wę z przed­sta­wi­cie­la­mi jed­ne­go z pro­du­cen­tów sys­te­mów ERP. Okazało się, że mają bar­dzo podob­ne do moich doświad­cze­nia i wnio­ski: pod­czas wdro­że­nia sys­te­mu ERP potrzeb­ny im jest ktoś, jeden, kto zna i rozu­mie jak dzia­ła dana fir­ma, a nie set­ki stron doku­men­ta­cji czy ste­no­gra­my z dzie­siąt­ków godzin warsz­ta­tów z przy­szły­mi użyt­kow­ni­ka­mi. Do tego fir­ma ta – nabyw­ca sys­te­mu ERP – powin­na mieć, nie szcze­gó­ło­wo opi­sa­ne dzie­siąt­ki deta­licz­nie opi­sa­nych pro­ce­sów i ich warian­tów, pro­ce­dur czy set­ki i tysią­ce nie raz wyma­gań, a stra­te­gię i tak­ty­kę, z któ­rej wyni­ka (da się wyczy­tać) rola opro­gra­mo­wa­nia ERP w fir­mie: tak­ty­kę czy­li opis reali­za­cji stra­te­gii fir­my z pomo­cą pla­no­wa­ne­go do wdro­że­nia sys­te­mu ERP. Ta tak­ty­ka, to opis tego kie­dy i po co opro­gra­mo­wa­nie ma wspie­rać pra­cow­nikw orga­ni­za­cji. To, jak się to będzie odby­wa­ło w szcze­gó­łach, zosta­nie opra­co­wa­ne przez dostaw­cę (wyko­naw­cę) kon­kret­ne­go pro­duk­tu, to dostaw­ca goto­we­go opro­gra­mo­wa­nia opra­co­wu­je kon­cep­cję wdro­że­nia, na pod­sta­wie doku­men­tu opi­su­ją­ce­go tak­ty­kę uży­cia tego opro­gra­mo­wa­nia i wyma­ga­nia biz­ne­so­we (opro­gra­mo­wa­nie dedy­ko­wa­ne wyma­ga dodat­ko­wo zapro­jek­to­wa­nia i udo­ku­men­to­wa­nia logi­ki biz­ne­so­wej jaką ma ono realizować).

I co teraz? Teraz potrzeb­ne jest źró­dło spój­nej wie­dzy o orga­ni­za­cji, jej stra­te­gii i tak­ty­ce w któ­rą ma się wpa­so­wać opro­gra­mo­wa­nie ERP. Któż jest tym źró­dłem? [[Product owner]].

Pytane teraz brzmi: kim jest i człon­kiem czy­je­go zespo­łu jest (powi­nien być) pro­duct owner”? Tu zacy­tu­ję osta­ni aka­pit mojej cie­płej jesz­cze recen­zji książki:

…na ile wizja pro­duk­tu upraw­nia jej posia­da­cza do aktyw­ne­go kie­ro­wa­nia pro­jek­tem wraz z kie­row­ni­kiem pro­jek­tu (Scrum Master), ale to pozo­sta­wiam czy­tel­ni­kom i prak­ty­kom. Jedno moim zda­niem jest pew­ne: nie ma sen­su by zespół deve­lo­pe­ra kon­tak­to­wał się, z tabu­nem przy­szłych ?use­rów?, ma sens by dosta­wał spój­ną wie­dzę o tym co tak na praw­dę ma powstać.

Źródło: Agile Product Management with Scrum | Jarosław Żeliński IT-Consulting

Autor powyż­szej książ­ki nie daje wprost odpo­wie­dzi na to pyta­nie, jed­nak mil­czą­co zakła­da też, że to zespół dostaw­cy wal­czy” ze zja­wi­skiem i pro­duct owner jest człon­kiem tego zespo­łu, nie zmie­nia to fak­tu, że wyma­ga­na od nie­go wie­dza i zro­zu­mie­nie tego, do cze­go user będzie uży­wał opro­gra­mo­wa­nia, powin­na być taka jak opi­sa­łem wyżej.

Co usły­sza­łem po raz kolej­ny (podob­ne roz­mo­wy z dostaw­ca­mi opro­gra­mo­wa­nia nie raz już pro­wa­dzi­łem) od przed­sta­wi­cie­li dostaw­cy sys­te­mu ERP? Potrzebują bar­dzo zwię­złej i spój­nej doku­men­ta­cji (ale raczej 50-ciu stron niż setek, że nie wspo­mnę o kil­ku tysią­cach (tak – widy­wa­łem takie) i po stro­nie klien­ta (jed­nej) oso­by, któ­ra ten doku­ment zna, rozu­mie, ma dostęp do klu­czo­wych osób w orga­ni­za­cji. Najchętniej do auto­ra tego doku­men­tu… Dostawcy opro­gra­mo­wa­nia jak dosta­ją listę setek pozy­cji wyma­gań podzie­lo­nych w mało zro­zu­mia­ły spo­sób na funk­cjo­nal­ne i poza funk­cjo­nal­ne (i inne) raczej sobie z tych spe­cy­fi­ka­cji dwo­ru­ją niż cie­szą się z ich otrzy­ma­nia (pomi­jam, ze nie czy­ta­ją w cało­ści). Po co są więc robio­ne? Bo zama­wia­ją­cy postrze­ga swo­ją pra­cę przez pry­zmat jej zło­żo­no­ści, warian­to­wo­ści, nie patrzy z per­spek­ty­wy narzę­dzia a tym wła­śnie jest opro­gra­mo­wa­nie. To tak jak by cie­śla lub sto­larz opi­sał wyma­ga­nia na mło­tek cie­siel­ski w posta­ci setek stron user sto­ry” o tym jak, do cze­go i kie­dy używa(łby) młot­ka.. dla ana­li­ty­ka pro­jek­tan­ta taki opis (a kon­kret­nie jego ską­pa część) ma sens, dla kon­struk­to­ra – żad­ne­go, ten raczej ocze­ku­je rysun­ku tech­nicz­ne­go wykonawczego.

The role of Product Owner (Scott Ambler, Agile Modeling)
The role of Product Owner (Scott Ambler, Agile Modeling)

Powyższy dia­gram to poglą­do­wy model roli pro­duct owne­ra (PO) autor­stwa jed­ne­go z moich ulu­bio­nych zwin­nych ana­li­ty­ków”: Scott’a Amblera (Scott Ambler). Niewątpliwie moż­na dywa­go­wać czy PO to pra­cow­nik” dosa­tw­cy czy kupu­ją­ce­go ale tu chy­ba część wąt­pli­wo­ści roz­wie­ją sło­wa jed­ne­go z moich klien­tów, postrze­gam go jako jed­ne­go z lepiej zarzą­dza­ją­cych ryzy­kiem biz­ne­so­wym, zna­nych mi, pre­ze­sów firm: Panie Jarku nie wiem czy jest Pan lep­szym czy gor­szym spe­cja­li­stą od ludzi dostaw­cy, zatrud­ni­łem Pana bo prze­ło­żo­nym tam­tych jest Prezes tam­tej firmy”.

Where Do Product Owners Come From? The goods news is that the­re are seve­ral via­ble options for whe­re Product Owners may come from: Business ana­lyst. Although a tra­di­tio­nal busi­ness ana­lyst could fill the role of pro­duct owner, the­re is a risk that they will fall into the­ir old habits of com­mu­ni­ca­ting via docu­men­ta­tion. Keep in mind that what agi­le teams real­ly need are people with agi­le ana­ly­sis skills who are empo­we­red to make deci­sions. So, a bet­ter option is an empo­we­red agi­le busi­ness ana­lyst. (za The Product Owner Role: A Stakeholder Proxy for Agile Teams).

Tak więc nasu­wa się wnio­sek, że rolę PO powi­nien peł­nić ten czło­wiek, któ­ry wła­śnie skoń­czył ana­li­zę biz­ne­so­wą i napi­sał raport z niej. Raport, któ­ry zawie­ra spe­cy­fi­ka­cją wyma­gań (naj­le­piej w for­mie jak opi­sa­na powy­żej). W zasa­dzie nad­zór autor­ski nad reali­za­cją tak­ty­ki wdro­że­nia sys­te­mu ERP (opro­gra­mo­wa­nia w ogó­le) to nic inne­go jak bycie pro­duct owne­rem” w pro­jek­cie na eta­pie jego reali­za­cji a SCRUM fak­tycz­nie, na dzi­siej­sze cza­sy, wyda­je się być naj­lep­szą meto­dą zarzą­dza­nia taki­mi pro­jek­ta­mi a utrzy­my­wa­nie aktu­al­no­ści doku­men­tu ana­li­zy biz­ne­so­wej i wyma­gań w toku pro­jek­tu pro­wa­dzi do tego, że po zakoń­cze­niu pro­jek­tu mamy nie­chcą­cy” kom­plet­ną i aktu­al­ną doku­men­ta­cje sta­nu uzy­ska­ne­go w toku wdrożenia.

(książ­ki Scotta Amblera cze­ka­ją na recenzję ;))

Strategia krótkoterminowa

Ty razem krót­ko. Natchnął mnie arty­kuł kole­gi, tu frag­ment tego artykułu:

Przede wszyst­kim nie ist­nie­je coś takie­go jak ?stra­te­gia krót­ko­ter­mi­no­wa?. Otóż jest to kla­sycz­ny oksy­mo­ron ? ?prze­no­śne zesta­wie­nie pojęć o prze­ciw­staw­nym, wyklu­cza­ją­cym się wza­jem­nie zna­cze­niu, np. spie­szyć się powo­li, sucha woda; anty­lo­gia, epi­tet sprzeczny?[1]. […] Nie daj­my sobie robić wody z mózgu. Nie ist­nie­ją te wszyst­kie ?stra­te­gie? albo nie są stra­te­gia­mi. To jest opis spo­so­bu dzia­ła­nia, plan dzia­łań, któ­ry nie jest stra­te­gią. Przyrównując do woj­ny, nie są to stra­te­gie, tyl­ko tak­ty­ki pozwa­la­ją­ce na wygra­nie poszcze­gól­nych bitew. Nie powin­no się tego sto­so­wać nawet w odnie­sie­niu do poje­dyn­czej kam­pa­nii. To kam­pa­nia komu­ni­ka­cyj­na powin­na być pod­po­rząd­ko­wa­na stra­te­gii mar­ke­tin­go­wej. (źr. Strategia krót­ko­ter­mi­no­wa | Filozofia marketingu).

W tym miej­scu, tra­dy­cyj­nie, przy­ta­czam słow­ni­ko­we defi­ni­cje pojęć:

stra­te­gia ?prze­my­śla­ny plan dzia­łań w jakiejś dzie­dzi­nie? ?dział sztu­ki wojen­nej obej­mu­ją­cy przy­go­to­wa­nie i pro­wa­dze­nie woj­ny oraz poszcze­gól­nych jej kam­pa­nii i bitew? (Słownik języ­ka pol­skie­go).

tak­ty­ka ?spo­sób postę­po­wa­nia mają­cy dopro­wa­dzić do osią­gnię­cia celu? ?dzie­dzi­na sztu­ki wojen­nej obej­mu­ją­ca teo­rię i prak­ty­kę pro­wa­dze­nia wal­ki przez jed­nost­ki róż­nych rodza­jów wojsk? (Słownik języ­ka pol­skie­go).

Nie usu­wa­łem defi­ni­cji z dzie­dzi­ny woj­sko­wo­ści, bo te ter­mi­ny mają woj­sko­wy rodo­wód. Jak widać, jest pew­na róż­ni­ca mię­dzy stra­te­gią a tak­ty­ką. Tak więc woj­ny to raczej lata i ogól­ne zało­że­nia ich wygry­wa­nia – stra­te­gia ich pro­wa­dze­nia. Poszczególne bitwy są kon­se­kwen­cją zasto­so­wa­nej tak­ty­ki, to raczej tygo­dnie lub co naj­wy­żej mie­sią­ce. Patrząc więc teraz na te defi­ni­cje przez pry­zmat np. wie­dzy o II Wojnie Światowej, jaką mamy np. ze szko­ły pod­sta­wo­wej, widać, że zwrot stra­te­gia krót­ko­ter­mi­no­wa” brzmi podob­nie nie­mą­drze jak chwi­lo­wa woj­na światowa”.

Stosowanie okre­ślo­nych ter­mi­nów zgod­nie z ich wła­ści­wy­mi zna­cze­nia­mi ma głę­bo­ki sens. Rzecz w tym, by budo­wa­ny opis” (np. biz­nes plan, pro­spekt emi­syj­ny, kon­tekst pro­jek­tu IT), był nie tyl­ko powszech­nie zro­zu­mia­ły” ale o to by w ogó­le miał jakiś sens. Bo to, że ład­nie i mądrze brzmi” w kor­po­ra­cyj­nej doku­men­ta­cji to na dłuż­szą metę za mało.

Pojęcia te, stra­te­gia i tak­ty­ka, mają swo­je odzwier­cie­dle­nie tak­że w sfor­ma­li­zo­wa­nej for­mie w two­rze­niu mode­lu moty­wa­cji biz­ne­so­wej (BMM). Tu uży­to oba te ter­mi­ny i poka­za­no typo­wy kon­tekst ich użycia:

Startegia i taktyka

Jak widać (powyż­szy dia­gram wyko­na­ny zgod­nie z regu­ła­mi nota­cji BMM (http://​www​.omg​.org/​s​p​e​c​/​B​MM/) for­mal­ne, stan­dar­do­we defi­ni­cje i ich uży­cie w tym mode­lu, tak­że poka­zu­ją, że tak­ty­ka to dzia­ła­nia reali­zo­wa­ne w rela­tyw­nie krót­kim okre­sie, celem jest wspie­ra­nie przy­ję­tej stra­te­gii orga­ni­za­cji. Ta ostat­nia, to dłu­go­ter­mi­no­wo usta­la­ne regu­ły biz­ne­so­we, któ­re wyzna­cza­ją tak­ty­kę dzia­ła­nia. Strategia dzia­ła­nia jest kon­se­kwen­cją misji orga­ni­za­cji, wspie­ra reali­za­cję celów. Taktyka to osią­ga­nie kon­kret­nych i mie­rzal­nych dzia­łań na rzecz celów biznesowych.

Kolejnym eta­pem ana­li­zy biz­ne­so­wej i pla­no­wa­nia jest ana­li­za SWOT, któ­rą tak­że doku­men­tu­je­my (moż­na) nota­cją BMM, co opi­sa­łem już wcze­śniej w arty­ku­le A po co nam ten SWOT.

A po co nam ten SWOT

W poprzed­nim arty­ku­le (Ile jest tych wyma­gań na sys­tem ERP) pisa­łem, że nad­mier­ne sku­pia­nie się na szcze­gó­łach nie tyl­ko nie wno­si nicze­go do pro­jek­tu ale nie raz wręcz go nisz­czy. Dotyczy to zresz­tą ogól­nie pro­jek­tów ana­li­tycz­nych, nie tyl­ko w dzie­dzi­nie IT.

Na stro­nach jed­ne­go z bar­dziej poczyt­nych ser­wi­sów o ana­li­zie IT – http://​www​.moder​na​na​lyst​.com – poja­wił się jakiś czas temu cie­ka­wy arty­kuł o ana­li­zie SWOT. Autor opi­su­je jak tę ana­li­zę prze­pro­wa­dzić, ja opi­szę jak jej użyć w ana­li­zie sys­te­mo­wej orga­ni­za­cji i spe­cy­fi­ko­wa­niu wyma­gań. We wstę­pie arty­ku­łu czytamy:

Much of the busi­ness of busi­ness ana­ly­sis is in the deta­ils, and most busi­ness ana­ly­sts are by natu­re deta­iled, sys­te­ma­tic thin­kers. Occasionally most orga­ni­za­tions, tho­ugh, have times when they can?t see the forest for the tre­es. That is when the high-level, bro­ad-ran­ge view that SWOT Analysis affords is just as use­ful in avo­iding costly errors as unam­bi­gu­ous requ­ire­ments. (What is SWOT Analysis?).

W dużym uprosz­cze­niu: wie­lu ana­li­ty­ków sku­pia się od razu na szcze­gó­łach, bo to natu­ral­ne ele­men­ty nasze­go bez­po­śred­nie­go oto­cze­nia, nie potra­fią spoj­rzeć na orga­ni­za­cję z dale­ka, nie potra­fią dostrzec lasu patrząc na poje­dyn­cze drze­wa”. Analiza SWOT pozwa­la spoj­rzeć na pro­blem z innej, wyż­szej per­spek­ty­wy, sze­rzej, dzię­ki cze­mu jest bar­dzo uży­tecz­na w uni­ka­niu kosz­tow­nych błę­dów jaki­mi są nie­jed­no­znacz­ne wymagania. 

Jednym z zabój­ców pro­jek­tów” (a kon­kret­nie ich budże­tów i har­mo­no­gra­mów) są tak zwa­ne wyma­ga­nia osie­ro­co­ne i wyma­ga­nia nie­od­kry­te na eta­pie ana­li­zy. Są to odpo­wied­nio wyma­ga­nia zgło­szo­ne do spe­cy­fi­ka­cji i zre­ali­zo­wa­ne, z któ­rych następ­nie nikt nie korzy­sta, oraz te odkry­wa­ne dopie­ro na eta­pie wdro­że­nia. Nie da się zapro­jek­to­wać” lasu myśląc o drze­wach bo celem jest las, a nie kon­kret­ne drzewa. 

Jeden pro­jekt może mieć jeden cel, jeże­li jed­nak celem” ma być każ­dy kolej­ny krok, podróż nigdy się nie kończy.

Wymagania o jakich pisa­łem w poprzed­nim arty­ku­le to wyma­ga­nia wobec roz­wią­za­nia, któ­rym było jakieś opro­gra­mo­wa­nie”. Jednak to dru­gi etap ana­li­zy. Generalnie naj­pierw ana­li­zu­je się i defi­niu­je wyma­ga­nia biz­ne­so­we, a potem dopie­ro wyma­ga­nia wobec roz­wią­za­nia, wie­dząc już jakie warun­ki musi ono speł­niać. Przykładowym wyma­ga­niem biz­ne­so­wym może być pod­nie­sie­nie jako­ści obsłu­gi klien­ta (co by to tu teraz nie mia­ło zna­czyć), a dopie­ro reko­men­do­wa­nym roz­wią­za­niem może być, np. opro­gra­mo­wa­ne CRM albo reor­ga­ni­za­cja dzia­łu sprze­da­ży (co z resz­tą wie­le firm robi znacz­nie czę­ściej niż kupu­je nowy CRM ;)).

Wiele firm rzu­ca się na pro­jek­ty od razu z zało­że­niem, że musi­my mieć nowe opro­gra­mo­wa­nie”. Co nie raz bywa dużym błę­dem i masą zmar­no­wa­nych środ­ków. Jak się przed tym ustrzec?

Warto popa­trzeć na orga­ni­za­cję i kon­kret­ny pro­blem z pew­nej per­spek­ty­wy, z wyż­sze­go pozio­mu abs­trak­cji, niż tyl­ko sto­jąc mię­dzy biur­ka­mi widząc kon­kret­ne spra­wy i ludzi się nimi zaj­mu­ją­cy­mi. Narzędziem pozwa­la­ją­cym wznieść” się na wyż­szy poziom abs­trak­cji jest wła­śnie ana­li­za SWOT. Analiza ta pole­ga na ziden­ty­fi­ko­wa­niu czte­rech klu­czo­wych ele­men­tów wpły­wa­ją­cych na orga­ni­za­cję : czyn­ni­ki zewnętrz­ne jaki­mi są oka­zje i zagro­że­nia oraz czyn­ni­ki wewnętrz­ne czy­li sil­ne i sła­be stro­ny orga­ni­za­cji. Tu waż­na infor­ma­cja, ana­li­za SWOT to ana­li­za cze­goś kon­kret­ne­go” w okre­ślo­nym śro­do­wi­sku”. Czynniki wewnętrz­ne opi­su­ją to coś”, zaś czyn­ni­ki zewnętrz­ne opi­su­ją śro­do­wi­sko tego cze­goś”. Można tak ana­li­zo­wać orga­ni­za­cję (np. fir­ma i jej oto­cze­nie ryn­ko­we) czy też pro­duk­ty pro­jek­tów (np. kon­kret­ne opro­gra­mo­wa­nie w fir­mie) ale nie sam pro­jekt wdro­że­nio­wy czy pro­ces (one nie są czymś”).

Analiza SWOT może być ele­men­tem ana­li­zy sys­te­mo­wej orga­ni­za­cji. Analiza SWOT to np. wstęp do opra­co­wa­nia reko­men­da­cji w odpo­wie­dzi na pro­blem biz­ne­so­wy. SWOT to iden­ty­fi­ka­cja i wpływ okre­ślo­nych ele­men­tów, pozo­sta­je oce­na tego jaki, i na co. Dlatego ana­li­za SWOT sta­ła się czę­ścią tak zwa­ne­go Modelu Motywacji Biznesowej (BMM). Model ten pozwa­la lepiej zro­zu­mieć oto­cze­nie pro­ble­mu” oraz śla­do­wać” ele­men­ty ziden­ty­fi­ko­wa­ne w ana­li­zie SWOT na kon­kret­ne pro­ce­sy biz­ne­so­we i struk­tu­rę organizacyjną.

SWOT

(dia­gram BMM: ana­li­za SWOT i przej­ście na pro­ce­sy biz­ne­so­we opr. wła­sne autora).

Z poprzed­nich moich arty­ku­łów wie­my, że wyma­ga­nia wobec roz­wią­za­nia (w tym wobec opro­gra­mo­wa­nia) mają swo­je źró­dło w pro­ce­sach biz­ne­so­wych i ich wyko­naw­cach. Jednak spi­sa­nie ich w posta­ci dekla­ra­tyw­nej listy pod­czas warsz­ta­tów i wywia­dów, pro­wa­dzi do powsta­nia dłu­giej i prak­tycz­nie nie­we­ry­fi­ko­wal­nej listy o jakiej pisa­łem w Ile jest tych wyma­gań na sys­tem ERP.

Lekarstwem na pro­blem jest wery­fi­ka­cja (two­rze­nie) listy wyma­gań wobec roz­wią­za­nia. Weryfikacja (dia­gram powy­żej) pole­ga na tak zwa­nym śla­do­wa­niu. Śladowanie to wywo­dze­nie każ­de­go wyma­ga­nia z pier­wot­nej potrze­by, jaką jest tak­ty­ka, któ­rą przy­ję­to by osią­gnąć cel. Taktyka ma swo­je źró­dło w stra­te­gii (tak­ty­ka imple­men­tu­je stra­te­gię). Strategia (jej skon­stru­owa­nie) jest odpo­wie­dzią na oka­zję ryn­ko­wą, któ­ra jest przy­czy­ną, dla któ­rej podej­mu­je­my dzia­ła­nia ryn­ko­we. Okazja ryn­ko­wa daje szan­sę na zysk” (pro­dukt dają­cy docho­dy) w posta­ci dostar­cze­nia swo­je­mu oto­cze­niu war­to­ści doda­nej. Warto tu zwró­cić uwa­gę na to, że ele­men­ty ana­li­zy SWOT tak­że powin­ny mieć swo­je uza­sad­nie­nie w posta­ci iden­ty­fi­ka­cji zewnętrz­nych i wewnętrz­nych czyn­ni­ków wpły­wu. Słabe stro­ny oraz zagro­że­nia powin­ny iden­ty­fi­ko­wać ryzy­ka pro­jek­tu. Analizę uzna­je­my za zakoń­czo­ną po ziden­ty­fi­ko­wa­niu wszyst­kich zna­nych klu­czo­wych czyn­ni­ków wpły­wu i ryzyk. Analiza taka jest ele­men­tem ana­li­zy sys­te­mo­wej orga­ni­za­cji.

Wielu wła­ści­cie­li firm, ich zarzą­dy, pomi­ja ten etap w pro­jek­tach z uwa­gi na swo­je prze­ko­na­nie, że ich dotych­cza­so­we dzia­ła­nia i chęć ich kon­ty­nu­acji, nie wyma­ga­ją żad­nej korek­ty, ocze­ku­ją poda­nia na tacy opi­su narzę­dzia, któ­re­go – jak sądzą – potrze­bu­ją. Zachowują się jak pacjen­ci, któ­rzy mimo, że ostat­nie bada­nia robi­li wie­le lat temu, nie dopusz­cza­ją myśli, że lekarz może im prze­pi­sać na gorącz­kę coś inne­go niż kolej­ną aspi­ry­ną. Bywa, że zbyt póź­no odkry­wa­ją, że tym razem to nie było kolej­ne przeziębienie.

Praktyka poka­zu­je, coś bar­dzo cie­ka­we­go: zamiast pro­wa­dzić żmud­ne i kosz­tow­ne wywia­dy, sesje warsz­ta­to­we, burze mózgów, któ­rych pro­duk­tem jest dłu­ga lista dość przy­pad­ko­wych pomy­słów na wyma­ga­nia”, war­to docho­dzić do listy wyma­gań meto­dą od ogó­łu do szcze­gó­łu, wła­śnie od pozio­mu ana­li­zy SWOT (opar­tej na wizji i misji orga­ni­za­cji). Takie podej­ście od razu, naj­krót­szą dro­gą, pro­wa­dzi – przez model pro­ce­sów biz­ne­so­wych – do bar­dzo spój­nej i kom­plet­nej, bez nad­mia­ro­wych (osie­ro­co­nych) wyma­gań, spe­cy­fi­ka­cji wyma­gań wobec roz­wią­za­nia. Każde wyma­ga­nie ma swo­je uza­sad­nie­nie (śla­do­wa­nie) w stra­te­gii, nie ma ryzy­ka, że coś pomi­nie­my, bo tu wery­fi­ka­to­rem jest model pro­ce­su (kom­plet­na i spraw­dzo­na lista czyn­no­ści). Koszty uzy­ska­nia spe­cy­fi­ka­cji wyma­gań tą meto­dą, są znacz­nie niż­sze niż tra­dy­cyj­ny­mi (wywia­dy) meto­da­mi bo: nie anga­żu­je­my cza­su całych zespo­łów pra­cow­ni­ków na wywia­dy i warsz­ta­ty, ryzy­ko bar­dzo kosz­tow­nych pomi­nięć i nad­mia­rów jest mini­mal­ne, licz­ba ite­ra­cji w takim pro­jek­cie zbli­ża się do JEDNEJ! i nie trze­ba odkry­wać wyma­gań meto­dą kosz­tow­nych pro­to­ty­pów na eta­pie przed­wcze­snej imple­men­ta­cji. Jedyny pro­blem” to jej prze­pro­wa­dze­nie, mimo poku­sy”, roz­po­czę­cia pro­jek­tu od razu bo nie ma cza­su na ana­li­zę, i szko­da na to pieniędzy”.

wielka ryba kto kogo zjadł wędkarz łowi złowiony

Strategia, model biznesowy, architektura korporacyjna ? jak to powiązać?

Na blo­gu moje­go kole­gi poja­wił się bar­dzo inspi­ru­ją­cy wpis, zakoń­czo­ny prowokacją :):

Oczywiście ? jest to moja pro­po­zy­cja podej­ścia do tema­tu. Będę wdzięcz­ny za Państwa opi­nie. (Strategia, model biz­ne­so­wy, archi­tek­tu­ra kor­po­ra­cyj­na ? jak to powią­zać? | Architektura Korporacyjna).

Charakter mam taki, że na nie­któ­re pro­wo­ka­cje odpo­wia­dam :). Odpowiadam na swo­im blo­gu, a nie bez­po­śred­nio kole­dze na stro­nie jego blo­ga, gdyż zbyt duży tekst mi się zro­bił” :).

W pro­jek­tach patrzę na poję­cia omó­wio­ne w arty­ku­le chy­ba nie­co (ale nie wie­le) ina­czej. Najpierw, zamiast cyta­tów z lite­ra­tu­ry, defi­ni­cje słownikowe:

wizja: czy­jeś wyobra­że­nie jakichś zda­rzeń mają­cych zajść w przy­szło­ści, zwy­kle przed­sta­wia­ne w książ­ce lub w filmie,

misja: posłan­nic­two, waż­ne odpo­wie­dzial­ne zada­nie do spełnienia

stra­te­gia: prze­my­śla­ny plan dzia­łań w jakiejś dziedzinie,

tak­ty­ka: spo­sób postę­po­wa­nia mają­cy dopro­wa­dzić do osią­gnię­cia celu,

Z per­spek­ty­wy defi­ni­cji przy­ta­cza­nych w wyżej cyto­wa­nym arty­ku­le, nie widzę tu koli­zji. Nadając kon­tekst biz­ne­so­wy tym poję­ciom, wizja to wyobra­że­nie pew­nej hipo­te­tycz­nej posta­ci świa­ta (np. ryn­ku). Misja to nasze zada­nie”, to cze­go się podej­mu­je­my by tę Wizję urze­czy­wist­nić. Strategia biz­ne­so­wa to nic inne­go jak plan dzia­łań, przy­ję­ty jako spo­sób reali­za­cji wizji. Taktyka to spo­sób reali­za­cji tego pla­nu czy­li imple­men­ta­cja strategii.

Gdybym miał w ten spo­sób opi­sać swo­ją dzia­łal­ność to napi­sał bym:

Moja wizją są pro­jek­ty, reali­zo­wa­ne w spo­sób spro­wa­dza­ją­cy ich ryzy­ko do zera. Misją moją jest zdo­by­wa­nie i krze­wie­nie wie­dzy pozwa­la­ją­cej reali­zo­wać pro­jek­ty ide­al­ne. Strategia jaka przy­ją­łem, to samo­dziel­ne stu­dia, wyko­ny­wa­nie zawo­du ana­li­ty­ka i dzie­le­nie się zdo­by­tą wie­dzą. Taktyka dzie­le­nia się wie­dzą to pro­wa­dze­nie szko­leń, wygła­sza­nie refe­ra­tów na kon­fe­ren­cjach i pro­wa­dze­nie bloga.

Ponad sześc lat temu pisa­łem o mode­lu biznesowym:

Poprawnie wyko­na­ny model biz­ne­so­wy opi­su­je i defi­niu­je zarazem:

- źró­dła zaopatrzenia

- kana­ły zbytu

- wpływ konkurencji

- głów­ne źró­dło mar­ży (zysku)

- źró­dła zagrożeń

(uza­sad­nie­nie powyż­sze­go w Model biz­ne­so­wy…).

Wygląda więc na to, że model biz­ne­so­wy to w zasa­dzie tak­ty­ka reali­za­cji (jakiejś usta­lo­nej ) stra­te­gii (ryn­ko­wej).

Połączenie pojęć: misja, wizja, stra­te­gia, tak­ty­ka oraz archi­tek­tu­ra kor­po­ra­cyj­na, jak je wyko­nać? W arty­ku­le Nowa spe­cy­fi­ka­cja Business Motivation Model 1.2 znaj­dzie­my taki oto diagram:

BMMOvierwiev

Przedstawia on mię­dzy inny­mi powyż­sze poję­cia i ich wza­jem­ne powią­za­nia. Jak widać, są to poję­cia zgod­ne z przy­ta­cza­ny­mi defi­ni­cja­mi (pole­cam lek­tu­rę spe­cy­fi­ka­cji mode­lu poję­cio­we­go i nota­cji BMM). Wizja to stan koń­co­wy, misja jest ele­men­tem zbio­ru środ­ków słu­żą­cych do osią­ga­nia wizji”. Mamy tu: misję oraz powią­za­ną z nią stra­te­gię i tak­ty­kę (jako imple­men­ta­cję strategii).

Gdzie tu Architektura Korporacyjna? Andrzej Sobczak (autor cyto­wa­ne­go arty­ku­łu) przy­ta­cza taką definicję:

archi­tek­tu­ra kor­po­ra­cyj­na (w jed­nym z jej ujęć) to for­mal­ny opis struk­tu­ry i funk­cji kom­po­nen­tów kor­po­ra­cji, wza­jem­nych powią­zań pomię­dzy tymi kom­po­nen­ta­mi oraz pryn­cy­piów i wytycz­nych zarzą­dza­ją­cych ich two­rze­niem i roz­wo­jem w cza­sie. Przy czym kom­po­nent kor­po­ra­cji defi­nio­wa­ny jest jako dowol­ny ele­ment kor­po­ra­cji, któ­ry słu­ży do jej kon­stru­owa­nia; mogą to być ludzie, pro­ce­sy, fizycz­ne struk­tu­ry jak rów­nież sys­te­my infor­ma­tycz­ne. (Strategia, model biz­ne­so­wy, archi­tek­tu­ra kor­po­ra­cyj­na ? jak to powią­zać? | Architektura Korporacyjna).

I teraz war­to zwró­cić uwa­gę na to, że for­mal­ny opis struk­tu­ry i funk­cji kom­po­nen­tów kor­po­ra­cji, wza­jem­nych powią­zań pomię­dzy tymi kom­po­nen­ta­mi” to struk­tu­ra orga­ni­za­cyj­na. Dalej mamy opis pryn­cy­piów i wytycz­nych zarzą­dza­ją­cych ich two­rze­niem i roz­wo­jem w cza­sie” czy­li wizje, misję, stra­te­gię oraz tak­ty­kę fir­my, decy­zje jej Zarządu. Patrząc na stwier­dze­nie, że kom­po­nent kor­po­ra­cji defi­nio­wa­ny jest jako dowol­ny ele­ment kor­po­ra­cji, któ­ry słu­ży do jej kon­stru­owa­nia; mogą to być ludzie, pro­ce­sy, fizycz­ne struk­tu­ry jak rów­nież sys­te­my infor­ma­tycz­ne” nale­ży uznać, że struk­tu­rę orga­ni­za­cyj­ną nale­ży uzu­peł­nić wie­dzą o narzę­dziach jakie Ci ludzie dosta­ją by poma­ga­ły im reali­zo­wać ich zada­nia, czy­li mię­dzy inny­mi sys­te­my infor­ma­tycz­ne (tak, one są jedy­nie narzędziami).

Pozostał nam fakt, że to powi­nien być for­mal­ny opis”. Zaglądamy do Encyklopedii PWN i czytamy:

język for­mal­ny: (inform.) język zło­żo­ny ze wszyst­kich słów (wyra­żeń) uzy­ski­wa­nych za pomo­cą ści­śle okre­ślo­nych reguł;

Czyli potrzeb­na jest nota­cja (sys­tem poję­cio­wy: prze­strzeń nazw). Jak widać mamy do dys­po­zy­cji BMM, któ­ry pasu­je” do oma­wia­ne­go pro­ble­mu. Uzupełniona sys­te­ma­mi poję­cio­wy­mi dzie­dzi­no­wy­mi” czy­li BPMN (pro­ce­sy biz­ne­so­we powią­za­ne z zaso­ba­mi) oraz UML (struk­tu­ry i sys­te­my) mam kom­plet­ny i spój­ny poję­cio­wo (dba o to orga­ni­za­cja OMG) zestaw narzę­dzi sta­no­wią­cy w moich oczach odpo­wiedź na tytu­ło­we pytanie.

I teraz moja kon­klu­zja: bazu­jąc na brzy­twie Ockhama” pod­ją­łem pró­bę spraw­dze­nia czy przy­pad­kiem odpo­wiedź na tytu­ło­we pyta­nie sfor­mu­ło­wa­ne przez Andrzeja, już nie ist­nie­je… Odnoszę wra­że­nie, że wła­śnie pra­ce OMG, ich wynik, są chy­ba odpo­wie­dzią na to pyta­nie. Faktem jest, że nie wprost, ale chy­ba ana­li­zu­jąc te sys­te­my poję­cio­we, archi­tek­tu­rę kor­po­ra­cyj­na oraz BMM, moż­na uznać, że tytu­ło­we powią­za­nie ist­nie­je. Opisałem to z nie­co innej stro­ny w arty­ku­le Architektura Korporacyjna z OMG.