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.
Dlaczego takich analiz wykonuje się mało? No cóż, nie są one w interesie dostawcy, który twierdzi, że jego system np. ERP jest "na pewno dobry". Po drugie wiele firm uznaje, że ich nie dotyczy ryzyko projektowe i pomijają analizy, a te są przecież niczym innym jak obniżeniem ryzyka niepowodzenia takich projektów. Pamiętajmy, że ponad 80% projektów wdrożeniowych w IT to projekty z silnie przekroczonymi budżetami i terminami, część z nich (szacuje się je na ok. 16%) to projekty zaniechane z tego powodu.
Każdy z Państwa sam musi sobie odpowiedzieć na pytanie: czy 20% budżetu jest warte tego by chronić pozostałe 80%.
Tak zwana kastomizacja to gwóźdź do trumny budżetu niejednego projektu, nie da się jej (tego dopasowania) wykonać małym kosztem. Dlaczego? Zmiany w gotowym, złożonym oprogramowaniu to projekt porównywalny czasem z jego wytworzeniem. Jedyne sensowne rozwiązanie w przypadku mniejszych budżetów to wybór gotowego produktu i "nie ruszanie" go, używanie takim jakim jest. Analiza wymagań w takim przypadku to koszt rzędu kilkunastu tysięcy złotych. Zakup gotowego, przeciętnie złożonego produktu, to kolejne kilkanaście tysięcy złotych. Jeżeli zrezygnujemy z "dostosowywania" (a pozwala na to skuteczna analiza i wybór produktu) to pozostaje koszt instalacji oprogramowania i przeszkolenia użytkowników.
Jeżeli nasze możliwości nie pozwalają na taki wydatek, można użyć standardowego oprogramowania, którego koszt to ok. kilka tysięcy złotych. Jednak należy się liczyć z tym, że to będzie "zwykły proszek".
Co mogę polecić małym i średnim firmom? No cóż, po takim artykule jak ten z Forbes'a odradzam po raz kolejny proces: wybieram dostawcę rozwiązań IT na bazie jego kompetencji, referencji i "piaru', dostawcą nazywającym siebie samego nie raz partnerem i integratorem rozwiązań. Polecam zdefiniowanie własnej, biznesowej wizji rozwoju, potem sprecyzowanie swoich potrzeb (np. poprzez zbudowanie własnego modelu działania), określenie potrzeb IT i na końcu dopiero wybór dostawcy produktu (oprogramowania), który wesprze realizację tak określonej wizji rozwoju. Należy też bezwzględnie pilnować, by to nasza wizja biznesu była realizowana a nie wizja dostawcy (ten ma swoją, pamiętajmy, że zysk dostawcy jest zawsze naszym kosztem!).
Dlatego hurtownie danych i tak zwane systemy Business Inteligence, wszelkie systemy wspomagania decyzji, to albo analiza historii albo prognozowanie oparte na modelach. Owszem analiza historii to także analiza korelacji ale to inny temat :). W kwestii marketingu lepiej jest, moim zdaniem, opracować model zjawiska, jednak do tego nie potrzebne są duże ilości danych a jedynie minimalny [[zestaw danych reprezentatywnych]] i to się nazywa zasadą ekonomii myślenia. Wielką zaś sztuką projektowania hurtowni danych dla systemów BI, nie jest samo gromadzenie danych a właśnie ich odsiewanie, dlatego systemy analityczne integrowane z systemami CRM bywają czasem bardziej szkodliwe niż pomocne.
nie wiem co to jest CRM ale mogę powiedzieć, że zarządzanie to określenie czego i od kogo oczekujemy, określenie swobód i ograniczeń każdemu pracującemu, określenie miar, których użyjemy do oceny spełnienia tych oczekiwań. Zarządzanie to ciągły proces, w którym menedżerowie, ustalając te swobody i ograniczenia kształtują środowisko pracy w organizacji tak, by możliwie najefektywniej spełniała ona swój cel: tworzyła wartościowy produkt dla klienta.
Wspomniany przez czytelnika na początku kontakt menedżer to nic innego, jak współdzielone dane o kontrahentach i dokumentach z nimi powiązanych. To dlatego bardzo często repozytorium dokumentów z metadanymi (w tym także powiązania dokument - kontrahent) wystarczą. Jeżeli chcemy dodatkowo usprawnić pracę z pomocą takiego repozytorium, powinno ono mieć funkcjonalność generowania zdarzeń powiązanych z dokumentami: fakt ich pojawienia się oraz zdefiniowanych, powiązanych terminów. Każde takie zdarzenie ma (może mieć) swoich subskrybentów. Skoro dane są przechowywane, system raportowy poda nam każdą pożądaną statystykę, na ich zaś podstawie można wyciągać wnioski co do wprowadzenia ewentualnych zmian w ograniczeniach. I pętla zarządzania się zamyka! A gdzie te śmieszne "przypływy dokumentów"? One są albo skutkiem ograniczeń, albo wymuszone przez procedurę albo efektem reguł biznesowych i kompetencji. Bez analizy tych zjawisk nie da się jednoznacznie opisać tak zwanych "przepływów dokumentów" bo tylko mała cześć z nich to efekt sztywnej procedury, którą faktycznie można opisać diagramem.
