Od pewnego czasu promowana jest ideam “małych ERP”, oto jedna z takich ‘promocj”:

Na rynku wyraźnie pojawił się popyt na tzw. ?małe ERP?, które Patrycja Ptaszek-Strączyńska charakteryzuje jako rozwiązania do szybkiego wdrożenia, z niską barierą wejścia, kosztami utrzymania oraz łatwym up-gradem.

– Popyt ten wystąpił ze strony przedsiębiorstw produkcyjnych, usługowych i handlowych zatrudniające od 20 do 50 osób, których rozwój organizacyjny można określić na wstępną fazę wzrostu ? wyjaśnia. – Wspólna cechą tej grupy klientów był brak zdefiniowanych celów biznesowych oraz nie wprowadzanie metod MbO, co ma ogromny wpływ na cenę rozwiązania. (za Na rynku pojawił się  na tzw. ‘małe ERP’.).

Najpierw kilka wyjasnień, czyli

Czym jest MbO i SMART

MbO to Management by Objectives czyli po protu zarządzanie przez cele. O SMART pisałem nie raz w kontekście IT ale ogólnie faktycznie chodzi także o cele. SMART w polskiej literaturze jest często przedstawiany jako akronim od słów: Sprecyzowane, Mierzalne, Akceptowane, Realistyczne, Terminowe (w języku ang. akronim brzmi tak samo: Simple, Measurable, Achievable, Relevant, Timely defined). W języku angielskim (w oryginale) jednak brzmi to właściwiej: proste, mierzalne, osiągalne, odpowiednie, określone w czasie. W sumie nic nowego ani spektakularnego (bo jak widać metoda SMART jest SMART). (inne moje artykuły na temat SMART)

Tak więc zarządzamy stawiając cele, a te cele powinny być proste, mierzalne, osiągalne, odpowiednie, określone w czasie. Tak jednak Pan [[Peter Drucker]] zaleca zarządzać przedsiębiorstwem. Zarządzanie przedsiębiorstwem to proces ciągły.

Zarządzanie

W sferze zarządzania mamy do czynienia z realizacją strategii firmy. Strategia określa sposób osiągania celów co sprowadza się do wyspecyfikowania kto, co i jak ma robić. Co mamy? Procesy biznesowe:

(powyższy model to struktura audytu: audyt taki sprawdza, czy wszystkie działania/procesy w firmie mają (jest znany) powyższy kompletny opis, więcej w dalszej części artykułu).

Zarządzanie przez cele, czyli należy je określić: są to produkty pracy i ich jakość. Jakość należy mierzyć. Tak więc mamy SMART bo te cele powinny być:

  1. proste: powinny być zrozumiałe dla wykonawcy,
  2. mierzalne: skoro celem jest produkt działania to dla oceny tego czy “jest właściwy” muszą istnieć miary osiągnięcia właściwego efektu, mierzymy jednak jakość procesu a nie samego produktu (ma znaczenie czy wytworzony stół jest bardzo dobry ale ma tez znaczenie ile czasu trwało jego wytworzenie…),
  3. osiągalne: stawiając cel w postaci opisu efektów pracy i jej jakości musza one być możliwe do osiągniecie, w przeciwnym wypadu po protu demoralizują wykonawców,
  4. odpowiednie: czyli muszą być zgodne ze strategią firmy, oczywistym jest, że wytwarzanie rzeczy nie wspierających strategii firmy we właściwy sposób nie jest drogą do sukcesu,
  5. określone w czasie: czas zawsze jest jednym z kryteriów oceny bo wszystko ma sens w konkretnym czasu, towar dostarczony na rampę po odjeździe pociągu jest bezwartościowy nawet jeżeli jest to towar najwyższej jakości.

A teraz o ERP

Wśród wielu wymagań na oprogramowanie wspomagające zarządzanie pojawia się, ale nie musi, pozycja o nazwie: kontrola przepływu pracy (popularny workflow). Czym jest ów workflow?

Przepływ pracy, proces biznesowy, to łańcuch czynności/aktywności. Każda z nich ma cele SMART, każda ma wykonawcę. jako całość także mają cel i odpowiedzialnego. Każda aktywność to jakaś praca.

Gdzie tu ERP? Każde oprogramowanie, ERP także, to jakiś zespół usług (system świadczy użytkownikowi usługi) nazywanych wymaganiami funkcjonalnymi czy przypadkami użycia. Jeżeli mamy wdrożyć system “z pudełka”, taki małyERP to należy się pogodzić z jednym: system jako sam zbiór funkcjonalności da się relatywnie łatwo wdrożyć, to wymaga przeszkolenia użytkowników. Jak tu postępować i jakie są ryzyka?

  1. Skoro oczekujemy tylko konkretnych funkcjonalności to wystarczy, że system wspiera wszystkie lub tylko wybrane (patrz diagram) aktywności (przypadki użycia systemu), wiedzę o właściwej kolejności ich wykonania posiada użytkownik (zna procedury).
  2. Jeżeli oczekujemy wsparcia dla “przepływu pracy” (chcemy narzucić kolejność wykonywania tych czynności, wdrożyć proces) to nabiera znaczenia to czy system zna właściwą kolejność i jest on możliwa do zmiany.
  3. Zawsze pojawia się ryzyko, czy na etapie wyboru systemu mającego setki możliwości, coś ważnego dla nas nam nie umknie. Jeżeli tak to system może mieć ograniczona przydatność.

Tak więc decydując się  małe ERP łatwe do wdrożenia trzeba mieć świadomość ryzyka. Sposobem uniknięcia powyższych ryzyk jest analiza i modelowanie procesów biznesowych oraz testowanie  potrzeb i ich wyspecyfikowanie z takimi modelami “w ręku”. Wtedy nic nam nie umknie jednak taka analiza podnosi koszt całego projektu. Ile ryzykujemy? Na pewno wartość systemu (możemy po zakupi e odkryć, że jest nieprzydatny), możliwe, że ratowanie go będzie wymagało przeróbek, te zaś także są kosztowne.

Czy warto?

Tak, zawsze warto podjąć próbę zakupu systemu ERP minimalnym kosztem. Najprostsza metoda to testowa eksploatacja (zakup na bazie samej prezentacji systemu gorąco odradzam!).  Jednak na tę ścieżkę mogą sobie pozwolić firmy, których sposób działania jest “standardowy” (co by to nie miało tu znaczyć ;)). Jeżeli tylko “czujemy”, że wyróżniamy się czymkolwiek na rynku i to stanowi o naszej pozycji na nim, odradzam “gotowce” bo te zrównają firmę z “resztą świata”. Czy to znaczy, że ma to być system dedykowany? Nie! To znaczy, że warto wykonać jednak model procesów, upewnić się, że jesteśmy MbO i SMART (i naprawić ewentualne braki), znaleźć nasze źródło przewagi. Dla tego jednego obszaru (źródła przewagi) wykonać dokładną analizę i zaprojektować dedykowane rozwiązanie, a “resztę” obsłużyć dobrze dobranym, gotowym, małym ERP. Takie badanie przed wdrożeniem to audyt firmy, audyt tego czy firma jest MbO i SMART (propnuje nie informatyzować bałaganu i niewiedzy), analiza przedwdrożeniowa czy analiza potrzeb to dopiero kolejne etapy projektu: specyfikowanie wymagań.

Aha, chyba widać już, że należy robić to przed wyborem i zakupem systemu ERP, nigdy po, bo wtedy jest za późno.

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