U dostawcy wody, energii czy ciepła faktura to tylko ostatni ekran długiego procesu. Zanim klient zobaczy kwotę, system musi przyjąć odczyt z licznika, sprawdzić jego sensowność, przyłożyć właściwą taryfę, rozliczyć zaliczki i dopilnować płatności. System billingowy dla mediów to w praktyce kilka silników działających razem, a nie generator PDF-ów. Gdy któryś się myli, błąd trafia prosto do klienta.
Z naszego doświadczenia najwięcej problemów bierze się nie z samego naliczania, lecz z brzegowych przypadków: zmiana taryfy w połowie okresu, wymiana licznika, korekta odczytu sprzed trzech miesięcy, przepisanie umowy na nowego właściciela. Nawet jeśli nie pokazujemy tu case’u z branży mediów, obsadzamy takie projekty ludźmi, którzy budowali złożone systemy rozliczeniowe i integracje z urządzeniami - w modelu wzmocnienia zespołu lub zespołu dedykowanego.
Dlaczego rozliczenia mediów są tak złożone?
Rozliczenia mediów wyglądają prosto tylko na slajdzie. W rzeczywistości splatają się w nich trzy osie zmienności naraz: czas (okresy, odczyty, korekty wstecz), produkt (taryfy, grupy taryfowe, składniki stałe i zmienne) oraz klient (gospodarstwo domowe, wspólnota, firma, odbiorca na granicy dwóch stref).
Do tego dochodzi regulator. Ceny bywają zatwierdzane administracyjnie i zmieniają się w trakcie okresu, a dostawca musi przeliczyć zużycie proporcjonalnie i udowodnić, skąd wzięła się każda pozycja na fakturze. Ten wymóg audytowalności sprawia, że liczy się nie tylko wynik, ale i ślad do niego prowadzący.
Jak działa silnik taryf i fakturowanie?
Sercem całości jest silnik taryf. To on zamienia surowe zużycie w kwotę, stosując rozgałęzione reguły: stawkę za jednostkę, opłatę stałą, opłatę mocową czy abonamentową, progi, strefy czasowe, bonifikaty, ulgi dla wybranych grup odbiorców. Projektujemy go tak, żeby reguły dało się zmieniać bez przepisywania kodu - jako konfigurację, nie zaszyte na sztywno wyjątki.
Na silnik nakłada się warstwa fakturowania. Tu pilnujemy między innymi:
- wariantów dokumentu - faktura prognozowana, rozliczeniowa, korygująca, duplikat,
- proporcjonalnego naliczania przy zmianie taryfy lub ceny w trakcie okresu,
- rozliczenia zaliczek i prognoz względem rzeczywistego zużycia,
- spójności numeracji i danych wymaganych przez księgowość i regulatora.
Każdą kwotę da się dzięki temu rozłożyć z powrotem na składniki - a o to prędzej czy później ktoś zapyta.
Jak przyjmujemy i walidujemy odczyty z liczników?
Opomiarowanie to miejsce, w którym dane wchodzą do systemu, i najczęstsze źródło błędnych faktur. Odczyty przychodzą dziś wieloma kanałami: zdalnie przez AMR/AMI, od inkasenta, z aplikacji klienta. Zanim trafią do naliczenia, muszą przejść walidację - zestaw kontroli wyłapujących to, co fizycznie nie ma prawa się zdarzyć:
- odczyt niższy niż poprzedni bez odnotowanej wymiany licznika,
- zużycie odstające od profilu danego punktu poboru,
- luki i duplikaty w szeregu odczytów,
- przepełnienie licznika i poprawne jego rozpoznanie.
Tam, gdzie realnego odczytu brakuje, wchodzi szacowanie - projektujemy je jawnie, na podstawie historii zużycia i profilu odbiorcy, i oznaczamy pozycję jako prognozę, którą kolejny rzeczywisty odczyt bezboleśnie koryguje.
Jak zorganizować płatności i inkaso?
Gdy faktura jest poprawna, zaczyna się druga połowa pracy: doprowadzić pieniądze do kasy i powiązać wpłatę z właściwą należnością. Spinamy w tej warstwie kanały płatności i automatyzujemy uzgadnianie wpłat z należnościami, z obsługą płatności masowych, poleceń zapłaty i nadpłat. Projektujemy reguły kolejności zaspokajania (co spłacamy najpierw: odsetki, zaległość, bieżącą fakturę) oraz miękką ścieżkę monitów - przypomnienie, wezwanie, dopiero potem twarde kroki. Dobrze ułożone inkaso odciąża biuro obsługi, bo większość spraw domyka się sama.
Jak obsłużyć dług i rozłożenie na raty?
Część odbiorców zawsze będzie zalegać - to nie wyjątek, lecz stały element modelu. Dlatego obsługę długu traktujemy jako osobny proces, a nie doklejkę do fakturowania. System musi prowadzić klienta przez etapy windykacji miękkiej, naliczać odsetki według właściwych reguł i umożliwiać zawarcie ugody lub harmonogramu ratalnego.
Harmonogram rat bywa podstępny: klient spłaca stare zadłużenie i jednocześnie generuje nowe faktury, a jedna nieopłacona rata może zrywać całą ugodę. Modelujemy te zależności wprost, żeby saldo klienta było jednoznaczne, a konsultant widział pełny obraz.
Jak dać klientom samoobsługę zużycia?
Każda sprawa, którą klient załatwi sam, nie trafia na infolinię. Dajemy więc odbiorcy portal i aplikację pokazujące więcej niż samą kwotę do zapłaty:
- historię zużycia w czytelnej formie, z porównaniem okresów,
- możliwość podania odczytu z telefonu, od razu po walidacji,
- faktury i płatności online w jednym miejscu,
- zgłoszenie sprawy bez telefonu do biura obsługi.
Samoobsługa działa jednak tylko wtedy, gdy stoi na tych samych danych co billing - jako widok na ten sam rdzeń, a nie osobna wysepka z własnymi liczbami.
Jak zintegrować billing z opomiarowaniem i ERP?
System billingowy nigdy nie stoi sam. Z jednej strony łączy się ze światem pomiarów - głowicami AMI, systemami akwizycji odczytów, czasem wprost z koncentratorami danych. Z drugiej rozmawia z ERP i księgą główną, gdzie lądują przychody i należności.
Spinamy te światy przez dobrze opisane interfejsy i kolejki zdarzeń, tak aby odczyt, faktura i wpłata płynęły między systemami bez ręcznego przeklejania. Pilnujemy przy tym jednego źródła prawdy dla każdej danej - żeby saldo w billingu i w ERP nigdy nie opowiadało dwóch różnych historii. To zwykle najbardziej newralgiczny element całego projektu.
Jakie kompetencje wnosimy do projektu billingowego?
Taki projekt nie potrzebuje „programistów w ogóle”, tylko składu pod specyfikę rozliczeń. Najczęściej zestawiamy:
- architekta rozumiejącego domenę billingu, taryf i danych pomiarowych,
- backendowców do silnika taryf, fakturowania i integracji,
- specjalistę od integracji i danych (AMR/AMI, ERP, strumienie odczytów),
- frontend / mobile do portalu i aplikacji samoobsługowej,
- QA nastawione na przypadki brzegowe i zgodność naliczeń.
Kompetencje weryfikujemy przed startem, a skład skalujemy w rytm projektu - od małego zespołu rozpoznającego dziedzinę po pełen zespół dedykowany.
Jak robimy to w RITS?
Działamy jako partner nearshore z Polski, który wchodzi w projekt kompetencją, a nie gotową „pudełkową” platformą. Opieramy się na doświadczeniu w budowie złożonych systemów transakcyjnych oraz integracji z urządzeniami i systemami przemysłowymi i przenosimy je na grunt mediów.
Najczęściej wchodzimy w jednym z dwóch wariantów: jako zespół dedykowany budujący dedykowane oprogramowanie billingowe od fundamentów albo jako wzmocnienie zespołu, które dokłada brakujące kompetencje tam, gdzie wasz zespół pracuje nad własnym systemem. Gdy ma to sens, dokładamy warstwę AI - na przykład do wykrywania anomalii w zużyciu - ale zawsze jako element procesu, nie hasło na slajdzie.
Od czego zacząć budowę rozliczeń i opomiarowania?
Zacznij od jednej, kompletnej ścieżki: od odczytu, przez walidację i taryfę, aż po fakturę i płatność dla jednej grupy taryfowej. Przejście jej do końca ujawni więcej prawdy o waszych danych niż najdłuższa specyfikacja i wyznaczy architekturę oraz potrzebne role. Różnice między współpracą projektową, zespołem dedykowanym a wzmocnieniem zespołu rozłożyliśmy na czynniki pierwsze w artykule o modelach współpracy IT.
Budujesz lub przebudowujesz rozliczenia i opomiarowanie u dostawcy mediów? Porozmawiajmy - dobierzemy zespół i architekturę pod Twój system billingowy.