…, że referencje mogą mijać się z prawdą.

Powszechną praktyką stosowaną przez dostawców IT na etapie sporządzania oferty jest manipulowanie referencjami.Na listach referencyjnych przedstawianych przez dostawców bardzo często znajdują się opisy wdrożeń, które np.:

  • nie miały miejsca
  • zostały zrealizowane przez innego partnera w sieci dealerskiej,
  • dotyczą innego zakresu współpracy pomiędzy przedsiębiorstwem a dostawcą np. wdrożenie innego systemu IT, dostawy sprzętu, usług doradczych,
  • zostały zrealizowane częściowo, w wąskim zakresie (niejednokrotnie niepełnego modułu),
  • dotyczą nieaktualnych (starych) wersji systemu, które nie są już rozwijane – rozwiązań, które oparte są o przestarzałą technologię bazodanową, środowisko DOS, etc.,
  • nie zostały zrealizowane przez dostawcę, lecz są referencją nowozatrudnionego pracownika,
  • zostały zrealizowane przez byłych pracowników dostawcy, a obecna kadra może nie posiadać kompetencji w tym obszarze,
  • dotyczą realizowanych aktualnie wdrożeń.

Zaskakujący jest fakt, że manipulacji dopuszczają się również liczący się dostawcy na rynku. Regułą natomiast jest to, że im marka dostawcy jest poważniejsza, tym częściej przedsiębiorcy odchodzą od weryfikacji referencji. To poważny błąd.

…, że zlecił realizację projektu podwykonawcy.

Dostawcy IT często korzystają z pomocy podwykonawców przy realizacji projektów. Zdarza się, że przekazują im 100% prac objętych umową, zatrzymując dla siebie jedynie marżę. Procedura ta może okazać się szczególnie bolesna dla przedsiębiorstw, które liczyły na doświadczenie i kompetencje dostawcy niezbędne przy realizacji projektu.

Z punktu widzenia dostawcy posiłkowanie się podwykonawcami jest logiczne i biznesowo uzasadnione:

  • Specjalizacja w IT jest konieczna, nie sposób posiadać najwyżej wykwalifikowanych inżynierów we wszystkich obszarach informatycznych. Dostawca musi skoncentrować się na kilku zakresach merytorycznych i w nich wzmacniać kompetencje, budować przewagę konkurencyjną,
  • Powierzenie części realizacji projektu grupie specjalistów, którzy znacznie przewyższają umiejętnościami, wiedzą i doświadczeniem własną kadrę może wpłynąć korzystnie na prace wdrożeniowe,
  • Dostawca zmniejsza liczbę etatów, redukuje koszty prowadzenia działalności, dzięki czemu jest wstanie zaoferować korzystne warunki realizacji kontraktu.

Tyle teorii. W praktyce okazuje się, że niektórzy podwykonawcy wcale nie dysponują wysokimi i unikatowymi kompetencjami. Mają inną zaletę – są tani. Przekazanie części realizacji zadań w „cudze ręce” przekłada się na delegowanie odpowiedzialności i brak kontroli nad całością projektu.

W konsekwencji:

  • prace wdrożeniowe przedłużają się w czasie np. z takiego powodu, że podwykonawca świadczy usługi dla kilku dostawców jednocześnie i sam wyznacza priorytety prac lub wymienia kadrę do realizacji projektu,
  • znacznie spada jakość realizowanych prac wdrożeniowych, co w praktyce oznacza niedostosowanie rozwiązania do potrzeb przedsiębiorstwa

BPC Group zanotowało, że w wielu przypadkach przedsiębiorcy / komitety sterujące nie analizują kompetencji dostawców w wystarczającym stopniu.

Nie weryfikują zespołów wdrożeniowych ani pod względem ich liczebności, ani w kontekście ich kompetencji. Zawierzają natomiast marce dostawcy/ producenta, słowom dobrze wyszkolonego handlowca, spisanym w ofercie wstępnej deklaracjom.

Gro przedsiębiorstw już doświadczonych podejmując decyzję o wyborze dostawcy, wymaga od oferenta przedstawienia listy kadry wdrożeniowej, a nawet umożliwienia rozmowy z przedstawionymi inżynierami. Lista takowa wówczas stanowi załącznik do umowy wdrożenia ERP – i to jest właściwe postępowanie.

…, gdzie ciąć cenę

Określenie właściwej ilości wymagań funkcjonalnych to pierwsza trudność, z którą spotyka się przedsiębiorstwo przy tworzeniu zapytania ofertowego.

Kluczowym problemem jest ich właściwe doprecyzowanie, nazwanie oraz nadanie im określonego statusu ważności.

W opinii Business Penetration & Consulting, każda pozycja na liście wymagań funkcjonalnych powinna być rozpatrywana w perspektywie trzech poziomów krytyczności (ich nazewnictwo jest sprawą drugorzędną):

  • Kluczowe/Wymagane – Najwyższy poziom krytyczności, który odnosi się do funkcji w rozwiązaniu IT, które dotyczą podstawowej działalności organizacji. Są one bezpośrednio związane z celami wdrożenia (np. Usprawnienie planowania produkcji: „Możliwość ustawiania priorytetu danego zlecenia produkcyjnego”; Optymalizacja pracy na magazynie: „Obsługa rozchodów magazynowych metodą FIFO, FIFO wg partii, itp.”; Przyśpieszenie procesu sprzedaży: „Możliwość sprzedaży i tworzenia zleceń sprzedaży w powiązaniu z ofertą z CRM”). Decydenci powinni rozpatrywać wyłącznie te systemy, które oferują w standardzie funkcjonalnym wymagania opatrzone statusem „kluczowe/wymagane”. W przypadku zmniejszenia zakresu projektu nie powinno się sięgać do tych funkcjonalności.
  • Wysoki/Wysoki Priorytet – Wymagania funkcjonalne, które związane są z realizacją głównych celów wdrożenia (bądź kluczowych aspektów celów drugorzędnych) z tą różnicą, iż nie są one dla przedsiębiorstwa krytyczne. Oznacza to, że decydenci akceptują możliwość ich modyfikacji bądź osiągnięcia danej funkcjonalności w inny sposób. Wskazane wymagania są najczęstszym wyznacznikiem ostatecznej oceny systemów (oczywiście tych rozwiązań, które kluczowe funkcjonalności ma w standardzie i są poddawane dalszej analizie).
    W przypadku zmniejszenia zakresu projektu powinno się sięgać do tych funkcjonalności tylko w ostateczności.
  • Średni/Życzeniowy – Życzeniowa lista potrzeb, która często dotyczy celów drugorzędnych i obszarów nie będących podstawą działalności przedsiębiorstwa. W tej grupie znajdują się wszelkie funkcjonalności, które potencjalnie usprawniłby naszą pracę, lecz nie mają na nią bezpośredniego wpływu. Często są to potrzeby wynikające z przyszłościowych planów przedsiębiorstwa (np. platforma B2B, sklep internetowy, oddział zagraniczny) lub dotyczą sytuacji wyjątkowych/sporadycznych (np. realizacja nietypowego zamówienia, wyjątek w procesie magazynowym, księgowym).

W przypadkach konieczności zmniejszenia zakresu projektu (ze względu na czas realizacji, budżet projektu), firma powinna sięgać w pierwszej kolejności do tych funkcjonalności.

Aby prawidłowo sporządzić listę wymagań funkcjonalnych wobec systemu informatycznego przedsiębiorstwo powinno wykonać analizę potrzeb biznesowych. Powinna ona obejmować opis bieżących procesów w przedsiębiorstwie (ze wskazaniem wąskich gardeł w działalności), jak i wymagań wobec systemu w perspektywie najbliższych lat.

Na zbyt obszernej liście wymagań, obok potrzeb strategicznych mogą znaleźć się opcjonalne. W konsekwencji przedsiębiorstwo może otrzymać oferty wyłącznie od dostawców, którzy oferują rozbudowane systemy o wartości kilku milionów złotych.

W praktyce okazuje się jednak, że firma nie potrzebuje aż tak dużych i drogich narzędzi informatycznych, gdyż większość zawartych w zapytaniu funkcji ma priorytet życzeniowy lub opcjonalny.

Zbyt wąski zakres wymagań funkcjonalnych przedstawionych w zapytaniu może spowodować, że zostanie wybrany system niedostosowany do potrzeb przedsiębiorstwa.

Zdarza się, iż decydenci zapominają o umieszczeniu w dokumencie funkcji dla nich oczywistych, a strategicznych z punktu widzenia przedsiębiorstwa.

Na listach nie umieszczane są obszary, które mogą być zinformatyzowane wyłącznie przez wyspecjalizowane systemy.

W konsekwencji przedsiębiorcy otrzymują bardzo wiele ofert, które obejmują standardowy pakiet funkcjonalności, a nie są w stanie zaspokoić specyficznych potrzeb organizacji.

Wskaż cele

Przy wyborze rozwiązania należy zastanowić się, czego decydenci oczekują od systemu WMS. Każda firma posiada inną strukturę, a zarazem priorytety. Dla jednych priorytetem będzie wyższy poziom obsługi klienta, bezbłędność dostaw, a dla innych wzrost wydajności pracowników czy wymierne oszczędności związane z redukcją zapasów, optymalizacją prac czy lepszym wykorzystaniem przestrzeni magazynowej.

Nieprawidłowe określenie swoich potrzeb może prowadzić do zaimplementowania rozwiązania, które w firmie okaże się kompletnie nieprzydatne. Wiąże się to z poniesieniem niepotrzebnych kosztów, związanych z późniejszą modyfikacją systemu.

Jeśli firma rzetelnie określi błędy, które chce wyeliminować, zdefiniuje procesy wymagające usprawnienia oraz ustali wskaźniki, które chce osiągnąć przez wdrożenie systemu, po pewnym czasie będzie mogła porównać efekty końcowe z zakładanymi, co prze- łoży się w przyszłości na lepsze zagospodarowanie systemu w przedsiębiorstwie.