Cz I Modelowanie systemów ERP... 13

Spis tre ci Wst p... 9 Cz I Modelowanie systemów ERP... 13 Rozdzia 1. Zrozumie ERP... 15 1.1. Uk ad modelowania ERP... 18 1.2. Otoczenie (kontekst) ERP... 20 1.2.1. Analiza PEST a ERP... 21 1.2.2. Zbiór interesariuszy systemu ERP... 22 1.2.3. ERP a regu y gry rynkowej... 24 1.3. Relacje ERP do niektórych zagadnie zarz dzania organizacj... 27 1.3.1. ERP a strategia rozwoju firmy... 27 1.3.2. ERP a system zapewnienia jako ci... 29 1.3.3. ERP a optymalizacja w organizacji... 30 1.3.4. ERP jako monitor a cucha warto ci... 32 1.4. ERP a procesy biznesowe... 34 Rozdzia 2. Model ontologiczny... 37 2.1. ERP jako wydzielony byt w organizacji... 37 2.1.1. Kwestie ontologiczne ERP... 39 2.1.2. Kwestie epistemologiczne ERP... 43 2.1.3. Kwestie aksjologiczne dotycz ce systemów ERP... 49 2.2. Model konceptualny... 54 2.2.1. Model a cucha warto ci... 54 2.2.2. Model stanu organizacji... 56 2.2.3. Model kontrolingu (sprz enia zwrotnego)... 58 Rozdzia 3. Model funkcjonalny ERP... 61 3.1. Model funkcjonalny organizacji dla celów ERP... 63 3.1.1. Uk ad warstw logicznych... 63 3.1.2. Procesy... 65 3.1.3. Zasoby w ERP... 70 3.2. Model funkcjonalny rachunkowo ci... 73 3.2.1. Struktura rachunkowo ci a ERP... 75 3.2.2. Plan kont... 81 3.2.3. Plan dekretów... 82 3.2.4. Obieg dokumentów finansowych... 84

6 Systemy ERP. Modelowanie, projektowanie, wdra anie 3.2.5. Sprawozdania finansowe i deklaracje... 85 3.2.6. ERP a ksi ga przychodów i rozchodów... 86 3.3. Modele funkcjonalne modu ów ERP poziomu operacyjnego... 89 3.3.1. System FK... 90 3.3.2. Handlowo-magazynowy... 100 3.3.3. Us ugowy... 109 3.3.4. Produkcja... 113 3.3.5. Kadry i p ace... 116 3.3.6. Maj tek trwa y... 123 3.3.7. Magazyny... 129 3.3.8. Kasa... 134 3.3.9. CRM model funkcjonalny... 136 3.4. Model funkcjonalny kontrolingu... 137 3.4.1. Model KPI a system ERP... 140 Rozdzia 4. Modele semantyczne ERP... 143 4.1. Modele semantyczne w FK... 145 4.1.1. Model semantyczny Dokument FK... 146 4.1.2. Model semantyczny Rejestr dokumentów (ksi ga g ówna)... 146 4.1.3. Model semantyczny Dziennik... 148 4.1.4. Model semantyczny Raport dokumentowy... 149 4.1.5. Model semantyczny Raport obrotowy... 150 4.1.6. Model semantyczny Deklaracja... 151 4.1.7. Model semantyczny Sprawozdanie finansowe... 151 4.1.8. Model semantyczny Zamkni cie roku, otwarcie BO... 152 4.2. Systemy sprzeda y... 152 4.2.1. Model semantyczny Faktura VAT... 154 4.2.2. Model semantyczny Rejestr sprzeda y... 156 4.2.3. Model semantyczny Raport sprzeda y... 156 4.2.4. Model semantyczny Deklaracja podatkowa... 157 4.3. Zarz dzanie kadry i p ace... 157 4.3.1. Kartoteka pracownika... 158 4.3.2. Rejestry... 164 4.3.3. Listy p ac... 166 4.3.4. Dodatkowe aspekty... 168 4.3.5. Sprawozdania i deklaracje... 168 4.4. Zarz dzanie maj tkiem trwa ym... 169 4.4.1. Model semantyczny dla amortyzacji ST... 169 4.4.2. Dokumenty zwi zane z maj tkiem trwa ym... 170 4.4.3. Rejestry w zarz dzaniu maj tkiem trwa ym... 171 4.4.4. Sprawozdania i raporty w obszarze maj tku trwa ego... 172 4.5. Kontroling i raporty skonsolidowane... 172 4.5.1. Raport zintegrowany dla stacji obs ugi samochodów... 172 4.5.2. Wska niki ekonomiczne wynikaj ce z bilansu i rachunku zysków i strat... 185 4.5.3. Prognozowanie... 187 Cz II Projektowanie systemów ERP... 195 Rozdzia 5. Projekty poziomu ekonomicznego... 197 5.1. Projekt a cucha warto ci... 198 5.1.1. Opis dóbr stanowi cych warto... 199 5.1.2. Projekt strategii sprz onej z ERP... 200 5.1.3. Mapa zada... 203 5.1.4. Mapa procesów... 209

Spis tre ci 7 5.1.5. Projekt obiegu informacji... 210 5.1.6. Zasoby informacyjne... 211 5.1.7. Polityka rachunkowo ci... 213 5.1.8. System zarz dzania... 215 5.2. Bia a ksi ga ERP (ERP white print)... 216 5.2.1. Jak ma funkcjonowa firma?... 216 5.2.2. Jak ma funkcjonowa zarz dzanie?... 217 5.2.3. Jak ma funkcjonowa kontroling?... 217 5.2.4. Jak ma funkcjonowa ERP?... 218 5.2.5. Uwarunkowania ekonomiczne i techniczne funkcjonowania ERP... 218 5.3. Niebieska ksi ga ERP... 219 5.3.1. Dokumentowanie formalne procesów... 219 5.3.2. Algorytmy warstwy biznes procesu... 220 5.3.3. Struktura bazy danych dokumentu... 223 5.3.4. Konsolidacja danych raporty operacyjne... 229 5.4. Studium wykonalno ci dla projektu wdro enia ERP... 230 5.4.1. Struktura studium wykonalno ci... 231 5.4.2. Harmonogram czasowo-zadaniowy wdro enia projektu ERP... 234 5.4.3. Koszty godzinowe tworzenia systemów IT... 237 5.4.4. Analiza wariantów... 237 5.4.5. Rodzaje ryzyka zwi zanego z projektem... 239 Rozdzia 6. Projekty poziomu IT... 241 6.1. Warstwa bazy danych... 242 6.1.1. System ERP a hurtownia danych... 243 6.1.2. Baza danych FK... 245 6.1.3. Baza danych modu u magazynowo-handlowego... 247 6.1.4. Baza danych modu u kadrowo-p acowego... 249 6.1.5. Baza danych modu u rodki trwa e... 250 6.1.6. Baza danych modu u EIS... 250 6.2. Warstwa dost pu do danych... 252 6.2.1. Model architektury danych OLTP... 252 6.2.2. Architektura OLAP... 253 6.2.3. Kostka OLAP... 256 6.2.4. Narz dzia dost pu i analizy danych... 258 6.2.5. Aspekty jako ci danych... 260 6.3. Warstwa biznes... 262 6.3.1. Warstwa biznes w modu ach operacyjnych ERP... 263 6.3.2. Warstwa biznes w module EIS... 264 6.4. Warstwa interfejsów i prezentacji... 264 6.4.1. Modu finansowo-ksi gowy... 267 6.4.2. Modu handlowo-us ugowo-magazynowy... 269 Cz III Wdra anie i serwis systemów ERP... 271 Rozdzia 7. Wdra anie systemu ERP... 273 7.1. Plan koncepcyjny... 277 7.1.1. Opracowanie koncepcji... 278 7.1.2. Planowanie ERP... 279 7.1.3. Zestrajanie organizacji z technologi ERP... 279 7.2. Plan operacyjny... 281 7.2.1. Planowanie operacji... 282 7.2.2. Imperatywy sukcesu... 284

8 Systemy ERP. Modelowanie, projektowanie, wdra anie 7.3. Realizacja... 287 7.3.1. Monitorowanie po o enia ekonomicznego z u yciem ERP... 287 7.3.2. Wskazania wynikaj ce ze sprz enia zwrotnego... 288 Rozdzia 8. Serwisowanie systemów ERP... 289 8.1. Serwis warstwy kulturowej organizacji... 290 8.1.1. Rein yniering procesów w kontek cie danych z ERP... 291 8.1.2. Budowanie zasobu wiedzy... 292 8.1.3. Rozwój kluczowych kompetencji... 293 8.2. Serwis warstwy technologicznej... 294 8.2.1. Pierwsza linia wsparcia... 295 8.2.2. Druga linia wsparcia... 297 8.2.3. Serwis poziomu systemowego... 299 8.3.Doradztwo i ocena systemu ERP... 300 8.3.1. Jak wybra system ERP?... 300 8.3.2. Jak wybra wykonawc wdro enia?... 304 8.3.3. Ile powinien kosztowa system ERP?... 306 Rozdzia 9. Dodatki... 309 9.1. Analiza wielokryterialna... 309 9.2. Procedura kontrolna spójno ci baz danych... 310 9.3. Procedura wdro enia struktury funkcjonalnej ERP... 312 9.3.1. Mapa procesów i jej relacje z modu ami ERP... 312 9.3.2. Mapa zada w relacji do stanowisk... 313 9.3.3. Karta stanowiska ERP... 314 9.3.4. Przetwarzanie informacji na stanowisku ERP... 314 9.4. Procedura przygotowania danych bilansu otwarcia... 315 9.4.1. Modu FK... 315 9.4.2. Modu handlowo-magazynowy... 316 9.4.3. Modu us ugowy... 317 9.4.4. Modu kadrowo-p acowy... 318 9.4.5. Modu rodki trwa e... 319 Literatura... 321 Indeksy i spisy... 325 Spis rysunków... 325 Spis przyk adów... 328 Spis tabel... 330 Spis arkuszy... 330 Skorowidz... 331

Wst p eby zarabia na wdra aniu systemów ERP, trzeba by troch wizjonerem, troch informatykiem i troch szarlatanem ekonomicznym. Ale przede wszystkim trzeba mie wiele szcz cia, aby pracowa z bardzo m drymi ksi gowymi. Dopiero po d u szym czasie rodz si wiedza i do wiadczenie oraz tworzy si warto dodana oferowanych rozwi za. Niniejsza ksi ka powsta a w wyniku prac nad przygotowaniem koncepcji systemu ERP dla jednej z ogólnopolskich firm. Generowana przez ni warto pojawia si w efekcie u ycia wiedzy. Przy okazji wytworzy y si znacz ce zasoby unikatowe. Charakter tej firmy uzasadnia budowanie modelu strategii zasobowej. Przy tym zasadnicz rol maj kluczowe kompetencje oraz kapita intelektualny. Z tego wynika wprost, e wynik finansowy stanowi wa ny, ale nie jedyny aspekt oceny pozytywnej dzia alno ci tej organizacji. Ten fakt by motywem przewodnim postawionej hipotezy, e nie istnieje na rynku odpowiedni system ERP w gotowej postaci. Dodatkowo zbiór procesów i struktura kompetencji okre laj specyficzne sposoby rozrachunków oraz rozlicze merytorycznych z efektów pracy, a tak e wyników projektów. Jak to zwykle bywa w zacnych organizacjach pa stwowych z du nalecia o ci socjalistycznych praktyk w zarz dzaniu, zarówno warto generowana w otoczeniu, jak i opis po o enia ekonomicznego by y nieustalone. Co wi cej, nie s mo liwe do ustalenia bez du ego nak adu pracy i reorganizacji struktury. Ale pojawi a si ambicja oraz wola wdro enia jakiego zacnego systemu ERP, najlepiej z górnej pó ki, bo w ko cu nie za swoje pieni dze. Zarz d zauwa y, e kontroling wymyka si z r k, a uzyskanie informacji o kosztach wybranego przedsi wzi cia (projektu biznesowego) wymaga powa nego zaanga owania zasobów ludzkich. W dodatku czas przetworzenia danych jest nieprzyzwoicie d ugi, pomimo istnienia standardowych programów ksi gowych. Uda o si wówczas namówi zarz d na wykonanie rzetelnej pracy, której wynikiem s bia a ksi ga 1 (white paper) i niebieska ksi ga 2 (blue print) zarz dzania. Okaza o si wtedy, ile niepewno ci i niejednoznaczno ci 1 Stelzner Michael A., Learn all about white papers, WhitePaperSource Publishing, 2008; http://www.writingwhitepapers.com/resources.html. 2 Blue print stanowi metafor planu architektonicznego, która jest u ywana w ró nych kontekstach projektów oraz schematów dzia ania. W szczególno ci dotyczy szczegó owej architektury obiegu dokumentów, u ycia zasobów etc.

10 Systemy ERP. Modelowanie, projektowanie, wdra anie usuni to z istniej cych obiegów dokumentów, map procesów itd. Powsta czysty obraz modelu funkcjonalnego organizacji, który satysfakcjonowa ca o zarz du. Uproszczono dokumentowanie procesów. I wówczas odkryto, e na rynku naprawd nie ma gotowego systemu ERP, który nadawa by si do bezpo redniego wdro enia. Przyj to koncepcj modyfikacji ju eksploatowanych modu ów zintegrowanego systemu IT wspomagaj cego zarz dzanie. Zaprojektowano napisanie nak adek importu i wymiany danych mi dzy modu ami oraz przygotowano generator raportów klasy EIS 3. Proces ten doprowadzi do zaistnienia bardzo skutecznego narz dzia, o u yteczno ci dok adnie dopasowanej do modelu biznesowego. Rozwi zanie to jest odporne na zmiany technologiczne i mody w bran y IT. Mo na zada pytanie, sk d czerpa em wzorce i najlepsze praktyki odno nie do wdra ania systemów ERP. Bynajmniej nie z wiod cych na rynku standardów systemów klasy ERP firm Oracle czy te SAP. W 99% problemów polskich firm mo na te systemy pomin, stosuj c znacznie bardziej uproszczone, ale dobrze zintegrowane, takie jak: CDN, Symfonia, Microsoft Dynamics. Nale y tylko uzupe ni je o odpowiednie modu y generuj ce syntetyczne informacje i raporty. Moja wiedza pochodzi od najlepiej zorganizowanych systemów ERP, które s wdro one globalnie w wybranych koncesjach marek samochodowych. W ród nich wymieni nale y: GBMS w firmie Mercedes-Benz, Alison w firmie Renault, BMI w firmie Ford oraz system Refeco w firmie PSA-Citroën. S to sprawozdania kontrolingowe umo liwiaj ce prze wietlenie wszystkich aspektów funkcjonalno ci i po o enia ekonomicznego danej koncesji. Wyniki z poszczególnych koncesji s konsolidowane centralnie, a nast pnie porównywane w sieci globalnej. Czy mo na sobie yczy lepszego pomiaru i definicji sprz enia zwrotnego? Stuletnia tradycja produkcji samochodów i co najmniej 30-letnia historia systemów zarz dzania stacjami obs ugi dokona y uporz dkowania dzia alno ci. Wprowadzi y równie wysoki poziom adu korporacyjnego u wi kszo ci licz cych si na rynku marek. Dzi ki koncepcjom lean management i japo skim systemom zarz dzania, JIT, kanban, kaizen 4, doprowadzono do wysokiej u yteczno ci systemów zintegrowanych IT w bran y samochodowej. To dlatego systemy IT sieci dilerskich s niemal doskonale uporz dkowane i zawieraj korporacyjne zasady zarz dzania biznesem danej marki. Jest to know-how implementowany w ramach umowy franchisingowej danego dilera z sieci. Nie wydaje mi si, e zbytnio b d si myli, twierdz c, e 90% systemów ERP dla dowolnych przedsi biorstw w Polsce mo na oprze na modelach funkcjonalnych zaczerpni tych ze stacji ASO Mercedes, Renault czy Peugeot-Citroën. W swojej ksi ce na temat modelowania 5 IT przedstawi em analogi funkcjonowania systemu ERP Motomanager oraz ERP dla szpitala Hospitalmanager. Ten pomys nie mo e do dzi zadzia a wy cznie z powodów politycznych. Po prostu nikt w Polsce nie jest zainteresowany 3 EIS Executive Information System (system informowania zarz du) jest to modu konsoliduj cy informacje ród owe i przygotowuj cy raporty kontrolingu i monitoringu w systemie ERP. 4 Imai M., Kaizen. Klucz do konkurencyjnego sukcesu Japonii, MT Biznes, Warszawa 2007. 5 Gospodarek T., Modelowanie w naukach o zarz dzaniu oparte na metodzie programów badawczych i formalizmie reprezentatywnym, Wydawnictwo Uniwersytetu Ekonomicznego we Wroc awiu, Wroc aw 2009, str. 181.

Wst p 11 rzeczywistym kosztem funkcjonowania s u by zdrowia oraz jej obiektywn optymalizacj. Jednak z informatycznego punktu widzenia proponowany model mo e dzia a w sposób doskona y 6. W tej ksi ce chcia bym przede wszystkim pokaza, e w dzisiejszej rzeczywisto ci biznesowej systemy informatyczne klasy ERP s z o onymi narz dziami inteligentnymi, wymagaj cymi interdyscyplinarnego podej cia do ich funkcjonalno ci i stosowania. Czysta technologia IT ma tu znaczenie drugorz dne i sprowadza si do w a- ciwego zarz dzania bazami danych oraz kojarzeniem informacji poprzez zapytania SQL. Decyzje podejmuje cz owiek. To on ustala, które informacje i w jakim uk adzie ma otrzyma z systemu IT, wykorzystuj c do wiadczenie i wiedz z zakresu zarz dzania. A jak to si b dzie dzia o w systemie komputerowym, tym zajmuje si in ynieria informatyki, która ma dost pn informacj pozyska, przetworzy i dostarczy w odpowiednim czasie do odpowiedniego miejsca. W systemach ERP technologia IT pe ni funkcj s u ebn w stosunku do zarz dzania, ale nie odwrotnie. Dlatego wszyscy oferenci systemów zintegrowanych klasy ERP czy MRPII powinni mie na uwadze, e transparentno technologii IT, ergonomia systemu informatycznego oraz bezpiecze stwo danych stanowi kluczowe cechy oceny. Licz si serwis i kastomizacja produktu. Konieczna jest te wiedza, któr musz posiada zarówno zamawiaj cy systemy, jak i oferenci rozwi za. Bez tego nie da si uzgodni stanowisk. S one wyra ane w dwóch ró ni cych si zasadniczo j zykach: mówionym (zamawiaj cy) i formalnym systemu (oferent). Chcia bym równie zwróci uwag, e proces projektowania systemów ERP sk ada si z dwóch podstawowych elementów. Jednym jest model funkcjonalny zarz dzania (ustalany przez ekonomistów oraz mened erów organizacji). Drugim jest projekt reprezentacji formalnej modelu zarz dzania (model IT). Nie da si panowa nad wdro eniem technologii inteligentnej klasy ERP bez stworzenia konceptualnych modeli kontrolingu, obiegu dokumentów, modelu ER entity relationship itd. Modelowanie w ERP musi by przeprowadzone od poziomu kontekstu biznesowego do ko cowego modelu algorytmów wyra onych w formalnym j zyku programisty w uk adzie warstw logicznych. Nie da si przeskoczy z poziomu ontologii ERP bezpo rednio do reprezentacji syntaktycznej lub do gotowego programu, który po zainstalowaniu b dzie natychmiast wykonywa u yteczne dzia ania dla organizacji. Dlatego warto pozna mechanizmy modelowania kolejnych warstw logicznych systemu. I to w a nie jest temat wart napisania ksi ki. Trzeba to zrobi tak, aby wiedza przekazana mia a charakter uniwersalny, niezale ny od technologii IT oraz zmienno ci otoczenia. Czy to si uda o w tej publikacji? Ocen pozostawiam czytelnikom, licz c na uwagi i dyskusj, która z pewno ci znajdzie fina w kolejnych wydaniach. Tadeusz Gospodarek 6 Gospodarek T., Informatyzacja komercyjnej firmy medycznej (KFM) wed ug modelu SOA [w:] Zarz dzanie komercyjn firm medyczn, pod red. M. Kowalewskiego i K. Perechudy, Wolters Kluwer, Warszawa 2008.

12 Systemy ERP. Modelowanie, projektowanie, wdra anie

Cz I Modelowanie systemów ERP

14 Cz I Modelowanie systemów ERP

Rozdzia 1. Zrozumie ERP Czym jest system ERP? Pytanie to nale y traktowa jako fundamentalne w odniesieniu do zagadnie, które b d poruszane dalej. Nale y przyj pewien kompromis epistemologiczny, umo liwiaj cy sformu owanie definicji systemu ERP w formie opisowej, a nie w formie precyzyjnego okre lenie formalnego. W ten sposób na postawione na pocz tku pytanie mo emy udzieli kilku odpowiedzi, które nie wykluczaj si wzajemnie: 1. ERP jest z o onym systemem wspomagaj cym zarz dzanie i podejmowanie decyzji. 2. ERP jest narz dziem pomiarowym oceny aksjologicznej zarz dzania. 3. ERP jest systemem porz dkuj cym procesy biznesowe organizacji. 4. ERP jest formaln reprezentacj a cucha warto ci organizacji. 5. ERP jest modelem funkcjonalno ci organizacji. 6. ERP jest zintegrowanym systemem informatycznym. Niestety, wi kszo mened erów widzi wy cznie ostatni aspekt okre lenia. Oto typowy przypadek. Pewien prezes znanej polskiej firmy postanowi wdro y system ERP. Zwo a wi c spotkanie dyrektoriatu i przemówi : Jeste my najwi ksz firm w bran- y w Polsce. Kto sprzedaje najwi ksze systemy ERP?. Informatycy odpowiedzieli, e to mo e by firma SAP. No to kupujemy system firmy SAP zdecydowa prezes. Jak postanowi, tak uczyni. Niestety, wkrótce okaza o si, e ten zakup nie by najlepsz decyzj. S awny system IT nie da sobie rady z rzeczywisto ci biznesow, z któr przysz o mu si zmierzy. Pomimo du ego nak adu si i rodków wdro enie nie posz o zbyt dobrze. I bynajmniej nie by a to wina systemu SAP. Otó to klasyczne rozumienie systemu informatycznego przez ró ne zarz dy i dyrekcje organizacji musi zosta zmienione z uj cia czysto technologicznego na uj cia systemowe. Tylko wówczas narz dzie informatyczne b dzie u yteczne i b dzie mog o pe ni jak funkcj kontroln w organizacji. ERP jest systemem z o onym, na który sk adaj si : technologia IT, wiedza ekonomiczna, struktura zarz dzania organizacj oraz zespó ludzki. To okre la, jak taki system musi by tworzony i jak ma dzia a. Koncepcj zarz dzania i pomiaru zajmuj si prezesi, a technologi informatycy.

16 Cz I Modelowanie systemów ERP Ci ostatni dostarczaj narz dzi oraz modeli poziomu semantycznego dla ju istniej cego adu organizacyjnego, ale nie odwrotnie. Pami tajmy, e to ludzie tworz struktury spo eczne i ekonomiczne. Mog one dzia a bez systemu ERP, generuj c warto w procesach biznesowych. Natomiast po czenie technologii IT i metod zarz dzania organizacj stwarza pole dla zaistnienia systemu informacyjnego wspomagaj cego procesy zarz dcze. Skuteczny system ERP jest zharmonizowanym modelem formalnym dzia ania organizacji. Jest oczywiste, e w procesach harmonizacji struktury organizacji i systemu informatycznego wyst pi aspekty dopasowania do ró nych ogranicze. Informatyka nak ada bariery technologiczne oraz prakseologiczne. Rzeczywisto gospodarcza nak ada ograniczenia na swobod interpretacji danych. Nale y zawsze pami ta, e ka dy system informatyczny jest jedynie inteligentnym narz dziem automatyzuj cym i porz dkuj cym procesy przetwarzania danych i informacji. To mo na równie przetworzy r cznie, tyle e bardzo powoli. Tym samym system ERP, i ka dy inny system IT wspomagaj cy zarz dzanie, stanowi reprezentacj formaln pewnego obrazu organizacji jej modelu funkcjonalnego. Sk adaj si na to obiegi dokumentów, struktury kompetencyjne, mapy procesów oraz zada, mapy przypisa zasobów etc. Dlatego system ERP nie powinien tworzy niczego nowego poza tym, co zosta o ju zdefiniowane na poziomie teorii ekonomii i nauk o zarz dzaniu. ERP wpisuje si w kultur organizacji, porz dkuj c procesy, ale tej kultury nie tworzy, poniewa nie jest samoprogramuj cym i samoucz cym si systemem SI. Nad tym musz pracowa ludzie. Wyniki dzia ania ERP równie s u ludziom. To w a nie stanowi istot zagadnienia. Reprezentacja formalna informatyczna (system ERP) musi by odwzorowaniem wzajemnie jednoznacznym ze swoim modelem rzeczywistym biznesu i jego procesów. W przeciwnym wypadku system informatyczny nie b dzie w stanie dostarcza spójnych informacji interpretowalnych przez ludzi. Co w takim razie mierzy system ERP, skoro jest narz dziem pomiarowym? Otó mierzy on, czy organizacja dzia a dobrze, czy le w czasie. A wi c odpowiada na pytania aksjologiczne, co oznacza dobra albo z a organizacja (lub jej funkcjonalno ) w danej chwili czasu oraz czy mo e by ona lepsza. A to wi e si z niezwykle trudnym problemem okre lenia, co znaczy stan organizacji w danej chwili czasu. Drug spraw jest ustalenie, czym jest warto kreowana przez organizacj w otoczeniu i jak j opisa formalnie. Jak wida, postawione kwestie z pewno ci nie nale do zagadnie informatyki, ale do problematyki ekonomii i zarz dzania, a bardziej poprawnie do zagadnie interdyscyplinarnych zwi zanych z systemami oraz z o ono ci. To ekonomi ci danej firmy musz najpierw zdefiniowa, jak zmierzy po o enie spo eczno-ekonomiczne, a dopiero pó niej si ga po narz dzia klasy ERP do automatyzacji pomiaru i monitoringu funkcji celu w czasie. Zwykle za jest tak, e kupuje si jakie rozwi zanie standardowe, zawieraj ce w sobie okre lon filozofi kontrolingu i logik biznesow. Wynika ona z wdro e oraz do wiadcze twórców ERP, która najcz ciej nie pasuje do kultury organizacji, w której ma by wdra ana. W ten sposób niemal zawsze istnieje konflikt 1 Wzajemnie jednoznaczny oznacza, e jakakolwiek zmiana w dzia aniu rzeczywistego modelu (np. obiegu dokumentów) musi zosta uwzgl dniona w systemie IT i odwrotnie. Cokolwiek zostanie wprowadzone w systemie IT, jako uproszczenie, udoskonalenie, optymalizacja (np. nowy dokument), musi zosta wdro one praktycznie. Dotyczy to zw aszcza wszelkich dokumentów finansowych, opisuj cych warto dodan w procesach biznesowych oraz sposobów ich rozksi gowania w systemie FK, gdzie agregowane s najistotniejsze dane.

Rozdzia 1. Zrozumie ERP 17 pomi dzy oczekiwaniami ze strony inwestorów oraz u ytkowników systemu ERP a technologicznymi i organizacyjnymi mo liwo ciami ich spe nienia. Najwi kszym jednak problemem jest ró nica pomi dzy wiedz próbuj cych skorzysta z dobrodziejstwa systemu ERP a wiedz oferenta rozwi za technicznych. Ci ostatni najcz ciej zbyt s abo znaj kwestie ekonomiczne i biznesowe organizacji i przede wszystkim skupiaj si na mo liwo ciach technicznych oraz technologicznych oferowanych produktów. Daleki jestem od tego, eby nie przejmowa sprawdzonych na rynku rozwi za standardowych, zw aszcza dla ma ych i rednich firm. Jest to bardzo skuteczna metoda wykonania skoku cywilizacyjnego organizacji na wy szy poziom zarz dzania. A to dzi ki wiedzy know-how ukrytej w poprawnie skonfigurowanych systemach zintegrowanych IT, wspomagaj cych zarz dzanie oraz logice biznesowej sprawdzonej w praktyce przez producentów. Jednak w przypadku organizacji opartych na wiedzy, albo tych, dla których wynik finansowy stanowi jedynie jeden z aspektów oceny warto ci lub funkcjonalno ci, takie gotowe rozwi zania na ogó nie s zadowalaj ce. A je eli pomiar stanu organizacji czy jej wydzia u wymaga stworzenia wieloaspektowych raportów przekrojowych, wówczas z pewno ci standardowe rozwi zania si nie sprawdz. Dotyczy to zw aszcza cz ci definiuj cej pozycje po danych formularzy modu ów informowania kierownictwa. Dlatego dobr praktyk przed przyst pieniem do realizacji projektu wdro enia systemu klasy ERP w organizacji powinno by przygotowanie porz dnego studium wykonalno ci. Kolejn kwesti do rozwi zania przed przyst pieniem do informatyzacji systemowej klasy ERP jest okre lenie kryteriów dla oceny rezultatów pomiarów oraz zdefiniowania kwantyfikatorów monitoringu. Przyk adami takich wska ników mog by : wska nik ROI, wska nik efektywno ci inwestycji w analizie CBA 2, EBITDA 3, wska nik pokrycia kosztów etc. Architekt systemu kontrolingu powinien wybra pewn grup takich najistotniejszych wska ników (patrz rozdzia 3.4.1). Nast pnie nale y ustali, sk d je pozyska (czy z FK, czy ksi g pomocniczych) oraz jakie warto ci krytyczne ka dego z nich nale y sygnalizowa i wyja nia poprzez automatyk przetwarzania danych systemu IT. To w a nie stanowi ide systemu ERP: monitorowa zagro enia zak adanej funkcji celu w czasie i w por reagowa. Jak wida, jest to zadanie z pogranicza informatyki, ekonomii oraz zarz dzania. Ale najwa niejszym aspektem jest fakt, e o interpretacji wyników oferowanych przez system ERP nale y rozwa a w kontek cie zmienno ci parametrów otoczenia. ERP stanowi w tej kwestii narz dzie monitoringu procesu ci g ej autoadaptacji organizacji w grze przeciwko otoczeniu 4. Tu system informatyczny wspiera podejmowanie decyzji. Pozwala prognozowa, porównywa stany oraz mierzy skutki podejmowanych decyzji o charakterze taktycznym. 2 CBA Cost-Benefit Analysis (analiza kosztów i korzy ci) patrz http://pl.wikipedia.org/wiki/analiza_koszt%c3%b3w_i_korzy%c5%9bci. 3 Earnings before Interest, Taxes, Depreciation and Amortization oznacza zysk przedsi biorstwa przed potr ceniem odsetek od zaci gni tych kredytów, dywidend, podatków oraz amortyzacji. 4 Gospodarek T., Aspekty z o ono ci i filozofii nauki w zarz dzaniu, Wydawnictwo WWSZiP w Wa brzychu, Wa brzych 2012.

18 Cz I Modelowanie systemów ERP Jak dzia a prawid owo wdro ony system ERP? Wydaje si to proste. Organizacja dysponuje okre lonymi zasobami, posiada zdefiniowany a cuch warto ci. Okre li a swój a cuch dostaw, zdefiniowa a procesy biznesowe umo liwiaj ce ci g o kreacji warto ci w otoczeniu, a nast pnie wykona a model formalny opisuj cy sposób dokumentowania wszystkich zdarze biznesowych. Utworzy a równie kryteria poprawno ci wyniku wraz z miar i skal parametrów kontrolnych funkcji celu. Zaistnia przy tym system informacyjny, stanowi cy izomorficzn reprezentacj formaln mierzonych warto ci. Umo liwia on dokonywanie pomiarów parametrów stanu w ustalonej skali w czasie. Mo na wówczas stwierdzi, e zaistnia system ERP pozwalaj cy na okre- lenie po o enia funkcjonalnego organizacji lub jej cz ci w danej chwili czasu. To po o enie opisane jest przez sko czon liczb parametrów stanu. Wykonuj c dowolne zmiany w a cuchu warto ci (np. zwi kszaj c sprzeda ), powodujemy, e na wyj ciu systemu ERP otrzymujemy inne warto ci po czasie t ani eli w chwili pocz tkowej t 0 przed dokonaniem zmian. Je eli dokonane zmiany poprawiaj wska niki, mówimy o dodatnim sprz eniu zwrotnym i kontynuujemy dzia ania w danym kierunku. Je li natomiast dokonane zmiany na wej ciu pogarszaj osi gane wska niki na wyj ciu, staramy si w kolejnym przedziale czasu poprawi parametry wej cia, tak eby osi gn zak adane warto ci (ujemne sprz enie zwrotne). Tym samym system ERP jest urz dzeniem analitycznym sprz enia zwrotnego wej cia-wyj cia a cucha warto ci organizacji. Jest to bardzo czytelny model funkcjonalny, który warto bardziej szczegó- owo opisa od strony praktycznej wdro enia. 1.1. Uk ad modelowania ERP Zbudowanie modelu systemu ERP nie jest tym samym co wykonanie modelu mostu lub samochodu. Wynika to z faktu, e system informatyczny dotyka kilku roz cznych aspektów rzeczywisto ci spo eczno-ekonomicznej. Stawia wymagania ogranicze niejednoznaczno ci interpretacji wyników oraz wymiernych definicji wielko ci, którymi si pos uguje. Pojawia si konflikt. Z jednej strony ograniczenia technologiczne nie pozwalaj na realizacj dowolnych algorytmów przez maszyny. Z drugiej za wymaga si cis ej kwantyfikacji zdarze biznesowych (spo ecznych) za pomoc sko czonej liczby parametrów, aby ustali jaki stan mierzalny w czasie. To prowadzi do niebezpiecznych luk interpretacyjnych na ró nych poziomach modelowania i utrudnia zadanie. Cz ciowo mo na ten konflikt zneutralizowa przez podzia modelowania systemu ERP przynajmniej na cztery wzajemnie sprz one kierunki (patrz rysunek 1.1): modelowanie konceptualne (filozofia zarz dzania); modelowanie ekonomiczne (metodologia i pomiar); modelowanie informacyjne (formalne przetwarzanie informacji); modelowanie informatyczne (programy w j zyku formalnym). 5 Porter M., Przewaga konkurencyjna, Helion, Gliwice 2006.

Rozdzia 1. Zrozumie ERP 19 Rysunek 1.1. Uk ad modelowania systemu ERP Samo modelowanie podzielone jest na okre lone warstwy logiczne (ontologia, epistemologia itp.). W efekcie powstaje pewien ci g komplementarnych dokumentów (model ontologiczny, funkcjonalny, semantyczny itp.). Jest on coraz bardziej zbli ony do sformalizowanego uj cia zagadnienia. Warto w tym miejscu zauwa y, e definiuj c za o enia systemu ERP, pos ugujemy si j zykiem naturalnym, wieloznacznym, metaforycznym. Na wyj ciu modelu ekonomicznego (reprezentacje i algorytmy) ca o systemu wyra ona jest j zykiem quasi-formalnym. Dopiero wówczas modelowanie stricte informatyczne mo e dokona ostatecznej formalizacji w wybranym j zyku programowania, zrozumia ym dla systemów translacyjnych komputera. Nie mamy adnej gwarancji, e przyst puj c do projektowania systemu ERP za pomoc uk adu modeli wzajemnie dope niaj cych si (patrz rysunek 1.1), na wyj ciu otrzymamy dok adnie to samo, co zamy lano na wej ciu. Translacja poj z j zyka naturalnego na j zyk formalny informatyki nie zawsze jest wzajemnie jednoznaczna. Dodatkowo ka dy model wprowadza okre- lone uproszczenia oraz ograniczenia formalne. Dlatego prezentowane na rysunku 1.1 modelowanie kaskadowe jest jedynie sensownym kompromisem, ale lepszej drogi nie ma. To jednak oznacza, e nie da si pomin adnego z wymienionych poziomów modelowania, przedstawionych na rysunku 1.1. A dodatkowo nie da si przeskoczy okre lonego poziomu modelowania, pomijaj c go. Od koncepcji do wyników z komputera wiedzie daleka i do wyboista droga. Dlatego nale y dok adnie opisa poszczególne etapy modelowania, poniewa stanowi one cenne wskazówki dla architekta systemu oraz projektanta.