Wyniki wyszukiwania dla „reguły biznesowe” – Strona 28

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

Projekty IT ? patrz i uważaj?

Moim zdaniem mamy do czynienia z pewnym paradoksem epoki: firmy inwestują w oprogramowanie nie raz setki tysięcy złotych i więcej, statystyka wdrożeń pokazuje, że podczas wdrożenia najprawdopodobniej dopłaci drugie tyle jednak firmy te (za obopólną zgodą z dostawcą oprogramowania) oszczędzają z górą kilkanaście procent planowanego budżetu projektu wykreślając z projektu analityka, prawnika i negocjatora. Moim zdaniem jest to lobbing dostawców IT, którzy generalnie zarabiają na niekompetencji i braku doświadczenia kupujących (nie wszyscy na szczęście). Rozumiem, że wiedza ekspercka ma wartość na rynku (sam na tym rynku funkcjonuję) ale nie rozumiem wykorzystania tej wiedzy przeciwko własnym klientom?

Czytaj dalej

Specyfikacja wymagań a bezpieczeństwo

Gdybym miał coś zasugerować w kwestii opisanego na początku problemu z wyciekiem danych to wykonanie analizy obecnej funkcjonalności posiadanego oprogramowania, wskazanie wszystkich ryzykownych punktów i dopiero od tego momentu szukał rozwiązania, przy czym nie szukałbym winnego, (bo to będzie teraz trudno udowodnić i jak już wspomniano najpewniej popsuje atmosferę w firmie) a po prostu pozatykałbym jak najszybciej wszystkie dziury.

Czytaj dalej

Zarządzanie wiedzą

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).

Czytaj dalej

Analiza przedwdrożeniowa

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.

Czytaj dalej

Naiwne modelowanie procesów biznesowych czyli za co nie płacić

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ć!

Czytaj dalej

SDJ – Pismo nie tylko dla programistów…

Okres wakacyjny (kiedy to było ...) zaowocował stosem zaległej literatury.... Dziś przyszła pora na zaległe numery Software Developer Journal. Czasopismo adresowane głównie do programistów i architektów ale jako analityk i…

Czytaj dalej

Dokumentowanie wymagań na systemy nie tylko ERP – droga do porażki

Istotą opisu wymagań na system jest kontekst całego projektu i tej inwestycji a kontekstem tym jest model biznesowy i zakres projektu. Model biznesowy można wykonać nawet metodami formalnymi za pomocą pseudokodu czy języka relacji logicznych jednak model taki jest bezwartościowy, jeżeli nie stanowi sobą zrozumiałego przekazu dla każdego zaangażowanego w projekt czytaj “szczególnie klienta biznesowego”. Kluczem do sukcesu jest tu modelowanie czyli zobrazowanie w sposób zrozumiały dla każdej strony w projekcie IT istoty biznesu i jego kontekstu w projekcie tworzenia i wdrażania oprogramowania. Model biznesowy i wewnętrzna struktura zarządzania organizacji to nie obiektowe modele a procesowe mapy łańcuchów tworzenia wartości w firmie. Model obiektowy ma zastosowanie dopiero podczas tworzenia modeli informacyjnych czyli struktury danych przechowywanych i przetwarzanych w firmie a dane to nic innego jak reprezentacja tych informacji, które firma chce przetwarzać oraz sposób w jaki chce to robić o czym wielu analityków zdaje się zapominać. Jak więc prowadzić analizy wymagań?

Czytaj dalej