Analityk biznesowy vs. Architekt biznesowy
Jednym z często dyskutowanych tematów podczas szkoleń, kursów i konferencji j poświęconych EA jest właściwa struktura i umocowanie komórki architektonicznej w organizacji. O ile nie budzi już większych emocji stwierdzenie (co nie oznacza, że jest to proste do osiągnięcia w praktyce), że zespół zajmujący się architekturą korporacyjną powinien być umocowany w hierarchii organizacyjnej maksymalnie wysoko (najlepiej pod CxO), o tyle skład takiego zespołu bywa bardzo różnie interpretowany.
W szczególności pojawia się pytanie, czy w skład zespołu architektonicznego powinni wchodzić analitycy biznesowi i czym się oni różnią od architektów biznesowych.
Punktem do poniższych rozważań jest wpis opublikowany na blogu Nicka Malika (i komentarze do tego wpisu), architekta w firmie Microsoft. Nick zauważył, że analityk biznesowy pełni o wiele bardziej operacyjną rolę niż architekt biznesowy. Wynika to z faktu, że analityk biznesowy musi w szczegółach zrozumieć problemy biznesowe i udokumentować odpowiednie wymagania, które będą stanowiły punkt wyjścia do opracowania określonego rozwiązania. Ale to nie analityk biznesowy jest odpowiedzialny za opracowanie tego rozwiązania, ani nawet za jego wizję – za te czynności odpowiada architekt.
Rolę architekta biznesowego można, według Nicka, rozpatrywać przez pryzmat czterech różnych płaszczyzn:
- zrozumienie rzeczywistych, na poziomie całej organizacji, potrzeb pomiędzy poszczególnymi liniami biznesowymi w odniesieniu do ogólnej strategii biznesowej,
- partycjonowanie usług, które poszczególne linie biznesowe powinny opracowywać i wskazanie mechanizmów ich współpracy,
- tworzenie wizji wykorzystania tych usług, z punktu widzenia całej organizacji,
- zapewnienie, że te usługi będą dopasowane do opracowanej wizji architektury organizacji.
Poniżej (w wybiórczy sposób) porównałem odpowiedzialności architekta biznesowego z odpowiedzialnościami analityka biznesowego.
| Architekt biznesowy | Analityk biznesowy |
| Przyjmuje perspektywę wartości biznesowej dostarczanej przez całą organizację. | Przyjmuje perspektywę wartości biznesowej dostarczanej przez konkretny projekt. |
| Współpracuje z dyrektorami programów, w celu ustalenia zakresu prac realizowanych w poszczególnych programach. | Współpracuje z kierownikiem projektu, w celu ustalenia zakresu prac realizowanych w tym projekcie. |
| Koncentruje się na zależnościach między programami. | Koncentruje się na zależnościach wewnątrz projektu. |
| Ustala ze sponsorami budżety na poszczególne transze programów. | Pracuje na ustalonym budżecie. |
| Współpracuje z architektem IT. | Współpracuje z analitykiem systemowym. |
Działania analityka biznesowego są więc komplementarne w stosunku do prac architekta biznesowego. Mają charakter bardziej granularny (wyraża się to także w proporcjach zespołu – w sieci można znaleźć np. taką statystykę: zespół 4 architektów biznesowych pracuje z zespołem 30 analityków biznesowych). Co więcej analityk biznesowy posługuje się ujęciem “analitycznym” (rozkłada zagadnienie na części), a architekt biznesowy “syntezą” (składa zagadnienie z części).
Komentarze do wpisu
To co mnie niepokoi w tym wpisie to próba budowania dychotomicznego podziału pomiędzy architektem a analitykiem. Doceniam próbę zdefiniowania różnic pomiędzy tymi rolami, ale jest to moim zdaniem próba nietrafiona. Gdyby ją czytać dosłownie można by dojść do wniosku, że np. analityk biznesowy nie współpracuje z architektem IT. Który z analityków zgodzi się na taką definicję?
Podział na tych co analizują i na tych co syntetyzują też wydaje mi się niecelny. Analiza i synteza to przecież 2 strony tej samej metody badawczej i jako takie nie mogą zostać rozdzielone w praktycznym działaniu (trochę mi to przypomina próbę dzielenia kierowców na tych, którzy podczas jazdy używają hamulca i na tych, którzy używają gazu). Dlatego zakładam, że autorowi chodziło raczej o podkreślenie, że różnica pomiędzy architektem a analitykiem polega na różnym rozłożeniu akcentów syntezy i analizy, w zależności od tego jaką rolę pełni się przy rozwiązywaniu danego problemu, a nie w zależności od tego jakie stanowisko się piastuje. Szkoda jednak, że nie zostało to wyłożone explicite.
Nie poświęcałbym temu tematowi tyle uwagi, gdyby nie fakt, że bałagan pojęciowy wokół ról i stanowisk powoduje coraz większe nieporozumienia i jest coraz bardziej uciążliwy w codziennej pracy. Przy próbie „wyczyszczenia” tematu proponowałbym jednak sięgnąć do źródła. W przypadku analizy biznesowej jest nim np. IIBA, która analizę biznesową definiuje tak:
"Business analysis is the set of tasks and techniques used to work as a liaison among stakeholders in order to understand the structure, policies, and operations of an organization, and to recommend solutions that enable the organization to achieve its goals."
Ani słowa o wymaganiach. Ani słowa o projektach. Na pierwszy rzut oka może się to wydawać dziwne, prawda?
Zaproponowany przez autora sposób widzenia analityka biznesowego jest typowy dla osób wywodzących się z działów IT lub firm wytwarzających oprogramowanie (to nie obelga, bo sam się za taką osobę uważam!), dla osób, którym przez doświadczenie bliższa jest inżynieria produkcji niż doradztwo i konsulting. Tam rzeczywiście oczekiwano od analityka zebrania wymagań (cichym założeniem było, że klient te wymagania ma, zna i umie je wyartykułować, a rolą analityka jest tylko ich spisanie) i przekazania ich zespołowi odpowiedzialnemu za implementację. Patrzono na funkcję analityka biznesowego jak na rolę projektową, działającą w jasno określonych harmonogramem i budżetem ramach, gdzie nie ma już miejsca np. na weryfikację uzasadnienia biznesowego projektu. Dodatkowo, w tych wszystkich projektach produktem projektu był działający soft. To jeszcze bardziej wzmacniało konotację analityk = projekt = produkcja oprogramowania.
Z czasem jednak, gdy technologie informatyczne zaczęły 'drive'ować' biznes, a nie tylko go wspierać, działy IT i dostawcy stanęli przed kolejnym wyzwaniem: jak skutecznie wdrażać zmiany w architekturze IT w sytuacji, gdy zmiana ta nie jest już tylko prostą wymianą starego ołówka na nowy, lecz zmianą wpływającą na model biznesowy i strategię firmy? I tak, na scenie zagościła architektura korporacyjna, z architektami korporacyjnymi i biznesowymi.
Ale osoby postrzegające analizę biznesową bardziej jako 'advisory' niż 'requirements recording' nie są bezczynne. Jeśli spojrzymy czy to na kierunek w jakim rozwija się praktyka zawodu analityka, czy to na literaturę „teoretyczną” trendsetterów ze stajni IIBA, to zobaczymy wyraźnie, że pojęcie analizy biznesowej zaczyna odnosić się do rozwiązywania problemów w skali całej organizacji. Rola analityka biznesowego traktowana jest jako rola organizacyjna, a nie projektowa!
Firmy, działając w coraz bardziej złożonym i coraz bardziej dynamicznym otoczeniu, potrzebują osób, które będą potrafiły organizację oswoić ze wszechobecną zmianą. Nie chodzi tu o osoby z konkretnym wykształceniem czy z wiedzą z konkretnego obszaru firmy, lecz o osoby posiadające niepowtarzalny zestaw predyspozycji. Ten zestaw ma pozwalać efektywnie rozwiązywać problemy biznesowe i pomagać decydentom podejmować decyzje, dzięki którym organizacja jako całość będzie przesuwać się w założonym kierunku. Do tego muszą to być osoby, które doskonale rozumieją swoją rolę i zgadzają się na nią (np. na to, że nie jest to i nigdy nie będzie rola pierwszoplanowa i na to, że będzie to rola, której przydatność zawsze będzie poddawana w wątpliwość, a w czasach kryzysu będzie pierwszym kandydatem „do cięcia”).
Ta nowa rola jednak w naturalny sposób „wypycha” analityków w stronę CxO tak samo, jak architektura korporacyjna wypycha w tę stronę najbardziej „proklienckie” i najbardziej „liderskie” osobowości z zespołów developerskich.
Dlaczego zatem uważam, że próba rozdzielenia roli architekta i analityka przez autora jest nietrafiona? Dlatego, że odmienność tych pojęć jest raczej zaszłością historyczną i dlatego, że zakres obowiązków architekta opisany w tekście całkowicie wpisuje się we współczesną definicję analizy biznesowej. Należałoby więc raczej uznać, że architekt biznesowy jest specyficznym typem analityka biznesowego, a nie bytem osobnym, równorzędnym. Jest typem analityka, który zajmuje się rzecz jasna tymi "największymi" i "najgrubszymi" problemami całej organizacji (co może powodować złudzenie, że jego zadaniem jest 'synteza'). Ale to wynika z umiejscowienia w strukturze i oczekiwań jego klientów (którymi przeważnie są CxO). Taki architekt wykorzystuje w swojej pracy ten sam zestaw narzędzi, kompetencji i umiejętności, jakiego używają "mniejsi" analitycy, rozwiązujący problemy taktyczne czy operacyjne.
Co więcej, wszyscy którzy wykonują analogiczną pracę, choć mogą nazywać się rozmaicie (analitycy strategiczni, procesowi, funkcjonalni, architekci biznesowi, korporacyjni, itp.) są analitykami biznesowymi. Nie dlatego, że wykonują (jak pracownicy fabryczni) te same czynności przy taśmie produkcyjnej, lecz dlatego, że pełnią tę samą rolę w procesie decyzyjnym i wykorzystują te same narzędzia do poszukiwania optymalnych rozwiązań. Uświadomienie sobie tego faktu może mieć istotne znaczenie np. przy podejmowaniu decyzji dot. struktury organizacyjnej firmy.
Dodaj komentarz