Sille Gavnholt Jygert, Konsultant i Kierownik Programów w firmie analitycznej Frost & Sullivan, potwierdza: ?Jeżeli chodzi o wdrożenia systemów ERP, coraz większego znaczenia nabiera efektywność, a nie koszty; teraz chodzi bardziej o wykonywanie właściwych działań we właściwy sposób. Często oznacza to potrzebę większej elastyczności we wdrożeniu i wykorzystaniu systemu ERP. Uważamy, że istnieją trzy główne obszary, w których użytkownicy mogą odnieść korzyści ze zwiększenia elastyczności systemów ERP:

  1. Większa koncentracja na procesach i zmianach, które system ERP ma wspierać.
  2. Nowe modele usług wdrożeniowych i wsparcia: coraz częściej dostawcy będą musieli zapewniać wsparcie dla konkretnych problemów biznesowych, a nie dla określonych technologii, aby móc działać w coraz szybciej zmieniającym się środowisku.
  3. Obsługa klientów: pojawią się nowe modele pozwalające realizować proces biznesowy i silniej angażować użytkowników, pomagając im przez to efektywniej wykorzystywać system w rozwiązywaniu problemów biznesowych.

Według Jamesa Greavesa, Dyrektora ds. IT w firmie projektowej Portsmouth Aviation, zdolność zachowania elastyczności i reagowania na zmieniające się wyzwania biznesowe to jeden z kluczowych atrybutów poszukiwanych u dostawców i w systemach ERP. (źr. Większa elastyczność i lepsza obsługa klienta na szczycie listy życzeń użytkowników systemów ERP).

Jeśli potraktować powyższe jako “znak czasu”, to ma to duże znacznie jako wpływ na sposoby i metody prowadzenia analiz wymagań i oceny potrzeb – narzuca duże wymagania na jej jakość.

System ERP to przede wszystkim narzędzie. Jeżeli wdrażamy je, to z myślą o konkretnych korzyściach. Popatrzmy na nie w kontekście warunków uzyskania powyższych korzyści:

Ad. 1. Nowe narzędzia IT wdrażane są (powinny) jako odpowiedź na potrzebę nowych zasobów. Ta potrzeba powinna być uzasadniona biznesowo. Praktyka pokazuje, że najefektywniejsze wdrożenia to efekt zmian zaplanowanych jako element realizacji nowej strategii firmy. To z reguły nowe lub zmienione procesy biznesowe i modele biznesowe.

Ad.2. Tu nasuwa się tylko jedno: analiza systemowa i model usługowy systemu, nie tyle SOA jako [[Service Oriented Architecture]] ale także jako poprzedzająca to [[Service Oriented Analysis]]. Zidentyfikowany problem biznesowy na etapie analizy wymagań zamienia się (powinien) w wymaganie w specyfikacji wymagań na system.

Ad.3. Modele biznesowe zmierzają w kierunku uczynienia klienta udziałowcem, programy lojalnościowe to prowadzenie do tego, by klient czuł się związany z dostawcą, by czuł, że kupując utrzymuje go, staje się źródłem gwarancji jego dalszego istnienia. Przyczynia się do tego by ulubiona marka zachowała się na rynku. Tu wkraczamy w elementy procesów biznesowych powiązanych z systemami CRM.

Nie da się tu, za mało miejsca, opisać całości szczegółów tych zagadnień, mogę co najwyżej wskazać jak można “gryźć” problem. A problem tkwi w złożoności współistnienia: procedur, ludzi, używanego oprogramowania, planów biznesowych i marketingowych itp. Złożoność ta jest trudna do ogarnięcia umysłem człowieka, samo zapisanie w postaci tekstu memoriału “Tak będziemy to robić” to stanowczo za mało. Dlaczego? Bo istotne jest nie tylko to ile elementów wchodzi w skład “problemu” a to jak są ze sobą powiązane oraz co i na co ma wpływ. Zrozumienie tkwi nie w tym, że wiem ile w lesie jest drzew i wilków a w tym, że wiem dlaczego i kiedy wilki się chowają za drzewami. Dlatego spis z inwentarza nie pomaga.

Poniżej diagram (a raczej jego namiastka) pokazujący jak opisać model pokazujący te oddziaływania i wpływy:

Plan rozwojowy - diagram BMM
Plan rozwojowy – diagram BMM

Celem takich diagramów nie jest tylko tworzenie obrazków. To narzędzie analizy, które zmusza do zadawania właściwych pytań, właściwym osobom. Jako, że model BMM stanowi kompletny system pojęciowy a przy okazji także ma swoją symboliczną wersje (notacja), pozwala tworzyć nieskomplikowane diagramy i skupić się na tym co ważne a po drugie pokazać system w sposób łatwy do weryfikacji i zrozumienia. Stworzenie spójnego tekstu na podstawie takiego diagramu jest już łatwe, w drugą stronę to niestety nie działa (łatwo jest słownie opisać skomplikowaną trasę wycieczki mając plan miasta w rękach, zrobienie tego na bazie wyobraźni jest dużo trudniejsze, dlatego jednak warto posiadać mapę).

Powyższy diagram, model motywacji, tu tworzony jest w kontekście projektu. Dlatego tu nie opisuje całej firmy a jedynie związane z celem elementy. Cele jest realizacja konkretnej wizji.

Jarosław Żeliński

Jarosław Żeliński: Od roku 1991 roku, nieprzerwanie, realizuje projekty z zakresu analiz i projektowania systemów, dla urzędów, firm i organizacji. Od 1998 roku prowadzi samodzielne studia i prace badawcze z obszaru analizy systemowej i modelowania (modele jako przedmiot badań: ORCID). Od 2005 roku, jako wykładowca akademicki wizytujący (nieetatowy), prowadzi wykłady i laboratoria (ontologie i modelowanie systemów informacyjnych, aktualnie w Wyższej Szkole Informatyki Stosowanej i Zarządzania pod auspicjami Polskiej Akademii Nauk w Warszawie.) Oświadczenia: moje badania i publikacje nie mają finansowania z zewnątrz, jako ich autor deklaruję brak konfliktu interesów. Prawa autorskie: Zgodnie z art. 25 ust. 1 pkt. 1) lit. b) ustawy o prawie autorskim i prawach pokrewnych zastrzegam, że dalsze rozpowszechnianie artykułów publikowanych w niniejszym serwisie jest zabronione bez indywidualnej zgody autora (patrz Polityki Strony). Konsultacje: wszelka pomoc i wyjaśnienia dotyczące treści artykułów autora bloga udzielana jest wyłącznie w ramach płatnych konsultacji.