Analityk Systemowy – łącznik dwóch światów
Słownikowa definicja analityka systemowego mówi, że jest to osoba, która potrafi analizować złożone problemy organizacji w celu opisania tych problemów i przedstawienia ich w formie możliwej do przetwarzania przez systemy informatyczne. No dobrze, ale co to tak naprawdę znaczy? Kto powinien być analitykiem systemowym, informatyk, czy znawca badanej dziedziny? Jaką uczelnię powinien skończyć, aby poprawnie wywiązywać się ze swoich zadań? Powinien reprezentować interesariuszy biznesowych, a może zespół informatyczny, który będzie wykonywał prace projektowe. Gdzie w ogóle uczą bycia analitykiem systemowym? Hm, sporo tych pytań i nie bardzo wiadomo jak na nie odpowiedzieć. Ja jednak spróbuje to zrobić w tym artykule.
Wróćmy na początek do definicji. Wygląda na to, że analityk systemowy powinien przynajmniej być w stanie zrozumieć daną dziedzinę biznesową, bo inaczej jak by miał analizować „złożone problemy organizacji”. Tę tezę potwierdza również fakt, że musi to wszystko później opisać ludziom, którzy będą implementować jego rozwiązania w systemie informatycznym. Musi to zrobić w taki sposób, aby nie powtórzyła się znana historyjka z huśtawką (gdzie huśtawka spełnia wszystkie wymagania, ale nie da się na niej huśtać).
A więc analityk systemowy nie tylko musi zebrać wymagania i przetłumaczyć je na język bardziej strawny przez informatyków, ale również dopilnować, aby jego intencje zostały zrealizowane we właściwy sposób przez zespół informatyczny.
Spójrzmy na sprawę z jeszcze innej perspektywy. Co będzie jeśli wymagania są zebrane, system w połowie zaimplementowany, a rząd wprowadzi nową ustawę, która całkowicie wywróci projekt do góry nogami? Albo co będzie jak sprawdzi się powszechna opinia, że użytkownicy biznesowi sami nie wiedzą czego chcą dopóki czegoś nie zobaczą? Kto wtedy będzie odpowiedzialny za wyprostowanie sprawy?
Kto powinien być analitykiem systemowym?
Najlepiej jakby była to osoba z doświadczeniem. Wynika to z tego, że rzadko uczy się na uczelniach analizy systemowej. Na informatyce jest to elementem inżynierii oprogramowania i uczą tego zwykle informatycy. Z kolei na uczelniach dziedzinowych gorzej jest z nauczaniem elementów „twardej” wiedzy informatycznej (oczywiście pewnie znajda się wyjątki). A tymczasem analityk powinien być dość zaawansowany technicznie, aby wiedział co się da zrobić, a czego nie. Z drugiej strony powinien umieć słuchać i nie bać się pytać, gdy czegoś nie rozumie. Parafrazując znaną maksymę „analityk ma dwoje uszu, a tylko jedne usta po to, aby dwa razy więcej słuchać niż mówić”. Jednak mówić powinien, szczególnie wypytać o wszystko czego nie rozumie, więc nieśmiałość i poczucie wstydu z byle powodu odpada.
Dodatkowo bardzo przydatne jest, jeśli analityk zna się na dziedzinie, której problemy analizuje. Analityk będzie dużo rozmawiał z biznesem i jeśli będzie ciągle zadawał pytania w stylu „co to jest prolongata” doprowadzi do irytacji swoich rozmówców. Ale i tak lepsze to niż udawać, że się wszystko rozumie.
Rola i odpowiedzialność w projekcie
Z grubsza rzecz biorąc, rolą analityka systemowego w projekcie jest zbieranie i zarządzanie wymaganiami. Aby tego dokonać analityk musi zadbać o to, aby znane mu były przynajmniej te procesy biznesowe, które mają jakąś interakcję z budowanym systemem.
Po zrozumieniu niezbędnych procesów biznesowych, analityk systemowy zajmuje się wydobywaniem wymagań na system. Musi zatem zlokalizować miejsca styku procesów biznesowych z systemem i opisać to, jak w poszczególnych procesach biznesowych wykorzystywany będzie system i kto z niego będzie w tych miejscach korzystał. Do opisywania tej części rzeczywistości, analityk na szczęście ma stosowne narzędzia, a na ich czele stoi UML (ang. Unified Modeling Language).
W następnym etapie, analityk musi opisać jak dana interakcja z systemem (przypadek użycia) będzie obsługiwana przez system.
Warsztat łącznika dwóch światów
Procesy biznesowe – niby nie jest niezbędne ich rozumienie, zawsze można skupić się na wymaganiach funkcjonalnych i zapomnieć o zrozumieniu merytoryki procesów biznesowych. Jednak użytkownicy, którzy opowiadają o swoich wymaganiach zwykli o czymś zapominać. Ponieważ lepiej żeby sobie przypomnieli już na samym początku, podczas rozmów o tym jak pracują i próby zrozumienia procesów biznesowych, można ograniczyć przeoczenia, czy niedociągnięcia. Trzeba też pamiętać, że ludzie biznesu nie robią tego złośliwie, raczej niektóre rzeczy wydają się tak oczywiste, że „nie warto o nich wspominać”. Do modelowania procesów biznesowych można wykorzystać diagramy aktywności w UML. Są też bardziej dedykowane notacje, jak BPMN (ang. Business Process Modeling Notation).
Funkcjonalność systemu – do modelowania funkcjonalności używa się zwykle diagramu przypadków użycia (ang. Use Case Diagram). Są na nim dwa główne artefakty. Pierwszy z nich – Aktor – obrazuje osobę lub urządzenie korzystające z systemu. Drugi artefakt, to Przypadek użycia (ang. Use Case) odzwierciedla on funkcję systemu, którą wykorzystuje Aktor. Należy zaznaczyć, że aktor jest zawsze na zewnątrz Systemu, a Przypadek użycia obrazuje to, co się dzieje wewnątrz.
Realizacja funkcji systemu – aby dowiedzieć się jak działa dana funkcja systemu niezbędny jest opis danego przypadku użycia. Służą do tego scenariusze. Można je opisywać za pomocą języka naturalnego, lub skorzystać z części UML jaką są diagramy aktywności.
Narzędzi informatycznych wspierających opisywanie systemów za pomocą języka UML jest mnóstwo. Niektóre próbują nawet (z lepszym lub gorszym skutkiem) z takiego opisu generować gotowy kod systemu lub przynajmniej szkielet kodu, który później programista może uzupełnić.
Ciekawa nisza
Z punktu widzenia planowania kariery zawodowej, niewątpliwie warto rozważyć karierę analityka systemowego. Jeśli już przepracujemy przed ekranem monitora wiele godzin i przejdzie nam ochota na poznawanie kolejnego rewolucyjnego języka programowania warto rozważyć pracę bliżej biznesu. Dzięki temu można poznać wielu ciekawych ludzi, a charakter tej pracy da nam również możliwość poznania wielu dziedzin biznesowych, bo przygotowując wymagania na system informatyczny można naprawdę dużo dowiedzieć się o tym jak działają nawet najbardziej złożone organizacje.
Jeśli więc lubisz technologię i nie chcesz się z nią całkowicie rozstawać, a jednocześnie chciałbyś poszerzać swoje horyzonty, polecam zajęcie analityka systemowego. Może się okazać, że z czasem zagniesz swoją wiedzą o bankowości niejednego bankowca, a o księgowości niejednego księgowego.
Tags: analityk, analiza, biznes, informatyka, kariera, modelowanie
Posted in Analiza systemowa, Biznes, Informatyka | 22 komentarzy »
Dobry analityk systemowy to skarb – tyle, że trudno go znaleźć. Bo musi to być osoba ze znajomością informatyki, technologii, języków programowania – po to by zdobyć się choćby na cień refleksji czy zrealizowanie danej potrzeby biznesowej jest wykonalne i ile może kosztować.
Z drugiej strony musi to być ktoś o osobowości zupełnie nieinformatycznej – potrafiący/a dobrze zrozumieć model biznesowy, poczuć po co budowany jest system, jakie potrzeby świata rzeczywistego ma realizować i dodatku osoba taka musi być bardzo kontaktowa (analityk mniej więcej połowę czasu spędza na rozmowach z ludźmi od “biznesu”).
A taką osobę – łącząca ze sobą dwa zupełnie inne światy, nie jest wcale tak łatwo znaleźć.
Tak, taką osobę jest znaleźć trudno i łatwiej ją chyba wychować niż znaleźć samorodka
Wynika to chyba z tego, że osoby “zajmujące się komputerami” są z definicji introwertyczne, inaczej nie siedziałyby z nosem w komputerze non stop, a introwertykom ciężko gadać z ludźmi i ich słuchać, uznać, że Ci ludzie mogą wiedzieć coś więcej w jakiejś dziedzinie od superinteligentnego informatyka. Dlatego uważam, że dobry analityk systemowy musi wyewoluować z dobrego komputerowca.
1. Najpierw jest introwertyczny i poznaje dogłębnie technologię siedząc po nocach z nosem wetkniętym w komputer.
2. Potem staje się pokornym, słuchającym ludzi i otwartym człowiekiem, który na zaplecze technologiczne.
Tak, to trudne, ale możliwe
Witam! U mnie w firmie są analitycy po kierunkach humanistycznych i radzą sobie bardzo dobrze , chyba lepiej nawet jest jeśli osoba, która nie miała wcześniej do czynienia z informatyką zabiera się za ten temat , a jeśli jest to osoba dla której ścisłe myślenie nie sprawia problem to już super . Ale dziewczyny radzą sobie dobrze i nadrabiają wiedzę informatyczną , ale za to mają inne lepsze spojrzenie na cały proces wytwarzania oprogramowania . Coś w tym jest
Dwie kwestie mi się nasuwają: definicje analityka systemowy i analityku biznesowy to w istocie te same kompetencje: skoro “jest to osoba, która potrafi analizować złożone problemy organizacji w celu opisania tych problemów i przedstawienia ich w formie możliwej do przetwarzania przez systemy informatyczne” to zaciera się granica pomiędzy powszechnie używanymi pojęciami: analityk systemowy i biznesowy bo wedle tej definicji obaj robią to sam ! (z czym się zgadzam).
Co do komentarzy przedmówców: nie znam studiów, na których uczy się modelowania organizacji w sposób zdatny do bezpośredniej implementacji choć mogę powiedzieć, że się da bo to robię. Natomiast nie zgodzę się z tezą, że taki analityk musi być programistą (także w przeszłości)bo to raczej “skrzywi” go w kierunku “myślenia implementacją” czego akurat należy unikać na etapie analizy bo jej wynik daje w opis tego co jest potrzebne a nie tego co ktoś potrafi wykonać.
[...] także inne ciekawe spojrzenie na ten problem w artykule Analityk systemowy – łącznik dwóch światów. Tu faktycznie staje się problematyczne stwierdzenie kim jest, a kim nie, analityk systemowy. [...]
Dla sprawgnionych wiedzy napewno przydatnym będzie BABOK.
pozdr,
A tak sobie myślę – co z osobą, która skończyła kierunek humanistyczny oraz Informatykę? Czy nadaje się?:)
Znam analityczkę po pedagogice, analityka po politologii i świetnego architekta, który skończył zarówno informatykę jak i filozofię. Nie przeceniajmy tych studiów, można się uczyć bez nich. Poza tym i tak największą wartością jest przecież doświadczenie
Ja lubię tłumaczyć obrazowo i na przykładach. Z projektowaniem systemów jest jak z projektowaniem w budownictwie. Są projektanci oczyszczalni ścieków, mostów, budynków mieszkalnych. Co ich łączy? Każdy musi znać normy budowlane, przepisy prawa, znać technologie itd. Nie wyobrażam sobie żeby jeden “analityk systemowy” był wstanie z takim samym efektem pochylić się nad każdym projektem biznesowym i być dobrym łącznikiem pomiędzy zleceniodawcą a informatykami. Moim zdaniem nie ma czegoś takiego jak łącznik, musi być zespół. Nic analityk systemowy nie zrobi bez piszących kod, ważny jest poziom zaufania.
Nie wyobrażam sobie analityka systemu bez wiedzy jak system powstaje, jakie są technologie, jakie są trendy. Nie powstają tylko systemy dedykowane poprawiające organizację z przedsiębiorstwach np. obieg dokumentów, powstają systemy skierowane do klienta, trzeba trafić w modę, trendy, oczekiwania docelowego klienta systemu. Wracając do terminologii budowlanej. Do zaprojektowania oczyszczalni ścieków, potrzebny jest technolog, specjalista od procesów, konstruktor, projektant – nad tym pracuje zespół. Dom też projektuje konstruktor, architekt od aranżacji wnętrz, od projektowania ogrodów. Co z tego wynika, ŻE NIE MA I NIE BĘDZIE ANALITYKA SYSTEMU OD WSZYSTKIEGO. I jeszcze jedno nie ma ludzi wszechwiedzących i nieomylnych. Uczmy się pracy zespołowej. Tzw. techniki agile’owe, czyli jak jednoosobowo – nie ma takiej opcji, tylko zespół. Tak ja to sobie wyobrażam.
Dodam aspekt dotąd nie podniesiony: umiejętności “miękkie” i “umocowanie”.
Wielokrotnie spotkałem się z sytuacją, gdy w wyniku analizy okazywało się, że oprócz skonstruowania systemu, należałoby nieco zmodyfikować organizację pracy we fragmencie organizacji. Zwykle na tym ktoś zyskuje a ktoś traci. I “obiektywny” wybór opcji jest trudny. Często wprowadzenie nowego systemu jest najbardziej groźne właśnie dla kogoś, kto jest najważniejszym źródłem informacji o tym, jak naprawdę działa firma. Trzeba umieć w takiej delikatnej sytuacji się znaleźć. No i bez dobrego wsparcia ze strony odpowiednio wysoko umocowanego sposora, wykonanie pracy bywa nierealne …
Jestem świeżo po uczelni informatycznej i mogę powiedzieć że brak mi było na niej spojrzenia biznesowego na informatykę- najlepsi w grupie to najczęściej mózgi od programowania ale jakoś mało kto myślał albo dokładniej mówiąc planował założenie własnej firmy informatycznej o charakterze projektowym gdyż najczęstszym hamulcem był kontakt z klient albo wyjście poza sferę warsztatu programisty danego języka dlatego też jak kiedyś w jednym komentarzu wspominałem UML powinien być wykładany jednocześnie z algorytmami i strukturami danych aby pomóc szybciej niż dopiero w pracy zawodowej posiąść elementarne obycie jak postępować aby wytworzyć produkt informatyczny jak nim kierować lub jak go zbywać na rynkach . Sytuacja taka będzie niestety nadal w Polsce istniała gdyż uczelnie mają za małe powiązania z przemysłem bądź rynkami kapitałowo-inwestycyjnymi w obszarze których funkcjonują potrzeby na produkt informatyczny o charakterze systemowym.
Dobry artykuł. Czy analityk powinien mieć wiedzę informatyczną? Moim zdaniem tak, nie dlatego, że musi wiedzieć czy coś da się napisać, bo napisać da się prawie wszystko. Wiedza ta jest potrzebna po to, aby już podczas spisywania wymagań potrafić chociaż zgrubnie oszacować koszty. Analityk powinien też zdawać sobie sprawę co można, a czego nie powinno się zmieniać w trakcie implementacji, bo wymusi to pisanie w zasadzie wszystkiego od nowa albo wręcz zmianę przyjętej technologii (znam takie przypadki). Często to analityk jest jedynym “technicznym” przedstawicielem firmy w rozmowach z klientem, a jak coś się obieca klientowi to często trudno to odkręcić.
Grzegorz: czytając przytoczoną przez Ciebie definicję analityka systemowego, podobnie jak kolega wyżej, zadałem sobie pytanie, jakas jest w takim razie definicja analityka biznesowego bo zwykle rozróżniamy te dwie role :)?
Z moich doświadczeń wynika, że jednak analityk powinien mieć background informatyczny.
Z tymi definicjami często jest problem niestety. Tylko jak nazwać analityka, który zajmuje się zrozumieniem i optymalizacją procesów biznesowych, skoro biznesowym nazwiemy tego, kto pracuje z biznesem na rzecz zebrania wymagań dla systemu informatycznego?
Jak wielu przedmówców również uważam, że analityk systemowy powinien posiadać wiedzę techniczną i branżową, żeby znać możliwości, narzędzia, ograniczenia. Z drugiej strony powinna być to osoba, która nie patrzy na projekt wyłącznie przez pryzmat technologii, a raczej dąży do stworzenia pełnej funkcjonalności w optymalny sposób. I tak jak pisze Medard, wiele zależy od komunikacji takiej osoby z teamem.
Analityk finansowy to według mnie osoba, która zna narzędzie, w którym będzie tworzony produkt jak i zna doskonale tematyką na przykład były programista będący głównym księgowym w przypadku systemów finansowo księgowych. Do tego jeszcze musi potrafić w krótki i czytelny sposób dokumentować i przekazywać innym swoją wiedzę. Można by powiedzieć “człowiek renesansu”, może następny Leonardo da Vinci.
Umiejętności z zakresu informatyki, matematyki i doskonała analiza problemów to nie wszystko. Trzeba jeszcze mieć szerokie zainteresowania, zdolność do spojrzenia na problemy z metapoziomu. Bardzo przydatna jest również wiedza z zakresu psychologii. I oczywiście równie rozwinięte zdolności do syntezy. To bardzo ciekawe zajęcie i w pewnym sensie wykonuję je przez całe moje życie. Ciągle spotykam się z problemami z różnych dziedzin i je rozwiązuję, ubranie tego w kod to już tylko sprawy techniczne, które też ćwiczę.
Zgadzam się, trzeba chcieć ciągle poznawać nowe. Trzeba mieć pociąg do tego “więcej i więcej”. To takie przeciwstawienie się amerykańskiej super wąskiej specjalizacji bez wiedzy co się dzieje dookoła.
Dalej też się zgadzam i potwierdzam, analitykiem jest się całe życie, w pracy i w domu, u klienta i na wakacjach. To tak jak z fotografikiem – w pewnym momencie przestaje oglądać zdjęcia kolegów, zaczyna je czytać (czułość, migawka, ogniskowa, przesłona, ilość źródeł światła…) i tak już zostaje.
Na koniec się nie zgadzam – analityk nie musi, może nawet nie powinien ubierać tego w kod.
Wyjdę od tego, że nie zgodzę się z tezą: “użytkownicy biznesowi sami nie wiedzą czego chcą dopóki czegoś nie zobaczą”. Oni zdecydowanie wiedzą czego chcą, zwykle nie wiedzą czego potrzebują. Ktoś, kto nie wie czego chce, nie wie jaki ma cel choćby spotkania z Wami. Chce program/system, ok. Ale po co mu to? Bo kolega w swojej firmie ma? To niech idzie do sklepu po pudełko, też będzie miał. To nie tak działa. On wie czego chce, wie jaki ma cel, wie po co mu to COŚ potrzebne. Może cel na początek nie jest SMART ale jest. My go pomagamy ubrać w słowa, które będą nas prowadziły przez projekt i pomogą trzymać to wszystko w garści. Naszym zadaniem jest zwerbalizować to COŚ.
W tym momencie pojawia się pytania czy do takiej rozmowy potrzebna nam wiedza informatyczna? Jeszcze nie! Analityk powinien umieć kierować rozmową, powinien wiedzieć kiedy szukać konkretów, a kiedy ogółu, powinien wpasować się w sposób myślenia każdego przedstawiciela biznesu, poznać jego słownik i umieć go wykorzystywać w tych rozmowach. Powinien umieć ogarnąć szerokie horyzonty procesów biznesowych i wyczuć gdzie i na ile trzeba je precyzować. Tu nadal nie potrzebna jest wiedza IT. Obycie tak, wiedza techniczna nie.
Czy podczas tworzenia dokumentacji potrzebna analitykowi wiedza techniczna? Nie. Potrzebna mu znajomość UML, BPMN. Nie musi się znać na cake’ach, php’ach, symfoniach i innych siszarpach. Z punktu widzenia agile’owego, a jeszcze precyzyjniej scrum’owego to nawet lepiej kiedy analityk (product owner) nie zna się na technice. Wówczas jego głowa pracuje w czysty, nieskażony myśleniem ‘da się/nie da się’ sposób. Jest przedstawicielem klienta w wewn. strukturze dewelopera. Dba o jakość, o wartość z punktu widzenia biznesu. Jeśli on nie zrozumie ‘java null exception’ to od razu zaznaczy do poprawy.
Moim zdaniem nietechniczny analityk to ekstrawertyk z szeroko rozwiniętą zdolnością rozwiązywania problemów, potrafiący spojrzeć z góry na temat i znaleźć rozwiązanie zza ściany. To osoba, która pozna procesy klienta i niemal jak audytor pomoże je usprawnić, a przy okazji zaproponuje narzędzie (nie musi wiedzieć jak je zbudować, od tego ma inżynierów). To tak jak ze śmigłowcem ratunkowym – potrzebujemy wyciągarkę dla rannych do 125kg. Nie ma jak jej zamocować? To zaprojektujcie nowe wsporniki.
Nie twierdzę, że wiedza techniczna może przeszkadzać analitykowi, ale stwarza ryzyko, że zacznie rozmawiać z biznesem w języku Suahili, co często wywołuje wzmożoną produkcję piany i wyłączenie słuchania. Może zagrażać doprowadzeniu analizy do końca, gdyż w międzyczasie będzie liczył podświadomie złotówki, roboczogodziny i zamknie temat jako nieopłacalny za wcześnie. A może z przodu leżało niewypowiedziane zdanie, które przeważyłoby szalę opłacalności?
Pytanie o to czy analitykowi systemowemu jest potrzebna wiedza “informatyczna” jest pytaniem typu – czy zero należy do liczb naturalnych. Obecnie się uważa, że nie należy i z tego podejścia chyba bierze się pytanie “czy analitykowi systemowemu jest potrzebna wiedza …” :). Dla mnie “natura” tego zawodu to czysta informatyka.
Właściwie nie padło tu nic z czym bym sie nie zgadzał – ani w artykule, ani w komentarzach, przy czym sądzę, że mistrzostwo analizy systemów najtrafniej opisuje punkt 2 komentarza z 20 lutego 2011 godz. 09:27.
Oczywiste jest, że im szersza i głębsza wiedza ( nie tylko informatyczna ) tym lepiej.
Podobnie – im większe doświadczenie ( nie tylko informatyczne ) tym lepiej.
Ale wiedza i doświadczenie to z pewnością za mało, aby być mistrzem analizy systemowej.
To analogiczna sytuacja do tej, w której doskonała kondycja, duża siła i szybkość ruchów, oraz spore doświadczenie w walce, nabyte np. przez adepta kung-fu po kilkunastu latach treningów, nie wystarczą aby stał się mistrzem sztuki walki. Musi jeszcze nauczyć się pokory i bezwarunkowego szacunku dla każdego przeciwnika. A na tę naukę czasem może nie wystarczyć życia.
Reasumując :
dobry analityk systemowy = jak najwięcej wiedzy + jak najwięcej doświadczenia – jak najmniej ego.
Witam, piekne komentarze, dorzuce może troche ze swojej perspektywy… z wyksztalcenia budowlaniec (obecnie na doktoracie), ale przebranżowiony po kierunku Business IS, pracuje jako analityk-konsultant, ale zdala od Softów. Na codzień czesto rozmawiam z konultantami w terenie, ludzie z niebywała wizją i możliwościami rozwiazywania problemów, lub odnajdywania nowych źródeł, wysoce ponad przeciętną. Wielokrotnie wynajdują rozwiazania które spokojnie umożliwiłoby im założeni startupów… ale co… podobnie jak moi znajomi “po infie” są oderwani od rzeczywistości, tylko w ta drugą stronę. Na informację “nie ma” zadają 20 pytań dlaczego? i propnują gdzie znaleźć. Czesto powtarza sie u mnie w firmie ze zdolności twardych mozna się nauczyć (w krótszym bądź dłuzszym czasie, w zależności od potencjału) zdolności miekkich również, ale to juz na starcie jest czasochlonne. I o ile łatwiej wciasnać ctrl+a i delete i zacząć klepac kodzik od nowa, o tyle naprawić/polepszyć kontakt z klientem/ relacje międzyludzkie już nieslychanie trudniej. Dlatego uważam że pradziwy AS (:P) albo BA jest niczym innym ale mostem! Bez zrozumienia zespołów z jednej i drugiej strony nie osiagnie nic, czesto jest to rodzaj zawodowej schizofrenii, kiedy w przeciągu godziny trzeba porozmawiać z klientem i z zespołem techników, kazdy nadajacy na innych czestotliwościach, bo kazdy po innej stronie rzeki. pozdrawiam i powodzenia wszystkim