Pāriet uz galveno saturu
FromNine
Izvēlne

MI un dati

Dati, uz kuriem var balstīt MI un lēmumus.

Mēs veidojam datu platformas, kurās katrai datu kopai ir īpašnieks, līgums un zināma kvalitāte, lai analītika, ikdienas darbs un MI izmantotu vienus un tos pašus uzticamos skaitļus.

Organizācijām, kurām vajadzīgs viens uzticams skats uz datiem, kas izkaisīti pa valstīm, uzņēmumiem un mantotām sistēmām.

Pieteikt sarunuApskatīt zināšanu risinājumu
Dati un analītika: spēju slāņiČetri slāņi viens aiz otra. No augšas uz leju: analītika un MI, kas izmanto datus, datu produkti ar īpašniekiem un līgumiem, lakehouse slāņi, kas datus attīra un saskaņo, un pārvaldība, kas aptver visu.01Analītika un MI02Datu produkti un līgumi03Lakehouse slāņi04Pārvaldība un izcelsme
  1. 01Datu produkti ar konkrētiem īpašniekiem, līgumiem un kvalitātes pārbaudēm
  2. 02Pārvaldība, kas nosaka nolūka ierobežojumu un glabāšanu, nevis tikai katalogs
  3. 03Viena KPI definīciju kopa, ko apstiprina gan uzņēmums, gan IT

01 Problēmas

Pazīstamas datu problēmas

Lielākā daļa neveiksmīgo MI projektu izrādās datu projekti citā izskatā.

  1. 01

    Trīs pārskati, trīs dažādi skaitļi

    Finanšu daļa, ražošana vai darbības vadība un valde katra aprēķina ieņēmumus vai lietu apjomu savā veidā. Sanāksmes sākas ar skaitļu saskaņošanu, nevis ar lēmumiem.

  2. 02

    Datiem nav īpašnieka, tāpēc neviens tos nelabo

    Kļūdas atrod vēlāk, izlabo izklājlapā, un nākamajā mēnesī tās atgriežas.

  3. 03

    MI komanda lielāko daļu laika meklē datus

    Katrs lietojums sākas ar nedēļām ilgiem piekļuves pieprasījumiem, datu izguvēm un tīrīšanu, ko nākamā komanda atkārtos.

  4. 04

    Arhīvi nav izmantojami MI

    Skenēti dokumenti ar sliktu OCR, dublikāti, trūkst metadatu. Izgūšana no tiem atgriež troksni.

02 Ko piegādājam

Ko mēs piegādājam

  1. 01 Datu pamati MI un analītikai

    Lakehouse arhitektūras ar slāņotu modelēšanu no neapstrādātiem datiem līdz saskaņotiem un lietošanai gataviem, un datu produkti, kas publicē, ko tie satur, cik svaigi ir dati un kas par tiem atbild.

    Ko mēs darām

    • Platformas arhitektūra un glabāšanas formātu izvēle
    • Slāņotas modelēšanas konvencijas
    • Datu produktu projektēšana ar līgumiem
    • Pakešu ielāde un izmaiņu datu uztveršana

    Ko Jūs saņemat

    • Lakehouse platforma, definēta kodā
    • Pirmie datu produkti ekspluatācijā
    • Datu līguma veidne un pārskatīšanas process

  2. 02 Kvalitāte, izcelsme un pamatdati

    Automātiskas kvalitātes pārbaudes katrā slānī, izcelsmes izsekošana no avota līdz pārskatam un pamatdati un klasifikatori svarīgākajām vienībām: iedzīvotājiem, klientiem, produktiem un aktīviem.

    Ko mēs darām

    • Kvalitātes noteikumi ar sliekšņiem un brīdinājumiem
    • Izcelsmes izsekošana kolonnu līmenī
    • Pamatdatu sasaiste un noteikumi, kura vērtība paliek spēkā
    • Klasifikatoru pārvaldība

    Ko Jūs saņemat

    • Kvalitātes panelis katram datu produktam
    • Izcelsmes dati, ko var vaicāt
    • Etalona ieraksti prioritārajām vienībām

  3. 03 Pārvaldība, kas tiek piemērota

    Katalogs, klasifikācija un piekļuves politikas, ko platforma piemēro automātiski. VDAR nolūka ierobežojums un glabāšanas termiņi ir ieprogrammēti, un datu koplietošana notiek pēc Datu pārvaldības akta noteikumiem, kur tas ir piemērojams.

    Ko mēs darām

    • Klasifikācijas shēma un marķēšana
    • Uz atribūtiem balstītas piekļuves politikas
    • Automātiska glabāšana un dzēšana
    • Datu koplietošanas līgumi un tehniskās kontroles

    Ko Jūs saņemat

    • Katalogs, ko aizpilda platforma
    • Piekļuves politikas kā kods
    • Glabāšanas grafiks darbībā

  4. 04 Nestrukturēts saturs, sagatavots MI

    OCR kvalitātes uzlabošana, metadatu bagātināšana, dublikātu novēršana un arhīvu sakārtošana, lai inteliģenta dokumentu apstrāde un izgūšanas sistēmas sāktu ar saturu, ko ir vērts izgūt.

    Ko mēs darām

    • Satura uzskaite un kvalitātes izlases pārbaude
    • OCR un izkārtojuma izguves uzlabojumi
    • Gandrīz identisku dokumentu noteikšana
    • Metadatu bagātināšana un klasifikācija

    Ko Jūs saņemat

    • Attīrīta, bagātināta satura krātuve
    • Satura kvalitātes pārskats
    • Noteikumi turpmāk pievienotajam saturam

  5. 05 Analītika un BI, ko cilvēki lieto

    Semantiskais slānis ar KPI definīcijām, ko saskaņojuši uzņēmums un IT, pārvaldīta pašapkalpošanās analītika un iegulta analītika SaaS produktos un portālos.

    Ko mēs darām

    • KPI definēšanas darbnīcas
    • Semantiskais modelis un rādītāju slānis
    • Pašapkalpošanās aizsargnoteikumi un sertificētas datu kopas
    • Iegulta analītika klientiem paredzētos produktos

    Ko Jūs saņemat

    • KPI glosārijs ar īpašniekiem
    • Sertificēts semantiskais modelis
    • Paneļi, kas aizstāj izklājlapas

  6. 06 Straumēšana ikdienas darbam

    Izmaiņu datu uztveršana un notikumu plūsmas tur, kur lēmumi nevar gaidīt nakts ielādi: krājumu atlikumi, lietu statuss, krāpšanas signāli.

    Ko mēs darām

    • Aizkaves prasības katram lietojumam
    • CDC no darbības datubāzēm
    • Plūsmu apstrāde un materializēti skati
    • Atkārtotas apstrādes un vēsturisko datu ielādes projektējums

    Ko Jūs saņemat

    • Straumēšanas konveijeri ekspluatācijā
    • Darbības skati ar svaiguma mērķiem
    • Atkārtotas apstrādes procedūra

03 Arhitektūra

Ilustratīva atsauces arhitektūra

Dati no darbības sistēmām un dokumentiem caur ielādi nonāk slāņotā lakehouse: neapstrādāti, kā saņemti, tad saskaņoti un kvalitātes pārbaudīti, tad datu produkti ar īpašnieku un līgumu. Lietotāji nekad nelasa neapstrādātus datus.

No datu produktiem viens ceļš ved uz semantisko slāni un BI, citi uz MI izgūšanu un pazīmēm un uz datu API citām sistēmām. Pārvaldība ir zem visa un to piemēro platforma, nevis politikas dokuments.

Ilustratīvs piemērs

  1. Avoti un ielāde

    • Darbības sistēmas
    • Dokumenti pēc OCR un bagātināšanas
    • Pakešu ielāde un CDC

  2. Lakehouse platforma

    • Neapstrādātie dati
    • Saskaņotie dati
    • Kvalitātes pārbaudes un izcelsme
    • Pamatdati un klasifikatori
    • Datu produkti ar līgumiem

  3. Izmantošana

    • Semantiskais slānis un BI
    • MI izgūšana un pazīmes
    • Datu API un koplietošana

  4. Pārvaldība

    • Pārvaldība: katalogs, klasifikācija, piekļuves politikas, glabāšana
No lakehouse slāņiem līdz datu produktiem ar īpašniekiem

Ilustratīva arhitektūra, nevis klienta sistēma.

Lasīt diagrammu kā tekstu

Galvenais ceļš ved no darbības sistēmām caur pakešu ielādi un izmaiņu datu uztveršanu, neapstrādāto datu slāni, saskaņoto slāni un datu produktiem līdz semantiskajam slānim ar pārvaldītu BI.

Nestrukturēti dokumenti arī nonāk ielādē pēc OCR un bagātināšanas. Kvalitātes pārbaudes un izcelsmes izsekošana aptver neapstrādāto un saskaņoto slāni. Pamatdati un klasifikatori papildina datu produktus. Datu produkti apkalpo arī MI izgūšanu un pazīmes, kā arī datu API koplietošanai.

Pārvaldības josla ar katalogu, klasifikāciju, piekļuves politikām un glabāšanu aptver visu platformu.

04 Apsvērumi un ierobežojumi

Inženierijas apsvērumi un ierobežojumi

  • Vispirms īpašnieki, tad rīki

    Kā mēs to risinām

    Katram datu produktam ir uzņēmuma īpašnieks, kas nosaka tā nozīmi, un tehniskais īpašnieks, kas nodrošina tā darbību. Mēs palīdzam definēt abas lomas un līgumu starp datu sniedzējiem un lietotājiem.

    Ierobežojumi un atkarības

    Platforma nevar radīt īpašumtiesības. Ja organizācija nenozīmē īpašniekus, kvalitātes problēmas atgriezīsies neatkarīgi no rīkiem.

  • Nolūka ierobežojums praksē

    Kā mēs to risinām

    Personas datus marķējam ar nolūkiem, kam tos drīkst izmantot, un piekļuves politikas un glabāšana automātiski seko šīm atzīmēm.

    Ierobežojumi un atkarības

    Kuri nolūki ir likumīgi, lemj Jūsu datu aizsardzības speciālists un juristi. Mēs to ieviešam, bet nelemjam.

  • Datiem MI vajadzībām ir sava kvalitātes latiņa

    Kā mēs to risinām

    MI lietojumiem mērām to, kas vajadzīgs izgūšanai un modeļiem: pārklājumu, svaigumu, dublikātus un teksta izguves kvalitāti.

    Ierobežojumi un atkarības

    Dažus arhīvus nav vērts labot. To parādīs izlases novērtējums, un dažreiz pareizā atbilde ir tos neiekļaut.

05 Kā strādājam

Kā mēs strādājam

Platformu veidojam ap pirmajiem svarīgajiem datu produktiem, nevis otrādi.

  1. 01

    Izvēlēties lēmumus, nevis datu kopas

    Sākam ar diviem vai trim lēmumiem vai MI lietojumiem un tiem vajadzīgajiem datiem, nosaucot īpašniekus.

    RezultātsDatu produktu saraksts ar īpašniekiem

  2. 02

    Veidot pamatus ap tiem

    Platforma, ielāde, kvalitātes pārbaudes un pārvaldība tieši tādā apjomā, lai šie produkti darbotos pareizi.

    RezultātsPirmie datu produkti ekspluatācijā

  3. 03

    Augt pa produktam

    Katrs jauns produkts izmanto esošos pamatus; katalogs un KPI glosārijs aug līdzi.

    RezultātsProduktu ceļvedis un lietošanas rādītāji

06 Cilvēka kontrole

Kur kontrole paliek cilvēkiem

Datu platformas automatizē datu kustību un pārbaudes. Cilvēki lemj par nozīmi, piekļuvi un nolūku.

  • Definīcijas apstiprina īpašnieki

    KPI vai datu produkta nozīme mainās tikai ar tā īpašnieka apstiprinājumu, un izmaiņām ir versija.

  • Piekļuvi piešķir politiku īpašnieki

    Datu īpašnieki lemj, kurš kādus datus drīkst izmantot un kādam nolūkam; platforma to piemēro un žurnālē katru piešķīrumu.

  • Kvalitātes pārkāpums aptur plūsmu

    Ja līguma pārbaude neizdodas, lietotāji tiek informēti, un īpašnieks lemj, vai publicēt, aizturēt vai labot.

07 Tehnoloģijas

Tehnoloģijas, ar kurām strādājam

Platformas
  • Databricks
  • Microsoft Fabric
  • Snowflake
  • Atvērts lakehouse uz Apache Iceberg vai Delta Lake
Konveijeri
  • dbt
  • Apache Spark
  • Kafka un Debezium
  • Mākoņa orķestrācijas rīki
Pārvaldība
  • Unity Catalog un Purview
  • Atvērtā koda katalogi
  • Datu kvalitātes ietvari
  • Uz politikām balstīta piekļuves kontrole
Analītika
  • Power BI
  • Semantiskie un rādītāju slāņi
  • Iegulta analītika
  • SAP analītika (esošās vides)

Tehnoloģijas nosaukums šajā sarakstā apraksta mūsu inženierijas pieredzi. Tas nenozīmē partnerību ar tās piegādātāju vai tā atbalstu.

08 Piemērs

Ilustratīvs piemērs

Ilustratīvs piemērs

Vieni darbības KPI pārtikas ražotāju grupai Baltijas valstīs

01Situācija
Grupas meitasuzņēmumi Latvijā, Lietuvā un Igaunijā ziņo par ražošanas apjomu, krājumiem un pasūtījumu atlikumu no savām ERP sistēmām ar savām definīcijām. Grupas vadība salīdzina skaitļus, kas nenozīmē vienu un to pašu.
02Ko mēs izveidotu
Saskaņoti datu produkti katram uzņēmumam, kas baro vienu semantisko slāni ar grupas līmenī saskaņotām KPI definīcijām, saglabājot vietējo detalizāciju.
03Kur lemj cilvēki
Katra uzņēmuma kontrolieris apstiprina savu datu sasaisti; grupas KPI īpašnieks apstiprina definīcijas un to izmaiņas.
04Ko mēs mērītu
Laiks ikmēneša pārskata sagatavošanai, saskaņošanas labojumu skaits un sertificēto paneļu lietojums.

09 Nozares skatījums

Jūsu nozarē

Latvija

Dati, kas šķērso robežas

Grupas ar uzņēmumiem Latvijā, Lietuvā un Igaunijā un iestādes, kas sadarbojas ar citām ES valstīm, koplieto datus pēc noteikumiem, kas izskatās līdzīgi, bet nav vienādi. VDAR nosaka vienu ietvaru personas datiem, un Latvijā to papildina Fizisko personu datu apstrādes likums. Datu akts dod lietotājiem tiesības uz datiem no savienotiem produktiem un pakalpojumiem, bet glabāšanas termiņu un nolūku interpretācija valstīs joprojām atšķiras.

Mēs projektējam datu produktus, kuru līgumi nosaka, kur datus drīkst apstrādāt, kādiem nolūkiem un cik ilgi, lai platforma katrai valstij piemērotu pareizo noteikumu bez atsevišķām datu kopijām.

Jautājumi par datiem un analītiku

Vai mums vajadzīgs datu tīkls (data mesh)?

Jums vajadzīgas tā noderīgās daļas: datu produkti ar īpašniekiem un līgumiem. Pilnīga decentralizācija atmaksājas lielās organizācijās ar nobriedušām jomu komandām. Daudzām organizācijām labāk der centrāla platformas komanda un jomu īpašumtiesības uz produktiem.

Vai mūsu dati ir gatavi MI?

To parādīs īss izlases novērtējums tiem avotiem, kas vajadzīgi lietojumam: pārklājums, kvalitāte, piekļuves tiesības un tiesiskais pamats. Atbilde parasti ir „daļēji”, ar skaidru sarakstu, ko labot vispirms. Mūsu MI inženierijas komandas izmanto to pašu novērtējumu.

Mums jau ir datu noliktava. Vai jāsāk no jauna?

Reti. Datu noliktava, kas nodrošina uzticamus pārskatus, ir vērtība. Parasti to paplašinām ar lakehouse iespējām nestrukturētiem un liela apjoma datiem un migrējam tikai tad, ja to attaisno izmaksas vai ierobežojumi.

Kā notiek datu koplietošana ar partneriem vai citām iestādēm?

Ar datu produktiem, kas pieejami caur pārvaldītām API, ar līgumiem, nolūka ierobežojumu un žurnālēšanu. Kur piemērojams Datu pārvaldības akts vai Datu akts, atbilstoši projektējam tehniskās kontroles.

Nosauciet lēmumu, ko ar šodienas datiem nevarat pieņemt

Mēs izsekosim, kas tam vajadzīgs, līdz pat avotiem un parādīsim, ko prasītu pirmais datu produkts.

Pieteikt sarunuApskatīt dokumentu apstrādi