Posted by Kira on Marzec 30th, 2016

jestem właśnie w trakcie maratonu corocznych sprawozdań z działalności telekomunikacyjnej (brzmi dumnie, co nie?) dla uke. pamiętam jeszcze, jak całkiem niedawno narzekałam sobie, że to właśnie urząd komunikacji elektronicznej uparcie wymaga komunikacji analogowej. już mi przeszło. zaraz po tym jak zobaczyłam, w jaki sposób życzą sobie być informowani elektronicznie…

mam nieodparte wrażenie, że skoro urząd komunikacji elektronicznej siedzi sobie w biurowcu w warszawie, to planując sprawozdania wygląda po prostu przez okno. ignorując radośnie fakt, że w innych częściach kraju niekoniecznie są same blokowiska, a nawet, o zgrozo, zdarzają się osiedla domków jednorodzinnych.

mam również wrażenie, że uke nie za bardzo wie, co się naokoło niego dzieje. nawet mimo tego, że było wielokrotnie informowane. zapewne po prostu korespondencja trafia na inne piętro i tam się przepływ informacji kończy.

oba te czynniki mają olbrzymi wpływ na coś o nazwie siis

siis jest mówiąc w dużym skrócie raportem, z którego uke życzy sobie dowiedzieć się, jak wygląda infrastruktura i zasięgi poszczególnych operatorów. cel zasadniczo szczytny i absolutnie go popieram. metod zdobywania tych informacji, a właściwie zasad, według których należy je przekazywać – już nie. bo naprawdę, sądziłam już, że nie da się w tym kraju wymyślić systemu bardziej porąbanego, niż ten napisany dla zus-u. otóż owszem, da się.

i urząd komunikacji elektronicznej tego dokonał. nie wiem tylko czy z premedytacją, czy przypadkowo. zanim ktoś się doczepi – tak, zgłaszałam. nie ja jedna. efekt? nope, efektu nie było. a naprawdę wystarczyłoby zmienić zaledwie kilka zasad i wszystkim żyłoby się łatwiej, bez utraty jakości zebranych danych.

problem pierwszy: zakończenia sieci

tu wracamy do biurowców i blokowisk w warszawie, za oknami uke. tam zakończeniem sieci jest po prostu lokalizacja bloku, a ilu jest w nim klientów to sprawa odrębna. w każdym razie zasięg jest i jak go wykażemy, to zasadniczo mamy z głowy.

z osiedlami domków nie jest już tak kolorowo, jako że w tym przypadku zakończeniem sieci jest nadal konkretny budynek – tyle, że jednorodzinny. co w praktyce oznacza, że jeżeli na ulicy dworcowej jest 50 klientów, to każdy z nich musi być wykazany jako zakończenie sieci. faktycznie więc, w tej sytuacji uke życzy sobie po prostu listę klientów. pomijam, że nadal nie jestem pewna, jak to się ma do ochrony danych osobowych. grunt, że wszystkie formularze i pola trzeba wypełnić dla kilkuset, a często kilku tysięcy użytkowników sieci. po licho, że się tak zapytam, skoro zasięg na tej dworcowej ewidentnie jest i wystarczyłoby tak jak w blokach, podać liczbę końcowych klientów?

efektem takiego podejścia jest to, że operatorzy działający na terenach, gdzie osiedli domków jednorodzinnych jest multum, muszą rok w rok przeglądać pełną listę swoich klientów i “z palca” dodawać i usuwać poszczególnych z nich. tych, którzy doszli i tych, którzy odeszli. a rotacja jest zawsze, więc weź sobie przeglądaj każdą ulicę i wypełniaj.

problem drugi: coroczne zmiany w systemie plików

jakby mało było tego, że należy przejrzeć ręcznie listę zakończeń sieci (czyli klientów), należy też ściągnąć sobie tak zwany generator, który dostosowuje to, co było wpisane rok temu, do nowych pomysłów wdrożonych na ten rok. dlaczego? ano bo formularze i zasady ich wypełniania się zmieniają. tylko teoretycznie wygląda to tak, że wrzuca się do generatora dane zeszłoroczne, pyk! – i wyskakują obecne. nie. po drodze wywalanych jest sporo błędów, które nie zawsze da się poprawić automatycznie.

częściej wymaga to po prostu wejścia w dane pole excella i ręcznego wklepania tego, co z bliżej nieokreślonych powodów zostało oznaczone na czerwono. zapewne nikogo nie zdziwi fakt, że generator nie raczy poinformować co właściwie jest tam źle, więc trzeba to sobie samodzielnie wykombinować. potem walidacja, kolejne błędy, kolejne poprawki… i tak do czasu, aż generator przestanie się nad użytkownikiem znęcać i łaskawie zaakceptuje całość.

i nie, nie znaczy to, że po zaimportowaniu poprawionych danych wszystko będzie już ok. to by było zbyt proste. ponowna weryfikacja danych, tym razem już w systemie siis, ponownie wywala tonę ostrzeżeń i błędów. i tak, te również należy poprawić z palca. dzika przyjemność, jak jest ich powiedzmy 247.

problem trzeci: nieogarnianie rzeczywistości

i tutaj miałam w tym roku problem największy, generujący kilkadziesiąt ostrzeżeń (tak, poprawić z palca, a co). do urzędu komunikacji elektronicznej poszło sporo informacji o tym, że gmina zielona góra została włączona do miasta zielona góra, a co za tym idzie – pozmieniały się adresy na jej terenie. niby prosta rzecz, bo wszystko poleciało według bardzo prostego schematu i nic, tylko wprowadzić poprawki w danych uke dotyczących miast, wsi i ulic. prawda?

nie.

uke co prawda wprowadziło sobie poprawki do siis, ale już nie do generatora. efekt jest piorunujący: zeszłoroczne adresy, jeszcze gminne, zostały bez najmniejszego problemu zaimportowane tak, jak sobie były – bo po co generator miałby je poprawiać. natomiast już sam siis wywala je jako błędy, bo korzysta z nowych danych, uwzględniających wszystkie zmiany – co wskazuje jasno, że uke nimi dysponuje i spokojnie mogłoby dać opcję zmiany automatycznej. nie, nie dało. adresy też są do poprawki ręcznej. kolejne kilkaset rekordów, takoż “z palca”.

podsumowanie?

nie będzie podsumowania. muszę jeszcze przeedytować trochę formularzy, których zawartości uke nie mogło zmienić na podstawie posiadanych danych automatycznie. więc następne 2-3 godziny spędzę jak ta idiotka wpisując “zielona góra” tam, gdzie wcześniej były nazwy wsi (notabene, dalej widoczne w systemie… tylko zdaniem tegoż systemu błędne).

będzie za to sugestia: może tak uke, poza ludźmi do analizy danych, zatrudniłoby też kogoś do analizy rzeczywistości?

Leave a Reply

You can use these tags: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>