Datavarehus i skatteetaten -

Presentasjon om: "Datavarehus i skatteetaten -"— Utskrift av presentasjonen:

1 Datavarehus i skatteetaten -
utfordringer workshop om semantisk interoperabilitet

2 Datavarehus – hva og hvorfor
Portal SKR S/R Reports Annet LTO LEP MVA LFP ER Discoverer Hovedbase Kontrolltorg DTI-torg Stat./mining OLAP DSF DSB Mottak Datavarehus Datavarehus muliggjør analyser, rapporter og spørringer basert på informasjon fra mange kilder Datavarehus henter eller mottar data fra ulike kildesystemer uavhengig av teknisk plattform Datavarehus legger grunnlaget for ”Business Intelligence”, utnytte informasjon slik at man kan ta beslutninger og handle basert på analyser, innsikt og kunnskap Skatteetaten bruker datavarehus bl.a. for å velge ut hvem som skal kontrolleres og for å drive smartere innkreving av utestående skatter og avgifter.

3 Vi har primært fokus på skatteinterne behov……….
Hvorfor er våre erfaringer relevante likevel? Vi erfarer at det enkelte Kildesystem har seg selv som fokus – eks. fredes kodeverk bare ett år Vi møter tilsvarende utfordringer som staten gjør i fht. intern samhandling og samhandling med publikum Standardisering Forståelig datautveksling Konsistens Vi kommer til å fortsette å bygge ut datavarehus, etter hvert også data fra eksterne kilder…………….

4 Utfordringer 1 - data fra ulike kilder
Flere formater Flere beskrivelser Hva har vi valgt som ”sannheten”? Virksomhet = slik det er beskrevet i Enhetsregisteret Person = slik det er beskrevet i DSF (Folkeregisteret)

5 Utfordringer 2 - dato Dato brukes i ulike sammenhenger, for ulike behov Hva har vi valgt? Dato for periode fra - til = – Dato for sist hentet data = :41 (Fra-dato og til-dato har ulik default verdi.)

6 Utfordringer 3 - adresse
Boligadresse Postadresse Virksomhetsadresse Hva har vi valgt ? Boligadresse: Vi er ikke så opptatt av format fordi den ikke brukes til kontakt. Vi bruker adresse slik vi får det fra DSF. Eks. hvis vi får GAB-adresse, lagrer vi den. Kommune er viktig. Postadresse: Kun viktig i den grad den er forskjellig fra boligadresse. Virksomhetsadresse: Slik den er definert i ER

7 Utfordringer 4 - Transaksjoner (betalings-)
Ulikt modellert i systemene våre Vi forsøker å standardisere format og generalisere transer på tvers av skatt / avgift Foreløpig har vi bare fått fra Skatteregnskapet. Der får vi ikke alle enkelttranser, men en sum innbetalt mellom hvert tiltak. Hva antar vi er det basale? Kravtype(eks. restskatt,mva,arbgavg),Kraveier(kommune),Opprinnelig krav,Saldo,beløp dato,

8 Modellering av datavarehuset.
Skatteetaten har noen kjerneoppgaver: Fastsette skatter og avgifter i hht. gjeldende lover og regler Innkreving av skatter og avgifter Kontroll av avgiftspliktige og skattepliktige for å sikre rett skatt og avgift Sett fra brukersiden, er det å kunne utnytte et ”bredt” datagrunnlag for analyse et stort fremskritt ved datavarehus Omstrukturering av informasjon – slik at vi får fleksibilitet

9 Fra datamodellen – Generalisering AKTØR
KNYTNING AKTØR kan være enten person eller virksomhet. AKTØR_KNYTNING gir oss mulighet til å beskrive Bedriftshierarkier Familie Forholdet mellom Bedrift Person etc. PERSON AKTØR VIRKSOMHET

10 Fra datamodellen – Generalisering - OPPGAVE
Vi har valgt å definere OPPGAVE – OPPGAVE_POST enten det er skatte- eller avgifts-informasjon Dette gjør det enkelt å knytte til oss nye kilder Utviklingen av teknologien gjør det enklere å generalisere i dag enn tidligere Pr. post skiller vi mellom påstand- xx - likning OPPGAVE OPPGAVE_POST

11 Fra datamodellen – Generalisering TILTAK
SAK RESKONTRO_KRAV RESKONTRO_KRAV være enten skatt eller avgift (krav og saldo) TILTAK – alle tiltak overfor person/virksomhet (hva vi måtte finne det hensiktmessig å definere som tiltak) TILTAK RESKONTRO_ TRANSAKSJON Kan denne brukes som grunnlag for å analysere hvilke tiltak som virker?

12 Metadata Det hadde vært ønskelig å få metadata fra kildesystemene
Slut tbruker laget Kilder Datatorg Mottak Datavarehus Datatorg Datatorg Bruker Dataflyt Det hadde vært ønskelig å få metadata fra kildesystemene Brukerne har definert de ulike datelementene slik at dette har vært kilden for beskrivelsen både i Sluttbrukerlaget og i de fysiske databasene Brukernes definisjoner har i overraskende grad også dekket behovet for utviklernes metadata.

13 Hva vil bli viktig for datavarehuset i skatteetaten fremover?
Vil kommunikasjon med saksbehandlersystemet bli viktig? I dag kun tilbakeføre segmentering I fremtiden kan det f. eks bli krav om å lagre resultat av kontroller for å finne ut mer om hvem som snyter og hvem som ikke gjør det. ODS Vil data fra Eksterne leverandører bli viktig? Vil samarbeid med andre offentlige aktører bli viktig? Staten som en smartere innkrever? Vil datautveksling i offentlige etater bli viktig? Personvern - Datatilsynet