Cel samorządów, z tego co można wyczytać, to zapobieżenie wyrzucania śmieci np. do lasów przez naszych kochanych uczciwych obywateli, gdyż do tej pory obywatel płacił za śmieci, które od niego odebrano. Wystarczyło "zutylizować" śmieci na własną rękę i były oszczędności. Drugi powód to ekologia, czyli maksymalizowanie odzysku (tak zwany [[recycling]]). Czy aby na pewno?
Modne ostatnio projekty modelowania procesów biznesowych z reguły, jako produkt, dostarczają niezliczone ilości "map procesów", które kończą swój żywot na zakurzonych z czasem półkach, powstawały zbyt dużym kosztem by je wyrzucić do kosza. Ich stałe utrzymanie (aktualizacja) nie raz bywa kosztowniejsze od wytworzenia. [...] jeżeli uznamy, że jedynym powodem prowadzenia projektów jest usprawnianie określonych procesów biznesowych, to znaczy, że uruchamianie tych projektów bez wiedzy, które to dokładnie procesy i bez pełnego zrozumienia ich wpływu na organizację, projektów tych nie należy rozpoczynać.
otwartość oprogramowania (kodu) czyni go bardziej wiarygodnym, otwartość kodu skłania jego twórców do podnoszenie jego jakości (wstyd zabrania partaniny ;)), to czy jest darmowy czy nie, zależy wyłącznie od modelu biznesowego sprzedaży: twórca sam ustala czy zarabia na licencjonowaniu kodu czy na swojej wiedzy i pracy, "zamykanie kodu", to kwestia subiektywnego uznania twórcy kodu, czy stanowi on (treść) chronione know-how (jego przewagę konkurencyjną) czy nie... ale warto dodać, że przewaga stojąca na takiej tajemnicy ma jednak gliniane nogi (jak każda przewaga bazująca w 100% na tajemnicy).
W dużym skrócie: nie warto dublować kompetencji bo to nomen omen powielanie ich kosztów. Jeżeli firma ma wdrożone procedury kontrolingowe, to naturalnym jest przekazanie danych (produktu) modelowania i optymalizacji procesów, zamiast wzajemne konkurowanie, tym bardziej, że dane z kontrolingu zawsze - jak sądzę - zostaną uznane za bardziej wiarygodne . Bardzo dobrym "narzędziem" łączącym kontroling, modelowanie procesów i zasoby (nie tylko IT) jest architektura korporacyjna, ale to materiał na kolejny artykuł ;).
Książkę polecam przede wszystkim analitykom do nauki ale także "wyżartym" programistom, by sobie uporządkowali zdobyte doświadczenie i możliwie łagodnie przechodzili od metod strukturalnych do obiektowych. Tu pewnie nowinka dla nich: bazy danych projektujemy na samym końcu, na etapie implementacji opracowanego kompletnego projektu obiektowego.