Rozliczenie usługi według zużycia: jak uzgodnić jednostkę i korektę danych

Klient otrzymuje rozliczenie usługi według zużycia i widzi wartość wyższą niż w poprzednim okresie. Pyta, skąd pochodzi liczba. Obsługa znajduje dwa odczyty, ale jeden dotyczy wymienionego urządzenia, a drugi został później poprawiony. Bez informacji o źródle i okresie trudno wyjaśnić rachunek, nawet jeśli sam wzór obliczenia jest prosty.

System rozliczeń według zużycia powinien wiązać odczyt z właściwą umową, jednostką, okresem i źródłem. Potrzebuje także procedury wyjaśniania braków oraz korekt. Rodzaj danych i zasady rozliczenia zależą od konkretnej usługi, umowy i właściwych przepisów.

Jeśli planujesz taki system, wyślij brief z opisem usługi, jednostki i sposobu przekazywania danych. Wystarczy fikcyjny przykład. Nie przesyłaj danych klientów ani poufnych dokumentów.

Nazwij to, co jest mierzone

Wyobraźmy sobie firmę rozliczającą usługę na podstawie pomiaru. Dla każdego klienta zapisuje urządzenie, okres i odczyty. To przykład projektowy, nie opis rzeczywistego rozliczenia ani określonej taryfy. Zanim powstanie ekran faktury, zespół powinien ustalić, co oznacza pojedyncza wartość i kto odpowiada za jej poprawność.

Czy urządzenie podaje stan narastający, czy wartość zużycia dla danego okresu? Czy liczba dotyczy jednego punktu, całej lokalizacji czy jednego z kilku urządzeń klienta? Czy odczyt przesyła dostawca pomiaru, pracownik czy sam klient? Odpowiedzi wyznaczają sposób obliczenia i rodzaj pytań, które obsługa będzie mogła wyjaśnić.

Jednostka musi być widoczna przy wartości oraz zgodna z definicją w źródle. Jeśli system przyjmuje dane w jednej jednostce, a prezentuje w innej, przeliczenie i sposób zaokrąglania trzeba uzgodnić dla usługi. Liczba bez jednostki może wyglądać poprawnie na wykresie, ale nie pozwala porównać dwóch odczytów.

W artykule o definicjach wskaźników opisujemy, jak ustalić znaczenie wyniku przed jego pokazaniem. Przy rozliczeniu do tej definicji dochodzą umowa, okres oraz sposób postępowania z korektą. Nie zakładajcie, że nazwa pola „zużycie” wyjaśnia te wszystkie elementy.

Przed projektowaniem pól poproście właściciela procesu o przejście jednego rozliczenia od źródła pomiaru do dokumentu dla klienta. Zapiszcie, gdzie pojawia się jednostka, kto sprawdza brak wartości i w którym miejscu można wyjaśnić pytanie. Jeśli uczestnicy używają tej samej nazwy dla różnych wielkości, doprecyzujcie ją na przykładzie. Uzgodniony słownik ułatwia późniejsze porównywanie wyników.

Powiąż odczyt z właściwym punktem i czasem

Każdy odczyt powinien być przypisany do właściwego punktu pomiaru, urządzenia i okresu. Jeżeli klient ma kilka lokalizacji, nazwa firmy nie wystarczy do rozpoznania źródła danych. Osoba wyjaśniająca potrzebuje identyfikatora używanego w procesie oraz informacji, od kiedy dane urządzenie obsługuje dany punkt.

Wymiana urządzenia wymaga osobnego zdarzenia. Przedstawcie stary i nowy identyfikator, datę zmiany oraz odczyty potrzebne do rozliczenia zgodnie z zasadami usługi. Nie należy odejmować wartości z różnych urządzeń tak, jakby pochodziły z jednego ciągłego licznika. Kolejność działań i potrzebne dokumenty ustala właściciel procesu.

Zapiszcie zarówno moment, którego dotyczy pomiar, jak i moment otrzymania danych, jeśli oba są istotne. Odczyt przesłany później może odnosić się do wcześniejszego dnia. Bez rozróżnienia tych dat system może przypisać liczbę do niewłaściwego okresu albo potraktować opóźniony pomiar jako nowy.

Gdy dane pochodzą z kilku źródeł, ustalcie ich rolę i sposób rozstrzygania sprzeczności. W artykule o źródłach danych w integracji pokazujemy, jak przypisać odpowiedzialność za wartości. W przypadku pomiaru potrzebna jest również historia wskazująca, która wersja została przyjęta do danego rozliczenia.

Przy przeniesieniu punktu pomiaru do nowej umowy nie zakładajcie, że całą historię można przypisać nowemu odbiorcy. Widoczność wcześniejszych danych oraz ich przechowywanie zależą od celu i zasad organizacji. System powinien umieć rozróżnić ciągłość pomiaru od prawa konkretnej osoby do przeglądania dokumentów. Uprawnienia trzeba sprawdzić także po zmianie właściciela lub zarządcy.

Uzgodnij okres i sposób obliczenia

Okres rozliczeniowy powinien mieć jednoznaczny początek i koniec. Przy projektowaniu trzeba ustalić, jak traktować odczyt wykonany blisko granicy okresu oraz zmianę umowy w jego trakcie. Odpowiedź wynika z zasad usługi i używanych danych. Nie powinna zależeć od tego, jak programista nazwał kolumnę w bazie.

Jeśli rozliczenie wynika z różnicy dwóch wskazań, pokażcie obie wartości oraz sposób przypisania ich do okresu. Zespół powinien móc rozpoznać wymianę urządzenia, brak jednego odczytu i sytuację, w której wskazania nie pasują do przyjętego modelu. Automatyczny wynik nie powinien ukrywać takiego wyjątku.

Przed wprowadzeniem kwoty trzeba ustalić warunki umowy i właściwe reguły dla danej usługi. Cena może zależeć od okresu lub innych uzgodnionych parametrów. Artykuł nie ustala taryf ani opłat. Interfejs powinien pokazać osobie uprawnionej wersję danych i zasad wykorzystanych do wyliczenia, bez zgadywania brakujących wartości.

Jeśli wyliczenie wymaga zaokrąglenia, uzgodnijcie moment jego wykonania oraz sposób prezentacji danych. Zaokrąglenie poszczególnych pozycji przed zsumowaniem może dać inny wynik niż zaokrąglenie sumy. To przykład decyzji projektowej, którą trzeba sprawdzić w warunkach danej usługi i odpowiednich przepisach.

Przy zmianie zasad w trakcie okresu rozliczeniowego potrzebny może być podział danych na części albo inny sposób wskazany w umowie. Przed obliczeniem trzeba ustalić, czy dostępne pomiary pozwalają wykonać taki podział i kto może go potwierdzić. Jeśli danych brakuje, nie należy wymyślać szczegółowej wartości tylko dlatego, że formularz wymaga liczby. Sprawa powinna trafić do ustalonego procesu wyjaśnienia.

Brak odczytu to osobny stan

Gdy pomiar nie dotrze, aplikacja nie powinna automatycznie zapisywać zera. Zero oznacza konkretną wartość. Brak danych oznacza, że system nie ma potwierdzonego pomiaru. Potrzebne jest wskazanie przyczyny, jeśli jest znana, oraz osoby odpowiedzialnej za kolejny krok.

W zależności od procesu może pojawić się prośba o ponowny odczyt, weryfikację urządzenia albo zastosowanie przewidzianej metody rozliczenia. Warunki takiego postępowania trzeba sprawdzić dla usługi i umowy. Jeśli wykorzystywane jest oszacowanie, użytkownik powinien móc odróżnić je od rzeczywistego odczytu oraz zobaczyć podstawę przyjętej wartości.

Jeśli dane napływają przez integrację, pokażcie, czy brak wynika z niedostępności źródła, czy źródło odpowiedziało, ale nie zawiera oczekiwanego pomiaru. W artykule o awarii integracji opisujemy przypisanie odpowiedzialności za wyjaśnienie problemu. Pusta tabela nie wystarczy jako instrukcja dla obsługi.

Pracownik zgłaszający brak powinien widzieć powiązane miejsce i okres, a nie wyłącznie techniczny kod błędu. Jeżeli kilka odczytów nie dotarło z tego samego źródła, można pogrupować je do analizy, zachowując możliwość przejścia do każdego punktu. Zbiorczy alert nie zastępuje ustalenia, które rozliczenia czekają na decyzję.

Przy odczycie wprowadzanym ręcznie pokażcie jednostkę obok pola i zasady wpisywania liczb. Jeśli wartość różni się od poprzedniej w sposób wymagający sprawdzenia, komunikat może poprosić o ponowną weryfikację. Nie musi z góry zakładać pomyłki. Osoba wprowadzająca powinna móc wyjaśnić sytuację, a pracownik zatwierdzający - zobaczyć tę informację przy decyzji.

Zachowaj historię korekty

Korekta może wynikać z błędnego odczytu, pomyłki w przypisaniu punktu albo późniejszego otrzymania wiarygodnych danych. Każdy przypadek wymaga wyjaśnienia. System powinien pokazać wartość wcześniej używaną, proponowaną zmianę, jej źródło oraz osobę odpowiedzialną za zatwierdzenie. Nie należy po cichu nadpisywać liczby, która była podstawą wcześniejszego rozliczenia.

Urząd Regulacji Energetyki opisuje przypadki korekty należności za energię elektryczną po stwierdzeniu błędów pomiaru lub odczytu. Wyjaśnienie URE dotyczy wskazanej w nim usługi i przepisów. Nie stanowi uniwersalnej procedury dla wszystkich rozliczeń opartych na zużyciu.

Osoba zatwierdzająca powinna widzieć skutki proponowanej zmiany dla odpowiedniego okresu i powiązanych dokumentów. Jeśli korekta dotyczy tylko jednego punktu, system nie powinien automatycznie zmieniać pozostałych lokalizacji klienta. W artykule o historii zmian opisujemy powiązanie decyzji ze źródłem oraz wcześniejszym stanem.

Po zatwierdzeniu sprawdźcie, które systemy otrzymały aktualizację i czy informacja dla klienta odpowiada rzeczywistemu stanowi sprawy. Samo wysłanie korekty do innego narzędzia nie oznacza jej przyjęcia. Jeśli jeden etap nie został potwierdzony, potrzebna jest kolejka do wyjaśnienia oraz osoba odpowiedzialna za dalszą komunikację.

Jeżeli zmianę proponuje integracja, pokażcie jej źródło i czas otrzymania danych. Pracownik powinien móc przejść do materiału potwierdzającego oraz odrzucić propozycję, gdy dotyczy innego punktu. Ustalcie również sposób postępowania z kolejną korektą tej samej wartości. Historia powinna pozwolić odróżnić anulowaną propozycję od zmiany faktycznie zastosowanej w rozliczeniu.

Wyjaśnij wynik klientowi i obsłudze

Widok klienta powinien pokazywać okres, jednostkę, wykorzystane wartości oraz sposób odnalezienia dokumentu lub zgłoszenia pytania. Szczegółowość zależy od usługi i odbiorcy. Zbyt techniczny identyfikator urządzenia nie zastąpi nazwy lokalizacji, a sama nazwa nie zawsze pozwoli obsłudze jednoznacznie znaleźć punkt.

Jeżeli wartość jest szacowana lub oczekuje na potwierdzenie, nazwijcie ten stan. Nie przedstawiajcie roboczego wyniku jako ostatecznego. Klient powinien wiedzieć, czy może przekazać pytanie lub poprawne dane oraz co stanie się po ich otrzymaniu. Komunikat o przyjęciu zgłoszenia nie oznacza jeszcze zatwierdzenia korekty.

Pracownik obsługi może potrzebować więcej informacji niż klient, ale zakres dostępu powinien wynikać z jego zadania. W artykule o rolach i uprawnieniach omawiamy rozdzielenie widoczności danych i możliwości ich zmiany. Przy rozliczeniu inna osoba może odpowiadać za przyjęcie pytania, a inna za zatwierdzenie korekty.

Przed publikacją podglądu poproście osobę niezwiązaną z projektem o odpowiedź na proste pytanie: z jakich wartości i za jaki okres wynika rozliczenie? Jeśli musi zgadywać znaczenie jednostki lub nie potrafi znaleźć informacji o korekcie, poprawcie widok. O przygotowaniu takich prób piszemy w artykule o testowaniu prototypu.

Sprawdź wyjątki przed odbiorem

Przygotujcie fikcyjne dane dla zwykłego okresu, braku odczytu, wymiany urządzenia i poprawionego pomiaru. Dla każdej sytuacji zapiszcie oczekiwany wynik oraz osobę uprawnioną do decyzji. Sprawdźcie, czy wcześniejsze rozliczenie pozostaje możliwe do wyjaśnienia po zatwierdzeniu korekty.

W środowisku testowym integracji odtwórzcie spóźniony odczyt i niedostępne źródło. Zweryfikujcie również ponowne dostarczenie tej samej informacji oraz moment potwierdzenia zapisu. Próba w środowisku testowym nie dowodzi sama w sobie poprawnego działania rzeczywistego rozliczenia po wdrożeniu.

W kryteriach odbioru zapiszcie także zadanie dla obsługi: odnalezienie źródła konkretnego wyniku oraz wyjaśnienie, kto zatwierdził zmianę. W oprogramowaniu na zamówienie projekt rozliczenia powinien wynikać z konkretnych danych, zasad usługi i odpowiedzialności zespołu.

W próbie uwzględnijcie również dwa punkty o podobnych nazwach i dwa urządzenia przypisane kolejno do jednego miejsca. Sprawdźcie, czy pracownik potrafi wskazać odpowiedni okres oraz źródło każdej wartości. Jeżeli korekta oczekuje na zatwierdzenie, klient i obsługa powinni widzieć stan zgodny z ich rolą. Po zatwierdzeniu porównajcie wynik w systemie źródłowym, panelu obsługi i widoku klienta.