Weryfikacja dostawcy IT

Data: 2015-02-02
Autor: Sebastian Konkol
Weryfikacja dostawcy IT

Od pewnego czasu moje życie konsultanta uczy mnie pokory. Przez kilka ostatnich lat wydawało mi się, że już „tak wiele widziałem”, że niewiele jest mnie w stanie zaskoczyć. A tu proszę, nowy projekt i niemalże każdego dnia uczę się czegoś nowego. Trochę smutne, że to głównie doświadczenia negatywne, ale to przecież także nauka. Podobnie, jak przez lata poznawałem głębie znaczenia terminu „problemy komunikacyjne”, tak teraz poznaję nowe znaczenie „trudności we współpracy z dostawcą”.

Nie o to chodzi, jaka jest branża klienta, ani który to dostawca. Zawsze uważałem, że – w przytłaczającej większości przypadków – zamawiający są bezradni wobec „widzimisiów” dostawców IT. Co ciekawe, część zamawiających postanawia oddawać poszczególne obszary swojego IT pojedynczym dostawcom, efektywnie tworząc im warunki monopolu (sic!). Miałem przyjemność współpracować z dostawcami, których modus operandi jest zupełnie inne – to są jednak rzadkie (choć chlubne) wyjątki. W większości przypadków relacja nie ma nic wspólnego w sytuacją win-win. Zamawiający się napinają, krzyczą na spotkaniach operacyjnych, eskalują do najwyższych możliwych szczebli, a dostawcy i tak robią to, co uważają za właściwe, reprezentując po prostu swój interes.

Zamawiający zgłasza błędy i – o dziwo – to on musi udowodnić, że to jest błąd. Kiedy już ten kontredans zostanie odtańczony, dostawca zapewnia o gotowości do usunięcia błędu, kiedy tylko zamawiający powie mu dokładnie co i jak ma zrobić. Zamawiający się na tę pułapkę łapią – i od tej pory to oni odpowiadają za analizę i spójność projektu technicznego.

Inna sytuacja, zamawiający dostaje do recenzji (tzw. odbioru) dokumentację, która nie nadaje się do niczego. Jedyny sensowny komentarz powinien brzmieć: to jest nie na temat. Dostawca jednak żąda szczegółowych uwag do tego dokumentu, aby go przerobić odpowiednio. Równie skuteczne byłoby przerobienie „Pana Tadeusza” na instrukcję użytkownika systemu informatycznego. Tym niemniej, zamawiający ulega żądaniom dostawcy – i od tej pory odpowiada za wszystko w tym dokumencie, efektywnie biorąc na siebie zadanie wykonania go.

Wszystko byłoby fajnie, gdyby czas był z gumy, ale nie jest. Upływ czasu działa na niekorzyść zamawiającego – to jego projekt się opóźnia, a że – być może w ostatecznym rozrachunku – z winy dostawcy, jest tu nieistotne. Projekt jest powołany z konkretnego powodu, ma uzasadnienie, które nie pozostanie niezmienne po wsze czasy. Zamawiających nie stać na to, żeby być zależnym od takiego dostawcy. Czy jest wyjście? Oczywiście, że jest – konkurencja.

Na bazie tych doświadczeń wyłonił się z moich przemyśleń pomysł na nieco inne podejście do tworzenia relacji zamawiający-dostawca, oparty na trzech fundamentach:

  • Zasady współpracy. Po pierwsze, dla każdego obszaru dostawców powinno być dwóch. Już wiele lat temu mistrz teorii gier John Nash udowodnił (dylemat więźnia), że w takiej sytuacji jedyną wygrywającą strategią takich dostawców jest współpraca między sobą. Po drugie, dostawcy powinni być karani jednostkowo za swoje błędy, ale nagradzani za jakość wykonania w całym obszarze powierzonym im. Po trzecie zamawiający powinien mieć prawo decydowania, któremu dostawcy powierzy zadanie z tego obszaru oraz do dołączenia „trzeciego” bez uzgadniania tego z dwoma wcześniejszymi. I to wystarczy, co do zasady.
  • Weryfikacja przed rozpoczęciem współpracy. Każdy dostawca powinien być weryfikowany na konkretnym, małym zadaniu, a weryfikacja powinna obejmować merytorykę, postawę współpracy i pracę zespołową. Wszak właśnie tak wygląda to dzisiaj – wiele tymczasowych zespołów, wiele projektów. I warto zapłacić za takie właśnie małe zadanie, gdyż później oszczędzi się znacznie więcej, unikając „złych dostawców”.
  • Kontraktowe zasady współpracy muszą umożliwiać premiowanie dostawcy – inaczej mówienie o sytuacji win-win jest wyłącznie fikcją literacką.

Standardem powinno być więc dążenie do relacji partnerskich zamawiającego z każdym z dostawców oraz relacji kontrolowanego współzawodnictwa między dostawcami – i kij, i marchewka.

Czy taki model współpracy jest trudniejszy? W mojej opinii nie jest, choć jeśli porównać go do obecnie stosowanego, to ujawnia on konieczność realizacji większego wachlarza zadań. W obecnie, powszechnie stosowanym modelu tych zadań nie było, tylko „w pewnym momencie” okazuje się, że zamawiający jest zaskoczony zaistniałą sytuacją. Nazywam do zarządzaniem przez zamykanie oczu.

Jak w każdym wypadku, jest tu także zagadnienie etyki. Działy zakupów technologii zwykły zachowywać się jak „wyciskarka do cytryn”, eliminując możliwość wytworzenia sytuacji partnerskiej na samym początku relacji zamawiający-dostawca. Na tym jednak cierpi wyłącznie zamawiający. Na tak zdefiniowaną złą wolę mój model nie pomoże – dostawcy przyciśnięci do ściany zmówią się i zamiast monopolu będzie oligopol, równie skuteczny w destrukcyjnych działaniu, ale poważniejszy w konsekwencjach dla zamawiającego.

Nie ma mechanizmu kontraktowego eliminującego wszelkie możliwe niegodziwości. Kontrakt powinien tworzyć środowisko dla budowy relacji zamawiający-dostawca, w której żadna ze stron nie będzie poddana sytuacji win-lose. To jak z wychowaniem dzieci: wychowanie wyłącznie przez karanie produkuje przestępców, a wyłącznie przez nagrody – socjopatów. Wierzę głęboko, że relacja zamawiający-dostawca ni musi być z definicji patologiczna. Ktoś jeszcze w to wierzy?

komentarze 2 dla

  1. Adam Gawlik napisał(a):

    Trafiłem tu przypadkowo (tagi mnie przywiodły).
    Kolego, przestań zamieszczać te swoje wypociny. Mam Ci uwierzyć, że jesteś PM? Piszesz jakbyś skończył filozofię lub inne bajkopisarstwo. od razu czuć humanistą. Zero konkretu – maximum lania wody. Gdzie tu doswiadczenia? Autor podszywa sie pod kogoś innego. Nie polecam.
    Adaś

  2. Sebastian Konkol napisał(a):

    No cóż. Takie komentarze także się trafiają. Wolność Internetu i każdy może powiedzieć, co myśli.
    Jakby to ujął John Keating: pudło, ale dziękuję za wypowiedź.

Pozostaw komentarz