Zduplikowane narzędzia SaaS

czym to jest

Zduplikowane narzędzia SaaS to aplikacje, które pełnią tę samą lub w znacznym stopniu nakładającą się funkcję, przyjęte niezależnie przez różne zespoły w tej samej organizacji.

Typowe przykłady to narzędzia do wideokonferencji kupione osobno przez różne działy, platformy do podpisywania dokumentów używane przez dział prawny i finansowy bez koordynacji, narzędzia do zarządzania projektami działające równolegle w inżynierii i operacjach oraz platformy do onboardingu HR przyjęte na poziomie działu, zanim ustanowiono system ogólnofirmowy.

Duplikacja jest zwykle nieplanowana, naturalny efekt rozproszonych zakupów. Każdy zespół miał uzasadnioną potrzebę, ocenił narzędzia pasujące do swojego workflow i się zarejestrował. Bez centralnej inwentaryzacji aplikacji nie było mechanizmu, który ujawniłby, że inny zespół już rozwiązał ten sam problem.

dlaczego się gromadzi

Zduplikowane narzędzia gromadzą się, gdy zakupy są rozproszone, a widoczność niska.

Szefowie działów mają autorytet nad własnymi budżetami narzędziowymi. Oceniają narzędzia na podstawie konkretnych wymagań swojego zespołu. Mogą nie wiedzieć, czego używają inne działy, zwłaszcza jeśli nie ma centralnego rejestru aplikacji ani procesu przeglądu IT.

Dostawcy aktywnie zachęcają do adopcji na poziomie zespołu. Wiele narzędzi SaaS jest zaprojektowanych, żeby rozprzestrzeniać się wirusowo w organizacjach, zaczynając od zespołu czy działu i rozszerzając się przez ich sieci. Narzędzie zostaje przyjęte na poziomie zespołu, zanim ktokolwiek zapyta, czy organizacja nie ma już czegoś podobnego.

Konsolidacja jest trudniejsza niż adopcja. Gdy zespół już używa narzędzia i wbudował je w swój workflow, przeniesienie go na inne narzędzie niesie koszt przełączenia: migrację danych, zmiany workflow, ponowne szkolenie. Nawet gdy duplikacja zostanie zidentyfikowana, krok konsolidacji zostaje odłożony, bo bieżący koszt obu narzędzi jest mniej widoczny niż wysiłek zmiany jednego z nich.

co to kosztuje

Koszt finansowy. Dwie subskrypcje za narzędzia, które można by skonsolidować w jedno. W środowiskach, gdzie zakupy były rozproszone po zespołach przez kilka lat, skumulowany koszt wielu zduplikowanych par może być istotny. Ten koszt jest trudniejszy do zauważenia, bo jest rozłożony po różnych liniach budżetowych i różnych datach odnowienia.

Rozproszenie danych. Ta sama kategoria danych trzymana u dwóch dostawców na różnych warunkach. Rekordy klientów w dwóch platformach CRM. Umowy w dwóch narzędziach do podpisywania. Te same dane pracowników w dwóch systemach onboardingu. Każda kopia podlega własnym praktykom obsługi danych, warunkom rezydencji i standardom bezpieczeństwa danego dostawcy. Masz dwukrotnie większą powierzchnię danych za połowę użyteczności.

Luka governance. Dwóch dostawców wymaga dwóch DPA, dwóch ocen bezpieczeństwa, dwóch zestawów przeglądów dostawców, dwóch wpisów w Twoim rejestrze podmiotów przetwarzających. Narzut się kumuluje. Gdy jeden dostawca doświadczy naruszenia albo zmieni swoje warunki, musisz wiedzieć, jakie dane były w jego systemie i kto był dotknięty. Przy zduplikowanych narzędziach pytanie o zakres jest bardziej skomplikowane.

Niespójne standardy bezpieczeństwa. Dwa narzędzia pełniące tę samą funkcję mogą mieć różne konfiguracje bezpieczeństwa, ustawienia MFA i kontrole dostępu. Użytkownicy jednego narzędzia mogą mieć lepiej kontrolowany dostęp niż użytkownicy drugiego. Ta rozbieżność nie jest zamierzona, ale tworzy nierówną postawę bezpieczeństwa między zespołami wykonującymi równoważną pracę.

co działa

Nakładanie się staje się widoczne dzięki funkcjonalnej mapie inwentaryzacji aplikacji: każde narzędzie zapisane wraz z podstawową funkcją, wideokonferencje, podpisywanie dokumentów, zarządzanie projektami, CRM, platforma HR, potem pogrupowane według funkcji, żeby narzędzia dzielące ten sam wiersz się wyróżniały. Mapa ma znaczenie, bo duplikacja jest niewidoczna na poziomie subskrypcji. Każde narzędzie wygląda uzasadnione na własnej linii budżetowej, a tylko widok na poziomie funkcji pokazuje dwa z nich robiące jedną pracę.

Nie każde takie sparowanie jest problemem. Niektóre organizacje świadomie prowadzą dwa narzędzia w jednej kategorii, podzielone według geografii, segmentu klientów czy granicy regulacyjnej, i taki układ jest decyzją, nie luką. Rozróżnienie warte zrobienia to między nakładaniem się, które ktoś wybrał, a nakładaniem się, którego nikt nie zauważył, bo tylko ten drugi rodzaj rozprasza dane i umowy bez nikogo, kto by odpowiadał za ten kompromis.

Uzasadnienie konsolidacji opiera się na trzech liczbach na parę duplikatów: koszcie subskrypcji, liczbie aktywnych użytkowników w każdym narzędziu i typach danych, jakie każde z nich przechowuje. Mając te dane, przegląd z odpowiednimi szefami działów może dojść do jednego z trzech uczciwych wniosków: skonsolidować do jednego narzędzia, potwierdzić, że podział jest zamierzony, albo ustawić konsolidację na następny cykl odnowienia, gdy koszty przełączenia są najniższe. Termin odnowienia ma tu większe znaczenie niż pilność, bo migracja w trakcie kontraktu płaci za oba narzędzia, jednocześnie pochłaniając wysiłek przełączenia.

To, co zapobiega kolejnej duplikacji, to sprawdzenie zakupowe: każdy wniosek o nowe narzędzie porównywany z istniejącym rejestrem aplikacji, zanim powstanie subskrypcja. Sprawdzenie kosztuje minuty i działa właśnie dlatego, że odbywa się w momencie adopcji, gdy żaden workflow jeszcze nie zależy od nowego narzędzia, a koszt przełączenia wciąż wynosi zero.