Sześć lat temu pisałem o scenariuszach:

… [[scenariuszowe metody oceny rentowności]]. Inwestycje ocenia się nie po jej kosztach jednostkowych w stosunku do stanowisk pracy ale w kontekście całkowitych skutków reorganizacji firmy po wdrożeniu. Te skutki to np. skrócenie czasu przygotowywania ofert, obniżenie ryzyka, nowy internetowy kanał sprzedaży. Drugi bardzo ważny i jeszcze rzadko zauważany czynnik to wartość dodana do produktu firmy jaką wprowadza wdrożony system. (Rentowność projektów IT, oraz inne moje artykuły na ten temat).

Metoda nadal rzadko stosowana ale z tam gdzie jest użyta, sprawdza się z powodzeniem. Jest trudna ale bardzo skuteczna. Bardzo często daje znacznie lepsze rezultaty (znana jest od lat 70tych) niż analiza trendów czy stosowanie tak zwanych dobrych praktyk (te ostatnie są tu raczej materiałem wejściowym do testowania modeli). Metody scenariuszowe to opisywane tu już zastosowanie analizy systemowej, która polega na modelowaniu oraz właśnie, na analizie scenariuszy, czyli testowaniu zachowania się (prognoza) stworzonego modelu w odpowiedzi na określone warunki (np. biznesowe), czyli użycie planowanego rozwiązania (testowanie modelu to-be). W efekcie otrzymujemy prognozy skutków zastosowania badanych rozwiązań jeszcze przed ich wdrożeniem. Wyższość scenariuszy polega tu na tym, że można skutecznie badać pomysły nowatorskie (innowacyjne jak kto woli), czego analiza danych historycznych czy dobrych praktyk nie da, z tego prostego powodu, że pomysł jest nowy więc nie istnieje jeszcze jego historia.

W 1995 roku  powstały pierwsze założenia tak zwanej [[architektury korporacyjnej]] (AK). Obecny [[TOGAF v.9.1]], dominujący chyba framework AK, zaleca stosowanie scenariuszy. Co znajdziemy na portalu  Architektura Korporacyjna (który gorąco polecam):

Celem scenariusza biznesowego jest przedstawienie na wysokim poziomie ogólności określonego problemu, który występuje w chwili obecnej w organizacji oraz proponowanego (tj. który zostanie zrealizowany w stanie docelowym ? to-be) sposobu jego rozwiązania ? zarówno na poziomie biznesowym jak i IT.

Formalna definicja scenariusza biznesowego, występująca w TOGAF jest następująca:

Scenariusz biznesowy opisuje na wysokim poziomie ogólności proces biznesowy, którego realizacja jest możliwa dzięki zastosowaniu określonego rozwiązania (rozumianego głównie jako rozwiązanie IT ? przyp. AS), środowisko biznesowe i techniczne, ludzi i komponenty informatyczne (zwane ?aktorami?), którzy są zaangażowani w realizację procesu a także pożądany wynik wykonania tego procesu. (za  Scenariusze biznesowe w architekturze korporacyjnej | Architektura Korporacyjna).

Tak więc jak widać, idea scenariuszy jest żywa i rozwija się. Scenariusze to nie tylko narzędzie analizy rentowności (mój tekst z 2006 roku przytoczony na początku), scenariusze to bardzo dobre narzędzie analizy i budowania rekomendacji, są tu nimi warianty i ich ryzyka.

Kluczowym narzędziem budowania scenariuszy są modele,  te jednak muszą być sformalizowane ([[użycie notacji formalnych]]), w przeciwnym wypadku są “niestetowalne” (w projektach bazujących na AK stosowana jest z reguły notacja ArchiMate).

TOGAF to nie jedyna metodologia, w której można spotkać idee użycia scenariuszy. [[The Open Group]] nie ma “monopolu”  ani na metody scenariuszowe ani na ([[notację ArchiMate]] stosowaną w projektach AK, która także nie jest objęta żadnym patentem ani inną ochroną prawną.  Tak więc zachęcam to brania tej metody pod uwagę, szczególnie w ryzykownych i dużych projektach.