Najwyższy czas na edukację informatyczną

Dobry sojusz CXO wymaga efektywnej współpracy działów biznesowych i informatycznych. Ten cel może być osiągnięty tylko wtedy, gdy każda ze stron zrozumie zasady działania partnerów w sojuszu. Dotychczas to szefowie IT słyszeli ciągle, że muszą uczyć się biznesu. Czy jednak w tym sojuszu oni są tymi, którzy najpilniej potrzebują wiedzy?

Dobry sojusz CXO wymaga efektywnej współpracy działów biznesowych i informatycznych. Ten cel może być osiągnięty tylko wtedy, gdy każda ze stron zrozumie zasady działania partnerów w sojuszu. Dotychczas to szefowie IT słyszeli ciągle, że muszą uczyć się biznesu. Czy jednak w tym sojuszu oni są tymi, którzy najpilniej potrzebują wiedzy?

Chciałbym niniejszym przeprosić za słowa krytyki pod adresem działów IT, które padały na łamach kolumny Klubu CIO z mojej strony. Moje ostatnie obserwacje przekonują mnie, że kierownicy i pracownicy działów IT lepiej rozumieją cele biznesowe niż biznes i specyfikę operacji IT, także tę, związaną z wdrażaniem rozwiązań informatycznych bezpośrednio go dotyczących. Być może jest to rezultatem ciągłej presji, którą nakłada się na informatykę, aby uzupełniała wiedzę biznesową, co najwidoczniej czyni. Faktem jest, że w kilku rozpoznanych przeze mnie ostatnio przypadkach to "informatyka" wywiera presję na "biznes", aby ten określił racjonalnie i systematycznie swoje potrzeby, przeanalizował swoje procesy i przygotował specyfikację do wdrożenia rozwiązań informatycznych. Niestety, póki co bezskutecznie.

Zobacz również:



"Czego wy od nas chcecie?"

Duże polskie przedsiębiorstwo zamierza wdrożyć nowy system zintegrowany. Rozważanych jest kilka opcji systemowych. Odpowiedzialność za prowadzenie procesu określenia i wyboru opcji (nie wyboru systemu) spoczęła w rękach pracowników działu informatyki.

Ze względu na wysokie koszty obsługi i modyfikacji obecnego systemu decyzja o wdrożeniu rozwiązania zintegrowanego jest wysoce uzasadniona. Prowadzący proces zdają sobie jednak sprawę z tego, że wdrożenie dowolnego z wybranych rozwiązań bez przeprowadzenia pewnej reorganizacji obecnych struktur operacyjnych, przeanalizowania i zmodyfikowania procesów zakończy się niepowodzeniem. Zmniejszy się elastyczność organizacji. Podniosą się i tak już wysokie koszty utrzymania systemu. Dlatego usiłują wpłynąć na swoich biznesowych partnerów, aby dokonali oni określenia takich właśnie wymagań i zmian. Jak dotychczas bez rezultatów.

Z czego może to wynikać? Najbardziej prawdopodobne są dwie przyczyny. Po pierwsze, "biznes" nie rozumie specyfiki procesu wyboru i wdrożenia systemu zintegrowanego i nie widzi potrzeby tak systematycznego podejścia. Jednocześnie nie ufa swoim partnerom po stronie informatyki, którzy usiłują przeprowadzić ten proces w sposób systematyczny - wymagając odpowiedzi na wiele pytań dotyczących celów działania działów biznesowych już na samym początku procesu wdrożeniowego. Dlaczego? I tutaj pojawia się druga przyczyna. Przez długie lata działy biznesowe tej firmy korzystały (zwykle poza strukturami IT) z usług zewnętrznych dostawców, którzy budowali i modyfikowali systemy informatyczne. Dostawcy ci zwykle wykonywali wszystkie (czasem zupełnie nieracjonalne z punktu widzenia przedsiębiorstwa) zachcianki "biznesu". W konsekwencji strona biznesowa żyje w przekonaniu, że nie musi zastanawiać się nad żadnymi zmianami, poprawą efektywności itp., bo przecież wszystko da się zmodyfikować później i nikt im nie odmówi. A że będzie to kosztowało niewspółmiernie więcej? To przecież będzie koszt "informatyki".

"I tak znowu zrobią to bez nas"

W innym dużym polskim przedsiębiorstwie przez wiele lat "informatyka" wspólnie z dostawcą zewnętrznym budowała system informatyczny na potrzeby całej organizacji. Niestety sposób pracy dostawcy - kopiowany przez wewnętrznych informatyków - nie odpowiadał żadnym standardom prowadzenia projektów. W ciągu tych kilku lat to "informatyka" w oparciu o swoje wyobrażenia o działalności przedsiębiorstwa decydowała o funkcjonalności systemu, odsuwając "biznes" na bok. Oczywiście większość zbudowanych rozwiązań nie spełnia wymagań biznesowych i prawdopodobnie firma ta niedługo stanie przed koniecznością wdrożenia rozwiązania zintegrowanego. Sposób prowadzenia prac projektowych przez IT doprowadził jednak do sytuacji bardzo źle rokującej każdemu nowemu przedsięwzięciu informatyczno-biznesowemu.

Większość doświadczeń (a w szczególności świadomość błędów, których należy unikać) leży po stronie "informatyki". "Biznes" zaś, który przez lata był ignorowany, nie widzi sensu uczestniczenia w inicjatywach, na które nie będzie miał wpływu. Brak doświadczeń będzie natomiast powodował sytuację podobną jak ta w pierwszym przykładzie: brak zrozumienia potrzeby systematycznego podejścia.

"Mamy problem? Kupmy system"

Jeszcze inne duże polskie przedsiębiorstwo - i jeszcze inna sytuacja. Przez kilka lat "informatyka" prowadziła wiele różnych przedsięwzięć, w tym wdrożenie kolejnych elementów systemu zintegrowanego. Jednocześnie, przy braku jakiejkolwiek strategii informatyzacji przedsiębiorstwa, wszystkie zgłaszane przez "biznes" inicjatywy były natychmiast realizowane przez "dostawcę wewnętrznego". Można powiedzieć, że był to swego rodzaju punkt honoru ówczesnego dyrektora IT, żeby wykazać, że jest w stanie zrobić wszystko, co dotyczy informatyki wewnętrznymi zasobami. Generowało to mało identyfikowalny koszt (wynikający z prac zasobów wewnętrznych), więc nie było traktowane jak poważny problem.

W konsekwencji w przedsiębiorstwie tym istnieje bardzo dużo rozwiązań wyspowych. Nie są one koordynowane ze sobą, a część z nich w ogóle nie jest wykorzystywana, ze względu na nieumiejętne i zbyt pochopne decyzje dotyczące zakupu i wdrożenia takich rozwiązań.

Oprócz kosztu zakupu i utrzymania wielu zróżnicowanych technologicznie rozwiązań istotnym negatywnym skutkiem takiego podejścia jest rozleniwienie użytkowników biznesowych, którzy, przyzwyczajeni do spełniania wszystkich swoich zachcianek, mogą nie rozumieć na przykład konieczności rezygnacji z części wymagań funkcjonalnych względem jakiegoś rozwiązania informatycznego ze względu na zbyt wysokie koszty lub po prostu ich techniczną niewykonalność.

Dajmy partnerowi szansę

Na ile opisane przykłady są wyjątkiem, a na ile regułą? Pewnie po trosze jednym i drugim. Prawdopodobnie taka sytuacja jest możliwa w dużych instytucjach, gdzie służby informatyczne i biznesowe mogą (a przynajmniej mogły kiedyś) działać do pewnego stopnia niezależnie od siebie. Mniejsze instytucje naturalnie mocniej wiążą ze sobą poszczególne aspekty działania.

Trzy powyższe przykłady, choć mają różną genezę, prezentują te same objawy. Trzeba wyraźnie powtórzyć, że to "informatyka" jest w nich lepiej przygotowana do współpracy z biznesem niż odwrotnie. Po stronie "informatyki" leży bowiem więcej doświadczeń i wiedzy na temat poprawnego podejścia do prowadzenia projektów.

Niestety, wydaje się także, że ta dojrzałość "informatyki" w zakresie aspektów biznesowych nie jest w tych organizacjach rozpoznawana i cały czas pokutują stereotypy o ich technicznym podejściu do wdrażania rozwiązań informatycznych. Wewnętrzne służby informatyczne mają (nader często) nieuzasadnioną małą wiarygodność w aspekcie znajomości działań i celów biznesowych przedsiębiorstwa.

W sytuacjach takich jak opisane powyżej, można zaradzić powyższym problemom przynajmniej na dwa sposoby. Po pierwsze, konieczne jest ustalenie i konsekwentne realizowanie strategii IT. Musi to być obiektywny wskaźnik działań zarówno dozwolonych, jak i zakazanych w tym obszarze. Po drugie, należy wypracować model współpracy "biznesu" i "informatyki" w przedsięwzięciach informatyczno-organizacyjnych i zacząć go stosować i testować, począwszy od małych inicjatyw po duże przedsięwzięcia. Metodą małych kroków, ale zmierzających do celu.

Paweł Biarda jest konsultantem firmy doradczej Andersen Business Consulting.