Zintegrowany ERP: postęp czy cofanie?

Kolejne ana­li­zy przed­się­biorstw za mną, a wraz z nimi obser­wo­wa­ne ste­reo­ty­py i kon­for­mizm wie­lu moich klien­tów. Tym razem kil­ka słów o tym co to jest sys­tem zin­te­gro­wa­ny”. Otóż bar­dzo wie­lu ludzi utoż­sa­mia to poję­cie z współ­dzie­le­niem danych”. Sprzedawcy opro­gra­mo­wa­nia ERP jak man­trę powta­rza­ją nasz sys­tem jest zin­te­gro­wa­ny bo wszyst­kie dane są wspól­ne, więc wszyst­kie infor­ma­cje wpro­wa­dza­ny tyl­ko raz i są wszę­dzie dostęp­ne”. O ERP i inte­gra­cji pisa­łem w Duży ERP czy inte­gra­cja, o idei i wyż­szo­ści inte­gra­cji na pozio­mie usług zamiast współ­dzie­le­nia danych pisa­łem w Wymagania poza­funk­cjo­nal­ne … Teraz popa­trz­my na to od stro­ny archi­tek­tu­ry biznesowej.

Nie ule­ga wąt­pli­wo­ści, że np. pra­co­daw­ca potrze­bu­je danych o nas, o naszym wykształ­ce­niu. Czy to zna­czy, że opty­mal­ne jest, by sys­te­my kadro­wo-pła­co­we współ­dzie­li­ły wszyst­kie dane z urzę­da­mi sta­nu cywil­ne­go i ze szko­ła­mi? Wszyscy wie­my, że po wie­lu latach spę­dzo­nych w szko­łach, mimo ogrom­nej ilo­ści danych szcze­gó­ło­wych o naszej edu­ka­cji, zebra­nych w tych szko­łach, pra­co­daw­cy wystar­czy wyma­ga­ne świa­dec­two jej ukoń­cze­nia oraz nasze imię, nazwi­sko, data i miej­sce uro­dze­nia. Zarówno Szkoła jak i Urząd Stanu Cywilnego mają znacz­nie bogat­sze dane na nasz temat, co nie zna­czy, że inne pod­mio­ty” powin­ny je współ­dzie­lić. Szkoła na żąda­nie wyda odpis świa­dec­twa a Urząd odpis aktu uro­dze­nia (bo nawet nie poszcze­gól­ne oce­ny czy poszcze­gól­ne dane oso­bo­we). Pisząc wcze­śniej o inte­gra­cji wska­zy­wa­łem na korzy­ści mini­ma­li­za­cji inter­fej­sów i sepa­ra­cji danych.

Tak więc mitycz­na inte­gra­cja w sys­te­mach ERP” w rozu­mie­niu wspól­ne dane” to może jed­nak relik­ty tech­no­lo­gii z przed 30/40 lat, kon­for­mizm kupu­ją­cych i opór przed zmia­ną u dostaw­ców? Zaryzykuję tu tezę, że dostaw­cy wie­lu sys­te­mów ERP fun­du­ją nam po pro­stu dług tech­no­lo­gicz­ny. Czy mam rację? Popatrzmy na jed­ne z ostat­nich badań Gartnera:

Omawiając stra­te­gie firm, Gaughan pod­kre­ślił rów­nież zna­cze­nie dzia­ła­ją­cych przy nich ośrod­ków badaw­czych. Ich nad­rzęd­nym celem jest two­rze­nie inno­wa­cji w takich spo­sób, aby ? zacho­wu­jąc pozo­ry roz­wo­ju ? utrzy­my­wać ist­nie­ją­cy stan rze­czy tak dłu­go, jak to tyl­ko moż­li­we.(Czego naj­więk­sze fir­my tech­no­lo­gicz­ne nie mówią swo­im klien­tom?)

O co tu chodzi?

Model rynku i przedsiębiorstwa

Najpierw dla porząd­ku przy­po­mnę poję­cie war­to­ści doda­nej Michaela Portera:

Wartość doda­na pra­cy, to róż­ni­ca postrze­ga­nej war­to­ści ryn­ko­wej pro­duk­tu przed i po wyko­na­niu nad nim pra­cy. Skoro war­tość ryn­ko­wa to kon­se­kwen­cja powsta­ją­cej war­to­ści doda­nej, nie trud­no się domy­ślić, że cena ryn­ko­wa pro­duk­tu tak­że wzro­śnie po jego prze­two­rze­niu”. Powyższy dia­gram poka­zu­je ogól­ną zasa­dę war­to­ści postrze­ga­nej: doko­nu­ją­cy wybo­ru Nabywca wie, że cena towa­ru prze­two­rzo­ne­go jest wyż­sza od ceny towa­ru uzy­ska­ne­go bez­po­śred­nio ze Źródła zaopa­trze­nia. Jeżeli mimo to decy­du­je się na ten droż­szy, ozna­cza to, że dostrze­ga war­tość tego prze­two­rze­nia i jest skłon­ny za to zapła­cić. Przykładem może być to, że dla rowe­rzy­sty stos żela­za i gumy ma jed­nak mniej­szą war­tość niż rower, ryba dostęp­na w skle­pie 800 km od morza ma więk­szą war­tość niż ta sama ryba w tak odda­lo­nym por­cie. Tyle w kwe­stii war­to­ści dodanej.

Popatrzmy teraz na to co się dzie­je w powyż­szym Podmiocie gospo­dar­czym”. Powyższy Podmiot gospo­dar­czy to taka oto struktura:

Przepływ produktów

Podmiot gospo­dar­czy two­rzy war­tość doda­ną poprzez prze­miesz­cze­nie pro­duk­tu w prze­strze­ni i cza­sie (ten sam pro­dukt zosta­je dostar­czo­ny w okre­ślo­ne miej­sce, np. sie­ci dys­try­bu­cji) oraz (lub) wytwa­rza­jąc lub prze­twa­rza­jąc okre­ślo­ne pro­duk­ty (tu pół­pro­duk­ty) lub surow­ce. Generalizując: pod­mio­ty gospo­dar­cze to zło­że­nie (kom­bi­na­cje) wytwa­rza­nia i dys­try­bu­cji. Aby moż­li­we było wytwa­rza­nie, potrzeb­na jest aktyw­ność pole­ga­ją­ca na pro­jek­to­wa­niu. Na dia­gra­mie połą­czo­no to wszyst­ko w pewien okre­ślo­ny ciąg logicz­ny dzia­łań. Z uwa­gi na to, że pro­jek­to­wa­nie z regu­ły nie odby­wa się w spo­sób przy­pad­ko­wy, w spo­sób prze­my­śla­ny zbie­ra­ne są infor­ma­cje z ryn­ku na temat potrzeb Nabywców (ryn­ku).

System informacyjny

Aby moż­li­we było zarzą­dza­nie tym wszyst­kim, koniecz­ne jest śle­dze­nie tych aktyw­no­ści, ich skut­ków i przy­czyn. Śledzenie to nic inne­go jak zbie­ra­nie danych o tym co chce­my wie­dzieć”. Jak mawia­ją spe­cja­li­ści z dzie­dzi­ny zarzą­dza­nia: zarzą­dzać moż­na tyl­ko tym co potra­fi­my mie­rzyć”. O czym mowa? O faktach:

Zarządzanie informacją

Wszystkie aktyw­no­ści pod­mio­tu gospo­dar­cze­go, two­rzą okre­ślo­ne fak­ty, jest nim np. sprze­daż (moment prze­nie­sie­nia wła­sno­ści pro­duk­tu na nabyw­cę), ten fakt jest doku­men­to­wa­ny fak­tu­rą VAT. Oczywiście wie­le takich fak­tów ma miej­sce wewnątrz pod­mio­tu (np. prze­ka­za­nie wytwo­rzo­ne­go pro­duk­tu do maga­zy­nu wyro­bów goto­wych itp.).

Takich fak­tów w fir­mach jest wie­le, jed­nak do celów zarzą­dza­nia nią, kolek­cjo­nu­je­my ich ści­śle okre­ślo­ną licz­bą. To, któ­re fak­ty reje­stru­je­my (zbie­ra­my dane) zale­ży od przy­czy­ny np. pra­wo i podat­ki są przy­czy­ną dokład­ne­go śle­dze­nia fak­tów zwią­za­nych z wszel­ki­mi ope­ra­cja­mi doty­czą­cy­mi kosz­tów dzia­łal­no­ści i przy­cho­dów. Wewnętrzne potrze­by zwią­za­ne z zarzą­dza­niem, są przy­czy­ną zbie­ra­nia (moni­to­ro­wa­nia) kolej­nych szczegółów.

Poza opi­sem fak­tów, kolek­cjo­nu­je­my w róż­nej for­mie, zasa­dy regu­lu­ją­ce to jakie fak­ty mają pra­wo lub muszą zajść: to regu­ły biz­ne­so­we. Zbiór tych danych (opi­sy fak­tów) i ich wza­jem­nej zależ­no­ści to sys­tem infor­ma­cyj­ny: infor­ma­cje o tym co się wyda­rzy­ło. Czego nam tu trosz­kę” bra­ku­je? Tego co nazy­wa­my np. księ­go­wo­ścią czy zarzą­dza­niem kadra­mi (w tym wyna­gro­dze­nia). Jednak one wła­śnie są tyl­ko” narzę­dziem do prze­twa­rza­nia danych o fak­tach. Celowo nie umie­ści­łem na dia­gra­mach tych aktyw­no­ści” bo one są pra­ca­mi pole­ga­ją­cy­mi na śle­dze­niu i moni­to­ro­wa­niu, na spra­woz­daw­czo­ści. Tak na praw­dę wysta­wie­nie fak­tu­ry VAT (opis fak­tu sprze­da­ży) jest czę­ścią aktyw­no­ści jaką jest sprze­daż. Do celów podat­ko­wych potrzeb­ne są tyl­ko zagre­go­wa­ne dane z fak­tur. Itd.

Architektura biznesowa

Wiemy więc już, że Podmiot gospo­dar­czy to okre­ślo­ne aktyw­no­ści: pro­jek­to­wa­nie, wytwa­rza­nia, sprze­daż, zaopa­trze­nie, obsłu­ga pytań” czy­li tak na praw­dę róż­nych spraw” (mogą być jesz­cze inne, zależ­nie od spe­cy­fi­ki pod­mio­tu i bran­ży, np. zarzą­dza­nie pro­jek­ta­mi w fir­mie usłu­go­wej). Każda z tych aktyw­no­ści two­rzy okre­ślo­ne fak­ty, pew­na część danych o nich – bo nie wszyst­kie – mogą być potrzeb­ne na zewnątrz”. Np. spo­śród wszyst­kich szcze­gó­ło­wych infor­ma­cji o reali­za­cji duże­go pro­jek­tu, do roz­li­cze­nia jego koszów i wysta­wie­niu fak­tu­ry, potrzeb­ne są wyłącz­nie okre­ślo­ne zagre­go­wa­ne dane a nie wszyst­kie jakie zna­my. Dotyczy to prak­tycz­nie każ­dej z wymie­nio­nych aktyw­no­ści. Jaki z tego wnio­sek? Nie musi­my współ­dzie­lić w jed­nym miej­scu wszyst­kich danych o poszcze­gól­nych aktyw­no­ściach. Poszczególne aktyw­no­ści prze­ka­zu­ją pomię­dzy sobą tyl­ko swo­je pro­duk­ty, i tyl­ko prze­ka­zy­wa­nie danych je opi­su­ją­ce ma sens. Zarządzanie każ­da aktyw­no­ścią odby­wa się lokal­nie (w niej) i tyl­ko tu jest potrzeb­na peł­na wie­dza”, każ­da z tych aktyw­no­ści to zamknię­ty i względ­nie nie­po­dziel­ny pro­ces two­rze­nia war­to­ści doda­nej (her­me­ty­za­cja) od któ­re­go na zewnątrz wyma­ga­my wyłącz­nie zagre­go­wa­nej infor­ma­cji, udo­stęp­nia­nie nad­mia­ru szcze­gó­łów na zewnątrz nicze­mu nie słu­ży (poza przy­pad­ka­mi gdy część z nich udo­stęp­nia­my do do szcze­gó­ło­wych ana­liz, te jed­nak tak­że wyko­na zewnętrz­ny dedy­ko­wa­ny pod­sys­tem. Prowadzenie roz­li­czeń i spra­woz­daw­czość to kolej­na aktyw­ność, któ­ra tak­że wyma­ga tyl­ko okre­ślo­nych zagre­go­wa­nych danych a nie wszyst­kich jaki­mi dysponujemy”.

Systemy ERP (pier­wot­nie tyl­ko FK, potem MRP i MRPII) powsta­wa­ły jako sys­te­my reje­stru­ją­ce dla okre­ślo­nych pod­mio­tów. W latach 80-tych i 90-tych (wte­dy one powsta­wa­ły), fir­my raczej się roz­ra­sta­ły, ich wewnętrz­na zmien­ność była bli­ska zeru, dla­te­go archi­tek­tu­ra w posta­ci jed­nej dużej rela­cyj­nej bazy danych i zesta­wu funk­cji je prze­twa­rza­ją­cych, mia­ła swo­je uza­sad­nie­nie. Rozwój fir­my wyma­gał prak­tycz­nie tyl­ko doda­wa­nia nowych funk­cji, cza­sem zmia­ny już ist­nie­ją­cych, raczej nie wyma­gał zmian w mode­lu danych.

Opisane wyżej aktyw­no­ści mogą być reali­zo­wa­ne w jed­nym pod­mio­cie, ale mogą to być odręb­ne pod­mio­ty. Dotyczy to tak­że aktyw­no­ści, jaką jest pro­wa­dze­nie roz­li­czeń (np. zewnętrz­ne biu­ro rachun­ko­we, spół­ka zależ­na itp.). Zmienność sytu­acji ryn­ko­wej, zmia­na stra­te­gii, prze­ję­cia, wydzie­la­nie spół­ek zależ­nych, to wszyt­ko ma pra­wo przy­tra­fić się każ­dej fir­mie i orga­ni­za­cji. To zna­czy, że pod­miot gospo­dar­czy może być zło­żo­ny z dowol­ne­go, zmie­nia­ją­ce­go się, zesta­wu powyż­szych aktyw­no­ści. Jaki z tego wniosek?

Skoro powyż­sze aktyw­no­ści są od sie­bie nie­za­leż­ne, takie też powin­no być opro­gra­mo­wa­nie, któ­re pozwa­la nimi zarzą­dzać. Zakup opro­gra­mo­wa­nia, któ­re sta­no­wi jeden, zin­te­gro­wa­ny współ­dzie­le­niem danych, mono­lit to nic inne­go jak zafun­do­wa­nie sobie dłu­gu tech­no­lo­gicz­ne­go w momen­cie pod­ję­cia decy­zji o takim zaku­pie. Żadna fir­ma, dzia­ła­ją­ca w obec­nych cza­sach, nie da sama sobie gwa­ran­cji, że jej wewnętrz­ne aktyw­no­ści nie zmie­nią się co do ich spe­cy­fi­ki, że nie przy­bę­dzie nowych, nie zre­zy­gnu­je z nie­któ­rych. Monolityczny cało­ścio­wy sys­tem ERP sta­no­wi hamu­lec każ­dej takiej zmia­ny. Oparcie cało­ści na cen­tral­nym , współ­dzie­lo­nym modu­le reje­stru­ją­cym (jest z nim z regu­ły księ­go­wość) to nie­mal­że zabe­to­no­wa­nie” archi­tek­tu­ry biz­ne­so­wej firmy.

to samo dla każdego

Kilka uwag na temat systemów ERP II, ich historii i metod ich wyboru

to samo dla każdego

Problem pole­ga na tym, że nie­mal­że każ­dy dostaw­ca sys­te­mu ERP twier­dzi, że jego pro­dukt pasu­je dla każ­dej fir­my. Czy na pew­no? Ale po kolei…

Systemy kla­sy ERP to sze­ro­ka gama opro­gra­mo­wa­nia wspo­ma­ga­ją­ce­go zarzą­dza­nie przed­się­bior­stwa­mi i orga­ni­za­cja­mi. Skrót ERP ozna­cza [[Enterprise Resource Planning]] (z ang. Planowanie Zasobów Organizacji). Systemy tego typu wywo­dzą się ewo­lu­cyj­ne z sys­te­mów MRP (Material Requirement Planning, Planowanie Potrzeb Materiałowych) i MRP II (Manufacturing Resource Planning, Planowanie Zasobów Produkcyjnych).

ERP jest opi­sy­wa­ne jako MRP III czy­li Money Resource Planning – Planowanie Zasobów Finansowych, w tym:

  1. jest sys­te­mem obej­mu­ją­cym całość pro­ce­sów pro­duk­cji i dystrybucji;
  2. inte­gru­je róż­ne obsza­ry dzia­ła­nia przedsiębiorstwa;
  3. uspraw­nia prze­pływ kry­tycz­nych dla jego funk­cjo­no­wa­nia informacji;

Od kil­ku lat obec­ne jest poję­cie ERP II. Podstawową cechą odróż­nia­ją­cą sys­te­my ERP II od poprzed­ni­ków jest to, że oprócz funk­cjo­nal­no­ści umoż­li­wia­ją­cej pla­no­wa­nie zaso­bów rze­czo­wych i finan­so­wych przed­się­bior­stwa, zawie­ra­ją opro­gra­mo­wa­nie pozwa­la­ją­ce na zarzą­dza­nie kon­tak­ta­mi z klien­tem (tzw. CRM – Customer Relationship Management) oraz doko­ny­wa­nie zaawan­so­wa­nych ana­liz, pro­wa­dze­nia tak zwa­ne­go kon­tro­lin­gu, mają funk­cjo­nal­no­ści zaawan­so­wa­ne­go rapor­to­wa­nia (pod­sys­tem wspo­ma­ga­nia podej­mo­wa­nia decy­zji, Business Intelligence). Cechą tych sys­te­mów, obec­nie już wyma­ga­ną, jest tak­że moż­li­wość korzy­sta­nia z nich poprzez sieć WWW.

Systemy te umoż­li­wia­ją two­rze­nie ser­wi­sów inter­ne­to­wych dla klien­tów przed­się­bior­stwa, koope­ran­tów czy wresz­cie pra­cow­ni­ków. Portale takie umoż­li­wia­ją bez­po­śred­nią komu­ni­ka­cję użyt­kow­ni­ków z sys­te­mem infor­ma­cyj­nym przed­się­bior­stwa. Klienci mogą prze­glą­dać aktu­al­ną ofer­tę fir­my, zama­wiać wyro­by czy uzy­ski­wać na bie­żą­co infor­ma­cje o sta­nie wcze­śniej zło­żo­nych zamó­wień. Podwykonawcy mogą sami spraw­dzić bie­żą­cy stan zapa­sów pro­du­ko­wa­ne­go przez sie­bie ele­men­tu i dopa­so­wać swój plan pro­duk­cyj­ny do zamó­wień gene­ro­wa­nych przez sys­tem MRP odbior­cy. Pracownicy przed­się­bior­stwa, nawet będąc poza nim, mogą zdo­być infor­ma­cje o bie­żą­cym sta­nie wybra­nych przez sie­bie dzie­dzin dzia­łal­no­ści. (na pod­sta­wie http://​www​.mrp​.malic​ki​.info/​e​r​p​2​.​h​tml)

Jak widać są to bar­dzo zło­żo­ne sys­te­my. Lista funk­cjo­nal­no­ści takie­go pakie­tu ERP II obej­mu­je ponad 6 tys. cech! Planowanie ich wdro­że­nia a wcze­śniej spe­cy­fi­ko­wa­nie wyma­gań, wybór pro­duk­tu i jego dostaw­cy nie może być typo­wym pro­ce­sem wybo­ru opro­gra­mo­wa­nia: nikt nie jest w sta­nie zarzą­dzać taką masą wyma­gań w jed­nym projekcie.

Dlatego meto­dy­ka, któ­rą sto­su­ję bazu­je na twier­dze­niu, że sys­te­my obsłu­gu­ją­ce stan­dar­do­we obsza­ry dzia­ła­nia, powin­ny być obsłu­gi­wa­ne stan­dar­do­wy­mi narzę­dzia­mi. Ich defi­nio­wa­nie nie pole­ga na spe­cy­fi­ko­wa­niu wszyst­kich ich cech, któ­rych są set­ki a powo­ły­wa­niu się na nor­my i prze­pi­sy, z któ­ry­mi muszą być (lub chce­my by były) zgod­ne. Wymagania na całość wystar­czy uzu­peł­nić o klu­czo­we para­me­try naszych pro­ce­sów i doku­men­tów (naj­wy­żej kil­ka­dzie­siąt!) oraz testy czy kon­kret­ny sys­tem je spełnia.

Projekty, któ­rych celem jest wdro­że­nie sys­te­mu ERP II powin­ny być pro­wa­dzo­ne w spo­sób pozwa­la­ją­cy jak naj­szyb­ciej zde­fi­nio­wać obszar sta­no­wią­cy klucz prze­wa­gi kon­ku­ren­cyj­nej, sta­no­wią­cy spe­cy­fi­kę danej orga­ni­za­cji, to co odróż­nia ją od resz­ty. Praktyka poka­zu­je, że jest to kil­ka do kil­ku­na­stu pro­cent dzia­łań (nie wię­cej niż 20%). To zało­że­nie pozwa­la pro­wa­dzić pro­jekt w nastę­pu­ją­cy sposób:

  1. ana­li­za biznesowa,
  2. ana­li­za prze­wa­gi konkurencyjnej,
  3. wyło­nie­nie obsza­ru budu­ją­ce­go prze­wa­gą na rynku,
  4. zde­fi­nio­wa­nie wyma­gań na tak okre­ślo­ny obszar,
  5. wska­za­nie stan­dar­dów, któ­re opi­su­ją pozo­sta­łe dzia­ła­nia w organizacji,
  6. pro­jekt logi­ki archi­tek­tu­ry systemu.

Pierwsze trzy to ele­ment stu­dium moż­li­wo­ści. Pozostałe trzy, uzu­peł­nio­ne o ofer­ty dostaw­ców, to stu­dium wyko­ny­wal­no­ści: w tym miej­scy moż­na zre­zy­gno­wać z pro­jek­tu lub przede­fi­nio­wać jego zakres i nie ma tym nic złego.

Kolejny wnio­sek z wie­lu wdro­żeń zło­żo­nych sys­te­mów: sys­tem IT nale­ży opi­sy­wać jako odręb­ne dzie­dzi­no­we pod­sys­te­my, wybie­rać, kupo­wać i wdra­żać osob­no (pole­cam arty­kuł fir­my K2Consulting: Jak zjeść sło­nia w ter­mi­nie i budże­cie i się przy tym nie udła­wić?).

Obecny poziom stan­da­ry­za­cji pozwa­la na rela­tyw­nie łatwą inte­gra­cję sys­te­mów róż­nych pro­du­cen­tów. Praktyka poka­zu­je, że wdro­że­nie kil­ku dobrze dobra­nych pod­sys­te­mów osob­no, jest znacz­nie tań­sze i trwa kró­cej niż kom­pro­mi­so­wy (naj­czę­ściej tak zwa­ny zgni­ły kom­pro­mis) wybór jed­ne­go uni­wer­sal­ne­go sys­te­mu i dosto­so­wy­wa­nie go do swo­ich potrzeb (tak zwa­na kastomizacja).

Struktura takie­go pro­jek­tu wyglą­da następująco:

(źr. Jarosław Żeliński, opra­co­wa­nie wła­sne, 2005 rok)

Analiza biz­ne­so­wa obej­mu­je wyłącz­nie obszar stra­te­gii i pro­ce­sów biz­ne­so­wych. Wdrożenie poprze­dza­ne jest ana­li­zą całej orga­ni­za­cji, wydzie­le­nie w niej nie­za­leż­nych obsza­rów dzie­dzi­no­wych (np. rachun­ko­wość, zarzą­dza­nie pro­ce­sa­mi pra­cy, zarzą­dza­nie wie­dzą, por­tal klien­ta, zarzą­dza­nie i ste­ro­wa­nie pro­duk­cją, zarzą­dza­nie pro­ce­sem sprze­da­ży, inne).

Każdy obszar cechu­je się tymi trze­ma pozio­ma­mi: stra­te­gia, pro­ce­sy, reali­za­cja. Na eta­pie ana­li­zy potrzeb pro­wa­dzi­my audyt i mode­lo­wa­nie pro­ce­sów. Zakładamy, że szcze­gó­ły tego ?jak pra­cu­je­my? i tak ule­gną zmia­nie po wdro­że­niu nowe­go narzę­dzia pra­cy, więc pomi­ja­my je na tym eta­pie (zosta­ną okre­ślo­ne pod­czas wdro­że­nia). Jeżeli ana­li­za wyka­że, że ist­nie­je obszar nie­stan­dar­do­wy w orga­ni­za­cji, tyl­ko dla tego obsza­ru pro­wa­dzi się szcze­gó­ło­wą ana­li­zę, gdyż w tym obsza­rze będzie (naj­praw­do­po­dob­niej) wdra­ża­ne roz­wią­za­nie dedykowane.

Co do czę­ści stan­dar­do­wej moż­na zro­bić to same­mu korzy­sta­jąc z tanich ofert dostęp­nych w sie­ci np. http://​rfp​-buil​der​.com/ (Ready-to-use RFI/RFP Templates Designed by expert ana­ly­sts for any softwa­re selec­tion pro­ject) gdzie moż­na nabyć gotow­ce. (patrz mój wcze­śniej­szy arty­kuł: Ile zapła­ci­łeś za wyko­na­nie SIWZ na sys­tem ERP?).

Tak więc zin­te­gro­wa­ny sys­tem ERP II nie musi ozna­czać od jed­ne­go dostaw­cy”. Po pierw­sze trud­no jest szcze­gó­ło­wo wyspe­cy­fi­ko­wać taki sys­tem, po dru­gie nie raz oka­zu­je się, że sys­te­my od wszyst­kie­go są do niczego”…

Opracowywanie wyma­gań to pla­no­wa­nie zmian. Nie ma sen­su spi­sy­wa­nie szcze­gó­łów tej pra­cy, jeże­li wdra­ża­ne zmian spo­wo­du­je powsta­nie np. nowych pro­ce­dur, wyni­ka­ją­cych z celu pro­jek­tu. Zupełnie wystar­czy wie­dza o pro­ce­sach i ich pro­duk­tach (co i po co robi­my). To jak one będą powsta­wa­ły (w jaki spo­sób) będzie efek­tem wdro­że­nia np. nowe­go sys­te­mu ERP i ist­nie­ją­cych ogra­ni­czeń, reguł biz­ne­so­wych. (cytat z arty­ku­łu: Modelowanie biz­ne­so­we c.d. ? know-how, gdzie ono jest?).