Beyond Business-IT Alignment

Data: 2012-11-15
Autor: Sebastian Konkol

Choć w większości polskich przedsiębiorstw nadal pokutuje stereotyp głupiego biznesu i złego IT, myśl o zarządzaniu technologią ICT (technologia informacyjna i komunikacyjna) nie zważa na stereotypy i rozwija się. Nawet w Polsce kierownictwa firm dostrzegają, że nie tyle ich działalność, co podstawa ich biznesu zależą od tych technologii. Taka zależność jest oczywista w branżach biznesu internetowego, telekomunikacji, bankowości, ubezpieczeń, ale występuje także w mniej oczywistych przypadkach, jak logistyka, czy media wszelakie. Świadome zarządy firm wiedzą, lub powoli dostrzegają, że wiele można zyskać podpatrując nowoczesne metody zarządzania technologią, aby wdrożyć je wprost do strategii rynkowych i jako modus operandi metod prowadzenia biznesu.

Poprzednia dekada opierała się na dążeniu do powiązania działań IT z działaniami biznesu. Wyrazem takich dążeń były mnożące się metody planowania działań IT w oparciu o koncepcje Business-IT Alignment – w skrócie, zapewnienia takiego rozwoju IT, aby z jednej strony miał on szansę nadążyć za oczekiwaniami rynku w stosunku do swoich firm, a z drugiej inspirował biznes prezentując niewykorzystywane możliwości. Metody te mają jednak pewną wadę, którą ja nazywam prostolinijną naiwnością – zakładały bowiem, że w wszystkim generalnie zależy na tym, aby sprawy szły dobrze. To jest chyba powód, dla którego taka koncepcja budowania strategii nie stała się jedyną akceptowalną. To jednak kwestia czasu, który upłynie, zanim realia rynkowe przycisną kierownictwa polskich firm na tyle, żeby dostrzegły oczywiste korzyści wynikające z działań synergicznych, a nie „każdy sobie”. A tymczasem, warto pokazywać, że znacznie więcej się dzieje, a także to, że myślenie o budowaniu biznesu i jego prowadzeniu już dzisiaj korzysta z doświadczeń metod zarządzania ICT.

Pod koniec XX wieku do zarządzania rozwojem oprogramowania weszła metoda Rapid Application Development (sama zakorzeniona w Rapid Prototyping wykorzystywanej przez przemysł od lat 70 ubiegłego wieku), w dużym uproszczeniu opierająca się na tworzeniu prototypów poddawanych ocenie użytkowników. Takie podejście miało na celu przyspieszenie konstatacji, że „zupełnie nie o to chodziło” do jak najwcześniejszych faz projektu. Myślenie o inkrementalnym tworzeniu aplikacji i systemów informatycznych (wciąż ewoluujące i doskonalone), powiązane z zapewnieniem jak najwcześniejszej oceny użytkowników jest bardzo zbieżne w swych założeniach z metodami budowy biznesu opartej na podobnym schemacie – budowania minimalnego produktu i stopniowego jego wzbogacania, w niemalże ciągłej komunikacji z przyszłym lub potencjalnym klientem. Na takiej zasadzie opierają się metody budowy biznesu Customer Development (Steve Blank, 2005) czy Lean Startup (Eric Ries, 2011). Podobnie jak w projektach systemów informatycznych zrozumienie oczekiwań użytkowników wymaga poważnej analizy, próba zbudowania biznesu opartego wyłącznie na wyobrażeniu „budowniczych” będzie w najlepszym wypadku bardzo kosztowna – w większości przypadków prowadzi po prostu do porażki.

Kiedy w 2001 roku ogłoszono Agile Manifesto, rozwój systemów informatycznych „stanął na głowie”. Według sygnatariuszy – z czym zgadzam się w pełni – działający system jest lepszy niż dogłębna dokumentacja, a zdolność odpowiadania na zmiany jest istotniejsza niż realizacja planu. Na podstawie tych i innych zasad powstały metody rozwoju oprogramowania, w których w określonym z góry i krótkim czasie miało być dostarczona określona wartość biznesowa działającego oprogramowania, a ciągła zmiana planów stawała się czymś naturalnym. Te zasady nie wzięły się jedna z pustki międzygwiezdnej, laboratoriów badawczych, czy zaciszy bibliotek uczelni – podpowiedziały je realia prowadzenia biznesu w czasach obecnych. Zmienność uwarunkowań i skracające się cykle życia produktów to właśnie takie realia, a próby ignorowania realiów kończą się zwykle w sposób opłakany. Na szczęście, przemyślenia wynikające z ruchu agile są już włączane do kanonu działań biznesowych, a jedną z prób podejmowanych w tej sferze jest choćby Flexible Product Development (Preston G. Smith, 2007).

Odkąd złożoność systemów informatycznych wykorzystywanych w firmach osiągnęła poziom porównywalny ze złożonością organizacyjną miast, myślenie o ICT przyjęło na stałe do swojego słownika termin architektury, którego znaczenie bardzo bezpośrednio odnosiło się do budownictwa. Pojęcia projekty budynku, architektury, urbanistyki były inspiracją dla okiełznania narastającego w ogromnym tempie skomplikowania systemów i relacji między nimi. Stosowanie podejścia architektonicznego w ICT nie jest jeszcze dojrzałe, a wiele firm nadal pozostaje na poziomie projektu systemu. Tym niemniej, doświadczenia zgromadzone wokół architektury korporacyjnej (Enterprise Architecture) stać się mogą źródłem pomysłów na rozwiązywanie problemów „konstrukcji” organizacji firm, zapewniającej osiąganie stawianych przed nią celów. Architektura różni się od projektu systemu tym, że skupia się nie tyle na wymaganiach do wypełnienia, lecz na zmienności i izolowaniu wpływu zmian. W warunkach współczesnego biznesu zmienność procesów, outsourcing, sieci partnerskie oznaczają właśnie tyle, że zmiany zachodzić będą w znacznie większym tempie, niż zdolność ich absorbowania przez organizację. Ergo, ważniejszym staje się zdolność dostosowania do zmian, niż perfekcja realizacji aktualnej „wersji” procesów biznesowych. Doświadczenia identyfikacji „interfejsów” procesowych i organizacyjnych, ich standaryzacji i podmiany „komponentów” realizacji zadań biznesowych – opanowane przez architektów ze świata ICT – stanowią cenne źródło pomysłów doskonalenia organizacji i procesów firm. Poza monopolami, trudno bowiem mi sobie wyobrazić firmy, które nie byłyby poddawane presji ciągłych zmian i dostosowań do otoczenia rynkowego.

Wracając do powodów niniejszego wpisu, wierzę, że jedynym słusznym rozwiązaniem stereotypów jest partnerska współpraca między tzw. biznesem a tzw. IT. Piszę „tak zwanym”, bo nie rozumiem tego rozdziału – szczególnie w branżach, w których działalność biznesowa jest po prostu stosowaniem technologii – ICT jest po prostu częścią biznesu, jak obsługa klienta, zarządzanie finansowe, czy marketing. Wierzę także, że obie strony „mitycznego konfliktu” skorzystają bardzo, jeśli zaczną się od siebie nawzajem uczyć. Zainteresowanym metodycznym podejściem do przyszłości relacji między biznesem a IT, polecam także lekturę z 2008 roku: Peter Hinssen “Business/IT Fusion How to move beyond Alignment and transform IT in your organization”, Mach Media NV/SA, ISBN: 9081324233. Jak zwykle, pozostaję do dyspozycji.

Pozostaw komentarz