Do rozpoczęcia projektu wdrożenia nowego rozwiązania, aplikacji czy systemu potrzebny jest nam dostawca, który ten produkt nam sprzeda lub na zamówienie wytworzy. Różnorodność funkcjonujących tutaj mechanizmów jest ogromna, każda firma może trochę inaczej podchodzić do tematu. Firma może np. posiadać własny zespół programistyczny i takie zlecenia realizować wewnętrznie. Może mieć też grupę dostawców działających w ramach stałego software house i w uproszczony sposób realizować zamówienia. Lub wychodzić za każdym razem z zapytaniem na rynek.
Zobaczmy z czym taki proces może się wiązać. Przyjmijmy najbardziej rozbudowaną ścieżkę. Biznes zgłasza nam zapotrzebowanie na nową aplikację, której potrzebują, aby usprawnić pracę. Zebrali część ogólnych wymagań, mają określony budżet i zwracają się do IT z prośbą o realizację zadania (trochę idealna wizja, ale na razie to pomińmy :) ). W trakcie bardziej dokładnej analizy (przy wsparciu analityka :) ) dochodzimy do wniosku, że najpierw chcemy zbadać rynek pod kątem możliwości. Tworzy się zespół projektowy, często jest to zainteresowany biznes, IT i kupiec, odpowiedzialny za przeprowadzenie postępowania ofertowego. Zostaje przyjęta strategia RFI - RFP - wybór dostawcy. Metoda zakupu to fixed price. Ok, a teraz po kolei.
RFI - request for information czyli zapytanie o informacje. Jest to pierwszy krok na ścieżce do ostatecznego zakupu. Zapytanie kieruje się z reguły w formule przetargu otwartego, gdzie każdy dostawca może się do nas zgłosić. Zakres wymagań jest na ogólnym poziomie, stąd też i oferty często nie są szczegółowo dopracowane. Celem RFI jest sprawdzenie czy to czego oczekujemy jest w mniejszym lub większym stopniu do osiągnięcia. Po wpłynięciu ofert możemy zorganizować warsztaty z dostawcami aby lepiej poznać proponowane rozwiązania. To postępowanie nie jest wiążące, nie zakładamy że wybierzemy konkretną firmę do współpracy. Po RFI jesteśmy w stanie lepiej sprecyzować wymagania i konkretniej oszacować budżet. Może się okazać, że wycofujemy się z projektu i na tym kończymy. Jeśli nie, przeprowadzamy RFP.
RFP - request for proposal, zapytanie o ofertę. Często jest w tym zawarte również RFQ (request for quotation), czyli ostateczne podpisanie umowy i ustalenie warunków. Do RFP możemy zaprosić te same firmy co do RFI, lub też dowolnie rozszerzać listę. Ten etap jest już bardziej szczegółowy, powinniśmy wiedzieć czego oczekujemy, na jakie koszty możemy sobie pozwolić oraz jaką formę współpracy chcemy wybrać. Warto poruszyć tutaj kwestie ewentualnej umowy, wsparcia po wdrożeniu czy licencji. Dostawcy mogą w trakcie procesu dopytywać o szczegóły. Warsztaty też są dobrym elementem rozwiewania wątpliwości. W zależności od organizacji weryfikowane są również pewne formalne kwestie typu zgodności KRS i inne lepiej znane kupcom odpowiedzialnym za proces. Jeżeli naszym celem jest wybór konkretnego rozwiązania często tworzy się zespół oceniający, który na podstawie przyjętych kryteriów ocenia otrzymane propozycje. Metody oceny mogą być dowolne, ale przeważnie zawsze dużą wagę stanowi cena. Gdy proces kończy się wyborem dostawcy przystępujemy do negocjacji oferty i planu wdrożenia.
Zakup możemy zrealizować w formule fixed price - mamy od razu określoną cenę za dostarczenie rozwiązania. FP ma swoje plusy i minusy, ponieważ łatwiej jest nam oszacować budżet, mamy pewne ramy których się trzymamy, ale z drugiej strony dostawcy często szacują "z górką" przy takich przetargach zabezpieczając się przed niedoprecyzowanymi wymaganiami. Ze strony zamawiającego też może się w trakcie okazać, że potrzebuje coś jeszcze. Wtedy do gry wchodzą CRy, czyli dodatkowe zamówienia w ramach change request. Warto nawet przy fixed price zostawić sobie pewną rezerwę w budżecie na tego typu rozszerzenia. Innym sposobem podejścia do tematu jest time and material, czyli "my Wam najpierw zrobimy i zobaczymy ile będzie to kosztować, a Wy dopiero wtedy zapłacicie". Hmm z jednej strony rozsądnie, bo płacimy za gotowy produkt, a nie za szacunki, z drugiej jednak kwestia zaufania do dostawcy. Wiadomo, że ten typ umowy jest uwarunkowany kontraktem, ale mimo wszystko. Z mojego doświadczenia częściej spotykam się z fixed price przy wychodzeniu na rynek. Time and material raczej używany do mniejszych zamówień, w obrębie zaufanych dostawców, z którymi mamy np. umowy ramowe.
A jak już dopniemy te wszystkie powyższe kwestie może nareszcie wystartować machina projektowa z komitetem sterującym, etapami, sprintami, kamieniami milowymi, testami, wdrożeniami itp, itd. :) No i oczywiście lessons learned na końcu :) Fajnym podsumowaniem opisanego procesu jest poniższy obrazek, który humorystycznie przedstawia początkowe oczekiwania w zderzeniu z możliwościami i ostatecznymi kosztami :) Nie musi tak być jeśli mamy bardzo gruby portfel i dużą swobodę, ale bardzo często właśnie tak się kończy.
