Tomasz Wyrozumski

Quo vadis ERP?

Abstrakt. Artykuł dotyczy systemów wspomagających pracę przedsiębiorstw. Próbujemy prześledzić w nim historię takich rozwiązań, ich aktualny stan rozwoju, a także zastanawiamy się nad kierunkami przyszłej ewolucji. Zwracamy przy tym szczególną uwagę na wzajemne oddziaływanie informatyki i biznesu, pokazując w jaki sposób potrzeby wpływają na powstawanie możliwości, a możliwości generują nowe potrzeby. Analizując uwarunkowania informatyczne, ekonomiczne i społeczne oraz posiłkując się konkretnymi przykładami, pokazujemy, jak dochodzi do jednoczenia się różnych koncepcji dotyczących zarządzania firmą.

1. Błękitna krew

Podobno, warunkiem koniecznym (a czasem nawet wystarczającym) zrobienia kariery w informatyce korporacyjnej jest znajomość odpowiednio dużej liczby trzyliterowych skrótów oraz umiejętność sprawnego nimi żonglowania. Zaczęliśmy dawno temu od CPU, HDD, czy IDE, by poprzez DAO i ADO wzbić się na wyżyny SOA. Dwuliterowość BI stanowi najwyższą formę nobilitacji w tym jakże szlachetnym towarzystwie, zaś skróty czteroliterowe, jak SaaS przywołują skojarzenia z nouveau riche. A jak należałoby uplasować ERP, którym zamierzamy się zająć? W naszym odczuciu porównać je można z rodem starym, zasłużonym, powszechnie znanym i poważanym, niezbyt ochoczo podążającym za najnowszą modą, żyjącym spokojnie i dostatnio na swoich włościach, posiadającym wiele gałęzi rozrzuconych po całym świecie i po wszystkich branżach. Nikt nie pyta, jak wspiął się na szczyt, nikt nie kwestionuje jego pozycji, niechętnie, ale jednak liczą się z jego opinią towarzyscy debiutanci, choć wielu z przyjemnością przypięłoby mu etykietkę dinozaura.

Skąd pochodzi, dokąd zmierza, jaka przyszłość się przed nim rysuje?

2. Prehistoria

Nazwa komputercałkiem słusznie sugeruje związek z obliczeniami, a wywodzi się bynajmniej nie ze sposobu w jaki działa procesor, lecz z najwcześniejszych zastosowań maszyn, po polsku zwanych niegdyś „liczącymi”. W istocie pierwsze takie urządzenia wykorzystywane były głównie w nauce oraz technice, a zwłaszcza w wojskowości. Przecierając sobie drogę do biznesu w naturalny sposób trafiły w ten jego obszar, gdzie zapotrzebowanie na obliczenia było największe – bądźmy sprawiedliwi – obliczenia niezbyt ambitne, ale za to bardzo żmudne i uciążliwe. Jak łatwo zgadnąć, myślimy tu o naliczaniu wynagrodzeń pracowników. Warto dodać, że zagadnienie dotyczyło wyłącznie firm wielkich i to nie tylko z uwagi na skalę problemu, a więc wielkość zatrudnienia, które, nota bene, w ówczesnych korporacjach było na ogół większe niż dziś, lecz również z innego bardzo prostego powodu: ceny zarówno samych komputerów, jak też ich pracy były na tyle wysokie, że firmy małe, nawet gdyby chciały, nie mogłyby sobie pozwolić na korzystanie z dobrodziejstw maszyn. Podsumowując, pierwsze zastosowania komputerów w biznesie (a więc i pierwsze programy służące przedsiębiorstwom) dotyczyły rozwiązywania problemów „twardych”, dobrze określonych i precyzyjnie zalgorytmizowanych, a co więcej – bardzo podobnych w różnych firmach. Ponadto, zastosowania owe miały miejsce wyłącznie w dużych korporacjach.

Żyjący na przełomie piętnastego i szesnastego wieku Luca Pacioli, prowadząc rachunki klasztoru Franciszkanów tylko pozornie skomplikował sobie życie, gdy postanowił rejestrować podwójnie każdą operację – na koncie aktywnym i pasywnym. I tak, chcąc zredukować prawdopodobieństwo pomyłek, stworzył podwaliny współczesnej rachunkowości. Zbadanie, czy konta bilansują się po każdym księgowaniu, jest zajęciem żmudnym dla człowieka, lecz bajecznie prostym dla komputera. Księgowość była zatem kolejnym obszarem biznesu, w który wkroczyła komputeryzacja, a przyczynił się do tego bez wątpienia rozwój nośników pamięci. Chodziło bowiem nie tylko o to, by coś przeliczyć, lecz również o to, by dane przechować, do ewentualnego późniejszego użycia. Stworzony w 1970 roku przez Edgara Franka Codda model relacyjny wydaje się niemal wymarzonym dla księgowości, choć przecież jesteśmy świadomi, jak szeroką gamę zastosowań posiada. Mówiąc o początkach relacyjnych baz danych byłoby zapewne nietaktem nie wspomnieć Lawrenca Josepha Ellisona, gdyż to właśnie on bodaj jako pierwszy na poważnie zainteresował się koncepcją Codda i postanowił zaimplementować ją w praktyce, tworząc firmę, która obecnie nosi nazwę Oracle. Zaznaczmy jednak, że to nie biznes (a już na pewno nie mały) należał do pierwszych odbiorców systemów bazodanowych. Łatwo się domyślić, że znacznie większe zapotrzebowanie na gromadzenie informacji oraz możliwości sfinansowania związanych z tym przedsięwzięć wykazywały amerykańskie instytucje rządowe. Wspomniany Larry Ellison, jeszcze zanim usamodzielnił się biznesowo, pracował przy projektach realizowanych między innymi dla Centralnej Agencji Wywiadowczej.

Urządzeniem towarzyszącym komputerowi niemal od samych jego narodzin, jest robot, który potrafi zapisywać informacje na papierze, powszechnie zwany drukarką. Z upływem lat zmieniał się oczywiście jego wygląd, zasada działania, a nawet podstawowe przeznaczenie. Starsi pamiętają jeszcze zapewne, że wyniki pracy programów komputerowych odbierało się ongiś w tzw. „okienku”, w postaci grubych plików arkuszy, stanowiących produkt drukarek wierszowych, afiliowanych przy mainframach. Wbrew pozorom, w przedsiębiorstwach zawsze zużywało się sporo papieru (choć zapewne nigdy tyle, co w administracji), więc właśnie drukarka otworzyła drzwi do kolejnego obszaru komputeryzacji firm. Mamy na myśli oczywiście elementarną automatyzację procesów sprzedaży, gospodarki magazynowej, serwisu, ewentualnie innych zbliżonych. Swoistą ironią losu jest fakt, iż u początków komputeryzacji (i to tej dotyczącej przedsiębiorstw), przewidywano, że pociągnie ona za sobą redukcję zużycia papieru, a stało się dokładnie odwrotnie. Łatwość drukowania sprawiła, że zaczęto przenosić na białe karty również to, co nikomu do niczego nie było potrzebne oraz mnożyć dokumenty, jakich kiedyś w ogóle by nie wystawiano z uwagi na ich małą użyteczność przy dużych kosztach związanych z wypisywaniem ręcznie (lub na maszynie). Również w przypadku pomyłki znacznie prościej było wydrukować coś jeszcze raz, niż nanosić korekty, tak jak się to czyniło w epoce przeddrukarkowej. Wreszcie, konstrukcyjne uwarunkowania drukarek sprawiały, iż najłatwiej było produkować strony tego samego formatu, co w praktyce owocowało znacznym spadkiem ekonomiczności wykorzystania papieru – znaczne jego powierzchnie pozostawały niezadrukowane.

Warto w tym miejscu uczynić pewne spostrzeżenie o ogólniejszym charakterze: otóż inwencja ludzi w zakresie wykorzystania komputerów okazała się wówczas w pewnym sensie dość ograniczona. Zamiast zastanawiać się nad zasadniczym przemodelowaniem procesów oraz wymianą informacji w formie elektronicznej, skoncentrowali się oni na opracowywaniu coraz lepszych technik druku, powielając tym samym wcześniejszy, prekomputerowy sposób funkcjonowania, a usprawniając jedynie pewien drobny jego element. W istocie jest to dość typowe dla rozwoju naszej cywilizacji, że nowe wynalazki zaczynają funkcjonować w obrębie starego paradygmatu, by dopiero po pewnym czasie go przełamać i rozwinąć skrzydła. Wystarczy przywołać znany przykład pierwszych samochodów, które stosunkowo długo przypominały swoim wyglądem pojazdy konne, choć przecież można je było konstruować już wtedy w całkiem inny sposób. Oczywiście, ktoś mógłby powiedzieć, iż w owych czasach, gdy porzucono ręczne wypisywanie faktur na rzecz ich drukowania z użyciem komputerów, nie było jeszcze sieci, Internetu, EDI, itp., lecz jak racjonalnie wytłumaczyć fakt, że dopiero całkiem niedawno nasze władze zezwoliły na przesyłanie faktur pocztą elektroniczną, a wiele firm i tak chce otrzymywać je na papierze, tak na wszelki wypadek? A ile jeszcze podobnych absurdów można by znaleźć – zwłaszcza w naszym kraju i zwłaszcza w sferze informatyzacji administracji publicznej? Aż strach pomyśleć…

3. Od M…

Wraz z upowszechnianiem się komputerów rozmyślano intensywnie nad tym, jakie jeszcze zastosowania mogłyby one znaleźć w przedsiębiorstwach. Ludzie rozumiejący, jak potężne możliwości tkwią w maszynach cyfrowych – nazwijmy ich informatykami – zdawali sobie doskonale sprawę, że naliczanie płac, gromadzenie zapisów księgowych, drukowanie standardowych dokumentów, czy produkowanie elementarnych zestawień (raportów), to w istocie bardzo niewiele w porównaniu z tym, do czego komputerów używano już w obszarach nauki i techniki.

Można zresztą znów pokusić się o pewne uogólnienie. Otóż, wydaje się, że wkraczanie komputerów w świat nauki miało charakter całkowicie odmienny, niż ich ekspansja w świecie biznesu. W nauce bowiem najpierw pojawiały się problemy wymagające użycia maszyn, zaś same maszyny (wraz z oprogramowaniem) były odpowiedzią na zidentyfikowane potrzeby. W dziedzinie fizyki i jej zastosowań znano wiele zagadnień, których rozwiązanie sprowadzało się do implementacji elementarnych praw, jak równania Newtona lub Maxwella, jednak wymagało przeprowadzenia ogromnej ilości obliczeń, co przy użyciu kredy i tablicy było praktycznie niewykonalne. Każdy student pierwszego roku potrafi zdiagonalizować formę kwadratową i poradzi sobie z nią bez trudu, jeśli wymiar przestrzeni wynosi 3, 4, 5… Ale jeśli macierz ma kilka tysięcy wierszy i kolumn? Jak wiadomo, zagadnienie dwóch ciał można rozwiązać ściśle i nie jest to specjalnie skomplikowane, ale gdy pojawi się trzecie, skazani jesteśmy jedynie na lepsze lub gorsze przybliżenia modelowe. Można zatem powiedzieć, że uczeni już od bardzo dawana czekali na komputery – gdyby dostali je do ręki Kopernik, Kepler, Lagrange lub Boltzmann, wiedzieliby doskonale, co z nimi zrobić.

Biznes wykazywał i wykazuje nadal znacznie większy konserwatyzm. Tu odwrotnie, najpierw pojawiały się możliwości, a więc komputery i oprogramowanie (stworzone na potrzeby nauk), potem najświatlejsi pionierzy wskazywali obszary potencjalnych zastosowań, następnie prekursorzy wdrażali odpowiednie rozwiązania, a dopiero dużo później podążała za nimi większość przedsiębiorstw, aż w końcu nikt nie mógł już sobie wyobrazić, by to, czy tamto można było robić bez użycia maszyn.

Identyfikując zatem kolejne obszary, w których użycie komputerów mogłoby usprawnić pracę przedsiębiorstw, dostrzeżono pewien problem, dotyczący w istocie niemal każdej branży. Jeżeli firma produkuje coś z surowców (komponentów), osoba odpowiedzialna za ową produkcję i jej ciągłość, najchętniej zapełniłaby po brzegi magazyny materiałów i utrzymywała w nich jak największy poziom zapasów – na wszelki wypadek. Dokładnie odwrotnie myśli jednak dyrektor finansowy. Z jego punktu widzenia pełny magazyn to zablokowana gotówka, która mogłaby pracować, a więc czysta strata. Dlatego też on z kolei wolałby widzieć pusty magazyn oraz dostawy docierające dokładnie wtedy, gdy pojawiają się konkretne zlecenia produkcyjne. Oczywiście, podobny problem dotyczy firm handlowych, a nawet usługowych i zapewne jest tak stary, jak sam handel, czy rzemiosło.

Gdy pod koniec dziewiętnastego stulecia elegant, powiedzmy z Tarnowa, zapragnął nabyć parasol według najnowszej mody, miejscowy kupiec gotów był sprowadzić mu go niezwłocznie z Krakowa, Lwowa lub Wiednia. Sam na składzie takich jednak nie posiadał, gdyż nie mógł liczyć na odpowiedni zbyt. Zaopatrywał się natomiast na bieżąco w szwarc, mydło i powidła śliwkowe, w ilościach wynikających z własnego doświadczenia. W latach sześćdziesiątych ubiegłego wieku doświadczenie to (choć bardziej dotyczące produkcji niż czystego handlu) stało się przedmiotem badań naukowych z dziedziny zarządzania. Wtedy też po raz pierwszy pojawił się w użyciu skrót MRP, oznaczający Material Requirements Planning, odnoszący się do procesów nakierowanych na optymalizację wytwarzania, a więc minimalizację kosztów przy założeniu zaspokojenia popytu.

Jako że nie tylko surowce potrzebne są w procesie produkcji, lecz również inne zasoby (pracownicy, maszyny, energia itp.), koncepcja MRP stosunkowo szybko przeewoluowała do tzw. MRP II, czyli Manufacturing Resource Planning. Zarówno MRP, jak i MRP II rozwijały się pod skrzydłami powstałej w 1957 roku organizacji APICS (American Production and Inventory Control Society), która obecnie określa się jako The Association for Operations Management.

Dopiero w latach osiemdziesiątych korporacje zaczęły budować systemy informatyczne, których zadaniem było optymalizowanie procesów wytwórczych. Trudno powiedzieć, czy inspiracją były tu badania teoretyczne, którym patronowało APICS, czy też raczej problemy dnia codziennego z jednej, a rosnące możliwości i ekspansja komputerów w innych dziedzinach – z drugiej strony. Być może, w jakimś stopniu jedno i drugie. Wydaje się natomiast, że opublikowany przez APICS w 1989 roku dokument MRP II Standard Systembył reakcją na fakt, iż systemy tego typu zaczęły już funkcjonować w przedsiębiorstwach. Spróbowano więc uporządkować związane z tym kwestie i wyznaczono funkcje, jakie powinno realizować oprogramowanie MRP II. Przedstawiamy je poniżej za [BKM11]

Sales and Operation Planning(SOP)– Planowanie sprzedaży i produkcji
Demand Management (DEM)– Prognozowanie popytu
Master Production Scheduling(MPS)– Harmonogramowanie produkcji finalnej
Material Requirement Planning (MRP)– Planowanie zapotrzebowania na materiały
Bill of Material Subsystem(BOM) – Wspomaganie zarządzania materiałami
Inventory Transaction System(INV)– Gospodarka magazynowa
Scheduled Receipts Subsystem(SRS)- Sterowanie zleceniami
Shop Floor Control (SFC)– Sterowanie stanowiskami roboczymi
Capacity Requirement Planning(CRP)– Zarządzanie mocami przerobowymi
Input/Output Control(I/OC)– Sterowanie kolejkami na stanowiskach roboczych
Purchasing(PUR)– Zakupy materiałów
Distribution Resource Planning (DRP)– Planowanie możliwości dystrybucyjnych
Tooling Planning and Control- Planowanie dostępności narzędzi
Financial Planning Interface – Interfejsy modułów finansowych
Business Planning– Planowanie biznesowe
Simulations– Symulacje (wpływu wprowadzanych zmian na funkcjonowanie firmy)
Performance Measurement– Pomiar efektywności (wykorzystania systemu MRP II)

Standaryzacja nie jest oczywiście sztuką dla sztuki, lecz powinna zawsze czemuś służyć – generalnie wygodzie człowieka. Gdy kupujemy jakieś urządzenie elektryczne, jest nam miło, jeżeli wtyczka, którą zakończony jest jego przewód zasilający, pasuje do gniazdka w naszym domu, a wymagane przezeń napięcie i częstotliwość prądu odpowiada parametrom naszej sieci. Jak wiadomo, gdy zaczynamy przemieszczać się po świecie, sytuacja cokolwiek się komplikuje… Czy jednak standaryzowanie ogólnych funkcjonalności systemów informatycznych ma jakiś głębszy sens? Wątpliwe. Miałoby, gdyby klienci zaopatrywali się w nie „w ciemno”, a więc np. kupowali rozwiązanie MRP II bez uważnego przyglądania się jego możliwościom, a polegając jedynie na tym, że spełnia wymogi APICS. Oczywiście, nikt nie posuwa się tak daleko. W przypadku wspomnianej wtyczki, jeśli tylko widzimy, że kształtem odpowiada ona standardowi francuskiemu, niemieckiemu, czy amerykańskiemu, nie musimy już pracowicie mierzyć rozstawu bolców, by upewnić się, że będzie ją można wetknąć do domowego gniazdka. Ale czy coś podobnego gwarantuje ów „standard” APICS? Raczej nie. Prędzej można by potraktować go jako zbiór wytycznych dla projektantów oprogramowania, po części bazujący na konkretnych doświadczeniach, a po części na tzw. myśleniu życzeniowym. Standaryzacja w informatyce ma sens – podobnie jak w elektrotechnice – tam, gdzie współpracować muszą ze sobą komponenty pochodzące od różnych dostawców. Klasycznym przykładem może tu być więc wymiana danych pomiędzy rozmaitymi elementami oprogramowania, ale nie jego biznesowe funkcjonalności!

Konstatując zatem, iż MRP II nie jest w istocie standardem, lecz manifestem, odnosi się jednocześnie wrażenie, że został on stworzony z myślą o przedsiębiorstwie stricte produkcyjnym, a więc wytwarzającym konkretne dobra materialne. Być może, tak właśnie było, choć paradoksalnie kontekst okazuje się znacznie rozleglejszy. W istocie bowiem produkcję można rozumieć znacznie szerzej, jako „produkcję dystrybucji”, a więc handel, bądź też „produkcję usług”. Jeśli wspiąć się na taki właśnie poziom abstrakcji i przejrzeć zamieszczoną powyżej listę wyobrażając sobie (dużą) hurtownię, wielooddziałowe przedsiębiorstwo świadczące usługi, a nawet bank, widać, że praktycznie każdy z punktów owego wykazu można przyporządkować do jakiegoś obszaru działań. Mimo to jednak czegoś w owym manifeście MRP II wyraźnie brak…

4. … do E.

O ile każde przedsiębiorstwo prowadzi (szeroko pojętą) produkcję i ona właśnie stanowi główne jego zajęcie, to jednak musi wykonywać też pewne działania wspomagające. Dotyczą one generalnie trzech obszarów: finansów, personelu oraz tzw. gospodarki własnej. Ponadto przedsiębiorstwo powinno też poświęcać nieco uwagi sobie samemu – na poziomie strategicznym. Musi zatem analizować swoją sytuację w zmieniającym się otoczeniu gospodarczym, tworzyć wizje oraz plany rozwoju wykraczające poza paradygmat codziennych działań, a w szczególności, nakierowane na modyfikowanie owego paradygmatu. To jakby czwarty, uzupełniający obszar, który informatycy zapewne nazwaliby metaobszarem.

Jeśli chodzi o gospodarkę własną (zarządzanie środkami trwałymi, remontami itp.), to w istocie potrzeby jej powinny zaspokajać w pełni rozwiązania tworzone według koncepcji MRP II, przy założeniu, że w tym konkretnym przypadku przedsiębiorstwo jest po prostu swoim własnym klientem.

Co do finansów i personelu, to, jak wspominaliśmy na samym początku, te dwa obszary zostały najwcześniej objęte informatyzacją. Być może właśnie dlatego, gdy zaczęły już funkcjonować rozwiązania spełniające założenia MRP II – a było to, przypomnijmy, w latach osiemdziesiątych – dostrzeżono potrzebę modernizacji programów finansowo-księgowych i kadrowo-płacowych na wzór systemów wspomagających produkcję. Oczywiście, nikt nie zamierzał zmieniać zasad rachunkowości, ani sposobów naliczania płac, czy innych świadczeń, lecz poza oczywistą chęcią unowocześnienia przestarzałych aplikacji, zaczęto myśleć o maksymalnej integracji owych „obszarów wspomagających” z MRP II.

Pozostały jeszcze kwestie planowania strategicznego, które z natury rzeczy najtrudniej jest zinformatyzować w stylu manifestu APICS, bowiem działania z nimi związane nakierowane są na modyfikację standardów, tych, które właśnie wcześniej podlegały informatyzacji. Potrzebne tu są zatem narzędzia „miękkie” – o nich będzie jeszcze mowa – oraz, co najważniejsze, dobry dostęp do informacji o charakterze syntetycznym. Przykładowo, zarząd przedsiębiorstwa nie będzie się zajmował bezpośrednio poszczególnymi reklamacjami klientów, ale powinna zainteresować go odpowiednia statystyka, tudzież to, jak zmienia się ona w czasie. Dalej, jeśli dane są niepokojące, zarząd ów powinien podjąć właściwe działania nakierowane na podniesienie jakości, które to działania mogą z kolei skutkować wprowadzeniem modyfikacji do przyjętego uprzednio modelu funkcjonowania, wspieranego przez system MRP II. Jak łatwo zgadnąć, może się też zdarzyć, że wspomniane modyfikacje wymagać będą przebudowy samego systemu informatycznego, a nawet jego wymiany. Ponieważ systemy na ogół nie wspomagają szukania swoich następców, zaś automatyzacja powtarzających się czynności sama w sobie nie prowadzi do reorganizacji procesów, które się automatyzuje, MRP II nie zda się tu na wiele.

Wymienione wyżej trzy (lub cztery) obszary zostały dostrzeżone przez Gartner Group, która w 1990 roku po raz pierwszy użyła określenia Enterprise Resource Planning (ERP)by opisać, naturalne skądinąd, rozszerzenie systemu MRP II. Litera Ezaczęła od tego czasu coraz bardziej wypierać literę Mz materiałów reklamowych producentów oprogramowania, chociaż proces ten trwał długo – można zaryzykować twierdzenie, że jakieś dziesięć lat. Oczywiście, materiały reklamowe, nawet najlepsze, nie przekładają się od razu na gospodarczą rzeczywistość. Byłoby stanowczą przesadą powiedzieć, że np. jeśli dziś jakieś przedsiębiorstwo wdraża „zintegrowany system zarządzania”, to jest to system ERP w rozumieniu Gartnera. Nie tak rzadko spotyka się sytuacje, kiedy to owa integracja odnosi się praktycznie wyłącznie do obszaru MRP II, podczas gdy księgowość i kadry zostają „po staremu”. Zresztą, jak już wspomniano, informatyzacja przedsiębiorstw odbywa się według pewnego utartego schematu: najpierw pojawiają się techniczne możliwości, potem prekursorzy, którzy próbują je wykorzystać, następnie powstaje mniej lub bardziej sformalizowana „teoria” (patrz Gartner), wreszcie kreuje się pewna moda i za nią podąża większość przedsiębiorstw, zaś na samym końcu dołączają maruderzy, których zarządy i tak nadal tkwić będą w przekonaniu, że „te wszystkie komputery, to niewiele dają”.

Nota bene, naszkicowany proces można próbować poddać sekcji wzdłuż kilku wymiarów. Jednym z nich jest wielkość przedsiębiorstw. Bezsprzecznie do pionierów należały ongiś firmy duże, zarówno z uwagi na skalę swoich problemów, jak i na znaczne koszty komputeryzacji. Gdy jednak maszyny cyfrowe zaczęły schodzić pod strzechy, ów „próg wejścia” znacznie się obniżył i – jak się wydaje – palmę pierwszeństwa przejęły podmioty mniejsze, które z natury rzeczy są bardziej sterowne, innowacyjne, a przy tym znacznie mniej inercyjne w swoich zachowaniach od globalnych koncernów.

Interesująca byłaby też sekcja w wymiarze geograficznym. Tu akurat można dostrzec pewne krzepiące zmiany. Ongiś bez wątpienia światło przychodziło z Zachodu, zaś kraje takie jak Polska, były wyraźnie zapóźnione, zresztą nie tylko pod względem komputeryzacji. W połowie lat dziewięćdziesiątych autorowi zdarzyło się współpracować z pewną firmą, która postanowiła wprowadzić na rynek polski jeden z zagranicznych systemów klasy ERP i oferować go średniej wielkości przedsiębiorstwom. Jak się jednak okazało, było na to jeszcze za wcześnie… Wydaje się, iż we wspomnianym sektorze zaczęto u nas na poważnie interesować się takimi rozwiązaniami dopiero z początkiem obecnego stulecia. Oczywiście, wraz z rozwojem gospodarczym nasz dystans w stosunku do krajów rozwiniętych nieco zmalał, choć akurat wyrównanie poziomów wymaga zdaniem ekonomistów jeszcze wielu dziesięcioleci i to przy założeniu w miarę stabilnej sytuacji międzynarodowej. Wystąpił jednak drugi, trochę niespodziewany efekt. Otóż, informatyzacja przedsiębiorstw ma zawsze charakter skokowy, przy czym skokiem jest tu wymiana starego oprogramowania na oprogramowanie nowszej generacji. Paradoksalnie więc, kraje wyżej rozwinięte, których firmy wcześniej dorobiły się rozwiązań zintegrowanych, mogą w pewnym momencie pozostać (i rzeczywiście pozostają) w tyle za nowicjuszami, którym dane było przeskoczyć pewien etap rozwoju. Dziś wcale nie należą do rzadkości zagraniczne firmy, które swoje funkcjonowanie opierają na oprogramowaniu pracującym w środowisku UNIX, obsługiwanym za pośrednictwem terminali znakowych! W jakimś sensie trochę się nam udało, jednak należy pamiętać, że to, co funkcjonuje u nich zostanie kiedyś wymienione, a to czego my używamy, też się kiedyś zestarzeje. Niestety, wtedy oni wysuną się na prowadzenie…

Warto uczynić na koniec jeszcze jedną obserwację: o ile MRP II ewidentnie nie pokrywał całego obszaru funkcjonowania przedsiębiorstwa, o tyle ERP, który to właśnie postawił sobie za cel, traktuje firmę jako pewien układ izolowany od otocznia gospodarczego. No, oczywiście nie całkiem izolowany: jest w nim wejście w postaci zakupów i wyjście, czyli sprzedaż. Jedno i drugie przypomina dobrze strzeżoną, stosunkowo wąską bramę, podczas gdy wszystko, co najważniejsze, dzieje się w środku i tego właśnie dotyczy informatyzacja. Czy taki obraz odpowiada jednak wyzwaniom nowoczesnej gospodarki?

5. Klient zostaje zauważony

Za czasów słusznie minionych w polskim handlu funkcjonowało hasło Klient nasz pan, które z rzeczywistością miało mniej więcej tyle samo wspólnego, co ówczesny polski handel z handlem bezprzymiotnikowym. Wieszano je jednak w sklepach realizując takie, czy inne wytyczne władzy centralnej, której marzyły się pełne półki, uśmiechnięci sprzedawcy i szczęśliwi klienci, a wszystko to w efekcie zaimplementowania ustroju zwanego realnym socjalizmem. Z biegiem lat rodzimi handlowcy coraz bardziej zapominali, jak to było przed wojną, gdy w sklepie padały słowa „Czym mogę służyć Szanownemu Panu?”, zaś szczęśliwcy, którym udało się zdobyć paszport i zobaczyć, jak wygląda świat, opowiadali potem zdumionym rodakom, że „tam, jak się wejdzie do sklepu, to mówią dzień dobry”. Implementacja socjalizmu zakończyła się ostatecznie niepowodzeniem, nie tylko w Polsce, ale i w całym naszym regionie, w związku z czym znów doświadczamy owego strasznego kapitalistycznego wyzysku, wskutek którego na usta prześladowanych sprzedawców powrócił uśmiech i słowa „Dzień dobry”. Nota bene, trzeba było na to aż dziesięciu lat, bo aż do końca ubiegłego wieku zazwyczaj na powitanie padało „Słucham”.

Paradoksalnie, również w krajach, gdzie klient zawsze był dobrze traktowany, w kontekście informatyzacji dostrzeżono go stosunkowo późno. Istniał, co prawda, już w systemach ERP, jednak nie jako podmiot, lecz przedmiot – zbiór danych potrzebnych do wystawienia faktury.

Właściwie nie wiadomo, kto i kiedy po raz pierwszy użył określenia Customer Relationship Management(CRM) – przynajmniej autorowi nie udało się tego z całą pewnością ustalić – a Internet jest pełen dyskusji na ten temat. Wydaje się jednak, że miało to miejsce około połowy lat dziewięćdziesiątych, zaś domniemanym autorem owego terminu jest Thomas Siebel. Choć niewątpliwie to jego firma stała się wówczas liderem rozwiązań tego typu, coś jednak „wisiało już w powietrzu”. Mówiło się bowiem wówczas o systemach Customer Supportlub Customer Care, które z założenia miały być czymś więcej niż tzw. Sales Force Automation(SFA), choć to z niej się poniekąd wywodzą. Subtelna różnica polega jednak na tym, że SFA traktuje klienta przedmiotowo, w duchu manifestu MRP II, podczas gdy CRM dostrzega jego podmiotowość, przenosząc dobre praktyki tradycyjnego handlu w sferę informatyki stosowanej.

Systemom CRM poświęcono już wiele miejsca w literaturze, a przed kilku laty stały się też one przedmiotem naszych rozważań (zobacz [TOWY05]). Zwróciliśmy wtedy uwagę, że pojęcie to jest bardzo niejednoznaczne i nawet przez fachowców używane w różnych kontekstach. Z jakichś powodów nie doczekało się takiej „standaryzacji” jak MRP II, czy ERP. Dlaczego? Może sama materia jest znacznie bardziej delikatna. W końcu, jeśli mamy dbać o relacje z klientem, to powinniśmy wykazać się elastycznością w myśl wspomnianej zasady Klient nasz pan, a nie wdrażać jakieś sztywne procedury przymuszające go do zachowywania się zgodnie z naszym widzimisię. Osobliwie, nie dostrzegają tego jednak wielkie korporacje, które pod nazwą CRM wdrażają systemy–potworki składające się niemal wyłącznie zcall center, bardzo skutecznie irytujące dzwoniących. Nic dziwnego, że – jak od czasu do czasu informuje Gartner – projekty tego typu kończą się w dużej mierze niepowodzeniem, to znaczy mimo wydanych milionów nie skutkują wzrostem dochodów.

W rzeczywistości koncepcja CRM jest bardzo prosta. Otóż, jeśli mamy kilku lub kilkunastu klientów, znamy ich wszystkich doskonale, rozumiemy specyfikę ich potrzeb, potrafimy im dogodzić. To trochę tak jak ze stałym gościem restauracji – wystarczy, że powie kelnerowi „Proszę, to, co zwykle”, a dostanie swoje ulubione penne al gorgonzola, zrobione jak należy, al dente, z lampką czerwonego Montepulciano. Informatyka, jak niemal zawsze, ma tylko rozwiązać problem skali – z rosnącą liczbą klientów nie jesteśmy już w stanie spamiętać ich preferencji, treści prowadzonych rozmów, uzgodnionych terminów itp. Chodzi więc, krótko mówiąc, o to, by robił to za nas system, zbierając dane, informując, przypominając, a więc po prostu, pomagając dobrze obsługiwać klienta. Z perspektywy tego ostatniego system powinien z kolei tworzyć pewną iluzję, uzmysławiając mu, że jest najważniejszy, jedyny, wyjątkowy i że cała firma zajmuje się tylko nim. Tyle przynajmniej sugeruje nazwa zarządzanie relacjami z klientem, dobra praktyka kupiecka oraz elementarny zdrowy rozsądek. Cała reszta, z infoliniami i „przykro nam, takie mamy procedury” na czele – to wypaczenia. Wypaczeniem należałoby nazwać również obsesyjne zbieranie informacji o preferencjach konsumentów, mające na celu oferowanie im kolejnych produktów podług ich (mniej lub bardziej domniemanych) upodobań. Jak słusznie zauważył jakiś czas temu jeden ze stałych felietonistów pisma Computerworld(Jakub Chabik? – cytujemy z pamięci), całe szczęście, że projekty CRM się nie udają, bo w przeciwnym razie bylibyśmy bombardowani niezliczoną liczbą ofert od każdego ze sklepów, w którym coś kiedyś kupiliśmy. Poniekąd i tak jesteśmy, więc może to i owo się „udało”? Niestety, w dobre praktyki handlowe – a te właśnie miały wspierać systemy CRM – w żadnej mierze nie jest wpisana nachalność.

Wróćmy jednak do historii. Wydaje się, że koncepcja CRM (tak czy inaczej rozumianego) zaczęła „materializować się” do postaci oprogramowania około połowy lat dziewięćdziesiątych ubiegłego stulecia – i to nie tylko na Zachodzie! Autor miał wówczas okazję kierować dwoma interesującymi projektami informatycznymi, z których jeden realizowany był dla pewnego operatora telekomunikacyjnego, drugi zaś dla niemieckiej firmy handlowej średniej wielkości, która właśnie otworzyła w Polsce swoją filię i kilkanaście biur regionalnych. W pierwszym przypadku rozwiązanie nazywano Customer Care, choć, prawdę powiedziawszy, bardziej zasługiwało ono wciąż jeszcze na miano Sales Force Automation. W drugim przypadku można już mówić o elementach prawdziwego CRM – w dobrym tego słowa znaczeniu. Rzecz charakterystyczna, oprogramowanie określane było jako System Obsługi Przedsprzedażnej.

Z końcem lat dziewięćdziesiątych do rozwiązań CRM zaczęło przymierzać się szereg dużych korporacji, jednakże ich plany w tym zakresie zostały w znacznej mierze zahamowane przez kryzys. Jak pamiętamy, na początku 2001 roku pękła tzw. bańka internetowa, a zamach z 11 września stał się gwoździem do trumny światowej gospodarki. Można powiedzieć, że owa naiwna wiara w istnienie e-ekonomiipodbiła też przy okazji notowania CRM’u. Kiedy jednak okazało się, że ludzkość nie zamierza wcale wyemigrować do Internetu, lecz nadal będzie jeść, poruszać się samochodami, nosić buty itd., inwestorzy zareagowali panicznie (a może rozsądnie?), zaś zarządy spółek zaczęły alergicznie reagować na skrót IT. Zablokowano fundusze, obcięto budżety, pozamrażano projekty…

W tym samym czasie wdrożenia ERP posuwały się, choć może nieco wolniej, lecz jednak do przodu. Fakt, iż dotyczyły one tzw. „twardej materii”, nie zaś ulotnych relacji z klientem, sprawił, że w tym obszarze decydenci nie utracili zaufania do informatyków, dokładnie rozumiejąc swoje potrzeby i korzyści płynące z IT.

CRM też doczekał się renesansu. Najpierw zaczęły budzić się firmy duże i wracać do odłożonych na półkę przedsięwzięć, w znacznej większości stanowiących – jak już o tym wspominaliśmy – karykaturalne ujęcie koncepcji zarządzania relacjami z klientem. Prawdziwy przełom nastąpił jednak nieco później…

Gdy sięgnąć do archiwalnych numerów pism branżowych, można dostrzec, że już od połowy pierwszej dekady XXI wieku (może nawet wcześniej) prognozowano, iż „kolejny rok będzie w Polsce rokiem CRM-u”. Tak się jednak przez te lata wcale nie działo. Jeśli z kolei przyjrzeć się analizom ekonomicznym, wynika z nich, że od dłuższego czasu rośnie ilość gotówki zgromadzonej na rachunkach przedsiębiorstw, co wciąż każe spodziewać się, że „ruszą inwestycje”. Zjawisko takie również nie miało dotychczas miejsca – przynajmniej w spektakularnej formie. Inwestorzy wykazują ostrożność, kierując się niepewnością odnośnie rozwoju (mało stabilnej) sytuacji makroekonomicznej oraz brakiem zaufania do rodzimych rozwiązań politycznych i prawnych. Coś się jednak ostatnio przełamało jeśli chodzi o inwestowanie w CRM. Mniej więcej od roku liczba zapytań ofertowych dotyczących tego typu rozwiązań, choć wciąż niezbyt wielka, rośnie jednak lawinowo. W ciągu ostatnich dziesięciu miesięcy autor zaobserwował ich tyle, co wciągu poprzednich dziesięciu lat. Co zatem spowodowało taki skok? Wydaje się że czynników było kilka:

Nauczono się działać w warunkach kryzysu. Zrozumiano, iż kryzys jest nieodłącznym elementem kapitalizmu, występuje co jakiś czas i wcale nie stanowi katastrofy – przeciwnie, jeśli się umie, można na nim zarobić.
Zauważono, że w warunkach słabej koniunktury nie opłaca się inwestować w nowe środki produkcji, lecz raczej należy skoncentrować się na sprzedaży, której nieodłącznym elementem jest dobra obsługa klienta, wymagająca wsparcia odpowiednimi narzędziami informatycznymi.
Wskutek wzrostu kosztów pracy spadła konkurencyjność eksportu naszych firm. Zaczęto więc szukać sposobów redukcji wydatków stałych i zwiększenia produktywności w obszarach „miękkich”. Obszary „twarde”, a więc mechanizacja i automatyzacja produkcji zostały zagospodarowane już wcześniej.
Zaowocowała wieloletnia praca u podstaw, a więc krzewienie świadomości potrzeb wdrażania rozwiązań CRM przez ich producentów, analityków i konsultantów biznesowych.

Wygląda więc na to, że zjawiska kryzysowe, podobne w jakimś sensie do tych z 2001 roku, które zatrzymały rozwój informatyki, teraz zaczęły informatyce, a zwłaszcza systemom CRM, sprzyjać. To pocieszające w obecnej sytuacji, zwłaszcza jeśli faktycznie na rachunkach przedsiębiorstw zgromadzone są zapasy gotówki. Oczywiście, trzeba mieć świadomość, że największą skłonność do inwestowania w warunkach spowolnienia gospodarczego wykazywać będą firmy stosunkowo niewielkie, bo to one, a nie korporacje potrafią szybko przeorientować się, gdy nadchodzą trudne czasy. Nie należy więc liczyć na wielkie projekty, lecz raczej na cały szereg projektów małych, o specyficznym charakterze. Zainteresowanym możemy polecić pouczającą lekturę [MARA06].

6. Sklep przyfabryczny

Owo rosnące zainteresowanie rozwiązaniami CRM, najpierw w sferze życzeniowego myślenia i prognoz informatyków, a potem już prawdziwej rzeczywistości, nie mogło oczywiście ujść uwadze dużych producentów systemów ERP. Zaczęli więc oni tworzyć „moduły CRM”, jako uzupełnienia swoich rozwiązań. Uczynił to leader rynku, niemiecki SAP, uczynili też inni, w tym polscy wiodący dostawcy, jak BPSC, Comarch, SIMPLE, czy UNIT4TETA. Można sobie wyobrazić (choć nie posiadamy na to żadnych dowodów), że owe moduły CRM były traktowane trochę po macoszemu i z pewnym lekceważeniem dla samego przedmiotu prac. Cóż to bowiem jest program do zarządzania relacjami z klientem, czymś ulotnym i źle zdefiniowanym, w porównaniu z „twardą” logistyką, magazynówką, księgowością, czy planowaniem produkcji? Zapewne nieraz więc padło: „Weźcie chłopcy i coś tam napiszcie, żeby było…”. Analitycy przeglądali więc dostępne, typowe wzorce, projektanci tworzyli: „Wiadomo, klient, karta klienta, kontakty sprzedawców, zadania, trochę analiz..”, a programiści pisali. I tak, jedna za drugą powstawały przybudówki – rozwiązania skądinąd praktyczne, użyteczne, niekiedy nawet całkiem dobre i przyjemne w użytkowaniu, jednak wyraźnie odprzęgnięte od całej reszty systemu ERP. Oczywiście, nie chodzi tu o brak wymiany danych, bo tę akurat udaje się zrealizować bez większego problemu, lecz raczej o samą strukturę rozwiązania, przypominającą duży zakład przemysłowy z niewielkim przyfabrycznym sklepem, wciśniętym w mur, gdzieś nieopodal głównej bramy. Sklep, jak to sklep, rządzi się własnymi prawami, tyle że towaru nie trzeba do niego dowozić z daleka.

7. Klient wchodzi do środka

Pomysł włączenia klienta w (szeroko rozumiany) proces produkcyjny należałoby zapewne nazwać fanaberią, a nawet nonsensem, jako że osoby postronne nie powinny plątać się po terenie zakładu. W zależności od specyfiki przedsiębiorstwa może to oczywiście stanowić pewną wartość, że w jednym miejscu da się podejrzeć zarówno notatki z rozmów z klientem, jak i dokumenty związane z zamówioną przez niego produkcją, lecz istota prawdziwej integracji ERP i CRM jest zupełnie inna.

CRM, jeśli się dobrze zastanowić, to w rzeczywistości system organizacji pracy biurowej, zorientowany na obsługę klienta. „Miękki” charakter działań wobec tego ostatniego determinuje elastyczność owego systemu. Nie można w nim np. zaszyć żadnych sztywnych procedur, bo zawsze, prędzej, czy później okaże się, że do tego konkretnego klienta będzie trzeba podejść trochę niestandardowo. Jeśli już mamy tworzyć jakieś reguły postępowania, musimy być w stanie robić to na bieżąco, modyfikować je w najprzedziwniejszy sposób i zawsze, ale to zawsze, dopuszczać odstępstwa od reguł. Jak wspominaliśmy, nie wiedzą o tym jeszcze w różnych dużych korporacjach (np. u operatorów telekomunikacyjnych), ale w ostatecznym rozrachunku, to tylko ich strata – liczona w utraconych klientach.

Skoro więc mamy taką elastyczność, to system przeznaczony dla klientów możemy równie dobrze zastosować do obsługi własnych pracowników, partnerów, podwykonawców, dostawców… Oczywiście tak długo, jak długo nie zahaczymy np. o magazyn, solidnie umocowany w sztywnych strukturach ERP. No właśnie, aż by się prosiło, by i ten magazyn mógł wpleść się w nasze procesy związane z ogólną organizacją pracy. I tu właśnie dotykamy sedna problemu. Systemu integrującego klasyczne ERP z funkcjonalnościami CRM nie da się stworzyć konstruując jakąś przybudówkę, lecz trzeba po prostu napisać go od nowa! Dlaczego?

8. Statyka czy dynamika?

Jednym z ulubionych słów każdego informatyka jest (a przynajmniej powinno być) słowoproces. Z matematycznego punktu widzenia proces stanowi odwzorowanie zbioru liczb rzeczywistych (reprezentujących czas) w przestrzeń stanów układu, który procesowi temu podlega. Proces stanowi więc sekwencję zmian, które zarówno w systemach komputerowych (z oczywistych przyczyn), jak i w systemie, jakim jest przedsiębiorstwo, mają charakter dyskretny. Tak więc, liczby rzeczywiste należy zamienić na naturalne i proces, który może nas zainteresować, staje się po prostu ciągiem stanów.

Komputerowe wspomaganie zarządzania procesem przebiegającym w realnym świecie wymaga de facto stworzenia jego wirtualnego modelu – gdy to uczynimy, równolegle biec będą obok siebie dwa procesy – jeden prawdziwy, a drugi symulowany przez komputer. Sterowanie wymaga permanentnej synchronizacji obydwu, a więc na każdym etapie powinno się porównywać stan układu rzeczywistego i stan układu symulowanego przez maszynę oraz dokonywać korekt, w zależności od sytuacji, bądź to w jednym, bądź w drugim układzie. Dla przykładu, jeśli mamy do czynienia z procesem, którego kilka elementów wiąże się z wydaniem towaru z magazynu, to po takim wydaniu ilość sztuk dostępnych w magazynie musi się zmniejszyć o to, co zostało wydane. Może się jednak zdarzyć, że coś przy okazji ulegnie zniszczeniu – wtedy stan wirtualny (w komputerze) będzie wymagał korekty. Może też jednak być inaczej. Otóż załóżmy, że towar powinien zostać wydany w ciągu godziny od powstania odpowiedniej dyspozycji, a tu nic się nie dzieje, bo magazynier się zagapił i, jak dobrze pójdzie, zorientuje się dopiero po trzech godzinach, gdy dojdzie już do małej afery. W takiej sytuacji proces wirtualny powinien skorygować (potencjalną) rzeczywistość przypominając magazynierowi o jego obowiązkach.

Patrzeć na przedsiębiorstwo w sposób procesowy zaczęto w latach osiemdziesiątych ubiegłego wieku (por. np. [RUBR95]), a może nawet jeszcze wcześniej. Powstał w związku z tym nawet kolejny trzyliterowy skrót – BPM (Business Process Management), odnoszący się do pewnej klasy systemów informatycznych, określanych też mianem rozwiązań wspierających pracę grupową lub obieg zdarzeń (i dokumentów), bądź rozwiązań Workflow. Jak pokazuje praktyka, BPM nie ma jednak racji bytu w oderwaniu od ERP i CRM. Bodaj najlepiej widać to na przykładzie informatyzacji administracji publicznej, gdzie – mogłoby się wydawać, bardzo słusznie – postawiono jakiś czas temu na elektroniczny obieg dokumentów i zaczęto wdrażać odpowiednie oprogramowanie. Mniej więcej przed dwoma laty autor miał okazję rozmawiać o tym ze starostą pewnego powiatu, który rękami i nogami bronił się przed uruchomieniem zakupionego już (w ramach projektu unijnego) systemu w swoim urzędzie. Padł wtedy następujący argument: „I po co mi to, jeżeli każde pismo trzeba będzie rejestrować dwa razy – raz w systemie obiegu dokumentów, a drugi raz w aplikacjach dziedzinowych, do podatków, wodociągów, geodezji itp.? Bez integracji to nie ma sensu.”. Czy można odmówić mu racji? Faktycznie, bez integracji to nie ma sensu. A nawet więcej, nie o integrację z jakimś zewnętrznym BPM tu chodzi, a raczej o to, by w pełni zintegrowany system działał według koncepcji BPM!

Czy tak właśnie jest w przypadku klasycznych rozwiązań ERP? Co do zasady, obsługują one procesy, bo po prostu nie mogą działać inaczej, tyle że owa „procesowość” jest w nich na ogół bardzo głęboko ukryta. Można powiedzieć, że o ile nowoczesne systemy CRM bazują (a na pewno powinny bazować) na koncepcji BPM, o tyle typowe ERP prezentują użytkownikom raczej tylko kolejne stany układu, jakim jest przedsiębiorstwo. Procesy mamy więc i tu i tu, jednak w jednym przypadku są one doskonale widoczne, a w drugim – schowane tak, że aż trudno się ich dopatrzeć. Co więcej, procesy ERP mają dość sztywny charakter – można je parametryzować i konfigurować, ale raczej nie da się ich sprzęgać z całkowicie elastycznymi procesami CRM. Jeśli CRM stanowi przybudówkę do ERP, bardzo trudno będzie „doszyć” do twardego procesu wydania z magazynu elementy miękkie typu „Jeśli dostawa musi się opóźnić, zadzwoń do klienta i w ramach rekompensaty zaproponuj mu coś ekstra w specjalnej promocji.”

Dlatego właśnie wydaje się, że stworzenie zintegrowanego rozwiązania ERP–CRM wymaga napisania go od początku, tak, by pozycja klienta została odpowiednio wyeksponowana. To właśnie klient musi znaleźć się w centrum systemu, bo to on, nie produkt, prezes, czy właściciel, jest najważniejszy w całej firmie. Zmieniamy zatem kolejność na CRM–ERP!

Przedstawiona powyżej koncepcja zaczyna się już materializować na polskim rynku. Wysiłek stworzenia zgodnego z nią rozwiązania podjął – jak się wydaje – Comarch, budując swoje Altum. Podobnie prezentuje się również Berberisfirmy BMS Creative, który zresztą, gdy wszedł na rynek przez dziesięciu laty, był niemal czystym CRM. W te ślady idą też inne firmy, odpowiadając skądinąd na oczekiwania klientów. Całkiem niedawno autorowi zdarzyło się usłyszeć następujące zdanie z ust osoby odpowiedzialnej za wybór oprogramowania dla dość pokaźnej spółki: „Potrzebuję dobrego systemu CRM z mocną gospodarką magazynową i sprzedażą. Oglądnąłem już kilka takich rozwiązań…”. Kiedyś – nie do pomyślenia!

9. Niech się stanie ład i porządek!

W procesowo zorientowanych systemach informatycznych da się na ogół implementować pewne wzorce działania, zwane procedurami, które z kolei mogą bądź to podpowiadać pracownikom określone zachowania, bądź też je na nich wymuszać. Sztywne i bezduszne procedury obsługi klienta były już przedmiotem naszej krytyki (również w [TOWY05]), jednak procedury same w sobie nie wydają się czymś a priori złym – przeciwnie, kojarzą się z ładem i porządkiem w organizacji.

Taki ład teoretycznie powinno zapewnić wdrożenie ISO 9001 i to najlepiej jeszcze przed uruchomieniem nowoczesnego ERP, który miałby oczywiście wesprzeć ISO od strony informatycznej. Nie chcemy wchodzić głębiej w zagadnienia związane z normami jakości, gdyż mogłyby być one tematem nie mniej rozległych niż niniejsze rozważań. Ograniczymy się tylko do stwierdzenia, że nakazują one same sensowne działania, ze zwróceniem szczególnej uwagi na klienta i zastosowaniem podejścia procesowego, na czele. Mówią też, że w firmie powinien panować porządek, czemu również można tylko przyklasnąć. Jak to ktoś mądry zauważył, bałaganu komputeryzować nie należy, bo po skomputeryzowaniu nie staje się on porządkiem, lecz jedynie skomputeryzowanym bałaganem, a więc, najpierw ISO, potem ERP. Czy jednak na pewno?

Otóż, rzeczywisty problem z ISO polega na tym, że zajmujący się nim konsultanci w przeważającej mierze nie dostrzegli jeszcze istnienia komputerów i wciąż myślą w kategoriach papierów, szaf i segregatorów. I tak, np. wymóg numerowania wszystkich możliwych dokumentów jest śmieszny w dobie systemów bazodanowych. Każda tabela powinna posiadać oczywiście unikalny klucz główny, ale ten akurat potrzebny jest komputerom, a nie ludziom. Normalny człowiek, poproszony przez jakąś firmę o podanie swojego numeru klienta, odpowiada: „Mam imię i nazwisko, znam je od dziecka, pamiętam gdzie mieszkam, ale jakiś numer? Niech przetwarzają go wasze maszyny, nie ja! Jeśli imię, nazwisko i adres wam nie wystarczają, kupcie sobie porządne oprogramowanie!” Smutna prawda polega na tym, że ogromna ilość firm wdraża ISO nie po to, żeby mieć porządek, ale po to, żeby mieć certyfikat. Robi to przy tym źle i bądź to, utrudnia sobie życie podnosząc tylko koszty i obniżając konkurencyjność, bądź też nie przestrzega wprowadzonych zasad postępowania.

Analizując różne rzeczywiste przypadki nabiera się przekonania, że jedynym sensownym podejściem jest równoległe wdrożenie ISO i ERP. W przeciwnym razie dochodzi do kompletnych patologii, jak np. ta, z którą autor miał okazję zetknąć się osobiście, gdy w pewnej firmie posiadającej już certyfikat jakości postanowiono wdrożyć system CRM. Odwzorowano w nim spisane wcześniej procedury, po czym okazało się, że nikt nie pracuje tak, jak one nakazują! Co więcej, nikt nie chce i nie może w ten sposób pracować. Procedury w systemie przemodelowano, a książka ISO pozostała sztuką dla sztuki. Nowoczesny, procesowo zorganizowany i zorientowany na klienta system ERP nie zaprowadzi więc wprawdzie sam ładu w przedsiębiorstwie, ale pomożego zaprowadzić i utrzymać.

Francuzi, którzy obsesyjnie niemal bronią swojego języka przed obcymi wpływami, wynaleźli kiedyś wspaniały termin informatyka(l’informatique), jako konkurencję dla anglosaskiego computer science. Na sam komputer mówią oni z kolei l’ordinateur, które to słowo nie ma nic wspólnego z liczeniem, ale wywodzi się od ordre, znaczącego rozkazywać, ale też porządkować. Charakterystyczne…

10. Co dalej?

Analizując rozwój koncepcji ERP wyeksponowaliśmy najważniejsze, w naszym odczuciu, zjawisko, a mianowicie powstawanie swoistej syntezy klasycznego ERP, CRM i BPM. Jest ono o tyle istotne, że tworzy nową jakość: oprogramowanie do zarządzania firmą, pomyślane procesowo, z klientem w roli głównej. Można teraz dodawać kolejne elementy, jak SCM (Supply Chain Management), zaawansowane narzędzia BI(Business Intelligence), bardzo ważne moduły MES (Manufacturing Execution Systems), sprzęgające zarządzanie produkcją bezpośrednio ze zautomatyzowanymi liniami technologicznymi, mniej lub bardziej wyrafinowane sklepy internetowe o rozmaitym charakterze itp., jednak nie wydaje się, aby mogły one wywołać jakąś rewolucję, choćby na miarę tej, którą przynosi szeroko dyskutowana synteza. Mieszczą się one po prostu doskonale w nowym paradygmacie ERP, co oznacza, że aby je uwzględnić, nie trzeba będzie przepisywać systemów od początku. Mieści się też w nim jeszcze jeden, przyszłościowy element, o którym wspominamy na samym końcu naszych rozważań, nie umniejszając jednak w żaden sposób jego roli.

Otóż, w dzisiejszych czasach coraz częściej mówi się o gospodarce opartej na wiedzy. W rzeczy samej, gospodarka zawsze była oparta na wiedzy, tyle tylko, że rola tej ostatniej staje się coraz większa i coraz bardziej postrzega się ją jako składnik kapitału (por. np. [KONO07]). Kapitałem zaś trzeba zarządzać, a zarządzanie, jak już doskonale wiemy, należy wspomagać informatyką. Przed czterema laty omawialiśmy już podczas konferencji PLOUG pewne teoretyczne założenia systemów informatycznych służących do zarządzania wiedzą ([TOWY07]), w związku z czym odsyłamy zainteresowanego czytelnika do owego artykułu, a także innej literatury, poświęconej temu zagadnieniu. Nasze obecne rozważania zakończymy natomiast przypuszczeniem, że zarządzanie wiedzą stanie się kiedyś również standardowym elementem systemów ERP. Gdyby miało być inaczej, wiara autora w permanentny rozwój cywilizacyjny zostałaby poddana bardzo ciężkiej próbie.

Bibliografia

[BKM11] Banaszak, Z., Kłos, S., Mleczko, J.: Zintegrowane systemy zarządzania, Polskie Wydawnictwo Ekonomiczne 2011, ISBN 978-83-208-1937-3.

[TOWY05] Wyrozumski, T.: Systemy CRM – czy i jak (nie) wdrażać?, XI Konferencja PLOUG, Kościelisko, październik, 2005, ss. 135–143, ISSN 1641-21-17.

[MARA06] Radziejowska, M.: Jak sprzedać duży system małej firmie?, XII Konferencja PLOUG, Kościelisko, październik, 2006, ss. 189–198, ISSN 1641-21-17.

[RUBR95] Rummler, G. A., Brache, A. P.: Improving Performance: How to Manage the White Space on the Organization Chart, 2nd Ed., Jossey-Bass Inc.Publishers1995, ISBN 978-07-879-0090-8.

[KONO07] Kowalczyk, A., Nogalski B. Zarządzanie wiedzą Koncepcja i narzędzia, Centrum Doradztwa i Informacji Difin sp. z o.o. 2007, ISBN 978-83-725-1694-7.

[TOWY07] Wyrozumski, T.: Jak zbudować system zarządzania wiedzą?, XIII Konferencja PLOUG, Kościelisko, październik, 2005, ss. 140–150, ISSN 1641-21-17.