listopad 2011 – Jarosław Żeliński IT-Consulting

Producent systemu ERP chce 20 mln USD zadośćuczynienia od długoletniego klienta – kliencie pilnuj się, pomogę

Post author:Jarosław Żeliński
Post published:30 listopada 2011
Post category:Analizy biznesowa i projektowanie oprogramowania
Post comments:0 Komentarzy
Post last modified:30 listopada 2011

Nie raz od klientów słyszę, że walka z dostawcę nie ma sensu, ale nie jest to prawda. Na etapie zawierania umowy zależy dostawcy bardzo, i jest to czas (ostatni!) by negocjować. Tak więc po pierwsze warto zadbać o treść uwowy, po drugie zadbać o swój know-how, jak? Dedykowane dla siebie funkcjonalności należy implementować, ale nie metodą ingerencji w pierwotny kod źródłowy (polecana przez dostawców kastomizacja) a poza nim, w postaci odrębnego projektu. Nawet jeżeli implementacja będzie miała miejsce w środowisku kupionej aplikacji to jednak nasz jest fragment kodu wytworzony od zera dla nas (jeżeli nie został zaprojektowany przez dostawcę pierwotnego systemu!). Tak więc po pierwsze warto zadbać o treść uwowy, po drugie zadbać o swój know-how, jak? Dedykowane dla siebie funkcjonalności należy implementować, ale nie metodą ingerencji w pierwotny kod źródłowy (polecana przez dostawców kastomizacja) a poza nim, w postaci odrębnego projektu. Nawet jeżeli implementacja będzie miała miejsce w środowisku kupionej aplikacji to jednak nasz jest fragment kodu wytworzony od zera dla nas (jeżeli nie został zaprojektowany przez dostawcę pierwotnego systemu!).

Czytaj dalej

Czas nie jest aktorem dla Systemu c.d. czyli projekt

Post author:Jarosław Żeliński
Post published:29 listopada 2011
Post category:Przykładowe projekty
Post last modified:16 lutego 2023

aktorem absolutnie nie jest Czas, aktorem jest inny system, tu źródło sygnału czasu. Diagram UC jest zgodny ze standardem a my "zrozumieliśmy istotę rzeczy". Stosowanie w analizie standardów prowadzi do rozumienia i ma taką właśnie zaletę: analiza i modelowanie prowadzi do zrozumienia problemu, łamanie zasad notacji ukrywa niezrozumienie problemu (o co chodzi z tym oczekiwanym przez klienta czasem).

Czytaj dalej

Czas nie jest aktorem Systemu

Post author:Jarosław Żeliński
Post published:27 listopada 2011
Post category:Analizy biznesowa i projektowanie oprogramowania
Post comments:5 komentarzy
Post last modified:17 stycznia 2024

Tak więc radzę ostrożnie z Wikipedią. Wprowadzanie pojęć ukrywających istotę rzeczy to moim zdaniem, ukrywanie niewiedzy na etapie analizy i projektowania. To jedna z przyczyn złej jakości procesu tworzenia oprogramowania. Niezależnie od tego jak ładnie umotywujemy istnienie aktora Czas, programista i tak musi ten problem rozwiązać i nie będzie to na pewno interfejs "interakcji Systemu z Czasem"... A co z czasem? No cóż, albo człowiek klika co godzinę w coś, albo wewnątrz systemu jest moduł, który generuje zdarzenie wywołujące te samo operację co klikający użytkownik... Moduł wewnętrzny systemu nie jest jego aktorem.Jak w takim razie w ogólności modelować cykliczność? Np. "prenumerata czasopisma na okres 12 m-cy", "codzienne generowanie raportu", "zbieranie wskazań licznika co N jednostek czasu" ? Po pierwsze usługa systemu to odpowiednio: zarządzanie prenumeratami, generowanie raportów, przetwarzanie pomiarów. Prenumerata to zapis mówiący, że mam otrzymać np. każde wydanie jakiegoś periodyka w ciągu danego roku. Generowanie raportów to czynność człowieka (raport na życzenie) albo automatu reagującego na zdarzenie "konkretny czas", zdarzenia takie generuje np. zegar systemowy. Zbieranie wskazań licznika to cykliczne zdarzenie inicjowane przez System. Implementacja tych wymagań to element projektowania logiki biznesowej i nie jest to już diagram przypadków użycia a model dziedziny systemu bo to tu jest logika biznesowa.

Czytaj dalej

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

Post author:Jarosław Żeliński
Post published:26 listopada 2011
Post category:Analizy biznesowa i projektowanie oprogramowania
Post comments:6 komentarzy
Post last modified:31 października 2015

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

Web 2.0 – kolejny niewypał?

Post author:Jarosław Żeliński
Post published:26 listopada 2011
Post category:Analizy biznesowa i projektowanie oprogramowania
Post comments:0 Komentarzy
Post last modified:26 listopada 2011

W końcu mamy postęp technologiczny i podobno kluczem do sukcesu są innowacje. Tylko czy przypadkiem producenci korporacyjnych systemów Web 2.0 nie polegają tylko na metodzie "trzeba stworzyć rynek na nasz produkt, mówmy że to jest potrzebne, może ktoś uwierzy". W końcu nie mało firm (a raczej ich prezesi) kupuje jakieś rozwiązanie nie dlatego, że im w czymś pomagają a dlatego, że są modne albo "uczynią Cię lepszą firmą".... (np. nie rozumiem na czym polega korzyść z noszenia gumowców latem mimo, że nie ma deszczu...;) ale ja nie znam się na modach).Mnie osobiście dla odmiany w ogóle nie dziwi to, że firmy nie zaadoptowały "Web 2.0" bo po co? Serwisy społecznościowe pozwalają nam na poszerzenie liczby kontaktów, a co poszerzamy kontaktując się z współpracownikami, których już znamy (a tych, których nie znamy pewnie nie chcemy znać...). Sam mam konto na Linked In, GoldenLine i FaceBook, jednak kluczowym powodem jest raczej kontakt z tymi, których w ciągu dnia pracy nie jestem w stanie spotkać (czy poznać). Umawiam się na weekendowe wieczory albo śledzę nowinki. A pracownik w pracy? Dla wielu, nie tylko z pionu handlowego, wartość ma właśnie poszerzanie grona znajomych poza własną firmą (koledze zza biurka niczego nie sprzeda...) dlatego jeżeli już Państwo szukają innowacyjnych rozwiązań to zawsze zainteresować się współdzieleniem treści z istniejącymi serwisami społecznościowymi, lepiej jest wykorzystywać te istniejące niż tworzyć własne, konkurencyjne...

Czytaj dalej

Analityk biznesowy czyli wyplenić dwuznaczność z dokumentów analitycznych!

Post author:Jarosław Żeliński
Post published:21 listopada 2011
Post category:Analizy biznesowa i projektowanie oprogramowania
Post comments:7 komentarzy
Post last modified:17 czerwca 2014

"Im większa niejednoznaczność dokumentu wymagań tym większe ryzyko, że projekt będzie miał kłopoty".Powyższe nie stanowi żadnego odkrycia co nie zmienia faktu, że jakość większości dokumentów wymagań (owe 70%) jest słaba, na co wskazują sami ankietowani.Rola Kierownika Projektu to między innymi zarządzanie ryzykiem. Statystyki są nieubłagane, więc brak dobrego analityka i dobrej analizy wymagań spycha projekt w kierunku kłopotów. No to mamy kolejne badanie: Znaczenie i zapotrzebowanie na specjalistów wg. Forrestera: 70% badanych decydentów uważa, że Analityk Biznesowy to kluczowa postać w projekcie. Jednak nie dlatego, że jest ważniejszy od np. kierownika projektu, bo nie jest ważniejszy. Dlatego, że od jakości jego produktu (analiza i specyfikacja wymagań) zależy właśnie ryzyko całego projektu.Co jest wadą większości analiz biznesowych? To, że są one tak na prawdę uporządkowanym zapisem wywiadów z klientem a nie faktyczną analizą organizacji, jej potrzeb (bo raczej nie koniecznie jej pracowników!) i celów biznesowych. Jakie są treści tekstowego lub tabelarycznego zapisu wywiadów? NIEJEDNOZNACZNE! Jakie są niesformalizowane, swobodnie tworzone diagramy procesów? NIEJEDNOZNACZNE! Jakie są słowne opisy struktury oprogramowania jakie ma powstać? NIEJEDNOZNACZNE!Co zrobić? Używać już na etapie analizy biznesowej i projektowania sformalizowanych narzędzi takich jak standardowe notacje i metodyki, wtedy opisy będą JEDNOZNACZNE. Czy to trudne? Tak, w końcu te 70% porażek to nie przypadek...

Czytaj dalej

Czego największe firmy technologiczne nie mówią swoim klientom?

Post author:Jarosław Żeliński
Post published:20 listopada 2011
Post category:Analizy biznesowa i projektowanie oprogramowania
Post comments:1 Komentarz
Post last modified:24 marca 2021

Zasady panujące na rynku produktów i usług IT wydają się przejrzyste: klient wydaje pieniądze na jakiś produkt, oczekując w zamian określonych korzyści. Jak wynika z udostępnionych przez Gartner Inc. analiz, firmy realizują przy okazji swoją strategię, o której wolałyby klientom nie mówić. Jakie są ich cele? [...]Omawiając strategie firm, Gaughan podkreślił również znaczenie działających przy nich ośrodków badawczych. Ich nadrzędnym celem jest tworzenie innowacji w takich sposób, aby ? zachowując pozory rozwoju ? utrzymywać istniejący stan rzeczy tak długo, jak to tylko możliwe.(źr. Czego największe firmy technologiczne nie mówią swoim klientom?. oraz oryginał: What Microsoft, Oracle, IBM, And SAP Don't Tell Customers)

Czytaj dalej

Co zrobić przed wyborem dostawcy usług IT?

Post author:Jarosław Żeliński
Post published:18 listopada 2011
Post category:Analizy biznesowa i projektowanie oprogramowania
Post comments:0 Komentarzy
Post last modified:19 listopada 2011

Jednak powyższy fragment, waga procesu opisu wymagań, stanowi tylko 8% całości tekstu, którego autorem jest firma dostarczająca dedykowane rozwiązania. Dlaczego? Może rzecz w tym, skoro analiza potrzeb (patrz powyżej) powinna być wykonana przed wyborem rozwiązania i jego dostawcy to wniosek nasuwa się sam: nie robi tego ten dostawca i słusznie. Tak więc z dużym prawdopodobieństwem można przyjąć, że "określanie potrzeb" nie jest mocną stroną firm, które dostarczają konkretne rozwiązania :).Skoro więc "Punktem wyjścia w procesie doboru dostawcy usług IT jest precyzyjne określenie własnej potrzeby w tym zakresie ", to gorąco zachęcam Państwa do precyzyjnego określania swoich potrzeb przed wyborem partnera, który je zrealizuje.

Czytaj dalej

Rzeczpospolita wprowadzi opłaty online – a nie mówiłem

Post author:Jarosław Żeliński
Post published:17 listopada 2011
Post category:Analizy biznesowa i projektowanie oprogramowania
Post comments:0 Komentarzy
Post last modified:15 listopada 2011

Tak więc rynek jest nieubłagany, skoro reklamy nie zarabiają na utrzymanie merytorycznych serwisów, trzeba będzie płacić za ich treść.Cóż? prawa rynku są nieubłagane, coraz więcej gazet i autorów blokuje bezpłatny dostęp do swoich archiwów zaś bieżące informacje są coraz częściej, nie tylko publikowane, są po prostu sprzedawane poszczególnym publikatorom (Prawo autorskie czyli model biznesowy sprzedaży wartości niematerialnych i usług).To, Rzeczpospolita, kolejny tytuł, który zaczyna pobierać opłaty za treść.

Czytaj dalej

Logika wnioskowania dedukcyjnego czyli czym jest poprawna analiza i modelowanie

Post author:Jarosław Żeliński
Post published:15 listopada 2011
Post category:Analizy biznesowa i projektowanie oprogramowania
Post comments:1 Komentarz
Post last modified:10 września 2019

W czym problem z kiepskiej jakości analizami i modelami? W tym, że ich autorzy podejmują próby dodawania nowych symboli do notacji, psując spójność i jednoznaczność diagramów, stosują symbole notacji niezgodnie z nadanymi im znaczeniami albo łamią zasadę wyłączonego środka mówiącą w uproszczeniu, że jeżeli coś jest czymś to znaczy, że nie jest już niczym innym (np. jeżeli coś jest zdarzeniem to na pewno nie jest ani czynnością, ani danymi, ani regułą decyzyjną). Innymi słowy: jeżeli jakieś ziarno węgla jest kostką to na pewno nie jest ani groszkiem, ani orzechem ani miałem.A co jeżeli jednak wynik analizy jest opisem w języku naturalnym lub zestawem diagramów łamiących zasady notacji? Wtedy tak naprawdę analitykami są programiści, bo oni i tak muszą to zamienić na kod w języku programowania, którego używają. Czy to dobry pomysł? Pozostawię odpowiedź czytelnikowi...

Czytaj dalej

HARD FACTS ON BUSINESS ANALYSIS

Post author:Jarosław Żeliński
Post published:15 listopada 2011
Post category:Analizy biznesowa i projektowanie oprogramowania
Post comments:2 komentarze
Post last modified:21 września 2022

? 70% of all project failures are as a result of poor requirements. ? There is a 60% time and cost premium to be paid on projects with poor quality requirements. ? As the projects get more interdepartmental and complex, the failure rate rises. ? It costs 80 times as much to fix defects after delivery, than at the specification stage. ? 74 per cent of all companies have immature requirements practices. ? Large scale systems project fail with alarming regularity. A typical project over-ran its budget by 189% and over-ran its schedule by 222%. ? Average project has about 30% rework. This means that for every Kshs 1,000,000, Kshs 300,000 is spent redoing something that was thought to be complete. ? The average company with low requirements maturity wastes 34% of the organization?s IT development budget. ? 68% of companies simply did not use the necessary competency in requirements discovery at the start of their project to assure project success. Source: IAG Business Analysis Benchmark, 2008 (za HARD FACTS ON BUSINESS ANALYSIS | LinkedIn).

Czytaj dalej

Przypadki użycia systemu czyli co?

Post author:Jarosław Żeliński
Post published:14 listopada 2011
Post category:Analizy biznesowa i projektowanie oprogramowania
Post comments:16 komentarzy
Post last modified:15 listopada 2011

Po kilku latach kolejnych doświadczeń upewniam się, że proste jest piękne: przypadek użycia to pojedyncza, elementarna kompletna usługa świadczona przez System dla jego użytkownika. Usługa ta jednak może mieć warianty.Jaki z tego ma pożytek sponsor projektu? Koszt, projekt ma kilkanaście lub kilkadziesiąt a nie setki przypadków użycia i jest łatwiejszy w implementacji.A gdzie przypadki systemowe? Nie ma takich. Pojęcie Aktora ma jasną definicję (osoba lub inny system mający interakcję z Systemem), pojęcie przypadku użycia także (specyfikacja działań Systemu w odpowiedzi na działania aktora lub innego podmiotu "zainteresowanego" Systemem) (źr.: OMG Unified Modeling LanguageTM (OMG UML), Superstructure Version 2.3). Wymyślanie nowych definicji nie tylko psuje standard bo nie pasuje do spójnej przestrzeni nazw. Wymyślanie swoich znaczeń po protu psuje zrozumiałość, niszczy role komunikacyjną modeli (języka ich tworzenia). Niestety Pan Cockbourn jest w moich oczach takim "dorabiaczem" i psującym sens prostego i jak widać trudnego zarazem, narzędzia jakim jest model przypadków użycia systemu.

Czytaj dalej

Koniec treści

Nie ma więcej stron do załadowania

Starsze wpisy