Rynek 2013

Firmy odkrywają, że sprawny obieg dokumentów zaczyna stanowić większą wartość dla klientów niż sprawność rachowania. Dlaczego? Bo nasi klienci postrzegają nas poprzez to, jak sprawnie ich obsługujemy a nie przez to, jak sprawnie księgujemy u siebie ich pieniądze.Tu warto zwrócić uwagę na to, że to co często nazywamy system CRM, to "jakaś" obsługa klientów a potem dopiero jakieś zbędne "lejki sprzedaży". Dlaczego zbędne? Bo każda firma, która w końcu z sensem wdrożyła budżetowanie wie, że plan przychodów i jego bieżąca realizacja to po prostu budżet i jego bieżąca realizacja więc ów "lejek" dubluje coś, co i tak powinno być (budżet przychodów). Po usunięciu "lejka" z zakresu wymagań pozostaje nam zarządzanie "sprawami" czyli obsługa zapytań, umów, faktur itp. To wszystko robi (potrafi) system workflow (zarządzanie przepływem pracy i dokumentów). A rejestr klientów? Akurat to nie stanowi żadnego problemu... Co mamy? Systemy CRM także nie są przedmiotem "wielkich planów zakupowych" bo w ich miejsce wchodzą systemy workflow: mają dokładnie taka funkcjonalność. Tak więc CRM jako strategia jak najbardziej, CRM jako kolejny system w firmie już nie koniecznie. Kluczowe ryzyko: systemów tego typu nie da się wdrażać "zwinnie" bo wymagają one bardzo dokładnej analizy taksonomii dokumentów przed rozpoczęciem wdrożenia...

Czytaj dalejRynek 2013

TOGAF or not TOGAF więc może Zachman

Badanie przydatności TOGAF/ArchiMate mam chyba za sobą (zapewne nie na miarę doktoratu ale troszkę jednak tak, chociaż...;)).  Na stronie mojego kolegi: ArchitekturaKorporacyjna.pl (polecam analitykom),  w jednym z artykułów pojawia się ciekawe stwierdzenie: TOGAF wskazuje, że niewłaściwe podczas modelowania jest bezpośrednie wiązanie procesu [biznesowego, jak sądzę] z aplikacją go wspierającą ? elementem pośrednim powinna być funkcja ? czyli: aplikacja wspiera realizację funkcji, a funkcja obejmuje cały proces lub jego fragment (w zależności od poziomu dekompozycji funkcji biznesowej). (Komentarze do TOGAF ? metamodel zawartości (cz. II) | Architektura Korporacyjna). i to jest coś co…

Czytaj dalejTOGAF or not TOGAF więc może Zachman

Analiza wymagań na oprogramowanie czyli opisanie czy zrozumienie

Istnieje coś takiego jak zasada SOLID projektowania oprogramowania (jedna z kluczowych cech dobrych projektów oprogramowania). Cóż to jest SOLID? To rozwinięcie od ang. Single responsibility, Open-closed, Liskov substitution, Interface segregation and Dependency inversion (więcej na stronie SOLID (object-oriented design) - Wikipedia, the free encyclopedia).Dzisiaj tylko o skutkach zaniedbania jednej, kluczowej chyba własności, która dotyczy całej aplikacji: Open-Close, która oznacza: aplikacja powinna być zamknięta na zmiany i otwarta na rozbudowę. Dla wielu na początku ta zasada brzmi wręcz kuriozalnie ale ona jak najbardziej jest możliwa do realizacji. Proszę zwrócić uwagę, że takie własnie są dobrze zarządzane firmy, nie ma w nich rewolucji organizacyjnej co roku, one się rozwijają a nie zmieniają.Oprogramowanie, jeżeli w wyniku analizy wymagań opracowano nie tylko raport z wywiadów ale także model logiki działania, też spełni te zasadę. Czym grozi jej niespełnienie w stosunku do oprogramowania? A tym, do czego przyznał się jeden z programistów podczas pewnej dyskusji na forum:kilka razy doświadczyłem sytuacji, że aby spełnić nowe proste wymaganie trzeba było się namęczyć zarówno z modelem danych jak i aplikacją, Oczywiście można w takiej sytuacji zarzucić, że system był źle zaprojektowany, nieskalowalny, nie przestrzegał SOLIDów, nie korzystał z wzorców itd ale to już jest inna bajka.Na co ja odpowiedziałem: nie, to jest właśnie ta bajka o nazwie analiza wymagań i projektowanie, które powinny być zrozumieniem a nie tylko stenogramem. Wtedy nowe funkcjonalności oprogramowania można dodawać bez potrzeby przebudowy jego wewnętrznej struktury. Nie raz jest z powodu tych kosztów po protu niemożliwy jest rozwój systemu. Oceńcie teraz Państwo sami, Ci którzy tego doświadczyli, skutki wdrożenia np. systemu ERP z kastomizacją.... niestety ogromna większość tego oprogramowania nie spełnia zasady SOLID. Dlaczego? Bo model relacyjny baz danych, jeżeli obejmuje wszystkie dane systemu, niestety nie spełnia tej zasady z założenia. A dostawcy tych systemów wręcz cieszą się z tego reklamując się: "nasz system jest w pełni zintegrowany poprzez pracę na wspólnej bazie danych".... Jak to przeczytasz, nie kupuj tego...

Czytaj dalejAnaliza wymagań na oprogramowanie czyli opisanie czy zrozumienie

Dlaczego nie podoba mi się klasa Pracownik?

Swego czasu pod artykułem Business Model vs. System Model, wywiązała się dyskusja, po tym jak napisałem, że oprogramowanie reprezentuje narzędzie pracy, więc projekt tego oprogramowania raczej powinien zawierać pojęcie (klasę) Karteka Pracowników a nie Pracownicy. Jeden z czytelników napisał wtedy (dociekliwym polecam w tym momencie cała tę dyskusje pod artykułem):... byt Pracownik jak najbardziej ma sens. Przecież tu jest zdefiniowane jego zachowanie (część jedynie z real world, ale jednak). Pracownik.pijeKaweRano().. przeciez nie KartotekaPracownika.pijeKaweRano() (Business Model vs. System Model).Gdzie problem?[...]No więc dlaczego nie podoba mi się klasa Pracownik? Bo pracownik to Aktor Systemu, a System ten przechowuje wybrane dane o tym pracowniku. Są to dane potrzebne np. do identyfikowania osób wystawiających dokumenty z Systemu, a do tego potrzebne są jedynie Karty Pracowników a nie Pracownicy. System (oprogramowanie) zastąpił papierowe Kartoteki Magazynowe dlatego są one teraz w Systemie, ale towary są w nadal magazynie 9a nie w Systemie), system "ma w środku" Kartę Towaru (zastąpiła papierową) zawierająca opis towaru i jego ilość w magazynie. Kartoteka Magazynowa to pudło zawierające Karty Towarów. Faktura VAT to obiekt w systemie, można ją wydrukować lub wysłać jej egzemplarz w postaci elektronicznej kontrahentowi.

Czytaj dalejDlaczego nie podoba mi się klasa Pracownik?

Utopia – czyli model ideału pomaga w projektach

Ten wpis adresuję przede wszystkim menedżerom nie tylko IT. Analitycy i programiści spokojnie mogą go pominąć, chyba, że ...;) chcą wiedzieć dlaczego powinny powstawać idealne projekty, kiedy mogą czasem wykonać niekoniecznie idealną implementację i dlaczego nie należy pomijać etapu idealnego projektowania. [...] Na zakończenie przyznam, że wśród moich niedoszłych klientów i programistów mam wielu wrogów. To Ci, którzy uważają, że analizy i projektowanie całości (co by tu słowo całość nie miało oznaczać) na samym początku są bez sensu, bo i tak wymagania biznesu się zmienią, więc i program będzie się zmieniał. Ja wtedy pytam: zmieniał czy rozszerzał? Jeżeli wymagania się zmieniają to raczej sygnał, że nie zostały na początku przemyślane... Biznes także ma skłonności do zaciągania opisywanego długu... Na koniec w kwestii wrogów pół żartem i pół serio:Chińczycy hołdują powiedzeniu: ?jak posiedzisz wystarczająco długo nad brzegiem rzeki, to zobaczysz trupy swoich wrogów płynące z prądem". No więc sobie siedzę.... i nie raz je oglądam... a siedzę sobie analizując i projektując... ;) i nie jestem tu sam...

Czytaj dalejUtopia – czyli model ideału pomaga w projektach

Czym jest a czym nie jest tak zwany model dziedziny systemu

Taksonomia diagramów UML Ten artykuł to kontynuacja wątku rozpoczętego wpisem o modelu dziedziny i diagramie klas, jednak inna jest intencja. Wśród wielu listów i pytań od studentów i pracujących już analityków, na temat UML, regularnie pojawia się pytanie o diagram klas i modelowanie tak zwanej dziedziny systemu. Gdy odpowiadam często pojawia się zarzut, "a tam napisano, że...". Ten artykuł to między innymi chęć zwrócenia uwagi na to, że w sieci i wielu książkach niestety mamy nie mało tak zwanej pseudowiedzy... Z zasady nie oceniam treści innych stron, jednak trudno zignorować coś,…

Czytaj dalejCzym jest a czym nie jest tak zwany model dziedziny systemu

Relacja z konferencji Cloud Solutions 23.01.2013, Warszawa

  23 stycznia w Warszawie odbyła się premierowa edycja konferencji Cloud Solutions, zorganizowana przez Platinium Cast, pod honorowym patronatem Ministra Administracji i Cyfryzacji Michała Boniego. Podczas konferencji poruszono tematy związane z  bezpieczeństwem  przetwarzania danych, prywatnością oraz regulacjami prawnymi w stosunku do Cloud Computingu.   Partnerami konferencji były firmy: Oktawave, Signati, NetApp. Pan Michał Kuźniar i Dariusz Nawojczyk z firmy Oktawave, która jest innowacyjną platformą infrastruktury na żądanie (IaaS), w ramach której istnieje możliwość uruchomienia, przetwarzania czy  przechowywania dowolnych zasobów( strony WWW, aplikacji biznesowej, etc.), opowiedzieli  o Autoskalerze w chmurze jako zmianie  w…

Czytaj dalejRelacja z konferencji Cloud Solutions 23.01.2013, Warszawa
Read more about the article Przetarg czyli wycena projektu…
#1 - a 3d render series showing change and motion

Przetarg czyli wycena projektu…

O przetargach napisano tak wiele krytycznych tekstów, więc po co ten? Nie będę się tu pastwił nad nimi. Zastanawia mnie co innego, i tu mała krytyka... W prasie pojawiły się doniesienia o rozstrzyganym przetargu ogłoszonym przez [[ARiMR]]: Asseco Poland za swoje prace zaproponowało 40,65 mln zł, a Sygnity 43,98 mln zł. W przetargu startowały też: konsorcjum ze spółką zależną Asseco - ZETO Łódź (29,36 mln zł) i konsorcjum z Infovide-Matrix (31,75 mln zł). Wybrana poprzednio [[oferta konsorcjum IT Works i Almaviva]] opiewała na 9,92 mln zł. Przetarg realizowany był według…

Czytaj dalejPrzetarg czyli wycena projektu…

Analityk to nie dyktafon

Dzisiaj żadnych technicznych mądrości ;) [...] Tak więc wymagania na oprogramowanie to minimalna liczba (specyfikacja) warunków, których spełnienie potwierdza przydatność tego oprogramowania do określonego celu. Oznacza to, że przede wszystkim należy określić cele! Jeżeli nie znajdziemy takiego oprogramowania na rynku, wtedy należy wykonać studium wykonywalności projektu dedykowanego oprogramowania.Jak określać cele? Przypadek użycia, wymagana usługa systemu, to nic innego jak właśnie cel. Celem jest możliwość wystawiania dokumentów XXX, celem jest generowanie raportów kontrolnych wykonania planu produkcji i obciążenia maszyn. Jeżeli system jest duży, celem (jednostka opisu wymagań) jest wsparcie procesu obsługi zamówień (i opis tego procesu jako załącznik). Ale nie jest dobrym celem zakupu oprogramowania: "rozwijana lista kontrahentów na ekranie tworzenia nowej faktury" czy "możliwość wprowadzenia nazwy ulicy, kodu i nazwy miasta w kartotece klienta".Jak mam nadzieję widać, nie bardzo ma sens porywanie się na zakup "wielkiego pakietu zintegrowanego", bo jak tu opracować w rozsądnym czasie i koszcie, specyfikację wymagań? Opracować listę celów wszystkich komórek organizacyjnych???? Jak zagwarantować jej niezmienność (zakres projektu), jeżeli taki projekt trwa np. pięć lat? Życzę powodzenia...

Czytaj dalejAnalityk to nie dyktafon

Gdzie się realizują wymagania

Bardzo często spotykam, pewnie nie ja jeden, specyfikacje wymagań zawierające zapisy "oczekiwań użytkowników". Bardzo często słyszę także, że to przyszły użytkownik oprogramowania powinien być źródłem wymagań. nic bardziej błędnego.. [...] Więc np. wymaganie "system powinien pozwalać na budowanie dowolnych rabatów sprzedaży do stałych klientów" (także cytat z pewnej specyfikacji systemu CRM) jest pustym stwierdzeniem. Po pierwsze jak te rabaty są naliczane, po drugie czy aby na pewno mechanizm pozwala na "dowolne rabaty"... Jak to opisać? Tu powinny się pojawić np. tablice decyzyjne a nie lakoniczne "dowolne rabaty".Na zakończenie uwaga: jeżeli planujemy kupić gotowe oprogramowanie, to ono już (gdzieś tam) istnieje, i specyfikowanie szczegółów opisujących dokładnie elementy pracy z interfejsem użytkownika i enigmatyczne opisy tego jak "system liczy", jest bezwartościowe. Raczej wywoła listę tak zwanych kastomizacji (zwanych gdzieniegdzie zabójcami projektów :)). Tak jednak właśnie wyglądają najczęściej specyfikacje pisane rękami przyszłych użytkowników: opiszą oni to z czym się stykają i co znają ale w ogóle nie opiszą wnętrza, którego najczęściej po protu nie rozumieją (i nie muszą bo to nie ich rola), wtedy specyfikacje systemów CRM pisane rękami przyszłych użytkowników - np. sprzedawców - zawierają właśnie bezwartościowe zapisy w rodzaju: "system powinien pozwalać na budowanie dowolnych rabatów sprzedaży do stałych klientów" a nie zawierają opisu jak te rabaty wyliczać. Odpowiadając na tytułowe pytanie: wymagania (funkcjonalne) realizują się w modelu dziedziny systemu, którego nie zawiera większość znanych specyfikacji wymagań... a warunkiem poprawnego wyboru oprogramowania są oczekiwania co do efektów przetwarzania.

Czytaj dalejGdzie się realizują wymagania

Tablice decyzyjne

Wiele firm ma problemy zarządcze nie dlatego, że są źle zarządzane, ale dlatego, że stopień złożoności tych firm jest zbyt duży by podejmować je na wyczucie. W obecnych czasach decyzje muszą być podejmowane w relatywnie krótkim czasie bo rynek nie czeka, jednak jakość tych decyzji nie powinna być zła. Dlaczego bywa zła? Bo decyzje są nie raz podejmowane z niepełnym zrozumieniem sytuacji. Podejmowana decyzja, by była możliwie najlepsza, wymaga pełnego zrozumienia, tego czego dotyczy (co chyba nie jest dziwne). Jeżeli dotyczy firmy, nie powinno się podejmować decyzji bez pełnego zrozumienia potencjalnego wpływu tej decyzji na firmę. W przeciwnym wypadku skutki są dość losowe, czyli nie zarządzamy a staramy się zarządzać.[...] Analiza biznesowa organizacji poprzedzająca np. wdrożenie nowego oprogramowania, powinna polegać na wykonaniu audytu i uporządkowaniu reguł decyzyjnych oraz opracowaniu modeli procesów biznesowych by je zweryfikować. Drugi krok to ocena, jakiej wiedzy oczekujemy od ludzi (ich umiejętności i wiedza). Dokumentujemy ją z obawy przed "błędem ludzkim". Tu zwracam uwagę na to, że wymaganiem na oprogramowanie może być tablica decyzyjna, jeżeli planujemy automatyzację jakiejś czynności. Proces biznesowy nie jest wymaganiem, to co najwyżej kontekst wykonywanych czynności.

Czytaj dalejTablice decyzyjne

Tablice decyzyjne – fakty a nie procesy

Tak więc, reguły biznesowe to ogólno-organizacyjne ograniczenia. Tablice decyzyjne to rodzaj "wiedzy" wpisanej w punkty podejmowania decyzji. Na modelach (diagramach) procesów biznesowych modelujemy jedynie skutki, czyli reakcje na podjęte - zgodnie z tablicą - decyzje.Gdyby modelować powyższe na diagramie np. BPMN, mielibyśmy bramkę z czterema wyjściami, każde wyjście reprezentował by wiersz Działań. Jak widać spodziewać się należy tu bramek XOR (alternatywa wyłączna) lub OR (alternatywa "zwykła"). Na diagramach BPMN za bramką byłyby czynności nazwane tak jak działania w wierszach. Aby nie komplikować nazewnictwa tych diagramów, tablica decyzyjna użyta z diagramem BPMN miała by wiersze Działań nazwane np. odpowiednio Wariant-1, Wariant-2 itd. a czynności były by umieszczone już na diagramie.Tego typu tablice doskonale nadają się do modelowania systemów rabatowych, lojalnościowych, wartości kredytów kupieckich, wag scoringu kredytów i wielu innych, w których kombinacje skończonej liczby czynników tworzą deterministyczną, skończoną liczbę dopuszczalnych zachowań. Na diagramie procesu powołujemy się wyłącznie na nazwę tablicy (np. kojarząc ją z konkretną czynnością) zamiast modelować skomplikowane przebiegi. Dlaczego? Bo warto pamiętać, żedecyzja - nawet bardzo skomplikowana - nie jest procesem a zaistniałym faktem, odpowiedzią na zastane warunkiJak widać, reakcja kierowcy na sygnalizator, to nie proces a fakt. Jest to konkretna reakcja na konkretną kombinację kolorów świateł na sygnalizatorze.W przypadku analizy wymagań, stosowanie tablic decyzyjnych, jako narzędzia specyfikowania pewnych zachowań systemu, jest bardzo wygodne bo po pierwsze: jest jednoznaczne, po drugie tablice decyzyjne to już standardowe narzędzie w inżynierii oprogramowania i nie trzeba wymyślać ich implementacji (np. w postaci maszyny stanowej: reguły to zdarzenia a działania do przejścia).

Czytaj dalejTablice decyzyjne – fakty a nie procesy

Koniec treści

Nie ma więcej stron do załadowania