Wstęp

Bogactwo Microsoft 365 może z początku przytłaczać – nie trudno się pogubić w gąszczu aplikacji takich jak Teams, Outlook, Planner, OneNote, Power Apps, Power Automate itd. Szczególnie z początku wyzwaniem będzie zachowanie balansu pomiędzy użyciem wszystkich możliwych narzędzi a prawidłowym ich wykorzystaniem. Dlatego umiejętnością właściwego podejścia do wykorzystania możliwości Microsoft 365 powinno być jednym z kluczowych aspektów każdego wdrożenia tej nowoczesnej technologii.

Główną zaletą produktów Microsoft 365 jest ich wysoka integracja (nie tylko w obrębie rozwiązań Microsoft, ale także i innych dostawców). W szczególności widać to na przykładzie tzw. PowerPlatform czyli PowerApps, Power Automate i PowerBI. Każda z wymienionych platform umożliwia integrację z jednym z ponad 300 platform SaaS, pośród których tych od Microsoft jest około 50.

Digital Workplace czyli Intranet 2.0

W tradycyjnym podejściu projektowania intranetu organizacji (czyli narzędzia do wewnętrznej organizacji pracy i kolaboracji pracowników), szczególnie takim ze środowiskiem instalowanym na lokalnych zasobach (tzw. on-premise), dominowała architektura, której fundamentem stawała się jedna platforma. Dla rozwiązań Microsoft taką platformą był SharePoint. W takim podejściu wystarczyło nauczyć się administrowania i rozszerzania możliwości jednej platformy aby dostosować ją do własnych potrzeb. Bardzo często jednak (a może zawsze?) kończyło się to tym, że takie wdrożenie wymagało wielu godzin pracy (liczonych w setkach) gdzie dostarczano różne funkcjonalności: od list zadań, przez proste procesy biznesowe, aż po stosunkowo rozbudowane systemy obiegu faktur czy procesów HR. Dodatkowo każda integracja z zewnętrznymi dostawcami wymagała dobudowania właściwej integracji po stronie docelowej platformy, na której miał być oparty intranet. I co ważne – wielu klientów posiadało bardzo zbliżone wymagania i wymagało pokrycia podobnych procesów.

Dlatego przy budowaniu Intranetu w oparciu o środowisko chmurowe nie stosuje się jednej platformy, ale wykorzystuje szereg platform opierając się na możliwości każdej z nich i ich wzajemnej integracji. Takie podejście nazywamy Digital Workplace czyli Cyfrowym Miejscem Pracy, gdyż z perspektywy użytkownika dalej korzystamy z paru podstawowych narzędzi (np Outlook i Teams), jednak „pod spodem”, zachodzi wzajemna komunikacja wszystkich platform dostępnych w środowisku – Teams komunikuje się z SharePointem, z Exchangem, z Plannerem; SharePoint komunikuje się z OneDrivem; a Planner z Microsoft To-Do. Jednocześnie każda z tych platform może funkcjonować jako samodzielne rozwiązanie. Takie podejście pozwala na modułowe budowanie Digital Workplace i rozszerzanie możliwości całego środowiska o funkcjonalności kolejnych modułów co dodatkowo skraca czas dostarczenia rozwiązania.

W takiej rozprzestrzenionej architekturze kluczowym więc elementem jest stworzenie prostej mapy produktów które pozwolą użytkownikowi osiągnąć jego cel (np. obsługa nowego wniosku czy wyszukanie wiadomości od klienta). W środowisku pracy najnowszych technologii, gdzie komunikacja jest nieodłączną częścią każdego projektu, naturalnym więc wydaje się być wykorzystanie platform służących właśnie komunikacji.

Komunikacja w organizacji 

W przestrzeni chmurowych produktów Microsoft są 3 narzędzia służące do komunikacji:

1. Outlook
2. Teams
3. Yammer

Model komunikacji w organizacji wg wizji Microsoft

Każde z tych narzędzi cechuje się innym kontekstem informacji, jednak to co ich łączy, to silnie zawiązana integracja z innymi produktami Microsoft np. SharePoint czy Stream. Należy tutaj zwrócić uwagę, że SharePoint występuje w tym zestawieniu jako kontener danych, w odróźnieniu od architektur On-Premise, gdzie często był wykorzystywany jako platforma komunikacji, organizacyji projektowej oraz jako fundament dla warstwy aplikacyjnej.

Microsoft Teams

W ujęciu Intranetu jako Digital Workplace opartego o Office365 warto przyjrzeć się bliżej platformie Microsoft Teams. Jej ogromną zaletą jest organizacja pracy zespołowej, a nawet całej organizacji, poprzez konteneryzacje i umiejscowienie w spójnym kontekście informacji pochodzących z różnych systemów.

Microsoft Teams agreguje treści z innych platform tworząc kontener na prace zespołową w ramach projektu czy departamentu

Platforma Teams, to miejsce w ramach którego zespół może prowadzić konwersację jeden-na-jeden oraz jeden-do-wielu (chat jak i wideokonferencje). W ramach Teams można utworzyć dowolną liczbę zespołów. Należy tu zaznaczyć następujące elementy cechujące każdy zespół:

1. Każdy zespół jest nierozerwalnie powiązany z grupą Microsoft 365. Efektem powiązania z taką grupą jest:

• Możliwość zarządzania uprawnieniami całej grupy
• Posiadanie grupowego kalendarza
• Posiadanie grupowej skrzynki mailowej
• Posiadanie grupowej witryny SharePoint
• Posiadanie grupowego Plannera
• Posiadanie grupowego OneNote

2. Każdy zespół posiada własną przestrzeń do organizacji pracy. W ramach tej przestrzeni może tworzyć kanały. Taki kanał może posiadać:

• Własny panel konwersacji
• Własną przestrzeń na pliki
• Własny notatki OneNote
• Własne zakładki i connectory – umożliwiają one integrację z dowolnymi platformami czy stronami WWW

Każdy zespół może posiadać wiele kanałów, a każdy kanał składa się z kilku elementów

Przykład aplikacji Teams

Przykładowa architektura Digital Workplace oparta o Microsoft Teams. Widoczne kafelki z obrazkami, to artykuły zagnieżdżone na witrynie SharePoint. Autor: Tracy van der Schyff

Jednym z założeń budowanego Intranetu jest umożliwienie pracy na wielu płaszczyznach przez różne kanały dostępu w zależności od preferencji użytowników, ale również stworzenie lokalizacji, która będzie dostępna dla wszystkich z odnośnikami lub nawigacją do każdego z elementów budowanego rozwiązania (tzw. „one point of truth”).

SharePoint Online

Pomimo zastosowania Teams do budowy Digital Workplace nie oznacza to, że SharePoint Online sprowadza się jedynie do bibliotek dokumentów i list. Dalej może on funkcjonować jako strona powitalna organizacji lub departamentu. W związku z tym warto zadbać o jego spójny wygląd, nawigację jak i treść. Przykładowo w podejściu Digital Workplace na stronie powitalnej w SharePoint Online znajdziemy teraz newsy (artykuły), kalendarium najważniejszych wydarzeń czy informacje o nowych pracownikach. Również samo otwarcie strony powitalnej może odbywać się już nie poprzez przeglądarkę internetową a poprzez jedną z zakładek Teamu organizacji.

Przykładowy wygląd strony SharePoint Online departamentu sprzedaży i marketingu

W celu uspójnienia nawigacji i brandingu (company color schema, company logo) SharePointa witryny działów grupuje się poprzez tzw. hub sites.

Przykład struktury Hub Sites w organizacji Contoso

Hub Sites jest to nowa koncepcja wdrażania Intranetu wewnątrz organizacji, które pozwala na tworzenie elastycznych struktur w kształcie gwiazdy. Główna lokalizacja lub funkcja łączy się z logicznie powiązanymi elmentami. Elastyczność polega na tym, że w miarę rozrastania się organizacji można tworzyć nowe punkty główne oraz przełączać elementy powiązane.

Przykładowy model dla Intranetu w małej organizacji:

• Intranet (główna lokalizacja hub site)
  • HR (deparament powiązany)
  • Finance (departament powiązany)
  • IT (departament powiązany)

W miarę rozrastania się struktur firmowych możemy z witryn tworzyć samodzielne hub sites i w ich obrębie podpinać kolejne witryny. W tym miejscu należy zauważyć następujące rzeczy:

• W ramach architektury Hub-Sites należy zrezygnować z tzw. Podwitryn (tzw. subsites).
• 1 witryna może być podpięta tylko do 1 Hub Site
• W dowolnym momencie każda witryna może zostać przepięta do innego Hub-Site
• Adres witryny może zostać zmieniony w dowolnym momencie na nowy (np z /sites/projektX na /sites/projektY)

Daje to ogromną elastyczność architektury rozwiązań w reagowaniu na dynamikę zmian organizacji.

Główna witryna Intranetu nadal może jednak poprzez linki, webparty albo tiles dawać dostęp do poszczególnych narzędzi, rozwiązań zbudowanych w firmie.

Przykładowy zestaw tiles z aplikacjami/rozwiązanami firmy

JednNależałoby się zastanowić w jaki sposób udostępnić dla wszystkich użytkowników rozwiązania takie jak biblioteka, urlopy czy też car sharing. Może to być wykonane w postaci tiles, highlighted content albo nawet jakąś osobną PowerApps Luncher otwierającą różne narzędzia.

Search

W każdym intranecie czy digital workplace istotną kwestią jest wyszukiwanie treści. Skuteczne wyszukiwanie informacji należy rozumieć jako:

• Skrócenie czasu wyszukiwania – poszukiwanie informacji jest najczęściej stratą czasu, który mógłby być inaczej spożytkowany
• Jedno miejsce wyszukiwania (jedna wyszukiwarka, agregacja treści) – duża strata czasu także widoczna jest przy odnajdywaniu miejsca czy systemu, gdzie należałoby szukać. W intranecie powinno być 1 miejsce z którego zawsze można znaleźć interesującą nas treść
• Wyszukiwanie kontekstowe – wyszukiwanie w ramach konkretnej lokacji/aplikacji powinno wyszukiwać tylko w jej obrębie. Z tego powodu nie należy umieszczać wyszukiwarki globalnej w każdym miejscu.
• Wyszukiwanie mobilne – ważny aspekt mobilności pracowników i dostępu do narzędzi z różnych miejsc.
• Powiązanie podobnych informacji z różnych źródeł (np. Produkt -> grupa produktów -> klienci) – szybki dostęp do wiedzy handlowej, potrzebny przy rozmowach i spotkaniach.

Warto zaznaczyć, że wartość wyszukiwania rośnie przy uporządkowanych zbiorach informacyjnych. Zatem, dobrą praktyką jest wprowadzenie ładu informacyjnego, który opisuje kategorie przechowywanej i przetwarzanej informacji: gdzie je zapisywać, jak je opisywać (metadane), jak zabezpieczyć przed nieuprawnionym dostępem, jak długo mają żyć, itp.

Każdy produkt Microsoft 365 posiada własną wyszukiwarkę. Dodatkowo w SharePoint czy Teams znajdują się wyszukiwarki globalne wyszukujące odpowiednio w obrębie wszystkich stron SharePoint czy Teams (także w zawartości pliku).

Wyszukiwanie z poziomu SharePoint

Wyszukiwanie z poziomu Teams

SharePoint umożliwia konfigurację wyników wyszukiwania w następujący sposób:

• Wertykały – zbiory wyników: osoby, pliki, video itp.
• Search Results template – szablon wyświetlania wyników
• Key words actions – na wystąpienie słów kluczowych można wyświetlić rekomendacje, konkretne wyniki
• Wildcards – szukanie po fragmentach fraz (np test* znajdzie wyniki dla „test”, „testy” jak i „testowanie”
• Ranking Model – nałożenie odpowiednich wag na metadane wpływające na kolejność wyników (np trafienie na słowo w tytule ma wyższą wagę (jest ważniejsze) niż trafienie na słowo w treści)
• Hit higlighting – podkreślanie trafionych fraz

Rekomendowane podejście

Przy projektowaniu rozwiązań IT na ocenę obranej architektury mają wpływ następuję czynniki:

1. Ogólny poziom skomplikowania – im wyższy, tym architekturę będzie cechować wyższa inercja czyli wyższe będą czynniki wymienione dalej. Poziom skomplikowania zależeć może np. od:
   1. Czy w architekturze wykorzystywane są gotowe platformy, czy wszystko budowane jest od podstaw?
   2. W przypadku gotowych platform:
      1. Jak skomplikowana jest instalacja platformy?
      2. Jak dużo wbudowanych funkcji wykorzystujemy?
   3. Jak dużych konfiguracji wymagają te platformy?
   4. Jak szybko jesteśmy w stanie zareagować i naprawić błąd platformy?
   5. W przypadku systemów/funkcjonalności budowanych od podstaw:
   6. Na ile stabilny i właściwie wykorzystywany jest wybrany język programowania?
   7. Na ile stabilne i właściwie wykorzystane są wybrane frameworki i biblioteki?
   8. Na ile dobrze wybrane frameworki i biblioteki są udokumentowane?
2. Czas budowy – im niższy tym lepiej dla całej architektury, gdyż wpływa to bezpośrednio na koszt błędnej analizy biznesowej
3. Kosztowność przedsięwzięcia
   1. Koszt błędnej analizy biznesowej– jak kosztowne będzie wycofanie się fragmentu rozwiązania, które okazało się niepotrzebne z punktu widzenia biznesu? Na ten współczynnik ma wpływ:
   2. całościowy koszt projektu – im większy koszt tym, naturalnie, koszt zmiany implementacji jego części również jest większy
   3. Koszt naprawy błędu – jak kosztowne będzie naprawienie błędnej implementacji (np błędu w aplikacji)? Koszt ten jest tym większy im bardziej skomplikowane jest rozwiązanie oraz im później zostanie wykryty błąd (tutaj, tak jak w poprzednim punkcie, zależy to również od mnogości etapów i sposobu prowadzenia projektu).
   4. Koszt wyjścia – jak kosztowne będzie wycofanie się z obecnej architektury bądź zastąpienie jego części (modułu) inną technologią?
4. Podejście projektowe
   1. etapowość projektu – im więcej etapów, milestones, tym częściej jesteśmy w stanie weryfikować zgodność z wymaganiami biznesu
   2. sposób prowadzenia projektu – im większe zaangażowanie zamawiającego w trakcie procesu dostarczania oprogramowania (np poprzez częstszy kontakt z dostawcą) tym ryzyko błędnej analizy biznesowej może być szybciej wykryte, a więc maleje koszt tego błędu
5. Utrzymywalność (maintenance) – Na ile rozwiązanie jest łatwe w utrzymaniu? Czy możemy to robić zasobami wewnętrznymi czy musimy posiłkować się firmą zewnętrzną?
6. Rozwój i integracja – Jak duże mamy pole manewru w przypadku rozwijania bądź integracji rozwiązania? Czy możemy rozwiązanie rozwijać własnymi zasobami czy musimy posiłkować się firmą zewnętrzną? Jak dużo pracy wymaga zachowanie odpowiedniego poziomu bezpieczeństwa? Jak duży wpływ mamy na zmiany wykorzystywanej platformy/biblioteki/framework’u? Czy jesteśmy w stanie zamrozić wersję?

Mając na uwadze powyższe punkty rekomendowane podejście jest następujące:

1. Wykorzystanie możliwie dużo platform dostępnych w Office365
   1. Wpływa to korzystnie, a więc na niższy poziom skomplikowania rozwiązania, krótszy czas budowy, niższy koszt błędnej analizy biznesowej i łatwiejsze utrzymanie. W kwestii rozwoju należy zauważyć 2 kwestie:
      1. Możemy możliwości platform (Microsoft udostępnia API do narzędzi). Dodatkowo Microsoft sam również regularnie rozwija swoje narzędzia.
      2. Każdy z komponentów Office365 posiada własne API jak i jest dostępne z poziomu graph API.
2. Wykorzystanie możliwie dużo funkcjonalności dostępnych „z pudełka” (out-of-the-box). Wpływa to korzystnie na architekturę, a więc obniża poziom skomplikowania rozwiązania, umożliwia krótszy czas budowy rozwiązania i niższy koszt błędnej analizy biznesowej. Na szczególną uwagę zasługuje tu wysoce uproszczone utrzymanie takich rozwiązań, gdyż aktualizacja, możliwości i bezpieczeństwo samych platform leży w całości po stronie dostawcy (Microsoft). Po stronie odbiorcy pozostaje jedynie utrzymanie własnych modyfikacji, których przy tym podejściu z założenia powinno być możliwie mało.
3. W przypadku konieczności budowy niestandardowych rozwiązań należy zacząć od budowy rozwiązań w oparciu o platformy Low-Code (PowerApps, Microsoft Flow, PowerBI). Rozpoczęcie od platform typu LowCode właściwie dotyka dwóch poprzednich punktów. Dodatkowym atutem platformy PowerApps jest istotnie skrócony proces od etapu analizy do etapu wdrożenia.

Takie podejście jak opisane powyżej zapewnia nam możliwie duży zysk (krótki czas weryfikacji biznesowej, niższy koszt całościowy rozwiązania) i niski koszt naprawy błędu. Należy jednak przy tej okazji pamiętać, że korzystając ze środowiska Office365:

• nie mamy wpływu na wersje produktów (zamrożenie wersji, rollback aktualizacji czy downgrade do wybranej wersji)
• ponosimy opłatę miesięczną, a nie jednorazową – miesięczna kwota zależy od licencji bazowej                (np. Office365 Business Premium) oraz mnogości usług premium. Choć finalna kwota jest niewielka w porównaniu do jednorazowych opłat jakie można zaobserwować u dostawców rozwiązań konkurencyjnych, to należy być świadomym konsekwencji wynikających z takiego modelu opłat w dłuższej perspektywie czasu.
• utrudniony scenariusz wyjścia – budowanie rozwiązań w oparciu o usługi Office365 cechuje niska migrowalność do innych dostawców rozwiązań. Praktycznie żadna z usług (SharePoint Online, Planner, PowerApps, Microsoft Flow itd) nie posiada mechanizmów do tego typu migracji. Natomiast można częściowo zaradzić temu problemowi np:
  • budując bazę danych na SQL i wykorzystywać go jako źródło danych dla PowerApps czy Microsoft Flow
  • wykorzystując wbudowane w niektóre usługi mechanizmy do eksportu danych do popularnych typów (np eksport listy sharepoint do excela)

Reasumując zalecanym podejściem będzie budowa intranetu zgodnie z poniższymi założeniami:

– SharePoint – główna platforma (zarówno organizacji jak i poszczególnych departamentów) do prezentacji treści typu news, wydarzenie ogólne, nawigacja po intranecie. To także platforma do przechowywania wszystkich plików oraz danych relacyjnych.

– Teams – główny kanał komunikacyjny oraz organizacja pracy zespołowej i departamentu

– OneNote – komponent do treści dowolnego formatu

– PowerApps, Power Automate – platformy do budowania wysoce interaktywnych i zautomatyzowanych procesów firmy (księgarnia, Idea Box, zamówienia obiadu itd)

– Domyślne ustawienia wyszukiwania – we wstępnej fazie projektu warto mieć świadomość o odpowiedniej architekturze informacji, ale samą konfiguracją searcha nie zajmować się na początku. Zasadniczo aby dostosować wyszukiwanie do potrzeb organizacji należy wpierw mieć treści w intranecie oraz warstwę bazodanową dla aplikacji (szczególnie jeśli będą nimi listy SharePoint). Warto też dodać, że Microsoft przebudowuje mocno swój system wyszukiwania poprzez projekt Cortex…ale to już na oddzielny artykuł 😉