Reguły biznesowe – projekt zabija ich bezsensowna ilość…

Bardzo często spotykam się z ogromną złożonością (liczba i ich podziały) wymagań. Problem tkwi nie raz w tym, że "narosła" przez lata "sterta zarządzeń", która zamiast zostać najpierw uporządkowana, jest "wprost" traktowana jako "wymagania". Takie podejście to krok w stronę klęski projektu. Procesy biznesowe są konsekwencją między innymi reguł biznesowych. Większość zarządów firm nie ma na półkach regałów map procesów, a firmy działają. Jednak każda firma ma zarządzenia Zarządu i to one tak na prawdę kształtują "procesy biznesowe". Podobnie jak np. w muzeach: mamy duże sale i wiele możliwości przejść przez nie. Co decyduje o tym, jaką drogę przejdziemy przez sale pełne eksponatów? Linia na podłodze? Nie! Barierki! Czym one są? To ograniczenia! Zarządzenia Zarządu stwarzają ograniczenia, ich konsekwencją są takie a nie inne procesy biznesowe. Dlatego zrozumienie i uporządkowanie reguł biznesowych jest ważne, a nie modelowanie procesów. Te są ich skutkiem. Modelowanie procesów to odkrywanie ścieżek wyznaczonych ograniczeniami. Jeżeli jednak pozwolimy utrzymać opisany bałagan to modele procesów biznesowych (ścieżki postępowania) przybiorą postać zawartości monstrualnego talerza spaghetti. A tak na prawdę polecam wystawę w Zamku Królewskim (Warszawa): Polska za czasów Jagiellonów oraz drugą: Historia krzyża Maltańskiego.

Czytaj dalejReguły biznesowe – projekt zabija ich bezsensowna ilość…

Koszmar każdego szefa: gdy nagle znikają wszyscy kluczowi pracownicy

Najpierw pewien nagłówek i cytat: Koszmar każdego szefa. Jak zarządzać firmą, z której nagle znikają wszyscy kluczowi pracownicy? Taki scenariusz to dramat dla każdego szefa. Wyobraź sobie, że rządzisz firmą, z której nagle znika 25 kluczowych pracowników. Kiepsko, prawda? (Koszmar każdego szefa. Jak zarządzać firmą, z której nagle znikają wszyscy kluczowi pracownicy | NaTemat.pl). To chyba będzie pierwszy przypadek, gdy odradzam czytanie artykułu, z którego pochodzi cytat, gdyż dyskusja polityczna jest ostatnią rzeczą, jakiej tu oczekuje (i ostrzegam, będę moderował takie wpisy ;)). Kluczem jest sam ten cytat oraz to, że…

Czytaj dalejKoszmar każdego szefa: gdy nagle znikają wszyscy kluczowi pracownicy

Procesy referencyjne czyli kto żyw niech ucieka

Na pewnym wysokim poziomie abstrakcji można mówić o procesach referencyjnych, a raczej dobrych praktykach np. proces tworzenia nowego produktu powinien mieć następujące kroki: opis pomysłu, analiza SWOT produktu na rynku, oszacowanie ceny sprzedaży, kosztu wytwarzania i planowanego poziomu sprzedaży, prognoza przepływów gotówkowych. Ale to "ogólny opis" a nie "prototypy procesów i mapy procesów". Tak więc są na pewno pewne pryncypia, można je znaleźć np. w książkę M.E.Portera "Strategie konkurencji" (autor koncepcji rynkowego łańcucha wartości) czy P.Druckera "Praktyka zarządzania". Jednak jak nam ktoś funduje system ERP z "wbudowanymi procesami referencyjnymi" to należy rozumieć: "szykuje się totalna rewolucja", czy ja przeżyjemy?

Czytaj dalejProcesy referencyjne czyli kto żyw niech ucieka

Wdrożenie ERP – koszt czy zysk?

Pokusa wdrożenia systemu połączonego z "modyfikowaniem pod potrzeby klienta" ładnie brzmi, ale nawet gdyby się to udało, to system taki usztywni firmę, zabierze jej więc jej kluczową zaletę: zwinność! Tak więc dla MSP owszem nawet duży system ERP ale z bogatym menu i swobodą dostępu do niego. Po drugie "wielkie zintegrowane zwierzę" będzie się wdrażało długo bo jest wielkie. Znacznie bezpieczniejszą dla MSP strategią jest wdrażanie funkcjonalności ERP etapami, mieszczącymi się w granicach roku budżetowego, nawet jeżeli miało by to oznaczać, że poszczególne moduły będą pochodziły od różnych dostawców (pisałem o tym nie raz tu). Nie ma możliwości łatwego udzielenia odpowiedzi na przytoczone dwa pytania na zadawane na konferencjach, bez zrozumienia tego co trapi daną firmę, jednak nasz kraj przoduje w sprzedaży leków bez recepty i mam wrażenie, że analogiczne zjawisko ma miejsce na rynku oprogramowania: po co nam jakaś analiza czy audyt, idziemy i kupujemy tego "erpa" bo mówią, że pomaga a firma sprzedająca obiecała, że pomoże.

Czytaj dalejWdrożenie ERP – koszt czy zysk?

Małe badanie czytelników

Od czasu do czasu warto zapytać kto czyta i po co czyta :) to co piszę. Nadchodzi kolejny rok więc jest okazja do takich pytań. Dotychczasowa "klasyfikacja" artykułów to kategorie (można kliknąć i zobaczyć jakie artykuły są w nich klasyfikowane): Analiza i modelowanie Case Study ? projekty Dla obecnych i potencjalnych klientów Inni piszą Konferencje i szkolenia Rady dla małych i średnich firm Recenzja książki Rozważania Rynek nie tylko IT Z listów od Państwa wiem, że jesteście Państwo: analitykami i projektantami, osobami zajmującymi kierownicze stanowiska menedżerskie, programistami. Do tej pory…

Czytaj dalejMałe badanie czytelników

Domain Driven Design UML Stereotypes – rozszerzenie w narzędziach Microsoft

Niedawno pisałem, że lubię i polecam styl DDD . Dlaczego? Bo nawet jak nie znamy przyszłych zmian (nowych wymagań) to na pewno projekt będzie się dało rozbudować zamiast zmieniać. Dlaczego? Bo jeśli projekt dobrze ?modeluje? rzeczywistość to znaczy, że jeśli tylko coś zmieni się w tej rzeczywistości, to będzie to możliwe do takiego samego odwzorowania w projekcie (Domain-Driven Design ? nie metoda a styl?.). Można o tym także przeczytać na blogu MSDN: Domain Driven Design (DDD) is especially suitable for creating long-term LOB Apps, but usually, DDD is presented as a…

Czytaj dalejDomain Driven Design UML Stereotypes – rozszerzenie w narzędziach Microsoft

O narzędziach CASE – rzadko ale jednak piszę

Prawdę mówiąc "zabraniam" przynoszenia komputerów na moje szkolenia, wymagam papieru i ołówka. Powody są dwa: Narzędzia CASE pomagają tylko wtedy gdy diagramów jest wiele i model jest złożony, na szkoleniach takich modeli się nie robi. Narzędzia, w szczególności niektóre, płatają figle i szkolenie np. z zakresu analizy biznesowej ewoluuje w stronę szkolenia z obsługi narzędzia.... do czego nie dopuszczam :). Napisze tu kilka słów jednak o narzędziach, bo dobrze jest jednak znać dobre i złe cechy swojego narzędzia. Spotykam się nie raz z bardzo popularnym pakietem CASE (SPARX Enteprise Architect) na szkoleniach (ma go wielu…

Czytaj dalejO narzędziach CASE – rzadko ale jednak piszę

Wiedza po studiach? Zostaliście oszukani…

Do napisania tego artykułu "zmusiła" mnie kolejna przygoda z korepetycjami, w której tym razem dostałem od studenta pełną treść zadania wraz ze wskazówkami. Nie będę pisał o jaką uczelnię chodzi i kim jest tenże wykładowca bo nie jest moim celem krytyka osoby czy uczelni. To co pisze, wydaje mi się, jest zjawiskiem powszechnym (w miarę czasu jakim dysponuje, udzielam często korepetycji studentom różnych uczelni). [...] to tylko przykład "zadania dla studenta", takich "zadań" i ich zaliczeń znam multum. Ktoś tak "wykształcony" pojawia się na rynku pracy i ma pretensje, że ma kłopoty ze znalezieniem pracy albo na podstawie dyplomu prestiżowej uczelni zostaje zatrudniony, i sieje spustoszenie w projektach nie raz ogromnej wartości. Jest nie raz gorzej, bo buduje stereotyp "nieprzydatnej i kosztownej pracy analityka". Powyższy przykład to praca wykładowcy na prestiżowej w naszym kraju uczelni na kierunku Analiza Biznesowa.

Czytaj dalejWiedza po studiach? Zostaliście oszukani…

Od biznesu do przypadków użycia

Wymagania na oprogramowanie są często dokumentowane z pomocą Przypadków Użycia (PU), zwanych w "oryginale" Use Case (UC). Wygodą stosowanie tej konwencji jest traktowanie Systemu jako tak zwanej czarnej skrzynki, czyli czegoś, czego wewnętrznej budowy nie znamy, ale znamy reakcje na bodźce. W przypadku oprogramowania, nie wiemy jak jest ono zbudowane (w momencie zamawiania go, może ono jeszcze nie istnieć), ale wiemy jak reaguje na "polecenia". Jest to uznanie zasady, że zamawiający definiuje CO oprogramowanie ma robić a nie to JAK ono to robi. W przypadku gotowego oprogramowania, lub na etapie poprzedzającym projektowanie, ma to sens, jednak należy pamiętać, że przypadki użycia nie determinują tego co tak na prawdę dostaniemy, co opisałem w artykule o tym co na prawdę opisują przypadki użycia. Generalnie diagram PU jest bardzo dobrym "korzeniem" do analizy i tworzenia pozostałych modeli, ale bez powstającego "natychmiast" modelu dziedziny nie jest możliwe zaprojektowanie granic (bounded context) dla komponentów. Spotykam się w literaturze z tezami, które uważam za słuszne, że jeden system (podsystem) nie powinien przekraczać 50 klas biznesowych w dziedzinie (liczba bliska 100 to ogromny system). Praca nad oprogramowaniem powinna zacząć się od analizy i rozbicia problemu na "strawne" kawałki. Najpierw podział na podsystemy, potem na komponenty, a na końcu konkretne klasy i ich realizacje. Nie ma tu mowy o podziale z perspektywy aktora, bo jeżeli wiemy jaka jest konstrukcja zaprojektowanego młotka albo kalkulatora, to nie możemy ograniczyć (bo nie mamy podstaw) liczby ich użytkowników, bo każdy ma swoje uzasadnione powody by wziąć do ręki np. młotek....

Czytaj dalejOd biznesu do przypadków użycia

Nowy paradygmat systemowy

Podstawową wyższością, dającą przewagę na rynku, jest zwinność organizacji. SOA to nic innego jak taka właśnie struktura systemu informatycznego: specjalizowane aplikacje, komponenty, instalowane (wdrażane) do realizacji konkretnych potrzeb zasobów takich jak pracownicy księgowości, pracownicy sprzedaży, pracownicy produkcyjni, itp.. Co więc robić? Opisać strategie rynkową firmy, Przeanalizować i opisać model biznesowy (sposób powstawania i źródło głównych dochodów), Uszczegółowić model biznesowy do opisu procesów kluczowych biznesowych i reguł biznesowych, Wskazać procesy, których wsparcie metodami informatycznymi przyniesie mierzalne korzyści, Zaprojektować (udokumentować) architekturą systemu informatycznego ukierunkowana na zasoby i usługi. Jeżeli pogodzimy się z faktem, że SOA to usługowa architektura systemu informatycznego firmy, zaś wszelkie webserwisy, szyny itp. to tylko możliwa implementacji (ale nie jedyna!) tej architektury to już będzie z górki. (W co inwestować w kryzysie c.d. - SOA) Tak więc, jak mawia mój znajomy profesor filozofii: gdy dwóch mówi to samo to nie jest to samo. Tu, o SOA, komponentach, analizie i projektowaniu zorientowanym na usługi mówi wielu. Dostawcy systemów ERP o zwartej, zintegrowanej architekturze będą tu z natury zachowywali bezwładność: SOA powoduje, że żaden ERP (system i jego dostawca) nie będzie miał monopolu u raz pozyskanego klienta.

Czytaj dalejNowy paradygmat systemowy

Modelowanie struktury organizacyjnej

Dosyć często spotykam się z modelowaniem struktur organizacyjnych czy nawet ról w procesach, z pomocą diagramów przypadków użycia i hierarchii aktorów z użyciem dziedziczenia. Jest to moim zdaniem kompletne nieporozumienie i fałszywe. Zawiłe diagramy struktur organizacyjnych w postaci aktorów dziedziczących po sobie (nie przytoczę tu żadnego, każdy taki jest w zasadzie zły), na których przełożony dziedziczy po podwładnym (lub podobne konstrukcje), są niemalże zawsze gruntu fałszywe. Studiowanie zakresów obowiązków pracowników firm jawnie pokazuje, że to nie prawda. Z zasady wielu menedżerów działów nie ma kompetencji swoich podwładnych, nie raz szef działu prawnego nie ma, i nie musi mieć, uprawnień radcowskich czy adwokackich, w wielu większych sekretariatach, upoważnienia do pewnych podpisów są przydzielane indywidualnie i szef (szefowa) nie ma tych wszystkich upoważnień. Szef kancelarii tajnej może mieć uprawnienia do informacji tajnej nadane przez ABW, których to uprawnień nie ma nie raz, jego przełożony. Przykładów na fałszywość dziedziczenia uprawnień w strukturze organizacyjnej można podać tak ogromną ilość, że dość częste stosowanie tej konstrukcji wydaje mi się niezrozumiałe. projektują oprogramowanie także, z reguły nieprawdą, jest dziedziczenie praw dostępu. Nie przypadkiem w praktyce stosuje metody macierzowe zarządzania prawami dostępu (niewydolne i nie prawdziwe w sensie biznesowym) lub kontekstowe (dużo lepsze).

Czytaj dalejModelowanie struktury organizacyjnej

Modelowanie biznesowe

Model organizacji to: opis motywacji jej działania, opis ludzi, jacy realizują wewnętrzne zadania, opis reguł jakie regulują ich zachowaniami. Całość (model) powinna być na tyle uporządkowana, by model był w 100% jednoznaczny, czyli kluczowe pojęcia w nim użyte powinny być zebrane w jeden wewnętrzny, spójny biznesowy słownik tej organizacji. To wszystko dopiero pozwoli stworzyć model procesów biznesowych, czyli wewnętrzne scenariusze zachowania. Samo utworzenie map (bo nie modeli) w postaci diagramów procesów z pomocą wywiadów, sesji warsztatowych i obserwacji, da produkt podobny do zdjęcia lotniczego rzeki: wiemy którędy płynie, ale kompletnie nie rozumiemy dlaczego akurat tak. Mamy jedynie udokumentowany stan obecny. Ingerencja w ten stan rzeczy, bez zrozumienia reguł rządzących tym jak i którędy płynie woda, kończy się nie raz katastrofami jakie znamy z doniesień o powodziach i zalaniach ostatnich lat. Bez poznania zasad rządzących zachowaniem się organizacji można "nie uniknąć problemów przy wprowadzaniu zmian". Każda reorganizacja, a w szczególności jest nią wdrażanie nowego oprogramowania, jest taką zmianą. Ta książka jest o modelowaniu organizacji.

Czytaj dalejModelowanie biznesowe

Koniec treści

Nie ma więcej stron do załadowania