Sześć lat temu pisa­łem o scenariuszach:

… [[sce­na­riu­szo­we meto­dy oce­ny ren­tow­no­ści]]. Inwestycje oce­nia się nie po jej kosz­tach jed­nost­ko­wych w sto­sun­ku do sta­no­wisk pra­cy ale w kon­tek­ście cał­ko­wi­tych skut­ków reor­ga­ni­za­cji fir­my po wdro­że­niu. Te skut­ki to np. skró­ce­nie cza­su przy­go­to­wy­wa­nia ofert, obni­że­nie ryzy­ka, nowy inter­ne­to­wy kanał sprze­da­ży. Drugi bar­dzo waż­ny i jesz­cze rzad­ko zauwa­ża­ny czyn­nik to war­tość doda­na do pro­duk­tu fir­my jaką wpro­wa­dza wdro­żo­ny sys­tem. (Rentowność pro­jek­tów IT, oraz inne moje arty­ku­ły na ten temat).

Metoda nadal rzad­ko sto­so­wa­na ale z tam gdzie jest uży­ta, spraw­dza się z powo­dze­niem. Jest trud­na ale bar­dzo sku­tecz­na. Bardzo czę­sto daje znacz­nie lep­sze rezul­ta­ty (zna­na jest od lat 70tych) niż ana­li­za tren­dów czy sto­so­wa­nie tak zwa­nych dobrych prak­tyk (te ostat­nie są tu raczej mate­ria­łem wej­ścio­wym do testo­wa­nia mode­li). Metody sce­na­riu­szo­we to opi­sy­wa­ne tu już zasto­so­wa­nie ana­li­zy sys­te­mo­wej, któ­ra pole­ga na mode­lo­wa­niu oraz wła­śnie, na ana­li­zie sce­na­riu­szy, czy­li testo­wa­niu zacho­wa­nia się (pro­gno­za) stwo­rzo­ne­go mode­lu w odpo­wie­dzi na okre­ślo­ne warun­ki (np. biz­ne­so­we), czy­li uży­cie pla­no­wa­ne­go roz­wią­za­nia (testo­wa­nie mode­lu to-be). W efek­cie otrzy­mu­je­my pro­gno­zy skut­ków zasto­so­wa­nia bada­nych roz­wią­zań jesz­cze przed ich wdro­że­niem. Wyższość sce­na­riu­szy pole­ga tu na tym, że moż­na sku­tecz­nie badać pomy­sły nowa­tor­skie (inno­wa­cyj­ne jak kto woli), cze­go ana­li­za danych histo­rycz­nych czy dobrych prak­tyk nie da, z tego pro­ste­go powo­du, że pomysł jest nowy więc nie ist­nie­je jesz­cze jego historia.

W 1995 roku powsta­ły pierw­sze zało­że­nia tak zwa­nej [[archi­tek­tu­ry kor­po­ra­cyj­nej]] (AK). Obecny [[TOGAF v.9.1]], domi­nu­ją­cy chy­ba fra­me­work AK, zale­ca sto­so­wa­nie sce­na­riu­szy. Co znaj­dzie­my na por­ta­lu Architektura Korporacyjna (któ­ry gorą­co polecam):

Celem sce­na­riu­sza biz­ne­so­we­go jest przed­sta­wie­nie na wyso­kim pozio­mie ogól­no­ści okre­ślo­ne­go pro­ble­mu, któ­ry wystę­pu­je w chwi­li obec­nej w orga­ni­za­cji oraz pro­po­no­wa­ne­go (tj. któ­ry zosta­nie zre­ali­zo­wa­ny w sta­nie doce­lo­wym ? to-be) spo­so­bu jego roz­wią­za­nia ? zarów­no na pozio­mie biz­ne­so­wym jak i IT.

Formalna defi­ni­cja sce­na­riu­sza biz­ne­so­we­go, wystę­pu­ją­ca w TOGAF jest następująca:

Scenariusz biz­ne­so­wy opi­su­je na wyso­kim pozio­mie ogól­no­ści pro­ces biz­ne­so­wy, któ­re­go reali­za­cja jest moż­li­wa dzię­ki zasto­so­wa­niu okre­ślo­ne­go roz­wią­za­nia (rozu­mia­ne­go głów­nie jako roz­wią­za­nie IT ? przyp. AS), śro­do­wi­sko biz­ne­so­we i tech­nicz­ne, ludzi i kom­po­nen­ty infor­ma­tycz­ne (zwa­ne ?akto­ra­mi?), któ­rzy są zaan­ga­żo­wa­ni w reali­za­cję pro­ce­su a tak­że pożą­da­ny wynik wyko­na­nia tego pro­ce­su. (za Scenariusze biz­ne­so­we w archi­tek­tu­rze kor­po­ra­cyj­nej | Architektura Korporacyjna).

Tak więc jak widać, idea sce­na­riu­szy jest żywa i roz­wi­ja się. Scenariusze to nie tyl­ko narzę­dzie ana­li­zy ren­tow­no­ści (mój tekst z 2006 roku przy­to­czo­ny na począt­ku), sce­na­riu­sze to bar­dzo dobre narzę­dzie ana­li­zy i budo­wa­nia reko­men­da­cji, są tu nimi warian­ty i ich ryzyka.

Kluczowym narzę­dziem budo­wa­nia sce­na­riu­szy są mode­le, te jed­nak muszą być sfor­ma­li­zo­wa­ne ([[uży­cie nota­cji for­mal­nych]]), w prze­ciw­nym wypad­ku są ​„nie­ste­to­wal­ne” (w pro­jek­tach bazu­ją­cych na AK sto­so­wa­na jest z regu­ły nota­cja ArchiMate).

TOGAF to nie jedy­na meto­do­lo­gia, w któ­rej moż­na spo­tkać idee uży­cia sce­na­riu­szy. [[The Open Group]] nie ma ​„mono­po­lu” ani na meto­dy sce­na­riu­szo­we ani na ([[nota­cję ArchiMate]] sto­so­wa­ną w pro­jek­tach AK, któ­ra tak­że nie jest obję­ta żad­nym paten­tem ani inną ochro­ną praw­ną. Tak więc zachę­cam to bra­nia tej meto­dy pod uwa­gę, szcze­gól­nie w ryzy­kow­nych i dużych projektach.