Net-Base Tímarit

01.08.2026

Gagnaþætting án gagnakirkjugarðs: CDC, atburðastreymi og ETL í samanburði fyrir ERP/CRM/birgðastjórnun

ETL, CDC eða Event Streaming: Þrjár leiðir til að samþætta ERP, CRM og birgðakerfi á hreinan og áreiðanlegan hátt – með skýrum afleiðingum fyrir rekstur, gagnagæði, biðtíma, úttekt og innleiðingu. Þessi samanburður sýnir hvernig hægt er að setja upp gagnastrauma stöðugt, án þess að búa til gagnagröf.

01.08.2026

Frá tímaritsþema til verkefnaframkvæmdar

Viðeigandi þjónustu- og tæknisíður fyrir greinina

Þegar ERP, CRM og lagerstjórn eru tengd saman vill maður yfirleitt tvö atriði í senn: ferlar skulu ganga óslitið (t.d. Auftrag → Kommissionierung → Versand → Rechnung), og gögn skulu vera tiltæk til greininga (t.d. Lieferfähigkeit, Deckungsbeiträge, Retourenquoten). Í framkvæmd skapast fljótt togstreita milli „Við þurfum þetta í skýrslunum í dag“ og „Við megum ekki óstöðugleika í framleiðslu‑ERP“. Hér ræðst hvort Gagnaintegration án gagnagröf heppnist eða hvort yfir ár safnist ógreinileg blanda af CSV‑útflutningum, næturverkefnum, skuggatöflum og óuppgreiddum gagnakópilum.

Þessi grein ber saman þrjár miðlægari nálganir: ETL (Extract, Transform, Load), CDC (Change Data Capture, þ.e. að greina og flytja gagnabreytingar) og Event Streaming (viðburðir sem samfelldur gagnastraumur um miðlara). Áherslan er ekki á forritunardetaljur heldur á arkitektúrleiðir, rekstrarveruleika, gagnagæði, öryggis‑ og innleiðingarmál – eins og þau koma fyrir í raunverulegum samþættingarverkefnum milli fyrirtækjakerfa.

Af hverju samþættingar verða oft að gagnagröf

Gagnagröf myndast sjaldnast af illri viljugleika. Dæmigerðar orsakir eru:

  • Óljós kerfismörk: ERP er stundum „leiðandi“, svo aftur CRM, og í lagerinu er eigin stöðulógík. Án skilgreindrar gagnayfirráðar (System of Record) eru árekstrar fyrirfram ætlaðir.
  • Ad‑hoc‑kröfur: „Við þurfum fljótt dashboard“ leiðir til beinra aðgangs að ERP; síðar bætast við fyrirspurnir, materialized views eða afrit. Hver hraður árangur (Quick Win) færist rekstrarálag og ábyrgð yfir.
  • Skortur á samningum: Viðmótssamningar (hver reitur, hvaða merking, hvaða útgáfustjórnun) vantar. Niðurstaðan er Schema‑Drift – reitir breyta merkingu eða uppbyggingu án þess að niðurstreymis‑kerfi skynji breytinguna tímanlega.
  • Engin rekstrarstefna: Jobs keyra „einhvers staðar“, aðgangsupplýsingar liggja í handritum, engin viðvörun er um gagnagöt og enginn getur svarað hvort skýrsla sé „fullkomin“.

ETL, CDC og Event Streaming leysa mismunandi hluta þessa vanda. Mikilvægast er að velja nálgun sem passar við ferlakritík, látenskröfur og rekstrarþroska – og að reka samþættingarveginn sem vöru, ekki sem eintaksgert verkefnisskjalf.

Skýr flokkun hugtaka: ETL, CDC og Event Streaming

ETL stendur fyrir „Extract, Transform, Load“: Gögn eru sótt úr upprunakerfum, umbreytt (t.d. hreinsuð, samantekin, mappuð) og hlaðin í markkerfi, oft Data Warehouse. Klassískt fer þetta fram lotubundið (batch), t.d. um nótt eða á klukkutíma fresti.

CDC (Change Data Capture) lýsir aðferðum sem greina breytingar á gögnum og flytja þær sem delta: ný/uppfærð/eydd gagnasett. CDC má útfæra með tímasprengjum, triggerum eða – rekstrarlega oft hreinskilnast – í gegnum transaktionslogs gagnagrunnsins. Markmiðið er yfirleitt „near realtime“, án þess að keyra síendurteknar fullar útdrætti.

Event Streaming lýsir birtingu viðburða (t.d. „Pöntun samþykkt“, „Vörumóttaka bókuð“) sem samfelldum straumi yfir skilaboðamiðlara (t.d. Kafka‑lík kerfi eða Service‑Bus hugmyndafræði). Neytendur áskriftast á viðburði og vinna úr þeim á sínum hraða. Mikilvægt: Viðburður er ekki sjálfkrafa „öll sönnun“ gagna, heldur oft stöðubreyting með samhengi.

Samanburður eftir þeim spurningum sem raunverulega skipta máli í rekstri

Seinkun: Hversu fljótar þurfa gögnin í raun að vera?

Fyrir margar ERP-skýrslur duga gögn frá „síðasta kvöldi“. Fyrir rekstur á lageri getur „5 mínútur gömul“ þegar verið of seint (t.d. við skort á birgðum). Hér gildir:

  • ETL skaffar áætlanleg uppfærsluglugga, en er samkvæmt hönnun ekki „strax“.
  • CDC hentar þegar þið viljið endurspegla breytingar á gögnum skjótt í skýrslu- eða leitarkerfum án endurmóta á viðskiptalógík.
  • Event Streaming hentar þegar ferlar þurfa að bregðast tímanlega (t.d. búa til sendingarmiða, uppfæra stöðu viðskiptavinar, senda tilkynningar).

Eitt algengt mistök er að krefjast „Realtime“ alls staðar. Realtime eykur flækjustig í eftirliti, villumeðferð og gagnasamræmi. Skynsamlegt er að flokka: Hvaða gögn eru rekstrarleg (ferlakrítísk), hvaða greiningar (skýrslukrítísk) og hvaða arkíversk (endurskoðun/eftirlit)?

Samræmi: Hvað gerist við hlutgalla?

Í dreifðum samþættingum eru hlutgallar eðlilegir: nettruflanir, timeouts, læsingar, viðhaldsgluggar. Ákvarðandi er hvort nálgun ykkar dembar þetta á traustan hátt.

  • ETL vinnur oft í keyrslum. Ef keyrsla mistakast er gagnastöðvum í áfangastaðnum oft viðhaldið sem „samræmt til tímapunkts X“, en verður síðan úrelt. Þetta er oft ásættanlegt fyrir skýrslugerð, svo lengi sem það er gegnsætt.
  • CDC flytur yfir deltas. Ef ferlið hangir uppi myndast aukasöfnun. Þetta er stjórnlegt, en þið þurfið að mæla seinkun (Lag) og setja viðvörunarmörk.
  • Event Streaming færist ábyrgð villna yfir á neytendur. Fyrir það þurfið þið idempotentleika (meðhöndlun margra sinnum án aukaverkana), retry-strategíur og eine Dead-Letter-Queue (geymsla fyrir óvinnanlegar skilaboð); annars verða villur „þöglar“ og koma upp fyrst innan fagdeildarinnar.

Samræmi er líka fagsmál: Verður „pöntun + línuatriði + birgðabókanir“ að koma sem pakki, eða nægir eventual consistency (síari samræming)? Því meiri sem pakkaóháðin er, því frekar þurfið þið færslumörk (transaction boundaries) og skýrar reglur um röð.

Álag og áhætta fyrir ERP: Hvað setur á kerfið undir álag og hvernig?

Mörg samþættingarvandamál eru í raun frammistöðu- og læsingarvandamál í upprunakerfinu. ERP er OLTP-kerfi (Online Transaction Processing): margar smáar færslur, hátt ritálag, viðkvæmir vísar.

  • ETL dregur oft stór gagnamagni. Án hreinna tíma glugga, Read-Replica eða sértækra útdráttartafla getur ETL hægðað ERP-ið.
  • CDC yfir logs er oft vægara vegna þess að það notar „nú þegar til staðar“ breytingastrauminn. Trigger-bundið CDC getur hins vegar lengt ritstíga og er í mikið álagi á töflum áhætta.
  • Event Streaming forðast beint lesálag ef atburðir koma úr forritinu sjálfu. Ef atburðir eru hins vegar „myndaðir úr gagnagrunninum“ eruð þið aftur nálægt CDC – með svipuðum íhugunum.

Regla úr framkvæmd: Ef ERP er í dag þegar þétt hannað ætti samþætting ekki að hefjast með viðbótar fullum útdrætti. Oft er það skynsamlegra að byrja með aftengingu, t.d. með CDC í sértækt skýrslu- eða samþættingarskema, og fyrst þar á eftir framkvæma umbreytingar.

ETL í daglegu: gott fyrir skýrslugerð, hættulegt sem ferlalím

ETL er hjá mörgum fyrirtækjum inngangur, því það er hugmyndafræðilega raunhæft: „Við sækjum gögn, förum yfir þau, hleðsum þau inn í DWH.“ Fyrir klassískar BI-kröfur er það enn skynsamlegt.

Styrkleikar ETL

  • Fyrirsjáanleiki: Næturkeyrslur eða klukkutíma keyrslur eru vel stýranlegar og passa inn í viðhaldsglugga.
  • Miðlæg umbreytingarlogík: Hreinsun, mapping, historíkerun (t.d. Slowly Changing Dimensions) eru vel þekkt í DWH-samhengi.
  • Endurskoðanleiki: Með Lauf-IDs, fjölda raða og checksumum geturðu rekjað hvað var hlaðið og hvenær.

Algengar áhættur og „gagnagröf“-munstur

  • Óstýrt útbreiðsla beins aðgangs: Því fleiri greiningar sem byggja beint á útfluttu töflunum, því fleiri „óopinberar gagnaafurðir“ myndast.
  • Skema-drift án snemma viðvörunar: Ef reitir í ERP breytast sjást þær oft ekki fyrr en við næstu keyrslu – eða verr: alls ekki, því núllgildi „renna í gegn“.
  • Batch-gluggar þrengjast: Gagnamagn vex, keyrslutími eykst, og á endanum rekast ETL-verkferlar á afrit, endurskipulagningu eða næturverkefnakeðjur í ERP.

Dæmi: Lager þarf daglega skýrslu „Artikel ohne Bestand aber offene Aufträge“. Sem ETL-rapport er það ásættanlegt. Ef þessi skýrsla er hins vegar notuð sem undirstaða fyrir rekstrarlega áætlanagerð breytist 24 stunda töf skyndilega í faglega hættu. Þá verður ETL að ferlislími – og það er sjaldan stöðugt.

CDC: Hin hagnýta leið að deltum og nálægt rauntíma

Schematische Darstellung von CDC über Transaktionslog mit Delta-Übertragung in Integrationsdatenbank und Data Warehouse
CDC með deltum aðskilur skýrslugerð og samþættingu frá OLTP gagnagrunninum.

CDC er oft kjörpunktur þegar þið viljið færa gögn úr ERP/CRM/Lager tímanlega í leitarkerfi, Data Warehouse eða samþættingar-gagnagrunna án þess að þurfa að endurhugsa alla faglega rökfræði sem atburðalíkan.

CDC-afbrigði og rekstrarafleiðingar þeirra

  • CDC byggt á tímapunktum/High-Watermark: Þið lesið „allt síðan síðasta tímamarki“. Þetta er einfalt, en viðkvæmt fyrir síðar gerðum leiðréttingum, tímadrift og vöntun eyðingarviðburða.
  • Trigger-byggð CDC: Breytingar skrifast aukalega í breytingartöflur. Þetta er virkni­lega skýrt en eykur skrifálag og krefst skýrra heimilda og viðhalds við skema­breytingar.
  • Log-byggð CDC: Breytingar eru dregnar úr viðskiptaskrá (transaction log). Þetta er oft skilvirkara og nær sannleikanum, en krefst vandaðrar stillingar því varðveisla logs, afritun og viðhaldsvinna öðlast beinan áhrif á samþættingu.

Mikilvægt fyrir stjórnendur: CDC er ekki „kveiktu á einu sinni“. Þið þurfið að fylgjast með seinkun, skilgreina endursamstillingarferla (t.d. uppbyggingu einstakra tafla) og ákvarða hversu lengi breytingasaga er vistuð í áfangastað.

Hvað CDC gerir sérstaklega vel

  • Minnkar þörf á heildarúttökum: Eftir upphaflegan snapshot færa kerfið sig yfir í að senda aðeins deltur.
  • Hreinn aðskilnaður OLTP og Analytics: Skýrslugerð getur keyrt á sér gagnagrunni eða Data Warehouse án þess að leggja álag á ERP.
  • Tæknilega hlutlaus gagnaafhending: Niðurstreymisteymi geta endurtekið umbreytingaskref sjálfstætt.

Hagnýtt dæmi: CRM þarf á daglegum grunni að vita hvort viðskiptavinur eigi óuppfylltar afhendingar, án þess að keyra sífellt flókin fyrirspurnir í ERP. CDC speglar viðeigandi töflur eða Views inn í samþættingargagnagrunn; CRM les þaðan. Niðurstaða: færri álagstopp í ERP, og fyrirspurnir er hægt að indeksa markvisst.

Viðburðastreymi: Þegar ferlar þurfa að bregðast við – og þið takið ábyrgð

Verkabelte Verbindungen zwischen Systemen als Fotomotiv für Event Streaming und entkoppelte Konsumenten
Í viðburðastreymi ræður skilvirk villumeðhöndlun um stöðugleika ferilsins.

Viðburðastreymi er sérstaklega gagnlegt þegar þið viljið ekki bara afrita gögn heldur orkestrera viðbrögð ferla: stöðubreytingar, tilkynningar, fylgiverkefni og samþættingar við samstarfsaðila. Viðburður er „atburður sem hefur gerst“ – með tímapunkti, auðkennum og lágmarks nauðsynlegu samhengi.

Kostir viðburðastreymis

  • Aðskilnaður: Framleiðandi og neytandi þurfa ekki að vera tiltækir samtímis. Þetta minnkar viðkvæmni í viðhaldsgluggum.
  • Skalun yfir neytendur: Fleiri kerfi geta nýtt sama viðburð (t.d. CRM, sendingar, BI), án þess að ERP þurfi að afhenda sérhvert markmið sérstaklega.
  • Sýnileiki í flæði: Með góðri vöktun sjást gegnumstreymi, uppsöfnuð biðröð og villutíðni fyrir hvern neytanda.

Áhættur og algengar ranghugmyndir

  • „Wir schicken Events, dann stimmt die Datenqualität“: Viðburðir flytja einnig rangar stöður ef upstream-staðfestingar vantar. Gagnagæði er áfram faglegt ábyrgðarviðfangsefni.
  • Idempotens wird vergessen: Tvöfalt viðburðir eiga sér stað (retry, net, rebalancing). Neytendur verða að þola tvíverknað, t.d. með einstökum Event‑ID-um og „already processed“-athugunum.
  • Skema- og útgáfustjórnun: Viðburðaskeyti eru viðmótasamningar. Án útgáfustjórnunar og áætlunar um afvikun myndast ringulreið, bara hraðar.
  • Röð er ekki sjálfgefin: Margir brokerar bjóða röð aðeins innan skilgreindra partitiona/lykla. Faglega þarf að vera ljóst hvaða lykill (t.d. pöntunar‑ID) tryggir röð.

Dæmigert senario: Í vörugeymslu er skráð útflutningur vara. ERP á að reikna, CRM á að uppfæra stöðu viðskiptavinar og rakningargátt á að útvega sendingarupplýsingar. Viðburðastreymi getur hreint aðskilið þetta. Ef hins vegar reikningagerð verður óhjákvæmilega að eiga sér stað fyrir stöðubreytingu, þarf annaðhvort ferilsamræmingu (t.d. Saga/Choreografie) eða skýrar reglur um hver er orkestratorinn. Annars geta stöður flogið/flökkt.

Aðstoð við ákvörðun: Hvaða nálgun hentar hvaða markmiði?

Í samþættingarverkefnum er röng grunnákvörðun dýr. Hagnýt flokkun:

Ef markmiðið ykkar er aðallega skýrslugerð og greining

  • Upphafspunktur: ETL eða ELT (hlaða fyrst, umbreyta síðar í áfangakerfinu) – með skýrum keyrsluáætlunum.
  • Þegar tímanleiki eykst: CDC sem gagnainntaka í Warehouse, ETL/ELT fyrir umbreytingu og módelbyggingu.
  • Ef markmið ykkar er rekstrarleg, tímanleg samstilling

    • Upphafspunktur: CDC fyrir tafla-/hlutaspeglun, auk léttvægra staðfestingar- og deilulausnaþjónustu.
    • Ef raunverulegar viðbragðskeðjur eru nauðsynlegar: Event Streaming, en aðeins með skilgreindu ownership og rekstrarlegri ábyrgð fyrir hvern neytanda.

    Ef markmið ykkar er ferlasamþætting milli ERP/CRM/birgðageymslu

    • Upphafspunktur: Event Streaming eða skilaboðamiðuð samþætting, bætt með bakrásum (Acknowledgements) og villuferlum.
    • ETL hér aðeins fyrir hliðarrennsli (t.d. daglegir samræmingar, skjalasafn, BI), ekki sem kveikja fyrir rekstraraðgerðir.

    Mikilvægt: Í raunveruleikanum er sjaldan um „annaðhvort‑eða“ að ræða. Margar stöðugar arkitektúrur sameina: Events fyrir ferla, CDC fyrir gagnauppfærslu og ETL/ELT fyrir skýrslugerðarmódel.

    Arkitektúr‑afleiðingar sem þið ættuð að skýra snemma

    Gagnaforræði og spurningar um Golden Record

    Hver má breyta hverju? „Golden Record“ er faglega gildur gagnapunktur fyrir hlut (kúnni, vara, pöntun). Ef mörg kerfi skrifa þarf skýrar reglur um árekstra: forgangsreglur, handvirk úrlausn eða MDM‑lausnir (Master Data Management). Án slíkra reglna verður samþætting sífellt „af hverju eru gögnin mismunandi?“‑mál.

    Villumeðhöndlun sem hluti af hönnuninni, ekki sem eftirvinnsla

    Hvort sem ETL, CDC eða Event Streaming: þið þurfið skilgreindar villuflokkar. Sannarlega gagnlegt er að skipta þeim í þrjá flokka:

    • Tæknilegar villur (Timeout, netverk, tímabundnar læsingar): sjálfvirk endurtilraun með backoff.
    • Merkingarvillur (skyldureitur vantar, óþekktur stöðustaður): í Quarantäne/Dead‑Letter, með möguleika á að kasta málum yfir í ticket‑kerfi.
    • Ferlaátök (röð brotin, tvöföld bókun): faglegur úrlausnargangur, oft með handvirkri ákvörðun.

    Án Quarantäne‑mekanisma endið þið í „samþættingin keyrir græn, en einstaka tilfelli vantar“. Það er fljótlegasta leiðin í gagnagröfina, því enginn veit lengur hvaða gagnastaða sé „sannur“.

    Yfirsýn, viðvörunarkerfi og rekjanleiki

    Fyrir IT‑stjórn og rekstur skipta skýrar spurningar máli: Hversu mörg gagnaskrár/atburðir á klukkustund? Hversu stórt er uppsafn? Hvaða tengi veldur flestum endurtilraunum? ETL þarf keyrslumonitorun (upphaf/endi, fjöldi raða), CDC þarf lag‑mæliniðurstöður, Event Streaming þarfnast consumer‑lag og Dead‑Letter‑hlutfalla. Þess til viðbótar þurfa loggar með tengingarkóðum (t.d. pöntunarnúmer) svo stuðningsmál endi ekki í skjámyndum.

    Öryggi og samræmi: Afrit gagna eru ábyrgð

    Samþætting framleiðir afrit. Afrit þýða nýja árásarflöt og nýjar varðveislu‑spurningar. Dæmigerð atriði sem koma of seint upp í verkefnum:

    • Least Privilege: ETL‑ og CDC‑reikningar ættu aðeins að geta lesið það sem nauðsynlegt er. Fyrir Event‑framleiðendur/neytendur skulu þjónustureikningar með lágmarksréttindum vera skylda.
    • Secrets‑Handling: Lykilorð í skriptum eða Task Scheduler eru klassík. Betra er miðstýrt Secrets‑management eða að minnsta kosti hreinn snúningur og endurskoðun.
    • DSGVO und Löschung: Þegar í ERP er eytt eða læst þarf skýrt að skilgreina hvað gerist í DWH/Data Lake/Stream. CDC þarf að fanga eyðingaratburði, ETL þarf eyðingar‑ eða nafnleysingar‑lógík.
  • Rekjanleikaskrár: Fyrir gagnrýna ferla getur verið mikilvægt hver, hvenær og hvaða stöðu var breytt. Þessar upplýsingar má ekki fjarlægja við umbreytingar í nafni hagræðingar.
  • Útbýting og flutningur: hvernig forðast þú Big-Bang-innleiðingar

    Tómísk mynd af stigvaxandi útbreiðslu með piloti, samhliða rekstri og yfirfærslu
    Stigvaxandi útbreiðsla með samhliða rekstri dregur úr áhættu og auðveldar samþykkt.

    Sérstaklega hjá vöxnum ferlum er stigvís yfirfærslan stöðugri. Hagnýt framgangsmáti:

    1. Kortleggja: Hvaða gagnastraumar eru til (þ.m.t. Excel, SFTP, beinir DB-aðgangar)? Hvaða eru ferlakritískir?
    2. Stöðugur markástandur fyrir hvern svið: t.d. „birgðastaða kemur úr WMS, stöða pantana úr ERP, viðskiptasamskipti úr CRM“.
    3. Samhliða rekstur með samstillingu: CDC/ETL keyra upphaflega í „shadow“ ham; niðurstöður eru bornar saman við fyrri stöðu (delta-skýrslur, úrtök).
    4. Cutover með möguleika á afturhvarfi: Fyrir rekstrarlegar samþættingar: skipta yfir á Event/CDC-gjafa, en með skýru afturfallsstigi (t.d. read-only fyrirspurnir eða tímabundinn batch).
    5. Hreinsun: Slökkva á gömlum jobbum, fjarlægja aðganga, festa skjölun og ábyrgðaraðila. Án þessa skrefs verður gagnagröf áfram til staðar, bara með nýrri skrauti.

    Mikilvægt er að stilla væntingar: Ein samþætting er aldrei „búin“. Nýir reitir, nýir ferlar, nýjar staðsetningar – allt hefur áhrif á gagnastrauma. Vel heppnuð teymi skilgreina því viðhaldsstillingu: útgáfustjórnun, prófanir, samþykktir, aðlögun vöktunar.

    Niðurlag: Gagnasamþætting án gagnagröf krefst tækni – og skýrleika í rekstri

    ETL er áfram traust tæki fyrir reporting, svo lengi sem þið hafið stjórn á keyrsluáætlunum, gagnasamningum og stækkun batch-glugga. CDC er oft pragmatísk leið til uppfærðs gagnastigs, léttir á kerfum sem eru uppspretta og skapar skýra aðgreiningu milli OLTP og greiningar. Event Streaming er öflugt þegar ferlar þurfa að bregðast við og mörg kerfi nýta atburði – en krefst þá stöðugs bilanastjórnunar, útgáfustjórnunar og ábyrgðar fyrir hvern neytanda.

    Í framkvæmd er ekki ákvörðunarspurningin „víða tækni er nútímaleg“, heldur: Hvers konar töf (latenz) og áreiðanleika þurfa ferlarnir okkar – og hvaða rekstrargetu getum við borið til lengdar? Ef þetta er skýrt snemma er hægt að byggja samþættingar þannig að þær vaxi án þess að rotna.

    Ef þið viljið uppbyggilega uppfæra samþættingar milli ERP, CRM og birgðakerfis – innifalið rekstrarhönnun, gagnasamninga og flutningsstefnu – hafið samband við okkur:

    Fyrir þetta efni eru einnig Change Data Capture (Cdc) og ERP-samþætting mikilvæg. Greinin setur þessa þætti í skiljanlegt samhengi og sýnir hvað skiptir máli í daglegu starfi.

    Ræddu verkefni eða endurnýjunarverkefni með Net-Base.

    Næsta skref

    Ef efnið verður að raunverulegu verkefni, ætti snemma að skoða kerfisarkitektúr, núverandi kerfi og rekstur í sameiningu.

    Við styðjum ekki aðeins við einstakar spurningar, heldur einnig þegar úr kóðabútum, eldri kerfum eða gáttahugmyndum þarf að verða traust fyrirtækjaverkefni.

    • Núverandi staða, markmynd og tæknileg áhætta eru metin saman.
    • REST, aðgangur að gögnum, gáttir og innleiðing verða ekki flutt til síðari tíma sem afleiðingar.
    • Þú sérð snemma hvaða leið er efnahagslega og rekstrarlega framkvæmanleg.

    Deila færslu

    Deila þessari færslu beint

    LinkedIn, X, XING, Facebook, WhatsApp og tölvupóstur eru strax í boði. Fyrir Instagram undirbúum við tengil og stuttan texta strax.

    Tölvupóstur

    Instagram opnast í nýjum flipa. Tengill og stuttur texti eru afritaðir í klippiborðið á undan.