Karakteristiska egenskaper hos nsi. Lista över konfigurationsroller Resursspecifikationsstruktur

UDC 004.37.01

ÅH. Zhilyaev ,
Institutet för informatik och
problem med regional förvaltning
KBSC RAS, forskare, Nalchik.

Introduktion

Skapandet av ett enhetligt informationsutrymme är en nödvändig förutsättning för effektiv hantering av olika objekt, vare sig det är ett företag, avdelning, region eller stat. Bildandet av en enhetlig miljö innebär integrering av förvaltningsprocesser, åtföljd av normalisering av informationsflöden. Ofta stöds förflyttningen av information på olika nivåer och delar av kontrollobjektet av olika informations- och redovisningssystem. Följaktligen finns det ett behov av att integrera dessa system. De växande processerna för globaliseringen av världsekonomin är i huvudsak integrationsprocesser. Sådana integrationsuppgifter är särskilt relevanta för Ryssland i samband med dess kommande anslutning till Världshandelsorganisationen (WTO).

Uppgiften att integrera informations- och redovisningssystem består av två inbördes relaterade delar: dataintegration och efterföljande applikationsintegration. När man utför dataintegration är det nödvändigt att förena och standardisera normativ och referensinformation (RNI). .

Masterdata är en villkorligt permanent del av all information i ett informationssystem (IS), till skillnad från aktuell information som genereras direkt i processen att arbeta i IS. Masterdata inkluderar: kataloger, ordböcker, linjära och hierarkiska listor, klassificerare, register, kodifierare, från vilka data används för att generera aktuella dokument.

För att beteckna sådan referensinformation i den engelskspråkiga litteraturen används termen Master Data (masterdata, masterdata), och uppgifterna för att hantera den kallas Master Data Management (MDM) Men på ryska begreppet normativ referens information (RNI) används nu oftare ), som förekom i discipliner relaterade till ekonomisk förvaltning även i tider före dator. I det här fallet återspeglar definitionen av "normativ" det faktum att problemet med att skapa kataloger måste lösas med hänsyn till industri, statliga och internationella standarder.

Om idag sådana termer som till exempel ACS (Automated Control Systems) eller IS (Information Systems) har blivit bekanta, orsakar ofta förkortningen "SU NSI" (Regulatory Reference Information Management System) förvirring. Även innebörden som ligger bakom dess avkodning förstås ofta endast av specialister. NSI är inte bara en databas, utan ett komplext organiserat system med många korsreferenser mellan enskilda kataloger och klassificerare. Mekanismen för att upprätthålla referensinformationens relevans är särskilt viktig. Kraven på fullständighet, noggrannhet och relevans av information i referensdatasystemet är mycket strängare än i en konventionell databas, eftersom informationsinnehållet i tillämpade uppgifter beror på referensdata under driften av vilket informationssystem som helst, inklusive automatiserade kontrollsystem. data. Masterdata är "grunden" för hela informationssystemet och hanteringen av detta system bör centraliseras. I figur 1 visas referensdata som den lägre nivån, "informationsgrunden" för hela IS-strukturen.

Ris. 1 Informationssystemnivåer

Det är den centraliserade hanteringen av referensdatasystemet, som är föremål för enhetliga regler och tillhandahålls av en enhetlig teknisk miljö, som gör det möjligt att upprätthålla enhetligheten av data, fullständighet, integritet och relevans för alla referensböcker och klassificerare som ingår i dess sammansättning. Därför att ha ett effektivt fungerande IS som löser verkliga problem.

Utvecklingen av fullfjädrad programvara för masterdatahantering började för bara några år sedan. Ledande mjukvarutillverkare har på senare tid ägnat mer och mer uppmärksamhet åt verktyg för hantering av masterdata (i den engelska versionen MDM, Master Data Management - master data management).

Det är svårt att tänka sig att lösa integrationsproblem utan centraliserad hantering av referensdata. Problemet med masterdatahantering uppstår även i sådana automatiserade och informationsstödda strukturer som banker eller försäkringsbolag. Masterdatahanteringssystem tillåter inte bara att ackumulera data från flera integrerade banksystem, till exempel för att generera rapporter för flera redovisningssystem; men också för att lösa problemen med operativ hantering av referensdata.

I Ryssland finns det inget enskilt centrum för bildandet av referensdata som liknar GOSTs. Och även om nya lagar relaterade till utveckling och cirkulation av elektroniska tekniska dokument nyligen har trätt i kraft, har de ännu inte haft någon märkbar inverkan på situationen.

NSI:s roll i informationsutvecklingen av regionen

Regional informatisering spelar en viktig roll i genomförandet av utvecklingsstrategin för informationsteknologisektorn i vårt land. Nyligen, i Ryska federationens beståndsdelar, har arbetet intensifierats med användningen av informationsteknik på alla områden i det regionala livet. Detta underlättades av genomförandet av ett antal evenemang av federala regeringsorgan och antagandet av reglerande dokument inom området för användning av informationsteknik på federal, departements-, regional och kommunal nivå. Ett av sådana dokument, utformat för att hjälpa till att lösa problemen med omfattande informationsbildning i regionen, är dekretet från Ryska federationens regering "Om förfarandet för bildande och användning av grundläggande klassificerare, kataloger och register vid tillhandahållande av statliga och kommunal service i elektronisk form” daterad den 31 augusti 2010.

En särskild roll för referensdata tilldelas även informatiseringsprogram för industrier och avdelningar. Till exempel publicerad den 31 mars 2010. I utkastet till koncept för informatisering av hälso- och sjukvården betonas särskilt att informationssystem inom hälso- och sjukvården bör utformas med hänsyn till standarder och regler och baseras på en enda basdata. (NSI som används inom området hälsovård, social utveckling och arbetsrelationer i Ryska federationen inkluderar totalt 163 olika klassificerare och referensböcker).

På regional nivå är målet med att implementera masterdatainfrastrukturen i automatiserade ledningssystem skapandet av ett enhetligt system av kataloger och klassificerare som används i statliga (kommunala) informationssystem för en konstituerande enhet i Ryska federationen, såväl som bildandet av av grundläggande redovisningsregister som säkerställer insamling och lagring av lämnad information om huvudobjekten för regional förvaltning. Systemet för hantering av masterdata, som är ett centraliserat arkiv och den enda leverantören av gemensamma masterdata för all infrastruktur och avdelningsinformationssystem i regionen, måste säkerställa informationskompatibilitet för lokala informationssystem och "elektroniska myndigheters" tillämpningar av ämnet.

Uppenbarligen bör nästa steg i utvecklingen av informationsteknik i Ryska federationen vara den efterföljande integrationen av avdelningar, regionala och kommunala informationssystem på federal nivå. Denna uppgift att integrera statliga informationssystem är så komplex att det förutom att standardisera dokument (exempelvis baserat på XML) och integrationsinfrastruktur i form av mjukvara, dirigera XML-dokument, krävs statliga insatser inom området standardisering av databeskrivningar.

Ett exempel på ett initiativ inom detta område är standarden e-GMS (UK GoverNmeNt Metadata Standard) antagen i Storbritannien. . Många länder har utgått från den så kallade "Dublin Core", som innehåller 15 delar av informationsbeskrivning:

• titel;
• författare eller skapare;
• ämne och nyckelord;
• beskrivning;
• utgivare;
• andra bidragsgivare;
• datum för;
• resurstyp;
• formatera;
• resursidentifierare;
• källa;
• språk;
• kommunikation;
• område (täckning);
• rättighetsförvaltning.

Förutom själva elementen har "Dublin Core" så kallade förtydliganden av element, till exempel: "Date of creation", "Date of publication", "Expiration date", etc. Länder kan inte bara använda denna kärna, men även lägga till eventuella ytterligare element som de anser vara nödvändiga. Dessutom är det första verktyget när man söker information vanligtvis att bläddra i kategorier. Därför definierar statliga initiativ för metadatastandarder standarder för en lista med kategorier (ett primärt sökverktyg utan användning av nyckelord).

Slutsatser

När du bekantar dig med lagstiftningen som syftar till att reglera tillhandahållandet av statliga och kommunala tjänster i elektronisk form, och organisera interdepartemental informationsinteraktion på statlig och kommunal nivå, kan du se:

• den faktiska avsaknaden av obligatoriska krav för standardisering av informationsteknik och programvara som används i statliga informationssystem som är nödvändiga för att säkerställa interdepartementalt informationsutbyte i rättsakter;
• avsaknaden av enhetliga tydliga krav i rättsakter för kataloger, klassificerare och datasystem för informationssystem som används vid informationsutbyte mellan avdelningar;
• avsaknaden av mekanismer för tillhandahållande av information och tillhandahållande av offentliga tjänster i elektronisk form i reglerande rättsakter som är enhetliga och obligatoriska för genomförande av alla federala, regionala och kommunala myndigheter. .

Idag, både i Ryska federationen och utomlands, är den största svårigheten med att genomföra projekt inom området för tillhandahållande av elektroniska tjänster på statlig, regional och kommunal nivå, såväl som liknande interdepartementala projekt, i förhållanden där betydande ansträngningar krävs för att integrera data och tillämpningar, består inte i användningen av vissa specifika tekniker, utan i att organisera processen för att anta relevanta standarder och harmonisera informationsteknikens arkitekturer för olika organisationer och avdelningar.

Projekt inom området för tillhandahållande av elektroniska tjänster på statlig, regional, kommunal och avdelningsnivå, som utförs av regeringar i olika länder, tillhandahåller följande huvudtyper av standarder:

• datastandarder;
• standarder för informationsutbyte mellan avdelningar;
• metadata (och informationsinhämtning) standarder;
• säkerhetsföreskrifter.

En enhetlig modern metodik för att underhålla masterdata behövs, annars kommer systemet att bli ohanterligt när mängden data ökar.
Reglerna och metoderna för att fylla i referensböcker och klassificerare måste preciseras i detalj, annars blir det extremt svårt att säkerställa ett högkvalitativt och välordnat arbete av experter för att upprätthålla referensdata. Det behövs en tydlig avgränsning av kompetensområden och ansvar för användare av referensdata och experter i dess hantering.

Det behövs en mycket effektiv modern teknik och referensdatahanteringssystem som löser problemet med åtkomst av flera användare till det med möjlighet till fysisk separering av befogenheter, implementerar interaktionen mellan användare och experter och säkerställer enkel skalning av systemet när både referensdatabasen själv och antalet serviceexperter.

Litteratur:
1. "Strategi för utvecklingen av informationssamhället i Ryska federationen" (godkänd av Ryska federationens president den 7 februari 2008 nr Pr-212);
2. Utkast till resolution från Ryska federationens regering "Om förfarandet för bildande och användning av grundläggande klassificerare, kataloger och register vid tillhandahållande av statliga och kommunala tjänster i elektronisk form" daterad 31 augusti 2010.
3. "Review of NSI", Publicering av ministeriet för ekonomisk utveckling, 2010
4. "Konceptet att skapa ett informationssystem inom vården för perioden fram till 2020", 2010.
5. Polotnyuk I."Metadata som grund för integration", PC Week/RE (492), 2005.
6. Ray Wang, Rob Karel."Trender 2008: Master Data Management" 2008.

Katalog « Företagsstruktur» innehåller en hierarki av funktionella uppdelningar av ett företag av alla typer - administrativt, produktion, etc.

Katalogen kan ha valfritt hierarkidjup och en hierarki av element används. Det betyder att en redovisningsenhet och planeringsobjekt kan vara vilken avdelning som helst i hierarkin.

Här är ett exempel på en hierarki av divisioner:

Administrering

Bokföring direktoratet Kommersiell service Säljavdelning Grupp detaljhandel Grupp grossist Inköpsavdelning

Produktion

Hjälptillverkning Reparationsverkstad Verktygsbutik Primärproduktion Upphandlingsproduktion gjuteri Sektion 1 Sektion 2 Smidesbutik Monteringsproduktion

Från detta exempel är det tydligt att produktionen kan struktureras i divisioner (sektioner, sektorer, grupper, avdelningar) med vilken nivå som helst av häckning.

Ur psynvinkel tolkas divisionen som utföraren av stegen i produktionsschemat, och i resursspecifikationerna för varje steg bestäms divisionen som utför steget.

Låt oss lista detaljerna för produktionsenheten, vars värden måste bestämmas i undersystemet "Produktionshantering".

Schema. Väljs från katalogen "Arbetsscheman".

En del av den här katalogen definierar arbetsschemat - start- och sluttiderna för arbetet separat för varje veckodag och separat för alla dagar före helgdagar. För varje veckodag kan du separat ange start- och sluttider för arbetet enligt schemat, och det kan finnas flera arbetsperioder per veckodag, till exempel från 8.00 till 13.00 och från 14.00 till 18.00 . Ett arbetsschema för en avdelning krävs för att beräkningsproceduren för produktionsschema kan bestämma antalet tillgängliga timmars arbete på avdelningen för varje kalenderdag.

Lager av material. Ett lager där materialbehovet genereras enligt produktionsschemat för planerade etapper på avdelningen. Detta lager kontrollerar tillgången på material för att slutföra steget. Om det behövs, för materialets nomenklatur och egenskaper, kan du skapa separata materiallager där deras tillgänglighet kommer att kontrolleras.

Schemaläggningsintervall. Bestämmer vilket intervall som ska användas för avdelningen vid beräkning av produktionsschemat efter steg. Alternativ: "Dag", "Vecka", "Månad".

Om det behövs, alternativet " Timme"För att använda detta intervall måste motsvarande funktionsalternativ vara aktiverat.

Kriterierna för att välja ett planeringsintervall för en avdelning är överensstämmelse med varaktigheten av typiska etapper som utförs på avdelningen och intervallets varaktighet. Till exempel, om de flesta stadierna på en avdelning inte varar mer än några dagar, är det vettigt att använda "Dag"-intervallet. Om den typiska varaktigheten av ett stadium avsevärt överstiger en vecka, är det rimligt att använda "vecka"-intervallet.

Att öka längden på intervallet utöver vad som är nödvändigt leder till en märkbar ökning av produktionens varaktighet, d.v.s. att "sträcka ut" produktionsschemat över tid.

En alltför minskning av intervalllängden leder till för mycket tidsdetaljer i produktionsschemat, vilket kan komplicera arbetet för den lokala avsändaren.

Metod för att hantera ruttblad. Denna inställning används vid hantering av ruttblad som körs på avdelningen.

Alternativ:

"BBV/UBVV-metodik". ML-exekveringsschemat genereras för nyckel-RC:er. ML-exekveringen övervakas genom passagen av den preliminära och slutliga bufferten av ML.

"Driftsplanering". Schemat genereras för alla DCs och ruttbladsoperationer. Dessutom måste du förtydliga "Planeringsmetod"- "Framåt" eller "Bakåt".

Lager (lagerområden)

Ur produktionsplaneringssynpunkt är ett lager ett objekt i produktionssystemet som uppfyller produktionsavdelningarnas behov av material och halvfabrikat.

Vid beräkning av schemat genereras ett schema över krav i lager för material och halvfabrikat (artikel, egenskaper, kvantitet, planeringsintervall).

Det lager från vilket produktionsenheten "drivs" som standard bestäms av enhetsinformationen.

Men inte vice versa: "Division"-attributet i "Warehouse"-katalogen påverkar inte planeringen (och tjänar för redovisningsändamål).

Du kan ange en mer detaljerad definition av förrådslagret - för division och artikel, egenskaper för källkomponenten.

Brigader och brigadsammansättning

Teamet är den direkta utföraren av arbetet i skedet (verksamheten) i verkstaden. För att redogöra för de anställdas produktion enligt ruttbladet, genererar den lokala avsändaren ett dokument "Brigade Order", där han anger teamet och vilka typer av arbete som teamet utförde enligt ruttbladet.

Teamet består av medarbetare. Brigadens sammansättning fastställs av dokumentet " Bildande av brigadsammansättningen", och är giltig från det datum som anges i dokumentet.

Om det är nödvändigt att detaljera beställningar ner till enskilda anställda, bildas brigader som består av en anställd i katalogen "Brigades".

Typer av arbetscenter, arbetscenter

Typer av arbetscenter är avsedda att beskriva en avdelnings produktionskapacitet. Typer av arbetscentraler har en tillgänglig arbetstid i planeringsintervall, som fylls i vid tilldelning av produktionssteg till intervall vid beräkning av produktionsschema.

En arbetsplatsvy består av specifika arbetscenter, till exempel utrustning. En synonym för typen av arbetscenter är "Grupp av utbytbara arbetscenter."

Exempel på arbetsplatser:

- Enhet av utrustning

- Arbetsplats

- Grupp av arbetare (lag eller professionell förening)

- Anställd

- Utrustningsenhet

För att beräkna ett genomförbart produktionsschema som motsvarar den maximala produktionsgenomströmningen, är det nödvändigt att allokera för resursspecifikationsstadier belastningsbara typer av arbetscenter i varje avdelning, vilket kan begränsa genomströmningen av etappen.

Detaljerna för typen av arbetscenter är följande:

Flagga "Planera arbete". Om flaggan är aktiverad kan denna typ av RC väljas i scenen som en laddad RC-typ. Flaggan är påslagen för RC-typer av divisionen, som kan visa sig vara divisionens "flaskhals".

Maximal tillgänglighet (timme, min, sek). Bestämmer den maximala varaktigheten för bearbetning av en sats av ett steg i intervallet för den division som RC-typen tillhör. För en batch av ett steg kan en bearbetningstid inte tilldelas i ett intervall som är större än den maximala tillgängligheten.

I den nuvarande versionen av UP2 har inställningarna för RC-typer redan ändrats något, samtidigt som den beskrivna essensen bibehålls. Nu kan du använda kryssrutorna för att:

- Om man ska ta hänsyn till tillgängligheten av RC-tid i schemaläggning på toppnivå. Och i så fall, kommer denna DC att vara nedladdningsbar eller inte.

- Bör DC vara involverad i produktionsstyrning med hjälp av Route Sheets på lägre nivå?

Följande diagram visar strukturen och förhållandet mellan katalogerna "Företagsstruktur", "Typer av arbetscentra", "Arbetscentra".

Ange tillgänglig arbetscentertid

Använd dokumentet "Tillgänglighet för arbetscenter" för att gå in i fonden för tillgänglig tid för arbetscenter. I dokumenthuvudet väljer du avdelning, typ av arbetscenter och dokumentperiod.

Den tabellformade delen av dokumentet utökas med kolumner - delningsintervall (till exempel dagar) i dokumentperioden.

I raden i tabellsektionen måste du välja ett arbetscenter som hör till arbetscentertypen, och med kolumnintervall, ange antalet tillgängliga timmar för varje intervall.

Resursspecifikationer

Resursspecifikation som ett nätverksdiagram

Olika typer av specifikationer är kända, till exempel konstruktionsspecifikationer, operationella flödesscheman över rutter, "träningspass", som vägar för passage av en del genom avdelningar.

Det vanligaste sättet att beskriva tillverkningsprocessen för en produkt är ett nätverksdiagram.

Resursspecifikation beskriver nätverksschemat för tillverkning av en produkt.

Nätverksnoder i denna beskrivning är sammankopplade produktionsstadier, utförda sekventiellt eller parallellt av avdelningar i processen att tillverka en produkt eller halvfabrikat. På en avdelning - en eller flera etapper som ska utföras.

Arcs– ömsesidigt beroende mellan stadier, visa, efter avslutade stadier kan följande etapper påbörjas.

Det är bekvämt att använda ett nätverksdiagram för att beskriva alla produktionsprocesser - i diskret, kontinuerlig produktion, i konstruktion, i designaktiviteter.

I allmänhet kan ett nätverksdiagram inte bara innehålla fakta om överföring av produkter mellan avdelningar, utan också fakta om överföring av arbetsresultat.

Resultatet av arbete som överförs mellan verkstäder har inte nödvändigtvis ett materiellt uttryck. Att överföra ett resultat från en avdelning till en annan avdelning, så att den andra avdelningen kan göra sin del av arbetet, innebär inte nödvändigtvis överföring av vissa produkter. Produkten kan till exempel placeras på en avdelning eller flyttas efter behov, medan arbetet med produkten kan utföras av andra avdelningar.

Produktionsstadierna kan omfatta inte bara tillverkning av produkter, utan även produktionsförberedelser, utrustningsinställning, dokumentationsutveckling, utbildning, installation etc.

I extremfallet kan en resursspecifikation inkludera alla steg i tillverkningen av en produkt, i enlighet med produktstrukturens hierarkiska träd. I det enklaste fallet består en resursspecifikation av ett produktionssteg. Denna resursspecifikation kallas enstegs.

Ett exempel på en resursspecifikation som ett nätverksdiagram med nodsteg visas i följande diagram:

Resursspecifikationsstruktur

Strukturen för en resursspecifikation som ett konfigurationsobjekt visas i följande diagram:

Resursspecifikationen innehåller:

Lista över utgångar,

Lista över materialinsatser,

Lista över arbetskostnader (efter typ av arbete),

Lista över etapper.

För varje insats, utmatning och arbetsinsats i en resursspecifikation i flera steg är det nödvändigt att ange i vilket skede insatsen (arbetsinsats) konsumeras eller produktionen produceras.

Vid ingången av stegen anges de initiala komponenter (material, tjänster) som kommer utifrån in i produktionsprocessen, som beskrivs i specifikationen.

De där. Dessa är de komponenter som för ett givet steg inte är utsignaler från andra steg med samma specifikation.

För en materialinmatning - en halvfärdig produkt, kan du aktivera flaggan " Tillverkad i process» och välj därför den resursspecifikation enligt vilken denna halvfabrikat ska produceras. Som ett resultat kommer denna resursspecifikation att "kompletteras" från denna ingång "nedåt" av en annan resursspecifikation. Således är det möjligt att skapa ett komplett träd av färdiga produkter från individuella specifikationer, i form av en kaskad av specifikationer.

Denna kaskad av specifikationer används när man genererar en specifikation för en specifik produktionsorderlinje. Hela kaskaden av relaterade resursstycklistor kopieras till orderradens stycklista.

I rekvisitan" Optimal mängd överföring mellan steg» du kan ange mängden av en produktbatch (resultat av arbete) som är tillrådlig att överföra mellan steg. Vid beräkning av produktionsschemat delas etappkvantiteten upp i batchdata, och varje batch planeras separat, baserat på tillgänglighetstiden för de laddade DC-typerna.

Standardarbetsintensiteten i resursspecifikationen, såväl som i den tekniska driften av ruttkartor, anges i avsnittet " Typer av arbete».

Typ av arbete - analys, enligt vilken arbetspriserna för arbetare skrivs in och arbetarnas produktion beaktas. Namnet på typen av arbete kan, förutom en beskrivning av själva arbetet, även innehålla den erforderliga kategorin arbetare och deras yrke. För en typ av arbete anges dess måttenhet, till exempel timmar eller bitar. Produkter.

För varje typ av arbete i det periodiska registret över information " Priser» kan du ange aktuellt pris per enhet för typen av arbete.

Resursspecifikationsstadier

En resursspecifikation kan vara enstegs eller flerstegs.

Om specifikationen är enstegs, redigeras detaljerna för ett enskilt steg direkt i specifikationsformuläret. Om specifikationen är flerstegsvis innehåller specifikationen en lista med steg. För att redigera etappdetaljer måste du öppna ett separat etappformulär från listan över etapper.

Sekvensen av etapper bestäms av stegdetaljerna: "Stagenummer", "Nästa etappnummer". Utifrån etappnumret och numret på nästa etapp byggs kopplingar mellan etapper i form av ett nätverksdiagram av etapper.

Scendetaljer bestämmer huvudparametrarna för scenplanering:

Underavdelning, där scenen framförs. Endast en division är definierad för ett skede. Om samma steg kan utföras på olika avdelningar är det nödvändigt att skapa olika resursspecifikationer

Kvantitet producerad på en gång. R batchstorlek eller volym av arbete för vilket stegens slutförandetid är standardiserad. Till exempel, om attributet specificerar en enhet, normaliseras exekveringstiden till ett.

Flagga "Planera arbetet för typer av DCs". Bestämmer metoden för att normalisera stegets varaktighet.

Flaggan är aktiverad. I scenen är det nödvändigt att ange vilka typer av arbetscenter som kommer att laddas av scenen och varaktigheten av bearbetningen av den samtidigt producerade kvantiteten på den laddade typen av arbetscenter. Dessa typer av DC kan visa sig vara "flaskhalsar" när man uppfyller produktionsschemat, så deras belastning i schemat beräknas. Dessutom är det nödvändigt att ange den preliminära (före bearbetning på den laddade RC-vyn) och slutlig bufferttid. Buffertar upptar separata intervall i produktionsschemat. Låt oss komma ihåg att om bearbetningstiden före eller efter den laddade RC-typen är mycket kortare än intervallets varaktighet, kan angivande av bufferttider leda till omotiverad infångning av hela intervall av buffertar och följaktligen till en omotiverad ökning av varaktigheten ett steg i produktionsschemat.

Flaggan är avstängd. Stadiet anger den tid det tar att slutföra det, för varje batchkvantitet. Man tror att under denna tid kommer etappen att vara avklarad i alla fall, oavsett antalet i etappen. Flaggan kan stängas av i etapper, vars utförande inte är relaterat till bearbetning på laddade typer av RC ("de så kallade "flaskhalsarna" anses följaktligen att avdelningen när man utför ett sådant steg har (relativ till avdelningar med ”flaskhalsar”) obegränsad produktionskraft.

Flagga « Kontinuerlig» etapp avgör om etappexekveringen kan delas upp i flera icke-angränsande intervall i schemat.

Om flaggan är påslagen exekveras scenen kontinuerligt och kan endast placeras i schemat i angränsande intervall.

Om flaggan är avstängd, kan exekveringen av scenen avbrytas, d.v.s. en del av tidsskedet kan placeras i grafen i ett intervall, och en del - i ett annat, inte intill det första, intervallet.

Kontinuitetskriterium – minst en operation inom ett steg är kontinuerlig och jämförbar med intervallets varaktighet. Sådana operationer omfattar till exempel värmebehandling, målning, torkning m.m.

Skillnaden mellan att planera "diskontinuerliga" och "kontinuerliga" steg visas i följande diagram:

Katalog « Företagsstruktur"innehåller en hierarki av funktionella uppdelningar av ett företag av alla typer - administrativt, produktion, och så vidare.

Katalogen kan ha valfritt hierarkidjup och en hierarki av element används. Det betyder att en redovisningsenhet och planeringsobjekt kan vara vilken avdelning som helst i hierarkin.

Från detta exempel är det tydligt att produktionen kan struktureras i divisioner (sektioner, sektorer, grupper, avdelningar) med vilken nivå som helst av häckning.

Ur psynvinkel tolkas divisionen som utföraren av stegen i produktionsschemat, i enlighet med resursspecifikationerna för varje steg definieras en division - scenens utförare.

Låt oss lista detaljerna för produktionsenheten, vars värden måste bestämmas i undersystemet "Produktionshantering".

• Schema. Väljs från katalogen "Arbetsscheman".

En del av den här katalogen definierar arbetsschemat - start- och sluttiderna för arbetet separat för varje veckodag och separat för alla dagar före helgdagar. För varje veckodag kan du separat ange start- och sluttider för arbetet enligt schemat, och det kan finnas flera arbetsperioder per veckodag, till exempel från 8.00 till 13.00 och från 14.00 till 18.00 . Ett arbetsschema för en avdelning krävs för att beräkningsproceduren för produktionsschema kan bestämma antalet tillgängliga timmars arbete på avdelningen för varje kalenderdag.

• Lager av material. Ett lager där materialbehovet genereras enligt produktionsschemat för planerade etapper på avdelningen. Detta lager kontrollerar tillgången på material för att slutföra steget. Om det behövs, för materialets nomenklatur och egenskaper, kan du skapa separata materiallager där deras tillgänglighet kommer att kontrolleras.
• Schemaläggningsintervall. Bestämmer vilket intervall som ska användas för avdelningen vid beräkning av produktionsschemat efter steg. Alternativ: "Dag", "Vecka", "Månad".

Om det behövs, alternativet " Timme", för att använda detta intervall måste du aktivera motsvarande funktionsalternativ.

Kriterierna för att välja ett planeringsintervall för en avdelning är överensstämmelse med varaktigheten av typiska etapper som utförs på avdelningen och intervallets varaktighet. Till exempel, om de flesta stadierna på en avdelning inte varar mer än några dagar, är det vettigt att använda "Dag"-intervallet. Om den typiska varaktigheten av ett stadium avsevärt överstiger en vecka, är det rimligt att använda "vecka"-intervallet.

Att öka längden på intervallet utöver vad som är nödvändigt leder till en märkbar ökning av produktionens varaktighet, det vill säga en "sträckning" av produktionsschemat över tiden.

En alltför minskning av intervalllängden leder till för mycket tidsdetaljer i produktionsschemat, vilket kan komplicera arbetet för den lokala avsändaren.

• Metod för att hantera ruttblad. Denna inställning används vid hantering av ruttblad som körs på avdelningen.

Alternativ:

• "BBV/UBVV-metodik". ML-exekveringsschemat genereras för nyckel-RC:er. ML-exekveringen övervakas genom passagen av den preliminära och slutliga bufferten av ML.
• "Driftsplanering". Schemat genereras för alla DCs och ruttbladsoperationer. Dessutom måste du förtydliga "Planeringsmetod"– "Framåt" eller "Bakåt".

Lager (lagerområden)

Ur produktionsplaneringssynpunkt är ett lager ett objekt i produktionssystemet som uppfyller produktionsavdelningarnas behov av material och halvfabrikat.

Vid beräkning av schemat genereras ett schema över krav i lager för material och halvfabrikat (artikel, egenskaper, kvantitet, planeringsintervall).

Det lager från vilket produktionsenheten "drivs" som standard bestäms av enhetsinformationen.

Men inte vice versa: "Division"-attributet i "Warehouse"-katalogen påverkar inte planeringen (och tjänar för redovisningsändamål).

Du kan ange en mer detaljerad definition av förrådslagret - för division och artikel, egenskaper för källkomponenten.

Brigader och brigadsammansättning

Teamet är den direkta utföraren av arbetet i skedet (verksamheten) i verkstaden. För att redogöra för de anställdas produktion enligt ruttbladet, genererar den lokala avsändaren ett dokument "Brigade Order", där han anger teamet och vilka typer av arbete som teamet utförde enligt ruttbladet.

Teamet består av medarbetare. Brigadens sammansättning fastställs av dokumentet " Bildande av brigadsammansättningen", och är giltig från det datum som anges i dokumentet.

Om det är nödvändigt att detaljera beställningar ner till enskilda anställda, bildas brigader som består av en anställd i katalogen "Brigades".

Typer av arbetscenter, arbetscenter

Typer av arbetscenter är avsedda att beskriva en avdelnings produktionskapacitet. Typer av arbetscentraler har en tillgänglig arbetstid i planeringsintervall, som fylls i vid tilldelning av produktionssteg till intervall vid beräkning av produktionsschema.

En arbetsplatsvy består av specifika arbetscenter, till exempel utrustning. En synonym för typen av arbetscenter är "Grupp av utbytbara arbetscenter."

Exempel på arbetsplatser:

■ Enhet av utrustning

■ Arbetsplats

■ En grupp arbetare (lag eller yrkesförening).

■ Anställd

■ Utrustningsenhet

För att beräkna ett genomförbart produktionsschema som motsvarar den maximala produktionsgenomströmningen, är det nödvändigt att allokera för resursspecifikationsstadier belastningsbara typer av arbetscenter i varje avdelning, vilket kan begränsa genomströmningen av etappen.

Detaljerna för typen av arbetscenter är följande:

• Flaggan "Planera arbete". Om flaggan är aktiverad kan denna typ av RC väljas i scenen som en laddad RC-typ. Flaggan är påslagen för RC-typer av divisionen, som kan visa sig vara divisionens "flaskhals".
• Maximal tillgänglighet (timme, min, sek). Bestämmer den maximala varaktigheten för bearbetning av en sats av ett steg i intervallet för den division som RC-typen tillhör. För en batch av ett steg kan en bearbetningstid inte tilldelas i ett intervall som är större än den maximala tillgängligheten.

I den nuvarande versionen av UP2 har inställningarna för RC-typer redan ändrats något, samtidigt som den beskrivna essensen bibehålls. Nu kan du använda kryssrutorna för att:

• Bör tillgängligheten av DC-tid beaktas vid schemaläggning på toppnivå? Och i så fall, kommer denna DC att vara nedladdningsbar eller inte.
• Bör DC vara inblandad i produktionsstyrning med hjälp av Route Sheets på lägre nivå?

Följande diagram visar strukturen och förhållandet mellan katalogerna "Företagsstruktur", "Typer av arbetscentra", "Arbetscentra".

Ange tillgänglig arbetscentertid

Använd dokumentet "Tillgänglighet för arbetscenter" för att gå in i fonden för tillgänglig tid för arbetscenter. I dokumenthuvudet väljer du avdelning, typ av arbetscenter och dokumentperiod.

Den tabellformade delen av dokumentet utökas med kolumner - delningsintervall (till exempel dagar) i dokumentperioden.

I raden i tabellsektionen måste du välja ett arbetscenter som hör till arbetscentertypen, och med kolumnintervall, ange antalet tillgängliga timmar för varje intervall.

Resursspecifikationer

Resursspecifikation som ett nätverksdiagram

Olika typer av specifikationer är kända, till exempel konstruktionsspecifikationer, operationella flödesscheman över rutter, "träningspass", som vägar för passage av en del genom avdelningar.

Det vanligaste sättet att beskriva tillverkningsprocessen för en produkt är ett nätverksdiagram.

Resursspecifikation beskriver nätverksschemat för tillverkning av en produkt.

Nätverksnoder i en sådan beskrivning är sammankopplade produktionsstadier, utförda sekventiellt eller parallellt av avdelningar som håller på att tillverka en produkt eller halvfabrikat. På en avdelning - en eller flera etapper som ska utföras.

Arcs– ömsesidigt beroende mellan stadier, visa, efter avslutade stadier kan följande etapper påbörjas.

Det är bekvämt att använda ett nätverksdiagram för att beskriva alla produktionsprocesser - i diskret, kontinuerlig produktion, i konstruktion, i designaktiviteter.

I allmänhet kan ett nätverksdiagram inte bara innehålla fakta om överföring av produkter mellan avdelningar, utan också fakta om överföring av arbetsresultat.

Resultatet av arbete som överförs mellan verkstäder behöver inte nödvändigtvis ha materiellt uttryck. Att överföra ett resultat från en avdelning till en annan avdelning, så att den andra avdelningen kan göra sin del av arbetet, innebär inte nödvändigtvis överföring av vissa produkter. Produkten kan till exempel placeras på en avdelning eller flyttas efter behov, medan arbetet med produkten kan utföras av andra avdelningar.

Produktionsstadierna kan omfatta inte bara tillverkning av produkter, utan även produktionsförberedelser, utrustningsinställning, dokumentationsutveckling, utbildning, installation och så vidare.

I extremfallet kan en resursspecifikation inkludera alla steg i tillverkningen av en produkt, i enlighet med produktstrukturens hierarkiska träd. I det enklaste fallet består en resursspecifikation av ett produktionssteg. Denna resursspecifikation kallas enstegs.

Ett exempel på en resursspecifikation som ett nätverksdiagram med nodsteg visas i följande diagram:

Resursspecifikationsstruktur

Strukturen för en resursspecifikation som ett konfigurationsobjekt visas i följande diagram:

Resursspecifikationen innehåller:

■ lista över utgångar,

■ lista över materialinsatser,

■ lista över arbetskostnader (per typ av arbete),

För varje insats, utmatning och arbetsinsats i en resursspecifikation i flera steg är det nödvändigt att ange i vilket skede insatsen (arbetsinsats) konsumeras eller produktionen produceras.

Vid ingången av stegen anges de initiala komponenter (material, tjänster) som kommer utifrån in i produktionsprocessen, som beskrivs i specifikationen.

Detta är de komponenter som för ett givet steg inte är utsignaler från andra steg med samma specifikation.

För en materialinmatning - en halvfärdig produkt, kan du aktivera flaggan " Tillverkad i process» och välj därför den resursspecifikation enligt vilken denna halvfabrikat ska produceras. Som ett resultat kommer denna resursspecifikation att "kompletteras" från denna ingång "nedåt" av en annan resursspecifikation. Således är det möjligt att skapa ett komplett träd av färdiga produkter från individuella specifikationer, i form av en kaskad av specifikationer.

Denna kaskad av specifikationer används när man genererar en specifikation för en specifik produktionsorderlinje. Hela kaskaden av relaterade resursstycklistor kopieras till orderradens stycklista.

I rekvisitan" Optimal mängd överföring mellan steg» du kan ange mängden av en produktbatch (resultat av arbete) som är tillrådlig att överföra mellan steg. Vid beräkning av produktionsschemat delas etappkvantiteten upp i batchdata, och varje batch planeras separat, baserat på tillgänglighetstiden för de laddade typerna av DC.

Standardarbetsintensiteten i resursspecifikationen, såväl som i den tekniska driften av ruttkartor, anges i avsnittet " Typer av arbete».

Typ av arbete - analys, enligt vilken arbetspriserna för arbetare skrivs in och arbetarnas produktion beaktas. Namnet på typen av arbete kan, förutom en beskrivning av själva arbetet, även innehålla den erforderliga kategorin arbetare och deras yrke. För en typ av arbete anges dess måttenhet, till exempel timmar eller bitar. Produkter.

För varje typ av arbete i det periodiska registret över information " Priser» kan du ange aktuellt pris per enhet för typen av arbete.

Resursspecifikationsstadier

En resursspecifikation kan vara enstegs eller flerstegs.

Om specifikationen är enstegs, redigeras detaljerna för ett enskilt steg direkt i specifikationsformuläret. Om specifikationen är flerstegsvis innehåller specifikationen en lista med steg. För att redigera etappdetaljer måste du öppna ett separat etappformulär från listan över etapper.

Sekvensen av etapper bestäms av stegdetaljerna: "Stagenummer", "Nästa etappnummer". Utifrån etappnumret och numret på nästa etapp byggs kopplingar mellan etapper i form av ett nätverksdiagram av etapper.

Scendetaljer bestämmer huvudparametrarna för scenplanering:

• Underavdelning, där scenen framförs. Endast en division är definierad för ett skede. Om samma steg kan utföras på olika avdelningar är det nödvändigt att skapa olika resursspecifikationer
• Kvantitet producerad på en gång. R batchstorlek eller volym av arbete för vilket stegens slutförandetid är standardiserad. Till exempel, om attributet specificerar en enhet, normaliseras exekveringstiden till ett.
• Flagga "Planera arbetet för typer av DCs". Bestämmer metoden för att normalisera stegets varaktighet.
  • Flaggan är aktiverad. I scenen är det nödvändigt att ange vilka typer av arbetscenter som kommer att laddas av scenen och varaktigheten av bearbetningen av den samtidigt producerade kvantiteten på den laddade typen av arbetscenter. Dessa typer av DC kan visa sig vara "flaskhalsar" när man uppfyller produktionsschemat, så deras belastning i schemat beräknas. Dessutom är det nödvändigt att ange den preliminära (före bearbetning på den laddade RC-vyn) och slutlig bufferttid. Buffertar upptar separata intervall i produktionsschemat. Låt oss komma ihåg att om bearbetningstiden före eller efter laddningstypen av RC är mycket kortare än intervallets varaktighet, kan specificering av bufferttider leda till omotiverad fångst av hela intervall av buffertar och följaktligen till en omotiverad ökning av varaktigheten av ett steg i produktionsschemat.
  • Flaggan är avstängd. Stadiet anger den tid det tar att slutföra det, för varje batchkvantitet. Man tror att under denna tid kommer etappen att vara avklarad i alla fall, oavsett antalet i etappen. Flaggan kan stängas av i etapper, vars utförande inte är relaterat till bearbetning på laddade typer av RC ("de så kallade "flaskhalsarna" anses följaktligen att avdelningen när man utför ett sådant steg har (relativ till avdelningar med ”flaskhalsar”) obegränsad produktionskapacitet.
• Flagga « Kontinuerlig» etapp avgör om etappexekveringen kan delas upp i flera icke-angränsande intervall i schemat.
  • Om flaggan är påslagen exekveras scenen kontinuerligt och kan endast placeras i schemat i angränsande intervall.
  • Om flaggan är avstängd kan exekveringen av steget avbrytas, det vill säga en del av tidsskedet kan placeras i schemat i ett intervall och en del - i ett annat, inte intill det första, intervallet.

Kontinuitetskriterium – minst en operation inom ett steg är kontinuerlig och jämförbar med intervallets varaktighet. Dessa operationer innefattar till exempel värmebehandling, målning, torkning och så vidare.

Skillnaden mellan att planera "diskontinuerliga" och "kontinuerliga" etapper visas i följande diagram.

Effektiviteten hos företag inom verkstadsindustrin beror till stor del på hur väl arbetet med referensinformation (RNI) är organiserat. Gruppens IT-direktör, Oleg Apanasik, talar för närvarande om projektet att implementera referensdatasystemet i AEM-Technologies-gruppen av företag och dess användning.

Intelligent Enterprise: Vilka var huvudmålen vid implementering av masterdata och vilka huvudstadier kan lösningen av denna uppgift delas in i?

Oleg Apanasik: Beslutet som fattats för implementering är baserat på våra anställdas erfarenhet av att hantera regulatorisk och referensinformation. Allt började med behovet av att centralisera hanteringen av katalogen över basmaterial och komponenter på två produktionsanläggningar och i förvaltningsbolaget. Vi utvecklade två företagsstandarder och flera arbetsinstruktioner, men varje gång dök det upp material i informationssystemen som inte matades in i enlighet med regulatoriska dokument, eller dubbletter av befintliga register.

Och i slutet av 2014 inledde vi ett projekt för att optimera arbetet med regel- och referensinformation. Inom dess ram utvecklades metoder för normalisering av flera huvudgrupper av kataloger - "Nomenklatur", "Motparter", "Anställda", "Finansiell" och "Teknologisk" - samt metoder för deras hantering.

Den organisatoriska ramen för projektet inkluderade huvudföretaget för vårt företag, beläget i staden Kolpino, och två filialer - Petrozavodskmash och Atommash från Volgodonsk.

Projektöversikten omfattade ett stort antal system, som är ganska lämpliga att delas in i separata grupper.

Först och främst talar vi om en hel rad av universella tillämpade affärssystem. Det här är två lösningar för företagsresurshantering - SAP ERP och 1C:UPP och två för personalhantering - SAP HR och 1C:ZUP. Detta bör även omfatta elektronisk dokumenthantering baserad på "1C: Document Flow", produkten "1C: Consolidation", samt utvecklingen för redovisning av mobilkommunikationskostnader "1C: Mobile Communication". Dessutom inkluderade kretsen produkter specialiserade för vår produktionsverksamhet: TeamCenter (Siemens PLM Software), ansvarig för design och teknisk förberedelse av produktion, ett system för att upprätthålla ett arkiv med teknisk dokumentation av företaget och hantera produktdata Sökning av Intermech-företaget , ett referens- och infIMBASE-data från samma tillverkare och åtkomstkontroll- och åtkomstkontrollsystem Perco. Infrastrukturprodukter var också involverade - ActiveDirectory domänkontrollant och MS SharePoint företagsportal.

Vilka universella metoder för informationsbehandling användes för att lösa de givna problemen - t.ex. datarensning, textsökning, hierarkisk eller annan klassificering, dataparameterisering, något annat? Allt som du just har listat avser tekniska metoder för att kontrollera riktigheten av bildandet av katalogposter för överensstämmelse med i förväg överenskomna regler. Vi pratar här om den så kallade "idiotsäkringen", och på den nivå som krävs för att arbeta med masterdatasystemet kan detta implementeras i vilket redovisningssystem som helst. Det är mycket svårare att komma överens om reglerna för underhåll av kataloger. För till exempel nomenklatur är det viktigt att namnet motsvarar regleringsdokumentet, och detta är effektivt när vi arbetar enligt GOST, OST eller TU. Men om kunden ber om att använda material enligt standarder som har upphört att gälla i landet, eller enligt kataloger av tillverkare, inklusive utländska, uppstår kontroversiella frågor som bör beskrivas i förväg. En uppsättning av dessa regler ligger till grund för metoderna och standarderna för hantering av masterdata.

Det skulle vara intressant att höra om metodisk betoning i arbetet med normativ och referensinformation...

För en framgångsrik drift av referensdatahanteringssystemet är det viktigt att genomföra det som enligt min mening är det längsta steget i projektet - datanormalisering. Innan projektet för att implementera master data management (MDM-system), vars huvudfunktion faktiskt är master data management, startade, använde företaget under många år olika redovisnings-, produktionslösningar samt designsystem, för vilka vi lagrar en enorm mängd olika referensinformation. Och vår naturliga önskan var att bevara och använda den ackumulerade data, men i enlighet med den nyutvecklade metodiken. För detta ändamål var datanormalisering nödvändig.

Jag kommer att nämna de viktigaste målen som vi strävade efter.

För det första måste varje katalogpost relatera till en specifik klass av huvudklassificeraren, och på ett sådant sätt att värdena för de obligatoriska egenskaperna för denna klass skrivs in för dessa poster.

För det andra tilldelas varje post ett enhetligt namn.

För det tredje skrivs attributvärdena för varje katalogpost in i enlighet med den godkända hanteringsmetoden.

För det fjärde bör det inte finnas några dubbletter i katalogen.

Och slutligen, för det femte, är det nödvändigt att varje katalogpost har en unik kod som är unikt förstådd av alla användare och applikationssystem som kommer åt katalogen.

Själva normaliseringsprocessen är också uppdelad i flera steg.

På scenen förarbete Klassificerare konfigureras och regler för bearbetning av "rå" data bestäms.

består i det faktum att alla filer som överförs från abonnentsystem, vars format överensstämmer med katalogdata, laddas in i MDM-systemet. Ingen databehandling eller analys utförs under nedladdning.

På scenen förbehandling av rådata Datauppsättningar genereras, "rå" data distribueras bland experter, regler för bearbetning utarbetas och utbildningsbaser byggs upp.

Klassificering av "rå" poster utförs i två steg: råposten tilldelas en eller annan klass och värdet på egenskaperna bestäms för varje vald klass.

Bildande av en referenspost: Efter klassificeringen söks en referenspost efter klassvärdet och en uppsättning karakteristiska värden, och om en post hittas hänvisar den "råa" posten till den. Om referensposten inte hittas skapas den med det angivna värdet för klassen och egenskaperna.

Bearbeta MDM-systemdata i abonnentsystemet - I detta skede uppdateras befintliga huvuddataobjektposter i abonnentsystemet eller nya läggs till.

Jag skulle vilja notera att hjärtat i MDM-systemet är ontologiservern (utvecklad av det ryska företaget AXELOT), som fungerar som en intelligent assistent till referensdataexperten. I klassificeringsstadiet uppmanar han experten att välja en klass som är lämplig för en given situation och för den valda klassen föreslår han egenskapernas värden.

Men integrationsbussen ansvarar för utbyte av data med abonnentsystem, som kopplar ihop objekt i olika system med hjälp av MDM-koder.

Finns det detaljer för att bygga ett referensdatahanteringssystem för stora maskinbyggande företag och vad består det av?

Det speciella med denna konstruktion ligger inte i företagets omfattning, utan i antalet informationssystem som drivs i företaget och i mängden referensböcker som används. Typen av produktion påverkar också hur du arbetar med systemet. Om vi ​​pratar om produktion av produkter i enstaka exemplar, läggs nya poster in i katalogen över material eller utrustning oftare än i serieproduktion, och följaktligen måste reglerna för att skapa poster vara strikt reglerade. I vårt företag läggs upp till tusen nya poster in i katalogen "Nomenklatur" enbart varje månad, så NSI-specialister har inte tid att ytterligare diskutera riktigheten av namngivningsmaterial.

Vilka element i det här fallet gäller det masterdatasystem du har byggt - material, verktyg, drift, personalkvalifikationer, leverantörer eller andra komponenter?

Vårt projekt utvecklade en metodik för att underhålla ett antal kataloger, indelade i fem grupper: nomenklatur, motparter, anställda, finansiell och teknisk. Om vi ​​talar om uppslagsböckerna som utgör dessa grupper, så beskriver de verkligen de komponenterna som du just nämnde, liksom många andra. Till exempel, i avsnittet "Nomenklatur" finns kataloger som "Basmaterial", "Verktyg", "Utrustning och inventarier", "Produkter". I motsvarande grupper finns kataloger som kallas "Motparter", "Anställda", "Personalpositioner", "Arbetscenter" eller säg "Kassaflödesposter". Kort sagt, vi har mer än tjugo referensböcker, och de täcker i detalj alla aspekter av AEM Technologies-företagets verksamhet, vare sig det är ekonomi, produktionsverksamhet eller personalledning. Dessutom, i fallet med att arbeta med nomenklaturkataloger, är datakällan MDM-systemet, och abonnenterna är redovisningssystem och designsystem. Men när man arbetar med katalogen "Anställda" är källan personalhanteringssystemet, och MDM-systemet spelar rollen som ett abonnentsystem och en integrationsbuss för redovisningssystem.

Traditionellt sett är starka och stabila förbindelser med leverantörer av material och komponenter, inklusive informations-, viktiga för stora verkstadsföretag. Finns det behov av någon form av harmonisering av masterdatasystemet med liknande system hos dina partners?

Vi har inte satt oss som uppgift att integrera med leverantörssystem. Och efter att ha gått hela vägen för att normalisera data på tre platser i vårt företag, tror jag att detta är osannolikt. Det är viktigt för oss att när den artikel som anges i materialbeskrivningen ingår i den tekniska specifikationen för leveransen, från den - i specifikationen av kontraktet och sedan anges i kvittodokumenten, följaktligen anländer till vårt lager, och är avskrivs för en specifik produktionsorder. I alla led ska sådan nomenklatur vara tydligt identifierad, oavsett var materiallistan upprättades, vem som var inblandad i köpet och var produktionen bedrivs.

Vad är IT-stöd för referensdata, vilka är nyckelfunktionerna här och hur är det tillrådligt att implementera detta i produkt- och organisatoriska termer?

I och med införandet av ett nytt informationssystem för IT-avdelningen tillkommer givetvis en funktion för att stödja det. Men det är inget nytt här: säkerställa oavbruten drift, säkerhetskopiering av data, användarutbildning, utveckling av regelverk och arbetsinstruktioner, modifiering av befintlig funktionalitet baserat på användarförfrågningar och dokumentation. En viss svårighet uppstår med integrationen av data, vilket arbete med som från början inte ingick i projektet... Men här har vi ett nära samarbete med våra entreprenörer.

Om vi ​​pratar kort om produktens och organisatoriska sidan av problemet, så var vår viktigaste IT-supportprodukt 1C:MDM Reference Information Management, samt Axelot Datareon ESB. Axelot var den huvudsakliga implementeringspartnern.

Många avdelningar i företaget är alltid intresserade av att utveckla ett system med reglerande och referensinformation. Hur kan detta intresse bättre beaktas i projektledningsstrukturen?

NSI-experter spelar en speciell roll både i implementeringsprojektet och i den efterföljande driften av MDM-systemet. Framgången för projektet beror till 80 % på deras lojalitet, arbetsförmåga och professionella kompetens. Det är de som bestämmer reglerna för att arbeta med information. Dessutom är dessa anställda från olika områden: för gruppen av kataloger "Nomenklatur" och "Teknologisk" är detta det tekniska direktoratet, för gruppen "Motparter" - kontoret, för katalogerna "Finansiellt" - redovisning och finansiärer, för " Anställda” - direktoratet för personalförvaltning. IT-tjänstens roll i utvecklingen av projektet är att hjälpa till att samla in eller formulera krav, samordna insamlad data med alla deltagare i affärsprocessen, säkerställa teknisk implementering och ytterligare stöd för verktyget för att underhålla kataloger. Men ägaren av masterdatahanteringsprocessen är företaget, och det beror bara på företagskunder om denna process kommer att utvecklas eller inte.

Ledande Intelligent Enterprise-expert Sergey Kostyakov pratade med Oleg Apanasik

Federal State Education Institute

Högre yrkesutbildning

National Research Technological University "MISiS"

Institutionen för automatiserade styrsystem

Kursuppgifter för kursen

"Systemteori och systemanalys"

Avslutad: Avdoshina Olga

Grupp: MA-10-1/I810-4

Lärare: Morozov E.A.

Moskva 2014

1.Definition av normativ information och referensinformation 3

2. Företagens problem och behov angående masterdatahanteringssystemet. 3

3.Enhetligt hanteringssystem för referensdata (EU-referensdata) 5

4.Skapande av ett automatiserat referensdatahanteringssystem 8

4.1 Analys av basdata 8

4.2.Val av arkitektur och uppskattning av kostnaden för att skapa ett automatiserat styrsystem för referensdata 10

4.3.Genomförande 15

5. Personer som ansvarar för att upprätthålla referensdata 16

6. Genomförandets effektivitet 18

7. Lista över begagnad litteratur 20

Definition av normativ information och referensinformation

Driften av varje automatiserat system baseras på regulatorisk referensinformation (RNI). Masterdata är en semipermanent del av all företagsinformation som inte genomgår betydande förändringar i organisationens dagliga verksamhet. Basdata inkluderar: ordböcker, uppslagsböcker och klassificerare, vars element (till exempel koder, namn på material, tjänster, entreprenörer, måttenheter etc.) används i genereringen av aktuella dokument.

Referensdata används i automatiserade system vid generering av verksamhetsdokument, planering och rapportering. Följaktligen beror kvaliteten på denna planerade, operativa och rapporterande information direkt på kvaliteten på masterdata. Hanteringsfel i samband med information av dålig kvalitet kostar ibland företag miljontals dollar i förluster.

Företagens problem och behov angående masterdatahanteringssystemet.

Företag använder som regel flera automatiserade system som stödjer olika affärsprocesser, där samma kataloger underhålls oberoende av varandra. Denna helt typiska situation orsakar följande problem:

Ytterligare kostnader för oberoende underhåll av samma kataloger;

Ytterligare kostnader förknippade med att säkerställa informationsinteraktion mellan system som använder olika kataloger för samma masterdataobjekt;

Stor arbetsintensitet och höga kostnader för att generera konsoliderad rapportering baserad på data där samma referensdataobjekt (varor, tjänster, entreprenörer) har olika koder och namn;

Låg kvalitet på regel- och referensdata.

Vad betyder "dålig kvalitet" regulatoriska referensdata? Detta är referensdata som:

Har problem med att strukturera material och utrustning i grupper;

Duplicerade eller motsägelsefulla data från katalogen över materiella och tekniska resurser (varor och tjänster) leder i 70% av fallen till en betydande ökning av företagets lager och bildandet av illikvida tillgångar. Till exempel:

Frånvaron av nödvändiga parametrar i produktbeskrivningen i katalogen kan leda till köp av en produkt som inte uppfyller de nödvändiga egenskaperna. Som ett resultat bildas illikvida tillgångar i lager;

Närvaron av dubbletter i katalogen tillåter dig inte att korrekt utföra den automatiska konsolideringen av allt beställt material och utrustning med samma namn för att få en konsoliderad applikation. Som ett resultat kommer beställningen att läggas hos leverantören i olika partier och företaget kommer inte att få någon rabatt för att lägga en beställning med stor volym, och därför kommer köpet att slutföras till ett högre pris;

Användningen av olika koder och namn på material och utrustning av olika avdelningar tillåter inte att analysera tillgången på material och utrustning i lager och användningen av befintliga lager, istället för att köpa nytt material och utrustning, vilket också leder till ekonomiska förluster.

Den låga kvaliteten på referensdata är en följd av bristen på specialisering i hanteringen av referensdata. Uppgifterna att öka affärseffektiviteten, behovet av att bygga en modern grund för utvecklingen av företagens IT-landskap, konstruktionen av nya företags affärssystem och utvecklingen av befintliga kräver ökad effektivitet i hanteringen av regulatoriska och referensdata. Införandet av Unified Reference Data Management System löser detta problem.

Enhetligt hanteringssystem för referensdata (EU-referensdata)

Huvuddataundersystemet har alltid funnits i tillämpade automatiserade system (redovisning, personal, verksamhetsplanering och produktionsledningssystem, leverans- och försäljningsledningssystem etc.) just som ett delsystem. I slutet av 1900-talet och början av 2000-talet bildades dock ett nytt förhållningssätt för hantering av normativ information och referensinformation och utvecklas snabbt, vilket gör det möjligt att säkerställa hög kvalitet på normativ och referensinformation.

Kärnan i det nya tillvägagångssättet är att skapa ett specialiserat Unified Master Data Management System (US Master Data Management System) i företag. Underhållet av all regulatorisk och referensinformation för företaget allokeras till ett separat system där företagets enhetliga kataloger upprätthålls: Unified Directory of Material and Technical Resources (MTR), Unified Directory of Works and Services, Unified Directory of Contractors, Unified Financial Directories, Unified Personal Directories, etc. d. Data från Unified Master Data Management System används som en källa för masterdata av alla applikationer företagssystem.

Figur 1. Länka data med stamdata

Masterdata underhålls alltså centralt i ett specialiserat system. I alla andra automatiserade system stoppas ändringar av stamdata. Masterdata ändras baserat på användarförfrågningar som skickas till Unified Master Data System. Programvaran i Unified Master Data System måste säkerställa generering, samordning och bearbetning av sådana förfrågningar i enlighet med de godkända föreskrifterna, såväl som replikering av uppdaterade masterdata till tillämpade automatiserade system. Underhållet av Unified Master Databases utförs av specialister inom området Master Data – Master Data Experts. Företag skapar Master Data Management Services. Ett nytt yrke är på väg - NSI-expert. När man skapar Unified Master Data Management Systems, utför företag arbete för att normalisera regulatoriska och referensdata. Normalisering innebär eliminering av fel, felaktigheter och ofullständighet i data, eliminering av dubbletter, tillägg av saknad information, sammanslagning av data i referensdatakatalogen.

Med ett betydande antal IT-applikationer eller en geografiskt fördelad struktur kräver underhåll och uppdatering av masterdata skapandet av ett speciellt automatiserat system (AS). Dess utveckling kommer att bli en av delarna för att skapa ett enhetligt informationsutrymme på företaget. Alla AS, oavsett var de är belägna, kommer att använda vanliga namn på objekt, och avdelningarnas och avdelningarnas arbete kommer att baseras på gemensamma regler, regler och procedurer.

Skapandet av ett automatiserat hanteringssystem för referensdata sker i flera steg: analys av sammansättningen av referensdata och processerna för dess underhåll, val av arkitekturen för det automatiserade systemet, bedömning av kostnaden för att skapa, utveckling och support.

Skapande av ett automatiserat referensdatahanteringssystem

1. Masterdataanalys

Huvudtyperna av referensdata inkluderar: referensböcker, klassificerare och reglerande dokument. Sammansättningen av referensdata visas i fig. 2.

Ris. 2. Typisk sammansättning av referensdata

Ett av de första stegen i att organisera hanteringen av stamdata är skapandet av ett register, som i detalj beskriver alla typer av stamdata som används i företaget. För föreskrifter ska exempelvis egenskaper som namn, ansvarig specialist, införandedatum, aktuella objekt, enheter som omfattas av föreskriften, tillhörande klassificerare och kataloger anges.

Dessutom är det nödvändigt att upprätta kopplingar mellan olika typer av referensdata, bestämma sammansättningen av informationen i dem, ange i vilka system uppgifterna behandlas (informationskällor) och för vilka affärsprocesser deras användning är nödvändig (konsumenter av information).

En sådan analys låter dig välja modeller för att upprätthålla masterdata inom alla funktionsområden, utveckla arbetsbestämmelser vid ändring eller radering av data (till exempel förstå vilka avdelningar som ska samordna ändringarna) och även identifiera fall av dubblering av information. På ett av företagen fann man alltså att enskilda divisioner underhåller och använder sina egna klassificerare och kataloger, som exakt upprepar innehållet i det centralt underhållna referensdatamaterialet. Till exempel duplicerade den lokala "Gäldenärsförteckningen" och "Gäldenärsförteckningen" den allmänna "förteckningen över motparter" till innehåll. Istället för att använda den allmänna "katalogen över grenar och strukturella underavdelningar" användes vår egen "katalog över separata underavdelningar" och "Klassifierare av grenar och separata underavdelningar". Som ett resultat slösades resurser på att underhålla flera typer av stamdata som innehöll samma data.

Baserat på analysen av registret över tillsyns- och referensinformation och data om kopplingarna mellan olika typer av referensdata, samt med hänsyn till strukturen och specifikationerna för företagets verksamhet, bildas de viktigaste funktionella kraven för det framtida AS:

möjligheten till centraliserad hantering av kataloger, klassificerare och andra dokument;

möjligheten till centraliserad kontroll av alla reglerings- och referensdata (under lagring, användning eller ändring);

stöd för centraliserad och distribuerad (om nödvändigt) hantering av masterdata;

lagra aktuella och historiska data i centralkontoret och filialerna, ge snabb åtkomst till dem;

automatisk synkronisering av reglerings- och referensinformation mellan systemelement i olika avdelningar eller grenar (vid behov);

möjligheten att ändra sammansättningen av kataloger och deras struktur utan att uppgradera systemkoden.

Valarkitektur och kostnadsbedömning för att skapa ett automatiserat referensdatahanteringssystem

Arkitekturen för referensdatahanteringssystemet kan väljas med hjälp av funktionskostnadsanalys. Detta är en metod som bestämmer det optimala förhållandet mellan egenskaper, egenskaper, funktioner hos systemet som är viktiga för användaren och kostnaderna för deras implementering.

I förhållande till referensdata innebär användningen av metoden funktionell kostnadsanalys att för varje typ av referensdata bestäms följande:

lista och antal affärsprocesser som kräver dess användning;

"användbarhet" av denna typ av referensdata (i termer av funktionsområden);

mängden kostnader förknippade med dess skapande, underhåll och uppdatering.

Finansiella kostnader bestäms med hänsyn till kostnaderna för att utveckla och implementera IT-applikationer, inköp av hårdvara och mjukvara som krävs för att skapa och använda masterdatasystemet, samt med hänsyn till kostnaderna för personal som kommer att vara involverad i service av systemet (utbildning , arbetsplatsutrustning, löner etc.). Det är också nödvändigt att ta hänsyn till indirekta kostnader som uppstår om kontroll över underhållet och stödet av referensdata och ändringar av referensböcker inte säkerställs. Detta kan till exempel vara kostnaden för att eliminera en felaktigt inmatad post i en klassificerare eller katalog. För dubbla poster i materialkatalogen är kostnaden för ett sådant fel lika med kostnaden för överskottslager i lagret.

Det är värt att notera att metoden för funktionell kostnadsanalys också används för att minska kostnaderna och förbättra kvaliteten på affärsprocesser i samband med att arbeta med masterdata. För att göra detta sammanställs en lista över funktioner som utförs för att underhålla, stödja och uppdatera data, rangordnad efter kostnad, arbetsintensitet eller tid. Åtgärder vidtas för att minska kostnaden eller genomförandetiden för de mest "dyra" eller "tidskrävande" funktionerna. Onödiga eller duplicerade operationer elimineras och sedan omfördelas de resurser som frigjordes på grund av förändringarna.

Baserat på de erhållna uppgifterna bestäms arkitekturen för referensdatasystemet - centraliserad eller decentraliserad. Valet av ett centraliserat system kommer till exempel att avsevärt förbättra kvaliteten på den information som tillhandahålls, vilket är oerhört viktigt för företagets centrala affärsprocesser. Kostnaden för detta alternativ kan dock vara högre än kostnaden för det motsatta.

Ett mer effektivt alternativ är att skapa ett system med en arkitektur med flera noder. Vad betyder det här?

Externa organisationer

Interna uppdelningar

Central nod för AS NSI

KonsumenterNSI

KonsumenterNSI

KonsumenterNSI

KonsumenterNSI

KonsumenterNSI

Underordnade noder till AS NVI

Ris. 3. Diagram över ett referensdatasystem med en flernivåarkitektur

AS NSI inkluderar en central nod och underordnade noder. Organisatoriskt är den centrala noden belägen i företagets huvudkontor, och underordnade finns i dess regionala grenar eller divisioner. Systemet bygger alltså på en geografiskt fördelad princip i enlighet med företagets struktur. Varje nod kan interagera med leverantörer, förändringsinitiatorer eller masterdatakonsumenter. Alla noder är sammankopplade genom olika typer av telekommunikation, vilket möjliggör snabbt datautbyte och automatisk synkronisering. Ett diagram över ett sådant system visas i fig. 3.

Faktum är att varje nod är ett miniautomatiskt system för att underhålla masterdata och tillhandahåller nödvändiga data för alla IT-applikationer som används i denna avdelning (Fig. 4). Spridning av information i hela systemet och upprätthållande av referensdatabasen säkerställs genom automatiskt datautbyte mellan noder.

Ris. 4. Typisk nodarkitektur

Valet av en sådan arkitektur gör det möjligt att dra fördel av den centraliserade hanteringen av masterdata (alla kataloger upprätthålls i ett enda system) och samtidigt fördela belastningen som är associerad med denna process över flera avdelningar (noder i det enhetliga systemet finns inte bara i företagets centrala kontor, utan också i regionala filialer). Dessutom, med detta tillvägagångssätt, anpassas systemet till den teknik för masterdatahantering som redan används på företaget och möjliggör samtidigt en smidig omorganisation för att öka effektiviteten. Detta leder till en minskning av kostnader och risker som uppstår vid implementering av ett enhetligt masterdatasystem.

Systemet låter dig automatiskt övervaka utförandet av operationer för att underhålla masterdata och, om nödvändigt, fatta beslut om omfördelning av resurser som är involverade i denna process. En annan fördel är möjligheten att koppla ändringar i referensböcker till relevanta regeldokument och därigenom motivera behovet av sådana justeringar. Kontroll av ändringar i relaterade kataloger säkerställs, vilket minimerar risken för informationsfel. Dessutom tillåter systemet inte att information matas in eller ändras utan tillstånd. Det innebär att det alltid är känt vem av specialisterna som skrivit in vissa uppgifter i uppslagsböcker eller andra dokument och när.

Uppdateringen av samma katalog kan utföras på olika noder - på detta sätt organiseras distribuerad hantering av masterdata. I det här fallet är det möjligt att separera åtkomsträttigheter för att utföra denna åtgärd (om en nod är ansvarig för att underhålla katalogen kommer ändringar som görs på andra noder först att få tillfällig status). Alla justeringar som görs replikeras snabbt i hela systemet, och endast den del av data som har ändrats överförs. Som ett resultat minimeras trafiken mellan noderna avsevärt. Det är värt att notera att kommunikation mellan noder kan organiseras med nästan alla medel och kanaler, vilket inte kräver speciella investeringar i utvecklingen av telekommunikation.

Genomförande

Efter att ha bestämt arkitekturen för det framtida systemet börjar dess omedelbara implementering: utveckling, installation och konfiguration av den centrala noden. Därefter läggs kataloger, klassificerare, regleringsdokument och annan liknande data från olika källor in i systemet. Processerna för att upprätthålla referensdata justeras med hänsyn till den teknik som används på företaget. Därefter integreras systemet med de IT-applikationer som används. Och slutligen, i slutskedet, replikeras den skapade strukturen till grenar och divisioner av företaget: regionala noder bildas.

Ansikten,ansvarigför att upprätthålla referensdata

En viktig fråga i genomförandet av projektet är bildandet av en referensdataavdelning, vars uppgift kommer att vara att säkerställa enhet och relevans för alla typer av referensdata. Deltagande av specialister är nödvändigt redan i utvecklings- och distributionsstadierna av AS NSI: deras funktioner kommer att omfatta samordning av arbetet med att skapa, implementera och underhålla enhetliga informationskataloger och klassificerare (till exempel "Katalog över strukturella divisioner", " Katalog över tekniska objekt", "Katalog över anläggningstillgångar" etc.).

Dessutom kommer verksamheten för referensdataavdelningen att vara relaterad till underhåll av företagskataloger, kontroll över användningen av allryska och branschklassificerare, utveckling och underhåll av ett register över kataloger samt interaktion med externa organisationer ( Federal Agency for Metrology, Gosstroy) om användningen av referensdata. Ett annat aktivitetsområde är skapandet av ett datalager för beställningar, instruktioner och andra liknande dokument.

Dessutom utför avdelningen uppgifterna att underhålla och utveckla ett enhetligt referensdatasystem. Huvudfrågorna inkluderar: utveckling av tekniska och operativa instruktioner för användare och specialister som ansvarar för att upprätthålla masterdata; organisera sin utbildning; utveckling av långsiktiga och aktuella planer för utvecklingen av referensdatasystemet. Slutligen interagerar referensdataavdelningen med andra företag som tillhör samma innehav i frågor om gemensamt underhåll av kataloger (om det finns ett sådant behov).

Deltagare i processen
Systemanvändare	Sök efter information: I centraliserade kataloger; I hjälpreferensböcker. Bildning: Applikationer för att lägga till poster till centraliserade kataloger; Program för att ändra poster i centraliserade kataloger; Applikationer för att lägga till/ändra information i extra kataloger.
Referensdataspecialist	Bearbetar en användarförfrågan: Analys av riktigheten av användarens applikation; Analys av förekomsten av dubbla positioner och förekomsten av en arbetsförfrågan om att lägga till eller ändra samma objekt; Skicka en begäran till användaren för att förtydliga information; Vägran att utföra en felaktig användarförfrågan, med angivande av orsaken; Lägga till, vid behov, information om referensdataobjektet; Klassificering av referensdataobjekt; Slutförande av bearbetning.
Metodolog	Kontrollera korrektheten av klassificering och bearbetning; Retur av ansökan för ytterligare behandling; Vägran att utföra en felaktig användarförfrågan, med angivande av orsaken.
Senior forskningsspecialist	Utnämning av en exekutor för att behandla ansökan bland masterdataspecialisterna; Kontroll av ansökningstider; Klassificeringsprocedurer: Göra tillägg och ändringar i klassificerarna; Tilldela en uppsättning egenskaper till masterdataobjekt; Klassificering av det skapade/ändrade masterdataobjektet.

Bord 1. Funktioner för centraliserad hantering av referensdata beroende på deltagarens roll

Effektivitetgenomförande

Vad tvingar företag att implementera en eller annan form av datavetenskapliga stödsystem? Förutsättningarna varierar, men vi kan identifiera uppgifter som är gemensamma för alla stora organisationer:

Behovet av integration av informationssystem på referensdatanivån, vilket skulle effektivisera och minska kostnaderna för processerna för att upprätthålla masterdata;

önskan att använda enhetliga referensinformationskoder för att automatisera insamlingen och analysen av företagsrapportering;

möjligheten att förbättra kvaliteten och tillförlitligheten hos reglerings- och referensinformation genom att eliminera dubblering av referensdata, optimera föreskrifter för dess underhåll och minska rutindrift;

centralisering av funktioner för att upprätthålla referensinformation baserat på utvecklade företagsklassificerings- och kodningsstandarder.

Förutom att lösa ovanstående problem kan implementeringen av ett referensdatastödsystem ge följande fördelar.

Direkta ekonomiska fördelar:

spara pengar som spenderas på att säkerställa kvaliteten (relevans, konsistens, fullständighet) av referensinformation i alla operativa informationssystem inom ramen för det "traditionella systemet" (dvs. kontrollera referensinformation och säkerställa dess kvalitet i det ögonblick då en begäran om användning av information av detta slag tas emot i ett specifikt system);

besparingar på användarlicenser för företagsdriven programvara för hantering av referensdata;

minska kostnaderna för att underhålla företagets stamdata genom att organisera en enda ingångspunkt för hantering av referensinformation som används av alla företagssystem;

minska kostnaderna för informationsutbyte av data mellan IS som drivs i företaget, öka dess effektivitet.

Indirekta ekonomiska fördelar:

förebygga företagsförluster i samband med användning av lågkvalitativ (irrelevant, motsägelsefull, ofullständig) referensinformation;

upprätthålla investeringar i redan utplacerade system och minska kostnaderna för deras integration i företagets informationsutrymme;

förhindra förluster på grund av fel i konsoliderad rapportering som är förknippade med irrelevansen eller inkonsekvensen hos referensinformationen som används i dess bildande.

Fördelar med NSI supportverktyg:

öka relevansen av masterdata för alla anslutna informationssystem;

tillgång till referensdata för alla anställda i företaget i realtid, oavsett var han befinner sig;

tydlig ansvarsfördelning för att hantera specifika kataloger.

Lista över begagnad litteratur

http://www.epam-group.ru/

http://computel.ru/upload/press%20about%20Computel/20130516_AutomatizationIT.pdf

http://consulting.1c.ru/ejournalPdfs/vlasov.pdf

http://nsint.ru/

Asadullaev S. "Metadatahantering med IBM Information Serve"", 2008

Maxim Vlasov "NORMATIV REFERENSINFORMATION: TESTAD MED PRAKTISKA"