Najważniejszy system w organizacji nie zawsze znajduje się na diagramie architektury. Czasem ma nazwę pliku, kilka makr i znacznie więcej użytkowników, niż zakładał jego twórca.
Ktoś w sprzedaży albo księgowości potrzebuje połączyć dane z dwóch systemów, obsłużyć wyjątek albo policzyć coś, czego nie uwzględnia żaden raport. Powstaje arkusz, który z czasem zyskuje kolejne funkcje, użytkowników i powiązania. Po dwóch latach ten sam plik może przetwarzać dane kilku działów i wpływać na decyzje biznesowe, choć w architekturze IT formalnie nie istnieje.
Właśnie w takich warunkach rozwija się Shadow IT: rozwiązania powstające poza standardowym nadzorem IT, które z czasem zaczynają pełnić istotną funkcję w procesach organizacji. Mogą to być na przykład:
- Excel, który z czasem stał się kluczowym narzędziem do obsługi procesu,
- aplikacja SaaS kupiona przez dział biznesowy bez konsultacji z IT,
- automatyzacja zbudowana samodzielnie w Power Automate,
- baza danych w Accessie – utrzymywana przez jednego pracownika,
- skrypt lub makro, od którego zależy część procesu,
- dane przesyłane między systemami przez arkusze, e-mail i ręczne kopiowanie.
Kiedy arkusz zaczyna pełnić funkcję systemu?
Nie decyduje o tym sama technologia. Excel, aplikacja low-code czy prosty skrypt mogą być narzędziem pomocniczym albo elementem, od którego zależy ciągłość procesu.
Warto zwrócić uwagę czy rozwiązanie:
- stanowi główne źródło ważnej informacji,
- przetwarza dane z kilku systemów,
- uruchamia lub warunkuje kolejne działania,
- jest wykorzystywane przez wiele osób lub działów,
- zawiera reguły, makra lub automatyczne przepływy,
- wpływa na raportowanie, decyzje lub wynik procesu.
Im więcej takich cech, tym trudniej traktować takie rozwiązanie jak zwykłe narzędzie użytkownika. W praktyce działa już jak system, choć nie przeszło formalnej ścieżki właściwej dla systemów IT.
Skąd bierze się Shadow IT w firmie?
Lokalne rozwiązania często powstają dlatego, że potrzeba biznesowa pojawia się szybciej niż możliwość jej obsłużenia w ramach standardowej ścieżki IT. Na początku są niewielkie, ale z czasem przybywa użytkowników, danych, reguł i zależności.
Low-code, no-code i AI jeszcze bardziej skracają drogę od pomysłu do działającego rozwiązania. Dlatego celem zarządzania Shadow IT nie powinno być objęcie centralnym nadzorem wszystkiego, co powstaje poza IT, ale rozpoznanie momentu, w którym lokalne narzędzie zaczyna mieć znaczenie dla ciągłości procesu, bezpieczeństwa danych lub działania innych systemów.
Jakie ryzyko naprawdę powinien ocenić CTO?
Nie każdy arkusz, przepływ czy lokalna aplikacja wymaga takiego samego poziomu kontroli. Narzędzie używane przez dwie osoby do pomocniczych obliczeń jest czymś innym niż rozwiązanie, które przetwarza dane z ERP, zasila raport zarządczy i warunkuje kolejne działania w procesie. W ocenie warto uwzględnić trzy obszary:
- Właściciel i utrzymanie: kto odpowiada za rozwiązanie, zatwierdza zmiany i reaguje na błędy? Czy może być ono utrzymywane przez kogoś innego niż jego autor?
- Dane i dostęp: jakie dane rozwiązanie przetwarza, skąd je pobiera, gdzie zapisuje i kto ma do nich dostęp? Czy możliwe jest odtworzenie historii zmian i działań?
- Zależności i krytyczność: z jakimi systemami i etapami procesu rozwiązanie jest powiązane, ilu użytkowników od niego zależy i co wydarzy się, jeśli przestanie działać?
Ocena tych trzech obszarów pozwala określić nie tylko poziom ryzyka, ale przede wszystkim właściwy poziom nadzoru. Część rozwiązań może pozostać w rękach biznesu, część będzie wymagała jasno określonego właściciela i zasad, a rozwiązania krytyczne mogą wymagać zaangażowania IT, dodatkowych zabezpieczeń albo zmiany technologii.
Najpierw widoczność, później decyzja
Pierwszym krokiem nie musi być standaryzacja ani migracja. IT potrzebuje przede wszystkim wiedzieć, które rozwiązania mają znaczenie dla organizacji.
Można podejść do tego w pięciu krokach:
- Odkryj: zidentyfikuj rozwiązania istotne dla procesów, danych lub decyzji. Przykładowo, Microsoft w dokumentacji Power Platform inventory pokazuje, jak administratorzy mogą uzyskać centralny wgląd w aplikacje, przepływy i agentów działających w środowisku Power Platform,
- Opisz: ustal właściciela, użytkowników, wykorzystywane dane i zależności,
- Oceń: określ krytyczność, skalę wykorzystania i konsekwencje ewentualnego błędu lub niedostępności,
- Dobierz poziom nadzoru: zdecyduj, czy rozwiązanie może pozostać lokalne, wymaga zasad governance, czy powinno zostać objęte większym nadzorem IT. Podobne podejście Microsoft opisuje w zaleceniach dotyczących zarządzania Power Platform na dużą skalę,
- Wracaj do oceny: znaczenie rozwiązania może zmieniać się wraz z liczbą użytkowników, danymi i rolą, jaką zaczyna pełnić w procesie.
Governance nie musi blokować citizen development
Shadow IT i citizen development mogą wyglądać podobnie, ale różni je sposób zarządzania. W modelu citizen development organizacja świadomie pozwala biznesowi tworzyć aplikacje i automatyzacje, jednocześnie określając zasady dotyczące bezpieczeństwa, danych, odpowiedzialności i utrzymania.
W praktyce oznacza to, że biznes może zachować możliwość szybkiego tworzenia rozwiązań, a IT zapewnia ramy pozwalające robić to w kontrolowany sposób.
Governance nie kończy się jednak na konfiguracji platformy. Microsoft, opisując Center of Excellence, zwraca uwagę, że skuteczne CoE wymaga nie tylko odpowiednich narzędzi, ale również ludzi, jasno określonych ról i odpowiedzialności, komunikacji oraz procesów.
Nie każdy „ukryty system” trzeba zastępować
Odzyskanie widoczności pozwala zdecydować, co dalej zrobić z danym rozwiązaniem. Lokalne narzędzie o niewielkim ryzyku może pozostać w obecnej formie. Inne będzie wymagało governance i stabilniejszego modelu utrzymania. Jeśli problemem są przepływy danych, właściwą odpowiedzią może być integracja. Jeśli natomiast narzędzie kompensuje skomplikowany sposób pracy, najpierw warto przyjrzeć się samemu procesowi.
Decyzja powinna więc wynikać z roli rozwiązania w procesie, jego krytyczności i ryzyka, a nie z samego faktu, że powstało poza formalnym nadzorem IT.
Od procesu do technologii, nie odwrotnie
Dopiero wtedy pojawia się pytanie o technologię. Proces można uprościć, połączyć istniejące systemy, wykorzystać RPA, zbudować rozwiązanie low-code albo zastosować AI. Coraz częściej technologie te również się uzupełniają.
Nie każdy proces jest jednak dobrym kandydatem do automatyzacji. Dlatego przed wyborem technologii trzeba zrozumieć jego przebieg, reguły, wyjątki, dane i miejsca, w których powstaje ręczna praca. Czasem większą wartość przyniesie najpierw uporządkowanie procesu, a dopiero później jego automatyzacja.
60 minut o tym, jak podejść do automatyzacji w Twojej organizacji
Jeśli w Twojej organizacji część procesów nadal opiera się na arkuszach, lokalnych aplikacjach lub ręcznym przenoszeniu danych, podczas Discovery Call możemy porozmawiać o tym, jakie są możliwości ich uporządkowania, integracji lub automatyzacji.
Pokazujemy, jakie możliwości dają dziś RPA, low-code i AI, jakie procesy warto brać pod uwagę w pierwszej kolejności oraz jak do podobnych wyzwań podchodzą inne organizacje. Rozmawiamy również o kosztach, bezpieczeństwie i barierach wejścia w poszczególne technologie.
Celem spotkania nie jest analiza konkretnego procesu ani wybór rozwiązania w 60 minut, ale lepsze rozeznanie możliwości i kierunków, które warto rozważyć w organizacji.
