Wybór dostawcy, umowa, realizacja

ContractXS

Ha! Startujemy z projektem. Będziemy mieli nowy system. Jeszcze tylko przetarg, rozmowy i zaczynamy. Wybór dostawcy, umowa, realizacja. Naturalny porządek rzeczy. To co teraz? Spisujemy wszystkie wymagania. Ogłaszamy światu, że szukamy dostawcy. Spływają oferty, krótka lista, rozmowy z handlowcami i ich dyrektorami. Negocjacje cenowe zadowalające. Stała cena ustalona. Wszyscy uśmiechnięci. Jeszcze tylko dobra umowa (bo to prawie gwarancja sukcesu). I zaczynamy. Potem już tylko…

Tak można by rozpocząć Baśń o projekcie. Trudniej jednak wyobrazić sobie końcówkę i wszyscy żyli długo i szczęśliwie.

To jeszcze raz. Naturalny porządek rzeczy. Spisujemy wszystkie wymagania.

Wszystkie wymagania

No tak. Trzeba je spisać. Tak aby o niczym nie zapomnieć, bo potem będzie problem. Ale jak? Jak to jak? Dajemy naszym ludziom zadanie. W szablonie ekselowym tworzymy wzór opisu. Uczymy, tych co jeszcze nie brali udziału w takim przedsięwzięciu, co to ten SMART. Jeśli idziemy w nowym duchu, to możemy i jakiś beklog wprowadzić i wyszkolić ludzi w stosowaniu formułki jako, trzy kropki chcę, trzy kropki, tak aby trzy kropki. Ludzie znają swoją robotę, to napiszą co trzeba. No co? Jakoś trzeba. Projekt nietrywialny to i wymagań sporo. Przeglądy, akceptacje. W końcu można wysłać zapytanie ofertowe.

Po drugiej stronie panika. Jest potencjalny kontrakt, mamy 126-stronicowy dokument, czytamy, więcej pytań, niż odpowiedzi. No, ale jakąś ofertę trzeba przygotować. Staramy się o spotkanie.  Od nas 6 osób, od nich 8. Bite sześć godzin nasiadówki. Wszystko grzecznie. Zadajemy zapytania. Odpowiadają. Jest wrażenie, że nie wszystko zostało ustalone po ich stronie. Dużo ze sobą dyskutują. Ale w końcu odpowiedzi są. Spisujemy notatkę. Uwzględniamy w ofercie.

Klasyka. O czym tu pisać?

No dobrze, a gdyby tak inaczej? Dlaczego wszystkie wymagania? Skąd my mamy je znać? A tak w ogóle, to co znaczy wszystkie? Przecież po to robimy projekt, by ustalić co ma być robione. Gdybyśmy to wiedzieli, to zakres projektu byłby o połowę mniejszy. W taki razie, co? Może na przykład cel długoterminowy, jaki chcielibyśmy osiągnąć po wdrożeniu efektów projektu? To może ukierunkować sposób myślenia potencjalnych dostawców o przedsięwzięciu. Ale dlaczego taki cel chcemy osiągnąć? To może poprzedźmy go opisem sytuacyjnym, szansami jakie widzimy, zdiagnozowanymi zagrożeniami i oceną stanu naszej organizacji względem tych czynników. To może jakoś pomóc w ocenie skali przedsięwzięcia. Kluczowe pojęcia. To jeszcze dobrze byłoby zdefiniować, bo jesteśmy trochę specyficzni i nie chcielibyśmy, aby dostawcy nas źle zrozumieli. Można by też opisać cele projektu, jakie naszym zdaniem należałoby osiągnąć przed rozliczeniem prac. Gdyby je uzupełnić o produkty, które naszym zdaniem należałoby wytworzyć, to też moglibyśmy troszkę rozjaśnić dostawcom, co nam po głowie chodzi. Ha! To krok dalej, napiszmy, czym naszym zdaniem te produkty powinny się cechować. Na przykład, Zoptymalizowany proces sprzedażowy. Wiemy, że ma maksymalizować cross-selling różnych linii produktowych. Wiemy, że ma być oparty o bliskie relacje z klientem. Dlaczego? No właśnie, to jeszcze dodajmy uzasadnienie – ano dlatego, że dzięki bliskim relacjom, dużo szybciej poznajemy prawdziwe potrzeby i jesteśmy w stanie zaoferować od razu usługę, na którą klient czeka.

No zaraz, zaraz. Ale na podstawie czegoś takiego, dostawca nie zbuduje nam syste…eeee… Ale, to nie jedyny produkt, który chcemy wytworzyć. Tak wynika z tej krótkiej analizy, którą wykonaliśmy. Ale numer! No dobra, to uzupełniamy informacjami o kluczowych interesariuszach, ograniczeniach przedsięwzięcia i ślemy zapytanie. Po drugiej stronie kilka osób zapoznaje się z 15-stronicowym opisem. Umawiają się na spotkanie. Po ich stronie 3-osoby. Po naszej trzy. Wyjaśniamy cel inicjatywy, aby obydwie strony miały jasność. Czekamy na ofertę.

Wybór dostawcy

Po czterdziestu pięciu dniach, zgodnie z podanym terminem, wpływają oferty. Nie jest źle – mamy czterech oferentów. Wszystkie oferty, punkt po punkcie, odnoszą się do naszych wymagań. Jedni to się postarali – dostaliśmy 620 stron! Uwzględnili nawet niskopoziomowe szczegóły technologiczne. Trochę nam ten Oracle nie leży, ale to się dogada. Wysłaliśmy oferty do technologów – Ci jak zwykle mieszają. Jeszcze się projekt nie zaczął, a już tysiąc pytań. Choć z drugiej strony, jak teraz nie ustalimy wszystkiego, to potem będą zmiany, przesunięcia terminów. Dobra, robimy serię spotkań. Niech Wszyscy, Wszystko wyjaśnią.

Technikalia wstępnie dograne. Uwzględniliśmy cztery warianty. Na wszelki wypadek. Mamy w propozycji zawarte trzy tygodnie analizy. Dostawca oddeleguje dwóch analityków, to pewnie i to finalnie ustalą. Nic to, terminy gonią, negocjujemy umowę. Łatwo nie jest, bo dostawca mówi, że w zależności od wariantu, koszty mogą być rożne. Nasi prawnicy nie zgadzają się na wariantową umowę. Mówią, że dostawca musi zdecydować ile chce kasy. Ryzyko musi wliczyć jakoś w ofertę. Strasznie się to wszystko przeciąga, a ludzie już czekają na rozpoczęcie. Jest. Cena ustalona. Termin też – za dwa i pół roku produkt będzie na produkcji. Wszystkie jedenaście modułów. Umowa podpisana. Zaczynamy. Nie łatwo wybrać dostawcę. Ale inaczej się nie da.

A gdyby jednak inaczej?

Oferta przyszła. 50 stron. Wygląda na to, że całkiem sporo czasu ma zostać poświęcone na analizę. Dostawca chciałby przedyskutować z każdą ze spółek produktowych aktualny kształt procesów z zakresy marketingu, sprzedaży oraz, co dziwne, dostarczania produktów. Ciekawe po co? Do późniejszej decyzji pozostawia konieczność jawnego naszkicowania procesów aktualnych. W ofercie są wzmianki o ujednoliceniu podejścia do oceny atrakcyjności klientów. Gdyby udało się opracować wspólne podejście, wówczas opcjonalnie elementem architektury IT stanie się system do automatyzacji reguł decyzyjnych. Podobnie zresztą jest z systemem do automatyzacji procesów. Można go brać pod uwagę, ale ostateczny kształt procesów i wynikające z tego wymagania wskażą na zasadność jego zastosowania. Zresztą, wykonawca nadmienia, że z racji krytyczności projektu i tworzonego rozwiązania IT, będzie chciał się zapoznać z całą architekturą IT naszej firmy, aby tak dobrać składowe rozwiązania, by były z nią zgodne. Elementem rozważań na etapie analizy będzie także docelowa struktura organizacyjna. Może się bowiem okazać, że zasadna okaże się centralizacja marketingu w ramach jednego działu, z którego będą oddelegowywane osoby do poszczególnych spółek. Odpowiedzialność za marketing byłaby jednakże utrzymywana w jednym miejscu. Być może wpłynie to jakoś na system CRM, który jest już wdrożony w każdej ze spółek. Dostawca wspomina także, że być może analizie powinny zostać poddane procedury reklamacyjne – one także mogą wpływać na efektywność procesów sprzedażowych.

Elementem oferty jest zestaw ról, jakie wystąpią po stronie dostawcy oraz oczekiwania wobec kompetencji nas – zamawiających. Dziwne. To my zamawiamy, a tu oczekiwania w drugą stronę. Chcą, abyśmy potrafili odnieść się do modeli procesowych. Oczywiście gwarantują dostępność swoich analityków – tytułują ich procesowymi – ale oczekują także zrozumienia diagramów po naszej stronie. Będzie architekt rozwiązania IT, wiodący analityk biznesowy, analitycy od poszczególnych rodzajów systemów, główny projektant, programiści. Analiza ma być prowadzona w sposób facylitacyjny – mamy dzięki temu mieć większy wpływ na kształt rozwiązania. Efekty analizy biznesowej od pewnego momentu mają być korelowane z architekturą rozwiązania IT. Tutaj także mają być prowadzone facylitowane warsztaty z naszymi architektami. Strasznie tego dużo. Nie wszystko rozumiemy. Co ciekawe, w ofercie jest zapis, że czas trwania etapów analizy jest w dużej mierze uzależniony od wspólnego tempa prac, którego na tym etapie nie da się oszacować. Jak to?! Oferta Time & Materials?! Choć z drugiej strony, przypominając sobie wcześniejsze projekty na Fixed Price, przez gardło nie przejdzie określenie łatwo i przyjemnie. Może jeśli będziemy kontrolowali przebieg prac, to takie podejście będzie lepsze? Ale jak to kontrolować? Nigdy tak nie pracowaliśmy?

Inspektor nadzoru inwestorskiego

Ale że co? Zatrudnić osobę z zewnątrz? Do kontroli zewnętrznej firmy? A jak się dogadają? [przyp. I to jest ten trudny i kluczowy moment tej historii. Dotykamy bowiem roli, w którą wcielić się powinny osoby cechujące się się zarówno bardzo wysokimi kompetencjami jak i wysoka etyką. O tym za chwilę.]

No dobrze, na budowach często taki model się sprawdza. To może i u nas się sprawdzi. Ale co miałby robić?

Co miałby robić? Pomoc w wyborze dostawcy

Z moich obserwacji wynika, że zamawiający najczęściej jako dostawcę usług traktują firmę. I to jest fundamentalna pomyłka. Projektów nie realizuje firma lecz ludzie. Oczywiście, najczęściej ludzie Ci są kierowani do pracy przez firmę, która kontrakt zdobyła, co nie zmienia faktu, iż nie firma prace będzie prowadzić. Drobna zmiana sposobu myślenia, która w ogromny sposób może zaingerować w sposób wyboru dostawcy.

W przypadku firmy, co najczęściej sprawdzamy? Stabilność finansową, referencje, certyfikaty kluczowych członków zespołu. Stabilność finansowa może wynikać z tak wielu czynników, nieistotnych dla naszego przedsięwzięcia, że ciężko na jej podstawie wnioskować, czy firma sobie poradzi, czy nie. Referencje. Zdobyte przez jakieś osoby w jakimś projekcie. Nie ma gwarancji, że te osoby jeszcze w firmie pracują. Certyfikaty. Mówią jedynie tyle, że osoba wie, co powinna umieć. Pytanie, czy to umie? Weźmy na analityczny przykład certyfikat OCUP. Poniższa tabela prezentuje zakres materiału z zakresu języka UML 2 objętego certyfikacją na poziomie Intermediate. Co z niej wynika? Ano to, że osoba zna język UML 2 w tym zakresie. Certyfikat nie daje odpowiedzi na pytanie, czy potrafi zastosować UML z tego zakresu do poprowadzenia prac analitycznych. Oczywiście, fakt że osoby posiadają certyfikat, oznacza, że w jakiś sposób inwestują w swój rozwój. Ale to niestety warunek konieczny a nie wystarczający z punktu widzenia naszych rozważań.

OCUP

Zakres materiału objętego certyfikacją OCUP 2 IntermediateLevel

Czego natomiast można oczekiwać od firmy? Metodyki. I tego, że znają ja ludzie, którzy będą oddelegowani do pracy w naszym projekcie. A ludzie, to kompetencje. Konkretna osoba, konkretna weryfikacja.

Czyli, co weryfikować? Metodykę? Ludzi? Przecież to jakaś abstrakcja? A może nie. Zapytajmy inspektora.

Aaaaa. Czyli elementem oferty ma być opis metodyki, jaka będzie zastosowana w naszym projekcie? Hmmm. No może. A jeśli napiszą, że metodyka będzie dynamicznie ustalana w trakcie prac? Albo, że jest to tajemnica firmy? Że co? Że to znaczy, że jej nie mają? Że, gdyby mieli, to by napisali? To nie jest oddanie własnej pozycji rynkowej innym? Nie nauczą się w tydzień, miesiąc, rok? Taaaak? To się latami wypracowuje? Czyli naciskać? Taaak? Ale dalej nie chcą? Halllo, nie słyszę panie inspektorze? Że co? Nie brać pod uwagę? Hallo! Haaaaaalo!

Napisali. Niektórzy. Przeglądamy. Razem z inspektorem. Nie rozumiemy, dopytujemy, analizujemy, dopytujemy. Brzmi sensownie. Zresztą, widać po wyniku. Kryteria oceny były wszystkim znane. Ci wypadli najlepiej. To co – mamy dostawcę? Nieeee?! Jak to nie? Mają metodykę. Sam pan mówił. Rozmawiamy dalej ze wszystkimi, którzy są powyżej minimum?

Aaaaaa…niech przyślą ludzi. No i co my z nimi zrobimy? Warsztaty? Jakie warsztaty. Przecież dopiero szukamy dostawcy. Aaaaa, takie przykładowe? Ile? Dwa? Trzy? Aaaaaa…jedne z analizy biznesowej, drugie z czego? Z analizy systemowej? Nie można w jedną analizę? Nie? To rożne analizy? Aaaaaa….inni ludzie będą uczestniczyć. Od nich? I od nas tez? Tak? System, biznes…jasna sprawa. Scenariusze napisać? Aaa, że niby od nas wiedzę muszą wyciągnąć? Nie podpowiadamy? A jak nie wyciągną? Znaczy, że słabo. No fakt, jak nie wyciągną na warsztatach to dlaczego mieliby wyciągnąć w projekcie. Dobrze, to my zaczniemy opisywać jakiś nasz problem. Mówi pan, że z jakiegoś zrealizowanego projektu? Słusznie. To będzie rzeczywisty przykład – łatwiej się będzie odnaleźć. Weźmy ten od samochodów. Tam były niezłe analizy. Szkoda, że post factum.

Trochę się zdziwili dostawcy. Jeden napisał, że oddeleguje ludzi, jak będzie miał kontrakt. No trudno. Odpadł. Dwie firmy się zgodziły. Jedna napisała, że to bardzo ciekawy pomysł. Spotykamy się z nimi siedemnastego listopada. Na trzy dni. W naszym ośrodku szkoleniowym w Ustce.

Zimno jak czort. No ale czego oczekiwać po listopadzie nad morzem. Spotykamy się o poranku. Handlowiec dostawcy jakiś spięty. Ale merytoryczni całkiem okej. Zaczynamy. Początek trudny, bo handlowiec rozpoczął od slajdów o firmie. Nic to, pół godziny i przejdziemy do konkretów.

Podzieliliśmy się na grupy, tak jak zaproponowali merytoryczni. Jedni dostali jako wsad opisane wczoraj procesy aktualne. Drugich poproszono, aby się zupełnie odcięli od tego, co jest, tylko pomyśleli jak taki proces mógłby wyglądać w świecie bez ograniczeń. Dziwny pomysł. Zawsze są jakieś ograniczenia. Ale co tam, mówią, to mają. Poszliśmy po zupełnej bandzie. Gdyby finansowy zobaczył, jak to zaplanowaliśmy, to by nas wszystkich…eeee…pozwalniał. Zostały dwie godziny dzisiejszych warsztatów. Siadamy razem. Pokazujemy nasze rozwiązania. Kurcze, dwa światy! I co , mamy teraz znaleźć odpowiedniki? W sumie, są. Ci z pierwszej grupy mówią, że tak się skoncentrowali na tym, co jest, że nawet nie pomyśleli, że można inaczej. Nieee, no nieźle to wygląda! Kurcze! Ale jazda! Gdybyśmy to wymyślili w poprzednim projekcie to teraz mielibyśmy jeden problem z głowy. Ha! To o to im chodziło z techniką Blue Sky! Niezłe, niezłe. Wcześniejsza firma nam tego nie pokazała.

W ogóle chłopaki są fajne. Otwarci. Wczoraj wieczorem jeden nam opowiadał, jak to było, gdy się certyfikował w Szkocji, Magiel miał niezły. Zresztą widać, że pozostali liczą się z jego zdaniem. Pamiętasz jak on ma na imię? Wszyscy do niego mówią Krokodyl. Adam? No fakt, jest w materiałach.

I jak panie inspektorze? Druga firma lepiej wypadła? Nasze oceny wyraźnie wskazują na drugą? Arkusz oceny, też. To co? Okej, idziemy w kierunku drugiej.

Co miałby robić? Pomoc w stworzeniu umowy

Prawnicy przygotowali umowę. Wzorowali się na poprzednich ,ale mieli sporo wątpliwości odnośnie zapisów, które wymagają naszej bieżącej oceny sposobu prowadzenia prac. Boją się, że dostawca będzie ciągnął analizy w nieskończoność. Tak, tak, wiem, że to w dużej mierze od nas zależy. Ale chyba tak jest fair. Jak będziemy zwlekali, to mamy większe koszty i późniejsze wdrożenie. Ale co to dostawcę? Aaaa, płatność jest po odbiorze prac. No tak. I jeszcze arkusz oceny jakościowej produktu? Całego? Aaaa, wszystkich produktów projektu? Znaczy się, rodzajów produktów? Czyli co? Określimy kiedy uznamy, że proces jest ukończony? I przypadek użycia? I model bazy danych? No dobra. I jeszcze korelacje? Nie do końca czuję, ale jeśli pan ogarnia temat, to jest okej. Przygotujemy to? Taaak? Razem z dostawcą? To będzie załącznik do umowy? W sumie, niezły pomysł. Metodyka też będzie załącznikiem? Aaaa…no tak, na to się umawiamy.

[Minął tydzień]. Mamy problem z tym pańskim przypadkiem użycia. Aaaa, wie pan o tym? Adam jutro będzie u nas? Spoko. Dogadamy się. Okej, pamięta pan, że ja mam jutro wolne. Widzimy się w poniedziałek.

Realizacja

Każdy z opisanych powyżej scenariuszy jest troszkę uproszczony –  za zadanie miał zilustrować problem. Żaden ze scenariuszy nie gwarantuje sukcesu. Natomiast każdy z nich w inny sposób zarządza ryzykiem. Pierwszy, iluzorycznie, stałą ceną. Ale wiadomo, że cena stała, w przypadku problemów, nie będzie ceną ostateczną. Udowadnianie winy (czas, koszty), ciąganie się po komitetach sterujących (czas, koszty), aneksy (czas, koszty), szukanie nowych dostawców (czas, koszty)… Drugi, zrozumieniem, że na początku nie można dokonać ustaleń końcowych i w konsekwencji, zweryfikowaniem dostawcy i bieżącym zarządzaniem pracami. Zaoszczędzamy w dużym stopniu na wyszukiwaniu (często, oczywistych) powodów opóźnień. Zmniejszamy ryzyko zamiatania problemów analitycznych pod dywan (analityk trafił na trop, który należałoby podążyć, ale ponieważ nikt nie zauważył, a czas nagli, to udajemy, że nie słyszeliśmy) i tym samym, wypracowania nieoptymalnego produktu. Ryzykujemy tym, że nie sprawdzi się inspektor. Niezależnie, czy osoba jest zewnętrzna, w stosunku do inwestora, czy nie (choć praktyka pokazuje, że w dużych firmach ciężko znaleźć odpowiednią liczbę osób o szerokiej wiedzy z zakresu procesów produkcyjnych) – na jej barkach spoczywa spora odpowiedzialność za sprawność prowadzonych prac. W zależności od sytuacji, inspektor może nie tylko kontrolować dostawcę, ale także doradzać. Choć w tej sytuacji należy zachować szczególną ostrożność, by nie utracić odpowiedzialności za wytwarzane produkty.

Nic nie stoi, oczywiście, na przeszkodzie, by w pierwszym scenariuszu zweryfikować dostawcę i zatrudnić inspektora. Troszkę to zmniejszy ryzyko, aczkolwiek paradygmaty współpracy są na tyle rożne, że moim zdaniem, fundamentalnych różnic nie uzyskamy.

Proponuję jakieś nowe podejście? Nie. To wszystko już było. Ale, jak to zwykle bywa w historii, te same koncepcje, dylematy wracają raz po raz pod innymi nazwami. Szczególnie teraz warto o tym pamiętać, gdyż popularny edżaj, ten stary i nietrywialny problem, próbuje rozwiązać trywialnymi metodami opisanymi w rożnej maści manifestach. Z drugiej strony podejścia waterfall są temu przeciwstawiane, jako te, które są nieelastyczne, nierealne i niepraktyczne. Wygląda jak wybór między rakiem a cholerą. Ale tak nie jest. Pośrodku jest zdrowy rozsądek i złożona rzeczywistość. Powyższa propozycja próbuje iść w tym kierunku. Niezależnie od sztandaru pod jakim idziemy, nie uciekniemy od problemu kompetencji zespołu (umiejętność pracy wspólnej, kultury), kompetencji poszczególnych jego członków (kompetencje w ramach reprezentowanej w procesie produkcyjnym roli), umiejętności zorganizowania wielu rożnego rodzaju prac wokół metodycznego kręgosłupa (połączenie różnorodności produktów, różnorodności ról, osi czasu w jeden spójny ciąg) oraz umiejętności zarządzania i kontroli procesu produkcyjnego (wychodząc z założenia, że zespół jako taki, sam siebie, jako takiego, raczej nie skontroluje i nie pozarządza). I o tej ostatniej umiejętności nie zapominajmy. Jest bardzo ważna.

Oczywiście, pojawia się pytanie jak znaleźć dobrego inspektora (nie zawsze jest to jedna osoba). Prostej odpowiedzi nie mam. Ale szukać warto.

Ilustracja wpisu – https://pl.freepik.com/darmowe-zdjecie/szczęśliwy-dojrzały-prawnik-wskazuje-przy-podpisu-miejscem-na-kontrakcie-dokumentuje-z-piorem_3140714.htm. Designed by Freepik


Licencja Creative Commons
Ten utwór jest dostępny na licencji Creative Commons Uznanie autorstwa – Bez utworów zależnych 4.0 Międzynarodowe.

Evergreen, czyli architektura procesów biznesowych część 2

Fred Astaire Small

Fred Astaire

 

Przeglądnąłem wczoraj statystykę popularności wpisów, i ku mojemu miłemu zaskoczeniu, w czołówce, przez prawie dwa lata, znajduje się krótka wypowiedź o znaczeniu architektury procesów dla prac analitycznych. Oczywiście, na podstawie jednego spostrzeżenia nie należy wyciągać żadnych głębokich wniosków, ale żywiąc nadzieję, iż jeden z nich jest zbliżony do choć odrobinę trafnego, postanowiłem rozszerzyć temat, i sięgnąć zarówno do klasyki (Geary Rummler), jak i współczesności (Martyn Ould). I nie będzie to żaden cover, tylko pokazanie, w jaki sposób można, łącząc różne doświadczenia, uporządkować to co często bywa nieuporządkowane. Czyli architekturę procesów. A nawet ciut więcej – architekturę biznesową.

Zarządzamy procesami (a przynajmniej tak twierdzimy), mamy ich tysiące (to widać w repozytorium), poświęcamy na ich opisanie mnóstwo czasu (to widzimy po niskiej dostępności analityków procesowych), procesy są bardzo złożone i wyjątkowo specyficzne (bo my w ogóle jesteśmy inni niż setka innych firm działających w tej branży i robiących to samo).

-I co?

I jakoś nie udaje nam się nad tym zapanować na wysokim poziomie. Mamy poczucie, że szlifujemy szczegóły, które nie „spinają się” na poziomie makro. Więc szlifujemy dalej szczegóły … może się zepnie.

Szerzej oczywiście można byłoby pisać o symptomach świadczących o „nie spinaniu się”, ale temu być może poświęcę osobny wpis. W bieżącym, szybko będę zmierzał do pomysłu na zredukowanie problemu. Geary Rummler (jeden z moich tzw. guru), lata (świetlne, z punktu widzenia szybkozmiennego, współczesnego świata) temu, w ramach ogólnej koncepcji zarządzania wykonaniem (ang. performance improvement) opracował koncepcję Mapy Supersystemowej (ang. supersystem map). Mapa supersystemowa obrazuje otoczenie organizacji oraz jej wewnętrzną strukturę. Kluczowym z punktu widzenia rozważań niniejszego wpisu elementem mapy jest jej centralny blok zawierający działania zarządcze (ang. managing), wspierające (ang. contributing) oraz systemy tworzenia wartości (ang. value creation system) . Tak opisana struktura działań organizacji stanowi podstawę do stworzenia zarządzalnego, w oparciu o koncepcję procesową, systemu. Warto przy okazji pamiętać, iż system to układ elementów mający określoną strukturę i stanowiący logicznie uporządkowaną całość (definicja zaczerpnięta ze Słownika Języka Polskiego PWN). Aby stwierdzić, czy organizacja stanowi system, należy uwidocznić jej strukturę – czyli stworzyć jej model.

VCS

Mapa supersystemowa

O ile działania zarządcze oraz wspierające powinny być dobrze znane osobom zajmującym się wdrażaniem procesowego podejścia do zarządzania organizacją, o tyle systemy tworzenia wartości wymagają wyjaśnienia. Zgodnie z teorią Geary’ego Rummlera systemy tworzenia wartości powinny być konstruowane zstępująco (ang. top-down), poczynając od wyższych poziomów abstrakcji, a kończąc na poziomie pracy realizowanej na określonym stanowisku. Tak stworzona struktura jest nazywana w metodyce hierarchią tworzenia wartości (ang. value creation hierarchy). Poziom najwyższy, to deklaracja systemów tworzenia wartości. Duże organizacje zwykle będą miały wiele takich systemów – ich liczba stanowi wypadkową skali i różnorodności działania oraz granulacji systemów. W założeniu, pojedynczy system tworzenia wartości powinien być zarządzalnym jako całość przez określoną jednostkę biznesową, ciągiem działań prowadzących do dostarczania Klientom organizacji określonego rodzaju produktu, za który dana jednostka odpowiada. Dla przykładu, w instytucji finansowej można wyobrazić sobie jeden system tworzenia wartości produktu kredytowego, ale równie dobrze można wyobrazić sobie kilka systemów wartości w tym obszarze, na przykład biorąc jako dodatkowy wyróżnik segmentację Klientów. Wówczas można byłoby otrzymać system tworzenia wartości produktu kredytowego dla klientów korporacyjnych,  system tworzenia wartości produktu kredytowego dla małych i średnich przedsiębiorców oraz system tworzenia wartości produktu kredytowego dla klientów indywidualnych. Poziom granulacji systemów tworzenia wartości, jak łatwo się domyślić nie jest ustandaryzowany i wynikać powinien bezpośrednio ze specyfiki organizacji.

W kolejnym kroku dekompozycji, w ramach każdego z systemów wartości należy wyróżnić trzy obszary działań – wytworzenie (ang. launched), sprzedanie (ang. sold) oraz dostarczenie (ang. delivery). Każdy z obszarów jest odpowiedzialny za wiodące pojęcie:

  • wytworzenie – ma na celu dbać o cykl życia produktu (bądź usługi), począwszy od pomysłu nań, na wycofaniu z oferty zakończywszy.,
  • sprzedanie – ma na celu pozyskanie oraz utrzymanie Klienta na produkty (bądź usługi) wchodzące w zakres danego systemu tworzenia wartości,
  • dostarczenie – ma na celu obsłużenie zamówienia na określony produkt (bądź usługę), począwszy od złożenia zamówienia, na zakończeniu obsługi produktu zakończywszy.

Innymi słowy i w pewnym uproszczeniu, pierwszy z obszarów obejmuje cykl życia produktu, drugi – cykl życia Klienta, trzeci natomiast – cykl życia zamówienia. Między obszarami można sobie wyobrazić relacje wskazujące na fakt, iż dany obszar może funkcjonować przy założeniu, iż w poprzedzającym go obszarze wykonano już jakąś część prac (na przykład, Sprzedawanie może się rozpocząć, gdy Wytworzenie dostarczy opis finalnego produktu, aczkolwiek produkt może być jeszcze niedostępny dla Klientów). Relacje tego typu zostały na poniższym schemacie oznaczone linią ciągłą. Linia przerywaną zaznaczono potencjalną zasadność dostarczania informacji zwrotnych dla obszarów. Dla przykładu, może być zasadnym dostarczanie z poszczególnych wystąpień działań z obszaru dostarczania informacji o udzielanych upustach, reklamacjach oraz sugestiach odnośnie potencjalnych modyfikacji produktu zgłaszanych przez Klientów.

VCS (L2)

Pierwszy poziom dekompozycji systemu tworzenia wartości

Wnikliwemu czytelnikowi może szybko przyjść na myśl pytanie, czy ten poziom dekompozycji systemu tworzenia wartości ma na celu jedynie dostarczenie bazy do dalszych rozważań, czy tez może być wykorzystany do podejmowania jakichkolwiek decyzji biznesowych (pomimo faktu, iż każdy z systemów tworzenia wartości będzie dekomponowany w taki sam sposób). Pytanie trafne, a odpowiedź brzmi – na tym poziomie można już podejmować decyzje biznesowe. Jednym z przykładów jest poniższy rysunek koncepcyjny, prezentujący działania związane z obsługą Klienta jako wspólne dla wszystkich systemów tworzenia wartości. Podjęcie takiej decyzji, oznaczać będzie w praktyce konieczność zapewnienia między innymi  jednolitego spojrzenia na Klienta we wszystkich strumieniach produktowych, zapewnienia wsparcia narzędziowego (przede wszystkim wsparcia IT) umożliwiającego międzyproduktowe relacje z Klientami (np. crossselling), wdrożenia praktyk zarządczych umożliwiających utrzymanie jednolitości kontaktów z klientem w różnych jednostkach biznesowych.

Na tym poziomie opisu organizacji można także pokusić się o przypisanie jednostek organizacyjnych do realizacji prac w każdym z trzech obszarów systemu tworzenia wartości. Przypisanie to może w niektórych przypadkach rodzić konieczność podjęcia istotnych decyzji biznesowych i tym samym dostarczyć jako technika zauważalne korzyści.

VCS (L2) v1

Przesądzenia architektury biznesowej na wysokim poziomie opisu organizacji

Kolejnym poziomem dekompozycji systemów tworzenia wartości jest wskazanie procesów uczestniczących w realizacji poszczególnych obszarów. Jest to więc moment, w którym dotykamy bezpośrednio tematyki architektury procesów biznesowych, a tym samym problemu, jak ja tworzyć. Metodyka G. Rummlera, nie będąc wyjątkiem, pozostawia analityka procesowego (analityka biznesowego, architekta biznesowego) samemu sobie, nie podając wskazówek, jakimi należy się kierować podczas próby interpretacji pracy realizowanej w organizacji w terminach procesów. Jest to moim zdaniem spory jej mankament, gdyż utworzenie spójnego w ramach organizacji systemu procesów jest zadaniem bardzo trudnym, i bez podania choćby podstawowych kryteriów identyfikacji procesów, prawdopodobieństwo uzyskanie jednolitego podziału jest nieduże.

W sukurs dojrzałej i ustabilizowanej metodyce może przyjść Trzecia Fala Procesowości, czyli metodyka Riva opracowana przez Martyna Oulda. Okrzyknięta przez specjalistów z szeroko pojętego obszaru zarządzania procesami (ang. Business Process Management) jako powiew świeżego powietrza w dojrzałej już dziedzinie, Riva dostarcza kilka fundamentalnych wartości, spośród których do najważniejszych należy zaliczyć kilkuetapowy proces dochodzenia do architektury procesów biznesowych.

Punktem wyjścia do rozważań na temat architektury procesów w metodyce Riva jest model pojęć (albo model informacyjny organizacji, który jest tworzony na tym samym poziomie abstrakcji), którego przykład prezentuje poniższy rysunek. Na potrzeby dalszych rozważań, przyjmijmy, że Produkt, jako pojęcie abstrakcyjne jest konkretyzowany między innymi poprzez Produkt kredytowy. Każdy produkt wprowadzany na rynek wymaga przeprowadzenia określonej liczby Badań jakościowych, które mają potwierdzić bądź obalić czynione przy jego konstruowaniu założenia. Produkty tworzone są z myślą o określonych Segmentach, które kategoryzują Klientów obsługiwanych przez organizację.

MP (1)

Model pojęć

Model pojęć, opisany diagramem, stanowi integralną część modelu opisującego organizację na poziomie biznesowym, dostarczając aparatu pojęciowego potrzebnego do właściwego rozumienia pozostałych składowych modelu architektury biznesowej. Podobnie i w tym przypadku, model ten będzie stanowił punkt wyjścia do określenia architektury poprzez:

  1. zaklasyfikowanie poszczególnych pojęć do kategorii przedmiotu pracy (ang. unit of work),
  2. określenie relacji typu generates, pomiędzy przedmiotami pracy,
  3. utworzenie sieci procesów skupionych wokół pojedynczego przedmiotu pracy oraz relacji generates z innymi przedmiotami pracy według określonego wzorca,
  4. dostosowanie wzorcowej architektury do specyfiki organizacji.

W opisywanym podejściu, za przedmiot pracy należy uznać takie pojęcie, co do którego możemy powiedzieć, iż z biznesowego punktu widzenia praca jest wykonywana i rozliczana po to, by zmieniać stan tego pojęcia. W naszym przypadku, oznacza to, iż specjaliści dziedzinowi zgodzili się co do tego, iż praca wykonywana jest wokół poszczególnych rodzajów produktów finansowych (którego przykładem jest Produkt kredytowy) oraz Badań jakościowych. Co więcej, uznano, iż podczas pracy nad produktem powstaje konieczność uruchomienia prac nad badaniami jakościowymi, co zostało jawnie zaznaczone relacją generates. Mając to na uwadze, możemy już stwierdzić, iż procesy biznesowe będą stworzone dla tych dwóch przedmiotów pracy, oraz że wystąpią relacje pomiędzy procesami skupionymi wokół nich, o czym za chwilę.

Próbując nałożyć model pojęć na wcześniej zdekomponowany system tworzenia wartości, moglibyśmy stwierdzić, iż wyróżnione przedmioty pracy w pełni zawierają się w pierwszym z jego etapów – Wytworzeniu. Przypisanie to, zilustrowane poniżej, należy traktować jako koncepcję, która niekoniecznie musi znaleźć odzwierciedlenie w diagramie.

VCS (L2) v2mp

Przypisanie przedmiotów pracy do obszaru systemu tworzenia wartości

 

W kolejnym kroku metodyki Riva, z każdym z przedmiotów pracy należy związać trzy rodzaje procesów, kategoryzowanych jako:

  • case process – proces, którego instancje będą tworzone dla każdej instancji przedmiotu pracy (w naszym przypadku, dla każdego z produktów kredytowych, rozumianych katalogowo) i będą odpowiadały za operowanie na instancji przez cały cykl jej życia.
  • case management process – proces jednoinstancyjny, którego zadaniem jest zarządzanie instancjami typu case process, uruchomionymi dla określonego przedmiotu pracy,
  • strategy process – proces jednoinstancyjny, którego celem jest dokonywanie strategicznych przesądzeń dla danego przedmiotu pracy (na przykład, ustalanie reguł biznesowych związanych z danym przedmiotem pracy).

Prócz utworzenia procesów, metodyka wskazuje na relacje je łączące, bazując jednakże bardziej na charakterze relacji, niźli konkretnym jej kontekście. Przykład przekształcenia  omawianych dwóch przedmiotów pracy oraz relacji generates na architekturę procesów przedstawia poniższy diagram. Zgodnie z regułą, dla każdego z dwóch przedmiotów pracy utworzono po 3 diagramy różnych typów. Bazując na relacji generates prowadzącej od Produktu kredytowego do Badania jakościowego, utworzono dwie relacje:

  • jedną pomiędzy procesem Utrzymanie produktu kredytowego a Zarządzanie badaniami jakościowymi, reprezentującą prośbę o uruchomienie badania jakościowego (a precyzyjniej, utworzenie instancji procesu Przeprowadzenie badania jakościowego), za których koordynacje proces odpowiada.
  • drugą pomiędzy Zarządzaniem produktami kredytowymi a Zarządzaniem badaniami jakościowymi, reprezentującą fakt mediacji pomiędzy procesami zarządczymi w sytuacji, gdy nie można uzyskać kompromisu w poprzednio opisanej komunikacji.

 

APB.png

Architektura procesów biznesowych

 

Opisany sposób transformacji przedmiotów pracy na architekturę procesów zgodnie z przedstawionym wzorcem jest nazywany w metodyce Riva tworzeniem pierwszej wersji architektury procesów (ang. first cut architecture). W kolejnym kroku, należy skonfrontować tak powstały obraz architektoniczny z rzeczywistością organizacyjną, w efekcie czego może dojść do uproszczenia modelu – na przykład poprzez redukcję relacji, przypisanie odpowiedzialności niektórych procesów, w sytuacji, gdy działania w procesach są trywialne, do innych procesów, itp. Oczywiście, na potrzeby niniejszego wpisu, zasady tworzenia powiązań pomiędzy przedmiotami pracy oraz transformacji na pierwszą wersję architektury zostały przedstawione wybiórczo, aby jedynie zaprezentować samą koncepcję. Cała pozostała złożoność metodyki Riva w tym zakresie pozwala na pokazanie większej liczby odcieni szarości, jakie mogą wystąpić podczas tworzenia architektury procesów.

Zidentyfikowane w powyżej przedstawiony sposób procesy oraz relacje występujące pomiędzy nimi, stanowią kolejny etap, jawnie ujęty w metodyce G. Rummlera, dekompozycji systemu tworzenia wartości. W rozważanym przykładzie, udało nam się stworzyć fragment architektury w pełni zawierający się w obszarze Wytworzenia, systemu wartości dla Produktu kredytowego. Docelowo, w ten sposób można byłoby wytworzyć architekturę dla wszystkich trzech obszarów, pokazując w jaki sposób, na poziomie samych deklaracji procesów realizowana jest praca (łącznie z informacjami zwrotnymi) mająca na celu dostarczać Klientom produktu i usługi z danego obszaru biznesowego.

 

VCS (L2) v3ap

Drugi  poziom dekompozycji systemu tworzenia wartości

Metodyka G. Rummlera wprowadza kolejne poziomy dekompozycji, prowadzące, poprzez opisy przebiegów poszczególnych procesów biznesowych, do poziomu opisu odpowiedzialności na poszczególnych rodzajach stanowisk pracy. Z uwagi jednakże na fakt, iż wpis dotyczy jedynie tematu architektury procesów, na tym etapie zakończę już wpis.

Na zakończenie pragnę zwrócić jeszcze uwagę na kilka mniej, lub bardziej jawnie ujętych wcześniej zagadnień, które warto przy tej okazji zgłębić.

Po pierwsze, z przedstawionej koncepcji dochodzenia do architektury procesów biznesowych jawnie wynika, iż jest ona integralną częścią większego systemu, jakim jest opis organizacji. Co więcej, nie jest nadrzędnym elementem, co oznacza, iż tworzenie architektury procesów biznesowych musi być poprzedzone wcześniejszymi pracami, mającymi skutkować utworzeniem kontekstu biznesowego dla niej. W aktualnie obowiązującej terminologii, można byłoby stwierdzić, iż architektura procesów biznesowych jest składową architektury biznesowej, z którą powinna być zgodna.

Po drugie, koncepcje Mapy supersystemowej oraz systemów tworzenia wartości zostały przedstawione jedynie w aspekcie dochodzenia do architektury procesów. Zupełnie pominąłem aspekt zarządzania wykonaniem organizacji (ang. performance management), bez którego w praktyce nie ma sensu tworzyć takiego modelu. Bardzo upraszczając, konstruowany opis organizacji należy uzupełnić o stawiane na różnych poziomach cele, uwzględnić zakres oraz sposoby pomiarów celów oraz przewidzieć mechanizmy, które pozwolą na analizę i podejmowanie działań, mających na celu usunięcie nieakceptowalnych rozbieżności pomiędzy planem a realizacją.

Po trzecie, chciałbym jawnie stwierdzić, iż architektura biznesowa obejmuje zakres jeszcze szerszy, niż to co zostało opisane we wpisie i dodane w pierwszych dwóch punktach uzupełnienia. Patrząc z punktu widzenia samej struktury informacji, pominąłem modele decyzyjne, reguły biznesowe, cały model opisujący plan biznesowy organizacji oraz wiele innych elementów, których stosowanie jest uzależnione od specyfiki organizacji. Warto mieć to na uwadze próbując wdrażać techniki analizy biznesowej, gdyż praktyka pokazuje, że bardzo często realizacja jednych prac rodzi konieczność wdrożenia do analitycznego przybornika nowych technik, które to z kolei… w ten sposób, ewolucyjnie, można wdrażać analizę biznesową i architekturę biznesową. Aby to jednak zadziałało należy mieć metodykę, należy dysponować mechanizmami pozwalającymi na jej rozbudowę, zasobami ludzkimi, które tę trudną pracę wykonają oraz dużo cierpliwości, gdyż nie od razu Kraków zbudowano. Próba pójścia na skróty z pewnością, wcześniej, czy później, zawiedzie.


Licencja Creative Commons
Ten utwór jest dostępny na licencji Creative Commons Uznanie autorstwa – Bez utworów zależnych 4.0 Międzynarodowe.

Wykonanie. Performance.

Geary Rummler

Geary Rummler

Geary Rummler, osoba, która wniosła fundamentalny wkład w rozwój Business Process Management, jednym tchem jest wymieniana jako współtwórca koncepcji Performance Improvement. Performance – przetłumaczony w AION jako Wykonanie – jest sumą wartości produktu oraz działań prowadzących do jego powstania i stanowi kluczowy czynnik wyznaczający jakość działań prowadzonych przez dowolna organizację. I o Wykonaniu będzie niniejszy wpis.

Ostatnimi czasy miałem sporo okazji do zajmowania się tematem budowania kompetencji, w szczególności w oparciu o transfer wiedzy.  Ponieważ analiza biznesowa należy do grupy profesji wysoce specjalizowanych, w przypadku których proces budowania kompetencji liczy się w dziesiątkach lat, niezmiennie od lat pojawia się problem sposobu efektywnego transferu wiedzy oraz celowości takich działań z punktu widzenia organizacji (najczęstszy zarzut, „wyszkolimy człowieka, a on wówczas albo zażąda ogromnej podwyżki, albo zmieni pracodawcę”).

Niełatwo podać proste i oczywiste odpowiedzi na zgłaszane wątpliwości. W efekcie, analitycy biznesowi – w organizacjach, w których miałem okazję przebywać wystarczająco długo bądź intensywnie, by cokolwiek wartościowego zaobserwować – są pozostawieni, w dużej mierze, sami sobie, jeśli chodzi o budowanie własnych kompetencji. A ponieważ dziedzina jest interdyscyplinarna, oparta o ogromny obszar wiedzy oraz wymagająca budowania doświadczenia, samodzielne podnoszenie kwalifikacji jest drogą przez mękę (by nie rzec, syzyfowa pracą).

Wspomniałem o Gearym Rummlerze nieprzypadkowo. Ostatnio bowiem po raz kolejny przekonałem się, iż najciemniej jest pod latarnią (pierwszym zawodowym certyfikatem, jaki uzyskałem, było poświadczenie znajomości metodyki Gearego Rummlera i uzyskanie uprawnień trenerskich i doradczych w jej obszarze). Przygotowując się do spotkania dotyczącego budowania kompetencji zastanawiałem się w jaki sposób uzasadnić:

  • celowość wieloletniego inwestowania w ludzi z punktu widzenia organizacji,
  • celowość ewaluacji procesu budowania kompetencji

oraz wskazać sposób na budowanie kompetencji analitycznych. Niby to oczywiste. Niby zrozumiałe. Niby zasadne.

Geary Rummler stwierdził podczas jednej z konferencji

Organizations are systems, and people are only as good as the system that they are in.

Bingo! Należy z jednej strony pokazać, że kompetencje pracowników mogą wpłynąć na funkcjonowanie organizacji, ale z drugiej strony, że organizacja musi być gotowa do wykorzystania kompetencji swoich pracowników. Kontynuując nawiązania do Gearego Rummlera, należy przedstawić ideę Performance Improvement. W proponowanym przez Rummlera podejściu do usprawniania wykonania, należy skoncentrować się na trzech jego poziomach wykonania:

  • poziomie organizacji,
  • poziomie procesów biznesowych (a w zasadzie, systemów tworzenia wartości – ang. value creation system), oraz
  • poziomie pracownika.

Koncentracja polega na stworzeniu takiego systemu, w którym wszystkie poziomy pozostają ze sobą w synergii – innymi słowy, są ze sobą zgodne. Zainteresowanych tematem metodyki Geary’ego Runnlera odsyłam do jego publikacji, w szczególności Improving Performance: How to Manage the White Space in the Organization Chart oraz White Space Revisited: Creating Value through Process.

Ponieważ zagadnienie, z jakim miałem się zmierzyć, koncentrowało się przede wszystkim wokół ludzi, ich kompetencji oraz rozwoju w zgodzie z oczekiwaniami organizacji, potrzebowałem podparcia w teorii przyjmującej ten punkt widzenia na Wykonanie. Kierunek był w miarę oczywisty Human Performance Technology (HPT). Dojrzała, ale ciągle rozwijająca się dziedzina wiedzy, wspierana działaniami stowarzyszenia International Society for Performance Improvement (ISPI) promującego koncepcję HPT oraz autorytety z dziedziny, o których w dalszej części. ISPI definiuje HPT jak poniżej:

Human Performance Technology, a systematic approach to improving productivity and competence, uses a set of methods and procedures — and a strategy for solving problems — for realizing opportunities related to the performance of people.

natomiast działania wymagane do osiągnięcia docelowego stanu wykonania opisuje w postaci modelu.

Model HPT (źródło ispi.org)

Model HPT (źródło ispi.org)

Model jest dość prosty (co nie oznacza, iż jego wdrożenie w życie jest także proste) i można go streścić jako konieczność zaplanowania i zrealizowania interwencji w systemie w sytuacji, gdy zostanie zdiagnozowana przyczyna źródłowa różnicy pomiędzy pożądanym stanem wykonania a stanem aktualnym. Istotnym elementem modelu jest stała ewaluacja wykonania.

W scenariuszu, gdy przyczyną źródłową rozbieżności pomiędzy stanem docelowym a aktualnym są niewystarczające kompetencje pracowników, interwencja polegać może na wdrożeniu działań podnoszących kompetencje, na przykład szkoleń, poddawanych stałej ewaluacji pod kątem wykonania. W przypadku szkoleń, ISPI jawnie powołuje się na prace Kirkpatricka, którego model ewaluacji stosujemy od lat.

Tak oto, kompetencje pracowników zostały systemowo wkomponowane w model opisujący organizację, stanowiąc jeden z czynników wpływających na wskaźniki wykonania, a ewaluacja została wskazana jako kluczowy czynnik osiągania sukcesu w tym zakresie.

Niby to oczywiste. Niby zrozumiałe. Niby zasadne. Skąd więc ten opór przed wdrażaniem?


Licencja Creative Commons
Ten utwór jest dostępny na licencji Creative Commons Uznanie autorstwa – Bez utworów zależnych 4.0 Międzynarodowe.

Model a dokumentacja, czyli pomieszanie z poplątaniem

 

„Biznes tego nie przeczyta!”

TrudnyModel2To jeden z najczęstszych komentarzy pojawiających się po zaprezentowaniu metod tworzenia spójnej, jednolitej i pozbawionej redundancji architektury biznesowej. Powiązane ze sobą w modelu plany biznesowe, opisy procesów biznesowych, modele koncepcji, reguły biznesowe, reguły decyzyjne, wymagania wobec IT tworzą skomplikowaną sieć wzajemnych relacji, oddając jednocześnie opisywaną rzeczywistość.

„Biznes tego nie przeczyta!”

Trudno się z tym stwierdzeniem nie zgodzić. Powiązane ze sobą w modelu plany biznesowe, opisy procesów biznesowych, modele koncepcji, reguły biznesowe, reguły decyzyjne, wymagania wobec IT tworzą skomplikowaną sieć wzajemnych relacji, która jest niełatwa do opracowania i interpretacji dla analityków biznesowych, mających w zakresie swoich obowiązków pracę z tego typu narzędziami inżynierskimi. Tym bardziej, niełatwo się w modelu poruszać specjalistom dziedzinowym, uczestniczącym w pracach analitycznych.

„Po co w takim razie tworzyć modele biznesu w ten sposób, skoro biznes tego nie przeczyta?!”

Narzędzia inżynierskie, których stosowanie skutkuje utworzeniem modelu, służą przede wszystkim analitykom biznesowym do prowadzenia prac według przyjętej metodyki. Nie stanowią więc li tylko języka komunikacji na linii zespół analityczny – specjaliści dziedzinowi, i w związku z tym ich użyteczność powinna być rozpatrywana w dużo szerszym kontekście, jako narzędzie:

  • analizy pozyskanych od specjalistów dziedzinowych informacji,
  • zwięzłego i jednoznacznego zapisu informacji, zgodnego z przyjętą metodyką prowadzenia prac,
  • weryfikacji i walidacji efektów analizy,
  • podziału pracy pomiędzy członkami zespołu analitycznego,
  • komunikacji pomiędzy członkami zespołu analitycznego,
  • stanowiące bazę do komunikacji analityk biznesowy – pozostali interesariusze przedsięwzięcia.

Biznes, stanowiąc bardzo ważną kategorię interesariuszy, powinien mieć dostęp do wiedzy zapisanej w modelu, w zakresie adekwatnym do powierzonego zadania i w czasie, który wynika ze sposobu prowadzonych w zgodzie z przyjętą metodyką prac.

„W jaki sposób biznes ma to przeczytać?!”

Biznes nie musi, aczkolwiek może, czytać model. Przede wszystkim, biznes musi wejść w posiadanie potrzebnej do prowadzenia prac wiedzy. Narzędziem, jakim dysponuje, jest kontakt z analitykiem biznesowym. Najczęstszy kontakt, to prace warsztatowe oraz indywidualne spotkania, w trakcie których następuje transfer wiedzy w obie strony. W trakcie sesji analitycznych, osoby w nich uczestniczące poznają się wzajemnie, poznają styl oraz metody pracy, a czasami nabierają wzajemnego zaufania, które zawsze pomaga. Analitycy nabywają wiedzę dziedzinową, natomiast specjaliści dziedzinowi, co najmniej podstawową wiedzę z zakresu stosowanych metod pracy oraz wykorzystywanych w projekcie inżynierskich środków wyrazu. Z czasem umożliwia to – wprawdzie, w ograniczonym zakresie –  ocenę efektów prac poza sesjami analitycznymi.

W sytuacjach, w których wymagana jest formalna, kompleksowa weryfikacja efektów prac, takie pół-formalne środki nie są wystarczające. W tych momentach, na analityku biznesowym ciąży obowiązek przekazania wiedzy w sposób, który umożliwi wszystkim stronom uczestniczącym w przeglądach prac zrozumienie wiedzy zapisanej w modelu i odniesienie się do niej. W tym celu mogą zostać zorganizowane warsztaty, w trakcie których specjaliści dziedzinowi, prowadzeni przez analityków biznesowych, weryfikują informacje odnotowane w modelu, lub mogą zostać przeprowadzone prezentacje, w trakcie których, w sposób zrozumiały dla specjalistów dziedzinowych, przedstawiana jest wiedza zapisana w modelu. Dodatkowo, gdy zasadne jest przeprowadzenie przez specjalistów dziedzinowych samodzielnej oceny efektów prac, konieczne może być przygotowanie dedykowanych temu zadaniu dokumentów, w których wiedza z modelu jest zapisana w języku naturalnym, naturalnym dla specjalistów dziedzinowych. Efekty tak przeprowadzonej oceny są analizowane przez analityków biznesowych, co może spowodować konieczność aktualizacji modelu.

„I kto za to płaci?”

Oczywiście, sponsor przedsięwzięcia. Jest to jego koszt. Błędem byłoby jednakże traktowanie takiego wydatku jako kosztu dodatkowego. Jest to naturalny koszt prowadzenia prac, w których uczestniczą grupy osób na co dzień posługujących się innymi środkami wyrazu. Jako dodatkowy koszt należałoby traktować te działania, które wynikają z nakazania którejkolwiek ze stron posługiwania się nienaturalnym dla siebie językiem. Tak samo negatywnie więc należy ocenić próby wymuszenia na specjalistach dziedzinowych samodzielnego tworzenia modeli, jak i na analitykach biznesowych, posługiwania się różnej maści edytorami tekstu lub tabelek. Prowadzone w ten sposób prace byłyby zarówno droższe jak i mniej skuteczne (*).

A dokumentacja?

Jaka dokumentacja? Jest przecież model. Zawsze aktualny, stale rozwijany, użyteczny i interpretowany różnym interesariuszom we właściwym czasie.

(*) Zagadnienie, które zostanie poruszone w kolejnych wpisach.