Hantering av normativ och referensinformation. Se vad "NSI" är i andra ordböcker NSI-efterlevnad

Bransch: Energi och boende samt kommunal service

Eftersom Rosatom förenar många företag och organisationer är skapandet av branschövergripande kataloger en nödvändig förutsättning för att centralisera och säkerställa insyn i inköpsaktiviteter och relationer med leverantörer, samt för att organisera det gemensamma arbetet med industriföretags IT-system. Det är därför projektet för att skapa ett enhetligt branschsystem för reglerande och referensinformation (URS NSI) inkluderades i "Program för omvandling av det finansiella och ekonomiska blocket och informationstekniken" av State Corporation. EOS NSI-systemet kommer att täcka organisationer i blocken "konstruktion och konstruktion av kärnkraftverk", "drift av kärnkraftverk" och "livscykel för kärnbränsle." Baserat på resultaten från en öppen tävling var IBS involverad i genomförandet av projektet och en specialiserad SAP-lösning valdes som plattform.

Hittills har ett pilotprojekt för att skapa ett enhetligt system för vetenskaplig information slutförts. Inom dess ram har ett antal kataloger skapats: "Motparter" (gäldenärer/borgenärer, juridiska personer, bosatta/utländska), "Material och tekniska resurser" (MTR), "Element av industrianläggningar", "Enhetligt diagram". of accounts”, en uppsättning allryska kataloger och klassificerare . De mest populära referensböckerna har blivit "Motparter" (innehåller för närvarande cirka 70 tusen poster), "MTR" (cirka 150 tusen poster) och "Enhetlig kontoplan". Redan under pilotprojektet var 215 företag anslutna till EOS NSI genom att använda katalogen "Motparter" och 35 företag som använde katalogen "MTR". Totalt arbetar mer än 4 tusen användare i systemet, deras åtkomst tillhandahålls med hjälp av portaltjänsten.

Arbete pågår för närvarande med att replikera systemet. Det förväntas att 2012 kommer det totala antalet EOS NSI-användare att nå cirka 10 tusen personer. Således kommer detta projekt inom området för att organisera reglerings- och referensinformation på SAP-plattformen att bli ett av de största i världen och det största i Europa. Resultaten av projektet och kapaciteten hos EOS NSI kommer att användas i ett antal andra IT-projekt inom Rosatom State Corporation. Bland dem är skapandet av ett enhetligt industriupphandlingssystem, ett enhetligt branschsystem för att integrera företagsapplikationer, ett enhetligt industridokumentflödessystem, ett fastighetsförvaltningssystem, införandet av ett enhetligt avvecklingscentersystem, etc.

« Centralisering av processerna för att upprätthålla regel- och referensinformation och användningen av ett lämpligt informationssystem kommer för det första att öka kvaliteten och tillförlitligheten hos informationen som tillhandahålls av IT-systemen. För det andra kommer det att minska kostnader och tid för att generera konsoliderad rapportering. För det tredje minimerar det risker på grund av ofullständig eller felaktig betalningsdata. Detta kommer också att möjliggöra optimering och säkerställande av insyn i upphandlingsprocesser och arbete med leverantörer, minska planeringstiden för inköp och leverans av material och utrustning, optimera processen för att underhålla masterdata genom att organisera en enhetlig förvaltningsmiljö", noterade Chef för NSI-programmet vid Greenatom CJSC Kirill Sukovykh.

När det gäller omfattningen och komplexiteten hos vissa informationssystem anges vanligtvis egenskaper som antalet jobb och flöden av bearbetade dokument och den totala volymen av databaser. Men på senare tid har antalet och storleken på kataloger allt oftare nämnts som en integrerad egenskap. Detta är inte särskilt tydligt för okunniga människor, men för specialister talar sådan information volymer. När allt kommer omkring är det referensdata (utbud av varor och produkter, detaljer om partners, leverantörer och kunder, beskrivning av organisationens struktur etc.) som i huvudsak är informationskärnan i företagsledningssystemet, inklusive redovisningsuppgifter, resursplanering, CAD, etc.; de säkerställer konsistens och konsolidering av data, eliminerar redundans av information och optimerar sökningen efter nödvändig information. Dessutom kombinerar kataloger alla andra dokument i systemet - fakturor, kontrakt, beställningar etc. - under hela dess livscykel.

För närvarande är ett av de viktigaste problemen i utvecklingen av informationsteknik på företagsnivå dataintegration. Ganska ofta förstås det som förmågan att arbeta med olika dataformat från olika fysiska källor (inklusive att konvertera dem från ett format till ett annat). Men en sådan syn är åtminstone ytlig. Faktum är att samordning och korrekt förståelse av information är omöjlig utan dess meningsfulla förståelse med hjälp av vanliga referensböcker.

Ris. 1. Organisation av arbetet med den centraliserade referensdatatjänsten

Detta problem är relevant över hela världen, men dess betydelse är särskilt stor för Ryssland, och här kan två punkter lyftas fram:

Automatisering av inhemska företag utvecklades som regel från botten och upp genom den gradvisa datoriseringen av enskilda områden och divisioner. Förutom att använda olika mjukvaru- och hårdvaruplattformar använde de också lokala kataloger, vilket inte är en lätt uppgift;

I det nuvarande skedet av bildandet av en marknadsekonomi i vårt land finns det aktiva processer för fusioner, förvärv, bildande av holdingstrukturer etc. I detta fall uppstår komplexa uppgifter att kombinera informationsresurser, men ofta på nivån för fullständig företagsledningssystem.

Vi har lyft fram dessa två punkter för att belysa de grundläggande skillnaderna i de bakomliggande situationerna. I det första fallet, i allmänhet, kan vi helt enkelt prata om fel när vi skapar systemet - det var nödvändigt att initialt skapa ett enhetligt referenssystem för företag, implementera en top-down designmetod. När man slår samman olika företag är situationen mycket mer komplicerad, eftersom vi talar om oberoende företag.

Ris. 2. Med hjälp av Ontologic 5.0-teknik kan du skapa ett enhetligt hanteringssystem för masterdata

Men sådana interna problem hos organisationer är bara toppen av isberget! I en tid präglad av ekonomisk globalisering och e-affärer måste företagsinformationssystem kommunicera med informationssystem hos partners, leverantörer och kunder. Och de måste tala på ett språk som varandra förstår. Sedan kan vi gå vidare till frågor om offentlig förvaltning...

För att illustrera vikten av bakgrundsinformation ska vi bara ge två exempel.

1. Som ni vet skapades för ungefär ett år sedan det anglo-ryska företaget TNK-BP, som bildades som ett resultat av en serie preliminära sammanslagningar av stora industriföretag (ONAKO, SIDANKO, TNK). En av de första uppgifterna från ledningen för det nya företaget var att organisera en enhetlig företagskatalogklassificerare av materiella och tekniska resurser. Detta måste göras redan innan man identifierade andra områden för utveckling av integrationslösningar och ledningssystem. Dessutom var det det gemensamma regelverket som var tänkt att bidra till bildandet av en enhetlig anglo-rysk företagsmentalitet (företaget har specialister från ryska TNC och engelska BP) och en gemensam förståelse för att göra affärer.

2. I slutet av andra världskriget satte USA:s president Roosevelt uppdraget att förstå orsakerna till problem med leveransen av reservdelar till fronten. Efter att ha utfört den nödvändiga forskningen kom amerikanerna till slutsatsen att reservdelar skickades till trupperna i mängder flera gånger större än behovet av dem. Samtidigt rådde det fortfarande brist på reservdelar på grund av att samma produkter samlades på lager, men märktes olika och bär olika namn. Som ett resultat utfärdade presidenten ett direktiv för att skapa ett enhetligt federalt system för att katalogisera förnödenheter för statliga behov, och i första hand för försvars- och säkerhetsbehov. Under de senaste tjugo åren har USA årligen investerat från 2 till 4 miljarder dollar i standardiseringsprogram enbart genom att använda modulära strukturer (produktanaloger) för att minska utbudet av försvarsdepartementet med cirka tre gånger.

Hantering av normativ och referensinformation

För att beteckna sådan referensinformation i automatiserade företagsledningssystem i väst används termen Master Data (masterdata, masterdata) och uppgifterna att hantera den kallas Master Data Management (MDM). Men på det ryska språket används nu oftare begreppet normativ referensinformation (RNI), som dök upp i discipliner relaterade till ekonomisk förvaltning redan i tider före datorn. I det här fallet återspeglar definitionen av "normativ" det faktum att problemet med att skapa kataloger på företagsnivå går långt utanför företagets gränser, det måste lösas med hänsyn till industri-, statliga och internationella standarder.

Vi kan ge följande definition: masterdata är en villkorligt permanent del av all företagsinformation (institutionell) i motsats till aktuell information som genereras direkt i processen för organisationens aktiviteter. Stamdata inkluderar ordböcker, uppslagsböcker och klassificerare, data från vilka (till exempel termer, måttenheter, koder, materialnamn, entreprenörer etc.) används för att skapa aktuella dokument. Sålunda, när en faktura genereras på en dator, väljs som regel namnen på material, måttenheter, namnet på det mottagande företaget (motparten), dess uppgifter och ett antal andra fält från kataloger som är inbyggda i systemet , istället för att skrivas in manuellt.

För att bedöma omfattningen av MDM-uppgifter kan följande data tillhandahållas. För stora företag inom olje- och gassektorn varierar storleken på materialkataloger från 100 till 250 tusen artiklar och för motparter - från 3 till 12 tusen poster.

Det är ganska uppenbart att frågorna om att skapa och upprätthålla referensdata klassificeras som oberoende uppgifter i företagets ledningssystem som helhet, detta hanteras ofta av en separat tjänst hos företaget.

Enligt experter är kostnaden för att behandla en stamdatapost i vårt land 2-5 dollar (utomlands - 10-20 dollar). Följaktligen kan kostnaden för ett projekt för bildandet av masterdata för ett stort företag uppskattas till 400-1000 tusen dollar (inklusive kostnaden för programvara, implementeringsrådgivning och support).

Olje- och gasindustrin, liksom ett antal statliga och regionala strukturer, var de första som förstod behovet av att utföra arbete med masterdata som en oberoende del av att skapa en organisations ledningssystem. För närvarande genomförs cirka 10-15 stora projekt om detta ämne i Ryssland, medan analytiker noterar ett snabbt ökat intresse för detta arbete från både företagssektorn och den offentliga sektorn. För att möta kundernas växande behov behövs en beprövad metod för att genomföra sådana projekt.

Problemet med att skapa ett företagsreferensdatasystem är just att det inte har en enkel lösning. Det verkar som att det mest rimliga sättet är att använda en färdig uppsättning kataloger (internationella, statliga, industri). Men faktum är att det kommer att vara extremt obekvämt för ett specifikt företag att använda dem (de är för överflödiga och tar inte hänsyn till organisationens särdrag), och dessutom är det helt enkelt omöjligt att skapa ett sådant globalt masterdatasystem i sin helhet (för mer information om detta ämne, se Dmitry Gulkos artikel "Hur man undviker typiska misstag när man bygger företags- och industrisystem med regulatorisk och referensinformation", PC Week/RE, N 18/2004, s. 35).

Att lösa problemet är endast möjligt i form av att skapa ett specialiserat system för att underhålla masterdata med hjälp av lämpliga standarder, metoder och programvara. I själva verket borde detta arbete kombinera tre parters ansträngningar:

Skapare av regler och standarder (både stat och industri);

Grundläggande mjukvaruleverantörer;

Systemintegratörer och konsulter som kan implementera allt detta med hänsyn till branschpraxis, nationella särdrag etc.

Under sovjettiden var statliga myndigheter mycket aktivt involverade i regleringsfrågor. Med början av perestrojkan var det ett misslyckande i denna verksamhet, och för bara 5-7 år sedan tog statliga strukturer upp detta arbete igen. Flera lagar och förordningar har redan antagits om detta ämne, och för närvarande finns det flera statliga standardklassificeringssystem för produkter och aktiviteter (OKP, OKVED, OKDP, TN VED, ECPS). Men var och en av dem har sitt eget specialiserade syfte och är inte lämpliga att använda i sin rena form i industri- eller företagssystem. Västerländska klassificeringssystem kan inte tillämpas i vårt land på grund av de betydande nationella särdragen i vår ekonomi. Generellt bör det noteras att för att effektivisera situationen på området för företags stamdata är ett mer aktivt deltagande av statliga organ önskvärt, men samtidigt som det inte går över gränsen för rimlig reglering.

Fig.3. Funktionsdiagram över masterdatahanteringssystemet

Master Data Management-frågor är också i fokus för grundläggande mjukvaruleverantörer. Samtidigt närmar de sig sin lösning från olika håll. Först och främst hanteras dessa uppgifter naturligtvis av tillverkare av ERP-lösningar, och ledaren här är SAP. Ett annat exempel är mjukvaruutvecklare för integration av infrastruktur. Här bör vi nämna IBM Corporation - dess senaste förvärv av Ascential Software förklaras till stor del av företagets avsikt att stärka MDM-riktningen (se PC Week/RE, N 10/2005, s. 12). Slutligen måste något sägas om leverantörer av dokumenthanteringssystem (t.ex. Hummingbird). Deras närvaro i MDM-segmentet förklaras å ena sidan av deras erfarenhet av att lösa dataintegrationsproblem, och å andra sidan av behovet av att använda intelligenta teknologier för att behandla ostrukturerad information för att hantera referensdata.

När det gäller systemintegratörer och konsultföretag, hanterar alla företag som genomför stora projekt för att skapa företagsledningssystem MDM-frågor i en eller annan grad. Några av dem (Intertech, LANIT, IBS, Unit Space, Katalit) har specialiserad utveckling inom detta område. Härnäst kommer vi kort att prata om förslag för att bygga företagsreferensdatasystem från Intertech, som under de senaste åren skaffat sig gedigen erfarenhet av att implementera liknande lösningar i företag som TNK-BP, Tatneft, SIBUR, samt i olika federala myndigheter och myndigheter avdelningar Moskva, etc. Hon ingick nyligen ett samarbetsavtal inom MDM-området med SAP Corporation (se PC Week/RE, N 13/2005, s. 49).

Teknik för att konstruera masterdata från företaget "Intertech"

Metodiken som föreslås av Intertech innebär skapandet av ett enhetligt system för att upprätthålla referensdata, som länkar all regulatorisk och referensinformation från företagets divisioner, dotterbolag och partners till det allmänna företagsinformationsutrymmet (Fig. 1).

Dess implementering kräver först och främst utveckling och antagande av en uppsättning standarder och regler för att upprätthålla ett företags masterdata. Som en teknisk grund för att konstruera referensdatasystem används en ontologisk modell för klassificering och kodning - en formell beskrivning av redovisningsobjekt, baserad på identifieringen av deras väsentliga egenskaper (Fig. 2). Detta tillvägagångssätt säkerställer ackumulering av vilken mängd konsekvent information som helst och kombinerar fördelarna med hierarkiska, facett-, adaptiva och referensklassificeringssystem. I allmänhet gör denna teknik det möjligt att standardisera expertspecialisternas handlingar när de utför operationer för att klassificera och koda grupper (klasser) av redovisningsobjekt, bestämma egenskaperna (funktionerna) för klasser och deras värden och bygga navigeringshierarkier. Den innehåller också en beskrivning av typiska användarförfrågningar, indelade i grupper efter graden av osäkerhet och oprecisitet i formuleringar, och rekommendationer för supporttjänstspecialister (experter).

Ris. 4. Huvudstadier i arbetet med att skapa ett enhetligt system för att upprätthålla referensdata

Själva systemet för att upprätthålla referensdata är implementerat i form av ett mjukvaru- och hårdvarukomplex (fig. 3), som inkluderar verktyg för att underhålla kataloger och klassificerare, verktyg för att söka efter bokföringsobjekt, moduler för informationsutbyte mellan experter och användare, och mekanismer för integration med externa applikationer. Dess huvudsakliga funktionella mjukvaruundersystem integrerade med varandra är "användararbetsstation", "expertarbetsstation" och "administratörsarbetsstation". Systemet i sin standardkonfiguration är baserat på Microsofts teknologier (OS - Windows, webbserver - IIS, DBMS - SQL Server), men det ger även möjlighet att använda andra mjukvaruplattformar.

Intertech-företaget har också utvecklat en steg-för-steg-metod för att implementera ett företags masterdatasystem (Fig. 4). Det bakomliggande tillvägagångssättet bygger på ett antal grundläggande principer.

Den evolutionära karaktären av utvecklingen av systemet innebär en steg-för-steg-övergång till moderna metoder för att underhålla och underhålla företagsreferensdata. Det allmänna schemat för detta tillvägagångssätt är som följer: gammalt -> gammalt + nytt -> nytt; i mellanstadier tillåts den parallella existensen av de gamla och nya systemen.

Masterdatasystemets anpassningsförmåga till särdrag och landskap hos befintliga applikationssystem (inklusive ERP-klasssystem) och till olika klassificerings- och kodningssystem förutsätter dess förmåga att integrera med externa system.

Kontinuitet gör att vi kan bevara alla de bästa och värdefulla sakerna som har utvecklats under år och decennier. Detta gäller användningen av potentialen hos referensdataspecialister, stabil funktion hos befintliga applikationssystem, möjligheterna till migrering och transformation av ackumulerade informationsmatriser.

Standardisering och enhetlighet av regelverk och metoder för att använda och underhålla företags stamdata, klassificering och kodningssystem gör det möjligt att säkerställa den konstanta relevansen och tillgängligheten av masterdata i hela företaget.

Att ta hänsyn till den mänskliga faktorn innebär förmågan att arbeta i systemet för olika kategorier av användare, med olika färdigheter och grader av "framsteg" inom området informationsteknologi, ergonomisk design och "vänlighet" av systemgränssnitt.

Ris. 5. Funktionell modell för processen att använda och underhålla en enhetlig referensdatabas

För att ett enhetligt system för att upprätthålla masterdata ska fungera effektivt måste en uppsättning organisations- och ledningslösningar utvecklas som ger en tydlig ansvarsfördelning och funktionellt ansvar i enlighet med kompetensen hos företagets personalgrupper (Fig. 5):

Användare är företagsanställda som använder vissa data från stamdatadatabasen när de genererar arbetsdokument;

Experter - specialister från referensdatagruppen, ansvariga för att generera och ändra data i referensdatadatabasen;

Profilspecialister som är väl insatta i vissa aspekter av en eller annan reglerings- och referensinformation som ligger inom deras kompetens inom deras huvudsakliga yrkesverksamhet. De deltar i förfarandet för att komma överens om tillagda eller ändrade data på rekommendation av en specialistexpert från referensdatagruppen;

Specialister på teknisk support är automations- och IT-servicepersonal som tillhandahåller underhåll av systemprogramvara och hårdvara.

I allmänhet tillåter implementeringen av ett enhetligt system för att underhålla masterdata kunden att lösa följande huvuduppgifter som hjälper till att förbättra effektiviteten i hela företaget:

Skapa ett centraliserat masterdatalager, som arbetar inom företagets enhetliga informationsutrymme och inkluderar hela utbudet av materiella och tekniska resurser och andra redovisningsobjekt;

Centralisera funktionerna för att upprätthålla referensdata baserat på utvecklade företagsklassificerings- och kodningsstandarder;

Skapa enhetliga regler och teknisk miljö för användaråtkomst till referensdata, underhåll av klassificerare och referensböcker av experter och teknisk support av systemet av administratörer;

Använd programvara inbyggd i systemet som upprätthåller den erforderliga nivån av datasäkerhet och dess ständiga uppdatering, exklusive lagring av duplicerad, felaktig eller föråldrad information;

Implementera implementeringen av klassificerare och kataloger med referensdata i befintliga förvaltnings-, redovisnings- och andra system, vilket gör det möjligt att effektivisera och minska kostnaderna för att upprätthålla tillsyns- och referensinformation;

Ge företagsledningen omedelbart den information som behövs för att fatta effektiva beslut.

Sabir Asadullaev och Alexander Karpov
Publicerad 09.11.2010

Grundläggande begrepp och terminologi

Masterdata (MD) innefattar information om kunder, anställda, produkter, varor, leverantörer, som i regel inte är transaktionell till sin natur.

Regulatory reference information (RNI) inkluderar ordböcker, referensböcker, klassificerare, kodifierare, standarder och identifierare. Detta är den grundläggande nivån för transaktionssystem, som i vissa fall underhålls av externa auktoriserade organisationer.

Ris. 1 illustrerar i en förenklad form skillnaden mellan masterdata, masterdata och transaktionsdata. I ett konventionellt försäljningssystem för flygbiljetter spelas rollen som referensdata av flygplatskodifieraren, skapad av systemutvecklarna med hänsyn till vissa specifika krav. Men för att interagera med andra internationella informationssystem måste flygplatskoden vara begriplig för alla. Detta syfte betjänas av en unik flygplatskod på tre bokstäver som tilldelas flygplatser av International Air Transport Association (IATA).

Passagerardata är inte lika stabil som flygplatskoder. Samtidigt kan passagerardata, när de väl har lagts in i systemet, senare användas för olika marknadsföringskampanjer, till exempel för rabatter vid uppnående av en viss total flygsträcka. Sådan information avser vanligtvis masterdata. Dessa inkluderar också data om besättningar, företagets flygplansflotta, last- och passagerarterminaler och många andra enheter som är involverade i flygtransportprocessen, men som inte beaktas i vårt förenklade exempel.

Den sista översta raden i fig. 1 visar schematiskt en tänkt transaktion associerad med försäljningen av en biljett. Det finns relativt få flygplatser i världen, det finns många fler kunder, men de kan använda det här företagets tjänster många gånger, och biljetten kan och bör inte återanvändas. För ett flygbolag är biljettförsäljningsdata de transaktionsdata som oftast ändras.

För att sammanfatta kan vi säga att masterdata utgör grundnivån för automatiserade informationssystem, och masterdata lagrar information om kunder och anställda, produktleverantörer, utrustning, material och andra affärsenheter.

Samtidigt har referensdata och MD en hel del gemensamt, därför kommer vi i de fall där de faktorer som övervägs avser både referensdata och MD att hänvisa till dem som "RSI och MD", till exempel "system för upprätthålla referensdata och MD”.

Allmänna nackdelar med traditionell hantering av NSI och MD

Det vanligaste och uppenbara problemet med traditionell hantering av NSI och MD är bristen på stöd för tillfälliga förändringar. Adressen är som regel en av de viktigaste komponenterna i referensdata och MD. Tyvärr ändras adresser. Kunden kan flytta, men han kan "flytta" hela huset och även gatan. År 2009 ändrades således adressen till Tower on the Embankment-komplexet av byggnader från "Krasnopresnenskaya vallen, byggnad 18" till "Presnenskaya vallen, byggnad 10". Således, frågan "Hur mycket korrespondens levererades till kontoret för företaget som hyr lokaler i Embankment Tower 2009?" ska korrekt hantera leveransposter med två olika adresser.

Men för att förändringar i livet ska återspeglas i IT-systemet räcker det inte med tekniska (hårdvara och mjukvara) verktyg för att underhålla referensdata och MD. Någon eller något behövs för att spåra förändringar. Det vill säga att det krävs organisatoriska åtgärder, till exempel personal med arbetsansvar motsvarande den vedertagna metodiken för att upprätthålla masterdata.

Således inkluderar företagshantering av referensdata och VD tre kategorier av aktiviteter:

Metodaktiviteter som definierar metoder, regler, standarder, processer och roller som stödjer hela livscykeln för att underhålla masterdata och MD
Organisatoriska åtgärder som bestämmer, i enlighet med metodkrav, organisationsstrukturen, funktionella enheter och deras uppgifter, roller och arbetsuppgifter för de anställda.
Teknologiska åtgärder som ligger på IT-nivå och säkerställer genomförandet av organisatoriska och metodiska åtgärder.

I den här artikeln kommer vi först och främst att överväga tekniska aktiviteter som inkluderar skapandet av en enhetlig masterdata- och MD-datamodell, underhåll och arkivering av historiska masterdata och MD, identifiering av masterdata och MD-objekt, eliminering av dubbletter, identifiering av motsägelser, säkerställa referensintegritet, stödlivscykel för ett referensdata och MD-objekt, utveckling av rengöringsregler, skapande av ett system för att underhålla masterdata och MD och dess integration med företagets operativa informationssystem. Låt oss överväga mer i detalj det tekniska området för att skapa masterdata och MD-infrastruktur och de tillhörande nackdelarna med traditionell masterdata och datahantering.

Tekniska nackdelar med att upprätthålla referensdata och MD

Det finns ingen enskild datamodell för masterdata och MD

Det finns ingen enhetlig datamodell för masterdata och MD, eller så är den inte formaliserad, vilket inte tillåter effektiv användning av masterdata och MD-objekt och komplicerar all automatisering av arbetet med data.

Datamodellen är den huvudsakliga och viktigaste delen av underhållet av masterdata och MD, och svarar till exempel på följande frågor:

vad ska ingå i de identifierande attributen för referensdata och MD-objekt?
Vilka av alla attributen för masterdata och MD-objekt ska lagras i datamodellen och tillskrivas masterdata och MD, och vad ska tillskrivas driftdata och lämnas i operativsystemets informationssystem?
hur man integrerar med hjälp av en modell med externa identifierare och klassificerare (OKPO, OKUD)?
Ger kombinationen av två attribut från olika IT-system en tredje unik och viktig egenskap ur affärsmässig synvinkel?

Det finns ingen enhetlig reglering för historik och arkivering

Historisk information i befintliga företags IT-system underhålls ofta enligt egna regelverk och har sina egna livscykler, som ansvarar för bearbetning, aggregering och arkivering av masterdata och MD-objekt. Även om det finns en enhetlig datamodell för masterdata och MD, är det en icke-trivial uppgift att synkronisera historiska data och arkivdata och föra dem till en enda form.

Ett exempel på problem orsakade av bristen på att upprätthålla historisk normativ information och referensinformation ges i avsnittet ""

Svårigheter att identifiera referensdata och MD-objekt

I olika IT-system har masterdata och MD-objekt sina egna identifierare - uppsättningar av attribut. Situationen är komplicerad när det för samma objekt i olika system inte är möjligt att identifiera en gemensam uppsättning attribut, vars kombination är unik och identifierar objektet i informationssystemet - en analog till ett sammansatt nyckelfält i databaser. I detta fall flyttar uppgiften att identifiera och jämföra objekt i olika IT-system från det deterministiska området till det probabilistiska området. I detta fall är det svårt att kvalitativt identifiera referensdata och MD-objekt utan specialiserade verktyg för dataanalys och bearbetning.

Förekomsten av duplicerade objekt av referensdata och MD

Komplexiteten i objektidentifiering leder till potentiell förekomst av dubbletter (eller möjliga dubbletter) av samma masterdata och MD-objekt i olika system, vilket är det största och mest betydande problemet för företag. Duplicering av information leder till dubblering av kostnader för bearbetning av objekt, dubblering av "entry points" och ökade kostnader för att underhålla objekts livscykler. Dessutom bör det noteras kostnaderna för manuell verifiering (avstämning) av dubbletter, som initialt är för höga, eftersom de ofta går utöver IT-systemens kapacitet och kräver operatörsmedverkan. Det bör noteras att förekomsten av dubbletter är ett systemfel som visas i de tidigaste stegen av affärsprocesser med hjälp av masterdata och MD-objekt. När affärsprocessen fortskrider får duplikatet kopplingar och attributsammansättning, och situationen blir ännu mer komplicerad.

Inkonsekvens mellan masterdata och MD-metadata

Varje informationssystem som stöder ett företags affärsområde och där masterdata och MD-objekt som är specifika för denna verksamhet genereras, definierar sin egen uppsättning affärsregler och restriktioner som åläggs både attributsammansättningen (metadata) och värdet av attribut. Som ett resultat av detta uppstår ofta en situation när dessa regler och begränsningar som specificeras i olika informationssystem kommer i konflikt med varandra, och därmed omintetgör även teoretiska försök att få alla masterdataobjekt till samma typ. Situationen förvärras när, med en utåt sett identisk datamodell, uppgifterna har samma semantiska innebörd, men en annan betydelse när det gäller presentation: olika stavningar, permutationer i adresser, förkortningar av fullständigt namn, olika kodningar, förkortningar.

Referensintegritet och synkronisering av referensdata och MD-modeller

I verkligheten innehåller alla referensdata och MD-objekt som finns i utrymmet för deras IT-system inte bara värden utan även länkar till andra referensdata och MD, som kan lokaliseras (och underhållas) i separata externa system. Här uppstår problemet med att synkronisera och bibehålla integriteten för hela organisationens masterdata och MD-modell med full kraft. Ett av de allmänt accepterade sätten att lösa den här typen av problem är övergången till användning av referensdata och MD, som underhålls och importeras till organisationen utifrån (till exempel kataloger KLADR, OKVED, TN VED, FSKP och ECPS ).

Missmatch mellan livscykeln för ett referensdata och MD-objekt

Som ett resultat av förekomsten av samma masterdata och MD-objekt i olika företagssystem, koordineras inte inmatningen och ändringen av detta objekt i dessa system, utan förlängs ofta över tiden. En situation är möjlig när ett objekt är i olika system i ömsesidigt uteslutande status (aktivt i ett system, arkiverat i ett annat, raderat i ett tredje), vilket gör det svårt att upprätthålla integriteten hos masterdataobjekt. Objekt som inte är relaterade och utspridda över tid är svåra att använda i både transaktions- och analytiska processer.

Utveckla städregler

Reglerna för rengöring av referensdata och MD hänförs ofta med rätta till metodologiska aspekter. Naturligtvis måste IT-specialister ställa in uppgifter från företagsanvändare, till exempel i vilka fall är det nödvändigt att uppdatera flygplatskoder, eller vilket av två betalkort som har korrekt kodning av detaljer. Men affärsspecialister är inte bekanta med krångligheterna med att implementera operativa IT-system. Dessutom är dokumentationen för dessa system antingen ofullständig eller saknas. Därför är en analys av informationssystem nödvändig för att förtydliga städreglerna och identifiera nya regler.

Felaktigt val av mastersystem för underhåll av referensdata och MD

Oftast är de viktigaste källorna och konsumenterna av masterdata och MD stora äldre företagsinformationssystem, som är kärnan i företagets verksamhet. I verkligheten väljs ett sådant system ofta som ett "mastersystem" för att underhålla masterdata och MD istället för att skapa ett specialiserat arkiv av masterdata och MD. Samtidigt tar man inte hänsyn till att sådan funktionalitet som regel är ovanlig för detta IT-system. Som ett resultat leder alla ändringar av sådana system relaterade till referensdata och MD i stora och orimliga utgifter. Situationen förvärras när, allt eftersom undersystemet för masterdata och datahantering utvecklas, det är nödvändigt att införa kvalitativt ny funktionalitet: batchdatabearbetning, formatering och rengöring, och utse dataansvariga.

Oförberedelse av IT-system för integration av referensdata och MD

För att fullt ut implementera hanteringen av masterdata och MD i ett företags befintliga IT-system är det nödvändigt att integrera dessa system och oftast är denna integration nödvändig inte som en engångs- och lokaliserad handling, utan som en förändring i processerna som lever inom IT-systemen. Förutom integration för onlinearbete är det nödvändigt att utföra integration för att utföra den initiala batchdataladdningen (ETL), samt att utföra manuella avstämningsprocedurer (avstämning).

Alla automatiserade informationssystem är inte redo för sådana förändringar, inte alla system tillhandahåller sådana gränssnitt, och oftast är detta helt ny funktionalitet för sådana system. Vid implementering av ett system uppstår arkitektoniska problem relaterade till valet av olika alternativ för att implementera ett masterdata- och MD-system och integrera det med företagets tekniska landskap. För att bekräfta vikten av denna punkt noterar vi att det finns utvecklade och testade arkitektoniska mönster och tillvägagångssätt som syftar till korrekt distribution och integration av masterdata- och MD-systemet.

Exempel på problem inom traditionell hantering av forskningsdata och MD

De största problemen med att hantera masterdata härrör således från decentralisering och fragmentering av masterdata i ett företag och manifesteras i praktiken i specifika exempel.

Passdata som en unik identifierare

Till exempel, i en stor bank, som ett resultat av att skapa en kunddatamodell, beslutades det att använda passdata som en del av att identifiera attribut under antagandet om maximal selektivitet. När man genomförde procedurer för att sammanfoga kunddata avslöjades att kundens pass inte är unikt, eftersom till exempel kunder som hade relationer med banken med hjälp av gamla pass och sedan med nya pass skapades som olika kunder. En analys av kundregister avslöjade fall där tusentals kunder var registrerade på ett pass. Till råga på allt var en av datakällorna bankinformationssystemet, där pass var ett valfritt krav och motsvarande fält fylldes i med "skräp" när de fylldes i.

Det bör noteras att de upptäckta problemen med kvaliteten på klientdata inte förväntades och upptäcktes först vid datarensningsstadiet, vilket krävde extra tid och pengar för att förfina datarensningsreglerna och klientdatamodellen.

Adress som en unik identifierare

I ett annat fall slog ett försäkringsbolag samman kundpersonuppgifter, där bland annat adressen användes som ett identifierande attribut. Det visade sig att de flesta av klienterna var registrerade på adresserna "samma", "på samma plats". Data av låg kvalitet kom från ett applikationssystem som stöder försäkringsagenternas verksamhet, vilket gjorde det möjligt för agenter att fritt tolka värdena för fälten i kundenkäten. Dessutom saknade detta system något format eller logiska kontroller av de inmatade uppgifterna.

Behovet av massiv förnyelse av kontrakt

I det tredje fallet, vid anslutning av ett befintligt företagsinformationssystem som stödjer relationer med klienter till systemet för underhåll av masterdata och MD, blev det klart vid teststadiet att det anslutna systemet inte automatiskt kunde acceptera ändringar från systemet för underhåll av master data och MD. För att göra detta är det nödvändigt att utföra vissa regleringsåtgärder, i det här fallet ringa kunden och återutfärda papperskontraktsdokument som nämnde kritisk information relaterad till masterdata och MD. På grund av den stora arbetsvolymen reviderades både tekniska och organisatoriska aspekter av arbetet med referensdata och MD.

Diskrepans mellan överenskomna uppgifter

Det fjärde exemplet beskriver en typisk situation för många organisationer. Som ett resultat av den snabba utvecklingen av företagets verksamhet beslutades det att öppna en ny riktning som stöder att arbeta med kunder i B2C / B2B-stil via Internet. För detta ändamål köptes ett nytt IT-system för att stödja automatiseringen av företagets nya affärsområde. Under driftsättningen blev det nödvändigt att integrera med befintliga masterdata och masterdata för företaget och utöka dem med specifika attribut, vilket visade sig inte vara så lätt, främst på grund av bristen på ett dedikerat masterdata och MD-system. Som ett resultat av detta laddades referensdata en gång in i det nya systemet utan någon återkoppling från företagets befintliga IT-landskap, vilket efter en tid ledde till två oberoende versioner av klientkataloger. Till en början löstes problemet genom att manuellt bearbeta klientdata i kalkylblad, men efter en tid ökade antalet klienter avsevärt, katalogerna var slutsålda och manuell bearbetning visade sig vara ineffektiv och dyr. Som ett resultat ledde situationen till en allvarlig eskalering av problemet på nivån för företagsanvändare som inte har en övergripande bild av sina kunder för att genomföra marknadsföringskampanjer.

Fördelar med företagshantering av referensdata och VD

Företagshantering av masterdata och MD ger följande fördelar:

Att följa lagkrav och minska risker
Kostnadsminskning
Ökad flexibilitet för att stödja nya affärsstrategier.

Det låter för bra för att vara sant, så låt oss titta på var och en av fördelarna med praktiska exempel.

Att följa lagkrav och minska risker

Utredningsmyndigheter krävde att det stora företaget skulle lämna uppgifter för de föregående 10 åren. Uppgiften verkade enkel och genomförbar: företaget hade långt tidigare infört rutiner för regelbunden arkivering och säkerhetskopiering av data och applikationsprogram, datamedia lagrades i ett säkert rum och utrustningen för att läsa media hade ännu inte blivit föråldrad. Men efter att ha återställt historiska data från arkivet upptäcktes det att uppgifterna inte hade någon praktisk betydelse - stamdata hade ändrats flera gånger under denna tid, och nu var det omöjligt att fastställa vad den eller den informationen avsåg. Ingen sörjde för arkivering av masterdata - det verkade som om detta var tidsbeständig information. Betydande straff ålades företaget och allvarliga organisatoriska slutsatser drogs mot företagets chefer. Dessutom skapades en enhet som ansvarar för att upprätthålla referensdata för att undvika en upprepning av den obehagliga situationen.

Vinsttillväxt och kundbehållning

En stor florist var en av de första som insåg effektiviteten av e-postmarknadsföring. En butikswebbplats skapades på vilken reklamkampanjer genomfördes, där kunderna kunde prenumerera på nyhetsbrev på Alla hjärtans dag, i samband med födseln av deras första barn, på en närståendes födelsedag, etc. Kunderna möttes därefter med förslag på färgval. Men reklamkampanjer genomfördes med inblandning av olika utvecklare som skapade olika, orelaterade applikationer. Därför kunde kunder få upp till tio e-postmeddelanden om samma fråga, vilket irriterade kunderna och fick dem att churna. Som ett resultat visade sig varje efterföljande reklamkampanj inte bara vara olönsam, utan minskade också antalet befintliga kunder. Blomsteraffären var tvungen att spendera en betydande summa pengar på att designa om och integrera sina applikationer. De höga kostnaderna var förknippade med heterogeniteten i kundinformation, flera adress- och telefonformat, vilket orsakade stora problem med att identifiera kunder för att eliminera flera poster.

Kostnadsminskning

Ett av huvudkraven för företagets produkter är behovet av att snabbt svara på förändringar i efterfrågan, ta ut nya produkter på marknaden på kort tid och kommunicera med konsumenterna. Vi ser att gårdagens obestridda ledare håller på att förvandlas till eftersläpande, och nykomlingar som tog ut sin produkt till marknaden för första gången ökar kraftigt sin vinst och kapitalisering. Under dessa förhållanden måste olika företagsinformationssystem som ansvarar för produktutveckling, dess leverans och försäljning, service och utveckling baseras på en enda informationsbas som täcker alla aspekter av företagets verksamhet. Sedan kräver introduktionen av en ny produkt på marknaden mindre tid och ekonomiska kostnader på grund av den sömlösa interaktionen mellan stödjande informationssystem.

Ökad flexibilitet för att stödja nya affärsstrategier

Eliminering av fragmentering och decentralisering av referensdata och MD-hantering gör det möjligt att tillhandahålla information som en tjänst. Detta innebär att vilket IT-system som helst, som följer etablerade utbytesprotokoll och åtkomsträttigheter, kan komma åt företagets system för underhåll av masterdata och MD och ta emot nödvändig data. Ett tjänsteorienterat tillvägagångssätt ger dig möjlighet att flexibelt bygga informationstjänster i enlighet med förändrade affärsprocesser, vilket säkerställer snabb respons från IT-tjänster och system inför förändrade krav.

Arkitektoniska principer för systemet för att upprätthålla referensdata och MD

Resurser för nedladdning

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

Zon=Informationshantering

Artikel-ID=577045

ArticleTitle=Underhålla referensdata med hjälp av praktiska exempel

I samband med övergången till en digital ekonomi har företag äntligen blivit övertygade om att data är en tillgång som är viktig att korrekt lagra, bearbeta, analysera, använda för att fatta beslut och göra prognoser. Effektiviteten hos dessa processer säkerställs av ett enda arkiv i vilket verifierad kvalitetsdata måste laddas. Uppgiften att konsolidera dem från olika källor innebär att sammanställa och synkronisera kataloger i olika IT-system. Det är just därför som företag behöver ledningssystem för regulatorisk referensinformation (RNI).

Enligt TAdviser är volymen av marknaden för masterdatahanteringssystem cirka 1,5 miljarder rubel i slutet av 2017. Efterfrågan på dessa lösningar växer med 20-25 % per år – i direkt proportion till tillväxten av företagsdigitalisering. Accelerationen av dynamiken underlättas av den växande penetrationen av molntjänster på den inhemska marknaden (med cirka 20 % per år), samt lanseringen av initiativ för att informera staten och samhället som en del av programmet.

Den allmänna vägen till digitalisering dikterar behovet av en samlad kunskapsbas om kunder, produkter etc. För att digitala initiativ ska bli framgångsrika är det nödvändigt att effektivt hantera data som först måste sammanföras för att bilda en tillförlitlig och korrekt tillhandahållande av en "enda version av sanningen" för alla affärsenheter. Följaktligen finns det en växande efterfrågan på datainsamlings- och konsolideringsverktyg som möjliggör snabb åtkomst till information oavsett dess källa, analys av mönster och anomalier och säker distribution av data.

I fokus

Företagsrepresentanter ställer mer och mer krav på kvaliteten på referensdata och dess hanteringsprocesser. Frågor om kvaliteten på referensdata uppstår också lokalt, bland specialister. Ju mer dramatiskt mängden data som ackumuleras av organisationer ökar, desto högre krav på prestanda hos informationssystem. Volymerna av referensböcker växer ständigt. Moderna lösningar inom området referensdatahantering förväntas kunna stödja arbete med mer än 1 miljard poster.

Om för 10 år sedan, i slutet av 2000-talet, uppgifterna med referensdata oftare uppfattades som processen att migrera kataloger som en del av implementeringen av redovisningsinformationssystem, så närmar sig företagen 2018 uppgifterna att hantera referensdata mer medvetet och strukturellt, med inblandning av funktionella avdelningar som direkt använder denna information i affärsprocesser. Uppgifter relaterade inte bara till utrustning och material, utan även till entreprenörer och andra referensdata förtydligas.

Den nuvarande situationen kräver en högre nivå av automatisering och formalisering: allt som kan "hårdkopplas" till en tydlig automatiserad algoritm måste formaliseras, eftersom Utan strikta regler förvandlas arbetet med referensdata till kaos. Även involveringen av olika affärsavdelningar i NSI-projekt ökar deras varaktighet. Som en lösning kommer moderna sätt att automatisera datakvalitet med hjälp av mekanismer i förgrunden”, kommenterar Bair Danilov, chef för referensdataavdelningen på IBS.

Från och med 2018 kommer upp till 75 % av denna marknad från konsultverksamhet och cirka 25 % upptas av licenser. Denna situation beror på det faktum att företag, förutom att skapa direkt katalogen, behöver dess integration med andra informationssystem och för kundkataloger - med system för skydd av personuppgifter, konstaterar Krok.

Nya trender

Bland de "heta" globala tekniska trenderna som förändrar referensdatamarknaden, noterar IBS-experter utvidgningen av omfattningen av kataloghantering, dvs. hantering inte bara av grundläggande data - entreprenörer och material, utan också av en enhetlig kontoplan, produktionstillgångar och andra nödvändiga referensböcker för företagets viktiga affärsprocesser. I fokus är också automatiseringen av processen att kontrollera referensdata, inklusive användning av maskininlärningsteknik, utveckling av enhetliga standarder för att upprätthålla motparter och material, samt skapandet av digitala ekosystem där tillverkare och köpare fritt kan utbyta transparent information om varor och transaktioner.

Förbättring är fortfarande den avgörande trenden. Maskininlärningsteknik möjliggör deduplicering av högre kvalitet på ett automatiserat sätt. Generellt förändrar utvecklingen märkbart tidigare etablerade tillvägagångssätt för att arbeta med referensdata - effektiviteten av dataigenkänning och korrigering ökar, möjligheten att använda multimediainformation läggs till, gör data mer visuell, etc.

Idag visar inte bara ekonomiska jättar, utan även medelstora företag intresse för kvaliteten på referensdata. IBS noterar en ökning av antalet förfrågningar om vetenskapliga forskningsprojekt från läkemedel, livsmedelsindustri, maskinteknik och lantbruk. Detta intresse sporras också av importsubstitutionsinitiativ - det är införandet av NSI som gör att vi kan lösa problemet med gradvis och rationell importsubstitution av utländska lösningar.

Topp 8 aktörer på den ryska marknaden för referensdatahanteringssystem

	Krok	IBS	SDI-lösning	"NCIT "Intertech"	TaskData	Lanit	EAE-konsult	Navicon
Intäkter från NSI-projekt 2016	RUB 135 miljoner	RUB 99,9 miljoner	RUB 63,3 miljoner	RUB 51,9 miljoner	44 miljoner rub.	28 miljoner rub.	11,2 miljoner rubel.	7,5 miljoner rubel.
Intäktsdynamik för NSI-projekt 2016/2015	13%	6%	32%	50%	90%	10%	-10%	Höjd
Antal NSI-projekt 2017		4	7	7	6 färdiga, 2 pågår	6	5	4
Antal NSI-projekt 2016		4 pågår, 1 färdig	4	7	4	5	3	4
Lösningar/plattformar som används	Croc NSI Suite, Talend Platform för MDM, MDM, Informatica MDM, ett antal Oracle-system, samt den inhemska Unidata-plattformen	SAP, Ataccama, egen utveckling (20%), 1C MDM	egen utveckling av Semantic MDM. DBMS Microsoft SQL Server, Oracle, PostgreSQL	* egen utveckling - mjukvaruplattform för hantering av referensdatasystem Ontologic (registrerad i Register of Russian Software No. 4114 daterad 11 december 2017); 2. Gruv- och metallurgiskt företag - skapande av ett automatiserat system för hantering av reglerings- och referensinformation, utveckling av en klassificerare för material och teknisk utrustning, normalisering av katalogen för material och tekniska resurser och katalogen över entreprenörer. Mer än 2000 användare. Baserat på SAP MDM, SAP PI, SAP Portal, SAP BPM. 3. Federal verkställande myndighet - Konsolidering och rengöring av mottagen information, integration av lösningen i företagets IS. Baserat på Informatica MDM, Informatica Power Center, Informatica Data Quality, Oracle BPM.	1. United Engine Construction Corporation - "Skapande och implementering av ett företagssystem för att hantera normativ information och referensinformation på plattformen för Semantic Reference Information Management System" 2. Utveckling av ett automatiserat system för att hantera tillsyns- och referensinformation från JSC Kalashnikov Concern på plattformen för hanteringssystemet Semantic referensdata. 3. "Utveckling av ett automatiserat system "Hantering av företags elektroniska kataloger" för PJSC RSC Energias behov.	1. Design, implementering och driftsättning av företagets ledningssystem för vetenskapliga data från Inter RAO Group; 2. Skapande av ett enhetligt system för reglerande och referensinformation för det statliga oljebolaget i Azerbajdzjan (SOCAR); 3. Skapande av ett enhetligt system för hantering av regulatorisk och referensinformation i företagets CJSC "ABI Product"; 4. Implementering av masterdatahanteringssystemet (utökade referensböcker) för PJSC MMC Norilsk Nickel; 5. Normalisering av Unified Directory of Materials and Equipment och kartläggning i registren i Unified Nomenclature Directory som en del av projektet för att introducera ett enhetligt koncept för hantering av företags stamdata för PJSC Polyus; 6. Skapande av en metodisk och reglerande ram för reglerande och referensinformation om katalogen över material och tekniska resurser och normalisering av katalogen över material och utrustning för Irkutsk Oil Company LLC; 7. Skapande av ett enhetligt system för hantering av reglerings- och referensinformation för basdata från Power Machines-företagsgruppen.	1. Industricentrum för utveckling och implementering av informationssystem (OCRS). Funktionaliteten i det första steget av ASOUP-3, som inkluderar ett automatiserat komplex för underhåll av referensdata, har utvecklats. 2. Federal Forestry Agency (Rosleskhoz). Skapande av ett delsystem för reglering och referensinformationshantering (RNSI). 3. United Instrument-Building Corporation (UPK). Ett projekt för att bygga en modell av ett referensdatahanteringssystem som en del av implementeringen av projektet "Network Integrated Settlement and Information Management System" (SIRIUS) - ett centraliserat inköpshanteringssystem för försvarsindustrin.	1. Utveckling av ett automatiserat system för att upprätthålla referensdata i en av de största bankerna i Ryssland (på Microsoft-plattformen med hjälp av NORMAs referensdatahanteringssystem, Oracle-databasen). 2. Utveckling av ett masterdatahanteringssystem för Gazprombank (på Microsoft-plattformen med hjälp av NORMA-masterdatahanteringssystemet, Microsoft SQL Server DBMS).	KSSS tur 8 - översättning av kataloger till IBM MDM-plattformen, gränssnitt till SAP PI-bussen, kvalitetskontroll av referensdata; Integration av KSSS med 1C DO - integration av Motpartskatalogen med 1C-system i DO; KSSS-NSI RREM - översättning och skapande av RREM-kataloger på IBM MDM-plattformen, gränssnitt till SAP PI-bussen. Oracle DBMS används för det nedre lagringslagret och för masterdatamart.	1. Food Union (konsolidering av rapportering från flera filialer och produktionsanläggningar, möjlighet att fatta ledningsbeslut baserat på en ständigt uppdaterad datauppsättning, implementering i Microsoft Azure molnmiljö). 2. Gazprom Gazenergoset (automatisering av laddning av aggregerade data från redovisningssystemen för dotterbolag och beroende företag (SDC) till företagets datalager (CDW) på centralkontoret). 3. Specialiserat förvaringsinstitut "Infinitum Specialized Depository" (optimering av affärsprocesser när det gäller att upprätthålla regulatorisk och referensinformation, optimering av arkitektur genom att skapa ett centraliserat masterdatalager, eliminering av dubbletter och dubbel datainmatning)
De största projekten efter antal kataloger 2015-2017		1. Projekt 1. Volymen av referensböcker är mer än 30. 2. Projekt 2. Volym referensböcker: cirka 20. 3. Projekt 3. Volymen av referensböcker är mer än 200.	1. Projekt av JSC "UEC". Volymen av referensböcker är mer än 20. Integration av KSSS med 1C för SIP - 31 organisationer i LUKOIL-gruppen; KSSS-NSI RREM - PJSC LUKOIL och 4 NGDO	1. Specialiserat depå "Infinitum" (cirka 40 000).

När vi arbetade med storskaliga automationsprojekt och skapade nya informationssystem, ställdes vi varje gång inför behovet av att implementera ett delsystem för att underhålla kataloger, klassificerare, register och andra liknande objekt som utgör kundens referensinformation (RNI). Under de 15 år som vi arbetat på LANIT med datahanteringssystem har livet gett oss kunder med en mängd olika krav. Och naturligtvis uppstod olika situationer i dessa projekt. Jag kommer att berätta om flera lärorika historier som hänt oss. I artikeln hittar du exempel som kommer att vara användbara för många som sysslar med mjukvaruutveckling. Jo, för de som jobbar direkt med NSI kommer det att bli ännu mer intressant - deras egen tröja ligger närmare kroppen.

Speciellt tack till den underbara konstnären Vasya Lozhkin för illustrationerna.

Fall ett. Hur man lastar en vagn och liten vagn

Skapande av ett enhetligt entreprenörsledningssystem för ett stort tillverkningsföretag med många fabriker över hela landet och utomlands.

Projektmål– skapa en enhetlig databas med motparter för alla divisioner. Motpartshanteringen sker utifrån förfrågningar som prioriteras från låg till akut. En brådskande ansökan ska behandlas av NSI-experter inom 2 timmar, oavsett tidsskillnad mellan avdelningarna.

Levande historia
Projektet avtalades med alla berörda parter (kundens ledning övertygade oss om detta) och utvecklades inom den givna tidsramen i enlighet med godkända krav.

Presentationen av det skapade motpartshanteringssystemet gick smidigt tills en framstående kvinna - chefen för den sibiriska grenen - reste sig och mycket energiskt, med ryska idiomatiska uttryck, uppmärksammade de församlade att när en järnvägsvagn kom till henne för lastning färdiga produkter skulle hon inte vänta 2 timmar tills någon i Moskva granskar ansökan om att lägga till en köpare.

Hon kommer inte att betala för stilleståndstiden för bilen medan ansökan godkänns, utan kommer att lägga in köparens data i systemet som de är och skicka varorna, och Moskvakamraterna kan sedan hantera informationen om köparen lika mycket som de vill.

Detta uttalande stöddes av flera andra chefer för företagets filialer, som nästan helt förstörde den centraliserade metoden för att upprätthålla en enda register över motparter baserad på applikationer.

Som ett resultat av detta modifierades projektet på så sätt att alla filialer fick tillgång till motpartsdatabasen och kunde göra ändringar i den direkt, men samtidigt gjordes en automatisk sökning efter liknande poster som visades för filialanställda, och han fattade ett beslut om behovet av att justera uppgifterna, som senare kontrollerades av en expertgrupp.

Vad vi minns: lita inte på ord från chefer och ansvariga personer på kundens sida om att alla beslut har kommit överens, allt är på ämnet och det finns inga invändningar. Identifiera alla projektintressenter och försök ta reda på systemkrav och begränsningar direkt från dem.

Fall två. Vi använder det som vi vill

Skapande av ett centraliserat kundhanteringssystem för ett försäkringsbolag med ett stort antal filialer och ombud över hela landet.

Projektmål– Skapande av en konsoliderad kundbas för användning i analytiska tillämpningar. Databasen samlades in från alla grenar, data verifierades, kompletterades och dubbletter av objekt eliminerades. Antalet kunder i en filial varierar från tusen till flera miljoner. Samtidigt finns det praktiskt taget ingen överlappning av kunder mellan filialer.

Levande historia

När en konsoliderad kunddatabas väl skapats måste den periodvis jämföras med filialdatabaser för att identifiera skillnader, sedan bearbeta dem och ladda upp ändringar till den konsoliderade databasen. Tillväxten av kundbasen mellan avstämningarna uppgick till flera tusen poster.

För att utföra avstämningen skapades en speciell modul, vars arkitektur designades utifrån det faktum att den snabbt måste jämföra ett stort antal poster och generera en relativt liten XML-fil med ändringar för nedladdning. XML-formatet valdes av kunden.

Efter att ha implementerat systemet fick vi ett meddelande från kunden att avstämningsmodulen fungerar extremt långsamt och genererar en enorm fil för att laddas in i den konsoliderade databasen, som de inte kan öppna på något sätt.

Vad blev det? Kunden utförde den första inläsningen av data från filialer till den konsoliderade katalogen. Experterna tyckte att detta arbete var tråkigt och tidskrävande, och de tog helt enkelt avstämningsmodulen och matade den med fullständiga data från den nya filialen, som aldrig hade laddats in i den konsoliderade katalogen.

Avstämningsmodulen, som enligt de tekniska specifikationerna skulle generera information om skillnader i antalet flera tusen poster, fick två miljoner poster som input, och alla saknades i den konsoliderade katalogen.

Som ett resultat, efter flera timmars övermänsklig ansträngning, genererade avstämningsmodulen ändå en fil för nedladdning, som inkluderade all filialdata. Och ja, den här filen var enorm.

Avstämningsmodulen användes inte av kunden för det avsedda syftet, men kunden gillade just det faktum att avstämning tillåter initial dataladdning, och han tänkte fortsätta arbeta på detta sätt, bara han bad om att avsevärt påskynda arbetet med modulen och gör något med den skapade filen så att den kunde öppnas i en textredigerare.

Som svar på våra invändningar om att avstämningsmodulen inte är avsedd för initial dataladdning, visade kunden glatt de tekniska specifikationerna och frågade, var står den skriven här? Vi använder det som vi vill!

Som ett resultat var vi tvungna att göra ändringar i avstämningsmodulens arkitektur för att bearbeta stora mängder data och generera en utdatafil i CSV-format, eftersom kunden absolut inte ville ge upp ett så bekvämt verktyg.

Vad vi minns: Inkludera alltid en beskrivning av begränsningarna i specifikationen - vad ditt system inte ska göra. Jo, eller skapa lösningar som tar hänsyn till alla möjliga användningsfall, vilket är mycket dyrare.

Fall tre. Inte en elefantunge, utan en elefant, och den måste flyga också

Skapande av ett centraliserat system för underhåll av masterdata för en finansiell organisation.

Projektmål- Skapande av ett centraliserat system för att underhålla kataloger och klassificerare med distribution av ändringar till intresserade system och databaser. Tillhandahålla åtkomst till externa system till kataloger via vårt systems webbtjänster.

Kunder har vanligtvis ett genomsnittligt antal poster per katalog från flera hundra till flera tusen. Vår senaste rekordhållare är en katalog som hade 11 miljoner poster. Men den här kunden gav oss en överraskning. Hans katalog innehöll över 100 miljoner poster. Vi laddade ner den i mer än en dag, eftersom... Under den första laddningen utfördes många datakontroller. Detta skulle inte ha varit ett stort problem, men kunden krävde att katalogen skulle laddas ner inom några minuter.

Som ett resultat var vi tvungna att kraftigt förändra hur systemet fungerar med denna uppslagsbok. Faktum är att det underhålls utanför systemet, och vi tillhandahåller bara ett gränssnitt för dess användning. Vi utvecklar för närvarande nya sätt för vårt system att arbeta med mycket stora kataloger. Vi hoppas att kunden kommer att gilla det.

Vad vi minns: I den moderna världen finns det mer och mer data, och dess tillväxttakt ökar ständigt. Systemet måste vara redo för höga belastningar även där de från början inte förväntades. Vi utvecklar ständigt vår lösning med hänsyn till aktuella trender inom datatillväxt och ökande krav på hastigheten på deras bearbetning.

Fall fyra. Svårt knep med filer

Skapande av ett centraliserat system för underhåll av masterdata i en stor bank.

Projektmål– Skapande av ett centraliserat system för att underhålla kataloger och klassificerare med distribution av ändringar i intresserade system och databaser. En speciell egenskap hos projektet är de mycket komplexa processerna för att sprida förändringar som påverkar många system.

Eftersom jag i framtiden kommer att behöva nämna vår egen lösning för att hantera referensdata kommer jag att tillåta mig en liten lyrisk utvikning.

Läs mer om NORMA-systemet.

Våra kunders uppgifter är i stort sett lika, och vi beslutade att minska kostnaderna för mjukvaruutveckling och minska projekttiden genom att skapa vår egen universella plattform för underhåll av masterdata och masterdata (Reference Data Management & Master Data Management). Systemet har funnits i mer än 10 år och under alla dessa år har vi på LANIT aktivt utvecklat det.

NORMA stöder centraliserad och distribuerad referensdatahantering. All data och metainformation behålls med hänsyn till förändringshistoriken, och systemet låter dig se och ändra hela uppsättningen av referensdata för ett godtyckligt datum i det förflutna eller framtiden. Processer för godkännande och godkännande av ändringar kan konfigureras för kataloger. Systemet inkluderar en dedikerad ändringsdistributionsserver, som låter dig interagera med externa system genom olika gränssnitt och skapa ganska komplexa integrationsprocesser (en sorts mini BizTalk Server). Vi har dataexport/importpaket som kan ladda upp/ladda katalogdata till databaser och filer i olika format. Underhåll av konverteringstabeller för externa system stöds.

NORMA inkluderar en grafisk frågebyggare och rapportdesigner. Förutom att arbeta med sina egna kataloger tillåter systemet, genom sitt gränssnitt, att se och ändra kataloger som finns i databaser utanför det, samt använda dessa kataloger i frågebyggaren och exportera/importera paket.

Som svar på förekomsten av olika händelser i systemet, till exempel händelser av ändringar i katalogen, kan plug-in programvarukomponenter skrivna i C# startas, som både kan kontrollera data och interagera med externa system och faktiskt NORMA-systemet i sig. Nästan alla systemfunktioner är tillgängliga via webbtjänster.

Systemet kan skalas både vertikalt genom att öka kraften hos applikationsservern och databasen, och horisontellt genom att använda en multi-nod applikationsserver, där varje nod eller grupp av noder är ansvarig för att utföra en separat funktion. För att lagra referensdata kan systemet använda Microsoft SQL Server, Oracle eller PostgreSQL.

Vanligtvis, när kunden skapar referenser och processer för att sprida förändringar, rådgör kunden med våra analytiker om vilket verktyg eller uppsättning verktyg som tillhandahålls av systemet som är bäst att använda för en viss uppgift. Den här gången sa kunden att han skulle skapa kataloger och processer självständigt.

Efter en tid kontaktade en av kundens specialister oss med ett klagomål om att hans data inte laddades in i systemet. Som bekräftelse fick vi ett dataimportpaket, en källfil med posterna som laddades och ett felmeddelande om att data som laddades var av fel typ.

Låt oss börja ta reda på det. Vi vrider paketet åt det här och det, provar olika alternativ för att representera källdata, men vi kan inte upprepa misstaget. Vi kontaktar kunden med frågor: kanske importpaketet har anslutna mjukvarukomponenter, kanske finns ytterligare restriktioner på katalogen, kanske data inte kommer från denna process? Vi får svaret på allt - det finns inget sådant, allt ska laddas lätt och fungerade tidigare.

Det visar sig att detta importpaket bara var toppen av ett isberg. Kort och mycket förenklat hände följande. Importproceduren laddade in rätt data från källfilen till katalogen. Den ursprungliga filen raderades. Vårt system spred sedan ändringarna till flera databaser, varav en jämförde sin egen data med våra ändringar och genererade en avvikelsefil som returnerades till vårt system för nedladdning. För att ladda ner den här filen använde kunden dessutom samma importprocedur som för källfilen. Och just den här filen, genererad av det externa systemet, innehöll data av fel typ. När vi analyserade originalfilen kunde vi uppenbarligen inte hitta några fel, och vi fick inte veta något om den andra filen och den utbredda processen att distribuera ändringar.

Vad vi minns: Kontrollera alltid informationen du får, även om de säger till dig att vi har ett litet problem här, och det är just på den här platsen, jag lovar min mamma! Analysera problemet i sitt sammanhang.

Fall fem. Jag börjar vänja mig vid inkonsekvenserna

Skapande av ett masterdatahanteringssystem i ett tillverkande företag.

Projektmål– skapande av ett system för att upprätthålla referensdata i ett förvaltningsbolag med många filialer, fabriker och designavdelningar.

Den här gången kom vi inte längre än några presentationer. Teknikerna gillade verkligen vårt NORMA-system. Hon täckte alla deras befintliga problem. Sedan var det turen att visa systemet för ledningen, och här inträffade årtiondets bummer. Den högt uppsatta chefen tittade, lyssnade och sa: "Vi arbetar alla här med Apple-produkter, de har en viss stil och ditt system passar inte in i den här stilen. Vi tänker inte ens överväga det."

Vad vi minns: Kunderna är olika, och för vissa är du helt enkelt inte lämplig. Stilen är annorlunda.

Liknande historier händer i olika projekt. Vad var intressant i ditt projektliv? Vad var en oväntad lektion för dig? Dela i kommentarerna.

Taggar: Lägg till taggar