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.

Jarosław Żeliński

Jarosław Żeliński: autor, badacz i praktyk analizy systemowej organizacji: Od roku 1991 roku, nieprzerwanie, realizuje projekty z zakresu analiz i projektowania systemów, dla urzędów, firm i organizacji. Od 1998 roku prowadzi samodzielne studia i prace badawcze z obszaru analizy systemowej i modelowania (modele jako przedmiot badań: ORCID). Od 2005 roku, jako nieetatowy wykładowca akademicki, prowadzi wykłady i laboratoria (ontologie i modelowanie systemów informacyjnych, aktualnie w Wyższej Szkole Informatyki Stosowanej i Zarządzania pod auspicjami Polskiej Akademii Nauk w Warszawie.) Oświadczenia: moje badania i publikacje nie mają finansowania z zewnątrz, jako ich autor deklaruję brak konfliktu interesów. Prawa autorskie: Zgodnie z art. 25 ust. 1 pkt. 1) lit. b) ustawy o prawie autorskim i prawach pokrewnych zastrzegam, że dalsze rozpowszechnianie artykułów publikowanych w niniejszym serwisie jest zabronione bez indywidualnej zgody autora (patrz Polityki Strony).

Ten post ma 2 komentarzy

  1. Guest

    Proponuję sprawdzić znaczenie metodologia vs metodyka…

    1. Jarek Żeliński

      Myślę, że sprawdzać nie trzeba. W tym artykule słowo metodologia w połączeniu z TOGAF jest używane bo literatura tego przedmiotu (w kraju i zagranicą, proponuje Google oraz fraza “metodologia TOGAF”) to robi. Nie oceniam tego i nie drążę z dwóch powodów: TOGAF to chronione prawem autorskim hasło oraz metodyka ta mało mnie interesuje (nie licząc faktu, że istnieje i tego że warto wiedzieć po co powstało) gdyż uważam, że architektura korporacyjna jako dziedzina doskonale sobie radzi bez TOGAF’u. Co do znaczenia słów metodologia i metodyka to są to słowa nadużywane po drugie oba mają jednak dość szerokie znacznie (tu za Słownik Języka Polskiego PWN):

      metoda [gr. méthodos ?sposób badania?], metodol. w nauce zespół ogólnych założeń badawczych, wytycznych w postępowaniu naukowym, lub sposób ujmowania badanych faktów.

      metodyka [gr.], metodol. zbiór zasad dotyczących sposobów postępowania, efektywnych ze względu na określony cel;

      metodologia nauk, w aspekcie pragmatycznym ? nauka o metodach działalności naukowej i stosowanych w nauce procedurach badawczych; w aspekcie teoretycznym ? nauka o elementach i strukturze systemów naukowych.

      Dodam, że TOGAF i nie tylko, to także przedmiot także badań naukowych (sam zajmuje się podobnymi).

Dodaj komentarz

Witryna wykorzystuje Akismet, aby ograniczyć spam. Dowiedz się więcej jak przetwarzane są dane komentarzy.