Załącznik nr 1

Transkrypt

Załącznik nr 1

PRAKTYKI GODNE POLECENIA
REKOMENDOWANY PROCES ZAKUPU APLIKACJI IT
Rekomendacja Polskiego Stowarzyszenia Menedżerów Logistyki i Zakupów
Partnerzy projektu
Kopiowanie i wykorzystywanie tego dokumentu w całości lub w części możliwe pod warunkiem podania źródła
©PSML&Wydawnictwo EUROLOGISTICS
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
Partnerzy projektu
str. 2
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.
Partnerzy projektu
str. 3
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.
Partnerzy projektu
str. 4
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.
2.
3.
Nasz proces biznesowy wraz z celami i oczekiwanymi rezultatami - na poziome ogólnym plus te ograniczenia które są niezbędne.
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.
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.
Partnerzy projektu
str. 5
Elementy, o które MUSIMY zapytać w RFI (zapytaniu ofertowym):
1.
2.
3.
4.
5.
Standing prawno - finansowy (KRS, Bilans, Rachunek Zysków i Strat).
Liczba aktualnie realizowanych projektów i szacunkowa średnia wartość
(przychód) jednego projektu.
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).
Model licencjonowania aplikacji.
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.
2.
Szacunkowy czas realizacji.
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.
Partnerzy projektu
str. 6
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ą).
Partnerzy projektu
str. 7
B. Prezentacja i weryfikacja systemów w dostępnej wersji:
a)
b)
c)
d)
maks. dwie, trzy firmy,
w oparciu o NASZE scenariusze kilku najważniejszych operacji w procesie,
zapoznanie się z dostępnymi rozwiązaniami stosowanymi przez inne firmy,
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.
Partnerzy projektu
str. 8
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.
Partnerzy projektu
str. 9
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ę.
Partnerzy projektu
str. 10
B. Koszty własne:
a)
b)
c)
d)
e)
f)
V.
koszt licencji obcych (system operacyjny, bazy danych, itp.) plus koszt
ich aktualizacji,
koszt sprzętu IT,
koszt ewentualnych urządzeń technicznych (np. podnośniki do wykonania
okablowania, itp.),
koszt infrastruktury,
zaangażowanie naszych pracowników (w tym delegacje),
koszt pracowników czasowych.
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.
2.
3.
Kosztowe (60 do 70%),
Organizacyjne (termin wdrożenia 10 - 20%),
Techniczne (20 - 30%):
a)
b)
c)
d)
e)
funkcjonalność,
infrastruktura,
utrzymanie,
architektura,
bezpieczeństwo.
Partnerzy projektu
str. 11
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.
2.
3.
4.
5.
6.
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.
Wszystkie elementy kosztów zewnętrznych z etapu TCO.
Rekomendujemy zapytać również dostawcę o koszty licencji obcych - pod
warunkiem, że jesteśmy gotowi przekazać mu wszystkie potrzebne informacje.
Harmonogram wdrożenia – szczegółowy wykaz zadań wraz z określeniem
wymaganego zaangażowania każdej strony oraz osoby odpowiedzialnej dla
każdego zadania.
Okres i zakres/warunki gwarancji.
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.
Partnerzy projektu
str. 12
7.
8.
9.
Sposób obliczania bazy dla opłaty za wsparcie techniczne i utrzymanie
w przypadku kolejnych rozszerzeń i modyfikacji.
Rodzaje standardowych raportów dostępnych w ramach kosztów licencji
i dostępne formaty w jakich raporty mogą być generowane.
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),
Partnerzy projektu
str. 13
-
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
Partnerzy projektu
str. 14

Załącznik nr 1

Transkrypt

Podobne dokumenty

Romans z klientem

Koszt uczestnictwa Dane firmy Adres firmy do wysyłki

Uczniowie we własnym zakresie powinni zapoznać się z niżej

Komunikacja marketingowa

Cyfrowy świat seniora Smartfon, tablet i nie tylko

Powstrzymać agresję u progu szkoły

Wydrukuj jako PDF

aukcja przewody głośnikowe, kable optyczne

Byliny ogrodowe - produkcja i zastosowanie

Kochając osobę z demencją. Jak znaleźć nadzieję