Redakcja Asseco News
e-mail: [email protected]
Od 1 stycznia 2014 r. Asseco przejęło obsługę informatyczną domeny Fix w Orange Polska w ramach programu konsolidacji dostawców.
Rys historyczny
Rok 2013 dla Pionu Telekomunikacji i Mediów zapowiadał się jako bardzo pracowity i wyjątkowy. Orange Polska (jeden z kluczowych klientów) kończył trzyletnie kontrakty z obecnymi dostawcami oprogramowania i rozpoczynał procedurę wyboru dostawców na kolejne trzy lata w ramach umów Vendors Consolidation 2. Asseco, jako aktualny dostawca oprogramowania w domenie Billing, uczestniczyło w tym postępowaniu.
Ponieważ Klient zmienił podejście do podziału tzw. domen i postanowił zmniejszyć liczbę dostawców, postępowanie stało się jeszcze trudniejsze. Cały obszar aplikacji został podzielony na domenę Fix (usług telefonii stacjonarnej) i domenę Mobile (usług telefonii komórkowej). Asseco złożyło oferty w obu proponowanych przez Orange obszarach i w wyniku postępowania podpisało umowę na dostawę usług w domenie Fix.
Jako że Asseco Poland przez poprzednie trzy lata było dostawcą domeny Billing, a ta stała się częścią domeny Fix, posiadane przez PTiM doświadczenie zaprocentowało podczas kolejnych etapów przygotowań do świadczenia usług.
Rozpoczęcie tranzycji
Sama tranzycja, czyli proces przechodzenia na nowego dostawcę, rozpoczęła się w ostatnich dniach sierpnia 2013 r. i zgodnie z harmonogramem została podzielona na dwa obszary. W pierwszym znalazło się 11 aplikacji z byłej domeny Billing. Dla tej grupy tranzycja miała trwać jedynie miesiąc i prowadzić do przejęcia tzw. pogłębionego utrzymania (jest to przejęcie odpowiedzialności za całość działania systemów „powyżej” infrastruktury, a więc zarówno warstwę systemu operacyjnego, bazodanową, aplikacyjną, jak i interface’ów). Wiązało się to z opanowaniem czynności administracyjno-operacyjnych, które dotychczas wykonywane były przez Orange Polska, a po podpisaniu umowy VC2 przechodziły pod obsługę Asseco.
Druga grupa 16 aplikacji (nowych dla Asseco) miała harmonogram tranzycji rozpisany na cztery miesiące i miała zostać przejęta w pełnym zakresie przez Asseco od 1 stycznia 2014 r.
Etapy tranzycji dla strumienia I
Strumień I, czyli aplikacje dotychczas utrzymywane przez Asseco, ze względu na bardzo krótki okres przejęcia wymagał dużego wysiłku w pozyskaniu wiedzy czysto operacyjnej. Zadania, które dotychczas wykonywał Klient, musiały zostać przeniesione do Asseco. Pomimo, że systemy były w ciągłej eksploatacji i osoby po obu stronach procesu przejęcia wiedzy musiały dopasowywać grafik spotkań do obciążeń systemu i jego uwarunkowań eksploatacyjnych – po miesiącu pierwszy etap tranzycji został z powodzeniem zakończony.
Etapy tranzycji dla strumienia II
Strumień II, czyli nowe aplikacje, był dużo większym wyzwaniem. Ten etap rozpoczął się od procesowania uprawnień do nowych obszarów dla osób zaangażowanych w ich przejęcie. Kluczową rolę odegrali tu administratorzy, którzy wymieniali między sobą setki maili i dokumentów formalnych dopuszczających do danych i środowisk.
Drugi etap tranzycji to budowa i uruchomienie środowisk dla nowych systemów. Wiązała się z tym również ogromna praca zespołu administratorów. Bez nich nie mogłoby być mowy o dalszych działaniach, kompilacji kodów, połączeniu systemów itd. Zadanie budowy środowisk kończyło się dostarczeniem raportów ich instalacji i tym samym zamykało tę fazę tranzycji. Finalizacja tego procesu miała jeszcze jeden kluczowy aspekt. Była „bitem startu” dla działów rozwojowych, które w tym momencie mogły przystąpić do prac. Dla klienta dopiero teraz rozpoczęło się właściwe przejęcie. To trochę jak z budową domu – nikt nie widzi budowania fundamentów, bo na budowie nic się nie dzieje, ale bez tego nie da się później stawiać ścian, dachu, okien i drzwi.
Kolejnym etapem było pozyskanie repozytoriów kodów produktów. Miało ono na celu przejęcie kodów źródłowych aplikacji, ich kompilację i porównanie z wersjami aktualnie używanymi na środowiskach produkcyjnych. Oprócz samych kodów źródłowych przekazywany był dostęp do Centralnego Repozytorium Kodów Źródłowych (CRKŹ), gdzie oprócz kodów źródłowych znajdują się dokumentacje produktów.
Następnym elementem tranzycji było pozyskanie wiedzy – ten etap trwał najdłużej. Do jego wykonania zostały powołane zespoły operacyjne po obu stronach: dostawcy i Klienta. Takie zespoły spotykały się w cyklach roboczych, przekazując sobie wiedzę operacyjną. Na jej podstawie stworzono dokumentację produktu zwaną Product CookBook. Sam PCB jest obszerną dokumentacją opisującą zarówno aspekty użytkowe systemu, jak i jego bezpieczeństwo, procedury administracyjne itd. Dla niektórych systemów dokumentacja ta ma ponad 500 stron plus załączniki. PCB jest dokumentem napisanym w jednakowym układzie merytorycznym dla wszystkich systemów, z porównywalnym poziomem szczegółowości. Jest to wartość dodana tranzycji, gdyż dzięki takiemu podejściu wszystkie systemy domeny BSSFixed są opisane w podobny sposób, a to ułatwia wprowadzanie nowych osób do systemów i zapoznawanie się z jego działaniem. Skraca to czas niezbędny do poznania nowego systemu.
Jednocześnie trwało kolejne zadanie mające na celu opisanie struktury zbiorów logicznych według metodyki IFPUG. Miało to służyć przyszłej normalizacji i ocenie złożoności zamian aplikacyjnych mierzonej w punktach funkcyjnych. Metodyka ta pozwala na oszacowanie złożoności aplikacji i jest sposobem przyjętym przez Orange do rozliczeń w ramach umowy VC2. Udokumentowanie map zbiorów logicznych pozwala ograniczyć liczbę spotkań Komitetu Uzgodnień Merytorycznych, których celem jest osiągnięcie konsensusu i wyjaśnienie rozbieżności pomiędzy wycenami stron. Zmniejszyło to czas TTM poprzez skrócenie procesu kontraktowania.
Budowanie wiedzy, kompetencji i dokumentacji to proces, który toczył się wraz z dwoma poprzednimi, a jego efektem miały być kolejne aktualizacje dokumentacji Product CookBook.
Sprawdzenie umiejętności, czyli faza TPAM. Ostatni miesiąc tranzycji upłynął na eliminowaniu błędów produkcyjnych podczas fazy nadzorowanego utrzymania. Podczas tej fazy zgłoszono prawie 70 błędów produkcyjnych. Rozwiązania przedstawiane przez Asseco podlegały akceptacji Orange i dopiero po poprawnym wypełnieniu wszystkich zadań została zaakceptowana faza TPAM, czyli ostatni element odbioru tranzycji.
Podsumowanie
Początkowo tranzycja wyglądała na projekt niezbyt skomplikowany, jednak z tygodnia na tydzień pojawiały się nowe wątki wymagające uwagi. Bez tych dodatkowych operacyjnych wątków, które nie miały produktów wymaganych dokumentami umowy, nie byłoby możliwe ukończenie tranzycji w terminie. Każdy z nich wprowadzał zmiany harmonogramu i zwiększał zakres prac. W szczytowym okresie lista wątków „okołotranzycyjnych” (które można nazywać podprojektami) wyniosła 30. Wszystkie dodatkowe zadania musiały być wykonane, aby od 1 stycznia 2014 r. Asseco w sposób właściwy mogło świadczyć usługi dla Orange.
Dodatkową trudnością był sam moment przekazania odpowiedzialności Asseco. Przez cały okres tranzycji oprogramowanie przejmowane przez Asseco było rozwijane przez obecnych dostawców. Aktualizowano kody źródłowe, usuwano błędy produkcyjne, co sprawiało, że zdobyta wiedza niekiedy stawała się szybko nieaktualna. Zespoły musiały się wykazywać błyskawiczną reakcją na zmieniające się otoczenie projektu. Ten aspekt był chyba najtrudniejszym elementem tranzycji, aby z punktu widzenia procesów biznesowych nie była widoczna zmiana dostawcy. I to, że po stronie biznesu i ciągłości działania systemów nie została zauważona zmiana dostawcy, uważamy za największy sukces zespołu.
Projekt w liczbach
Dokumentacja projektu (Product CookBook, dokumentacje techniczne, administracyjne, raporty) zawiera ponad 12 tys. stron i zajmuje ponad 1,8 GB danych.
Projekt objął swoim zakresem ponad 130 osób z Pionu Telekomunikacji i Mediów.
Odbyło się 18 spotkań Komitetu Techniczno-Organizacyjnego oraz 16 wewnętrznych spotkań statusowych. Do tego należy dodać około dwustu spotkań operacyjnych zespołów.
Tekst: Maciej Sysakiewicz