Dostawca oprogramowania na zamówienie - od czego zależy wybór
Dostawca oprogramowania na zamówienie odpowiada za cały łańcuch od analizy po utrzymanie, więc jego wybór jest decyzją na lata, a nie na jeden projekt. System pisany pod konkretny proces staje się częścią pracy firmy. Zmiana wykonawcy po dwóch latach kosztuje tyle, ile przejęcie cudzego kodu, a to zależy od decyzji podjętych przy pierwszej umowie.
Ten tekst zajmuje się jednym pytaniem: jak ocenić kandydatów według kryteriów, które da się sprawdzić, a nie według wrażenia z prezentacji. Zakres pojęcia opisuje strona o software house, a ogólny przegląd rynku - artykuł o dostawcy oprogramowania dla firm. Tutaj chodzi o samą procedurę wyboru.
Rodzaje dostawców i związane z nimi ryzyko
Na rynku działają wykonawcy o różnym profilu. Każdy profil ma inną mocną stronę i inne typowe ryzyko.
| Typ dostawcy | Mocna strona | Typowe ryzyko |
|---|---|---|
| Programista indywidualny | Niski koszt, szybki start | Zależność od jednej osoby, brak zastępstwa |
| Mała pracownia programistyczna | Bezpośredni kontakt z zespołem | Ograniczona zdolność do równoległych prac |
| Software house | Zespół z podziałem ról i proces testowy | Wyższy koszt wejścia, formalna umowa |
| Integrator z własnym produktem | Gotowe moduły i wiedza branżowa | Skłonność do dopasowania projektu do produktu |
Żaden z typów nie jest zły z definicji. Pytanie brzmi, czy profil dostawcy pasuje do skali i ryzyka projektu. System obsługujący magazyn przez całą dobę wymaga innej organizacji utrzymania niż wewnętrzny moduł raportowy używany przez trzy osoby.
Zapytanie ofertowe i porównywalność ofert
Oferty da się porównać tylko wtedy, gdy każdy kandydat odpowiada na to samo zapytanie. Zamawiający, który rozmawia z trzema wykonawcami na podstawie trzech różnych opisów potrzeb, dostaje trzy wyceny na trzy różne projekty. Zapytanie ofertowe powinno zawierać opis procesów i listę integracji. Dopisuje się do niego wymagania niefunkcjonalne oraz oczekiwany sposób rozliczenia.
Dobrą praktyką jest także krótka faza rozpoznawcza przed wyceną. Może być płatna albo bezpłatna, zależnie od skali projektu. Analiza przedwdrożeniowa, opisana w artykule o analizie przedwdrożeniowej, pokazuje, czy wykonawca zadaje pytania o proces, czy tylko o termin i budżet. Kandydat, który wycenia projekt po jednej rozmowie, zwykle wycenia własne założenia, a nie potrzeby zamawiającego.
Pytania do każdego oferenta
Poniższe cztery pytania należy zadać wszystkim kandydatom i zapisać odpowiedzi w tej samej formie.
- Kto wykona pracę - imiona i role osób przypisanych do projektu oraz zastępstwo na wypadek nieobecności.
- Jak wygląda odbiór - kto pisze scenariusze testowe, kiedy zamawiający widzi działającą wersję i według jakich kryteriów przyjmuje etap.
- Co zawiera cena - czy cena obejmuje dokumentację i szkolenia. Trzeba też wiedzieć, czy zawiera migrację danych oraz kod źródłowy, czy są one wyceniane osobno.
- Co dzieje się po odbiorze - zakres gwarancji, warunki umowy serwisowej i sposób zgłaszania błędów.
Model rozliczenia i jego konsekwencje
Ten sam zakres prac można rozliczyć na kilka sposobów, a wybór modelu zmienia rozkład ryzyka między zamawiającego i wykonawcę. Przy stałej cenie ryzyko przekroczenia kosztów spada na wykonawcę, ale każda zmiana wymaga aneksu. Przy rozliczeniu według czasu pracy zamawiający zachowuje elastyczność, lecz sam pilnuje budżetu.
| Model | Kiedy pasuje | Główne ryzyko zamawiającego |
|---|---|---|
| Cena stała za zakres | Zakres znany i opisany w specyfikacji | Sztywny zakres, każda zmiana wymaga aneksu |
| Czas i materiał | Zakres niepewny, prace iteracyjne | Brak górnej granicy kosztu bez limitu budżetowego |
| Ryczałt miesięczny za zespół | Rozwój ciągły, wiele drobnych zmian | Płatność także w miesiącach o małej liczbie zadań |
| Model mieszany | Faza projektowa stała, rozwój według czasu | Potrzeba jasnej granicy między fazami |
Niezależnie od modelu warto żądać raportu z postępu prac w formie zgodnej z ofertą. Zamawiający, który płaci za czas, widzi wtedy, na co go poświęcono, a ten, który płaci za etap, widzi, ile zostało do odbioru.
Limit budżetowy i zmiany
Przy rozliczeniu według czasu warto ustalić limit, po przekroczeniu którego wykonawca wstrzymuje prace do decyzji zamawiającego. Limit chroni obie strony: zamawiający nie dowiaduje się o przekroczeniu po fakcie, a wykonawca nie pracuje bez potwierdzenia budżetu.
Referencje i próba pracy dostawcy
Referencje mają wartość, gdy dotyczą podobnego procesu i zbliżonej skali. List polecający od klienta z innej branży mówi o kulturze współpracy, ale nie o zdolności do zbudowania systemu magazynowego czy rozliczeniowego. Zamawiający może poprosić o kontakt do osoby, która korzystała z dostarczonego systemu, i zadać jej kilka konkretnych pytań.
Pytania do klienta referencyjnego powinny dotyczyć faktów: czy projekt zakończył się w uzgodnionym zakresie, jak wykonawca reagował na błędy po wdrożeniu i czy zmiana zakresu przebiegała według ustalonych zasad. Odpowiedź „jesteśmy zadowoleni” jest mniej użyteczna niż informacja, że po pierwszej awarii wykonawca przekazał opis przyczyny i zmianę w kodzie tego samego dnia.
Przegląd kodu i demonstracja
Wykonawca powinien pokazać nie tylko gotowy ekran, lecz także sposób pracy: repozytorium z historią zmian oraz procedurę przeglądu kodu przed scaleniem. Ważne są też testy automatyczne i skrypty wdrożeniowe. Zamawiający bez wiedzy technicznej może poprosić niezależnego specjalistę o ocenę fragmentu kodu. Kilka godzin przeglądu ujawnia więcej niż tygodnie rozmów handlowych.
Reguła: referencja liczy się dopiero po rozmowie z osobą, która używa dostarczonego systemu, a nie wyłącznie z osobą, która podpisała umowę.
Tabela oceny ofert z wagami
Tabela oceny zamienia wrażenia na liczby i chroni przed decyzją opartą wyłącznie na cenie. Kryteria i wagi ustala zamawiający przed otwarciem ofert, tak aby wynik nie był dopasowywany do faworyta. Poniższe wagi są przykładowe i wymagają dostosowania do ryzyka konkretnego projektu.
| Kryterium | Waga | Co oceniamy |
|---|---|---|
| Zrozumienie procesu | 25% | Jakość pytań w fazie rozpoznawczej, trafność uwag do zapytania |
| Referencje i próbka pracy | 20% | Podobieństwo projektów, wynik rozmowy z klientem, przegląd kodu |
| Kod i prawa | 20% | Przekazanie kodu, przeniesienie praw, lista komponentów |
| Gwarancja i serwis | 20% | Zakres gwarancji, poziomy usług, sposób zgłaszania błędów |
| Cena i harmonogram | 15% | Jasność wyceny, ryzyka założone w harmonogramie |
Ocenę każdego kryterium wystawia zespół co najmniej dwuosobowy, a średnia z ocen jest mnożona przez wagę. Zamawiający, który chce policzyć wynik automatycznie, może zapisać oceny w arkuszu albo w bazie. Poniższe zapytanie T-SQL jest przykładowe i pokazuje sumę ważoną dla każdego oferenta.
SELECT o.Nazwa,
SUM(k.Waga * s.Ocena) / SUM(k.Waga) AS WynikWazony
FROM dbo.Oferent AS o
JOIN dbo.OcenaKryterium AS s ON s.OferentId = o.OferentId
JOIN dbo.Kryterium AS k ON k.KryteriumId = s.KryteriumId
GROUP BY o.Nazwa
ORDER BY WynikWazony DESC;Kryteria odrzucające i punktowane
Nie wszystkie wymagania nadają się do punktowania. Część z nich to warunki konieczne: bez zgody na przekazanie kodu źródłowego albo, gdy wykonawca ma dostęp do danych osobowych, bez umowy powierzenia ich przetwarzania oferta odpada niezależnie od liczby punktów. Punktuje się dopiero to, co podlega stopniowaniu, na przykład jakość referencji albo szczegółowość harmonogramu.
Rozdzielenie obu grup zapobiega sytuacji, w której wysoka ocena za cenę i harmonogram kompensuje brak zgody na podstawowe zapisy umowy.
Wynik liczbowy nie zastępuje rozmowy. Pomaga natomiast wykryć sytuację, w której dostawca z najlepszą ceną ma najsłabsze oceny w kryteriach dotyczących kodu i serwisu, czyli tam, gdzie błędy wychodzą po wdrożeniu.
Gwarancja i odpowiedzialność za wady
Gwarancja na oprogramowanie na zamówienie dotyczy zgodności systemu ze specyfikacją. Obejmuje naprawę błędów wykonawcy, ale nie obejmuje nowych funkcji ani zmian wynikających z decyzji biznesowych zamawiającego. Umowa powinna rozdzielać te dwie kategorie, bo w praktyce większość sporów zaczyna się od pytania, czy zgłoszenie jest błędem, czy życzeniem.
Ważny jest także rozdział między czasem reakcji a czasem naprawy. Reakcja oznacza potwierdzenie zgłoszenia i podjęcie diagnozy, naprawa oznacza dostarczenie poprawki. Wykonawca może dotrzymać pierwszego terminu, nie mając żadnego zobowiązania co do drugiego, jeśli umowa tego nie rozdziela.
| Priorytet | Przykład zgłoszenia | Co ustala umowa |
|---|---|---|
| Krytyczny | System nie uruchamia się, magazyn stoi | Czas reakcji, dostępność w godzinach pracy i poza nimi |
| Wysoki | Błędny wynik w raporcie rozliczeniowym | Czas reakcji i termin poprawki lub obejścia |
| Średni | Funkcja działa, ale nie zgodnie ze specyfikacją | Poprawka w najbliższym wydaniu |
| Niski | Literówka w komunikacie | Poprawka razem z kolejną zmianą |
Umowa serwisowa i utrzymanie po wdrożeniu
Gwarancja wygasa, a system nadal działa i wymaga opieki. Umowa serwisowa opisuje, kto przyjmuje zgłoszenia i w jakich godzinach. Wskazuje też kanał zgłoszeń oraz priorytety. Określa także zakres aktualizacji platformy, na przykład SQL Server i systemu operacyjnego, oraz zasady wykonywania i sprawdzania kopii zapasowych. Podział obowiązków między dostawcę a zamawiającego jest szerzej omówiony w tekście o oprogramowaniu na zamówienie a obsłudze IT.
Utrzymanie systemu można oprzeć na umowie ryczałtowej, pomocy zdalnej albo doraźnych zleceniach, czyli tych samych formach, w jakich rozliczają się firmy świadczące obsługę informatyczną. Porównanie takich modeli znajduje się na stronie o obsłudze informatycznej firm. Dla zamawiającego ważne jest, aby umowa serwisowa nie uzależniała dostępu do kodu od jej przedłużania.
Wsparcie wdrożenia przez dostawcę
Okres tuż po uruchomieniu generuje najwięcej zgłoszeń, bo użytkownicy zderzają się z systemem w warunkach rzeczywistych. Rolę dostawcy w tej fazie opisuje artykuł wsparcie wdrożenia systemu - rola dostawcy. Kandydat powinien wskazać, kto z jego zespołu będzie dostępny w pierwszych tygodniach i w jakim trybie.
Bezpieczeństwo, prawa do kodu i czerwone flagi
Kryteria techniczne uzupełnia ocena bezpieczeństwa. Zamawiający może wymagać, aby aplikacja webowa była budowana z uwzględnieniem wymagań weryfikacji bezpieczeństwa aplikacji publikowanych przez organizację OWASP, w tym standardu Application Security Verification Standard. Wykonawca powinien odpowiedzieć, które wymagania standardu uwzględnia i jak je testuje.
Drugim obszarem są prawa do kodu i jego przekazanie. Szczegóły opisuje artykuł o dedykowanym oprogramowaniu na zamówienie, w którym omówiono specyfikację i prawa do kodu. W tabeli oceny odpowiada im osobne kryterium, bo błąd w zapisach kosztuje najwięcej wtedy, gdy zamawiający chce zmienić wykonawcę.
Plan wyjścia z umowy
Umowa z dostawcą powinna przewidywać zakończenie współpracy, zanim do niego dojdzie. Plan wyjścia wskazuje, w jakim terminie wykonawca przekazuje kod oraz dokumentację i dane, a także jak wygląda okres przejściowy, w którym nowy zespół poznaje system. Taki zapis niewiele kosztuje przy podpisaniu umowy, a przy sporze bywa jedynym, który zapobiega paraliżowi pracy.
Czerwone flagi w ofercie
Cztery sygnały warto potraktować jako powód do dodatkowych pytań przed podpisaniem umowy.
- Brak opisu zakresu - oferta składa się z kwoty i terminu, bez listy funkcji i kryteriów odbioru.
- Niechęć do pokazania kodu - wykonawca odmawia przeglądu próbki albo dostępu do repozytorium w trakcie projektu.
- Brak imion w zespole - oferta nie wskazuje osób, a tylko „zespół programistów”.
- Serwis bez zakresu - umowa serwisowa nie rozdziela błędów od zmian i nie określa priorytetów.
Ponieważ różne firmy mają inne zasady współpracy, przydaje się porównanie z wymaganiami opisanymi w artykule o dostawcy oprogramowania z doświadczeniem oraz o wyborze dostawcy i integracjach. Pytanie o styl pracy zespołu i o podział ról warto uzupełnić wnioskiem z projektu pilotażowego. Jeśli decyzja dotyczy wyboru między własnym systemem a gotowym rozwiązaniem, pomaga tekst o oprogramowaniu dedykowanym i rozwiązaniach masowych.
SoftwareStudio opisuje w ofercie zespół, w którym pracują analitycy, programiści, specjaliści od baz danych oraz wdrożeniowcy, i wycenia projekty indywidualnie. Zakres współpracy przy oprogramowaniu na zamówienie znajduje się na stronie oferty oprogramowania na zamówienie, a kontakt w sprawie wyceny jest dostępny pod numerem +48 533 322 626.
