„Co mam zrobić z moimi systemami?”

Data: 2014-03-19
Autor: Sebastian Konkol
„Co mam zrobić z moimi systemami?”

„Mam ten cały bałagan systemów IT…”, „Oni żądają dostarczania tylu rzeczy!” „Gubię się… Co zrobić najpierw – a co odłożyć na później?” To typowe zdania opisujące współczesną firmę uzależnioną od technologii informacyjnej, na którą składają się zwykle z dwa elementy: (1) wiele, równocześnie prowadzonych inicjatyw rozwojowych oraz (2) złożoność rozwiązań technicznych. Choć radzenie sobie z wieloma „równoległymi” inicjatywami jest czysto zarządczym zagadnieniem dającym się obsługiwać „standardowymi metodami” postępowania, skuteczne rozwiązanie może opierać się na filozofii architektury korporacyjnej (EA, Enterprise Architecture).

Co ciekawe, w przeważającej liczbie przypadków to właśnie zależności tkwiące głęboko w konstrukcji rozwiązań i złożoności całego środowiska ICT wywierają zdecydowanie mocniejszy wpływ na zdolność realizacji, niż cele biznesowe. Kluczowym jest więc przedstawienie środowiska ICT – zarówno obecnego, jak i przyszłego – w kategoriach zrozumiałych biznesowo, a inicjatyw do celów biznesowych. Taki efekt osiągam wykorzystując elementy metody Technology Roadmapping, a dokładniej jej adaptacji do sfery rozwoju architektury.

U podstaw takiego podejścia leży zrozumienie trzech oddzielnych perspektyw opisujących inicjatywy angażujące rozwój systemów ICT oraz znalezienie krytycznych zależności pomiędzy nimi. Perspektywy te obejmują:

  • Know-why – biznesowy powód dla angażowania się w określoną inicjatywę; oczekiwane jej rezultaty wyrażone przez zdolności organizacji (Enterprise Capabilities) do realizacji określonych rzeczy, zwykle wywiedzione z planów strategicznych i definicji programów;
  • Know-what – cechy lub zdolności (capabilities), zarówno organizacyjne jak i technologiczne, wymagające wytworzenia dla zapewnienia wykonalności powodów biznesowych angażowania firmy w inicjatywę rozwojową; ta część jest ściśle powiązana z architekturą korporacyjną (architektura biznesowa, danych, aplikacji i techniczna);
  • Know-how – zmiany i rozszerzenia systemów informatycznych lub modyfikacje procesów biznesowych; opisują one sposób, w jaki zdolności organizacji mają być nabyte lub wytworzone.

Perspektywa know-why jest zwykle postrzegana jako czysto biznesowa, podczas gdy know-how – jako czysto techniczna. Składowe opisu wewnątrz każdej z tych perspektyw mogą być wewnętrznie zależne, a ludzie rutynowo działający w tych obszarach rozumieją je. Perspektywa know-what (część realizowana metodami EA) łączyć ma obie siły rozwojowe – zdolności wynikające z zapotrzebowania biznesowego (Business Pull), jak i wynikające z podaży technologicznej (Technology Push). Ta ostatnia perspektywa wiąże także ograniczenia – oczekiwana sekwencja celów biznesowych do osiągnięcia, wymagana kolejność realizacji zmian w środowisku informatycznym.

Wydaje się więc, że najwłaściwszym pytaniem do postawienia jest „To co chcesz uzyskać, Drogi Kliencie?” Niestety, stawianie takich pytań prowadzi zwykle do jednego z dwóch scenariuszy: albo biznes zaczyna mówić, jak mają być skonstruowane systemy informatyczne, albo traktuje to jak szukanie wymówek, żeby „nie dostarczyć”. Tak, czy inaczej, eskalacja konfliktu. Pytam więc zwykle „Czego oni od nas chcą?” (wszak zawsze są jacyś „oni”) i na bazie odpowiedzi dokonuję swoistej syntezy potrzeb na podstawie obrazu oczekiwanego rozwiązania. Dopiero na tym buduję wizję właściwego rozwiązania – praca architektoniczna, której wynikiem jest opis z perspektywy know-what, wyrażający explicite zależności i graniczenia. Proces nie jest ani prosty, ani bezbolesny, ale daje się przeprowadzić.

W efekcie pracy tworzę zwykle obraz wyrażony w czasie – sekwencję wersji, „migawek” zdolności organizacji, jaka powinna być osiągana w określonych etapach w przyszłości, uwzględniających konsensus między perspektywami know-why i know-what. Taka roadmapa przedstawia (zawierają także argumentację uzasadniającą) kroki ewolucji organizacji i wspomagających ją systemów informatycznych. Ponieważ roadmapa jest narzędziem planowania strategicznego, jej skala czasu nie jest liniowa. Dzielę horyzont czasu na trzy obszary: (1) krótkoterminowy, zwykle mierzony w skali tygodni, (2) średnioterminowy, mierzony w miesiącach i (3) długoterminowy, odmierzany kwartałami lub latami.

Nie tyle sama roadmapa co proces jej wytworzenia zapewnia dodatkowe efekty głębszego zrozumienia i zaangażowania w realizację celów:

  • Zależności i ograniczenia wynikające z perspektywy know-why są wyrażane explicite – tłumaczą uzasadnienie biznesowe i „karzą” inicjatywy niezgodne z nimi.
  • Zależności „zakopane” w złożoności ICT są odkrywane, oddzielając rzeczywiste problemy od lenistwa, zapewniając większą transparentność rozwiązań i zrozumienie ich konsekwencji.
  • Priorytety biznesowe są ważone ryzykiem technologicznym, tworząc obiektywne zasady ustalania sekwencji realizacji inicjatyw rozwojowych.
  • Potencjalnie błędne projekty są korygowane – rewizją ich zakresów, sposobu realizacji zadań lub ryzyka, jakim projekty powinny zarządzać.

Dla ilustracji, jeden z moich projektów doradczych dla klienta z branży medycznej, który dotychczas obsługiwał klientów instytucjonalnych, ale rozszerzał obszar działania także na klientów indywidualnych. Jedną z kluczowych zdolności, jakiej wytworzenie było wymagane od IT, było uruchomienie systemu bilingowego, który byłby zdolny do automatyzacji całości rozliczeń z klientami indywidualnymi. O pomoc zostałem poproszony w czasie, kiedy typowy dialog biznes-IT przebiegał według schematu: „Ten ficzer ma być dostarczony na deadline!” – „Nie ma szans – za późno sobie o tym przypomnieliście”. Pat, deadlock, wojna pozycyjna. Poprosiłem o tydzień „zawieszenia broni” i przeprowadziłem obie strony przez „ćwiczenie z roadmappingu”. W trakcie tego ćwiczenia „okazało się”, że:

  • Zachowujące element konkurencyjności wejście na nowy rynek wymaga wprowadzenia nowego produktu dla nowej grupy klientów. Przy takim ograniczeniu wdrożenie systemu bilingowego dałoby się przeprowadzić bez migracji bazy klienckiej, co było podstawową obawą IT.
  • Kluczowym wymaganiem dla bilingu była zdolność prowadzenia wyceny usługi online. Nikt nie potrafił uzasadnić, dlaczego to jest wymaganie postawione systemowi bilingowemu, więc uzgodniliśmy jego wydzielenie z zakresu tego projektu i realizację w ramach działań rozwojowych systemów front-office.
  • Nie tylko udało się uzgodnić sposób realizacji oczekiwań, ale nawet uzyskać trochę czasu dla buforu projektu. Bardzo przydał się później…

Choć roadmapping może wyglądać na ćwiczenie zarządcze, nie jest nim. EA jest filozofią, która czyni takie ćwiczenie możliwym, a jego wyniki – bezpośrednio aplikowalnymi. Jest to ćwiczenie silnie merytoryczne – separuje „świat biznesu” od „świata technologii” tam, gdzie separacja powinna być utrzymana nie pozwalając jednocześnie na przemilczenie czegokolwiek, co uzależnia od siebie te dwa światy. W ten sposób tworzona jest płaszczyzna komunikacji między tzw. biznesem i tzw. IT, oferując wspólny i spójny język wyrażania wzajemnych oczekiwań, uwarunkowań i ograniczeń – umożliwiając w efekcie holistyczne planowanie rozwoju firmy uzależnionej od technologii.

Pozostaw komentarz