Zaczęło się od bajki o Ministerstwie Napojów i karafkach z pieczęcią (pełny tekst można znaleźć na stronie Szczecińskiego Klubu Informatyka: http://www.klubinformatyka.pl/artykul.php?a=6 ).
Już kilka dni przed kwietniowym spotkaniem Warszawskiego Klubu Informatyka na liście PTI-L trwała ożywiona i niekiedy ostra dyskusja: czy, co i w jaki sposób można - bądź nie należy - homologować.

Spotkanie w Honoratce przebiegło w znacznie bardziej zgodnej atmosferze, niż dyskusja na liście. Nasi goście z Ministerstwa Gospodarki, Pracy i Polityki Socjalnej poświęcili nam 3 godziny i była to bardzo interesująca rozmowa. Homologowanie systemów w formie proponowanej przez dyrektora Zbigniewa Olejniczaka z Departamentu Informatyki Ministerstwa nie spotkało się z żadnymi istotnymi sprzeciwami.
Działa to tak:

1. każdy samorząd (powiaty w przypadku Urzędów Pracy lub gminy w wypadku pomocy społecznej) może używać oprogramowania, jakie lubi - homlogowanego lub nie.
2. jeśli chce, aby budżet (resort) pokrył koszty zakupu oprogramowania, powinno to być oprogramowanie sprawdzone (homologowane) przez resort. Oprogramowania homologowanego używa obecnie ponad 70% urzędów pracy. Homologowane są 4 bardzo różne rozwiązania, kilka dalszych jest testowanych.
3. Przy homologacji resort wymaga od strony technicznej:
   1. aby program przechowywał dane na serwerze SQL;
   2. aby serwer z klientem komunikował się za pomocą XML;
   3. zalecana, ale nie bezwzględnie wymagana, jest architektura trójwarstwowa (serwer bazy danych, serwer aplikacji i klient lub cienki klient, np. przeglądarka). Może być ona realizowana w *.Net, Javie, innych rozwiązaniach aplikacyjnych lub bezpośrednio w C++.
4. Resort poddaje też oprogramowanie testom zgodnie z serią standardowych scenariuszy. Sprawdzają one wymagane funkcje oprogramowania oraz jego zachowanie się w przypadku typowych błędów operatora i niestandardowych przypadków, na przykład błędnych lub niepełnych danych.
5. Wymagania homologacyjne są jawne. Scenariusze testowe w tej chwili nie są jawne, resort zastanawia się nad ich udostępnieniem.
6. Wymagania homologacyjne publikowane są osobno dla każdej aplikacji używanej w Urzędach Pracy. Resort nie wymusza stosowania aplikacji-molochów, które robią wszystko i jeszcze trochę. Odwrotnie: zachęca do niezależnego kupowania i wdrażania każdego podsystemu.
7. Podstawą wymagań homologacyjnych są formaty i struktury danych, które instytucje samorządowe przekazują lub udostępniają rządowi i rząd za te dane im powinien płacić.
8. Dla obywatela treść zasad, norm i wymagań homologacyjnych powinna być bezpłatna. Procedura homologacyjna jest obecnie bezpłatna i powinna taka pozostać.
9. Procedura obecnie jest bardzo elastyczna co do terminów testów homologacyjnych. Można je powtarzać, można je zaliczać etapami.

Znacznie więcej emocji wzbudziły inne tematy, w których sala i goście byli również w zasadzie zgodni:

1. Systemy Urzędów Pracy, pomocy socjalnej oraz ZUS i na przykład PFRON są całkowicie odseparowane i nie wymieniają się danymi. Więcej: często prawo zabrania takiej wymiany.
2. Pesel mógłby być podstawowym rejestrem osobowym, ale... tu następuje wiele zastrzeżeń praktycznych. W każdym razie dla resortu pesel jest lepszym rejestrem niż NIP lub numer ZUS.
3. Wprowadzone przez Senat z inicjatywy ISOC poprawki do ustawy o pomocy społecznej były dla naszych gości zaskoczeniem, które spotkało ich na ostatnim etapie tworzenia ustawy i z tego względu nie byli z nich zadowoleni, ale ich treść w niczym im nie przeszkadza. Przedstawiciele ISOC wskazali, że skorzystali z niepowtarzalnej okazji i że poprawki te mają być zabezpieczeniem na czasy, gdy inni urzędnicy zechcieliby zastosować mniej neutralny tryb pracy.
4. Zamówienia-molochy o wartości pół miliarda każde, obejmujące oprogramowanie, sprzęt, kable i budynek są zabójcze i skazane na klęskę.
5. Lepsze i lepiej wzajemnie powiązane oprogramowanie pomoże mądrzej wydawać środki na pomoc społeczną, ale nie wpłynie na zmniejszenie tych wydatków.