Stutt yfirlit

MVP er ekki "smíða allar greiningar fyrir alla". MVP er að sanna að mynstrið er endurnýtanlegt.

dk Insights er viðbót við dk áskrift sem skilar þremur hlutum:

  • Áreiðanlegan gagnaflutning úr dk+ REST API fyrir völda viðskiptavini, með sögulegri og stigvaxandi (incremental) hleðslu.
  • Eitt endurnýtanlegt fjárhagsmódel sem hægt er að smíða einu sinni og þjóna mörgum viðskiptavinum á öruggan hátt.
  • Aðgangsstýrð afhending — innbyggð í Mínar síður, með einnig DataCentral portali sem aukaleið fyrir bókara og kraftnotendur.

Arkitektúrinn í MVP er viljandi conservative:

Hvar gögnin búa

Innan dk Azure-tenants

Engin gögn fara út fyrir Microsoft-skýið og íslenska/EU svæði. Azure Data Factory, Azure Key Vault, Azure SQL.

Hvernig módelin smíðast

Power BI semantic model

Tabular módel byggt á gold-töflum. RLS á CompanyKey. Innfellt í Mínar síður með stuttum embed-tokens.

Staðfest staða

Hver tæknilegur valkostur var staðfestur með Microsoft skjölum (sjá viðauka). Hér eru valin lykilatriði — heildarlistinn er í mvp.md §2.

SviðStaðfest staða fyrir MVPNóta
API gagnaflutningurAzure Data Factory REST tengillADF styður REST copy, marga auðkenningar­hætti og pagination.
Lyklar & leyndarmálAzure Key VaultADF nær í lykla á keyrslutíma; engin leyndarmál í kóða.
HljómunAzure Data Factory eingönguHeldur MVP einföldum og forðast óþarfa palla.
GeymslaAzure SQL fyrir control, raw, staging, warehouseHentar 2-3 viðskiptavinum í MVP. Endurmeta þegar volume og umfang vex.
MódelPower BI semantic models · PBIPBestur kostur fyrir staðlað endurnýtanlegt fjárhagsmódel.
Auðkenning · innfelltdk Portal IdentityNotandi skráir sig inn í Mínum síðum, dk-bakendi kallar á þjónustulagið server-to-server.
Auðkenning · sjálfstæðMicrosoft Entra External IDNæsta kynslóð utanaðkomandi auðkenningar; Azure AD B2C er ekki nýtt grunngildi 2026.
EmbedDataCentral er brokerdk-framendi býr aldrei til BI embed-tokens. Þeir eru gerðir server-side.
Multi-tenancySameiginlegt módel + dynamic RLSRéttur valkostur fyrir MVP. Stærri viðskiptavinir geta kallað á sterkari einangrun síðar.
ÖryggiAðgangsréttindi og RLS — bæðiEkki treysta á síun í framenda. RLS prófað sjálfvirkt áður en notandi sér nokkuð.

Markmið MVP

Hvað á að sannreyna — og jafn mikilvægt: hvað á ekki að gera í MVP.

Aðalmarkmið

Sanna mynstrið

  • Sækja bókhalds­gögn úr dk+ API fyrir 2-3 viðskiptavini.
  • Smíða eitt endurnýtanlegt fjárhags­módel og 3-5 staðlaðar skýrslur.
  • Innleiða skýrslurnar í dk-framenda­prófunarsíðu.
  • Mæla auðkenningu, RLS, frammi­stöðu, gagna­gæði og rekstrareign.
Aukamarkmið

Aukin staðfesting

  • Sýna sjálfstæðan DataCentral portal fyrir bókara og kraft­notendur.
  • Staðfesta hvernig bókhalds­stofur stýra mörgum viðskiptavinum.
  • Búa til endurnýtanlega innleiðingareign: IaC, ADF templates, SQL migration, Power BI artifacts og runbooks.
Ekki í umfangi

Hvað MVP er ekki

Heildarflutningur á öllum dk gagna­safna­svæðum.
Real-time event streaming.
Sérsniðnar skýrslur fyrir hvern viðskiptavin.
Notendabúin sjálfsþjónustumódel.
Writeback í dk+ — eingöngu read.
Endur­hönnun á dk gagnastefnu.

Tilraunaviðskiptavinir

2-3 viðskiptavinir með viljandi ólík aðgangsmynstur. MVP verður að innihalda að minnsta kosti eitt fjölfyrirtækja- eða bókhalds­stofu­mynstur — annars prófar það ekki erfiðasta og verðmætasta hluta viðskipta­rökstuðningsins.

Tegund viðskiptavinarAf hverju velja þennanHvað á að staðfesta
Smáfyrirtæki
Eitt fyrirtæki
Einföld skýrslugerð á félagsstigi. Auðveld leið inn. Grunn fjárhags­skýrslur, beinn aðgangur, UX í Mínum síðum.
Samstæða
Mörg félög undir einu leyfi
Margfélaga­sýn — fer í kjarna þess sem dk selur stærri viðskipta­vinum. Félags­hierarkía, samstæðu­sýn, drill-down og RLS á CompanyKey.
Bókhaldsstofa
Stýrir mörgum viðskipta­vinum
Mestu möguleg söluáhrif í framtíðinni — einn notandi sér mörg fyrirtæki. Eignasafns­sýn, kortlagning bókara → viðskiptavinir, framsalsaðgangur, val á virku félagi.
Ef einungis 2 í boði

Veljið: eitt einfalt einsfélaga­fyrirtæki, og eitt fjölfélaga eða bókhalds­stofu­dæmi. Án seinna mynstrsins prófum við ekki RLS á raunverulegan máta.

Hvernig viðskiptavinurinn upplifir þetta

Tvær afhendingar­leiðir. Aðalleið: innbyggt í Mínar síður. Aukaleið: sjálfstæður DataCentral portal fyrir bókara og innra fólk.

5.1 · Aðalleið

Innfellt í Mínar síður

Skref fyrir notanda:

  1. Notandi skráir sig inn í dk portal.
  2. dk-framendi spyr hvaða greiningar sé í boði fyrir innskráðan notanda.
  3. dk-bakendi kallar á DataCentral Embedding API.
  4. DataCentral staðfestir dk-vottun, notanda, tenant, félags­aðgang, skýrslu og leyfi.
  5. DataCentral skilar embed-session.
  6. dk-framendi birtir innfellda skýrslu.
  7. Bæði kerfin skrá notkun.

Engin sérstök BI-innskráning. dk heldur viðskipta­vinatengslunum og útliti.

5.2 · Aukaleið

Sjálfstæður DataCentral portal

Best fyrir:

  • Bókhaldsstofur sem stýra mörgum viðskiptavinum.
  • Kraftnotendur og fjármála­teymi sem þurfa meira pláss.
  • Innra dk fólk fyrir sölu og þjónustu­sýningar.
  • Stærri viðskiptavinir sem þurfa greiningar­þungan vinnusvæði.

Einnig góð baktrygging meðan dk-framenda­tenging þroskast.

Af hverju þjónustulag yfirhöfuð?

DataCentral er ekki bara "þar sem skýrslurnar liggja". Hlutverkið er skýrt millilag á milli dk rekstrarkerfa og notenda — það lag sem dk vill ekki setja inn í aðal­bókhalds­forritið.

6.1

Aðskilur greiningar frá kjarna­kerfunum

dk þarf ekki að sjá um BI-tákn, skýrslu­leyfi, viðskipta­vinapakka, eða aðgangs­reglur. Þjónustu­lagið heldur þessu öllu á einum stað og dk bætir bara við einföldu kalli.

6.2

Ein vara á tveimur leiðum

Sama eign — innbyggt í Mínar síður, í sjálfstæðum portal, eða síðar gegnum samstarfs­portal eða API. Búið til einu sinni, afhent á mörgum stöðum.

6.3

Bætt öryggi

Server-side embed-tokens, RLS-claim­smíði, deny-by-default, audit log. Sami staðurinn ákveður hver má sjá síðuna og hvaða gögn módelið skilar.

6.4

Pakkning og verðlagning

Basic Insights · Business Insights · Group Insights · Bókhalds­stofu­pakki · Enterprise Embedded. dk Insights snýst ekki bara um betri skýrslur — heldur að breyta dk gögnum í endur­tekjandi vöru.

Afhending í áföngum

Röð af niðurstöðum frekar en dagatali. Hver áfangi hefur skýrar útgöngu­skilyrði — næsti áfangi byrjar ekki fyrr en sá fyrri stendst.

Phase 0

Staðfesta forsendur

Áður en smíði byrjar

Staðfesta dk+ API endapunkta, auðkenningu, tilraunaviðskiptavini, gagna­sam­þykki, embedding API samning, Power BI capacity eign og umhverfi.

Útgönguskilyrði: API aðgangur virkar fyrir prófunarfélag, lykil­endapunktar skjalfestir, öryggis­eigandi samþykkir gagna­flutnings­mynstur, listi tilrauna­viðskiptavina samþykktur.

Phase 1

Setja upp pall

Innviðir

Azure resource group, Key Vault, Azure SQL, Data Factory, monitoring, GitHub Actions deployment, basic DataCentral uppsetning.

Útgönguskilyrði: Innviði hægt að setja upp úr repo, ADF les test-leyndarmál úr Key Vault, SQL migrations virka sjálfkrafa.

Phase 2

Sækja og geyma gögn

Gagnaflutningur

Metadata-driven extraction pipelines, raw landing, staging, control tables, sync history, gagnagæða­tékk.

Útgönguskilyrði: API-gögn dregin fyrir tilraunaviðskiptavini, incremental watermark virkar (eða takmörkun skjalfest), bilanir greinanlegar, re-run er idempotent.

Phase 3

Curated warehouse + módel

Módel og RLS

Stjörnu­skema, account mapping, fyrsta semantic módel, dynamic RLS, gagna­orðabók.

Útgönguskilyrði: Módel endurnýjast, P&L tölur stemma við dk source export innan samþykktra marka, RLS prófar sannar félags­aðskilnað, ókortlagðir GL reikningar sjást í gagna­gæða­niðurstöðum.

Phase 4

Skýrslur og þjónustu­lag

Aðalafhending

3-5 skýrslur, DataCentral skýrslu­listi, leyfis­upps­etning, embed session endapunktur, sjálf­stæður portal sýnishorn.

Útgönguskilyrði: Skýrslur birtast gegnum DataCentral, skýrslur birtast innfelldar í dk-prófunar­framenda, notandi sér eingöngu skýrslur og félög sem hann hefur leyfi á.

Phase 5

Notenda­prófun

Sannreyna gildi

Próf­handrit, gagna­samþykkt, UX endur­gjöf, frammi­stöðu­mælingar, þjónustu­runbook.

Útgönguskilyrði: Tilraunanotendur klára kjarnaverkefni, frammi­staða innan samþykktra marka, gagna­villur flokkaðar og leystar eða samþykktar.

Phase 6

Go / no-go

Ákvarðanir byggðar á: tæknilegri framkvæmni, öryggi, gagna­gæðum, dk verk­þungi, viðskipta­vina­endur­gjöf, pakkningu, einingar­hagfræði og rekstrar­þunga.

Möguleikar: stoppa · stækka MVP · viðskipta­legur tilrauna­launching · vörumegin­væðing.

Samþykkis­skilyrði

Hvað þarf að standast áður en MVP er metið vel heppnað.

Virkni

Notendur ná verkum

  • Notandi opnar skýrslur úr Mínum síðum.
  • Skýrslur sýna réttar félags­tölur.
  • Bókhalds­stofu­notandi sér eingöngu þá viðskiptavini sem hann hefur aðgang að.
  • Skýrslu­listi fylgir leyfum notanda.
Gagnagæði

Tölur stemma

  • Fjárhags­tölur stemma við dk source-export innan samþykktra marka.
  • Engir ókortlagðir GL reikningar í stöðluðu P&L viðskiptavinarins.
  • Bilaðar API-hleðslur sjást í eftirliti.
  • Tími síðustu uppfærslu birtist notanda.
Öryggi

Aðskilnaður stenst

  • Notandi án félagsaðgangs sér engin gögn.
  • Notandi frá félagi A sér ekki félag B.
  • Bókari frá stofu A sér ekki viðskiptavini stofu B.
  • Embed-tokens eru stutt­lifandi og ekki gerðir í vafra.
  • RLS prófar eru sjálfvirkir.
Frammistaða

Mæliviðmið

  • Embed session creation latency.
  • Fyrsti opnunartími skýrslu.
  • Slicer-svar.
  • Módel refresh tími · ADF extraction tími.

Áhætta & mótvægi

Þetta eru áhættur sem geta felt MVP — eða gert hann mun dýrari en gert var ráð fyrir. Hver áhætta hefur skýra mótvægis­aðgerð.

ÁhættaÁhrifMótvægi
dk+ API styður ekki áreiðan­legan incremental syncHáttSannreyna snemma; nota period-reload sem varafall; skjalfesta sem MVP-niðurstöðu.
API rate limits hindra skölunHáttThrottling, backoff, batch á endapunktum, sync-tímasetningar.
RLS uppsetning leyfir gagna­lekaKrítísktSjálfvirkir RLS prófar · deny by default · adversarial test users.
Reikningskort­lagning ófullkominHáttSkýrsla yfir ókortlagða reikninga + samþykkis­flæði.
Azure SQL skalar ekki í framtíðinniMiðSQL er MVP-geymsla; skilgreina ákvörðunar­hlið um skala­stærð.
Auðkennings­eign óljósHáttÁkveða strax: dk-aðal innfellt vs DataCentral sjálfstætt vs bæði.
Skýrslu­frammistaða lélegMiðImport mode · aggregate töflur · indexing · incremental refresh.
dk-framenda­tenging tekur lengri tíma en gögninMiðSjálfstæður portal sem baktrygging meðan tenging þroskast.
Viðskiptavinir treysta ekki tölunumHáttSmíða afstemmingar­skjái og source drill-back metadata.
Pakkning óljósMiðVerðlagning og pakka­greining inni í tilraun, ekki bara tæknileg sannreynsla.

Ákvarðanir sem þarf áður en smíði byrjar

Tólf spurningar sem dk og DataCentral verða að svara áður en kóði er skrifaður. Listinn er ekki tæmandi en hver punktur breytir umfangi eða arkitektúr.

01 · Tilrauna­viðskiptavinir

Hverjir 2-3 og hvaða félög undir hverjum?

02 · Gagnaumfang

Hvaða endapunktar í MVP — GL, kort, viðskiptavinir, birgjar, reikningar, greiðslur, áætlanir?

03 · Söguleg gögn

Hve langt aftur í upphafs­hleðslu?

04 · Refresh tíðni

Daglega, mörgum sinnum á dag, eða nálægt rauntíma?

05 · Auðkenning

dk portal eingöngu, DataCentral sjálfstætt, eða bæði?

06 · Embed eign

Brokkar DataCentral að fullu, eða kallar dk beint á BI-veituna? Tilmæli: DataCentral.

07 · Capacity eign

Hvaða tenant/workspace/capacity keyrir Power BI módelin?

08 · Gagna­heimkynni

Staðfesta að öll gögn liggja í dk Azure-tenant nema sérstaklega samþykkt.

09 · Pakkning

Hvaða pakkar eru prófaðir í MVP?

10 · Þjónusta

Hver tekur við aðgangs­málum, gagna­ágreiningi, skýrslu­villum, kerfis­atburðum?

11 · Öryggis­samþykkt

Hver samþykkir RLS- og embed-token hönnun?

12 · Go/no-go viðmið

Hvaða mælikvarðar verða að standast áður en stækkað er?

Næsta skref

90 mínútna fundur dk + DataCentral, innan tveggja vikna

Markmið: leysa þessar 12 ákvarðanir og einblöðung með ákvörðunum sem fer aftur til allra hagaðila. Eftir það er smíði MVP-pípu fyrir fyrsta tilraunaviðskiptavin (sennilega smáfyrirtæki) byrjuð.

Næst: Tæknilegur arkitektúr Skoða mockup