Elementy motywacji

Spis treści – Archimate 3.0

Elementy motywacji

Na stronie tej opisano następujące elementy:

• Interesariusz (Stakeholder)
• Czynnik sterujący (Driver)
• Ocena (Assessment)
• Cel (Goal)
• Wymaganie (Requirement)
• Ograniczenie (Constraint)
• Pryncypium (Principle)
• Wartość (Outcome)

Elementy motywacji są stosowane do zobrazowania powodów i przyczyn stojących za zmianami w architekturze korporacyjnej.

Interesariusz (Stakeholder)

Interesariusz jest zdefiniowany jako rola jednostki, zespołu lub organizacji (lub jej pochodnej), która może pozostawać pod wpływem lub mieć wpływ na wynik architektury.

Interesariusze zmieniają, realizują lub określają cele organizacji, w taki sposób aby realizowały ich interesy. Przykładami interesariuszy są CEO, dyrektor rady, klienci, biznes, architekci oprogramowania oraz ustawodawcy.

Interesariusz – notacja

Na modelu poniżej został przedstawiony przykład modelowania interesariuszy. Zostali zamodelowani dwaj główni Interesariusze: Zarząd i Klient. Zarząd został utworzony z trzech innych interesariuszy: CIO, CEO, CFO.

Przykład użycia interesariusza

Czynnik sterujący (Driver)

Czynnik sterujący jest zdefiniowany jako element który tworzy, motywuje lub napędza zmiany w organizacji.

Czynnik sterujący może być wewnętrzny – w takim wypadku jest zazwyczaj powiązany z interesariuszem. Przykładem czynników sterujących są „Satysfakcja klienta”, „Zgodność z prawem”, czy „Rentowność”. Czynnik sterujące także mogą być zewnętrzne, np. zmiany ekonomiczne lub zmiany prawa.

Czynnik sterujący – notacja

Na modelu poniżej zostały przedstawione przykłady zastosowania wewnętrznych i zewnętrznych czynników sterujących dla zmian. Interesariusze CEO i Klient współdzielą troskę o satysfakcję klienta. CEO dodatkowo ma przypisaną troskę dotyczącą satysfakcji akcjonariuszy, które są dalej rozłożone na dwa podrzędne czynniki sterujące Wartość akcji i Zysk. Został także zamodelowany zewnętrzny czynnik sterujący Zmiany ekonomiczne, który ma wpływ na wewnętrzny czynnik Wartość akcji.

Przykład użycia czynnika sterującego

Ocena (Assessment)

Ocena jest zdefiniowana jako wynik pewnej analizy dla czynnika sterującego.

Ocena może ujawniać silne i słabe strony, szanse i zagrożenia dla jakiegoś obszaru zainteresowania. Ocena powinna wpływać na aktualizację aktualnych lub powstawanie nowych celów, a także wywoływać zmiany w architekturze korporacyjnej. Silne i słabe strony występują wewnątrz organizacji. Szanse i zagrożenia na zewnętrz. Słabe strony i zagrożenia mogą być rozważane jako problemy, które powinny być rozwiązane poprzez cele, które będą je eliminować. Silne strony i szanse powinny być tłumaczone bezpośrednio na cele. Na przykład ocena słabej strony „Klienci narzekają na helpdesk” powinna być zdefiniowana jako cel „Usprawnić działanie helpdesk”. Natomiast szansa „Klienci preferują ubezpieczenia, które mogą być zarządzane on-line”, powinno być zdefiniowane jako cel „Wprowadzenie zarządzania portfelem usług on-line”.

Ocena – notacja

Model poniżej opisuje ocenę czynników sterujących Satysfakcja klienta oraz Obsługa wsparcia helpdesk. Wszystkie przedstawione oceny reprezentują słabości. Odnośnie oceny ogólnej satysfakcji klienta wyszczególniono problemy dotyczące narzekań klientów oraz rezygnacji klientów z firmy ArchiSurance. Dalsza ocena narzekań klientów pozwoliła na podzielenie skarg na cztery bardziej szczegółowe problemy.

Przykład użycia oceny

Cel (Goal)

Cel jest definiowany jako końcowy stan, który chce osiągnąć interesariusz.

Cel może reprezentować dowolny stan, jaki ma zostać osiągnięty przez interesariusza, np. załatwienie sprawy lub wyprodukowanie jakiejś wartości. Cele mogą być zdekomponowane, aby określić bardziej szczegółowe cele, łatwiejsze do opisania. Na przykład cel „zwiększenie przychodu, może zostać zdekomponowane na cele „redukcja kosztów” i „zwiększenie sprzedaży”. Cele często są opisywane z wykorzystaniem słów opisujących jakość, np. „zwiększenie”, „zmniejszenie”, „poprawienie” lub „uproszczenie”. Przykładami celów mogą być np. zwiększenie przychodu lub zmniejszenie czasu oczekiwania na serwis.

Cel – notacja

Model poniżej przedstawia użycie celów adresujących ocenę czynnika sterującego Koszt, którego ocena wykazała za duże koszty oprogramowania oraz za duże koszty pracownicze. Za duże koszty oprogramowania, zostały zaadresowane przez cele Redukcja kosztów utrzymania oraz Redukcja bezpośrednich kosztów oprogramowania. Za duże koszty pracownicze natomiast zostały zaadresowane przez Redukcję obciążenia pracowników, która została rozdzielona na cele Ograniczenie pracy wykonywanej ręcznie oraz Redukcję interakcji z klientami.

Przykład użycia celu

Wymaganie (Requirement)

Wymaganie jest zdefiniowane jako deklaracja potrzeby, która ma zostać zrealizowana przez architekturę (a tym samym i przez organizację).

Wymagania modulują właściwości tych elementów, które są potrzebne do osiągnięcia końcowych celów biznesowych, które są zamodelowane przez elementy typu cel. Cele te są realizowane przez wprowadzenie zmian w aktualnych systemach informatycznych lub przez tworzenie nowych lub zmianę istniejących procesów biznesowych.

 

Wymaganie – notacja

Model poniżej ilustruje rozkład celów wobec wymagań. Cele Ułatwienie samoobsługi i Wprowadzenie efektywniejsze interakcji z użytkownikiem powstały z dekompozycji celu Redukcji interakcji z klientami, który jest częścią dekompozycji celu Redukcja obciążenia pracowników. Cel Ułatwienie samoobsługi może zostać zrealizowany przez wymagania Zapewnienie dostępu do portfela on-line oraz Zapewnienie dostępu do informacji on-line. Oba te wymagania są realizowane przez określone komponenty aplikacji. Natomiast oba wymagania Przypisanie opiekuna do klienta oraz Zapewnienie dostępu do portfela on-line realizują Usprawnienie zarządzania portfelem.

Przykład użycia wymagania

Ograniczenie (Constraint)

Ograniczenie stanowi czynnik, który zapobiega lub utrudnia realizację celu.

W odróżnieniu do wymagania, ograniczenie nie precyzuje potrzeb związanych z architekturą –  nakłada ograniczenie na sposób osiągnięcia celu. To mogą być restrykcje dotyczące sposobu implementacji systemu (np.: specyfikujące technologię jaka zostanie wykorzystana) lub ograniczeń procesu biznesowego (np.: okresowe raportowanie do instytucji nadzorującej).

Ograniczenie – notacja

Na modelu poniżej został przedstawiony przykład zastosowania ograniczeń do projektu realizacji oprogramowania. Pierwsze dotyczy wysokości budżetu przeznaczonego na projekt, drugie dotyczy technologii jaka ma być użyta do implementacji komponentu aplikacji realizowanego w projekcie.

Przykład użycia ograniczenia

Pryncypium (Principle)

Pryncypium jest zdefiniowane jako zasada określająca właściwości i cechy, które powinna spełniać architektura.

Pryncypia są ściśle powiązane z celami i wymaganiami. Podobnie jak wymagania, pryncypia definiują pożądane właściwości systemów. Jednak pryncypia mają szerszy zasięg i są bardziej abstrakcyjne od wymagań. Pryncypium definiuje ogólną właściwość, która ma zastosowanie do wszystkich systemów w danym kontekście. Wymaganie natomiast definiuje właściwość, która ma zastosowanie do określonego systemu.

Pryncypium – notacja

Model poniżej przedstawia pryncypium System powinien być przyjazny użytkownikowi, które realizuje cele Redukcja interakcji z klientem oraz Ograniczenie pracy wykonywanej ręcznie. Pryncypium to następnie jest wyspecyfikowane przez dwa wymagania: Zapewnienie dostępu do portfela on-line oraz Zapewnienie dostępu do informacji on-line.

Przykład użycia pryncypium

Wartość (Outcome)

Wartość (rezultat)- to wynik jaki powinien zostać uzyskany po osiągnięciu celu.

Wartości są wysokopoziomowymi, zorientowanymi na biznes wynikami uzyskiwanymi dzięki zdolnościom organizacji. Wartości są namacalne, mogą być ilościowe lub związane z czasem, a także mogą być związane z ocenami. Ta sama wartość może mieć inne znaczenie dla różnych interesariuszy.

Wartość – notacja

Model poniżej przedstawia pryncypium System powinien być przyjazny użytkownikowi, które realizuje cele Redukcja interakcji z klientem oraz Ograniczenie pracy wykonywanej ręcznie. Pryncypium to następnie jest wyspecyfikowane przez dwa wymagania: Zapewnienie dostępu do portfela on-line oraz Zapewnienie dostępu do informacji on-line.

Przykład użycia wartości

W niniejszym materiale pominięto, z uwagi znikomy stopień zastosowania, elementy: Value i Meaning.

Przykładowe perspektywy (punkty widzenia)

Punkt widzenia interesariuszy

Punkt widzenia interesariuszy pozwala projektantowi lub analitykowi na zamodelowanie interesariuszy, wewnętrznych i zewnętrznych czynników sterujących dla zmian oraz ocen (z uwzględnieniem mocny i słabych stron, szans i zagrożeń) dla tych czynników. Może także opisywać (na wysokim poziomie abstrakcji) cele, które mają za zadanie rozwiązanie trosk interesariuszy.

Przykład modelu dla punktu widzenia interesariuszy

Punkt widzenia realizacji celów

Punkt widzenia realizacji celów pozwala na uszczegółowienie celów wysokiego poziomu, za pomocą bardziej szczegółowych/konkretnych celów oraz określenie tych bardziej szczegółowych celów za pomocą wymagań i ograniczeń, które określą właściwości jakie muszą być spełnione dla realizacji tych celów.

Przykład modelu dla punktu widzenia realizacji celów

Punkt widzenia kontrybucji celów

Punkt widzenia kontrybucji celów pozwala projektantowi analitykowi na zamodelowanie wpływu wymagań na cele. Model ten może posłużyć do analizy wpływu celów na inne cele lub do wykrycia konfliktów pomiędzy celami interesariuszy.

Przykład modelu dla punktu widzenia kontrybucji celów

Punkt widzenia pryncypiów

Punkt widzenie pryncypiów pozawala analitykowi lub projektantowi zamodelować pryncypia, które są istotne dla określonych problemów projektowania, włączając cele, które motywują pow stanie tych pryncypiów.

Przykład modelu dla punktu widzenia pryncypiów

Punkt widzenia realizacji wymagań

Punkt widzenia realizacji wymagań pozwala projektantowi na zamodelowanie realizacji wymagań przez inne elementy, takie jak aktorzy biznesowi, usługi i procesy biznesowe, usługi i komponenty aplikacji, itd. Zwykle wymagania wynikają z uszczegółowienia celów.

Przykład modelu dla punktu widzenia realizacji wymagań

Punkt widzenia motywacji

Punkt widzenia motywacji pozwala projektantowi lub analitykowi na zamodelowanie aspektów motywacyjnych, bez skupiania się na konkretnych elementach związanych z tym aspektem. Na przykład ten punkt widzenia może być wykorzystany do przedstawienia całościowego lub częściowego opisu aspektu motywacyjnego dla powiązanych interesariuszy, ich podstawowych celów, pryncypiów które są stosowane, oraz podstawowych wymagań dla usług, procesów, aplikacji i obiektów.

Przykład modelu dla punktu widzenia motywacji

Spis treści – Archimate 3.0