Proces zbierania i analizy wymagań u developera

Analiza Biznesowa i specyfikacja wymagań opracowana metodą opisywaną tu i na stronach OMG, jest od tej ostatniej (grupa konsultantów i sesje warsztatowe) znacznie tańsza. W czasie trwa podobnie, jednak robi to z reguły jedna osoba (tak! ale przy założeniu ma stosuje zaawansowane narzędzia CASE nie tylko do tworzenia diagramów ale także do ich weryfikacji śladowania zarządzania spójnością modeli itp.), a efektem jest projekt logiczny a nie dopiero lista wymaganych cech. Korzyść jest więc podwójna. Jeżeli zrobi to Analityk wynajęty przez Klienta a nie Dostawcy, to wszelkie prawa (know-how) do projektu pozostają po stronie nabywcy. Można powiedzieć, że to trudne i kosztowne. Trudne owszem, wymaga doświadczenia i wiedzy zarówno z zakresu zarządzania jak i inżynierii oprogramowania. Per saldo, wliczając w to koszty modyfikacji na etapie wdrażania i odkrywania wymagań (wady specyfikacji nie poddającej się weryfikacji) jest to proces zawsze tańszy (badania kierowników projektów wskazują, że zła jakość wymagań generuje dodatkowe koszty rzędu 60% wartości projektu, koszt takiej analizy nie przekracza zaś 20%). Do tego pojawiają się potencjalne koszty nieujawnione klientowi: prawa autorskie do projektu i aplikacji. Jeżeli firma będąca wykonawca oprogramowania robi analizę swojego klienta i potem mu sprzedaje prawa do jej wyników wraz z dostarczanym oprogramowaniem, to jest to klasyczny przypadek anegdoty o konsultantach, którzy zapytani o to która jest godzina, proszą Cie o Twój zegarek, odpowiadają na pytanie która godzina i wystawiają fakturę za usługę i także za zwracany Ci Twój zegarek.

Continue ReadingProces zbierania i analizy wymagań u developera

Duży monolityczny ERP czy integracja

Tym razem krótko. Praktycznie za każdym razem moje rozmowy z potencjalnymi klientami dotykają problemu: jeden zintegrowany system ERP czy kilka dziedzinowych rozwiązań. Ja zawsze powtarzam to samo: im większy monolityczny system tym większym ograniczeniem i kosztem staje się dla firmy, tym większe uzależnienie od jednego dostwcy. Na rynku ścierają się stale dwie grupy opinii: "duży ERP jest lepszy bo od jednego dostawcy i od razu zintegrowany", kontra teza "duży ERP monolityczny wymaga wielu prac dostosowawczych i bardzo trudno zmienić w nim jedno nie ingerując w resztę". [...] "lepszym rozwiązaniem będzie wdrożenie systemów dziedzinowych i ich zintegrowanie"...

Continue ReadingDuży monolityczny ERP czy integracja

Kilka uwag na temat systemów ERP II, ich historii i metod ich wyboru

Analiza biznesowa obejmuje wyłącznie obszar strategii i procesów biznesowych. Wdrożenie poprzedzane jest analizą całej organizacji, wydzielenie w niej niezależnych obszarów dziedzinowych (np. rachunkowość, zarządzanie procesami pracy, zarządzanie wiedzą, portal klienta, zarządzanie i sterowanie produkcją, zarządzanie procesem sprzedaży, inne). Każdy obszar cechuje się tymi trzema poziomami: strategia, procesy, realizacja. Na etapie analizy potrzeb prowadzimy audyt i modelowanie procesów. Zakładamy, że szczegóły tego ?jak pracujemy? i tak ulegną zmianie po wdrożeniu nowego narzędzia pracy, więc pomijamy je na tym etapie (zostaną określone podczas wdrożenia). Jeżeli analiza wykaże, że istnieje obszar niestandardowy w organizacji, tylko dla tego obszaru prowadzi się szczegółową analizę, gdyż w tym obszarze będzie (najprawdopodobniej) wdrażane rozwiązanie dedykowane. Tak więc zintegrowany system ERP II nie musi oznaczać "jedno rozwiązanie od jednego dostawcy". Po pierwsze trudno jest szczegółowo wyspecyfikować taki system, po drugie nie raz okazuje się, ze "systemy od wszystkiego są do niczego"...

Continue ReadingKilka uwag na temat systemów ERP II, ich historii i metod ich wyboru
Read more about the article Modelowanie biznesowe c.d. – know-how, gdzie ono jest?
źr. Busnes Process Trends http://www.bptrendsassociates.com/

Modelowanie biznesowe c.d. – know-how, gdzie ono jest?

Proces biznesowy, nie procedura i nie opis przepływu pracy, to prosty ciąg czynności, których celem jest konkretny rezultat: produkt procesu (jego wyjście). Proces ma cel, stanowi prosty łańcuch pracy wykonawcy (Rola), radzi sobie z wydarzeniami "utrudniającymi". Główny ciąg (oczekiwany) zaznaczono szarą strzałką. Pozostałe "atrakcje" to czynności wymuszone pewnymi nie oczekiwanymi (a raczej nie chcianymi), ale przewidzianymi zdarzeniami. Tu nie ma "rombów", bramek decyzyjnych bo one są cechą "procesów decyzyjnych", procedur, a te to reguły biznesowe i "wiedza o biznesie" a nie proces biznesowy. Pewne czynności mogą być ograniczone Procedurą, która mówi, że "tylko tak wolno tę pracę wykonać". Reguły biznesowe to wewnętrzne (np. zarządzenia) lub zewnętrzne (prawo) ograniczenia. Pojawia się rola czyli wykonawca (tu rola działu HR - opis kompetencji pracowników), on posiada niezbędną wiedzą i umiejętności, potrafi obsługiwać "maszyny" (także oprogramowanie). Tak więc definicja mówiąca, że proces wykonuje się w w środowisku ograniczeń i wymaga zasobów tak właśnie wygląda: zasoby to ludzie (role), ich wiedza i narzędzia pracy, ograniczenia to reguły biznesowe i procedury.

Continue ReadingModelowanie biznesowe c.d. – know-how, gdzie ono jest?

Hurtownie danych czyli “Systemy od historii”

Hurtownia danych to model stworzony pod kątem przetwarzania faktów historycznych na prostym modelu danych (diagram powyżej, górny, to tak zwana kostka OLAP). Opracowanie takiego modelu wymaga specjalnej analizy i projektu, ale nie zapominajmy: analizę się robi raz a raporty stale... Tak więc szanowni Państwo. Jeśli tylko Wasza firma jest bliżej czołówki niż ogona rankingu rynku w Waszej branży, nie dajcie się namówić na jeden zintegrowany ERP i jakiś model referencyjny, bo nawet jak uda się go wdrożyć, to zmiana czegokolwiek będzie trudna a upgrade do nowszej wersji niemożliwy. Opracowanie projektu systemu składającego się z komponentów, pozwoli Wam dobrać najlepiej spełniające Wasze wymagania aplikacje. Jak z klocków LEGO złożycie "dedykowany system" pomagający utrzymać przewagę na rynku, a nie cofający Waszą firmą do poziomu "innych podmiotów w branży".

Continue ReadingHurtownie danych czyli “Systemy od historii”