We wpisie: Metodyka wytwarzania oprogramowania zrobiłem wprowadzenie do modelowania. W tym tekście opiszę fazę inicjacji.
Cele fazy inicjacji
W fazie inicjacji należy bezwzględnie ustalić priorytetowe użytkownika. Warto pamiętać, że po stronie klienta marny do czynienia z wieloma różnymi użytkownikami przyszłego systemu. Jako grupy powinno się wyróżnić zleceniodawcę (sponsora) oraz bezpośrednich. Praktyka pokazuje, że często cele i spojrzenia na system tych dwu grup użytkowników mogą być różne. Trzeba starać się uwzględnić kryteria obydwu stron, należy jednak pamiętać, że system będzie oceniany głównie przez przyszłych użytkowników. Ważnym elementem fazy inicjacji jest jasne określenie celów przedsięwzięcia z punktu widzenia klienta, zamawiającego. Nie zawsze są one oczywiste, co często powoduje nieporozumienia pomiędzy klientem a wykonawcą. W fazie inicjacji powinny zostać określone przede wszystkim cele biznesowe przyszłego projektu.
Na tym etapie nie jest jeszcze podjęta decyzja o rozpoczęciu całościowych prac nad przedsięwzięciem. Niemożliwe jest też (ze względu choćby na ograniczenia czasowe i brak odpowiednich zasobów. Zdefiniowanie szczegółowych celów realizowanych przez przyszły system. Cele identyfikowane na etapie studium osiągalności, jak wskazuje nazwa, powinny pomóc w podjęciu decyzji strategicznych, a więc m.in. decyzji o tym, czy dany projekt zostanie przekazany do dalszych prac. Z tego względu cele powinny być definiowane na odpowiednim poziomie ogólności i koncentrować się na strategicznych, biznesowych korzyściach dla klienta. Cele wyróżnione w fazie inicjacji powinny zostać zapisane w odpowiednim dokumencie. Dokument taki stanowi ważny punkt odniesienia dla całości przyszłych, potencjalnych prac nad systemem, Nie wolno też zapominać o formalnej akceptacji dokumentu z celami strategicznymi przez obie strony — wykonawcę i klienta. Równie ważne jak zdefiniowanie strategicznych celów przedsięwzięcia jest określenie ograniczeń klienta (np. finansowych, infrastruktury, zasobów ludzkich, czasu wdrożenia itd.). Cele oraz wstępnie zidentyfikowane potrzeby biznesowe powinny być opisane w dokumencie Wizja lub zamodelowane w dowolnym narzędziu case.
Dla porządku zamieszczam kilka definicji, którymi zazwyczaj się posługuję
- Cel biznesowy to stan lub warunki, jakie musi spełnić organizacja, by osiągnąć plan zdefiniowany w wizji. Przykład: Przyspieszenie procesu podpisania umowy sprzedaży
- Potrzeba biznesowa określa, na wysokim poziomie abstrakcji elementy, czynniki, zdarzenia i działania związane z realizacją celu biznesowego. Przykład: Ograniczenie czynności sprzedaży w procesie przygotowania umowy
Cele i potrzeby biznesowe określają osoby żywotnie zainteresowane zmianą lub usprawnieniem procesu biznesowego. Zazwyczaj są to przedstawiciele biznesu. W dalszej części kursu będę ich nazywał Klientami. Na tym etapie warto jest pójść krok dalej i doprecyzować cały zakres przedsięwzięcia w takim stopniu, w jakim to będzie możliwe. Po pierwsze przygotuj wysokopoziomowy model procesów biznesowych. Zidentyfikuj kluczowe procesy których dotkną zmiany. Idealnie nadaje się tutaj język Archimate.
Identyfikując te procesy zastanowisz się po pierwsze jakie obszary, Twojego biznesu będą podlegały zmianie. Jeśli masz przygotowane modele to super. Jeśli ich nie masz wypisz te obszary choćby na kartce papieru. Następnie do zidentyfikowanych obszarów biznesowych dopisz wszystkie systemy, które twoim zdaniem w nich uczestniczą. W ten oto sposób powstanie mapa systemów i mapa procesów, które w ramach danej inicjatywy mogą ulec zmianie. Tak identyfikowane systemy i procesy należy zderzyć z planem rozwoju organizacji z portfolio projektów. Jeśli twoje organizacji nie ma biura zarządzania projektami nie ma portfolia projektów to musisz sprawdzić, jaki jeszcze inicjatywy toczą się w organizacji i jeśli chociaż któraś z nich dotyka wcześniej z modyfikowanego systemu lub procesu biznesowego musisz to odnotować. zmiana czy to procesu biznesowego, czy systemów informatycznych wynikająca z kilku inicjatyw w tym samym czasie to olbrzymie ryzyko, które Musisz wziąć pod uwagę. Ponadto to zdarzenie jest konieczne, by sprawdzić ile inicjatyw się toczy, ile tematów musi ogarnąć IT. Liczba zmian w danej organizacji i zamknięta. momencie, w którym inicjatyw jest zbyt dużo albo zwiększamy zasoby iT (ludzie zespoły) albo minimalizujemy liczbę zmian.
Mówiąc o zasobach mam tu na myśli ludzi sprzęt czas pieniądze. Moim zdaniem nie ma nic gorszego od IT, które bierze na siebie wszystkie projekty wrzucone przez biznes a po kilkunastu miesiącach biznes ma pretensje, że na drobną zmianę czeka wiele wiele miesięcy. Oczywiście sytuacje takie są bardzo złożone. Nie oceniam.
Działania związane z oszacowaniem przedsięwzięcia mają za zadanie uświadomić wszystkim od kierowników projektów do klientów, którzy zlecają zmiany Ile toczy się projektów? Ile z nich wpływa na właśnie inicjowaną kolejną zmianę? Przeciwdziała także sytuacji, w której aktualna inicjatywa wpływa a najgorszym wypadku znosi już właśnie obecnie implementowane zmiany.
W tym miejscu należy wspomnieć o roli architekta biznesowego.
Architekt biznesowy może pomóc określić cele Modyfikacji. Jako Modyfikacja rozumiem utworzenie nowej lub korekta funkcjonalności systemu (albo jego parametrów). W tym miejscu pojawia się także architekt biznesowy. To rola osoby, która odpowiada za zrozumienie rzeczywistych, na poziomie całej organizacji, potrzeb pomiędzy poszczególnymi liniami biznesowymi w odniesieniu do ogólnej strategii biznesowej.
Innymi słowy architekt biznesowy to osoba, która zna sposób działania firmy i jest w stanie określić cel zmiany oraz impakt zmiany na procesy biznesowe.
Po określeniu celu zmiany warto jest określić stan obecny. Architekt biznesowy może pomóc w analizie stanu obecnego. Poznanie aktualnego stanu działania organizacji jest potrzebne, aby ustalić co powinno ulec zmianie, na co planowana zmiana wywrze wpływ (pośrednio lub bezpośrednio). Wiedzę tę można pozyskać z aktualnie istniejących repozytoriów, utrwalić ją lub zaktualizować w ramach analizy zgłoszonej potrzeby. Otóż chodzi o to że jeżeli chcemy wdrożenie jakąkolwiek zmianę to musimy mieć jakąś ramkę stan zamknięty na daną chwilę. Musi być jakiś punkt startu. Punkt bazowy, który będzie dla nas odniesieniem dla wprowadzonych zmian. W ocenie stanu obecnego kluczową rolę pełni architekt biznesowy, a także bardzo często analityk biznesowy. Architekt biznesowy dokonuje analizy architektury biznesowej, natomiast analityk biznesowy identyfikuje procesy biznesowe, które będą ulegać zmianie do szczegółowe cele zmiany dostrzegła potrzeby biznesowe identyfikuje wstępne wymagania biznesowe.
W tym miejscu pragnę podkreślić, że te procesy są identyfikowane, a nie koniecznie modelowane.
Na ostatnim etapie tej fazy powstaje wizja biznesowa, czyli opis tego co stanie się z naszym biznesem lub jego fragmentem po wprowadzaniu zmiany. W tym kroku Architekt biznesowy może pomóc w stworzeniu opisu stanu docelowego.
Podsumowując ten wpis
Potrzeby i wymagania klienta powinny wynikać z celów wyższego poziomu reprezentujących sposób realizacji z ogólną strategią biznesową i misją organizacji. Każda dojrzała organizacja ma wyraźnie określone i zrozumiałe dla swoich członków cele i strategię biznesu. Projekty inicjowane są po to, by dostarczyć produktów i usług umożliwiających osiągnięcie tych celów. Oznacza to, że każdy projekt powinien służyć czemuś konkretnemu w rozumieniu funkcjonowania organizacji – to coś jest określone przez wizję wyrażającą główne cele i założenia projektu.
Wizję zazwyczaj definiuje sponsor projektu, jednak może być ona również opracowana przez innych interesariuszy.
Spis treści:
