Razlike između nsi sustava upravljanja. Karakteristične značajke nsi. Nedosljednost između matičnih podataka i MD metapodataka

UDK 004.37.01

OH. Žiljajev ,
Zavod za informatiku i
problemi regionalnog upravljanja
KBSC RAS, istraživač, Naljčik.

Uvod

Stvaranje jedinstvenog informacijskog prostora nužan je uvjet za učinkovito upravljanje različitim objektima, bilo da se radi o poduzeću, odjelu, regiji ili državi. Formiranje jedinstvenog okruženja uključuje integraciju procesa upravljanja, praćenu normalizacijom protoka informacija. Često je kretanje informacija na različitim razinama i dijelovima kontrolnog objekta podržano različitim informacijskim i računovodstvenim sustavima. Sukladno tome, postoji potreba za integracijom ovih sustava. Rastući procesi globalizacije svjetskog gospodarstva u biti su integracijski procesi. Takvi integracijski zadaci posebno su relevantni za Rusiju u vezi s njezinim nadolazećim pristupanjem Svjetskoj trgovinskoj organizaciji (WTO).

Zadatak integracije informacijskih i računovodstvenih sustava sastoji se od dva međusobno povezana dijela: integracije podataka i naknadne integracije aplikacija. Pri izvođenju integracije podataka potrebno je objediniti i standardizirati normativno-referentne informacije (RNI). .

Matični podaci uvjetno su trajni dio svih informacija u informacijskom sustavu (IS), za razliku od tekućih informacija koje se generiraju neposredno u procesu rada u IS-u. Matični podaci uključuju: imenike, rječnike, linearne i hijerarhijske liste, klasifikatore, registre, šifratore, iz kojih se podaci koriste u generiranju tekućih dokumenata.

Za označavanje takvih referentnih informacija u literaturi na engleskom jeziku koristi se izraz Master Data (master data, master data), a zadaci upravljanja njima nazivaju se Master Data Management (MDM). Međutim, na ruskom jeziku koncept normativne reference informacija (RNI) sada se sve češće koristi), koji se pojavio u disciplinama vezanim uz gospodarsko upravljanje još u predračunalnom vremenu. U ovom slučaju, definicija "normativnog" odražava činjenicu da se problem stvaranja imenika mora riješiti uzimajući u obzir industrijske, državne i međunarodne standarde.

Ako su danas pojmovi kao što su, na primjer, ACS (Automatizirani sustavi upravljanja) ili IS (Informacijski sustavi) postali poznati, tada kratica "SU NSI" (Regulatory Reference Information Management System) često izaziva zabunu. Čak i značenje koje se krije iza njegovog dekodiranja često razumiju samo stručnjaci. NSI nije samo baza podataka, već složeno organiziran sustav s mnogo unakrsnih referenci između pojedinačnih imenika i klasifikatora. Posebno je važan mehanizam održavanja relevantnosti referentnih informacija. Zahtjevi za cjelovitost, točnost i relevantnost informacija u sustavu referentnih podataka mnogo su stroži nego u konvencionalnoj bazi podataka, budući da tijekom rada bilo kojeg informacijskog sustava, uključujući automatizirane sustave upravljanja, informacijski sadržaj primijenjenih zadataka ovisi o referentnim podacima. podaci. Matični podaci su “temelj” cjelokupnog informacijskog sustava i upravljanje tim sustavom treba biti centralizirano. Na slici 1 prikazani su referentni podaci kao niža razina, “informacijski temelj” cijele strukture IS-a.

Riža. 1 Razine informacijskog sustava

Upravo centralizirano upravljanje sustavom referentnih podataka, podložno jedinstvenim propisima i osigurano jedinstvenim tehnološkim okruženjem, omogućuje održavanje objedinjenosti podataka, potpunosti, cjelovitosti i relevantnosti svih referentnih knjiga i klasifikatora koji ulaze u njegov sastav. Stoga, imati učinkovito funkcionirajući IS koji rješava stvarne probleme.

Razvoj potpunog softvera za upravljanje matičnim podacima započeo je prije samo nekoliko godina. Vodeći proizvođači softvera u posljednje vrijeme sve više pozornosti posvećuju alatima za upravljanje matičnim podacima (u engleskoj verziji MDM, Master Data Management - upravljanje matičnim podacima).

Teško je zamisliti rješavanje problema integracije bez centraliziranog upravljanja referentnim podacima. Problem upravljanja matičnim podacima javlja se čak iu takvim automatiziranim i informacijski podržanim strukturama kao što su banke ili osiguravajuća društva. Sustavi upravljanja glavnim podacima omogućuju ne samo prikupljanje podataka iz nekoliko integriranih bankovnih sustava, na primjer, generiranje izvješća za nekoliko računovodstvenih sustava; ali i riješiti probleme operativnog upravljanja referentnim podacima.

U Rusiji ne postoji jedinstveni centar za formiranje referentnih podataka sličnih GOST-ovima. I, iako su novi zakoni koji se odnose na razvoj i cirkulaciju elektroničke tehničke dokumentacije nedavno stupili na snagu, oni još nisu imali primjetan utjecaj na situaciju.

Uloga NSI-ja u informatizaciji regije

Regionalna informatizacija ima važnu ulogu u provedbi strategije razvoja informatičkog sektora u našoj zemlji. Nedavno je u sastavnim entitetima Ruske Federacije intenziviran rad na korištenju informacijskih tehnologija u svim sferama regionalnog života. Tome je pridonijela provedba niza događaja od strane federalnih tijela vlasti i usvajanje regulatornih dokumenata u području korištenja informacijskih tehnologija na saveznoj, odjeljenoj, regionalnoj i općinskoj razini. Jedan od takvih dokumenata, osmišljen kako bi pomogao u rješavanju problema sveobuhvatne informatizacije regije, je Uredba Vlade Ruske Federacije „O postupku formiranja i korištenja osnovnih klasifikatora, imenika i registara u pružanju državnih i komunalne službe u elektroničkom obliku” od 31. kolovoza 2010. godine.

Posebnu ulogu referentnih podataka također imaju programi informatizacije za industrije i odjele. Na primjer, u objavljenom 31. ožujka 2010. U nacrtu Koncepta informatizacije zdravstva posebno se ističe da informacijski sustavi u zdravstvu trebaju biti projektirani uvažavajući standarde i propise te temeljeni na jedinstvenim matičnim podacima. (NSI koji se koristi u području zdravstvene zaštite, socijalnog razvoja i radnih odnosa Ruske Federacije uključuje ukupno 163 različita klasifikatora i priručnika)..

Na regionalnoj razini, cilj implementacije infrastrukture matičnih podataka u automatizirane sustave upravljanja je stvaranje jedinstvenog sustava imenika i klasifikatora koji se koriste u državnim (općinskim) informacijskim sustavima konstitutivnog entiteta Ruske Federacije, kao i formiranje temeljnih računovodstvenih registara koji osiguravaju prikupljanje i pohranjivanje danih informacija o glavnim objektima regionalnog upravljanja. Sustav za upravljanje matičnim podacima, kao centralizirani repozitorij i jedini dobavljač zajedničkih matičnih podataka za sve infrastrukturne i odjelske informacijske sustave u regiji, mora osigurati informacijsku kompatibilnost lokalnih informacijskih sustava i aplikacija “elektroničke uprave” subjekta.

Očito, sljedeći korak u razvoju informacijske tehnologije u Ruskoj Federaciji trebao bi biti kasnija integracija odjelskih, regionalnih i općinskih informacijskih sustava na federalnoj razini. Ova zadaća integracije vladinih informacijskih sustava toliko je složena da su uz standardizaciju dokumenata (primjerice temeljenih na XML-u) i integracijske infrastrukture u obliku softvera, usmjeravanja XML dokumenata, vladini napori potrebni i na polju standardizacije opisa podataka.

Primjer inicijative u ovom području je e-GMS (UK GoverNmeNt Metadata StaNdard) standard usvojen u UK. . Mnoge zemlje uzele su kao osnovu takozvanu „Dublin Core“, koja uključuje 15 elemenata opisa informacija:

  • titula;
  • autor ili kreator;
  • tema i ključne riječi;
  • opis;
  • izdavač;
  • drugi suradnici;
  • datum;
  • vrsta izvora;
  • format;
  • identifikator izvora;
  • izvor;
  • jezik;
  • komunikacije;
  • površina (pokrivenost);
  • upravljanje pravima.

Osim samih elemenata, “Dublin Core” ima takozvana pojašnjenja elemenata, na primjer: “Datum stvaranja”, “Datum objave”, “Datum isteka”, itd. Zemlje ne mogu samo koristiti ovu jezgru, ali i dodati sve dodatne elemente koje smatraju potrebnima. Osim toga, prvi alat pri traženju informacija obično je pregledavanje kategorija. Stoga vladine inicijative za standarde metapodataka definiraju standarde za popis kategorija (primarni alat za pretraživanje bez upotrebe ključnih riječi).

Zaključci

Prilikom upoznavanja sa zakonodavstvom koje ima za cilj reguliranje pružanja državnih i općinskih usluga u elektroničkom obliku, te organiziranje međuresorne informacijske interakcije na državnoj i općinskoj razini, možete vidjeti:

  • stvarni nedostatak u regulatornim pravnim aktima obveznih zahtjeva za standardizaciju informacijskih tehnologija i softvera koji se koriste u državnim informacijskim sustavima potrebnim za osiguranje međuresorske razmjene informacija;
  • nedostatak u regulatornim pravnim aktima jedinstvenih jasnih zahtjeva za direktorije, klasifikatore i sheme podataka informacijskih sustava koji se koriste u međuresornoj razmjeni informacija;
  • nepostojanje u regulatornim pravnim aktima mehanizama za pružanje informacija i pružanje javnih usluga u elektroničkom obliku koji su jedinstveni i obvezni za provedbu od strane svih federalnih, regionalnih i općinskih vlasti. .

Danas, kako u Ruskoj Federaciji tako iu inozemstvu, glavna poteškoća u provedbi projekata u području pružanja elektroničkih usluga na državnoj, regionalnoj i općinskoj razini, kao i sličnih međuresornih projekata, u uvjetima u kojima su potrebni značajni napori za integraciju podataka i aplikacija, ne sastoji se u korištenju određenih specifičnih tehnologija, već u organiziranju procesa usvajanja relevantnih standarda i usklađivanja arhitektura informacijske tehnologije različitih organizacija i odjela.

Projekti u području pružanja elektroničkih usluga na državnoj, regionalnoj, općinskoj i ministarskoj razini, koje provode vlade različitih zemalja, predviđaju sljedeće glavne vrste standarda:

  • standardi podataka;
  • standardi za međuresornu razmjenu informacija;
  • standardi metapodataka (i pronalaženja informacija);
  • sigurnosni standardi.

Potrebna je jedinstvena suvremena metodologija za vođenje matičnih podataka jer će u protivnom, s povećanjem količine podataka, sustav postati neupravljiv.
Propisi i metodologija popunjavanja priručnika i klasifikatora moraju biti detaljno razrađeni, inače će biti izuzetno teško osigurati kvalitetan i uredan rad stručnjaka u vođenju referentnih podataka. Potrebno je jasno razgraničiti područja nadležnosti i odgovornosti korisnika referentnih podataka i stručnjaka za njihovo upravljanje.

Potrebna je visokoučinkovita suvremena tehnologija i sustav upravljanja referentnim podacima koji rješava problem višekorisničkog pristupa istom uz mogućnost fizičkog odvajanja ovlasti, implementira interakciju korisnika sa stručnjacima i osigurava jednostavno skaliranje sustava pri povećanju kako sama referentna baza podataka i broj servisnih stručnjaka.

Književnost:
1. „Strategija razvoja informacijskog društva u Ruskoj Federaciji” (odobren od strane predsjednika Ruske Federacije 7. veljače 2008. br. Pr-212);
2. Nacrt rezolucije Vlade Ruske Federacije "O postupku formiranja i korištenja osnovnih klasifikatora, imenika i registara u pružanju državnih i općinskih usluga u elektroničkom obliku" od 31. kolovoza 2010.
3. “Pregled NSI”, Publikacija Ministarstva gospodarskog razvoja, 2010
4. „Koncept izgradnje informacijskog sustava u zdravstvu za razdoblje do 2020. godine“, 2010.
5. Polotnjuk I."Metapodaci kao osnova za integraciju", PC Week/RE (492), 2005.
6. Ray Wang, Rob Karel."Trendovi 2008: Upravljanje glavnim podacima" 2008.

Sabir Asadullaev i Alexander Karpov
Objavljeno 09.11.2010

Osnovni pojmovi i terminologija

Matični podaci (MD) uključuju podatke o kupcima, zaposlenicima, proizvodima, robi, dobavljačima, koji u pravilu nisu transakcijske prirode.

Regulatorne referentne informacije (RNI) uključuju rječnike, referentne knjige, klasifikatore, kodifikatore, standarde i identifikatore. To je osnovna razina transakcijskih sustava koju u nekim slučajevima održavaju vanjske ovlaštene organizacije.

Riža. Slika 1 ilustrira u pojednostavljenom obliku razliku između matičnih podataka, matičnih podataka i transakcijskih podataka. U konvencionalnom sustavu prodaje zrakoplovnih karata, ulogu referentnih podataka ima kodifikator zračne luke, koji su izradili programeri sustava uzimajući u obzir određene specifične zahtjeve. Ali za interakciju s drugim međunarodnim informacijskim sustavima, šifra zračne luke mora biti razumljiva svima. Troslovna jedinstvena šifra zračne luke koju je zračnim lukama dodijelila Međunarodna udruga zračnog prometa (IATA) služi u tu svrhu.

Podaci o putnicima nisu stabilni kao kodovi zračnih luka. Istodobno, jednom uneseni u sustav podaci o putnicima mogu se naknadno koristiti za razne marketinške akcije, primjerice za popuste pri dostizanju određene ukupne udaljenosti leta. Takve se informacije obično odnose na matične podatke. Oni također uključuju podatke o posadama, floti zrakoplova tvrtke, teretnim i putničkim terminalima i mnogim drugim subjektima uključenim u proces zračnog prijevoza, ali nisu uzeti u obzir u našem pojednostavljenom primjeru.

Posljednji, gornji red na sl. Slika 1 shematski prikazuje zamišljenu transakciju povezanu s prodajom ulaznice. U svijetu ima relativno malo zračnih luka, mnogo je više klijenata, ali oni mogu koristiti usluge ove tvrtke mnogo puta, a karta se ne može i ne smije ponovno koristiti. Stoga su podaci o prodaji karata za avioprijevoznika transakcijski podaci koji se najčešće mijenjaju.

Ukratko, možemo reći da matični podaci čine osnovnu razinu automatiziranih informacijskih sustava, a matični podaci pohranjuju informacije o kupcima i zaposlenicima, dobavljačima proizvoda, opremi, materijalima i drugim poslovnim subjektima.

Istodobno, referentni podaci i MD imaju mnogo toga zajedničkog, stoga, u slučajevima kada se faktori koji se razmatraju odnose i na referentne podatke i na MD, nazivat ćemo ih "RSI i MD", na primjer, "sustav za održavanje referentnih podataka i MD”.

Opći nedostaci tradicionalnog upravljanja NSI i MD

Najčešći i očiti problem s tradicionalnim upravljanjem NSI i MD je nedostatak podrške za privremene promjene. Adresa je u pravilu jedna od najvažnijih sastavnica referentnih podataka i MD. Nažalost, adrese se mijenjaju. Klijent se može seliti, ali može “preseliti” cijelu kuću pa čak i ulicu. Tako je 2009. godine adresa kompleksa zgrada Kule na nasipu promijenjena iz "Krasnopresnenskaja nasipa, zgrada 18" u "Presnenskaja nasipa, zgrada 10". Tako je upit “Koliko je korespondencije isporučeno u ured tvrtke koja iznajmljuje prostore u Tornju na Embankmentu u 2009. godini?” treba ispravno rukovati zapisima o isporuci s dvije različite adrese.

Međutim, da bi se promjene u životu odrazile na IT sustav, nije dovoljno imati tehnološke (hardverske i softverske) alate za održavanje referentnih podataka i MD. Netko ili nešto je potrebno za praćenje promjena. Odnosno, potrebne su organizacijske mjere, npr. osoblje s radnim obvezama koje odgovaraju prihvaćenoj metodologiji za održavanje matičnih podataka.

Dakle, korporativno upravljanje referentnim podacima i MD uključuje tri kategorije aktivnosti:

  1. Metodološke aktivnosti koje definiraju metode, propise, standarde, procese i uloge koje podržavaju cijeli životni ciklus održavanja matičnih podataka i MD
  2. Organizacijske mjere kojima se, sukladno metodološkim zahtjevima, utvrđuje organizacijska struktura, funkcionalne jedinice i njihovi zadaci, uloge i radne odgovornosti zaposlenika.
  3. Tehnološke mjere koje se nalaze na informatičkoj razini i osiguravaju provedbu organizacijskih i metodoloških mjera.

U ovom ćemo članku razmotriti prije svega tehnološke aktivnosti koje uključuju stvaranje jedinstvenog modela matičnih podataka i MD podataka, održavanje i arhiviranje povijesnih matičnih podataka i MD, identifikaciju matičnih podataka i MD objekata, uklanjanje duplikata, identifikaciju proturječja, osiguravanje referentnog integriteta, podrška životnom ciklusu referentnih podataka i MD objekta, razvoj pravila čišćenja, stvaranje sustava za održavanje matičnih podataka i MD i njegova integracija s operativnim informacijskim sustavima poduzeća. Razmotrimo detaljnije tehnološko područje stvaranja matičnih podataka i MD infrastrukture te povezane nedostatke tradicionalnih matičnih podataka i upravljanja podacima.

Tehnološki nedostaci održavanja referentnih podataka i MD

Ne postoji jedinstveni model podataka za matične podatke i MD

Ne postoji jedinstveni model podataka za matične podatke i MD, ili nije formaliziran, što onemogućuje učinkovito korištenje matičnih podataka i MD objekata i komplicira automatizaciju rada s podacima.

Podatkovni model je glavni i najvažniji dio održavanja matičnih podataka i MD-a, odgovarajući na primjer na sljedeća pitanja:

  • što bi trebalo biti uključeno u identifikacijske atribute referentnih podataka i MD objekta?
  • Koje od svih atributa matičnih podataka i MD objekta treba pohraniti u podatkovni model i pripisati matičnim podacima i MD, a što pripisati operativnim podacima i ostaviti u operativnom informacijskom sustavu?
  • kako integrirati pomoću modela s vanjskim identifikatorima i klasifikatorima (OKPO, OKUD)?
  • Daje li kombinacija dva atributa iz različitih IT sustava treći jedinstveni i važan atribut s poslovne točke gledišta?

Ne postoji jedinstveni propis za vođenje povijesti i arhiviranje

Povijesne informacije u postojećim korporativnim IT sustavima često se održavaju prema vlastitim propisima i imaju vlastite životne cikluse koji su odgovorni za obradu, agregaciju i arhiviranje matičnih podataka i MD objekata. Čak i ako postoji objedinjeni model podataka za matične podatke i MD, sinkronizacija povijesnih i arhivskih podataka i njihovo dovođenje u jedinstveni oblik nije trivijalan zadatak.

Primjer problema uzrokovanih nedostatkom održavanja povijesnih normativnih i referentnih informacija dan je u odjeljku “”.

Poteškoće u identificiranju referentnih podataka i MD objekata

U raznim informatičkim sustavima, matični podaci i MD objekti imaju vlastite identifikatore - skupove atributa. Situacija je komplicirana kada za iste objekte u različitim sustavima nije moguće identificirati jedan zajednički skup atributa, čija je kombinacija jedinstvena i identificira objekt u informacijskom sustavu - analog kompozitnog ključnog polja u bazama podataka. U ovom slučaju zadatak identifikacije i usporedbe objekata u različitim IT sustavima prelazi iz determinističkog područja u probabilističko područje. U tom je slučaju teško kvalitativno identificirati referentne podatke i MD objekte bez specijaliziranih alata za analizu i obradu podataka.

Pojava dvostrukih objekata referentnih podataka i MD

Složenost identifikacije objekta dovodi do potencijalne pojave duplikata (ili mogućih duplikata) istih matičnih podataka i MD objekta u različitim sustavima, što je glavni i najznačajniji problem za poslovanje. Dupliciranje informacija dovodi do dupliciranja troškova obrade objekata, dupliciranja “ulaznih točaka” i povećanja troškova održavanja životnih ciklusa objekata. Dodatno treba istaknuti troškove ručne provjere (usklađivanja) duplikata koji su u startu previsoki jer često nadilaze mogućnosti IT sustava i zahtijevaju sudjelovanje operatera. Treba napomenuti da je pojava duplikata sistemska greška koja se pojavljuje u najranijim koracima poslovnih procesa koji koriste matične podatke i MD objekt. Nadalje, kako poslovni proces napreduje, duplikat dobiva veze i sastav atributa, a situacija postaje još kompliciranija.

Nedosljednost između matičnih podataka i MD metapodataka

Svaki informacijski sustav koji podržava poslovnu liniju poduzeća i u kojem se generiraju glavni podaci i MD objekti specifični za ovo poslovanje, definira vlastiti skup poslovnih pravila i ograničenja nametnutih i na sastav atributa (metapodatke) i na vrijednost atributi. Zbog toga često dolazi do situacije da se ova pravila i ograničenja navedena u različitim informacijskim sustavima međusobno sukobljavaju, čime se poništavaju čak i teoretski pokušaji da se svi objekti matičnih podataka dovedu u isti tip. Situacija je pogoršana kada, s vanjskim identičnim modelom podataka, podaci imaju isto semantičko značenje, ali različito značenje u smislu prezentacije: različito pisanje, permutacije u adresama, kratice punog imena, različita kodiranja, kratice.

Referentni integritet i sinkronizacija referentnih podataka i MD modela

U stvarnom životu, svi referentni podaci i MD objekti smješteni u prostoru njihovog IT sustava sadrže ne samo vrijednosti, već i poveznice na druge referentne podatke i MD, koji se mogu nalaziti (i održavati) u zasebnim vanjskim sustavima. Ovdje u punoj snazi ​​dolazi do problema sinkronizacije i održavanja integriteta cjelokupnih matičnih podataka i MD modela organizacije. Jedan od općeprihvaćenih načina za rješavanje ove vrste problema je prelazak na korištenje referentnih podataka i MD koji se održavaju i unose u organizaciju izvana (primjerice imenici KLADR, OKVED, TN VED, FSKP i ECPS). ).

Neusklađenost između životnog ciklusa referentnih podataka i MD objekta

Kao rezultat prisutnosti istih matičnih podataka i MD objekta u različitim korporativnim sustavima, unos i promjena ovog objekta u tim sustavima nije koordiniran i često se produljuje tijekom vremena. Moguća je situacija kada je objekt u različitim sustavima u međusobno isključivim statusima (u jednom sustavu aktivan, u drugom arhiviran, u trećem obrisan), što otežava održavanje integriteta objekata matičnih podataka. Objekte koji nisu povezani i rašireni tijekom vremena teško je koristiti u transakcijskim i analitičkim procesima.

Razvijanje pravila čišćenja

Pravila za čišćenje referentnih podataka i MD često se s pravom pripisuju metodološkim aspektima. Naravno, IT stručnjaci trebaju postavljati zadatke od poslovnih korisnika, primjerice, u kojim slučajevima je potrebno ažurirati kodove zračnih luka ili koja od dvije platne kartice ima ispravno kodiranje detalja. Ali poslovni stručnjaci nisu upoznati sa zamršenostima implementacije operativnih IT sustava. Štoviše, dokumentacija za te sustave je ili nepotpuna ili nedostaje. Stoga je potrebna analiza informacijskih sustava kako bi se pojasnila pravila čišćenja i identificirala nova pravila.

Pogrešan izbor glavnog sustava za održavanje referentnih podataka i MD

Najčešće su najznačajniji izvori i potrošači matičnih podataka i MD veliki naslijeđeni korporativni informacijski sustavi, koji su srž poslovanja poduzeća. U stvarnom životu, takav se sustav često odabire kao "glavni sustav" za održavanje matičnih podataka i MD-a umjesto stvaranja specijaliziranog repozitorija matičnih podataka i MD-a. Pritom se ne uzima u obzir da je takva funkcionalnost u pravilu neuobičajena za ovaj IT sustav. Kao rezultat toga, sve izmjene takvih sustava vezane uz referentne podatke i MD rezultiraju velikim i nerazumnim troškovima. Situacija se pogoršava kada je razvojem matičnih podataka i podsustava za upravljanje podacima potrebno uvesti kvalitativno nove funkcionalnosti: skupnu obradu, formatiranje i čišćenje podataka te imenovati upravitelje podataka.

Nespremnost IT sustava za integraciju matičnih podataka i MD

Kako bi se upravljanje matičnim podacima i MD-om u potpunosti implementiralo u postojeće informatičke sustave poduzeća, potrebno je te sustave integrirati, a najčešće je ta integracija nužna ne kao jednokratni i lokalizirani čin, već kao promjene u procesima koji žive unutar IT sustava. Osim integracije za online rad, potrebno je provesti integraciju za provedbu početnog skupnog učitavanja podataka (ETL), kao i za provođenje ručnih postupaka usklađivanja (usklađivanje).

Nisu svi automatizirani informacijski sustavi spremni za takve promjene, nemaju svi sustavi takva sučelja, a najčešće je to potpuno nova funkcionalnost za takve sustave. Prilikom implementacije sustava pojavljuju se arhitektonski problemi vezani uz izbor različitih opcija za implementaciju matičnih podataka i MD sustava i njegovu integraciju s tehnološkim krajolikom poduzeća. Kako bismo potvrdili važnost ove točke, napominjemo da postoje razvijeni i testirani arhitektonski obrasci i pristupi usmjereni na ispravnu implementaciju i integraciju matičnih podataka i MD sustava.

Primjeri problema u tradicionalnom upravljanju istraživačkim podacima i MD

Dakle, glavni problemi upravljanja matičnim podacima proizlaze iz decentralizacije i fragmentacije matičnih podataka u poduzeću i očituju se u praksi na konkretnim primjerima.

Podaci iz putovnice kao jedinstveni identifikator

Na primjer, u velikoj banci, kao rezultat stvaranja modela podataka o klijentima, odlučeno je koristiti podatke iz putovnice kao dio identifikacijskih atributa uz pretpostavku maksimalne selektivnosti. Prilikom provođenja postupaka spajanja podataka o klijentima otkriveno je da putovnica klijenta nije jedinstvena, budući da su, primjerice, klijenti koji su imali odnose s bankom sa starim putovnicama, a zatim s novim putovnicama kreirani kao različiti klijenti. Analiza podataka o klijentima otkrila je slučajeve u kojima su tisuće klijenata bile registrirane na jednoj putovnici. Povrh svega, jedan od izvora podataka bio je bankovni informacijski sustav u kojem su putovnice bile neobavezan uvjet, a odgovarajuća polja su se punila “smećem” prilikom popunjavanja.

Treba napomenuti da uočeni problemi s kvalitetom podataka o klijentima nisu bili očekivani te su otkriveni tek u fazi čišćenja podataka, što je zahtijevalo dodatno vrijeme i novac za doradu pravila čišćenja podataka i modela podataka o klijentu.

Adresa kao jedinstveni identifikator

U drugom slučaju, osiguravajuće društvo spajalo je osobne podatke klijenata, gdje je, između ostalog, adresa korištena kao identifikacijski atribut. Ispostavilo se da je većina klijenata prijavljena na adresama “isto”, “na istom mjestu”. Podaci niske kvalitete došli su iz aplikacijskog sustava koji podržava aktivnosti agenata osiguranja, što je agentima omogućilo da slobodno tumače vrijednosti polja u upitniku klijenta. Štoviše, ovom sustavu nedostajale su bilo kakve formatne ili logičke provjere unesenih podataka.

Potreba za masovnim obnavljanjem ugovora

U trećem slučaju, pri povezivanju postojećeg korporativnog informacijskog sustava koji podržava odnose s klijentima na sustav za održavanje matičnih podataka i MD, tek je u fazi testiranja postalo jasno da povezani sustav ne može automatski prihvatiti promjene iz sustava za održavanje matičnih podataka. podaci i MD. Da biste to učinili, potrebno je provesti neke regulatorne radnje, u ovom slučaju nazvati klijenta i ponovno izdati papirnate ugovorne dokumente koji spominju kritične informacije vezane uz matične podatke i MD. Zbog velikog obima posla revidirani su i tehnološki i organizacijski aspekti rada s referentnim podacima i MD.

Neusklađenost dogovorenih podataka

Četvrti primjer opisuje tipičnu situaciju za mnoge organizacije. Kao rezultat brzog razvoja poslovanja poduzeća, odlučeno je otvoriti novi smjer koji podržava rad s klijentima u B2C / B2B stilu putem Interneta. U tu svrhu nabavljen je novi informatički sustav za podršku automatizaciji nove poslovne linije tvrtke. Tijekom implementacije postalo je potrebno integrirati s postojećim matičnim podacima i matičnim podacima poduzeća te ih proširiti specifičnim atributima, što se pokazalo ne tako lakim, prvenstveno zbog nedostatka namjenskih matičnih podataka i MD sustava. Kao rezultat toga, referentni podaci učitani su jednom u novi sustav bez ikakvih povratnih informacija iz postojećeg IT krajolika tvrtke, što je nakon nekog vremena dovelo do dvije neovisne verzije imenika klijenata. Isprva se problem rješavao ručnom obradom podataka o klijentima u proračunskim tablicama, no nakon nekog vremena broj klijenata se značajno povećao, imenici su rasprodani, a ručna obrada se pokazala neučinkovitom i skupom. Posljedično, situacija je dovela do ozbiljne eskalacije problema na razini poslovnih korisnika koji nemaju cjelovitu sliku svojih klijenata za provođenje marketinških kampanja.

Prednosti korporativnog upravljanja referentnim podacima i MD

Korporativno upravljanje matičnim podacima i MD-om pruža sljedeće prednosti:

  • Usklađenost sa zakonskim zahtjevima i smanjenje rizika
  • Smanjenje troškova
  • Povećana fleksibilnost za podršku novim poslovnim strategijama.

Zvuči predobro da bi bilo istinito, pa pogledajmo svaku od prednosti na praktičnim primjerima.

Usklađenost sa zakonskim zahtjevima i smanjenje rizika

Istražni organi su od velike tvrtke tražili podatke za prethodnih 10 godina. Zadatak se činio jednostavnim i izvedivim: tvrtka je davno prije toga uvela procedure za redovno arhiviranje i sigurnosno pohranjivanje podataka i aplikativnih programa, mediji s podacima pohranjeni su u sigurnoj prostoriji, a oprema za čitanje medija još nije zastarjela. Međutim, nakon obnavljanja povijesnih podataka iz arhive, otkriveno je da podaci nemaju nikakvo praktično značenje - glavni podaci su se mijenjali nekoliko puta tijekom tog vremena, pa je sada bilo nemoguće utvrditi na što se ti ili oni podaci odnose. Nitko nije omogućio arhiviranje matičnih podataka - činilo se da su to vremenski otporne informacije. Poduzeću su izrečene značajne kazne, a protiv rukovoditelja poduzeća doneseni su ozbiljni organizacijski zaključci. Osim toga, formirana je jedinica zadužena za održavanje referentnih podataka kako se nemila situacija ne bi ponovila.

Rast profita i zadržavanje kupaca

Velika cvjećarna jedna je od prvih koja je shvatila učinkovitost e-mail marketinga. Izrađena je web stranica trgovine na kojoj su provedene reklamne kampanje, gdje su se kupci mogli pretplatiti na newslettere za Valentinovo, vezano uz rođenje prvog djeteta, rođendan voljene osobe i sl. Kupci su naknadno dočekani prijedlozima za izbor boja. Međutim, reklamne kampanje su provedene uz uključivanje različitih programera koji su kreirali različite, nepovezane aplikacije. Stoga su korisnici mogli primiti do deset e-poruka o istom problemu, što je iritiralo korisnike i uzrokovalo ih da odustanu. Kao rezultat toga, svaka sljedeća reklamna kampanja ne samo da se pokazala neisplativom, već je i smanjila broj postojećih kupaca. Cvjećarna je morala potrošiti značajnu količinu novca na redizajn i integraciju svojih aplikacija. Visok iznos troškova bio je povezan s heterogenošću podataka o kupcima, više formata adresa i telefona, što je uzrokovalo velike probleme u identifikaciji kupaca radi eliminiranja višestrukih unosa.

Smanjenje troškova

Jedan od glavnih zahtjeva za proizvode tvrtke je potreba za brzim odgovorom na promjene potražnje, izvođenje novih proizvoda na tržište u kratkom vremenu i komunikacija s potrošačima. Vidimo da se jučerašnji neosporni lideri pretvaraju u zaostatke, a novopridošlice koje su prvi put donijele svoj proizvod na tržište naglo povećavaju svoju dobit i kapitalizaciju. U takvim uvjetima različiti korporativni informacijski sustavi zaduženi za razvoj proizvoda, njegovu nabavu i prodaju, servis i razvoj moraju se temeljiti na jedinstvenoj informacijskoj bazi koja pokriva sve aspekte poslovanja poduzeća. Zatim, uvođenje novog proizvoda na tržište zahtijeva manje vremena i financijskih troškova zbog besprijekorne interakcije pratećih informacijskih sustava.

Povećana fleksibilnost za podršku novim poslovnim strategijama

Uklanjanje fragmentacije i decentralizacija referentnih podataka i upravljanja MD-om omogućuje pružanje informacija kao usluge. To znači da bilo koji IT sustav, poštujući uspostavljene protokole razmjene i prava pristupa, može pristupiti korporativnom sustavu za održavanje matičnih podataka i MD-a i primiti potrebne podatke. Pristup orijentiran na usluge omogućit će vam fleksibilnu izgradnju informacijskih usluga u skladu s promjenjivim poslovnim procesima, osiguravajući tako pravovremenu reakciju IT usluga i sustava na promjenjive zahtjeve.

Arhitektonski principi sustava za održavanje referentnih podataka i MD

Resursi za preuzimanje

static.content.url=http://www.site/developerworks/js/artrating/

Zona=Upravljanje informacijama

ID članka=577045

ArticleTitle=Održavanje referentnih podataka pomoću praktičnih primjera

Imenik « Struktura poduzeća"sadrži hijerarhiju funkcionalnih odjela poduzeća svih vrsta - administrativnih, proizvodnih i tako dalje.

Imenik može imati bilo koju dubinu hijerarhije, a koristi se hijerarhija elemenata. To znači da obračunska jedinica i objekt planiranja može biti bilo koji odjel u hijerarhiji.

Iz ovog primjera jasno je da se proizvodnja može strukturirati u odjele (sekcije, sektore, grupe, odjele) s bilo kojom razinom ugniježđenja.

Sa stajališta podsustava za upravljanje proizvodnjom, odjel se tumači kao izvršitelj faza proizvodnog plana, sukladno tome, u specifikacijama resursa za svaku fazu definiran je odjel - izvršitelj faze;

Nabrojimo detalje proizvodne jedinice čije se vrijednosti moraju odrediti u podsustavu "Upravljanje proizvodnjom".

  • Raspored rada. Odabrano iz direktorija "Rasporedi rada".

Element ovog imenika definira raspored rada - vrijeme početka i završetka rada posebno za svaki dan u tjednu i posebno za sve predblagdanske dane. Za svaki dan u tjednu možete posebno odrediti vrijeme početka i završetka rada prema rasporedu, a može biti više vremenskih perioda rada po danu u tjednu, npr. od 8.00 do 13.00 i od 14.00 do 18.00 sati. . Potreban je raspored rada za odjel kako bi se postupkom izračuna rasporeda proizvodnje moglo odrediti broj sati rada koji je dostupan u odjelu za svaki kalendarski dan.

  • Skladište materijala. Skladište u kojem se generiraju potrebe za materijalima prema rasporedu proizvodnje za planirane faze u odjelu. Ovo skladište provjerava dostupnost materijala za dovršetak pozornice. Po potrebi, za nomenklaturu i karakteristike materijala, možete postaviti zasebna skladišta materijala gdje će se provjeravati njihova dostupnost.
  • Interval rasporeda. Određuje koji će se interval koristiti za odjel prilikom izračuna rasporeda proizvodnje po fazama. Mogućnosti: "Dan", "Tjedan", "Mjesec".

Ako je potrebno, opcija " Sat", da biste koristili ovaj interval, morate omogućiti odgovarajuću funkcionalnu opciju.

Kriteriji za odabir intervala planiranja za odjel su usklađenost s trajanjem tipičnih faza koje se izvode u odjelu i trajanje intervala. Na primjer, ako većina faza u odjelu ne traje više od nekoliko dana, tada ima smisla koristiti interval "Dan". Ako tipično trajanje faze značajno premašuje tjedan dana, tada je razumno koristiti interval "tjedni".

Povećanje duljine intervala iznad potrebnog dovodi do osjetnog produljenja trajanja proizvodnje, odnosno do „rastezanja“ proizvodnog plana tijekom vremena.

Pretjerano smanjivanje duljine intervala dovodi do previše vremenskih detalja u rasporedu proizvodnje, što može komplicirati rad lokalnog dispečera.

  • Metoda upravljanja rutnim listovima. Ova se postavka koristi pri upravljanju listovima puta koji se izvode u odjelu.

Mogućnosti:

  • "BBV/UBVV metodologija". Raspored izvršavanja ML-a generira se za ključne RC-ove; ML-om se nadzire prolazak preliminarnog i konačnog međuspremnika.
  • "Operativno planiranje". Raspored se generira za sve DC-ove i operacije lista ruta. Osim toga, morate pojasniti "Metoda planiranja"– “Naprijed” ili “Natrag”.

Skladišta (skladišni prostori)

Sa stajališta planiranja proizvodnje, skladište je objekt proizvodnog sustava koji zadovoljava potrebe proizvodnih odjela za materijalima i poluproizvodima.

Prilikom izračuna rasporeda generira se raspored potreba u skladištima materijala i poluproizvoda (artikal, karakteristike, količina, interval planiranja).

Skladište iz kojeg se proizvodna jedinica "napaja" prema zadanim postavkama određeno je detaljima jedinice.

Ali ne obrnuto: atribut “Podjela” u imeniku “Skladište” ne utječe na planiranje (i služi za računovodstvene svrhe).

Možete specificirati detaljniju definiciju skladišta nabave - za odjeljak i stavku, karakteristike izvorne komponente.

Brigade i sastav brigade

Tim je neposredni izvršitelj rada na pozornici (operacije) u radionici. Za obračun učinka zaposlenika prema Putnom listu, lokalni dispečer generira dokument „Brigadni nalog” u kojem navodi tim i vrste poslova koje je tim obavljao prema Putnom listu.

Tim čine djelatnici. Sastav brigade utvrđen je dokumentom “ Formiranje sastava brigade“, a vrijedi od datuma navedenog u dokumentu.

Ako je potrebno detaljizirati naredbe do pojedinih zaposlenika, tada se u imeniku „Brigade” formiraju brigade koje se sastoje od jednog zaposlenika.

Vrste radnih centara, radni centri

Vrste radnih centara namijenjene su opisu proizvodnog kapaciteta odjela. Vrste radnih centara imaju raspoloživi fond radnog vremena u planskim intervalima koji se popunjava kod raspoređivanja proizvodnih faza u intervale pri obračunu proizvodnog plana.

Prikaz radnog centra sastoji se od specifičnih radnih centara, kao što su dijelovi opreme. Sinonim za vrstu radnih centara je "Grupa međusobno zamjenjivih radnih centara".

Primjeri radnih centara:

■ Jedinica opreme

■ Radno mjesto

■ Skupina radnika (tim ili strukovno udruženje).

■ Zaposlenik

■ Jedinica opreme

Da bi se izračunao izvediv raspored proizvodnje koji odgovara maksimalnom protoku proizvodnje, potrebno je za faze specifikacije resursa dodijeliti vrste radnih centara koji se mogu učitavati u svakom odjelu, što može ograničiti protok faze.

Pojedinosti o vrsti radnih centara su sljedeće:

  • Oznaka "Planiraj rad". Ako je zastavica uključena, ova vrsta RC može se odabrati u fazi kao učitana vrsta RC. Oznaka je uključena za RC tipove divizije, koji se mogu pokazati kao "usko grlo" divizije.
  • Maksimalna dostupnost (sat, min, s). Određuje maksimalno trajanje obrade jedne šarže stupnja u intervalu odjeljka kojem tip RC pripada. Za jednu seriju stupnja, trajanje obrade ne može se dodijeliti u intervalu većem od maksimalne dostupnosti.

U trenutnoj verziji UP2, postavke za tipove RC, uz zadržavanje opisane suštine, već su se donekle promijenile. Sada možete koristiti potvrdne okvire za:

  • Treba li dostupnost DC vremena uzeti u obzir pri raspoređivanju na najvišoj razini? I ako je tako, hoće li se ovaj DC moći preuzeti ili ne.
  • Treba li DC biti uključen u upravljanje proizvodnjom korištenjem Route Sheets na nižoj razini?

Sljedeći dijagram prikazuje strukturu i odnos imenika “Struktura poduzeća”, “Vrste radnih centara”, “Radni centri”.

Unos dostupnog vremena radnog centra

Za unos fonda raspoloživog vremena radnih mjesta po intervalima koristi se dokument Raspoloživost radnih mjesta. U zaglavlju dokumenta odaberite odjel, vrstu radnog mjesta i razdoblje dokumenta.

Tablični dio dokumenta proširen je stupcima - intervalima podjele (npr. dana) u razdoblju dokumenta.

U retku tabelarnog dijela potrebno je odabrati radni centar koji pripada Tipu radnog centra, te intervalima stupaca označiti broj sati raspoloživosti za svaki interval.

Specifikacije resursa

Specifikacija resursa kao mrežni dijagram

Poznate su različite vrste specifikacija, na primjer, specifikacije dizajna, operativni dijagrami toka ruta, “workouts”, kao rute za prolazak dijela kroz odjele.

Najčešći način za opisivanje procesa proizvodnje bilo kojeg proizvoda je mrežni dijagram.

Specifikacija resursa opisuje mrežni raspored za proizvodnju proizvoda.

Mrežni čvorovi u ovom opisu su međusobno povezane faze proizvodnje, koje provode odjeljenja uzastopno ili paralelno u procesu proizvodnje proizvoda ili poluproizvoda. U jednom odjelu - izvodi se jedna ili više faza.

lukovi– međuovisnost između faza, pokazati, po završetku kojih faza mogu započeti sljedeće faze.

Mrežni dijagram je prikladan za opisivanje bilo kojeg proizvodnog procesa - u diskretnoj, kontinuiranoj proizvodnji, u građevinarstvu, u projektantskim aktivnostima.

Općenito, mrežni dijagram može sadržavati ne samo činjenice prijenosa proizvoda između odjela, već i činjenice prijenosa rezultata rada.

Rezultat rada koji se prenosi između radionica ne mora nužno imati materijalni izraz. Prijenos rezultata iz odjela u drugi odjel, kako bi drugi odjel odradio svoj dio posla, ne mora nužno uključivati ​​prijenos određenih proizvoda. Proizvod se može, primjerice, nalaziti u jednom odjelu ili premještati po potrebi, dok rad na proizvodu mogu obavljati drugi odjeli.

Faze proizvodnje mogu uključivati ​​ne samo proizvodnju proizvoda, već i pripremu proizvodnje, postavljanje opreme, razvoj dokumentacije, obuku, instalaciju i tako dalje.

U ekstremnom slučaju, specifikacija resursa može uključivati ​​sve faze proizvodnje proizvoda, u skladu s hijerarhijskim stablom strukture proizvoda. U najjednostavnijem slučaju, specifikacija resursa sastoji se od jednog proizvodnog koraka. Ova specifikacija resursa naziva se jednostupanjska.

Primjer specifikacije resursa kao mrežnog dijagrama s fazama čvora prikazan je u sljedećem dijagramu:

Struktura specifikacije izvora

Struktura specifikacije resursa kao konfiguracijskog objekta prikazana je na sljedećem dijagramu:

Specifikacija resursa sadrži:

■ popis izlaza,

■ popis ulaznih materijala,

■ popis troškova rada (po vrsti posla),

Za svaki input, output i input rada u višefaznoj specifikaciji resursa potrebno je naznačiti fazu u kojoj se input (input rada) troši ili output proizvodi.

Na ulazima faza naznačene su početne komponente (materijali, usluge) koje dolaze izvana u proizvodni proces, opisane specifikacijom.

To jest, to su one komponente koje, za dani stupanj, nisu izlazi drugih stupnjeva iste specifikacije.

Za unos materijala - poluproizvod možete uključiti oznaku " Proizvedeno u procesu» i sukladno tome odaberite specifikaciju resursa prema kojoj se ovaj poluproizvod mora proizvesti. Kao rezultat toga, ova specifikacija resursa bit će "dovršena" od ovog unosa "dolje" drugom specifikacijom resursa. Tako je moguće kreirati cjelovito stablo gotovih proizvoda iz pojedinačnih specifikacija, u obliku kaskade specifikacija.

Ova kaskada specifikacija koristi se prilikom generiranja specifikacije za određenu liniju proizvodnog naloga. Cijela kaskada srodnih sastavnica resursa kopira se u sastavnicu retka narudžbe.

U rekvizitima" Optimalna količina prijenosa između faza» možete odrediti količinu serije proizvoda (rezultat rada) koju je preporučljivo prenijeti između faza. Prilikom izračunavanja plana proizvodnje, količina stupnja je podijeljena u šaržne podatke, a svaka serija se planira zasebno, na temelju vremena raspoloživosti učitanih tipova DC.

Standardni intenzitet rada u specifikaciji resursa, kao iu tehnološkim operacijama karata ruta, naveden je u odjeljku " Vrste poslova».

Vrsta rada - analitika, prema kojoj se unose cijene rada za radnike, a uzima se u obzir učinak radnika. Naziv vrste posla može sadržavati, osim opisa samog posla, i traženu kategoriju radnika i njihovo zanimanje. Za vrstu rada navedena je mjerna jedinica, na primjer, sati ili komadi. proizvoda.

Za svaku vrstu rada u periodičnom registru podataka " Cijene» možete navesti trenutnu cijenu po jedinici vrste posla.

Faze specifikacije resursa

Specifikacija resursa može biti jednostupanjska ili višestupanjska.

Ako je specifikacija jednostupanjska, detalji o jednoj fazi uređuju se izravno u obrascu specifikacije. Ako je specifikacija višefazna, tada specifikacija sadrži popis faza. Za uređivanje pojedinosti o fazi morate otvoriti zaseban obrazac za fazu s popisa faza.

Redoslijed faza određen je detaljima faze: "Broj faze", "Broj sljedeće faze". Na temelju broja stupnja i broja sljedećeg stupnja grade se veze između stupnjeva u obliku mrežnog dijagrama stupnjeva.

Detalji pozornice određuju glavne parametre planiranja pozornice:

  • pododjel, u kojoj se pozornica izvodi. Za fazu je definirana samo jedna podjela. Ako se iste faze mogu izvesti u različitim odjelima, tada je potrebno izraditi različite specifikacije resursa
  • Količina proizvedena u jednom trenutku. R veličina serije ili obujam posla za koji je standardizirano vrijeme završetka faze. Na primjer, ako atribut specificira jedinicu, tada se vrijeme izvršenja faze normalizira na jedan.
  • Oznaka "Planirajte rad vrsta DC-ova". Određuje metodu normalizacije trajanja stadija.
    • Oznaka je omogućena. U stupnju je potrebno naznačiti koje vrste radnog mjesta će se opteretiti po stupnju i trajanje obrade istovremeno proizvedene količine na opterećenom tipu radnog mjesta. Ove vrste DC-a mogu se pokazati kao "uska grla" pri ispunjavanju rasporeda proizvodnje, pa se izračunava njihovo opterećenje u rasporedu. Osim toga, potrebno je naznačiti preliminarno (prije obrade na učitanom RC pogledu) i konačno vrijeme međuspremnika. Međuspremnici zauzimaju zasebne intervale u rasporedu proizvodnje. Podsjetimo se da ako je vrijeme obrade prije ili nakon vrste učitavanja RC-a mnogo kraće od trajanja intervala, tada određivanje vremena međuspremnika može dovesti do neopravdanog hvatanja cijelih intervala međuspremnicima i, sukladno tome, do neopravdanog povećanja međuspremnika trajanje faze u rasporedu proizvodnje.
    • Zastava je isključena. Faza označava vrijeme koje je potrebno da se dovrši, za bilo koju količinu serije. Vjeruje se da će za to vrijeme etapa biti završena u svakom slučaju, bez obzira na broj u etapi. Zastavica se može isključiti u fazama, čije izvršenje nije vezano za obradu na učitanim tipovima RC („tzv. „uska grla“); sukladno tome, smatra se da odjel pri izvođenju takve faze ima (relativni odjelima s “uskim grlima”) neograničen proizvodni kapacitet.
  • Zastava « Stalan» faza određuje može li se izvedba faze podijeliti u nekoliko nesusjednih intervala u rasporedu.
    • Ako je zastavica uključena, tada se faza izvršava kontinuirano i može se nalaziti u rasporedu samo u susjednim intervalima.
    • Ako je zastavica isključena, tada se izvođenje faze može prekinuti, odnosno dio vremenske faze može se nalaziti u rasporedu u jednom intervalu, a dio - u drugom, koji nije susjedan prvom intervalu.

Kriterij kontinuiteta – najmanje jedna operacija unutar faze je kontinuirana i usporediva s trajanjem intervala. Te operacije uključuju, na primjer, toplinsku obradu, bojanje, sušenje i tako dalje.

Razlika između "diskontinuiranih" i "kontinuiranih" faza planiranja prikazana je na sljedećem dijagramu.


Konfiguracijske uloge podijeljene su u sljedeće skupine:
Proizvodnja
Trgovina i skladištenje
Financije


Analiza i planiranje
Regulirano računovodstvo
Postavljanje matičnih podataka
Trgovačka oprema
Upravni
Servis

Proizvodnja

* Shift master - daje prava za unos operativnih proizvodno knjigovodstvenih podataka.
* Pregled podataka o operativnom knjigovodstvu proizvodnje - daje prava za pregled izvješća o podacima o operativnom knjigovodstvu proizvodnje.
* Certifikacija – daje prava za rad s podsustavom certifikacije.
* Tehnolog – daje prava za unos podataka iz regulatornog proizvodnog sustava.
* Shop Economist – daje prava za formuliranje operacija upravljanja proizvodnjom u upravljačkom računovodstvu.

Trgovina i skladištenje

* Skladištar - daje prava registracije skladišnog poslovanja za upravljačko računovodstvo.
* Upravitelj naloga - daje prava za rad s podsustavom naloga. Može se koristiti i samostalno i u kombinaciji s drugim ulogama.
* Voditelj nabave – daje prava za rad s podsustavom za upravljanje nabavom.
* Voditelj prodaje – daje prava za rad s podsustavom upravljanja prodajom.
* Maloprodaja – daje prava za registraciju dokumenata o maloprodaji, uloga nije neovisna – koristi se zajedno s ulogom “Voditelj prodaje”.
* Određivanje cijena – daje prava za rad s podsustavom određivanja cijena.

* Bankarsko poslovanje - daje prava za obavljanje poslova s ​​bankovnim dokumentima.
* Unos zahtjeva za utrošak sredstava - daje pravo na registraciju dokumenata “Zahtjev za utrošak sredstava” i “Zatvaranje zahtjeva za utrošak sredstava”.
* Obračun plaća - uloga se postavlja zajedno s ulogama "Blagajnik", "Bankovno poslovanje". Uloga daje prava za registraciju dokumenata: o "Prijemni nalog" s vrstama operacija:
- Povrat od strane zaposlenika
o "Blagajnički izdatak" s vrstama prometa:
- Obračuni po kreditima i pozajmicama sa zaposlenicima
- Isplata plaća prema izvodima
- Isplata plaće zaposleniku
- Isplata položenih plaća
- Izdavanje novca u blagajnu
o "Izlazni platni nalog" s vrstama operacija:
- Obračuni po kreditima i pozajmicama sa zaposlenicima
- Prijenos plaća

* Blagajnik - daje pravo na registraciju gotovinskih dokumenata.
* Razmjena podataka s Client-Bank programima - postavlja se korisniku ako mu je potrebna mogućnost korištenja Client-Bank obrade.
* Odgovorne osobe - daje pravo na registraciju dokumenata za odgovorne osobe.
* Odobravanje zahtjeva za izdatke DS - daje prava na odobravanje zahtjeva.
* Financijer – daje prava za formiranje gotovinskih transakcija u upravljačkom računovodstvu.

Plaće i upravljanje ljudskim resursima

* Kadrovski upravitelj reguliranih podataka - daje prava za rad s kadrovskim dokumentima za organizacije, personaliziranim i vojnim evidencijama zaposlenika poduzeća i standardnim rasporedima poduzeća.
* HR menadžer podataka za upravljanje - daje prava za rad s kadrovskim dokumentima za poduzeće, dokumentima o obuci, planiranju i odobravanju godišnjih odmora te upitnicima.
* Voditelj zapošljavanja - daje prava za rad s kandidatima, s podsustavom upitnika, s kadrovskim planom poduzeća.
* Kalkulator reguliranih plaća - daje prava za izračun reguliranih vremenskih razgraničenja, obračun poreza i kreiranje plaća u računovodstvu.
* Kalkulator plaća menadžera – pruža prava za izračun obračuna menadžerskih obveza.

Dugotrajna imovina i radna odjeća

* Računovodstvo dugotrajne imovine i nematerijalne imovine - daje pravo formiranja poslovanja s dugotrajnom imovinom (uključujući upravljanje održavanjem opreme) i nematerijalnom imovinom u upravljačkom računovodstvu.
* Računovodstvo radne odjeće - daje prava na objekte podsustava "Radna odjeća i specijalna oprema".

Analiza i planiranje

* Budgeting – daje prava za rad s proračunskim podsustavom.
* Planiranje – daje prava za rad s podsustavom planiranja.
* Troškovno računovodstvo - daje prava na podatke o troškovnom računovodstvu i troškovima proizvoda za upravljanje i regulirano računovodstvo.

Regulirano računovodstvo

* IFRS računovođa - daje prava za formuliranje poslovnih transakcija u IFRS.
* Izvršenje rutinskih operacija za regulirano računovodstvo - daje prava za provođenje regulatornih dokumenata za regulirano računovodstvo (BU i NU).
* Formiranje u reguliranom računovodstvu - daje prava na izradu dokumenata za računovodstveno i porezno knjigovodstvo, te prava na izradu izvještaja računovodstvenog podsustava. i gotovinu računovodstvo.
* Pogledati podatke reg računovodstvo - daje prava čitanja računovodstvenih podataka. i gotovinu računovodstvo, te prava na izradu izvještaja računovodstvenog podsustava. i gotovinu računovodstvo.
* Regulirano izvješćivanje - pruža prava za primjenu reguliranog izvješćivanja.
Uloga se koristi zajedno s ulogom "Formiranje u reguliranom računovodstvu".
* Pravo na siguran protok dokumenata s regulatornim tijelima (Savezna porezna služba, Mirovinski fond) - daje pravo na korištenje ugrađenog algoritma za informacijsku interakciju s regulatornim tijelima (Savezna porezna služba i
Mirovinski fond) putem komunikacijskih kanala. Uloga je postavljena zajedno s jednom od uloga: "Regulirano izvješćivanje",
"HR stručnjak reguliranih podataka" ili "Kalkulator reguliranih plaća".
* PDV računovodstvo - daje prava na objekte PDV podsustava, obavljanje rutinskih PDV operacija i generiranje PDV izvješća.
* Računovodstvo za financijsko računovodstvo - daje prava na obračun budućih troškova.

Postavljanje matičnih podataka

* Postavljanje glavnih podataka - daje prava na zajedničke objekte, na primjer, skladišta, odjele, računovodstvene politike
(upravljano računovodstvo).
* Postavljanje matičnih podataka troškova - daje prava na podatke podsustava "Upravljanje troškovima".
* Postavljanje matičnih podataka (reg) - daje prava na podatke vezane uz regulirano računovodstvo.

Trgovačka oprema

* Administrator blagajne - daje prava za konfiguriranje blagajničkih blagajni i zatvaranje blagajničke smjene.
* Korištenje komercijalne opreme - postavlja se korisniku ako mu je potrebna mogućnost korištenja komercijalne opreme.
* Postavljanje komercijalne opreme - postavlja se korisniku ako mu je potrebna mogućnost konfiguracije komercijalne opreme.
* KKM operater - daje pravo registracije maloprodajnog dokumenta “KKM Potvrda”.

Upravni

* Administrator korisnika - daje prava za upravljanje korisnicima.
* Puna prava - omogućuje pristup svim konfiguracijskim objektima i dodjeljuje se za izvođenje servisnih operacija: o ažuriranje informacijske sigurnosti o brisanje objekata označenih za brisanje o rad s dnevnikom predaje o itd.
Ne preporuča se stalni rad u sustavu pod ulogom “Puna prava”, uključujući obavljanje poslovnih operacija.
* Postavljanje datuma zabrane izmjene podataka - postavlja se korisniku ukoliko treba imati mogućnost postavljanja datuma zabrane izmjene podataka.
* Pravo upravljanja - daje se korisniku ukoliko ima potrebu za obavljanjem isključivo administrativnih poslova i poslova.

Servis

* Administracija dodatnih obrazaca i obrada - postavlja se korisniku ako treba promijeniti imenik "Vanjska obrada".
* Administracija spremljenih postavki - postavlja se korisniku ako treba upravljati spremljenim postavkama izvješća izgrađenih na temelju univerzalnog.
* Pravo vanjske veze - daje se korisniku ako treba raditi s infobazom preko vanjske veze.
* Pravo na prikaz informacija - postavlja se korisniku ako mora moći prikazati verzije za ispis, kopirati generirane verzije za ispis u međuspremnik ili ih spremiti kao vanjske datoteke.
* Pravo pokretanja vanjskih izvješća i obrada - daje se korisniku ukoliko mu je potrebna mogućnost otvaranja vanjskih izvješća i obrada.
Ulogu treba dodijeliti samo kompetentnim zaposlenicima:
Korištenje vanjskih izvješća ili obrada može predstavljati prijetnju sigurnosti podataka sustava u obliku: uništavanja (zlonamjernog ili zbog nesposobnosti), neovlaštenog pristupa.
* Pravo korištenja e-pošte - postavlja se korisniku ako treba raditi s ugrađenom e-poštom.
* Pregled kretanja dokumenta - dodjeljuje se korisniku ako treba vidjeti kretanje dokumenta (u upravljanoj aplikaciji).
* Pregled strukture podređenosti - postavlja se korisniku ako treba vidjeti strukturu podređenosti dokumenata (u upravljanoj aplikaciji).

U konfiguraciji je također dodijeljena uloga "Korisnik". Ova uloga daje pristup za ulazak u program i automatski se dodjeljuje svim korisnicima (prilikom promjene korisničkih uloga u Enterprise verziji).

Učinkovitost poduzeća u strojarskoj industriji uvelike ovisi o tome koliko je dobro organiziran rad s referentnim informacijama (RNI). IT direktor grupe Oleg Apanasik trenutno govori o projektu implementacije sustava referentnih podataka u grupi tvrtki AEM-Technologies i njegovoj upotrebi.

Inteligentno poduzeće: Koji su bili glavni ciljevi pri implementaciji matičnih podataka i na koje glavne faze se može podijeliti rješenje ovog zadatka?

Oleg Apanasik: Odluka donesena za implementaciju temelji se na iskustvu naših zaposlenika u upravljanju regulatornim i referentnim informacijama. Sve je počelo s potrebom da se centralizira upravljanje imenikom osnovnih materijala i komponenata na dva proizvodna mjesta iu društvu za upravljanje. Izradili smo dva standarda poduzeća i nekoliko uputa za rad, no svaki put su se u informacijskim sustavima pojavljivali materijali koji nisu uneseni u skladu s regulatornim dokumentima ili duplikati postojećih zapisa.

A krajem 2014. pokrenuli smo projekt optimizacije rada s regulatornim i referentnim informacijama. U okviru njega razvijene su metode za normalizaciju nekoliko glavnih grupa imenika - "Nomenklatura", "Druge strane", "Zaposlenici", "Financijski" i "Tehnološki" - kao i metode za njihovo upravljanje.

Organizacijski okvir projekta uključivao je glavno poduzeće naše tvrtke, smješteno u gradu Kolpino, i dvije podružnice - Petrozavodskmash i Atommash iz Volgodonska.

Nacrt projekta uključivao je veliki broj sustava, koje je sasvim prikladno podijeliti u posebne skupine.

Prije svega, riječ je o cijelom nizu univerzalnih primijenjenih poslovnih sustava. Riječ je o dva rješenja za upravljanje resursima poduzeća - SAP ERP i 1C:UPP te dva za upravljanje kadrovima - SAP HR i 1C:ZUP. To bi također trebalo uključiti upravljanje elektroničkim dokumentima na temelju "1C: Tijek dokumenata", proizvod "1C: Konsolidacija", kao i razvoj za računovodstvo troškova mobilnih komunikacija "1C: Mobile Communication". Osim toga, krug je uključivao proizvode specijalizirane za naše proizvodne aktivnosti: TeamCenter (Siemens PLM Software), odgovoran za projektiranje i tehnološku pripremu proizvodnje, sustav za održavanje arhive tehničke dokumentacije poduzeća i upravljanje podacima o proizvodima Pretraga tvrtke Intermech , sustav za upravljanje referentnim i informacijskim bazama podataka IMBASE podataka istog proizvođača te sustav za upravljanje i kontrolu pristupa Perco. Infrastrukturni proizvodi također su bili uključeni - kontroler domene ActiveDirectory i korporativni portal MS SharePoint.

Koje su univerzalne metode obrade informacija korištene za rješavanje zadanih problema - recimo čišćenje podataka, pretraživanje teksta, hijerarhijska ili druga klasifikacija, parametrizacija podataka, nešto drugo? Sve što ste upravo naveli odnosi se na tehničke metode provjere ispravnosti formiranja imeničkih zapisa u skladu s unaprijed dogovorenim pravilima. Ovdje govorimo o takozvanom “fool-proofingu”, a na razini potrebnoj za rad sa sustavom matičnih podataka, to se može implementirati u bilo koji računovodstveni sustav. Puno je teže dogovoriti pravila vođenja imenika. Na primjer, za nomenklaturu je važno da naziv odgovara regulatornom dokumentu, a to je učinkovito kada radimo prema GOST, OST ili TU. Ali ako kupac traži korištenje materijala prema standardima koji su prestali vrijediti u zemlji ili prema katalozima proizvođača, uključujući strane, tada se pojavljuju kontroverzna pitanja koja bi trebala biti opisana unaprijed. Skup ovih pravila temelji se na metodama i standardima za upravljanje matičnim podacima.

Bilo bi zanimljivo čuti o metodološkim naglascima u radu s normativnim i referentnim informacijama...

Za uspješan rad sustava za upravljanje matičnim podacima važno je provesti, po meni, najdužu fazu u projektu - normalizaciju podataka. Prije nego što je započeo projekt implementacije upravljanja matičnim podacima (MDM sustavi), čija je osnovna funkcija zapravo upravljanje matičnim podacima, tvrtka je dugi niz godina koristila različita računovodstvena, proizvodna rješenja, kao i sustave dizajna, za koje pohranjujemo golemu količina raznih referentnih informacija . A naša je prirodna želja bila sačuvati i koristiti prikupljene podatke, ali u skladu s novorazvijenom metodologijom. U tu svrhu bila je potrebna normalizacija podataka.

Navest ću glavne ciljeve kojima smo težili.

Prvo, svaki unos imenika mora se odnositi na određenu klasu glavnog klasifikatora, i to na način da se za te unose unose vrijednosti obveznih karakteristika ove klase.

Drugo, svakom zapisu se dodjeljuje unificirano ime.

Treće, vrijednosti atributa svakog unosa imenika unose se u skladu s odobrenom metodologijom upravljanja.

Četvrto, ne bi trebalo biti dvostrukih unosa u imeniku.

I konačno, peto, potrebno je da svaki unos imenika ima jedinstveni kod koji jedinstveno razumiju svi korisnici i aplikacijski sustavi koji pristupaju imeniku.

Sam proces normalizacije također je podijeljen u nekoliko faza.

Na pozornici pripremni rad Konfiguriraju se klasifikatori i utvrđuju pravila za obradu “sirovih” podataka.

sastoji se u činjenici da se sve datoteke prenesene iz pretplatničkih sustava, čiji je format u skladu s imeničkim podacima, učitavaju u MDM sustav. Tijekom preuzimanja ne vrši se obrada ili analiza podataka.

Na pozornici prethodna obrada neobrađenih podataka Skupovi podataka se generiraju, "sirovi" podaci se distribuiraju među stručnjacima, razrađuju se pravila za njihovu obradu i grade se baze za obuku.

Klasifikacija "sirovih" zapisa provodi se u dvije faze: neobrađeni zapis se dodjeljuje jednoj ili drugoj klasi, a za svaku odabranu klasu utvrđuje se vrijednost karakteristika.

Formiranje referentnog zapisa: nakon klasifikacije, referentni zapis se traži prema vrijednosti klase i skupu karakterističnih vrijednosti, a ako se zapis pronađe, tada se "sirovi" zapis odnosi na njega. Ako referentni zapis nije pronađen, tada se kreira sa specificiranom vrijednošću klase i karakteristikama.

Obrada podataka MDM sustava u sustavu pretplatnika - U ovoj fazi ažuriraju se postojeći zapisi objekata matičnih podataka u sustavu pretplatnika ili se dodaju novi.

Napominjem da je srce MDM sustava Ontology server (razvijen od strane ruske tvrtke AXELOT), koji služi kao inteligentni pomoćnik stručnjaku za referentne podatke. U fazi klasifikacije poziva stručnjaka da odabere klasu koja je primjerena danoj situaciji i za odabranu klasu predlaže vrijednosti karakteristika.

Ali integracijska sabirnica odgovorna je za razmjenu podataka s pretplatničkim sustavima, koja povezuje objekte u različitim sustavima pomoću MDM kodova.

Postoje li specifičnosti izgradnje sustava za upravljanje referentnim podacima za velika strojograđevna poduzeća i od čega se sastoji?

Osobitost ove konstrukcije nije u veličini poduzeća, već u broju informacijskih sustava koji rade u poduzeću i količini korištenih referentnih knjiga. Vrsta proizvodnje također utječe na to kako radite sa sustavom. Ako je riječ o izradi proizvoda u pojedinačnim primjercima, tada se novi unosi u imenik materijala ili opreme upisuju češće nego u serijskoj proizvodnji, pa sukladno tome pravila izrade unosa moraju biti strogo regulirana. U našoj se tvrtki svaki mjesec samo u imenik „Nomenklatura” unese do tisuću novih unosa, tako da stručnjaci NSI-a nemaju vremena dalje raspravljati o ispravnosti imenovanja materijala.

Koji se elementi u ovom slučaju odnose na sustav matičnih podataka koji ste izgradili - materijale, alate, operacije, kvalifikacije osoblja, dobavljače ili druge komponente?

Naš projekt je razvio metodologiju za vođenje određenog broja imenika, podijeljenih u pet skupina: nomenklatura, ugovornih strana, zaposlenici, financijski i tehnološki. Ako govorimo o referentnim knjigama koje čine ove skupine, one doista opisuju te komponente koje ste upravo spomenuli, kao i mnoge druge. Na primjer, u odjeljku "Nomenklatura" nalaze se imenici kao što su "Osnovni materijali", "Alati", "Oprema i inventar", "Proizvodi". U odgovarajućim grupama nalaze se direktoriji pod nazivom “Druge strane”, “Zaposlenici”, “Radna mjesta”, “Radni centri” ili, recimo, “Stavke novčanog toka”. Ukratko, imamo više od dvadeset priručnika, koji vrlo detaljno pokrivaju sve aspekte djelovanja tvrtke AEM Technologies, bilo da se radi o financijskim, proizvodnim aktivnostima ili upravljanju osobljem. Štoviše, u slučaju rada s imenicima nomenklature, izvor podataka je MDM sustav, a pretplatnici su računovodstveni sustavi i sustavi za projektiranje. Ali kada radite s imenikom "Zaposlenici", izvor je sustav za upravljanje osobljem, a MDM sustav igra ulogu pretplatničkog sustava i integracijske sabirnice za računovodstvene sustave.

Tradicionalno, jake i stabilne veze s dobavljačima materijala i komponenti, uključujući informacijske, važne su za velika strojarska poduzeća. Postoji li potreba za nekakvim usklađivanjem sustava matičnih podataka sa sličnim sustavima vaših partnera?

Nismo si postavili zadatak integracije sa sustavima dobavljača. I budući da smo otišli do kraja da normaliziramo podatke na tri lokacije u našoj tvrtki, mislim da je to malo vjerojatno. Za nas je važno da nakon što je stavka navedena u materijalnoj izjavi uključena u tehničku specifikaciju za nabavu, iz nje - u specifikaciju ugovora, a zatim je naznačena u dokumentima o primitku, sukladno tome pristižući u naše skladište, i otpisan za određeni proizvodni nalog. Takvi predmeti moraju biti nedvosmisleno identificirani u svim fazama, neovisno o tome gdje je izrađen popis materijala, tko je bio uključen u nabavu i gdje se odvija proizvodnja.

Što je IT podrška za referentne podatke, koje su tu ključne funkcije i kako ju je preporučljivo implementirati u proizvodnom i organizacijskom smislu?

Naravno, uvođenjem novog informacijskog sustava za IT odjel dodaje se i funkcija podrške. No, tu nema ništa novo: osiguravanje nesmetanog rada, backup podataka, obuka korisnika, izrada pravilnika i uputa za rad, izmjena postojećih funkcionalnosti na temelju zahtjeva korisnika i dokumentacije. Integracija podataka, rad s kojima u početku nije bio uključen u projekt, predstavlja određene poteškoće, ali ovdje blisko surađujemo s našim izvođačima.

Ako ukratko govorimo o proizvodnoj i organizacijskoj strani problema, onda je naš ključni proizvod IT podrške bio 1C:MDM Reference Information Management, kao i Axelot Datareon ESB. Axelot je bio glavni implementacijski partner.

Mnogi odjeli tvrtke uvijek su zainteresirani za razvoj sustava regulatornih i referentnih informacija. Kako se taj interes može bolje uzeti u obzir u strukturi upravljanja projektom?

Stručnjaci NSI-a imaju posebnu ulogu kako u projektu implementacije tako iu kasnijem radu MDM sustava. Uspjeh projekta 80% ovisi o njihovoj lojalnosti, radnoj sposobnosti i stručnim kompetencijama. Oni su ti koji određuju pravila rada s informacijama. Štoviše, radi se o djelatnicima iz raznih područja: za grupu direktorija “Nomenklatura” i “Tehnološki” to je tehnička direkcija, za grupu “Druge strane” - ured, za direktorije “Financije” - računovodstvo i financijeri, za “ Zaposlenici” - Uprava za upravljanje kadrovima. Uloga IT službe u razvoju projekta je pomoć u prikupljanju ili formuliranju zahtjeva, koordinacija prikupljenih podataka sa svim sudionicima u poslovnom procesu, osiguranje tehničke implementacije i daljnja podrška alata za vođenje imenika. No, vlasnik procesa upravljanja matičnim podacima je poslovanje, a samo o poslovnim korisnicima ovisi hoće li se taj proces razvijati ili ne.

S Olegom Apanasikom razgovarao je vodeći stručnjak za Intelligent Enterprise Sergej Kostjakov



mob_info