Wąskim gardłem jest przejście z procesów na model dziedziny i przypadki użycia, które to tak na prawdę powinny być sprowadzone jeden do jednego do modułów (klas) wykonawczych np. widoku i kontrolera wzorca MVC (który bardzo lubię :)) a model dziedziny wchodzi jeden do jednego w Model w MVC.
Tak więc moim zdaniem zarządzanie wiedzą to nie tylko jej gromadzenie i udostępnianie, ale przede wszystkim selekcja! Nasz mózg robi dokładnie to samo: zapomina o wszystkim co nie jest bezpośrednio używane do bieżącego życia i przeżycia.Na pewno nie jest to miejsce na streszczanie takich konferencji ale w jednej z prezentacji pojawiło się ważne stwierdzenie: retencja danych (gromadzenie ich, tu w kontekście wiedzy należy rozumieć: celowo, wybiórczo i w kontrolowany sposób). Jest to moim zdaniem druga najważniejsza cecha systemów zarządzania wiedzą (pierwszą była powiązana z tym pojęciem selekcja danych).
Coraz częściej spotykam się w ?prasie internetowej? czyli w blogach i komentarzach na temat ich wartości z przypadkami manipulowania ich treścią. Dotyczy to z jednej strony koniunkturalnej zmiany treści wpisów czy wręcz usuwania chwilowo niewygodnych (szczególnie dotyczy to blogów polityków ale nie tylko) a z drugiej ustalania autorstwa treści gdzie w zasadzie łatwo to określić po pierwszeństwie publikacji (na szczęście manipulowanie datami wpisów jest już dość trudne).Na niwie własnego biznesu jak i takich jak powyższe wydarzeń mam wrażenie ( i "przepowiadam" :)), że doczekamy czasów gdy wiarygodność operatora ISP np. blogu będzie polegała na tym, że: - każdy wpis będzie opatrzony prawdziwą datą i czasem (niemodyfikowalnym przez autora blogu) - wpisy będą wersjonowane a usunięcie będzie możliwe wyłącznie przez administratora (np. na wniosek) a nie przez autora wpisu.
Tak więc: jak dostawca dużego ERP mówi, że duży ERP jest najlepszy to należy to traktować tak samo jak ofertę dostawcy dużego zestawu garnków ze stali nierdzewnej, z których i tak na co dzień używamy jednego a naleśniki i tak robimy z pomocą kupionej wcześniej dobrej teflonowej patelni bo do naleśników lepsza a zamiana jej na nową z nierdzewki tylko dlatego, że "z kompletu" przeczy zdrowemu rozsądkowi i używa się jej mimo, że pokrywka z zestawu lekko wystaje ... ale przykrywa bo taki jest jej główny cel (w zasadzie tylko nie powinna być mniejsza ani zbyt duża).
Z danymi jest troszkę tak jak z pieniędzmi i ludźmi: samo posiadanie pieniędzy z nikogo jeszcze nie uczyniło wielkiego człowieka co nie zmiania faktu że wielu stale i za wszelką cenę próbuje tylko mieć dużo pieniędzy. Posiadanie dużej ilości danych (w hurtowni) nie czyni z nich ani wiedzy ani narzędzia wspomagającego podejmowanie decyzji.
(więcej…)
Ciekawe jest to, że dostawcy i wykonawcy oprogramowania często zawyżają wartość swoich usług w zasadzie na życzenie zamawiających. Robią nie ze złej woli, robią to bo zamawiający niejako sami o to proszą. Dyskutuję przy okazji projektów z wieloma programistami, projektantami, wdrożeniowcami i prawie wszyscy mówią jedno: to zamawiający ma określić swoje wymagania, jeśli określi jej zbyt ogólnikowo musimy w ofercie założyć margines bezpieczeństwa kosztów na wszelkie zmiany i uściślenia jakie klient najprawdopodobniej wniesie podczas realizacji tak słabo udokumentowanego projektu. Korekty będą na pewno bo na podstawie “jednej strony” opisu wymagań nie da się stworzyć miarodajnego projektu, twórca oprogramowania będzie więc gdybał na koszt zamawiającego. To z tego powodu, moim zdaniem, popularne są metody odkrywania wymagań poprzez kolejne prototypy. Programista sam nie określi wymagań ale będzie żądał pieniędzy za te prototypy no bo przecież nie będzie dopłacał do swoich usług.
Na stronie serwisu http://www.samorzad.pap.pl pojawił się ciekawy artykuł: Serwis jak labirynt. Nie licząc zamieszczonej listy powodów trudności w korzystaniu z serwisów WWW Urzędów (przebadano cztery z Małopolski) pojawiły się przykłady typowych kłopotów: ?Dodatkowym problemem jest sam opis tego elementu [elementy menu na stronie, przyp. red.] (?Katalog usług. Poradnik interesanta.?). Nie jest to język, którym posługują się użytkownicy. Szukając tej części serwisu szukali raczej linku ?załatw sprawę w urzędzie?, ewentualnie “e-urząd??. Jak podejść więc do tworzenia biznesowej firmowej strony WWW? Nie wierzyć w to, że strona WWW to portal Web 2.0, strona WWW dla firmy czy urzędu to po prostu kolejna aplikacja biznesowa, która musi (przepraszam, żyjemy w wolnym kraju: powinna) przynieść korzyści.
Specyfikacja wymagań powinna dokładnie opisywać procesy, to jakie dane i gdzie są potrzebne, z jakimi innymi systemami należy się zintegrować i wiele innych, istotnych z punktu widzenia zamawiającego i jego infrastruktury oraz potencjalnych kosztów. Teraz dopiero dostawca może dokonać rzetelnej wyceny a specyfikacja wymagań będzie odzwierciedlała potrzeby zamawiającego a nie możliwości dostawcy J.
?Termin SaaS pochodzi z języka angielskiego i jest skrótem wyrażenia ?Software as a Service?. W języku polskim jego odpowiednikiem jest termin ?Oprogramowanie jako usługa?. SaaS polega na zdalnym udostępnieniu oprogramowania poprzez Internet. W modelu SaaS udostępniana jest nie tyle sama aplikacja (nie następuje uruchomienie pełnej aplikacji na komputerze użytkownika), lecz umożliwia się interakcję z nią poprzez interfejs przeglądarki internetowej. Sama aplikacja znajduje się na serwerach dostawcy SaaS.? Jednak w prasie i nie tylko pojawiają się pewne mity o zaletach tej architektury. Jakie? Model aplikacji w architekturze SaaS Zanim wgłębimy się…
Po co to napisałem? Absolutnie nie była moim celem krytyka produktu, celem jest zwrócić Państwa uwagę na to by zawsze zapytać o to czy moduły oferowanego oprogramowania są samowystarczalne, czy mogą pracować z oprogramowaniem innych dostawców i jakie to oprogramowanie musi spełniać wymagania. Wybór monolitycznego pakietu to decyzja o tym, że wszystkie poszczególne moduły spełniają nasze wymagania. Nie dajcie się Państwo namawiać na kompromisy w rodzaju: ?ten moduł co prawda nie robi tego co Państwo chcecie ale jest konieczny by działał moduł XXX?.To prosta droga do zniszczenia pieczołowicie wypracowanych metod pracy w firmie. Reorganizacja przed wdrożeniem nie polega na przejęciu cudzych metod (procesów referencyjnych itp.) tylko na optymalizacji własnych!
Podstawową więc wyższością, dającą przewagę na rynku, jest zwinność organizacji mającej luźno powiązane elementy (zasoby, w tym informatyczne) współpracujące ze sobą na bazie ?kontraktów?. SOA to nic innego jak taka właśnie struktura systemu informatycznego: specjalizowane aplikacje, komponenty, instalowane (wdrażane) do realizacji konkretnych potrzeb zasobów takich jak pracownicy księgowości, pracownicy sprzedaży, pracownicy produkcyjni, itp.. W tym kontekście możliwe jest oszacowanie zwrotu z inwestycji w SOA jako wdrożenie sposobu realizacji strategii informatyzacji firmy. SOA jako projekt technologiczny bez podbudowy zarządczej moim zdaniem nie ma żadnego sensu gdyż to strategia zarządzania jest w stanie pokazać jakim kosztem jest sens tą strategie wdrażać. Pytanie o zwrot z inwestycji w SOA bez tej wiedzy moim zdaniem pozostanie bez odpowiedzi z powodu braku danych.
Każdy model procesów nie spełniający powyższych zasad można nazwać właśnie naiwnym modelem czyli takim, w którym dowolne symbole, bez zdefiniowanych zasad zostały połączone ze sobą tak jak usłyszano np. w rozmowie z pracownikiem analizowanej organizacji. Modele takie są bardzo często narzędziem do planowania zmian organizacyjnych, specyfikowania wymagań na systemy IT, specyfikowania centrów kosztów w metodach ABC zarządzania kosztami, w wielu innych sytuacjach. Użycie w którejkolwiek z tych potrzeb złego, naiwnego modelu skazuje cały projekt na niepowodzenie.Tak więc model procesów bez zdefiniowanej i rygorystycznie przestrzeganej semantyki (słownika symboli), syntaktyki (zasad dopuszczalnych relacji pomiędzy tymi symbolami), pragmatyki (co modelujemy i jak) należy odrzucić!
