Pereiti prie pagrindinio turinio
FromNine
Meniu

DI ir duomenys

Duomenys, kuriais gali remtis dirbtinis intelektas ir sprendimai.

Kuriame duomenų platformas, kuriose kiekvienas duomenų rinkinys turi savininką, sutartį ir žinomą kokybę, todėl analitika, kasdienė veikla ir DI remiasi tais pačiais patikimais skaičiais.

Organizacijoms, kurioms reikia vieno patikimo duomenų vaizdo, nors duomenys išsibarstę po šalis, juridinius asmenis ir senąsias sistemas.

Duomenys ir analitika: gebėjimų sluoksniaiKeturi vienas po kito išdėstyti sluoksniai. Iš viršaus į apačią: analitika ir DI, kurie naudoja duomenis, duomenų produktai su savininkais ir sutartimis, lakehouse sluoksniai, kuriuose duomenys valomi ir suderinami, ir valdysena, apimanti visa tai.01Analitika ir DI02Duomenų produktai ir sutartys03Lakehouse sluoksniai04Valdysena ir duomenų kilmė
  1. 01Duomenų produktai su konkrečiais savininkais, sutartimis ir kokybės patikromis
  2. 02Valdysena, kuri įgyvendina tikslo apribojimą ir saugojimo terminus, o ne vien katalogas
  3. 03Vienas KPI apibrėžimų rinkinys, kurį patvirtina ir verslas, ir IT

01 Problemos

Pažįstamos duomenų problemos

Dauguma nuviliančių DI projektų iš tikrųjų yra užmaskuoti duomenų projektai.

  1. 01

    Trys ataskaitos, trys skirtingi skaičiai

    Finansų skyrius, operacijų komanda ir valdyba pajamas ar bylų skaičių apskaičiuoja kiekvienas savaip. Posėdžiai prasideda nuo skaičių derinimo, o ne nuo sprendimų.

  2. 02

    Duomenys neturi savininko, todėl niekas jų netaiso

    Klaidos randamos vėlesniuose etapuose, pataisomos skaičiuoklėje ir kitą mėnesį vėl grįžta.

  3. 03

    DI komanda daugiausia laiko praleidžia ieškodama duomenų

    Kiekvienas panaudojimo atvejis prasideda savaitėmis prieigos prašymų, ištraukų ir valymo, kuriuos kita komanda vėl pakartos.

  4. 04

    Archyvai netinka DI

    Skenuoti dokumentai su prastu tekstų atpažinimu (OCR), dublikatai ir jokių metaduomenų. Paieška tokiuose archyvuose grąžina triukšmą.

02 Ką pateikiame

Ką pateikiame

  1. 01 Duomenų pagrindai DI ir analitikai

    Lakehouse architektūros su sluoksniniu modeliavimu, nuo neapdorotų duomenų iki suderintų ir naudojimui paruoštų, ir duomenų produktai, kurie skelbia, ką juose rasite, kokie jie švieži ir kas už juos atsako.

    Ką darome

    • Platformos architektūra ir saugojimo formatų pasirinkimas
    • Sluoksninio modeliavimo susitarimai
    • Duomenų produktų projektavimas su sutartimis
    • Paketinis duomenų įkėlimas ir pokyčių fiksavimas (CDC)

    Ką gaunate

    • Kodu aprašyta lakehouse platforma
    • Pirmieji duomenų produktai gamybinėje aplinkoje
    • Duomenų sutarties šablonas ir peržiūros procesas
  2. 02 Kokybė, kilmė ir pagrindiniai duomenys

    Automatinės kokybės patikros kiekviename sluoksnyje, duomenų kilmė nuo šaltinio iki ataskaitos ir pagrindiniai bei klasifikatorių duomenys svarbiausiems objektams: gyventojams, klientams, produktams ir turtui.

    Ką darome

    • Kokybės taisyklės su ribomis ir įspėjimais
    • Duomenų kilmės fiksavimas stulpelių lygiu
    • Pagrindinių duomenų susiejimo ir galutinės reikšmės parinkimo taisyklės
    • Klasifikatorių duomenų valdymas

    Ką gaunate

    • Kokybės skydelis kiekvienam duomenų produktui
    • Duomenų kilmė, kurią galima užklausti
    • Etaloniniai įrašai prioritetiniams objektams
  3. 03 Valdysena, kuri iš tikrųjų taikoma

    Katalogas, klasifikacija ir prieigos politikos, kurias platforma taiko automatiškai. BDAR tikslo apribojimas ir saugojimo terminai įgyvendinami techniškai, o dalijimasis duomenimis vyksta pagal Duomenų valdymo akto taisykles, kai jos taikomos.

    Ką darome

    • Klasifikavimo schema ir žymėjimas
    • Atributais grįstos prieigos politikos
    • Automatinis saugojimas ir ištrynimas pasibaigus terminui
    • Dalijimosi duomenimis sutartys ir techninės kontrolės priemonės

    Ką gaunate

    • Iš platformos užpildomas katalogas
    • Prieigos politikos kaip kodas
    • Veikiantis saugojimo terminų grafikas
  4. 04 Nestruktūrizuotas turinys, paruoštas DI

    OCR kokybės gerinimas, metaduomenų papildymas, dublikatų šalinimas ir archyvų tvarkymas, kad išmanusis dokumentų apdorojimas ir paieškos sistemos pradėtų nuo turinio, kurį verta rasti.

    Ką darome

    • Turinio inventorizacija ir kokybės atrankinis tikrinimas
    • OCR ir išdėstymo atpažinimo gerinimas
    • Beveik identiškų dokumentų aptikimas
    • Metaduomenų papildymas ir klasifikavimas

    Ką gaunate

    • Išvalyta, papildyta turinio saugykla
    • Turinio kokybės ataskaita
    • Taisyklės nuo šiol pridedamam turiniui
  5. 05 Analitika ir BI, kuria žmonės naudojasi

    Semantinis sluoksnis su KPI apibrėžimais, dėl kurių susitarė verslas ir IT, valdoma savitarnos analitika ir į SaaS produktus bei portalus įterpta analitika.

    Ką darome

    • KPI apibrėžimo dirbtuvės
    • Semantinis modelis ir rodiklių sluoksnis
    • Savitarnos apsaugos priemonės ir sertifikuoti duomenų rinkiniai
    • Įterpta analitika klientams skirtuose produktuose

    Ką gaunate

    • KPI žodynas su savininkais
    • Sertifikuotas semantinis modelis
    • Skydeliai, pakeičiantys skaičiuokles
  6. 06 Srautiniai duomenys kasdienei veiklai

    Pokyčių fiksavimas ir įvykių srautai ten, kur sprendimai negali laukti naktinio įkėlimo: atsargų likučiai, bylų būsena, sukčiavimo signalai.

    Ką darome

    • Delsos reikalavimai kiekvienam panaudojimo atvejui
    • CDC iš operacinių duomenų bazių
    • Srautų apdorojimas ir materializuoti rodiniai
    • Pakartotinio apdorojimo ir istorinių duomenų užpildymo projektas

    Ką gaunate

    • Srautiniai konvejeriai gamybinėje aplinkoje
    • Operaciniai rodiniai su šviežumo tikslais
    • Pakartotinio apdorojimo procedūra

03 Architektūra

Iliustracinė etaloninė architektūra

Duomenys iš operacinių sistemų ir dokumentų per įkėlimą patenka į sluoksniuotą lakehouse: pirmiausia neapdoroti, kokie gauti, tada suderinti ir patikrinti, galiausiai duomenų produktai su savininku ir sutartimi. Vartotojai niekada neskaito neapdorotų duomenų.

Iš duomenų produktų viena trasa veda į semantinį sluoksnį ir BI, kitos į DI paiešką ir požymius bei duomenų API kitoms sistemoms. Valdysena yra po visu tuo ir ją taiko platforma, o ne politikos dokumentas.

Iliustracinis pavyzdys
  1. Šaltiniai ir įkėlimas

    • Operacinės sistemos
    • Dokumentai po OCR ir papildymo
    • Paketinis įkėlimas ir CDC
  2. Lakehouse

    • Neapdorotų duomenų sluoksnis
    • Suderintų duomenų sluoksnis
    • Kokybės patikros ir kilmė
    • Pagrindiniai ir klasifikatorių duomenys
    • Duomenų produktai su sutartimis
  3. Naudojimas

    • Semantinis sluoksnis ir BI
    • DI paieška ir požymiai
    • Duomenų API ir dalijimasis
  4. Valdysena

    • Valdysena: katalogas, klasifikacija, prieigos politikos, saugojimo terminai
Lakehouse sluoksniai ir duomenų produktai su savininkais

Iliustracinė architektūra, ne kliento sistema.

Skaityti diagramą kaip tekstą

Pagrindinė trasa veda nuo operacinių sistemų per paketinį įkėlimą ir pokyčių fiksavimą, neapdorotų duomenų sluoksnį, suderintų duomenų sluoksnį ir duomenų produktus iki semantinio sluoksnio su valdoma BI.

Nestruktūrizuoti dokumentai po OCR ir papildymo taip pat patenka per įkėlimą. Kokybės patikros ir duomenų kilmė apima neapdorotų ir suderintų duomenų sluoksnius. Pagrindiniai ir klasifikatorių duomenys papildo duomenų produktus. Duomenų produktai taip pat aptarnauja DI paiešką ir požymius bei dalijimuisi skirtas duomenų API.

Visą platformą apima valdysenos juosta su katalogu, klasifikacija, prieigos politikomis ir saugojimo terminais.

04 Aspektai ir ribos

Inžineriniai aspektai ir ribos

  • Pirmiausia savininkai, tada įrankiai

    Kaip tai sprendžiame

    Kiekvienas duomenų produktas turi verslo savininką, kuris sprendžia, ką jis reiškia, ir techninį savininką, kuris užtikrina, kad jis veiktų. Padedame apibrėžti abu vaidmenis ir sutartį tarp duomenų teikėjų ir vartotojų.

    Ribos ir priklausomybės

    Platforma negali sukurti atsakomybės. Jei organizacija nepaskiria savininkų, kokybės problemos sugrįš, kad ir kokie būtų įrankiai.

  • Tikslo apribojimas praktikoje

    Kaip tai sprendžiame

    Asmens duomenys pažymimi tikslais, kuriems jie gali būti naudojami, o prieigos politikos ir saugojimo terminai automatiškai vadovaujasi šiomis žymomis.

    Ribos ir priklausomybės

    Kurie tikslai yra teisėti, sprendžia Jūsų duomenų apsaugos pareigūnas ir teisininkai. Mes tai įgyvendiname, bet nesprendžiame.

  • Duomenims DI taikoma atskira kokybės kartelė

    Kaip tai sprendžiame

    DI panaudojimo atvejams matuojame tai, ko reikia paieškai ir modeliams: aprėptį, šviežumą, dublikatus ir teksto išgavimo kokybę.

    Ribos ir priklausomybės

    Kai kurių archyvų taisyti neverta. Atrankinis vertinimas tai parodys, o kartais teisingas sprendimas yra jų neįtraukti.

05 Kaip dirbame

Kaip dirbame

Platformą kuriame aplink pirmuosius svarbius duomenų produktus, o ne atvirkščiai.

  1. 01

    Renkamės sprendimus, ne duomenų rinkinius

    Pradedame nuo dviejų ar trijų sprendimų ar DI panaudojimo atvejų ir jiems reikalingų duomenų, paskyrę savininkus.

    RezultatasDuomenų produktų sąrašas su savininkais

  2. 02

    Aplink juos kuriame pagrindus

    Platforma, įkėlimas, kokybės patikros ir valdysena, tiek, kiek reikia šiems produktams tinkamai aptarnauti.

    RezultatasPirmieji duomenų produktai gamybinėje aplinkoje

  3. 03

    Plečiamės produktas po produkto

    Kiekvienas naujas produktas naudoja tą patį pagrindą, o katalogas ir KPI žodynas auga kartu su juo.

    RezultatasProduktų planas ir naudojimo rodikliai

06 Žmogaus kontrolė

Kur sprendžia žmonės

Duomenų platformos automatizuoja duomenų perkėlimą ir patikras. Žmonės sprendžia dėl reikšmės, prieigos ir tikslo.

  • Apibrėžimus tvirtina savininkai

    KPI ar duomenų produkto reikšmė keičiasi tik tada, kai tai patvirtina jo verslo savininkas, o pakeitimas versijuojamas.

  • Prieigą suteikia politikų savininkai

    Duomenų savininkai sprendžia, kas kokius duomenis ir kokiu tikslu gali naudoti, o platforma tai užtikrina ir registruoja kiekvieną suteiktą prieigą.

  • Kokybės pažeidimas sustabdo grandinę

    Kai sutarties patikra nepavyksta, vartotojai apie tai informuojami, o savininkas sprendžia, ar duomenis skelbti, sulaikyti ar taisyti.

07 Technologijos

Technologijos, su kuriomis dirbame

Platformos
  • Databricks
  • Microsoft Fabric
  • Snowflake
  • Atviras lakehouse su Apache Iceberg arba Delta Lake
Konvejeriai
  • dbt
  • Apache Spark
  • Kafka ir Debezium
  • Debesijai pritaikytas orkestravimas
Valdysena
  • Unity Catalog ir Purview
  • Atvirojo kodo katalogai
  • Duomenų kokybės karkasai
  • Politikomis grįsta prieigos kontrolė
Analitika
  • Power BI
  • Semantiniai ir rodiklių sluoksniai
  • Įterpta analitika
  • SAP analitika (esamose sistemose)

Technologijos paminėjimas apibūdina mūsų inžinerinę patirtį. Tai nereiškia partnerystės su jos gamintoju ar gamintojo pritarimo.

08 Pavyzdys

Iliustracinis pavyzdys

Iliustracinis pavyzdys

Vienas veiklos rodiklių rinkinys baldų gamybos grupei

01Situacija
Baldų ir medienos gaminių grupė turi gamyklų Lietuvoje ir Lenkijoje. Kiekviena gamykla našumą, broką ir neįvykdytus užsakymus skaičiuoja savo sistemoje pagal savus apibrėžimus, todėl grupės vadovybė lygina skaičius, kurie reiškia ne tą patį.
02Ką kurtume
Kiekvienos gamyklos suderinti duomenų produktai, teikiantys duomenis į vieną semantinį sluoksnį su grupės lygiu sutartais KPI apibrėžimais, išsaugant vietines detales.
03Žmogaus kontrolė
Kiekvienos gamyklos kontrolieriai tvirtina savo duomenų susiejimą, o grupės KPI savininkas tvirtina apibrėžimus ir jų pakeitimus.
04Ką matuotume
Laikas, per kurį parengiama mėnesio ataskaita, derinimo pataisymų skaičius ir sertifikuotų skydelių naudojimas.

09 Sektoriaus požiūriu

Jūsų sektoriuje

  • Valdomi mokslinių tyrimų ir veiklos duomenys su griežtu tikslo apribojimu, pseudonimizavimu ir prieigos registravimu.

  • Produktų ir turto pagrindiniai duomenys, kokybės ir gamybos duomenys, sujungti planavimui, atsekamumui ir DI.

  • Valstybės registrai kaip autentiški šaltiniai, vienkartinio duomenų pateikimo principas ir ataskaitos, kurias politikos formuotojai ir auditoriai gali atsekti iki konkretaus įrašo.

Lietuva

Duomenys keliose šalyse ir sistemose

Lietuvos įmonių grupės, turinčios padalinių kitose ES šalyse, ir viešojo sektoriaus institucijos dalijasi duomenimis pagal taisykles, kurios atrodo panašios, bet nėra vienodos. BDAR nustato vieną asmens duomenų apsaugos sistemą, kurios laikymąsi Lietuvoje prižiūri Valstybinė duomenų apsaugos inspekcija (VDAI). Duomenų aktas suteikia naudotojams teises į susietųjų gaminių ir susijusių paslaugų duomenis, o saugojimo terminų ir tikslų aiškinimas šalyse vis dar skiriasi.

Projektuojame duomenų produktus, kurių sutartyse nurodyta, kur duomenis galima tvarkyti, kokiais tikslais ir kiek laiko, todėl platforma gali taikyti kiekvienai šaliai tinkamą taisyklę, nekurdama atskirų duomenų kopijų.

Klausimai apie duomenis ir analitiką

Ar mums reikia duomenų tinklo (data mesh)?

Jums reikia naudingų jo dalių: duomenų produktų su savininkais ir sutartimis. Visiška decentralizacija atsiperka didelėse organizacijose su brandžiomis sričių komandomis. Daugeliui organizacijų geriau tinka centrinė platformos komanda, o už produktus atsako sritys.

Ar mūsų duomenys paruošti DI?

Tai parodys trumpas atrankinis šaltinių, kurių reikia panaudojimo atvejui, vertinimas: aprėptis, kokybė, prieigos teisės ir teisinis pagrindas. Atsakymas paprastai būna „iš dalies“, su aiškiu sąrašu, ką taisyti pirmiausia. Tą patį vertinimą naudoja ir mūsų DI inžinerijos komandos.

Jau turime duomenų saugyklą. Ar pradedame iš naujo?

Retai. Duomenų saugykla, teikianti patikimas ataskaitas, yra vertybė. Paprastai ją papildome lakehouse galimybėmis nestruktūrizuotiems ir didelės apimties duomenims, o perkeliame tik tada, kai tai pateisina kaina ar ribojimai.

Kaip dalijatės duomenimis su partneriais ar kitomis institucijomis?

Per duomenų produktus, teikiamus valdomomis API, kai sutartys, tikslo apribojimas ir registravimas jau yra vietoje. Kai taikomas Duomenų valdymo aktas ar Duomenų aktas, atitinkamai projektuojame technines kontrolės priemones.

Įvardykite sprendimą, kurio negalite priimti su dabartiniais duomenimis

Atseksime, ko jam reikia, iki pat šaltinių ir parodysime, ko pareikalautų pirmasis duomenų produktas.