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.
Poprawny model organizacji, w szczególności mapa procesów biznesowych, powinien opisywać tylko przedmiot analizy np. specyfikę organizacji będąca np. źródłem jej przewagi konkurencyjnej i to jak organizacja tę specyfikę tworzy. Model powinien się odwoływać do innych istniejących już dokumentów, np. zakresu kompetencji pracownika czy instrukcji stanowiskowej. Model zawsze powinien mieć jakiś cel swojego powstania i kontekst.
Zarządzanie zasobami ludzkimi, bo tak często nazywane jest ostatnio to coś, kojarzy mi się z przedmiotowym podejściem do ludzi. Jakkolwiek ludzie to zasoby ale jednak żywe i jedyne obdarzone inteligencją, bo w sztuczną jednak nadal nie wierzę. Wsparcie zarządzania tymi zasobami powinno więc moim zdaniem bazować na tej inteligencji a system wspierający zarządzenie zasobami powinien, moim zdaniem, z tej inteligencji korzystać. Postanowiłem opisać moje wrażenia i pomysły na coś co w firmach nazywa się wspomaganie działu HR (Human Resources) i informatyczne wsparcie tego procesu. Nie będzie to opis żadnego dostępnego…
Wakacje spowodowały u mnie mały zator prasy dlatego postanowiłem napisać kilka słów o tym co w całej kupce a nie o tym co pojedynczym numerze. Od pewnego czasu jestem czytelnikiem miesięcznika Software Developer's Journal (SDJ). Co prawda jestem analitykiem a nie np. koderem ale w końcu niektóre projekty i UML'owe obrazki piszę dla koderów właśnie a dobrze jest znać swojego "klienta" i jego potrzeby. A co znajdziemy w numerach z Czerwca, Lipca i Sierpnia? Kilka ciekawostek
Moda na procesy, zarządzanie zorientowane procesowo, outsourcing procesów biznesowych itp. to nie moda. Moim zdaniem to kolejny etap zrozumienia tego co się wokoło nas dzieje bo w sadzie nie ma procesu procesowego. W sądzie ma miejsce proces dochodzenia do poznania prawdy i wydania sprawiedliwego sądu.
[toc] Usługi na sztuki czy kompleksowe pakiety SOA moim zdaniem zagroziło zintegrowanym systemom np. ERPII i nie tylko. Pojawiło się światełko w tunelu dla szybko wdrażanych aplikacji na życzenie z jednoczesną możliwością oceny ich rentowności. SOA: usługi na miarę, system jak ulał Service Oriented Architecture (ang. Architektura Zorientowana na Usługi) to idea tworzenia systemów informacyjnych w postaci niezależnych komponentów. Każdy komponent to obiekt ze ściśle zdefiniowaną funkcjonalnością. Celem każdego komponentu jest wsparcie konkretnego procesu biznesowego. O jakie procesy chodzi? Tu wagi nabiera modelowanie procesów zorientowane na produkty. Projektowanie tego typu…
Wiele firm mówi o mapowaniu procesów a opisuje tylko procedury i zasoby. Nie chcą czy może nie potrafią? Wiele firm oferujących usługi doradcze, nawet te uznane na rynku, myli mapowanie i modelowanie procesów biznesowych z odzwierciedlaniem stanu organizacji pracy firmy w postaci procedur i opisu przepływu pracy. Pominięcie etapu opisu modelu firmy jeszcze w oderwaniu od systemu informatycznego jest moim zdaniem głównym powodem niepowodzeń wielu projektów. Obecnie stale spotykam się z modelami wykonywanymi przez inżynierów systemowych zamiast analityków biznesowych. Używają oni do tego celu narzędzi do obiektowego modelowania elementów systemów…
