Gra w ryzyko

Dostawcy IT muszą przejąć od swoich klientów część ryzyka – to teza debaty oksfordzkiej Klubu CIO. Do walki stanęły dwie drużyny: drużyna CIO oraz drużyna prezesów firm IT.

RUNDA 1

Sławomir Soszyński: Ryzyko jest pewnym wydarzeniem, określonym prawdopodobieństwem wystąpienia i wyrażoną wielkością straty lub szansy. Zwykle na ryzyko patrzy się poprzez pryzmat negatywny. Powinno się jednak dostrzegać w nim także szanse. W warunkach polskich podczas zawierania umowy z dostawcą IT niejednokrotnie bierze się pod uwagę ryzyko wyłącznie o wpływie negatywnym, bez zwracania uwagi na możliwy transfer ryzyka (szansa). Inny trend panuje w głównych centrach finansowych, takich jak Londyn, Nowy Jork czy Singapur. Wynagrodzenie dostawcy zależne jest od sukcesu wdrożenia u klienta, odpowiedzialności za wdrażane usługi i rodzaje ryzyka, takie jak czas dostarczenia, jakość itd., u klienta. Model ten jest silnie skorelowany pomiędzy stronami umowy – sukces klienta jest sukcesem dostawcy. Podobnie jest z niepowodzeniami. Uważam, że taki model jest bardziej fair. Jednym z przykładów jest zarządzanie w chmurze. Klient, nabywając taką usługę u dostawcy, przechodzi z CAPEX-u na OPEX, co wpływa na model finansowy firmy. Zmienia się również model zarządzania ryzykiem. Dostawca zaczyna odpowiadać za ryzyka (często nie zdając sobie z tego sprawy na początku współpracy), które dotyczą prowadzonej przez klienta działalności, np. wynikające z obowiązujących przepisów prawa, strategiczne, operacyjne, transakcyjne itd. Dostawca staje się partnerem. My, klienci, szukamy takiego partnera. Szukamy strategicznego doradcy, który może zainwestować w długofalowe partnerstwo i obietnicę wyższej nagrody, biorąc na siebie część rodzajów ryzyka i związanych z tym inwestycji.

Bartosz Soroczyński: Dzielić się ryzykiem? Najważniejsze, jak przygotowane są projekty i jak w nich definiowane jest ryzyko. Czy jest to ryzyko technologiczne, integracyjne, czy wiąże się bezpośrednio z działalnością podstawową klienta? W jakim stopniu realizowany przez nas projekt wpływa na ryzyko związane z głównym obszarem biznesu klienta, a w jakim wpływa na ryzyko po stronie dostawcy? Firmy integratorskie, producenckie na rynku IT często działają zgodnie z regulacjami giełdowymi, amerykańskimi, dotyczącymi rozpoznawania przychodów. Im lepiej zdefiniowane ryzyko w projekcie, im precyzyjniej zwymiarowane, tym skuteczniej możemy te środki rozpoznać. Ważne jest rozpoznawanie przychodów. Dystrybutorzy czy integratorzy często nie chcą kredytować całości projektów, ale chcą dzielić się ryzykiem. Ryzykiem dwukierunkowym, przechodzącym od klienta do dostawcy i od dostawcy do klienta. Należy świadomie przygotowywać projekty, kierować się analizą zwrotu z inwestycji, żeby klient, odbiorca, zrozumiał specyfikę integratorów i dostawców. A dostawcy na etapie przygotowań do projektu powinni dobrze zrozumie specyfikę projektu, firmy. Takie zrozumienie pozwoli na podzielenie się ryzykiem dwukierunkowym, czy wręcz dzielenie się sukcesem. Dostrzegamy wolę relacji partnerskiej, dokładnego zrozumienia specyfiki biznesu klienta, współdzielenia ryzyka i takiego kształtowania projektu, żeby przyniósł sukces obu stronom.

Marek Kobielski: Mówimy o sytuacji, kiedy dostawca przychodzi do klienta z propozycją projektu. Tymczasem po jego stronie jest jeszcze wiele rodzajów ryzyka poprzedzających ten moment. Są związane z innowacyjnością produktu, z jego zaprojektowaniem w całym procesie R&D, wypromowaniem, wprowadzeniem na rynek. Dostawca ponosi ryzyko, że produkt nie będzie pasował lub okaże się nieinnowacyjny. Musi stworzyć kanały sprzedaży, wyedukować ludzi, którzy zainteresują klienta produktem. Dlatego w tej układance potrzebny jest integrator, z którym zwykle mają Państwo do czynienia. W całym procesie znajduje się między klientem a producentem i próbuje pogodzić wodę z ogniem. Niwelować, amortyzować ryzyko.

Pierwszą rundę zakończyło głosowanie, podczas którego 64 osoby z ok. 200 obecnych na sali przychyliły się do zdania reprezentowanego przez drużynę CIO.

RUNDA 2

Józef Wacnik: Z punktu widzenia odbiorców usług IT nie są potrzebne produkty, ale rozwiązania. Wynika to z ewolucji modelu świadczenia usług IT w organizacji. Obecnie dział IT wyszukuje obszary, w których można usługami IT zwiększyć efektywność działania organizacji. Wprowadza innowacyjne pomysły, ale żeby je zrealizować, potrzebuje od dostawców gotowych rozwiązań. Powinny być one opisane, skatalogowane, łatwe do dostosowywania do realiów firmy i biznesu. Następny element to przenoszenie tzw. profesjonalnego IT do dostawców. IT w organizacjach już nie świadczy pełnego portfela usług, oczekuje raczej wsparcia w realizacji pomysłów na etapie koncepcji, projektu i jego wdrożenia. Firmy unikają budowania własnych kompetencji w szerokim zakresie. Najczęściej są to kompetencje związane z kluczowym biznesem organizacji, pozostałe systemy przenoszone są do dostawców. Ryzyko też przenoszone jest do dostawców. IT oczekuje, że ryzyko nie tylko będzie współdzielone z dostawcą, ale wręcz w dużej części do niego przeniesione. To wynika z nowego modelu świadczenia usług IT. Nie mamy w tym modelu środków, aby całkowicie nim zarządzać. Dlatego nasze oczekiwania dotyczące współdzielenia i przejmowania ryzyka są ogromne i przypuszczam, że będą dalej rosły.

Marek Kobielski: Żyję chyba w innej rzeczywistości, ponieważ biorę ryzyko na siebie. Cały czas, zaczynając od fazy projektowej, przygotowania się do spotkania z klientem czy wielomiesięcznych negocjacji z nim, kiedy jeszcze nie wiemy, czy dojdzie do przetargu. To jest już ryzyko połączone z kosztami. Potem trafiam jako dostawca w ramy przetargu publicznego, gdzie często jednym z najważniejszych kryteriów jest cena, i ryzyko powiększa się o kolejny stopień. Chętnie zapewniłbym odbiorcy usługę „pod klucz”, tylko czasami ramy prawne powodują, że składam najtańszą ofertę. Firmy obciążone są coraz trudniejszymi projektami, dlatego dyskutujemy z klientami nad elaboratami prawnymi, które przerzucają na mnie większość kategorii ryzyka.

Jacek Pulwarski, Polskie Towarzystwo Informatyczne: Opowiadał Pan o ryzyku dostawcy, które jest zawsze, a wydaje mi się, że mówimy o ryzyku klienta...

Marek Kobielski: To naczynia połączone, należy rozpatrywać je razem. Cykl zaczyna się w momencie wymyślenia produktu i trwa do momentu, kiedy klient zacznie na nim świadczyć usługi. Klient jest zainteresowany minimalizowaniem ryzyka po swojej stronie, ale nie może się to odbywać kosztem zwiększenia ryzyka po stronie dostawcy.

Maciej Wiśniewski: Tak powinno być, kiedy mówimy o ryzyku przedsięwzięcia IT. Nie oczekuję, że klient będzie przyjmował na siebie ryzyko prowadzenia przeze mnie biznesu. Ja również nie chciałbym być odpowiedzialny za ryzyko biznesowe po stronie zamawiającego. Mogę wziąć na siebie ryzyko projektu – tym się zajmujemy, mówiąc o współdzieleniu.

Bartosz Soroczyński: Myśleliśmy, że jest to układ rodzinny – projekt jest naszym wspólnym dzieckiem, im lepiej go przygotujemy, tym lepsze będą później korzyści i rezultaty wynikające z jego realizacji.

Józef Wacnik: Chciałbym się odnieść do pojęcia tzw. ryzyka biznesowego. Czy leży ono po stronie dostawcy czy po stronie klienta? Jeżeli większość procesów biznesowych w organizacji jest przeniesiona do obszaru rozwiązań teleinformatycznych, jeżeli rozwiązania są w większej części obsługiwane przez dostawcę, to ryzyko biznesowe także przesuwa się w jego stronę. Nie ma klasycznego modelu, w którym IT jest albo wewnątrz, albo na zewnątrz. To obszar odpowiedzialności rozmytej, stąd poziom ryzyka i sposób jego szacowania są wyjątkowo trudne.

Maciej Wiśniewski: Jeżeli przyjmuję ryzyko na siebie, to powinienem mieć środki, mechanizmy, żeby nim zarządzać. Często jako dostawca, integrator, czuję, że ryzyko leży w znacznej mierze po mojej stronie, ale nie mam narzędzi do zarządzania nim. Jako przykład podam jeden z bardzo dużych projektów, które realizowałem dla sektora administracji państwowej. Kontrakt był nienegocjowalny. W trakcie prac okazało się, że wszystkie strony zgadzały się, że trzeba wykonać zmianę, ale nie można było tego zrobić. Należało realizować pracę zgodnie z umową, a po zakończeniu tego procesu musieliśmy wprowadzić zmianę, ale dopiero po odbiorze produktu przez klienta. Jako dostawca poniosłem koszt, a projekt opóźnił się o pół roku. Kto poniósł odpowiedzialność za ryzyko? Oczywiście, ja. Czy miałem wpływ na zarządzanie tym ryzykiem? Niestety, nie.

Jan Markiewicz, Ericpol: Do zarządzania ryzykiem potrzebna jest dokładna znajomość tematu, a więc wymagań klienta. Ericpol zajmuje się od lat zarządzaniem ryzykiem klienta. 95% artykułów naszej działalności stanowi eksport. A dlaczego nie Polska? Dlatego że nie mamy jasnego przekazu co do jego oczekiwań. Ryzyko zależy od klienta.

Sławomir Soszyński: Chciałbym się odnieść do Pana wypowiedzi. Jako dostawca technologiczny nie chce Pan brać na siebie ryzyka biznesowego. Jako klienci o tym wiemy i już na początku negocjacji musimy planować pesymistyczny scenariusz dotyczący strategii wyjścia. Nie jesteśmy na takim poziomie, aby zaufać dostawcy na tyle i być przekonanym, że przyjmie na siebie ryzyka związane z daną usługą. My też spędzamy dużo czasu nad tym, aby projekt zakończył się zgodnie z planem. Jak wiadomo, a badania rynkowe to potwierdzają, ponad 60% projektów nie kończy się zakładanym sukcesem.

Podczas głosowania po II rundzie 30 osób z 200 opowiedziało się za stwierdzeniem, że teza jest fałszywa.

RUNDA 3

Jarosław Serba: Z dyskusji wynika, że skłaniamy się ku temu, żeby przyjmować na siebie ryzyko związane z projekstami IT. Argumenty rozumiem, ale nie kupuję ich jako klient. Jeszcze 15–20 lat temu standardowym modelem świadczenia usług było oddzielne dostarczenie sprzętu na zasadzie odrębnej umowy i ponoszenie kosztów wdrożenia na zasadzie time and material. To był model akceptowany przez rynek. Obecnie większość kontraktów jest realizowana zgodnie z zasadą fixed price. W zależności od tego, czy projekt jest dobrze zdefiniowany, dostawca dostaje dodatkowo za ryzyko 20% lub więcej. To korzystne i wygodne dla dostawcy, niekorzystne dla klienta. Zmierzamy do tego, żeby tymi 20% się dzielić. Jako eksperci od biznesu czy jako vendorzy, czy jako integratorzy często przychodzicie i mówicie: Znamy wasz biznes, wiemy, jak działa rynek, znamy realia, potrafimy zrobić to lepiej niż wy. Jeżeli więc tak definiujemy zasady współpracy, to dlaczego chcemy przerzucać całość ryzyka projektowego czy usługowego na klienta? Gdy znamy dobrze proces, łatwiej przyjmujemy na siebie ryzyko. Tam, gdzie ryzyko jest słabo zdefiniowane, próbujemy przesunąć je na drugą stronę kontraktu, w konsekwencji nie mamy zarządzania ryzykiem, tylko zarządzanie kryzysem. Wniosek? Więcej czasu powinniśmy poświęcać na przygotowanie kontraktów, zdefiniowanie zakresu i na wypracowanie relacji kontraktowych.

Bartosz Soroczyńki: Nie mówimy o zmianie modelu, ale o jego udoskonalaniu. Zawsze byliśmy i jesteśmy otwarci na ryzyko. Chcemy przejść w kierunku bardziej partnerskiej relacji, bliższej współpracy przy opracowywaniu projektów, żeby lepiej zrozumieć biznes klienta i pokazać, jakie ryzyko jest po naszej stronie. Żeby nie tylko cena była brana pod uwagę, ale i inne parametry. Należy patrzeć nie tylko na ryzyko statystyczne, ale na prawdziwe ryzyko zwymiarowane w projekcie. Takie podejście nieczęsto spotyka się na polskim rynku. Na rynkach zagranicznych tendencja jest odwrotna – projekty time and material są tak przygotowane, że można wdrożyć proces zarządzania ryzykiem. Są i projekty fixed fee, ale głównym modelem jest time and material. Jako firmy, myśląc o ryzyku projektowym, bardzo dużo ryzykujemy – inwestujemy spore środki w prefigurowanie środowisk technologicznych. Mówimy o prefigurowaniu warstwy sprzętowej z warstwą middleware, z sieciową, bazodanową, czyli dostarczamy rozwiązania prefigurowane, pozbywając się ryzyka integracyjnego. Pod względem technologicznym nasz rynek dostawców się zmienia, co wpływa na integratora i na klienta.

Maciej Wiśniewski: Z dyskusji wynikają ciekawe wnioski. Dla producentów ryzyko zaczyna się dużo wcześniej, na etapie R&D, którego klienci i odbiorcy, a także być może sami vendorzy w kraju nie dostrzegają. Inaczej jest na etapie projektowym, kiedy ryzyko może (ale nie musi) być współdzielone. Projekty są często bardzo drogie, dlatego że nie ma zdefiniowanego zakresu ryzyka i dolicza się dodatkowe kwoty na ryzyko. Gdyby ryzyko było podzielone, prawdopodobnie za ten budżet można byłoby zrealizować dwa projekty, a nie jeden. Trzecia kwestia: nie ma jednego rodzaju firmy IT. Firmy IT muszą przejąć część ryzyka. Chcemy to robić w postaci zrównoważonej, z korzyścią dla klienta i dla powodzenia projektu. Nie mogę zrozumieć, w jaki sposób w modelu fixed pric koszt jest przerzucany na klienta. Moim zdaniem to się wyklucza. To właśnie w modelu fixed price koszt jest po stronie dostawcy. Modele time and material pokazują odpowiedzialność za to, że klient zobowiązuje się ponieść ryzyko przygotowania projektu i zakontraktowania ustalonych zasobów na określoną liczbę dni. U nas takich projektów nie ma. Jako branża bierzemy już ryzyko na siebie, przyjmujemy współodpowiedzialność za ryzyko projektowe, ale apelujemy, żeby była współmierność absorpcji ryzyka do możliwości zarządzania nim.

Stanisław Musiał, PT Allianz: Jeśli chodzi o dostawców IT, to część sprzedaje narzędzia i praktycznie nie ponosi odpowiedzialności, bo w ich imieniu działa inna firma, która ponosi ryzyko. Należy podzielić ryzyko na dostawców aplikacji czy wdrożeniowców i na dostawców narzędzi.

Bartosz Soroczyński: Myśląc o ofercie Oracle’a, mówimy o wszystkich rozwiązaniach: sprzętowych, związanych z oprogramowaniem aplikacyjnym, narzędziowym, o consultingu, o usługach dostaw rozwiązań. Moja firma partycypuje w ryzyku. Uwzględniamy kary umowne, czas reakcji itd. Jesteśmy również partnerem, który w niektórych sytuacjach występuje bezpośrednio, w innych w roli integratora, ale przez cały czas zarządzamy ryzykiem, staramy się je zwymiarować. Zawsze nastawiamy się na dobre przygotowanie projektu i wdrożenie zestawu narzędzi, które umożliwiają zwymiarowanie ryzyka i uwzględnienie go w projekcie.

Grzegorz Wielemborek, Millennium: Chciałbym powrócić do kwestii narzędzi do zarządzania ryzykiem. W metodologiach projektowych tymi narzędziami są budżet ryzyka i budżet zmiany. Z nich możemy dofinansować zmiany projektowe i wynikające z budżetu ryzyka. Stopień wykorzystania środków zależy od metodologicznego przygotowania projektu.

Jarosław Serba: Wydaje się, że dostawca, przekazując oprogramowanie, ryzyka praktycznie nie ponosi. Kiedy wdrożenie się nie udaje, to jednak część odpowiedzialności spoczywa na nim. Znam przykłady co najmniej dwóch wdrożeń, kiedy w takich sytuacjach się nie odwraca; postępuje tak głównie z uwagi na swój wizerunek

Marek Kobielski: Pewnych rzeczy nie da się zapisać w umowach i tylko relacje między klientem a dostawcą regulują kwestie, czy idziemy ścieżką pokojową czy wojenną.

Sławomir Soszyński: Zanim produkt wejdzie w fazę produkcji, firma poświęca dużo czasu w dziale R&D na jego opracowanie. W branży finansowej mamy wspólne R&D z naszymi kluczowymi dużymi partnerami (partnerami, nie dostawcami). Uważam, że granica pomiędzy tym, czym jest biznes, a IT będzie się w dalszym ciągu zacierać. To IT wdraża rozwiązania biznesowe. Podejście do bliskiej współpracy w zakresie prowadzenia R&D pozwala dostawcy IT zrozumieć, jak działa klient i jakie są jego oczekiwania. Dla klienta jest to również dobry model, ponieważ może skorzystać z wiedzy dostawcy z innych sektorów gospodarki, trendów rynkowych i potencjalnych nisz rynkowych. W takim przypadku partnerstwo częściowo rekompensuje ryzyko bo obu stronach.

Po końcowym głosowaniu debatę oksfordzką wygrała drużyna prezesów firm IT.

W celu komercyjnej reprodukcji treści Computerworld należy zakupić licencję. Skontaktuj się z naszym partnerem, YGS Group, pod adresem [email protected]

TOP 200