Temat: Jak zostać analitykiem biznesowym

Dziękuję za odpowiedź :)

Mój zakres obowiązków mi odpowiada, tylko zastanawia mnie, skąd ten "fenomen" - taka rozbieżność w oczekiwaniach, a identyczna nazwa dla stanowiska. To... intrygujące :D

Czytałam kiedyś (i ostatnio znowu do tego powróciłam) o stanowiskach typu "Data Scientist" lub "badacz danych" i wydaje mi się, że to drugie rozumienie analityka biznesowego - jako osoby, która ma na podstawie zebranych danych powiedzmy, że zdiagnozować kondycję firmy i wskazać obszary, które wymagają naprawy, jest temu dosyć bliskie. Co Pan o tym sądzi?

Temat: Jak zostać analitykiem biznesowym

W zasadzie to powinno wystarczyć za odpowiedź:

Jarosław Ż.:
Niestety nazwa "analityk biznesowy" nie ma "zastrzeżonego" znaczenia

Regularnie spotykam się z ogłoszeniami o pracę dotyczącymi roli "Analityka biznesowego". Zwłaszcza w sytuacji gdy to headhunter do mnie dzwoni zaczynam od pytania o zakres i zasadniczo ta sama nazwa odnosi się do dwóch obszarów.

Jednym jest analiza biznesu pod kątem procesów, możliwości ich optymalizacji, głównie przy użyciu narzędzi informatycznych i dalej związane z tym zbieranie wymagań do systemów IT.

Drugim z kolei jest analiza biznesu od strony liczb - czyli jak to ujął Jarosław "grzebanie w danych" - mające na celu "wyciśnięcie" jak najwięcej informacji o możliwej optymalizacji z posiadanych już danych.

Zauważ, że w obu wypadkach cel jest podobny - analiza biznesu w poszukiwaniu możliwości optymalizacji. Prawdopodobnie stąd wywozi się taka sama nazwa stanowisk - "Analityk biznesowy". Jednak zakres wymagań i zadań potencjalnego pracownika jest oczywiście zupełnie inny.

Osobiście uważam, że optymalne byłoby jakieś zróżnicowanie tych nazw, choćby przez dodanie np. Analityk biznesowy procesów/wymagań i Analityk biznesowy danych (można by też użyć po prostu Analityk procesów/wymagań i Analityk danych), jednak nazwa w odniesieniu do stanowiska w obu przypadkach utrwaliła się do tego stopnia, że podobne zróżnicowanie jest praktycznie nierealne. Dodatkowym utrudnieniem jest fakt, że nawet w wybranych obszarach (szczególnie w podniesieniu do analityka procesów/wymagań) powstają kolejne niejednoznaczności - jedne organizacje rozumieją to szeroko, wrzucając do analizy biznesowej wszystko od analizy procesów, definiowania zakresów wsparcia IT, zbieranie szczegółowych wymagań, po wsparcie testów, a często także zadania dotyczące zarządzania projektami, podczas gdy inne różnicują stanowiska na bardziej biznesowe (analityk biznesowy odpowiada za poszukiwanie miejsc optymalizacji i definicję zakresu projektów) oraz techniczne/IT (analityk funkcjonalny/systemowy zbierający szczegółowe wymagania systemowe).

O tym, do jakiego stopnia ta niespójność utrwalona można się przekonać choćby czytają "UML for Business Analysts" Howarda Podesvy, który zaraz na wstępie książki podkreśla występujące podwójne znaczenie pojęcia analityka biznesowego, po czym zaznacza, że ta książka dedykowana jest dla analityka biznesowego IT, czyli tego "od wymagań", a nie "od danych".

Temat: Jak zostać analitykiem biznesowym

drobne uzupełnienie

Zauważ, że w obu wypadkach cel jest podobny - analiza biznesu w poszukiwaniu możliwości optymalizacji.

Analiza a optymalizacja to dwie odrębne rzeczy: żeby coś optymalizować trzeba (wypadało by ;)) to wcześniej przeanalizować, analiza to samodzielny etap pracy poprzedzając wszelkie decyzje nie tylko te dotyczące optymalizacji, analizy wymaga w zasadzie podjęcie każdej decyzji o ile tylko uznamy, że jej podjęcie bez analizy jest zbyt ryzykowne.

[...]

O tym, do jakiego stopnia ta niespójność utrwalona można się przekonać choćby czytają "UML for Business Analysts" Howarda Podesvy, który zaraz na wstępie książki podkreśla występujące podwójne znaczenie pojęcia analityka biznesowego, po czym zaznacza, że ta książka dedykowana jest dla analityka biznesowego IT, czyli tego "od wymagań", a nie "od danych".

Co do tej książki to odradzam... ;) "uczenie się" z niej... więcej tu:

http://it-consulting.pl/autoinstalator/wordpress/2015/...

Temat: Jak zostać analitykiem biznesowym

występujące podwójne znaczenie pojęcia analityka biznesowego, po czym zaznacza, że ta książka dedykowana jest dla analityka biznesowego IT, czyli tego "od wymagań", a nie "od danych".

analityk to analityk,
wymagania to (język polski)

wymaganie «warunek lub zespół warunków, którym ktoś lub coś musi odpowiadać»

Opisanie, z pozycji biznesu, wymagań na oprogramowanie nie wymaga wiedzy o IT, jednak żeby zamówić (zlecić wykonanie) oprogramowanie trzeba to umieć zrobić. Wymagania rodzinny na dom to opis tego jak sobie wyobrażają życie w nim, bezpieczne dla inwestora zlecenie budowy domu wymaga jednak projektu architektonicznego, to zrobi architekt, który raczej nie jest nawet murarzem. Kim jest tu architekt? Jest tym co w BABoK zdefiniowano jako jako Business Analyst. Nie jest to w sumie nazwa zastrzeżona ale na obecnym rynku chyba najbliższa prawdzie.

Pojęcie "analityk IT" jest chyba najbardziej niefortunnym pojęcie, analityk analizuje coś co istnienie wiec analityk IT to osoba która "analizuje istniejący system IT"....

Temat: Jak zostać analitykiem biznesowym

Jarosław Ż.:
drobne uzupełnienie

Zauważ, że w obu wypadkach cel jest podobny - analiza biznesu w poszukiwaniu możliwości optymalizacji.

Analiza a optymalizacja to dwie odrębne rzeczy: żeby coś optymalizować trzeba (wypadało by ;)) to wcześniej przeanalizować, analiza to samodzielny etap pracy poprzedzając wszelkie decyzje nie tylko te dotyczące optymalizacji, analizy wymaga w zasadzie podjęcie każdej decyzji o ile tylko uznamy, że jej podjęcie bez analizy jest zbyt ryzykowne.

OK, zgadzam się. To co robi analityk nie służy li tylko późniejszej optymalizacji - możliwości jest wiele, od stwierdzenia że wszystko jest ok (i nie trzeba nic zmieniać - umówmy się, w realnym świecie co najmniej rzadkie zjawisko), po poszukiwanie możliwości rozwoju, wejścia na nowe rynki itp. I tak jak napisałeś - każda zmiana powinna być poprzedzona (jakąś) analizą, choć nie do każdej potrzeba analityka ;-) W rzeczywistości choćby nieświadomie jakąś analizę prowadzi się zawsze, różnica jest taka, że analityk robi to w sposób usystematyzowany, a przy ty (zazwyczaj) ma doświadczenie i wiedzę, dzięki czemu łatwiej mu (a czasem wręcz w ogóle jest w stanie) "ogarnąć" problem o wysokim stopniu złożoności. Ponadto (zazwyczaj) analityk jest bezstronny, czy przynajmniej bardziej bezstronny niż zlecający ewentualną analizę.

Nie napisałem też, że to analityk optymalizuje, choć z takimi stanowiskami też się spotkałem ;-)

[...]

O tym, do jakiego stopnia ta niespójność utrwalona można się przekonać choćby czytają "UML for Business Analysts" Howarda Podesvy, który zaraz na wstępie książki podkreśla występujące podwójne znaczenie pojęcia analityka biznesowego, po czym zaznacza, że ta książka dedykowana jest dla analityka biznesowego IT, czyli tego "od wymagań", a nie "od danych".

Co do tej książki to odradzam... ;) "uczenie się" z niej... więcej tu:

http://it-consulting.pl/autoinstalator/wordpress/2015/...

To nie ta książka. Ja pisałem o tej:
https://books.google.pl/books?q=editions:ISBN1592009123...

Istnieją dwa wydania (drugie ma taką ciemnoniebieską okładkę). W moim odbiorze to całkiem sensowna książka pozwalająca zrozumieć tak sam proces analizy jak i podstawy UMLa używanego w takim procesie.

Na koniec - analityk biznesowy IT analizuje biznes pod kątem IT. Niekoniecznie rozwiązań istniejących - powiedziałbym nawet że przeciwnie, raczej pod kątem nowych systemów czy też zmian, które należy w istniejących systemach wprowadzić.

Natomiast analityk odpowiedzialny za analizę istniejących systemów IT i ewentualne poprawki (w kontekście np. poprawy efektywności) określany jest zazwyczaj mianem analityka systemowego (IT).

Za to samo "analityk IT" jest faktycznie niefortunne. Jest to określenie równie precyzyjne, co "informatyk", czy (żeby użyć Twojego porównania) "budowlaniec".

Temat: Jak zostać analitykiem biznesowym

To nie ta książka. Ja pisałem o tej:
https://books.google.pl/books?q=editions:ISBN1592009123...

Istnieją dwa wydania (drugie ma taką ciemnoniebieską okładkę). W moim odbiorze to całkiem sensowna książka pozwalająca zrozumieć tak sam proces analizy jak i podstawy UMLa używanego w takim procesie.

Też mam, niestety podobny gniot z opisem systemowych use casów i procesach modelowanych w Use Case, przykład "poprawnego" diagramy Use Case z jednym includowanym Use Case (musza być co nie mniej dwa) ..... strzałki na asocjacjach Aktor Use CAse to kuriozum i totalne niezrozumienie tego diagramu, generalnie masa błędów i pseudo teorii autora

Na prawdę polecam oryginalną specyfikację .... wersja 2.5 ma dwa razy mniejsza objętość niż pooprzednie :)

Na koniec - analityk biznesowy IT analizuje biznes pod kątem IT.

Nie ma czegoś takiego, biznes to jest biznes, można co najwyżej później ocenić na ile "jakieś rozwiązanie IT" jest (może być ) przydatne (w BABoK wyraźnie jest napisane, ze wymagania opisują PRODUKT, który może być oprogramowaniem spełniającym lub nie, określonego wymagania czyli czy przydatny do czegoś z opisem do czego)

Niekoniecznie rozwiązań istniejących - powiedziałbym nawet że przeciwnie, raczej pod kątem nowych systemów czy też zmian, które należy w istniejących systemach wprowadzić.

Ponad 90% wdrożeń to wdrożenia oprogramowania istniejącego, kupionego na rynku

Natomiast analityk odpowiedzialny za analizę istniejących systemów IT i ewentualne poprawki (w kontekście np. poprawy efektywności) określany jest zazwyczaj mianem analityka systemowego (IT).

w BABoK przeczytamy, że rola "analityka systemowego (IT) to kuriozum, "analiza systemowa" to dość szerokie pojecie (google i "analiza systemowa" oraz "ogólna teoria systemów", po protu oprogramowanie w firmach to to także jakiś system.

Generalnie w branży IT mam straszny bałagan pojęciowy i masę pseudowiedzy o UML i pokrewnychTen post został edytowany przez Autora dnia 19.06.16 o godzinie 15:51

Temat: Jak zostać analitykiem biznesowym

To nie ta książka. Ja pisałem o tej:
https://books.google.pl/books?q=editions:ISBN1592009123...

Też mam, niestety podobny gniot z opisem systemowych use casów i procesach modelowanych w Use Case,

Organizacja (np. firma) też jest swego rodzaju systemem, nie widzę zatem nic złego w określaniu procesów biznesowych z użyciem UMLa. Oczywiście zdaję sobie sprawę z BPMNa i do modelowania procesów biznesowych staram się go używać, jednak samo w sobie użycie UMLa nie jest tu niczym złym. Use Case'y w tym wypadku określają listę procesów biznesowych mogących przebiegać w danej organizacji.
Sam przebieg procesu modelowany jest z użyciem diagramu aktywności.

Moje zastrzeżenia budzi tu jedynie przedstawienie na diagramie UC pracowników, którzy są składowymi systemu (organizacji), a zatem nie powinni pojawić się na diagramie UC.

przykład "poprawnego" diagramy Use Case z jednym includowanym Use Case (musza być co nie mniej dwa) .....

Specyfikacja nic takiego nie narzuca ;-) A mówiąc poważnie - spotkałem się z podejściem (z którym się w pełni zgadzam), że wydzielanie UC includowanych/stanowiących rozszerzenie ma sens w dwóch wypadkach - jeśli częściowy UC samodzielnie stanowi proces mający sens (czyli może być uruchomiony w oderwaniu od innych UC) lub jeśli fragment jest reużywany w różnych UC. W tym kontekście istotnie model, w którym jeden UC jest np. includowany przez drugi UC i nigdy nie występuje ani samodzielnie, ani nie jest wykorzystany przez kolejnego UC (czy to w ramach include, czy extend) nie powinien być modelowany osobno. Jednak nie widzimy całej dokumentacji tylko fragmenty. Zakładam, że te jednorazowo includowane UC mają też zastosowanie gdzie indziej (aczkolwiek opisana zasada powinna być mocno podkreślona i widoczna na diagramach).

strzałki na asocjacjach Aktor Use CAse to kuriozum i totalne niezrozumienie tego diagramu, generalnie masa błędów i pseudo teorii autora

A to bardzo ciekawe twierdzenie, zwłaszcza uwzględniając, że na oficjalnych egzaminach z UML (zaczynając od poziomu Fundamental) pojawiają się UC właśnie z takimi strzałkami jak u Podesvy. Rozumiem, że uważasz osobę z OMG, która tworzyła oficjalne pytania za totalnie nie rozumiejącą diagramu UC?

Na prawdę polecam oryginalną specyfikację .... wersja 2.5 ma dwa razy mniejsza objętość niż pooprzednie :)

Uważasz, że sama specyfikacja wystarczy do nauczenia się UMLa? Owszem, kiedy złapie się podstawy jest to pozycja obowiązkowa. Ale brak w niej punktu zaczepienia dla osoby, która chciałaby zacząć modelować z użyciem UML. Zresztą samo OMG zaleca sięganie po inne materiały, w szczególności książki pokazujące jak konkretnie użyć UMLa (inna sprawa, że jedyną pozycją, którą polecają bezpośrednio jest "UML 2.0 in a nutshell", która też nie odnosi się do modelowania, a w dodatku pomija ogromne partie UMLa.

Niekoniecznie rozwiązań istniejących - powiedziałbym nawet że przeciwnie, raczej pod kątem nowych systemów czy też zmian, które należy w istniejących systemach wprowadzić.

Ponad 90% wdrożeń to wdrożenia oprogramowania istniejącego, kupionego na rynku

OK, nie byłem tutaj precyzyjny. Chodzi mi o systemy lub funkcjonalności w systemie nowe w firmie/organizacji. Oczywiście wynikiem analizy może być (i najczęściej jest) wybranie istniejącego już oprogramowania, które w największym stopniu spełnia wymagania biznesu (i ewentualnie określenie koniecznych zmian - o ile to możliwe)

Generalnie w branży IT mam straszny bałagan pojęciowy i masę pseudowiedzy o UML i pokrewnych

A tu się zgadzamy w 100% :-)

Temat: Jak zostać analitykiem biznesowym

Tomasz M.:

To nie ta książka. Ja pisałem o tej:
https://books.google.pl/books?q=editions:ISBN1592009123...

Też mam, niestety podobny gniot z opisem systemowych use casów i procesach modelowanych w Use Case,

Organizacja (np. firma) też jest swego rodzaju systemem, nie widzę zatem nic złego w określaniu procesów biznesowych z użyciem UMLa.

Nie neguję użycia UML w modelowaniu organizacji, jednak "biznesowe przypadki użycia" to byt z poza UML ... nie nazywajmy UML'em tego co nim nie jest...

przykład "poprawnego" diagramy Use Case z jednym includowanym Use Case (musza być co nie mniej dwa) .....

Specyfikacja nic takiego nie narzuca ;-)

niestety tak: include to wyłączona część wspólna scenariuszy co najmniej dwóch UC.... przypadek "includowany" nie jest więc samodzielny i nie mozna z nim kojarzyć aktorów.
specyfikacja UML 2.5 rozdz. 18.1.3.3 Includes
"The Include relationship is intended to be used when there are common parts of the behavior of two or more UseCases. This common part is then extracted to a separate UseCase, to be included by all the base UseCases having this part in common. As the primary use of the Include relationship is for reuse of common parts, what is left in a base UseCase is usually not complete in itself but dependent on the included parts to be meaningful."

strzałki na asocjacjach Aktor Use CAse to kuriozum i totalne niezrozumienie tego diagramu, generalnie masa błędów i pseudo teorii autora

A to bardzo ciekawe twierdzenie, zwłaszcza uwzględniając, że na oficjalnych egzaminach z UML (zaczynając od poziomu Fundamental) pojawiają się UC właśnie z takimi strzałkami jak u Podesvy. Rozumiem, że uważasz osobę z OMG, która tworzyła oficjalne pytania za totalnie nie rozumiejącą diagramu UC?

Proszę podać odnośnik do UML z tą tezą... (egzaminatorzy nie są źródłem specyfikacji), pomijam fakt, że przypadek użycia jest wywoływany (inicjowany) przez aktora nie odwrotnie. W OMG jest wielu spierających się o pryncypia ludzi, wystarczy śledzić ich prace by wiedzieć, ze są tam różni ludzie. Ja, jak wielu projektantów, bazuje na logice UML i obiektowym paradygmacie a nie na spekulacjach. Wystarczy obserwować jak rugowana jest w końcu z UML pozbawiona sensu logicznego asocjacja agregacji (zwana potocznie słabą kompozycją). Podobnie spotykam się z powoływaniem na tutoriale firmy SPARX, które nie raz są czystym bełkotem (i takie dyskusje też można spotkać nie tylko na LinkedIn :)) z moim ulubionym bełkotem typu "aktor czas".....

Na prawdę polecam oryginalną specyfikację .... wersja 2.5 ma dwa razy mniejsza objętość niż poprzednie :)

Uważasz, że sama specyfikacja wystarczy do nauczenia się UMLa?

Specyfikacja to coś czego nie wolno łamać, nauka korzystania z UML to co innego, ale na pewno nie jest to sztuka obchodzenia specyfikacji. Do nauczenia się UML trzeba poznać semantykę i syntaktykę tej notacji, zrozumieć paradygmat obiektowy oraz dużo ćwiczyć. To czy źródłem podstawowej wiedzy jest oryginalna specyfikacja, czy jej opracowania, ma znaczenie drugorzędne, ważne by te drugie nie fałszowały pierwszej.

Temat: Jak zostać analitykiem biznesowym

Dzień dobry,

trafiłem tutaj szukając poprzez Google odpowiedzi na pytanie o drogę do zostania analitykiem biznesowym.

Jestem historykiem, w tej chwili studia doktoranckie, ale rozważam je zakończyć, albo może odłożyć na drugi plan, bo już najwyższy czas życie poukładać. Chciałbym więc przekwalifikować się z kochanej historii na coś konkretniejszego zawodowo i oferującego pracę.

Znajoma pracująca w HR zasugerowała mi zainteresowanie się tematem analityka biznesowego.
Ot, jestem osobą o analitycznym i dociekliwym usposobieniu (stąd zresztą zainteresowanie historią. Dojrzale traktując historię mamy przecież cały szereg związków przyczynowo skutkowych mogących pomagać zrozumieć dzisiejszą sytuację w danym zakresie). Mam zarazem świadomość, że jest wiele osób które uważają, że super analizują wszystko,a w moim odczuciu w żaden sposób nie wchodzą w szczegóły, w rozbudowaną strukturę tematu. Analogicznie i ja mogę przeceniać swoje analityczne zdolności.

Chciałbym jednak ten mój charakter nakierować na coś dochodowego. Analiza biznesowa brzmi dobrze. Szukanie jednak informacji w Google daje dość sprzeczne, co najmniej z pozoru, informację. A to, że najlepiej mieć wykształcenie matematyczne, albo że to ekonomiczne jest realnym wymogiem. Są i wskazania o IT, zarządzaniu, jak i to, że właśnie z humanisty można się przekierować.
Są i wskazania (w tym temacie zresztą też obecne) o stosowaniu różnych definicji "analityka biznesowego".

Widzę kursy online, standardowe, jak i studia podyplomowe. Są zarazem i tam czasem podawane wymogi, czasem nie. Trudno zarazem ocenić wiarygodność danych ofert.

Chciałbym więc prosić o sugestie od czego zacząć.

Temat: Jak zostać analitykiem biznesowym

Witam,

od lat zajmowałam się programowaniem, gdzie również spotykałam sie z analiza wymagan, modelami UML, chciałam teraz zmienić profesję, ale w każdym ogłoszeniu jest wymagane min. 2 letnie doświadczenie.

Jakieś wskazówki co do firm, które przyjmują również dinozaurów do przyuczenia ?

Pozdrawiam.

Temat: Jak zostać analitykiem biznesowym

Sama praca jako analityk biznesowy to może być wiele różnych dziedzin.
Analitykiem biznesowym nazywają siebie:
- Osoby od inżynierii wymagań
- Osoby od analizy strategicznej przedsiębiorstwa
- Osoby od optymalizacji procesów
- Osoby od analizy danych
- Osoby od analizy cyberbezpieczeństwa organizacji
- Osoby od UX
- Osoby w postaci Product Ownera

Pytanie w jakiej roli ty siebie widzisz? Jeśli chodzi o analityka biznesowego w IT to polecam przeczytać wpis który pokazuje jak wielu obszarów analityk może dotykać i też w zależności od organizacji w różnych miejscach on występuje.

https://analizowac.pl/analityk/proces-pracy-analityka-it/

Temat: Jak zostać analitykiem biznesowym

Moja rada jest podobna do kolegów, dużo czytać w tym zakresie. A jeśli chodzi o studia to sama robiłam kierunek analityk biznesowy na WSKZ. To była podyplomówka i uważam, że wiele się nauczyłam dzięki temu kierunkowi. Studia są opracowane w bardzo porządny sposób, wiedza przekazywana jest w bardzo zrozumiały sposób nawet dla osób nie mających styczności wcześniej z tym tematem.