Od pew­ne­go cza­su pro­mo­wa­na jest ide­am ​„małych ERP”, oto jed­na z takich «pro­mocj”:

Na ryn­ku wyraź­nie poja­wił się popyt na tzw. ?małe ERP?, któ­re Patrycja Ptaszek-Strączyńska cha­rak­te­ry­zu­je jako roz­wią­za­nia do szyb­kie­go wdro­że­nia, z niską barie­rą wej­ścia, kosz­ta­mi utrzy­ma­nia oraz łatwym up-gradem.

- Popyt ten wystą­pił ze stro­ny przed­się­biorstw pro­duk­cyj­nych, usłu­go­wych i han­dlo­wych zatrud­nia­ją­ce od 20 do 50 osób, któ­rych roz­wój orga­ni­za­cyj­ny moż­na okre­ślić na wstęp­ną fazę wzro­stu ? wyja­śnia. – Wspólna cechą tej gru­py klien­tów był brak zde­fi­nio­wa­nych celów biz­ne­so­wych oraz nie wpro­wa­dza­nie metod MbO, co ma ogrom­ny wpływ na cenę roz­wią­za­nia. (za Na ryn­ku poja­wił się na tzw. «małe ERP».).

Najpierw kil­ka wyja­snień, czyli

Czym jest MbO i SMART

MbO to Management by Objectives czy­li po pro­tu zarzą­dza­nie przez cele. O SMART pisa­łem nie raz w kon­tek­ście IT ale ogól­nie fak­tycz­nie cho­dzi tak­że o cele. SMART w pol­skiej lite­ra­tu­rze jest czę­sto przed­sta­wia­ny jako akro­nim od słów: Sprecyzowane, Mierzalne, Akceptowane, Realistyczne, Terminowe (w języ­ku ang. akro­nim brzmi tak samo: Simple, Measurable, Achievable, Relevant, Timely defi­ned). W języ­ku angiel­skim (w ory­gi­na­le) jed­nak brzmi to wła­ści­wiej: pro­ste, mie­rzal­ne, osią­gal­ne, odpo­wied­nie, okre­ślo­ne w cza­sie. W sumie nic nowe­go ani spek­ta­ku­lar­ne­go (bo jak widać meto­da SMART jest SMART). (inne moje arty­ku­ły na temat SMART)

Tak więc zarzą­dza­my sta­wia­jąc cele, a te cele powin­ny być pro­ste, mie­rzal­ne, osią­gal­ne, odpo­wied­nie, okre­ślo­ne w cza­sie. Tak jed­nak Pan [[Peter Drucker]] zale­ca zarzą­dzać przed­się­bior­stwem. Zarządzanie przed­się­bior­stwem to pro­ces ciągły.

Zarządzanie

W sfe­rze zarzą­dza­nia mamy do czy­nie­nia z reali­za­cją stra­te­gii fir­my. Strategia okre­śla spo­sób osią­ga­nia celów co spro­wa­dza się do wyspe­cy­fi­ko­wa­nia kto, co i jak ma robić. Co mamy? Procesy biznesowe:

(powyż­szy model to struk­tu­ra audy­tu: audyt taki spraw­dza, czy wszyst­kie działania/procesy w fir­mie mają (jest zna­ny) powyż­szy kom­plet­ny opis, wię­cej w dal­szej czę­ści artykułu).

Zarządzanie przez cele, czy­li nale­ży je okre­ślić: są to pro­duk­ty pra­cy i ich jakość. Jakość nale­ży mie­rzyć. Tak więc mamy SMART bo te cele powin­ny być:

1. pro­ste: powin­ny być zro­zu­mia­łe dla wykonawcy,
2. mie­rzal­ne: sko­ro celem jest pro­dukt dzia­ła­nia to dla oce­ny tego czy ​„jest wła­ści­wy” muszą ist­nieć mia­ry osią­gnię­cia wła­ści­we­go efek­tu, mie­rzy­my jed­nak jakość pro­ce­su a nie same­go pro­duk­tu (ma zna­cze­nie czy wytwo­rzo­ny stół jest bar­dzo dobry ale ma tez zna­cze­nie ile cza­su trwa­ło jego wytworzenie…),
3. osią­gal­ne: sta­wia­jąc cel w posta­ci opi­su efek­tów pra­cy i jej jako­ści musza one być moż­li­we do osią­gnie­cie, w prze­ciw­nym wypa­du po pro­tu demo­ra­li­zu­ją wykonawców,
4. odpo­wied­nie: czy­li muszą być zgod­ne ze stra­te­gią fir­my, oczy­wi­stym jest, że wytwa­rza­nie rze­czy nie wspie­ra­ją­cych stra­te­gii fir­my we wła­ści­wy spo­sób nie jest dro­gą do sukcesu,
5. okre­ślo­ne w cza­sie: czas zawsze jest jed­nym z kry­te­riów oce­ny bo wszyst­ko ma sens w kon­kret­nym cza­su, towar dostar­czo­ny na ram­pę po odjeź­dzie pocią­gu jest bez­war­to­ścio­wy nawet jeże­li jest to towar naj­wyż­szej jakości.

A teraz o ERP

Wśród wie­lu wyma­gań na opro­gra­mo­wa­nie wspo­ma­ga­ją­ce zarzą­dza­nie poja­wia się, ale nie musi, pozy­cja o nazwie: kon­tro­la prze­pły­wu pra­cy (popu­lar­ny work­flow). Czym jest ów workflow?

Przepływ pra­cy, pro­ces biz­ne­so­wy, to łań­cuch czynności/aktywności. Każda z nich ma cele SMART, każ­da ma wyko­naw­cę. jako całość tak­że mają cel i odpo­wie­dzial­ne­go. Każda aktyw­ność to jakaś praca.

Gdzie tu ERP? Każde opro­gra­mo­wa­nie, ERP tak­że, to jakiś zespół usług (sys­tem świad­czy użyt­kow­ni­ko­wi usłu­gi) nazy­wa­nych wyma­ga­nia­mi funk­cjo­nal­ny­mi czy przy­pad­ka­mi uży­cia. Jeżeli mamy wdro­żyć sys­tem ​„z pudeł­ka”, taki małyERP to nale­ży się pogo­dzić z jed­nym: sys­tem jako sam zbiór funk­cjo­nal­no­ści da się rela­tyw­nie łatwo wdro­żyć, to wyma­ga prze­szko­le­nia użyt­kow­ni­ków. Jak tu postę­po­wać i jakie są ryzyka?

1. Skoro ocze­ku­je­my tyl­ko kon­kret­nych funk­cjo­nal­no­ści to wystar­czy, że sys­tem wspie­ra wszyst­kie lub tyl­ko wybra­ne (patrz dia­gram) aktyw­no­ści (przy­pad­ki uży­cia sys­te­mu), wie­dzę o wła­ści­wej kolej­no­ści ich wyko­na­nia posia­da użyt­kow­nik (zna procedury).
2. Jeżeli ocze­ku­je­my wspar­cia dla ​„prze­pły­wu pra­cy” (chce­my narzu­cić kolej­ność wyko­ny­wa­nia tych czyn­no­ści, wdro­żyć pro­ces) to nabie­ra zna­cze­nia to czy sys­tem zna wła­ści­wą kolej­ność i jest on moż­li­wa do zmiany.
3. Zawsze poja­wia się ryzy­ko, czy na eta­pie wybo­ru sys­te­mu mają­ce­go set­ki moż­li­wo­ści, coś waż­ne­go dla nas nam nie umknie. Jeżeli tak to sys­tem może mieć ogra­ni­czo­na przydatność.

Tak więc decy­du­jąc się małe ERP łatwe do wdro­że­nia trze­ba mieć świa­do­mość ryzy­ka. Sposobem unik­nię­cia powyż­szych ryzyk jest ana­li­za i mode­lo­wa­nie pro­ce­sów biz­ne­so­wych oraz testo­wa­nie potrzeb i ich wyspe­cy­fi­ko­wa­nie z taki­mi mode­la­mi ​„w ręku”. Wtedy nic nam nie umknie jed­nak taka ana­li­za pod­no­si koszt całe­go pro­jek­tu. Ile ryzy­ku­je­my? Na pew­no war­tość sys­te­mu (może­my po zaku­pi e odkryć, że jest nie­przy­dat­ny), moż­li­we, że rato­wa­nie go będzie wyma­ga­ło prze­ró­bek, te zaś tak­że są kosztowne.

Czy warto?

Tak, zawsze war­to pod­jąć pró­bę zaku­pu sys­te­mu ERP mini­mal­nym kosz­tem. Najprostsza meto­da to testo­wa eks­plo­ata­cja (zakup na bazie samej pre­zen­ta­cji sys­te­mu gorą­co odra­dzam!). Jednak na tę ścież­kę mogą sobie pozwo­lić fir­my, któ­rych spo­sób dzia­ła­nia jest ​„stan­dar­do­wy” (co by to nie mia­ło tu zna­czyć ;)). Jeżeli tyl­ko ​„czu­je­my”, że wyróż­nia­my się czym­kol­wiek na ryn­ku i to sta­no­wi o naszej pozy­cji na nim, odra­dzam ​„gotow­ce” bo te zrów­na­ją fir­mę z ​„resz­tą świa­ta”. Czy to zna­czy, że ma to być sys­tem dedy­ko­wa­ny? Nie! To zna­czy, że war­to wyko­nać jed­nak model pro­ce­sów, upew­nić się, że jeste­śmy MbO i SMART (i napra­wić ewen­tu­al­ne bra­ki), zna­leźć nasze źró­dło prze­wa­gi. Dla tego jed­ne­go obsza­ru (źró­dła prze­wa­gi) wyko­nać dokład­ną ana­li­zę i zapro­jek­to­wać dedy­ko­wa­ne roz­wią­za­nie, a ​„resz­tę” obsłu­żyć dobrze dobra­nym, goto­wym, małym ERP. Takie bada­nie przed wdro­że­niem to audyt fir­my, audyt tego czy fir­ma jest MbO i SMART (prop­nu­je nie infor­ma­ty­zo­wać bała­ga­nu i nie­wie­dzy), ana­li­za przed­wdro­że­nio­wa czy ana­li­za potrzeb to dopie­ro kolej­ne eta­py pro­jek­tu: spe­cy­fi­ko­wa­nie wymagań.

Aha, chy­ba widać już, że nale­ży robić to przed wybo­rem i zaku­pem sys­te­mu ERP, nigdy po, bo wte­dy jest za późno.