Spis treści:
| Spis treści | ||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
Składowe wymagane do stworzenia przepływu w systemie LOG Plus
Na potrzeby zbudowania poprawnego katalogu z przepływami które będą wykorzystwane w danej organizacji do obsługi procesów (nie tylko tych związanych z IT), wymagane są poniższe elementy, które będą wykorzystywane:
Katalog spraw
Proces
Graf workflow
Formularze
Oraz konfiguracja:
Ról i uprawnień
Grup osób
Powiadomień
...
ETAP I –
...
ETAP II – Zbuduj katalog spraw
ETAP III – Utwórz wzorcowe szablony grafów procesów
ETAP III – Rozrysuj wzorcowy szablon grafu procesu
ETAP IV - Utwórz szablony formularzy
ETAP V – Rozbuduj poszczególne grafy o niestandardowe elementy
ETAP VI – Wprowadź ograniczenia do widoczności katalogu spraw i listy zgłoszeń
ETAP VII – Aktywuj funkcję powiadomień dla Zgłoszeń Helpdesk
...
Budowa listy procesów
Krok I – Budowa roboczej sekcji procesów
Należy zapoznać się z artykułem dotyczącym tworzenia sekcji dla procesów. Na potrzeby tworzenia szablonów workflow w systemie powinna zostać utworzona sekcja, na przykład o nazwie "HD – szablony przepływów". Warto zauważyć, że system domyślnie zawiera sekcję "Helpdesk Standard", która zawiera predefiniowane grupy procesów i workflow, wykorzystywane w „pudełkowym” katalogu spraw.
Krok II – Budowa roboczej grupy procesów
W ramach istniejącej sekcji należy dodać grupę, która będzie służyć do porządkowania szablonów przepływów tworzonych w kolejnych etapach. Przykłady grup procesów mogą być zbudowane w sekcji o nazwie "HD – szablony przepływów". Szczegółowe instrukcje znajdziesz w artykule .
Krok III – Tworzenie wszystkich procesów
Procesy należy utworzyć, dodając jedynie ich nazwy. Szczegółowe instrukcje znajdziesz w artykule
Krok IV – Grupowanie procesów według typu
W tym kroku procesy powinny zostać pogrupowane według typu, na przykład: Incydenty, Wnioski. Następnie należy utworzyć odpowiednie grupy w katalogu procesów i przenieść do nich procesy zgodnie z ich typem.
...
ETAP II – Budowa katalogu spraw
Katalog spraw pozwala na tworzenie uporządkowanej struktury spraw w organizacji, co umożliwia użytkownikom łatwe uruchamianie odpowiednich procesów. Każda sprawa w katalogu jest powiązana z konkretnym procesem, który inicjuje ciąg zdarzeń, formularzy oraz akcji.
Budowanie katalogu spraw wymaga przemyślenia jego struktury, aby uniknąć konieczności późniejszych modyfikacji, które mogą obejmować zmiany w workflow, formularzach oraz uprawnieniach. Jeśli organizacja potrzebuje prostego katalogu, warto skupić się na minimalnym podziale, np. "Sprawy IT" z typami jak "Zgłoszenie problemu" i "Zgłoszenie wniosku". W bardziej złożonych przypadkach można zastosować wielopoziomową hierarchię, uwzględniającą różne działy i typy spraw.
Krok I – Utworzenie katalogu spraw
Przejdź do Ustawień w systemie.
Wybierz Helpdesk > Katalog spraw.
Kliknij Nowy katalog i uzupełnij wymagane pola, takie jak nazwa katalogu, katalog nadrzędny oraz opcjonalnie opis i ikonę katalogu.
Zapisz zmiany.
Krok II – Tworzenie struktury spraw w katalogu
Przejdź do Ustawień i wybierz Helpdesk > Katalog spraw.
Wybierz Nowa sprawa i uzupełnij pola, takie jak nazwa sprawy, katalog nadrzędny, przypisany proces oraz opis.
Zapisz zmiany.
Należy pamiętać, że na najniższym poziomie katalogu spraw, każda sprawa musi mieć dedykowany formularz wejściowy, odpowiednie uprawnienia widoczności oraz zdefiniowany flow procesu. Każda sprawa musi być podłączona do konkretnego procesu, który określa graf przepływu, zgodnie z opisem w Etapie III.
...
ETAP III – Wzorcowe szablony grafów procesów
Po ustaleniu i akceptacji struktury katalogu spraw, można przejść do kolejnego kroku, jakim jest budowanie wzorcowych procesów. Każdy proces będzie oparty na dedykowanym szablonie workflow, stworzonym w graficznym edytorze. Te szablony mogą być następnie duplikowane i wykorzystywane do budowy innych procesów o tym samym typie sprawy.
Krok I – Tworzenie sekcji dla procesów
Na potrzeby budowy szablonów workflow należy utworzyć w systemie sekcję, na przykład "HD – szablonów przepływów". Szczegółowy opis tworzenia sekcji znajduje się tutaj. Warto pamiętać, że system domyślnie zawiera sekcję "Helpdesk Standard", która obejmuje predefiniowane grupy procesów i workflow dla „pudełkowego” katalogu spraw.
Krok II – Dodanie procesu w ramach grupy
Należy dodać procesy w ramach utworzonych grup, które będą zawierały wzorcowe szablony dla różnych typów przepływów. Artykuł dotyczący budowania procesów dostępny jest tutaj.
W ramach grupy standardowych przepływów zostanie dodany jeden proces, na którym można pracować podczas tworzenia standardowego grafu procesu. W grupie rozbudowanych przepływów można umieścić klon tego procesu, który zostanie rozwinięty o niestandardowe kroki w dalszych etapach.
Kolejne procesy, które wymagają większej liczby akceptacji, mogą również być umieszczane w tej grupie i powinny być klonami szablonu, który zostanie rozbudowany w późniejszych etapach.
...
ETAP III – Tworzenie wzorcowego szablonu grafu procesu
Tworzenie wzorcowego szablonu grafu procesu jest kluczowe dla zapewnienia spójności i standaryzacji w obsłudze zgłoszeń. Można zbudować kilka szablonów, różniących się drobnymi szczegółami (np. dodatkowy krok w procesie), jednak ważne jest, aby utrzymać jednolitość nazewnictwa i struktury.
Na przykład, akcje widoczne w procesie powinny mieć jednolite nazwy pisane w trybie rozkazującym: Realizuj, Rozwiąż, Odrzuć, Wstrzymaj, aby uniknąć zamieszania i zachować spójność.
Krok I – Ustalanie kroków i statusów w procesie
W pierwszej kolejności należy ustalić kroki (statusy), które będą widniały w procesie. Ważne jest, aby minimalizować liczbę kroków w prostych przepływach, zachowując standardową strukturę. Wzorcowy szablon może obejmować następujące statusy:
Otwarty: Zgłoszenie zostało dodane do systemu i przypisane do zespołu, ale nie podjęte przez operatora.
W realizacji: Operator podjął zgłoszenie i jest odpowiedzialny za jego realizację.
Rozwiązany: Zgłoszenie zostało rozwiązane, a zgłaszający został poinformowany.
Zamknięty: Zgłoszenie zostało ostatecznie zamknięte, bez możliwości ponownego otwarcia.
Statusy dodatkowe mogą obejmować:
Odrzucony: Zgłoszenie odrzucone przez operatora.
Anulowany: Zgłoszenie anulowane przez zgłaszającego.
Zwrócony do uzupełnienia: Operator potrzebuje więcej informacji od zgłaszającego.
Wysłany na zewnątrz: Zgłoszenie przekazane do zewnętrznej firmy.
Krok II – Budowa grafu przepływu
Na podstawie ustalonych statusów należy zbudować graf przepływu w edytorze workflow.
Mechanika edytora:
Narzędzia są w stałej pozycji na przestrzeni roboczej, możesz je umieszczać i przesuwać za pomocą metody drag&drop.
Można skalować (zmniejszać/zwiększać) obiekty na polu edycji.
Można przesuwać i usuwać obiekty grupowo poprzez zaznaczenie (shift).
Dwukrotne kliknięcie w obiekt umożliwia dodanie nazwy kształtu.
Pojedyncze kliknięcie w obiekt umożliwia jego edycję, sklonowanie lub usunięcie.
Każdy obiekt ma swój unikalny nr #ID nadawany automatycznie w obrębie danego procesu.
Pojedyncze kliknięcie w narzędzie i wybór Edytuj wywołuje okno edytora etapu procesu.
Elementy procesu:
Etap: Określa konkretne fazy procesu (Start, Stop, Akceptacja) i może mieć przypisane reguły oraz kworę akceptacji.
Przejście: Opisuje czynności odbywające się "w tle" pomiędzy etapami.
Rozpoczynając od ikony Start, metodą "drag & drop" należy umieścić ją na grafie, nazwać (np. "Start procesu") i ustawić początkowy stan procesu jako Nowe. Kolejne etapy, takie jak Otwarty, W realizacji, Rozwiązany, Zamknięty i inne, powinny być umieszczone zgodnie z przyjętymi krokami. Następnie należy narysować powiązania między stanami, tworząc przejścia.
Krok III – Ustalanie standardowych akcji dla każdego przejścia
Każde przejście w workflow powinno mieć przypisane odpowiednie standardowe akcje, takie jak:
Uruchom formularz: Formularz uruchamiany po wybraniu odpowiedniego typu sprawy z katalogu.
Ustaw wartość pola: Automatyczne uzupełnienie pola odpowiednią wartością (np. Zgłaszający, Grupa realizująca, Realizujący).
Wyślij wiadomość e-mail: Wysyłanie wiadomości e-mail do odpowiednich adresatów.
Akcje te należy przypisać do odpowiednich przejść w procesie, zapewniając spójność i automatyzację działań. Warto, aby nazwy przejść były krótkie i w trybie rozkazującym, np. "Rozwiąż", "Podejmij", "Odrzuć", aby zachować jasność i spójność w całym systemie.
Przy realizacji każdego z tych kroków, należy pamiętać o ujednoliceniu nazw oraz zapewnieniu, że procesy będą funkcjonować zgodnie z przyjętymi standardami.
Krok IV – Ustalanie standardowych uprawnień dla przejść w workflow
Podczas definiowania przejść w workflow kluczowe jest określenie uprawnień, które regulują dostępność przycisków umożliwiających przejście do kolejnych etapów procesu. Uprawnienia te definiują, kto może wykonać daną akcję, czyli przesunąć zgłoszenie na inny stan.
Podobnie jak w przypadku reguł, uprawnienia powinny być powiązane z warunkami, które muszą spełniać operatorzy zgłoszenia (realizujący, akceptujący, zgłaszający), aby móc wykonać dane przejście. Warunki te można dodać, edytując przejście w zakładce Warunki klikając "Dodaj warunki".
Podstawowe warunki dla uprawnień:
Zalogowany użytkownik: Warunek umożliwia wykonanie przejścia tylko dla określonego użytkownika, np. osoby dodającej sprawę.
Zalogowany użytkownik przypisany do grupy: Warunek stosowany do przejść, które mogą być wykonane przez wszystkich członków wskazanej grupy realizującej.
Zalogowany użytkownik jest przypisany do działu lub organizacji: Warunek stosowany do przejść, które mogą być wykonane przez członków wskazanego działu lub organizacji.
Pole zgłoszenia : Warunek stosowany do przejść, które mogą być wykonane tylko jeżeli wskazane pole zgłoszenia spełni wymagania np. będzie zawierało daną zmienną.
Wersja językowa: Przejście będzie możliwe tylko do wykonania dla określonej wersji językowej.
Przykłady zastosowania warunków:
Przejście dostępne tylko dla zgłaszającego: Używane w przejściach umożliwiających np. reklamację zgłoszenia.
Przejście dostępne tylko dla grupy realizującej: Stosowane w większości przejść po zarejestrowaniu zgłoszenia, w którym widoczność została ustawiona dla Zalogowanego użytkownika który jest członkiem grupy realizującej. Akcje możliwe do wykonania są wtedy widoczne dla wszystkich osób przypisanych do danej grupy (samo ustawienie w danym procesie takiej grupy definiujemy w regułach, w danej akcji).
Przejście dostępne tylko dla przełożonego: Typowe dla akcji związanych z akceptacją zgłoszeń. Akcje związane z akceptacją lub odrzuceniem zgłoszenia są widoczne wtedy tylko dla osoby w roli bezpośredniego przełożonego osoby Zgłaszającej
Przejście dostępne tylko dla lidera grupy: Dedykowane dla liderów zespołów odpowiedzialnych za zarządzanie zgłoszeniami.
Przykład:
Dla przejścia "Odrzuć" w procesie, widoczność i możliwość wykonania akcji może być ustawiona tak, aby była dostępna wyłącznie dla użytkowników przypisanych do grupy realizującej. Uwaga! Każdy taki warunek działa z operatorem AND, co oznacza, że wszystkie warunki muszą być spełnione, aby przejście było możliwe.
Finalizacja:
Wszystkie przejścia w standardowym grafie procesu powinny mieć przypisane odpowiednie uprawnienia wraz z warunkami, które spełniają podstawowe wymagania procesu. Pozostałe, bardziej zaawansowane warunki i modyfikacje, zostaną omówione w Etapie V, gdzie grafy będą rozbudowywane o niestandardowe elementy, takie jak dodatkowe statusy, akcje czy uprawnienia.
ETAP IV - Tworzenie szablonów formularzy
Zbudowane na tym etapie formularze należy wykorzystać w ramach etapu III i etapu IV dla opisanych akcji na przepływach (Krok III – ustal standardowe akcje dla każdego przejścia w workflow)
Edytor formularza umożliwia tworzenie formularzy, które pojawią się w określonych momentach procesu, pozwalając użytkownikowi na wprowadzenie potrzebnych danych.
Formularze mogą zawierać różne sekcje i pola, które można mapować z elementami zgłoszenia, na przykład z tytułem zgłoszenia. Oznacza to, że wpisane przez użytkownika informacje automatycznie zostaną przypisane do odpowiednich miejsc w zgłoszeniu.
Tworzenie formularza
Z górnego paska nawigacyjnego wybierz Procesy → Katalog formularzy.
Wybierz grupę, w której chcesz stworzyć nowy formularz.
Kliknij Dodaj formularz.
W formularzu można tworzyć sekcje, dodawać pola tekstowe, listy rozwijalne, wybory wielokrotne i inne elementy. Ważne jest, aby formularz nie był przeładowany informacjami. Prosty formularz powinien zawierać podstawowe elementy, takie jak opis zgłoszenia, możliwość dodania załączników, oraz podstawową kategoryzację.
Przykłady zastosowania:
Prosty formularz: Zawiera tylko podstawowe pola, takie jak opis zgłoszenia, załączniki, i zgłaszający. Jest przejrzysty i łatwy do wypełnienia.
Zaawansowany formularz: Może zawierać pola wielokrotnego wyboru, listy rozwijalne oraz pola dat, umieszczone na górze formularza dla lepszej dostępności kluczowych informacji. Opis zgłoszenia może być przesunięty niżej, jeśli nie jest kluczowy.
Uwaga dotycząca automatyzacji
Niektóre pola, jak Temat zgłoszenia, mogą być automatycznie wypełniane przez system za pomocą zdefiniowanych akcji w grafie workflow, co pozwala uprościć formularz dla użytkownika.
...
ETAP V – Rozbudowa grafów o niestandardowe elementy
W tym etapie koncentrujemy się na procesach, które różnią się od standardowych grafów stworzonych w Etapie III, zarówno pod względem przebiegu, akcji, jak i uprawnień. Te bardziej zaawansowane grafy mogą posłużyć jako wzorcowe szablony dla złożonych procesów, takich jak wnioski czy zmiany, które często wymagają dodatkowych kroków akceptacji.
Krok I – Ustal dodatkowe kroki i statusy w procesie
Dla bardziej złożonych procesów można dodać dodatkowe kroki, jeśli jest to konieczne. Przykłady takich kroków obejmują:
Akceptacja: Zgłoszenie przypisane do osoby w roli akceptującego, np. przełożonego lub właściciela biznesowego.
Analiza: Przekazanie zgłoszenia do wstępnej analizy przez operatora lub lidera grupy.
Planowanie: Etap ustalania kluczowych parametrów, takich jak czas realizacji w przypadku zmiany.
Zamrożony: Wstrzymanie zgłoszenia z uzasadnieniem, co zatrzymuje naliczanie czasów.
Testy: Przeprowadzenie testów przed wprowadzeniem zmiany na produkcję.
Wycofanie: Czynności mające na celu wycofanie zmiany w razie niepowodzenia.
Ocena: Ostatni etap, gdzie przeprowadzana jest ocena i raportowanie zmiany.
Krok II – Rozbudowa grafu przepływu
Aby rozbudować standardowy szablon grafu:
Klonowanie szablonu: Przejdź do standardowego szablonu, wybierz „Klonuj” i zapisz go pod nową nazwą, np. "Szablon flow dla wniosków - jedna akceptacja".
Edycja grafu: Przejdź do zakładki „Graf procesu” w nowym szablonie i wprowadź zmiany w trybie edycji. Dodaj nowe kroki, takie jak „Akceptacja przełożonego”, i połącz je z istniejącymi stanami.
Każda strzałka przejścia powinna reprezentować konkretną akcję, taką jak „Akceptuj”, „Odrzuć” lub „Brak decyzji”. Należy również skonfigurować powiązania z nowo dodanymi etapami akceptacji.
Krok III – Ustal dodatkowe akcje dla przejść w workflow
Do każdego przejścia można dodać niestandardowe akcje, które zostaną wykonane podczas obsługi zgłoszenia. Przykłady takich akcji obejmują:
Dodaj komentarz: Automatyczne dodanie komentarza w zgłoszeniu, np. z numerem zgłoszenia.
Dodaj notatkę: Dodanie wewnętrznej notatki dla grupy obsługującej zgłoszenie.
Dodaj zadanie: Tworzenie zadań dla poszczególnych osób lub grup, np. sprawdzenie stanu magazynu lub budżetu.
Dodanie zgłoszenia podrzędnego: Utworzenie nowego zgłoszenia, które będzie powiązane z nadrzędnym zgłoszeniem.
Każdą akcję można skonfigurować zgodnie z potrzebami procesu, w tym ustawiając jej widoczność i uprawnienia.
Krok IV – Ustal specyficzne uprawnienia dla przejść w workflow
W bardziej zaawansowanych procesach może być konieczne wprowadzenie dodatkowych warunków dla przejść, aby je wykonać. Przykłady takich warunków obejmują:
Przypisanie do działu lub organizacji: Warunek sprawdzający, czy użytkownik jest przypisany do odpowiedniego działu lub organizacji.
Pole zgłoszenia: Sprawdza wartość konkretnego pola, np. budżetu, i warunkuje możliwość wykonania przejścia.
Na przykład, przejście „Zakupiono sprzęt” może być dostępne tylko wtedy, gdy pole Budżet jest wypełnione kwotą równą lub większą niż 3000.
Podsumowanie
Rozbudowane grafy procesów pozwalają na bardziej precyzyjne zarządzanie złożonymi procesami, w których wymagana jest większa elastyczność i niestandardowe rozwiązania. Ważne jest, aby przy wprowadzaniu tych zmian zachować spójność z wcześniej ustalonymi standardami i dokładnie przemyśleć każdy dodatek, aby nie skomplikować niepotrzebnie procesu.
...
Etap VI – Wprowadzanie ograniczeń do widoczności katalogu spraw i listy zgłoszeń
W tym etapie należy skonfigurować role i uprawnienia w systemie LOG Plus, aby określić, jakie elementy katalogu spraw i listy zgłoszeń są widoczne dla poszczególnych użytkowników oraz jakie akcje mogą oni wykonywać.
Krok I – Ustalanie widoczności elementów w katalogu spraw
W ramach tego kroku definiuje się, które elementy w katalogu spraw są widoczne dla danej osoby po zalogowaniu się do systemu. Domyślnie przyjmuje się, że "wszyscy widzą wszystko". Dlatego w roli przypisanej do wszystkich użytkowników systemu, która zawiera minimalny zestaw uprawnień, widoczność wszystkich elementów katalogu spraw jest zazwyczaj włączona.
Przykład: Rola z włączonymi wszystkimi elementami w katalogu spraw powinna mieć zaznaczoną opcję "Podgląd", co umożliwia użytkownikom przeglądanie wszystkich dostępnych spraw.
Krok II – Konfiguracja widoczności listy zgłoszeń
Tutaj określa się, jakie zgłoszenia są widoczne na liście dla poszczególnych użytkowników po zalogowaniu. Podstawowa rola dla wszystkich użytkowników powinna zapewniać widoczność tylko tych zgłoszeń, dla których zalogowany użytkownik jest:
Twórcą
Zgłaszającym
Realizującym
Przykład: Rola z minimalnym zakresem widoczności do listy zgłoszeń powinna mieć ustawienia umożliwiające przeglądanie tylko tych zgłoszeń, które są bezpośrednio związane z użytkownikiem. Dla grup obsługujących zgłoszenia można utworzyć rozszerzone role, które dodatkowo umożliwiają przeglądanie zgłoszeń przypisanych do zespołu lub grupy.
Krok III – Definiowanie akcji dostępnych dla użytkownika na zgłoszeniach
W tym kroku konfiguruje się, jakie akcje użytkownik może wykonać na zgłoszeniach, do których ma dostęp. Poza akcjami wynikającymi z uprawnień w grafach workflow, można ustawić dodatkowe uprawnienia, takie jak:
Podgląd zgłoszenia: Podstawowa akcja dostępna nawet dla ról z minimalnymi uprawnieniami.
Dodawanie i podgląd notatek wewnętrznych: Dedykowane dla operatorów zgłoszeń.
Edycja zgłoszenia: Przeznaczona dla operatorów zgłoszeń, umożliwia modyfikację treści zgłoszenia.
Usuwanie zgłoszenia: Zarezerwowane dla administratorów systemu lub liderów Helpdesk.
Przykład: Rola z uprawnieniami dla operatorów Helpdesk może rozszerzać dostępne akcje o edycję zgłoszeń i dodawanie notatek, co pozwala na bardziej kompleksowe zarządzanie zgłoszeniami przez osoby pełniące rolę operatorów.
Podsumowanie
Wprowadzenie odpowiednich ograniczeń do widoczności katalogu spraw i listy zgłoszeń, jak również zdefiniowanie dostępnych akcji na zgłoszeniach, pozwala na precyzyjne zarządzanie dostępem użytkowników do różnych funkcji systemu LOG Plus. Dzięki temu możliwe jest utrzymanie porządku i bezpieczeństwa w obsłudze zgłoszeń oraz dostosowanie widoczności i uprawnień do potrzeb organizacji.
...
ETAP VII – Aktywacja powiadomień dla Zgłoszeń Helpdesk
Oprócz akcji związanych z wysyłaniem e-maili w ramach grafów workflow, system LOG Plus oferuje możliwość definiowania podstawowych powiadomień, które mogą być prezentowane w aplikacji i/lub wysyłane na e-mail. Powiadomienia te są standardowymi funkcjami systemu, niezależnymi od specyficznych workflow, i dotyczą kilku kluczowych akcji:
Dodanie sprawy
Zmiana statusu sprawy
Nowy komentarz w zgłoszeniu
Charakterystyka powiadomień
Powiadomienia te są szablonowe, co oznacza, że ich zawartość jest ustalona i nie można jej modyfikować. Są one zatem traktowane jako standardowe akcje systemowe, które działają poza indywidualnymi workflow. Gdy włączymy powiadomienie o nowym zgłoszeniu, np. dla osoby, która dodała sprawę, system automatycznie wysyła takie powiadomienia do zdefiniowanych odbiorców, niezależnie od typu zgłoszenia.
Kiedy zrezygnować z systemowych powiadomień?
W pewnych przypadkach, może być pożądane, aby powiadomienia systemowe nie były wysyłane, np. gdy w konkretnym procesie nie chcemy informować zgłaszającego o dodaniu nowego zgłoszenia. W takich sytuacjach należy wyłączyć standardowe powiadomienia i zamiast tego skorzystać z akcji w ramach grafu workflow, które pozwalają na dostosowanie komunikacji do potrzeb danego procesu. Tego rodzaju zmiany powinny być wprowadzane w Etapie V, gdzie standardowy graf można rozbudować lub modyfikować, np. usuwając niepotrzebne akcje.
Dostosowanie wysyłki e-maili w workflow
Podobnie, jeśli chcemy wysyłać e-maile w ramach workflow, ale potrzebujemy, aby zawierały one więcej informacji niż te dostępne w standardowych powiadomieniach, warto skorzystać z akcji w workflow. Dzięki temu można precyzyjnie określić, jakie informacje mają być zawarte w wiadomości, co pozwala na bardziej zaawansowaną i dostosowaną do potrzeb komunikację. Należy pamiętać, że szablony systemowych powiadomień są stałe i ich treść nie może być zmieniana, więc wszelkie dodatkowe informacje należy dodawać poprzez akcje w workflow.
...
Czego należy unikać?
Formularze
W projektowaniu formularzy należy unikać kilku kluczowych błędów, które mogą zniechęcić użytkowników do korzystania z narzędzia:
Zbyt duża ilość wymaganych pól: Jeżeli formularz wymaga od użytkownika wypełnienia zbyt wielu pól, szczególnie w przypadku zgłaszania problemu, użytkownik może poczuć frustrację związaną z czasem potrzebnym na jego wypełnienie. Może to skutkować rezygnacją z używania narzędzia na rzecz bardziej bezpośrednich metod, jak kontakt telefoniczny.
Brak opisów pól: Pola formularza powinny być jasno oznaczone. Jeśli etykieta pola nie wyjaśnia użytkownikowi, co dokładnie powinien wpisać lub wybrać, może to prowadzić do błędów i utrudnień w procesie zgłaszania.
Niepotrzebne walidacje pól: Walidacje powinny być stosowane tylko tam, gdzie są naprawdę konieczne, aby wspomóc szybszą analizę zgłoszenia. Nadmiar walidacji może spowolnić proces zgłaszania i zniechęcić użytkowników.
Powiadomienia
Należy ostrożnie korzystać z funkcji powiadomień, szczególnie w zakresie wysyłania e-maili:
Dualizm powiadomień: Jeśli w danym grafie workflow zastosowano już akcję wysyłki maila do tego samego odbiorcy, włączanie dodatkowych powiadomień systemowych może prowadzić do wysyłania podwójnych wiadomości, co jest zbędne i może irytować odbiorców.
Ograniczona zawartość powiadomień: Systemowe powiadomienia mają stałą, niemodyfikowalną treść. Jeśli wymagane jest przekazanie bardziej szczegółowych informacji, lepiej skorzystać z akcji w workflow, które pozwalają na dostosowanie treści wiadomości do potrzeb.
Graf workflow
Przy tworzeniu grafów workflow należy zachować spójność i prostotę:
Spójność nazw przycisków akcji: Wszystkie grafy powinny mieć jednolite nazewnictwo przycisków, najlepiej w formie nakazującej, np. "Realizuj", "Rozwiąż". Brak spójności może wprowadzać zamieszanie.
Minimalizacja liczby kroków: W grafie powinno być jak najmniej etapów (statusów). Proste grafy, takie jak "Nowy", "Otwarty", "W realizacji", "Rozwiązany", "Zamknięty", "W akceptacji", są bardziej przejrzyste.
Krótkie nazwy statusów i przejść: Im krótsze nazwy, tym bardziej czytelne. Długie nazwy mogą być obcinane lub zawijać się, co obniża czytelność.
Przemyślana kolejność akcji: Akcje w przejściach powinny być ustawione w logicznej kolejności. Na przykład, jeśli akcja „Uruchom formularz” następuje przed akcją „Wypełnij pole wartością XYZ”, może dojść do sytuacji, w której pole nie zostanie prawidłowo wypełnione.
Ograniczona liczba warunków w uprawnieniach do przejść: Najczęściej powinien wystarczyć jeden warunek. Większa ich liczba może sprawić, że przejście nie będzie dostępne dla żadnego użytkownika, co zablokuje proces.
Uprawnienia i role
Przy definiowaniu ról i uprawnień należy pamiętać o kilku kluczowych zasadach:
Unikanie tworzenia ról dla pojedynczych użytkowników: Role powinny być przypisane do większych grup osób, np. rola z minimalnym zakresem uprawnień dla wszystkich użytkowników portalu LOG Plus lub dla operatorów Helpdesk.
Unikanie dublowania uprawnień: Jeżeli użytkownik ma już przypisaną rolę z dostępem do katalogu spraw, nie ma potrzeby nadawania tych samych uprawnień w dodatkowej roli. Nowe role powinny jedynie rozszerzać zakres uprawnień.
Ograniczona ilość uprawnień w roli: Lepiej jest stworzyć rolę z mniejszym zakresem uprawnień, a następnie rozszerzać ją w miarę potrzeby, niż dać użytkownikom zbyt szeroki dostęp od samego początku.