Wyniki wyszukiwania dla „zarządzanie wiedzą” – Strona 10 – JZ IT Consulting Limited

Reguły biznesowe jako motor sterujący organizacji: fakty + definicje pojęć

Mapa (model) procesów oraz struktura organizacyjna, by były jednoznaczne, muszą być także zestawem zdefiniowanych pojęć. Musimy wiedzieć co znaczy słowo: przełożony, podwładny, komórka organizacyjna czy jej kierownik. Jeszcze większym wyzwaniem zdefiniowanie systemu pojęć dla mapy procesów (proces, czynność, zdarzenie, dokument…). Budowanie systemów pojęciowych spełniających powyższe warunki jest bardzo trudne dlatego dla modeli procesów biznesowych najlepiej wykorzystać gotowy model pojęciowy: jest nim notacja. Najlepiej obecnie opracowanym takim modelem pojęciowym jest gotowa notacja [[BPMN]]. Tworzenie własnych jest kosztowne (czas i wiedza osoby opracowującej) i bardzo ryzykowne (może się nie udać). Dlatego używanie dzisiaj własnych lub innych (np. dostosowywane profilami diagramy UML) jest w moich oczach nieracjonalnym podejściem.

Model pojęć specyficzny dla danej organizacji niestety musi powstać “od zera”, podobnie jak powiązana z nim specyfiakcja reguł biznesowych. Jest to trudne bo tworzenie przestrzeni nazw wymaga utrzymania niezależności poszczególnych definicji i spójności i zupełności całego ich systemu. Niedochowanie tych wymagań prowadzi do niepełności a nawet sprzeczności reguł biznesowych, które w końcu są budowane (odkrywane i dokumentowane) z pomocą tych pojęć. Zanim wiec zaangażujesz kogoś do modelowania własnej firmy, upewnij się, komu zlecasz tę pracę…

W bardzo dużym więc skrócie:

procesy biznesowe to faktyczny, widoczny sposób pracy firm (ludzi w nich zatrudnionych),
procesy to efekt funkcjonowania ludzi w środowisku ograniczeń,
należy poznać tych ludzi,
ograniczenia to: procedury, prawo, zarządzenia wewnętrzne oraz specyficzne dla firmy wewnętrzne normy zwane regułami biznesowymi,
opracowanie biznesowego modelu firmy wymaga zrozumienia i opisania tego co powyżej opisałem,
nie istnieje droga na skróty.
…

Czytaj dalej

Hej, Biznesie, to ma być dla biznesu czyli dla Ciebie!

Tak więc jest metoda, praktyka pokazuje, że sprawdza się. Praktyka pokazuje także, że niestety nie jest to łatwe (modelowanie biznesu metodami obiektowymi, tu niestety nie da się powiedzieć, że “nie święci garnki lepią”) dlatego powstały pewne zalecenia i wzorce projektowe. Należy je zrozumieć, nauczyć się stosować i stosować, co i tak nie zastąpi “projektowania” czyli twórczego pierwiastka w tym procesie. Dokładnie tak samo jak nie da się automatycznie tworzyć kodu programu, do tego potrzebni są (dobrzy) programiści.

Z przekorą powiem też, że nie wiem jak zwinność metod programistycznych ([[Agile Manifesto]]) miała by ten proces uzdrowić i uczynić lepszym (nadal uważam, że brak dokumentacji, w tym modeli, raczej psuje projekty). Podsumowując można by powiedzieć, że etapy tworzenia oprogramowania to:

Analiza biznesowa, której produktem są: model organizacji (CIM) oraz specyfikacja tego co ma powstać (PIM), to drugie to kompletne wymagania. Całość (sformalizowane modele) pozwala na przetestowanie czy tak określone wymagania spełniają potrzeby biznesu.
Wytworzenie oprogramowania polegające na: implementacji modelu PIM, rozwiązaniu problemów technicznych (wymagania niefunkcjonalne) oraz dostarczeniu i wdrożeniu.
Powyższe, tak udokumentowany projekt, pozwala także osiągnąć dodatkową korzyść: “wiedza organizacji” tkwi w modelu PIM i developer nie może jej przejąć bez zgody autora, Analityka Biznesowego i sponsora projektu (prawo autorskie).

Czytaj dalej

Słabości tradycyjnych metod wytwarzania IT – czy na pewno słabości?

A co mówią statystyki?

Analysts report that as many as 71 percent of software projects that fail do so because of poor requirements management, making it the single biggest reason for project failure?bigger than bad technology, missed deadlines or change management fiascoes. ( źr. Fixing the Software Requirements Mess CIO.com).

Parząc na powyższe (wytłuszczenie: w większości z ponad 71% złych projektów programistycznych, powodem kłopotów było złe zarządzanie wymaganiami, co czyniło większe szkody niż pozostałe powody, takie jak technologie, napięte terminy czy zarządzanie zmianami, razem wzięte). Tak więc zastanówmy się czy aby na pewno brak projektu i specyfikacji wymagań to dobry sposób na projekt IT. Czy metody wytwarzania bazujące na braku pierwotnego projektu, faktycznie są zbawieniem projektów programistycznych… Dodam na koniec, że powyższe dotyczy w takim samym stopniu systemów dedykowanych jak i gotowych a wymagających “kastomizacji” bo to (nowe funkcjonalności systemu) także projekt dedykowany.

Czytaj dalej

Wymagania na system ERP – co ma do tego M.E.Porter i rok 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…

Czytaj dalej

Ach ten wstrętny, wścibski analityk

Cóż, zastąpienie procesu analizy i projektowania werbalną komunikacją to droga na skróty: czerwona strzałka. Czy to zła droga? Droga na skróty to wspomniane na początku ryzyko, ogromne bo statystyki wskazują stale, że ok. 70-80% projektów programistycznych ma poważne kłopoty. Statystyki te są takie same od lat.

Od lat znany jest powyższy proces i mimo to zawsze jest te 80% klientów i ich dostawców, którzy dogadują się, że analiza i projektowania żadnemu z nich nie służy… tak jak to napisano na początku.

Po co to napisałem? By każdy z Państwa sam, świadomie, oceniał ryzyko swoich projektów. Rezygnacja z analizy i projektowania to podjęcie pewnego ryzyka, przez klienta. Niestety rezygnacja z analizy i projektowania ze strony dewelopera to czasem dodatkowo skutek uznania, że analiza i projektowanie leży poza kompetencjami programistów (Ci obiektowo kodują) wiec wybierają jest droga na skróty.

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

IIBA czyli “jak to niektórzy robią w Ameryce”

Dlaczego tak często projekty łamią zasady rozsądku i zarządzania ryzykiem?

Wczoraj na sali i w kuluarach padły między innymi takie odpowiedzi:

dostawcy oprogramowania bardzo często nie potrafią takiej analizy wykonać bo nie mają wymaganych kompetencji, ale potrafią programować i tylko na to się godzą.
dostawcy oprogramowania doskonale wiedzą, że istnieje ryzyko że ich produkt nie spełnia wymagań więc bardzo często nie dopuszczają do takich analiz forsując od razu wdrożenie (wręcz tępią w projektach zewnętrznych analityków!).
klienci mają stale do czynienia z dostawcami a bardzo rzadko z niezależnymi analitykami i bardzo często przyjmują wiarę w to co mówią dostawcy.

Czytaj dalej

Co wybrać czyli cykl życia projektu tworzenia oprogramowania

Zbiegły się dwa fakty: gorąca dyskusja na forum na temat umiejętności programistów i przy okazji ich roli w procesie wytwarzania oprogramowania oraz przesyłka z kolejną nową książką na moja półkę. Ale po kolei. Najpierw fazy cyklu wytwarzania oprogramowania a potem kilka uwag. Zakupiona książka opisuje całość, ja tu skupie się na jej wstępie. Nie będę jej tłumaczył a jedynie opisze idee. Zwrócę także uwagę na pewne aspekty związane z dostarczaniem gotowego oprogramowania, np. systemów typu ERP lub ich komponentów.

Czytaj dalej