W 2006 r. rynek oprogramowania dla małych i średnich przedsiębiorstw (MŚP) ponownie wzrósł. Jego wartość wynikająca z funkcjonowania ponad 210 firm producentów oprogramowania zwiększyła się zarówno w sektorze małych, jak i średnich przedsiębiorstw. Wzrosty te dla sektora MŚP ogółem oznaczały w 2006 r. dynamikę złotówkową równą 14,6%.
Właśnie otzrymałem mail: Szanowni Państwo, w imieniu Konsorcjum Koordynującego Narodowy Program Foresight Polska 2020 pragnę serdecznie podziękować za zainteresowanie Programem i wypełnienie ankiety rekrutacyjnej do Zespołu Ekspertów Zewnętrznych Narodowego Programu Foresight 2020. Mam również przyjemność poinformować, iż proces rekrutacji został w Państwa przypadku zakończony pozytywnie. Serdecznie witamy w gronie Ekspertów Zewnętrznych Narodowego Programu Foresight Polska 2020. Jacek Szut Research Executive Pentor Research International Koordynator ds. Promocji Narodowego Programu Foresight Polska 2020 Co to jest Foresight Polska 2020 Program realizowany jest przez Konsorcjum Koordynujące, wybrane w drodze konkursu, w składzie: Instytut…
Jeden z pracowników moich klientów, duży developer powiedział, że firma i to co się w niej dzieje jest tak skomplikowana, że nie wyobraża sobie bo można to było opisać lub narysować. Powiedziałem, że można, należy jednak po pierwsze przyjąć pewien poziom szczegółowości opisu sensowny z perspektywy człowieka (model to uproszczenie) oraz podzielić problem na kawałki... dyskusja nie miała końca. Mój projekt dobiegł końca i okazało się, że udało się opisać nie małą firmę w ciągu miesiąca, modelem na kilkudziesięciu stronach. Jak?
A jednak jak to mówią "nigdy nie mów nigdy". Postanowiłem napisać o SaaS (Software as a Service, ang. Oprogramowanie jako Usługa) mimo wcześniejszych deklaracji, że nie będę tego tematu poruszał, ale tu w nieco innym kontekście. Dlaczego? Bo jednak nie potrafię słuchać tłumaczenia: "SaaS jest dobre dla firm bo jest dobre". Ja oczywiście zawsze jestem uciążliwy i pytam "Dlaczego dla mnie jest dobre"? Tłumaczenie, że "Dzierżawione jest lepsze i tańsze" od razu nasuwa mi pytanie "To dlaczego dostawcy SaaS nie są jeszcze milionerami?" A jak chcę skopać leżącego to pytam jeszcze o rentowność (dla mnie, nie dla niego).
Artykuł opisuje drugi, po przypadkach użycia i modelu dziedziny systemu, aspekt opisu wymagań: zachowania systemu. Nie jest to proste biorąc pod uwagę różnorodność problemów: obiekty stanowe (np. dokumenty, ludzie), współbieżność i transakcyjność i wiele innych. Opisanie tekstem w sposób jednoznaczny tych elementów wymagań jest praktycznie nie możliwe. Za pomocą diagramów: sekwencji, komunikacji, aktywności, maszyny stanów, czy przebiegów czasowych możliwe jest przekazanie opisu budowy systemu np. programistom będąc niemalże pewnym, że napiszą kod taki jaki chciał projektant mimo, tego, że nie będzie go w tym procesie kodowania.
Kolejna ślepa uliczka jaką dostrzegam w reklamach systemów klasy workflow to wskazywanie jako głównej korzyści ich wdrożenia narzucenie ścisłej kontroli poczynaniom pracowników. Nie znam przypadku wdrożenia systemu zakończonego sukcesem, którego głównym celem było kontrolowanie pracowników wbrew ich woli. Typowym przykładem są różnego typu restrykcyjne systemy kontroli czasu pracy czy kontroli pracy przy komputerze, nadzór urzędnika tą metodą także się nie sprawdza. Lepszy jest moim zdaniem system informatyczny zaprojektowany tak by pomagał pracownikom osiągać ich cele. On niejako wdraża się sam. Systemy kontroli i restrykcji, nawet jeżeli udaje się je wdrożyć, są bardzo kosztowne i często bojkotowane przez ludzi.
Nie szukać systemu który ?pasuje do nas? bo raczej żaden od razu nie pasuje. Ostrożnie podchodzić do ?dobrych praktyk? i ?modeli referencyjnych?. Zgodnie z zasadą: Jeżeli w dwóch różnych firmach, nawet w tej samej branży, funkcjonuje taki sam model biznesowy i procesowy to w jednej z nich na pewno jest zły! System informatyczny powinien pozwolić obsłużyć nasze wymagania (procesy) ale nie procedury. Procedury tworzy się w tracie wdrażania.
Przetwarzanie informacji to tabele te zaś są prozą życia menedżerów :). Podczas wielu projektów związanych z kolekcjonowaniem wymagań na system IT wielokrotnie pojawiał się problem raportów i podobnych działań. Bardzo często wymagania tego typu są specyfikowane za pomocą wzorów raportów. Ma to jednak poważną wadę: zamyka lub utrudnia drogę rozwoju tej funkcjonalności (nie licząc usług płatnego definiowania kolejnych typów raportów świadczonych przez wykonawców systemów). Raporty jednak to tylko wierzchołek góry lodowej, "pod wodą" są dane i ich model czyli sposób zarządzania nimi i ich postać.
Moim zdaniem stopień wykorzystania technologii wspierających przetwarzanie informacji jest w sektorze przemysłowym największy z uwagi na stopień komplikacji większości procesów produkcyjnych. Trudno jest ocenić o ile więcej bo chyba nikt takich badań nie prowadził. Moim zdaniem każdą firmę można podzielić na podobne obszary jednak ile by ich nie było tylko firmy produkcyjne będą miały obszar produkcji. Firmy handlowe, usługowe, logistyczne niewątpliwie mają skomplikowane procesy biznesowe jednak nie odbiegają one w swej istocie zbytnio od tych w firmach produkcyjnych. Systemy informacyjne specyficzne dla produkcji są natomiast niszą na rynku właśnie z uwagi na ograniczony rynek na nie (tylko firmy produkcyjne) dlatego dodatkowo są kosztowniejsze.
Zostałem zaproszony na tę konferencję zarówno jako patron medialny (jako wydawca serwisu IT-Consulting.pl) oraz jako ekspert. Wydaje mi się, że to jedna z ciekawszych konferencji jakie się odbywają w naszym kraju w tej branży gdyż gromadzi z jednej strony czołowe kadry naukowe a z drugiej przedstawicieli liczących się podmiotów na rynku i przedstawicieli instytucji rządowych czyli jednego z największych beneficjentów technologii ICT (ang. Information and Communication Technology). Poniżej moje refleksje z wybranych referatów. Pominięcie niektórych z nich to efekt mojego pewnego subiektywizmu w ich ocenie, starałem się zwrócić uwagę na pewne wybrane aspekty związane z obszarem moich zainteresować i mam nadzieję czytelników portalu. Dla porządku zamieszczam na końcu artykułu pełną listę referatów i ich autorów.
Osobą odpowiedzialną za system IT zawsze będzie zamawiający. Dlatego zamawiający powinien jednoznacznie opisać swoje oczekiwania i zrozumieć potem odpowiedź czyli propozycję ich wykonawcy. Menedżer nie musi uczyć się diagramów UML ale powinien rozumieć modele procesów tak by mieć możliwość ich oceny i zatwierdzania. Dlatego modele procesów powinny być tworzone metodami zrozumiałymi dla menedżerów, moim zdaniem nie jest to notacja UML. Notacja ta jednak jest niewątpliwie doskonałym narzędziem do udokumentowania i przekazania swoich oczekiwań przyszłemu wykonawcy systemu: integratorowi IT. Tak więc wykonaj model procesów biznesowych, określ które procesy chcesz informatyzować. Potem przygotuj na bazie tej analizy listę przypadków użycia przyszłego systemu, uzupełnij ją o model pojęciowy twojego biznesu i firmy i przekaż to do realizacji wykonawcy systemu. Na koniec pozostaje wdrożenie a to już osobny projekt :), socjologiczny.
Model to przede wszystkim narzędzie analityczne i komunikacyjne. Analityczne bo model powinien bez potrzeby kontaktu z pierwowzorem zachowywać sie tak jak on (w wybranym kontekście oczywiście). Komunikacyjny bo powinien być zrozumiały dla osoby nie biorącej udziału w jego tworzeniu. Po trzecie model powinien odwzorowywać istotę badanego zjawiska a nie kopiować jego poboczne cechy lub opisywać nie wnoszące nic do badania informacje oczywiste lub wręcz zaciemniające istotę problemu. Model wieży Eiffla do celów zbadania oporów powietrza nie musi zawierać informacji o kolorze i o tym ile schodów należy pokonać by na nią wejść. Na tej samej zasadzie rysowanie na diagramie faktu, że np. dokument jest komukolwiek przekazywany z ręki do ręki jest rysownictwem a nie modelowaniem.
