Znacie to uczucie? Wchodzicie na spotkanie zarządu. Po jednej stronie stołu siedzi „Biznes” – panowie w drogich garniturach i panie z tabletami, które liczą ROI szybciej niż wy wpisujecie hasło do roota. Po drugiej stronie siedzi „IT” – ludzie, którzy wiedzą, czym jest Kubernetes, ale boją się kontaktu wzrokowego.

Atmosfera gęstnieje.

Dyrektor Finansowy pyta: „Dlaczego wczoraj nie mogliśmy wystawiać faktur przez dwie godziny?! Ile na tym straciliśmy?”.

A szef infrastruktury, patrząc w buty, odpowiada: „Mieliśmy niespodziewany skok utylizacji CPU na klastrze bazodanowym spowodowany nieoptymalnym query i musieliśmy zrestartować serwis, żeby zwolnić locki”.

Cisza.

Dyrektor Finansowy słyszy: „Byliśmy zajęci psuciem rzeczy i w sumie to nie nasz problem, to wina query”.

Informatyk myśli: „Wyjaśniłem przecież dokładnie, o co chodzi, czepiają się”.

I tu, cały na biało (albo w smart casual), wchodzi on. Business Relationship Manager (BRM).

Mówi: „Mieliśmy zator w systemie, bo wpłynęło nietypowo dużo zamówień naraz. System się przytkał, ale już działa. Żeby to się nie powtórzyło przy Black Friday, musimy dokupić trochę mocy obliczeniowej. Kosztuje to tyle, co połowa tego, co wczoraj straciliśmy”.

Biznes kiwa głową: „Kupujcie”.

IT oddycha z ulgą: „Dostaniemy nowy sprzęt”.

O tym dzisiaj będzie. O tym, że BRM w ITIL 4 to nie jest kolejna nudna rola dla kogoś, kto nie umie kodować. To jest, moi drodzy, tłumacz symultaniczny z języka „nerd” na język „pieniądz”.

ITIL 4, czyli koniec z siedzeniem w piwnicy

Kiedyś IT było dostawcą usług. Jak elektrownia. Pstrykasz i ma być światło. Jak nie ma, to dzwonisz z awanturą. Ale ITIL 4 wywrócił to do góry nogami. Teraz nie jesteśmy „dostawcą”, jesteśmy „partnerem”. Mówimy o współtworzeniu wartości (Value Co-creation). Piękne hasło, prawda? Ale co ono znaczy w praktyce?

Znaczy tyle, że IT nie może już tylko „dowozić ticketów”. Musi rozumieć, po co ten biznes w ogóle istnieje. I tu wkracza BRM.

BRM to taki most nad przepaścią. Albo lepiej – terapeuta małżeński. Jego zadaniem jest sprawić, żeby te dwa światy, które z natury się nie rozumieją, zaczęły ze sobą rozmawiać, a nie tylko na siebie warczeć.

Dyplomata w strefie wojny, czyli zarządzanie oczekiwaniami

Największy błąd IT? Obiecywanie gruszek na wierzbie, żeby tylko „Biznes” dał im spokój.

– „Zrobicie nam tę aplikację na wczoraj?”

– „Yyy, no postaramy się”.

A potem jest płacz i zgrzytanie zębów, bo „postaramy się” dla biznesu znaczy „będzie gotowe”, a dla programisty „spróbuję, jak skończę kawę i trzy inne projekty”.

Kluczową kompetencją BRM-a jest Expectation Management, czyli brutalna szczerość ubrana w ładne słowa. BRM musi umieć powiedzieć „NIE”. Ale nie takie „nie, bo mi się nie chce”, tylko:

„Słuchajcie, możemy to zrobić na wczoraj, ale wtedy system X przestanie działać, a bezpieczeństwo będzie na poziomie hasła 'admin1′. Chcecie podjąć to ryzyko?”.

BRM to ten gość, który bierze wymagania biznesowe (często brzmiące jak list do Świętego Mikołaja) i zamienia je na specyfikację techniczną. A potem bierze specyfikację techniczną i tłumaczy biznesowi, dlaczego to tyle trwa i kosztuje. Bez niego IT robi to, co myśli, że jest potrzebne, a Biznes dostaje to, czego nie chciał.

Efekt Arbuza – zmora każdego CIO

Słyszeliście kiedyś o „Efekcie Arbuza” (Watermelon Effect)? To moje ulubione zjawisko w korporacjach, z którym BRM musi walczyć każdego dnia.

Wyobraźcie sobie taką sytuację: Mamy spotkanie przeglądowe SLA (Service Level Agreement). Wyświetlacie slajdy. Wszystko jest na ZIELONO.

• Dostępność serwera: 99,99% (Zielono!)
• Czas reakcji na zgłoszenie: < 15 min (Zielono!)
• Rozwiązanie incydentu: < 4h (Zielono!)

Jesteście z siebie dumni jak pawie. A po drugiej stronie stołu klient jest CZERWONY ze wściekłości. Jak to możliwe? Przecież SLA się zgadza!

Ano tak, że arbuz jest zielony na zewnątrz, a czerwony w środku.

Może i serwer działał przez 99,99% czasu, ale padł akurat w te 5 minut, kiedy Prezes robił najważniejszy przelew roku.

Może i czas reakcji był 10 minut, ale polegał na automatycznym mailu „Przyjęliśmy zgłoszenie”, po czym przez 4 godziny nikt nic nie zrobił, a Pani Krysia z księgowości nie mogła zamknąć miesiąca.

Statystyki są super, ale Experience (doświadczenie) użytkownika leży i kwiczy.

I tu rola BRM jest nieoceniona. To on nie patrzy tylko w Excela. On idzie do tej Pani Krysi, pije z nią kawę i pyta: „Słuchaj, jak ci się z nami pracuje?”. I wtedy dowiaduje się prawdy, której nie pokażą żadne systemy monitoringu. Dowiaduje się, że system co prawda działa, ale jest tak nieintuicyjny, że ludzie wolą liczyć na kalkulatorze.

BRM przebija tę zieloną skórkę arbuza i sprawdza, czy w środku nie ma krwistej miazgi.

Podsumowując: Po co ci ten BRM?

Możecie pomyśleć: „Eee tam, kolejne stanowisko dla kogoś, kto będzie chodził na lunche”. Błąd.

W nowoczesnym ITIL 4, gdzie technologia zmienia się szybciej niż nastroje nastolatka, potrzebujesz kogoś, kto trzyma rękę na pulsie relacji.

Bez BRM-a jesteście tylko „działem od komputerów”. Z dobrym BRM-em stajecie się strategicznym partnerem, bez którego firma nie może istnieć. BRM sprawia, że IT przestaje być kosztem, a zaczyna być inwestycją.

Więc jeśli jesteś informatykiem – znajdź swojego BRM-a i postaw mu piwo. On codziennie tłumaczy twoje „nie da się” na język, który sprawia, że nie zwalniają cię z pracy. A jeśli jesteś menedżerem i zastanawiasz się, dlaczego IT cię nie rozumie – może czas zainwestować w tłumacza?

Artykuł Most nad przepaścią: Jak BRM łączy „język IT” z „językiem biznesu” (i dlaczego to ratuje d#$&) pochodzi z serwisu Mariusz Siek.

W dynamicznym świecie IT, gdzie szybkość reakcji i jakość obsługi klienta są na wagę złota, efektywne zarządzanie wiedzą (Knowledge Management – KM) staje się fundamentem sukcesu. Firmy dążą do tego, aby wspierać swoich klientów w samodzielnym rozwiązywaniu problemów, jednocześnie zwiększając efektywność pracy zespołów wsparcia. Tutaj na scenę wkraczają ITIL (Information Technology Infrastructure Library) oraz Jira Service Management (JSM), wspierane przez Confluence, oferujące kompleksowe podejście do budowania i utrzymywania bazy wiedzy.

Czym jest Baza Wiedzy i dlaczego jest tak ważna?

Baza wiedzy to scentralizowane repozytorium informacji, które gromadzi i udostępnia dane dotyczące usług, produktów, procedur, rozwiązań problemów i często zadawanych pytań. Wykorzystywana jest w organizacji na dwa sposoby:

• Dla klientów: Umożliwia samoobsługę, pozwalając im szybko znaleźć odpowiedzi na pytania bez konieczności kontaktowania się z działem wsparcia. To przekłada się na natychmiastowe zaspokojenie potrzeb i zwiększoną satysfakcję.
• Dla agentów wsparcia: Dostarcza im narzędzi i informacji potrzebnych do szybszego i bardziej efektywnego rozwiązywania zgłoszeń, w szczególności incydentów i wniosków o usługę. Dostęp do aktualnej wiedzy eliminuje potrzebę wielokrotnego „wynajdywania koła na nowo” i skraca czas reakcji.

W kontekście ITIL, baza wiedzy jest kluczowym elementem procesu Zarządzania Wiedzą, który ma na celu upewnienie się, że właściwe informacje są dostępne dla właściwych osób, we właściwym czasie i we właściwej formie. To wspiera każdy etap cyklu życia usług, od strategii, przez projektowanie, wdrożenie, aż po ciągłe doskonalenie.

Strategia „Shift-Left”: Przesunięcie Rozwiązań Bliżej Klienta

Idea Shift-Left to strategiczne podejście, które polega na przeniesieniu możliwości rozwiązywania problemów jak najbliżej użytkownika końcowego. Zamiast eskalować każde zapytanie do wyższych poziomów wsparcia, dąży się do tego, aby klient mógł samodzielnie znaleźć rozwiązanie lub uzyskać pomoc na pierwszej linii wsparcia. Baza wiedzy jest sercem tej strategii.

Jak to działa w praktyce? Jeśli klient ma problem, zamiast dzwonić na infolinię, najpierw sprawdza bazę wiedzy. Jeśli tam znajdzie rozwiązanie, to problem jest rozwiązany natychmiast, bez obciążania agentów. Jeśli nie, to agent, który odbiera zgłoszenie, również korzysta z bazy wiedzy, aby szybko znaleźć odpowiedź. To nie tylko odciąża zespół wsparcia, ale także skraca czas oczekiwania na rozwiązanie dla klienta.

Role i Odpowiedzialności w Zarządzaniu Wiedzą

Efektywne zarządzanie wiedzą wymaga jasno określonych ról i odpowiedzialności. Nie jest to jednorazowy projekt, ale ciągły proces, który wymaga zaangażowania wielu stron:

• Właściciel Wiedzy (Knowledge Owner): Odpowiada za ogólną strategię zarządzania wiedzą, wyznacza cele i mierzy efektywność.
• Redaktorzy Wiedzy (Knowledge Editors/Authors): To eksperci merytoryczni, którzy tworzą, aktualizują i recenzują artykuły w bazie wiedzy. Mogą to być agenci wsparcia, specjaliści techniczni, a nawet użytkownicy biznesowi.
• Menedżer Bazy Wiedzy (Knowledge Base Manager): Odpowiada za utrzymanie struktury bazy, dba o spójność i jakość treści, a także zarządza procesami publikacji i archiwizacji.
• Użytkownicy: Zarówno klienci, jak i agenci, którzy aktywnie korzystają z bazy wiedzy i dostarczają informacje zwrotne.

Ważne jest, aby proces tworzenia i aktualizacji wiedzy był zintegrowany z codziennymi operacjami. Na przykład, po rozwiązaniu incydentu przez agenta, powinien on mieć możliwość łatwego udokumentowania rozwiązania w bazie wiedzy, aby inni mogli z niego skorzystać w przyszłości.

Mierzenie Efektywności Bazy Wiedzy

Aby upewnić się, że baza wiedzy spełnia swoje zadanie, niezbędne jest regularne mierzenie jej efektywności. Kluczowe wskaźniki (KPIs) obejmują:

• Współczynnik samoobsługi (Self-Service Rate): Procent zgłoszeń, które zostały rozwiązane przez klientów samodzielnie, bez interwencji agenta.
• Wskaźnik wykorzystania bazy wiedzy: Liczba wyświetleń artykułów, wyszukiwań i unikalnych użytkowników.
• Wskaźnik sukcesu wyszukiwania: Procent wyszukiwań, które zakończyły się znalezieniem odpowiedniego artykułu.
• Oceny artykułów: Opinie użytkowników na temat przydatności i kompletności artykułów (np. oceny gwiazdkowe, kciuki w górę/w dół).
• Czas rozwiązywania problemów przez agentów: Skrócenie średniego czasu rozwiązywania zgłoszeń po wdrożeniu lub usprawnieniu bazy wiedzy.
• Redukcja liczby zgłoszeń: Zmniejszenie ogólnej liczby zgłoszeń do działu wsparcia.

Regularna analiza tych wskaźników pozwala identyfikować luki w wiedzy, poprawiać jakość treści i optymalizować działanie bazy.

Integracja Jira Service Management i Confluence: Potężne Duo dla Zarządzania Wiedzą

Jira Service Management (JSM) i Confluence to narzędzia firmy Atlassian, które doskonale uzupełniają się w kontekście zarządzania wiedzą.

• Jira Service Management to platforma do zarządzania usługami IT (ITSM), która służy do obsługi zgłoszeń, zarządzania incydentami, problemami, wnioskami o usługę i zmianami.
• Confluence to narzędzie do współpracy i zarządzania treścią, które idealnie nadaje się do tworzenia i utrzymywania bazy wiedzy.

Ich integracja pozwala na płynne i efektywne działanie:

1. Łatwe tworzenie artykułów z JSM: Agenci mogą tworzyć artykuły bazy wiedzy bezpośrednio z poziomu zgłoszenia w JSM, dokumentując rozwiązania problemów, które mogą być przydatne w przyszłości. To eliminuje potrzebę przełączania się między narzędziami i zachęca do dzielenia się wiedzą.
2. Sugerowanie artykułów w Portalu Klienta JSM: Kiedy klient wprowadza swoje zapytanie w portalu samoobsługowym JSM, system automatycznie sugeruje powiązane artykuły z bazy wiedzy Confluence. To natychmiastowo prowadzi klienta do potencjalnego rozwiązania.
3. Wyszukiwanie wiedzy przez agentów: Agenci wsparcia mają dostęp do bazy wiedzy Confluence bezpośrednio z poziomu zgłoszenia w JSM, co pozwala im szybko znaleźć potrzebne informacje i skuteczniej rozwiązywać problemy.
4. Ustrukturyzowana wiedza w Confluence: Confluence oferuje potężne możliwości organizacji treści: strony, przestrzenie, tagi, indeksowanie i zaawansowane wyszukiwanie. Dzięki temu baza wiedzy jest uporządkowana i łatwa do nawigacji.
5. Historia wersji i kontrola dostępu: Confluence śledzi historię zmian w artykułach, co jest kluczowe dla zarządzania wersjami. Można również łatwo kontrolować, kto ma dostęp do poszczególnych sekcji bazy wiedzy.

Praktyczne wskazówki dotyczące implementacji i utrzymania bazy wiedzy z wykorzystaniem Confluence i JSM

• Zacznij od małych kroków: Nie próbuj budować całej bazy wiedzy od razu. Zacznij od najczęściej zadawanych pytań i najczęstszych problemów.
• Definiuj standardy treści: Ustal wytyczne dotyczące struktury, języka i formatowania artykułów, aby zapewnić spójność i czytelność.
• Zachęcaj do współpracy: Umożliw agentom łatwe tworzenie i aktualizowanie artykułów. Rozważ wdrożenie systemu nagród lub wyróżnień dla najbardziej aktywnych twórców wiedzy.
• Regularnie recenzuj i aktualizuj: Wiedza szybko się dezaktualizuje. Ustal cykliczne przeglądy artykułów, aby upewnić się, że są one wciąż trafne i kompletne.
• Wykorzystaj tagi i kategorie: Używaj tagów i kategorii w Confluence, aby ułatwić wyszukiwanie i nawigację.
• Monitoruj statystyki: Regularnie analizuj wskaźniki efektywności, aby identyfikować obszary do poprawy.
• Zbieraj informacje zwrotne: Zachęcaj użytkowników do oceniania artykułów i zgłaszania sugestii. To cenne źródło informacji o brakującej wiedzy lub problemach z istniejącymi treściami.

Typowe Pułapki w Zarządzaniu Bazą Wiedzy

Wdrożenie bazy wiedzy to jedno, ale jej efektywne utrzymanie to drugie. Istnieje kilka typowych pułapek, których należy unikać:

• Nieaktualna wiedza: To największy wróg bazy wiedzy. Jeśli klienci i agenci napotykają nieaktualne lub błędne informacje, szybko tracą zaufanie do bazy i przestają z niej korzystać. Kluczowe jest regularne aktualizowanie treści.
• Brak zaangażowania: Baza wiedzy nie będzie działać bez aktywnego udziału pracowników. Jeśli nie ma jasnych ról, odpowiedzialności i zachęt do dzielenia się wiedzą, baza szybko stanie się martwym projektem.
• Słaba jakość treści: Artykuły muszą być jasne, zwięzłe, zrozumiałe i kompletne. Jeśli są źle napisane, pełne żargonu lub nie dostarczają pełnych rozwiązań, nie spełnią swojej funkcji.
• Trudno dostępna wiedza: Nawet najlepsze artykuły są bezużyteczne, jeśli użytkownicy nie mogą ich znaleźć. Upewnij się, że struktura bazy jest intuicyjna, a funkcja wyszukiwania działa efektywnie.
• Brak promocji: Nie wystarczy stworzyć bazę wiedzy – trzeba ją promować wśród klientów i agentów. Poinformuj ich o jej istnieniu i zachęcaj do regularnego korzystania.
• Tylko dla agentów: Niektórzy popełniają błąd, tworząc bazę wiedzy wyłącznie dla wewnętrznego użytku. Pełen potencjał bazy tkwi w jej udostępnieniu klientom, co umożliwia samoobsługę.

Podsumowanie

Baza wiedzy, w kontekście ITIL i z wykorzystaniem narzędzi takich jak Jira Service Management i Confluence, to nie tylko trend, ale konieczność w dzisiejszym środowisku biznesowym. Umożliwia ona implementację strategii „Shift-Left”, wspiera samoobsługę klientów i znacząco zwiększa efektywność pracy agentów wsparcia.

Pamiętaj, że zarządzanie wiedzą to proces ciągły, wymagający zaangażowania, regularnych przeglądów i adaptacji. Inwestując w solidną bazę wiedzy, firmy nie tylko poprawiają satysfakcję klientów, ale także budują bardziej wydajne, spójne i odporne na wyzwania zespoły IT.

Artykuł Baza Wiedzy w ITIL i Jira Service Management: Klucz do Samoobsługi i Efektywności pochodzi z serwisu Mariusz Siek.

W świecie, gdzie każda minuta przestoju przekłada się na realne straty, priorytetem staje się efektywne zarządzanie incydentami.

Centralnym elementem tego procesu jest recepcja zgłoszenia. To pierwszy, krytyczny krok w obsłudze incydentu IT. Polega na rejestracji incydentu zgłoszonego przez użytkownika i wprowadzeniu go do systemu obsługi zgłoszeń. To coś więcej niż odebranie telefonu – to ustrukturyzowany proces, który zapewnia udokumentowanie i wiarygodność informacji o incydencie.

Czym jest recepcja zgłoszenia?

To moment, w którym użytkownik po raz pierwszy kontaktuje się z działem IT w związku z incydentem. Incydent przestaje być indywidualnym doświadczeniem i staje się oficjalnym elementem procedury naprawczej.

Recepcja zgłoszenia obejmuje:

• Rejestracja zgłoszenia: Zapisanie w systemie ITSM. Generowany jest unikalny numer zgłoszenia, umożliwiający śledzenie postępów.
• Zebranie kluczowych informacji: Pozyskanie od użytkownika niezbędnych danych, takich jak:
  • Identyfikacja zgłaszającego: Dane kontaktowe użytkownika.
  • Opis incydentu: Szczegółowe informacje o incydencie, dotkniętym systemie/aplikacji.
  • Czas wystąpienia: Kiedy incydent się pojawił?
  • Objawy: Komunikaty błędów, nietypowe zachowanie systemu.
  • Wpływ: Jak incydent wpływa na pracę użytkownika/działalność firmy (pilność).
• Potwierdzenie przyjęcia: Wysłanie automatycznego powiadomienia do zgłaszającego z numerem referencyjnym zgłoszenia. To buduje zaufanie i daje pewność, że sprawa jest w toku.
• Wstępna kategoryzacja: Określenie rodzaju incydentu (np. problem z siecią, błąd oprogramowania). Ułatwia to przypisanie zgłoszenia do właściwego zespołu wsparcia.
• Ustalenie priorytetu: Na podstawie pilności i wpływu na biznes, wstępne określenie priorytetu zgłoszenia.

Dlaczego to tak ważne?

Efektywna recepcja zgłoszenia to fundament sprawnego działania działu IT i zadowolenia użytkowników. Oto dlaczego:

• Formalizacja procesu: Strukturyzuje obsługę zgłoszeń, eliminując ryzyko zagubienia ich w natłoku komunikacji.
• Efektywna komunikacja: Potwierdzenie przyjęcia zgłoszenia informuje użytkownika, że jego incydent jest znany i podjęto działania.
• Sprawne zarządzanie zasobami: Ułatwia przypisywanie zgłoszeń do odpowiednich zespołów wsparcia i monitorowanie postępów.
• Dane do analizy i doskonalenia: Zebrane informacje dostarczają cennych danych do identyfikacji powtarzających się incydentów i optymalizacji procesów.

Recepcja zgłoszenia w świetle ITIL 4

Recepcja zgłoszenia idealnie wpisuje się w framework ITIL 4, a w szczególności w praktyki:

• Service Desk: Praktyka Service Desk jest centralnym punktem kontaktu między użytkownikami a dostawcą usług IT. Jak wspomniano w jednym z artykułów, większość organizacji zaczyna wdrażanie ITIL właśnie od Service Desk, a recepcja zgłoszenia jest jego kluczowym elementem.
• Zarządzanie incydentami: Celem tej praktyki jest jak najszybsze przywrócenie normalnego działania usługi. Recepcja zgłoszenia stanowi pierwszy krok w tym procesie. Zgodnie z wcześniejszym wpisem, Zarządzanie Incydentami i Service Desk to praktyki wdrażane najczęściej razem.
• Zarządzanie wnioskami o usługi: Recepcja zgłoszenia obejmuje również rejestrowanie wniosków o usługi (np. prośba o nowy sprzęt, dostęp do oprogramowania). Wnioski o usługi to kolejna popularna praktyka w organizacjach.

Jira Service Management (JSM) – wsparcie dla recepcji zgłoszeń

JSM oferuje szereg funkcjonalności wspierających proces recepcji zgłoszeń:

• Portale samoobsługowe: Użytkownicy mogą zgłaszać incydenty i wnioski o usługę za pośrednictwem intuicyjnych portali.
• Konfigurowalne formularze: Możliwość tworzenia formularzy zgłoszeniowych dostosowanych do różnych typów incydentów i wniosków o usługę.
• Automatyzacja przepływu pracy: Automatyczne przypisywanie zgłoszeń do odpowiednich zespołów na podstawie kategorii i priorytetu.
• Integracja z narzędziami komunikacji: Możliwość integracji z narzędziami takimi jak Slack czy Microsoft Teams w celu usprawnienia komunikacji.
• Raportowanie i analizy: Dostęp do raportów i analiz dotyczących efektywności procesu obsługi zgłoszeń.

Optymalizacja recepcji zgłoszeń

Aby recepcja zgłoszeń przebiegała jak najsprawniej, należy przeprowadzić:

• Szkolenie personelu: Zapewnij odpowiednie szkolenie dla osób odpowiedzialnych za recepcję zgłoszeń.
• Wielokanałowość: Umożliwiaj zgłaszanie incydentów różnymi kanałami (telefon, email, portal samoobsługowy).
• Automatyzacja procesów: Wykorzystaj automatyzację do przyspieszenia rejestracji i kategoryzacji zgłoszeń.
• Proste formularze: Twórz jasne i zwięzłe formularze zgłoszeniowe.
• Monitorowanie i doskonalenie: Regularnie analizuj dane i wdrażaj ulepszenia w procesie.

Podsumowanie

Recepcja zgłoszenia to fundament sprawnej obsługi incydentów w IT. To proces rejestracji incydentu, zebrania kluczowych informacji i zapewnienia użytkownikowi, że jego sprawa jest w toku. W połączeniu z narzędziami takimi jak Jira Service Management i praktykami ITIL, efektywna recepcja zgłoszeń pozwala na sprawne rozwiązywanie incydentów, minimalizowanie przestojów i zwiększanie satysfakcji użytkowników.

Artykuł Recepcja zgłoszenia w IT: Fundament sprawnej obsługi incydentów pochodzi z serwisu Mariusz Siek.

W pierwszej części artykułu opisałem kluczowe koncepcje praktyki Umożliwianie Zmian w ITIL 4. Teraz skupimy się na głębszym zrozumieniu strumieni wartości, procesów, ról, technologii oraz rekomendacji, które są kluczowe dla efektywnego wdrażania zmian w organizacji.

Strumienie wartości i procesy

Umożliwianie Zmian ma na celu zmaksymalizowanie liczby udanych zmian usług i produktów poprzez zapewnienie odpowiedniej oceny ryzyka, autoryzację zmian i zarządzanie harmonogramem zmian. Praktyka integruje się ze strumieniami wartości, aby zmiany były skuteczne, bezpieczne i terminowe.

Dwa kluczowe procesy w praktyce Umożliwianie Zmian to:

• Planowanie i Optymalizacja Umożliwiania Zmian: Ten proces obejmuje czynności związane z oceną, priorytetyzacją i planowaniem zmian.
• Zarządzanie Cyklem Życia Zmian: Kontrola nad całym cyklem życia zmian, od zgłoszenia do wdrożenia i weryfikacji.

Proces 1: Planowanie i Optymalizacja Umożliwiania Zmian

Kluczowe dane wejściowe:

• Rekordy (zapisy) zmian
• Aktualne modele zmian i standardowe procedury zmian
• Zasady i wymogi regulacyjne
• Informacje o konfiguracji usług
• Informacje o zasobach IT
• Katalog usług
• Umowy SLA z konsumentami i dostawcami/partnerami
• Wytyczne i ograniczenia finansowe
• Informacje o ryzyku
• Informacje o potencjale wykonawczym i wydajności
• Zasady i plany ciągłości

Kluczowe wyniki:

• Zdefiniowane role i obowiązki dla praktyki umożliwiania zmian
• Raport z analizy przeglądu zmian
• Inicjatywy udoskonalające
• Żądania zmian
• Zaktualizowane modele zmian
• Zaktualizowane standardowe procedury zmian

Ten proces polega na strategicznym podejściu do zmian, zapewniając, że są one wprowadzane w sposób przemyślany, minimalizując ryzyko i maksymalizując wartość.

Rys 1. Proces Planowania i optymalizacji umożliwiania zmian (źródło: publikacja ITIL 4 Umożliwianie zmian opracowana przez Peoplecert)

Działania procesu planowania i optymalizacji umożliwiania zmian:

• Inicjacja umożliwiania zmian (Change Enablement Initiation) : Zespół odpowiedzialny za wprowadzenie lub formalizację istniejących praktyk zarządzania usługami dokumentuje początkową wersję następujących elementów: rola zmiany w strumieniach wartości, istniejące procesy i procedury związane ze zmianą, role i obowiązki praktyki, poziomy i obowiązki w ramach uprawnień do zmiany, kryteria kategoryzacji i priorytetyzacji zmian, modele zmian.
• Przegląd i Planowanie Zmian (Change Review and Planning): Menedżer zmian wraz z właścicielami usług, przeprowadza przegląd dostępnych procesów, procedur i modeli zmiany. Identyfikuje możliwości optymalizacji modelu zmiany i standardowych procedur zmiany, w tym standaryzację nowych typów zmian.
• Inicjacja Doskonalenia Modelu i Procedury Zmian (Change Model and Procedure Improvement Initiation): Menedżer zmiany lub Koordynator zmian rejestruje inicjatywy udoskonalenia, które będą realizowane w ramach praktyki ciągłego doskonalenia lub inicjuje żądanie zmiany, jeśli modele zmiany i procedury są zawarte w zakresie praktyki umożliwiania zmian.
• Komunikacja Aktualizacji Modelu i Procedury Zmiany (Change Model and Procedure Update Communication: Jeśli model zmiany zostanie pomyślnie zaktualizowany, jest on przekazywany odpowiednim interesariuszom wraz z zaktualizowanymi procedurami i inną odpowiednią dokumentacją.

Proces 2: Zarządzanie Cyklem Życia Zmian

Kluczowe dane wejściowe:

• Żądania zmiany
• Modele zmian i standardowe procedury zmian
• Zasady i wymogi regulacyjne
• Informacje o konfiguracji i zasobach IT
• Katalog usług
• Umowy o poziomie usług (SLA) z konsumentami i dostawcami/partnerami
• Wytyczne i ograniczenia finansowe
• Informacje o ryzyku
• Informacje o potencjale wykonawczym i wydajności
• Zasady i plany ciągłości
• Zasady i plany bezpieczeństwa informacji

Kluczowe wyniki:

• Rekordy zmian
• Harmonogram zmian
• Raporty z przeglądu zmian
• Zmienione zasoby i usługi

Ten proces zapewnia kontrolę nad wszystkimi etapami zmiany, od jej zgłoszenia do pomyślnego wdrożenia i weryfikacji.

Rys 2. Proces Zarządzanie cyklem życia zmian (źródło: publikacja ITIL 4 Umożliwianie zmian opracowana przez Peoplecert)

Działania procesu zarządzania cyklu życia zmiany:

1. Zgłoszenie zmiany (Change Registration): Rejestracja propozycji zmiany w systemie.
2. Ocena zmiany (Change Assessment): Ocena wpływu, ryzyka i wartości zmiany.
3. Autoryzacja zmiany (Change Authorization): Uzyskanie formalnej zgody na wdrożenie zmiany.
4. Planowanie wdrożenia (Change Planning): Opracowanie szczegółowego planu wdrożenia.
5. Wdrożenie zmiany (Change Realization Control): Wprowadzenie zmiany w środowisku produkcyjnym.
6. Przegląd i Zamknięcie Zmiany (Change Review and Closure): Potwierdzenie, że zmiana została wdrożona poprawnie i działa zgodnie z oczekiwaniami. Zakończenie procesu zmiany i udokumentowanie wyników.

Organizacje i Ludzie

Praktyka Umożliwianie Zmian wymaga zaangażowania różnych osób i zespołów w organizacji. Dwie kluczowe role to:

Rola 1: Manager Zmiany (Change Manager)

• Cel: Zmaksymalizowanie liczby udanych zmian, minimalizacja ryzyka i zakłóceń.
• Odpowiedzialności:
  • Nadzorowanie całego procesu zmian.
  • Koordynacja działań różnych zespołów.
  • Ocena ryzyka i wpływu zmian.
  • Utrzymywanie harmonogramu zmian.
  • Raportowanie o postępach i wynikach zmian.
• Kompetencje:
  • Znajomość ITIL 4.
  • Umiejętność zarządzania ryzykiem.
  • Komunikacja i umiejętności interpersonalne.
  • Umiejętność rozwiązywania problemów.

Rola 2: Autoryzujący Zmianę (Change Authority)

• Cel: Podejmowanie decyzji dotyczących zatwierdzania zmian na podstawie oceny ryzyka i wpływu na usługi.
• Odpowiedzialności:
  • Ocena wniosków o zmiany.
  • Zatwierdzanie lub odrzucanie zmian.
  • Upewnianie się, że zmiany są zgodne z politykami i procedurami organizacji.
• Kompetencje:
  • Wiedza techniczna.
  • Zrozumienie biznesowe.
  • Umiejętność podejmowania decyzji.

Informacje i technologie

Technologia odgrywa kluczową rolę w automatyzacji i usprawnieniu procesu Umożliwiania Zmian.

Narzędzia wspierające praktykę Umożliwianie Zmian:

• Systemy zarządzania usługami IT (ITSM): Narzędzia takie jak ServiceNow, Jira Service Management, Freshservice, które automatyzują workflow zmian, umożliwiają śledzenie postępów i zarządzanie dokumentacją.
• Narzędzia do zarządzania konfiguracją (CMDB): Bazy danych konfiguracji (CMDB) pomagają zrozumieć relacje między różnymi elementami infrastruktury IT i ocenić wpływ zmian.
• Narzędzia do automatyzacji wdrożeń: Narzędzia takie jak Ansible, Chef, Puppet umożliwiają automatyzację wdrażania zmian, zmniejszając ryzyko błędów i przyspieszając proces.
• Narzędzia do monitoringu i alertów: Systemy monitoringu, takie jak Nagios, Zabbix, Datadog, pomagają monitorować wydajność i dostępność usług po wdrożeniu zmian.
• Narzędzia do zarządzania projektami: Narzędzia takie jak Microsoft Project, Asana, Trello pomagają w planowaniu i zarządzaniu złożonymi zmianami, które są realizowane jako projekty.

Partnerzy i Dostawcy

Partnerzy i dostawcy mogą odgrywać ważną rolę w praktyce Umożliwianie Zmian, szczególnie w obszarach, które wymagają specjalistycznej wiedzy lub zasobów.

Rola partnerów i dostawców:

• Dostarczanie oprogramowania i narzędzi: Dostawcy systemów ITSM, CMDB i narzędzi do automatyzacji.
• Usługi konsultingowe: Pomoc w projektowaniu i wdrażaniu procesów Umożliwiania Zmian.
• Wsparcie techniczne: Pomoc w rozwiązywaniu problemów związanych z wdrożeniem zmian.
• Outsourcing operacji: Przekazanie części zadań związanych z zarządzaniem zmianami zewnętrznemu dostawcy.

Rekomendacje dotyczące sukcesu praktyki

Aby praktyka Umożliwianie Zmian była skuteczna, warto wziąć pod uwagę następujące rekomendacje:

• Zrozumienie kontekstu biznesowego: Upewnij się, że zmiany są zgodne z celami biznesowymi organizacji.
• Komunikacja: Komunikuj zmiany wszystkim zainteresowanym stronom.
• Automatyzacja: Automatyzuj procesy, gdzie to możliwe, aby zmniejszyć ryzyko błędów i przyspieszyć wdrożenia.
• Ciągłe doskonalenie: Regularnie przeglądaj procesy Umożliwiania Zmian i wprowadzaj ulepszenia.
• Szkolenia: Zapewnij odpowiednie szkolenia dla wszystkich osób zaangażowanych w proces zmian.
• Kultura uczenia się: Stwórz środowisko, w którym błędy są traktowane jako okazja do nauki i doskonalenia.
• Wybór odpowiednich narzędzi: Wybór narzędzi, które integrują się z istniejącym środowiskiem i wspierają potrzeby organizacji.
• Monitorowanie metryk: Ustalenie metryk do monitorowania efektywności procesu zmian i identyfikowanie obszarów do poprawy.

Umożliwianie Zmian to kluczowa praktyka w ITIL 4, która pomaga organizacjom skutecznie zarządzać ryzykiem i wdrażać innowacje. Stosując się do powyższych rekomendacji, możesz zwiększyć prawdopodobieństwo sukcesu wdrożonych zmian i osiągnąć korzyści biznesowe.

Artykuł Prosto o ITIL – Praktyka Umożliwiania Zmian – Zaawansowane aspekty skutecznej transformacji – część 2 pochodzi z serwisu Mariusz Siek.

„Zmiany, zmiany, zmiany…” – słowa Stanisława Barei z kultowej komedii „Co mi zrobisz jak mnie złapiesz” idealnie oddają realia współczesnego IT. Zmiany są nieuniknione, a sposób, w jaki nimi zarządzamy, decyduje o naszym sukcesie lub porażce. W dzisiejszym artykule, opartym na mojej wiedzy i doświadczeniu, przyjrzymy się praktyce ITIL 4, która pomaga nam w efektywnym zarządzaniu zmianami – Umożliwianiu Zmian (Change Enablement). To klucz do zwinnego i bezpiecznego wprowadzania innowacji w Twojej organizacji. Jak już wspomniałem wcześniej przy okazji omawiania praktyki Service Desk, odpowiednie podejście do zmian to fundament stabilnego IT.

Cel Praktyki

Praktyka Umożliwiania Zmian w ITIL 4 ma na celu minimalizację ryzyka związanego z wprowadzaniem zmian w środowisku IT, przy jednoczesnym maksymalizowaniu korzyści biznesowych.

Chodzi o to, by zmiany były wprowadzane w sposób kontrolowany, z pełną świadomością potencjalnych konsekwencji, ale bez nadmiernego hamowania innowacji. Celem jest zapewnienie, że każda zmiana jest właściwie oceniona, zaplanowana i wdrożona, a także monitorowana po wdrożeniu, aby upewnić się, że przynosi oczekiwane rezultaty. Bez sprawnego Umożliwiania Zmian, jakakolwiek próba wdrożenia nowych technologii, czy optymalizacji istniejących procesów, może zakończyć się chaosem i kosztownymi błędami.

Koncepcje i Pojęcia Kluczowe

Zrozumienie podstawowych pojęć jest kluczowe dla skutecznego wdrożenia praktyki Umożliwiania Zmian:

• Zmiana (Change): Definiowana jako dodanie, modyfikacja lub usunięcie czegokolwiek, co może mieć bezpośredni lub pośredni wpływ na usługi IT. Przykłady to: aktualizacja oprogramowania, zmiana konfiguracji serwera, wdrożenie nowej aplikacji, modyfikacja procesu biznesowego wspieranego przez IT.
• Rodzaje Zmian:
  • Standardowe (Standard Changes): Zmiany o niskim ryzyku, dobrze udokumentowane i powtarzalne. Mają predefiniowaną procedurę wdrażania i są zatwierdzane automatycznie, bez konieczności udziału Change Advisory Board (CAB). Przykładem może być cykliczna aktualizacja oprogramowania antywirusowego lub restart serwera w celach konserwacyjnych.
  • Normalne (Normal Changes): Zmiany, które wymagają oceny ryzyka i zatwierdzenia przez Change Authority (zwykle CAB). Wymagają szczegółowego planowania i koordynacji, ponieważ mogą mieć istotny wpływ na usługi IT i biznes.
  • Pilna (Emergency Changes): Zmiany wprowadzane w trybie pilnym w celu naprawy awarii lub zapobieżenia poważnemu problemowi. Wymagają przyspieszonej procedury zatwierdzania i wdrożenia, ale nadal powinny być kontrolowane, aby uniknąć dodatkowych problemów.
• Change Authority: Osoba lub grupa odpowiedzialna za zatwierdzanie zmian. W przypadku zmian normalnych zazwyczaj jest to CAB, natomiast zmiany standardowe mogą być zatwierdzane automatycznie lub przez wyznaczonego właściciela zmiany. Kluczowe jest, aby Change Authority posiadało odpowiednią wiedzę i uprawnienia, aby podejmować trafne decyzje.
• Ryzyko (Risk): Potencjalne negatywne skutki związane z wprowadzeniem zmiany. Ocena ryzyka powinna uwzględniać prawdopodobieństwo wystąpienia problemu oraz jego wpływ na biznes. Należy brać pod uwagę takie aspekty jak: przerwy w dostępności usług, utrata danych, naruszenie bezpieczeństwa, negatywny wpływ na produktywność użytkowników.
• CAB (Change Advisory Board): Grupa doradcza, składająca się z przedstawicieli różnych działów IT i biznesu, której zadaniem jest ocena i zatwierdzanie zmian normalnych. CAB zapewnia, że zmiany są rozpatrywane z różnych perspektyw i że uwzględniane są wszystkie istotne czynniki.

Zakres Praktyki

Praktyka Umożliwiania Zmian obejmuje następujące działania:

• Identyfikacja Zmian: Rejestrowanie wszystkich proponowanych zmian w systemie zarządzania zmianami (np. w systemie ITSM). Każda zmiana powinna być odpowiednio udokumentowana, z uwzględnieniem celu zmiany, zakresu, planowanych działań, zasobów potrzebnych do wdrożenia oraz potencjalnych ryzyk.
• Ocena i Planowanie: Analiza wpływu zmiany na usługi IT (np. na dostępność, wydajność, bezpieczeństwo), ocena ryzyka, opracowanie planu wdrożenia i planu awaryjnego (rollback plan). Plan wdrożenia powinien zawierać szczegółowy harmonogram, listę zadań, przypisanie odpowiedzialności oraz kryteria sukcesu.
• Zatwierdzanie Zmian: Uzyskanie zgody od Change Authority na wdrożenie zmiany. Decyzja o zatwierdzeniu powinna być oparta na analizie ryzyka, ocenie wpływu na biznes oraz dostępności zasobów.
• Wdrożenie Zmian: Realizacja planu wdrożenia zgodnie z ustalonym harmonogramem. Podczas wdrożenia należy monitorować postęp prac, identyfikować potencjalne problemy i reagować na nie w sposób proaktywny.
• Monitorowanie i Raportowanie: Śledzenie postępu wdrożenia, identyfikacja problemów i raportowanie o statusie zmian do interesariuszy. Regularne raportowanie pozwala na utrzymanie kontroli nad procesem zmian i zapewnia transparentność.
• Przegląd Po Wdrożeniu (Post Implementation Review – PIR): Ocena skuteczności zmiany po jej wdrożeniu, identyfikacja lekcji wyciągniętych i wprowadzenie usprawnień do procesu zarządzania zmianami. PIR pozwala na ciągłe doskonalenie procesu zarządzania zmianami i minimalizację ryzyka w przyszłości.

Czynniki Sukcesu Praktyki

Aby praktyka Umożliwiania Zmian przynosiła oczekiwane rezultaty, należy zwrócić uwagę na następujące czynniki:

• Jasne i Zrozumiałe Zasady: Polityka zarządzania zmianami powinna być prosta, zrozumiała i dostępna dla wszystkich zainteresowanych stron. Powinna określać role i odpowiedzialności, procedury zatwierdzania zmian, kryteria oceny ryzyka oraz zasady komunikacji.
• Zaangażowanie Biznesu: Zmiany w IT powinny być wprowadzane w oparciu o potrzeby biznesowe i w ścisłej współpracy z użytkownikami. Reprezentanci biznesu powinni być zaangażowani w proces planowania i oceny zmian, aby upewnić się, że są one zgodne z celami strategicznymi organizacji.
• Automatyzacja: Wykorzystanie narzędzi do automatyzacji procesów zarządzania zmianami, takich jak systemy ITSM (ServiceNow, Jira Service Management, BMC Helix ITSM), może znacznie przyspieszyć i usprawnić proces. Automatyzacja pozwala na redukcję błędów, zwiększenie efektywności i poprawę jakości zarządzania zmianami.
• Komunikacja: Regularna i transparentna komunikacja z interesariuszami na temat planowanych i wdrażanych zmian jest kluczowa dla budowania zaufania i minimalizowania negatywnego wpływu na użytkowników. Komunikacja powinna obejmować informacje o celu zmiany, zakresie, harmonogramie, potencjalnych ryzykach oraz planowanych działaniach.

Kluczowe Metryki

Monitorowanie kluczowych metryk pozwala na ocenę skuteczności praktyki Umożliwiania Zmian i identyfikację obszarów do poprawy. Przykładowe metryki to:

• Procent Udanych Zmian: Odsetek zmian, które zostały wdrożone bez problemów i przyniosły oczekiwane rezultaty. Wysoki wskaźnik udanych zmian świadczy o efektywnym procesie planowania, oceny ryzyka i wdrożenia.
• Średni Czas Wdrożenia Zmiany: Czas potrzebny na wdrożenie zmiany od momentu zgłoszenia do momentu zakończenia wdrożenia. Krótki czas wdrożenia świadczy o sprawnym procesie zarządzania zmianami i szybkiej reakcji na potrzeby biznesowe.
• Liczba Nieudanych Zmian: Liczba zmian, które zakończyły się niepowodzeniem i wymagały wycofania. Wysoka liczba nieudanych zmian może wskazywać na problemy w procesie planowania, oceny ryzyka lub wdrożenia.
• Liczba Nagłych Zmian: Liczba zmian wprowadzanych w trybie pilnym, co może świadczyć o problemach w planowaniu i proaktywnym zarządzaniu zmianami. Wysoka liczba nagłych zmian może prowadzić do chaosu i zwiększonego ryzyka wystąpienia problemów.

To dopiero początek naszej podróży po świecie Umożliwiania Zmian. W drugiej części artykułu zagłębimy się w procesy, role, technologie i partnerów zaangażowanych w tę praktykę. Dowiesz się, jak skutecznie wdrożyć zarządzanie zmianami w Twojej organizacji, aby stały się one Twoim sprzymierzeńcem w drodze do sukcesu.

Artykuł Prosto o ITIL – Praktyka Umożliwiania Zmian – Jak Sprawnie Wprowadzać Nowości w Świecie IT? – część 1 pochodzi z serwisu Mariusz Siek.

W pierwszej części o Zarządzanie relacjami biznesowymi omówiłem kluczowe definicje, elementy, PSF i KPI praktyki. W drugiej części przedstawię strumienie wartości i procesy, role i odpowiedzialności, informacje i technologie, zaangażowanie partnerów i dostawców oraz rozwój umiejętności dla praktyki zarządzania relacjami biznesowymi.

Strumienie wartości i procesy

Praktyka Zarządzania relacjami biznesowymi składa się z dwóch procesów:

• Zarządzanie wspólnym podejściem do relacji biznesowych.
• Zarządzanie podróżami relacji biznesowej.

Zarządzanie wspólnym podejściem do relacji biznesowych

Kluczowe dane wejściowe:

• Strategia organizacji
• Ocena kultury organizacji i wzorców zachowań relacyjnych
• Informacje o interesariuszach
• Portfel usług
• Inicjatywy udoskonalające

Kluczowe wyniki:

• Mapy interesariuszy
• Analiza kultury
• Wymagania strategiczne
• Zasady relacji biznesowych
• Modele relacji biznesowych
• Materiały dotyczące planowania, szkoleń i podnoszenia świadomości
• Raport z przeglądu relacji biznesowych
• Inicjatywy dotyczące poprawy

Rys 1. Proces Zarządzanie wspólnym podejściem do relacji biznesowych (źródło: publikacja ITIL 4 Business Relationship Management opracowana przez Peoplecert)

Działania procesu Zarządzanie wspólnym podejściem do relacji biznesowych:

• Przeanalizuj kulturę, strategię i interesariuszy organizacji. Liderzy dostawcy usług, analizują strategie biznesowe i IT organizacji, kulturę organizacyjną i sposób, w jaki wspierają strategię. Liderzy analizują również pozycjonowanie dostawcy usług względem biznesu i kluczowych interesariuszy wewnętrznych i zewnętrznych. Powstałe raporty analityczne i mapy interesariuszy są omawiane z szerszym kierownictwem w celu potwierdzenia wyników i zwiększenia świadomości inicjatywy.
• Opracuj i uzgodnij kluczowe zasady relacji biznesowych. Liderzy i menedżerowie dostawcy usług, wspólnie z liderami biznesowymi i menedżerami, opracowują i uzgadniają kluczowe zasady relacji biznesowych dla organizacji. Zasady te definiują kluczowe cechy relacji z kluczowymi grupami interesariuszy biznesowych.
• Opracuj i uzgodnij modele relacji biznesowych dla kluczowych grup interesariuszy. Dla każdej kluczowej grupy interesariuszy opracowywany jest model relacji i uzgadniany przez menedżerów ds. relacji biznesowych dostawcy usług. Przykłady grup interesariuszy, dla których można opracować model relacji biznesowych, obejmują sponsorów, klientów, użytkowników wewnętrznych i użytkowników zewnętrznych.
• Osadź modele relacji biznesowych w strumieniach wartości usług. Uzgodnione zasady i modele są komunikowane i omawiane w całej organizacji. W zależności od używanego modelu, może to być zrobione jako formalne szkolenie (dla relacji z klientami zewnętrznymi i użytkownikami) lub wplecione w szersze programy świadomości kulturowej i rozwoju (aby zapewnić, że zasady BRM są przyjmowane w całej organizacji).
• Przejrzyj i dostosuj podejście i modele relacji biznesowych. Menedżerowie ds. relacji biznesowych monitorują i sprawdzają przyjęcie i skuteczność uzgodnionych zasad i modeli relacji. Odbywa się to na podstawie zdarzenia (incydentów, konfliktów lub kryzysów w relacjach) i interwału (zwykle rocznego). Uzyskane ustalenia i inicjatywy są wykorzystywane jako dane wejściowe do ciągłego doskonalenia.

Zarządzanie podróżami relacji biznesowej

Kluczowe dane wejściowe:

• Zasady i modele relacji biznesowych
• Materiały szkoleniowe i informacyjne
• Role i obowiązki
• Komunikacja z interesariuszami

Kluczowe wyniki:

• Wyciągnięte wnioski, inicjatywy poprawy
• Zapisy relacji według modelu

Rys 2. Proces Zarządzanie podróżami relacji biznesowych (źródło: publikacja ITIL 4 Business Relationship Management opracowana przez Peoplecert)

Działania procesu Zarządzanie podróżami relacji biznesowych:

• Identyfikuj interesariuszy i model relacji. Agent ds. relacji biznesowych (na przykład partner biznesowy, account manager lub service manager) kontaktuje się lub jest kontaktowany przez przedstawiciela obecnego lub potencjalnego klienta. Agent ds. relacji lub relationship manager ocenia klienta i identyfikuje interesariuszy oraz odpowiedni model relacji.
• Zweryfikuj i dostosuj model relacji do sytuacji. Menedżer ds. relacji biznesowych potwierdza lub wyznacza agenta ds. relacji na potrzeby podróży oraz potwierdza lub dostosowuje model relacji.
• Postępuj zgodnie z modelem relacji biznesowej. Wyznaczeni agenci ds. relacji biznesowych postępują zgodnie z modelem relacji w interakcjach z interesariuszami biznesowymi i pomagają innym członkom organizacji w komunikacji z biznesem.
• Zarządzaj wyjątkami. W przypadku wystąpienia konfliktów lub gdy model relacji okazuje się nieskuteczny, agent. relacji biznesowych oraz menedżer relacji biznesowych pomagają rozwiązać problem i, w razie potrzeby, sugerują aktualizację modelu relacji biznesowych.
• Przejrzyj relację. Członkowie zespołu zaangażowani w relacje z biznesem, agenci relacji i menedżerowie relacji biznesowych okresowo dokonują przeglądu relacji po zmianach i ważnych wydarzeniach, a także w przypadku zakończenia relacji.

Organizacje i ludzie

W praktyce występują dwie kluczowe role:

• Menedżer relacji biznesowych
• Agent relacji biznesowych

Menedżer relacji biznesowych jest odpowiedzialny za:

• Opracowywanie i utrzymywanie modeli relacji biznesowych
• Komunikowanie się, szkolenie i wspieranie agentów relacji biznesowych
• Przeglądanie relacji biznesowych
• Koordynowanie podróży relacji biznesowych
• Zarządzanie wyjątkami w podróżach relacji biznesowych.

Rolę menedżera relacji biznesowych może pełnić menedżer ds. produktów lub usług, lider IT (w mniejszych organizacjach może to być nawet CIO lub menedżer IT), partner biznesowy ds. IT lub menedżer ds. kont, lub może to być dedykowane stanowisko.

Agent relacji biznesowych jest odpowiedzialny za:

• Utrzymywanie zdrowych relacji z interesariuszami biznesowymi
• Przestrzeganie uzgodnionego modelu relacji biznesowych
• Koordynowanie bieżących interakcji między interesariuszami biznesowymi a członkami organizacji (na przykład agent obsługi klienta lub account menedżer może koordynować interakcje użytkowników lub klientów z innymi członkami i zespołami dostawcy usług za pośrednictwem strumienia wartości usług)
• Uczestnictwo w zarządzaniu wyjątkami od modeli relacji biznesowych
• Uczestnictwo w przeglądach relacji biznesowych.

Rola ta raczej nie będzie pełniona przez dedykowaną osobę; raczej będzie ona realizowana przez jedną z innych ról zaangażowanych w podróż obsługi interesariusza biznesowego.

Na przykład użytkownicy mogą wchodzić w interakcje z agentami pomocy technicznej, specjalistami ds. wsparcia technicznego lub inżynierami terenowymi, którzy są agentami relacji biznesowych w ścieżce użytkownika. Podobnie klienci prawdopodobnie będą wchodzić w interakcje z właścicielami i menedżerami produktów lub usług, account menedżerami lub partnerami biznesowymi, liderami IT, takimi jak CIO, lub analitykami biznesowymi.

Informacje i technologie

Korzyści wynikające z automatyzacji BRM.

Partnerzy i dostawcy

• Dostarczanie oprogramowania. Większość oprogramowania używanego do BRM jest współdzielona z innymi praktykami. Jednak niektóre narzędzia, takie jak narzędzia do przechwytywania i analizy doświadczeń oraz narzędzia ankietowe, mogą być nabywane i wykorzystywane wyłącznie do działań BRM. W takim przypadku menedżerowie relacji biznesowych powinni określić wymagania i współpracować z innymi zespołami i praktykami dostawcy usług, aby zapewnić, że wymagane narzędzia zostaną zakupione, wdrożone i wykorzystane w optymalny sposób.
• Wykonywanie działań BRM. Niektóre działania BRM mogą być w dużej mierze lub całkowicie wykonywane przez wyspecjalizowanego dostawcę. Są to zazwyczaj ankiety, pomiary satysfakcji i analizy. Zaangażowanie wyspecjalizowanego dostawcy pomaga zapewnić niezależną ocenę relacji biznesowych i zoptymalizować wykorzystanie zasobów dostawcy usług. Menedżerowie relacji biznesowych powinni upewnić się, że metody używane i raporty dostarczane przez dostawcę są istotne i spełniają uzgodnione podejście BRM. Ważne jest również, aby upewnić się, że dostęp dostawcy do danych organizacji jest zatwierdzony przez organizację i spełnia jej zasady bezpieczeństwa informacji.
• Konsultacje i doradztwo. Specjalistyczni dostawcy, którzy rozwinęli wiedzę specjalistyczną w zakresie zarządzania relacjami i zarządzania doświadczeniem, mogą pomóc w ustanowieniu i rozwijaniu praktyk, przyjęciu metod i technik (takich jak Gemba walk i VoC) oraz początkowym opracowaniu modeli relacji biznesowych. Podobnie jak w przypadku integracji usług, BRM nie może być całkowicie delegowane zewnętrznemu konsultantowi. Relacje między firmą a wewnętrznymi dostawcami usług muszą być zarządzane przez te dwie strony, a strony zewnętrzne jedynie pomagają i doradzają.

Podsumowanie najważniejszych zagadnień

• BRM służy jako „pomost” lub „tłumacz” między biznesem a IT i pomaga obu stronom ściślej współpracować, aż do momentu, w którym nie potrzebują już pomostu ani tłumacza. Ta konwergencja biznesu i IT jest kluczową cechą transformacji cyfrowej, co sprawia, że ​​BRM jest ważnym czynnikiem umożliwiającym tę transformację.
• BRM koncentruje się na relacjach z różnymi interesariuszami biznesowymi, zazwyczaj ze sponsorami, klientami i kluczowymi użytkownikami usług IT.
• Działania BRM powinny być zintegrowane z strumieniami wartości usług dostawcy usług, zapewniając płynne i efektywne podróże interesariuszy. BRM nie powinno być rozwijane w izolacji ani skupiać się wyłącznie na początkowym zaangażowaniu klientów.
• Istnieją dwie kluczowe role, które wykonują działania BRM: menedżerowie relacji biznesowych i agenci relacji biznesowych. Chociaż rola menedżera BRM może być dedykowanym stanowiskiem w organizacji, rola agenta jest zawsze połączona z innymi rolami w strumieniach wartości usług. Każdy członek dostawcy usług, który wchodzi w interakcję z interesariuszami biznesowymi, działa jako agent relacji i powinien przestrzegać uzgodnionych modeli relacji biznesowych.
• Modele relacji biznesowych definiują zasady interakcji z interesariuszami biznesowymi w kontekście ich podróży i strumieni wartości usług.
• Praktyka BRM dostawcy usług może i powinna skorzystać z automatyzacji. Istnieje wiele narzędzi programowych, które mogą być pomocne w BRM.
• Praktyka BRM często polega na partnerach i dostawcach dostawcy usług. Obejmuje to członków trzecich stron trzecich działających jako agenci relacji biznesowych w imieniu dostawcy usług, a także może obejmować delegowanie innych obowiązków związanych z BRM. Wymaga to starannego rozważenia zaangażowania stron trzecich i wpływu na relacje biznesowe. Własność relacji nigdy nie powinna być delegowana.
• Rozwój możliwości BRM powinien być częścią inicjatyw ciągłego doskonalenia dostawcy usług. Docelowy poziom możliwości BRM powinien być dostosowany do rodzaju relacji usługowej między firmą a dostawcą usług informatycznych; Zależy to również od skali i złożoności organizacji oraz od celów dotyczących skuteczności, wydajności, produktywności i zgodności BRM.

Artykuł Prosto o ITIL – Zarządzanie Relacjami Biznesowymi – część 2 pochodzi z serwisu Mariusz Siek.

Tematyka związana z zarządzaniem relacjami biznesowymi (Business Relationship Management – BRM), omawiana jest w ITIL w ramach szkolenia obejmującego rozszerzenia do ITIL. Nie jest to jedna z 34 praktyk ITIL ale czy na pewno? Jak zobaczycie ebook do BRM to składa się z bardzo podobnych rozdziałów jak pozostałe praktyki, opartych na czterech wymiarach zarządzania usługami. Przyjrzyjmy się bliżej co zawiera.

Cel

Celem zarządzania relacjami biznesowymi jest ustanowienie i pielęgnowanie powiązań między dostawcą usług a kluczowymi interesariuszami konsumentów usług na poziomie strategicznym i taktycznym. Obejmuje to identyfikację, analizę, monitorowanie i ciągłe doskonalenie relacji z interesariuszami biznesowymi.

Można więc powiedzieć, że BRM opiera się na relacji usługowej, która składa się z świadczenia usług, przyjmowania, konsumowania usług oraz zarządzania relacją usługową.

Kluczowi interesariusze

Kto jest „biznesem”, z którym trzeba budować i utrzymywać relacje?

Kluczowymi interesariuszami po stronie konsumentów usług czyli biznesu, są dobrze znane w ITIL trzy role: klient, użytkownik i sponsor. Klient definiuje wymagania i odpowiada za ich realizację, użytkownik korzysta z usług a sponsor autoryzuje koszty związane z usługą.

BRM w pierwszej kolejności skupia się na relacjach z klientami i sponsorami. To nie znaczy jednak, że pomija całkowicie użytkownika. Zrozumienie potrzeb, wymagań i doświadczenia użytkownika, ma również duże znaczenia w budowaniu relacji pomiędzy dostawca usług a „biznesem”, niezależnie czy biznes jest wewnątrz czy na zewnątrz organizacji.

Zakres

Zakres praktyki BRM obejmuje:

• Opracowywanie i promowanie podejścia do relacji między dostawcą usług a firmą w całej organizacji oraz integrowanie tego podejścia z kulturą organizacji
• Identyfikowanie interesariuszy będących konsumentami usług i zarządzanie relacjami z nimi
• Zapobieganie konfliktom i ich rozwiązywanie
• Monitorowanie i utrzymywanie efektywnych i zdrowych relacji usługowych

Relacja usługowa

Czym właściwie jest relacja usługowa?

Relacja usługowa to współpraca między dostawcą usług a konsumentem usług. Relacje usługowe obejmują świadczenie usług, konsumpcję usług i zarządzanie relacjami usługowymi.

Świadczenie usług to wszystkie działania wykonywane przez organizację w celu świadczenia usług i/lub dostarczania towarów. Świadczenie usług obejmuje:

• Zarządzanie zasobami dostawcy, skonfigurowanymi w celu dostarczania usług. Pamiętamy, że zasoby dostawcy to nie tylko rozwiązania informatyczne ale również ludzie, procesy, strumienie wartości, katalog usług, SLA itp.
• Zapewnianie dostępu do tych zasobów dla użytkowników, tak aby mogli skorzystać ze świadczonych im usług.
• Realizację uzgodnionych działań usługowych, czyli normalne wykorzystanie usługi, wnioski o usługi i wsparcie.
• Zarządzanie poziomem usług i ciągłe doskonalenie. Mówiąc najprościej dostawca usług i konsumenci podpisują umowę SLA, z której dostawca musi się wywiązać. Jeżeli nie dotrzymuje umowy SLA musi podejmować aktywności związane z ciągłym doskonaleniem.

Konsumpcja usług, to działania wykonywane przez organizację w celu konsumpcji usług i/lub nabycia towarów. Konsumpcja usług obejmuje:

• Zarządzanie zasobami konsumenta potrzebnymi do korzystania z usługi
• Działania usługowe wykonywane przez użytkowników, w tym wykorzystywanie zasobów dostawcy i żądanie realizacji działań usługowych.

Relacje usługowe są ustanawiane między dwiema lub większą liczbą organizacji w celu współtworzenia wartości. W relacji usługowej organizacje przyjmują role dostawców usług lub konsumentów usług. Te dwie role nie wykluczają się wzajemnie, a organizacje zazwyczaj zarówno świadczą, jak i konsumują kilka usług w dowolnym momencie.

Rodzaje relacji usługowej w odniesieniu do BRM

ITIL definiuje trzy rodzaje relacji usługowej: relację podstawową, relację kooperacyjną i partnerstwo.

Zakres BRM dla poszczególnych rodzajów relacji został przedstawiony poniżej.

Relacja podstawowa

• Zrozumieć wymagania biznesowe i oczekiwania dotyczące usług.
• Komunikować ofertę usług i potencjalną wartość usług.
• Monitorować i poprawiać zadowolenie interesariuszy.
• Uczestniczyć w zarządzaniu poważnymi awariami i powiązanymi ryzykami dla relacji.
• Wnosić wkład w ciągłe doskonalenie produktów, usług i strategii dostawcy usług.
• Ciągle ulepszać podejście do zarządzania relacjami.

Relacja kooperacyjna (wszystkie z relacji podstawowej, oraz dodatkowo)

• Zrozumieć rolę usług w działalności klienta.
• Pomagać sponsorom i klientom w tworzeniu i ocenie uzasadnienia biznesowego dla usług i opcji usług.
• Zrozumieć, omówić i stale ulepszać wartość biznesową usług.
• Pełnić rolę pomostu między klientem a zespołami ds. produktów i usług, komunikując przewidywane zmiany popytu; nowe i zmieniające się wymagania; informacje zwrotne; i możliwości ulepszeń.

Partnerstwo (wszystkie z relacji podstawowej i kooperacyjnej, oraz dodatkowo)

• Zrozumieć modele biznesowe i operacyjne konsumenta usług.
• Uczestniczyć w planowaniu biznesowym i sugerować usprawnienia w oparciu o możliwości dostawcy usług.
• Sugerować innowacje biznesowe oparte na usługach.
• Informować i napędzać rozwój produktów i usług dostawcy usług w oparciu o przewidywany i zaplanowany rozwój biznesu konsumenta usług.
• Pomagać konsumentowi usług w optymalizacji wykorzystania usług informatycznych.

Czynniki sukcesu praktyki

Chociaż nominalnie BRM nie jest to praktyką ITIL, to definiujemy dla niego czynniki sukcesu praktyki (Practice Success Factors – PSF), czyli złożony funkcjonalny komponent praktyki, który jest wymagany, aby praktyka spełniała swoje przeznaczenie, cel.

Dla zarządzania relacjami biznesowymi zostały zdefiniowane dwa czynniki sukcesu:

• Nawiązywanie i ciągłe doskonalenie efektywnego podejścia do relacji między dostawcą usług a biznesem (konsumentem). Podejście to opiera się na zestawie wartości i zasad przyjętych przez wszystkich w organizacji. Często wartości organizacji wyraźnie odnoszą się do takich pojęć, jak otwartość, współpraca, usuwanie winy i zapewnianie bezpieczeństwa psychologicznego.
• Zapewnienie efektywnych i zdrowych, ciągłych relacji między dostawcą usług a biznesem (konsumentem). Dostawca usług dąży do zapewnienia, że ​​sponsorzy, klienci i użytkownicy reprezentujący konsumentów usług są zadowoleni ze świadczonych usług i ze wspólnych relacji. BRM obejmuje techniki i narzędzia, które pomagają zrozumieć interesy interesariuszy i zapewnić, że ich potrzeby i oczekiwania są zarządzane i spełniane.

Kluczowe metryki

Skuteczność i wydajność BRM powinna być oceniana w kontekście strumieni wartości, do których praktyki się przyczyniają. Kontekst biznesu i strumieni wartości jest ważny przy definiowaniu, czy wydajność praktyki jest uważana za dobrą, czy nie.

Metryki są powiązane ze zdefiniowanymi czynnikami sukcesu praktyki i potwierdzają lub nie, że dany czynnik sukcesu został osiągnięty lub nie. Poniżej zdefiniowane kluczowe metryki dla zarządzania relacjami biznesowymi

PSF – Nawiązywanie i ciągłe doskonalenie efektywnego podejścia do relacji między dostawcą usług a biznesem

• Przyjęcie wspólnego podejścia do BRM jako części kultury organizacyjnej dostawcy usług.
• Satysfakcja kluczowych interesariuszy z podejścia dostawcy usług do BRM.
• Liczba i procent relacji zerwanych z powodu nieprzyjęcia i nieprzestrzegania uzgodnionego podejścia.

Zapewnienie efektywnych i zdrowych, ciągłych relacji między dostawcą usług a biznesem

PSF – Zapewnienie efektywnych i zdrowych, ciągłych relacji między dostawcą usług a biznesem

• Wizerunek dostawcy usług w biznesie.
• Satysfakcja kluczowych interesariuszy z relacji.
• Liczba i procent relacji zerwanych z powodu źle zaplanowanych działań w zakresie zarządzania relacjami.

Przedstawiłem najważniejsze koncepcje związane z zarządzaniem relacjami biznesowymi. W drugiej części artykułu opiszę strumienie wartości i procesy, organizacje i ludzie (role i odpowiedzialności), informacje i technologie, czyli narzędzia wspierające BRM, relacje z partnerami i dostawcami oraz rozwój możliwości związanych z zarządzaniem relacjami biznesowymi.

Artykuł Prosto o ITIL – Zarządzanie Relacjami Biznesowymi – część 1 pochodzi z serwisu Mariusz Siek.

W pierwszej części o praktyce Zarządzanie wnioskami o usługi omówiłem kluczowe definicje, elementy, PSF i KPI praktyki. W drugiej części przedstawię strumienie wartości i procesy, role i odpowiedzialności, informacje i technologie, zaangażowanie partnerów i dostawców oraz najważniejsze rekomendacje związane z praktyką Zarządzania wnioskami o usługi.

Strumienie wartości i procesy

Praktyka Zarządzania wnioskami o usługi składa się z dwóch procesów:

• Kontrola realizacji wniosków o usługi. Proces ten skupia się na przyjęciu wniosku od Uzytkownika, jego kategoryzacji i skierowaniu do realizacji.
• Przegląd wniosków o usługi i ich optymalizacja. Proces ten koncentruje się na ciągłym doskonaleniu modeli wniosków o usługi, w tym zarządzania nimi i ich wykonania. Rekomendowane jest wykonywanie tego procesu regularnie lub w odpowiedzi na wyniki ankiety przeprowadzonej wśród użytkowników.

Kontrola realizacji wniosków o usługi

Kluczowe dane wejściowe:

• Zapytania dotyczące wniosków o usługi
• Modele wniosków o usługi
• Umowy o gwarantowanym poziomie świadczenia usług
• Zapisy i raporty dotyczące działań związanych z realizacją

Kluczowe wyniki:

• Zrealizowane wnioski o usługi
• Zapisy i raporty dotyczące działań związanych z realizacją
• Badania zadowolenia użytkowników

Rys 1. Proces Kontroli realizacji wniosku o usługę (źródło: publikacja ITIL 4 Zarządzanie wnioskami o usługi opracowana przez Peoplecert)

Działania procesu kontroli realizacji wniosków o usługi:

• Kategoryzacja wniosku – Agent Service Desk sprawdza zapytanie od Użytkownika, w zakresie warunków wstępnych i uprawnień użytkownika oraz wybiera właściwy model wniosku o usługi.
• Inicjowanie i kontrola modelu wniosku o usługi – Agent Service Desk wybiera odpowiedni zespół wsparcia lub specjalistów, zgodnie z modelem wniosku o usługi. Zespół realizujący wniosek o usługi postępuje zgodnie z opracowanymi procedurami. Jeżeli wymagane są dodatkowe zatwierdzenia, uzyskiwane są one na podstawie obowiązujących procedur. Po zrealizowaniu wniosek o usługi kierowany jest do przeglądu.
• Doraźna kontrola realizacji – W przypadku wystąpienia niestandardowej pracy, nie opisanej w procedurze, można wykonać wniosek o usługi jako doraźny. W każdym przypadku trzeba podjąć decyzję czy robimy wyjątek czy odmawiamy realizacji. Pamiętajmy, że realizacja doraźna jest wyjątkiem a nie obowiązującą regułą. Po realizacji wniosku w sposób doraźny należy uaktualnić o ten przypadek model wniosku o usługi.
• Przegląd realizacji  – Po wykonaniu wniosku, następuje weryfikacja czy został poprawnie wykonany. Sposób weryfikacji opisany jest oczywiście w modelu wniosku o usługi. W ramach przeglądu realizacji można zebrać informację zwrotną od użytkowników, w tym jak są zadowoleni z wykonania wniosku.

Raporty i zapisy z przeglądu realizacji służą jako dane wejściowe do procesu przeglądu i optymalizacji wniosków o usługi.

Przegląd i optymalizacja wniosków o usługi

Kluczowe dane wejściowe:

• Aktualne modele wniosków o usługi
• Wyniki ankiety przeprowadzonej wśród użytkowników
• Powiązane zmiany i modele zmiany
• Polityki i wymogi regulacyjne
• Katalog usług
• Umowy o gwarantowanym poziomie świadczenia usług
• Informacje o zasobach IT
• CMDB
• Informacje o potencjale wykonawczym i wydajności

Kluczowe wyniki:

• Zaktualizowany model wniosku o usługi
• Zaktualizowane procedury wniosków o usługi i instrukcje robocze

Rys 2. Proces Przeglądu i optymalizacji wniosku o usługi (źródło: publikacja ITIL 4 Zarządzanie wnioskami o usługi opracowana przez Peoplecert)

Działania procesu przeglądu i optymalizacji wniosków o usługi:

• Zapisy wniosków o usługi i analiza raportów – Właściciel praktyki wniosków o usługi, wraz z właścicielami usług i innymi odpowiednimi interesariuszami, wykonuje przegląd wybranych wniosków o usługi i powiązanych metryk w okresie i/lub odpowiednich powtarzających się zmian w praktyce umożliwiania zmian. Identyfikują oni możliwości nowych modeli wniosków o usługi i/lub doskonalenie obecnych modeli wniosków o usługi.
• Rozpoczęcie doskonalenia modelu wniosku o usługi – Właściciel praktyki zgłasza inicjatywę doskonalenia, która następnie jest obsługiwana przez praktykę ciągłego doskonalenia, a jeżeli jest wdrażana to z wykorzystaniem praktyki umożliwiania zmian. Jeżeli weryfikacja wprowadzonej zmiany nie potwierdzi efektywnego działania modelu wniosku o usługę, jest ona przekazywana do dalszej analizy.
• Komunikacja aktualizacji modelu wniosku o usługi – Jeśli model wniosku o usługi zostanie pomyślnie zaktualizowany, informacje o nim są komunikowane odpowiednim interesariuszom.

Organizacje i ludzie

W praktyce Zarządzania wnioskami o usługi nie ma specyficznych ról związanych z tą praktyką. Rolę zgłaszającego wniosek o usługę może pełnić każdy użytkownik lub jego upoważniony przedstawiciel i nie wymaga ona specjalnych umiejętności lub kompetencji. Zadania związane z realizacją wniosków o usługę wykonują specjaliści techniczni, właściciele usług i pracownicy wsparcia użytkownika. Ważne jest jednak zapewnienie odpowiedniej współpracy oraz śledzenie wykonywania zadań.

Nie tworzy się dedykowanych struktur organizacyjnych do realizacji wniosków o usługi. Zazwyczaj te same struktury zespołów są wykorzystywane do zarządzania wnioskami o usługi i incydentami. Service desk działa jako początkowy punkt rejestracji, weryfikacji i działania lub eskalacji wniosków o usługi.

Informacje i technologie

Najczęściej wykorzystywane narzędzia automatyzacji dla praktyki Zarządzania wnioskami o usługi:

• Zarządzanie przepływem pracy i narzędzia do współpracy
  • Obsługa wniosków o usługi od inicjacji do realizacji i przeglądu
  • Projektowanie, komunikacja, zastosowanie i kontrola modeli wniosków o usługi
• Narzędzia do monitorowania i zarządzania zdarzeniami
  • Wsparcie wykonania i kontroli modelu wniosku o usługi
  • Wsparcie realizacji doraźnych wniosków
• Narzędzia do publikowania
  • Komunikacja nowych i udoskonalonych modeli wniosków o usługi
• Media społecznościowe
  • Komunikacja nowych i udoskonalonych modeli wniosków o usługi
• Narzędzia do analizy i raportowania
  • Pomiar i raportowanie praktyki
• Narzędzia do planowania i priorytetyzacji pracy
  • Planowanie i śledzenie inicjatyw w zakresie doskonalenia

Rekomendacje dotyczące automatyzacji zarządzania wnioskami o usługi:

• Projektowanie strumieni wartości
• Uwzględnienie modeli wniosków o usługi
• Uwzględnienie planowania siły roboczej i raportowania
• Wykorzystanie pomiaru i raportowania od samego początku
• Zapewnianie dostępności i wygody umiejętności samopomocy
• Rozważanie wykorzystania superużytkowników

Partnerzy i dostawcy

Partnerzy i dostawcy mogą wspierać praktykę zarządzania wnioskami o usługi w obszarach:

• Wykonywanie działań związanych z zarządzaniem wnioskami o usługi. Ze względu na powtarzalny charakter obsługi wniosków o usługi, niektóre działania mogą być w dużym zakresie lub całkowicie wykonywane przez dostawcę zewnętrznego. Pamiętać należy o efektywnej integracji  dostawców zewnętrznych z przepływami pracy oraz przestrzeganiu obowiązujących polityk. Wszelkie informacje dotyczące współpracy powinny być opisane w modelach wniosków o usługi.
• Dostarczanie narzędzi oprogramowania. ITIL zaleca wykorzystanie zintegrowanego narzędzia do zarządzania usługami, które między innymi obsłuży wnioski o usługę. Wymagania dotyczące narzędzia powinny być odpowiednio zebrane i uzgodnione pomiędzy różnymi właścicielami praktyk.
• Konsulting i doradztwo. Wyspecjalizowani dostawcy, którzy posiadają wiedzę w zakresie zarządzania wnioskami o usługi, mogą pomóc w utworzeniu i rozwoju praktyki, wdrożeniu metod i technik (takich jak automatyzacja) oraz wstępnym opracowaniu modeli wniosków o usługi.

Rekomendacje dotyczące sukcesu praktyki

• Koncentracja na wartości dla użytkowników
• Zapewnianie przejrzystych i przyjaznych dla użytkownika interfejsów i procedur
• Rozważenie monitorowania i zarządzania zdarzeniami związanymi z utrzymaniem ruchu
• Koncentracja na strumieniu wartości usługi
• Zaczęcie od najpopularniejszych wniosków o usługi
• Uwzględnienie rejestracji informacji zwrotnych we wszystkich modelach wniosków o usługi

Artykuł Prosto o ITIL – Praktyka Zarządzanie wnioskami o usługi – część 2 pochodzi z serwisu Mariusz Siek.

Praktyka zarządzania wnioskami o usługi, to kolejną najczęściej wykorzystywana w organizacjach, po Service Desk i Zarządzaniu Incydentami, praktyka ITIL. Nie ma chyba w tym żadnego zaskoczenia, bo wnioski o usługi, udostępniane są użytkownikom aby mogli zamawiać realizację działań, które są ściśle związane ze świadczonymi usługami. Zresztą, sam Service Desk, jako praktyka zajmuje się incydentami i wnioskami o usługę. Jak widać, zależności pomiędzy tymi trzema praktykami są mocne.

Cel

Celem praktyki zarządzanie wnioskami o usługi jest wspieranie uzgodnionej jakości usługi poprzez obsługę wszystkich wstępnie zdefiniowanych, inicjowanych przez użytkownika wniosków o usługi w sposób efektywny i przyjazny dla użytkownika.

Warto zwrócić uwagę, że wnioski o usługę może składać rola użytkownik a nie klient. ITIL jasno rozróżnia te dwie role, co nie znaczy, że jedna osoba nie może pełnić obu tych ról.

Użytkownik składając wniosek o usługę, może go wybrać z listy wcześniej zdefiniowanych działań oraz powinien wiedzieć kiedy jego wniosek zostanie zrealizowany.

Wniosek o usługę

Wniosek użytkownika lub upoważnionego przedstawiciela użytkownika inicjujący działanie związane z usługą, które zostało uzgodnione jako normalna część dostarczenia usługi.

Oprócz użytkownika, wniosek o usługę może złożyć jego upoważniony przedstawiciel, czyli np. kierownik, przełożony, menedżer i jest to normalna część świadczenia usługi, nie incydenty, nie problemy i nie zmiany.

Jakie najczęściej elementy obejmują wnioski o usługę? Są to:

• Wniosek o dostęp do zasobu, usługi lub oferty usług – chyba najczęściej występujący, tzw. Dostępy, czyli nadawanie, zmiana i odbieranie uprawnień dostępu do aplikacji, zasobów, usług.
• Żądanie inicjujące działanie związane z usługą (wykonywane przez dostawcę usług lub wspólnie z użytkownikiem) – np. zamówienie raportu, wymiana toneru w drukarce, zwiększenie quoty skrzynki email.
• Zapytanie o informacje – np. w jakich godzinach pracuje biuro, jak można skorzystać z samochodu służbowego, jak zarezerwować środowisko do wykonania testów
• Informacje zwrotne, pochwały lub skargi – pewnie częściej skargi niż pochwały

Co do zasady wnioski o usługę nie wymagają autoryzacji (akceptacji). Są jednak dwa wyjątki. Wnioski dotyczące zagadnień bezpieczeństwa, np. nadania uprawnień do aplikacji, muszą być zaakceptowane przez przełożonego lub kogoś z zespołu ds. bezpieczeństwa informacji, zanim będą mogły być zrealizowane. Podobnie jest z wnioskami o usługę, które dotyczą poniesienia kosztów finansowych. Tutaj również wymagana jest akceptacja np. dyrektora finansowego, przed realizacją wniosku.

Ponieważ wnioski o usługę są ustandaryzowane, czyli dobrze znane i sprawdzone, można je również częściowo lub w pełni zautomatyzować.

Wnioski o usługę i sposób ich realizacji mogą mieć wpływ na doświadczenie użytkownika i w konsekwencji na jego satysfakcję lub jej brak.

Typowy strumień wartości związany z realizacją wniosku o usługi może obejmować, następujące praktyki i działania:

• service desk: przetwarzanie zapytania użytkownika
• zarządzanie wnioskami o usługi: kierowanie i prowadzenie realizacji zgłoszeń
• zarządzanie infrastrukturą i platformą: wykonywanie niezbędnych operacji technicznych
• zarządzanie wydaniami: udostępnianie komponentów usługi użytkownikom
• umożliwienie zmian: koordynacja niezbędnych zmian
• zarządzanie bezpieczeństwem informacji: dostarczanie lub modyfikowanie dostępu.

Model wniosku o usługi

Powtarzalne, predefiniowane podejście do realizacji określonego rodzaju wniosków o usługi.

Ponieważ aktywności wykonywane w ramach wniosków o usługę są powtarzalne, możemy opracować predefiniowane podejścia (modele) do ich realizacji. Model wniosku o usługę zawiera:

• procedury i przepływy pracy, w tym możliwe opcje i decyzje
• role i odpowiedzialne zespoły (zazwyczaj jako macierz RACI)
• automatyzacja i używane narzędzia
• podmioty zewnętrzne uczestniczące w umowach i wspierające je.

Katalog wniosków o usługi

Widok katalogu usług, dostarczający szczegółowych informacji na temat wniosków o usługi dotyczących istniejących i nowych usług, który jest udostępniany użytkownikowi.

Wszystkie wnioski o usługę przechowywane są w katalogu wniosków o usługę, który jest widokiem katalogu usług. Należy pamiętać, że wsad merytoryczny do katalogu wniosków o usługę opracowuje praktyka zarządzania wnioskami o usługę ale za ich umieszczenie w katalogu usług, odpowiada praktyka zarządzania katalogiem usług.

Zakres

Zakres praktyki zarządzanie wnioskami o usługi obejmuje:

• zarządzanie modelami wniosków o usługi
• przetwarzanie wniosków o usługi składanych przez użytkowników lub ich przedstawicieli
• zarządzanie realizacją wniosków o usługi zgodnie z uzgodnionymi modelami
• przegląd i ciągłe doskonalenie wydajności przetwarzania i realizacji zgłoszeń

Czynniki sukcesu praktyki

Dla każdej praktyki ITIL definiuje czynniki sukcesu (Practice Success Factors – PSF), czyli złożony funkcjonalny komponent praktyki, który jest wymagany, aby praktyka spełniała swoje przeznaczenie, cel.

Dla praktyki zarządzanie wnioskami o usługę zostały zdefiniowane dwa czynniki sukcesu:

• Zapewnianie optymalizacji procedur realizacji wniosków o usługi dla wszystkich usług. Ważne jest, aby identyfikować, dokumentować i testować procedury realizacji wniosków o usługi oraz przydzielać odpowiedzialność za działania. Procedury realizacji wniosków o usługi powinny podlegać ciągłemu doskonaleniu w oparciu o monitorowanie wydajności realizacji i satysfakcji użytkowników.
• Zapewnianie, że wszystkie wnioski o usługi są realizowane zgodnie z uzgodnionymi procedurami i w sposób satysfakcjonujący użytkownika. Procedury realizacji wniosków o usługę powinny być zoptymalizowanie i udokumentowane, wtedy będzie zapewnione, że są łatwe do planowania i realizacji.

Kluczowe metryki

Skuteczność i wydajność praktyk ITIL powinna być oceniana w kontekście strumieni wartości, do których praktyki się przyczyniają. Kontekst biznesu i strumieni wartości jest ważny przy definiowaniu, czy wydajność praktyki jest uważana za dobrą, czy nie.

Metryki są powiązane ze zdefiniowanymi czynnikami sukcesu praktyki i potwierdzają lub nie, że dany czynnik sukcesu został osiągnięty lub nie. Poniżej zdefiniowane kluczowe metryki dla praktyki zarządzania wnioskami o usługę

• PSF – Zapewnianie optymalizacji procedur realizacji wniosków o usługi dla wszystkich usług
  • Kompletność katalogu wniosków o usługi; liczba i procent wniosków o usługi, które nie są wspierane procedurami realizacji
  • Liczba i odsetek wniosków o usługi, które nie mogły zostać zrealizowane zgodnie z uzgodnioną procedurą z powodu błędów/niedociągnięć w procedurze
  • Zadowolenie członków zespołu realizujących wnioski zgodnie z dostarczanymi instrukcjami
  • Średni czas i koszt potrzebny do realizacji wniosków (według typów/modeli)
  • Odsetek wniosków o usługi z całkowicie lub w dużej mierze zautomatyzowaną realizacją (liczba, odsetek w katalogu, odsetek w całkowitej liczbie i czas realizacji)
• PSF – Zapewnianie, że wszystkie wnioski o usługi są realizowane zgodnie z uzgodnionymi procedurami i w sposób satysfakcjonujący użytkownika
  • Liczba i odsetek wniosków zrealizowanych zgodnie z umową SLA
  • Wpływ incydentów spowodowanych nieprawidłową realizacją wniosków o usługi
  • Zadowolenie użytkowników z realizacji wniosków
  • Liczba i odsetek zrealizowanych wniosków z odchyleniami od uzgodnionych procedur

Przedstawiłem najważniejsze koncepcje związane z praktyką zarządzanie wnioskami o usługę. W drugiej części artykułu opiszę strumienie wartości i procesy, organizacje i ludzie (role i odpowiedzialności), informacje i technologie, czyli narzędzia wspierające praktykę, relacje z partnerami i dostawcami oraz rekomendacje związane z osiągnięciem sukcesu przez praktykę.

Artykuł Prosto o ITIL – Praktyka Zarządzanie wnioskami o usługi – część 1 pochodzi z serwisu Mariusz Siek.

W pierwszej części o praktyce Zarządzanie Incydentami omówiłem kluczowe definicje, elementy, PSF i KPI praktyki. W drugiej części przedstawię strumienie wartości i procesy, role i odpowiedzialności, informacje i technologie, zaangażowanie partnerów i dostawców oraz najważniejsze rekomendacje związane z praktyką Zarządzania Incydentami.

Strumienie wartości i procesy

Praktyka Zarządzania Incydentami składa się z dwóch procesów:

• Obsługa i rozwiązanie incydentów. Proces ten koncentruje się na obsłudze i rozwiązaniu poszczególnych incydentów, od ich wykrycia do zamknięcia.
• Okresowy przegląd incydentów. Proces ten zapewnia nabyte doświadczenia z obsługi i rozwiązania incydentów oraz ciągłe doskonalenie podejść do zarządzania incydentami.

Obsługa i rozwiązanie incydentów

Kluczowe dane wejściowe:

• Zapytania użytkowników
• Monitorowanie i dane dotyczące zdarzeń
• Zapytania użytkowników
• Informacja o konfiguracji usług
• Informacje o zasobach IT
• Katalog usług
• Umowy SLA z korzystającymi i dostawcami/partnerami
• Informacje o potencjale wykonawczym i wydajności
• Polityki i plany ciągłości działalności
• Polityka i plany bezpieczeństwa informacji
• Zapisy problemu
• Baza wiedzy

Kluczowe wyniki:

• Zapisy incydentu
• Komunikacje dotyczące statusu incydentu
• Wnioski o zbadanie problemu
• Wnioski o zmianę
• Aktualizacje bazy wiedzy
• Przywrócone elementy konfiguracji i usługi

Rys 1. Proces Obsługi i rozwiązania incydentu (źródło: książka ITIL 4 Zarządzanie Incydentami opracowana przez Peoplecert)

Działania procesu obsługi i rozwiązania incydentu:

• Wykrywanie incydentu – Incydent może zostać wykryty przez Użytkownika lub system monitorowania jako zdarzenie. Użytkownik zgłasza incydent do Service Desk za pomocą uzgodnionych kanałów komunikacji. Agent service desk wykonuje wstępną klasyfikację zapytania użytkownika, potwierdzając, że zgłoszenie faktycznie dotyczy incydentu.
• Rejestrowanie incydentu – Agent service desk rejestruje incydent, dodając do zapisu incydentu wszystkie dostępne dane. Im więcej wartościowych danych zostanie zebranych tym łatwiejsza będzie diagnoza incydentu.
• Klasyfikacja incydentu – Agent service desk określa kategorię incydent, czyli do jakiej grupy wsparcia ma trafić incydent i priorytet incydentu, czyli jak szybko incydent ma zostać rozwiązany.
• Diagnoza incydentu –  Jeżeli rozwiązanie jest dostępne w bazie wiedzy, agent SD rozwiązuje incydent. Jeżeli nie ma rozwiązania incydentu w bazie wiedzy, odpowiedni zespół wsparcia wykonuje diagnozę w celu znalezienia rozwiązania incydentu. W diagnozie incydentu, praktykę Zarzadzania Incydentami może wspierać praktyka zarządzania problemami.
• Rozwiązanie incydentu – Po znalezieniu rozwiązania odpowiednie zespoły wsparcia stosują rozwiązanie, pracując sekwencyjnie lub równolegle. Rozwiązanie incydentu może wymagać zainicjowania zmiany. Jeśli rozwiązanie nie działa, wykonywana jest dodatkowa diagnoza.
• Zamknięcie incydent – Po potwierdzeniu przez użytkownika rozwiązania incydentu może zostać on zamknięty. Jeżeli użytkownik nie potwierdza skutecznego rozwiązania to incydent trafia ponownie do diagnozy.

Okresowy przegląd incydent

Proces ten koncentruje się na ciągłym doskonaleniu praktyki zarządzanie incydentami, modeli incydentów i procedur obsługi incydentów. Jest on wykonywany regularnie lub wyzwalany przez raporty dotyczące incydentów podkreślające nieefektywność i inne szanse na doskonalenie. Regularne przeglądy mogą odbywać się co dwa do trzech miesięcy lub częściej, zależnie od skuteczności istniejących modeli i procedur

Kluczowe dane wejściowe:

• Aktualne modele incydentów i procedury Zapisy incydentów Raporty dotyczące incydentów
• Polityki i wymogi regulacyjne
• Informacje o konfiguracji Informacje o zasobach IT
• Umowy SLA z korzystającymi i dostawcami/partnerami
• Informacje o potencjale wykonawczym i wydajności,
• Polityki i plany ciągłości działalności
• Polityki i plany bezpieczeństwa

Kluczowe wyniki:

• Zaktualizowane modele incydentów
• Zaktualizowane procedury obsługi incydentów
• Zapisy incydentu
• Komunikacja na temat zaktualizowanych modeli i procedur dotyczących incydentów
• Wnioski o zmianę Inicjatywy doskonalenia Raporty z przeglądów incydentu

Rys 2. Proces Okresowy przegląd incydentu (źródło: książka ITIL 4 Zarządzanie Incydentami opracowana przez Peoplecert)

Działania procesu Okresowego przeglądu incydentu:

• Przegląd incydentu i analiza zapisów dotyczących incydentu – Kierownik ds. incydentów, wraz z właścicielami usług i innymi odpowiednimi interesariuszami, wykonuje przegląd wybranych incydentów, takich jak poważne incydenty, incydenty nierozwiązane w określonym czasie lub wszystkie incydenty w określonym czasie. Identyfikują oni szanse na optymalizację modelu incydentów i procedur obsługi incydentów, w tym automatyzację przetwarzania i rozwiązania incydentu.
• Rozpoczęcie doskonalenia modelu incydentu – Kierownik ds. incydentów rejestruje inicjatywy doskonalenia, które mają być wprowadzane w życie z udziałem praktyki ciągłego doskonalenia lub inicjuje wniosek o zmianę
• Komunikacja dotycząca aktualizacji modelu incydentu – Jeśli model incydentu zostanie pomyślnie zaktualizowany, następuje komunikacja z odpowiednimi interesariuszami. Zazwyczaj jest to wykonywane przez osobę zarządzającą incydentem i/lub właściciela usługi albo zasobu.

Organizacje i ludzie

W praktyce Zarządzania Incydentami mamy dwie role: Kierownik/Menedżer ds. incydentów oraz Kierownik/Menedżer ds. poważnych incydentów Odpowiedzialności poszczególnych ról zostały opisanie poniżej.

Kierownik/Menedżer ds. incydentów odpowiada za:

• Koordynację obsługi incydentów w organizacji lub w określonym obszarze, takim jak terytorium, produkt lub technologia, zależnie od projektowania organizacyjnego
• Koordynowanie pracy ręcznej z incydentami, zwłaszcza tymi obejmującymi wiele zespołów
• Monitorowanie i przegląd pracy zespołów zajmujących się obsługą i rozwiązaniem incydentów
• Zapewnianie wystarczającej świadomości o incydentach i ich statusie w całej organizacji
• Przeprowadzanie regularnych przeglądów incydentów i inicjowanie doskonalenia praktyki zarządzanie incydentami, modeli incydentów i procedur obsługi incydentów
• Rozwój wiedzy organizacji w zakresie procesów i metod praktyki zarządzanie incydentami.

Kierownik/Menedżer ds. poważnych incydentów (Major Incident Manager), ma podobny zakres obowiązków jak Kierownik/Menedżer ds. incydentów tylko zajmuje się wyłącznie poważnymi incydentami.

W obsłudze incydentów dobrze korzystać z kultury nieobwiniania, tak by nie szukać winnych incydentów aby ich ukarać ale znajdować trwałe rozwiązania incydentów i przyczyny źródłowe problemów. Zespoły uczestniczące w rozwiązywaniu incydentów powinny ciągle podnosić swoje kompetencje i dzielić się zdobytą wiedzą z innymi aby zwiększać skuteczność rozwiązywania incydentów.

Informacje i technologie

Najczęściej wykorzystywane narzędzia automatyzacji dla praktyki Zarządzania Incydentami:

• Narzędzia do monitorowania i zarządzania zdarzeniami
  • Wykrywanie incydentów
  • Analiza trendów i zdarzeń podczas diagnozowania incydentów
  • Potwierdzenie rozwiązania incydentu
• Narzędzia do zarządzania przepływem pracy i współpracy
  • Zarządzanie cyklem życia incydentów
  • Wsparcie i automatyzacja modeli incydentów
  • Komunikacja między specjalistami zaangażowanymi w obsługę i rozwiązanie incydentów
  • Integracja praktyk ze strumieniami wartości usług
• Narzędzia do zarządzania wiedzą
  • Klasyfikacja i przydział incydentów, identyfikacja znanych rozwiązań incydentów
• Narzędzia do zarządzania konfiguracją usług
  • Klasyfikacja i diagnoza incydentów
• Narzędzia do klasyfikacji i analizy, w tym wspomagane uczeniem maszynowym (Machine Learning)
  • Klasyfikacja i analiza incydentów
• Zdalna administracja, diagnoza, wdrożenie i inne narzędzia do zarządzania infrastrukturą i oprogramowaniem
  • Diagnoza i rozwiązanie incydentów
• Narzędzia do planowania i priorytetyzacji pracy
  • Planowanie i śledzenie inicjatyw w zakresie doskonalenia
• Narzędzia do analizy i raportowania
  • Pomiar i raportowanie praktyki
• Narzędzia ankietowe
  • Zbieranie informacji zwrotnych w celu doskonalenia praktyki

Rekomendacje dotyczące automatyzacji zarządzania incydentami:

• Automatyzacja strumienia wartości
• Zezwalanie na różne przepływy pracy w przypadku incydentów inicjowanych przez użytkowników i zdarzenia
• Niekomplikowanie nadmiernie przepływów pracy i reguł biznesowych
• Zwracanie uwagi na pomiary i raportowanie od samego początku
• Zapewnienie odpowiedniej komunikacji
• Wykorzystanie umiejętności uczenia maszynowego

Partnerzy i dostawcy

Partnerzy i dostawcy mogą wspierać praktykę zarządzania incydentami w obszarach:

• Wykonywanie działań procesów, w szczególności diagnozowanie i rozwiązanie incydentu. Ważne jest zapewnienie efektywnej integracji podmiotów zewnętrznych z przepływami pracy związanymi z incydentami i wymianą informacji, a także przestrzeganie przez nie odpowiednich polityk. Model incydentów określają w jaki sposób strony trzecie uczestniczą w obsłudze incydentów. Dobrze jest również zapewnić jasne i zrozumiałe kanały komunikacji.
• Dostarczanie narzędzi oprogramowania. Dostawcy zewnętrzy zapewniają narzędzia klasy ITSM, które są wykorzystywane również przez inne praktyki. Najlepiej jakby to było zintegrowane narzędzie do zarządzania usługami.
• Konsulting i doradztwo. Wyspecjalizowani dostawcy, którzy zdobyli wiedzę w zakresie zarządzania incydentami, mogą pomóc w ustanowieniu i rozwoju praktyk, przyjęciu metod i technik oraz wstępnym opracowaniu modeli incydentów.

Rekomendacje dotyczące sukcesu praktyki

• Spójrz na incydenty z perspektywy korzystającego z usług
• Gromadzenie i ponowne wykorzystywanie danych wspierające rozwiązywanie incydentów
• Zrozumienie, zarządzanie i doskonalenie strumienia wartości rozwiązania incydentów, a nie tylko praktyki zarządzanie incydentami
• Rozwijaj praktykę w sposób ciągły, ale nie komplikuj jej nadmiernie
• Stosuj odpowiednie techniki w przypadku złożonych incydentów
• Pomiar praktyki i wytworzenie regularnych raportów i tablic wskaźników dla interesariuszy

Artykuł Prosto o ITIL – Praktyka Zarządzanie Incydentami – część 2 pochodzi z serwisu Mariusz Siek.