Wydawnictwo Publicus Sp. z o.o.
04-260 Warszawa, ul. Jedwabnicka 1
tel/fax: +48 22 610 10 99 w. 26
Bank Zachodni WBK SA XVII Oddział Warszawa 
08 1090 1753 0000 0001 1981 0954

Ostrzeżenie

JUser::_load: Nie można załadować danych użytkownika o ID: 50.

poniedziałek, 04 listopad 2013 21:33

NEUTRALNOŚĆ TECHNOLOGICZNA W INFORMATYCE?

Napisane przez 

Urzędy samorządowe, zamawiając cokolwiek w drodze zamówień publicznych, mają obowiązek równego traktowania wszystkich potencjalnych podmiotów – które mają prawo do złożenia ważnej oferty. Dotyczy to również sytuacji, kiedy do urzędów zamawiamy rozwiązania informatyczne. Wtedy również musimy równo traktować podmioty dostarczające takie rozwiązania. Potocznie mówimy wtedy o neutralności technologicznej rozwiązań.

Należy tutaj jednak postawić zasadnicze pytanie: jak zapewnić neutralność technologiczną, skoro kupujemy konkretne urządzenia i systemy, które są przecież wykonane w konkretnej technologii? Czy wtedy przestajemy być neutralni i nie dopełniamy wymogów prawa zamówień publicznych?

Neutralność technologiczna według prawa

Ustawa o informatyzacji podaje znaczenie zasady neutralności technologicznej. Według jej twórców jest to „zasada równego traktowania przez władze publiczne technologii teleinformatycznych i tworzenia warunków do ich uczciwej konkurencji, w tym zapobiegania możliwości eliminacji technologii konkurencyjnych przy rozbudowie i modyfikacji eksploatowanych systemów teleinformatycznych lub przy tworzeniu konkurencyjnych produktów i rozwiązań”. Ponadto, prawo zamówień publicznych nakazuje, aby „w ogłoszeniu o zamówieniu i w specyfikacji istotnych warunków zamówienia” przedmiot zamówienia został opisany „w sposób jednoznaczny i wyczerpujący oraz zapewniający zachowanie uczciwej konkurencji i równego traktowania wykonawców”.

A zatem, zgodnie z obiema ustawami – zarówno o informatyzacji, jak i prawem zamówień publicznych – nie można na wstępie do jakiejkolwiek inwestycji informatycznej przewidywać konkretnych technologii, które mogą być dostarczane wyłącznie przez jeden podmiot lub grupę podmiotów skupionych w jednej grupie kapitałowej. W praktyce zamówień publicznych, stosując zasadę neutralności wobec potencjalnych dostawców, absolutnie nie można sprzyjać budowaniu niedozwolonych monopoli technologicznych i prawnych. Należy bacznie zwracać również uwagę na treść umów podpisywanych z wykonawcami po to, by na podstawie ich zapisów nie dopuścić do wymuszenia na instytucji publicznej kolejnych zamówień rozszerzających wcześniej wykonane produkty w trybie niekonkurencyjnym, czyli z tzw. „wolnej ręki”.

Rozwój ewolucyjny

W praktyce wytwarzania systemów informatycznych jest oczywistością, że kolejne wersje wdrożonych systemów powstają na bazie rozwoju wersji poprzednio istniejących. Czy nie jest to zatem okoliczność, która powinna zwolnić instytucję publiczną z konieczności zasady zachowania neutralności technologicznej?

Otóż, nie. W żadnym wypadku nie można zasłaniać się taką sytuacją. Już podczas zamawiania pierwszej wersji systemu informatycznego trzeba mieć na względzie fakt, że za jakiś czas może zaistnieć konieczność zamówienia jego kolejnej – zmodyfikowanej – wersji. Taka konieczność może wynikać chociażby z chęci ulepszenia systemu, rozszerzenia jego zakresu lub zmiany prawa, na podstawie którego tenże system wdrożono. A zatem konieczne jest, aby urząd publiczny jako zamawiający zawsze o tym pamiętał – i już przy zamówieniu pierwszej wersji systemu co najmniej:

1.            zapewnił przekazanie zamawiającemu majątkowych praw autorskich do uzyskiwanych produktów na wszystkich polach jego eksploatacji,

2.            zapewnił przekazanie zamawiającemu czytelnych kodów źródłowych oprogramowania wraz z ich dokumentacją,

3.            zapewnił przekazanie zamawiającemu wszelkiej dokumentacji niezbędnej dla właściwego zainstalowania i uruchomienia zamawianych produktów informatycznych,

4.            zapewnił przeszkolenie niezbędnej grupy pracowników zamawiającego w celu uzyskania jego samodzielności w uruchamianiu i użytkowaniu zamówionego systemu.

Aby w maksymalnie możliwym stopniu zapewnić sobie szansę na zachowanie neutralności technologicznej rozwiązań informatycznych na kolejnych etapach ich rozwoju, powinniśmy dopilnować powyższych wytycznych. W przeciwnym wypadku możemy narazić urząd na skuteczne odwołania do Krajowej Izby Odwoławczej, negatywne wyniki kontroli Prezesa Urzędu Zamówień Publicznych, a także na wykazanie naruszenia zasad dyscypliny finansów publicznych.

Jawne i otwarte interfejsy

We wcześniejszych numerach naszego pisma pisaliśmy już o interoperacyjności systemów informatycznych. Warto na to zwrócić uwagę, również mówiąc o neutralności technologicznej. Jawne i otwarte interfejsy są obecnie uznane za skuteczny sposób zapewnienia równego dostępu do możliwości dostarczenia konkretnych rozwiązań informatycznych. Należy to rozumieć w ten sposób, że jeżeli zdefiniujemy formaty komunikatów przesyłanych pomiędzy systemami, standardy techniczne obowiązujące dla tych systemów oraz wymogi sprzętowe i prawne – to dajemy szansę różnym oferentom skutecznego złożenia oferty w postępowaniu dotyczącym naszego zamówienia. Jednocześnie pozostajemy wówczas w zgodności z wytycznymi ustawy o informatyzacji, co dla zamówień informatycznych w administracji publicznej jest równie ważne.

Zachęcamy zatem do ponownego zajrzenia do wcześniejszych numerów Magazynu Samorządowego „GMINA”, aby przypomnieć sobie problematykę interoperacyjności systemów informatycznych i jawności interfejsów.

Jawność testów akceptacyjnych

Nie tylko jawność interfejsów jest ważna. Już w pierwszej wersji ustawy o informatyzacji z 2005 roku podjęto działania zmierzające do tego, aby umożliwić dowolnemu wytwórcy oprogramowania wytwarzanie własnych programów komunikujących się z innymi systemami, używanymi w instytucjach publicznych. Problem wyniknął przede wszystkim z braku otwartości systemu Zakładu Ubezpieczeń Społecznych. Panowało wtedy powszechne oburzenie faktem, że jedynym oprogramowaniem, które umożliwiało pracodawcom przesyłanie do ZUS comiesięcznych raportów ubezpieczonych, był program „Płatnik” – dostarczany przez Zakład Ubezpieczeń Społecznych i finansowany ze środków publicznych. Tymczasem spora grupa producentów oprogramowania finansowo-księgowego dla firm nie mogła dołączyć do swoich produktów modułu współpracy z systemem informatycznym ZUS, z powodu braku chęci opublikowania przez ZUS formatów interfejsów wymiany danych. Głównym uzasadnieniem ze strony ZUS była konieczność zachowania bezpieczeństwa danych składowanych w jego systemie. W opinii wielu ekspertów – również mojej – było to stanowisko dyskusyjne.

Szukając rozwiązania tego oczywistego impasu, dawne Ministerstwo Nauki i Informatyzacji wprowadziło do ustawy o informatyzacji zapis o konieczności wydania tzw. rozporządzenia o testach akceptacyjnych i badaniu zgodności oprogramowania interfejsowego. Rozporządzenie to obowiązuje od listopada 2005 r., a jest ono ogłoszone w Dzienniku Ustaw z roku 2005 nr 217 pod pozycją 1836.

Idea tego rozporządzenia polega na tym, że w przypadku, kiedy urząd publiczny nakazuje kontakt ze sobą za pomocą systemu informatycznego, to ma wtedy obowiązek opublikować projekty testów akceptacyjnych dla oprogramowania interfejsowego. Na tej podstawie dowolny wytwórca oprogramowania może zbadać swój produkt i poddać go badaniom na zgodność z tymi projektami testów. Po pozytywnym przejściu badania, oprogramowanie takie może być pełnoprawnie używane do komunikacji z urzędem publicznym. Urząd publiczny nie może w takim przypadku odmówić przyjmowania danych wysyłane przez to oprogramowanie.

Bądźmy racjonalni

Prowadząc proces zamówień publicznych oraz planując rozwój systemów informatycznych, powinniśmy w sposób rozsądny patrzeć na faktyczne potrzeby urzędu i nie ulegać przy tym naszym osobistym preferencjom. Ważne jest, aby zamawiać wyłącznie to, wobec czego istnieje uzasadniona potrzeba zakupu i użycia. Dokonywanie zakupów musi być zorganizowane w taki sposób, aby zachować zasadę równego traktowania potencjalnych oferentów z równoczesną umiejętnością uzasadnienia wymagań, sformułowanych przez urząd. Informatycy muszą również umieć przewidzieć potencjalne kierunki rozwoju zamawianych systemów – tak, aby można było potraktować pierwsze zamówienie nowego systemu jako pierwszy krok w jego ewolucyjnym rozwoju. Tutaj kłania nam się grupa zagadnień współczesnej inżynierii oprogramowania, dotycząca sposobu organizacji cyklu życia oprogramowania… Ale o tym na łamach kolejnych numerów naszego pisma.

Lock full review www.8betting.co.uk 888 Bookmaker

PARTNERZY