Analityk biznesowy, współpracujący ściśle z kierownikiem projektu, ułatwia radzenie sobie z wyzwaniami biznesowymi. Jednakże, podczas gromadzenia wymagań dla nowego lub już istniejącego projektu, analityk biznesowy musi mieć na uwadze, że każdy projekt może wymagać stworzenia i przeprojektowania towarzyszących mu procesów. Analityk biznesowy musi więc działać jako nośnik zmiany, aby sprawić, że nowo wprowadzane procesy nie tylko zwiększają sukces projektu, lecz także zwielokrotniają szanse projektu na osiągnięcie celów biznesowych organizacji.
Wczoraj podczas spotkania, miałem ciekawą rozmowę z przedstawicielami jednego z producentów systemów ERP. Okazało się, że mają bardzo podobne do moich doświadczenia i wnioski: podczas wdrożenia systemu ERP potrzebny im jest ktoś, jeden, kto zna i rozumie jak działa dana firma, a nie setki stron dokumentacji czy stenogramy z dziesiątków godzin warsztatów z przyszłymi użytkownikami. Do tego firma ta - nabywca systemu ERP - powinna mieć, nie szczegółowo opisane dziesiątki detalicznie opisanych procesów i ich wariantów, procedur czy setki i tysiące nie raz wymagań, a strategię i taktykę, z której wynika…
Być może więc za specyfikowanie wymagań na oprogramowanie powinny odpowiadać urzędy centralne od razu po tym, jak nałożą jakiś ustawowy obowiązek na podległe im urzędy? Wtedy mamy "osobę" analityka, który wykona analizę nowej ustawy i opracuje wymagania na oprogramowanie. Firma, która wygra przetarg, zapewne w ramach swojej analizy i opracowania koncepcji rozwiązania, popyta urzędników o jakieś szczegóły w rodzaju wewnętrzna organizacja pracy urzędu, struktury obowiązków i kompetencji itp. ale nie o to co urzędnik ma robić a czego nie!
I dokładnie takie samo podejście polecam firmom: zanim wybierzecie produkt lub wykonawce oprogramowania, jako interesariusze własnych projektów, zlećcie analizę i opracowanie specyfikacji i dopiero potem pozwalajcie własnym Waszym pracownikom decydować o Waszych firmach, nie to będą przynajmniej wasze kadry kierownicze.
Tak więc programista implementuje logikę biznesową, tę musi jednoznacznie udokumentować analityk, oraz zapewnia uzgodnioną jakość (wymagania pozafunkcjonalne). Ma więc dużo pracy... ale nie powinien podejmować prób wpływu na implementowaną logikę biznesową.
Czyli np. "jako sprzedawca, dostaję od klientów zamówienia, na podstawie których muszę wystawiać faktury VAT", do tego analityk doda, np. po analizie otrzymanej partii dokumentów, strukturę zamówienia i faktury VAT oraz "algorytm" wyliczenia podatków.
Jeżeli programista zaczyna "lepiej wiedzieć" od zamawiającego, forsując np. prostszą implementację, to znaczy, że przekroczył swoje kompetencje, sam sobie - jako developerowi - robi krzywdę psując to oprogramowanie bo klient i tak prędzej czy później na tych uproszczeniach "polegnie". Rolą analityka są także ewentualne negocjacje z zamawiającym, uproszczeń lub rozwinięć tego opisu. Czy analityk może być "pracownikiem" dostawcy? Jak sądzicie?
nie istnieją proste rozwiązania złożonych problemów
Co jakiś czas czytamy o porażkach projektów w sferze publicznej, zapewniam, że są one nie takim rzadkim zjawiskiem w sferze prywatnej. Dlaczego nie czytamy o tym? Bo, na szczęście dla firm prywatnych, nie dotyczy ich ustawa o dostępie do informacji publicznej itp., projekt nabywa status "tajemnica korporacji"' i nikt nie wie poza tymi, co brali udział w projekcie.
Miewam konsultacje, korepetycje, coaching itp. Pytany jestem często: "czy zdarza się Panu w projektach, że np. kierownik projektu mówi, że nie ważna jest jakość tych projektów tylko termin i protokół odbioru, klient i tak nie potrafi tego skontrolować". Powiem tak, zdarza mi się i wtedy odmawiam albo rezygnuje z udziału w projekcie, jednak ja nie mam umowy o prace i jestem nią szantażowany (jej utratą). Prawdę mówiąc nie wiem co mam tym ludziom mówić, poza powyższym oczywiście, ale i tak zawsze mówię: bądź uczciwy (co jest bardzo trudne).
Tak więc gdy trafisz na klienta myślącego prostymi schematami, opowiedz mu co proponujesz i nie narzucaj się. Klient, który "wie lepiej" - nie mówiąc Ci o tym - i tak pogrzebie Twoja pracę... A na początku zawsze ostrzegaj swoich klientów tak ja ja: "zanim zapytacie, bądźcie pewni, że chcecie poznać odpowiedź"...
Niestety bywa tak, że klient na początku pokazuje, że przyjmuje z pokorą to co mówisz, a powie Ci o tym, że nie uznaje odpowiedzi dopiero jak ją pozna , wtedy jedynym co można zrobić jest wyjęcie segregatora, który zawiera zapisane wszystkie, zaakceptowane po drodze, kluczowe etapy tej współpracy... miej je zawsze. Drugim wyjście jest ... wyjście z tego projektu.
Rada dla firm angażujących analityków: sprawdź czy przypadkiem angażowany analityk nie jest badaczem much...
Rada dla angażowanych analityków: upewnij się, czy przypadkiem organizacja, która Cię angażuje, nie jest wioską szamana...
Wymagania interesariuszy. Moja definicja interesariusza (jedna z wielu): osoba (podmiot) zainteresowana zaistnieniem produktu, na którą pojawienie się produktu ma wpływ. Nie raz jestem pytany czy interesariusz ma prawo zgłaszania wymagań. Jeżeli ma coś do powiedzenia podczas odbioru produktu to znaczy, że ma wymagania. One mogą być jednak niejawne czyli taki interesariusz nie zgłasza wymagań ale ma wpływ na odbiór produktu, należy go koniecznie zidentyfikować. Jeżeli zaś ktoś nie ma nic do gadania przy odbiorze produktu nie jest interesariuszem (ang. stakeholder, kluczem jest tu 'holder' czyli dysponent mający coś do powiedzenia, mający wpływ). Tak wiec interesariusz to ktoś kto, na swoim poziomie ogólności, także musi umieć określić, kiedy uzna, że produkt spełnia jego wymagania. Jak nie potrafi, ktoś musi mu pomóc...analityk :)).
I tu rola analityka. Interesariusz spisuje co mu przyjdzie do głowy swoim językiem, analityk upewnia się, że zrozumiał, doprowadza je do postaci testowalnej i klasyfikuje "wymagania" jako "źródło: konkretny interesariusz" (bo każde wymaganie musi mieć właściciela). Proszę zwrócić uwagę, że interesariuszem jest także użytkownik jeżeli tylko ma coś go powiedzenia w projekcie :).
Dzisiaj krótki artykuł o wymaganiach dziedzinowych. W jednym z poprzednich artykułów pisałem o wymaganiach, że problem tkwi w ich zrozumieniu i o tym, że przyszły użytkownik nie powinien pisać "jaki ma być ten program", bo popycha projekt w stronę chaotycznych oczekiwań. I tu jest sedno: analiza nie powinna być tylko pasmem wywiadów, którego produktem będę setki stron zapisów z ankiet i przeprowadzonych rozmów. Analiza, to duża praca, której celem powinno być zrozumienie a nie tylko opisanie. (Analiza wymagań na oprogramowanie czyli opisanie czy zrozumienie). Wymagania najczęściej dzielimy na funkcjonalne i…
Badanie przydatności TOGAF/ArchiMate mam chyba za sobą (zapewne nie na miarę doktoratu ale troszkę jednak tak, chociaż...;)). Na stronie mojego kolegi: ArchitekturaKorporacyjna.pl (polecam analitykom), w jednym z artykułów pojawia się ciekawe stwierdzenie: TOGAF wskazuje, że niewłaściwe podczas modelowania jest bezpośrednie wiązanie procesu [biznesowego, jak sądzę] z aplikacją go wspierającą ? elementem pośrednim powinna być funkcja ? czyli: aplikacja wspiera realizację funkcji, a funkcja obejmuje cały proces lub jego fragment (w zależności od poziomu dekompozycji funkcji biznesowej). (Komentarze do TOGAF ? metamodel zawartości (cz. II) | Architektura Korporacyjna). i to jest coś co…
Taksonomia diagramów UML Ten artykuł to kontynuacja wątku rozpoczętego wpisem o modelu dziedziny i diagramie klas, jednak inna jest intencja. Wśród wielu listów i pytań od studentów i pracujących już analityków, na temat UML, regularnie pojawia się pytanie o diagram klas i modelowanie tak zwanej dziedziny systemu. Gdy odpowiadam często pojawia się zarzut, "a tam napisano, że...". Ten artykuł to między innymi chęć zwrócenia uwagi na to, że w sieci i wielu książkach niestety mamy nie mało tak zwanej pseudowiedzy... Z zasady nie oceniam treści innych stron, jednak trudno zignorować coś,…
#1 - a 3d render series showing change and motion
O przetargach napisano tak wiele krytycznych tekstów, więc po co ten? Nie będę się tu pastwił nad nimi. Zastanawia mnie co innego, i tu mała krytyka... W prasie pojawiły się doniesienia o rozstrzyganym przetargu ogłoszonym przez [[ARiMR]]: Asseco Poland za swoje prace zaproponowało 40,65 mln zł, a Sygnity 43,98 mln zł. W przetargu startowały też: konsorcjum ze spółką zależną Asseco - ZETO Łódź (29,36 mln zł) i konsorcjum z Infovide-Matrix (31,75 mln zł). Wybrana poprzednio [[oferta konsorcjum IT Works i Almaviva]] opiewała na 9,92 mln zł. Przetarg realizowany był według…
Dzisiaj żadnych technicznych mądrości ;) [...] Tak więc wymagania na oprogramowanie to minimalna liczba (specyfikacja) warunków, których spełnienie potwierdza przydatność tego oprogramowania do określonego celu. Oznacza to, że przede wszystkim należy określić cele! Jeżeli nie znajdziemy takiego oprogramowania na rynku, wtedy należy wykonać studium wykonywalności projektu dedykowanego oprogramowania.
Jak określać cele? Przypadek użycia, wymagana usługa systemu, to nic innego jak właśnie cel. Celem jest możliwość wystawiania dokumentów XXX, celem jest generowanie raportów kontrolnych wykonania planu produkcji i obciążenia maszyn. Jeżeli system jest duży, celem (jednostka opisu wymagań) jest wsparcie procesu obsługi zamówień (i opis tego procesu jako załącznik). Ale nie jest dobrym celem zakupu oprogramowania: "rozwijana lista kontrahentów na ekranie tworzenia nowej faktury" czy "możliwość wprowadzenia nazwy ulicy, kodu i nazwy miasta w kartotece klienta".
Jak mam nadzieję widać, nie bardzo ma sens porywanie się na zakup "wielkiego pakietu zintegrowanego", bo jak tu opracować w rozsądnym czasie i koszcie, specyfikację wymagań? Opracować listę celów wszystkich komórek organizacyjnych???? Jak zagwarantować jej niezmienność (zakres projektu), jeżeli taki projekt trwa np. pięć lat? Życzę powodzenia...
Podstawową wyższością, dającą przewagę na rynku, jest zwinność organizacji. SOA to nic innego jak taka właśnie struktura systemu informatycznego: specjalizowane aplikacje, komponenty, instalowane (wdrażane) do realizacji konkretnych potrzeb zasobów takich jak pracownicy księgowości, pracownicy sprzedaży, pracownicy produkcyjni, itp.. Co więc robić?
Opisać strategie rynkową firmy,
Przeanalizować i opisać model biznesowy (sposób powstawania i źródło głównych dochodów),
Uszczegółowić model biznesowy do opisu procesów kluczowych biznesowych i reguł biznesowych,
Wskazać procesy, których wsparcie metodami informatycznymi przyniesie mierzalne korzyści,
Zaprojektować (udokumentować) architekturą systemu informatycznego ukierunkowana na zasoby i usługi.
Jeżeli pogodzimy się z faktem, że SOA to usługowa architektura systemu informatycznego firmy, zaś wszelkie webserwisy, szyny itp. to tylko możliwa implementacji (ale nie jedyna!) tej architektury to już będzie z górki. (W co inwestować w kryzysie c.d. - SOA)
Tak więc, jak mawia mój znajomy profesor filozofii: gdy dwóch mówi to samo to nie jest to samo. Tu, o SOA, komponentach, analizie i projektowaniu zorientowanym na usługi mówi wielu. Dostawcy systemów ERP o zwartej, zintegrowanej architekturze będą tu z natury zachowywali bezwładność: SOA powoduje, że żaden ERP (system i jego dostawca) nie będzie miał monopolu u raz pozyskanego klienta.
