Znaczenie przedsiębiorstw z sektora MŚP w rozwoju gospodarczym Polski

Doświadczenia krajów wysoko rozwiniętych pokazują, że mała przedsiębiorczość odgrywa olbrzymią rolę w gospodarce wpływaj ąc na wzrost gospodarczy, nasycenie rynku towarami odpowiedniej jakości oraz wzrost zatrudnienia. Małe i średnie przedsiębiorstwa są swoistym stymulatorem rozwoju gospodarki, a ich liczba oraz potencjał może być jedną z miar oceny wzrostu gospodarczego[1].

Sektor MŚP charakteryzuje się dynamicznym podejściem do otoczenia. Uważa się, że firmy te są w stanie najszybciej reagować na zmieniające się potrzeby i preferencje potencjalnych klientów. Na ogół mają one trafne rozeznanie w sytuacji rynkowej, dlatego też łatwiej angażują się w określone przedsięwzięcia inwestycyjne. Dla dużych jednostek działanie na małych rynkach może być nieopłacalne, stąd często ustępuj ą one na nich miejsca małym bądź średnim firmom. Poprzez prowadzenie działalności w niszach rynkowych oraz na rynkach o mniejszym potencjale, przedsiębiorstwa z sektora MŚP przyczyniają się do podnoszenia sprawności funkcjonowania całej gospodarki[2].

Liczba aktywnych MŚP w 2002 r. wynosiła 1 732 701 (99,84 % ogółu przedsiębiorstw), z czego ok. 1 690 000 (97,5 %) to firmy mikro[3], 29 000 (1,7 %) to firmy małe i 13 000 (0,8 %) – firmy średnie[4]. Sektor ten odgrywa również znaczącą rolę pod względem udziału w PKB – na mikro, małe i średnie przedsiębiorstwa przypadało 48,6 % wytworzonego w 2002 r. produktu krajowego brutto, z tego na firmy mikro i małe 40,5 %, a na firmy średnie 8,1 %[5].

Małe i średnie firmy stanowią także ważne źródło absorpcji bezrobocia. W Polsce, w 2002 r. sektor ten zatrudniał 69,3 % ogółu pracujących (50,1 % w przedsiębiorstwach mikro i małych oraz 19,2 % w przedsiębiorstwach średnich)[6].

Istotny jest w szczególności fakt aktywizacji zawodowej ludności w regionach o niższym stopniu uprzemysłowienia. Rozwój małej przedsiębiorczości na tych terenach wydaje się być jednym ze sposobów na wyrównanie dysproporcji w rozwoju gospodarczym wiodących miast w Polsce oraz regionów uboższych, najczęściej mało atrakcyjnych dla dużych inwestorów. Działające w takich regionach mikro, małe i średnie przedsiębiorstwa, poprzez zwiększenie poziomu zatrudnienia oraz zaspokajanie bieżących potrzeb zamieszkałej tam ludności, pozytywnie wpływają na rozwój społeczności lokalnych. Tym samym przyczyniają się one do rozwiązania szeregu problemów zarówno gospodarczych, jak i społecznych.

[1] A. Skowronek – Mielczarek, Małe i średnie przedsiębiorstwa. Źródła finansowania, Warszawa 2003, s. 6.

[2] Ibidem, s. 7.

[3] H. Blińczak, Firmy mikro, rola makro, „Rzeczpospolita”, 25.11.2004 r.

[4] Raport o stanie…, op. cit., s. 28.

[5]  Firmy duże wytworzyły w badanym okresie 20,1 % PKB, pozostała część została wytworzona w innych sekcjach gospodarki (ibidem, s. 22).

[6]   Ibidem, s. 34.

Reklamy

Problemy integracji Rational Team Concert

praca magisterska o o zarządzaniu projektami informatych

Głównym zadaniem prac projektowych było usystematyzowanie wiedzy i przedstawienie w jak najprostszej postaci modeli oraz uzasadnień integracji Rational Team Concert z innymi aplikacjami Rationalowymi. Nie było to jednak proste zadanie ze względu na ograniczenia softwarowe oraz czynniki, które były mniej lub bardziej nieoczekiwane, takie jak:

  • Duże rozproszenie, niekompletność lub nieaktualność informacji
  • Szybko zmieniające się wersje oprogramowania
  • Nieoczekiwane błędy podczas konfiguracji integracji lub instalacji nowych oprogramowań
  • Krótki okres trwania licencji dodatkowych aplikacji
  • Niewłaściwe tłumaczenia nazw opcji w polskich wersjach aplikacji

Pierwszą poważną przeszkodą w integrowaniu i tworzeniu pracy było duże rozproszenie, niekompletność i nieaktualność znajdowanych informacji. Znaczna większość źródeł, danych i wiadomości dotyczących integracji aplikacji Rational, jakie można odnaleźć na specjalistycznych portalach i w książkach, posiada przestarzałe informacje. Bardzo pomocnym w tym przypadku okazuje się kontakt z profesjonalistami i twórcami tych narzędzi. Wskazówki udzielone przez zawodowców pomogły w stworzeniu nowych, zaktualizowanych procedur łączenia oprogramowania.

Następnym mankamentem tworzenia opracowania integracji, były szybko zmieniające się wersje oprogramowań. Nie rzadko zdarzało się, że pewne elementy potrzebne do łączenia aplikacji były przeniesione, zmodyfikowane lub całkowicie usunięte z nowych wydań programów. W tym przypadku należało odnaleźć inne rozwiązania łączenia platform Rationalowych.

Pojawiały się również nieoczekiwane problemy podczas konfiguracji lub instalacji nowych oprogramowań. Szczególnie kłopotliwe były te błędy, których nie można było w żaden sposób zlikwidować, jak tylko poprzez usunięcie wszystkich plików i ponowną próbę modyfikacji. Można przy tym zauważyć, jak głęboko programy Rational wchodzą w pliki systemowe, gdyż ciężko je z nich usunąć.

Niedociągnięciami są też niekompletne, lub niewłaściwe tłumaczenia polskich wersji oprogramowania. W wielu miejscach można napotkać zestawienie polskich i angielskich nazw opcji, w szczególności w aplikacjach web’owych RQM i RRC. Może to być bardzo uciążliwe dla użytkowników tych platform.

Problemów występujących podczas realizacji jakiegokolwiek z przedsięwzięć nie da się całkowicie uniknąć ani przewidzieć. Te które można napotkać pracując nad zintegrowaniem platform Rationalowych należą raczej do małej lub średniej kategorii problemów. Natomiast dużą zaletą tych oprogramowań są podobieństwa interface’owe, które sprawiają że poznawanie następnych aplikacji z tej grupy przychodzi dużo szybciej i łatwiej.

Integracja Rational Team Concert z aplikacjami grupy Rational

praca magisterska o o zarządzaniu projektami informatycznymi

Projekt informatyczny, który ma na celu wytworzenie oprogramowania, składa się z bardzo złożonych procesów, które ulegają zmianie chociażby z powodu zmieniających się wymagań klienta lub z powodu nieprzewidzianych wypadków. Złożoność działań i zmienność warunków realizacji przedsięwzięcia wpływa na pojawiające się problemy ze skoordynowaniem i uporządkowaniem wszelkich czynności, które należy podjąć do wytworzenia produktu.  Komplikacje wynikłe z tego tytułu mają kluczowe znaczenie dla powodzenia całego projektu, do tego stopnia, że niespełna 30%[1] z nich udaje się zrealizować z pełnym sukcesem tzn. w wyznaczonym czasie, w określonym budżecie oraz ze zrealizowanym pełnym zakresem wymagań klienta. Aby zmienić ten stan rzeczy z pomocą przychodzą liczne narzędzia, które mają pomóc w zrealizowaniu projektów. Jednak, żaden do tej pory produkt istniejący na rynku, nie jest w stanie objąć wszystkich obszarów związanych z zarządzaniem projektem informatycznym. Pomimo tego, istnieje możliwość połączenia różnego rodzaju oprogramowania w celu realizacji projektu. Między innymi firma IBM stworzyła swoje narzędzia grupy Rational, które obejmują znakomitą większość dziedzin zarządzania projektami informatycznymi. Ogromną ich zaletą jest to, iż posiadają one szerokie możliwości integracyjne nie tylko wśród narzędzi z tej samej grupy, ale również wśród aplikacji innych firm.

Istnieje bardzo wiele możliwości integracji narzędzi Rational, gdyż każde z nich możemy łączyć z jednym lub więcej aplikacji tworząc dowolne konfiguracje w zależności od potrzeb. Wykorzystywane i integrowane w niniejszej pracy aplikacje skupiają się wokół Rational Team Concert. Jest to jedyne narzędzie z grupy Rational skupiające wszystkie najważniejsze instrumenty do zarządzenia projektem oraz o tak szerokich możliwościach integracyjnych.

Przed przystąpieniem do realizacji projektu zespół i jego kierownik powinien się zastanowić, które narzędzia oprócz RTC, wdrożyć do swojego przedsięwzięcia. Jest to zagadnienie bardzo istotne i zależy od indywidualnych potrzeb każdego zespołu oraz charakteru projektu. Ułatwieniem dokonania wyboru mogą posłużyć przedstawione dalej możliwości integracyjne Rational Team Concert z innymi wybranymi narzędziami, takimi jak:

  • Rational Method Composer
  • Rational Requirements Composer
  • Rational Quality Manager
  • Rational RequsitePro
  • Rational Asser Manager
  • Rational Software Architect

Każde z tych narzędzi zajmuje się inną dziedziną w zakresie wytwarzania oprogramowania. Krótki opis w/w aplikacji wraz z wyszczególnieniem głównych elementów tworzonych w każdym z nich zawarte są na początku podrozdziałów, w dalszej części pracy.

Istnieją trzy główne sposoby integracji Rational Team Concert z innymi platformami:

  1. Komunikacja między serwerami
  2. Łączenie plików przez linkowanie
  3. Instalacja plug-inów

 Ad. a) Komunikacja między serwerami

Pierwszy sposób opiera się na ustanowieniu komunikacji pomiędzy serwerami. Wymaga to konfiguracji oprogramowania często na poziomie instalacyjnym. Jest to najtrudniejsza forma integracji, jednak pozwala ona na korzystanie ze wspólnego repozytorium i stu procentową komunikację między aplikacjami.

     Ad. b) Łączenie plików przez linkowanie

Drugi sposób wykorzystuje webową formę aplikacji. Jest to łączenie jednego elementu z aplikacji „A” z drugim elementem z aplikacji „B” za pomocą linków, jednak same narzędzia nie współpracują ze sobą. Zmiana któregokolwiek elementu wywoła reakcję tylko w elemencie z nim powiązanym.

     Ad. c) Instalacja plug-inów

Trzeci sposób odnosi się do aplikacji klienckich. Wiąże się on z instalacją plug-inów czyli tzw. wtyczek. Pozwala to na importowanie i eksportowanie plików z jednego narzędzia do drugiego. Nie występuje tu żadna komunikacja pomiędzy serwerami i aplikacjami, a jedynie pozwala to na importowanie i eksportowanie plików z jednego narzędzia do drugiego.

Poniższa tabela przedstawia możliwości integracyjne RTC z wybranymi narzędziami grupy Rational, w zależności od sposobu ich łączenia.

Tabela 3.2.1

Możliwości integracyjne Rational Team Concert z wybranymi narzędziami grupy Rational

  Rational Method Composer Rational Requirements Composer Rational Quality Manager Rational RequisitePro Rational Asset Manager Rational Software Architect
Komunikacja między Serverami + + +
Łączenie plików (linkowanie) + + +
Wtyczki (plug-in) + +

Legenda: „+” – występowanie integracji , „-” – brak integracji                     Źródło: Opracowanie własne

RTC można połączyć z każdym z aplikacji Rational. Można tego dokonać za pomocą jednego lub dwóch sposobów.  W dalszej części pracy zostało przedstawione, w jaki sposób
i jakie korzyści można osiągnąć łącząc RTC z tymi aplikacjami.

[1] K. Waćkowski, J. M. Chmielewski, opt. cit., str. 17

Ocena platformy Rational Team Concert

Po rozpoznaniu narzędzia Rational Team Concert warto zastanowić się nad zaletami i wadami jakie ten produkt posiada. Poniżej w tabeli znajduje się zestawienie najważniejszych silnych i słabych stron oprogramowania RTC.

Tabela 2.3.1

Wady i zalety Rational Team Concert

Zalety Wady
Ø  Możliwość zarządzania projektami za pomocą zwinnych metod

Ø  Rozszerzone możliwości budowania wersji przy ograniczeniu występowania błędów

Ø  Możliwość szybkiej oceny stanu projektu

Ø  Możliwość modyfikowania dostępnych zasobów do potrzeb projektu

Ø  Wspomaganie zarządzania rozproszonym zespołem

Ø  Duża ilość materiałów pomocniczych

Ø  Szerokie możliwości integracji z innymi aplikacjami

 

Ø  Brak możliwości tworzenia architektury systemu

Ø  Brak wsparcia dla zarządzania budżetem projektu

Ø  Brak możliwości badania jakości produktów cząstkowych

 

Źródło: Opracowanie własne

Wśród silnych stron na uwagę zasługują szczególnie trzy pozycje. Pierwsza to stosunkowo nowa możliwość wśród narzędzi produktów służących do zarządzania przedsięwzięciami, którą jest sposobność zastosowania zwinnych metod wytwarzania oprogramowania. W Rational Team Concet można wykorzystać szablony procesów opartych na metodach lekkich takich jak Scrum, które automatycznie wygenerują pewne elementy zgodnie z charakterystyką wybranego sposobu zarządzania. Stanowi to duże uproszczenie
i ułatwienie pracy nie tylko dla kierownika, ale również dla członków jego zespołu.

Drugą pozycją jest wspomaganie zarządzania rozproszonym zespołem. Otóż RTC pozwala na dostosowanie widoków portalu w taki sposób, aby każdy z członków zespołu miał stały dostęp do bieżących informacji i zdarzeń oraz mógł sprawdzić nad jakimi elementami są prowadzone aktualnie prace oraz jakie zmiany są wymagane. Istnieje również możliwość wymiany informacji w kontekście pracy, co pozwala na komunikację pomiędzy użytkownikami bez konieczności bycia w tym samym miejscu i czasie. To proste rozwiązanie jest bardzo nowatorskie wśród produktów tego typu.

Kolejnym dużym atutem RTC jest szeroki dostęp do materiałów pomocniczych, związanych z tym oprogramowaniem. W przypadku wystąpienia jakichkolwiek wątpliwości na temat posługiwania się aplikacją można zasięgnąć bezpłatnych publikacji, które są dostępne na stronach internetowych platformy Jazz. Można również skorzystać z porad specjalistów w przypadku nietypowych problemów. Szerokie wsparcie merytoryczne jakie oferuje IBM do swoich produktów, stanowi bez wątpienia bardzo duży atut dla zespołów korzystających z tych aplikacji.

Analizując stronę słabych stron Rational Team Concert można stwierdzić, iż wady są związane z brakami obsługiwania obszarów zarządzania: jakości, budżetu oraz wymagań.
Te mankamenty można jednak usunąć poprzez wykorzystanie szerokich możliwości integracyjnych programu. A mianowicie wszystkie programy grupy Rational są zbudowane na tej samej platformie (Jazz), co zapewnia szeroką paletę możliwości integracji wybranych aplikacji. Każdy z programów Rational obsługuje inne obszary w ramach zarządzania projektem, przykładowo do zarządzania jakością służy Rational Quality Manager, a obszar związany z wymaganiami obsługuje Rational Requirements Composer i Rational RequisitePro. Za pomocą łączenia tych aplikacji z RTC można w bardzo przystępny sposób wyeliminować wady RTC bez konieczności rozbudowywania samej aplikacji.

Podsumowując rachunek plusów i minusów Rational Team Concert, nie ulega wątpliwości, że posiada on bardzo wiele użytecznych cech, które pod względem zarządzania projektem stawiają ten program ponad konkurencyjnymi aplikacjami. Co więcej można stwierdzić iż, wady związane z samą obsługą i funkcjonalościami programu nie występują, natomiast jego braki można wyeliminować poprzez łączenie aplikacji z innymi programami, o czym traktuje następny rozdział niniejszej pracy.

Wyzwania dla współczesnego zarządzania projektami informatycznymi

Dynamicznie rozwijający się świat IT stwarza dla przedsiębiorstw nowe możliwości prowadzenia działalności gospodarczej, które mogą decydować o zdobyciu przez nie przewagi konkurencyjnej na rynku. Dlatego też firmy decydujące się na inwestycje związane z systemami informatycznymi stawiają coraz wyższe wymagania przed zespołami, które je wytwarzają. Aby sprostać tym wymogom kierownicy zespołów projektowych sięgają po lekkie metody zarządzania, które mają pomóc w dostarczeniu klientom tego, czego oczekują, w jak najkrótszym czasie. Niestety ich zastosowanie ma swoje mankamenty, szczególnie z punktu widzenia zamawiającego produkt, który może z tego względu wymuszać pewne trudne działania na stronie wykonawcy. Takimi wyzwaniami może być żądanie wyceny realizacji czy ustalenia planów i harmonogramów projektu.

Charakterystyka metod lekkich sprawia, iż ocena budżetu projektu może być bardzo problematyczna. Klient pomimo, że może dysponować pokaźnymi środkami finansowymi, może wymagać pewnego szacunku kosztów realizacji przedsięwzięcia. Nie jest to łatwe zadanie dla kierownika zespołu, nawet przy mnogości istniejących sposobów na ich estymacje. Zarząd naciskany przez sponsorów musi  podjąć decyzję o budżecie podpierając się jedynie wykonanymi prognostycznymi szacunkami, które często nie mają w rzeczywistości żadnego odzwierciedlenia. Błędy oceny kosztów wiążą się ze zmieniającymi się warunkami realizacji projektu jaki i z nieuwzględnieniem dodatkowych obciążeń z tytułu opóźnień, które występują w ok. 50% przedsięwzięć.[1]

Podobnie jak w przypadku budżetu jest również z budowaniem szczegółowych harmonogramów prac dla całego projektu. Klienci oprócz przedstawionego kosztorysu wymagają często rozpisanej koncepcji realizacji projektu, co stanowi najczęściej fikcję stworzoną na potrzeby sponsora.  Plany charakteryzują się tym, że im większy obejmują okres czasu, tym bardziej są niedokładne i trudniejsze do ułożenia. Największą precyzją planowania odznacza się wyłączenie najbliższa/następna faza projektu.[2] Dlatego realizacja ułożonego na początku przedsięwzięcia planu jest niemożliwa ze względu na nieprzewidziane przypadki, zmiany wymagań czy warunków pracy.

Kolejnym dużym wyzwaniem dla kierowników i zespołów projektowych jest częsta zmiana wymagań. Problem wynika z tego, że modyfikacje komponentów mogą zachwiać całą architekturą produktu. Zmieniony lub dodany na życzenie element może nie współgrać z pozostałymi komponentami. Ponadto pojawia się problem z ponownym przeorganizowaniem planów wydań czy też iteracji. Jak pokazuje jednak rzeczywistość projektów informatycznych żądanie zmiany wymagań przez klienta jest częstym procederem. Niestety nawet przy użyciu metod lekkich, dostosowywanie się do zmieniających się założeń co do systemu, jest bardzo kłopotliwe i stanowi przyczynę niepowodzeń wielu projektów.

Odbiegając nieco od wyzwań związanych z klientem, warto również wspomnieć o wyzwaniach dotyczących samego zespołu projektowego, który według pragmatyków IT  stanowi kluczowy czynnik sukcesu przedsięwzięcia.

Pierwszą kwestią jest dobór odpowiednich ludzi do zespołu. Jest to bardzo często duży dylemat dla kierowników projektu, gdyż jeden niewłaściwie dobrany człowiek może doprowadzić do porażki całego zespołu. Z tego powodu zaczęto coraz bardziej zaostrzać kryteria selekcji dla uczestników projektu. Oprócz wiedzy, kwalifikacji i umiejętności, kandydat musi posiadać również pewne określone cechy osobowości zgodne z wymogami danej roli w zespole.[3] Co ciekawe, aspekty charakterologiczne stoją w hierarchii ponad posiadaną wiedzą pretendenta na członka zespołu. Jest tak dlatego, gdyż cechy osobowe są stałe i nie można ich posiąść w szybkim czasie, natomiast brak wiedzy czy umiejętności można dowolnie uzupełniać. Tu pojawia się jednak problem, gdyż dokonanie pomiaru cech osobowościowych i dopasowania kandydata do roli jest bardzo trudne. Aby pomóc sobie w podjęciu decyzji, kierownicy wybierają ludzi na podstawie wykonanych testów psychologicznych. Pomimo tego proces ten jest nadal bardzo skomplikowany, zwłaszcza przy tworzeniu zespołu od samego początku.

Drugim problemem może okazać się decyzja o liczebności zespołu. Wg przyjętych standardów optymalna liczba osób to 5 lub od 10 do 15.  Większa liczba osób może prowadzić do obniżenia jakości produktu końcowego i występowania większej ilości problemów podczas trwania projektu (rys. 1.3.1). Może to wynikać z utrudnień komunikacji oraz problemami związanymi z zarządzaniem zbyt dużą grupą.

Rysunek 1.3.1 Wyniki projektów it w zależności od wielkości zespołu

Kolejnym bardzo trudnym wyzywaniem stojącym przed wieloma kierownikami projektów informatycznych jest zarządzanie zespołem wirtualnym. Łączy się to nie tylko z problemem braku możliwości spotkania „face to face”, ale również z różnicą czasową.[4] Stanowi to dużą przeszkodę w komunikacji, przesyłaniu informacji czy przekazywaniu narzędzi, co może prowadzić do nieporozumień, opóźnień, a co gorsza w konsekwencji do klęski projektu.

Uczestnicy projektów informatycznych wciąż szukają sposobów na sprostanie powyższym wyzwaniom. Pomocy wypatrują w dynamicznie rozwijającym się świecie IT, w którym powstaje wiele nowych technologii. One mają ułatwić zarządzanie i realizację projektów. W dalszej rozdziałach niniejszej pracy została zawarta odpowiedz w jaki sposób  i czy w ogóle mogą one wspomagać procesy zarządcze przedsięwzięć informatycznych.

[1] A. Bielewicz, opt. cit.

[2] R. Jones, opt. cit., str. 112.

[3] G. R. Heerkens, Jak zarządzać projektami?, Wydawnictwo RM, Warszawa 2003, str. 75

[4] Z. Szyjewski, Metodyki zarządzania projektami informatycznymi, Placet,  luty 2004

Pięć faz zarządzania projektami

pora na prace magisterskie o zarządzaniu projektami

[Będzie im poświęcone następnych kilka wpisów]

W tradycyjnym podejściu wyłaniamy pięć faz zarządzania projektami:

  • Inicjację
  • Planowanie
  • Wykonywanie
  • Nadzór
  • Zakończenie

Nie każdy projekt przechodzi przez wszystkie wymienione wyżej fazy. Może się zdarzyć, iż przedsięwzięcia będą przechodzić wiele razy przez tę samą fazę lub nie będą przechodzić przez nie w ogóle. Specyfika i przebieg każdego projektu jest bardzo odmienna, dlatego proponowany układ faz jest tylko pewnego rodzaju modelem postępowania.

W zarządzaniu projektami wyróżnia się nie tylko fazy, ale również i obszary zarządzania. Są one bardzo dokładnie opisane w książce PMBoK, która stanowi zbiór wiedzy pragmatyków i naukowców zajmujących się i rozwijających profesję zarządzania przedsięwzięciami. A mianowicie wyróżnia się dziewięć takich dziedzin[1]:

  1. Zarządzanie integracją (Poject Integration Management)
  2. Zarządzanie zakresem (Project Scope Management)
  • Zarządzanie czasem (Project Time Management)
  1. Zarządzanie kosztami (Project Cost Management)
  2. Zarządzanie jakością (Project Quality Management)
  3. Zarządzane zasobami ludzkimi (Project Human Resource Management)
  • Zarządzanie komunikacją (Project Communications Management)
  • Zarządzanie ryzykiem (Project Risk Management)
  1. Zarządzanie zamówieniami publicznymi (Project Procurement Management)

Podobnie jak fazy zarządzania, nie wszystkie obszary muszą być uwzględnione
w każdym projekcie. To kierownik zespołu w głównej mierze decyduje o zastosowaniu danego aspektu w przedsięwzięciu. Wybór ten jednak może determinować późniejszą porażkę bądź sukces całego projektu, dlatego bardzo ważne jest przeprowadzenie dokładnej analizy, które dziedziny zarządzania są istotne dla danego przypadku.

Jak ukazują badania nawet trafny dobór obszarów zarządzania nie jest wystarczający, aby projekt zakończył się powodzeniem. Zarządzanie projektem w ramach tych wybranych dziedzin okazuje się zbyt trudne dla części kierowników zespołów projektowych, co można zauważyć na zmieszczonym na następnej stronie wykresie.

Rysunek 0‑1 Przyczyny niepowodzeń projektów informatycznych

Źródło: The Standish Group

Z badań The Standish Group wynika, że aż 18% przedsięwzięć zakończyło się porażką z powodu słabego zarządzania. Taki sam wysoki wynik osiągnęło stawianie przed zespołem nierealnych do zrealizowania celów. Jak można zauważyć źródło tych dwóch najważniejszych determinant leży bezpośrednio u podstaw pracy wewnątrz-zespołowej kierownika i członków jego zespołu. Najmniej istotnymi przyczynami upadku projektu wydają się być czynniki całkowicie zewnętrzne, nie zależne od grupy projektowej.

Nie patrząc jednak na przyczyny, niepowodzenia projektów są niezwykle kosztowne. Wg przeprowadzonych analiz Gartnera straty ponoszone z tytułu źle przeprowadzonych lub niezrealizowanych projektów IT wynoszą około 600 mld USD rocznie.[2]

W celu uniknięcia porażki i jej wysokich kosztów, warto się zastanowić, co może podwyższyć prawdopodobieństwo sukcesu projektu. Tu przychodzą z pomocą kolejne badania, które ukazują determinanty powodzenia przedsięwzięć (tabela 1). Potwierdzają one przedstawione wcześniej analizy The Standish Group, gdyż stanowią ich odwrotność.

Tabela 1.1.1

Determinanty sukcesu projektu informatycznego

Determinanta Udział procentowy
Wsparcie wyższego kierownictwa – zarządu 18%
Zaangażowanie użytkowników 16%
Doświadczenie kierownika projektu 14%
Jasno określone cele biznesowe 12%
Zminimalizowany zakres projektu 10%
Standaryzacja infrastruktury aplikacyjnej 8%
Stabilne bazowe wymagania 6%
Formalna metodologia 6%
Rzetelna ocena 5%
Inne 5%

Źródło: K. Waćkowski, J. M. Chmielewski, Wspomaganie zarządzania projektami informatycznymi, Helion 2007, str. 18

Jak wynika z przedstawionych badań, sukces zarządzania projektem zależy w głównej mierze od ludzi, którzy zajmują stanowisko kierowników lub menedżerów projektów. Aż dwa spośród trzech pierwszych miejsc w tabeli zajmuje odmiana tej determinanty, którą jest wsparcie oraz doświadczenie osoby zarządzającej projektem.

Poza zarządem, zaangażowaniem w projekcie muszą się wykazać również użytkownicy. Brak wkładu tych najważniejszych decydentów potrafi położyć nawet najmniejszy projekt[3].

Sumując wyniki procentowe pierwszych trzech miejsc w rankingu, osiągamy 48%-owy wkład czynnika ludzkiego w powodzenie całego przedsięwzięcia.
Nie zgłębiając się jednak w specjalistyczne badania, a przeglądając dostępne pozycje
w prasie i najnowszej literaturze również dowiemy się, iż współcześni pragmatycy zajmujący się zarządzaniem projektami informatycznymi stawiają na zespół i ludzi, którzy
go tworzą.

Porównując dwa przedstawione badania warto zwrócić uwagę, iż i w jednej, i w drugiej analizie pierwsze miejsca są ściśle związane z rolą kierownika projektu. Istotę i rangę tej ważnej funkcji bardzo dobrze opisał Bartłomiej Łatka w artykule dla Biuletynu Finansów Publicznych. Autor tak przedstawia analizowaną kwestię: Zarządzanie projektami, jako dziedzina ściśle inżynierska daje do ręki kierownika projektu narzędzia pracy. Tymi narzędziami jest zestaw metodyk zarządzania wszystkimi aspektami przedsięwzięcia, algorytmów postępowania, szablonów dokumentacji, metod modelowania rzeczywistości, komunikacji z otoczeniem projektu. Ułatwia znakomicie organizowanie projektu, raportowanie jego postępów, rozliczanie – prowadząc niemal za rękę poprzez kolejne etapy, fazy, zadania, procesy obsługowe. Prawidłowo realizowana funkcja Kierownika Projektu daje ponadto gwarancję posiadania w każdym momencie pełnej informacji o stanie przedsięwzięcia, w tym o grożących mu ryzykach. Wszystko po to, aby zwiększyć przewidywalność projektu, obniżyć jego ryzyko, utrzymać budżet, harmonogram oraz optymalnie wykorzystać dostępne zasoby.

Jak podkreśla autor artykułu zarządzanie projektami jest dyscypliną specjalistyczną. Osoby trudniące się tą profesją decydują o dobrze odpowiednich narzędzi pracy. W gestii kierownika leży dobór metod zarządzania i dobrych praktyk, w taki sposób aby zminimalizować ryzyko niepowodzenia projektu. Zatem jednym z najważniejszych aspektów przed przystąpieniem do realizacji projektu, jest dobranie przez kierownika odpowiedniej metody i procesów zarządczych z uwzględnieniem następujących czynników:

  • Dojrzałość zespołu,
  • Wiedza i doświadczenie kierownika,
  • Dostępny czas na realizację projektu,
  • Złożoność i stopień innowacyjności projektu,
  • Zaangażowanie i dojrzałość klienta,
  • Rozproszenie zespołu

Sposób postępowania wybrany na podstawie wymienionych wyżej elementów musi być jasny i zrozumiały dla wszystkich członków zespołu. Każdy z użytkowników powinien dokładnie znać swoją rolę i pełnioną odpowiedzialność. Elementy te jednak mogą się różnić w zależności od rodzaju wybranej metody. Dla przybliżenia problemu w następnym podrozdziale zostały opisane kategorie metod zarządzania projektami.

[1] Project Management Institute, opt. cit., str. 37

[2] A. Bielewicz, Kiedy projekt zawodzi, Computerworld nr 07-2007, 30 października 2007.

[3] Przemysław Wysota, Nowe standardy otwartości, COMPUTERWORLD, październik 2007

Rodzaje przedsiębiorstw i ich funkcje

W gospodarce rynkowej występuje wiele rodzajów przed­siębiorstw, wyróżnianych ze względu na różne kryteria.

Mogą być one klasyfikowane ze względu na kryterium własności, rodzaje prowadzonej działalności, wielkość (skalę produkcji), po­zycję rynkową. formy zintegrowania zakładów, obszar geograficz­ny, rozwój technologii itp. Kryteria te są często mało precyzyjne. Stąd też i mało dokładne są podziały przedsiębiorstw na różne kategorie. Tak na przykład mało precyzyjny jest podział przed­siębiorstw w zależności od stopnia zmechanizowania i zauto­matyzowania, czyli podział na przedsiębiorstwa o niskim stopniu zautomatyzowania i wysokim stopniu zautomatyzowania (np. ela­styczne systemy produkcji, produkcja zintegrowana komputerowo) czy ze względu na skalę produkcji (wielkie, średnie i małe), czy też według rodzajów działalności, gdyż trudno spotkać przedsię­biorstwa zajmujące się wytwarzaniem tylko jednego produktu lub usługi, jako że coraz powszechniejsze jest zjawisko integrowania działalności gospodarczej z innymi rodzajami działalności. Mało precyzyjny jest także jeże podział przedsiębiorstw według pozycji rynkowej, tzn. na doskonale konkurencyjne, o ograniczonej konkurencyjności oraz mono­pole naturalne i sztuczne, oligopole i monopsony Najłatwiej jest klasyfikować przedsiębiorstwa według kryterium ora własności. Według tego kryterium mogą one stanowić własność pro indywidualną, być spółką cywilną (założoną na podstawie prawa cywilnego), spółką jawną, spółką z ograniczoną odpowiedzialnością, spółką akcyjną, spółką komandytową (zakładaną na pod- ind stawie prawa handlowego); przedsiębiorstwa mogą też być państwowe, spółdzielcze, komunalne, samorządowe i międzynarodowe.

PRZEDSIĘBIORSTWA – SPÓŁKI

Przedsiębiorstwa te stanowią zrzeszenie osób lub kapitału Powołane do prowadzenia działalności gospodarczej.

Wspólnicy na podstawie umowy zobowiązują się dążyć do osiąg­nięcia wspólnego celu poprzez podjęcie działalności wytwórczej, budowlanej, handlowej lub usługowej. Ze względu na formę prawną rozróżnia się rodzaje spółek: osobowe, kapitałowe, cywilne i handlowe

Spółki osobowe, to takie, które opierają swoją działalność na osobistej pracy wspólników, przy czym wspólnicy wraz ze spółką ponoszą pełną odpowiedzialność za jej zobowiązania. Wyróżnia się wśród nich: spółki cywilne, jawne i komandytowe. Spółki kapitałowe to takie, które opierają swoją działalność na kapitale wnoszonym w formie udziałów lub akcji. W spółkach tych wspól­nicy nie odpowiadają za zobowiązania spółki wobec wierzycieli, odpowiada za nie tylko spółka swoim kapitałem (oddzielonym od majątku wspólników). Spółkami kapitałowymi są: spółka z ogra­niczoną odpowiedzialnością oraz spółka akcyjna. Spółki cywilne są unormowane przepisami kodeksu cywilnego, zaś handlowe ­przepisami kodeksu handlowego. Do spółek handlowych zalicza się spółki: jawną, komandytową, z ograniczoną odpowiedzialno­ścią oraz akcyjną.