Proste zarzÄ…dzanie projektami

Ostatnio interesowałem się wystawianiem faktur. Jest kilka programów, pytałem znajomych księgowych i studentek rachunkowości o rodzaje faktur, rodzaje podatków jakie trzeba zapłacić do urzędu skarbowego o rodzaje faktur, vat, podatek należny i naliczony. Jest klika naprawdę dobrych programów takich jak cdn słaba optima itp. Na prawdę dobry dla mnie okazał się program do wystawiania faktu www.infakt.pl. Ma on wszystkie cechy dobrego programu, jest szybki i bezpieczny. Polecam serdecznie.

Natomiast firmy oczekują, że wykorzystywane przez nie aplikacje będą w pełni dopasowane do modelu biznesowego, czyli będą odwzorowywały obecną strukturę logiczną biznesu, rozwijały się wraz z przedsiębiorstwem (elastyczność) itd. Dodatkowym elementem komplikującym strukturę środowiska informatycznego są fuzje i przejęcia. Naruszają one jego heterogeniczność, gdyż wchłonięte przedsiębiorstwa wnoszą własne aplikacje i dane, które trzeba integrować z istniejącymi. Wprowadza to nadmiarowość systemów oraz utrudnia jednolitą obsługę klienta. Niespójne, powielane i pofragmentowane dane powodują sprzeczność w raportach biznesowych. Wszystko to sprawia, że technologia zaczyna ograniczać rozwój biznesu, zamiast w nim pomagać. Praktyczną i wydajną metodą rozwiązania tego problemu jest koncepcja integracji ukierunkowana na usługi, czyli właśnie SOA.

Część z nich była tworzona przez informatyków pracujących w firmie, później rozbudowywana już przez inne osoby. Wybrane aplikacje były natomiast zakupione od podmiotów zewnętrznych, w tym część z nich była profilowana do konkretnych, indywidualnych potrzeb, niektóre były wdrażane w standardowej formie. W efekcie w przedsiębiorstwach funkcjonuje niejednokrotnie kilkanaście, czasami kilkadziesiąt aplikacji, które powstawały w różnym okresie, więc są oparte na różnorodnych technologiach, czasami wykorzystują platformy systemowe, które nie są już wspierane i rozwijane przez producentów. Autorzy tych aplikacji nie zawsze też pozostawili lub stworzyli kompletną dokumentację. Wreszcie, wykorzystywane systemy są ze sobą niekompatybilne i dla zapewnienia komunikacji pomiędzy nimi trzeba pisać kolejne aplikacje i skrypty. Utrzymanie tak stworzonej architektury jest niezmiernie kosztowne, a przede wszystkim niefunkcjonalne, co wcale nie oznacza, że aplikacje te są złe, wręcz przeciwnie, wiele z nich idealnie odwzorowuje procesy biznesowe poszczególnych działów czy jednostek.

Korzyści, które przynosi wdrożenie architektury ukierunkowanej na usługi, to zmniejszenie kosztów dzięki wielokrotnemu wykorzystaniu usług (aplikacji, modułów itp.). Jedyną trudnością, jaką napotyka ta idea, jest konieczność zmiany myślenia o sposobach projektowania, wdrażania i zarządzania aplikacjami. Aby lepiej zrozumieć istotę problemu, warto zacząć od analizy procesu powstawania i wdrażania użytkowanych obecnie w większości polskich firm aplikacji.

SOA to architektura, w której są budowane, wdrażane i zarządzane usługi, mające zapewnić sprawniejsze funkcjonowanie infrastruktury IT oraz pełniejsze odwzorowanie biznesu poprzez szybką reakcję na zmieniające się wymagania. Zatem im bardziej dynamicznie jest prowadzona dana działalność, tym większe korzyści można osiągnąć dzięki implementacji SOA.

Zgodnie z opublikowanymi niedawno w Stanach Zjednoczonych badaniami IDG Research Service Group, specjaliści IT są podzieleni niemal równo pomiędzy tych, którzy twierdzą, że tematykę SOA znają dobrze bądź dość dobrze, a tych, którzy deklarują, iż nie mają o niej pojęcia. Najprawdopodobniej wyniki uzyskane w innych krajach, w tym w Polsce, okazałyby się zbliżone do grupy drugiej (lub z przewagą do niej). Z tego powodu wiele firm czy instytucji nie zdaje sobie sprawy, że wdrożyło już część architektury SOA, a do uzyskania istotnych korzyści biznesowych nie jest potrzebna inwestycja na ogromną skalę i rewolucja systemowa. Wystarczy, że krok po kroku będą one realizowały strategię, którą i tak już wprowadzają w życie.

SOA - ten termin pojawia się coraz częściej w tematach konferencji, tytułach artykułów prasowych, dyskusji, paneli, w rozmowach prowadzonych przez CIO. Mimo to jest nadal pojęciem dość mglistym, którego źródło jedni widzą w integracji aplikacji, a inni w rozwoju Web Services.

Określenie miar wyniku to kolejny krok uzgodnień, które zasadniczo toczą się w zespole projektowym, ale bezpośred­nio dotyczą klientów. Rzecz w tym, by rozpoznając ich wy­magania i oczekiwania precyzyjnie określić, co to znaczy: osiągnąć cel i sformułować standardy konkretyzujące jego
pojęcie.

Podobnie jak w fazie uruchamiania projektu, podczas pla­nowania należy ciągle badać wykonalność przedsięwzięcia. Ponieważ planowanie dotyczy przyszłości, zatem zawsze wiąże się z wykorzystaniem niekompletnych lub niepewnych informacji — zawiera więc w sobie element ryzyka. Dodat­kowo warto zauważyć, że to właśnie faza planowania prze­sądza o 75% kosztów, które zostaną poniesione w trakcie realizacji projektu. Dlatego też, bez opracowania pełnego pla­nu projektu nie należy przystępować do kolejnej fazy czyli
do realizacji.

Podstawą planowania powinno być rozpoznanie zadań (co trzeba zrobić?), a dopiero w dalszej kolejności właściwe podejście metodyczne (jak zrobić?).