Pierwsze zastosowania aplikacji wspierających biznes pojawiły się już latach 60. Tworzone w pracochłonnych środowiskach programistycznych wspierały wąskie obszary aktywności przedsiębiorstwa. Postęp środowisk programistycznych oraz atrakcyjniejsze modele baz danych spowodowały coraz szersze zastosowania aplikacji biznesowych. Okres do połowy lat 80 to czas budowy systemów ewidencyjno – transakcyjnych, bez większych pretensji co architektury i rozwiązań metodologicznych.
Jednocześnie w powszechnej świadomości pojawia się standard MRP dotyczący bilansowania zasobów materiałowych. W tym czasie w ośrodkach akademickich oraz stowarzyszeniach stawiających sobie za cel propagowanie wykorzystania informatyki do celów biznesowych, rodzą się formalne zaawansowane wymagania względem oprogramowania wspierającego przedsiębiorstwa. Rok 1989 - jako moment publikacji przez organizację APICS (American Production and Inventory Control Society) formalnych wymagań względem systemu MRP II - jest datą cezurą dla kategoryzacji systemów wspierających biznes.
Choć już w latach 70- tych w przedsiębiorstwach znajdowały zastosowanie systemy wspierające sferę produkcyjną i logistyczną, to dzięki publikacji APICS-u stworzono standard, do którego mógł się odwoływać menadżer zarządzający firmą. Uważna lektura postulatów APICS-u nie pozostawia wątpliwości, że główny kierunek poszukiwań to produkcja i logistyka. Stowarzyszenie sformułowało 16 postulatów, które identyfikują istotę głównych problemów przy pojmowaniu przedsiębiorstwa. Postulaty dotyczyły: planowania produkcji i sprzedaży, zarządzania popytem, harmonogramowania produkcji, planowania potrzeb materiałowych, zarządzania strukturami materiałowych, gospodarki magazynowej, sterowania zleceniami produkcyjnym, sterowania produkcją, planowania i bilansowania zdolności produkcyjnych, kontroli i ewidencji zakupów, symulacji i pomiarów wyników.
Merytorycznie rzecz ujmując standard MRPII był krokiem rewolucyjnym względem klasy MRP porównywalnym z wynalezieniem maszyny parowej w XIX wieku. Aby spełnić postulaty zawarte w opublikowanym standardzie dostawcy informatyki musieli pojmować przedsiębiorstwo przez pryzmat procesów biznesowych. Pomiędzy poszczególnymi modułami, interfejsami pojawia się coraz więcej węzłów integralnościowych, tak, aby jak najwierniej oddać procesy biznesowe zachodzące w organizacjach. W latach 90-tych w publikacjach pojawia się następny standard : ERP. Kategoria ERP jest ewolucyjnym dopełnieniem MRPII – postuluje totalne bilansowanie wszystkich zasobów przedsiębiorstwa ze szczególnym uwzględnieniem środków finansowych.
To co działo się z zakresem funkcjonalnym oprogramowania wspomagającego przedsiębiorstwo nie byłoby możliwe bez równoczesnego rozwoju innych aspektów składających się na rozwiązanie informatyczne. Bezprecedensowej ewolucji podlegały bowiem: bazy danych, środowiska programistyczne, systemy operacyjne, warstwy rozwiązań sieciowych, Internet, metodyki zarządzania złożonym i rozległym projektem, metodyki zarządzania przedsiębiorstwem, sprzęt. Najlepsze rozwiązania proceduralne nie pozwoliłyby na rozwój funkcjonalny oprogramowania, jeżeli nie mielibyśmy szybkich i efektywnych baz danych. Rozwiązania biznesowe wsparła architektura relacyjnych baz danych, choć na użytek rozwiązań specjalizowanych (np. hurtownie danych) pojawiły się architektury zmodyfikowane, lepiej służące określonemu wąskiemu celowi. Atrakcyjny okazał się model klient – serwer oraz rozwiązania SQL, które skutecznie wypierają inne standardy. W przedsiębiorstwie zaczęto dostrzegać procesy, których skuteczne wsparcie informatyką wymagało modułów kodowanych poprzez setki tysiące linii kodów źródłowych. Lekarstwem okazały się nowe techniki programowania: programowanie obiektowe oraz środowiska generowania kodu, zwane środowiskiem programistycznym czwartej generacji. Prawdziwą rewolucją było wprowadzenie interfejsu graficznego oraz ujednolicenie systemów operacyjnych. Dzięki klarownym standardom i otwartym interfejsom pomiędzy bibliotekami oraz modułami, zaczął w systemach zintegrowanych działać efekt kumulacji Rozwój technologii sieciowych oraz Internetu spowodował, że zaczęto pojmować rozwiązania wdrażane w przedsiębiorstwach w kontekście procesu ‘globalnego’. Co więcej, aby skutecznie wymieniać informacje pomiędzy uczestnikami ‘globalnego procesu’ musiały się pojawiać nowe standardy wymiany informacji, stąd pojawienie się protokołów EDI, XML, czy też XBRL.
Cały czas na najwyższych obrotach pracuje przemysł dostarczający warstwę sprzętową. Nowe, zaawansowane rozwiązania generują popyt na serwery o coraz większej mocy obliczeniowej, zaś zakres stosowania informatyki powoduje, że rozwiązania mające na celu bezpieczeństwo danych są na wagę złota. To dzięki rozwiązaniom klastrowym wielu menadżerów odpowiedzialnych za informatykę, może spokojniej myśleć o bezpieczeństwie procesów wspomaganych przez oprogramowanie.
W latach 90- tych pojawiły się publikacje traktujące o ryzyku związanym z udanym wdrożeniem systemu ERP. Im system bardziej skomplikowany, tym wymagania względem organizacji są większe, co oczywiście pociąga za sobą większe ryzyko porażki. W niektórych publikacjach prawdopodobieństwo porażki było wyceniane na poziomie przekraczającym 50 % ! Stąd zapotrzebowanie na atrakcyjne metodyki zarządzania rozległym projektem, z powodzeniem zaspakajane przez ośrodki akademickie oraz dostawców rozwiązań.
Po roku 2000 z coraz większym natężeniem zaczął pojawiać się problem z kategoryzacją systemów zintegrowanych. Kryzys tożsamości klasyfikacji ERP rozpoczął się od momentu, gdy do jednego worka wrzucono programy ewidencyjne, których istota leży w rejestrowaniu faktów ex post i te systemy, które realizują wyrafinowane zadania bilansowania zasobów i obciążeń również ex ante (między innymi ERP). Kłopoty nomenklaturowe oraz brak dobrej jednoznacznej kategoryzacji złożoności funkcjonalnej, tudzież ‘rozwydrzenie’ marketingowe’ dostawców spowoduje – mam nadzieję – wprowadzenie nowych klasyfikacji i nowych kategorii, które pomogą w identyfikacji sensu i celu poszczególnych aplikacji.
Rozwój interfejsów komunikacyjnych oraz postępująca standaryzacja kategorii, pojęć w sferze merytorycznej oraz protokołów wymiany informacji w warstwie technologicznej będzie pchał w objęcia systemu ERP rozwiązania dziedzinowe. ERP niczym wielkie miasto będzie pochłaniało przylegające wsie, stając się metropolią, w której podział na dzielnice będzie coraz bardziej rozmazany. Mieszkaniec będzie zadawał sobie co najwyżej pytanie: w jaki tramwaj wsiąść by znaleźć się w określonej dzielnicy lub skorzystać z konkretnego dobrodziejstwa, jakie oferują wielkie metropolie…
Autor: Dariusz Grześkowiak, Graffiti.ERP Spółka Akcyjna
Źródło: www.graffiti-erp.pl
Choć już w latach 70- tych w przedsiębiorstwach znajdowały zastosowanie systemy wspierające sferę produkcyjną i logistyczną, to dzięki publikacji APICS-u stworzono standard, do którego mógł się odwoływać menadżer zarządzający firmą. Uważna lektura postulatów APICS-u nie pozostawia wątpliwości, że główny kierunek poszukiwań to produkcja i logistyka. Stowarzyszenie sformułowało 16 postulatów, które identyfikują istotę głównych problemów przy pojmowaniu przedsiębiorstwa. Postulaty dotyczyły: planowania produkcji i sprzedaży, zarządzania popytem, harmonogramowania produkcji, planowania potrzeb materiałowych, zarządzania strukturami materiałowych, gospodarki magazynowej, sterowania zleceniami produkcyjnym, sterowania produkcją, planowania i bilansowania zdolności produkcyjnych, kontroli i ewidencji zakupów, symulacji i pomiarów wyników.
Merytorycznie rzecz ujmując standard MRPII był krokiem rewolucyjnym względem klasy MRP porównywalnym z wynalezieniem maszyny parowej w XIX wieku. Aby spełnić postulaty zawarte w opublikowanym standardzie dostawcy informatyki musieli pojmować przedsiębiorstwo przez pryzmat procesów biznesowych. Pomiędzy poszczególnymi modułami, interfejsami pojawia się coraz więcej węzłów integralnościowych, tak, aby jak najwierniej oddać procesy biznesowe zachodzące w organizacjach. W latach 90-tych w publikacjach pojawia się następny standard : ERP. Kategoria ERP jest ewolucyjnym dopełnieniem MRPII – postuluje totalne bilansowanie wszystkich zasobów przedsiębiorstwa ze szczególnym uwzględnieniem środków finansowych.
To co działo się z zakresem funkcjonalnym oprogramowania wspomagającego przedsiębiorstwo nie byłoby możliwe bez równoczesnego rozwoju innych aspektów składających się na rozwiązanie informatyczne. Bezprecedensowej ewolucji podlegały bowiem: bazy danych, środowiska programistyczne, systemy operacyjne, warstwy rozwiązań sieciowych, Internet, metodyki zarządzania złożonym i rozległym projektem, metodyki zarządzania przedsiębiorstwem, sprzęt. Najlepsze rozwiązania proceduralne nie pozwoliłyby na rozwój funkcjonalny oprogramowania, jeżeli nie mielibyśmy szybkich i efektywnych baz danych. Rozwiązania biznesowe wsparła architektura relacyjnych baz danych, choć na użytek rozwiązań specjalizowanych (np. hurtownie danych) pojawiły się architektury zmodyfikowane, lepiej służące określonemu wąskiemu celowi. Atrakcyjny okazał się model klient – serwer oraz rozwiązania SQL, które skutecznie wypierają inne standardy. W przedsiębiorstwie zaczęto dostrzegać procesy, których skuteczne wsparcie informatyką wymagało modułów kodowanych poprzez setki tysiące linii kodów źródłowych. Lekarstwem okazały się nowe techniki programowania: programowanie obiektowe oraz środowiska generowania kodu, zwane środowiskiem programistycznym czwartej generacji. Prawdziwą rewolucją było wprowadzenie interfejsu graficznego oraz ujednolicenie systemów operacyjnych. Dzięki klarownym standardom i otwartym interfejsom pomiędzy bibliotekami oraz modułami, zaczął w systemach zintegrowanych działać efekt kumulacji Rozwój technologii sieciowych oraz Internetu spowodował, że zaczęto pojmować rozwiązania wdrażane w przedsiębiorstwach w kontekście procesu ‘globalnego’. Co więcej, aby skutecznie wymieniać informacje pomiędzy uczestnikami ‘globalnego procesu’ musiały się pojawiać nowe standardy wymiany informacji, stąd pojawienie się protokołów EDI, XML, czy też XBRL.
Cały czas na najwyższych obrotach pracuje przemysł dostarczający warstwę sprzętową. Nowe, zaawansowane rozwiązania generują popyt na serwery o coraz większej mocy obliczeniowej, zaś zakres stosowania informatyki powoduje, że rozwiązania mające na celu bezpieczeństwo danych są na wagę złota. To dzięki rozwiązaniom klastrowym wielu menadżerów odpowiedzialnych za informatykę, może spokojniej myśleć o bezpieczeństwie procesów wspomaganych przez oprogramowanie.
W latach 90- tych pojawiły się publikacje traktujące o ryzyku związanym z udanym wdrożeniem systemu ERP. Im system bardziej skomplikowany, tym wymagania względem organizacji są większe, co oczywiście pociąga za sobą większe ryzyko porażki. W niektórych publikacjach prawdopodobieństwo porażki było wyceniane na poziomie przekraczającym 50 % ! Stąd zapotrzebowanie na atrakcyjne metodyki zarządzania rozległym projektem, z powodzeniem zaspakajane przez ośrodki akademickie oraz dostawców rozwiązań.
Po roku 2000 z coraz większym natężeniem zaczął pojawiać się problem z kategoryzacją systemów zintegrowanych. Kryzys tożsamości klasyfikacji ERP rozpoczął się od momentu, gdy do jednego worka wrzucono programy ewidencyjne, których istota leży w rejestrowaniu faktów ex post i te systemy, które realizują wyrafinowane zadania bilansowania zasobów i obciążeń również ex ante (między innymi ERP). Kłopoty nomenklaturowe oraz brak dobrej jednoznacznej kategoryzacji złożoności funkcjonalnej, tudzież ‘rozwydrzenie’ marketingowe’ dostawców spowoduje – mam nadzieję – wprowadzenie nowych klasyfikacji i nowych kategorii, które pomogą w identyfikacji sensu i celu poszczególnych aplikacji.
Rozwój interfejsów komunikacyjnych oraz postępująca standaryzacja kategorii, pojęć w sferze merytorycznej oraz protokołów wymiany informacji w warstwie technologicznej będzie pchał w objęcia systemu ERP rozwiązania dziedzinowe. ERP niczym wielkie miasto będzie pochłaniało przylegające wsie, stając się metropolią, w której podział na dzielnice będzie coraz bardziej rozmazany. Mieszkaniec będzie zadawał sobie co najwyżej pytanie: w jaki tramwaj wsiąść by znaleźć się w określonej dzielnicy lub skorzystać z konkretnego dobrodziejstwa, jakie oferują wielkie metropolie…
Autor: Dariusz Grześkowiak, Graffiti.ERP Spółka Akcyjna
Źródło: www.graffiti-erp.pl