Co zostaje po wdrożeniu Microsoft 365

Licencje to początek

Po migracji poczty i plików zespół projektowy przechodzi do kolejnych zadań, a środowisko wchodzi w tryb „działa, więc nie ruszamy”. Tymczasem Microsoft 365 zmienia się co miesiąc: pojawiają się nowe funkcje, zmieniają się ustawienia domyślne, a użytkownicy tworzą zespoły, witryny i udostępnienia szybciej, niż ktokolwiek je przegląda.

Utrzymanie po wdrożeniu nie wymaga dużego zespołu, ale wymaga rytmu i właścicieli. W praktyce sprowadza się do trzech obszarów: tożsamości, danych i zmian w samej usłudze. Każdy z nich zaniedbany przez kwartał zostawia ślad, który później trudno odkręcić.

Tożsamość i dostęp

Konta są pierwszą rzeczą, która rozjeżdża się po projekcie. Pracownicy odchodzą i zmieniają działy, współpracownicy zewnętrzni kończą zlecenia, a ich dostęp zostaje. Regularnie przeglądamy:

• konta osób, które odeszły: czy zostały zablokowane w dniu odejścia i czy ich dane przekazano następcy,
• konta gości w Microsoft Entra ID i datę ich ostatniego logowania,
• członkostwo w rolach administracyjnych, najlepiej przydzielanych tylko na czas wykonania zadania,
• zasady dostępu warunkowego i wymuszenie uwierzytelniania wieloskładnikowego dla wszystkich użytkowników,
• konta awaryjne z uprawnieniami administratora: czy istnieją, czy są wyłączone z zasad, które mogłyby je zablokować, i czy ktoś monitoruje ich użycie.

Tam, gdzie pozwala na to licencja, część tych zadań można zautomatyzować przeglądami dostępu w Entra ID, w których właściciele grup co kwartał potwierdzają, kto nadal powinien mieć dostęp. Najważniejsze jest jednak połączenie z działem kadr: informacja o odejściu pracownika powinna trafiać do IT w dniu zmiany, a nie przy okazji kolejnego przeglądu.

Po projekcie warto też sprawdzić, czy w środowisku nie zostały wyjątki zrobione na czas migracji: wyłączone uwierzytelnianie wieloskładnikowe dla kont technicznych, dopuszczone starsze protokoły logowania, tymczasowe uprawnienia administracyjne dla partnera wdrożeniowego. Każdy taki wyjątek był uzasadniony w trakcie prac, ale pozostawiony na stałe staje się najsłabszym punktem całego środowiska.

Biblioteki SharePoint i zespoły bez właściciela

W trakcie wdrożenia zakłada się zespoły i witryny dla działów i projektów. Po roku część z nich nie ma już aktywnego właściciela, bo osoba, która je tworzyła, zmieniła rolę albo odeszła z firmy. Treści zostają, uprawnienia zostają, a nikt nie potrafi powiedzieć, czy można je usunąć.

Dlatego od pierwszego dnia utrzymania obowiązuje prosta zasada: każdy zespół i każda witryna ma co najmniej dwóch właścicieli. Pomagają w tym wbudowane mechanizmy, takie jak zasady dla grup bez właściciela, które proszą aktywnych członków o przejęcie tej roli, oraz zasady wygasania grup Microsoft 365, które wymagają okresowego potwierdzenia, że grupa jest nadal potrzebna. Dla bibliotek z dokumentami objętymi obowiązkiem archiwizacji warto dodatkowo ustawić zasady przechowywania, żeby usunięcie zespołu nie oznaczało utraty danych.

Przy okazji przeglądu witryn warto spojrzeć na zajętość magazynu. Historia wersji dokumentów, kopie robocze i nieużywane witryny projektowe potrafią zająć znaczną część dostępnej przestrzeni, a dokupienie miejsca jest kosztem, którego można uniknąć dzięki rozsądnym ustawieniom wersji i archiwizacji zakończonych projektów.

Zmiany w usłudze i nowe funkcje

Microsoft zapowiada zmiany w Microsoft 365 z wyprzedzeniem, głównie przez Centrum wiadomości w centrum administracyjnym i publiczny plan rozwoju usługi. Problem polega na tym, że wiadomości jest dużo, a większość dotyczy funkcji, z których firma nie korzysta. Bez filtra ważne informacje giną w tłumie i zmiana zaskakuje użytkowników w dniu wdrożenia.

Dobrze sprawdzają się trzy proste praktyki:

• cotygodniowy przegląd Centrum wiadomości z oznaczeniem zmian, które wymagają decyzji, konfiguracji albo komunikatu do pracowników,
• grupa użytkowników z wcześniejszym dostępem do nowych wersji (wydanie docelowe), która sprawdza zmiany, zanim trafią do wszystkich,
• krótka notatka dla pracowników raz w miesiącu o tym, co się zmieniło i jak z tego korzystać.

Szczególną uwagę warto zwracać na funkcje włączane domyślnie, zwłaszcza związane z udostępnianiem, aplikacjami firm trzecich i narzędziami AI. Decyzja o ich wyłączeniu albo ograniczeniu powinna zapaść przed datą wdrożenia, a nie po pierwszym pytaniu od działu prawnego.

Pierwszy kwartał po projekcie

Pierwsze trzy miesiące decydują o tym, czy utrzymanie stanie się nawykiem, czy zostanie odłożone do następnego problemu. Proponujemy prosty rytm, który da się prowadzić bez osobnego zespołu:

Po kwartale warto przygotować krótkie podsumowanie: co się zmieniło, ile kont i zespołów uporządkowano, które zmiany w usłudze dotknęły użytkowników. To dobry materiał do rozmowy z zarządem o tym, czy utrzymanie wymaga wsparcia z zewnątrz, czy wystarczą własne siły.

Kto za to odpowiada

Najczęstszym błędem po wdrożeniu jest założenie, że Microsoft 365 utrzymuje się sam, bo jest usługą w chmurze. Microsoft odpowiada za infrastrukturę i dostępność usługi, ale konfiguracja, tożsamości, uprawnienia i dane pozostają po stronie organizacji. Ten podział warto zapisać wprost:

• IT odpowiada za konfigurację, bezpieczeństwo i monitoring,
• właściciele biznesowi za treści i dostęp w swoich zespołach i witrynach,
• dział kadr za przekazywanie informacji o przyjęciach, przeniesieniach i odejściach w dniu zmiany,
• zarząd za decyzję, jaki poziom ryzyka organizacja akceptuje i ile przeznacza na utrzymanie.

Wdrożenie się skończyło, a środowisko rośnie bez kontroli?

Ustalimy rytm utrzymania Microsoft 365 i podział odpowiedzialności, a jeśli trzeba, przejmiemy część zadań administracyjnych.

Porozmawiaj z ekspertem