Temat: Od modelu biznesowego do wymagań na system
Jarosław prosi o wypowiedzi z punktu widzenia modeli biznesowych, a tu o wyższości programowania strukturalnego nad obiektowym albo odwrotnie :(
Jak wiadomo, jestem sceptyczny w odniesieniu do wymyślonej i lansowanej roli informatyki w biznesie. Właśnie z punktu widzenia modeli biznesowych.
Najpierw podsumuję punkty krytyczne w moich dotychczasowych wypowiedziach:
1. Rzecz absolutnie zasadnicza - rola komputera. Wcale nie podobają mi się marzenia informatyków, aby uczynić komputer uczestnikiem procesu biznesowego, na równi z człowiekiem (chociaż rozumiem, że marzenia to rzecz przyjemna). To po prostu nie może dobrze pracować.
Przykład: workflow, uważany przez informatyków za jedno z czołowych osiągnięć w budowaniu systemów enterprise. No i ten workflow nie pracuje, ponieważ ludzie podejmują sami decyzję, co będą robić, a co odłożą na później albo na nigdy. Szefowie w przedsiębiorstwach donoszą, że workflow pracuje tylko wtedy, gdy za "niesubordynację" pracownicy są karani. Więc po co ta niesłychanie skomplikowana maszynka workflow, skoro to nie problem informatyczny tylko problem dyscypliny, poczucia obowiązku itp. - problem ludzi po prostu? Nie lepiej pozostawić te karteczki listy "To Do" i dziennik podawczy, które także nie działają, ale są tańsze?
Gdy się do workflow dołoży zasadę eskalacji (przekazywania wyżej zadań niewykonanych), to mamy już pełen bałagan i rozregulowanie procesów! Kto u diaska wymyśla takie reguły sterowania, które są dalekie od optymalnych????
Zamiast tego trzeba sobie zadać pytanie o podział zadań pomiędzy operatora i maszynę. Komputera używam jako narzędzia, moi koledzy i współpracownicy też. Ma przetwarzać tworzywo, czyli informacje, tak jak ja chcę, a nie tak, jak chce projektant "systemu" wymodzonego z sufitu. Sorry, nie z sufitu tylko z "analizy systemowej". Dokładnie wbrew zasadom usprawniania procesów, które każą usprawniać proces jaki jest, a nie jakiś idealny, systemowy.
Zatem chcę mieć komputer przy pomocy którego wyciągnę z bazy potrzebne mi dane, zestawię je, pomyślę nad analizą i każę komputerowi coś do niej policzyć. To wszystko.
Prosty przykład. Po zainstalowaniu w wydawnictwie ERP mój pracownik chciał wystawić przy jego pomocy fakturę i nie mógł. Mimo że oczywiście był na to sposób, ale ukryty głęboko, bo projektant wymyślił, że "złożoność systemu należy ukryć przed Użytkownikiem, którego ona nie powinna obchodzić". Sorry, a jakie jest uzasadnienie na tego rodzaju "paradygmat", oprócz prywatnych teoryjek projektanta o Użytkownikach?
Więc ów pracownik nie mógł użyć komputera jako narzędzia.
Ismael Chang Ghalimi przedstawił we Wrocławiu przykład komputera biorącego udział w procesie biznesowym, wykonując POZA KONTROLĄ UŻYTKOWNIKA krytyczne operacje. Sorry, dlaczego tak? Autonomizacja maszyny przecież nie tak wygląda, wystarczy poczytać i przejść się po hali fabrycznej z automatami do obróbki. No i trzeba chcieć się nauczyć czegoś z podobnych przykładów.
Siedzę teraz nad swoimi wynalazkami, które wymagają wsparcia komputerem. Chcę zmontować maszynę do bardzo prostych operacji, z istniejących aplikacji. No i co trafię na aplikację, to nie działa. Żadna! Mimo że wszystkie są zrobione dla tego samego środowiska. Przyczyna? Zaprojektowano je z myślą o działaniu w systemie z innymi komponentami systemu, znacznie na wyrost, nie zaś z myślą o działaniu na życzenie Użytkownika.
No i z tymi doświadczeniami nijak nie mogę pojąć, jak można wymyślać systemy działające dla systemów. Znam setki systemów produkcyjnych i wszystkie są urządzeniami społeczno-technicznymi mającymi sprecyzowane przeznaczenie, podatne są na przeróbki, zrozumiałe dla Użytkowników itd. A do czego służy ERP, jakie jest jego przeznaczenie? Gdy pytam o to informatyków, pieprzą o bazach danych, klasach i zmiennych itd. To nie jest odpowiedź!
2. Koncepcja SOA dlatego mi się spodobała, że na pierwszy rzut oka wygląda na wyłom w tradycji informatyki. Że realizowana jest w postaci szkieletu, do którego ponoć mogę podczepić usługi wedle swoich potrzeb, jako użytkownik. Podobnie jak mogę zamontować taki albo inne narzędzie do obrabiarki wielowrzecionowej.
No ale okazuje się, że znowu nie to, że programiści klną na to jak szewcy, a szefowie informatyki usiłują wiązać tym swoje "legacy", które nie pasują do siebie ze swej natury, wszak każdy producent wpuszcza klientów w maliny swoimi wewnętrznymi zamkniętymi standardami. Jeden tylko przypadek jest mi znany, gdy firmy ubezpieczeniowe w Niemczech rozpędziły tych szarlatanów na cztery wiatry.
3. Gdy słucham różnych architektów na konferencjach, jak pokazują przykłady zastosowań UML i BPMLów, to włosy stają mi dęba. "Tu sobie napiszemy klasę wysyłania odpowiedzi na reklamację klienta, a tu będziemy sobie mieli analogicznie wyglądającą klasę wysyłania pracownika na szkolenie". Może nieco przesadzam, ale nie bardzo. Pełna dowolność! Wyobraźnia projektanta ponad wszystko, całkowita sufitologia.
4. W Wikipedii jest przykład procesu opisanego w BPMN bodajże. To proces wspomagający aukcję elektroniczną. W schemacie widać jak na dłoni pewien nonsens, błąd w projekcie procesu. Gdy pytam o to informatyków, naskakują na mnie, że przecież "takie są wymagania dla procesu aukcji, uwarunkowane przepisami itp.". No to ja się pytam, jaka jest rola projektanta? Czy projektant to gość, który zapisuje bzdury bo "takie są wymagania"? Godzi się na komputeryzację nonsensów i bałaganu? "On jest tylko od tego"? Wydawało mi się, że rolą projektanta jest również zwalczanie nonsensów. Ale może niedzisiejszy jestem, za bardzo wierzę w dorosłość dorosłych ludzi...
Na razie tyle.
пропозиції роботи
