Cztery lata temu, na zakoń­cze­nie pew­nej pole­mi­ki, napisałem:

Takie podej­ście, dzie­dzi­no­we dzia­ły w fir­mach ? dzie­dzi­no­we pod­sys­te­my dla nich, w ogó­le umoż­li­wia spraw­ne dzia­ła­nie. Coraz powszech­niej­sze sta­je wydzie­la­nie pod­mio­tów zależ­nych lub ich wchła­nia­nie. Mając jeden wiel­ki System ERP nie­moż­li­we jest ?pro­ste? wydzie­le­nie zależ­nej spół­ki logi­stycz­nej czy obsłu­gi HR. Nie raz widy­wa­łem praw­ni­cze łama­nie gło­wy jako podzie­lić licen­cję ERP na kawał­ki w przy­pad­ku pącz­ko­wa­nia lub połą­czyć przy fuzji spół­ek. Praktyka poka­zu­je, że opro­gra­mo­wa­nie jest tym lep­sze im lepiej odwzo­ro­wu­je świat rze­czy­wi­sty orga­ni­za­cji i firm, a ten nie jest mono­li­tycz­ny. Po dru­gie sam fakt rosną­ce­go zna­cze­nia elek­tro­nicz­nej wymia­ny danych pomię­dzy fir­ma­mi powo­du­je, że już nic nie będzie jed­nym mono­li­tycz­nym sys­te­mem, a na inte­gra­cję jeste­śmy ska­za­ni. Czy ona jest zła? Nie, cie­szy­my się, że moż­na już kupić atra­ment czy toner inne­go pro­du­cen­ta do posia­da­nej dru­kar­ki, że moż­na użyć uni­wer­sal­nej łado­war­ki do tele­fo­nu komór­ko­we­go, ciesz­my się, że moż­na użyć np. inne­go HR niż ten od nasze­go ERP? (Źródło: RE: Duży ERP czy inte­gra­cja | | Jarosław Żeliński IT-Consulting).

Dzisiaj co nie­co o archi­tek­tu­rze biz­ne­so­wej i archi­tek­tu­rze IT sys­te­mów ERP.

Na począ­tek jed­nak coś z nie­daw­nej publi­ka­cji w COMPUTERWORLD (źr. COMPUTERWORLD Wrzesień 2016, Budowa apli­ka­cji z małą ilo­ścią kodu):

Oprogramowanie, któ­re nie two­rzy prze­wa­gi kon­ku­ren­cyj­nej, moż­na kupić. Aplikacje decy­du­ją­ce o satys­fak­cji klien­ta coraz czę­ściej daje się stwo­rzyć małym wysił­kiem, z goto­wych kloc­ków, doda­jąc tro­chę wła­snych pomy­słów i kodu. […]

Gartner prze­wi­du­je, że w 2020 r. 75% apli­ka­cji będzie two­rzo­nych, a nie kupo­wa­nych. Coraz wię­cej firm odcho­dzi od naby­wa­nia goto­wych roz­wią­zań, idąc w kie­run­ku two­rze­nia pro­gra­mów z wie­lu czę­ści skła­do­wych pocho­dzą­cych z róż­nych źró­deł. (źr. j.w.)

Na ryn­ku poja­wia się coraz wię­cej spe­cja­li­zo­wa­nych pod­sys­te­mów dzie­dzi­no­wych, głów­nym powo­dem jest potrze­ba dosto­so­wa­nia archi­tek­tu­ry IT nie tyl­ko do spe­cy­fi­ki fir­my ale tak­że do tak­ty­ki dzia­ła­nia i stra­te­gii. Prowadzi to do sytu­acji, w któ­rej wdra­ża­nie sys­te­mów mono­li­tycz­nych sta­je trud­ne, gdyż sys­te­my te cechu­je inte­gra­cja poprzez współ­dzie­le­nie danych (dzię­ki cze­mu modu­ły są roz­łącz­ne). Kolejnym ogra­ni­cze­niem jest opar­cie dzia­ła­nia ser­ca całe­go ERP na dowo­dach księ­go­wych (fak­tu­ry, doku­men­ty maga­zy­no­we) co powo­du­je, że moduł rachun­ko­wo­ści zawsze musi być wdro­żo­ny jako pierw­szy. To bar­dzo ogra­ni­cza moż­li­wość wpły­wu na kolej­ność wdra­ża­nia modu­łów. Praktyka poka­zu­je, że inte­gro­wa­nie nie­za­leż­nych pod­sys­te­mów na pozio­mie wymia­ny danych (każ­dy zawie­ra spe­cy­ficz­ną dla sie­bie logi­kę biz­ne­so­wą i inne struk­tu­ry infor­ma­cji) jest łatwiej­sze niż pró­by dosto­so­wy­wa­nia wie­lu modu­łów nie­współ­dzie­lo­nych te same dane zapi­sa­ne w jed­nym znor­ma­li­zo­wa­nym mode­lu. Wydzielanie dzie­dzi­no­wych, wła­snych dedy­ko­wa­nych pod­sys­te­mów, to tak­że jedy­ny spo­sób na ochro­nę wła­sne­go know-how.

Poniżej pod­ją­łem pró­bę upo­rząd­ko­wa­nia obec­ne­go sta­nu ofe­ro­wa­nych na ryn­ku aplikacji.

Model pojęciowy

Podstawowym narzę­dziem ana­li­zy biz­ne­so­wej jest two­rze­nie mode­li poję­cio­wych. Są to słow­ni­ki pojęć w for­mie gra­ficz­nej. Zdefiniowane w słow­ni­ku poję­cia na dia­gra­mach takich łączy się z pomo­cą rze­czy­wi­stych faktów.

Powyższy dia­gram to uprosz­czo­ny model poję­cio­wy fir­my (opr. wła­sne auto­ra, dia­gram fak­tów nota­cji SBVR). Analiza poję­cio­wa ma dwa pod­sta­wo­we cele: upo­rząd­ko­wa­nie pojęć i ich zna­czeń oraz wykry­cie i opra­co­wa­nie podzia­łu zakre­su dzia­ła­nia fir­my na spój­ne dzie­dzi­no­we obsza­ry. Powyższy dia­gram obra­zu­je przy­kła­do­wy pro­dukt takiej ana­li­zy. Jest on uprosz­czo­ny z uwa­gi na ogra­ni­czo­ną obję­tość tego arty­ku­łu, jed­nak poka­zu­je ogól­ną zasa­dę two­rze­nia takie­go mode­lu. Pojęcia w słow­ni­ku pojęć biz­ne­so­wych są odwzo­ro­wy­wa­ne na dia­gra­mie (pro­sto­kąt) i łączo­ne mie­dzy sobą klu­czo­wy­mi dla sie­bie fak­ta­mi (zda­rze­nia­mi). Na mode­lach takich poja­wia­ją się sku­pi­ska gęsto połą­czo­nych ze sobą pojęć, mię­dzy tymi sku­pi­ska­mi zaś licz­ba połą­czeń jest rela­tyw­nie mała. Na dia­gra­mie wyróż­nio­no typo­we obsza­ry w fir­mach (od lewej): Produkcja, Logistyka, Zarządzanie pro­duk­ta­mi, Rachunkowość, Obsługa kon­tak­tów z klien­ta­mi. Jest to oczy­wi­ście bar­dzo uprosz­czo­na wer­sja, ale poka­zu­je mecha­nizm pro­wa­dze­nia samej ana­li­zy poję­cio­wej. Pojęcia te to nazwy, któ­re opi­su­ją przed­mio­ty, dzia­ła­nia lub ich cechy. Są wyko­rzy­sty­wa­ne w tre­ści doku­men­tów np. nazwy pól for­mu­la­rzy, w ich tytu­łach itp.. Nie nale­ży jed­nak takich mode­li utoż­sa­miać z mode­la­mi danych bo nimi nie są. Ten etap ana­li­zy pozwa­la wychwy­cić ewen­tu­al­ne spe­cy­ficz­ne dla danej fir­my obsza­ry dzie­dzi­no­we a tak­że gra­ni­ce mię­dzy tymi obsza­ra­mi, któ­re nie muszą być typowe.

Analiza poję­cio­wa to prze­słan­ka do opra­co­wa­nia archi­tek­tu­ry kom­po­nen­tów IT. Założenie pod­sta­wo­we to uzna­nie, że każ­dy wewnętrz­nie sil­nie powią­za­ny obszar poję­cio­wy to ?kan­dy­dat? na spój­ny (i nie­po­dziel­ny) kom­po­nent zaś pro­ste i rzad­kie fak­ty mię­dzy tymi sku­pi­ska­mi kan­dy­du­ją na miej­sca podzia­łu na kom­po­nen­ty i wymia­ny infor­ma­cji (inter­fej­sy mię­dzy pod­sys­te­ma­mi lub apli­ka­cja­mi). Praktyka takich ana­liz poka­zu­je, że cza­sem ma sens a cza­sem jed­nak nie, umiesz­cza­nie np. fak­tu­ro­wa­nia w zakre­sie sys­te­mu CRM (obsłu­ga kon­tak­tów z klien­tem). Przykładów róż­no­rod­no­ści jest znacz­nie więcej.

Typowe podsystemy IT oferowane na rynku

W tej czę­ści krót­ko opi­sze­my stan­dar­do­we pod­sys­te­mu IT ofe­ro­wa­ne na ryn­ku. Definicje powsta­ły na pod­sta­wie ser­wi­su Encyklopedia Zarządzania mfi​les​.pl (opi­sa­ne w kolej­no­ści alfa­be­tycz­nej, patrz tak­żę: ).

APS Advanced Planning and Scheduling to sys­te­my, któ­re roz­wi­ja­ją jak dotych­czas przede wszyst­kim jako zakre­sy funk­cji reali­zo­wa­nych w obrę­bie MRP II. Systemy kla­sy APS zapew­nia­ją bowiem szyb­szą reak­cję całe­go łań­cu­cha dostaw na zmie­nia­ją­ce się potrze­by klien­tów lub w warun­kach poja­wia­nia się dodat­ko­wych, nie­spo­dzie­wa­nych zamó­wień. Innym atu­tem sys­te­mów tej kla­sy jest tak­że inte­gro­wa­nie pla­nów pro­duk­cyj­nych z pla­na­mi dys­try­bu­cyj­ny­mi (B. Tinham, 2000, s. 17). Jako natych­mia­sto­we korzy­ści z zasto­so­wa­nia akcen­to­wa­ne są lep­sza obsłu­ga klien­ta oraz reduk­cja pozio­mu zapasów.

Specjaliści wdra­ża­ją­cy sys­te­my kla­sy APS pod­kre­śla­ją, że zasto­so­wa­nie takie­go modu­łu nie sta­no­wi samo w sobie roz­wią­za­nia pro­ble­mu reago­wa­nia na nagłe zmia­ny wiel­ko­ści zapo­trze­bo­wa­nia na ofe­ro­wa­ne pro­duk­ty. W dal­szym cią­gu koniecz­ne jest bowiem per­ma­nent­ne moni­to­ro­wa­nie prze­bie­gu pro­ce­sów pro­duk­cyj­nych oraz reali­za­cji zadań w obrę­bie dzie­dzin wspomagających.

CAD (ang. Computer Aided Design) ? kom­pu­te­ro­wo wspo­ma­ga­ne pro­jek­to­wa­nie, któ­re ma zasto­so­wa­nie głów­nie w inży­nie­rii budow­la­nej, mecha­nicz­nej oraz elek­trycz­nej [P. Nowakowski. 2006, s. 11].

Do głów­nych zadań sys­te­mu CAD nale­ży odpo­wied­nie opra­co­wa­nie doku­men­ta­cji pro­jek­to­wej bazu­ją­cej na stwo­rzo­nym mode­lu trój­wy­mia­ro­wym oraz przy­go­to­wy­wa­niu odpo­wied­niej pre­zen­ta­cji two­rzo­ne­go obiek­tu w celu jego demon­stra­cji poten­cjal­nym odbior­com. [P. Nowakowski. 2006, s. 12]. Na pod­sta­wie tak opra­co­wa­nej doku­men­ta­cji pro­jek­to­wej, sys­tem CAD ma moż­li­wość bez­błęd­ne­go gene­ro­wa­nia deta­licz­nych list deta­li i pod­ze­spo­łów. Zarządzanie wer­sja­mi pro­jek­tów pozwa­la nad­zo­ro­wać, par­tie i uni­kal­ne wyko­na­nia produktów.

CRM to sys­tem infor­ma­tycz­ny umoż­li­wia­ją­cy imple­men­ta­cję stra­te­gii CRM (stra­te­gię zarzą­dza­nia kon­tak­ta­mi z kli­ne­ta­mi). Najczęściej sys­te­my tego typu mają budo­wę modu­ło­wą oraz sze­reg dostęp­nych funk­cji, a tak­że współ­pra­cę z inny­mi sys­te­ma­mi fir­my. Ewidencja klien­tów, gru­po­wa­nie kon­tak­tów z klien­tem, zarzą­dza­nie pro­jek­ta­mi i inne, umoż­li­wia­ją indy­wi­du­al­ne podej­ście do klien­ta, a tak­że wspo­ma­ga­ją dal­szą dobrą współ­pra­cę z klien­tem, nawet po odej­ściu pra­cow­ni­ka, któ­ry się nim zaj­mo­wał. System taki powi­nien współ­dzia­łać z pozo­sta­ły­mi sys­te­ma­mi w przed­się­bior­stwie. (E. Frąckiewicz, 2005, s. 56)

MES (źr. MESA International): ​„System MES (Manufacturing Execution System) ma na celu dostar­cze­nie infor­ma­cji, któ­ra pozwa­la na opty­ma­li­za­cję ope­ra­cji pro­duk­cyj­nych począw­szy od pro­ce­su zamó­wie­nia, aż do eta­pu dostar­cze­nia pro­duk­tów goto­wych.” Jest to sys­tem udo­stęp­nia­ją­cy infor­ma­cje o funk­cjo­no­wa­niu linii pro­duk­cyj­ne w cza­sie rze­czy­wi­stym, lub quasi-rzeczywistym.

MRPII (ang. Manufacturing Resource Planning, roz­wi­nię­ty sys­tem pla­no­wa­nia zaso­bów wytwór­czych przed­się­bior­stwa) został opra­co­wa­ny w 1989 r. przez Amerykańskie Stowarzyszenie Sterowania Produkcją i Zapasami (APICS). Jest kon­ty­nu­acją sys­te­mu MRP. Pozwala na pla­no­wa­nie zaso­bów pro­duk­cyj­nych, obej­mu­je ste­ro­wa­nie zaso­ba­mi i pro­duk­ta­mi przed­się­bior­stwa oraz zarzą­dza­nie dzia­łal­no­ścią fir­my tak­że w aspek­cie finan­so­wym, uzu­peł­nio­ne o modu­ły pla­no­wa­nia sprze­da­ży, zarzą­dza­nia kadra­mi, sta­no­wi­ska­mi robo­czy­mi, gotów­ką itp. Umożliwiają pla­no­wa­nie dzia­łal­no­ści przed­się­bior­stwa pro­duk­cyj­ne­go i dys­try­bu­cyj­ne­go (han­dlo­we­go) [Klonowski, 2004, s. 66 – 87].

PLM (źr. www​.con​tro​len​gi​ne​ering​.pl) to stra­te­gicz­ne podej­ście biz­ne­so­we, sto­su­ją­ce kon­se­kwent­ny zestaw roz­wią­zań do wspie­ra­nia wspól­ne­go two­rze­nia, zarzą­dza­nia, roz­po­wszech­nia­nia oraz sto­so­wa­nia fir­mo­wych defi­ni­cji doty­czą­cych pro­duk­tu i zakła­du, któ­re obej­mu­ją całość przed­się­wzię­cia ? od kon­cep­cji pro­duk­tu do koń­ca jego ?życia?, inte­gru­jąc zaso­by ludz­kie, pro­ce­sy, sys­te­my fir­mo­we oraz infor­ma­cje. PLM two­rzy i zarzą­dza cyfro­wo pro­duk­tem lub całym zakła­dem, zapew­nia­jąc fir­mie i reali­zo­wa­nym przez nią przed­się­wzię­ciom spój­ną struk­tu­rę informacyjną.

Produkcja ogół dzia­łań zmie­rza­ją­cych do dostar­cze­nia dóbr i usług na rynek.

Rachunkowość finan­so­wa (źr. coin.wne.uw.edu.pl/akocia/rach_fi/Rachunkowosc%20finansowa.ppt) Rejestr zda­rzeń gospo­dar­czych. Zdarzenie gospo­dar­cze to fakt, któ­ry jest:

1. udo­ku­men­to­wa­ny,
2. wyra­żo­ny w mier­ni­ku pieniężnym,
3. wywie­ra wpływ na akty­wa, pasy­wa lub wyni­ki dzia­łal­no­ści jed­nost­ki gospodarczej,

Podlega reje­stra­cji w księ­gach rachun­ko­wych. Zdarzenie gospo­dar­cze jest rów­no­znacz­ne z ope­ra­cją gospodarczą.

SCADA (źr. sys​te​my​-ste​ro​wa​nia​.pl) (Supervisory Control And Data Acquisition) nale­ży do war­stwy nad­rzęd­nej sys­te­mu ste­ro­wa­nia auto­ma­ty­ki prze­my­sło­wej. Głównym zada­niem SCADA jest wizu­ali­za­cja pro­ce­su w tzw. cza­sie rze­czy­wi­stym oraz umoż­li­wie­nie inge­ren­cji w pro­ces ? ste­ro­wa­nie poszcze­gól­ny­mi ele­men­ta­mi wyko­naw­czy­mi, zada­wa­nie para­me­trów, zmia­na nastaw ? z pozio­mu ope­ra­to­ra mają­ce­go do dys­po­zy­cji sta­cję kom­pu­te­ro­wą. SCADA zawie­ra naj­czę­ściej nastę­pu­ją­ce elementy:

1. wizu­ali­za­cję pro­ce­su w posta­ci gra­fik synoptycznych,
2. archi­wi­za­cję danych produkcyjnych,
3. moduł rapor­to­wy,
4. moduł pod­sta­wo­wej ana­li­zy i prze­glą­du danych historycznych,
5. moduł udo­stęp­nia­nia danych wyż­szym war­stwom struk­tu­ry zarzą­dza­nia przed­się­bior­stwem w celu ana­li­zy szcze­gó­ło­wej (sys­te­my MES, ERP, PLM).

WMS (Warehouse Management System), sta­no­wi kom­plek­so­we roz­wią­za­nie infor­ma­tycz­ne (opro­gra­mo­wa­nie, urzą­dze­nia, usłu­gi i ser­wis) pozwa­la­ją­ce na zarzą­dza­nie ruchem pro­duk­tów na maga­zy­nie oraz opty­ma­li­zu­ją­ce wyko­rzy­sta­nie prze­strze­ni maga­zy­no­wej. Szczególnym zada­niem reali­zo­wa­nym w ramach sys­te­mów WMS jest bez­błęd­na loka­li­za­cja towa­rów w maga­zy­nie oraz kon­tro­la prze­bie­gu obro­tu maga­zy­no­we­go. System dostar­cza infor­ma­cji doty­czą­cych sta­nu maga­zy­no­we­go według wie­lu róż­nych kry­te­riów oraz umoż­li­wia spraw­ną loka­li­za­cję każ­dej par­tii towa­ru i każ­dej poje­dyn­czej prze­sył­ki. W sys­te­mie WMS ope­ra­tor może wyge­ne­ro­wać odpo­wied­nią ety­kie­tę i ozna­czyć nią jed­nost­ki towa­ro­we lub w momen­cie przyj­mo­wa­nia towa­ru do maga­zy­nu przy­jąć do sys­te­mu infor­ma­cje zawar­te na ety­kie­cie nada­nej jej wcze­śniej przez inny podmiot. 

System ten, skła­da­ją­cy się z wyżej wymie­nio­nych pod­sys­te­mów, przed­sta­wia dia­gram poniżej.

Na dia­gra­mie zobra­zo­wa­no opi­sa­ne pod­sys­te­my oraz pod­sta­wo­we ele­men­ty komu­ni­ka­cji mie­dzy nimi. Komunikacja ta to głów­nie wza­jem­ne ?uży­cie [danych]? (ich wymia­na na żąda­nie a nie współ­dzie­le­nie). Podaż tych apli­ka­cji na ryn­ku potwier­dza opi­sa­ny na począt­ku arty­ku­łu, podział na klu­czo­we pod­sys­te­my dzie­dzi­no­we. Mamy tu jed­nak pew­ne spe­cja­li­zo­wa­ne pod­sys­te­my, któ­rych nie wyka­za­ła ana­li­za poję­cio­wa. Powodem jest to, że powyż­sza przy­kła­do­wa i bar­dzo uprosz­czo­na ana­li­za bazo­wa­ła na stan­dar­do­wych poję­ciach i fak­tach (czy­li wystę­pu­ją­cych w każ­dej fir­mie pro­duk­cyj­nej), zaś na ryn­ku mamy tak­że do czy­nie­nia z fir­ma­mi o bar­dziej roz­bu­do­wa­nej zło­żo­no­ści dzia­ła­nia lub mają­cej w swo­jej stra­te­gii więk­szą szcze­gó­ło­wość kon­tro­li i pla­no­wa­nia w wybra­nych obsza­rach dzie­dzi­no­wych (wyma­ga to pre­cy­zyj­niej­szej ana­li­zy niż ta przed­sta­wio­na). Np. pod­sys­tem APS to wła­śnie taki przy­pa­dek: jego wdro­że­nie jest uza­sad­nio­ne tam, gdzie wyma­ga­ne są (lub są moż­li­we) zarzą­dza­nie więk­szą ilo­ścią szcze­gó­łów i więk­sza auto­ma­ty­za­cja zarzą­dza­nia. Podobnie roz­wią­za­nia PLM.

Na dia­gra­mie tym mamy dość typo­wą archi­tek­tu­rę sys­te­mu ERP II, któ­ra pozwo­li lepiej zro­zu­mieć budo­wę takie­go sys­te­mu. Sercem fir­my pro­duk­cyj­nej jest Linia pro­duk­cyj­na. Linia ta jest obsłu­gi­wa­na przez ludzi jed­nak inter­fej­sem dla pozo­sta­łych pod­sys­te­mów jest MES, pod­sys­tem któ­ry zamie­nia wszyst­kie istot­ne fak­ty z ?życia linii pro­duk­cyj­nej? (sys­te­my czuj­ni­ków i pod­ze­spo­łów wyko­naw­czych) w stru­mień danych zro­zu­mia­łych dla pozo­sta­łych pod­sys­te­mów. Systemy MES w róż­nej for­mie, są coraz czę­ściej dostar­cza­ne przez pro­du­cen­tów maszyn i całych linii pro­duk­cyj­nych wraz z nimi. Więcej o tym pisa­łem w nie­daw­nym arty­ku­le o Internecie rze­czy (urzą­dze­nia elek­tro­me­cha­nicz­ne wraz z opro­gra­mo­wa­niem zbie­ra­ją­cym dane i komu­ni­ku­ją­cym się ?ze świa­tem?). Z danych dostar­cza­nych przez MES korzy­sta­ją sys­te­my moni­to­ro­wa­nia i zobra­zo­wa­nia infor­ma­cji SCADA. Z nich korzy­sta głów­nie zało­ga obsłu­gu­ją­ca linię pro­duk­cyj­ną oraz służ­by utrzy­ma­nia ruchu. Elementy zarzą­dza­nia i pla­no­wa­nia zaopa­trze­nia poja­wia­ją się w pod­sys­te­mie MRPII, któ­ry z MES zbie­ra dane o bie­żą­cym wyko­rzy­sta­niu i zuży­ciu zaso­bów. Podsystem Produkcja zarzą­dza reali­za­cją zle­ceń pro­duk­cyj­nych (zaspo­ka­ja­nie nie­do­bo­ru pro­duk­tów wła­snych w maga­zy­nach). Położeniem i ilo­ścią pro­duk­tów w maga­zy­nach zarzą­dza WMS. Rachunkowość finan­so­wa zbie­ra i prze­twa­rza wszel­kie fak­ty księ­go­we zwią­za­ne z przy­ję­cia­mi, wyda­nia­mi, prze­two­rze­niem, kosz­ta­mi oraz sprze­da­żą pro­duk­tów i kosz­ta­mi zaku­pu surow­ców. Wszelkie kon­tak­ty z klien­ta­mi zwią­za­ne z ofer­to­wa­niem, przyj­mo­wa­niem zamó­wień, obsłu­gą dostaw czy rekla­ma­cja­mi obsłu­gu­je CRM, któ­ry zawsze w więk­szym lub mniej­szym stop­niu reali­zu­je wewnętrz­ny obieg dokumentów.

Powyższy opis jest dość ogól­ny, to świa­do­me gdyż po pierw­sze fir­my się mię­dzy sobą róż­nią, nie raz bar­dzo istot­nie, po dru­gie apli­ka­cje dzie­dzi­no­we tak­że są dość zróżnicowane.

Każda fir­ma, szu­ka­jąc spo­so­bu na uzy­ska­nie prze­wa­gi ryn­ko­wej, sta­ra się pew­ne obsza­ry ope­ra­cyj­ne budo­wać wg, wła­snej stra­te­gii. To mię­dzy inny­mi powo­du­je, że każ­de wdro­że­nie jest inne i nie ma jed­nej jedy­nie-słusz­nej archi­tek­tu­ry IT.

[2021 – 09-04] Coraz czę­ściej moż­na sie spo­tkać z opi­sa­mi sys­te­mów wspie­ra­ją­cych fir­my pro­duk­cyj­ne, w któ­rych sys­te­my te to odręb­ne dedy­ko­wa­ne, dzie­dzi­no­we apli­ka­cje, zin­te­gro­wa­ne w jeden spój­ny sys­tem. Obecnie nie jest to trud­ne (szyb­ko postę­pu­je stan­da­ry­za­cja inte­gra­cji). Wszędzie tam gdzie poja­wia się spe­cy­fi­ka danej fir­my nale­ży opra­co­wać jej model i stwo­rzyć inter­fejs dosto­so­wa­ny do stan­dar­dów obo­wią­zu­ją­cych stan­dar­dów. Jednym że stan­dar­dów jest mode­lo­wa­nie zorien­to­wa­ne na struk­tu­rę danych, któ­re zawsze są prze­ka­zy­wa­ne w posta­ci doku­men­tów (paczek danych) a nie odwo­łań do baz danych .

Źródła