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

Jarosław Żeliński

Jarosław Żeliński: autor, badacz i praktyk analizy systemowej organizacji: 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 nieetatowy wykładowca akademicki, 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).

Ten post ma 2 komentarzy

  1. Piotr

    Skrót ERP nie ozna­cza Enterprise Resource Management a Enterprise Resource Planning. Polecam jed­nak lek­tu­rę Wikipedii (wer­sja angielska).
    ERP II to ERP roz­sze­rzo­ne o usłu­gi (naj­czę­ściej webo­we) dostęp­ne dla klien­tów, dostaw­ców, pra­cow­ni­ków i innych akto­rów”.

    1. Jarek Żeliński

      Mój błąd (ERP a błęd­ne ERM), popra­wi­łem. dzię­ku­ję za zwró­ce­nie uwagi.

Dodaj komentarz

Witryna wykorzystuje Akismet, aby ograniczyć spam. Dowiedz się więcej jak przetwarzane są dane komentarzy.