„Szef kazał mi outsourceować”

Data: 2014-08-15
Autor: Sebastian Konkol
„Szef kazał mi outsourceować”

Outsourcing, termin modny dekadę temu, miał przynosić znaczące oszczędności. Niemalże każda funkcja IT, jaką można sobie wyobrazić, stała się przedmiotem eksperymentów outsourcingowych. Czasami okazywały się one sukcesem (przy określonej definicji słowa sukces), lecz w większości przypadków tak się sprawy nie kończyły. Efektem były powrotna fala „backsourcingu” oraz odium przypisane outsourcingowi. Outsourcing – jak każde inne narzędzie – nie jest ani dobry, ani zły. To sposób jego wykorzystania sprawia, że inicjatywy skorzystania z niego kończą się sukcesem lub porażką.

W mojej ocenie, sednem sprawy nie jest „jak outsourceować”, lecz „co outsourceować”. Zagadnienia „jak” utożsamiane są zwykle z zapisami kontraktowymi, co – w pewien sposób – zwalnia organizację z myślenia o przedmiocie takich prac. Zagadnienia „co” muszą być przez organizację przemyślane zanim sprawy kontraktowe zaczną być w ogóle tematem do dyskusji.

Pracując w projektach outsourcingowych dostrzegałem powtarzające się wzorce czynników, które mają największy wpływ na ostateczny sukces takich inicjatyw. Pośród nich znajdują się przede wszystkim:

  • Zależność od infrastruktury. Trudno jest poddać outsourcingowi system (lub jego część), jeśli współdzieli on duże części infrastruktury rozumianej nie tylko jako sprzęt, ale także jako platformę systemową i aplikacyjną, a także obowiązujące standardy. W takich sytuacjach trudno jest także oszacować „wolumen” infrastruktury, jaki zapewni odpowiednią jego pojemność.
  • Siła integracji z innymi systemami. Im mocniej zintegrowany system będący przedmiotem rozważań outsourcingowych, tym trudniej jest do „wyłuskać”. Poza oczywistą koniecznością wprowadzenia zmian w interfejsach systemu zmienia się także znacząco charakter integracji – B2B jest zasadniczo odmiennym zagadnieniem niż EAI.
  • Kompletność procesów biznesowych. Outsourcing części procesu biznesowego oznacza podział odpowiedzialności za cały proces – podział, którego wcześniej nie było. Złożoność takich zagadnień sprawia, że zwykle nie udaje się przewidzieć wszystkich konsekwencji wprowadzenia takiego podziału, a konsekwencje te „lubią się ujawniać” w najbardziej niekorzystnych okolicznościach.

Celem jest więc identyfikacja zbioru systemów (lub ich modułów), których outsourcing będzie reprezentował najmniejszy wysiłek i najmniejsze ryzyko. Identyfikacji tej najsprawniej jest dokonać na kanwie architektury korporacyjnej (Enterprise Architecture), analizując związki w każdej z „warstw” architektury (biznesowej, aplikacji, danych i technicznej). Takie zadanie realizuję zwykle zaczynając od określenia powodu dla outsourcingu, a przez to najmniejszego fragmentu architektury, jakiego outsourcing zapewnia wypełnienie powodu. Analizując związku tego obszaru z otoczeniem oceniam koszt transformacji architektury do postaci zapewniającej zdolność do outsourcingu przy minimalizacji czynników ryzyka. Wynikiem może być zarówno konieczność powiększenia tego obszaru, jak i jego zmniejszenia.

W praktyce ustalenie powodu dla outsourcingu jest zwykle znacznie poważniejszym zagadnieniem, niż przeprowadzenie analizy obszaru do podania takim działaniom. Każde takie przedsięwzięcie działa zwykle w otoczeniu ekonomicznym, w którym założenia są wyrażane w formie nie dającej się wprost przełożyć na architekturę. W efekcie powstają zwykle warianty zakresu projektu outsourcingowego, które muszą podlegać ocenie z perspektywy założeń (nie tylko ekonomicznych) dla outsourcingu.

Enterprise Architecture posiada zdolność integrowania bardzo zróżnicowanych punktów widzenia na środowisko systemów informatycznych i ich rolę w biznesie firmy. Bezpieczeństwo, zdolność do rozwoju i zarządzania stają się szczególnie istotne w przypadku outsourcingu. Złożone analizy granic i otoczenia obszaru podlegającego outsourcingowi, wymagające uwzględnienia tych i innych perspektyw, nie byłyby możliwe bez zachowania zdolności integracji wiedzy tworzonych przez filozofię architektury. Koncepcja i ramy organizacyjne zarządzania architekturą udostępniają menedżerom i inżynierom IT możliwości integrowania zróżnicowanych, punktów widzenia, często postrzeganych jako potencjalnie sprzeczne. Nie oznacza to, rzecz jasna, że EA rozwiązuje problemy – ludzie rozwiązują problemy. Jednak budowanie na kanwie Enterprise Architecture udostępnia narzędzia ich rozwiązywania – daje zrozumienie esencji zagadnień i przejrzystość oraz umożliwia podejmowanie decyzji bazujących na maksymalnym zbiorze informacji, obniżając ryzyko ich podejmowania. Spraw kluczowych w przedsięwzięciach o długoterminowych skutkach, jakimi są projekty outsourcingowe.

Pozostaw komentarz