Zamówienia publiczne na oprogramowanie

Wielkość: px
Rozpocząć pokaz od strony:

Download "Zamówienia publiczne na oprogramowanie"

Transkrypt

1 Tomasz Barbaszewski Zamówienia publiczne na oprogramowanie Aspekty technologiczne i finansowe FUNDACJA WOLNEGO I OTWARTEGO OPROGRAMOWANIA POZNAŃ 2010 Publikacja wydana 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. Patronat honorowy Partnerzy merytoryczni 1

2 Autor Tomasz Barbaszewski Wykładowca Uniwersytetu Jagiellońskiego i Politechniki Krakowskiej, doktor fizyki teoretycznej (z zakresu modelowania komputerowego IF PAN Warszawa). Od 1992 r. czynnie zaangażowany w rozwój profesjonalnych systemów komputerowych w Polsce. Współautor wielu zrealizowanych projektów z zakresu bezpieczeństwa IT w tym certyfikowanych przez ABW. Prezes krakowskiej firmy ABA w Krakowie, były dyrektor ds. nowych technologii w firmie Optimus S.A. Od 2008 roku Przewodniczący Rady Ekspertów Fundacji Wolnego i Otwartego Oprogramowania Redakcja Grzegorz Kmita Fotografie Archiwum sxc.hu Wydawca Fundacja Wolnego i Otwartego Oprogramowania ul. Wawrzyniaka 10, Poznań tel , fax POZNAŃ

3 Wprowadzenie P 1 rzedstawione opracowanie poświęcono analizie możliwości wykorzystywania wolnego i otwartego oprogramowania w administracji państwowej. Opracowanie ma charakter prezentacji strategii biznesowo-technicznej i nie odnosi się szczegółowo do zagadnień prawnych. 3 Pierwszą część opracowania poświęcono omówieniu podstawowych modeli tworzenia oprogramowania oraz ich właściwości. Analizę przeprowadzono dla następujących typów oprogramowania: komercyjnego z półki (COTS Commercial Off The Shelf), przygotowywanego na indywidualne zamówienie (NDI Non Developmental Item) oraz Wolnego i Otwartego Oprogramowania (FOSS Free Open Source Software). Zestawiono również najważniejsze czynniki sukcesu oraz ryzyka związane z wykorzystywaniem tych rodzajów oprogramowania. W dalszej części opracowania przedstawiono definicję i podstawowe właściwości Systemu Otwartego (Open System) przyjmując za wzorcowe opracowania Software Engineering Institute (SEI) Carnegie Mellon University oraz omówiono strategię akwizycji systemów IT opartą o procedury MOSA (Modular Open System Approach) zalecaną przez Departament Obrony USA oraz stosowaną przez szereg jednostek administracyjnych i przedsiębiorstw komercyjnych. Przedstawiono pięć podstawowych etapów prac związanych z pozyskaniem nowego systemu lub modernizacją istniejących rozwiązań. Szczególną uwagę poświęcono zgodności projektu (i co za tym idzie rozwiązania) informatycz-

4 ZAMÓWIENIA PUBLICZNE NA OPROGRAMOWANIE ASPEKTY TECHNOLOGICZNE I FINANSOWE nego z procesami realizowanymi przez jednostkę organizacyjną i zgodność z podejściem procesowym stosowanym przez rodziny norm ISO: 9000 oraz Przeanalizowano także role poszczególnych grup ludzkich, które będą korzystać z systemu lub dbać o jego poprawną eksploatację: użytkowników, pracowników IT oraz decydentów właścicieli systemu, odpowiedzialnych za sprawy budżetowe. Zgodnie z zasadami zarządzania przez jakość wzięto także pod uwagę zagadnienia związane z eksploatacją i modernizacją systemu oraz potrzeby szkolenia w podziale na poszczególne grupy (użytkownicy, administratorzy itp.). Końcową część opracowania poświęcono analizie możliwości zastosowania Wolnego i Otwartego Oprogramowania do realizacji standardowego stanowiska pracy urzędnika szczebla podstawowego. Analizę przeprowadzono etapowo, zgodnie z zaleceniami strategii Modular Open System Approach: 1. Określenie potrzeb 2. Zdefiniowanie struktury modularnej 3. Określenie kluczowych interfejsów 4. Analiza dostępnych rozwiązań i standardów 5. Weryfikacja założeń i testy rozwiązania. Otrzymane rezultaty porównano z wymaganiami obowiązującymi dla przetargów publicznych. Ograniczono się do części opisowo-technicznej dokumentacji przetargowej (Specyfikacja Istotnych Warunków Zamówienia) oraz warunków, jakie powinna ona spełniać, aby zagwarantować wybór rozwiązania odpowiadającego rzeczywistym potrzebom biznesowym jednostki organizacyjnej oraz zachowanie warunków swobodnej konkurencji pomiędzy oferentami. 4

5 1 / Modele rozwoju oprogramowania programowanie licencjonowane komercyjnie można podzielić na dwie podsta- O wowe grupy: Oprogramowanie COTS (Commercial Off The Shelf), dostarczane w formie gotowego, zamkniętego produktu, dostępnego w systemie sprzedaży hurtowej oraz detalicznej. Do tej grupy mogą należeć zarówno systemy operacyjne (popularne MS Windows), programy narzędziowe (np. systemy antywirusowe) jak i użytkowe (zintegrowane systemy typu Office). Oprogramowanie NDI (Non Developmental Item) przygotowane specjalnie dla określonego użytkownika (w przypadku, którego dotyczy ta analiza dla administracji państwowej) według przedstawionych przez tego użytkownika wymagań (np. system obsługi Zakładu Ubezpieczeń Społecznych, Policji, Urzędów Skarbowych itp.). 1.1 / Oprogramowanie COTS (Commercial Off The Shelf ) Oprogramowanie w obu grupach różni się zasadniczo przebiegiem procesu, w wyniku którego powstaje. W przypadku gotowego, udostępnianego z półki oprogramowania proces analizy potrzeb oraz projektowania oprogramowania pozostaje pod całkowitą kontrolą jego producenta. Kieruje się on wieloma czynnikami, z których najistotniejsze to: pozycjonowanie produktu na wolnym rynku, analiza potrzeb wielu grup użytkowników, możliwości ogólnie dostępnego sprzętu, zasoby i doświadczenia własne, wymagania zgłaszane przez sieć dystry- -bucyjną. W konsekwencji powstaje produkt nastawiony na spełnienie wymagań przeciętnego użytkownika, a co za tym idzie możliwy do zaoferowania jak największej liczbie klientów. Producenci zdają sobie sprawę ze słabości tej strategii, więc starają się oferować podprodukty np. wersje Lite, Home, Professional czy Ultimate, które wyposażane są w różne zestawy realizowanych funkcji. Produkty tego typu są kierowane na szeroki rynek i nie można liczyć, że będą się nimi opiekować specjaliści z zakresu IT. Dlatego więc producenci przykładają tak wielką wagę do łatwej instalacji, możliwego uproszczenia procesu kon- 5

6 ZAMÓWIENIA PUBLICZNE NA OPROGRAMOWANIE ASPEKTY TECHNOLOGICZNE I FINANSOWE figuracji (np. mechanizmy plug & play), oraz unikania edycji plików konfiguracyjnych na korzyść list wyboru lub innych funkcji obsługiwanych przez urządzenia wskaźnikowe (myszkę itp.). Minimalizuje to możliwość popełniania błędów, a tym samym redukuje koszty wsparcia technicznego. Wiele osób używa w stosunku do programów tej grupy pojęcia zakup oprogramowania, które jest oczywiście całkowicie błędne. Zgodnie z dokumentami dostarczanymi przez producenta otrzymujemy bowiem jedynie Prawo do użytkowania (Right to Use) oprogramowania. Najczęściej przedmiotem zakupu są dwie pozycje: 1. nośnik z oprogramowaniem oraz dokumentacja (w formie książkowej lub elektronicznej), 2. wspomniane już Prawo do użytkowania obwarowane zazwyczaj wieloma ograniczeniami (np. zakaz analizy i modyfikowania kodu, wynajmowania lub przekazywania itp.). O ile pozycja 1 jest objęta gwarancją (najczęściej w formie wymiany wadliwego nośnika) to pozycja 2 jest zazwyczaj wyłączona z odpowiedzialności (często stosowana jest tu formuła w maksymalnym zakresie dozwolonym przez prawo ). Powstaje więc problem świadczenia wsparcia technicznego dla oprogramowania, z którego korzysta użytkownik. Polityka świadczenia tego wsparcia jest uzależniona o producenta. Jeśli Prawo do użytkowania dotyczy stosunkowo niewielkiej liczby użytkowników np. kilku-kilkunastu tysięcy producenci starają się organizować wsparcie techniczne we własnym zakresie, oferując je w formie terminowych kontraktów (Maintenance Contract). Jest to płatna dodatkowo usługa, która musi być zakupiona albo obligatoryjnie, albo jako opcja. Jeśli Prawo do użytkowania jest udzielane bardzo dużej liczbie użytkowników, producent przenosi najczęściej obowiązki związane ze świadczeniem wsparcia technicznego na swych partnerów handlowych, lub w przypadkach bardziej wymagających programów tworzy odrębną sieć autoryzowanych ośrodków wsparcia technicznego. Podobna polityka jest prowadzona przy oferowaniu szkoleń. Uprawnienia użytkownika (zarówno domowego, jak i instytucjonalnego) są w przypadku oprogramowania z półki bardzo ograniczone. Producenci realizują te ograniczenia w dwojaki sposób: poprzez dostarczanie oprogramowania jedynie w postaci kodów wykonywalnych, poprzez wprowadzenie ograniczeń natury prawnej np. zakaz analizy kodu i prób jego modyfikacji. Co więcej, takie próby nie są karane np. jedynie utratą gwarancji, lecz ścigane na mocy przepisów prawa autorskiego. 1.2 / Oprogramowanie na zamówienie (NDI Non Developmental Item ) Jest to oprogramowanie tworzone na specjalne zamówienie przyszłego użytkownika. Bardzo często jest dostarczane wraz z produktem dostępnym z półki np. wraz z systemem obsługi bazy danych. Może być dostarczone użytkownikowi zarówno w formie zamkniętej, jak i otwartej, zaś zasady jego wykorzystywania mogą być każdorazowo uzgodnione pomiędzy wykonawcą a zamawiającym. Ze względu na unikalność oprogramowania zarówno wsparcie techniczne, jak i szkolenia są z zasady realizowane przez realizującego zamówienie na wykonanie oprogramowania. W przeciwieństwie do oprogramowania dostępnego z półki, użytkownik ma w tym przypadku duże możliwości negocjacji warunków kontraktu a nawet może wpływać na proces powstawania oprogramowania. Może także zagwarantować sobie dostarczenie kodów źródłowych (także z prawem do ich modyfikacji). Czynniki ryzyka i sukcesu tych rodzajów oprogramowania na s. 9. 6

7 MODELE ROZWOJU OPROGRAMOWANIA OP ROGRAMOWANIE Z PÓŁKI (COT S ) Oprogramowanie jest pod całkowitą kontrolą producenta. Wszelkie negocjacje warunków dostawy oraz obsługi są bardzo trudne, o ile w ogóle możliwe. W wyniku transakcji zakupu otrzymujemy jedynie nośnik (lub kopię elektroniczną) oraz bardzo ograniczone prawo do wykorzystywania oprogramowania. Wsparcie techniczne nie jest zazwyczaj zawarte w cenie Praw do wykorzystywania należy je zakupić osobno. Konfiguracja oprogramowania jest możliwa jedynie w granicach przewidzianych i dozwolonych przez producenta. Odstępstwa od tej zasady są ścigane prawnie. Brak możliwości analizy kodu oprogramowania ogranicza w praktyce możliwości jego audytu tylko do testów penetracyjnych typu Black Box. Występuje bardzo duże ryzyko uzależnienia się od określonego dostawcy (vendor lock-in), a tym samym znaczne ograniczenie możliwości modernizacji systemu. Oprogramowanie najczęściej nie posiada architektury modularnej. Uniemożliwia (lub znacznie utrudnia) to wymianę określonych funkcji systemu. Producenci oprogramowania starają się wprowadzać własne standardy licząc, że duża liczba użytkowników oprogramowania spowoduje uznanie ich za standardy de facto i dzięki temu uzyskają przewagę nad konkurencją. Standardy te są najczęściej nieudokumentowane lub udokumentowane jedynie częściowo. Wybór oprogramowania ogranicza się w praktyce jedynie do wyboru bezpośredniego dostawcy. Zamawiający nie ma wpływu na techniczne właściwości oprogramowania. CZYNNIKI RYZYKA CZYNNIKI SUKCESU OP ROGRAMOWANIE NA ZAM ÓW IENIE (NDI) Oprogramowanie powstaje we współpracy z Zamawiającym. Wydłuża to proces projektowania, testowania oraz wdrożenia. Znacznie wyższa cena oprogramowania. Uprawnienia użytkownika mogą być negocjowane. Wsparcie techniczne jest świadczone bezpośrednio przez realizującego zamówienie. Konfiguracja oprogramowania najczęściej wymaga posiadania odpowiedniej wiedzy specjalistycznej i jest realizowana przez pracowników IT. Konieczność przeprowadzenia szczegółowego odbioru oprogramowania oraz weryfikacji kompletności jego dokumentacji. Występuje bardzo duże ryzyko uzależnienia się od określonego dostawcy (vendor lock-in), a tym samym znaczne ograniczenie możliwości modernizacji systemu. Oprogramowanie najczęściej nie posiada architektury modularnej. Uniemożliwia (lub znacznie utrudnia) to wymianę określonych funkcji systemu. Producenci oprogramowania starają się wprowadzać własne standardy licząc, że duża liczba użytkowników oprogramowania spowoduje uznanie ich za standardy de facto i dzięki temu uzyskają przewagę nad konkurencją. Standardy te są najczęściej nieudokumentowane lub udokumentowane jedynie częściowo. Wysokie koszty szkoleń (niezbędne jest indywidualne szkolenie specjalistów IT) oraz wdrożenia. Wybór rozwiązania wymaga starannego rozpoznania możliwości oferentów oraz pracochłonnych testów proponowanych rozwiązań a wielokrotnie także wdrożenia pilotażowego. OP ROGRAMOWANIE Z PÓŁKI (COT S ) Popularność oprogramowania i powszechna umiejętność jego obsługi na podstawowym poziomie. Procedura instalacji i konfiguracji oprogramowania nie wymaga zaawansowanej wiedzy specjalistycznej. Przystosowanie oprogramowania do pracy na typowym, powszechnie dostępnym sprzęcie. W przypadku systemu operacyjnego dostęp do wielu (choć w większości płatnych) programów narzędziowych lub użytkowych. Oferowanie oprogramowania (odsprzedaż Praw do wykorzystywania ) przez wiele podmiotów, co pozwala na wybór najkorzystniejszej oferty. OP ROGRAMOWANIE NA ZAM ÓW IENIE (NDI) Możliwość dostosowania oprogramowania do własnych potrzeb. Łatwa współpraca z wykonawcą oprogramowania oraz możliwość wpływu na jego funkcjonalność oraz ergonomię. Zdefiniowana odpowiedzialność wykonawcy, możliwość uzyskania kompetentnego wsparcia technicznego. Możliwość negocjowania przekazania praw autorskich, dostępu do kodu źródłowego, praw do modyfikacji i uzupełnień. Prosta organizacja procedur testowania, odbioru oraz audytu oprogramowania, zgodności z założeniami, funkcji bezpieczeństwa itp. 7

8 ZAMÓWIENIA PUBLICZNE NA OPROGRAMOWANIE ASPEKTY TECHNOLOGICZNE I FINANSOWE W praktyce najczęściej spotyka się rozwiązania wykorzystujące zarówno oprogramowanie z półki, jak i współpracujące z nim oprogramowanie opracowane na zamówienie. W urzędach administracji państwowej w Polsce stosuje się wiele programów specjalistycznych, które zostały przygotowane przez niezależne firmy programistyczne (ISV Independent Software Vendor). Proces opracowania tych programów był realizowany w sposób charakterystyczny dla oprogramowania przygotowywanego na zamówienie lecz po uzyskaniu przez firmę programistyczną akceptacji (a niekiedy również formalnej homologacji) oprogramowanie to posiada bardzo zbliżone właściwości do oprogramowania z półki. Przykładem może być choćby System Ewidencji Ludności. Ze względu na współpracę ze scentralizowanym systemem PESEL (Powszechny System Ewidencji Ludności) jego funkcjonalność jest ściśle określona przez system nadrzędny i z tego względu może on być masowo powielany. Firma typu ISV zazwyczaj opracowuje taki program dla określonego środowiska systemowego (najczęściej korzystając z programów dostępnych z półki ) i uzyskuje tym samym wpływ na jego wybór. Ogranicza to niewątpliwie możliwość swobodnej konkurencji. Systemy tego typu są najczęściej dystrybuowane przez sieć partnerską ISV na identycznych zasadach, jak oprogramowanie dostępne z półki, jednak zazwyczaj wsparcie techniczne jest świadczone bezpośrednio przez ISV tak jest np. dla większości systemów obsługi finansowej, płacowej itp. 1.3 / Wolne i Otwarte Oprogramowanie (WiOO, ang. FOSS Free Open Source Software lub FLOSS Free/Libre Open Source Software) Podstawowe właściwości tego oprogramowania wiążą się z zupełnie innym podejściem do ochrony praw autorskich. Znacznie upraszczając zagadnienie, autor (lub podmiot gospodarczy) zrzeka się praw majątkowych zachowując oczywiście prawa osobiste. Klasyczny model Wolnego i Otwartego Oprogramowania spełnia wszystkie 4 Wolności zdefiniowane przez Richarda M. Stallmana, założyciela Free Software Foundation: wolność wykorzystywania, wolność analizowania i modyfikowania, wolność rozpowszechniania, wolność ulepszania pod warunkiem zachowania pierwszych trzech wolności. Z oczywistych powodów technicznych dla zagwarantowania powyższych wolności wymagany jest dostęp do kodu źródłowego oprogramowania czyli jego otwartość. Stąd więc wynika dwuprzymiotnikowość nazwy takiego oprogramowania. Uprawnienia użytkownika Wolnego i Otwartego Oprogramowania są więc praktycznie nieograniczone jednak należy zwrócić uwagę, że wymogiem prawnym jest uzyskanie wiarygodnej informacji o dozwolonych działaniach (polach eksploatacji) utworu podlegającego ochronie w ramach przepisów ustawowych. Dozwolone pola eksploatacji określa dokument zwany potocznie licencją (ścisłe znaczenie prawne terminu licencja jest nieco inne). Przed przystąpieniem do eksploatacji oprogramowania należy się więc koniecznie zapoznać z uprawnieniami, których udziela nam właściciel praw autorskich. Wynika stąd, że wraz z oprogramowaniem powinniśmy otrzymać dokument, który to precyzyjnie określa. Rozważając wykorzystywanie Wolnego i Otwartego Oprogramowania należy wziąć pod uwagę proces jego powstawania. Zasadą jest w tym przypadku tak zwany Rozproszony rozwój technologiczny (Shared Technology Development). Wiele projektów jest rozpoczynanych przez uczelnie lub ośrodki naukowo-badawcze w ramach finansowanych również ze środków rządowych wystarczy tu wymienić takie projekty jak APACHE (NCSA National Center for Supercomputing Applications, któremu także zawdzięczamy jedną w pierwszych graficznych przeglądarek stron WWW NSCA Mosaic), Security-Enhanced Linux (projekt rozpoczęty przez US National Security Agency), klastery Beowulf (NASA) itp. Projekty te są często kontynuowane i rozwijane już przez niezależne organizacje. 8

9 MODELE ROZWOJU OPROGRAMOWANIA W ostatnich latach coraz częściej w sponsorowanie projektów Wolnego i Otwartego Oprogramowania włączają się duże firmy komercyjne IBM, Novell, Sun itp. Powstają również wolne wersje programów oferowanych jako oprogramowanie z półki np. OpenOffice i StarOffice. Nieprawdziwe są więc opinie, że Wolne i Otwarte Oprogramowanie tworzone jest jedynie przez studentów czy hobbystów jednym słowem, przez nieprofesjonalistów. Po prostu model rozwoju takiego oprogramowania jest modelem opartym o działania rozproszone, co jednak absolutnie nie wyklucza udziału najwyższej klasy profesjonalistów. Oczywiście rozwój oprogramowania według takiego modelu wymaga pełnej dostępności kodu źródłowego oraz zezwolenia na jego modyfikowanie. Rozproszony rozwój oprogramowania powoduje jednak także problemy. Pierwszym jest brak zainteresowania firm dystrybucyjnych. Jest on całkowicie zrozumiały, ponieważ pomimo, że nie ma żadnego zakazu odsprzedaży Wolnego i Otwartego Oprogramowania to może ono być bez ograniczeń kopiowane i rozpowszechniane (trzecia wolność R. M. Stallmana). Jest to zasadnicza różnica w porównaniu z oprogramowaniem licencjonowanym komercyjnie, gdzie użytkownik nie ma prawa do redystrybucji. W dodatku dystrybutor (dostawca) musi poinformować użytkownika o jego prawach do nieograniczonego wykorzystywania oraz rozpowszechniania Wolnego i Otwartego Oprogramowania, ponieważ jest zobowiązany do załączenia dokumentu licencyjnego. Wyklucza to z góry stosowany powszechnie system udzielania praw do korzystania z oprogramowania na każdej stacji roboczej (lub pojedynczym użytkownikom) osobno, wprowadzanie mechanizmów kontrolnych, kodów aktywacyjnych itp. Drugi problem wiąże się z tym, że Wolne i Otwarte Oprogramowanie jest dostarczane bez gwarancji. Jest to zrozumiałe, ponieważ jeśli dopuszcza się prawo do dowolnej modyfikacji oprogramowania, to trudno udzielać gwarancji na nieznane jeszcze i wprowadzane przez trzecią stronę modyfikacje. Wprowadzenie jakiejkolwiek formy gwarancji na oprogramowanie wyklucza również w praktyce model rozproszonego rozwoju. Warto jednak zwrócić uwagę, że gwarancje udzielane na oprogramowanie licencjonowane komercyjnie dostępne z półki ograniczają z zasady odpowiedzialność producenta jedynie do wymiany oprogramowania lub zwrotu opłaty za zakupione Prawo do wykorzystywania. W przypadku Wolnego i Otwartego Oprogramowania Prawo do użytkowania otrzymujemy nieodpłatnie, i to bez żadnych ograniczeń gwarancja polegająca na zwrocie kosztów zakupu tego prawa byłaby więc pozbawiona jakiegokolwiek sensu. 1.4 / Realizacja wsparcia technicznego Wsparcie techniczne dla Wolnego i Otwartego Oprogramowania jest realizowane na dwa sposoby: w rozproszonym modelu społecznościowym, na podstawie zawartych kontraktów na świadczenie takiego wsparcia (Maintenance Contracts). Pierwszy model jest odpowiedni raczej dla indywidualnych użytkowników zaskakuje jednak swoją wysoką efektywnością, aczkolwiek oczywiście nie gwarantuje czasu rozwiązania problemu. Drugi przeznaczony jest głównie dla instalacji wykorzystywanych dla celów profesjonalnych i jest realizowany odpłatnie przez określony podmiot prawny (dostawcę oprogramowania lub całego rozwiązania, urządzenia wykorzystującego wolne oprogramowanie itp.). Należy zdecydowanie podkreślić, że oba powyższe modele są również wykorzystywane dla oprogramowania licencjonowanego komercyjnie jako uzupełnienie ograniczonej (często do absolutnego minimum) gwarancji. Zawarcie dobrego kontraktu na świadczenie wsparcia technicznego w przypadku instalacji 9

10 ZAMÓWIENIA PUBLICZNE NA OPROGRAMOWANIE ASPEKTY TECHNOLOGICZNE I FINANSOWE profesjonalnej powinno być regułą niezależnie od rodzaju oprogramowania, ponieważ tylko w przypadku precyzyjnego określenia obowiązków stron można dochodzić ewentualnych roszczeń z tytułu niedopełnienia zobowiązań przyjętych umową na świadczenie wsparcia technicznego. Koniecznie należy także zwrócić uwagę na zagadnienia prawne związane z realizacją umowy na świadczenie takiego wsparcia w przeciwnym razie można napotkać nieprzewidziane trudności. Źle zawarta umowa serwisowa może doprowadzić do uzależnienia od dostawcy/serwisanta, nadmiernych i nieuzasadnionych kosztów opieki serwisowej itp. Mogą także wystąpić poważne trudności z rozwiązaniem takiej umowy zwłaszcza w przypadku oprogramowania licencjonowanego komercyjnie. Problemy z tym związane dotknęły już kilku ważnych organizacji państwowych w Polsce i zostały nawet odnotowane w prasie. Rozproszony model rozwoju Wolnego i Otwartego Oprogramowania minimalizuje powyższe ryzyko, ponieważ nie występuje tu producent dysponujący wszystkimi prawami do oprogramowania. Kody oprogramowania są dostępne dla wszystkich (w tym oczywiście przede wszystkim dla użytkownika). Zachowuje on więc pełną swobodę działania nawet w przypadku konieczności zerwania umowy o świadczenie wsparcia technicznego i serwisu oprogramowania. Może wówczas wybrać inny podmiot oferujący odpowiadające mu usługi lub nawet serwisować system we własnym zakresie zatrudniając odpowiednich specjalistów. Ma to również duże znaczenie w przypadku systemów przetwarzających i przechowujących informacje i dane wymagające szczególnej ochrony. Czynniki sukcesu i ryzyka związane ze stosowaniem Wolnego i Otwartego Oprogramowania patrz: s

11 MODELE ROZWOJU OPROGRAMOWANIA Stosowanie Wolnego i Otwartego Oprogramowania czynniki sukcesu i ryzyka N A JWA ŻNIEJSZE CZY N N IKI SUKCES U Pełna kontrola nad oprogramowaniem dostęp do kodu źródłowego, specyfikacji interfejsów itp. Możliwość zastosowania otwartej i modularnej architektury systemu i w konsekwencji zachowanie wymienialności poszczególnych modułów. Wysoki stopień standaryzacji oraz interoperacyjności. Brak uzależnienia od dostawcy oprogramowania. Bardzo duże możliwości dostosowywania funkcjonalności systemu do rzeczywistych potrzeb. Możliwość swobodnego rozwoju systemu (uaktualnienia, modernizacje itp.) przy pełnym zachowaniu jego funkcjonalności. Duży wybór oprogramowania narzędziowego. Brak uzależnienia wsparcia technicznego od decyzji producenta (autoryzowane ośrodki wsparcia itp.). Pełna i kompetentna obsługa serwisowa systemu może być realizowana zarówno we własnych zakresie, jak i przez dowolnie wybrany podmiot zewnętrzny. Szkolenia użytkowników mogą być prowadzone niezależnie od producenta i autoryzowanej przez niego sieci ośrodków edukacyjnych itp. Możliwość wprowadzenia centralizacji systemu bez dodatkowych kosztów licencyjnych a nawet przy ich ograniczeniu. Duże możliwości współpracy z produktami trzeciej ręki w tym także z systemami korzystającymi z oprogramowania licencjonowanego na zasadach komercyjnych. Możliwość osiągnięcia wysokiego poziomu bezpieczeństwa bez potrzeby ponoszenia dodatkowych kosztów. Powszechna dostępność dodatkowego oprogramowania zabezpieczającego w domenie publicznej (oprogramowanie antywirusowe, antyspamowe, firewall, do tworzenia kopii awaryjnych itp.). Pełne możliwości audytu systemu od weryfikacji projektu poprzez poprawność implementacji aż po testy funkcjonalne i penetracyjne. Proste wdrożenie Systemu Zarządzania Bezpieczeństwem Informacji. N A JWAŻNIE JSZE CZY NN IKI RY ZYKA Konieczność precyzyjnego określenia funkcjonalności systemu. Ograniczony dostęp do oprogramowania użytkowego powszechnego użytku. Możliwe trudności w komunikacji z innymi systemami występujące w przypadku stosowania przez te systemy zamkniętych i nie w pełni udokumentowanych standardów. Przekazanie zbyt dużych uprawnień użytkownikom może spowodować zakłócenia w pracy systemu i konieczność interwencji serwisowej. Przyzwyczajenia użytkowników i konieczność ich przeszkolenia. Ograniczenie możliwości wykorzystywania komputerów (stanowisk pracy) do celów pozasłużbowych może spowodować próby zdyskredytowania oprogramowania jako nie nadającego się do pracy. W przypadku administracji narzucanie wykorzystywania (nawet wbrew obowiązującym przepisom wyższego rzędu) konkretnego oprogramowania licencjonowanego komercyjnie (np. arkuszy kalkulacyjnych zawierających złożone funkcje). Zwiększenie wymagań stawianych administratorom systemu (informatykom) zwłaszcza w systemach o dużym stopniu centralizacji. Może to skutkować próbami storpedowania wdrożenia. Trudniejszy wybór partnerów zewnętrznych ze względu na brak rekomendacji przez producenta. Dotyczy to zarówno samej dostawy, jak i przeprowadzenia szkoleń, wdrożenia itp. Ryzyko wdrożenia niewystarczająco udokumentowanego systemu o unikalnych właściwościach zbliżonych do systemu zamkniętego. Konieczność zarządzania dokumentacją oprogramowania, zmianami w nim dokonywanymi przez instytucję wykorzystującą oprogramowanie lub na zasadzie zlecenia zewnętrznego najlepiej zgodnie z zaleceniami normy PN ISO/OSI

12 2 / Kryteria wyboru oprogramowania system otwarty i zamknięty P omimo bardzo szybkiego rozwoju Wolnego i Otwartego Oprogramowania nie należy oczekiwać, że wyprze ono z rynku oprogramowanie licencjonowane komercyjnie. Zwłaszcza w segmencie użytkowników indywidualnych (domowych) powinno ono zachować znaczną przewagę jeszcze przez długi okres czasu z uwagi na to, że oferuje ono łatwe uruchamianie różnych dodatkowych funkcji komputera PC wykorzystywanego jako centrum rozrywki, konsoli gier itp. Obecna przewaga licencjonowanego komercyjnie systemu MS Windows jest w tym segmencie przytłaczająca i zapewne nie ulegnie to istotnej zmianie w dającej się przewidzieć przyszłości. Z drugiej strony coraz więcej podmiotów biznesowych wykorzystuje Wolne i Otwarte Oprogramowanie ze względów ekonomicznych. Również na wielu komputerach domowych coraz częściej pojawia się Wolne Oprogramowanie. Analiza rozwoju komputerów osobistych, a później sieci komputerowych wskazuje na bardzo silną tendencję do standaryzacji rozwiązań wokół rozwiązań otwartych. Co więcej, nawet najwięksi producenci sprzętu i oprogramowania są zmuszeni przez rynek do dostosowywania się do otwartych standardów, a nie odwrotnie. Dowodem jest choćby prawie absolutna dominacja architektury INTEL, sieci Ethernet i protokołu TCP/IP. Konkurencyjne rozwiązania nie są już rozwijane. Z bardzo dużym prawdopodobieństwem można przyjąć, że tendencja ta obejmie także wkrótce warstwę aplikacyjną. Świadczy o tym trwający proces standaryzacji różnych formatów plików pomimo sporych kontrowersji jest on już bardzo zaawansowany, a w niektórych przypadkach wręcz zakończony. Przystępując do projektowania lub modernizacji systemu należy niewątpliwie te fakty wziąć pod uwagę. Celem powinno być zbudowanie systemu, który będzie odpowiadał zarówno obecnym warunkom, charakteryzował się neutralnością technologiczną, nie powodował wykluczenia z przyczyn technicznych żadnej z grup potencjalnych użytkowników i mógł być w sposób ciągły modernizowany w celu przystosowywania go do zmieniających się warunków zewnętrznych. 12 System otwarty jest więc bardzo atrakcyjnym rozwiązaniem. Jego właściwości techniczne, możliwość adaptacji, wprowadzania nowych technologii, standaryzacja oraz oczywiście koszty całkowite przewyższają pod każdym względem rozwiązania systemów zamkniętych.

13 KRYTERIA WYBORU OPROGRAMOWANIA SYSTEM OTWARTY I ZAMKNIĘTY Nie należy ukrywać, że wdrożenie z sukcesem systemu opartego w dużym stopniu na Wolnym i Otwartym Oprogramowaniu jest bardziej złożone i pracochłonne i wymaga większej wiedzy od członków zespołu integracyjno wdrożeniowego. Sytuacja jednak ulega szybkim zmianom i poziom wiedzy technicznej wśród kadry IT także bardzo szybko wzrasta. Powszechna dostępność szybkiego Internetu, ogromne (i, co najważniejsze, otwarte dla wszystkich chętnych) zasoby wiedzy związanej z Wolnym i Otwartym Oprogramowaniem, a wreszcie nieodpłatny dostęp do samego oprogramowania znacznie ograniczyły znaczenie tego czynnika ryzyka. System zamknięty i system otwarty porównanie SYST E M ZAMKNIĘTY Wykorzystuje unikalne, nieudokumentowane interfejsy, formaty danych, języki programowania oraz protokoły zarządzane przez ich dostawcę lub organizacje od niego zależne. Przy opracowaniu systemu przykładana jest waga do wprowadzania jak największej ilości unikalnych funkcji i właściwości w celu osiągnięcia przewagi nad konkurencją. Nie przykłada się wagi do zachowania modularności systemu. Tendencja do tworzenia rozwiązań, które będą mogły być powielane możliwie najmniejszym kosztem. Ograniczona do jednego, określonego środowiska kompatybilność z innymi rozwiązaniami. Rozwój, modernizacja oraz uaktualnianie systemu wiążą się z kosztami, które są określane arbitralnie przez producenta. Wysoki koszt całkowity (TCO). Ograniczony i kosztowny transfer wiedzy technologicznej. Ograniczony czas życia. Ograniczone możliwości adaptacji dla potrzeb nowych wprowadzanych technologii. Koncentracja na obecnych uśrednionych potrzebach oraz redukcji kosztów opracowania systemu. Silne uzależnienie od integratorów, dostawców oraz producentów. Proste testy zgodności w określonym środowisku utrudniona i kosztowna współpraca z innymi środowiskami. SYST E M OTWA RTY Wykorzystuje publicznie dostępne i powszechnie akceptowane interfejsy, formaty danych, języki programowania oraz protokoły. Szczególna uwaga jest przykładana do interfejsów i systemu zarządzania nim oraz przestrzegania ogólnie przyjętych konwencji. Zachowanie modularności systemu jest priorytetem w procesie jego tworzenia. Niezależność od producentów oraz technologii. Bardzo wysoka interoperacyjność, skalowalność oraz kompatybilność z innymi rozwiązaniami. Wykorzystywanie rozwiązań i produktów pochodzących z różnych źródeł. Rozwój, modernizacja oraz uaktualnianie systemu nie pociągają za sobą znacznych kosztów i mogą być realizowane z zachowaniem swobodnej konkurencji. Niski koszt całkowity (TCO). Swobodny dostęp do najnowszych baz wiedzy technologicznej. Długi czas życia. Szybka adaptacja pojawiających się nowych technologii. Łatwe dostosowywanie systemu do indywidualnych potrzeb użytkownika. Symbioza w relacjach z integratorami, dostawcami i producentami. Otwartość na rozwiązania nowych podmiotów. Skomplikowane i wymagające testy współpracy modułów pomiędzy sobą oraz systemu z innymi środowiskami. 13

14 3 / Przygotowanie do wdrażania oprogramowania (Modular Open System Approach ) 3.1 / Etap pierwszy określenie potrzeb Jest to chyba najważniejszy, a często zaniedbywany etap budowy lub modernizacji systemu. Cele, jakim ma służyć system, są ściśle zdeterminowane przez procesy realizowane przez organizację. Wiele jednostek administracyjnych ma wdrożone systemy rodziny ISO 9000, a nawet ISO 27000, które są oparte na podejściu procesowym, określenie więc funkcji, jakich wymagamy od systemu, a tym samym w przypadku jednostki administracyjnej stanowiska pracy urzędnika lub funkcjonariusza, nie powinno stanowić większego problemu. Na tym etapie absolutnie nie należy dokonywać żadnego wyboru rozwiązania należy jedynie przeprowadzić rzetelną inwentaryzację rzeczywistych potrzeb. Będzie ona stanowić podstawę dalszych etapów wdrażania systemu. Potrzeby powinny być bezwzględnie umotywowane, a ich związek z procesami biznesowymi udokumentowany. Na tym etapie nie należy uwzględniać żadnych potrzeb, które ewentualnie mogą wystąpić w przyszłości, lub które nie mają związku z procesami biznesowymi lub związek nie jest oczywisty. Możliwość ewentualnej rozbudowy systemu zostanie uwzględniona w następnych etapach. 14

15 PRZYGOTOWANIE DO WDRAŻANIA OPROGRAMOWANIA mu operacyjnego. W ten sposób skutecznie można zrealizować podstawowy cel architektury modularnej zapewnienie gotowości na zmiany (Designing for Change). Dążenie do wymienności poszczególnych modułów niezależnie od innych jest zawsze uzasadnione, ponieważ uzyskujemy dzięki temu swobodę wyboru najkorzystniejszego, dostępnego w danej chwili (także w przyszłości) rozwiązania i rozwój systemu może przebiegać drogą ewolucyjną poprzez wymianę poszczególnych modułów w dłuższym czasie a nie rewolucyjną, wymagającą znacznej przebudowy systemu. 3.2 / Etap drugi zdefiniowanie modułów Na tym etapie należy dokonać podziału potrzeb na możliwie niezależne moduły funkcjonalne. W zakresie przedstawianego opracowania skoncentrowano się z oczywistych powodów na typowych funkcjach realizowanych przez następujące moduły: system operacyjny, oprogramowanie biurowe, oprogramowanie do przeglądania Internetu, oprogramowanie do obsługi poczty elektronicznej, które w większości przypadków będą wykorzystywane na każdym stanowisku pracy. 3.3 / Etap trzeci zarządzanie interfejsami Wymienione powyżej moduły powinny oczywiście współpracować pomiędzy sobą wymieniając informacje za pośrednictwem interfejsów. Powinny jednak być w najwyższym możliwym stopniu wymienne np. oprogramowanie do przeglądania Internetu nie powinno być trwale zintegrowane z systemem operacyjnym oraz z oprogramowaniem biurowym itp. Na tym etapie powinniśmy dokonać wyboru interfejsów, które uznamy za kluczowe dla działania naszego systemu. Niezależnie od tego, czy są to interfejsy wewnętrzne (pomiędzy modułami) lub zewnętrzne, za pomocą których system komunikuje się z otoczeniem, kluczowe interfejsy powinny korzystać w Otwartych Standardów. Jeśli taki standard nie jest dostępny lub nie spełnia naszych wszystkich wymagań, konieczne będzie sporządzenie kompletnej i precyzyjnej dokumentacji interfejsu. Uzyskanie takiej dokumentacji od dostawców zewnętrznych bywa często utrudniane. Dostawcy motywują to najczęściej tajemnicą handlową (sic!) lub koniecznością zachowania bezpieczeństwa komunikacji. Przyjęcie rozwiązania, w którym zastosowano (najszerzej rozumiane) kluczowe dla funkcjonowania naszego systemu interfejsy bez dostarczenia ich pełnej i weryfikowalnej dokumentacji wiąże się z bardzo dużym ryzykiem dla jednostki eksploatującej system i nie powinno być akceptowane. Jeśli komunikacja przez dany interfejs ma być dodatkowo zabezpieczana (kontrola integralności, szyfrowanie...) należy po prostu zastosować sprawdzone i powszechnie dostępne algorytmy (np. AES i SHA) i mechanizmy (IPSec, SSL) zabezpieczające, a nie stosować bardzo niebezpiecznej praktyki zabezpieczania przez zaciemnianie (Security by Obscurity ). Dla poprawnego funkcjonowania całości systemu nie jest istotne, jakie konkretnie oprogramowanie zostanie wybrane, lecz sprawne działanie interfejsów pomiędzy modułami oraz oczywiście interfejs użytkownika. Dobór interfejsów jest więc znacznie ważniejszą rzeczą niż wybór np. systemu operacyjnego. System operacyjny nie jest zazwyczaj bezpośrednio wykorzystywany przez użytkownika służy on jedynie do realizacji funkcji systemowych wymaganych do działania przez pozostałe moduły oraz do ich uruchamiania. Jest on więc praktycznie przeźroczysty dla użytkownika i jego wybór wynika jedynie z wymagań pozostałych modułów. Pozostałe moduły muszą być oczywiście dostosowane do współpracy z określonym systemem operacyjnym. Obecnie dostępne są moduły, które mogą pracować w środowisku różnych systemów operacyjnych. Wybór takich modułów jest zawsze korzystny, ponieważ uwalnia on użytkownika od uzależnienia od dostawcy jednego rodzaju syste- Oprócz kluczowych interfejsów w systemie będzie zapewne realizowanych wiele innych łączy, 15

16 ZAMÓWIENIA PUBLICZNE NA OPROGRAMOWANIE ASPEKTY TECHNOLOGICZNE I FINANSOWE których znaczenie jest mniej ważne dla funkcjonowania całego rozwiązania. Wymagania dla tych interfejsów mogą być zdefiniowane indywidualnie, zależnie od ich znaczenia. Jest to podstawowy błąd, ponieważ: dostawca nie będzie posiadał odpowiedniej wiedzy o procesach organizacji a tym samym o jej rzeczywistych potrzebach, i w konsekwencji zaoferuje rozwiązania najkorzystniejsze ze swego punktu widzenia; 3.4 / Etap czwarty wybór standardów i rozwiązania zadania pierwszych trzech etapów można powierzyć zewnętrznej firmie (np. konsultingowej w zakresie IT), lecz powinna ona złożyć jasną deklarację, że nie jest zainteresowana bezpośrednio ani pośrednio w realizacji danego przedsięwzięcia. Dopiero ten etap jest związany z analizą rynku, wyborem potencjalnych rozwiązań i ich dostawców. W poprzednich etapach zgromadziliśmy już pełny zestaw niezbędnych danych do przygotowania zapytania ofertowego. W zapytaniu nie powinniśmy narzucać potencjalnym dostawcom konkretnych rozwiązań sprzętowych i programowych. Możliwość taka jest w przypadku przetargów publicznych zresztą znacznie ograniczona a może skutkować dla zamawiającego odrzuceniem niejako a priori bardzo korzystnego nowego rozwiązania. 3.5 / Etap piąty sprawdzenie spełnienia założeń i testy systemu Jeśli założenia sporządzono w sposób precyzyjny, techniczny odbiór systemu jest bardzo prosty. Umowa dostawy powinna oczywiście przewidywać działania na wypadek, gdyby dostarczony system nie spełnił wymagań (powinny być one bezwarunkowo w całości spisane i przyjęte wraz z zakresem czynności odbiorczych przez obie strony). Wiele jednostek prowadzących przetargi publiczne z zakresu IT niejako programowo rezygnuje z najkorzystniejszego mechanizmu relacji zamawiający dostawca: relacji symbiotycznej. Jest to zapewne związane z obawami przed oskarżeniem (lub podejrzeniami) o korupcję, które są całkowicie bezpodstawne, bo na etapie tworzenia koncepcji rozwiązania takie symbiotyczne kontakty (z zachowaniem ich jawności) znacznie ułatwiają wybór najkorzystniejszego rozwiązania i poznanie faktycznych kompetencji dostawców, ich ew. podwykonawców itp. Kontakty te należy oczywiście prowadzić na etapie ogólnego zapytania ofertowego a nie po ogłoszeniu wiążącej specyfikacji SIWZ. W przypadkach bardziej złożonych systemów można przewidzieć wykonanie testów na instalacji pilotażowej. Bardzo korzystne jest ujęcie w umowie wymogu przeprowadzenia szkoleń jeszcze przed dostawą całego systemu. Dzięki temu nie tylko zdecydowanie skraca się czas osiągnięcia przez instalację pełnej wydajności, lecz również bardzo szybko wyjdą na jaw ewentualne braki systemu lub konieczność poszerzenia zakresu wymagań. W przypadku, gdy szkolenia są prowadzone odpowiednio wcześnie, możliwe jest dokonanie korekt w systemie jeszcze przed jego dostawą. W wielu przypadkach w Polsce mamy do czynienia jedynie z realizacją tego etapu z pominięciem poprzednich. Zamawiający często uważają poprzednie trzy etapy za mało istotne i kwitują je stwierdzeniami to powinien wykonać dostawca. 16

17 4 / Porównanie ról podmiotów uczestniczących w procesie projektowania i wdrażania systemu J ak już powyżej zaznaczono, system przeznaczony do pracy profesjonalnej powinien być ściśle związany z procesami realizowanymi przez organizację; w rozważanym przypadku przez jednostkę administracyjną. 4.1 / Użytkownik Ponieważ zgodnie z zamówieniem niniejsza analiza ma dotyczyć stanowiska komputerowego urzędnika niższego szczebla, którego zadania i kompetencje są zazwyczaj dokładnie zdefiniowane, czynna rola użytkownika w procesie projektowania i wdrażania systemu powinna być ograniczona. Użytkownik powinien otrzymać stanowisko pracy wyposażone w odpowiednie funkcje sprzętowe oraz programowe umożliwiające realizację powierzonych mu obowiązków nie powinien mieć natomiast wpływu na wybór rozwiązania, wyposażenia sprzętowego swojego stanowiska, rodzaju zainstalowanego oprogramowania itp. Ma to szczególne znaczenie dla niezawodności i bezpieczeństwa eksploatacji systemu komputerowego. Użytkownik nie powinien w szczególności: instalować jakiegokolwiek sprzętu (z urządzeniami peryferyjnymi włącznie) oraz oprogramowania lub zmieniać konfiguracji swojego stanowiska pracy, 17

18 ZAMÓWIENIA PUBLICZNE NA OPROGRAMOWANIE ASPEKTY TECHNOLOGICZNE I FINANSOWE korzystać bez kontroli z jakichkolwiek przenośnych masowych nośników danych (zarówno tylko do odczytu, jak i do zapisu i odczytu), decydować o wykorzystywaniu (lub nie) mechanizmów bezpieczeństwa systemu. Użytkownik powinien zostać natomiast przeszkolony w zakresie wykorzystywania powierzonego mu stanowiska komputerowego oraz powinien mieć możliwość skorzystania w razie potrzeby z kompetentnej pomocy technicznej (tak zwanego Help Desku). 4.2 / Dział IT Rola działu IT (informatyka) jest w procesie wdrażania, eksploatacji i modernizacji systemu nie do przecenienia. Ze względu na usytuowanie wewnątrz organizacji pracownicy tego działu mogą dokładnie poznać procesy przez nią realizowane oraz, co za tym idzie, określić wymagania zarówno dla całego systemu, jak i dla poszczególnych stanowisk pracy. Zadaniem działu IT jest przetłumaczenie potrzeb na język techniczny, sprawdzenie adekwatności dostępnych rozwiązań i możliwości ich dostosowania do wymagań jednostki. Dział IT powinien zrealizować wszystkie wymienione w poprzedni rozdziale etapy akwizycji rozwiązania. O ile pierwszy etap (określenie potrzeb) powinien być zrealizowany w ścisłej współpracy z właścicielem systemu i wymaga jedynie informacji dostępnych wewnątrz organizacji, o tyle kolejne etapy są już związane z koniecznością sprawdzenia dostępności różnych rozwiązań. Jest to niezbędne już na etapie definiowania modułów, ponieważ wybór systemu operacyjnego silnie determinuje sposób realizacji pozostałych funkcji wymaganych dla stanowiska pracy. Podział na moduły jest bardzo istotny, jeśli chcemy przygotować rozwiązanie na ewentualne przyszłe zmiany. Do zadań Działu IT należy również określenie kluczowych interfejsów oraz opracowanie systemu zarządzania nimi. Dotyczy to zarówno interfejsów wewnętrznych, np. współpraca programu obsługi poczty elektronicznej z oprogramowaniem biurowym, integracja mechanizmów bezpieczeństwa (podpis cyfrowy, ochrona kryptograficzna dokumentów) z oprogramowaniem użytkowym, jak i zewnętrznych, z interfejsem użytkownika włącznie. W wyniku tych działań Dział IT powinien przedstawić Właścicielowi Systemu zestawienie dostępnych rozwiązań (zarówno opartych o oprogramowanie licencjonowane komercyjnie, jak i Wolne i Otwarte Oprogramowanie) w celu dokonania ostatecznego wyboru. Dział IT powinien również odpowiadać że przeprowadzenie testów rozwiązania. 4.3 / Właściciel systemu Przez właściciela systemu będziemy tu rozumieć osobę kierująca jednostką administracyjną i odpowiedzialną za jej budżet. Podejmuje ona finalną decyzję o wyborze rozwiązania na podstawie materiałów przygotowanych przez dział IT powinna więc otrzymać z tego działu komplet informacji umożliwiających, podjęcie odpowiedniej decyzji. Poważnym błędem jest stosowanie przy wyborze rozwiązania jedynie kryterium kosztu zakupu rozwiązania. Niewątpliwie automatyzuje to proces decyzyjny, utrudnia składanie ew. protestów itp. jednakże jest związane z bardzo dużym ryzykiem, że dostarczone rozwiązanie będzie formalnie zgodne z ogłoszonymi wymaganiami, jednakże nie będzie w rzeczywistości odpowiadać faktycznym (obecnym lub przyszłym) potrzebom jednostki i w efekcie narazi właściciela systemu na dodatkowe koszty lub wręcz utrudni (albo nawet uniemożliwi) wdrożenie zakupionego systemu z powodu braku środków w budżecie na dokonanie niezbędnych uzupełnień i poprawek. Chęć utrzymania jedynie kryterium cenowego prowadzi także do opracowywania i publikowania bardzo szczegółowych Specyfikacji Istotnych Warunków Zamówienia (SIWZ), wymieniania w niej konkretnych produktów lub producentów, co jest niezgodne z naczelną zasadą zachowania 18

19 PORÓWNANIE RÓL PODMIOTÓW UCZESTNICZĄCYCH W PROCESIE PROJEKTOWANIA I WDRAŻANIA SYSTEMU konkurencyjności w procedurze przetargu publicznego. Praktyka wykazuje, że nawet bardzo szczegółowo przygotowany techniczny SIWZ może zawierać luki, które mogą zostać wykorzystane przez niezbyt uczciwych oferentów, zaś jednoznaczne wskazanie produktu jest po prostu niezgodne z prawem. Godnym polecenia rozwiązaniem jest natomiast opracowanie i opublikowanie arkusza testów oraz przeprowadzenie wstępnych testów oferowanych rozwiązań. Testy takie powinny być przeprowadzone w sposób otwarty w obecności przedstawiciela oferenta, który powinien dowieść, że właściwie skonfigurowane rozwiązanie (oprogramowanie) spełnia wymagania opublikowane w arkuszu testów. 4.4 / Szkolenia i organizacja pomocy dla użytkowników Skomputeryzowane stanowisko pracy powinno przede wszystkim ułatwiać pracę jego użytkownikowi i służyć osiąganiu przez niego założonej wydajności. Dotyczy to również (a może nawet szczególnie) urzędników administracji. Często podnoszony jest argument, że popularne oprogramowanie licencjonowane komercyjnie dostępne z półki jest ogólnie znane i żadne szkolenie nie jest w tym przypadku wymagane. Zapomina się jednak, że profesjonalna działalność wcale nie wymaga głębokiej znajomości systemu operacyjnego lub programów użytkowych, takich jak procesor tekstu czy arkusz kalkulacyjny lecz na sprawnej realizacji procedur związanych z procesami biznesowymi realizowanymi przez organizację. Procedury te mogą oczywiście wykorzystywać odpowiednie narzędzia programowe jak choćby popularne makroinstrukcje arkuszy kalkulacyjnych, lecz zazwyczaj użytkownik nie ma ani potrzeby, ani możliwości modyfikowania tych procedur. Urzędnik niższego szczebla korzystać będzie raczej z przygotowanych wzorów pism urzędowych, a nie będzie takich wzorów tworzyć. Szkolenie użytkowników powinno więc być nieodłącznym składnikiem wdrażania lub modernizacji systemu informatycznego. Tematyka i zakres szkoleń powinny być ściśle dostosowane do zadań stawianych użytkownikowi (urzędnikowi). Szeroka wiedza ogólna (np. w zakresie obsługi systemu operacyjnego czy też procesora tekstu lub arkusza kalkulacyjnego) może ułatwić przeprowadzenie szkoleń specjalistycznych, jednakże nie jest absolutnie niezbędna, a niekiedy może być wręcz szkodliwa. Organizacja efektywnego systemu pomocy dla użytkowników jest także niezbędna. Należy przyjąć zasadę, że użytkownicy nie są w żadnym przypadku uprawnieni do serwisowania komputerowych stanowisk pracy zarówno własnych, jak i cudzych. Specjalistyczne firmy zajmujące się organizacją pracy analizowały dość szczegółowo zachowania użytkowników w przypadku wystąpienia nieprawidłowości w działaniu ich komputerowego stanowiska pracy. Z tych analiz wynika, że większość użytkowników podejmuje próby usunięcia awarii we własnym zakresie, a w przypadku, gdy to się nie udaje, sięga zazwyczaj po pomoc kolegów. Dopiero po tym, jak próby naprawy stanowiska nie przynoszą przez dłuższy czas pożądanego skutku, kontaktują się z pracownikami Help Desku lub innymi osobami, w których zakresie obowiązków leży utrzymanie systemu komputerowego w ruchu. Rezultaty takiego postępowania są bardzo niekorzystne dla instytucji eksploatującej system: wydłużają znacząco czas od wystąpienia awarii do skutecznego jej usunięcia; w czasie, w którym użytkownik (urzędnik) usiłuje naprawić swoje stanowisko pracy nie realizuje on działań służbowych powstają więc opóźnienia, za które obwiniany jest komputer ; pomoc świadczona (często spontanicznie) użytkownikowi przez innych pracowników (urzędników) wyklucza ich także z realizacji obowiązków służbowych (nawet, jeśli ich stanowiska pracy są całkowicie sprawne); próby naprawy komputerowego stanowiska pracy przez osoby bez odpowiedniego 19

20 ZAMÓWIENIA PUBLICZNE NA OPROGRAMOWANIE ASPEKTY TECHNOLOGICZNE I FINANSOWE przygotowania oraz doświadczenia kończą się często powiększeniem uszkodzeń; nie można wykluczyć, że obserwowane zakłócenia w pracy systemu są spowodowane prowadzeniem ataku sieciowego na komputer użytkownika, czego przypadkowe osoby nie są łatwo w stanie stwierdzić. Aby uniknąć powyższych niepożądanych zjawisk konieczne jest zorganizowanie sprawnego kanału pomocy dla użytkowników oraz zdecydowane wymaganie niezwłocznego sygnalizowania przez ten kanał wszelkich usterek oraz nieprawidłowości, które wystąpiły w czasie pracy z systemem. Dzięki temu nie tylko będzie możliwe sprawne usuwanie ewentualnych awarii, ale także odpowiednie usprawnianie pracy systemu, ponieważ informacje o występujących problemach będą gromadzone i w razie potrzeby udostępniane specjalistom. W praktyce bardzo często spotykamy się z bardzo niskim szacowaniem kosztów szkoleń i wsparcia technicznego dla oprogramowania licencjonowanego komercyjnie i dostępnego z półki. Motywowane jest to powszechną znajomością takiego oprogramowania. Argument ten jest co najmniej wątpliwy, bo jak wspomniano powyżej użytkownik nie powinien być w żadnym przepadu serwisantem własnego komputera. Sytuacja taka jest typowa w przypadku komputerów domowych, jednak absolutnie niedopuszczalna w zastosowaniach profesjonalnych! 4.5 / Eksploatacja systemu Wydatki na system nie kończą się wraz z jego zakupem występują również podczas eksploatacji. Zmieniające się otoczenie zewnętrzne (np. zmiany w przepisach i pragmatyce służbowej), uzupełnienia i poprawki oprogramowania, ochrona antywirusowa i przed atakami sieciowymi itp. powodują dodatkowe koszty związane z pracą systemu. Niestety, w wielu przypadkach te koszty nie są uwzględniane zarówno przez Zamawiających, jak i przez Dostawców. Jedynie dostawcy profesjonalnego oprogramowania wyraźnie określają koszty prowadzenia jego obsługi, proponując zawieranie tak zwanych kontraktów wsparcia technicznego (Maintenance Contract). Koszt takiego kontraktu na rok wynosi przeciętnie od 20 do 30% ceny praw do korzystania z oprogramowania (Right to Use). Podnoszony często argument, że wsparcie dla typowego oprogramowania może być realizowane we własnym zakresie nie jest do końca prawdziwy, ponieważ w takim przypadku użytkownik nie jest indywidualnie informowany na przykład o konieczności zainstalowania określonej poprawki (łatki) lub o innych istotnych problemach, które występują podczas eksploatacji oprogramowania. Zmuszony jest więc śledzić na bieżąco informacje udostępniane przez producenta (np. o dostępności uzupełnienia typu Service Pack, problemach z jego instalacją itp.). Taka organizacja wsparcia eksploatacyjnego również generuje określone koszty a w dodatku nie zapewnia użytkownikowi bezpośredniego kontaktu z producentem oprogramowania, który dysponuje odpowiednią bazą wiedzy, a więc taką bazę musi sobie użytkownik zorganizować we własnym zakresie. Te obowiązki (i związaną z nimi odpowiedzialność) trzeba przecież komuś powierzyć. Uzyskanie realnego wsparcia technicznego podczas eksploatacji oprogramowania stanowi dla zamawiających spory problem. Występują tu duże różnice w zależności od rodzaju, a raczej od modelu tworzenia i dystrybucji oprogramowania. W przypadku typowego oprogramowania dostępnego w ogólnoświatowej dystrybucji z półki, kontakt użytkownika z producentem jest z konieczności bardzo ograniczony. Producenci oczywiście zdają sobie z tego sprawę i tworzą sieci Autoryzowanych Ośrodków Wsparcia Technicznego (Support Centers), które świadczą odpowiednie usługi dodatkowe komercyjnie. Jeśli oprogramowanie jest dystrybuowane w mniejszych ilościach, producent na ogół oferuje dodatkowe programy wsparcia technicznego we własnym zakresie niekiedy nawet obligatoryjnie. Taki model świadczenia wsparcia technicznego (bezpośrednio przez producenta) jest regułą w przypadku oprogramowania tworzonego na zamówienie. 20

JAK PRAWIDŁOWO ZAMAWIAĆ SYSTEM INFORMATYCZNY DLA SZPITALA PERSPEKTYWA OBSERWATORA

JAK PRAWIDŁOWO ZAMAWIAĆ SYSTEM INFORMATYCZNY DLA SZPITALA PERSPEKTYWA OBSERWATORA Fundacja Wolnego i Otwartego Oprogramowania (FWiOO) JAK PRAWIDŁOWO ZAMAWIAĆ SYSTEM INFORMATYCZNY DLA SZPITALA PERSPEKTYWA OBSERWATORA AGATA MICHAŁEK-BUDZICZ ul. Staszica 25/8, 60-524 Poznań, tel.: +48.

Bardziej szczegółowo

Instrukcja dla Oferenta. Strona 1 z 9

Instrukcja dla Oferenta. Strona 1 z 9 Definicje Instrukcja dla Oferenta System B2B cały system informatyczny (zarówno software autorski, jak i licencje serwerowe, stanowiskowe, bazodanowe, etc.) obejmujący całą funkcjonalność wskazaną we wszystkich

Bardziej szczegółowo

Instrukcja dla Oferenta

Instrukcja dla Oferenta Instrukcja dla Oferenta Definicje System B2B cały system informatyczny (zarówno software autorski, jak i licencje serwerowe, stanowiskowe, bazodanow Instrukcja. Należy wypełnić WSZYSTKIE POLA oznaczone

Bardziej szczegółowo

WARUNKI ŚWIADCZENIA SERWISU GWARANCYJNEGO WSPARCIA UŻYTKOWNIKÓW HELP DESK ORAZ ASYSTY TECHNICZNEJ

WARUNKI ŚWIADCZENIA SERWISU GWARANCYJNEGO WSPARCIA UŻYTKOWNIKÓW HELP DESK ORAZ ASYSTY TECHNICZNEJ Załącznik nr 6 do SIWZ WARUNKI ŚWIADCZENIA SERWISU GWARANCYJNEGO WSPARCIA UŻYTKOWNIKÓW HELP DESK ORAZ ASYSTY TECHNICZNEJ I. Warunki ogólne 1. Wykonawca zobowiązany jest do udzielenia Zamawiającemu gwarancji

Bardziej szczegółowo

WARUNKI ŚWIADCZENIA SERWISU GWARANCYJNEGO ORAZ ASYSTY TECHNICZNEJ

WARUNKI ŚWIADCZENIA SERWISU GWARANCYJNEGO ORAZ ASYSTY TECHNICZNEJ Załącznik nr 6 do SIWZ WARUNKI ŚWIADCZENIA SERWISU GWARANCYJNEGO ORAZ ASYSTY TECHNICZNEJ I. Warunki ogólne 1. Wykonawca zobowiązany jest do udzielenia Zamawiającemu gwarancji na przedmiot Umowy i zobowiązuje

Bardziej szczegółowo

Dąbrowa Górnicza, dnia 03.10.2014 r. ZAPYTANIE OFERTOWE. Zamawiający:

Dąbrowa Górnicza, dnia 03.10.2014 r. ZAPYTANIE OFERTOWE. Zamawiający: Dąbrowa Górnicza, dnia 03.10.2014 r. ZAPYTANIE OFERTOWE Zamawiający: ANETA GRYLA FIRMA HANDLOWO USŁUGOWA "CASMIR" 41-303 Dąbrowa Górnicza Ulica Bukowa 23 NIP : NIP 6291893246 1. Podstawa formalna zapytania

Bardziej szczegółowo

Vendor Lock-In - analiza problemu

Vendor Lock-In - analiza problemu Tomasz Barbaszewski - FWiOO Warszawa, wrzesień 2010 Vendor Lock-In - analiza problemu Co to jest i jak powstaje Vendor Lock-In? Zagrożenia związane z Vendor Lock-In dla użytkownika Vendor Lock-In w administracji

Bardziej szczegółowo

Będzin, dnia 01.07.2014 r. ZAPYTANIE OFERTOWE. Zamawiający: GRYLA JAROSŁAW Firma Handlowo-Usługowa "MATAR" Bedzin Siemońska 11 Kod pocztowy 42-500

Będzin, dnia 01.07.2014 r. ZAPYTANIE OFERTOWE. Zamawiający: GRYLA JAROSŁAW Firma Handlowo-Usługowa MATAR Bedzin Siemońska 11 Kod pocztowy 42-500 Będzin, dnia 01.07.2014 r. ZAPYTANIE OFERTOWE Zamawiający: GRYLA JAROSŁAW Firma Handlowo-Usługowa "MATAR" Bedzin Siemońska 11 Kod pocztowy 42-500 1. Podstawa formalna zapytania ofertowego Niniejsze Zapytaniem

Bardziej szczegółowo

Wyższa Szkoła Bankowa w Toruniu ul. Młodzieżowa 31a 87-100 Toruń www.wsb.pl/torun Toruń, dnia 17.04.2014r. ZAPYTANIE OFERTOWE nr 1/NOR/0119/2014

Wyższa Szkoła Bankowa w Toruniu ul. Młodzieżowa 31a 87-100 Toruń www.wsb.pl/torun Toruń, dnia 17.04.2014r. ZAPYTANIE OFERTOWE nr 1/NOR/0119/2014 Wyższa Szkoła Bankowa w Toruniu ul. Młodzieżowa 31a 87-100 Toruń www.wsb.pl/torun Toruń, dnia 17.04.2014r. ZAPYTANIE OFERTOWE nr 1/NOR/0119/2014 Zamawiający: Wyższa Szkoła Bankowa w Toruniu z siedzibą

Bardziej szczegółowo

STRATEGIA zamówień publicznych w przedsięwzięciach informatycznych MF

STRATEGIA zamówień publicznych w przedsięwzięciach informatycznych MF Warszawa, 10 grudnia 2014 r. STRATEGIA zamówień publicznych Robert Kietliński Zastępca Dyrektora Departament Informatyzacji Usług Publicznych Z czym mamy do czynienia? Skala informatycznych zamówień w

Bardziej szczegółowo

Strona znajduje się w archiwum.

Strona znajduje się w archiwum. Strona znajduje się w archiwum. Zapytanie odnośnie SIWZ w postępowaniu na dostawę oprogramowania, sprzętu i wdrożenie dedykowanego systemu backupowego dla serwerów Unix oraz Windows w MSP Warszawa, dnia

Bardziej szczegółowo

Krzysztof Wawrzyniak Quo vadis BS? Ożarów Mazowiecki, styczeń 2014

Krzysztof Wawrzyniak Quo vadis BS? Ożarów Mazowiecki, styczeń 2014 1 QUO VADIS.. BS? Rekomendacja D dlaczego? Mocne fundamenty to dynamiczny rozwój. Rzeczywistość wdrożeniowa. 2 Determinanty sukcesu w biznesie. strategia, zasoby (ludzie, kompetencje, procedury, technologia)

Bardziej szczegółowo

nas sprawdził czas INFORMATYKA ELEKTRONIKA AUTOMATYKA

nas sprawdził czas INFORMATYKA ELEKTRONIKA AUTOMATYKA nas sprawdził czas INFORMATYKA ELEKTRONIKA AUTOMATYKA Wstęp Biznes Dane Aplikacje Infrastruktura Wirtualizacja Systemy operacyjne Pytania Funkcjonalności środowiska IT: Czy obecnie moje środowisko IT ma

Bardziej szczegółowo

ZAPISY SIWZ ZABEZPIECZAJĄCE ZAMAWIAJĄCEGO TYLKO PRZED CZYM?

ZAPISY SIWZ ZABEZPIECZAJĄCE ZAMAWIAJĄCEGO TYLKO PRZED CZYM? ZAPISY SIWZ ZABEZPIECZAJĄCE ZAMAWIAJĄCEGO TYLKO PRZED CZYM? Andrzej Dopierała Od 1998 roku prezes polskich oddziałów korporacji IT Ta historia zaczyna się od tego, gdy przedsiębiorstwo/instytucja ( Zamawiający

Bardziej szczegółowo

Wybór ZSI. Zakup standardowego systemu. System pisany na zamówienie

Wybór ZSI. Zakup standardowego systemu. System pisany na zamówienie Wybór ZSI Zakup standardowego systemu System pisany na zamówienie Zalety: Standardowy ZSI wbudowane najlepsze praktyki biznesowe możliwość testowania przed zakupem mniej kosztowny utrzymywany przez asystę

Bardziej szczegółowo

GoBiz System platforma współpracy marektingowej

GoBiz System platforma współpracy marektingowej GoBiz System platforma współpracy marektingowej Spis treści 1. Opis przedmiotu zamówienia... 1 1.1. Definicje... 1 2. Główny cel platformy... 2 3. Główni odbiorcy systemu... 2 4. Przedmiot zamówienia...

Bardziej szczegółowo

Personalizacja Plan-de-CAMpagne dostosowywanie programu do indywidualnych potrzeb firm, działów oraz osób

Personalizacja Plan-de-CAMpagne dostosowywanie programu do indywidualnych potrzeb firm, działów oraz osób Personalizacja Plan-de-CAMpagne dostosowywanie programu do indywidualnych potrzeb firm, działów oraz osób Wdrożenie systemu planowania zasobów przedsiębiorstwa pomimo wielu korzyści często też wiąże się

Bardziej szczegółowo

Specyfikacja techniczna GoBiz Virtual Office - systemu dostępu do zasobów wirtualnego biura przez Internet

Specyfikacja techniczna GoBiz Virtual Office - systemu dostępu do zasobów wirtualnego biura przez Internet Specyfikacja techniczna GoBiz Virtual Office - systemu dostępu do zasobów wirtualnego biura przez Internet Spis treści 1. Opis przedmiotu zamówienia... 1 1.1. Definicje... 1 2. Główny cel systemu... 2

Bardziej szczegółowo

Informatyzacja administracji zaczyna się od przetargów

Informatyzacja administracji zaczyna się od przetargów Projekt "Prawidłowe i transparentne przetargi publiczne na narzędzia informatyczne" jest realizowany przy wsparciu udzielonym przez Islandię, Liechtenstei i Norwegię ze środków Mechanizmu Finansowego Europejskiego

Bardziej szczegółowo

ZAPYTANIE OFERTOWE. Zamawiający. Przedmiot zapytania ofertowego. Wrocław, dnia 23.03.2015 r.

ZAPYTANIE OFERTOWE. Zamawiający. Przedmiot zapytania ofertowego. Wrocław, dnia 23.03.2015 r. ZAPYTANIE OFERTOWE Wrocław, dnia 23.03.2015 r. W związku z realizacją przez Nova Telecom spółka z ograniczoną odpowiedzialnością, projektu pn.: Wdrożenie zintegrowanego systemu klasy B2B, umożliwiającego

Bardziej szczegółowo

Dlaczego outsourcing informatyczny? Jakie korzyści zapewnia outsourcing informatyczny? Pełny czy częściowy?

Dlaczego outsourcing informatyczny? Jakie korzyści zapewnia outsourcing informatyczny? Pełny czy częściowy? Dlaczego outsourcing informatyczny? Przeciętny informatyk firmowy musi skupić w sobie umiejętności i specjalizacje z wielu dziedzin informatyki. Równocześnie musi być administratorem, specjalistą od sieci

Bardziej szczegółowo

Istotne postanowienia umowy

Istotne postanowienia umowy Załącznik nr 7 Istotne postanowienia umowy Zgodnie z wynikiem postępowania o udzielenie zamówienia publicznego w trybie przetargu nieograniczonego o wartości nieprzekraczającej kwoty określonej w przepisach

Bardziej szczegółowo

Zapytanie ofertowe. Dotyczące budowy serwisu do automatycznego świadczenia e-kursów

Zapytanie ofertowe. Dotyczące budowy serwisu do automatycznego świadczenia e-kursów Robo NET Sp. z o.o. Gdańsk, dnia 30 listopada 2009 r. ul. Trzy Lipy 3 80-172 Gdańsk NIP:9571023335 REGON: 220787917 KRS: 0000333062 Zapytanie ofertowe Dotyczące budowy serwisu do automatycznego świadczenia

Bardziej szczegółowo

ZAMAWIAJĄCY. CONCEPTO Sp. z o.o.

ZAMAWIAJĄCY. CONCEPTO Sp. z o.o. Grodzisk Wielkopolski, dnia 11.02.2013r. ZAMAWIAJĄCY z siedzibą w Grodzisku Wielkopolskim (62-065) przy ul. Szerokiej 10 realizując zamówienie w ramach projektu dofinansowanego z Programu Operacyjnego

Bardziej szczegółowo

Specyfikacje. Tabela 1. Cechy usługi. Sposób realizacji usługi. Dostęp do zasobów technicznych. Analiza i rozwiązywanie

Specyfikacje. Tabela 1. Cechy usługi. Sposób realizacji usługi. Dostęp do zasobów technicznych. Analiza i rozwiązywanie Arkusz danych Usługi wsparcia dotyczące Usługi Care Pack i usługi kontraktowe, część pakietu HP Care Korzyści z usługi Dostęp do zasobów technicznych HP w celu rozwiązywania problemów Potencjalne obniżenie

Bardziej szczegółowo

Dobór systemów klasy ERP

Dobór systemów klasy ERP klasy ERP - z uwzględnieniem wymagań normy ISO 9001 Prezentacja w Klubie Menedżera Jakości, 19 marzec 2008 Zagadnienia ogólne związane z doborem systemu klasy ERP Podstawowe podziały klasyfikujące systemy

Bardziej szczegółowo

WDROŻENIE ZINTEGROWANEGO SYSTEMU INFORMATYCZNEGO ZARZĄDZANIA GMINĄ - FRONT I BACK OFFICE W TYM SZKOLENIE UŻYTKOWNIKÓW

WDROŻENIE ZINTEGROWANEGO SYSTEMU INFORMATYCZNEGO ZARZĄDZANIA GMINĄ - FRONT I BACK OFFICE W TYM SZKOLENIE UŻYTKOWNIKÓW Urząd Gminy Rajcza ul. Górska 1 34-370 Rajcza Odpowiedź na zapytania dotyczące treści SIWZ! Działając na podstawie art. 38 ust.1 i 2 ustawy z dnia 29 stycznia 2004 roku Prawo zamówień publicznych ( Dz.

Bardziej szczegółowo

ZESPÓŁ OPIEKI ZDROWOTNEJ. w Świętochłowicach sp. z o.o.

ZESPÓŁ OPIEKI ZDROWOTNEJ. w Świętochłowicach sp. z o.o. ZESPÓŁ OPIEKI ZDROWOTNEJ w Świętochłowicach sp. z o.o. ul. Chorzowska 38, 41-605 Świętochłowice tel. 032/245 50 41 do 5, tel/fax: 032/245 34 40 Sąd Rejonowy Katowice-Wschód Wydział VIII Gospodarczy KRS

Bardziej szczegółowo

1. Zakup stacji roboczej przenośnej ze stacją dokującą, monitorem i klawiaturą - 1 szt.

1. Zakup stacji roboczej przenośnej ze stacją dokującą, monitorem i klawiaturą - 1 szt. Załącznik nr 3 SPECYFIKACJA ZAMÓWIENIA Dotyczy wyłonienia dostawcy w ramach projektu Wdrożenie innowacyjnego systemu klasy B2B dla integracji i automatyzacji procesów biznesowych w zakresie następujących

Bardziej szczegółowo

produkować, promować i sprzedawać produkty, zarządzać i rozliczać przedsięwzięcia, oraz komunikować się wewnątrz organizacji.

produkować, promować i sprzedawać produkty, zarządzać i rozliczać przedsięwzięcia, oraz komunikować się wewnątrz organizacji. Wspieramy w doborze, wdrażaniu oraz utrzymaniu systemów informatycznych. Od wielu lat dostarczamy technologie Microsoft wspierające funkcjonowanie działów IT, jak i całych przedsiębiorstw. Nasze oprogramowanie

Bardziej szczegółowo

JTW SP. Z OO. Zapytanie ofertowe. Zewnętrzny audyt jakościowy projektu technicznego dedykowanego systemu B2B Platforma Integracji Serwisowej

JTW SP. Z OO. Zapytanie ofertowe. Zewnętrzny audyt jakościowy projektu technicznego dedykowanego systemu B2B Platforma Integracji Serwisowej JTW SP. Z OO Zapytanie ofertowe Zewnętrzny audyt jakościowy projektu technicznego dedykowanego systemu B2B Platforma Integracji Serwisowej Strona 1 z 8 Spis treści 1. Klauzula poufności... 3 2. Wskazówki

Bardziej szczegółowo

Projekt współfinansowany ze środków Europejskiego Funduszu Rozwoju. Regionalnego w ramach Programu Operacyjnego Innowacyjna Gospodarka

Projekt współfinansowany ze środków Europejskiego Funduszu Rozwoju. Regionalnego w ramach Programu Operacyjnego Innowacyjna Gospodarka Warszawa, dnia 22.05.2013 r. Zapytanie ofertowe na: 1) Zakup wartości niematerialnej i prawnej w postaci nowoczesnego systemu B2B 2) Zakup nowych środków trwałych w postaci 3 zestawów komputerowych (komputer

Bardziej szczegółowo

ZAPYTANIE OFERTOWE: Licencje na moduły systemu B2B oraz usługi wdrożeniowe.

ZAPYTANIE OFERTOWE: Licencje na moduły systemu B2B oraz usługi wdrożeniowe. Kraków, 06.08.2012 r. ZAPYTANIE OFERTOWE: Licencje na moduły systemu B2B oraz usługi wdrożeniowe. Zamawiający: Omni Rafał Olszowski, ul. Krowoderska 53/23, 31-142 Kraków, Tel/Fax: (12) 294 40 33, e-mail:

Bardziej szczegółowo

7. zainstalowane oprogramowanie. 8. 9. 10. zarządzane stacje robocze

7. zainstalowane oprogramowanie. 8. 9. 10. zarządzane stacje robocze Specyfikacja oprogramowania do Opis zarządzania przedmiotu i monitorowania zamówienia środowiska Załącznik nr informatycznego 1 do specyfikacji Lp. 1. a) 1. Oprogramowanie oprogramowania i do systemów

Bardziej szczegółowo

Modele sprzedaży i dystrybucji oprogramowania Teoria a praktyka SaaS vs. BOX. Bartosz Marciniak. Actuality Sp. z o.o.

Modele sprzedaży i dystrybucji oprogramowania Teoria a praktyka SaaS vs. BOX. Bartosz Marciniak. Actuality Sp. z o.o. Modele sprzedaży i dystrybucji oprogramowania Teoria a praktyka SaaS vs. BOX Bartosz Marciniak Actuality Sp. z o.o. Prezes Zarządu Społeczeństwo informacyjne społeczeństwo, które znalazło zastosowanie

Bardziej szczegółowo

Opis administracji terminali ABA-X3 v.1.5.0

Opis administracji terminali ABA-X3 v.1.5.0 Opis administracji terminali v.1.5.0 System terminalowy jest scentralizowany oznacza to, że Użytkownik stacji roboczej (terminala) jest całkowicie uzależniony od konfiguracji wprowadzonej przez Administratora.

Bardziej szczegółowo

1. Wyjaśnienia/Zmiana treści specyfikacji istotnych warunków zamówienia/przedłużenie terminu składania ofert

1. Wyjaśnienia/Zmiana treści specyfikacji istotnych warunków zamówienia/przedłużenie terminu składania ofert Sygnatura postępowania: BZP/31/DRI/2015 BGK BANK GOSPODARSTWA KRAJOWEGO Warszawa, 8 lipiec 2015 r. Zamawiający: Bank Gospodarstwa Krajowego Al. Jerozolimskie 7 00-955 Warszawa Biuro Zamówień Publicznych

Bardziej szczegółowo

ZAPYTANIE OFERTOWE PRZEDMIOT ZAMÓWIENIA. W ramach projektu planowane jest przeprowadzenie 2 etapów w okresie od 1.02.2014 r. do 30.11.2014 roku.

ZAPYTANIE OFERTOWE PRZEDMIOT ZAMÓWIENIA. W ramach projektu planowane jest przeprowadzenie 2 etapów w okresie od 1.02.2014 r. do 30.11.2014 roku. Od podpisania umowy do 31.06.2014 DOTACJE NA INNOWACJE. Inwestujemy w waszą przyszłość. Rzeszów, 27.01.2014 r. ZAPYTANIE OFERTOWE W związku z realizacją projektu Wdrożenie platformy B2B realizującej procesy

Bardziej szczegółowo

WYJAŚNIENIA NR 2 TREŚCI SIWZ

WYJAŚNIENIA NR 2 TREŚCI SIWZ CPI-ZZP-2244-40-495/13 Warszawa, dnia 24 stycznia 2013 roku Wykonawcy, którzy pobrali SIWZ w postępowaniu nr 40-CPI-ZZP-2244/12 Działając na podstawie art. 38 ust. 1a, ust. 2 i ust. 4 w zw. z art. 12a

Bardziej szczegółowo

WODOCIĄGI KIELECKIE Sp. z o.o. ul. Krakowska 64, 25-701 Kielce tel.: +48 41 36 531 00; fax: +48 41 34 552 20; e-mail: wodkiel@ wod-kiel.com.

WODOCIĄGI KIELECKIE Sp. z o.o. ul. Krakowska 64, 25-701 Kielce tel.: +48 41 36 531 00; fax: +48 41 34 552 20; e-mail: wodkiel@ wod-kiel.com. WODOCIĄGI KIELECKIE Sp. z o.o. ul. Krakowska 64, 25-701 Kielce tel.: +48 41 36 531 00; fax: +48 41 34 552 20; e-mail: wodkiel@wod-kiel.com.pl REGON 290856791 NIP 959 116 49 32 Sąd Rejonowy w Kielcach X

Bardziej szczegółowo

Szczegółowy opis przedmiotu zamówienia

Szczegółowy opis przedmiotu zamówienia Szczegółowy opis przedmiotu zamówienia PWPW S.A. Strona 1 z 5 1. INFORMACJE WPROWADZAJĄCE 1.1. Przedmiotem postępowania jest udzielenie zamówienia na wdrożenie centralnego systemu Call Center w zakresie

Bardziej szczegółowo

Piotr Krząkała. Dyrektor Handlowy ds. Kluczowych Klientów

Piotr Krząkała. Dyrektor Handlowy ds. Kluczowych Klientów Piotr Krząkała Dyrektor Handlowy ds. Kluczowych Klientów Strategia firmy Każda organizacja działająca we współczesnym biznesie powinna posiadać określoną strategię działania i na tej bazie budować system

Bardziej szczegółowo

WARUNKI GWARANCJI I SERWISU GWARANCYJNEGO

WARUNKI GWARANCJI I SERWISU GWARANCYJNEGO Załącznik nr 3 do Umowy nr.. z dnia r. Warunki gwarancji i serwisu gwarancyjnego WARUNKI GWARANCJI I SERWISU GWARANCYJNEGO 1. Definicję pojęć: Celem opisania warunków świadczenia usług serwisowych definiuje

Bardziej szczegółowo

PROCEDURA UTRZYMANIA I ROZWOJU KWESTIONARIUSZA ZAINTERESOWAŃ ZAWODOWYCH

PROCEDURA UTRZYMANIA I ROZWOJU KWESTIONARIUSZA ZAINTERESOWAŃ ZAWODOWYCH Załącznik nr 2 do umowy nr 37/DI/PN/2013 PROCEDURA UTRZYMANIA I ROZWOJU KWESTIONARIUSZA ZAINTERESOWAŃ ZAWODOWYCH Rozdział 1. WPROWADZENIE Celem niniejszego dokumentu jest sprecyzowanie procedury zarządzania

Bardziej szczegółowo

BCC ECM Autorskie rozwiązanie BCC wspomagające zarządzanie dokumentami oraz procesami biznesowymi

BCC ECM Autorskie rozwiązanie BCC wspomagające zarządzanie dokumentami oraz procesami biznesowymi BCC ECM Autorskie rozwiązanie BCC wspomagające zarządzanie dokumentami oraz procesami biznesowymi Prezentacja rozwiązania Co to jest ECM? ECM (enterprise content management) to strategia świadomego zarządzania

Bardziej szczegółowo

Załącznik nr 8 Inne wymagania Zamawiającego, związane z realizacją przedmiotu zamówienia. Spis opracowań stanowiących Załącznik nr 8 do SIWZ

Załącznik nr 8 Inne wymagania Zamawiającego, związane z realizacją przedmiotu zamówienia. Spis opracowań stanowiących Załącznik nr 8 do SIWZ Załącznik nr 8 Inne wymagania Zamawiającego, związane z realizacją przedmiotu zamówienia Nr Nazwa Spis opracowań stanowiących Załącznik nr 8 do SIWZ 1. Szczegółowe wymogi dotyczące procedury dostawczo-odbiorowej

Bardziej szczegółowo

Projekt dotyczy stworzenia zintegrowanego, modularnego systemu informatycznego wspomagającego zarządzanie pracownikami i projektami w firmie

Projekt dotyczy stworzenia zintegrowanego, modularnego systemu informatycznego wspomagającego zarządzanie pracownikami i projektami w firmie Projekt dotyczy stworzenia zintegrowanego, modularnego systemu informatycznego wspomagającego zarządzanie pracownikami i projektami w firmie informatycznej. Zadaniem systemu jest rejestracja i przechowywanie

Bardziej szczegółowo

Projekt współfinansowany przez Unię Europejską z Europejskiego Funduszu Rozwoju Regionalnego Fundusze Europejskie dla rozwoju regionu łódzkiego

Projekt współfinansowany przez Unię Europejską z Europejskiego Funduszu Rozwoju Regionalnego Fundusze Europejskie dla rozwoju regionu łódzkiego Łódź, dn. 10.10.2014 r. OGŁOSZENIE O ZAMÓWIENIU nr 2/3.3/081 (POWYŻEJ 14 tys. EURO) 1. Zamawiający Firma i adres: PL Europa S.A. NIP: 725-195-02-28 Regon: 100381252 2. Tryb udzielenia zamówienia Zgodnie

Bardziej szczegółowo

I. Opis projektu ZAPYTANIE OFERTOWE. Warszawa, dn. 07.01.2015r. Dane firmowe: ialbatros S.A. ul. Jutrzenki 183 02-231 Warszawa NIP: 108-00-09-770

I. Opis projektu ZAPYTANIE OFERTOWE. Warszawa, dn. 07.01.2015r. Dane firmowe: ialbatros S.A. ul. Jutrzenki 183 02-231 Warszawa NIP: 108-00-09-770 Warszawa, dn. 07.01.2015r. Dane firmowe: ialbatros S.A. ul. Jutrzenki 183 02-231 Warszawa NIP: 108-00-09-770 ZAPYTANIE OFERTOWE W związku z realizacją Projektu System B2B integrujący systemy ialbatros

Bardziej szczegółowo

Projekt Badawczy Analiza wskaźnikowa przedsiębiorstwa współfinansowany ze środków Unii Europejskiej

Projekt Badawczy Analiza wskaźnikowa przedsiębiorstwa współfinansowany ze środków Unii Europejskiej Projekt Badawczy Analiza wskaźnikowa przedsiębiorstwa współfinansowany ze środków Unii Europejskiej FiM Consulting Sp. z o.o. Szymczaka 5, 01-227 Warszawa Tel.: +48 22 862 90 70 www.fim.pl Spis treści

Bardziej szczegółowo

Opieka techniczna systemu GeoMelio (ETAP II) Lp Rodzaj usługi Opis usługi

Opieka techniczna systemu GeoMelio (ETAP II) Lp Rodzaj usługi Opis usługi Załącznik nr 3 do umowy Opieka techniczna systemu GeoMelio (ETAP II) Lp Rodzaj usługi Opis usługi 1. a) Rozszerzenia funkcjonalności systemu (nie zmieniające generalnej struktury programu). Usługa umożliwia

Bardziej szczegółowo

DLA SEKTORA INFORMATYCZNEGO W POLSCE

DLA SEKTORA INFORMATYCZNEGO W POLSCE DLA SEKTORA INFORMATYCZNEGO W POLSCE SRK IT obejmuje kompetencje najważniejsze i specyficzne dla samego IT są: programowanie i zarządzanie systemami informatycznymi. Z rozwiązań IT korzysta się w każdej

Bardziej szczegółowo

Dotacje na innowacje Inwestujemy w waszą przyszłość

Dotacje na innowacje Inwestujemy w waszą przyszłość Załącznik nr 1 Załącznik techniczny przedmiotu zamówienia zakup badań w zakresie opracowania wersji serwera aplikacyjnego pod aplikację wektorową i obsługi wymiany treści multimedialnych w tymże serwerze

Bardziej szczegółowo

ZAPISY OGÓLNE... 2 II. WARUNKI GWARANCJI SPRZĘTU... 4 III. WARUNKI GWARANCJI DLA OPROGRAMOWANIA... 6 IV. POZIOMY SLA...

ZAPISY OGÓLNE... 2 II. WARUNKI GWARANCJI SPRZĘTU... 4 III. WARUNKI GWARANCJI DLA OPROGRAMOWANIA... 6 IV. POZIOMY SLA... Załącznik nr 10 Warunki Gwarancji I. ZAPISY OGÓLNE... 2 II. WARUNKI GWARANCJI SPRZĘTU... 4 III. WARUNKI GWARANCJI DLA OPROGRAMOWANIA... 6 IV. POZIOMY SLA... 7 I. Zapisy ogólne 1. Wykonawca udziela Zamawiającemu

Bardziej szczegółowo

WYJAŚNIENIE TREŚCI SPECYFIKACJI ISTOTNYCH WARUNKÓW ZAMÓWIENIA

WYJAŚNIENIE TREŚCI SPECYFIKACJI ISTOTNYCH WARUNKÓW ZAMÓWIENIA Załącznik nr 24 do zarządzenia Dyrektora IRZiBŻ PAN w Olsztynie nr 118/2012 z dnia 30.04.2012r znak: ZP-PNK/D/2013/9/87 Olsztyn, dnia 17.10.2013 r. WYJAŚNIENIE TREŚCI SPECYFIKACJI ISTOTNYCH WARUNKÓW ZAMÓWIENIA

Bardziej szczegółowo

SZCZEGÓŁOWY OPIS PRZEDMIOTU ZAMÓWIENIA I WYMAGAŃ TECHNICZNYCH DOTYCZĄCYCH DOSTAWY SPRZĘTU KOMPUTEROWEGO WRAZ Z OPROGRAMOWANIEM (ZADANIE NR 1)

SZCZEGÓŁOWY OPIS PRZEDMIOTU ZAMÓWIENIA I WYMAGAŃ TECHNICZNYCH DOTYCZĄCYCH DOSTAWY SPRZĘTU KOMPUTEROWEGO WRAZ Z OPROGRAMOWANIEM (ZADANIE NR 1) Projekt współfinansowany przez Unię Europejską ze środków Europejskiego Funduszu Rozwoju Regionalnego w ramach Programu Operacyjnego Innowacyjna Gospodarka 2007-2013 Załącznik nr 6 do SIWZ SZCZEGÓŁOWY

Bardziej szczegółowo

Szczegółowy zakres przedmiotu zamówienia. I. Opieka nad serwerami TAK/NIE

Szczegółowy zakres przedmiotu zamówienia. I. Opieka nad serwerami TAK/NIE Szczegółowy zakres przedmiotu zamówienia Załącznik nr 7 do SIWZ I. Opieka nad serwerami TAK/NIE 1 Prace konserwacyjne przynajmniej dwa razy do roku (prócz rakcji na awarie) Całodobowy monitoring pracy

Bardziej szczegółowo

Miasto Łomża jako Zamawiający odpowiada na pytania otrzymane od Wykonawcy.

Miasto Łomża jako Zamawiający odpowiada na pytania otrzymane od Wykonawcy. Łomża, dn. 15.07.2014 r. WIN. 271.2.8.1.2014 Do wszystkich zainteresowanych Dotyczy: postępowania o udzielenie zamówienia publicznego na zadanie: Stop wykluczeniu cyfrowemu w mieście Łomża dostawa komputerów,

Bardziej szczegółowo

zaprasza do składania ofert w odpowiedzi na: ZAPYTANIE OFERTOWE nr 1/6/2015/POIG 8.2

zaprasza do składania ofert w odpowiedzi na: ZAPYTANIE OFERTOWE nr 1/6/2015/POIG 8.2 TORA-LESZNO SPÓŁKA Z OGRANICZONĄ ODPOWIEDZIALNOŚCIĄ MÓRKOWSKA 40a 64-100 Wilkowice NIP: PL 6972312026 UDA-POIG.08.02.00-30-194/12-00 Wilkowice, 12.06.2015 zaprasza do składania ofert w odpowiedzi na: ZAPYTANIE

Bardziej szczegółowo

Zapytanie ofertowe nr 1/POIG 8.2/2013

Zapytanie ofertowe nr 1/POIG 8.2/2013 Świecie, 02.12.2013r. Zapytanie ofertowe nr 1/POIG 8.2/2013 Zamawiający: Drukarnia MW Wieczorek Mirosław Ul. Gen. J. Hallera 7G, 86-100 Świecie NIP: 5591391666, REGON: 093072292 Tel. 525256081, Fax. 525256081

Bardziej szczegółowo

(Wzór umowy) UMOWA Nr CSIOZ/../2015

(Wzór umowy) UMOWA Nr CSIOZ/../2015 (Wzór umowy) UMOWA Nr CSIOZ/../2015 zawarta w dniu..2015 roku w Warszawie pomiędzy: Załącznik nr 3 do Zapytania ofertowego Skarbem Państwa - Centrum Systemów Informacyjnych Ochrony Zdrowia z siedzibą w

Bardziej szczegółowo

SZCZEGÓŁOWY OPIS PRZEDMIOTU ZAMÓWIENIA I WYMAGAŃ TECHNICZNYCH DOTYCZĄCYCH DOSTAWY SPRZĘTU KOMPUTEROWEGO WRAZ Z OPROGRAMOWANIEM

SZCZEGÓŁOWY OPIS PRZEDMIOTU ZAMÓWIENIA I WYMAGAŃ TECHNICZNYCH DOTYCZĄCYCH DOSTAWY SPRZĘTU KOMPUTEROWEGO WRAZ Z OPROGRAMOWANIEM Załącznik Nr 7 do SIWZ SZCZEGÓŁOWY OPIS PRZEDMIOTU ZAMÓWIENIA I WYMAGAŃ TECHNICZNYCH DOTYCZĄCYCH DOSTAWY SPRZĘTU KOMPUTEROWEGO WRAZ Z OPROGRAMOWANIEM Postanowienia ogólne: 1) Dostawa 30 sztuk zestawów

Bardziej szczegółowo

Wstęp do Informatyki. Klasyfikacja oprogramowania

Wstęp do Informatyki. Klasyfikacja oprogramowania Wstęp do Informatyki Klasyfikacja oprogramowania Oprogramowanie komputerowe Funkcjonalność komputera jest wynikiem zarówno jego budowy, jak i zainstalowanego oprogramowania Komputer danej klasy znajduje

Bardziej szczegółowo

Opis Przedmiotu Zamówienia

Opis Przedmiotu Zamówienia Załącznik nr 1 do SIWZ/ załącznik nr 1 do umowy OP/UP/099/2011 Opis Przedmiotu Zamówienia 1. Przedmiot zamówienia 1.1. Przedmiotem zamówienia jest świadczenie usług konsultancko-developerskich dla systemu

Bardziej szczegółowo

Opis przedmiotu zamówienia (OPZ) Świadczenie usługi Asysty Technicznej dla systemu E-BPNT

Opis przedmiotu zamówienia (OPZ) Świadczenie usługi Asysty Technicznej dla systemu E-BPNT Załącznik nr 1 do SIWZ Opis przedmiotu zamówienia (OPZ) Świadczenie usługi Asysty Technicznej dla systemu E-BPNT 1 I. Przedmiot zamówienia: Świadczenie usługi Asysty Technicznej dla systemu E-BPNT. II.

Bardziej szczegółowo

Można rozpatrywać dwa sposoby zapewnienia obsługi informatycznej firmy:

Można rozpatrywać dwa sposoby zapewnienia obsługi informatycznej firmy: Oferta firmy W swojej codziennej pracy pomagamy firmom w kompleksowej obsłudze informatycznej. Jesteśmy dynamicznym, młodym zespołem techników i informatyków. Nasza oferta oparta jest na sprawdzonych i

Bardziej szczegółowo

CEL SZKOLENIA: uzyskanie przez uczestników praktycznych umiejętności prawidłowego postępowania na każdym etapie procedury

CEL SZKOLENIA: uzyskanie przez uczestników praktycznych umiejętności prawidłowego postępowania na każdym etapie procedury NAZWA SZKOLENIA: Przygotowanie zamówień publicznych na zakup systemów teleinformatycznych w tym sprzętu i oprogramowania komputerowego także typu open source. CEL SZKOLENIA: uzyskanie przez uczestników

Bardziej szczegółowo

Zapytanie ofertowe. Przedmiot: Stanowisko: Administrator systemu dla nowej e-usługi firmy Intellive

Zapytanie ofertowe. Przedmiot: Stanowisko: Administrator systemu dla nowej e-usługi firmy Intellive Zapytanie ofertowe Przedmiot: Stanowisko: Administrator systemu dla nowej e-usługi firmy Intellive Projekt: Stworzenie rozwiązania wspomagającego pewne i efektywne zakupy na aukcjach internetowych Data

Bardziej szczegółowo

Metodyka projektowania komputerowych systemów sterowania

Metodyka projektowania komputerowych systemów sterowania Metodyka projektowania komputerowych systemów sterowania Andrzej URBANIAK Metodyka projektowania KSS (1) 1 Projektowanie KSS Analiza wymagań Opracowanie sprzętu Projektowanie systemu Opracowanie oprogramowania

Bardziej szczegółowo

Zapytanie ofertowe. Skawina 7 listopada 2014

Zapytanie ofertowe. Skawina 7 listopada 2014 Skawina 7 listopada 2014 Zapytanie ofertowe Szanowni Państwo, W związku z realizacją projektu pt. Elektroniczna wymiana informacji pomiędzy partnerami w biznesie szansą na rozwój firmy HAUTEC Sp. z o.o.,

Bardziej szczegółowo

System CMMS Profesal Maintenance wspiera prace UR w firmie MC Bauchemie

System CMMS Profesal Maintenance wspiera prace UR w firmie MC Bauchemie System CMMS Profesal Maintenance wspiera prace UR w firmie MC Bauchemie Firma MC Bauchemie Firma MC Bauchemie w Środzie Wielkopolskiej to wyspecjalizowany zakład produkcyjny dodatków do betonu, produktów

Bardziej szczegółowo

Szczegółowy Opis Przedmiotu Zamówienia. System monitoringu (CCTV) oraz system integrujący do zarządzania bezpieczeństwem dla CEUE

Szczegółowy Opis Przedmiotu Zamówienia. System monitoringu (CCTV) oraz system integrujący do zarządzania bezpieczeństwem dla CEUE Załącznik nr 8... /nazwa i adres Wykonawcy/.. miejscowość i data Szczegółowy Opis Przedmiotu Zamówienia System monitoringu (CCTV) oraz system integrujący do zarządzania bezpieczeństwem dla CEUE Dostawa

Bardziej szczegółowo

Zapytanie ofertowe nr 06/2014

Zapytanie ofertowe nr 06/2014 Poznań, dnia 27.11.2014r. Zapytanie ofertowe nr 06/2014 dotyczy: zaprojektowania, wykonania, dostarczenia i wdrożenia kompleksowego systemu informatycznego zarządzania kancelarią brokerską, umożliwiającego

Bardziej szczegółowo

ZAPYTANIE OFERTOWE. Ul. Sikorskiego 28 44-120 Pyskowice NIP 6480001415 REGON 008135290. Oferty pisemne prosimy kierować na adres: Hybryd Sp. z o.o.

ZAPYTANIE OFERTOWE. Ul. Sikorskiego 28 44-120 Pyskowice NIP 6480001415 REGON 008135290. Oferty pisemne prosimy kierować na adres: Hybryd Sp. z o.o. ZAPYTANIE OFERTOWE Pyskowice, dn. 28.04.2014r. Szanowni Państwo, Zwracamy się do Państwa z zaproszeniem do złożenia ofert na ujęte w niniejszym zapytaniu ofertowym zakupy w związku z realizowanym w ramach

Bardziej szczegółowo

OPIS WARUNKÓW ZAMÓWIENIA. do przetargu nieograniczonego nr 20/V/2015

OPIS WARUNKÓW ZAMÓWIENIA. do przetargu nieograniczonego nr 20/V/2015 ZARZĄD INFRASTRUKTURY KOMUNALNEJ I TRANSPORTU W KRAKOWIE ul. Centralna 53, 31-586 Kraków, centrala tel. +48 12 616 7000, fax: +48 12 616 7417,email: sekretariat@zikit.krakow.pl OPIS WARUNKÓW ZAMÓWIENIA

Bardziej szczegółowo

Pytanie nr 3: Czy połączenie urządzenie mobilne -> serwer będzie szyfrowane? (protokół HTTPS).

Pytanie nr 3: Czy połączenie urządzenie mobilne -> serwer będzie szyfrowane? (protokół HTTPS). Do Wykonawców Wrocław, 12.06.2015r. CUI-DOAZ.331.10.2015 CUI/ZP/PN/10/2015/11/... Dotyczy: postępowanie o udzielenie zamówienia publicznego na: Rozwój CRM - Opracowanie i wdrożenie aplikacji mobilnej CRM

Bardziej szczegółowo

ZAPYTANIE OFERTOWE. z dnia 20 grudnia 2013r.

ZAPYTANIE OFERTOWE. z dnia 20 grudnia 2013r. Projekt współfinansowany ze środków Unii Europejskiej w ramach Europejskiego Funduszu Rozwoju Regionalnego ZAPYTANIE OFERTOWE z dnia 20 grudnia 2013r. w związku z realizacją projektu pn. Wdrożenie systemu

Bardziej szczegółowo

Doświadczenia w wdrażaniu systemu zarządzania bezpieczeństwem informacji zgodnego z normą ISO 27001

Doświadczenia w wdrażaniu systemu zarządzania bezpieczeństwem informacji zgodnego z normą ISO 27001 Doświadczenia w wdrażaniu systemu zarządzania bezpieczeństwem informacji zgodnego z normą ISO 27001 na przykładzie Urzędu Miejskiego w Bielsku-Białej Gliwice, dn. 13.03.2014r. System Zarządzania Bezpieczeństwem

Bardziej szczegółowo

Czeladź, dnia 01.03.2014 r. ZAPYTANIE OFERTOWE. Zamawiający:

Czeladź, dnia 01.03.2014 r. ZAPYTANIE OFERTOWE. Zamawiający: Czeladź, dnia 01.03.2014 r. ZAPYTANIE OFERTOWE Zamawiający: Katowickie Przedsiębiorstwo Naprawy Maszyn Budowlanych "BUDROPOL" Spółka Jawna A. Będkowski, R. Liczberski i inni 41-253 Czeladź ul. Letnia 3

Bardziej szczegółowo

Usterka oprogramowanie nie realizuje funkcji określonych w dokumentach oprogramowania

Usterka oprogramowanie nie realizuje funkcji określonych w dokumentach oprogramowania ZAŁĄCZNIK NR 3 do umowy z dnia r. Szczegółowe warunki i zasady świadczenia przez Wykonawcę usług serwisu gwarancyjnego. 1. Definicje Usterka oprogramowanie nie realizuje funkcji określonych w dokumentach

Bardziej szczegółowo

TECHNOLOGIE JUTRA DZISIAJ NOWOCZESNE ZARZĄDZANIE MAJĄTKIEM

TECHNOLOGIE JUTRA DZISIAJ NOWOCZESNE ZARZĄDZANIE MAJĄTKIEM TECHNOLOGIE JUTRA DZISIAJ NOWOCZESNE ZARZĄDZANIE MAJĄTKIEM PODSTAWA PRAWNA Każda instytucja publiczna oraz przedsiębiorstwa zobowiązane są do prowadzenia ewidencji majątku oraz jego okresowej inwentaryzacji.

Bardziej szczegółowo

ZAPROSZENIE DO ZŁOŻENIA OFERTY CENOWEJ NA ANALIZĘ PRZYGOTOWAWCZĄ

ZAPROSZENIE DO ZŁOŻENIA OFERTY CENOWEJ NA ANALIZĘ PRZYGOTOWAWCZĄ Warszawa, 5.01.2015 ZAPROSZENIE DO ZŁOŻENIA OFERTY CENOWEJ NA ANALIZĘ PRZYGOTOWAWCZĄ 1. Nazwa i adres zamawiającego: PROGUEST CONSULTING SP. Z O. O. ul. Powstańców 24N lok. 3 05-091 Ząbki Firma PROGUEST

Bardziej szczegółowo

Odpowiedź Zamawiającego w ramach zgłoszonych wniosków o wyjaśnienie SIWZ

Odpowiedź Zamawiającego w ramach zgłoszonych wniosków o wyjaśnienie SIWZ Warszawa, 2016-04-19 WIF.261.3.2016 Wszyscy Wykonawcy Dotyczy: postępowania o udzielenie zamówienia publicznego prowadzonego w trybie przetargu nieograniczonego na zaprojektowanie, wykonanie i wdrożenie

Bardziej szczegółowo

Zasady organizacji projektów informatycznych

Zasady organizacji projektów informatycznych Zasady organizacji projektów informatycznych Systemy informatyczne w zarządzaniu dr hab. inż. Joanna Józefowska, prof. PP Plan Definicja projektu informatycznego Fazy realizacji projektów informatycznych

Bardziej szczegółowo

ZAPYTANIE OFERTOWE NR 7/2013

ZAPYTANIE OFERTOWE NR 7/2013 Dial Tone Sp. z o.o. Piaseczno dn. 02.12.2013 r. ul. Okulickiego 7/9 05-500 Piaseczno NIP 123-126-21-66 Regon 145805375 ZAPYTANIE OFERTOWE NR 7/2013 na Rozbudowa programu komputerowego (Portal Partnerski)

Bardziej szczegółowo

MINISTERSTWO ADMINISTRACJI I CYFRYZACJI RAPORT KOŃCOWY

MINISTERSTWO ADMINISTRACJI I CYFRYZACJI RAPORT KOŃCOWY RAPORT KOŃCOWY z realizacji umowy nr 6/Infostrategia/MAC/UW-UR/13 z dnia 22.08.2013 r. na udzielenie wsparcia doradczego beneficjentom projektów szerokopasmowych realizowanych w ramach działania 8.3 Programu

Bardziej szczegółowo

PROCEDURA ADMINISTROWANIA ORAZ USUWANIA AWARII I BŁĘDÓW W CSIZS

PROCEDURA ADMINISTROWANIA ORAZ USUWANIA AWARII I BŁĘDÓW W CSIZS Załącznik nr 3 do umowy nr 10/DI/PN/2016 PROCEDURA ADMINISTROWANIA ORAZ USUWANIA AWARII I BŁĘDÓW W Rozdział 1. ADMINISTROWANIE 1. Wykonawca, w celu zapewnienia ciągłości funkcjonowania, zobowiązuje się

Bardziej szczegółowo

Wzór umowy. reprezentowaną przez

Wzór umowy. reprezentowaną przez Załącznik nr 3 do SIWZ Wzór umowy zawarta w dniu. pomiędzy: Wielkopolskim Urzędem Wojewódzkim w Poznaniu z siedzibą al. Niepodległości 16/18, 61-713 Poznań zwanym dalej Zamawiającym reprezentowanym przez:

Bardziej szczegółowo

Zdalne monitorowanie i zarządzanie urządzeniami sieciowymi

Zdalne monitorowanie i zarządzanie urządzeniami sieciowymi Uniwersytet Mikołaja Kopernika w Toruniu Wydział Matematyki i Informatyki Wydział Fizyki, Astronomii i Infomatyki Stosowanej Piotr Benetkiewicz Nr albumu: 168455 Praca magisterska na kierunku Informatyka

Bardziej szczegółowo

Zapytanie ofertowe 7/2013

Zapytanie ofertowe 7/2013 03.06.2013 r. Zapytanie ofertowe 7/2013 Dotyczy: Zakup systemu informatycznego B2B do realizacji projektu pn. Wdrożenie zintegrowanego systemu B2B w celu usprawnienia zarządzania współpracą GLOKOR Sp.

Bardziej szczegółowo

firmy produkty intranet handel B2B projekty raporty notatki

firmy produkty intranet handel B2B projekty raporty notatki firmy mail intranet produkty DOKUMENTY handel raporty B2B projekty notatki serwis zadania Dlaczego warto wybrać Pakiet ITCube? Najczęściej wybierany polski CRM Pakiet ITCube jest wykorzystywany przez ponad

Bardziej szczegółowo

Bezpieczeństwo aplikacji i urządzeń mobilnych w kontekście wymagań normy ISO/IEC 27001 oraz BS 25999 doświadczenia audytora

Bezpieczeństwo aplikacji i urządzeń mobilnych w kontekście wymagań normy ISO/IEC 27001 oraz BS 25999 doświadczenia audytora Bezpieczeństwo aplikacji i urządzeń mobilnych w kontekście wymagań normy ISO/IEC 27001 oraz BS 25999 doświadczenia audytora Krzysztof Wertejuk audytor wiodący ISOQAR CEE Sp. z o.o. Dlaczego rozwiązania

Bardziej szczegółowo

Powiatowy Urząd Pracy ul. Staszica 47a 42-800 Kalisz [dalej: Zamawiający ]

Powiatowy Urząd Pracy ul. Staszica 47a 42-800 Kalisz [dalej: Zamawiający ] 1/5 Poznań, 16 kwietnia 2010 r. Powiatowy Urząd Pracy ul. Staszica 47a 42-800 Kalisz [dalej: Zamawiający ] INFORMACJA W SPRAWIE NIEZGODNEJ Z PRZEPISAMI PRAWA ZAMÓWIEŃ PUBLICZNYCH CZYNNOŚCI ZAMAWIAJĄCEGO

Bardziej szczegółowo

ZAPYTANIE OFERTOWE. nr 1/UE/2014. z dnia 7.01.2014 r. w związku z realizacją projektu pn.

ZAPYTANIE OFERTOWE. nr 1/UE/2014. z dnia 7.01.2014 r. w związku z realizacją projektu pn. Projekt współfinansowany ze środków Unii Europejskiej w ramach Europejskiego Funduszu Rozwoju Regionalnego ZAPYTANIE OFERTOWE nr /UE/204 z dnia 7.0.204 r. w związku z realizacją projektu pn. Wdrożenie

Bardziej szczegółowo

wsparcia w zakresie kryteriów wyboru firmy szkoleniowej lub weryfikacji jej działań. Członkowie Polskiej Izby Firm Szkoleniowych Strona 1 z 10

wsparcia w zakresie kryteriów wyboru firmy szkoleniowej lub weryfikacji jej działań. Członkowie Polskiej Izby Firm Szkoleniowych Strona 1 z 10 Misją Polskiej Izby Firm Szkoleniowych jest działanie na rzecz ciągłego rozwoju kompetencji i kształcenia przez cale życie poprzez rozwój rynku szkoleniowego, na którym obowiązują zasady uczciwej konkurencji.

Bardziej szczegółowo

Załącznik Nr 6 do siwz. UMOWA (projekt)

Załącznik Nr 6 do siwz. UMOWA (projekt) Załącznik Nr 6 do siwz UMOWA (projekt) zawarta w dniu... r. pomiędzy Samodzielnym Publicznym Zakładem Opieki Zdrowotnej z siedzibą w Parczewie 21-200, ul. Kościelna 136, zarejestrowanym w Sądzie Rejonowym

Bardziej szczegółowo

Projekt MCA. Spotkanie Przedsiębiorc. biorców w z Przedstawicielami Służby S

Projekt MCA. Spotkanie Przedsiębiorc. biorców w z Przedstawicielami Służby S Projekt MCA Spotkanie Przedsiębiorc biorców w z Przedstawicielami Służby S Celnej Zbigniew Juzoń Warszawa, 19 grudnia 2012 r. Kierownik Projektu MCA Izba Celna w Kielcach Projekt Program e-cło,, POIG.07.01.00-00

Bardziej szczegółowo

OPIS PRZEDMIOTU ZAMÓWIENIA

OPIS PRZEDMIOTU ZAMÓWIENIA Lubelskie Centrum Transferu Technologii Politechniki Lubelskiej ul. Nadbystrzycka 36, 20-618 Lublin Tel. 81 538 42 70, fax. 81 538 42 67; e-mail: lctt@pollub.pl OPIS PRZEDMIOTU ZAMÓWIENIA Do realizacji

Bardziej szczegółowo

Autor: Artur Lewandowski. Promotor: dr inż. Krzysztof Różanowski

Autor: Artur Lewandowski. Promotor: dr inż. Krzysztof Różanowski Autor: Artur Lewandowski Promotor: dr inż. Krzysztof Różanowski Przegląd oraz porównanie standardów bezpieczeństwa ISO 27001, COSO, COBIT, ITIL, ISO 20000 Przegląd normy ISO 27001 szczegółowy opis wraz

Bardziej szczegółowo

Usprawnienie procesu zarządzania konfiguracją. Marcin Piebiak Solution Architect Linux Polska Sp. z o.o.

Usprawnienie procesu zarządzania konfiguracją. Marcin Piebiak Solution Architect Linux Polska Sp. z o.o. Usprawnienie procesu zarządzania konfiguracją Marcin Piebiak Solution Architect Linux Polska Sp. z o.o. 1 Typowy model w zarządzaniu IT akceptacja problem problem aktualny stan infrastruktury propozycja

Bardziej szczegółowo