Klient: Główny Urząd Statystyczny.
Projekt realizowany na potrzeby wsparcia spisów: Powszechnego Spisu Rolnego 2010 Narodowego Spisu Powszechnego 2011.

Projekt został zainicjowany wiosną. Polska podobnie jak inne kraje Unii Europejskiej musiała przeprowadzić spisy narodowe. W pierwszej kolejności spisy próbne, następnie spisy w dużej skali, powszechne. Cała masa prac i przygotowań w trakcie postępowania publicznego: wybór podwykonawców, planowanych technologii, rozwiązań informatycznych, zaskutkowały wyborem oferty konsorcjum, w którym jedną z najważniejszych ról powierzono naszej firmie.

Zamawiający jasno przedstawił cele dotyczące aplikacji mobilnej, która miała być głównym kanałem pozyskiwania danych spisowych. Szacowano, że przez aplikację (czyli przy pomocy rachmistrzów) zrealizowane zostanie ponad 80% spisu.

Zadania zlecone przez GUS obejmowały:

• Wykonanie aplikacji mobilnej dla łącznej liczby 36 tysięcy użytkowników
• Stworzenie rozwiązania zapewniającego bezpieczeństwo, spójność i integralność komunikacji
• Zarządzanie wdrożeniem infrastruktury sprzętowej
• Przeprowadzenie szkolenia dla użytkowników
• Świadczenie serwisu i wsparcie w czasie spisów

Oczywistym było, że z uwagi na krytycznie krótki czas realizacji projektu, brak możliwości jego opóźnienia (terminy były określone ustawą) oraz skalę przedsięwzięcia, należało podzielić projekt na kilka podprojektów zarządzanych w ramach jednego dużego projektu (a może już programu).

Pierwszym i najtrudniejszym zadaniem było przygotowanie aplikacji mobilnej. Początkowo miała to być prosta aplikacja wykorzystująca używane wcześniej przez Klientów Softline narzędzia do zarządzania formularzami i ankietami, planowania dnia, modułu wiadomości, wymiany danych z serwerem, zbierania danych GPS. Wszystkie mechanizmy były wystarczające. Wyjątek stanowił moduł formularza, który okazał się wierzchołkiem góry lodowej. Zmienność założeń, walidacji, ścieżek, czy automatycznego uzupełniania odpowiedzi powodowały dodatkowe utrudniania w implementacji. Okazało się, że stare oprogramowanie nie sprosta wymaganiom, a na wytworzenie nowego nie ma czasu. Zespół analityków, projektantów i programistów wytworzył hybrydę, która łączyła nowe funkcjonalności z przetestowanym na kilkunastu tysiącach użytkowników dotychczasowym silnikiem. Należało jeszcze uzupełnić aplikację o dodatkowe mechanizmy zapewniające bezpieczeństwo rachmistrza oraz bezpieczeństwo danych (w tym osobowych i poufnych). Na etapie wytwarzania koncepcji przyjęto, że będą opierały się na infrastrukturze PKI. Z uwagi na brak możliwości zastosowania standardowych rozwiązań, zaimplementowano system przechowujący klucz prywatny na specjalnie stworzonej na potrzeby tego projektu karcie SIM. Mając na uwadze jedno z głównych wymagań systemu, które narzucało konieczność zapewnienia pełnej funkcjonalności systemu w trybie off-line, został do zaimplementowania mechanizm obsługi map (ortofotomapy + wektory). Nie można było skorzystać z mechanizmów dostępu do serwera mapowego, ponieważ rozwiązanie działałoby jedynie w przypadku połączenia z siecią. Przygotowano więc pisane na miarę, całkiem nowe silniki obsługi map. Zapewniały pełne skalowanie, kafelkowanie, buforowanie oraz zarządzanie przez rachmistrza wyświetlanymi warstwami. Aplikacja mobilna 4mPOWER Census była gotowa.

Szeroko rozumiana aplikacja mobilna stanowiła tylko jeden element systemu. Pozyskane na niej dane były szyfrowane i przygotowywane do wysyłki. System był tak skonstruowany, aby bez konieczności ingerencji rachmistrza móc wysłać dane na serwer. Pytanie: co by się stało, gdyby jednocześnie 20 tysięcy rachmistrzów próbowało takie dane wysłać? Symulacje wydajnościowe systemu wykazały, że do prawidłowej pracy potrzebna jest grupa kilku serwerów komunikacyjnych. Główne ich zadanie to autoryzacja terminala, deszyfrowanie danych i przekazanie ich dalej do aplikacji dyspozytorskiej a później do Operacyjnej Bazy Mikrodanych. Dzięki modyfikacjom oprogramowania oraz zastosowaniu LoadBalancera, udało się doprowadzić do stanu, kiedy trzy serwery pracowały na wydajności 90% podczas synchronizacji wszystkich urządzeń. Dawało to bezpieczeństwo zarówno Klientowi, jak i Dostawcy. Mając na uwadze konieczność zapewnienia wysokiej dostępności systemu, został zbudowany ośrodek zapasowy, z całkowicie oddzielnymi łączami, serwerami i sprzętem pomocniczym. W czasie testów, ośrodek zapasowy przejmował rolę ośrodka centralnego w kilka godzin.

Wraz z zakończeniem prac nad aplikacją działającą na małych terminalach oraz aplikacją przygotowaną na duże serwery komunikacyjne rozpoczęły się prace wdrożeniowo - integracyjne. Pierwszym wyzwaniem logistycznym było zainstalowanie aktualnej wersji aplikacji na urządzenia mobilne, rozproszone po całej Polsce. Do wykonania tego zadania przygotowana została aplikacja Remote Device Manager. Za pomocą rozwiązania można było dowolnie zarządzać terminalami: sprawdzić stan, aktualizować aplikację, wymuszać wysłanie danych, pobrać współrzędne geograficzne terminala, wykasować dane, a nawet zablokować czy całkowicie zresetować urządzenie. Kolejne zadania dotyczyły głównie konfiguracji środowiska, zarządzania użytkownikami, utrzymaniem spójności danych i zarządzenia zmianami. System zaczynał tworzyć spójną całość.

Struktura spisowa obejmowała dwie grupy użytkowników, korzystających z aplikacji mobilnej. Pierwsza z nich to rachmistrze (w dwóch spisach ok. 30 tys. osób), którzy z aplikacją na urządzeniu typu hand held odwiedzali respondenta w celu przeprowadzenia wywiadu. Druga grupa to liderzy gminni, którzy mieli za zadanie wspierać rachmistrzów w pracach spisowych (zarówno metodologicznie, jak i technicznie). Obie grupy należało przeszkolić w krótkim, nieprzekraczalnym czasie. Ponieważ rachmistrze i liderzy opierali się na tej samej aplikacji, ale mieli różne zadania, wymagało to indywidualnego podejścia do każdej z grup. Dwa różne plany szkoleń, dwa scenariusze szkoleniowe, dwa rodzaje egzaminów. Realnie – dwa podprojekty. Szkolenia poprzedzające każdy ze spisów trwały 3 miesiące (ok. miesiąc na liderów, dwa miesiące na rachmistrzów). Wszystkie szkolenia były szkoleniami trzydniowymi, w grupach nie przekraczających 20 osób. Dodatkowo należało założyć, że żaden z uczestników nie powinien dojeżdżać na szkolenia dalej niż 60 km od miejsca zamieszkania. Wymagało to utworzenia kilkudziesięciu centrów szkoleniowych. Na potrzeby realizacji szkoleń pracowało ponad 250 trenerów wyposażonych w laptopy, rzutniki i handheldy. Pomimo sztywnego harmonogramu, który na potrzebę zarządzania ryzykiem oznaczony był jako „niezmienny”, życie wymusiło modyfikacje będące pochodną katastrofy smoleńskiej, a później dwóch tur wyborów prezydenckich, jak również powodzi, które nawiedziły południową część Polski. Dzięki determinacji i poświęceniu trenerów i uczestników, szkolenia udało się zakończyć w założonym czasie.

Wiadomo, że łańcuch jest na tyle wytrzymały, na ile wytrzymuje najsłabsze ogniwo. Pierwszego dnia okazało się, że jeden z podsystemów innego dostawcy nie przyjął żądanego obciążenia i rachmistrze nie mogli pobrać inicjalnych danych potrzebnych do pracy. Pierwszymi, którzy odczuli to na własnej skórze byli konsultanci świadczący serwis na pierwszej linii wsparcia. Podczas jednej rozmowy (często trwającej minutę), na telefon konsultanta próbowało dodzwonić się 17 kolejnych użytkowników szukających wsparcia. Koniec drugiego dnia powoli zaczął stabilizować sytuację, w trzecim została ona opanowana. Ilość telefonów do serwisu malała, w międzyczasie wprowadzono system wsparcia przez Internet, co również wpłynęło na zmniejszenie obciążenia ruch telefonicznego. Serwis od pierwszego do ostatniego dnia spisu działał przez 12 godzin dziennie, a w zależności od natężenia iloci rozmów świadczyło go od kilkunastu do kilkudziesięciu osób.

Powszechny Spis Rolny zakończył się 31.X.2010 roku. Utrudnienia na początku, które zawsze towarzyszą przedsięwzięciom prekursorskim o wielkiej skali szybko zostały zażegnane. Rachmistrze pracując przez dwa miesiące przeprowadzili przy użyciu aplikacji mobilnej autorstwa Softline 1 mln 722 tys. ankiet. Udział wykorzystania aplikacji w kanałach spisowych wynosił 94%. Patrząc z perspektywy udanego spisu należy uznać, że sukces projektu to sukces wypracowany przez cały zespół. Każdy z podprojektów miał wyznaczony harmonogram niewiele różniący się od ścieżki krytycznej. Subtelne balansowanie pomiędzy zarządzaniem twardym i zarządzaniem miękkim pozwoliło nie naruszyć zależności między zespołami, utrzymać terminowość dostarczania produktów i zapewnić ich jakość. Konsekwentne stosowanie metodyki zarządzania, bieżące monitorowanie ryzyka projektowego, a przede wszystkim zaangażowanie i determinacja członków zespołów oraz odpowiedzialność kierowników projektów pozwoliły na doprowadzenie do momentu, w którym możemy pochwalić się udanym wdrożeniem największego systemu mobilnego w Europie.