Z wolnej ręki – „z przyczyn technicznych o obiektywnym charakterze”
- Dodano: 22 czerwca 2010
- Wprowadził: patyczak
- Komentarze: 25
Do tej pory w serwisie PPP IT opisywane były przetargi, rozpisane z naruszeniem Prawa zamówień publicznych, polegającym na wskazaniu z nazwy konkretnego oprogramowania, zamiast – jak nakazują przepisy – opisaniu go pod względem technicznym lub funkcjonalnym. Tym razem serwis porusza inny problem – licznych zamówień w trybie „z wolnej ręki”, który zamawiający uzasadniają „przyczynami technicznymi o obiektywnym charakterze”.
W serwisie opisano trzy przykładowe przetargi – wszystkie z jednego tylko dnia, 18 czerwca 2010. Urząd Miejski w Radomiu opublikował ogłoszenie o zamiarze zawarcia umowy pt. Zamówienie z wolnej ręki na świadczenie opieki nad programem Xpertis Ewidencja działalności gospodarczej, Gmina Łask ogłosiła zamiar zawarcia umowy na Świadczenie usług serwisu i bieżącej konserwacji systemu KSAT2000, wdrożonego w Urzędzie Miejskim w Łasku, Dyrektor Urzędu Morskiego w Gdyni ogłosił zamówienie pt. Nadzór autorski nad wszystkimi systemami finansowo – księgowymi firmy Unisoft Sp z o.o. eksploatowanymi w Urzędzie Morskim w Gdyni.
Zamawiający uzasadniają tryb zamówienia – “z wolnej ręki” – w sposób następujący: Niniejsze zamówienie może być świadczone przez jednego Wykonawcę z przyczyn technicznych o obiektywnym charakterze. Tylko Wykonawca współpracujący w zakresie obsługi Zamawiającego z licencjonodawcą ma prawo do modyfikacji treści programów w językach FORMULA i Report, co wynika z pkt. 18 zawartej umowy licencyjnej na użytkowanie oprogramowania Xpertis Ewidencja działalności gospodarczej. Pozwala to na zastosowanie trybu zamówienia z wolnej ręki, zgodnie z przepisami art. 67 ust. 1 pkt. 1 lit. a ustawy – Prawo zamówień publicznych (t.j. Dz.U. nr 223 z 2007r., poz. 1655 z późn. zm.).
Powyższy fragment pochodzi z uzasadnienia zamówienia Urzędu Miejskiego w Radomiu. W ogłoszeniu Gminy Łask czytamy: (…) Zastosowanie trybu zamówienia z wolnej ręki w przedmiotowym postępowaniu jest zgodne z cytowanym przepisem, gdyż wdrożony w Urzędzie Miejskim w Łasku program KSAT2000 może być serwisowany jedynie przez producenta programu i jednocześnie dostawcę oprogramowania (…) Podobnie brzmi uzasadnienie Urzędu Morskiego w Gdyni: Zamawiający może udzielić zamówienia z wolnej ręki jeżeli zachodzi następująca okoliczność: Usługa może być świadczona przez jednego wykonawcę z uwagi na ochronę praw wyłącznych (…). Firma Unisoft jest autorem zakupionych programów Finansowo – Księgowych wykonanych w technologii Oracle. (…) Z uwagi na wygaśnięcie z końcem miesiąca maja b.r. terminu pełnienia nadzoru autorskiego nad w/w systemami, zaistniała potrzeba jego przedłużenia na kolejny okres 24 miesięcy.
Takich ogłoszeń pojawia się wiele, a za każdym razem uzasadnienie jest podobne: ze względu na wcześniej zawarte umowy, tylko jeden wykonawca jest w stanie podjąć się realizacji zadania. Mamy więc do czynienia z sytuacją, gdy urząd uzależniony jest od jednego tylko wykonawcy.
Można, owszem, tłumaczyć – jak czynią to zamawiający – że usługa może być świadczona przez jednego wykonawcę z przyczyn technicznych o obiektywnym charakterze. Trzeba jednak zauważyć, że owe obiektywne przyczyny techniczne są wynikiem popełnionego w przeszłości błędu lub zaniedbania, polegającego na tym, że zamawiający nie zażądał dostępu do kodu źródłowego zamawianego oprogramowania ani przeniesienia na siebie autorskich praw majątkowych. Gdyby to zrobił, miałby nad swoim oprogramowaniem pełną kontrolę, a tym samym uniknął pułapki vendor lock-in: mógłby do jego obsługi zatrudnić własnych informatyków lub też firmę zewnętrzną, która w drodze przetargu zaoferuje najlepsze warunki.
Dodajmy na zakończenie, że z problemem vendor lock-in mamy do czynienia także na poziomie urzędów znacznie wyższej rangi, gdzie w grę wchodzą o wiele większe wydatki. Sztandarowym przykładem jest tu Zakład Ubezpieczeń Społecznych, jest dziś zdany na łaskę firmy Asseco. Chodzi tu o kontrakt wart miliardy złotych i bezpieczeństwo całego krajowego systemu ubezpieczeń społecznych, tymczasem – jak czytamy w serwisie Gazety Wyborczej zakład może zdecydować jedynie, z której strony umowy się podpisać.
Sądząc po ilości ogłoszeń o zamówieniach w trybie “z wolnej ręki” taka sytuacja w urzędach na wszystkich szczeblach administracji to raczej norma niż wyjątek.
Znalezione w serwisie PPP IT. Jest on prowadzony w ramach projektu Fundacji Wolnego i Otwartego Oprogramowania pt. “Prawidłowe i transparentne przetargi publiczne na narzędzia informatyczne”. Projekt jest realizowany przy wsparciu udzielonym przez Islandię, Liechtenstein i Norwegię ze środków Mechanizmu Finansowego Europejskiego Obszaru Gospodarczego, Norweskiego Mechanizmu Finansowego oraz budżetu Rzeczypospolitej Polskiej w ramach Funduszu dla Organizacji Pozarządowych.
Więcej informacji: http://pppit.org.pl/?a=75
Znalazłeś literówkę? Zgłoś ją używając formularza!
Jeśli uważasz, że ten nius jest nieobiektywny, przedstawia nieprawdziwe wydarzenie, jest spamem lub nie spełnia standardów serwisu, napisz raport.
Niusy na podobny temat:
Komentarze są prywatnymi opiniami dodających je osób. Prosimy o zachowanie kultury wypowiedzi. Komentarze obraźliwe oraz obniżające poziom serwisu będą usuwane. Więcej w regulaminie komentowania.
25 komentarzy
Wszystkie autorskie niusy w serwisie publikowane są na licencji Creative Commons Uznanie autorstwa 2.5 Polska.
No dobra – to co można konkretnie zrobić w sytuacji, gdy w Urzędzie XYZ jest program do czegoś (księgowość) kompatybilny sam z sobą?
.
Ja nie znam ani jednego przykładu koszernego prg do księgowości. Poza tym jest kwestia dostosowania takiego programu do wymogów środowiska – Urząd ma inne wymagania niż np. hurtownia mydła.
.
.
Proforma dopiszę:
Jestem za tym by nie było vendor-lock w _żadnym_ naszym Urzędzie. Skoro na terenie całej Polski obowiązuje jedno prawo to przecież można zagonić informatyków w Urzędach do zrobienia jednego przezroczystego systemu opartego np o web-2.0 albo na screen'ie z publicznie dostępnym kodem. Do tego jeśli wreszcie udałoby się dowiązać wspólnie (po 100%) odpowiedzialność (i ją egzekwować) za działanie/bezpieczeństwo danych na informatykach i możnowładców (prezydentów, burmistrzów, itd) to wreszcie by coś zaczęło się zmieniać.
Koledze to się chyba coś porąbało. Od kiedy to informatycy piszą programy ( nie mówię o skryptach ) to zadanie dla programistów. Z taki podejściem to pewnie ta aplikacja dla 20 ludzi by działała ale przy 1000 to na pewno nie.
Informatycy robią to co im każą inni. Takich z ideałami to się wywala od razu bo generują problemy. A to z doświadczenia wiem.
A co – programista to nie informatyk?:) lepiej nie wyskakuj z taką tezą na jakiejś konferencji, chyba, że lubisz adrenalinę:)
Pytanie: od kiedy to skrypt nie jest programem?
Co jeszcze informatyk w urzędzie jednym czy drugim ma robić? Przy podejściu że informatyk jest od wszystkiego (zacięty papier, robienie szablonów w wordzie, wymiana tonera, a jednocześnie nadzór nad siecią, programami, bazami danych, serwerami, a wolnym czasie, którego wiecznie brakuje, niech jeszcze pomaga paniom w biurze w ich obowiązkach), do tego za połowę stawki w porównaniu z normalnymi firmami albo i mniej, to chyba zbyt duże wymagania? W urzędach pracują albo pasjonaci, albo miernoty, za przeproszeniem. A jeśli ktoś ma inne zdanie, proszę bardzo, niech się zatrudni i sam sprawdzi
Na wszelki wypadek dodam, ze Asseco to byly Prokom. Jak to mowia, w metnej wodzie latwiej lowic ryby.
[quote]
Zamawiający nie zażądał dostępu do kodu źródłowego zamawianego oprogramowania ani przeniesienia na siebie autorskich praw majątkowych. Gdyby to zrobił, miałby nad swoim oprogramowaniem pełną kontrolę, a tym samym uniknął pułapki vendor lock-in: mógłby do jego obsługi zatrudnić własnych informatyków lub też firmę zewnętrzną, która w drodze przetargu zaoferuje najlepsze warunki.
[/quote]
Wg mnie to trochę zbyt optymistyczne myślenie. Masz program, którego kod źródłowy ma dziesiątki o ile nie setki MB teraz weź firmę zewnętrzną, która będzie Ci robiła modyfikacje – samo wgryzienie się w kod może zająć mnóstwo czasu a tu jeszcze trza ten soft wspierać.
JA raczej optuję za tym, żeby ktoś wreszcie to ustandaryzował i walnął jeden program na całą Polskę jak to wspomniał Mieszko.
Devil
Jeśli ktoś pisze program to powinien załączyć dokumentację oraz opisać i komentować kod tak, że następca modyfikacji takiego kodu będzie wiedział, co każda linijka kodu robi. Jeśli kod nie jest dokumentowany i opisany, to program jest robiony po prostu z założenia źle;)
Tak,tak… Komentarze sa pisane wtedy jak kod jest niejasno pisany. Przejrzysty kod jest dokumentacja sam w sobie.
No popatrz… a w Szczecinie nie wiedzą, że to zbyt optymistyczne i dostają kod źródłowy
@rafal-b
Nawet z dobrze udokumentowanym kodem baaardzo dużo czasu zajmie Ci dojście jak/gdzie/dlaczego …. dolicz do tego, że źródła zajmują Ci np 20 albo więcej MB, do tego jak wspomniałem pozostaje wsparcie tego.
@BoBsoN
O zbytnim optymizmie mówiłem w kategorii tego, że firma druga sprawnie i szybko dokona Ci zmian mając dostęp do źródeł – niestety tak nie jest.
Devil
Wszystko zależy od dokumentacji jaką przyjmiesz i kodu, który zatwierdzisz. Nic nie zwalnia cię z sprawdzenia jakości produktu ci dostarczonego – kod i dokumentacja też podlegają tej zasadzie.
W Szczecinie z tego co wiem inna firma dała sobie radę przy bardzo napiętym terminie dostarczenia rozwiązania (każdy dzień zwłoki kosztował bajońską kwotę). Może uda się z tego urzędu załatwić case-study – wtedy byłby namacalny dowód
BTW – zbytni optymizm możliwy jest w dowolną stronę. Zbytnim optymizmem jest też myślenie, że soft zamkniętych źródeł będzie szybciej rozwijany, szybciej dostaniemy poprawki, będzie lepszej jakości itd…. tego typu sprawy nie zależą od otwartości/zamkniętości tylko od jakości dostawcy. Może się okazać, że właśnie niezależny vendor dostarczy ci szybciej rozwiązanie niż główny producent w danym momencie skupiony na rozwoju lub zupełnie innym działaniu.
Chętnie sam zobaczyłbym ten case – sam nie programuje ale z opowieści kolegów programistów wynika raczej, że jest to trudna rzecz tym trudniejsza im większy rozmiar źródeł. Daleki jestem od stwierdzenia, że zamknięte czy otwarte źródła cokolwiek gwarantują natomiast producentowi zawsze jest łatwiej i szybciej coś zmodyfikować.
Devil
To wtedy można zamówić taki support z wolnej ręki na powiedzmy rok i ogłosić przetarg na wsparcie z czasem rozpoczęcia w momencie zakończenia tego oficjalnego, wcześniej (po podpisaniu umowy) udostępniając kod.
Według europejskiego prawa przetargowego ustalono progi kiedy można oddać z wolnej reki. Do 50K EUR można, powyżej trzeba wybrać spośród przynajmniej 3 ofert dostawców usługi a powyżej 125K EUR należy przeprowadzić przetarg europejski. Oczywiście można zakup usług "pociąć" na kawałki mniejsze niż 50K ale tu wydział finansowy powinien zapobiegać takiemu wykroczeniu. Jeżeli urząd nie zastosuje się do tych zasad każda firma europejska możne zaprotestować i wtedy sprawa trafia do sadu. Tak jest przynajmniej w Holandii. Właśnie jestem w trakcie przygotowywania się do przetargu europejskiego na program do kontroli ruchu drogowego na holenderskich drogach tak wiec zagłębiam się powoli w te problematykę. Do tej pory mojemu poprzednikowi udawało się trwać w vendor lock-in jednak nowe europejskie prawo przetargowe uniemożliwia takie postępowanie.
Prawo które tu w bardzo wielkim skrócie opisałem wprowadzono w styczniu 2010.
Zaistniała potrzeba.
Zatem działamy jak trzeba.
Dokładnie takie jest całe życie.
I zupełnie nie rozumiem o co chodzi autorowi?
Za wszelkie wybory dokonane wcześniej płaci się później.
ZAWSZE.
Czy ktoś z was w ogóle widział na oczy algorytmy Prokomu/Asseco zaimplementowane przez ostatnie 21 lat tzw. "wolnej" Polski, których zadaniem jest wyliczanie comiesięcznych wysokości rent i emerytur w ZUS dla paru milionów rodaków??? Ludzie czy możecie sobie chociaż wyobrazić złożoność problemu utrzymania takiego systemu w ruchu ciągłym, żeby kaska płynęła w miarę regularnie do masowego odbiorcy? Przecież to są setki łatek, do poprawek, do zmian i modyfikacji wynikających ze wszystkich historycznych głosowań naszego parlamentu oraz aktów wykonawczych rządu – pojedynczo proste sprawy, ale jak pomnożycie przez prawie 8 milionów indywidualnych przypadków i 21 lat historii tych zmian, to żadna dokumentacja nie pomoże…
Zróbcie sobie ciepłe mleczko na dobranoc i śnijcie kolorowo o potędze otwartego kodu, a rano włączycie radio i telewizor nadający wg. zamkniętej koncesji, potem wykonacie kilka rozmów telefonicznych przez ulubionego operatora działającego wg. koncesji, wsiądziecie do samochodu lub autobusu czy metra napędzanego energią wytwarzaną i sprzedawaną przez bynajmniej niecharytatywną firmę z koncesją i pojedziecie do pracy, szkoły, na uczelnię gdzie ktoś was będzie oceniał wg. jakichś tam spisanych reguł i własnego widzimisię, a nie otwartego serca dobrych życzeń…
Może za parę lat dorobicie się męża/żony, dzieci, starszych rodziców lub po prostu zażyłych przyjaciół, którym trzeba pomagać i się nimi opiekować i wtedy nagle dotrze do waszej czupryny olśnienie, że zamiast tracić czas na pisanie czy analizowanie kolejnego tysiączka fantastycznych linijek super wykręconego algorytmu warto porozmawiać przez kilkadziesiąt minut ze swoją 90 letnią babcią, która słabo słyszy, krótko widzi, cicho mówi i zupełnie nie rozumie o co wam chodzi z tym opensource i freeware, ale za to kocha was bardzo i liczy każdą sekundę, którą z nią spędzacie, bo to może być jej ostatnie lato w życiu z wnuczkami… Więc wtedy nazajutrz udacie się opisaną już wyżej drogą do pracy i zamówicie z wolnej ręki profesjonalną usługę utrzymania systemu którym się opiekujecie, tylko po to aby wasi klienci mieli dobrą obsługę na czas w swoich sprawach – bo oni też mają swoje babcie, no a wy będziecie mogli wyjść uczciwie z pracy kilka minut po 17stej, bo wszystko będzie działać i jeszcze raz uda się porozmawiać z babcią zanim…
Resumując,
ten artykuł jest zupełnie bez sensu – nic konstruktywnego do życia nie wnosi, ani nie podaje rozwiązania żadnego istotnego problemu. Ogólnie DNO.
Nie zgadzam się z twoim rozumowaniem. Program napisany jak sam piszesz 21 lat temu i łatany do tej pory to tak jak jeździć do dzisiaj stara Warszawa i twierdząc ze nie ma innego współczesnego samochodu który może zastąpić wysłużoną Warszawę. Oczywiście pomijam tu sentymenty do starych samochodów
Utrzymywanie tak starego programu kosztuje mnóstwo pieniędzy w porównaniu z alternatywami dostępnymi na dzisiejszym rynku. Zupełnie jak ta stara Warszawa którą można zastąpić ekonomicznym współczesnym autem z poduszkami powietrznymi, ABS, klimatyzacja i innymi systemami które były nie do pomyślenia 21 lat temu.
Myślę również ze twoja babcia mogłaby skorzystać z zaoszczędzonych w ten sposób publicznych pieniędzy kiedy by je wydano na na przykład lepsza opiekę lekarska niż pakować je na rachunki firm trzymających sektor publiczny w duszącym uścisku zwanym vendor lock-in.
A mi się wydaje, że zmiana samochodu to trochę mniejszy problem, niż zmiana systemu według którego naliczane są emerytury
.
Wydaje Ci się:) mówimy tutaj na poziomie abstraktu – nie jest ważne czy wymiana samochodu problemowo jest równa wymianie softu. Ważne są efekty tej wymiany, które są w obu przypadkach zyskami. I
Jeśli ktoś tutaj na forum nasłany z ZUS chce twierdzić, że jest inaczej i ucieczka z vendor lock-in nie przynosi zysków to proponuję, by spróbował to opisać i wydać jako pracę naukową, bo nobel pewien – no kidin – Obama dostał pokojowego
OK. To pomysl abstrakcyjnie o F16 produkowanym od 30 lat….
Sugerujesz, że mając F16 nie będę mógł posiadać już eskadr innych (choćby F'ek) samolotów bojowych? interesujące… a "abstrakcyjnie" to właśnie zasugerowałeś w kontekście dyskusji.
Tylko nie można sobie po prostu pójść do sklepu i kupić programu do obsługi ZUS tylko trzeba by było ogłosić przetarg na wdrożenie takiego i (a to nie jest pikuś) przekonwertowanie całej bazy płatników wraz ze sprawdzeniem błędów.
Kris. Demonizujesz. Próbujesz przekazać nieprawdziwe wnioski w podświadomość co mniej obeznanych osób. Starasz się zasugerować, że na open source się nie zarabia (pierwszy fail), że nie ma profesjonalnego wsparcia dla softu open sorurce (drugi jeszcze większy fail – jest i to mam wrażenie czasami na lepszym poziomie niż do zamkniętoźródłowych).
Jak to jest, że są urzędy, które zamawiają softy o porównywalnej złożoności (a może i bardziej złożone) i potrafią wpisać wymóg otwartości źródeł i pełnej dokumentacji. I dzięki temu mają pełną władzę nad dalszym rozwojem projektu. I jeszcze powiem ci, że to działa – bo w kolejnym przetargu potrafią wybrać innego dostawcę rozszerzenia i wszystko biega jak się patrzy…. a ZUS jakoś nie potrafi.
Resumując, Twoja wypowiedź jest zupełnie bez sensu – nic konstruktywnego do dyskusji nie wnosi, nie podejmuje żadnej sensownej polemiki z artykułem, ani nie podaje rozwiązania żadnego istotnego problemu. Ogólnie osiągnąłeś właśnie rzeczony przez siebie poziom: DNO.
Czy na open source nie można zarobić? Oczywiścdie że można! Czy nie ma dla niego wsparcia? Oczywiście że jest! Czy przekazywanie źródeł to dobry pomysł? Oczywiście że tak! Czy pożądna dokumentacja jest niezbędna? Oczywiście że tak! Ale myślenie że uda się przekazać utrzymanie/serwis/rozwój tak złożonego systemu jaki jest w ZUS innej firmie z dnia na dzień (zaraz po wygaśnieciu starego kontraktu) jest kolosalną pomyłką! Kolosalną! Można oczywiście powiedzieć że da się umowę podpisać tak aby kary były w wysokości takiej o jakiej się nikomu nie śniło. Można. Ale co z tego. Ten system musi działać. Musi! Czy wydano na niego za dużo pieniędzy? Z penością. Czy popełniono błędy w trakcie jego realizacji? Bez wątpienia. Ale przekazanie utrzymania tego systemu komuś innemu niż producent/dostawca musi być procesem! Im wcześniej zdacie sobie z tego sprawę (i im wcześniej osoby odpowiedzialne za ten system do tego dojdą) tym prędzej być może będzie możliwe przekazanie utrzymanie/rozwóju tego sytemu innej firmie. Złożoność tego systemu nie polega tylko na tym że w dużej mierze oparty jest o technologie ktore już na wstępnie zawężają grono dostawców/oferentów tylko do największych graczy rynkowych (przeważnie nienajtańsi) ale również na jego "masie". Czas potrzebny na zapoznanie się z jego budową (zastosowana technologia), poznanie mechanizmów działania, wreście miliony linii kodu przez które trzeba się przebić powdują że trzeba to postrzegać jako proces który zajmnie ogromną ilość czasu. Firmy które poświęcą ten czas na to aby poznać ten system po to aby móc potem zaoferować konkurencyjną ofertę (a uważam że tylko w ten sposób ZUS, myśląc poważnie o bezpieczeństwie, jest w stanie wybrać firmę która zapewni bezpieczne działanie/serwis/rozwój tego systemu) na utrzymaniej tego systemu będą musiały zrekompensować sobie koszty poniesione na proces "poznania". Sądzę na chwilę obecną, dopóki nie rozpoczniesię "proces" o którym mówię, wybór aktualnego dostawcy jest najbezpieczniejszy i najlepszy.
Takich ogłoszeń pojawia się wiele, a za każdym razem uzasadnienie jest podobne: ze względu na wcześniej zawarte umowy, tylko jeden wykonawca jest w stanie podjąć się realizacji zadania. Mamy więc do czynienia z sytuacją, gdy urząd uzależniony jest od jednego tylko wykonawcy.
Niestety, systemy komputerowe w urzędach, szczególnie w księgowości, podatkach itp. pojawiły się dość dawno. Przechowują (po wielu latach używania i aktualizacji) dane nieraz setek tysięcy obywateli zgromadzone często w przestarzałej bazie, lub źle zarządzanej przez program. Przykładem jest system SIGID, który dane trzyma w DBF i codziennie trzeba przeprowadzać indeksację, a przynajmniej raz w miesiącu ich technik dokonuje tajemniczych rytów, by reanimować kluczowe bazy.
Niestety, migracja do nowego systemu wydaje się rozwiązaniem o wiele groźniejszym niż utrzymywanie dotychczasowej prowizorki:
1. Mało kto ma takie pojęcie o niuansach księgowości podatkowej jak SIGID
2. Migracja to od 60% do 30% strat w bazie, które trzeba uzupełniać ręcznie. Na wsparcie SIGID nie ma co liczyć, oni w ogóle mają wszystkich w [D].
3. Mimo wszystko są to dane podatkowe o wielkiej wadze nie tylko jako suma informacji, ale też dla każdego poszczególnego obywatela. Pamiętamy jeszcze perturbacje z ZUSem, prawda? Amatorów (właśnie amatorów) na takie wdrożenie jest wielu, niewielu jest zawodowców.
Zatem informatycy będą się zastanawiać jeszcze długo, na co, jeżeli w ogóle, zmigrować, żeby się posypało jak najmniej.