Inżynieria systemów oparta na modelach (MBSE) jest sformalizowaną metodologią, która jest używana do wspierania wymagań, projektowania, analizy, weryfikacji i walidacji związanych z rozwojem złożonych systemów. W przeciwieństwie do inżynierii skoncentrowanej na dokumentach, MBSE stawia modele w centrum projektowania systemu. Zwiększone przyjęcie środowisk modelowania cyfrowego w ciągu ostatnich kilku lat doprowadziło do zwiększonego przyjęcia MBSE. W styczniu 2020 roku NASA odnotowała ten trend, informując, że MBSE “jest coraz częściej przyjmowane zarówno przez przemysł, jak i rząd jako sposób na śledzenie złożoności systemu.” W tym wpisie na blogu przedstawiam krótkie wprowadzenie do MBSE.
Wyniki Megapanel PBI/Gemius za maj 2011
Polskie Badania Internetu Sp. z o.o. (PBI) i firma badawcza Gemius SA, współpracujące w zakresie realizacji badania ?Megapanel PBI/Gemius? ? standardu pomiaru oglądalności witryn i aplikacji internetowych w Polsce, opublikowały wyniki za maj 2011. (Wyniki_Megapanel_PBI_Gemius_maj_2011).
Pierwsze trzy pozycje oglądalności stron to kolejno od najlepszej: grupa Google, grupa Onet, grupa Wirtualna Polska - Orange. W tym grupa NK.pl na pozycji 7., Facebook na pozycji 9., grupa Wikipedia na pozycji 11., Microsoft na pozycji 14. więc jak widać nasza rodzima NK dobrze się trzyma, szkoda, że nie ma charakterystyki odwiedzających... Prawdę mówiąc zaskakuje mnie pozycja Microsoftu, czy jest to wyniki klikana w Pomoc w środowisku Windows czy też realne zainteresowanie produktami.
Łańcuch wartości M.E.Porter (Competitive Advantage, 1985)
Podejście takie jest stosowane. Badania pokazują, że liderzy rynku, bez względu na branżę, to firmy dobrze zarządzane a nie te, które najwięcej wydały na IT. Podejście to wymaga dużej odwagi i samodzielności, ignorowania tak zwanych modeli referencyjnych (bo te są dobrymi praktykami a nie czymś co należy skopiować), owocuje jednak sukcesami. Niestety często zdarza się, że wdrożenie systemu ERP niszczy przewagę firmy, gdyż nowa technologia zamiast ją umocnić niszczy kompromisami i kopiowaniem modeli innych firm (nie raz konkurentów) wszystko to co odróżniało ją od innych.
Za zakończenie polecam gorąco drugą ksiązkę Portera: [[Porter o konkurencji, Michael E. Porter, PWE, Warszawa 2001]]. W tej znajdziemy zbiór dziewięciu artykułów na temat budowania konkurencji i jej utrzymaniu. W szczególności warto poznać artykuł "[[W jaki sposób informacja wpływa na przewagę konkurencyjną]]". Pięć zasad, które mogą pomóc w budowaniu przewagi na bazie informacji, odsyłam do książki , warto. To przyczynek to napisania kilku słów o systemach wspomagania decyzji ale to inny temat, nie ERP...
Użycie modelu jako narzędzia wyboru systemu ERP jest bardzo skuteczne - wystarczy go opisać dodatkowo zakresem projektu i rozesłać do dostawców i zapytać czy ich system pasuje do modelu oraz ile ten produkt kosztuje rok po roku. Jednocześnie dobrze wykonany model organizacji nie zawiera informacji nadmiarowych, które zawsze podnoszą koszt jego wykonania, a często stanowią zbędne ograniczenia. Dobry model powstaje z użyciem standardów i dobrych praktyk. Do typowych standardów należą: notacja BPMN (Business Process Modeling Notation), UML (Uniefied Modeling Langualge), AchiMate/TOGAF, Siatka Zachmanna, Business Motivation Model. Do dobrych praktyk np. wzorce projektowe czy zalecenia Business Rules Group. Zachęcam do zakupu całego wydania COMPUTERWORLD Aplikacje Kompendium ERP Czerwiec 2011.
Fowler pyta o to, o co wielu wielu informatyków: czy dostarczenie firmie kolejnych nowych możliwości, powinno się realizować poprzez napisanie (tworząc dedykowane) potrzebne nowe oprogramowanie, czy poprzez zakup gotowego oprogramowania. Ogólnie opinia, zalecane podejście przez Fowlera to: jeżeli proces wymagający wsparcia nowym oprogramowaniem, to proces kluczowy dla utrzymania konkurencyjności lepiej stworzyć oprogramowanie dedykowane do tego procesu. Jeżeli to jeden z procesów pomocniczych, efektywniej będzie kupić gotowe oprogramowanie i dostosowanie do niego procesu w firmie. Co ciekawe, podobnie jak ja, zaleca w przypadku gotowego oprogramowania dostosowanie się do niego a nie dostosowywanie oprogramowania do siebie.
Opisywane tu nie raz metody bazujące na modelowaniu przyszłego systemu (jego logiki biznesowej) i testowaniu czy model pozwala na spełnienie celu biznesowego dają oszczędności nawet 50%, a bywa, że znacznie większe, jeśli okaże się, że uniknięto zakupu jakiegoś zbędnego oprogramowania lub modułu. Koszt dobrze opracowanej analizy z dużym zapasem pokrywają oszczędności wynikające z braku wielu prototypów.
Podsumowując: analityka zawsze warto zatrudnić, poprzedzając to kontrolą tego co wytworzy. Dobry analityk zawsze wyceni projekt jako umowę o dzieło o konkretnym terminie i koszcie. Projekty w rodzaju czas i materiał to projekty w rodzaju " na początku nikt nic nie wie". Warto je robić tylko w przypadkach, gdy tej wiedzy faktycznie nie ma, spodziewamy się systemu o wartości setek tysięcy złotych lub kosztowniejszych i zainwestowanie nawet kilkudziesięciu tysięcy w analizę, która pozwoli oszacować ryzyko wydania tych kilkuset, może mieć sens. W takich przypadkach i tak ustalamy próg kosztów, przy których uznamy, że dalsze prace już niczego nowego nie wniosą.
A na koniec, analiza trwająca kilka czy kilkanaście dni roboczych, zakończona kilkudziesięcioma stronami tekstu i tabelą na setki pozycji wymagań w niczym nam nie pomoże.
