PRAKTYKI GODNE POLECENIA

Transkrypt

1 PRAKTYKI GODNE POLECENIA REKOMENDOWANY PROCES ZAKUPU APLIKACJI IT Rekomendacja Polskiego Stowarzyszenia Menedżerów Logistyki i Zakupów

2 dokument przygotowali: Joanna Smolińska - manager ds. Zakupów, ING Usługi Finansowe S.A. dr inż. Andrzej Bobiński - prezes zarządu, Logifact Marek Jędra - wiceprezes, Quantum software S.A. Andrzej Zawistowski - członek zarządu PSML Adam Błuś - wydawca, Eurologistics str. 2

3 PROPONOWANE ETAPY I. Analiza potrzeb wewnętrznych (w tym cele biznesowe i oczekiwane rezultaty). II. Analiza rynku (dostępne produkty i potencjalni dostawcy) - RFI (zapytanie o informacje). III. Ustalenie strategii wsparcia systemowego. IV. Elementy kosztowe TCO (całkowity koszt użytkowania). V. Kryteria wyboru i określenie ich ważności (wag). VI. Przygotowanie zapytania ofertowego - RFP. VII. Analiza ofert i negocjacje. VIII. Wybór dostawcy i podpisanie umowy. IX. Realizacja umowy (wdrożenie, szkolenie, wsparcie posprzedażne i dalszy rozwój aplikacji). I. ANALIZA POTRZEB WEWNĘTRZNYCH (w tym cele biznesowe i oczekiwane rezultaty) JEST TO NAJWAŻNIEJSZY ETAP CAŁEGO PROCESU ON DECYDUJE O JEGO POWODZENIU! Pierwszym krokiem jest powołanie Zespołu Projektowego z udziałem: -- właściciela procesu biznesowego, -- przedstawicieli komórek, którzy dany proces obsługują, -- IT (specjalisty ds. wdrożeń i wsparcia technicznego oraz specjalisty ds. infrastruktury), -- analityka finansowego (kontroling), -- osoby odpowiedzialnej za przeprowadzenie procesu zakupowego. str. 3

4 Rekomendujemy, aby liderem Zespołu Projektowego została osoba odpowiedzialna za proces zakupowy. Podstawowym zadaniem Zespołu Projektowego jest przygotowanie tzw. business case i uzyskanie akceptacji kierownictwa firmy i środków finansowych na jego rozpoczęcie. Zaczynamy od szczegółowego opisu procesu biznesowego, który chcemy wprowadzić lub poprawić - opis powinien być wsparty wizualizacją graficzną przedstawiającą poszczególne etapy/działania w procesie i ich wzajemne zależności. Musimy również precyzyjnie określić jaki jest cel biznesowy tego procesu oraz oczekiwane rezultaty (funkcjonalności) dla poszczególnych jego etapów. Podsumowanie: SKONCENTRUJ SIĘ NA PROCESIE I POTRZEBACH BIZNESOWYCH A NIE NA NARZĘDZIACH IT. NIE DOPASOWUJ PROCESU DO DOSTĘPNYCH NARZĘDZI. JASNO OKREŚL CELE, KTÓRE CHCESZ OSIĄGNĄĆ I OCZEKIWANE REZULTATY. SKUP SIĘ NA WYNIKU A NIE NA METODZIE JEGO OSIĄGANIA (POZOSTAW SZCZEGÓŁOWE ROZWIAZANIA NA KOLEJNE ETAPY). Teraz kolej na sprawdzenie, jakie aplikacje są dostępne na rynku, oraz które w optymalny sposób mogą wesprzeć nasz proces biznesowy. str. 4

5 II. ANALIZA RYNKU (DOSTĘPNE PRODUKTY I POTENCJALNI DOSTAWCY) - RFI (zapytanie o informacje) Podstawowe cele tego etapu to: 1. Analiza rynku: a) rynek dostawców - wybór tych, których zaprosimy do składania finalnych ofert, b) rynek produktów - sprawdzenie w jakim stopniu dostępne narzędzia/aplikacje IT spełniają nasze potrzeby i oczekiwania biznesowe (jaka będzie skala niezbędnych modyfikacji do aplikacji z półki - jeżeli takie są). 2. Weryfikacja naszych oczekiwań biznesowych - benchmarking z najlepszymi rozwiązaniami w projektowanym przez nas procesie. 3. Przekazanie informacji o naszych uwarunkowaniach. 4. Weryfikacja naszych wstępnych założeń budżetowych (koszty i czas realizacji). Elementy, które MUSIMY uwzględnić w RFI (przed wysłaniem RFI Umowa o Poufności): 1. Nasz proces biznesowy wraz z celami i oczekiwanymi rezultatami - na poziome ogólnym plus te ograniczenia które są niezbędne. 2. Architektura systemu oraz nasze środowisko informatyczne: a) wymagania sprzętowe (np. rodzaj sprzętu, terminali, itp.), b) ograniczenia technologiczne, c) inne systemy i aplikacje oraz konieczne interfejsy. 3. Ewentualne ograniczenia formalno-prawne (prawne elementy umowy) oraz finansowe (np. termin płatności) - jeżeli takie wynikają z polityki firmy i nie możemy ich zmienić. TYLKO TE NIEZBĘDNE - w przeciwnym wypadku już na tym etapie możemy nie potrzebnie wyeliminować lepsze rozwiązania. str. 5

6 Elementy, o które MUSIMY zapytać w RFI (zapytaniu ofertowym): 1. Standing prawno - finansowy (KRS, Bilans, Rachunek Zysków i Strat). 2. Liczba aktualnie realizowanych projektów i szacunkowa średnia wartość (przychód) jednego projektu. 3. Referencje z wdrożonych narzędzi wraz z kontaktami do kierowników projektu po stronie ich klientów - jeżeli jeszcze pracują; jeżeli nie to do właściciela procesu, który wdrożony projekt obsługuje i do opiekuna (maks. 4-5 referencji; preferowane min. 2 referencje z naszej branży np. farmacja, bankowość czy logistyka - na tym etapie nie wymagajmy bezwzględnie referencji tylko z branży). 4. Model licencjonowania aplikacji. 5. Model opłat za wsparcie powdrożeniowe (czy opłaty są roczne, kwartalne? Czy stanowią % od wartości pierwotnego wdrożenia? Czy rosną w przypadku gdy modyfikujemy aplikację w trakcie jej użytkowania? itp.).kompetencje oraz ilość aktualnie zatrudnionych specjalistów w podziale na poziomy ich doświadczenia (junior, senior, itp.) - ich dostępność, język i lokalizacja. Elementy które możemy uwzględnić w RFI (jeżeli np. po tym etapie chcemy zweryfikować założenia (budżet, czas realizacji - musimy pamiętać, że nie zawsze dostawca będzie w stanie te informacje dostarczyć na tym etapie): 1. Szacunkowy czas realizacji. 2. Jakie nasze zasoby są wymagane, stawki za godzinę pracy wybranych specjalistów - cennik standardowy (stawki roboczo-godzin różnych typów konsultantów) w przypadku konieczności modyfikacji systemu po jego wdrożeniu. str. 6

7 III. USTALENIE STRATEGII WSPARCIA SYSTEMOWEGO W PIERWSZEJ KOLEJNOŚCI OCENIAMY ROZWIĄZANIA (SYSTEMY), A DOPIERO W DRUGIEJ KOLEJNOŚCI DOSTAWCÓW JE PROPONUJĄCYCH. W celu uzyskania najbardziej optymalnych warunków handlowych zalecane jest, aby w procesie wyboru były brane co najmniej dwa różne rozwiązania (systemy) o zbliżonych poziomach warunków handlowych. Liczba oferentów zależy od rynku danego rodzaju aplikacji (w niektórych przypadkach dany system oferuje tylko producent, a w innych produkt wdrażany jest przez partnerów). Generalną zasadą powinno być utrzymanie konkurencji zarówno między rozwiązaniami, jak i dostawcami je oferującymi. A. Wybór firm do dalszych rozmów - kryteria: a) roczne obroty firmy wobec wartości naszego projektu, b) struktura projektów i ich średnia wartość czy firma nie jest zależna od wyniku jednego dużego projektu, c) wyniki weryfikacji referencji bezpośrednie rozmowy, d) eliminacja skrajności (np. w kosztach pracy specjalistów), e) ilość i poziom doświadczenia pracowników (chodzi o informacje pozwalające ocenić czy w przypadku utraty części ludzi w trakcie wdrożenia, dostawca będzie w stanie zapewnić w krótkim czasie zastępstwo o porównywalnych kwalifikacjach), f) jeśli współpracowaliśmy z danym dostawcą w przeszłości, to jak wyglądała współpraca (pamiętajmy, że wybór partnera wdrożeniowego w wielu przypadkach wiążę się z kilkuletnią współpracą). str. 7

8 B. Prezentacja i weryfikacja systemów w dostępnej wersji: a) maks. dwie, trzy firmy, b) w oparciu o NASZE scenariusze kilku najważniejszych operacji w procesie, c) zapoznanie się z dostępnymi rozwiązaniami stosowanymi przez inne firmy, d) musimy wyjaśnić elastyczność systemu wobec ewentualnych zmian prawnych (jeżeli jest to istotne w danym przypadku). C. Weryfikacja naszego procesu biznesowego i oczekiwanych rezultatów: a) ostateczna decyzja, które elementy procesu są must to have, a które tylko nice to have, b) czy oczekiwane rezultaty/funkcjonalności są realne do osiągnięcia czy też powinniśmy je zweryfikować, c) jakie dodatkowe elementy powinniśmy wprowadzić do procesu/funkcjonalności, o których nie myśleliśmy na początku, d) orientacyjna ilość licencji potrzebnych do użytkowania systemu - poprzez określenie jakie działy będą korzystać z aplikacji i czy wszyscy będą ją wykorzystywać w tym samym zakresie (różne typy licencji - zależy to od kompleksowości całego procesu biznesowego, który ma zostać wsparty narzędziem w postaci systemu oraz od modelu licencjonowania producenta aplikacji) - ta informacja pozwoli na oszacowanie kosztów licencji już na wstępnym etapie, bazując na modelach licencjonowania przedstawionych we wstępnych ofertach (będących wynikiem RFI). D. Opracowanie ostatecznego procesu biznesowego, naszych celów i oczekiwanych rezultatów wraz ze szczegółowymi rozwiązaniami, jeżeli są dla nas krytyczne. str. 8

9 E. WYBÓR FINALNEJ STRATEGII kierunek dalszego działania: a) dostępne narzędzia z półki gwarantują realizację naszych krytycznych potrzeb biznesowych i wymagają niewielkich modyfikacji, b) niezbędna jest istotna kastomizacja oferowanych narzędzi z półki, c) brak narzędzi na rynku - niezbędne stworzenie nowej aplikacji dla nas: robimy to in house, kupujemy z rynku. F. Aktualizacja business case dla wybranej powyżej strategii: a) budżet, b) dostępność naszych zasobów, c) akceptacja Zarządu do kontynuowania projektu na bazie uaktualnionych założeń i przyjętej strategii. DLA DALSZEJ ANALIZY PRZYJMUJEMY KONIECZNOŚĆ BUDOWY NOWEGO NARZĘDZIA I JEGO POZYSKANIE Z RYNKU. str. 9

10 IV. ELEMENTY KOSZTOWE TCO CAŁKOWITY KOSZT UŻYTKOWANIA Aby właściwie przygotować zapytanie ofertowe, a następnie przeprowadzić udane negocjacje i wybrać optymalne rozwiązanie, musimy zestawić WSZYSTKIE koszty, które będziemy lub MOŻEMY ponosić w związku z zakupem, wdrożeniem oraz użytkowaniem danej aplikacji. Dotyczy to zarówno kosztów zewnętrznych jak i kosztów naszej organizacji. A. Koszty zewnętrzne (dostawcy): a) koszt licencji własnych według modelu licencjonowania dostawcy - musimy podać planowaną liczbę użytkowników lub licencji, b) koszt ewentualnej aktualizacji oraz nowych licencji w przyszłości (nowi użytkownicy), c) koszt analizy przed-wdrożeniowej (projekt wdrożeniowy), d) projekt techniczny (opis każdej operacji), e) wdrożenie (powinien zawierać koszt parametryzacji oraz niezbędnych interfejsów), f) kastomizacja, g) szkolenie, h) instalacja aplikacji, i) dokumentacja techniczna (stanowiskowa, administratora, bazy danych), j) koszty delegacji, k) koszt wsparcia technicznego, l) koszt utrzymania oraz nowych wersji aplikacji (upgrade s), m) rozwój aplikacji stawki godzinowe dla wybranych specjalistów, n) opłata za dostęp do kodów źródłowych kastomizacji i zgoda na ich ewentualne modyfikacje przez nas lub trzecią stronę. str. 10

11 B. Koszty własne: a) koszt licencji obcych (system operacyjny, bazy danych, itp.) plus koszt ich aktualizacji, b) koszt sprzętu IT, c) koszt ewentualnych urządzeń technicznych (np. podnośniki do wykonania okablowania, itp.), d) koszt infrastruktury, e) zaangażowanie naszych pracowników (w tym delegacje), f) koszt pracowników czasowych. V. KRYTERIA WYBORU OPTYMALNEGO ROZWIĄZANIA I OKREŚLENIE ICH WAŻNOŚCI (WAGI) PRZED rozpoczęciem etapu zbierania i analizy ofert oraz negocjacji, Zespół Projektowy MUSI określić jasne kryteria według których będzie oceniać otrzymywane oferty i dokona ostatecznego wyboru. A następnie przypisać im określone wagi (ważność dla nas w tym konkretnym przypadku). Najczęściej stosowane są następujące kryteria: 1. Kosztowe (60 do 70%), 2. Organizacyjne (termin wdrożenia 10-20%), 3. Techniczne (20-30%): a) funkcjonalność, b) infrastruktura, c) utrzymanie, d) architektura, e) bezpieczeństwo. str. 11

12 Poprawna realizacja tego etapu znacznie przyspieszy proces oceny ofert i wzmocni naszą pozycję negocjacyjną. Ułatwi wybór dostawcy i zagwarantuje, że będzie on transparentny i zminimalizuje wewnętrzne konflikty interesów. Umożliwi również racjonalne wyjaśnienie naszej decyzji np. wobec innych dostawców czy interesariuszy. VI. ZAPYTANIE OFERTOWE - RFP Teraz jesteśmy już przygotowani do stworzenia i wysłania zapytania ofertowego RFP. W zapytaniu powinniśmy uwzględnić następujące elementy: 1. Wszystkie te informacje i pytania, które zawarliśmy w RFI - ze względów formalnych: zapytanie i oferta są dokumentami wiążącymi strony a RFI nie - PRZEDE WSZYSTKIM OPIS PROCESU, JEGO CELE I OCZEKIWANE REZULTATY ORAZ KONKRETNE FUNKCJONALNOŚCI. 2. Wszystkie elementy kosztów zewnętrznych z etapu TCO. 3. Rekomendujemy zapytać również dostawcę o koszty licencji obcych - pod warunkiem, że jesteśmy gotowi przekazać mu wszystkie potrzebne informacje. 4. Harmonogram wdrożenia szczegółowy wykaz zadań wraz z określeniem wymaganego zaangażowania każdej strony oraz osoby odpowiedzialnej dla każdego zadania. 5. Okres i zakres/warunki gwarancji. 6. SLA: a) rodzaje błędów i ich definicje (szczególnie błędów krytycznych), b) maksymalne gwarantowane czasy reakcji i usunięcia każdego typu błędu, c) godziny pracy, lokalizacja i język help desk/serwisu dostawcy, d) procedura zgłaszania błędów, kary za przekroczenie czasu reakcji/usunięcia błędu. str. 12

13 7. Sposób obliczania bazy dla opłaty za wsparcie techniczne i utrzymanie w przypadku kolejnych rozszerzeń i modyfikacji. 8. Rodzaje standardowych raportów dostępnych w ramach kosztów licencji i dostępne formaty w jakich raporty mogą być generowane. 9. Opcjonalnie można zapytać o warunki dostosowywania systemu do zmiany przepisów prawnych (czy odbywa się to w ramach update ów aplikacji?). W przypadku SLA rekomendujemy aby dostawca podał koszty wsparcia technicznego w dwóch wariantach: - przy własnych czasach reakcji/usunięcia błędów, - dla czasów określonych przez nas z punktu widzenia krytyczności aplikacji dla naszego biznesu. VII. ANALIZA OFERT I NEGOCJACJE Dla łatwego porównywania ofert rekomendujemy przygotowanie najbliższego naszym planom scenariusza biznesowego na podstawie którego będziemy wartościować oferty, np.: horyzont czasowy 3 lata, liczba użytkowników 150, co roku wzrasta ona o 10 osób, co roku dostawca wprowadzał będzie na prośbę modyfikacje i rozszerzenia z pracochłonnością 200 h, itp. Podczas negocjacji poza wszystkimi wymienionymi powyżej elementami, MUSIMY ustalić z dostawcą: - szczegółowe zapisy dotyczące praw autorskich, - zasady dostępu do kodów źródłowych do wszystkich modyfikacji aplikacji standardowej zrobionych specjalnie dla nas (chodzi o zapewnienie sobie możliwości modyfikacji i rozwoju aplikacji np. jeżeli firma przestaje istnieć lub już danej aplikacji nie wspiera lub nie rozwija), str. 13

14 - zgodę na modyfikacje przez nas in house lub przez stronę trzecią (o ile będzie to racjonalne i uzasadnione technicznie i finansowo), - harmonogram płatności: rekomendujemy, aby poza konieczną przedpłatą (np. na zakup sprzętu czy prace wstępne) płacić za zrealizowane etapy (np. analiza przedwdrożeniowa, projekt techniczny, szkolenie, wdrożenie, itp.) oraz np. finalne 10% za ostateczne uruchomienie. VIII. ANALIZA OFERT i NEGOCJACJE IX. REALIZACJA UMOWY Dziękujemy wszystkim osobom, które wniosły swój wkład w stworzenie Rekomendowanego Procesu Zakupu Aplikacji IT. Dziękujemy, że poświęciliście Państwo bezinteresownie swój czas i wiedzę na rzecz wspólnego działania. Polskie Stowarzyszenie Menedżerów Logistyki Wydawnictwo Eurologistics str. 14