Modelowanie przedsiębiorstwa stwarza dobrą możliwość analizy oraz kształtowania procesów działania. Dzięki temu można uniknąć problemów przy wprowadzaniu zmian. (Hubert H. Zimmermann). Produkt: Spójna, kompletna i niesprzeczna dokumentacja opisująca strategię organizacji,…
Od czasu do czasu w zakresie wymagań biznesowych pojawiają się (coraz częściej) potrzeby z obszaru szeroko rozumianego kontrolingu, który polega na zbieraniu danych w celu tworzenia wyrafinowanych raportów, bazujących na…
Tak więc OK, przemyciłem tu (mam nadzieję) ważne informacje:
– sama struktura to nie model,
– tworząc jakikolwiek model musimy rozumieć i opisać jego zachowanie, opisać mechanizm działania (zachowanie) każdego elementu tej struktury,
– dlatego model dziedziny systemu, czy w ogóle model jakiegokolwiek systemu, to tak na prawdę obiektowy model, który nie może być modelem anemicznym ([[anemiczny model dziedziny]]),
– bez zrozumienia mechanizmu działania organizacji, wprowadzając do niej jakiekolwiek zmiany, szczególnie wdrażając oprogramowanie, raczej jej zaszkodzicie niż pomożecie.
(dlatego też, diagramy ERD i tak zwane modele danych, pozbawione funkcji, nie są modelami czegokolwiek a jedynie określonym strukturami).
Wczoraj podczas spotkania, miałem ciekawą rozmowę z przedstawicielami jednego z producentów systemów ERP. Okazało się, że mają bardzo podobne do moich doświadczenia i wnioski: podczas wdrożenia systemu ERP potrzebny im…
Regularnie czytam blog Andrzeja Sobczaka, profesora SGH. Czasami bywa, że mam odmienne zdanie niż tam prezentowane, i tym razem też tak jest. Ostatni wpis na tym blogu zawiera siedmiopunktową prognozę na…
Jaki opis powstanie po przeprowadzeniu kilku dni warsztatów z graczami, którzy grają od lat, zasady gry znają na pamięć, bywa ze podejmują próby łamania zasad dla osiągnięcia doraźnych efektów? To będą długie, nie raz niespójne wywody. Każdą z wymienionych gier opisują jednak jednoznacznie dwa bardzo krótkie dokumenty: reguły gry oraz minimalne umiejętności i wiedza każdego z graczy. Z takim dokumentem każdy projektant oprogramowania sobie poradzi bez problemu.
Zakup oprogramowania, które stanowi jeden, zintegrowany współdzieleniem danych, monolit to nic innego jak zafundowanie sobie długu technologicznego w momencie podjęcia decyzji o takim zakupie. Żadna firma, działająca w obecnych czasach, nie da sama sobie gwarancji, że jej wewnętrzne aktywności nie zmienią się co do ich specyfiki, że nie przybędzie nowych, nie zrezygnuje z niektórych. Monolityczny całościowy system ERP stanowi hamulec każdej takiej zmiany. Oparcie całości na centralnym , współdzielonym module rejestrującym (jest z nim z reguły księgowość) to niemalże „zabetonowanie” architektury biznesowej firmy.
Propozycja powyższa (polecam pełny tekst) to próba ograniczenia roszczeń OZZ oraz ograniczenie typów urządzeń objętych tym parapodatkiem. Mam nadzieję, że kropla drąży kamień, i praktyki OZZ o innych „pasożytów” zostaną jeszcze bardziej ograniczone. Dlaczego? Bo miedzy innymi, co jest nie tylko nielogiczne ale jest zwykłym pasożytnictwem, obecne prawo skutkuje tym, że OZZ dostają pieniądze za to, że między innymi moje opracowania (do których nic nie mają owe OZZ), są przeze mnie i moich klientów kopiowane na papier i nośniki CD. Jakim prawem jakakolwiek OZZ pobiera pieniądze za moje dzieła?
