Którą część SaaS warto zastąpić jako pierwszą
Firma chce odejść od SaaS, ale większość zespołu nadal potrzebuje go do codziennej pracy. Pierwszy etap zmiany powinien mieć wyraźną granicę: wiadomo, która praca przechodzi do nowej aplikacji, skąd bierze dane i co pozostaje w obecnym systemie. Bez tego częściowa wymiana łatwo tworzy dwa miejsca obsługi tej samej sprawy.
Syntalith
Syntalith może zaproponować własną aplikację dla wybranego fragmentu pracy oraz połączenie jej z narzędziami, które firma zachowuje. Przed ustaleniem zakresu warto prześledzić jedną sprawę od początku do końca. Szukamy miejsca, w którym można rzeczywiście przekazać odpowiedzialność między systemami, a potem ocenić działanie nowego etapu.
Pierwszy zakres musi dać się oddzielić
Załóżmy, że firma usługowa prowadzi klientów, oferty i realizację w jednym pakiecie. Najwięcej ręcznej pracy wymaga przygotowanie dokumentów po zakończonej usłudze. Zespół rozważa własny obieg tych materiałów, pozostawiając oferty i planowanie w obecnym narzędziu.
Taki podział może być czytelny: zakończone zlecenie wraz z identyfikatorem klienta trafia do aplikacji dokumentowej, a odpowiedzialna osoba przygotowuje pakiet. Trzeba jednak rozstrzygnąć, co stanie się po ponownym otwarciu zlecenia. Jeżeli poprawka pozostanie tylko w starym systemie, pracownik może przekazać nieaktualne materiały. Ta zależność należy do pierwszego zakresu, nawet jeśli występuje rzadziej niż zwykłe zakończenie pracy.
Dobry kandydat ma zrozumiały początek, rezultat potrzebny odbiorcy i osobę odpowiedzialną za całość. Można wskazać, które informacje będą odczytywane z dotychczasowego narzędzia i które nowe zapisy powstaną poza nim. Gdy prawie każda czynność wymaga zmiany rekordu w obu miejscach, granica wymaga ponownego przemyślenia.
Wybór nie musi padać na najbardziej irytującą funkcję. Czasem jest ona tak mocno związana z resztą pakietu, że jej wydzielenie pociąga za sobą dużą część systemu. Lepiej porównać kilka kandydatów według znaczenia problemu, zależności i możliwości sprawdzenia wyniku. Obszar mniej rozległy może dać firmie doświadczenie w zamawianiu i utrzymywaniu własnego oprogramowania.
Dwa systemy potrzebują uzgodnionej współpracy
AWS opisuje stopniowe zastępowanie funkcji systemu we wzorcu strangler fig: stare i nowe części współistnieją podczas przejścia. Opis dotyczy modernizacji aplikacji i ma określone ograniczenia techniczne. Przy SaaS możliwość takiego podziału trzeba osobno sprawdzić w dostępnych integracjach i warunkach usługi.
Przed budową warto zapytać dostawcę obecnego produktu, czy konfiguracja albo dostępny dodatek rozwiąże wybrany problem. Własny fragment może także pozostać trwałym rozszerzeniem, jeśli reszta pakietu dobrze służy firmie. Decyzja o pierwszym etapie nie zobowiązuje do późniejszego odtworzenia wszystkich funkcji.
W porównaniu kosztów uwzględnij okres współpracy obu narzędzi. Dostęp do starego systemu, połączenia i pomoc użytkownikom nadal mogą być potrzebne. Nie należy zakładać, że uruchomienie jednej aplikacji automatycznie zmniejszy zobowiązanie wobec dostawcy SaaS. To zależy od warunków korzystania i tego, kto nadal potrzebuje produktu.
Przejście ma właściciela po obu stronach
Otwarte sprawy wymagają jasnego ustalenia, gdzie będą dokończone. W przykładzie firma może pozostawić rozpoczęte pakiety dokumentów w starym obiegu, a nowe kierować do aplikacji, albo uzgodnić ich przeniesienie. Pracownik powinien łatwo sprawdzić właściwe miejsce bez porównywania dwóch list.
Zamówienie powinno obejmować sposób wyjaśniania brakujących aktualizacji i odpowiedzialność za połączenie. Ustal też dostęp do kodu, dokumentacji i eksport danych z odwołaniami do pierwotnych zleceń. Dzięki temu kolejny etap lub zmiana wykonawcy nie wymagają odtwarzania znaczenia zapisów od początku.
Porozmawiaj z Syntalith o czynności, którą zespół najczęściej wykonuje poza SaaS. Na jej przykładzie możemy omówić granicę pierwszego zakresu, zależności i warunki pozostawienia reszty systemu. Informacje o wycenie są w cenniku.
Sprawdźmy, czy własne oprogramowanie ma uzasadnienie
Porównajmy obecny abonament, potrzebne funkcje i pracę wokół systemu z kosztem budowy, migracji oraz utrzymania rozwiązania na zamówienie.
Poznaj aplikacje na zamówienie