Kto jest winny porażki wdrożenia ERP

Artykuł jaki ukazał się w COMPUTERWORLD skłonił mnie do konfrontacji moich doświadczeń i obserwacji z jego treścią, uwagami innych doświadczonych specjalistów. Być może warto pokusić się o pewne wnioski i sugestie... Wina klienta Według niego…

Czytaj dalej Kto jest winny porażki wdrożenia ERP

Projektowanie czegoś dla gotowego ERP nie ma sensu…czy aby na pewno?

celem dostawcy gotowego systemu ERP jest wdrożyć go bez żadnych modyfikacji bo (jej koszty) zjadają marżę dostawcy. Celem kupującego oprogramowanie ERP, jest wsparcie swoich procesów biznesowych a nie kopia cudzych. To dwa sprzeczne interesy. Silna firma wymusi na dostawcy ERP zmiany, słaba nie raz poddaje się wierząc tezom dostawcy, że nowy system uporządkuje stan ich organizacji i da przewagę nad konkurencją. Kto tu ma rację?

Czytaj dalej Projektowanie czegoś dla gotowego ERP nie ma sensu…czy aby na pewno?

SaaS c.d.

Wprowadzenie 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…

Czytaj dalej SaaS c.d.

W co inwestować w kryzysie c.d. – SOA

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.

Czytaj dalej W co inwestować w kryzysie c.d. – SOA

Aspiryna na kryzys czyli czego pilnować w firmie i na co wydawać pieniądze w kryzysie

Kryzys zmusza do jeszcze bardziej wnikliwego myślenia i o strategiach rynkowych i o strategiach IT, bez których w sumie trudno sobie wyobrazić te pierwsze. Dwa lata temu pisałem o tym, że nadejdzie koniec systemów zintegrowanych w roli jednego uniwersalnego systemu w firmie: SOA: Czy to już nadchodzący koniec zintegrowanych ERP?

Czytaj dalej Aspiryna na kryzys czyli czego pilnować w firmie i na co wydawać pieniądze w kryzysie

IEEE830-1998 ? czy produkuje dobre wymagania?

Paradoksalnie wykonanie takiego modelu jest tu największą trudnością. Dlaczego? Tworząc go należy bezwzględnie panować na jego złożonością, panować nad subiektywizmem osób z którymi prowadzimy wywiady, rozumieć strategię modelowanej firmy i jej model biznesowy, wiele innych. Identyfikacja procesów sama w sobie jest trudna, wymaga posiadania metod ich identyfikacji i weryfikacji poprawności samej analizy i modelu, to jednak temat na książkę a nie na taki artykuł.

Czytaj dalej IEEE830-1998 ? czy produkuje dobre wymagania?

SaaS czy to jest BPO? Czyli swoje w końcu czy cudze…

A jednak jak to mówią “nigdy nie mów nigdy”. Postanowiłem napisać o SaaS (Software as a Service, ang. Oprogramowanie jako Usługa) mimo wcześniejszych deklaracji, że nie będę tego tematu poruszał, ale tu w nieco innym kontekście. Dlaczego? Bo jednak nie potrafię słuchać tłumaczenia: “SaaS jest dobre dla firm bo jest dobre”. Ja oczywiście zawsze jestem uciążliwy i pytam “Dlaczego dla mnie jest dobre”? Tłumaczenie, że “Dzierżawione jest lepsze i tańsze” od razu nasuwa mi pytanie “To dlaczego dostawcy SaaS nie są jeszcze milionerami?” A jak chcę skopać leżącego to pytam jeszcze o rentowność (dla mnie, nie dla niego).

Czytaj dalej SaaS czy to jest BPO? Czyli swoje w końcu czy cudze…

Software Development Journal 11/2007

Artykuł opisuje drugi, po przypadkach użycia i modelu dziedziny systemu, aspekt opisu wymagań: zachowania systemu. Nie jest to proste biorąc pod uwagę różnorodność problemów: obiekty stanowe (np. dokumenty, ludzie), współbieżność i transakcyjność i wiele innych. Opisanie tekstem w sposób jednoznaczny tych elementów wymagań jest praktycznie nie możliwe. Za pomocą diagramów: sekwencji, komunikacji, aktywności, maszyny stanów, czy przebiegów czasowych możliwe jest przekazanie opisu budowy systemu np. programistom będąc niemalże pewnym, że napiszą kod taki jaki chciał projektant mimo, tego, że nie będzie go w tym procesie kodowania.

Czytaj dalej Software Development Journal 11/2007