Którą część SaaS warto zastąpić jako pierwszą

AWS opisuje wzorzec strangler fig: nowe funkcje przejmują kolejne fragmenty starego systemu, aż stary można wyłączyć. Przy SaaS działa to podobnie, ale każdy fragment potrzebuje własnej granicy danych, bo poprawka zapisana tylko w starym systemie da pracownikowi nieaktualne materiały.

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.

Ile to kosztuje

Od czego zacząć

Na bezpłatnej analizie wybieramy jeden proces i liczymy wolumen oraz czas pracy zespołu, a w 2 dni robocze dostajesz pisemne podsumowanie z ceną. Budowę prowadzimy w ramach aplikacji AI, a utrzymanie wyceniamy osobno.