Program do nadzorowania reklamacji - wiek spraw i działania korygujące

Program do nadzorowania reklamacji a rejestr zgłoszeń

Rejestr zgłoszeń odpowiada na pytanie, co wpłynęło do firmy. Nadzór odpowiada na inne pytanie: co w tej chwili wymaga reakcji kierownika. Program do nadzorowania reklamacji korzysta z tych samych danych co rejestr, ale czyta je z punktu widzenia kolejki i wieku sprawy, a nie tylko jej treści.

Różnica ujawnia się przy pierwszej awarii procesu. Gdy sprawa zatrzymuje się u jednego pracownika, rejestr nadal pokazuje ją jako otwartą i nic więcej. Widok nadzorczy pokazuje, od ilu dni sprawa stoi w tym samym statusie i kto jest jej właścicielem.

Terminy wynikające z przepisów oraz eskalację po przekroczeniu SLA opisuje artykuł o zarządzaniu reklamacjami i terminach. Statusy oraz model danych sprawy zawiera tekst o oprogramowaniu do obsługi reklamacji. Ten artykuł dotyczy tego, co kierownik widzi i robi na podstawie tych danych.

Kolejki i obciążenie zespołu

Kolejka według właściciela sprawy

Każda otwarta sprawa ma właściciela, czyli osobę albo dział odpowiedzialny za kolejny krok. Kolejka nadzorcza grupuje sprawy według właściciela i statusu. Kierownik widzi od razu, że jeden pracownik prowadzi kilkanaście spraw czekających na decyzję, a drugi zaledwie jedną.

SELECT w.NazwaWlasciciela,
       s.NazwaStatusu,
       COUNT(*)                 AS LiczbaSpraw,
       MIN(r.DataZmianyStatusu) AS NajstarszaZmiana
FROM dbo.Reklamacja AS r
JOIN dbo.Wlasciciel AS w ON w.Id = r.WlascicielId
JOIN dbo.Status     AS s ON s.Id = r.StatusId
WHERE s.CzyOtwarty = 1
GROUP BY w.NazwaWlasciciela, s.NazwaStatusu
ORDER BY LiczbaSpraw DESC;

Zapytanie zwraca liczbę spraw i datę najstarszej zmiany w każdej grupie. Nazwy tabel i kolumn są tu przykładowe. Kolumna CzyOtwarty w słowniku statusów pozwala odfiltrować sprawy zamknięte i anulowane bez wpisywania nazw statusów w zapytaniu, więc zestawienie nie rozjeżdża się po dodaniu nowego statusu.

Obciążenie a przydział zgłoszeń

Sama liczba spraw bywa myląca, ponieważ wymiana towaru zajmuje mniej czasu niż spór o szkodę transportową. Zestawienie można oprzeć na wadze przypisanej do typu reklamacji. Obciążenie jest wtedy sumą wag, a nie liczbą wierszy.

Reguły, według których sprawa trafia do działu albo osoby, opisuje artykuł o programie do obsługi reklamacji. Nadzór korzysta z ich wyniku: pokazuje, czy przydział faktycznie równoważy pracę.

Sprawy bez właściciela

Osobnego widoku wymagają sprawy, które nikomu nie zostały przypisane. Trafiają do kolejki ogólnej, gdy żadna reguła przydziału nie pasuje do kategorii produktu albo rodzaju problemu. Jeśli kolejka ogólna rośnie, to sygnał, że reguły trzeba uzupełnić, a nie że zespół pracuje wolniej. Zestawienie takich spraw otwiera poranny przegląd, ponieważ każda z nich czeka na pierwszą decyzję.

Wiek spraw i sprawy, które stoją

Wiek sprawy liczy się na dwa sposoby. Wiek całkowity to liczba dni od rejestracji zgłoszenia. Wiek w statusie to liczba dni od ostatniej zmiany statusu. Do nadzoru ważniejszy jest drugi, bo sprawa może mieć trzy tygodnie i być prowadzona sprawnie, a może mieć cztery dni i stać bez ruchu.

SELECT Przedzial, COUNT(*) AS LiczbaSpraw
FROM (
    SELECT CASE
             WHEN d.Dni <= 2  THEN N'0-2 dni'
             WHEN d.Dni <= 7  THEN N'3-7 dni'
             WHEN d.Dni <= 14 THEN N'8-14 dni'
             ELSE N'powyzej 14 dni'
           END AS Przedzial
    FROM dbo.Reklamacja AS r
    JOIN dbo.Status AS s ON s.Id = r.StatusId
    CROSS APPLY (SELECT DATEDIFF(DAY, r.DataZmianyStatusu, SYSDATETIME()) AS Dni) AS d
    WHERE s.CzyOtwarty = 1
) AS x
GROUP BY Przedzial;

Funkcja DATEDIFF liczy przekroczone granice jednostki, a nie pełne doby. Zgłoszenie z 23:50 i zmiana statusu o 00:10 następnego dnia dają różnicę jednego dnia, choć minęło dwadzieścia minut. Przy progach liczonych w dniach ten błąd jest akceptowalny, ale przy progach godzinowych warto porównywać znaczniki czasu wprost. Składnię opisuje dokumentacja funkcji DATEDIFF na Microsoft Learn.

Reguła: sprawa bez zmiany statusu przez ustaloną liczbę dni trafia na listę kierownika, niezależnie od tego, czy termin SLA został już przekroczony.

Sprawy oczekujące na klienta

Część spraw stoi, ponieważ czeka na działanie klienta, na przykład na przesłanie towaru do serwisu. Jeżeli proces ma taki status, zestawienie wieku powinno go pokazywać osobno. Sprawa czekająca na paczkę nie jest zaległością zespołu, ale nadal wymaga przypomnienia, po którym klient dostaje wiadomość albo sprawa zostaje zamknięta z odpowiednim kodem.

Kalendarz i statusy w demo Studio RMA.net

Demo Studio RMA.net udostępnia widok kalendarza, w którym każda reklamacja jest blokiem czasu, a kolumny odpowiadają statusom. Ekran pochodzi z wersji demonstracyjnej i zawiera dane przykładowe. Statusy widoczne na ekranie i sposób ich odczytu w nadzorze zestawia tabela.

Numer sprawy na ekranie zawiera rok i miesiąc, a po nich numer kolejny, więc już z listy widać, z którego okresu pochodzi zgłoszenie. Lewe menu ma osobne sekcje dla reklamacji i serwisu oraz dla kartotek, a część informacyjna oferuje zestawienia i raporty oraz kalendarz i wykres. Wersję demonstracyjną można sprawdzić na stronie demo reklamacji.

Wskaźniki nadzoru i przegląd tygodniowy

Wskaźniki mają sens tylko wtedy, gdy ktoś regularnie na nie patrzy. Przegląd tygodniowy trwający kwadrans, prowadzony na tym samym zestawieniu, daje więcej niż rozbudowany raport czytany raz na kwartał.

Reklamacje powtórne wykrywa się po numerze seryjnym. Gdy towar go nie ma, kluczem staje się model wraz z partią i kodem przyczyny. Okno czasu trzeba dobrać do rodzaju towaru: dla części eksploatacyjnych wystarczą tygodnie, dla urządzeń używanych latami liczy się okres gwarancji. Zbyt krótkie okno ukrywa powtórzenia, zbyt długie łączy niepowiązane sprawy.

Do czasów lepiej nadaje się mediana niż średnia, ponieważ kilka spraw ciągnących się miesiącami zawyża średnią i przesłania typowy przebieg. SQL Server liczy medianę funkcją PERCENTILE_CONT.

SELECT DISTINCT
       PERCENTILE_CONT(0.5) WITHIN GROUP
         (ORDER BY DATEDIFF(HOUR, r.DataRejestracji, r.DataDecyzji)) OVER () AS MedianaGodzinDoDecyzji
FROM dbo.Reklamacja AS r
WHERE r.DataDecyzji IS NOT NULL
  AND r.DataRejestracji >= DATEADD(DAY, -90, SYSDATETIME());

Czas w godzinach kalendarzowych zawyża wynik dla spraw zarejestrowanych w piątek po południu. Jeśli firma ma umowne dni robocze, liczenie musi uwzględniać kalendarz, a jego budowę opisuje wspomniany wyżej tekst o terminach i SLA.

Stały porządek przeglądu skraca spotkanie i pozwala porównywać tygodnie między sobą. Prosty układ ma cztery punkty.

• Zaległości - sprawy ponad progiem wieku w statusie, z decyzją o właścicielu i nowym terminie.
• Sprawy powtórne - usterki, które wróciły w ustalonym oknie czasu, z numerami poprzednich zgłoszeń.
• Działania CAPA - zadania po terminie oraz zadania czekające na weryfikację skuteczności.
• Kolejka ogólna - sprawy bez właściciela, które wymagają przydziału lub poprawy reguł.

Działania korygujące i zapobiegawcze CAPA w nadzorze reklamacji

Norma ISO 10002 zawiera wytyczne postępowania z reklamacjami w organizacji, w tym klasyfikowanie i analizę zgłoszeń. Program do nadzorowania reklamacji dostarcza dane do tych czynności: kod przyczyny oraz model towaru. Do tego dochodzą dostawca i data zgłoszenia. Same dane nie poprawiają jakości. Potrzebny jest jeszcze mechanizm, który zamienia powtarzający się wzorzec w zadanie z właścicielem i terminem.

Takim mechanizmem jest CAPA (Corrective and Preventive Action). Działanie korygujące usuwa przyczynę niezgodności, która już wystąpiła. Działanie zapobiegawcze usuwa przyczynę niezgodności, która jeszcze się nie pojawiła, ale wynika z danych, na przykład z rosnącej liczby zgłoszeń jednego kodu przyczyny.

Progi wyzwalające CAPA ustala firma. Zbyt niski próg zalewa dział jakości zadaniami, zbyt wysoki oznacza, że wzorzec zostanie zauważony dopiero po kilkudziesięciu reklamacjach. Rejestr CAPA warto trzymać obok danych reklamacji, żeby zadanie wskazywało sprawy, z których powstało.

CREATE TABLE dbo.DzialanieCAPA (
    Id              INT IDENTITY(1,1) PRIMARY KEY,
    KodPrzyczyny    VARCHAR(20)   NOT NULL,
    ModelTowaru     VARCHAR(50)   NULL,
    Typ             CHAR(1)       NOT NULL CHECK (Typ IN ('K', 'Z')),  -- K: korygujace, Z: zapobiegawcze
    Opis            NVARCHAR(500) NOT NULL,
    WlascicielId    INT           NOT NULL,
    TerminWdrozenia DATE          NOT NULL,
    DataWeryfikacji DATE          NULL,
    Skuteczne       BIT           NULL
);

Kolumna Skuteczne pozostaje pusta do chwili weryfikacji. Zestawienie działań bez daty weryfikacji po terminie jest kolejnym widokiem nadzorczym, bo działanie bez sprawdzonego skutku niczego nie zamyka. Powiązanie z jakością produkcji opisuje artykuł o kontroli jakości w systemie produkcyjnym oraz tekst o zarządzaniu reklamacjami a jakością produktów.

Ślad zmian i odpowiedzialność za decyzje

Nadzór wymaga odpowiedzi na pytanie, kto i kiedy zmienił decyzję albo termin. Przesunięcie terminu to jeden z najłatwiejszych sposobów ukrycia opóźnienia, więc historia terminów jest częścią widoku kierownika. Dwa mechanizmy SQL Server odpowiadają na to pytanie na różnych poziomach.

• Historia biznesowa sprawy - wpis dla każdej zmiany statusu z autorem i komentarzem, widoczny dla użytkowników systemu.
• Wersjonowanie techniczne - poprzednie wersje wiersza zapisywane automatycznie w tabeli czasowej, dostępne dla administratora i audytora.

Wersjonowanie techniczne nie zastępuje historii biznesowej, ponieważ nie zna kontekstu: zapisuje, że kolumna się zmieniła, ale nie wie dlaczego. Z kolei historia biznesowa zależy od aplikacji i nie obejmuje zmian wprowadzonych bezpośrednio w bazie. Dla takich zmian służy SQL Server Audit, który rejestruje zdarzenia na poziomie serwera lub bazy.

Wybór programu do nadzorowania reklamacji

Przed zakupem warto sprawdzić, czy widok nadzorczy jest osobną funkcją, czy tylko listą z filtrami. Lista z filtrami wymaga za każdym razem ręcznego układania zapytania. Widok nadzorczy zapamiętuje ustawienia i pokazuje te same liczby w tym samym układzie co tydzień.

Ocenę widoku nadzorczego najlepiej oprzeć na próbie. Kilka przykładowych zgłoszeń z różnych działów, wprowadzonych do wersji demonstracyjnej, pokazuje, czy system odpowiada na pytania z pierwszej tabeli, a nie tylko wyświetla listy. Widok, którego ustawienia trzeba za każdym razem układać od nowa, często przestaje być używany.

Raporty z takich zestawień buduje się zwykle w narzędziu raportowym, a przykład drogi od zapytania SQL do wydruku pokazuje artykuł o SQL Report Builder i raportach RDL. Funkcje nadzoru w Studio RMA.net opisuje producent na stronie aplikacji do nadzorowania reklamacji. Definicję numeru RMA i zasady jego nadawania wyjaśnia tekst o numerze RMA, a ogólne tło logistyki zwrotnej podaje artykuł o Return Merchandise Authorization. Przejrzystość statusu dla klienta jest osobnym tematem, omówionym w tekście o programie do zarządzania reklamacjami.