Strona poświęcona mojej pracy naukowej i usługom jakie świadczę polskim podmiotom. Zapraszam tych którzy szukają wiedzy i tych którzy szukają wsparcia w swoich projektach informatyzacji.
Cyfrowa Transformacja Organizacji: wiedza ogólna bezpłatnie na blogu, mój czas dedykowany dla Twojej Firmy tu:
Nie raz pojawiały się tu (mój blog) odniesienia do tak zwanego ideału (idealizacja ) jako wzorca lub szkieletu. W artykule o studium wykonalności pisałem:
Dzisiaj kilka słów o jednym z „kilerów” projektów analitycznych: utrata panowania nad szczegółowością.
Detale, detale…
Praktycznie zawsze w toku odbioru wyników prac analitycznych słyszę: „ale tu nie ma wielu rzeczy”. I jest to prawda, ale nie ma (zostały po protu pominięte) rzeczy nieistotnych z perspektywy analizy i jej celu. Firmy istnieją i rozwijają się latami, nie raz nawet kilkadziesiąt lat. W tym czasie „obrastają” w różne lokalne „sposoby”, mnóstwo wariantów osiągania konkretnych, tych samych celów, nawet tych malutkich lokalnych. Bywają ich setki. Bardzo popularnym, wśród firm dostarczających oprogramowanie, sposobem „analizowania” jest pisanie tak zwanych user story (historyjki użytkownika). Są to, opisane słowami pracownika analizowanej firmy, zdarzenia stanowiące podstawę „zrozumienia” jak dana organizacja działa. Metoda ta jest obciążona poważną wadą:
User story to perspektywa użytkownika i to skażona jego ograniczoną wiedzą lub jej brakiem oraz ograniczonym doświadczeniem lub brakiem doświadczenia. Duże, zdobyte w jednym miejscu, doświadczenie pracownika, bez głębszej i szerszej analizy, też nie poprawia sytuacji, częściej ją jeszcze pogarsza (bo nikt nie podejmuje dyskusji z tym ?dużym doświadczeniem?). (Źródło: User story czyli nic nie poprawić a może nawet bardziej skomplikować | | Jarosław Żeliński IT-Consulting
Opisy te bywają nie raz bardzo bogate, zebrane w toku wielogodzinnych, tak zwanych, warsztatów lub ankiet. Spisywane są nie raz ogromne ilości detali, które zamiast cokolwiek wyjaśnić, zaciemniają istotę rzeczy.
Powyższe zdjęcie przedstawia coś co nazwę „stanem obecnym”. To widok jaki zastaje ktoś, kto spojrzy na daną organizację „teraz”. Opisanie tego co widzimy może zająć elokwentnej osobie nawet wiele stron tekstu. Czy opis ten przybliży nas choć troszkę do odpowiedzi na pytanie „co to jest i jak to działa”?
Celem analizy jest zrozumienie, z czym na prawdę mamy do czynienia. Analityk swoją pracą powinien doprowadzić do powstania dokumentu (modeli…) obrazujących „istotę rzeczy”, powinien w końcu odkryć, że powyższe to jest to:
Jeżeli więc mamy opracować rekomendacje do zmian, zaprojektować oprogramowanie, to albo zrozumiemy co i po co dana firma robi, czym na prawdę jest, albo zabrniemy w dokumentowanie ogromnej liczby detali, dotychczasowych sposobów osiągania celów, co potrafi „zabić projekt” swoją szczegółowością (i zabetonować, nie koniecznie dobry, stan obecny).
Przeprowadzenie analizy ma jeden cel: zrozumieć. Nie jest jej celem „opisywanie” czegokolwiek. Niestety wiele firm pomija analizy, idzie ścieżką „opiszemy co robimy i wystarczy”.
Czego się spodziewać po projekcie, gdy słyszę: nie ma czasu na analizę, myśmy już podpisali umowę z wykonawcą bo nasza firma nie ma czasu. Niestety najczęściej taki projekt trwa znacznie dłużej niż planowano, pieniądze oszczędzone na ?zbędnym? projektowaniu ideału z ogromna nawiązką są wydawane na kolejne modyfikacje i poprawki (Źródło: Utopia ? czyli model ideału pomaga w projektach | | Jarosław Żeliński IT-Consulting)
Tak więc, dokumentacja zawierająca 10 diagramów procesów biznesowych prawie zawsze będzie lepsza od tej zawierającej 100 diagramów. Ta, która nie zawiera żadnego, jednak będzie znacznie gorsza.….
Polecam świetną książkę na ten temat, w której autor pisze we wstępie:
Projektowanie ideału jest takim sposobem myślenia o zmianie, który można przedstawić w sposób: w rozwiązywaniu problemów, praktycznie dowolnego rodzaju, można uzyskać najlepsze wyniki dzięki wyobrażeniu sobie idealnego rozwiązania, a następnie cofnięciu się aż do miejsca, w którym znajdujesz się w chwili obecnej. Dzięki temu unikniesz urojonych przez siebie przeszkód, zanim jeszcze w ogóle pojmiesz, jaki ma być ideał. .
Niaz, M. (1993). If Piaget’s epistemic subject is dead, shall we bury the scientific research methodology of idealization? Journal of Research in Science Teaching, 30(7), 809 – 812. https://doi.org/10.1002/tea.3660300717
Ackoff, R. L., Magidson, J., Addison, H. J., & Ehrlich, A. (2007). Projektowanie ideału: kształtowanie przyszłości organizacji. Wyższa Szkoła Przedsiębiorczości i Zarządzania im. Leona Koźmińskiego : Wydawnictwa Akademickie i Profesjonalne.
Liu, C. (2004). Laws and Models in a Theory of Idealization. Synthese, 138(3), 363 – 385.
Jarosław Żeliński: autor, badacz i praktyk analizy systemowej organizacji: Od roku 1991 roku, nieprzerwanie, realizuje projekty z zakresu analiz i projektowania systemów, dla urzędów, firm i organizacji. Od 1998 roku prowadzi samodzielne studia i prace badawcze z obszaru analizy systemowej i modelowania (modele jako przedmiot badań: ORCID). Od 2005 roku, jako nieetatowy wykładowca akademicki, prowadzi wykłady i laboratoria (ontologie i modelowanie systemów informacyjnych, aktualnie w Wyższej Szkole Informatyki Stosowanej i Zarządzania pod auspicjami Polskiej Akademii Nauk w Warszawie.) Oświadczenia: moje badania i publikacje nie mają finansowania z zewnątrz, jako ich autor deklaruję brak konfliktu interesów. Prawa autorskie: Zgodnie z art. 25 ust. 1 pkt. 1) lit. b) ustawy o prawie autorskim i prawach pokrewnych zastrzegam, że dalsze rozpowszechnianie artykułów publikowanych w niniejszym serwisie jest zabronione bez indywidualnej zgody autora (patrz Polityki Strony).
Zgodzę się, że drążenie detali na początku analizy jest bezcelowa i zawsze warto wyjść od procesów, zrozumieć cele firmy i reguły, które w niej funkcjonują. Ale męczy mnie pytanie – co dalej? Przecież jakieś oprogramowanie trzeba jednak wytworzyć, a na podstawie samych modeli procesów i reguł, nawet najlepiej udokumentowanych, może być ciężko. Czy po zamodelowaniu przedsiębiorstwa praca analityka się kończy? Czy nie powinien brać udziału we właściwej produkcji rozwiązania, w analizie jego funkcjonalności? Czy wtedy właśnie wspomniane wyżej user stories (mając na uwadze nadrzędność analizy procesów) nie stają się przydatne?
1. Zaczynanie od procesów biznesowych i bazowanie na nich pozwala zweryfikować poprawność logiki całości i uniknąć odkrywania wymagań w trakcie wdrożenia, pozwala samemu zamawiającemu ocenić sens tego co zamawia. Przypominam, że modele procesów zawierają także: wzory dokumentów i reguły biznesowe. 2. Oprogramowanie to: interfejs użytkownika, formularze i ich zawartość (pola) oraz logika biznesowa (reguły przetwarzania zawartości tych pól), to tego ewentualne integracje (gdy jakąś logikę realizuje inne oprogramowanie).
Doskonałym wręcz sposobem jest podejście polegające na zaprojektowaniu przez analityka architektury logicznej oprogramowania. Metoda dobrze opisana w literaturze, bazuje na notacjach BPMN (procesy) a później UML (logika aplikacji). Pozwala przetestować całą logikę i wychwycić ewentualne błędy zanim jeszcze powstanie kod.
Moim zdaniem (i tak robię) analityk nie może „uciec” z projektu, od momentu rozpoczęcia implementacji staje się „product ownerem” (nadzór autorski i zarządzanie zmianą, kontakt z biznesem i developerem). Z mojego doświadczenia user story z ust przyszłego użytkownika ma taką wartość jak wyobrażenia blondynki (sorry ;)) o nowym samochodzie. Użytkownicy nie są specjalistami z zakresu inżynierii programowania a nawet z obszaru zarządzania…
Patrząc na gotowe oprogramowanie widać, że składa się ono ze skończonej ilości wprowadzanych informacji, grupowanych w formularze. Produktem pracy oprogramowania są te same (archiwum) dane lub dane nowe lub zmienione będące wynikiem przetwarzania. Przetwarzanie to reguły biznesowe i ewentualne wzory matematyczne.
Złożoność tkwi w ilości związków między tymi danymi a nie w pracy ludzi. Analiza polega na zrozumieniu tych związków i udokumentowaniu ich a nie na zapisaniu co robią ludzie w firmie (bo robią masę rzeczy na masę różnych sposobów). Ewentualne detale i „bajery” w aplikacji zaprojektuje projektant GUI (UX designer).
Zgodnie z art. 25 ust. 1 pkt. 1) lit. b) ustawy o prawie autorskim i prawach pokrewnych zastrzegam, że dalsze rozpowszechnianie artykułów publikowanych w niniejszym serwisie jest zabronione. Ewentualne użycie treści wymaga indywidualnej zgody autora.
Nie wykryto skryptu Javascript. Javascript wymagany do działania tej strony. Proszę włączyć go w ustawieniach przeglądarki i odświeżyć tę stronę.
Zarządzaj zgodami plików cookie
Aby zapewnić jak najlepsze wrażenia, korzystamy z technologii, takich jak pliki cookie, do przechowywania i/lub uzyskiwania dostępu do informacji o urządzeniu. Zgoda na te technologie pozwoli nam przetwarzać dane, takie jak zachowanie podczas przeglądania lub unikalne identyfikatory na tej stronie. Brak wyrażenia zgody lub wycofanie zgody może niekorzystnie wpłynąć na niektóre cechy i funkcje.
Funkcjonalne
Zawsze aktywne
Przechowywanie lub dostęp do danych technicznych jest ściśle konieczny do uzasadnionego celu umożliwienia korzystania z konkretnej usługi wyraźnie żądanej przez subskrybenta lub użytkownika, lub wyłącznie w celu przeprowadzenia transmisji komunikatu przez sieć łączności elektronicznej.
Preferencje
Przechowywanie lub dostęp techniczny jest niezbędny do uzasadnionego celu przechowywania preferencji, o które nie prosi subskrybent lub użytkownik.
Statystyka
Przechowywanie techniczne lub dostęp, który jest używany wyłącznie do celów statystycznych.Przechowywanie techniczne lub dostęp, który jest używany wyłącznie do anonimowych celów statystycznych. Bez wezwania do sądu, dobrowolnego podporządkowania się dostawcy usług internetowych lub dodatkowych zapisów od strony trzeciej, informacje przechowywane lub pobierane wyłącznie w tym celu zwykle nie mogą być wykorzystywane do identyfikacji użytkownika.
Marketing
Przechowywanie lub dostęp techniczny jest wymagany do tworzenia profili użytkowników w celu wysyłania reklam lub śledzenia użytkownika na stronie internetowej lub na kilku stronach internetowych w podobnych celach marketingowych.
Zgodzę się, że drążenie detali na początku analizy jest bezcelowa i zawsze warto wyjść od procesów, zrozumieć cele firmy i reguły, które w niej funkcjonują. Ale męczy mnie pytanie – co dalej? Przecież jakieś oprogramowanie trzeba jednak wytworzyć, a na podstawie samych modeli procesów i reguł, nawet najlepiej udokumentowanych, może być ciężko.
Czy po zamodelowaniu przedsiębiorstwa praca analityka się kończy? Czy nie powinien brać udziału we właściwej produkcji rozwiązania, w analizie jego funkcjonalności? Czy wtedy właśnie wspomniane wyżej user stories (mając na uwadze nadrzędność analizy procesów) nie stają się przydatne?
1. Zaczynanie od procesów biznesowych i bazowanie na nich pozwala zweryfikować poprawność logiki całości i uniknąć odkrywania wymagań w trakcie wdrożenia, pozwala samemu zamawiającemu ocenić sens tego co zamawia. Przypominam, że modele procesów zawierają także: wzory dokumentów i reguły biznesowe.
2. Oprogramowanie to: interfejs użytkownika, formularze i ich zawartość (pola) oraz logika biznesowa (reguły przetwarzania zawartości tych pól), to tego ewentualne integracje (gdy jakąś logikę realizuje inne oprogramowanie).
Doskonałym wręcz sposobem jest podejście polegające na zaprojektowaniu przez analityka architektury logicznej oprogramowania. Metoda dobrze opisana w literaturze, bazuje na notacjach BPMN (procesy) a później UML (logika aplikacji). Pozwala przetestować całą logikę i wychwycić ewentualne błędy zanim jeszcze powstanie kod.
Moim zdaniem (i tak robię) analityk nie może „uciec” z projektu, od momentu rozpoczęcia implementacji staje się „product ownerem” (nadzór autorski i zarządzanie zmianą, kontakt z biznesem i developerem). Z mojego doświadczenia user story z ust przyszłego użytkownika ma taką wartość jak wyobrażenia blondynki (sorry ;)) o nowym samochodzie. Użytkownicy nie są specjalistami z zakresu inżynierii programowania a nawet z obszaru zarządzania…
Patrząc na gotowe oprogramowanie widać, że składa się ono ze skończonej ilości wprowadzanych informacji, grupowanych w formularze. Produktem pracy oprogramowania są te same (archiwum) dane lub dane nowe lub zmienione będące wynikiem przetwarzania. Przetwarzanie to reguły biznesowe i ewentualne wzory matematyczne.
Złożoność tkwi w ilości związków między tymi danymi a nie w pracy ludzi. Analiza polega na zrozumieniu tych związków i udokumentowaniu ich a nie na zapisaniu co robią ludzie w firmie (bo robią masę rzeczy na masę różnych sposobów). Ewentualne detale i „bajery” w aplikacji zaprojektuje projektant GUI (UX designer).
o szczegółach więcej tu:
http://it-consulting.pl/autoinstalator/wordpress/2014/06/18/gdzie-sa-te-cholerne-szczegoly/