Producenci programów dla firm - trzy typy i ocena dojrzałości produktu

Producenci programów dla firm - trzy typy wytwórców

Producenci programów dla firm nie tworzą jednego rodzaju produktu. Jedni wydają pakiety dla setek tysięcy odbiorców, inni budują systemy dla jednej dziedziny, a jeszcze inni piszą aplikację od zera na potrzeby jednej organizacji. Różnica wpływa na cenę i tempo zmian oraz na ilość pracy po stronie kupującego, więc typ wytwórcy warto rozpoznać, zanim zacznie się porównywać oferty.

W praktyce granice się zacierają, bo producent pakietu bywa też wykonawcą wdrożeń, a software house rozwija własne produkty. Poniższy podział opisuje model pracy, a nie firmę jako taką. Jedna firma może działać w dwóch modelach, na przykład sprzedawać system branżowy i pisać do niego dodatki na zamówienie.

Reguła: im bardziej proces firmy odbiega od typowego, tym więcej pracy przenosi się z konfiguracji produktu na programowanie.

Pojęcie producenta oprogramowania i jego rolę w projekcie omawia artykuł o producencie oprogramowania, a organizację pracy firm piszących kod na zlecenie opisuje tekst o software house.

Typ producenta da się rozpoznać już w ofercie. Cennik za stanowisko i standardowa lista funkcji wskazują na pakiet. Demo z pojęciami danej dziedziny, na przykład z lokalizacjami i statusami dokumentów, wskazuje na produkt branżowy. Wycena według nakładu pracy i pytania o wymagania zamiast prezentacji funkcji zdradzają wykonawcę dedykowanego.

Pakiet, rozwiązanie branżowe czy system na zamówienie

Producent standardu

Producent pakietu standardowego sprzedaje ten sam produkt bardzo wielu klientom, więc koszt rozwoju rozkłada się na całą bazę użytkowników. Wynikiem jest niska cena za stanowisko i dojrzałość produktu wypracowana na dużej liczbie zastosowań. Płaci się za to ograniczoną elastycznością: firma dostosowuje procedury do programu, a nie odwrotnie.

Pakiet dobrze obsługuje procesy, które w większości firm wyglądają podobnie, na przykład obieg dokumentów księgowych. Gorzej radzi sobie z procesami, w których liczy się szczegół operacyjny, jak kompletacja z podziałem na strefy czy okna czasowe na rampach.

Producent branżowy

Producent branżowy zna jedną dziedzinę na tyle dobrze, że modeluje jej pojęcia w samej strukturze bazy. System magazynowy operuje lokalizacjami i partiami towaru oraz dokumentami ruchu, a system reklamacji statusami zgłoszenia i decyzjami o naprawie. Klient dostaje słownictwo i procedury, które rozumie jego zespół, bez tłumaczenia z języka księgowego na magazynowy.

Typowym przykładem jest system WMS. Kiedy chodzi o rampy i okna czasowe, ten sam poziom specjalizacji reprezentuje moduł opisany w artykule o awizacjach VSS.net. Narzędziownię obsługuje osobna linia produktów, którą przedstawia tekst o programie do narzędziowni.

Producent dedykowany

Wykonawca systemu na zamówienie zaczyna od analizy, a nie od produktu. Efektem jest aplikacja dopasowana do specyfikacji, ale też odpowiedzialność za jej utrzymanie, która w modelu pakietowym spoczywa na producencie. Zakres i różnice rozwiązań na zamówienie porządkuje artykuł o oprogramowaniu na zamówienie.

Aplikacje internetowe mają tu przewagę nad programami instalowanymi na komputerach: działają w przeglądarce, więc wdrożenie nie wymaga wymiany sprzętu, a zadania w tle, takie jak wysyłka powiadomień, wykonują się niezależnie od tego, czy ktoś jest zalogowany. Zagadnienia tej architektury zbiera tekst o aplikacji webowej.

Koszt w czasie w trzech modelach

Cena zakupu nie pokazuje pełnego kosztu, bo każdy model rozkłada wydatki inaczej. Pakiet standardowy ma niski koszt początkowy i stałą opłatę za wsparcie, ale każda zmiana procesu wymaga obejścia w programie. System na zamówienie kosztuje najwięcej na starcie, a późniejsze zmiany są tanie, jeśli wykonawca przygotował kod do rozbudowy.

Przy systemie dedykowanym dochodzi kwestia praw do kodu. Umowa powinna rozstrzygać, czy klient nabywa autorskie prawa majątkowe, czy otrzymuje licencję, oraz czy wykonawca przekazuje kod źródłowy wraz z dokumentacją. Od tego zależy, czy po zakończeniu współpracy inny zespół będzie mógł rozwijać aplikację.

Ocena dojrzałości produktu przed zakupem

Dojrzałość produktu nie wynika z liczby lat na rynku, tylko z tego, jak producent zarządza zmianami. Sprawdza się ją pytaniami, na które da się odpowiedzieć dokumentem: polityką wersji oraz harmonogramem wsparcia i opisem migracji. Wymijająca odpowiedź na takie pytanie jest sama w sobie sygnałem.

Wersjonowanie i migracje bazy

Zasady numerowania wydań opisuje specyfikacja Semantic Versioning. Zmiana pierwszego numeru oznacza zmianę niezgodną z poprzednią wersją, drugiego - nową funkcję bez utraty zgodności, a trzeciego - poprawkę błędu. Dla klienta liczy się wniosek praktyczny: aktualizacja z 2.4.1 do 2.4.3 nie powinna wymagać zmian w integracjach, a z 2.4 do 3.0 już tak.

Dojrzały produkt zapisuje wersję schematu w samej bazie, dzięki czemu każdy skrypt migracyjny wie, czy został już uruchomiony. Poniższy przykład jest poglądowy, a nazwy obiektów są przykładowe.

CREATE TABLE dbo.SchemaVersion (
    Version    NVARCHAR(20)  NOT NULL PRIMARY KEY,
    Script     NVARCHAR(200) NOT NULL,
    AppliedAt  DATETIME2(0)  NOT NULL DEFAULT SYSUTCDATETIME()
);

SELECT TOP (1) Version, AppliedAt
FROM dbo.SchemaVersion
ORDER BY AppliedAt DESC;

Zapytanie zwraca aktualną wersję schematu i moment jej wdrożenia. Skrypt aktualizacji sprawdza tabelę na początku i pomija kroki, które już wykonano, więc jego ponowne uruchomienie po przerwaniu nie psuje bazy.

Reguła: migracja bazy musi dać się powtórzyć bez skutków ubocznych, bo przerwane wdrożenie to sytuacja normalna, a nie wyjątek.

Proces wydania i notatki o zmianach

Producent, który dojrzale zarządza produktem, publikuje notatki o zmianach dla każdego wydania. Wpis wskazuje naprawione błędy i dodane funkcje oraz czynności, które użytkownik musi wykonać po aktualizacji, na przykład uruchomić skrypt migracyjny. Brak takich notatek oznacza, że klient dowiaduje się o zmianach dopiero wtedy, gdy zmienią się wyniki jego raportów.

Kolejnym sygnałem są testy regresji. Producent uruchamia je przed wydaniem, żeby poprawka w jednym module nie zepsuła innego. Klient nie ma wglądu w te testy, ale może zapytać, jak często wychodzą wydania poprawkowe po dużej aktualizacji. Częste wydania naprawcze tuż po premierze świadczą o słabej kontroli jakości.

Referencje i test na własnych danych

Referencje mają wartość, gdy dotyczą podobnej skali i podobnego procesu. Rozmowa z klientem, który używa produktu od kilku lat, ujawnia rzeczy nieobecne w prezentacji: jak przebiegła ostatnia aktualizacja, ile trwało usunięcie poważnego błędu i czy zespół producenta potrafi wyjaśnić przyczynę awarii.

Uzupełnieniem jest próba na własnych danych. Producent uruchamia środowisko testowe, w którym firma wczytuje przykładową partię dokumentów i sprawdza, czy zestawienia zgadzają się z tymi, które znane są z obecnego systemu. Próba jest tania w porównaniu z kosztem błędnego wyboru i wykrywa rozbieżności w modelu danych, zanim zaczną się wdrożenie i płatności.

Cykl życia produktu i wsparcie producenta

Każda wersja programu ma datę końca, po której producent przestaje wydawać poprawki. Kupujący powinien znać tę datę przed zakupem, bo od niej zależy, kiedy trzeba będzie zaplanować migrację. Przykładem jasnej polityki jest Fixed Lifecycle Policy firmy Microsoft: harmonogram wsparcia jest podany w chwili premiery produktu, a wsparcie standardowe trwa co najmniej pięć lat.

Konsekwencje zignorowania cyklu życia pokazuje artykuł o SQL Server 2008 w systemie magazynowym. Wersja poza wsparciem nie otrzymuje poprawek bezpieczeństwa, więc nie nadaje się do nowych wdrożeń, a istniejące instalacje wymagają planu migracji.

• Wsparcie standardowe - producent naprawia błędy i rozwija funkcje, a klient otrzymuje nowe wersje w ramach umowy.
• Wsparcie ograniczone - dostępne są głównie poprawki bezpieczeństwa, bez nowych funkcji i bez zmian w projekcie.

Plan migracji z wersji, której wsparcie się kończy, powinien powstać z wyprzedzeniem, najlepiej w chwili, gdy producent ogłasza datę końca. Migracja obejmuje bazę danych oraz integracje i szablony wydruków, a każdy z tych elementów ma osobny czas testów. Odkładanie decyzji do ostatnich miesięcy zmusza do pracy pod presją, w której błędy migracji kosztują najwięcej.

Osobną kwestią jest to, kto odpowiada za rozwój po zakończeniu wdrożenia. W modelu pakietowym producent aktualizuje produkt dla wszystkich klientów, a klient płaci za wsparcie i nowe wersje. W modelu dedykowanym umowa musi wskazywać, czy wykonawca utrzymuje aplikację, czy przekazuje kod klientowi wraz z dokumentacją.

Producenci programów dla firm w logistyce - produkty i dodatki

Logistyka dobrze ilustruje model mieszany. Firma kupuje produkt branżowy dla magazynu, a jego luki uzupełnia dodatkami wykonanymi na zamówienie: integracją z ERP, dodatkowym raportem albo etykietą w formacie wymaganym przez odbiorcę. Mapę systemów, z których składa się takie środowisko, pokazuje artykuł o oprogramowaniu logistycznym.

SoftwareStudio prowadzi linię produktów branżowych: Studio WMS.net dla magazynu, Studio VSS.net dla awizacji i okien czasowych, Studio RMA.net dla reklamacji oraz Studio TCS.net dla narzędziowni. Zakres pierwszego produktu opisuje strona Studio WMS.net, a działanie systemów można obejrzeć w demo online. Firma pisze też aplikacje internetowe i mobilne na zamówienie, co pozwala łączyć oba modele w jednym projekcie.

Szczególną grupą odbiorców są operatorzy logistyczni, którzy obsługują towary wielu klientów we wspólnej przestrzeni. Wymagają oni systemu, który rozdziela stany i rozliczenia między zleceniodawców, dlatego produkt branżowy uzupełnia się regułami rozliczeń. Rolę takich firm opisuje artykuł o operatorze logistycznym.

Pytania do producenta przed podpisaniem umowy

Ocena producenta kończy się listą pytań, na które odpowiedzi trafiają do umowy. Część dotyczy produktu, część organizacji pracy. Dobrze, gdy odpowiedzi zapisano wcześniej, w analizie potrzeb, co opisuje artykuł o analizie przedwdrożeniowej.

• Bezpieczeństwo - jakie mechanizmy autoryzacji i szyfrowania stosuje aplikacja oraz jak producent reaguje na zgłoszoną lukę.
• Wsparcie - jakie są godziny obsługi oraz priorytety zgłoszeń wraz z czasami reakcji zapisanymi w umowie.
• Aktualizacje - jak często wychodzą wydania oraz czy klient może przetestować je przed wdrożeniem.
• Szkolenia - kto uczy pracowników i czy materiały obejmują procedury firmy, a nie tylko funkcje programu.

Reguła: odpowiedź producenta, której nie da się zapisać w umowie, nie powinna wpływać na decyzję o zakupie.

Wybór dostawcy w szerszym ujęciu, wraz z porównaniem ofert, porządkuje tekst o dostawcy oprogramowania dla firm.