CRM – Page 5 – JZ IT Consulting Ltd

Ach ten opluty wodospad… czyli lessons learned ERP

Post author:Jaroslaw Zelinski
Post published:22 July 2012
Post category:Analizy biznesowa i projektowanie oprogramowania

Opisane tu podejście często nazywane jest "kaskadowym" (waterfall - wodospad). Jest ono dość często wskazywane jako powód porażek projektów, ale moim zdaniem jest to pewna demagogia, gdyż tak na prawdę przyczyną większości problemów jest nie tyle "wodospadowe" podejście, ono jak widać z powyżej opisanego procesu, ma głęboki sens, co wzięcie sobie na barki projektu (zawarcie umowy z dostawca na trzy lata to przyjęcie w dniu jej zawarcia harmonogramu łamiącego opisana powyżej zasadę) na lata zaniedbując zupełnie fakt, że otoczenie rynkowe obecnie zmienia się nawet co kwartał. Mamy więc kuriozalne zestawienie: podjęcie projektu od razu od ostatniego etapu (wybór dostawy, produktu i realizacja) i zaplanowanie go od razu na np. trzy lata. To projekt w rodzaju "nie wiem co tu jest grane ale kupujemy [ten system] i wdrażamy go". To nie ma prawa się udać... A nasze "lessons learned"? No właśnie, znane mi projekty zakończone kłopotami, to właśnie projekty na skróty. Projektu prowadzone w myśl powyższych zasad (krótkie i dobrze zaplanowane etapy) są znacznie bardziej odporne na kłopoty.

Czym jest jakość oprogramowania… a może od czego ona zależy?

Post author:Jaroslaw Zelinski
Post published:26 June 2012
Post category:Analizy biznesowa i projektowanie oprogramowania

Coraz częściej utożsamiam analizę z projektem gdyż w sumie produktem analizy jest jakiś projekt czyli model tego co analizowano, model tego co rekomenduję by powstało. Analiza sama z siebie nie jest samowystarczalna (to znaczy samo analizowanie nie jest wartościowym produktem samym w sobie). Problemy z projektami obserwuje nie ja jeden. W każdym kolejnym projekcie staram się szukać przyczyn, zrozumieć problem i podjąć próbę rozwiązania. Problem w zasadzie jest znany. [...] Dalej mamy same dobre rady, z którymi trudno polemizować: Wysoka modularność, współpraca wielu niezależnych, lub luźno powiązanych elementów, możliwość wymiany małych części, lub tworzenie różnych wariantów tego samego modułu, to podejścia, które przyniosą nam wartość dodaną. Ludzie mający do czynienia z monolitami (układ: jedna wielka baza danych i do tego wielki serwer aplikacyjny) z reguły postrzegają podejście rozproszone (dziesiątki lub setki małych kawałków fruwających gdzieś w koło) jako trudniejsze, bardziej skomplikowane i przez to gorsze i bardziej ryzykowne. Takie spojrzenie to postawienie sprawy do góry nogami. I tu moim zdaniem autor ma 100% racji. Nie ma chyba nic gorszego niż uznanie, że "jeden wielki zintegrowany system" to zaleta tego Systemu, jest to jego największa wada.

Prawo a wymagania …

Post author:Jaroslaw Zelinski
Post published:11 June 2012
Post category:Analizy biznesowa i projektowanie oprogramowania

Podstawową korzyścią z wyodrębnienia reguł biznesowych i słownika pojęć jest uporządkowanie słownictwa w dokumentacji i uczynienie jej jednoznaczną oraz weryfikacja ewentualnych sprzeczności regulacji wewnętrznych (Zarządzeń, Prawa). Powoływanie się na Reguły biznesowe na modelach procesów biznesowych, pozwala zachować ich prostotę nie tracąc szczegółowości wiedzy o procesach. Tak wykonana dokumentacja procesów nie wymaga częstej i kosztownej aktualizacji, z reguły aktualizowane są procedury i reguły biznesowe, na które modele procesów się powołują. Tak więc akty prawne to zakazy i nakazy, reguły biznesowe. Oprogramowanie, zależnie od przyjętej konwencji, nie powinno ograniczać ani nawet utrudniać postępowania zgodnego z prawem, może pojawić się oczekiwanie by nie pozwalało łamać prawa. Szczegółowa analiza aktów prawnych, w moich oczach, ma sens gdy projektujemy oprogramowanie. Gdy stawiamy wymagania przed już istniejącym oprogramowaniem, zakładamy że kupimy gotowe, wystarczy wymagać zgodności z prawem w obszarze stosowania oprogramowania. Jeżeli np. oprogramowanie ma pozwalać na wystawianie faktur to znaczy, że powinno być możliwe wystawienie każdej faktury przewidzianej prawem w sposób zgodny z nim. Możemy dodatkowo zażądać by nie było możliwe wystawienie faktury niezgodnej z prawem.

Model biznesowy czyli po co mi te procesy przed wdrożeniem ERP czy CRM…

Post author:Jaroslaw Zelinski
Post published:29 January 2012
Post category:Analizy biznesowa i projektowanie oprogramowania

Wdrożenie nowego oprogramowania, jeżeli ma mieć sens, powinno więc wspierać tworzenie dodatkowego zysku lub przychodu, w przeciwnym wypadku w zasadzie nie ma sensu. Innym powodem może być ratowanie posiadanego już przychodu czyli utrzymania się na rynku. Dodatkowy zysk, to efekt obniżania kosztów. Ratowanie posiadanego rynku, to efekt reakcji na siły rynku: siły dostawcy (np. jego system EDI wymusza inwestycje u nas), siły odbiorcy (oczekuje obsługi podobnej do tej, jaką oferuje konkurencja), siły konkurencji (ich produkty i usługi są wyższej jakości, musimy też zainwestować). Powyższy model obrazuje to co ma wpływ na to Dlaczego zarabiamy. Zbudowanie takiego modelu dla konkretnej firmy, zrozumienie Dlaczego zarabia, pozwala szukać sposobu i miejsc mogących przyczynić się do realizacji celu projektu, jednak cel ten należy wcześniej Nazwać. Drugi krok to ocena możliwości realizacji i prognozowanie skutków, by określić cel: miarę i wielkość tego co chcemy osiągnąć by wiedzieć czy się udało. Podsumowanie Model biznesowy moim zdanie nie odnosi się do procesów biznesowych, to procesy biznesowe są konsekwencją modelu biznesowego. Dlaczego? Bo jeśli przyjmiemy, że model biznesowy obrazuje (dokumentuje) źródła zysku firmy w łańcuchu wartości na rynku, to procesy biznesowe są opisem tego, w jaki sposób ta wartość wewnątrz firmy powstaje. To pozwala dopiero wskazać jakie działania (procesy) wesprzeć i jak, by "ulepszyć" firmę. Dlatego brak modelu biznesowego jest poważnym utrudnieniem analizy wymagań... bo czego wymagać od oprogramowania skoro nie wiemy co i jak pomoże w zarządzaniu firmą?

Biznes wychodzi z objęć systemu … monolitycznego ERP

Post author:Jaroslaw Zelinski
Post published:28 December 2011
Post category:Analizy biznesowa i projektowanie oprogramowania

Rynek stale się rozwija i dojrzewa. Praktycznie każda większa firma doświadczyła w jakiejś formie wdrożenia gotowego, dostosowywanego do potrzeb, oprogramowania ERP. Warto jednak podkreślić, że idea jednego "super systemu" ERP II, odchodzi powoli do lamusa. Moim zdaniem to kwestia roku, dwóch. Pierwsze symptomy to zalecenia producentów dużych systemów: wdrażać gotowe oprogramowanie w postaci "gotowej" tylko tam gdzie pasuje, obszary specyficzne dla firmy opisać i zaprojektować dla nich dedykowane rozwiązanie i zintegrować. Dobry system ERP to środowisko programistyczne (tak zwany framework, szkielet). Systemy, nawę je "zapóźnione", nadal wymagają ingerencji w ich kod by cokolwiek osiągnąć. Kompromisem jest sytuacja, w której system ERP ma bogaty interfejs (tak zwane [[API, Application Programming Interface]]) pozwalający na integrację dedykowanych podsystemów lub właśnie zewnętrznych komponentów czyli korzystania z możliwości jakie daje Cloud Computing). Przyszłość to komponenty...