Proces dla e-deklaracji – czyli pytanie z odpowiedzią

Rozliczyłaś/eś już pit? Rozliczasz się razem czy osobno? Czy są jakieś ulgi? Czy będzie zwrot czy kwota do zapłaty? Do kiedy dokładnie jest termin? Gdzie jest mój urząd? Czy rozliczasz się elektronicznie? Te i wiele pytań pojawia się obecnie w naszych rozmowach. Przyczyna jest prosta. Już niedługo kończy się termin, kiedy można składać roczne deklaracje podatkowe.

Wielu podatników zdecyduje się po raz pierwszy lub kolejny złożyć swoją deklarację elektronicznie. W tym celu skorzysta z aplikacji w przeglądarce lub pobranej na komputer, wypełni dane, a następnie wybierze “Złóż deklarację”. Na koniec będzie czekać na otrzymanie tzw. UPO, czyli potwierdzenia złożenia deklaracji. W zależności od podsumowania na deklaracji, będzie musiał zapłacić brakującą kwotę podatku lub czekać na zwrot nadpłaty. Wariant takiego procesu opisany jest na poniższym diagramie.

Na diagramie, jak widać, proces został przedstawiony od strony aplikacji. Dodany został na nim również krok dot. komunikacji z serwisem ministerstwa, obsługującym elektroniczne składanie deklaracji. Jest też krok weryfikacyjny, który w takich aplikacjach występuje – dotyczący dochodu za rok poprzedzający rok, którego dotyczy składana deklaracja. Aplikacja przygotowuje komunikat z deklaracją (prawdopodobnie w xml) i wysyła żądanie (ang. request) jej przetworzenia przez serwis. Następnie czeka na odpowiedź (ang. response). Odpowiedź może wskazywać na przyjęcie deklaracji, poprawne jej przetworzenie czy błąd. Można powiedzieć, że jest to przykład zastosowania wzorca Pytanie-Odpowiedź (ang. request-response).

Aplikacja może prowadzić użytkownika przez wypełnienie deklaracji, sugerując ekranami lub pytaniami konkretne czynności lub też umożliwiać całkowicie samodzielne wypełnienie formularzy, podobnie jak w przypadku papierowej deklaracji. W trakcie wypełniania, może jedynie sprawdzać powiązania oraz zależności pól, a sprawdzanie konkretnych wartości jest dość ograniczone. Wypełnienie takiej deklaracji, mając pod ręką materiały źródłowe, trwa kilkanaście minut. Oczekiwanie na odpowiedź z serwisu to kilka minut. Można to zrobić w dowolnym, odpowiednim dla podatnika momencie. Nie musi także udawać się do urzędu, aby przekazać deklarację papierową.

Reklama

Inteligentne podlewanie i nie tylko

Chyba prawie każdy wyjeżdzając na dłuższy wyjazd, zastanawiał się co się stanie z kwiatami na balkonie, w domu, czy ogrodzie. Jedni stosują metody związane z automatycznymi zraszaczami lub nawodnieniem, inni z odwróconymi butelkami albo innymi systemami nawadniania mniej lub bardziej zautomatyzowanymi. Niektórzy w tym celu zatrudniają znajomych czy sąsiadów. Inni podlewają przed wyjazdem i myślą: „powinno starczyć”. Te bardziej lub mniej automatyczne są powiązane z dzisiejszym wpisem.

Wyobraźmy sobie, że każda skrzynka, donicznka lub istotny obszar ogródka ma zamontowany czujnik z identyfikatorem. Każdy czujnik jest odpytywany lub przesyła informacje do centralnego rejestru. Mechanizm kontrolny sprawdza reguły i informuje właściciela roślin o wystąpieniu określonych zdarzeń: np. skrzynka zawierająca kwiaty X ma za małą wilgotność. Skutkiem może być automatyczne nawodnienie, informacja do opiekuna lub inna czynność z góry określona. Pewnie takie rozwiązania w różnych wariantach już istnieją i są dostępne na rynku. Ideę takiej sytuacji obrazuje diagram.

Dane zbierane z czytników opariełaby się również na danych o powiązaniu czytnika z roślinami i danych o powiązaniu roślin z rekomendowaną wilgotnością. Wynik z czytnika, roślina, rekomendowana wilgotność – to trójka będąca podstawą podjęcia decyzji w ramach reguły. Podobnie jak w przypadku produktów w sklepie – identyfikator produktu, lokalizacja w sklepie – przy wykorzystaniu fal radiowych określana była aktualna zawartość koszyka. Zbieranie takich danych z czytników jest podstawą funkcjonowania tzw. Internetu Rzeczy (ang. Internet of Things/IoT).

Idea IoT zakłada, że każdy (możliwy do zidentyfikowania) przedmiot codziennego użytku (i nie tylko) może dostarczać danych, zarówno o użytkowniku, sposobie używania lub otoczeniu. Dane mogą trafiać do serwisu internetowego, gdzie są dostępne także dla innych użytkowników. Mogą zarówno potwierdzać przyjęte reguły, jak i je zmieniać. Mogą być używane do podejmowania decyzji albo do wyświetlania specyficznych informacji dla użytkowników serwisu (np. o zanieczyszczeniu powietrza na terenie miasta).

Od początku do końca, czy na odwrót?

Jakiś czas temu opisywałem na prostym przykładzie zakupów jakie zależności w projekcie występują między czasem, zakresem oraz budżetem. Zwiększając listę zakupów nastąpi prawodpodobnie wzrost pozostałych wartości (czasu realizacji oraz potrzebnego budżetu). Ograniczenie z kolei czasu lub budżetu może się wiązać z ograniczeniem możliwych do wykonia zakupów. Takie podejście jest specyficzne dla waterfallowego zarządzania projektami.

Załóżmy jednak teraz, że mamy listę zakupów i wiemy ile z jej pozycji możemy zrealizować w określonej jednostce czasu. Dzieląc wielkość listy zakupów przez ilość pozycji (prędkość) otrzymujemy wielkrotność jednostek czasu (liczbę iteracji), którą potrzebujemy do zrealizowania pełnych zakupów. Jest to tzw. planowanie z ustalonym zakresem – diagram A.

Postawmy się jednak teraz w sytuacji, gdy narzucono mam termin, do którego mamy wykonać zakupy. W takiej sytuacji, znając prędkość zakupów, jesteśmy w stanie określić jaki zakres listy jesteśmy w stanie zrealizować w narzuconym czasie. Dzieląc dostępny czas przez jednostki czasu, otrzymujemy wielkrotność prędkości realizacji (liczbę iteracji). W takiej sytuacji istotne jest określenie kryteriów szacowania wartości/użyteczności poszczególnych pozycji listy. W szczególności, gdy z wyliczeń okaże się, że realizacja pełnej listy nie jest możliwa w zaplanowanym czasie. Jest to tzw. planowanie z ustaloną datą – diagram B.

Takie sposoby planowania stosuje się w projektach opartych o metodyki zwinne (m.in. Agile). W przypadku tych metodyk, odpowiednikiem prędkości zakupów jest prędkość realizacji/zespołu liczona dla jednostki czasu, jaką jest długość tzw. sprint. Sama prędkość realizacji/zespołu jest liczona w tzw. story point-ach, w których wycenia się (w ramach wyceny zakresu) także poszczególne wymagania, będące odpowiednikami pozycji zakupów.

Opisane metody można zaprezentować jak na powyższym diagramie. Pierwsze co się rzuca w oczy to fakt, że ten sam element – lista zakupów/zakres realizacji – jest w pierszym (diagram A) przypadku wejściem dla procesu, a dla drugiego (diagram B) – wyjściem. W przypadku ustalonej (planowanej) daty zakończenia – sytuacja jest wręcz odwrotna, w pierwszym przypadku (diagram A) jest wyjściem, a w drugim (diagram B) wejściem. Procesy opierają się na tych samych podstawach – m.in. prędkości realizacji/zespołu oraz zakresie realizacji (oczekiwanym/pełnym).

Autentykacja lub/i autoryzacja – razem czy osobno?

Wiele aplikacji dostępnych przez przeglądarkę lub jako osobny program wymaga przejścia ekranu logowania się. Należy podać login/identyfikator/e-mail oraz hasło. System w odpowiedzi sprawdza, czy dane są prawidłowe. W przypadku błędu weryfikacji, nie pozwala na przejście dalej. Jeżeli są poprawne, udostępnia aplikację. Nie wszystkie jednak opcje mogą być dostępne dla danego użytkownika – choćby w aplikacji próbnej lub z rozbudowaną hierarchią użytkowników.

Pierwszy etap to tzw. autentykacja (ang. authentication) lub bardziej po polsku uwierzytelnianie użytkownika. Jest to czynność realizowana na bazie komunikacji użytkownika i systemu, mająca sprawdzić, czy użytkownik (osoba logująca się) jest tym, za kogo się podaje. Weryfikacja polega na sprawdzeniu jest autentyczności. Odbywa się to przy założeniu, że tylko określony użytkownik zna/posiada parę login/hasło lub dodatkowe elementy używane przy identyfikacji (odpowiedzi na zdefiniowane pytania, tokeny). Czasami ta czynność może odbywać się w sposób niezauważalny dla użytkownika (w zależności od zastosowanych mechanizmów). Jest to pierwszy krok na poniższym diagramie.

Drugi etap to autoryzacja, czyli sprawdzenie, czy ropoznany użytkownik ma uprawnienia do dostępu/wykorzystania lub innej czynności wykonywanej na danym obiekcie. O autoryzacji pisałem w poprzednim wpisie (czyli o umożliwieniu instalacji na stacji roboczej). Jest to trzeci krok na powyższym diagramie.

Trudno mówić o poprawnym przeprowadzeniu procesu autoryzacji bez informacji o użytkowniku, w “imieniu” którego ten proces ma zostać przeprowadzony. Można stwierdzić, że wynik procesu uwierzytelniania jest wejściem dla procesu autoryzacji. Z tego wniosek, że te procesy przeważnie występują razem, o ile aplikacja, system informatyczny lub dane takiej kontroli wymagają. W pewnych sytuacjach, autoryzacja może nastąpić jedynie o dane identyfikacyjne skąd nastąpiło żądanie – np. określony numer MAC komputera przy dostępie do sieci bezprzewodowej. Choć w sumie weryfikacja numerów MAC jest pewnym rodzajem autentykacji (podobnie jak para login/hasło lub linie papilarne zapisane w bazie).

Zainteresowanych szczegółami różnych sposobów autoryzacji oraz uwierzytelniania odsyłam na przykład do książki „Bezpieczeństwo danych w systemach informatycznych„.

Komunikacja jako efekt procesu

Ostatnio na blogu „Analiza systemowa”  przeczytałem artykuł „Nie ulec pokusie zadowolenia wszystkich”  i zacząłem się zastanawiać co poza wymienionymi krokami oraz wskazanymi w komentarzu można zrobić.

Pierwsza myśl to kwestia zarządzania ryzykiem, do czego można podejść zgodnie z PROCĄ, o której pisałem wcześniej. W szczególności ma to istotne znaczenie, gdy wchodzimy z nowym produktem, do nowej grupy odbiorców na danym rynku lub chcemy zaistnieć na nowym rynku. To, co może się wydarzyć na rynku lub „wrócić” w postaci informacji zwrotnej od użytkowników powinno być przedmiotem zarządzania ryzykiem. Np. Jednym z zagrożeń może być niewłaściwe wykorzystanie produktu lub nieprzyjęcie się produktu na rynku. Wskazane w komentarzu do artykułu pojawienie się substytutów także jest pewnym ryzykiem. Dla każdego zidentyfikowanego w ten sposób ryzyka można przygotować odpowiednią strategię postępowania i z dużym prawdopodobieństwem można powiedzieć, że nie będzie to akceptacja. Bardziej skłaniałbym się ku zapobieganiu. A co może tym pomóc? Właśnie druga kwestia, o której warto pamiętać…

Komunikacja. Wdrożenie produktu, począwszy od jego opracowania, przez przygotowanie po działania promocyjne jest swego rodzaju procesem. Na każdym jego etapie konieczne jest patrzenie przez pryzmat tego, co chcemy zakomunikować i komu. Powyższy diagram prezentuje odbiorców komunikacji i przykładowe mechanizmy wspierające. Spirala na środku diagramu wskazuje, że komunikacja inicjowana jest wewnętrz firmy, najpierw w kierunku pracowników, którzy powinni rozumieć po co i co zamierza firma stworzyć i dla kogo, wprowadzane są badania rynku itd. Jest to „proces” ciągły, który jest inicjowany, a jego efekty są wykorzystywane w procesie wdrożenia nowego produktu i usługi. Komunikacja na poszczególnych ramieniach trójkąta musi być spójna. Nie ma nic gorszego jak sytuacja, gdy klient, który zachęcony reklamą dowiaduje się od pracownika firmy, że jest inaczej. Wspomniana trójca czas, koszt oraz jakość określa również ramy działań związanych z komunikacją, ponieważ komunikacja też kosztuje i jest kosztem wdrożenia lub utrzymania rozwiązania produktu, może już nie samego projektu, ale jest zestawiana z osiąganymi korzyściami z produktu.

Dynamika – szczegółowość opisu

Trochę zainspirowany komentarzem do jednego z poprzednich wpisów, prowadzącym do artykułu „Diagram klas – czyli „reinżynieria” analizy biznesowej” (z it-consulting.pl/blog), a trochę w wyniku krystalizacji pomysłu na kolejny wpis, postanowiłem spojrzeć na diagram klas z poprzedniego wpisu w sposób bardziej dynamiczny. Jest to o tyle ważne, że sposób prezentacji diagramu klas i wykorzystane konstrukcje wpływają później na sposób implementacji takiego rozwiązania, przedstawiającego w bardziej lub mniej szczegółowy wymagania użytkownika. Chciałbym się skupić na elemencie „Zamówienia” wraz z operacjami wykonywanymi na nim.

Zastanówmy się najpierw czego oczekuje użytkownik systemu do składania zamówień od tego elementu. Odpowiedź nasuwa się sama, chce zaspokoić, w szczególności, dwie swoje potrzeby:

• potrzebę dodania produktu do zamówienia oraz
• potrzebę (ewentualnego) usunięcia produktu z zamówienia

Po prostu wyszukuje produkt i dodaje go do zamówienia, bądź wchodzi do „zamówienia” (listy dodanych produktów) i usuwa dany produkt. Świadomie nie wpisałem powyżej zmiany ilości, ponieważ tak naprawdę zwiększenie/zmniejszenie ilości produktu można zinterpretować jako dodanie/usunięcie produktu. Zostańmy jednak przy operacjach dodaj/usuń.

Użytkownik wybiera daną opcję i nie interesuje go co się dzieje wewnątrz systemu. Poniższy diagram w notacji BPMN jest próbą zaprezentowania tego, co mogłoby się dziać.

Diagram obrazuje, że system może kilka różnych czynności wykonać po wybraniu opcji przez użytkownika. Kilka kwestii wymaga jednak komentarza. Na poziomie Klienta zostały przedstawione operacje na najwyższym poziomie tożsame wręcz przyciskom w systemie. Natomiast na poziomie Systemu pojawiają się operacje wskazane na diagramie klas. Użytkownik dodaje produkt do zamówienia, określając jego ilość, a system tworzy pozycję na zamówieniu, dla danego produktu wraz z odpowiednią ilością. Pozycje zamówienia w tym wypadku nie są współdzielone (zastosowano kompozycję).

Można byłoby dalej dodać mechanizmy zabezpieczające przed dodaniem większej ilości produktu niż jest dostępna. Można także określić operacje proklienckie.  Wraz z kolejnymi zamówieniami sytuacja klienta w systemie oraz określonych produktów w pewnym sensie się zmienia. Zwiększając precyzję opisu wymagań można wskazywać kolejne ograniczenia czy też możliwości.

Rozbudowa opisu może przejść od typowej „narracji” (przykład w poprzednim wpisie), przez konkretne „scenariusze” (repezentowane przez tabele, diagramy) po „komunikację” (między elementami, wymianę komunikatami, co częściowo zostało pokazane w niniejszym wpisie).