Erinevused nsi juhtimissüsteemide vahel. Nsi iseloomulikud tunnused. Põhiandmete ja MD metaandmete vastuolu

UDK 004.37.01

Oh. Žiljajev ,
Informaatika Instituut ja
piirkondliku juhtimise probleemid
KBSC RAS, uurija, Naltšik.

Sissejuhatus

Ühtse inforuumi loomine on vajalik tingimus erinevate objektide efektiivseks haldamiseks, olgu selleks siis ettevõte, osakond, piirkond või riik. Ühtse keskkonna kujunemine hõlmab juhtimisprotsesside integreerimist, millega kaasneb infovoogude normaliseerimine. Sageli toetavad info liikumist erinevatel tasanditel ja juhtimisobjekti osadel erinevad info- ja arvestussüsteemid. Sellest tulenevalt on vajadus need süsteemid integreerida. Maailmamajanduse kasvavad globaliseerumisprotsessid on oma olemuselt integratsiooniprotsessid. Sellised integratsiooniülesanded on Venemaa jaoks eriti aktuaalsed seoses tema eelseisva ühinemisega Maailma Kaubandusorganisatsiooniga (WTO).

Info- ja arvestussüsteemide integreerimise ülesanne koosneb kahest omavahel seotud osast: andmete integreerimine ja sellele järgnev rakenduste integreerimine. Andmete integreerimise teostamisel on vajalik normatiiv- ja viiteteabe (RNI) ühtlustamine ja standardiseerimine. .

Põhiandmed on tinglikult püsiv osa kogu infosüsteemis (IS) olevast infost, erinevalt jooksvast infost, mis tekib vahetult IS-is töötamise käigus. Põhiandmete hulka kuuluvad: kataloogid, sõnastikud, lineaarsed ja hierarhilised loendid, klassifikaatorid, registrid, kodifitseerijad, mille andmeid kasutatakse jooksvate dokumentide genereerimisel.

Sellise viiteinfo tähistamiseks ingliskeelses kirjanduses kasutatakse mõistet Master Data (põhiandmed, põhiandmed), mille haldamise ülesandeid nimetatakse aga põhiandmete haldamiseks (MDM). nüüd on sagedamini kasutusel info (RNI) ), mis ilmus majandusjuhtimisega seotud erialadel juba arvutieelsel ajal. Sel juhul peegeldab "normatiivse" määratlus tõsiasja, et kataloogide loomise probleem tuleb lahendada, võttes arvesse tööstuse, riigi ja rahvusvahelisi standardeid.

Kui tänapäeval on tuttavaks saanud sellised mõisted nagu näiteks ACS (Automated Control Systems) või IS (Information Systems), siis lühend “SU NSI” (Regulatory Reference Information Management System) tekitab sageli segadust. Isegi selle dekodeerimise taga peituvat tähendust mõistavad sageli ainult spetsialistid. NSI ei ole lihtsalt andmebaas, vaid keerukalt organiseeritud süsteem, millel on palju ristviiteid üksikute kataloogide ja klassifikaatorite vahel. Eriti oluline on võrdlusteabe asjakohasuse säilitamise mehhanism. Teabe täielikkuse, täpsuse ja asjakohasuse nõuded võrdlusandmete süsteemis on palju rangemad kui tavapärases andmebaasis, kuna mis tahes infosüsteemi, sealhulgas automatiseeritud juhtimissüsteemide töötamise ajal sõltub rakendusülesannete infosisu viiteandmetest. andmeid. Põhiandmed on kogu infosüsteemi “vundament” ja selle haldamine peaks olema tsentraliseeritud. Joonisel 1 on võrdlusandmed näidatud kui kogu IS-i struktuuri alumine tase, "teabe alus".

Riis. 1 Infosüsteemi tasemed

Just võrdlusandmete süsteemi tsentraliseeritud haldamine, mille suhtes kehtivad ühtsed regulatsioonid ja mida pakub ühtne tehnoloogiline keskkond, võimaldab säilitada kõigi selle koosseisu kuuluvate teatmeteoste ja klassifikaatorite andmete ühtsuse, täielikkuse, terviklikkuse ja asjakohasuse. Seetõttu omada tõhusalt töötavat IS-i, mis lahendab tegelikud probleemid.

Põhiandmete haldamise täisväärtusliku tarkvara väljatöötamine algas alles paar aastat tagasi. Juhtivad tarkvaratootjad on viimasel ajal pööranud üha enam tähelepanu põhiandmete haldamise tööriistadele (ingliskeelses versioonis MDM, Master Data Management - master data management).

Integratsiooniprobleemide lahendamist on raske ette kujutada ilma võrdlusandmete tsentraliseeritud haldamiseta. Põhiandmete haldamise probleem tekib isegi sellistes automatiseeritud ja infotoega struktuurides nagu pangad või kindlustusseltsid. Põhiandmete haldussüsteemid võimaldavad mitte ainult koguda andmeid mitmest integreeritud pangasüsteemist, näiteks genereerida aruandeid mitmele raamatupidamissüsteemile; vaid ka etalonandmete operatiivjuhtimise probleemide lahendamiseks.

Venemaal puudub GOST-iga sarnaste võrdlusandmete moodustamise keskus. Ja kuigi hiljuti jõustusid uued elektrooniliste tehniliste dokumentide väljatöötamise ja ringlusega seotud seadused, ei ole need olukorrale veel märgatavat mõju avaldanud.

NSI roll piirkonna informatiseerimisel

Meie riigi infotehnoloogiasektori arengustrateegia elluviimisel on oluline roll regionaalsel informatiseerimisel. Viimasel ajal on Vene Föderatsiooni moodustavates üksustes intensiivistunud töö infotehnoloogia kasutamise kallal kõigis piirkondliku elu valdkondades. Seda soodustas mitmete föderaalvalitsusorganite ürituste elluviimine ja infotehnoloogia kasutamise valdkonda reguleerivate dokumentide vastuvõtmine föderaal-, osakondade, piirkondlikul ja omavalitsuse tasandil. Üks sellistest dokumentidest, mille eesmärk on aidata lahendada piirkonna igakülgse informatiseerimise probleeme, on Vene Föderatsiooni valitsuse määrus “Põhiklassifikaatorite, kataloogide ja registrite moodustamise ja kasutamise korra kohta riigi- ja munitsipaalteenuste osutamisel. teenused elektroonilisel kujul” 31. augustil 2010. a.

Eriline roll võrdlusandmetele on määratud ka tööstuste ja osakondade informatiseerimisprogrammidele. Näiteks 31. märtsil 2010 avaldatud. Tervishoiu informatiseerimise kontseptsiooni eelnõus rõhutatakse eelkõige, et tervishoiu infosüsteemid tuleks kujundada standardeid ja regulatsioone arvestades ning põhinema ühtsetel võrdlusandmetel. (Vene Föderatsiooni tervishoiu, sotsiaalse arengu ja töösuhete valdkonnas kasutatav NSI sisaldab kokku 163 erinevat klassifikaatorit ja teatmeraamatut).

Piirkondlikul tasandil on automatiseeritud haldussüsteemides põhiandmete infrastruktuuri juurutamise eesmärk Vene Föderatsiooni moodustava üksuse riiklikes (kohalikes) infosüsteemides kasutatavate kataloogide ja klassifikaatorite ühtse süsteemi loomine, samuti moodustamine. raamatupidamise põhiregistrid, mis tagavad regionaalse juhtimise põhiobjektide kohta edastatava teabe kogumise ja säilitamise. Põhiandmete haldussüsteem, olles tsentraliseeritud hoidla ja ainus ühiste põhiandmete tarnija piirkonna kõigi infrastruktuuride ja osakondade infosüsteemide jaoks, peab tagama kohalike infosüsteemide ja teema „elektroonilise valitsemise“ rakenduste infoühilduvuse.

Ilmselt peaks Venemaa Föderatsiooni infotehnoloogia arendamise järgmine samm olema osakondade, piirkondlike ja kohalike omavalitsuste infosüsteemide integreerimine föderaalsel tasandil. See valitsuse infosüsteemide integreerimise ülesanne on sedavõrd keerukas, et lisaks dokumentide standardiseerimisele (näiteks XML-i baasil) ja integreerimise infrastruktuurile tarkvara näol, XML-dokumentide marsruutimisele on valitsuse jõupingutusi vaja ka andmekirjelduste standardimise vallas.

Selle valdkonna algatuse näide on Ühendkuningriigis vastu võetud e-GMS (UK GoverNmeNt Metadata StaNdard) standard. . Paljud riigid on võtnud aluseks niinimetatud Dublini tuuma, mis sisaldab 15 teabekirjelduse elementi:

• pealkiri;
• autor või looja;
• teema ja märksõnad;
• kirjeldus;
• kirjastaja;
• teised panustajad;
• kuupäev;
• ressursi tüüp;
• formaat;
• ressursi identifikaator;
• allikas;
• keel;
• side;
• pindala (katvus);
• õiguste haldamine.

Lisaks elementidele endile on “Dublini tuumas” elementide nn täpsustused, näiteks: “Loomiskuupäev”, “Avaldamise kuupäev”, “Aegumiskuupäev” jne. Riigid ei saa kasutada ainult seda tuuma, kuid lisage ka täiendavaid elemente, mida nad vajalikuks peavad. Lisaks on teabe otsimisel esimene tööriist tavaliselt kategooriate sirvimine. Seetõttu määratlevad valitsuse metaandmete standardite algatused kategooriate loendi standardeid (peamine otsingutööriist ilma märksõnu kasutamata).

järeldused

Tutvudes õigusaktidega, mille eesmärk on reguleerida riigi- ja munitsipaalteenuste osutamist elektroonilisel kujul ning korraldades osakondadevahelist teabevahetust riigi ja omavalitsuste tasandil, näete:

• osakondadevahelise teabevahetuse tagamiseks vajalike riigi infosüsteemides kasutatava infotehnoloogia ja tarkvara standardimise kohustuslike nõuete tegelik puudumine normatiivaktides;
• ühtsete selgete nõuete puudumine normatiivaktides osakondadevahelises teabevahetuses kasutatavate infosüsteemide kataloogidele, klassifikaatoritele ja andmeskeemidele;
• Regulatiivsetes õigusaktides puuduvad elektroonilised teabe ja avalike teenuste osutamise mehhanismid, mis on ühtsed ja kohustuslikud kõigi föderaal-, piirkondlike ja munitsipaalasutuste jaoks. .

Tänapäeval on nii Vene Föderatsioonis kui ka välismaal suurimad raskused riigi-, piirkondlikul ja kohalikul tasandil elektrooniliste teenuste osutamise projektide ning sarnaste osakondadevaheliste projektide elluviimisel tingimustes, kus andmete integreerimiseks on vaja teha suuri jõupingutusi. ja rakendused, ei seisne mitte teatud spetsiifiliste tehnoloogiate kasutamises, vaid asjakohaste standardite vastuvõtmise protsessi korraldamises ning erinevate organisatsioonide ja osakondade infotehnoloogiliste arhitektuuride ühtlustamises.

Osariigi, piirkondlikul, kohaliku omavalitsuse ja osakondade tasandil elektrooniliste teenuste osutamise valdkonna projektid, mida viivad läbi erinevate riikide valitsused, näevad ette järgmist tüüpi standardeid:

• andmestandardid;
• osakondadevahelise teabevahetuse standardid;
• metaandmete (ja teabeotsingu) standardid;
• ohutusstandardeid.

Vaja on ühtset kaasaegset põhiandmete pidamise metoodikat, vastasel juhul muutub andmemahu kasvades süsteem juhitamatuks.
Teatmeteoste ja klassifikaatorite täitmise eeskirjad ja metoodika peavad olema üksikasjalikult lahti kirjutatud, vastasel juhul on väga raske tagada ekspertide kvaliteetset ja korrapärast tööd võrdlusandmete säilitamisel. Vaja on selgelt piiritleda võrdlusandmete kasutajate ja selle haldamise ekspertide pädevus- ja vastutusvaldkonnad.

Vaja on ülitõhusat kaasaegset tehnoloogiat ja etalonandmete haldussüsteemi, mis lahendab mitme kasutaja juurdepääsu probleemile koos võimude füüsilise lahususe võimalusega, rakendab kasutajate suhtlust ekspertidega ning tagab süsteemi hõlpsa skaleerimise nii võimsuse suurendamisel. viiteandmebaas ise ja teenindusekspertide arv.

Kirjandus:
1. "Vene Föderatsiooni infoühiskonna arendamise strateegia" (kinnitatud Vene Föderatsiooni presidendi poolt 7. veebruaril 2008 nr Pr-212);
2. Vene Föderatsiooni valitsuse 31. augusti 2010. aasta otsuse eelnõu "Põhiklassifikaatorite, kataloogide ja registrite moodustamise ja kasutamise korra kohta riigi- ja munitsipaalteenuste osutamisel elektroonilisel kujul".
3. “NSI ülevaade”, Majandusarengu Ministeeriumi väljaanne, 2010
4. "Tervishoiu infosüsteemi loomise kontseptsioon perioodiks kuni 2020", 2010. a.
5. Polotnjuk I."Metaandmed integreerimise alusena", PC Week/RE (492), 2005.
6. Ray Wang, Rob Karel."Trendid 2008: Põhiandmete haldamine" 2008.

Sabir Asadullajev ja Aleksander Karpov
Avaldatud 09.11.2010

Põhimõisted ja terminoloogia

Põhiandmed (MD) sisaldavad teavet klientide, töötajate, toodete, kaupade, tarnijate kohta, mis reeglina ei ole tehingulise iseloomuga.

Regulatiivne viiteteave (RNI) sisaldab sõnastikke, teatmeteoseid, klassifikaatoreid, kodifitseerijaid, standardeid ja identifikaatoreid. See on tehingusüsteemide põhitase, mida mõnel juhul hooldavad välised volitatud organisatsioonid.

Riis. 1 illustreerib lihtsustatud kujul põhiandmete, põhiandmete ja tehinguandmete erinevust. Tavalises lennupiletite müügisüsteemis mängib võrdlusandmete rolli lennujaama kodifitseerija, mille loovad süsteemi arendajad, võttes arvesse teatud spetsiifilisi nõudeid. Kuid teiste rahvusvaheliste infosüsteemidega suhtlemiseks peab lennujaama kood olema kõigile arusaadav. Seda eesmärki täidab Rahvusvahelise Lennutranspordi Assotsiatsiooni (IATA) poolt lennujaamadele määratud kolmetäheline unikaalne lennujaamakood.

Reisijate andmed ei ole nii stabiilsed kui lennujaama koodid. Samas saab reisija andmeid pärast süsteemi sisestamist kasutada erinevate turunduskampaaniate jaoks, näiteks teatud kogulennu vahemaa saavutamisel allahindluste tegemiseks. Selline teave viitab tavaliselt põhiandmetele. Need hõlmavad ka andmeid meeskondade, ettevõtte lennukipargi, kauba- ja reisijateterminalide ning paljude teiste õhutranspordiprotsessis osalevate üksuste kohta, kuid mida meie lihtsustatud näites ei käsitleta.

Viimane, ülemine rida joonisel fig. 1 kujutab skemaatiliselt mõttelist tehingut, mis on seotud pileti müügiga. Maailmas on suhteliselt vähe lennujaamu, kliente on palju rohkem, kuid nad saavad selle firma teenuseid mitu korda kasutada ning piletit ei saa ega tohi uuesti kasutada. Seega on lennufirma jaoks piletimüügiandmed kõige sagedamini muutuvad tehinguandmed.

Kokkuvõtteks võib öelda, et põhiandmed moodustavad automatiseeritud infosüsteemide põhitaseme ning põhiandmed salvestavad teavet klientide ja töötajate, tootetarnijate, seadmete, materjalide ja muude äriüksuste kohta.

Samas on võrdlusandmetel ja MD-l palju ühist, mistõttu juhtudel, kui vaadeldavad tegurid on seotud nii võrdlusandmete kui ka MD-ga, nimetame neid „RSI-ks ja MD-ks”, näiteks „süsteemiks võrdlusandmete ja MD säilitamine”.

NSI ja MD traditsioonilise juhtimise üldised puudused

NSI ja MD traditsioonilise juhtimise kõige levinum ja ilmsem probleem on ajutiste muudatuste toetamise puudumine. Aadress on reeglina võrdlusandmete ja MD üks olulisemaid komponente. Kahjuks aadressid muutuvad. Klient võib kolida, aga ta võib “kolida” terve maja ja isegi tänava. Nii muudeti 2009. aastal hoonete kompleksi „Krasnopresnenskaja muldkeha, hoone 18“ aadressi „Presnenskaja muldkeha, hoone 10“ aadressiks „Presnenskaja muldkeha, hoone 10“. Seega päring "Kui palju kirjavahetust toimetati 2009. aastal Vallatornis ruume rentiva ettevõtte kontorisse?" peaks korrektselt käsitlema kahe erineva aadressiga tarnedokumente.

Selleks, et muutused elus IT-süsteemis kajastuksid, ei piisa aga tehnoloogilistest (riist- ja tarkvaralistest) vahenditest võrdlusandmete ja MD säilitamiseks. Muutuste jälgimiseks on vaja kedagi või midagi. See tähendab, et vajalikud on organisatsioonilised meetmed, näiteks töötajad, kelle töökohustused vastavad üldandmete säilitamise metoodikale.

Seega hõlmab võrdlusandmete ja MD ettevõtte haldamine kolme tegevuskategooriat:

1. Metoodilised tegevused, mis määratlevad meetodid, eeskirjad, standardid, protsessid ja rollid, mis toetavad kogu põhiandmete ja MD säilitamise elutsüklit
2. Organisatsioonilised meetmed, mis määravad vastavalt metoodilistele nõuetele kindlaks organisatsiooni struktuuri, funktsionaalsed üksused ja nende ülesanded, töötajate rollid ja töökohustused.
3. Tehnoloogilised meetmed, mis asuvad IT tasandil ja tagavad organisatsiooniliste ja metoodiliste meetmete rakendamise.

Käesolevas artiklis käsitleme eelkõige tehnoloogilisi tegevusi, mis hõlmavad ühtse põhiandmete ja MD andmemudeli loomist, ajalooliste põhiandmete ja MD hooldust ja arhiveerimist, põhiandmete ja MD objektide tuvastamist, duplikaatide kõrvaldamist, identifitseerimist. vastuolude, viiteterviklikkuse tagamine, tugiandmete ja MD objekti elutsükli toetamine, puhastusreeglite väljatöötamine, viiteandmete ja MD säilitamise süsteemi loomine ning selle integreerimine ettevõtte toimivate infosüsteemidega. Vaatleme üksikasjalikumalt põhiandmete ja MD-infrastruktuuri loomise tehnoloogilist valdkonda ning sellega seotud traditsioonilise põhiandmete ja MD-halduse puudusi.

Võrdlusandmete ja MD säilitamise tehnoloogilised puudused

Põhiandmete ja MD jaoks pole ühtset andmemudelit

Põhiandmete ja MD jaoks puudub ühtne andmemudel või see on vormistamata, mis ei võimalda põhiandmete ja MD-objektide efektiivset kasutamist ning raskendab igasugust andmetega töötamise automatiseerimist.

Andmemudel on põhiandmete ja MD säilitamise peamine ja kõige olulisem osa, mis vastab näiteks järgmistele küsimustele:

• mida tuleks lisada viiteandmete ja MD-objekti identifitseerivate atribuutide hulka?
• Millised kõigist põhiandmete ja MD-objekti atribuutidest tuleks andmemudelis salvestada ja omistada põhiandmetele ja MD-le ning millised tuleks omistada operatsiooniandmetele ja jätta operatsiooniinfosüsteemi?
• kuidas integreerida väliste identifikaatorite ja klassifikaatoritega (OKPO, OKUD) mudeli abil?
• Kas erinevate IT-süsteemide kahe atribuudi kombinatsioon annab kolmanda ainulaadse ja ärilisest seisukohast olulise atribuudi?

Ajaloo säilitamisel ja arhiveerimisel puudub ühtne regulatsioon

Ajaloolist teavet olemasolevates ettevõtte IT-süsteemides hoitakse sageli vastavalt oma eeskirjadele ja sellel on oma elutsüklid, mis vastutavad põhiandmete ja MD-objektide töötlemise, koondamise ja arhiveerimise eest. Isegi kui põhiandmete ja MD jaoks on olemas ühtne andmemudel, on ajalooliste ja arhiiviandmete sünkroonimine ja nende ühtsele vormile viimine mittetriviaalne ülesanne.

Näide probleemidest, mis on põhjustatud ajaloolise normatiivse ja viiteteabe puudumisest, on toodud jaotises “”.

Raskused võrdlusandmete ja MD-objektide tuvastamisel

Erinevates IT-süsteemides on põhiandmetel ja MD-objektidel oma identifikaatorid - atribuutide komplektid. Keeruline on olukord, kui samade objektide puhul erinevates süsteemides ei ole võimalik tuvastada üht ühist atribuutide komplekti, mille kombinatsioon on unikaalne ja identifitseerib infosüsteemis objekti - liitvõtmevälja analoogi andmebaasides. Sel juhul liigub erinevates IT-süsteemides objektide tuvastamise ja võrdlemise ülesanne deterministlikust piirkonnast tõenäosusalasse. Sel juhul on võrdlusandmete ja MD-objektide kvalitatiivne tuvastamine raske andmeanalüüsi ja -töötluse spetsiaalsete tööriistadeta.

Põhiandmete ja MD-objektide duplikaatide esinemine

Objektide tuvastamise keerukus toob kaasa samade põhiandmete ja MD-objektide duplikaatide (või võimalike duplikaatide) esinemise erinevates süsteemides, mis on äritegevuse peamine ja kõige olulisem probleem. Teabe dubleerimine toob kaasa objektide töötlemise kulude dubleerimise, "sisenemispunktide" dubleerimise ja objektide elutsüklite ülalpidamiskulude suurenemise. Lisaks tuleb märkida duplikaatide käsitsi kontrollimise (ühildamise) kulud, mis on esialgu liiga suured, kuna need lähevad sageli IT-süsteemidest kaugemale ja nõuavad operaatori osalust. Tuleb märkida, et duplikaatide esinemine on süsteemiviga, mis ilmneb põhiandmeid ja MD-objekti kasutavate äriprotsesside esimestel etappidel. Lisaks omandab duplikaat äriprotsessi edenedes seoseid ja atribuutide koostist ning olukord muutub veelgi keerulisemaks.

Põhiandmete ja MD metaandmete vaheline vastuolu

Iga infosüsteem, mis toetab ettevõtte ärivaldkonda ja milles genereeritakse selle ettevõtte põhiandmed ja MD-objektid, määratleb oma ärireeglid ja piirangud, mis on kehtestatud nii atribuudi koostisele (metaandmetele) kui ka väärtusele. atribuudid. Seetõttu tekib sageli olukord, kus need erinevates infosüsteemides määratud reeglid ja piirangud lähevad omavahel vastuollu, nullides nii ära isegi teoreetilised katsed viia kõik põhiandmeobjektid ühte tüüpi. Olukorda raskendab see, kui väliselt identse andmemudeli korral on andmetel sama semantiline tähendus, kuid esitusviisilt erinev tähendus: erinev kirjapilt, permutatsioonid aadressides, täisnime lühendid, erinevad kodeeringud, lühendid.

Referentsi terviklikkus ja võrdlusandmete ja MD-mudelite sünkroniseerimine

Reaalses elus sisaldavad kõik nende IT-süsteemi ruumis paiknevad viiteandmed ja MD-objektid mitte ainult väärtusi, vaid ka linke teistele viiteandmetele ja MD-le, mida saab paigutada (ja hooldada) eraldi välissüsteemides. Siin kerkib üles kogu organisatsiooni põhiandmete ja MD-mudeli sünkroniseerimise ja terviklikkuse säilitamise probleem. Üks üldtunnustatud viise sedalaadi probleemide lahendamiseks on üleminek võrdlusandmete ja MD kasutamisele, mida hoitakse ja imporditakse organisatsiooni väljastpoolt (näiteks kataloogid KLADR, OKVED, TN VED, FSKP ja ECPS ).

Võrdlusandmete ja MD-objekti elutsükli mittevastavus

Kuna erinevates ettevõtte süsteemides on samad põhiandmed ja MD-objektid, ei ole selle objekti sisestamine ja muutmine nendes süsteemides kooskõlastatud ning sageli pikendatakse seda aja jooksul. Võimalik on olukord, kui objekt on erinevates süsteemides üksteist välistavates olekutes (ühes süsteemis aktiivne, teises arhiveeritud, kolmandas kustutatud), mis raskendab põhiandmete objektide terviklikkuse säilitamist. Objekte, mis ei ole omavahel seotud ja mis on aja jooksul hajutatud, on raskesti kasutatavad nii tehingu- kui ka analüütilistes protsessides.

Puhastusreeglite väljatöötamine

Võrdlusandmete ja MD puhastamise reeglid on sageli täiesti õigustatult omistatud metoodilistele aspektidele. Loomulikult peavad IT-spetsialistid ärikasutajatelt ülesandeid seadma, näiteks millistel juhtudel on vaja lennujaama koode uuendada või kummal kahest maksekaardil on korrektne andmete kodeering. Kuid ärispetsialistid pole operatiivsete IT-süsteemide juurutamise keerukusega kursis. Lisaks on nende süsteemide dokumentatsioon kas puudulik või puudub. Seetõttu on puhastusreeglite selgitamiseks ja uute reeglite väljaselgitamiseks vajalik infosüsteemide analüüs.

Vale põhisüsteemi valik võrdlusandmete ja MD säilitamiseks

Enamasti on põhiandmete ja MD olulisemateks allikateks ja tarbijateks suured pärandettevõtte infosüsteemid, mis on ettevõtte äritegevuse tuum. Reaalses elus valitakse selline süsteem sageli põhiandmete ja MD säilitamiseks „põhisüsteemiks”, selle asemel, et luua spetsiaalne põhiandmete ja MD hoidla. Samas ei võeta arvesse, et selline funktsionaalsus on selle IT-süsteemi puhul reeglina ebatavaline. Selle tulemusena põhjustavad viiteandmete ja MD-ga seotud süsteemide mis tahes muudatused suuri ja ebamõistlikke kulutusi. Olukorda raskendab see, kui põhiandmete ja andmehalduse alamsüsteemi arenedes on vaja kasutusele võtta kvalitatiivselt uus funktsionaalsus: andmepakettide töötlemine, vormindamine ja puhastamine ning määrata andmehaldurid.

IT-süsteemide ettevalmistamatus võrdlusandmete ja MD integreerimiseks

Põhiandmete ja MD haldamise täielikuks juurutamiseks ettevõtte olemasolevatesse IT-süsteemidesse on vaja need süsteemid integreerida ja enamasti on see integreerimine vajalik mitte ühekordse ja lokaliseeritud toiminguna, vaid IT-süsteemides elavate protsesside muutumine. Lisaks võrgutöö integreerimisele on vaja läbi viia integreerimine esmase pakettandmete laadimise (ETL) läbiviimiseks, samuti käsitsi vastavusseviimise protseduuride läbiviimiseks (konciliation).

Kõik automatiseeritud infosüsteemid ei ole sellisteks muudatusteks valmis, kõik süsteemid ei paku selliseid liideseid ja enamasti on see selliste süsteemide jaoks täiesti uus funktsionaalsus. Süsteemi juurutamisel kerkivad esile arhitektuursed küsimused, mis on seotud erinevate võimaluste valikuga põhiandmete ja MD-süsteemi juurutamiseks ning selle integreerimiseks ettevõtte tehnoloogilise maastikuga. Selle punkti olulisuse kinnitamiseks märgime, et on välja töötatud ja testitud arhitektuurimustreid ja lähenemisviise, mille eesmärk on põhiandmete ja MD-süsteemi õige juurutamine ja integreerimine.

Näited probleemidest traditsioonilises uurimisandmete ja MD haldamises

Seega tulenevad põhiandmete haldamise peamised probleemid ettevõttes põhiandmete detsentraliseerimisest ja killustatusest ning avalduvad praktikas konkreetsetes näidetes.

Passiandmed unikaalse identifikaatorina

Näiteks suures pangas otsustati kliendiandmete mudeli loomise tulemusena kasutada passiandmeid atribuutide tuvastamise osana maksimaalse selektiivsuse eeldusel. Kliendiandmete liitmise protseduuride läbiviimisel selgus, et kliendi pass ei ole unikaalne, kuna erinevateks klientideks loodi näiteks kliendid, kes olid pangaga suhelnud vanade passide ja seejärel uute passidega. Kliendidokumentide analüüsimisel selgus juhtumeid, kus ühele passile registreeriti tuhandeid kliente. Kõige tipuks oli üheks andmeallikaks pangainfosüsteem, kus passid olid kohustuslikud ja vastavad väljad täideti täitmisel “prügiga”.

Tuleb märkida, et tuvastatud probleemid kliendiandmete kvaliteedis ei olnud ootuspärased ja need avastati alles andmete puhastamise etapis, mis nõudis täiendavat aega ja raha andmete puhastamise reeglite ja kliendiandmete mudeli täpsustamiseks.

Aadress unikaalse identifikaatorina

Teisel juhul ühendas kindlustusselts klientide isikuandmed, kus muuhulgas kasutati aadressi identifitseeriva atribuudina. Selgus, et enamik kliente oli registreeritud aadressidel “samal”, “samas kohas”. Madala kvaliteediga andmed pärinesid kindlustusagentide tegevust toetavast rakendussüsteemist, mis võimaldas agentidel vabalt tõlgendada kliendiankeedi väljade väärtusi. Lisaks puudus selles süsteemis sisestatud andmete vorming ega loogiline kontroll.

Vajadus lepingute massiliseks uuendamiseks

Kolmandal juhul, ühendades olemasoleva, klientidega suhteid toetava ettevõtte infosüsteemi põhiandmete ja MD hooldussüsteemiga, selgus alles testimisetapis, et ühendatud süsteem ei saa automaatselt vastu võtta muudatusi põhiandmete hooldussüsteemist. andmed ja MD. Selleks on vaja läbi viia mõned regulatiivsed toimingud, antud juhul helistada kliendile ja väljastada uuesti paberkandjal lepingudokumendid, mis mainisid põhiandmete ja MD-ga seotud olulist teavet. Suure töömahu tõttu vaadati üle nii põhiandmete kui ka MD-ga töötamise tehnoloogilised ja organisatsioonilised aspektid.

Kokkulepitud andmete lahknevus

Neljas näide kirjeldab paljude organisatsioonide tüüpilist olukorda. Ettevõtte äritegevuse kiire arengu tulemusena otsustati avada uus suund, mis toetab klientidega töötamist B2C / B2B stiilis Interneti kaudu. Selleks osteti uus IT-süsteem, mis toetab ettevõtte uue ärisuuna automatiseerimist. Kasutuselevõtu käigus tekkis vajadus integreerida ettevõtte olemasolevate põhiandmete ja põhiandmetega ning laiendada neid spetsiifiliste atribuutidega, mis ei osutus sugugi nii lihtsaks, eelkõige spetsiaalse põhiandmete ja MD-süsteemi puudumise tõttu. Selle tulemusena laaditi viiteandmed ühe korra uude süsteemi ilma ettevõtte olemasoleva IT maastiku tagasisideta, mis mõne aja pärast viis kliendikataloogide kahe sõltumatu versioonini. Algul lahendati probleem kliendiandmete käsitsi töötlemisega arvutustabelites, kuid mõne aja möödudes kasvas klientide arv märgatavalt, kataloogid müüdi välja ning käsitsi töötlemine osutus ebaefektiivseks ja kulukaks. Selle tulemusena tõi olukord kaasa probleemi tõsise eskaleerumise ärikasutajate tasandil, kellel puudub turunduskampaaniate läbiviimiseks oma klientidest üldpilt.

Võrdlusandmete ja MD ettevõtte haldamise eelised

Põhiandmete ja MD ettevõttehaldus pakub järgmisi eeliseid:

• Õigusnõuete täitmine ja riskide vähendamine
• Kulude vähendamine
• Suurem paindlikkus uute äristrateegiate toetamiseks.

See kõlab liiga hästi, et olla tõsi, seega vaatame kõiki eeliseid praktiliste näidetega.

Õigusnõuete täitmine ja riskide vähendamine

Uurimisvõimud nõudsid suurfirmalt eelneva 10 aasta andmete esitamist. Ülesanne tundus lihtne ja teostatav: ettevõttes oli juba ammu kasutusele võetud andmete ja rakendusprogrammide regulaarse arhiveerimise ja varundamise protseduurid, andmekandjaid hoiti turvalises ruumis ning andmekandjate lugemiseks mõeldud seadmed polnud veel vananenud. Pärast ajalooliste andmete taastamist arhiivist aga avastati, et andmetel polnud praktilist tähendust – põhiandmed olid selle aja jooksul korduvalt muutunud ning nüüd ei olnud võimalik tuvastada, millega need või teised andmed seotud on. Põhiandmete arhiveerimist ei näinud keegi ette – tundus, et tegemist on ajakindla infoga. Ettevõttele määrati märkimisväärsed karistused, ettevõtte juhtide suhtes tehti tõsiseid korralduslikke järeldusi. Lisaks loodi viiteandmete säilitamise eest vastutav üksus, et vältida ebameeldiva olukorra kordumist.

Kasumi kasv ja klientide hoidmine

Suur lillepood oli üks esimesi, kes mõistis meiliturunduse tõhusust. Loodi kaupluse veebisait, millel viidi läbi reklaamikampaaniad, kus kliendid said tellida uudiskirju sõbrapäeval, seoses esimese lapse sünniga, lähedase sünnipäeval jne. Seejärel tervitati kliente värvivalikute soovitustega. Reklaamikampaaniad viidi läbi aga erinevate arendajate kaasamisel, kes lõid erinevaid, omavahel mitteseotud rakendusi. Seetõttu võisid kliendid saada sama probleemi kohta kuni kümme e-kirja, mis ärritas kliente ja tekitas nendes segadust. Selle tulemusena ei osutunud iga järgnev reklaamikampaania mitte ainult kahjumlikuks, vaid vähendas ka olemasolevate klientide arvu. Lillepood pidi oma rakenduste ümberkujundamiseks ja integreerimiseks kulutama märkimisväärse summa raha. Kulude suur summa oli seotud klienditeabe heterogeensuse, mitme aadressi- ja telefonivorminguga, mis tekitas suuri probleeme klientide tuvastamisel, et kõrvaldada mitu kirjet.

Kulude vähendamine

Üks peamisi nõudeid ettevõtte toodetele on vajadus kiiresti reageerida nõudluse muutustele, tuua turule lühikese ajaga uusi tooteid ja suhelda tarbijatega. Näeme, et eilsed vaieldamatud liidrid on muutumas mahajääjateks ning oma toote esmakordselt turule toonud uustulnukad suurendavad järsult oma kasumit ja kapitalisatsiooni. Nendes tingimustes peavad mitmesugused ettevõtte infosüsteemid, mis vastutavad tootearenduse, selle tarnimise ja müügi, teeninduse ja arenduse eest, põhinema ühtsel infobaasil, mis hõlmab kõiki ettevõtte tegevuse aspekte. Seejärel nõuab uue toote turule toomine tänu toetavate infosüsteemide sujuvale koostoimele vähem aega ja rahalisi kulutusi.

Suurem paindlikkus uute äristrateegiate toetamiseks

Viiteandmete ja MD-halduse killustatuse ja detsentraliseerimise kaotamine võimaldab pakkuda teavet teenusena. See tähendab, et iga IT-süsteem, järgides kehtestatud vahetusprotokolle ja juurdepääsuõigusi, pääseb ligi ettevõtte põhiandmete ja MD-de haldamise süsteemile ning võtab vastu vajalikke andmeid. Teeninduskeskne lähenemine võimaldab paindlikult üles ehitada infoteenuseid vastavalt muutuvatele äriprotsessidele, tagades seeläbi IT-teenuste ja süsteemide õigeaegse reageerimise muutuvatele nõuetele.

Võrdlusandmete ja MD säilitamise süsteemi arhitektuursed põhimõtted

Ressursid allalaadimiseks

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

Zone=Teabehaldus

Artikli ID=577045

ArticleTitle=Viiteandmete säilitamine praktiliste näidete abil

Kataloog « Ettevõtte struktuur"sisaldab igat tüüpi ettevõtte funktsionaalsete osakondade hierarhiat - haldus-, tootmis- ja nii edasi.

Kataloogil võib olla mis tahes hierarhia sügavus ja kasutatakse elementide hierarhiat. See tähendab, et arvestusüksus ja planeerimisobjekt võivad olla hierarhias mis tahes jaotus.

Sellest näitest on selge, et tootmist saab struktureerida osakondadeks (sektsioonid, sektorid, rühmad, osakonnad) mis tahes pesitsustasemega.

Tootmisjuhtimise allsüsteemi seisukohalt tõlgendatakse jaotust tootmisgraafiku etappide täitjana, vastavalt iga etapi ressursi spetsifikatsioonis on määratletud jaotus - etapi täitja.

Loetleme tootmisüksuse üksikasjad, mille väärtused tuleb määrata alamsüsteemis "Tootmise juhtimine".

• Ajakava. Valitud kataloogist "Töögraafikud".

Selle kataloogi element määratleb töögraafiku – töö algus- ja lõpuajad eraldi iga nädalapäeva kohta ja eraldi kõigi pühade-eelsete päevade jaoks. Iga nädalapäeva kohta saab graafiku alusel eraldi määrata töö algus- ja lõpuaja ning nädalapäevas võib olla mitu tööperioodi, näiteks 8.00-13.00 ja 14.00-18.00 . Osakonna töögraafik on vajalik selleks, et tootmisgraafiku arvutamise kord saaks määrata osakonnas saadaolevate töötundide arvu iga kalendripäeva kohta.

• Materjalide ladu. Ladu, kus materjalivajadus tekib vastavalt tootmisgraafikule osakonnas planeeritud etappidele. See ladu kontrollib etapi lõpetamiseks materjalide saadavust. Vajadusel saab materjali nomenklatuuri ja omaduste jaoks rajada eraldi materjalilaod, kus nende saadavust kontrollitakse.
• Ajastamise intervall. Määrab, millist intervalli osakonna jaoks kasutatakse tootmisgraafiku arvutamisel etappide kaupa. Valikud: "Päev", "Nädal", "Kuu".

Vajadusel valik " Tund", selle intervalli kasutamiseks peate lubama vastava funktsionaalse valiku.

Osakonna planeerimisintervalli valiku kriteeriumid on vastavus osakonnas tehtavate tüüpiliste etappide kestusele ja intervalli kestusele. Näiteks kui enamik osakonna etappe ei kesta kauem kui paar päeva, siis on mõttekas kasutada intervalli “Päev”. Kui etapi tüüpiline kestus ületab oluliselt nädala, siis on mõistlik kasutada “nädala” intervalli.

Intervalli pikkuse suurendamine üle vajaliku toob kaasa tootmise kestuse märgatava pikenemise, st tootmisgraafiku "venitamise" aja jooksul.

Intervalli pikkuse liigne vähendamine toob tootmisgraafikus kaasa liiga palju aega, mis võib kohaliku dispetšeri tööd keerulisemaks muuta.

• Marsruudilehtede haldamise meetod. Seda sätet kasutatakse osakonnas täidetavate marsruudilehtede haldamisel.

Valikud:

• "BBV/UBVV metoodika". ML-i täitmise ajakava genereeritakse võtme-RC-de jaoks. ML-i täitmist jälgitakse esialgse ja lõpliku puhvri läbimisel ML-i poolt.
• "Operatsiooni planeerimine". Ajakava koostatakse kõigi DC-de ja marsruudilehtede toimingute jaoks. Lisaks peate selgitama "Planeerimismeetod"– “Edasi” või “Tagasi”.

Laod (laopinnad)

Tootmise planeerimise seisukohalt on ladu tootmissüsteemi objekt, mis vastab tootmisosakondade vajadustele materjalide ja pooltoodete järele.

Graafiku arvutamisel koostatakse materjalide ja pooltoodete ladudes esitatavate nõuete ajakava (artikkel, omadused, kogus, planeerimisintervall).

Ladu, kust tootmisüksus vaikimisi "toiteallikaks" antakse, määratakse üksuse üksikasjade järgi.

Kuid mitte vastupidi: kataloogis "Ladu" olev atribuut "Division" ei mõjuta planeerimist (ja on mõeldud raamatupidamise jaoks).

Saate määrata tarnelao täpsema määratluse - jaotuse ja kauba jaoks lähtekomponendi omadused.

Brigaadid ja brigaadi koosseis

Meeskond on töökojas laval toimuva töö (operatsioonide) vahetu teostaja. Marsruudilehe järgi töötajate väljundi arvestamiseks koostab kohalik dispetšer dokumendi “Brigaadi korraldus”, milles märgib ära meeskonna ja tööliigid, mida meeskond marsruudilehe järgi tegi.

Meeskond koosneb töötajatest. Brigaadi koosseis kehtestatakse dokumendiga “ Brigaadi koosseisu moodustamine", ja kehtib alates dokumendis märgitud kuupäevast.

Kui on vaja korraldusi detaileerida kuni üksikute töötajateni, siis kataloogis “Brigaadid” moodustatakse ühest töötajast koosnevad brigaadid.

Töökeskuste tüübid, töökeskused

Töökeskuste tüübid on mõeldud kirjeldama osakonna tootmisvõimsust. Töökeskuste tüüpidel on planeerimisintervallides vaba tööaja fond, mis täidetakse tootmisetappide määramisel intervallidele tootmisgraafiku arvutamisel.

Töökeskuse vaade koosneb konkreetsetest töökeskustest, näiteks seadmetest. Töökeskuste tüübi sünonüüm on "Vahetatavate töökeskuste rühm".

Näited töökeskustest:

■ Seadmete ühik

■ Töökoht

■ Töötajate rühm (meeskond või kutseliit).

■ Töötaja

■ Seadmete üksus

Maksimaalsele tootmisvõimsusele vastava teostatava tootmisgraafiku arvutamiseks on vaja ressursispetsifikatsiooni etappideks eraldada igas osakonnas laaditavad töökeskused, mis võib piirata etapi läbilaskevõimet.

Töökeskuste tüüpide üksikasjad on järgmised:

• Lipp “Planeeri tööd”. Kui lipp on lubatud, saab seda tüüpi RC valida etapis laaditud RC tüübiks. Lipp on sisse lülitatud divisjoni RC tüüpide jaoks, mis võib osutuda divisjoni kitsaskohaks.
• Maksimaalne saadavus (tund, min, s). Määrab ühe etapi ühe partii töötlemise maksimaalse kestuse selle jaotuse intervallis, kuhu RC-tüüp kuulub. Etapi ühe partii jaoks ei saa töötlemise kestust määrata maksimaalsest saadavusest suurema intervalliga.

Praeguses UP2 versioonis on RC tüüpide seaded kirjeldatud olemust säilitades juba mõnevõrra muutunud. Nüüd saate märkeruutude abil teha järgmist.

• Kas tipptasemel ajakava koostamisel peaks arvestama alalisvoolu aja saadavust? Ja kui jah, siis kas see DC on allalaaditav või mitte.
• Kas DC peaks olema kaasatud tootmisjuhtimisse, kasutades marsruudilehti madalamal tasemel?

Järgmine diagramm näitab kataloogide “Ettevõtte struktuur”, “Töökeskuste tüübid”, “Töökeskused” struktuuri ja seoseid.

Töökeskuse vaba aja sisestamine

Töökeskuste vaba aja fondi intervallide kaupa sisestamiseks kasutage dokumenti “Töökeskuste saadavus”. Dokumendi päises valige osakond, töökeskuse tüüp ja dokumendiperiood.

Dokumendi tabeliosa on laiendatud veergude kaupa - dokumendiperioodi jagamise intervallid (näiteks päevad).

Tabelijaotise real tuleb valida töökeskuse tüüp, mis kuulub töökeskuse tüübi alla, ja veergude intervallide kaupa märkida iga intervalli jaoks saadavuse tundide arv.

Ressursi spetsifikatsioonid

Ressursi spetsifikatsioon võrguskeemina

Tuntud on mitut tüüpi spetsifikatsioone, näiteks, marsruutide töövooskeemid, "treeningud" kui marsruudid osa läbimiseks osakondadest.

Kõige tavalisem viis mis tahes toote tootmisprotsessi kirjeldamiseks on võrguskeem.

Ressursi spetsifikatsioon kirjeldab toote valmistamise võrgugraafikut.

Võrgusõlmed sellises kirjelduses on omavahel seotud tootmisetapid, mida teostavad osakonnad toote või pooltoote valmistamise protsessis järjest või paralleelselt. Ühes osakonnas - üks või mitu etappi, mis tuleb läbi viia.

Kaared– etappide vastastikune sõltuvus, show, milliste etappide läbimisel võivad alata järgmised etapid.

Võrguskeemi on mugav kasutada mis tahes tootmisprotsessi kirjeldamiseks – diskreetse pideva tootmise, ehituse, projekteerimistegevuse puhul.

Üldiselt võib võrguskeem sisaldada mitte ainult toodete osakondadevahelise ülekandmise fakte, vaid ka töötulemuste ülekandmise fakte.

Töötubade vahel ülekantud töö tulemus ei pruugi omada materiaalset väljendust. Tulemuse ülekandmine osakonnast teise osakonda, et teine ​​osakond saaks oma osa tööst ära teha, ei tähenda tingimata teatud toodete üleviimist. Toode võib näiteks asuda ühes osakonnas või vastavalt vajadusele teisaldada, samas kui tööd tootega võivad teha teised osakonnad.

Tootmisetapid võivad hõlmata mitte ainult toodete valmistamist, vaid ka tootmise ettevalmistamist, seadmete seadistamist, dokumentatsiooni väljatöötamist, koolitust, paigaldamist jne.

Äärmuslikul juhul võib ressursi spetsifikatsioon hõlmata kõiki toote valmistamise etappe vastavalt toote struktuuri hierarhilisele puule. Kõige lihtsamal juhul koosneb ressursi spetsifikatsioon ühest tootmisetapist. Seda ressursi spetsifikatsiooni nimetatakse üheastmeliseks.

Ressursispetsifikatsiooni näide sõlme etappidega võrguskeemina on näidatud järgmisel diagrammil:

Ressursi spetsifikatsiooni struktuur

Ressursispetsifikatsiooni struktuur konfiguratsiooniobjektina on näidatud järgmisel diagrammil:

Ressursi spetsifikatsioon sisaldab:

■ väljundite loend,

■ materjalisisendite loetelu,

■ tööjõukulude loetelu (töö liigi järgi),

Mitmeastmelises ressursi spetsifikatsioonis on iga sisendi, väljundi ja tööjõusisendi puhul vaja näidata, millises etapis sisend (tööjõusisend) tarbitakse või väljund toodetakse.

Etappide sisenditel näidatakse spetsifikatsioonis kirjeldatud algkomponendid (materjalid, teenused), mis tulevad väljastpoolt tootmisprotsessi.

See tähendab, et need on need komponendid, mis antud etapi jaoks ei ole sama spetsifikatsiooni teiste etappide väljundid.

Materjali sisendi - pooltoote puhul saate lubada lipu " Toodetud protsessi käigus» ja vastavalt sellele valida Ressursi spetsifikatsioon, mille järgi see pooltoode tuleb toota. Selle tulemusel "täidetakse" see ressursi spetsifikatsioon sellest sisendist "alla" teise ressursi spetsifikatsiooniga. Seega on võimalik individuaalsetest spetsifikatsioonidest koostada terviklik valmistoodete puu spetsifikatsioonide kaskaadi kujul.

Seda spetsifikatsioonide kaskaadi kasutatakse konkreetse tootmistellimuse rea spetsifikatsiooni genereerimiseks. Kogu seotud ressursi materjalimaterjalide kaskaad kopeeritakse tellimuse reale BOM.

Rekvisiidis " Optimaalne ülekande hulk etappide vahel» saate määrata tootepartii koguse (töötulemuse), mida on soovitav etappide vahel üle kanda. Tootmisgraafiku arvutamisel jagatakse etapi kogus partiiandmeteks ning iga partii planeeritakse eraldi, lähtudes laetavate alalisvoolutüüpide saadavuse ajast.

Standardne töömahukus ressursi spetsifikatsioonis, samuti marsruudikaartide tehnoloogilistes toimingutes on näidatud jaotises " Töö tüübid».

Töö liik - analüütika, mille järgi sisestatakse töötajate tööjõuhinnad ja võetakse arvesse töötajate toodangut. Töö liigi nimetus võib lisaks töö enda kirjeldusele sisaldada ka nõutavat töötajate kategooriat ja nende elukutset. Tööliigi puhul määratakse selle mõõtühik, näiteks tunnid või tükid. tooted.

Iga perioodilise teaberegistri töö liigi kohta " Hinnad» saab märkida tööliigi hetkehinna ühiku kohta.

Ressursi spetsifikatsiooni etapid

Ressursi spetsifikatsioon võib olla ühe- või mitmeastmeline.

Kui spetsifikatsioon on üheastmeline, redigeeritakse ühe etapi üksikasju otse spetsifikatsioonivormil. Kui spetsifikatsioon on mitmeastmeline, sisaldab spetsifikatsioon etappide loendit. Lava detailide redigeerimiseks tuleb etappide loendist avada eraldi lavavorm.

Etappide jada määratakse etapi detailidega: “Etapi number”, “Järgmise etapi number”. Lavanumbri ja järgmise etapi numbri alusel ehitatakse lavadevahelised ühendused lavade võrguskeemi kujul.

Lava üksikasjad määravad etapi planeerimise peamised parameetrid:

• alajaotis, milles lava esitatakse. Ühe etapi jaoks on määratletud ainult üks jaotus. Kui erinevates osakondades saab teha samu etappe, siis on vaja luua erinevad ressursside spetsifikatsioonid
• Korraga toodetud kogus. R partii suurus või töömaht, mille etapi valmimisaeg on standardiseeritud. Näiteks kui atribuudis on määratud ühik, normaliseeritakse etapi täitmisaeg üheks.
• Lipp "Planeerige DC tüüpide tööd". Määrab etapi kestuse normaliseerimise meetodi.
  • Lipp on lubatud. Etapis on vaja märkida, millist tüüpi töökeskusi etapi järgi laaditakse ja üheaegselt toodetud koguse töötlemise kestus laaditud töökeskuse tüübile. Seda tüüpi alalisvooluseadmed võivad tootmisgraafiku täitmisel osutuda kitsaskohtadeks, mistõttu arvutatakse nende koormus graafikus. Lisaks on vaja märkida esialgne (enne töötlemist laaditud RC vaates) ja lõplik puhvri aeg. Puhvrid hõivavad tootmisgraafikus eraldi intervallid. Tuletagem meelde, et kui töötlemisaeg enne või pärast RC laadimistüüpi on palju lühem kui intervalli kestus, võib puhvri aegade määramine viia tervete intervallide põhjendamatu hõivamiseni puhvrite poolt ja sellest tulenevalt põhjendamatu tõusuni. tootmisgraafiku etapi kestus.
  • Lipp on välja lülitatud. Etapp näitab selle täitmiseks kuluvat aega mis tahes partii koguse puhul. Arvatakse, et selle ajaga saab etapp läbi igal juhul, sõltumata etapil olevast numbrist. Lipu saab välja lülitada etappide kaupa, mille täitmine ei ole seotud laaditud tüüpi RC-ga töötlemisega (vastavalt "nn kitsaskohad" loetakse, et osakonnal on sellise etapi läbiviimisel (suhteline). kitsaskohtadega osakondadesse) piiramatu tootmisvõimsus.
• Lipp « Pidev» etapp määrab, kas etapi teostamist saab ajakavas jagada mitmeks mittekülgnevaks intervalliks.
  • Kui lipp on sisse lülitatud, siis toimub etapp pidevalt ja ajakavas saab paikneda ainult külgnevate intervallidega.
  • Kui lipp on välja lülitatud, saab etapi täitmise katkestada, see tähendab, et osa ajaetapist võib paikneda ajakavas ühes intervallis ja osa teises, mitte esimese intervallis.

Järjepidevuse kriteerium – vähemalt üks operatsioon etapis on pidev ja võrreldav intervalli kestusega. Need toimingud hõlmavad näiteks kuumtöötlust, värvimist, kuivatamist jne.

Erinevused planeerimise "katkestuse" ja "pideva" etapi vahel on näidatud järgmisel diagrammil.

Konfiguratsioonirollid on jagatud järgmistesse rühmadesse:
Tootmine
Kaubandus ja ladustamine
Rahandus


Analüüs ja planeerimine
Reguleeritud raamatupidamine
Põhiandmete seadistamine
Jaekaupluse seadmed
Administratiivne
Teenindus

Tootmine

* Shift master – annab õiguse operatiivse tootmisarvestuse andmete sisestamiseks.
* Tootmisarvestuse operatiivandmete vaatamine – annab õiguse vaadata tootmisarvestuse operatiivandmete aruandeid.
* Sertifitseerimine – annab õiguse töötada sertifitseerimise alamsüsteemiga.
* Tehnoloog – annab õigusi andmete sisestamiseks regulatiivsest tootmissüsteemist.
* Poeökonomist – annab õiguse vormistada tootmisjuhtimise toiminguid juhtimisarvestuses.

Kaubandus ja ladustamine

* Laopidaja – annab õiguse laotoimingute registreerimiseks juhtimisarvestuse jaoks.
* Tellimuste haldur – annab õigusi tellimuste alamsüsteemiga töötamiseks. Saab kasutada nii iseseisvalt kui ka koos teiste rollidega.
* Ostujuht – annab õigused hankehalduse allsüsteemiga töötamiseks.
* Müügijuht – annab õiguse töötada müügihalduse allsüsteemiga.
* Jaemüük – annab õiguse registreerida jaemüügi dokumente, roll ei ole iseseisev – seda kasutatakse koos rolliga “Müügijuht”.
* Hinnakujundus – annab õiguse töötada hinnakujunduse alamsüsteemiga.

* Pangatoimingud - annab õiguse teha toiminguid pangadokumentidega.
* Rahaliste vahendite taotluste sisestamine - annab õiguse registreerida dokumente “Kulutaotlemine” ja “Kulutamistaotluste sulgemine”.
* Palgamakse - roll seatakse koos rollidega "Kassa", "Pangatoimingud". Roll annab õigused dokumentide registreerimiseks: o "Kassa laekumise order" koos toimingute tüüpidega:
- Töötaja poolt tagasimaksmine
o "Kassakulu order" tehingutüüpidega:
- Laenude ja laenude arveldused töötajatega
- Töötasu maksmine vastavalt väljavõtetele
- Töötajale töötasu maksmine
- Deponeeritud töötasu maksmine
- Raha väljastamine KKM kassasse
o "Väljaminev maksekorraldus" toimingute tüüpidega:
- Laenude ja laenude arveldused töötajatega
- Palkade ülekandmine

* Kassa – annab õiguse kassadokumentide registreerimiseks.
* Andmevahetus Client-Bank programmidega – seadistatakse kasutajale, kui tal on vaja kasutada Kliendi-Pank töötlust.
* Vastutavad isikud – annab vastutavatele isikutele dokumentide registreerimise õigused.
* DS-i kulutuste taotluste kinnitamine – annab taotluste kooskõlastamise õigused.
* Finantseerija – annab juhtimisarvestuses kassahaldustehingute vormistamise õigused.

Palga- ja personalijuhtimine

* Reguleeritud andmete personalihaldur – annab õiguse töötada organisatsioonide personalidokumentidega, ettevõtte töötajate personaliseeritud ja sõjaväeliste dokumentidega ning ettevõtte standardsete ajakavadega.
* Juhtimisandmete personalijuht - annab õiguse töötada ettevõtte personalidokumentidega, koolituste, puhkuse planeerimise ja kinnitamise dokumentidega ning ankeetidega.
* Värbamisjuht – annab õiguse töötada kandidaatidega, ankeetide alamsüsteemiga, ettevõtte personaliplaaniga.
* Reguleeritud palgakalkulaator - annab õiguse arvutada reguleeritud viitvõlgu, arvutada makse ja koostada palkasid raamatupidamises.
* Juhtkonna palgakalkulaator – annab õiguse arvutada juhtkonna viitvõlgu.

Põhivara ja tööriided

* Põhivara ja immateriaalse põhivara arvestus - annab õiguse põhivaraga toimingute vormistamiseks (sh seadmete hoolduse juhtimine) ja immateriaalse põhivaraga juhtimisarvestuses.
* Tööriiete raamatupidamine – annab õigusi alamsüsteemi "Töörõivad ja eriseadmed" objektidele.

Analüüs ja planeerimine

* Eelarvestamine – annab õiguse töötada eelarve koostamise alamsüsteemiga.
* Planeerimine – annab õiguse töötada planeerimise allsüsteemiga.
* Kuluarvestus – annab õiguse kuluarvestuse andmetele ja tootekuludele juhtimis- ja reguleeritud raamatupidamise jaoks.

Reguleeritud raamatupidamine

* IFRS raamatupidaja - annab õigused vormistada äritehinguid IFRS-is.
* Reguleeritud raamatupidamise rutiinsete toimingute teostamine - annab õiguse teostada reguleeritud raamatupidamist reguleerivaid dokumente (BU ja NU).
* Moodustamine reguleeritud raamatupidamises – annab õiguse teostada raamatupidamise ja maksuarvestuse dokumente ning õigusi koostada raamatupidamise alamsüsteemi aruandeid. ja sularaha raamatupidamine.
* Vaata reg raamatupidamine - annab õiguse lugeda raamatupidamisandmeid. ja sularaha raamatupidamine ja raamatupidamise alamsüsteemi aruannete koostamise õigused. ja sularaha raamatupidamine.
* Reguleeritud aruandlus – annab õigused reguleeritud aruandluse rakendamiseks.
Seda rolli kasutatakse koos rolliga "Moodustamine reguleeritud raamatupidamises".
* Õigus tagada dokumentide liikumine reguleerivate asutustega (föderaalne maksuteenistus, pensionifond) – annab õiguse kasutada sisseehitatud algoritmi teabevahetuseks reguleerivate asutustega (föderaalne maksuteenistus ja pensionifond).
Pensionifond) sidekanalite kaudu. Roll määratakse koos ühe rolliga: "Reguleeritud aruandlus",
“Reguleeritud andmete personalispetsialist” või “Reguleeritud palkade kalkulaator”.
* Käibemaksuarvestus - annab õigusi käibemaksu alamsüsteemi objektidele, käibemaksu reguleerivate toimingute teostamiseks ja käibemaksuaruannete koostamiseks.
* Finantsarvestuse arvestus – annab õiguse tulevaste kulude arvestuseks.

Põhiandmete seadistamine

* Põhiandmete seadistus – annab õigusi tavalistele objektidele, näiteks laod, divisjonid, raamatupidamispoliitikad
(juhitud raamatupidamine).
* Kulude põhiandmete seadistamine - annab õigused alamsüsteemi "Kuluhaldus" andmetele.
* Põhiandmete (reg) seadistamine - annab õigusi reguleeritud raamatupidamisega seotud andmetele.

Jaekaupluse seadmed

* Kassaadministraator – annab õigused kassakassade seadistamiseks ja kassavahetuse sulgemiseks.
* Kaubandusseadmete kasutamine – seadistatakse kasutajale, kui tal on vaja kommertsseadmeid kasutada.
* Kaubandusseadmete seadistamine – seadistatakse kasutajale, kui tal on vaja kaubanduslikke seadmeid seadistada.
* KKM Operaator - annab õiguse registreerida jaemüügidokument “KKM kviitung”.

Administratiivne

* Kasutaja administraator – annab õigusi kasutajate haldamiseks.
* Täielikud õigused – annab ligipääsu kõikidele konfiguratsiooniobjektidele ja on määratud teostama teenindustoiminguid: o infoturbe uuendamine o kustutamiseks märgitud objektide kustutamine o töö täitmislogiga o jne.
Ei ole soovitatav töötada süsteemis püsivalt rolli all “Täielikud õigused”, sh äritoimingute tegemine.
* Andmete redigeerimise keelamise kuupäeva määramine – määrake kasutajale, kui tal on vaja andmete muutmise keelamise kuupäeva määrata.
* Haldusõigus - antakse kasutajale, kui tal on vaja täita eranditult haldusfunktsioone ja töötada.

Teenindus

* Lisavormide administreerimine ja töötlemine – määrata kasutajale, kui tal on vaja muuta kataloogi "Väline töötlemine".
* Salvestatud seadistuste administreerimine - seadistatakse kasutajale, kui tal on vaja hallata universaalse baasil koostatud aruannete salvestatud seadistusi.
* Välisühenduse õigus – antakse kasutajale, kui tal on vaja infobaasiga töötada välisühenduse kaudu.
* Teabe kuvamise õigus – määratakse kasutajale, kui tal on vaja kuvada prinditavaid versioone, kopeerida genereeritud prinditavaid versioone lõikepuhvrisse või salvestada väliste failidena.
* Väliste aruannete ja töötlemise käivitamise õigus - määratakse kasutajale, kui tal on vaja väliseid aruandeid ja töötlemist avada.
Rolli tuleks määrata ainult pädevatele töötajatele:
Väliste aruannete kasutamine või töötlemine võib kujutada endast ohtu süsteemiandmete turvalisusele järgmisel kujul: hävitamine (pahatahtlik või ebakompetentsuse tõttu), volitamata juurdepääs.
* E-posti kasutamise õigus – määratakse kasutajale, kui tal on vaja sisseehitatud meiliga töötada.
* Vaata dokumendi liikumisi – määratakse kasutajale, kui tal on vaja dokumentide liikumisi vaadata (hallatavas rakenduses).
* Vaata alluvusstruktuuri – määrake kasutajale, kui tal on vaja vaadata dokumentide alluvusstruktuuri (hallatavas rakenduses).

"Kasutaja" roll on samuti määratud konfiguratsioonis. See roll annab juurdepääsu programmi sisenemiseks ja määratakse kõigile kasutajatele automaatselt (kasutajarollide muutmisel ettevõtte versioonis).

Masinatööstuse ettevõtete efektiivsus sõltub suuresti sellest, kui hästi on korraldatud töö viiteinfoga (RNI). Kontserni IT-direktor Oleg Apanasik räägib hetkel AEM-Technologies ettevõtete grupis viiteandmete süsteemi juurutamise projektist ja selle kasutamisest.

Arukas ettevõte: millised olid peamised eesmärgid põhiandmete juurutamisel ja millisteks peamisteks etappideks saab selle ülesande lahendamise jagada?

Oleg Apanasik: Rakendamiseks vastu võetud otsus põhineb meie töötajate kogemustel regulatiivse ja viiteteabe haldamisel. Kõik sai alguse vajadusest tsentraliseerida põhimaterjalide ja komponentide kataloogi haldamine kahes tootmiskohas ja haldusfirmas. Töötasime välja kaks ettevõtte standardit ja mitu tööjuhendit, kuid iga kord ilmus infosüsteemidesse materjale, mis ei olnud sisestatud regulatiivsete dokumentide kohaselt, või olemasolevate kirjete duplikaadid.

Ja 2014. aasta lõpus algatasime projekti regulatiivse ja viiteteabega töö optimeerimiseks. Selle raames töötati välja meetodid mitme peamise kataloogide rühma - "Nomenklatuur", "Vastaspooled", "Töötajad", "Finants" ja "Tehnoloogiline" - normaliseerimiseks, samuti nende haldamise meetodid.

Projekti organisatsiooniline raamistik hõlmas meie ettevõtte peaettevõtet, mis asub Kolpino linnas, ja kahte filiaali - Petrozavodskmash ja Atommash Volgodonskist.

Projekti ülevaade sisaldas suurt hulka süsteeme, mida on üsna sobiv jagada eraldi rühmadesse.

Esiteks räägime tervest hulgast universaalse otstarbega rakenduslikest ärisüsteemidest. Need on kaks ettevõtte ressursihalduse lahendust – SAP ERP ja 1C:UPP ning kaks personalijuhtimise lahendust – SAP HR ja 1C:ZUP. See peaks hõlmama ka elektroonilist dokumendihaldust, mis põhineb “1C: Document Flow”, tootel “1C: Consolidation”, samuti mobiilside kulude arvestuse arendust “1C: Mobile Communication”. Lisaks olid vooluringis meie tootmistegevusele spetsialiseerunud tooted: TeamCenter (Siemens PLM Software), mis vastutab tootmise projekteerimise ja tehnoloogilise ettevalmistamise eest, süsteem ettevõtte tehnilise dokumentatsiooni arhiivi pidamiseks ja tooteandmete haldamiseks. Ettevõtte Intermech otsing , viite- ja teabeandmebaasi haldussüsteem IMBASE andmed samalt tootjalt ning läbipääsu- ja juurdepääsukontrollisüsteem Perco. Kaasatud olid ka taristutooted – ActiveDirectory domeenikontroller ja MS SharePointi ettevõtteportaal.

Milliseid universaalseid infotöötluse meetodeid antud probleemide lahendamiseks kasutati - näiteks andmete puhastamist, tekstiotsingut, hierarhilist või muud liigitamist, andmete parameetristamist, midagi muud? Kõik, mida te just loetlesite, on seotud tehniliste meetoditega kataloogikirjete moodustamise õigsuse kontrollimiseks eelnevalt kokkulepitud reeglitele. Jutt käib siin nn “lollikindlusest” ja põhiandmete süsteemiga töötamiseks vajalikul tasemel saab seda rakendada igas arvestussüsteemis. Hoopis keerulisem on kokku leppida kataloogide pidamise reeglites. Näiteks nomenklatuuri jaoks on oluline, et nimi vastaks normatiivdokumendile ja see on efektiivne, kui töötame vastavalt GOST-ile, OST-ile või TU-le. Kuid kui klient palub kasutada materjale vastavalt riigis kehtivuse kaotanud standarditele või tootjate kataloogidele, sealhulgas välismaistele, siis tekivad vastuolulised küsimused, mida tuleks eelnevalt kirjeldada. Nende reeglite kogum on põhiandmete haldamise meetodite ja standardite aluseks.

Huvitav oleks kuulda metoodilistest rõhuasetustest normatiivse ja viiteinfoga töötamisel...

Võrdlusandmete haldussüsteemi edukaks toimimiseks on oluline läbi viia minu arvates projekti pikim etapp – andmete normaliseerimine. Enne põhiandmete haldamise (MDM süsteemide) juurutamise projekti algust, mille põhifunktsioon on tegelikult põhiandmete haldus, kasutas ettevõte aastaid erinevaid raamatupidamis-, tootmislahendusi, aga ka projekteerimissüsteeme, mille jaoks säilitame tohutult palju mitmesuguse viiteteabe hulk . Ja meie loomulik soov oli kogutud andmeid säilitada ja kasutada, kuid vastavalt äsja väljatöötatud metoodikale. Selleks oli vajalik andmete normaliseerimine.

Nimetan peamised eesmärgid, mille poole püüdlesime.

Esiteks peab iga kataloogi kirje olema seotud põhiklassifikaatori kindla klassiga ja selliselt, et nendele kirjetele sisestatakse selle klassi kohustuslike tunnuste väärtused.

Teiseks omistatakse igale kirjele ühtne nimi.

Kolmandaks sisestatakse iga kataloogikirje atribuutide väärtused vastavalt kinnitatud haldusmetoodikale.

Neljandaks ei tohiks kataloogis olla topeltkirjeid.

Ja lõpuks, viiendaks, on vajalik, et igal kataloogikirjel oleks unikaalne kood, millest saavad unikaalselt aru kõik kataloogile ligipääsevad kasutajad ja rakendussüsteemid.

Normaliseerimisprotsess ise on samuti jagatud mitmeks etapiks.

Laval ettevalmistustööd Klassifikaatorid on konfigureeritud ja määratakse reeglid töötlemata andmete töötlemiseks.

seisneb selles, et kõik abonendisüsteemidest edastatud failid, mille vorming on kooskõlas kataloogiandmetega, laaditakse MDM-süsteemi. Allalaadimise ajal andmeid ei töödelda ega analüüsita.

Laval algandmete eeltöötlus Moodustatakse andmekogusid, jagatakse ekspertide vahel “toorandmed”, töötatakse välja reeglid nende töötlemiseks ja ehitatakse koolitusbaase.

"Toores" kirjete klassifikatsioon teostatakse kahes etapis: toorkirje määratakse ühele või teisele klassile ja iga valitud klassi jaoks määratakse tunnuste väärtus.

Viitekirje moodustamine: Klassifitseerimise järel otsitakse klassi väärtuse ja iseloomulike väärtuste komplekti järgi viitekirjet ning kui kirje leitakse, siis viitab sellele kirje “toores”. Kui viitekirjet ei leita, luuakse see klassi ja tunnustega määratud väärtusega.

MDM-süsteemi andmete töötlemine abonendisüsteemis - Selles etapis uuendatakse abonendisüsteemis olemasolevaid põhiandmeobjektide kirjeid või lisatakse uusi.

Tahaksin märkida, et MDM-süsteemi südameks on ontoloogiaserver (arendatud Vene ettevõtte AXELOT poolt), mis toimib viiteandmete eksperdi intelligentse abilisena. Klassifitseerimise etapis kutsub ta eksperti üles valima antud olukorra jaoks sobiva klassi ja soovitab valitud klassi jaoks tunnuste väärtused.

Kuid abonendisüsteemidega andmete vahetamise eest vastutab integratsioonisiin, mis ühendab MDM-koodide abil erinevates süsteemides olevad objektid.

Kas suurte masinaehitusettevõtete võrdlusandmete haldussüsteemi ehitamisel on spetsiifikat ja millest see koosneb?

Selle konstruktsiooni eripära ei seisne mitte ettevõtte mastaabis, vaid ettevõttes kasutatavate infosüsteemide arvus ja kasutatavate teatmeteoste mahus. Tootmise tüüp mõjutab ka seda, kuidas te süsteemiga töötate. Kui me räägime toodete valmistamisest üksikeksemplarina, siis uued kanded materjalide või seadmete kataloogi sisestatakse sagedamini kui seeriatootmises ja vastavalt sellele peavad kannete loomise reeglid olema rangelt reguleeritud. Ainuüksi “Nomenklatuuri” kataloogi sisestatakse meie ettevõttes iga kuu kuni tuhat uut kirjet, mistõttu ei jää NSI spetsialistidel aega materjalide nimetamise õigsuse üle pikemalt arutleda.

Millised elemendid puudutavad antud juhul teie ehitatud põhiandmete süsteemi – materjalid, tööriistad, toimingud, personali kvalifikatsioon, tarnijad või muud komponendid?

Meie projektis töötati välja metoodika mitmete kataloogide pidamiseks, mis jagunesid viide rühma: nomenklatuur, vastaspooled, töötajad, finants- ja tehnoloogiakataloog. Kui me räägime teatmeteostest, mis need rühmad moodustavad, siis need kirjeldavad tõesti neid komponente, mida just mainisite, aga ka paljusid teisi. Näiteks jaotises "Nomenklatuur" on sellised kataloogid nagu "Põhimaterjalid", "Tööriistad", "Seadmed ja inventar", "Tooted". Vastavates rühmades on kataloogid nimega “Vastaspooled”, “Töötajad”, “Personali ametikohad”, “Töökeskused” või näiteks “Rahavoogude kirjed”. Ühesõnaga, meil on üle kahekümne teatmeraamatu ja need käsitlevad väga detailselt kõiki AEM Technologies ettevõtte tegevuse aspekte, olgu selleks siis finants-, tootmistegevus või personalijuhtimine. Veelgi enam, nomenklatuurikataloogidega töötamise puhul on andmeallikaks MDM-süsteem ning tellijateks raamatupidamis- ja disainisüsteemid. Kuid kataloogiga "Töötajad" töötades on allikaks personalihaldussüsteem ja MDM-süsteem täidab abonendisüsteemi ja raamatupidamissüsteemide integratsioonisiini rolli.

Traditsiooniliselt on suurte masinaehitusettevõtete jaoks olulised tugevad ja stabiilsed sidemed materjalide ja komponentide, sealhulgas teabe, tarnijatega. Kas on vaja mingisugust põhiandmete süsteemi ühtlustamist oma partnerite sarnaste süsteemidega?

Me ei seadnud endale ülesandeks integreeruda tarnijasüsteemidega. Ja olles jõudnud meie ettevõtte kolme saidi andmete normaliseerimiseni, arvan, et see on ebatõenäoline. Meie jaoks on oluline, et kui materjaliaruandes märgitud ese on lisatud tarne tehnilisse kirjeldusse, siis sellest - lepingu kirjeldusse ja seejärel märgitud kauba kättesaamise dokumentidesse, saabub vastavalt meie lattu ja on konkreetse tootmistellimuse jaoks maha kantud. Kõikidel etappidel tuleb selline nomenklatuur selgelt identifitseerida, olenemata sellest, kus materjalide loetelu koostati, kes osales ostmises ja kus tootmine toimub.

Mis on viiteandmete IT-tugi, millised on siin peamised funktsioonid ja kuidas on soovitatav seda toote- ja organisatsioonilises plaanis rakendada?

Loomulikult lisandub IT-osakonna uue infosüsteemi kasutuselevõtuga seda toetav funktsioon. Kuid siin pole midagi uut: katkematu töö tagamine, andmete varundamine, kasutajate koolitamine, regulatsioonide ja tööjuhendite väljatöötamine, olemasoleva funktsionaalsuse muutmine kasutaja soovide ja dokumentatsiooni alusel. Mõningaid raskusi valmistab andmete integreerimine, millega töö algselt projekti ei kaasatud... Kuid siin teeme oma töövõtjatega tihedat koostööd.

Kui rääkida lühidalt probleemi toote- ja organisatsioonilisest küljest, siis meie peamine IT-tugitoode oli 1C:MDM Reference Information Management, aga ka Axelot Datareon ESB. Axelot oli peamine rakenduspartner.

Paljud ettevõtte osakonnad on alati huvitatud regulatiivse ja viiteteabe süsteemi väljatöötamisest. Kuidas saaks seda huvi projektijuhtimise struktuuris paremini arvesse võtta?

NSI eksperdid mängivad erilist rolli nii rakendusprojektis kui ka MDM-süsteemi hilisemas töös. Projekti edukus sõltub 80% nende lojaalsusest, töövõimest ja erialastest kompetentsidest. Just nemad määravad teabega töötamise reeglid. Lisaks on need töötajad erinevatest valdkondadest: kataloogide rühma “Nomenklatuur” ja “Tehnoloogia” jaoks on see tehniline direktoraat, grupi “Vastaspooled” jaoks - kontor, kataloogide “Finants” jaoks - raamatupidamine ja rahastajad, “ Töötajad” – personalijuhtimise direktoraat. IT-teenuse roll projekti arendamisel on aidata koguda või sõnastada nõudeid, kooskõlastada kogutud andmed kõigi äriprotsessis osalejatega, tagada kataloogide pidamise tööriista tehniline teostus ja edasine tugi. Kuid põhiandmete haldamise protsessi omanik on äri ja ainult äriklientidest sõltub, kas see protsess areneb või mitte.

Aruka ettevõtte juhtiv ekspert Sergei Kostjakov vestles Oleg Apanasikuga