CRM – Page 6 – JZ IT Consulting Ltd

Hurtownie danych czyli “Systemy od historii”

Post author:Jaroslaw Zelinski
Post published:7 December 2011
Post category:Analizy biznesowa i projektowanie oprogramowania

Hurtownia danych to model stworzony pod kątem przetwarzania faktów historycznych na prostym modelu danych (diagram powyżej, górny, to tak zwana kostka OLAP). Opracowanie takiego modelu wymaga specjalnej analizy i projektu, ale nie zapominajmy: analizę się robi raz a raporty stale... Tak więc szanowni Państwo. Jeśli tylko Wasza firma jest bliżej czołówki niż ogona rankingu rynku w Waszej branży, nie dajcie się namówić na jeden zintegrowany ERP i jakiś model referencyjny, bo nawet jak uda się go wdrożyć, to zmiana czegokolwiek będzie trudna a upgrade do nowszej wersji niemożliwy. Opracowanie projektu systemu składającego się z komponentów, pozwoli Wam dobrać najlepiej spełniające Wasze wymagania aplikacje. Jak z klocków LEGO złożycie "dedykowany system" pomagający utrzymać przewagę na rynku, a nie cofający Waszą firmą do poziomu "innych podmiotów w branży".

Czy systemy CRM przynoszą oczekiwane korzyści?

Post author:Jaroslaw Zelinski
Post published:8 November 2011
Post category:Analizy biznesowa i projektowanie oprogramowania

Wdrożenie systemu CRM poprzedzać powinna szczegółowa analiza procesów biznesowych oraz realnych potrzeb organizacji To w zasadzie podsumowanie powyższych uwag. CRM to praktycznie dwa kluczowe aspekty: procesy biznesowe związane z obsługą zdarzeń dotyczących klientów, repozytorium dokumentów powiązanych z tymi zdarzeniami. Te dwa powyższe punkty skłaniają mnie do postawienia tezy, mówiącej że dobry system CRM to system wspomagający procesy biznesowe związane z obsługą klientów oraz zarządzający informacjami związanymi z obsługą klientów. Powinien też integrować te dane w całej organizacji. Dlatego warto rozważyć, analizę obecnej sytuacji w firmie i wdrożenie, zamiast oprogramowania mającego w nazwie CRM, systemu typu workflow wraz z repozytorium dokumentów. Przy ograniczonym budżecie doskonale, w roli CRM, sprawdzają się same repozytoria dokumentów, które później zawsze można uzupełnić systemem wspierającym procesy biznesowe.

Cloud Computing to architektura systemu

Post author:Jaroslaw Zelinski
Post published:11 October 2011
Post category:Analizy biznesowa i projektowanie oprogramowania

Jak widać, można wskazać wiele korzyści z CC. Przede wszystkim model opłaty może być za gotowość, za realne wykorzystanie lub na innej zasadzie. Nie ma tu mowy o licencjach, jest mowa o wykonanej pracy. Problemem jest tu ocena czy danej firmie w ogóle CC pomoże, a jeśli tak to gdzie. Decydowanie się na CC nie powinno być efektem zauroczenia treścią np. takiej jak ta konferencji. Nie powinno być też emocjonalną decyzją po wysłuchaniu wizji dostawców takich usług. Skoro CC to jednak architektura, proponuję kolejność następującą: analiza biznesowa (cel projektu), analiza wymagań, projekt architektury systemu, decyzja, które komponenty system możliwe są do kupienia, a które należy potraktować jako zasób zewnętrzny (cudzy). Osobiście nie polecam podejścia polegającego na znalezieniu "fajnego" komponentu i zastanawianiu się gdzie go u siebie upchać. To często spotykany przypadek, w którym "coś nam sprzedano". Polecam rzetelne, pragmatyczne spojrzenie biznesowe, kończące się tym, że znajdziemy i kupimy od kogoś coś, co jest nam potrzebne i przyniesie korzyści, także finansowe.

Słabości tradycyjnych metod wytwarzania IT – czy na pewno słabości?

Post author:Jaroslaw Zelinski
Post published:10 October 2011
Post category:Analizy biznesowa i projektowanie oprogramowania

A co mówią statystyki? Analysts report that as many as 71 percent of software projects that fail do so because of poor requirements management, making it the single biggest reason for project failure?bigger than bad technology, missed deadlines or change management fiascoes. ( źr. Fixing the Software Requirements Mess CIO.com). Parząc na powyższe (wytłuszczenie: w większości z ponad 71% złych projektów programistycznych, powodem kłopotów było złe zarządzanie wymaganiami, co czyniło większe szkody niż pozostałe powody, takie jak technologie, napięte terminy czy zarządzanie zmianami, razem wzięte). Tak więc zastanówmy się czy aby na pewno brak projektu i specyfikacji wymagań to dobry sposób na projekt IT. Czy metody wytwarzania bazujące na braku pierwotnego projektu, faktycznie są zbawieniem projektów programistycznych... Dodam na koniec, że powyższe dotyczy w takim samym stopniu systemów dedykowanych jak i gotowych a wymagających "kastomizacji" bo to (nowe funkcjonalności systemu) także projekt dedykowany.

Od czego zacząć wdrożenie

Post author:Jaroslaw Zelinski
Post published:15 July 2011
Post category:Analizy biznesowa i projektowanie oprogramowania

Użycie modelu jako narzędzia wyboru systemu ERP jest bardzo skuteczne - wystarczy go opisać dodatkowo zakresem projektu i rozesłać do dostawców i zapytać czy ich system pasuje do modelu oraz ile ten produkt kosztuje rok po roku. Jednocześnie dobrze wykonany model organizacji nie zawiera informacji nadmiarowych, które zawsze podnoszą koszt jego wykonania, a często stanowią zbędne ograniczenia. Dobry model powstaje z użyciem standardów i dobrych praktyk. Do typowych standardów należą: notacja BPMN (Business Process Modeling Notation), UML (Uniefied Modeling Langualge), AchiMate/TOGAF, Siatka Zachmanna, Business Motivation Model. Do dobrych praktyk np. wzorce projektowe czy zalecenia Business Rules Group. Zachęcam do zakupu całego wydania COMPUTERWORLD Aplikacje Kompendium ERP Czerwiec 2011.