Wyniki wyszukiwania dla „reguły biznesowe” – Strona 15

W sądach i urzędach giną dokumenty, nie musi tak być

Zapewne nie odtworzy się oryginałów ale poświadczone, elektroniczne kopie można posiadać. Dlatego urzędom, i nie tylko, sugeruje rozważenie: zamiast walczyć z wdrażaniem mało tu skutecznych, kosztownych i długotrwałych we wdrożeniu, systemów obiegu dokumentów, wdrożyć porządne repozytorium dokumentów, archiwów elektronicznych. Łatwiej jej wdrożyć, są w znacznej części gotowe wymagania dostępne na stronach Archiwum Państwowego. Zarządzanie procesem przepływu dokumentów jest trudniejsze bo po pierwsze, wymaga powyżej wykonanej analizy, po drugie system workflow i tak wymaga dobrego repozytorium dokumentów.
Mając dobre archiwum zabezpieczymy lekko licząc 90% związanych z zarządzaniem dokumentami potrzeb bo:

mamy ich kopie w repozytorium
możliwe jest automatyczne monitowanie terminów właściwym osobom,
możliwe jest więc dekretowanie,
niemożliwe jest ukrycie tego, na jakim etapie (u kogo) jest dana sprawa i jak długo jest załatwiana.
Tak więc można … Czy ktoś chce mnie może przekonać, że w firmach dokumenty nie giną? Giną i to znacznie częściej niż w urzędach, więc pokory proszę w ocenie urzędów …

Czytaj dalej

Od czego zacząć wdrożenie

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.

Czytaj dalej

RACI, SIPOC i inne czyli modelowanie organizacji c.d.

Modelując jakąkolwiek firmę jakąkolwiek notacją warto projekt modelowania uzupełnić o jego pragmatykę, to jest o specyfikację wszelkich warunków tworzenia modeli. Opracowanie takiej dokumentacji wymaga ustalenia tych zasad, a także zdefiniowania słownika, skończonej przestrzeni nazw i definicji, która pozwoli jednoznacznie zaklasyfikować każde pojęcie z życia firmy do właściwego, i tylko jednego, elementu modelu. Projekt modelowania procesów to nie jest proste rysowanie tego co się dzieje. Tak powstają najczęściej nieprzydatne i kosztowne zarazem dokumenty.

Projekt modelowania procesów biznesowych to wnikliwa analiza całej organizacji, sposobu zarządzania nią i udokumentowania tego jak faktycznie powstaje w niej wartość dla klienta. Nie raz niestety odnoszę wrażenie, że w wielu projektach tego rodzaju duża wartość analizy i modeli biznesowych zostaje zastąpiona skomplikowanymi i nic nie wartymi diagramami.

Czytaj dalej

Nowa specyfikacja Business Motivation Model v.1.1 i modelowanie biznesu

Stosowanie analizy systemowej, modelowania oraz formalnych notacji do tworzenia modeli, powoduje, że wyniki analiz są daleko bardziej wiarygodne. Z reguły celem pracy analityka biznesowego czy projektanta jest opracowanie opisu rekomendowanego rozwiązania. Może nim być docelowy model organizacji czy też opis oprogramowania jakie należy dostarczyć (bo nie zawsze wytworzyć!). W procesie formalnej analizy systemowej (nie jest to analiza systemu informatycznego, to analiza dowolnego systemu), powstają modele, które testujemy. Taki model to najpierw hipoteza, a po weryfikacji, jest to opis rozwiązania (projekt tego co ma powstać). Idealną sytuacją była by taka, a której mamy narzędzia do modelowania każdej analizowanej dziedziny. W klasycznej inżynierii jest to rysunek techniczny i zasady obliczania wytrzymałości, sformalizowany system tworzenia schematów elektrycznych i elektronicznych i wiele innych (zależnie od dziedziny), notacje UML w inżynierii oprogramowania. W sferze zarządzania mieliśmy do niedawna biała plamę, teraz mamy już BMM czy ArchiMate. Moim zdaniem utrzymywanie, że można coś skutecznie analizować metodami nieformalnymi świadczy raczej o niewiedzy i braku kompetencji.

Czytaj dalej

Rentowność projektu czyli jego wizja i wykonywalność – należy planować

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%.

Czytaj dalej

CRM – jaką pełni rolę

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.

Czytaj dalej

Wymagania na oprogramowanie ERP a analiza przedwdrożeniowa – gdzie różnica?

Tak więc analiza wymagań to jest praca wykonana by opisać czego oczekujemy i dokonać wyboru. Analiza przedwdrożeniowa to praca wykonywana przez dostawcę, którego wybrano, w celu opracowania specyfikacji prac jakie należy wykonać by wdrożyć dany produkt. Dobrze wykonany model nie zawiera informacji nadmiarowych, które zawsze podnoszą koszt wykonania modelu a także nie raz stanowią zbędne ograniczenia. Użycie takiego modelu jako narzędzia wyboru systemu ERP jest bardzo skuteczne: wystarczy go rozesłać do dostawców i zapytać po pierwsze czy ich system pasuje do niego, jeżeli tak to ile kosztuje ten produkt rok po roku. Z takim modelem kupujący nie musi udowadniać, że jego oczekiwania mają sens (co nie raz zdają się podważać dostawcy) a dostawca musi zdeklarować, że jego produkt pasuje do modelu.

Czytaj dalej

Ten straszny diagram klas

Warto zwrócić uwagę na to, że diagram klas diagramowi nie równy, to samo narzędzie może posłużyć do dwóch różnych celów w tej samej dokumentacji. Widać także (mam nadzieję), że próba pokazania na jednym diagramie zarówno systemu pojęć jak i sposobu ich przetwarzania, jako informacji w systemach informatycznych, jest raczej błędnym podejściem. Wydaje mi się, że podejmowanie takich prób świadczy o niezrozumieniu różnicy pomiędzy systemem pojęciowym a modelem przetwarzania informacji. W szczególności gdy dotyczy to systemów obiektowych.

Czytaj dalej