Kupujemy system IT.

Wróćmy zatem do naszej sytuacji. Zakupy dostały nowe zadanie. Znalezienie nowego sytemu IT do zarządzania sprzedażą. Spróbujmy zatem przybliżyć w postępowanie w modelu waterfall. W modelu, który przez wielu praktyków zakupów jest dzisiaj mocno krytykowany. W opinii praktyków, podejście polegające na zdefiniowaniu wszystkich wymagań co do funkcjonalności na początku procesu zakupowego jest ryzykowne dla organizacji. Zanim zapytanie trafi do potencjalnych oferentów, Użytkownik musi a priori, zdefiniować i opisać wszystkie detaliczne wymagania co do oprogramowania. Sugeruje się wręcz aby zestaw wymagań biznesowych uzupełniony został wykazem tzw. przypadków użycia (ang. use case), czyli precyzyjnie opisanym zestawem instrukcji,jakie oprogramowanie ma wykonywać.

Załóżmy zatem, że użytkownik biznesowy (lub grupa użytkowników) doskonale zna proces sprzedaży, wie dokładnie jakie funkcjonalności powinno zawierać oprogramowanie. Co więcej, zakłada się, że biznes jest w stanie przewidzieć także jak będzie się zmieniał rynek w perespektywie 6, 12 lub 24 miesięcy. Są sektory gospodarki, które charakteryzują się niską dynamiką zmian, więc jest duże prawdopodobieństwo, że dzisiaj zaplanowane funkcjonalności będą również efektywne w perespektywie 2-3 lat. Biorąc pod uwagę fakt, że czas wdrożenie nowego systemu IT do zarzadzania sprzedażą to około 6-12 miesięcy to założenie o niezmienności założeń funkcjonalnych jest jak najbardziej istotne. Co w sytuacji, gdy rynek zmienia się w sposób ciągły a oczekiwania klientów są coraz bardziej kompleksowe ? Specyfikę podejścia do zarządzania zakupami w takiej sytuacji postaram się przybliżyć w 2. części artykułu.

Wymagania funkcjonalne to niejedyny składnik kształtujący wycenę oferty na system sprzedaży.
Istotnym składnikiem wyceny będą również:

1. Własność kodów źródłowych aplikacji.
2. Parametry umowy utrzymania (Software Maintenance Agreement, SWMA).
3. Kary umowne lub zachęty motywujące dostawcę do zakończenia projektu.
4. Strategia wyjścia z umowy.
5. Koszt infrastruktury związanej z wdrożeniem projektu wraz usługą utrzymania (Hardware Maintenance Agreement, HWMA).
6. Koszt ewentualnej infrastruktury chmurowej.
7. Koszty szkoleń dla personelu.
8. Koszty zabezpieczeń związanych z cybersecurity.
9. Koszt dostosowania się do wymogów regulatora.
10. Koszt dodatkowych zasobów, które musimy pozyskać do skutecznego wdrożenia systemu.
11. Procedura wprowadzania zmian do umowy.
12. Zakres ewentualnego podoutsourcingu

Dobrą praktyką jest zdefiniowanie tych elementów zapytania, które są nienegocjowalne. Wiele firm ma wewnętrzne procedury i wymogi co do cybersecurity, wdrażania zmian, podejścia do zarządzania projektami, organizacją środowisk testowych. Negocjowanie parametrów, które wiemy, że nie mogą się zmienić to strata czasu. Jeżeli firma posiada wzorce umów na kontraktowanie zakupu technologii to warto stworzyć pod potrzeby zapytania ofertowego zestaw istotnych zapisów umowy, które powinny stanowić załącznik do zapytania. Podmiot ofertujący będzie miał już na etapie zapytania ofertowego wgląd w zapisy umowy, które pojawią się w umowie wdrożeniowej. Skróci to czas potrzebny na konsultacje prawników.

Następnym, istotnym elementem zapytania są kryteria wyboru dostawcy. Liczność kryteriów może być dowolna, jednak zakupowiec, w porozumieniu z biznesem, powinien zaproponować taki ich zestaw aby odpowiadały one na potrzeby organizacji. Na pewno, jedynym kryterium nie może być cena. Doświadczenie dostawcy we wdrażaniu podobnych systemów wraz potwierdzoną listą referencyjną to na pewno jedno z must be w etapie oceny ofert. Warto również rozważyć dodanie możliwości odbycia wizyt referencyjnych u klientów, dla których dostawca zrealizował wdrożenie. W każdym przypadku sugeruję również dodanie tzw. składnika miękkiego, czyli subiektywnej oceny danego dostawcy przez użytkownika biznesowego. Częstą praktyką jest zapraszanie przedstawicieli wewnętrznych struktur IT do oceny ofert. Kryteria mogą zatem uwzględniać elementy związane z technologiami wykorzystywanymi przez dostawcę we wdrożeniu i kastomizacji systemu.

Przyjmijmy zatem, że dostaliśmy odpowiedzi na zapytania ofertowe. Zakupowcy, przedstawiciele wewnętrznego IT oraz użytkownicy biznesowi dokonali ocen przedstawionych ofert. Zakupowiec przenegocjował istotne elementy oferty. Mamy zatem ostateczną ofertę od danego dostawcy.

Zapada decyzja o wyborze oferty.

Wybór najbardziej optymalnej oferty względem przyjętych kryteriów to nie koniec procesu zakupowego. Zakupowiec musi jeszcze przenegocjować ostateczne zapisy umowy lub umów. To często jest faza, której pracochłonność przekracza fazę wyboru najkorzystniejszej oferty. Stopień skomplikowania umowy zależy oczywiście od oczekiwań stron postępowania co do szczegółowości regulowania każdego aspektu realizacji umowy oraz rozkładu odpowiedzialności za poszczególne jej elementy.

Mamy ofertę i umowę…zaczynamy wdrożenie.

Umowa z dostawcą została podpisana. Strony przygotowują się do realizacji projektu. Formowane są zespoły projektowe, przygotowywana infrastruktura. Zarząd uzupełnia brakujące kompetencje poprzez zatrudnienie odpowiednich specjalistów. Rusza projekt, trwa analiza stanu AS-IS, tworzone są szczegółowe harmonogramy. Zaczyna się konfiguracja i kodowanie niezbędnych komponentów docelowego rozwiązania systemowego.

Dokładnie 2 tygodnie po rozpoczęciu prac okazuje się, że właściciel firmy dostał korzystną ofertę zakupu komplementarnego biznesu konkurenta, który chce się wycofać z danej branży. Konkurent znany był z tego, że wdrażał wszystkie nowinki i innowacje jakie pojawiały się na rynku. Wiadomo, że konkurent dużą wagę przykładał do kanału on-line, który u nas był tylko jednym z wielu kanałów. Co zatem powinniśmy zrobić ? Wiadomo, że w przypadku pozytywnej decyzji o połączeniu biznesów, dojdzie do łączenia części operacyjnych i sprzedażowych spółek, co wymusi zmiany w systemach sprzedaży. Ale my właśnie wdrażamy nowe rozwiązanie. Umowa została podpisana, zobowiązania zaciągnięte, zakres zdefiniowany, ludzie zatrudnieni, infrastruktura uzupełniona.

Nie ma jednoznacznej odpowiedzi na pytanie co dalej. Możliwości jest co najmniej kilka. Najprawdopodobniej umowy, zakres i harmonogram wdrożenia będą musiałby być ponownie otwarte do negocjacji. Zmiany muszą uwzględniać te wynikające z połączenia dwóch, różnych od siebie biznesów. Ile to będzie dodatkowo kosztowało? Ile czasu musimy przeznaczyć na taką zmianę? Jakie dodatkowe zasoby zaangażować ?. Czy rozwiązanie, które właśnie zaczęliśmy wdrażać, będzie właściwe dla połączonych spółek? Pojawia się wiele pytań, na które musimy sobie odpowiedzieć.

Opisując taką potencjalną sytuację chciałem zwrócić uwagę na to, jakie ryzyko wiąże się z podejściem waterfall przy realizacji strategicznych zmian w organizacji. Determinizm i z góry określony zakres wdrożenia, który jest efektywny dla naszego biznesu może już być nieodpowiedni w sytuacji, którą opisałem. Zarządzający na pewno będą oczekiwać synergii z tytułu połączenia spółek. Nasza umowa, która właśnie weszła w fazę realizacji, musi zostać dopasowana do zupełnie nowej i nieoczekiwanej sytuacji. Nasze wymagania, po dwóch tygodniach od momentu rozpoczęcia projektu, właśnie się zdezaktualizowały.

Jak uniknąć takich sytuacji oraz w jaki sposób dopasować się do dynamiki zmian w otoczeniu biznesowym? Jak podejść do wdrożenia systemu, jeżeli wiemy, że zmiany w otoczeniu będą wymuszały na nas szybkie dopasowanie się do wymagań rynku? To będzie temaem drugiej części publikacji „Kupujemy system IT”, do lektury której już teraz zapraszam.