Silesian SolutionsPorozmawiajmy o projekcie
Wszystkie realizacje

System dedykowany

BLS Katowice

Platforma do prowadzenia likwidacji szkód dla biura BLS Katowice. Strona firmowa i część robocza to jedna aplikacja. Rekordem centralnym jest sprawa, więc statusy, terminy i dokumenty podzielone na typy prowadzi się przy niej.

Strona BLS Katowice: opis biura, zakres likwidacji szkód i przycisk prowadzący do platformy.
Strona publiczna z wejściem do platformy. Zrzut w treści strony pokazuje pulpit po zalogowaniu.

Strona firmowa i platforma do prowadzenia spraw to w BLS Katowice jedna aplikacja, nie dwie - ten sam build obsługuje gościa czytającego stronę publiczną i pracownika prowadzącego likwidację szkody. Biuro dostało narzędzie, w którym sprawa, jej dokumenty i jej status stoją w jednym miejscu. Wcześniej obieg opierał się na skrzynce pocztowej.

Jedna aplikacja, dwie role

Frontend to pojedyncza aplikacja w Angularze, z komponentami PrimeNG i tłumaczeniami przez ngx-translate. Routing rozdziela dwa światy. Gość dostaje strony publiczne: stronę główną, opis współpracy i kontakt. Dalej zaczyna się część robocza z pulpitem, sprawami i archiwum.

Ekran logowania do platformy likwidacji szkód BLS Katowice
Wejście do platformy. Ten zrzut kończy się na logowaniu.

Korzyść widać dopiero przy utrzymaniu. Jeden build, jeden zestaw zależności, jedno wdrożenie, czyli koszt policzony raz zamiast dwa razy. Takie granice systemu wyznaczamy przy architekturze IT i modernizacji. Formularz kontaktowy ze strony publicznej i sprawa prowadzona dalej mówią do tego samego API. Zgłoszenie nie zmienia po drodze formatu ani systemu.

Zaplecze i dokumenty sprawy

Backend stoi na Symfony z Doctrine i bazą MySQL, a REST wystawia przez FOSRestBundle. Sprawa jest tu rekordem centralnym. Wokół niej gromadzą się daty, dokumenty i osoby, które ją prowadzą.

Diagram platformy BLS Katowice: przeglądarka gościa i pracownika, jeden build w Angularze, API w Symfony i baza MySQL ze sprawą jako rekordem centralnym
Ten sam build obsługuje oba tryby, a oba mówią do tego samego API i tej samej bazy.

Dokumentacja jest przypięta do sprawy i podzielona na typy. Nie leży w jednym worku z załącznikami, więc szukanie opinii czy kosztorysu nie polega na przeglądaniu listy plików po nazwach. Komplet dokumentów sprawy pobiera się jedną paczką, bez klikania po pozycjach.

Przypisanie sprawy woła do osoby prowadzącej mailem, z numerem sprawy w temacie. Powiadomienie SMS-em jest w kodzie przygotowane i wyłączone, więc kanałem, który realnie działa, jest poczta. Powód jest terenowy. Rzeczoznawca jedzie na oględziny i nie siedzi przy skrzynce.

Co z tego wynika

Sprawa, dokumenty i terminy siedzą w jednym rekordzie. Na pytanie o stan likwidacji biuro odpowiada z jednego ekranu, bez zestawiania danych ze skrzynki, dysku i arkusza.

Dokumentacja przestała być zbiorem załączników nazwanych od przypadku. Jest przypięta do sprawy i podzielona na typy, więc opinia czy kosztorys znajdują się bez przeglądania listy plików.

Strona firmowa i platforma to ten sam build, więc zależności, wdrożenie i utrzymanie liczą się raz.

Wykorzystane technologie

  • Angular
  • Symfony
  • MySQL
  • Doctrine
  • PrimeNG

Zobacz wdrożenie