Bazy NoSQL jako implementacje wzorców struktur informacji

Dane nie­struk­tu­ral­ne sta­no­wią ponad 80% skła­do­wa­nych danych, to ozna­cza, że model rela­cyj­ny pozwa­la opi­sać i prze­twa­rzać tyl­ko uła­mek posia­da­nej infor­ma­cji (UNSTRUCTURED DATA AND THE 80 PERCENT RULE)

Wstęp

W pod­su­mo­wa­niu nie­daw­ne­go arty­ku­łu o NoSQL w chmu­rze, napisałem: 

Problem pro­jek­to­wa­nia struk­tur doku­men­tów, tak­że w bazach doku­men­to­wych, to osob­ne i trud­ne zagad­nie­nie. Opisałem go w naj­now­szym arty­ku­le, któ­ry uka­że się za nie­dłu­go w wydaw­nic­twie IGI Global: Emerging Challenges, Solutions, and Best Practices for Digital Enterprise Transformation. (Repozytorium w chmu­rze – NoSQL – Jarosław Żeliński IT-Consulting – Systemy Informacyjne)

Artykuł sie wła­śnie uka­zał. We wstę­pie napisałem:

Dokumenty czę­sto zawie­ra­ją dużą ilość róż­nych danych two­rzą­cych wspól­nie wie­le kon­tek­sto­wych zbio­rów danych (agre­ga­tów). Zastosowanie mode­lu rela­cyj­ne­go do orga­ni­za­cji takich danych pro­wa­dzi do wyge­ne­ro­wa­nia roz­bu­do­wa­ne­go sys­te­mu powią­za­nych rela­cyj­nie tabel, przy czym usu­nię­cie redun­dan­cji czę­sto powo­du­je utra­tę kon­tek­stu tre­ści poszcze­gól­nych pól w tabe­lach. Rodzi to koniecz­ność sto­so­wa­nia wyso­ce zło­żo­nych zapy­tań SQL, aby doku­men­ty te mogły być zapi­sy­wa­ne w tej bazie danych i z niej pobie­ra­ne. W ten spo­sób sama baza danych zawie­ra wyłącz­nie dane pozba­wio­ne kon­tek­stu obec­ne­go w tabe­lach, a nie dokumenty.

Wielu auto­rów zwra­ca­ło uwa­gę na pro­blem zło­żo­no­ści i utra­ty jed­no­li­te­go kon­tek­stu mode­lu rela­cyj­ne­go (Ślęzak i in., 2018). Autorzy ci suge­ro­wa­li, że kon­tek­sty powin­ny być sepa­ro­wa­ne w dużych rela­cyj­nych mode­lach danych. Jednak zale­ce­nie sepa­ra­cji kon­tek­stów (Evans, 2003; Fowler, 1997; Fowler & Rice, 2005), przy zacho­wa­niu mode­lu rela­cyj­ne­go, nie poma­ga w cał­ko­wi­tym roz­wią­za­niu pro­ble­mu (Awang et al., 2012, 2012, 2012).

Zmiana kon­tek­stu czę­sto zmie­nia zna­cze­nie danych (Danesi, 2004). Podejmowane pró­by zacho­wa­nia zna­cze­nia danych czę­sto pro­wa­dzą do two­rze­nia roz­bu­do­wa­nych rela­cyj­nych mode­li danych, gene­ru­jąc tym samym dodat­ko­we kosz­ty. Dlatego też wyko­rzy­sta­nie jed­ne­go rela­cyj­ne­go mode­lu danych do zapi­su zawar­to­ści wie­lu róż­nych doku­men­tów może uczy­nić z takie­go sys­te­mu ogrom­ny i nie­po­dziel­ny mono­lit, któ­ry jest kosz­tow­ny zarów­no w roz­wo­ju, jak i w utrzy­ma­niu. (Digital Documents as Data Carriers and a Method of Data Management Guaranteeing the Unambiguity of the Recorded Information: Ontology-Oriented Data Management and Document Databases)

Rodzaje baz danych NoSQL na rynku

Praktyka poka­zu­je, że bazy te to odpo­wiedź na stan­dar­do­we obec­nie wyma­ga­nia wobec sys­te­mów infor­ma­cyj­nych, jaki­mi są zmien­ność struk­tur danych, ich ogra­ni­czo­na struk­tu­ra­li­za­cja lub nawet jej cał­ko­wi­ty brak .

Akronim NoSQL został po raz pierw­szy uży­ty w 1998 roku przez Carlo Strozzi’ego jako nazwa jego lek­kiej, open­so­ur­ce rela­cyj­nej” bazy danych, któ­ra nie uży­wa­ła SQL. Nazwa ta poja­wi­ła się ponow­nie w 2009 roku, kie­dy Eric Evans i Johan Oskarsson uży­li jej do opi­sa­nia nie­re­la­cyj­nych baz danych. Relacyjne bazy danych są czę­sto okre­śla­ne jako sys­te­my SQL. Termin NoSQL może ozna­czać zarów­no Nierelacyjna SQL” lub bar­dziej popu­lar­ne tłu­ma­cze­nie Nie tyl­ko SQL” (Not only SQL), aby pod­kre­ślić fakt, że nie­któ­re sys­te­my mogą obsłu­gi­wać języ­ki zapy­tań podob­ne do SQL. (źr.: A Brief History of Non-Relational Databases – DATAVERSITY)

Jeden z moim zda­niem cie­kaw­szych arty­ku­łów o NoSQL napi­sał Fowler 10 lat temu .

Bazy danych «key-value».

Bazy te są naj­prost­szym typem bazy NoSQL. Każdy ele­ment (wiersz) w takiej bazie to para klucz i war­tość (dane prze­cho­wy­wa­ne), tu zawar­tość (dane prze­cho­wy­wa­ne) to zawsze jakiś plik” (podob­nie jak pole typu BLOB: Binary Large OBject). Zawartość ta może być pobra­na wyłącz­nie poprzez odwo­ła­nie się do jej iden­ty­fi­ka­to­ra (klu­cza) . Bazy te są dosko­na­łe do prze­cho­wy­wa­nia dużych ilo­ści róż­no­rod­nych danych, gdzie nie trze­ba prze­twa­rzać tre­ści tych danych w samej bazie (np. wyszu­ki­wa­nie zawar­to­ści na pod­sta­wie jej okre­ślo­nych cech). Służą one wyłącz­nie do zacho­wy­wa­nia i odzy­ski­wa­nia pli­ków. Praktycznie jest to pła­ski sys­tem plików. 

model repo­zy­to­rium key-value (opra­co­wa­nie wła­sne autora) 
meto­da zapi­su w repo­zy­to­rium key-value (opra­co­wa­nie wła­sne autora) 

Dokumentowe bazy danych. 

To odmia­na bazy key-value. Przechowuje dane w posta­ci okre­ślo­nej struk­tu­ral­nej tre­ści: doku­men­tów (np. JSON czy XML). Struktury te mają swo­je defi­ni­cje, a ich typów może być dowol­na licz­ba . Jedna baza może więc zawie­rać doku­men­ty o dowol­nie wybra­nej, okre­ślo­nej struk­tu­rze. Dostępne na ryn­ku bazy tego typu maja tak­że bar­dzo dobre i szyb­kie moto­ry zapy­tań, są coraz czę­ściej sto­so­wa­ne jako bazy danych ogól­ne­go przeznaczenia. 

Baza doku­men­to­wa. Dokument to czy­tel­na dla czło­wie­ka treść, w bazach doku­men­to­wych ma on okre­ślo­na ale nie sztyw­ną struk­tu­rę: może to być JSON, XML. Dokument (jego treść) jest prze­twa­rza­ny poza bazą danych (kom­po­nent Logika biz­ne­so­wa). (opra­co­wa­nie wła­sne autora) 

Bazy zmieno-kolumnowe.

Przechowują dane w posta­ci agre­ga­tów o zmien­nych liściach”. Bazy tego typu zapew­nia­ją dużą ela­stycz­ność w sto­sun­ku do rela­cyj­nych baz danych, ponie­waż nie jest wyma­ga­ne, aby każ­dy wiersz agre­gat posia­dał tyle samo i te same ele­men­ty (kolum­ny) . Bazy tego typu są powszech­nie sto­so­wa­ne do prze­cho­wy­wa­nia danych np. danych pro­fi­lo­wych użyt­kow­ni­ków. Są czę­sto opi­sy­wa­ne w poniż­szy sposób:

Diagram of a column family in a wide column store database.
Model archi­tek­tu­ry kom­po­nen­tu z bazą zmien­no-kolum­no­wą (powyż­sze wyra­żo­ne jako model dzie­dzi­ny kom­po­nen­tu z uży­ciem UML)

Jak widać, bazy te prze­cho­wu­ją agre­ga­ty. Nazwanie agre­ga­tu wier­szem” jest nie­for­tun­ne bo to jed­nak nie są pła­skie tabe­le, jed­nak poję­cia wier­szy i kolumn zrzu­cam tu jed­nak na karb ste­reo­ty­pu zaczerp­nię­te­go z mode­lu relacyjnego.

Grafowe bazy danych. 

Przechowują dane w posta­ci węzłów i kra­wę­dzi (aso­cja­cje mię­dzy węzła­mi). Węzły zazwy­czaj prze­cho­wu­ją infor­ma­cje o obiek­tach (ludzie, miej­sca, przed­mio­ty) kra­wę­dzie zaś prze­cho­wu­ją infor­ma­cje o moż­li­wych związ­kach mię­dzy węzła­mi . Grafowe bazy danych dosko­na­le spraw­dza­ją się w przy­pad­kach gdy trze­ba zapi­sy­wać i śle­dzić związ­ki mię­dzy obiek­ta­mi i ana­li­zo­wać je, np. sie­ci spo­łecz­no­ścio­we czy wykry­wa­nie oszustw. Tak są naj­czę­ściej opi­sy­wa­ne gra­fo­we bazy danych, a przed­sta­wia­ne są np. tak:

Uważam, że powyż­sze to try­wial­na i naiw­na meto­da przed­sta­wia­nia baz tego typu. Istotą sys­te­mu prze­twa­rza­nia infor­ma­cji jest tu (w takim mode­lu) jest prze­cho­wy­wa­nie infor­ma­cji o obiek­tach i o fak­tach je łączą­cych takich jak zda­rze­nia doty­czą­ce pary obiek­tów . Mogą to być typo­we fak­ty, np. Samochód miał koli­zje w Mieście, gdzie Samochód i Miasto to węzły, a koli­zja to zda­rze­nie. Ważne jest to, że Samochód i Miasto moż­na opi­sać okre­ślo­nym cech, sama koli­zje tak­że, waż­ne jest to, że fak­tów łączą­cych dwa obiek­ty może być wie­le (w czasie). 

Związki mię­dzy obiek­ta­mi opi­sy­wa­ne są też meto­dą RDF (Resource Description Framework) jako zda­nia: Subject – Predicate – Object .

O każ­dym obiek­cie będzie jeden rekord w bazie danych, o każ­dym fak­cie też, ale róż­nych fak­tów, któ­rych cecha­mi są te obiek­ty może być wie­le (cechą stłucz­ki jest mię­dzy inny­mi miej­sce stłucz­ki i samo­chód, któ­ry miał tę stłucz­kę). Cechami obiek­tów są nazwa, data powsta­nia i ewen­tu­al­na data usu­nię­cia (znisz­cze­nia), tak­że cechy defi­niu­ją­ce takie jak np. kolor, typ czy wyda­wa­ne dźwię­ki. Cechami fak­ty są czas zaist­nie­nia oraz obiek­ty (ich nazwy), któ­rych okre­ślo­ny fakt doty­czy. Ważne jest to, że poło­że­nie obiek­tu nie jest jego cechą defi­niu­ją­cą. Graf jest defi­nio­wa­ny jako nazwa­ne związ­ki mię­dzy obiek­ta­mi, są nimi wła­śnie fak­ty (a sze­rzej: pre­dy­ka­ty). Warto też zazna­czyć, że w kon­tek­ście np. zda­rzeń gospo­dar­czych, fak­tem jest fak­tu­ra opi­su­ją­ca trans­ak­cje do jakiej doszło. Jednak w archi­wum doku­men­tów fak­tu­ra jest obiek­tem archi­wal­nym .

Tak więc bar­dziej sfor­ma­li­zo­wa­na struk­tu­ra danych w bazie gra­fo­wej mogła by wyglą­dać tak:

Struktura infor­ma­cyj­na gra­fo­wej bazy danych: obiek­ty (nie­bie­skie) i związ­ki (żół­te) (opra­co­wa­nie wła­sne autora)

Diagram powyż­szy jest kolo­ro­wa­ny dla popra­wy czy­tel­no­ści. W tej posta­ci widać obiek­ty i łączą­ce je fak­ty: w bazach gra­fo­wych są to for­mal­nie tak zwa­ne związ­ki seman­tycz­ne (zna­cze­nio­we), ale jest to jed­nak duże uprosz­cze­nie. Systemy zapi­su infor­ma­cji w posta­ci tró­jek: poję­cie-pre­dy­kat-poję­cie mają szer­sze uza­sad­nie­nie (pla­nu­ję publi­ka­cję z wyni­ka­mi szer­szych badań). Metamodel sys­te­mu zapi­su infor­ma­cji o obiek­tach i związ­kach mię­dzy nimi wyglą­da tak:

Metamodel gra­fo­wej bazy danych (opra­co­wa­nie wła­sne autora) 

Warto zauwa­żyć, że zarów­no Obiekt jak i Związek seman­tycz­ny mogą być prze­cho­wy­wa­ne w bazie doku­men­to­wej lub kolumnowej…

Podsumowanie

To co dzi­siaj nazy­wa­my baza­mi danych NoSQL to tyl­ko natu­ral­ne mode­le infor­ma­cyj­ne. Kiedy odkry­te? Nie wiem, ale wiem, że w tym wszyst­kim naj­bar­dziej nie­na­tu­ral­ny jest model rela­cyj­ny. Dlaczego? Bo nie wystę­pu­je w natu­rze i spra­wia same pro­ble­my. Celowo zapre­zen­to­wa­łem sfor­ma­li­zo­wa­ne dia­gra­my UML dla każ­de­go typu, by poka­zać, że NoSQL to tyl­ko i aż mode­le infor­ma­cyj­ne spo­ty­ka­ne w rze­czy­wi­sto­ści życia czło­wie­ka. Konstrukcje jak te wyżej opi­sa­ne, to tak na praw­dę mode­le infor­ma­cji wyni­ka­ją­ce z dzie­dzi­ny pro­ble­mu, nie jest tak że są uży­wa­ne z powo­du wyna­le­zie­nia” baz NoSQL, jest dokład­nie odwrotnie. 

Obecne bazy NoSQL rozu­mia­ne jako moto­ry baz danych”, to imple­men­ta­cje infor­ma­cyj­nych wzor­ców pro­jek­to­wych. Diagramy UML powy­żej to meta­mo­de­le tych wzorców. 

Na temat baz danych i baz NoSQL pole­cam kom­plek­so­we opra­co­wa­nie Joe Celko: Complete guide to NoSQL: what eve­ry SQL pro­fes­sio­nal needs to know abo­ut non­re­la­tio­nal data­ba­ses .

Podsumowanie 2

Pojawiają się tezy że to się nie nada­je do ERP, że nikt tak nie robi… Otóż:

Systemy ERP budo­wa­ne w opar­ciu o cen­tral­ne bazy danych RDBMS ewo­lu­ują­ce do chmu­ry są nie­ja­ko ska­za­ne na bazy NoSQL (zna­ko­mi­ta więk­szość chmu­ro­wych repo­zy­to­riów chmu­ro­wych to bazy NoSQL).

Ewolucja Architektury tak zwa­nych stan­dar­do­wych ERP 

Podstawowym pro­ble­mem sys­te­mów zbu­do­wa­nych w opar­ciu o bazy RDBMS/SQL jest to, że nie ma w nich doku­men­tów, a jedy­nie dane roz­ło­żo­ne w tabe­lach. Uzyskanie doku­men­tu (np. fak­tu­ry) wyma­ga każ­do­ra­zo­wo dyna­micz­ne­go zebra­nia danych z wie­lu tabel, ich złą­cze­nia i sfor­ma­to­wa­nia, czy­li uży­cia języ­ka SQL. Dlatego ewo­lu­cja nowo­cze­snych sys­te­mów ERP idzie w kie­run­ku sys­te­mów, w któ­rych funk­cje kal­ku­la­cyj­ne oraz doku­men­ty są roz­dzie­lo­ne, a doku­men­ty są prze­cho­wy­wa­ne w posta­ci zmaterializowanej: 

Zarządzanie doku­men­ta­mi w sys­te­mach ERP 

Podsumowanie 3

Od dłuż­sze­go cza­su sto­su­je w pro­jek­tach struk­tu­ry infor­ma­cyj­ne nazy­wa­ne NoSQL. Sa to prak­tycz­nie wszyst­kie opi­sa­ne wyżej struk­tu­ry. Projekt dla agen­cji foto­gra­ficz­nej BE&W (archi­wum zdjęć), pro­jekt dla Biura Polonii Kancelarii Senatu (obsłu­ga wnio­sków o dofi­nan­so­wa­nie o zmien­nej struk­tu­rze), pro­jekt dla Żandarmerii Wojskowej (zarzą­dza­nie spra­wa­mi docho­dze­nio­wo-śled­czy­mi w całej Polsce), pro­jekt dla KGHM (stan­da­ry­za­cja sys­te­mu utrzy­ma­nia ruchu, zarzą­dza­nie infra­struk­tu­rą produkcyjną).

Więcej już nie­dłu­go… Zachęcam do zada­wa­nia pytań o NoSQL pod tym wpisem. 

Źródła

Bouhali, R., & Laurent, A. (2015). Exploiting RDF Open Data Using NoSQL Graph Databases. In R. Chbeir, Y. Manolopoulos, I. Maglogiannis, & R. Alhajj (Eds.), Artificial Intelligence Applications and Innovations (Vol. 458, pp. 177 – 190). Springer International Publishing. https://​doi​.org/​1​0​.​1​0​0​7​/​978 – 3‑319 – 23868-5_13
Besta, M., Peter, E., Gerstenberger, R., Fischer, M., Podstawski, M., Barthels, C., Alonso, G., & Hoefler, T. (2020). Demystifying Graph Databases: Analysis and Taxonomy of Data Organization, System Designs, and Graph Queries. ArXiv:1910.09017 [Cs]. http://​arxiv​.org/​a​b​s​/​1​9​1​0​.​0​9​017
Harley Vera, Wagner Boaventura, Maristela Holanda, Valeria Guimaraes, & Fernanda Hondo. (2015). Data Modeling for NoSQL Document-Oriented Databases. CEUR Workshop Proceedings, 1478, 129 – 135.
Celko, J. (2014). Joe Celko’s Complete guide to NoSQL: what eve­ry SQL pro­fes­sio­nal needs to know abo­ut non­re­la­tio­nal data­ba­ses. Elsevier/Morgan Kaufmann.
Garba, M. (2020). A Comparison of NoSQL and Relational Database Management Systems (RDBMS). 1(2), 9.
Karnitis, G., & Arnicans, G. (2015). Migration of Relational Database to Document-Oriented Database: Structure Denormalization and Data Transformation. 2015 7th International Conference on Computational Intelligence, Communication Systems and Networks, 113 – 118. https://​doi​.org/​1​0​.​1​1​0​9​/​C​I​C​S​y​N​.​2​0​1​5​.30
Gyorödi, C., Gyorödi, R., & Sotoc, R. (2015). A Comparative Study of Relational and Non-Relational Database Models in a Web- Based Application. International Journal of Advanced Computer Science and Applications, 6(11). https://​doi​.org/​1​0​.​1​4​5​6​9​/​I​J​A​C​S​A​.​2​0​1​5​.​0​6​1​111
Guimaraes, V., Hondo, F., Almeida, R., Vera, H., Holanda, M., Araujo, A., Walter, M. E., & Lifschitz, S. (2015). A stu­dy of geno­mic data pro­ve­nan­ce in NoSQL docu­ment-orien­ted data­ba­se sys­tems. 2015 IEEE International Conference on Bioinformatics and Biomedicine (BIBM), 1525 – 1531. https://​doi​.org/​1​0​.​1​1​0​9​/​B​I​B​M​.​2​0​1​5​.​7​3​5​9​902

Wymagania na coś dużego – w czym problem?

Zapytania o pro­dukt mają­cy wdzięcz­ną nazwę Analiza potrzeb i opra­co­wa­nie wyma­gań na sys­tem ERP” (w miej­sce ERP moż­na wsta­wić dowol­ny innych skrót w rodza­ju CRM, BI, SCM, work­flow itp..) naj­czę­ściej rodzą ocze­ki­wa­nia w posta­ci lista wyma­gań funk­cjo­nal­nych i poza-funkcjonalnych”.

Lista taka jest zna­na z inży­nie­rii opro­gra­mo­wa­nia i jest powszech­nie sto­so­wa­na do pro­jek­to­wa­nia i wytwa­rza­nia tego opro­gra­mo­wa­nia. Ale jest pewien pro­blem gdy celem jest zakup goto­we­go opro­gra­mo­wa­nia, bo w koń­cu goto­we­go nie pro­jek­tu­je­my, bo podob­no ma być tań­sze niż pisa­nie od początku.

Niedawno napi­sa­łem:

Duży sys­tem ERP to set­ki i tysią­ce jego przy­pad­ków uży­cia, nie ma sen­su ich spe­cy­fi­ko­wa­nie podob­nie jak nie ma sen­su pyta­nie o nie przy­szłych użyt­kow­ni­ków tego sys­te­mu, bo nie są w sta­nie ich wyli­czyć. Ma jed­nak sens zro­zu­mie­nie tego jak fir­ma dzia­ła. Po raz kolej­ny posłu­żę się meta­fo­rą Martina Fowlera: grę w sno­oke­ra moż­na opi­sać rela­cjo­nu­jąc (zapi­su­jąc) set­ki kolej­nych par­tii, ale i tak nigdy nie wyspe­cy­fi­ku­je­my nawet ułam­ka moż­li­wych zagrań. Zdecydowanie lep­szą meto­dą jest przyj­rze­nie się kil­ku par­tiom i wychwy­ce­nie cech bili, ich ilo­ści, wymia­rów sto­łu oraz reguł gry, bo to będzie zgod­ne nie tyl­ko z histo­rią ode­gra­nych par­tii sno­oke­ra ale z każ­dą przy­szłą partią.

Dlatego zamiast pro­wa­dze­nia żmud­nych wywia­dów i two­rze­nie nie­sku­tecz­nej listy setek szcze­gó­ło­wych opi­sów moż­li­we­go uży­cia opro­gra­mo­wa­nia, lepiej jest zro­zu­mieć orga­ni­za­cję, stwo­rzyć jej model (dzie­dzi­ny) i wyspe­cy­fi­ko­wać jakie usłu­gi ma to opro­gra­mo­wa­nie świad­czyć dla użyt­kow­ni­ków teraz (bo tak nale­ży rozu­mieć poję­cie przy­pad­ku uży­cia sys­te­mu). Poprawny model dzie­dzi­ny pozwo­li tak­że na obsłu­gę przy­szłych wyma­gań mimo, że nie zna­my ich teraz. Podobnie jak stół bilar­do­wy: nie zna przy­szłych ude­rzeń ale wie­my, że na pew­no zosta­ną ?obsłu­żo­ne?. (Czym jest to co mode­lu­jesz w opro­gra­mo­wa­niu? Model dzie­dzi­ny sys­te­mu jako wyma­ga­nie.).

Wydawało by się, że wszyst­ko jasne. Ale? Popatrzmy na poniż­szy diagram:

Czas trwa­nia ana­li­zy i spe­cy­fi­ko­wa­nia (pra­co­chłon­ność, więc tak­że koszt) rośnie linio­wo w takt kolej­nych dni pra­cy nad ana­li­zą. W mia­rę powsta­wa­nia kolej­nych udo­ku­men­to­wa­nych szcze­gó­łów, ryzy­ko, że wybie­rze­my zły (nie­pa­su­ją­cy nam) pro­dukt male­je. Jednak ryzy­ko jest, jak widać, funk­cją nie­li­nio­wą (jest to praw­do­po­do­bień­stwo złe­go wybo­ru, któ­re nigdy nie doj­dzie do zera) zaś wzrost kosz­tów jest linio­wy. W efek­cie od pew­ne­go momen­tu, dość bli­skie­go począt­ko­wi tej pra­cy, kosz­ty takiej ana­li­zy rosną szyb­ciej niż korzy­ści z jej szcze­gó­ło­wo­ści. Tak więc w typo­wym pro­jek­cie w zasa­dzie ska­za­ni jeste­śmy na kom­pro­mis i uzna­nie pew­ne­go (nie tak małe­go) ryzy­ka, że jed­nak wybór będzie zły (mimo, że pro­dukt speł­ni skoń­czo­ną listę wymagań).

Przekroczenie pew­nej umow­nej gra­ni­cy roz­sąd­ku” – ana­li­zy i spi­sy­wa­nia szcze­gó­łów – popy­cha taki pro­jekt w kie­run­ku pro­jek­to­wa­nia nowe­go sys­te­mu, a mia­ło być tanio, bo chce­my kupić sys­tem goto­wy. Krótkie wyli­cze­nie: typo­wy sys­tem ERPII to ok. 6 tys. cech. Samo ich spi­sa­nie ze zro­zu­mie­niem to:

  • opis jed­ne­go wyma­ga­nia to 500 zna­ków (śred­ni wynik z kil­ku zna­nych mi dokumentów)
  • jed­na stro­na maszy­no­pi­su to 1800 znaków
  • 6 tys cech to 6000 x 500 zna­ków / 1800 stro­na = 1667 stron tekstu
  • z roz­mów z wyko­naw­ca­mi ana­li­ty­ka­mi wiem, że efek­tyw­nie piszą ok. 7 mery­to­rycz­nych stron dzien­nie (to dość opty­mi­stycz­ne założenie)
  • w efek­cie 1667 stron / 7 dzien­nie = 238 dni robo­czych, staw­ka bar­dzo tanie­go kon­sul­tan­ta to np. 1000zł/dzień, otrzy­mu­je­my: 238 tys. zło­tych i ponad rocz­ny projekt.
  • Jeżeli uzna­my, że jed­nak spe­cy­fi­ko­wa­nie jest poprze­dza­ne ana­li­zą, dla uprosz­cze­nia (zno­wu bar­dzo opty­mi­stycz­nie) przyj­mę, trwa­ją­ca tyle co spi­sy­wa­nie jej wyni­ków, mamy dwa lata pra­cy i pół milio­na złotych.
  • Skrócenie tego poprzez zatrud­nie­nie nie jed­ne­go a np. czte­rech ana­li­ty­ków pod­nie­sie kosz­ty o ok. 30% (znam takich, któ­rzy by tu doda­li 50% i pew­nie mają nie raz rację) na koor­dy­na­cję, kon­tro­lę zgod­no­ści, popraw­ki wyni­ka­ją­ce z uspój­nia­nia pra­cy róż­nych autorów”.

Urealnienie tych wyli­czeń (choć­by staw­ki ana­li­ty­ków) wywin­du­je ten budżet na kwo­tę znacz­nie ponad milion zło­tych! Na to sobie mało kto sobie pozwo­li. W więk­szo­ści przy­pad­ków nie jest robio­na tak dłu­go trwa­ją­ca ana­li­za i za nie takie pie­nią­dze. Zaryzykuje tezę, że – obser­wu­jąc sta­ty­sty­ki pro­jek­tów IT – nie ma to, takie podej­ście, żad­ne­go sen­su. Tak więc tak opra­co­wa­ne spe­cy­fi­ka­cje, są jed­nak uprasz­cza­ne z uwa­gi na kosz­ty, są z zasa­dy niekompletne!

Teraz przy­szła pora na moje­go ser­decz­ne­go przy­ja­cie­la, któ­ry zjadł zęby na kor­po­ra­cyj­nym ryn­ku IT (wyba­czy­cie mi Państwo, że dane jego zacho­wam dla sie­bie). Oto co mi nie­daw­no powie­dział pod­czas podob­nej dyskusji:

Nawet przy kup­nie kon­kret­nej kieł­ba­sy kry­te­riów wybo­ru skle­pu może być wie­le i zakła­da­my, że ktoś ma czas/pieniądze aby je wszyt­kie zasto­so­wać, by pod­jąć decy­zję. Przy kup­nie samo­cho­du czy komór­ki ilość funk­cji, któ­re trze­ba porów­nać jest tak duża, że porów­ny­wa­nie to już spo­ra pra­ca. Nie zawsze ma się zaso­by, aby ją wyko­nać. Nabywca z dobrym dzia­łem zaku­pów ma sche­ma­ty oce­ny wie­lo­kry­te­rial­nej skom­pli­ko­wa­nych towa­rów i usług, Ale kto poświę­ci 2 godzi­ny na decy­zję, jaki kupić sobie dłu­go­pis? Pewnie nikt, ale na pod­ję­cie decy­zji kup­na komór­ki 2 godzi­ny to sta­now­czo za mało, choć błęd­na decy­zja jest kosz­tow­na lub wią­że nas na 2 lata z mode­lem, któ­ry nie speł­nia oczekiwań.

Producenci róż­nych rze­czy zda­ją sobie spra­wę, że kosz­ty pod­ję­cia wła­ści­wej decy­zji przy skom­pli­ko­wa­nych pro­duk­tach są spo­re i ludzie będą podej­mo­wać decy­zje błęd­ne, to pozwa­la dzia­łać na ryn­ku fir­mom, któ­re w prze­ciw­nym wypad­ku by upadły.

I jak teraz wyglą­da­ją w Państwa oczach zaku­py i wdro­że­nia dużych goto­wych sys­te­mów? Czy to zna­czy, że kup­no goto­we­go sys­te­mu nigdy nie ma sen­su? Ależ ma ale…

Gotowe opro­gra­mo­wa­nie jest adre­so­wa­ne z zasa­dy do wie­lu róż­nych odbio­rów, ska­za­ne jest więc na znacz­ny nad­miar funk­cjo­nal­no­ści na zapas” (popa­trz­my z jakiej czę­ści cech tele­fo­nów czy pakie­tów biu­ro­wych korzy­sta­my). Skoro więc potrze­bu­je­my cze­goś co ma 100 potrzeb­nych nam cech a wybie­ra­my coś goto­we­go na ryn­ku co ma ich 1000, ale zawie­ra te potrzeb­nych nam 100, to sama nasu­wa się teza, że powy­żej pew­ne­go pro­gu uni­wer­sal­ne roz­wią­za­nie kosz­tu­je wię­cej (uwzględ­nia­jąc kosz­ty decy­zji) niż korzy­ści z cech wyma­ga­nych i zapew­ne nie raz war­to wyko­nać coś pod nasze potrze­by”. I tu poja­wia się haczyk: nale­ży te potrze­by bar­dzo dobrze – z mini­mal­nym ryzy­kiem – opi­sać. Bo wszy­scy wie­my jak się koń­czą pro­jek­ty pro­gra­mi­stycz­ne, w któ­rych klient nie wie cze­go chce”.

Jak to robić lepiej? Po pierw­sze nie kupo­wać dużych i dro­gich zin­te­gro­wa­nych sys­te­mów” bo to duże ryzy­ko, kupo­wać mniej­sze, łatwiej­sze do opi­sa­nia, pro­jek­to­wać i two­rzyć te, któ­re są zbyt dużym ryzy­kiem w przy­pad­ku złe­go wybo­ru. Jeżeli już z powo­du ryzy­ka mamy poświę­cić duży budżet na kosz­tow­ne spe­cy­fi­ko­wa­nie opro­gra­mo­wa­nia to sygnał, że nale­ży je za te pie­nią­dze po pro­stu zapro­jek­to­wać i wykonać.

Niestety nie ma pro­stej odpo­wie­dzi na pyta­nie jak to robić dobrze”. Chyba, że będzie to pro­po­zy­cja nastę­pu­ją­ce­go procesu:

  1. ana­li­za biznesowa,
  2. zde­fi­nio­wa­nie celu,
  3. zapro­jek­to­wa­nie archi­tek­tu­ry sys­te­mu (to jako sys­tem nale­ży rozu­mieć orga­ni­za­cję wraz z wspie­ra­ją­ca ją infor­ma­ty­ką), tu zmie­rza­my w kie­run­ku tak zwa­nej [[archi­tek­tu­ry korporacyjnej]],
  4. ziden­ty­fi­ko­wa­nie ocze­ki­wa­nych od opro­gra­mo­wa­nia usług (wyma­ga­nia), podzie­lić je na odręb­ne ale spój­ne obsza­ry dzie­dzi­no­we,
  5. dla każ­de­go obsza­ru dzie­dzi­no­we­go opra­co­wać wyma­ga­nia na oprogramowanie,
  6. wybrać roz­wią­za­nia.

Zwracam uwa­gę na drob­ny szcze­gół: wybo­ru pro­duk­tu i jego dostaw­cy doko­nu­je­my na koń­cu, nigdy na począt­ku! A kto i dla­cze­go nas prze­ko­nu­je, że nale­ży naj­pierw kupić a potem analizować?

(arty­kuł uka­zał się tak­że w ERP​-Viev​.pl)

Model biznesowy czyli po co mi te procesy przed wdrożeniem ERP czy CRM…

Zarówno lite­ra­tu­ra jak i sieć inter­net roją się od prób odpo­wie­dzi na pyta­nie: jak stwo­rzyć dobry model biz­ne­so­wy? Nie ma moim zda­niem jed­nej słusz­nej odpo­wie­dzi na to pyta­nie, a dowo­dem jest rynek i jego sta­le powsta­ją­ce i upa­da­ją­ce fir­my. Jest jed­nak odpo­wiedź na inne pyta­nie: z cze­go skła­da się model biz­ne­so­wy (czy dobry to inna spra­wa ;)). Ten, któ­ry tu opi­sze wyda­je się być pomoc­ny. Korzystam z nie­go, gdyż wyma­ga zwró­ce­nia uwa­gę na kore­la­cję war­to­ści doda­nej z uza­sad­nie­niem jej jako war­to­ści ryn­ko­wej. Wartości doda­na i ryn­ko­wa, nie są moim zda­niem toż­sa­me, gdyż moż­na np. dodać war­tość do przed­mio­tu nie pod­no­sząc jego war­to­ści ryn­ko­wej. Np. pod­nie­sie­nie jako­ści i wytrzy­ma­ło­ści san­da­łów nadal nie czy­ni z nich war­to­ścio­we­go pro­duk­tu w Antarktyce.

Model biz­ne­so­wy czym jest? Najprostsza defi­ni­cja poję­cia model to uprosz­cze­nie rze­czy­wi­sto­ści”. Po co go robi­my? W biz­ne­sie są (muszą być) podej­mo­wa­ne decy­zje, jest to isto­ta zarzą­dza­nia. Podstawowym poję­ciem w ana­li­zie sys­te­mo­wej jest zaś:

Problem decy­zyj­ny: jest to sytu­acja, w któ­rej moż­li­we są co naj­mniej dwa warian­ty roz­wią­za­nia (postę­po­wa­nia), pro­wa­dzą­ce do róż­nych, nie­zna­nych wyników.

Klasyczny sche­mat postę­po­wa­nia w ana­li­zie sys­te­mo­wej był w moim blo­gu nie raz opi­sa­ny. Tu zazna­czę jedy­nie, że model to sed­no pro­ce­su ana­li­zy sys­te­mo­wej. To model jest opi­sem ana­li­zo­wa­ne­go zja­wi­ska, repre­zen­tu­je zależ­no­ści w nim funk­cjo­nu­ją­ce i pozwa­la (jeże­li jest popraw­ny) z dużym praw­do­po­do­bień­stwem prze­wi­dy­wać skut­ki pla­no­wa­nych decyzji.

Makrootoczenie po kolei

Ten roz­dział moż­na pomi­nąć jak komuś niepotrzebny 🙂

Łańcuch wartości

M.E.Porter jest auto­rem tak zwa­nej teo­rii łań­cu­cha war­to­ści ryn­ko­wej. Mówi ona, w pew­nym uprosz­cze­niu, że środ­ki prze­pły­wa­ją na ryn­ku w kie­run­ku odwrot­nym do kie­run­ku prze­pły­wu ryn­ko­wej war­to­ści doda­nej. Innymi sło­wy nabyw­ca pła­ci dostaw­cy za korzy­ści jakie przy­no­si mu dostar­czo­ny mu pro­dukt (w tym tak­że usłu­ga). Seria pod­mio­tów na ryn­ku, sta­no­wią­ca łań­cuch dys­try­bu­cji dóbr sta­no­wi ryn­ko­wy łań­cuch war­to­ści. Kluczem jest tu zwią­zek war­to­ści jaką pozy­sku­je kupu­ją­cy, kupu­jąc pro­dukt i ceny jaką jest gotów za nie­go zapła­cić. Stąd tak­że pocho­dzi poję­cie ceny ryn­ko­wej, któ­ra nie wyni­ka z kosz­tów wytwo­rze­nia pro­duk­tu a z korzy­ści jakie postrze­ga kupu­ją­cy, skon­fron­to­wa­nej z dostęp­ny­mi pro­duk­ta­mi kon­ku­ren­cyj­ny­mi lub sub­sty­tu­ta­mi. Tu nale­ży zazna­czyć, że kana­ły dys­try­bu­cji, jako usłu­ga, tak­że wno­szą war­tość doda­ną: udo­stęp­nia­ją pro­dukt w miej­scu jego ofe­ro­wa­nia (sprze­da­ży, zakupu).

Kolejne waż­ne poję­cie to mar­ża, któ­ra wska­zu­je na zysk w posta­ci róż­ni­cy pomię­dzy kosz­tem wytwo­rze­nia pro­dukt a ceną uzy­ska­ną z jego sprze­da­ży. Tu nale­ży zwró­cić uwa­gę na kil­ka waż­nych elementów.

Wartość pro­duk­tu dla kupu­ją­ce­go doty­czy miej­sca w jakim naby­wa on pro­dukt (mało mnie inte­re­su­je ile kosz­tu­je cukier w cukrow­ni, inte­re­su­je mnie cena cukru w moim osie­dlo­wym skle­pie, w któ­rym bywam). Tak więc mamy kolej­ne waż­ne poje­cie: kanał dys­try­bu­cji. Jeżeli kanał dys­try­bu­cji nie nale­ży do nas, bez­po­śred­nim naszym klien­tem jest posia­dacz (ope­ra­tor) tego kana­łu. Analogicznie nale­ży patrzeć na kanał zaopatrzenia.

Konkurencyjność

Kolejne waż­ne poję­cie to tak zwa­ny model pię­ciu sił Portera (tego same­go ;)). Model ten opi­su­je siłę kon­ku­ren­cji oraz czte­ry czyn­ni­ki (siły) mają­ce na nią wpływ: siła dostaw­cy, siła nabyw­cy, siła wpły­wu pro­duk­tów kon­ku­ren­cyj­nych i siła wpły­wu sub­sty­tu­tów. Graficznie ten model wyglą­da tak:

Siła wpły­wu dostaw­cy zale­ży od kon­ku­ren­cji mię­dzy dostaw­ca­mi, im więk­sza tym jego siła mniej­sza (mamy duży wybór). Analogicznie siła wpły­wu nabyw­cy: przy dużym popy­cie siła nabyw­ców (wpływ na nas) jest mała (np. ich pozy­cja nego­cja­cyj­na). Siła wpły­wu pro­duk­tów kon­ku­ren­cyj­nych to oczy­wi­sty wpływ: im wię­cej pro­duk­tów takich samych” tym więk­sza pre­sja na nasze ceny i jakość. Analogiczny wpływ maja sub­sty­tu­ty. Tu zwró­cę uwa­gę na to czym jest sub­sty­tut: to pro­dukt inny niż kon­ku­ren­cji ale mają­cy tę samą war­tość dla nabyw­cy np. usłu­ga sprzą­ta­nia kon­ku­ru­je z zaku­pem odku­rza­cza na wła­sność albo szczo­tecz­ka do zębów z pły­nem do płu­ka­nia ust.

Tyle z pod­staw ana­li­zy ryn­ku i makro­oto­cze­nia. Po co to wszystko?

Cel projektu i model biznesowy jako narzędzie analizy biznesowej

Projekt IT, wdro­że­nie nowe­go opro­gra­mo­wa­nia, zapro­jek­to­wa­nie roz­wią­za­nia… po co? Nowy sys­tem np. ERP lub CRM to narzę­dzie pra­cy. Po co w nie inwe­sto­wać? Chcemy coś popra­wić? Co? Często sły­szę uza­sad­nie­nia zaczy­na­ją­ce się od popra­wa…” cze­go? Po kolei.

Na pyta­nie: na czym Pan zara­bia, łatwo odpo­wie­dzieć, to sprze­da­wa­ny pro­dukt. Zaczynają się scho­dy jak pada pyta­nie: Dlaczego Pan zara­bia? Do cze­go zmierzam?

Jeżeli ktoś chce coś w fir­mie popra­wiać, naj­pierw powi­nien zro­zu­mieć jak dzia­ła to coś w fir­mie. Bez tego inge­ren­cja w fir­mę jest po pro­tu nie­prze­wi­dy­wal­na. Teza, że innym pomo­gło” przy­po­mi­na raczej sło­wa zaka­ta­rzo­ne­go: weź aspi­ry­nę, mi pomo­gło” skie­ro­wa­ne do kasz­lą­ce­go gruźlika.

Tak. Model biz­ne­so­wy i ana­li­za sys­te­mo­wa to narzę­dzia pozwa­la­ją­ce zacząć w prze­my­śla­ny spo­sób inwe­sto­wać w opro­gra­mo­wa­nie. To ana­li­za, któ­rą war­to wyko­nać na samym począt­ku, co pozwo­li wska­zać cel pro­jek­tu, zro­zu­mieć wpływ opro­gra­mo­wa­nia na fir­mę oraz oce­nić real­ność osią­gnię­cia celu projektu.

Model biznesowy

Znając takie poję­cia jak łań­cuch war­to­ści i kon­ku­ren­cja może­my pod­jąć pró­bę zna­le­zie­nia, nazwa­nia i roz­wią­za­nia problemu.

Spotykam się z wie­lo­ma opi­sa­mi tego co to jest model biz­ne­so­wy ale jestem zwo­len­ni­kiem defi­ni­cji rodem z mar­ke­tin­gu i ksią­żek mię­dzy inny­mi M.E.Portera: model biz­ne­so­wy jest opi­sem pro­wa­dze­nia dzia­łal­no­ści gospo­dar­czej, dzię­ki któ­rej przed­się­bior­stwo przy­no­si zyski. Zasadniczym ele­men­tem mode­lu biz­ne­so­we­go jest wska­za­nie roli pod­mio­tu w łań­cu­chu war­to­ści, w któ­rym uczest­ni­czy. Model biz­ne­so­wy okre­śla kto, co, komu, jakim kosz­tem i za jaką cenę, dostar­cza. Model biz­ne­so­wy dostar­cza więc opi­su powsta­wa­nia war­to­ści doda­nej i zysku w firmie.

W kon­tek­ście ana­li­tycz­nym jest to model sys­te­mu zawie­ra­ją­cy jeden obiekt cen­tral­ny jakim jest ana­li­zo­wa­ny pod­miot (tu powsta­je war­tość doda­na”) oraz obiek­ty oddzia­ły­wa­ją­ce, będą­ce dostaw­ca­mi, odbior­ca­mi, źró­dła­mi ogra­ni­czeń. Na bazie powyż­sze­go opi­su moż­na stwo­rzyć nastę­pu­ją­cy ogól­ny model słu­żą­cy do ana­li­zy systemowej:

Powyższy dia­gram to model obra­zu­ją­cy łań­cuch war­to­ści i wpływ kon­ku­ren­cji na ana­li­zo­wa­ną fir­mę, a kon­kret­nie na war­tość doda­ną” jaką ofe­ru­je na ryn­ku. Kluczowe pyta­nie, Dlaczego zara­biasz”, wyma­ga zro­zu­mie­nia dla­cze­go nasz Odbiorca (Klient) nie zaopa­tru­je się bez­po­śred­nio u nasze­go dostaw­cy (zie­lo­na linia prze­ry­wa­na), co takie­go wno­si nasza fir­ma, że war­to przyjść do nas za to zapła­cić. Ważnym ele­men­tem są kana­ły zaopa­trze­nia i dys­try­bu­cji. Wskazują one kim są na praw­dę klien­ci i dostawcy.

Przykładowe cele wdrożenia:

  1. Zwiększenie sprze­da­ży (obro­tów) poprzez…
  2. Obniżenie kosz­tów. Buduje dodat­ko­we zyski przy zacho­wa­nej cenie sprze­da­ży i wie­lo­ści sprzedaży.
  3. Ratowanie przy­cho­dów. Odpowiedź na naci­ski konkurencji.

Wartość obro­tów moż­na zwięk­szyć albo poprzez prze­ję­cie klien­tów kon­ku­ren­cji albo przez stwo­rze­nie nowych potrzeb na ryn­ku i zaspo­ko­je­nie ich, to raczej mate­riał na prze­ję­cia lub inno­wa­cje. Wartość zysków zwięk­sza sie obni­ża­jąc kosz­ty. O rato­wa­niu nie­co dalej…

Wdrożenie nowe­go opro­gra­mo­wa­nia, jeże­li ma mieć sens, powin­no więc wspie­rać two­rze­nie dodat­ko­we­go zysku lub przy­cho­du, w prze­ciw­nym wypad­ku w zasa­dzie nie ma sensu.

Dodatkowy zysk, to efekt obni­ża­nia kosz­tów. Ratowanie posia­da­ne­go ryn­ku, to efekt reak­cji na siły ryn­ku: siły dostaw­cy (np. jego sys­tem EDI wymu­sza inwe­sty­cje u nas), siły odbior­cy (ocze­ku­je obsłu­gi podob­nej do tej, jaką ofe­ru­je kon­ku­ren­cja), siły kon­ku­ren­cji (ich pro­duk­ty i usłu­gi są wyż­szej jako­ści, musi­my też zainwestować).

Powyższy model obra­zu­je to co ma wpływ na to Dlaczego zara­bia­my. Zbudowanie takie­go mode­lu dla kon­kret­nej fir­my, zro­zu­mie­nie Dlaczego zara­bia, pozwa­la szu­kać spo­so­bu i miejsc mogą­cych przy­czy­nić się do reali­za­cji celu pro­jek­tu, jed­nak cel ten nale­ży wcze­śniej Nazwać. Drugi krok to oce­na moż­li­wo­ści reali­za­cji i pro­gno­zo­wa­nie skut­ków, by okre­ślić cel: mia­rę i wiel­kość tego co chce­my osią­gnąć by wie­dzieć czy się udało.

Podsumowanie

Model biz­ne­so­wy moim zda­niem nie odno­si się do pro­ce­sów biz­ne­so­wych, to pro­ce­sy biz­ne­so­we są kon­se­kwen­cją mode­lu biz­ne­so­we­go. Dlaczego? Bo jeśli przyj­mie­my, że model biz­ne­so­wy obra­zu­je (doku­men­tu­je) źró­dła zysku fir­my w łań­cu­chu war­to­ści na ryn­ku, to pro­ce­sy biz­ne­so­we są opi­sem tego, w jaki spo­sób ta war­tość wewnątrz fir­my powsta­je. To pozwa­la dopie­ro wska­zać jakie dzia­ła­nia (pro­ce­sy) wes­przeć i jak, by ulep­szyć” fir­mę. Dlatego brak mode­lu biz­ne­so­we­go jest poważ­nym utrud­nie­niem ana­li­zy wyma­gań… bo cze­go wyma­gać od opro­gra­mo­wa­nia sko­ro nie wie­my co i jak pomo­że w zarzą­dza­niu firmą?

Na tym eta­pie Analityk Biznesowy może dać mene­dże­rom dobry model biz­ne­so­wy symu­lu­ją­cy mode­lo­wa­ną orga­ni­za­cję, pod­sta­wę do podej­mo­wa­nia decy­zji orga­ni­za­cyj­nych. (Czym jest Piąty ele­ment ? Audyt orga­ni­za­cji czy­li ana­li­za biz­ne­so­wa).

Jeden z moich klien­tów kie­dyś powie­dział: Nie mam poję­cia co chcie­li osią­gnąć poprzed­ni dostaw­cy sys­te­mu ERP sko­ro nie zain­te­re­so­wa­li się moim mode­lem biz­ne­so­wym, inte­re­so­wał ich wyłącz­nie budżet projektu…”…

Na koniec o roli biz­nes pla­nu, przy­kład wdro­że­nia ser­wi­su infor­ma­cyj­ne­go… na popra­wę humoru:

Plany na 2012 rok – do kogo uderzać…

GUS w dru­giej poło­wie roku 2011 opu­bli­ko­wał dane za lata 2009/2010 doty­czą­ce wyko­rzy­sta­nia sys­te­mów ERP i CRM:

Za kla­sy­fi­ka­cją GUS, przyj­mu­je­my: duże fir­my to te któ­re zatrud­nia­ją powy­żej 250 osób, śred­nie 50 – 249, małe 9 – 49 i mikro ? do 9 osób. Na począ­tek jesz­cze kil­ka dodat­ko­wych danych analitycznych:

Nakłady inwe­sty­cyj­ne to dome­na więk­szych firm. Przykładowo fir­my duże odpo­wia­da­ją za ok. 53% nakła­dów inwe­sty­cyj­nych. Razem z fir­ma­mi śred­ni­mi wiel­kość ta rośnie do 75%. Firmy mikro odpo­wia­da­ją za 13% nakła­dów z war­to­ści ogó­łem. Absolutnie nie moż­na tego oce­niać nega­tyw­nie. Relacje typu: inwe­sty­cje do przy­cho­dów, za 1 zatrud­nio­ne­go itd. nie są w tym przy­pad­ku mia­ro­daj­ne. Przede wszyst­kim dla­te­go, że znacz­na część firm mikro zwią­za­na jest z usłu­ga­mi czy wybra­ną dzia­łal­no­ścią pro­duk­cyj­ną, któ­re nie wyma­ga­ją pono­sze­nia dużych nakła­dów inwestycyjnych.

Ostatnim para­me­trem jaki chcia­łem poru­szyć jest war­tość doda­na. Udział poszcze­gól­nych grup przed­się­biorstw w war­to­ści ogó­łem w latach 2003 – 2008 nie ule­gał poważ­niej­szym waha­niom. Trudno też doszu­kać się tren­dów dla poszcze­gól­nych grup. W struk­tu­rze podzia­łu, na pierw­szym miej­scu są fir­my duże w udzia­łem 44%. Na dru­gim są fir­my mikro ? 28%. Dalej firm śred­nie z udzia­łem 18% i małe z udzia­łem 10%. Rezultat wyglą­da ina­czej jeże­li porów­na­my war­tość doda­ną w prze­li­cze­niu na oso­by pra­cu­ją­ce. W przy­pad­ku firm małych, śred­nich i dużych, war­tość doda­na na pra­cu­ją­ce­go to od 1,2 do 1,5 (fir­my duże) krot­no­ści śred­niej. Firmy mikro 0,8 śred­niej. (źr. Opinie eko­no­micz­ne.)

W sys­te­my ERP (zarzą­dza­nie zaso­ba­mi) inwe­stu­ją fir­my pro­por­cjo­nal­nie do ich wiel­ko­ści. Wydaje się to oczy­wi­ste, im więk­sze zaso­by tym więk­szym wyzwa­niem jest zarzą­dza­nie nimi. Ciekawsze dane daje sta­ty­sty­ka dla sys­te­mów (funk­cjo­nal­no­ści) CRM (zarzą­dza­nie rela­cja­mi z klien­ta­mi). Zbieranie infor­ma­cja i współ­dzie­le­nie jej to głów­na potrze­ba, kró­lu­je więc tak zwa­ny sys­tem typu kon­takt menedżer”.

Nieco ambit­niej­sze funk­cjo­nal­no­ści (ele­men­ty mar­ke­tin­gu i pro­mo­cji) wyko­rzy­stu­je 80% posia­da­czy sys­te­mów CRM. Co cie­ka­we wiel­kość fir­my nie ma tu zna­cze­nia. Wniosek? Prawdopodobnie to cecha ludzi zarzą­dza­ją­cy­mi tymi fir­ma­mi a nie wiel­ko­ści fir­my decy­du­je o stra­te­gii IT. Druga cie­ka­wost­ka to odsta­wa­nie w dół firm z bran­ży budow­nic­twa oraz zakwa­te­ro­wa­nia i wyży­wie­nia od resz­ty” (ponad dwu­krot­nie mniej firm w rela­cji do śred­niej, wyko­rzy­stu­je te narzę­dzia pra­cy). Moim zda­niem jest tak dla­te­go, że w tej bran­ży więk­szość firm (głów­nie tych mniej­szych) to pod­wy­ko­naw­cy reali­zu­ją­cy cudze pro­jek­ty, im CRM jest mało potrzeb­ny bo nie pozy­sku­ją klien­tów bezpośrednio.

Największy udział mają fir­my z bran­ży IT i tele­ko­mu­ni­ka­cji, no cóż tu przy­sło­wie szewc bez butów cho­dzi” abso­lut­nie się tu nie sprawdza :).

Wydaje mi się, że rynek na sys­te­my ERP/CRM rośnie, jed­nak z mody na taki sys­tem (tu chy­ba fak­tycz­nie moż­na mówić o nasy­ce­niu) prze­cho­dzi w oce­nę real­nych potrzeb i biz­ne­so­wej opła­cal­no­ści (nadal mniej niż 80% ma taki sys­tem). Co maja pozo­sta­łe sko­ro wie­my, że coś mają?”. Z moich doświad­czeń wyni­ka, ze mają jakiś sys­tem FK/magazyny/sprzedaż” oraz bazy ad-hoc (np. Excel) lub po pro­tu dużo ręcz­nej pra­cy. Czemu nie inwe­stu­ją w ERP? Nie widzą powo­du by wydać tak duże pie­nią­dze choć czu­ją, że dalej tak nie pociągną.

Jeżeli wie­rzyć innym bada­niem, mówią­cym, że w fir­mach dużych jest nasy­ce­nie, nale­ży się sku­pić na fir­mach śred­nich i małych. Patrząc na wyni­ki oce­ny two­rzo­nej war­to­ści doda­nej w każ­dej gru­pie (na pierw­szym miej­scu są fir­my duże w udzia­łem 44%. Na dru­gim są fir­my mikro ? 28%) oraz moim nie­daw­nym wyli­cze­niem, że roz­bu­do­wa­ny sys­tem tego typu na wła­sność to inwe­sty­cja rzę­du mini­mum 75 tys. zł, moim zda­niem moż­na raczej mówić, że inwe­sty­cje poczy­nią fir­my śred­nie. A mikro? Tworzą dużą war­tość doda­ną więc maja docho­dy, nie mają jed­nak moż­li­wo­ści zain­we­sto­wa­nia aż 75 tys. zł. Co pozo­sta­ło? Dzierżawa czy­li SaaS. Prawdopodobnie jest to duży rynek (mikro fir­my) dla usług dzier­ża­wy opro­gra­mo­wa­nia o typo­wej wie­lo­ści kon­trak­tu 5 użytkowników/10GB danych. Te wiel­ko­ści to coraz popu­lar­niej­sze w USA ofer­ty hostingowe/SaaS o wdzięcz­nej nazwie Lite.

Co do innych wnio­sków pozo­sta­wiam Państwu zaba­wę z przy­to­czo­ny­mi dany­mi. No i prze­pra­szam, że ta tabel­ka tak dłu­go cze­ka­ła na swo­ja kolej w moim blogu.… 😉