W roku 1997 biznes mediowy Polskapresse urósł do takich rozmiarów, że potrzebował wsparcia profesjonalnego systemu informatycznego.

Nie ma gotowych pakietów obsługujących sprzedaż powierzchni reklamowych, sporządzanie biznesplanów kampanii reklamowych, badanie ich skuteczności itd. Przed ogłoszeniem przetargu na wykonanie stosownego systemu opracowano jego wstępne założenia. Dotyczyły one obciążenia systemu (np. ilość danych, liczba klientów, liczba faktur, zależności między tymi wartościami) oraz funkcjonalności (moduły obsługi klientów, kalkulacja dla agencji, kalkulacja dla gazet, cenniki współpracujących gazet). Opisano też podstawowy proces biznesowy. Dla danego klienta układa się kampanię reklamową na bazie celów, jakie sobie wyznaczył, następnie wybiera grupę gazet, w których kampania będzie realizowana. Kolejny etap to wybór formatów, stron, emisji i sporządzenie kalkulacji (z baz pobiera się ceny, rabaty, dopłaty, itd.). Po zatwierdzeniu ich przez klienta wydawane są zlecenia do gazet.

"Wybraliśmy IMPAQ, który zaoferował korzystną cenę, podkreślał szwajcarską precyzję w swoim procesie produkcyjnym (jest to firma o rodowodzie szwajcarskim) i zapewnił nam wyłączność na ten produkt z możliwością przejęcia praw do kodu źródłowego" - mówi Artur Cichoń, dyrektor informatyki w Polskapresse z Warszawy. Po rozstrzygnięciu przetargu czteroosobowa grupa specjalistów z IMPAQ-u przez trzy miesiące przeprowadzała, metodą wywiadów, szczegółową analizę wymagań. Zrozumienie biznesu Polskapresse jest dosyć trudne. Jest to branża szybko rozwijająca się. A w samym biznesie mediowym jest wiele sytuacji skrajnych, nietypowych, które trudno zamknąć w określonych funkcjach. Ostatecznie więc zdecydowano się na rozpoczęcie budowy systemu od skonstruowania struktury bazy danych bez uszczegółowienia ramowych procesów w firmie. "Specjaliści IMPAQ-u powiedzieli, że później nałoży się na nią bez kłopotu taką funkcjonalność, jaką będziemy chcieli" - wspomina Artur Cichoń. Zaprezentowany przez IMPAQ projekt nie wzbudził w firmie żadnego sprzeciwu, żadnych komentarzy.

Po pół roku prac wdrożeniowych okazało się jednak, że współpraca między partnerami nie układa się dobrze: mimo zamknięcia pierwszego etapu, system nie był używany. "Nie można polegać na systemie, który nie uwzględnia wszystkich przypadków, jakie zdarzają się w naszym biznesie. A stosownej funkcjonalności nie zbudowano, ponieważ wstępne analizy nie były wystarczające. System budowano na najczęściej spotykanych wzorcach procesu, a nie na wszystkich możliwych" - twierdzi Artur Cichoń. Specjaliści IMPAQ-u mają jednak inne zdanie na temat pierwszych niepowodzeń. "W trakcie budowy systemu klient sam lepiej poznawał swój biznes i dochodził do wniosku, że pewne rzeczy można robić inaczej. Jego wymagania co do funkcjonalności wzrosły o 50%. Nic dziwnego, że nie mieściły się w założonym budżecie" - mówi Andrzej Padlewski, szef projektu z ramienia IMPAQ-u. Sprawy komplikował też dynamiczny rozwój rynku prasy i konieczność uwzględniania nowych zjawisk.

Każdy projekt informatyczny, choć ma na celu zbudowanie narzędzia do ułatwienia pracy jego przyszłym użytkownikom, jest dla nich uciążliwym obowiązkiem, dodatkowym utrudnieniem w pracy, czasochłonnym zadaniem o nieznanych efektach. "Przyszli użytkownicy systemu nie zawsze mieli dość czasu i umiejętności, aby zwrócić uwagę projektantom systemu na czynniki krytyczne w swojej pracy" - przyznaje Artur Cichoń. Natomiast Andrzej Padlewski zwraca uwagę, że szef informatyki za dobrze wcielił się w rolę pośrednika między przyszłymi użytkownikami a projektantami systemu: "Przez to użytkownicy czuli się mniej odpowiedzialni za trafność i wykonanie swoich wymagań". W efekcie użytkownicy otrzymali coś innego niż się spodziewali.

Na pewno też zawiodła komunikacja między klientem a wykonawcą zlecenia. "Brak komentarzy do projektu może wskazywać, że przedstawiliśmy go w języku mało zrozumiałym dla odbiorcy. Chociaż może też zdradzać fakt, że klient dostatecznie nie zapoznał się z dokumentacją" - przyznaje Andrzej Padlewski.

Mogłoby się wydawać, że obie firmy: klient i jego dostawca znalazły się w specyficznej, wyjątkowej sytuacji, że grozi ona kryzysem i gwałtownym rozstaniem. Nic podobnego. Opisany etap jest typowy dla wszystkich projektów informatycznych. Zawsze tak jest, że w momencie formułowania wymagań dla przyszłego systemu informatycznego, w okresie budowania założeń systemu firmy partnerzy znają siebie zbyt mało, a także swoje możliwości i umiejętności. A nie ma na to szans, aby dostawca systemu oddelegował swoich pracowników do pracy u klienta i oni tam wcielili się w jego szeregowych pracowników i w ten sposób poznawali biznes, dla którego potem zbudują informatyczne wsparcie. Dostawca poznaje firmę na podstawie komunikatów, które od klienta otrzymuje. Muszą zatem najpierw wypracować język komunikacji werbalnej i niewerbalnej. Paradoksalnie jednak umiejętność rozumienia partnera przychodzi nie wtedy, gdy jest najbardziej potrzebna - czyli na początku, gdy są formułowane wymagania - lecz w późniejszym okresie projektu, gdy trwa już bezpośrednia praca nad projektem i ujawniają się rozbieżności, a nawet konflikty. Przedtem bowiem każdy sądzi, że ten drugi ma na myśli dokładnie to, co on sam. Słowa wszak padają podobne z obu stron. Dopiero wprowadzenie w życie jakiegoś rozwiązania ujawnia, że te same sformułowania co innego znaczą dla każdej ze stron, a nawet dla każdej osoby zaangażowanej w projekt. Tak więc etap konfliktu i niezgodności jest w zasadzie nieunikniony, aby uczestnicy projektu przekonali się w czym się nie rozumieją i spróbowali od nowa znaleźć właściwą ścieżkę.

Tak było i w tym przypadku. W roku 1998 przyjęto nową formułę współpracy. Zamiast budować budżet dla całego projektu, jak to było wcześniej, zdecydowano co miesiąc płacić ryczałt za wykonanie określonych prac programistycznych. Pozwoliło to uniknąć kłopotliwych renegocjacji umowy w przypadku zmiany zakresu projektu. "To wygodna formuła, wówczas gdy klient jeszcze sam dokładnie nie wie, co ostatecznie będzie obejmował system informatyczny" - mówi Andrzej Padlewski. Z kolei dla Artura Cichonia była to gwarancja, że IMPAQ będzie wykonywał kolejne prace zgodne z priorytetami, które będzie wyznaczała Polskapresse, a nie według własnego wyobrażenia o kolejności działań.

Ponownie przeanalizowano wymagania dla systemu, zaprojektowano funkcje. Wykonane elementy oprogramowania testowano, przekazywano użytkownikom, wprowadzono zaproponowane zmiany, aż do uzyskania pełnej akceptacji. W styczniu 1999 r. uruchomiono pierwszą wersję oprogramowania. Użytkownicy byli z niego zadowoleni, jednak ich sposób wykonywania zadań trochę się w tym czasie zmienił, a poza tym byli już bardziej świadomi, w czym system informatyczny może im pomóc, następne więc pół roku system cyzelowano. W czerwcu zmieniono wersje bazy SQL na wyższą, dającą więcej możliwości. Tak powstała II wersja oprogramowania. Sprawdził się model pracy, w którym oprogramowanie jest tworzone małymi fragmentami, ale precyzyjniej zdefiniowanymi. Szybciej się wówczas wychwytuje pomyłki, a poprawki są mniej pracochłonne. Również korzyść dla użytkownika jest szybciej dostrzegalna i mobilizuje go do dalszej współpracy.

Od jesieni ub.r. trwają prace nad wprowadzaniem nowych funkcji umożliwiających pracownikom Polskapresse efektywniejszy model pracy. "Chodzi o to, aby naszych ludzi odciążyć od mało twórczej pracy, polegającej na wyszukiwaniu informacji czy kalkulowaniu. System powinien Çzrobić za nichČ tyle, aby oni mogli skupić się na kontaktach z klientem, na zarządzaniu jego potrzebami reklamowymi" - wyjaśnia Artur Cichoń. Wszystko wskazuje na to, że partnerzy rozumieją się już na tyle dobrze, iż te plany zostaną zrealizowane. Ale najpierw beczkę soli...