W skrócie
Część potrzeb firmy pokrywa konfiguracja statusów i pól formularza, a resztę zmiana w kodzie programu. Zmianę opisuje się na przykładowych sprawach z kryteriami odbioru, zanim producent przygotuje wycenę. Przykładem zmiany na zamówienie jest aplikacja Android dla serwisantów, która powstała w 2023 roku dla serwisu taboru szynowego. Zmianę utrzymuje producent, który sam wydaje nowe wersje programu.
Konfiguracja czy zmiana w kodzie programu
Przy wdrożeniu wdrożeniowcy konfigurują statusy i role, a także pola formularza i szablony korespondencji. Taka konfiguracja nie zmienia kodu programu, więc nie wymaga osobnego utrzymania. Konfiguracja statusów i ról trwa przy standardowym wdrożeniu 1-2 tygodnie. Zmiana w kodzie jest potrzebna dopiero wtedy, gdy firma chce nowej funkcji, której konfiguracja nie daje. Konfigurację opisujemy przy konfiguracji programu do reklamacji przy wdrożeniu.
Konfiguracja nie zmienia kodu programu, a każda zmiana w kodzie wymaga wyceny.
Starsza dokumentacja opisuje też personalizację przez szablony menu, formatek, widoków tabel i wydruków. Szablony zmieniają głównie wygląd i układ ekranów. Szablon wydruku zmienia się np. po zmianie przepisów o reklamacjach. Personalizację opisujemy przy personalizacji programu do reklamacji.
Przykłady zmian na zamówienie
Zmiany na zamówienie dotyczą zwykle nowych funkcji albo integracji, których nie ma w standardowej wersji. Najbardziej widocznym przykładem jest aplikacja Android dla serwisantów terenowych, która powstała w jednym wdrożeniu. Aplikacja mobilna jest w cenniku osobnym modułem, a jej zakres ustala się dla konkretnej firmy. Zmiana w programie wymaga zawsze wyceny, nawet gdy jest niewielka. Zestawiamy typowe zmiany:
| Rodzaj zmiany | Przykład | Kiedy ma sens |
|---|---|---|
| Aplikacja mobilna | Aplikacja Android dla serwisantów taboru szynowego | Serwisanci pracują w terenie |
| Integracja | Połączenie z systemem WMS operatora logistycznego | Dane leżą w innym systemie firmy |
| Raport | Własny raport z danymi dla zarządu | Standardowe raporty nie pokazują potrzebnych danych |
| Reguła terminu | Termin liczony według umowy z odbiorcą | Firma ma terminy inne niż 14 dni |
| Wydruk | Protokół z treścią prawną firmy | Firma ma własny wzór dokumentu |
Integracja z WMS z referencji z 2012 roku pokazuje zmianę, która łączy program z innym systemem firmy. Aplikację mobilną opisujemy przy reklamacjach na telefonie i tablecie, a raporty przy raportach reklamacyjnych w SQL Server Reporting Services. Każda z tych zmian zaczyna się od analizy procesu, a nie od projektu ekranu.
Raport na zamówienie korzysta z tych samych danych co raporty standardowe. Nowy raport nie zmienia więc sposobu pracy działu reklamacji. Zarząd dostaje go w PDF albo XLS tak jak inne raporty. Według starszych opisów administrator nadaje nowemu raportowi nazwę w menu.
Jak opisać zmianę dla producenta
Dobry opis zmiany zaczyna się od problemu firmy, a nie od gotowego rozwiązania. Programista, który zna cel, zaproponuje często prostszą zmianę niż ta, którą firma wymyśliła sama. Opis przygotowuje zwykle kierownik działu reklamacji razem z osobami z pierwszej linii. Opis zmiany zawiera zwykle cztery elementy:
- Cel zmiany - problem, który zmiana ma rozwiązać, np. ręczne liczenie terminów z umów.
- Przykładowe sprawy - kilka prawdziwych reklamacji, na których zmiana ma działać.
- Użytkownicy - osoby i działy, które będą korzystać z nowej funkcji.
- Kryteria odbioru - sytuacje, w których firma sprawdzi, że zmiana działa.
Przykładowe sprawy powinny pochodzić z codziennej pracy działu, a nie z wyjątków. Dane osobowe klientów w przykładach zastępujemy danymi zmyślonymi przed wysłaniem opisu. Dobrze opisana zmiana skraca też czas wyceny, bo producent nie musi dopytywać o szczegóły. Wymagania opisujemy szerzej przy specyfikacji wymagań dla systemu reklamacji.
Wycena i termin zmiany
Na podstawie opisu producent szacuje pracę programistów i testy, a potem przygotowuje wycenę z terminem. Według opisów analizy przedwdrożeniowej zakres zmian trafia do wyceny razem z wdrożeniem. Zmiana zamówiona po uruchomieniu programu ma osobną wycenę. Wycena zawiera zakres zmiany, czyli opis tego, co zmiana obejmuje, a czego nie. Różnicę między błędem a zmianą opisujemy przy programie do reklamacji od producenta.
Termin zmiany wynika z jej zakresu, a ustala się go razem z wyceną. Dla porównania integracja z ERP przy standardowym wdrożeniu zajmuje 1-2 tygodnie, a testy 3-5 dni. Duże zmiany dzieli się na etapy, żeby firma korzystała z części funkcji wcześniej. Pierwszy etap obejmuje wtedy funkcję potrzebną najczęściej. Prace dla firm spoza regionu producenta prowadzimy zdalnie, co opisujemy przy wdrożeniu systemu reklamacji na odległość.
Testy i odbiór zmiany
Producent testuje zmianę na przykładowych sprawach z opisu, zanim przekaże ją firmie. Potem użytkownicy firmy sprawdzają ją według kryteriów odbioru. Odbiór kończy się zgodą firmy na uruchomienie zmiany w programie, na którym pracuje dział. Testy producenta obejmują też sprawdzenie, czy zmiana nie psuje innych funkcji programu.
Użytkownicy nowej funkcji dostają krótkie szkolenie albo opis zmiany. Zmiana, która zmienia sposób pracy działu, wymaga też aktualizacji procedury reklamacyjnej firmy. Pierwsze tygodnie po uruchomieniu pokazują, czy zmiana działa na wszystkich rodzajach spraw. Uwagi użytkowników z tego okresu trafiają do producenta jako zgłoszenia poprawek.
Zmiana na zamówienie a nowe wersje programu
Zmianę na zamówienie utrzymuje producent, który sam wydaje nowe wersje programu. Dzięki temu nowa wersja nie wymaga osobnej umowy z firmą, która przygotowała zmianę. Przy pośredniku zmiana i nowa wersja pochodzą od dwóch firm, więc każda aktualizacja wymaga ich uzgodnienia. Zasady utrzymania zmiany zapisuje się w umowie razem z Software Maintenance. Przed wydaniem nowej wersji producent może sprawdzić, czy zmiany na zamówienie działają dalej.
W chmurze prywatnej nową wersję instaluje producent, więc firma nie planuje aktualizacji sama. Przy instalacji na serwerze firmy termin aktualizacji ustala się z działem IT firmy. Numer wersji w stopce pokazuje, która wersja działa po aktualizacji. Firma, która zmieniła sposób pracy, sprawdza po aktualizacji najpierw funkcje z własnych zmian.
Kiedy zmiana w programie się opłaca
Zmiana opłaca się, gdy zastępuje ręczną pracę powtarzaną przy wielu sprawach. Reguła terminu przydaje się firmie z setkami spraw od odbiorców z różnymi umowami, a nie firmie z kilkoma sprawami w miesiącu. Przed zamówieniem zmiany firma sprawdza zwykle cztery rzeczy:
- Liczba spraw - ile reklamacji w miesiącu dotyczy problemu.
- Czas pracy - ile minut dział traci na każdą taką sprawę.
- Ryzyko błędu - czy ręczna praca kończy się przekroczeniem terminu.
- Alternatywa - czy wystarczy konfiguracja albo obejście w uwagach sprawy.
Przy rzadkich sprawach tańsze jest zwykle obejście w uwagach sprawy niż nowa funkcja. Rachunek porównuje koszt zmiany z czasem, który dział zaoszczędzi w ciągu roku. Ryzyko przekroczenia terminu wobec konsumenta liczy się osobno, bo brak odpowiedzi w 14 dni oznacza uznanie reklamacji.
Firmę i jej zespół opisujemy przy SoftwareStudio jako producencie Studio RMA.net. Aplikację dla procesu spoza reklamacji przygotowujemy osobno, bo zmiana w Studio RMA.net dotyczy tylko procesu reklamacji. Zmiana, której firma nie musi zamawiać, bo wystarczyła konfiguracja, jest zawsze najtańsza.