Klasyfikacja incydentów dla płynnego działania i współpracy SaaS

Jeśli sam prowadzisz firmę, na przykład biznes online, prawdopodobnie zauważyłeś, że klasyfikacja incydentów bardzo pomaga. Nie ma znaczenia, czy używasz własnego systemu klasyfikacji incydentów, czy narzędzi zewnętrznych. Zasadniczo klasyfikacja incydentów pozwala wybrać kwestie wymagające natychmiastowej uwagi w stosunku do tych, które mogą poczekać. Zbieranie takich elementów podczas sprintu nie jest tak naprawdę zgodne z czystym Scrumem, ale może być zgodne z innymi zwinnymi metodologiami, takimi jak Kanban. Z tego powodu idealną konfiguracją jest sytuacja, w której zespół reagowania na incydenty jest całkowicie oddzielony od zespołu programistów. Jeśli tak nie jest, możesz być zmuszony do użycia raczej Kanbana lub Scrumbana zamiast czystego Scruma, aby uruchomić zarówno prawidłowe zarządzanie incydentami, jak i rozwój jednocześnie przez ten sam zespół.

Najpierw definicje incydentów

Niezależnie od tego, którego aspektu szukasz w tym artykule – czy jesteś kimś, kto chce podpisać umowę SLA, czy chcesz ustalić, jak szybko software house powinien reagować na incydenty, czy też potrzebujesz wprowadzić pewną standaryzację do swojej firmy wewnętrznie – pierwszą rzeczą, której potrzebujesz, są definicje. Moim zdaniem w minimalnej konfiguracji definicje powinny zawierać następujące elementy:

1. Krótki tag dla definicji opisujący jej pilność
2. Długi opis wpływu problemu na system, aby można go było zaliczyć do kategorii definicji
3. Oczekiwany czas rozwiązania – w jakim czasie problem powinien zostać rozwiązany na produkcji

Ale byłoby to bardziej kompletne, gdybyś dodał trochę smaku do tego aspektu, na przykład:

1. Przykłady dla każdego tagu – aby lepiej zrozumieć definicję
2. Oczekiwany czas pierwszej odpowiedzi – to nie jest rozwiązanie, ale wskazanie, że „pracujemy nad tym” lub „ponieważ jest to kwestia bezpieczeństwa, tymczasowo wyłączyliśmy system”
3. Zasady eskalacji – jeśli incydent jest błędnie sklasyfikowany, co musi się stać, aby eskalować go na wyższy poziom
4. Podstawowy kanał komunikacji
5. Kanał awaryjny komunikacji – jeśli nic się nie dzieje po „oczekiwanym czasie pierwszej reakcji”, gdzie zadzwonić

Typowa tabela definicji może wyglądać następująco:

.

.

.

Teraz, gdy mamy już definicje incydentów, możemy przejść do przypadków użycia.

Przypadki użycia dla definicji incydentów według firm

Jestem właścicielem firmy współpracującym z Software House

Jeśli jesteś właścicielem firmy, a software house dostarcza Ci jakieś oprogramowanie, to Twoi użytkownicy w pewnym momencie napotkają na jakieś problemy. W takich przypadkach oczekiwałbyś, że software house będzie działał szybko i niezawodnie w zależności od tego, jak ważny jest problem, tak aby zakłócenia w bieżącym sprincie były minimalne. Dlatego też przeszacowanie poziomu incydentów przyniesie efekt przeciwny do zamierzonego i spowoduje jedynie obniżenie priorytetu zgłoszenia.

Z drugiej strony, niedocenianie znaczenia problemu również nie jest dobre. Na przykład, jeśli widzisz błąd bezpieczeństwa, który może prowadzić do wycieku danych, to jest to zdecydowanie krytyczny problem. Niedocenianie w takim przypadku może prowadzić do kwestii prawnych i jeszcze większych problemów. Najlepiej byłoby więc, gdyby klasyfikacja była jak najbardziej zbliżona do prawdy.

Kiedy wiesz, że musisz zgłosić problem, powinieneś również wiedzieć, gdzie lub jak wysłać go do software house. Niektórzy mogą udostępnić specjalny formularz (być może nawet ze sztuczną inteligencją, która pomaga kategoryzować poziom zgłoszenia), inni chcą, aby został on przesłany za pośrednictwem Slacka lub Asany, ale w krytycznych przypadkach najlepiej jest po prostu zadzwonić lub wysłać wiadomość e-mail na wskazany adres e-mail. Jeśli masz SLA, ale nie znasz kanału – zapytaj swój software house (lub może to być wskaźnik, że taki kanał nie istnieje, więc powinieneś poszukać innego software house’u).

Jestem właścicielem firmy zajmującym się sprawami użytkowników

Jeśli prowadzisz własną usługę online, w pewnym momencie otrzymasz pewnego rodzaju skargi od użytkowników. Lepiej być na to przygotowanym – nawet jeśli użytkownicy nie mają umowy SLA, powinieneś zapewnić pewien rodzaj wsparcia i obsługi zgłoszeń użytkowników – nawet jeśli w większości przypadków nie będą oni wysyłać krytycznych problemów, ale raczej prośby o pomoc.

Jednym ze sposobów jest podłączenie się do zewnętrznego systemu obsługi zgłoszeń. Są one przyjemne i łatwe do uruchomienia, ale jest jeden problem: przenoszą cię poza twoją platformę, więc immersja użytkownika spada (użytkownik jest przenoszony poza naszą przestrzeń i może stracić zainteresowanie twoją platformą lub wypełnianiem szczegółów sprawy). Lepiej jest, jeśli możesz zatrzymać użytkownika na platformie, ale wymaga to niestandardowej integracji lub opracowania takiego systemu biletowego. Trzecim sposobem – jeśli szukasz opcji budżetowej lub dostosowywania przepływu wsparcia – może być automatyzacja N8N w połączeniu z NocoDB. 

.

Jedną rzeczą, o której należy pamiętać, jest to, że pomimo najlepszych intencji użytkownik może nie być w stanie wystarczająco dokładnie opisać problemu. Dlatego ważne są dwa elementy. Po pierwsze: poprosić o kontakt lub powiązać kwestie z użytkownikami. Po drugie: upewnij się, że używasz Sentry i Clarity lub Hotjar, abyś mógł wyśledzić problem.

Jestem Software House zapewniającym wsparcie lub SLA

W takim przypadku należy upewnić się, że umowy SLA lub wsparcia są jasne i precyzyjne, a klienci używają odpowiednich kanałów do komunikacji z Tobą. Upewnij się również, że używasz odpowiednich narzędzi do śledzenia, takich jak Sentry lub MS Clarity, abyś mógł odtworzyć dany problem. Również Sentry jest ważne w tym aspekcie, że można śledzić problemy, których użytkownicy nie zgłaszają. Moim zdaniem jest to absolutnie niezbędne narzędzie.

Usprawnienie procesu dystrybucji zgłoszeń

Można tu zauważyć pewien schemat: użytkownik wysyła dane do właściciela firmy, który wysyła dane do software house’u. Jest jednak pewien haczyk: nie każde zgłoszenie jest zgłoszeniem. Może to być zgłoszenie do pomocy technicznej lub prośba o funkcję. 

>

I bez względu na to, czy jesteś producentem oprogramowania, czy właścicielem firmy, powinieneś zrozumieć cały proces, przez który przechodzi zgłoszenie. Pomocne może być przejrzenie pełnej ścieżki wsparcia i zwizualizowanie jej, ewentualnie z konsultacją drugiej strony. Taki proces może wyglądać podobnie do tego (zwróć uwagę na kolory, które identyfikują obszar odpowiedzialności!)

Klasyfikacja incydentów w Sailing Byte

Czy masz jakieś problemy z klasyfikacją incydentów, którą wprowadziliśmy w pakietach SLA? Klasyfikacja incydentów jest ważna jako metoda określania zgłoszonych zadań za pośrednictwem Asany lub innej uzgodnionej metody.

>

Pamiętaj, że ten opis jest tylko sugestią i ostatecznie to nasz zespół wsparcia decyduje:

>

• czy incydent rzeczywiście miał miejsce, czy jest to tylko zadanie wsparcia niezwiązane z incydentem;
• jaki poziom dotkliwości wystąpił;
• Czy istnieje możliwość obniżenia poziomu incydentu, co da nam dłuższe ramy czasowe rozwiązania.

Zadania wsparcia bez incydentów

Klient składa wniosek o udzielenie informacji na temat możliwego zadania wsparcia, które nie ma wpływu operacyjnego. Wdrożenie lub korzystanie z Oprogramowania przez Klienta lub jego klientów jest kontynuowane i nie ma negatywnego wpływu na wydajność. Obejmuje to również wszystkie zadania, którymi można zarządzać w ramach CMS bez opracowywania nowych funkcji.

Przykłady:

>

• Sprawdzenie, czy sprawa zgłoszona przez Klienta jest incydentem
• Zmiana tekstu lub opisu produktu na stronie
• Zmiana obrazu/grafiki na stronie
• Wykonanie aktualizacji systemu lub wtyczki
• Menadżer potrzebuje instrukcji jak zmienić cenę produktu

DUŻY incydent

Drobne funkcje Oprogramowania są niedostępne lub dostępne jest dobre rozwiązanie alternatywne, lub niedostępne są nieistotne funkcje Oprogramowania. Wpływ na klienta, niezależnie od wykorzystania produktu, jest minimalny.

Przykłady:

• Menedżer chce zmienić obraz w pokazie slajdów, ale ten obraz nie skaluje się prawidłowo. Menedżer może wrócić do oryginalnego obrazu.
• Po tym jak menedżer zmienił styl na produkcie, styl nie jest wyświetlany poprawnie, ale tekst jest widoczny.
• Użytkownik nie otrzymał wiadomości e-mail z fakturą na swój adres e-mail.

Incydent POŚREDNI

Ważne funkcje Oprogramowania nie działają poprawnie, ale istnieją alternatywne rozwiązania. Chociaż nie ma to wpływu na inne obszary Oprogramowania, system jest uszkodzony – niektóre funkcje są niedostępne.

Przykłady:

• Użytkownik końcowy nie może zostawić komentarza do swojego zamówienia, ale może napisać wiadomość e-mail do pomocy technicznej lub będzie mógł wykonać taką czynność później.
• Menadżer nie może w żaden sposób zmienić treści lub opisu produktu, ale może tymczasowo wyłączyć produkt, aby problematyczna treść nie była widoczna.

Poważny incydent

Wpływ zgłoszonego incydentu jest taki, że wielu klientów nie jest w stanie korzystać z Oprogramowania lub w rozsądny sposób kontynuować pracy przy użyciu Oprogramowania. Poważna utrata funkcji lub wydajności wpływająca na wszystkich/dużą liczbę użytkowników. Nie istnieje żadne obejście.

Przykłady:

• Użytkownik końcowy w systemie zakupowym nie może zapłacić za to, co znajduje się w jego koszyku za pomocą jednego ze środków (przykład: płatność kartą kredytową nie działa).
• Użytkownik końcowy nie może utworzyć nowego konta.
• Użytkownik zarządzający nie może usunąć produktu, który jest niedostępny.

Incydent KRYTYCZNY

Wpływ zgłoszonego incydentu jest taki, że żaden klient nie może korzystać z Oprogramowania. Pełna utrata funkcji lub wydajności wpływająca na wszystkich użytkowników. Nie istnieje żadne obejście.

Przykłady:

• Witryna internetowa została zhakowana, a zawartość strony głównej witryny została zastąpiona zhakowanym obrazem.
• Wykryto, że użytkownik znalazł naruszenie bezpieczeństwa i może uzyskać dane wszystkich innych użytkowników
• Z powodu błędu w zmianie DNS strona nie jest dostępna na całym świecie

.

Dlaczego muszę dodatkowo płacić za obsługę incydentów?

Kiedy zajmujemy się rozwojem, płacisz za rozwój i to jest zawarte w umowie. Ponadto, jako firma programistyczna, często podpisujemy umowę „serwisową”, która pomaga rozwijać małe funkcje i reagować na problemy bez konsekwencji prawnych lub finansowych w określonych terminach. Podpisanie SLA wymusza posiadanie gotowego zespołu reagowania na SLA, a prowadzenie takiego zespołu i utrzymywanie go w gotowości, wraz z wszelkimi procedurami, które należy wdrożyć, kosztuje dodatkowo. Istnieją jednak korzyści z płatnych pakietów SLA.

Zapewniona szybka reakcja i rozwiązanie

Opłacenie obsługi incydentów w ramach umowy o gwarantowanym poziomie świadczenia usług (SLA) gwarantuje, że w przypadku wystąpienia problemu, takiego jak awaria systemu lub błąd oprogramowania, masz bezpośredni dostęp do specjalistów, którzy są zobowiązani umową do reagowania i rozwiązywania problemów w określonych ramach czasowych. Oznacza to, że firma może zminimalizować przestoje i szybko przywrócić normalną działalność, co ma kluczowe znaczenie dla utrzymania ciągłości procesów i zadowolenia klientów. Jeśli przedłużające się oczekiwanie na odpowiedź może spowodować problemy prawne lub finansowe, to SLA jest prawdopodobnie dobrym kierunkiem.

Jasna odpowiedzialność i zdefiniowane oczekiwania

Umowa SLA określa jasne oczekiwania dotyczące jakości usług i czasu reakcji, ustanawiając odpowiedzialność między firmą a dostawcą oprogramowania. Jeśli dostawca nie spełnia tych standardów, umowa SLA oferuje ramy dla rozwiązania problemu, w tym potencjalne kary lub procedury eskalacji. Taka jasność pomaga uniknąć sporów i zapewnia, że obie strony rozumieją swoje obowiązki. Takie aspekty można dostrzec w definicjach incydentów wspomnianych powyżej.

Zmniejszone ryzyko biznesowe i wpływ finansowy

Przerwy w działaniu systemu i nierozwiązane incydenty mogą prowadzić do znacznych strat finansowych. Inwestując w obsługę incydentów opartą na umowach SLA, zmniejszasz ryzyko przedłużających się przestojów, chronisz swoje przychody i reputację.

Ciągłe doskonalenie i proaktywne monitorowanie

Umowy SLA często obejmują regularne przeglądy i raportowanie wydajności, zachęcając dostawców do ciągłego doskonalenia swoich usług. Proaktywne monitorowanie i automatyczne śledzenie incydentów pomaga wykrywać i rozwiązywać problemy przed ich eskalacją, zapewniając niezawodność i wydajność oprogramowania.

Dostęp do specjalistycznego wsparcia i konsultacji

Dzięki umowie SLA zyskujesz gwarantowany dostęp do wsparcia technicznego, w tym pomocy infolinii i konsultacji ekspertów. Gwarantuje to, że zespół może uzyskać pomoc nie tylko w sytuacjach awaryjnych, ale także w przypadku codziennych pytań operacyjnych, co dodatkowo zmniejsza ryzyko zakłóceń.

Podsumowanie zalet pakietów SLA

.

Podsumowując, opłacenie obsługi incydentów SLA przez software house to inwestycja w ciągłość biznesową, zaufanie klientów i doskonałość operacyjną. Zapewnia to, że w przypadku wystąpienia problemów masz wsparcie, strukturę i odpowiedzialność niezbędne do ich sprawnego i skutecznego rozwiązania. W porównaniu z umową „serwisową”, umowa ta zapewnia odpowiedzialność za czas rozwiązania i reakcję w oparciu o definicje.