Wymagania na system PULS zostały przygotowane w 1995 r. Wskazano wówczas na konieczność wytworzenia, w docelowej wersji 2.0 tego rozwiązania, ponad 20 aplikacji funkcjonalnych. Spośród nich do dziś powstało i jest użytkowanych przez urzędy pracy i ich filie osiem modułów (Administrator, Finanse, Formalna Obsługa Osób, Pośrednictwo Pracy, Prace Okresowe i Staże, Statystyka, Szkolenia i Poradnictwo Zawodowe, Świadczenia Finansowe). Trzy dalsze (Kadry, Płace, Wskaźniki Efektywności) zostały wdrożone z końcem 2002 r.

Poziom faktycznego wykorzystania aplikacji systemu PULS jest bardzo różny i nie zawsze możliwy do oszacowania. Na fakt ten wpływ ma kilka czynników. System PULS jest wybiórczo wykorzystywany w wojewódzkich urzędach pracy, choć wydaje się, że mógłby być stosowany powszechnie przynajmniej w zakresie aplikacji Finanse, a w najbliższej przyszłości również Kadry i Płace.

System PULS jest systemem zintegrowanym, ale jedynie na poziomie powiatowych urzędów pracy i niekiedy ich filii. Poszczególne powiatowe instalacje PULS nie zostały zintegrowane. System utworzono w - najbardziej popularnej w pierwszej połowie lat 90. XX wieku, chociaż obecnie rzadko już polecanej - architekturze klient-serwer, z tzw. grubym klientem. Architektura ta, mimo że na początku lat 90. była uważana za rewolucyjną, ma wady, które dzisiejsze techniki informatyczne są w stanie wyeliminować.

Problemy ze śledzeniem wydatków i określeniem zapotrzebowania na fundusze

Dysponent Funduszu Pracy, przekazujący środki na realizację zadań urzędów pracy, musi mieć bieżące informacje o rzeczywistym zapotrzebowaniu poszczególnych jednostek. Z drugiej strony, dysponent FP musi mieć pewność, że środki, które przekazuje, są prawidłowo wykorzystywane. Przydział środków finansowych na urzędy pracy jest realizowany zgodnie z algorytmem ogłoszonym we właściwym rozporządzeniu. Gdyby informacja o aktualnym stanie zapotrzebowania i wykorzystania funduszy przez urzędy pracy była dostępna na bieżąco, to sterowanie wykorzystaniem pieniędzy mogłoby być bardziej racjonalne.

Problemy z monitorowaniem

Istnieje potencjalne zagrożenie dokonania rejestracji bezrobotnego w więcej niż jednym urzędzie pracy (np. poprzez złożenie fałszywego oświadczenia na karcie rejestracyjnej). Pracownik urzędu pracy, dokonujący rejestracji, może zadzwonić do innego urzędu pracy i zapytać, czy dana osoba nie jest tam zarejestrowana. Nie ma jednak technicznej możliwości, aby system PULS sam poinformował, że rejestrowana osoba ma wpis również w innym urzędzie. Rejestrowane dane klientów urzędów pracy są obecnie weryfikowane pod względem aktualności i prawdziwości poprzez porównanie ich przez pracownika urzędu pracy z dokumentami przedłożonymi przez klienta. Nie ma jednak możliwości, aby system dostarczył informacji (np. po weryfikacji w ZUS) czy dokumenty zawierają prawdziwe dane.

Przestarzałe narzędzia

System PULS został w całości wykonany w technologii Progress w wersji 7.3c (baza danych Progress RDBMS i okienkowa aplikacja użytkownika końcowego napisana w języku Progress 4GL). To technologia, która od ponad dwóch lat nie jest już oferowana przez firmę Progress. Firma nie rozprowadza tego oprogramowania i nie oferuje wsparcia. Wersja Progress 7.x była pierwszą wersją, umożliwiającą programowanie aplikacji z graficznym interfejsem użytkownika, pracujących pod kontrolą Windows. Narzędzia te były przystosowane do pisania aplikacji w architekturze klient-serwer z tzw. grubym klientem metodami strukturalnymi. Język Progress 4GL jest własnym rozwiązaniem firmy Progress. Istnieje małe prawdopodobieństwo, aby szkoły, w których uczy się programowania, wykorzystywały ten język w procesie kształcenia. Rynek programistów w Polsce charakteryzuje się raczej niewielką podażą specjalistów znających to rozwiązanie.

Duże wymagania w stosunku do sieci lokalnych

Architektura klient-serwer z tzw. grubym klientem, zastosowana w systemie PULS, powoduje, że wszelkie dane składowane na serwerze bazy danych, niezbędne do wykonania obliczeń (np. zestawień statystycznych), muszą zostać przesłane do aplikacji działającej na stacji roboczej użytkownika końcowego. Powoduje to masowe przesyłanie danych w sieci LAN, co wydłuża czas oczekiwania na odpowiedź systemu wszystkim pozostałym użytkownikom, także tym, którzy nie korzystają w danej chwili z funkcji charakteryzujących się dużym zapotrzebowaniem na dane.

Uzależnienie urzędów pracy od jednego dostawcy

Z realizacją całości systemu PULS tylko przez jednego wykonawcę wiążą się wszystkie zagadnienia związane z brakiem konkurencji (wynika to jednak z wycofania się drugiego oferenta podczas prac nad systemem w latach 90. - przyp. red.). Z drugiej jednak strony można powiedzieć, że z takiego układu płyną również znaczne korzyści. Stronie zamawiającej o wiele łatwiej jest przekazywać wymagania i akceptować ich realizację, jeżeli ma do czynienia z mniejszą - w szczególności z jednym - liczbą usługodawców.

Źródło: syriusz.mg.gov.pl