Architektura Problemu

Uwaga. Wiele terminów występujących w  tekście zostało użytych w ramach przyjętej przez autora konwencji terminologicznej. W celu ich wyróżnienia, zostały one zapisane jako nazwy własne. 

Niniejszy wpis stanowi uzupełnienie postu "Kryzys tożsamości" i zawiera przykład budowy tzw. Architektury Problemu (AP).
AP to zbiór wzajemnie powiązanych i oddziałujących na siebie czynników, które łącznie powodują pewien niepożądany lub niekorzystny stan, określany jako tzw. Problem podlegający Rozwiązaniu.
Rozwiązanie Problemu polega na opracowaniu i przeprowadzeniu Zmiany, która spowoduje nowy stan,  uznawany za pożądany lub akceptowany, w którym nie będą występować niepożądane efekty.
By Problem rozwiązać, należy uprzednio zidentyfikować jego Przyczynę oraz mechanizm powstawania niepożądanych objawów. Służy temu budowa i analiza AP, a dokładnie modelu tejże architektury.

Zanim przystąpimy do budowy modelu AP zdefiniujemy tzw. koncepty architektoniczne (patrz diagram poniżej). 

Dla ilustracji techniki budowy AP oraz procesu analitycznego posłużmy się fikcyjnym przypadkiem biznesowym.

Firma XYZ świadczy usługi telekomunikacyjne. Jednym z jej produktów jest usługa dostępu do bramki SMS. Zarząd postanowił podnieść udział XYZ w rynku usług dostępowych poprzez zwiększenie wolumenu Klientów oraz konkurencyjność poprzez wzrost ich satysfakcji. Ostatnio jednak kierownictwo XYZ zostało zaniepokojone zmianami następujących wskaźników efektywności: 
  • spadł Indeks Satysfakcji Klientów,
  • wzrósł Średni Koszt Utrzymania Klienta,
i z zadowoleniem odnotowało, że
  • spadł Wskaźnik Migracji Klientów.

Zlecono zatem analitykowi rozpoznanie przyczyn zaistniałej sytuacji. Analityk, zapoznawszy się z elementami wpływającymi na wartości ww. wskaźników, budując Architekturę Problemu (patrz diagram poniżej) przeprowadził analizę, z  której wynika, że zmiany wskaźników spowodowane są następującą Przyczyną:

  1. W wyniku realizacji strategii "Zwiększenie konkurencyjności" nastąpił wzrost zatrudnienia i płac personelu działu obsługi Klienta (Serwis dostępny 24/7/365), co pociągnęło za sobą wzrost Średniego Kosztu Utrzymania Klienta, na co również pośrednio wpłynęła realizacja strategii  "Zwiększenie udziału w rynku usług Desktop-2-SMS" poprzez rozwój partnerskiej sieci akwizytorów wynagradzanych prowizyjnie. Wprowadzony mechanizm wynagradzania, połączony z narzuceniem wysokich norm (tzw. targetów) zaktywizował akwizytorów, co skutkowało zwiększeniem wolumenu nowo zawartych umów, a to  z kolei pozytywnie wpłynęło na wartość Wskaźnika Migracji Klientów.
  2. Wzrost liczby nowych klientów odnotowano również  w Obszarze X, który jest obsługiwany przez centrum usług telekomunikacyjnych o ograniczonych możliwościach rozbudowy bazy technologicznej. Jako że nowe umowy w Obszarze X były zawierane bez weryfikacji technicznych możliwości świadczenia usługi, w wielu przypadkach XYZ nie mogło wywiązać się z SLA, co spowodowało lawinowy wzrost reklamacji, z których wiele nie mogło być załatwionych pozytywnie w umownym terminie z powodu braku możliwości rozbudowy infrastruktury technicznej (nie ważne z jakiego powodu). To wpłynęło na spadek Indeksu Satysfakcji Klientów.
  3. Brak weryfikacji  technicznych możliwości świadczenia usługi dostępu do bramki SMS wynikał z przestarzałej architektury systemu IT wspierającego operacje XYZ: moduł CRM nie był informacyjnie zintegrowany z modułem zarządzania usługami oraz aplikacją zarządzania dostępem do bramki SMS - wymiana zleceń i potwierdzeń uruchomienia usługi prowadzona była poprzez pocztę elektroniczną.

Powyższy wywód ilustruje następujący model Architektury Problemu (patrz diagram poniżej), który wskazuje na  Strukturę Przyczyny - powiązane czynniki wpływające na zaistniały stan -  oraz jej Zachowanie, czyli mechanizm powodujący zmianę wartości wskaźników. Jako że jest to tylko ilustracja techniki modelowania, nie należy traktować modelu jako pełnej analizy problemu. Diagram należy budować i analizować " z góry w dół", w kierunku przeciwnym do kierunku relacji wpływu - od objawów do ich przyczyn.



Proponuję, aby w charakterze ćwiczenia opracować warianty Rozwiązania Problemu, czyli Zmiany z uwzględnieniem odpowiedzi na następujące pytania:
  • co należy zmienić?
  • na co należy zmienić?
  • jak należy przeprowadzić zmianę?
Propozycje można składać w formie komentarza do niniejszego posta.

Diagramy zamieszczone w niniejszym tekście zostały wykonane przy użyciu notacji ArchiMate® i modelera Archi®. ArchiMate® jest znakiem zastrzeżonym The Open Group. Archi® jest znakiem zastrzeżonym Phillipa Beauvoir.

***
Copyright and intellectual property rights.
This publication is the exclusive property of Marek Bisztyga, who has all copyrights and other intellectual property rights to the content of this publication, including text, design, graphics, logos, and video. Without the express consent of Marek Bisztyga, it is forbidden to duplicate, change, and/or make public the content of the publication in any form and in any way.













Brak komentarzy:

Prześlij komentarz