3. Kongres Informatyki Polskiej
3. Kongres Informatyki Polskiej

Kongres odbył się w dniach
2 - 4 czerwca 2003 roku w Poznaniu
 

organizatorzy

Polska Izba Informatyki i Telekomunikacji  
Polskie Towarzystwo Informatyczne  
Stowarzyszenie Polski Rynek Oprogramowania  Naukowe Towarzystwo Informatyki Ekonomicznej  
Stowarzyszenie Internet Society Poland  
Stowarzyszenie Komputer i Sprawy Szkoły KISS AFCEA - Polski Oddział Stowarzyszenia Łączności i Elektroniki Sił Zbrojnych  
 
sponsorzy główni kongresu

ComputerLand SA
Solidex SA

sponsorzy kongresu

BRE Bank  McKinsey & Company
Microsoft  Plus GSMProkom
 
mecenasi kongresu

Narodowy Bank Polski - Mecenas Młodych Informatyków
Naukowa i Akademicka Sieć Komputerowa

Polskie Centrum Certyfikacji Elektronicznej - Sigillum



7. Projekty informatyczne

Wynik realizacji przedsięwzięć informatycznych jest przede wszystkim zależny od ludzi tworzących i realizujących te przedsięwzięcia, a w mniejszym stopniu od zastosowanej technologii realizacji oraz narzędzi informatycznych.

Powyższe stwierdzenie podsumowuje dyskusje dotyczące metod, celów i analiz przyczyn porażek oraz opisów sukcesów realizacji przedsięwzięć informatycznych. Prowadzi to do stwierdzenia, że kluczem do uzyskania sukcesu w projekcie informatycznym jest dobór profesjonalnego zespołu o odpowiednich umiejętnościach działającego w otoczeniu ludzi rozumiejących znaczenie danego przedsięwzięcia.

Projekt informatyczny wdrożony z sukcesem to projekt:
  • zakończony w założonym czasie oraz budżecie,
  • mający oczekiwaną funkcjonalność i wydajność,
  • zaakceptowany przez użytkownika,
  • przynoszący wykonawcy należne mu korzyści.
Niestety w zbyt wielu realizacjach projektów informatycznych notujemy porażki (nie tylko w Polsce), co oznacza ogromne straty oraz podważanie zaufania do powszechnego zastosowania informatyki.

Przyczynami porażek realizacji projektu informatycznego - oprócz niestosowania się do reguł inżynierii oprogramowania - są:
  • po stronie zamawiającego
    • brak wkomponowania przyszłego projektu w proces biznesowy zamawiającej firmy czy instytucji,
    • brak profesjonalnie przygotowanej i odpowiadającej rzeczywistym potrzebom specyfikacji (według której zostaje zamawiany projekt) albo preparowanie specyfikacji pod określonego wykonawcę w wyniku działań korupcyjnych,
    • brak w zespole odpowiedniej wiedzy i umiejętności definiowania założeń oraz metod odbioru projektu,
    • brak wiedzy i standardów zarządzania projektami oraz jakością i ryzykiem lub wręcz zachęcanie wykonawcy do ich zaniechania w celu obniżenia kosztów,
    • brak zdecydowania i odpowiedniego nadzoru ze strony kierownictwa,
    • wybieranie wykonawcy na podstawie minimalnej ceny zamiast oceny umiejętności zespołu oraz funkcjonalności oferowanego rozwiązania,
    • brak odpowiedniego przeszkolenia oraz motywacji użytkowników systemu,
  • w sferze administracji publicznej po stronie zamawiającego dodatkowo
    • brak przygotowanych na czas przepisów (ustaw i rozporządzeń) z dziedziny, której ma dotyczyć projekt,
    • brak przewidywania kosztów eksploatacyjnych systemu, nieuwzględnianie w planach budżetowych upływu okresów gwarancji oraz technologicznego starzenia się systemu,
  • po stronie wykonawcy
    • brak umiejętności oceny ryzyka podejmowania się wykonania danego projektu,
    • brak poczucia odpowiedzialności za podjęcie nierealnego zadania oraz akceptowanie źle przygotowanych specyfikacji wymagań użytkowych,
    • stosowanie dumpingu cenowego lub praktyk korupcyjnych dla wygrania przetargu,
    • brak odpowiedniego profesjonalnego przygotowania zespołu do realizacji projektu (rekrutacja zespołu wykonawczego dopiero po podpisaniu kontraktu),
    • brak wiedzy i standardów zarządzania projektami,
    • brak umiejętności koordynacji prac projektowych zespołu wykonawcy,
    • brak umiejętności koordynacji prac z zespołem zamawiającego,
    • brak umiejętności komunikacji w zespole projektowym oraz z otoczeniem,
    • skrywanie rzeczywistego stopnia zaawansowania prac (ukrywanie trudności) przed kierownictwem wykonawcy,
    • niedocenianie obaw zwykłych użytkowników systemu ze strony zamawiającego.
Wymienione przyczyny porażek realizacji projektu informatycznego nie wyczerpują tematu. Zwracając uwagę na najważniejsze z nich, mamy nadzieję na opamiętanie się zarówno zamawiających, jak i wykonawców. Szczególnie ważnym jest odpowiednie wczesne przygotowanie odpowiednich ustaw i rozporządzeń, na których podstawie mają funkcjonować procedury projektu. Niestety w historii czołowych projektów w naszej administracji większość problemów rozpoczynała się od braku odpowiednich ustaw - począwszy od ustaw o VAT i PIT dla systemu POLTAX po ustawę o dofinansowaniu rolników dla systemu IACS! Nie ulega też wątpliwości, że istnienie korupcji przy wielu przetargach (co ciekawsze, często również w przetargach prowadzonych przez firmy prywatne) ma istotny wpływ na przyszły sukces, a raczej porażkę projektu informatycznego. Z kolei zmniejszanie kosztów poprzez rezygnację z niezbędnych elementów projektu, jak zarządzanie jakością czy ryzykiem, może prowadzić do tak bolesnych wpadek, jak głośne załamanie się systemu obsługi wyborów samorządowych.

Zagwarantowanie poprawności i bezpieczeństwa funkcjonowania systemów informatycznych jest istotą pewności ich użytkowania. Konieczne jest określenie zakresu osobistej odpowiedzialności prawnej twórców systemu za skutki jego błędnego funkcjonowania. Należy wymagać, aby osoby zatrudnione przy realizacji dużych przedsięwzięć miały odpowiednie wykształcenie i kwalifikacje zawodowe, a zastosowana technologia była zgodna z zasadami sztuki informatycznej. Jednocześnie muszą być określone wymagania stawiane użytkownikowi takiego systemu, aby ten z kolei zachowywał należytą staranność w zapewnienie bezpieczeństwa jego eksploatacji. Jako przykład można wykorzystać zasady stosowane od lat w budownictwie i energetyce, a także w medycynie.

Zakres gwarancji poprawności funkcjonowania systemów teleinformatycznych oraz określenie stopnia odpowiedzialności dostawcy za skutki wynikłe z awarii lub za spowodowania awarii systemów od nich zależnych wymaga uregulowań technicznych oraz prawnych. Trudność rozwiązania tego problemu leży w braku jednoznacznych definicji poprawności funkcjonowania systemu i określenia jej zależności od staranności w jego użytkowaniu. Oczywiście proste stwierdzenia są już gotowe i można je ujmować w akty prawne. Nie ma jednak jeszcze wypracowanych zasad dla bardziej złożonych systemów zbudowanych w nowych technologiach. Nie wiadomo, gdzie leży granica pomiędzy przyczynami powodowanymi ludzkim zaniedbaniem a przyczynami nieprzewidywalnymi lub zależnymi tylko od natury. Z rozwiązaniem tych problemów wiąże się też weryfikacja kwalifikacji osób projektujących, realizujących, wdrażających i eksploatujących systemy teleinformatyczne.

Procedury zamówień publicznych w informatyce muszą w większym stopniu niż obecnie wymagać odpowiedzialności przedstawicieli zamawiającego za rzetelne przygotowywanie specyfikacji zamówienia oraz wyboru oferenta. Bez dobrej (poprawnej i pełnej) specyfikacji nie może być dobrego systemu Obie strony - zamawiający oraz wykonawca - powinny zgodnie z umową odpowiadać za przygotowanie oraz jakość realizacji projektów teleinformatycznych.

Pomimo stosowania od kilku lat ustawy o zamówieniach publicznych zbyt często końcowy wynik realizacji zamówienia odbiega od oczekiwań. W każdym z takich przypadków można znaleźć wiele przyczyn, zarówno po stronie dostawcy, jak i zamawiającego. Po stronie dostawcy najczęstszymi przyczynami są: zbytnie obniżenie wartości kontraktu (z chęci wygrania przetargu) oraz nierealne skrócenie czasu realizacji i brak odpowiednich specjalistów. Po stronie zamawiającego najczęściej następuje zmiana specyfikacji projektu spowodowana zmianami prawa oraz ograniczeniami finansowymi oraz żądanie dodatkowych prac w ramach tego samego kontraktu. W specyfikacjach przetargowych powinny być określone wymagania nie tylko sprzętowo-techniczne ale również umiejętności zespołu wykonawczego. Nie usprawiedliwiając nierzetelnych czy też mało doświadczonych dostawców, konieczne jest jednak wprowadzenie odpowiedzialności zespołu po stronie zamawiającego za jakość i efekty realizacji kontraktu. Wspólna odpowiedzialność obu stron wzmocni dążenia do poszukiwania ugody i drogi dążenia do celu, a nie gromadzenia "dowodów" przeciwko drugiej stronie.



patroni medialni
Lupus Trójka Wprost Computerworld

Kongres Informatyki Polskiej
jest cykliczna imprezą organizowaną co cztery lata. Dwie pierwsze edycje odbyły się w Poznaniu w 1994 i 1998 roku wzbudzając duże zainteresowanie nie tylko w środowisku informatycznym, ale także wśród polityków i przedstawicieli innych branż gospodarki. Gościem 2.Kongresu był między innymi: obecny Premier RP Leszek Miller, natomiast Prezydent RP Aleksander Kwaśniewski, ówczesny Premier RP Jerzy Buzek i ówczesny Marszałek Sejmu RP Maciej Płażyński wystosowali listy do uczestników.
Nazwy oficjalne
Oficjalna nazwa Kongresu: 3. Kongres Informatyki Polskiej
Oficjalny skrót nazwy Kongresu: 3. KIP
Oficjalna strona Kongresu: www.kongres.org.pl
Oficjalny adres poczty elektronicznej: biuro@piit.org.pl

Dodatkowych Informacji udziela:
Biuro PIIT: biuro@piit.org.pl, (22) 628-2260
Biuro PTI: pti@pti.org.pl, (22) 838-4705

uwagi i komentarze do strony: Piotr Waglowski (c) 2003 VaGla