Sille Gavnholt Jygert, Konsultant i Kierownik Programów w fir­mie ana­li­tycz­nej Frost & Sullivan, potwier­dza: ?Jeżeli cho­dzi o wdro­że­nia sys­te­mów ERP, coraz więk­sze­go zna­cze­nia nabie­ra efek­tyw­ność, a nie kosz­ty; teraz cho­dzi bar­dziej o wyko­ny­wa­nie wła­ści­wych dzia­łań we wła­ści­wy spo­sób. Często ozna­cza to potrze­bę więk­szej ela­stycz­no­ści we wdro­że­niu i wyko­rzy­sta­niu sys­te­mu ERP. Uważamy, że ist­nie­ją trzy głów­ne obsza­ry, w któ­rych użyt­kow­ni­cy mogą odnieść korzy­ści ze zwięk­sze­nia ela­stycz­no­ści sys­te­mów ERP:

1. Większa kon­cen­tra­cja na pro­ce­sach i zmia­nach, któ­re sys­tem ERP ma wspierać.
2. Nowe mode­le usług wdro­że­nio­wych i wspar­cia: coraz czę­ściej dostaw­cy będą musie­li zapew­niać wspar­cie dla kon­kret­nych pro­ble­mów biz­ne­so­wych, a nie dla okre­ślo­nych tech­no­lo­gii, aby móc dzia­łać w coraz szyb­ciej zmie­nia­ją­cym się środowisku.
3. Obsługa klien­tów: poja­wią się nowe mode­le pozwa­la­ją­ce reali­zo­wać pro­ces biz­ne­so­wy i sil­niej anga­żo­wać użyt­kow­ni­ków, poma­ga­jąc im przez to efek­tyw­niej wyko­rzy­sty­wać sys­tem w roz­wią­zy­wa­niu pro­ble­mów biznesowych.

Według Jamesa Greavesa, Dyrektora ds. IT w fir­mie pro­jek­to­wej Portsmouth Aviation, zdol­ność zacho­wa­nia ela­stycz­no­ści i reago­wa­nia na zmie­nia­ją­ce się wyzwa­nia biz­ne­so­we to jeden z klu­czo­wych atry­bu­tów poszu­ki­wa­nych u dostaw­ców i w sys­te­mach ERP. (źr. Większa ela­stycz­ność i lep­sza obsłu­ga klien­ta na szczy­cie listy życzeń użyt­kow­ni­ków sys­te­mów ERP).

Jeśli potrak­to­wać powyż­sze jako ​„znak cza­su”, to ma to duże znacz­nie jako wpływ na spo­so­by i meto­dy pro­wa­dze­nia ana­liz wyma­gań i oce­ny potrzeb – narzu­ca duże wyma­ga­nia na jej jakość.

System ERP to przede wszyst­kim narzę­dzie. Jeżeli wdra­ża­my je, to z myślą o kon­kret­nych korzy­ściach. Popatrzmy na nie w kon­tek­ście warun­ków uzy­ska­nia powyż­szych korzyści:

Ad. 1. Nowe narzę­dzia IT wdra­ża­ne są (powin­ny) jako odpo­wiedź na potrze­bę nowych zaso­bów. Ta potrze­ba powin­na być uza­sad­nio­na biz­ne­so­wo. Praktyka poka­zu­je, że naj­efek­tyw­niej­sze wdro­że­nia to efekt zmian zapla­no­wa­nych jako ele­ment reali­za­cji nowej stra­te­gii fir­my. To z regu­ły nowe lub zmie­nio­ne pro­ce­sy biz­ne­so­we i mode­le biznesowe.

Ad.2. Tu nasu­wa się tyl­ko jed­no: ana­li­za sys­te­mo­wa i model usłu­go­wy sys­te­mu, nie tyle SOA jako [[Service Oriented Architecture]] ale tak­że jako poprze­dza­ją­ca to [[Service Oriented Analysis]]. Zidentyfikowany pro­blem biz­ne­so­wy na eta­pie ana­li­zy wyma­gań zamie­nia się (powi­nien) w wyma­ga­nie w spe­cy­fi­ka­cji wyma­gań na system.

Ad.3. Modele biz­ne­so­we zmie­rza­ją w kie­run­ku uczy­nie­nia klien­ta udzia­łow­cem, pro­gra­my lojal­no­ścio­we to pro­wa­dze­nie do tego, by klient czuł się zwią­za­ny z dostaw­cą, by czuł, że kupu­jąc utrzy­mu­je go, sta­je się źró­dłem gwa­ran­cji jego dal­sze­go ist­nie­nia. Przyczynia się do tego by ulu­bio­na mar­ka zacho­wa­ła się na ryn­ku. Tu wkra­cza­my w ele­men­ty pro­ce­sów biz­ne­so­wych powią­za­nych z sys­te­ma­mi CRM.

Nie da się tu, za mało miej­sca, opi­sać cało­ści szcze­gó­łów tych zagad­nień, mogę co naj­wy­żej wska­zać jak moż­na ​„gryźć” pro­blem. A pro­blem tkwi w zło­żo­no­ści współ­ist­nie­nia: pro­ce­dur, ludzi, uży­wa­ne­go opro­gra­mo­wa­nia, pla­nów biz­ne­so­wych i mar­ke­tin­go­wych itp. Złożoność ta jest trud­na do ogar­nię­cia umy­słem czło­wie­ka, samo zapi­sa­nie w posta­ci tek­stu memo­ria­łu ​„Tak będzie­my to robić” to sta­now­czo za mało. Dlaczego? Bo istot­ne jest nie tyl­ko to ile ele­men­tów wcho­dzi w skład ​„pro­ble­mu” a to jak są ze sobą powią­za­ne oraz co i na co ma wpływ. Zrozumienie tkwi nie w tym, że wiem ile w lesie jest drzew i wil­ków a w tym, że wiem dla­cze­go i kie­dy wil­ki się cho­wa­ją za drze­wa­mi. Dlatego spis z inwen­ta­rza nie pomaga.

Poniżej dia­gram (a raczej jego namiast­ka) poka­zu­ją­cy jak opi­sać model poka­zu­ją­cy te oddzia­ły­wa­nia i wpływy:

Celem takich dia­gra­mów nie jest tyl­ko two­rze­nie obraz­ków. To narzę­dzie ana­li­zy, któ­re zmu­sza do zada­wa­nia wła­ści­wych pytań, wła­ści­wym oso­bom. Jako, że model BMM sta­no­wi kom­plet­ny sys­tem poję­cio­wy a przy oka­zji tak­że ma swo­ją sym­bo­licz­ną wer­sje (nota­cja), pozwa­la two­rzyć nie­skom­pli­ko­wa­ne dia­gra­my i sku­pić się na tym co waż­ne a po dru­gie poka­zać sys­tem w spo­sób łatwy do wery­fi­ka­cji i zro­zu­mie­nia. Stworzenie spój­ne­go tek­stu na pod­sta­wie takie­go dia­gra­mu jest już łatwe, w dru­gą stro­nę to nie­ste­ty nie dzia­ła (łatwo jest słow­nie opi­sać skom­pli­ko­wa­ną tra­sę wyciecz­ki mając plan mia­sta w rękach, zro­bie­nie tego na bazie wyobraź­ni jest dużo trud­niej­sze, dla­te­go jed­nak war­to posia­dać mapę).

Powyższy dia­gram, model moty­wa­cji, tu two­rzo­ny jest w kon­tek­ście pro­jek­tu. Dlatego tu nie opi­su­je całej fir­my a jedy­nie zwią­za­ne z celem ele­men­ty. Cele jest reali­za­cja kon­kret­nej wizji.