Valószínűleg már hallotta az állítást, hogy "az adat az új arany". Webináriumokon gyakori, az analitikai szoftverek értékesítői anyagaiban pedig már szinte kötelező elemként jelenik meg ez a mondat. Azt próbálják eladni Önnek, hogy 1) az adatok jelentik a választ minden kihívására, és 2) néhány egyszerű kattintás választja el attól, hogy a tökéletesen formázott adatok az Ön és vállalkozása érdekében működjenek. Sőt, azt mondják, hogy bárki meg tudja csinálni, nem szükséges széleskörű adat- vagy statisztikai ismeret, mert az önkiszolgáló üzleti intelligencia könnyedén elsajátítható / használható a laikus felhasználók számára is. Ön lehet üzletági alkalmazott, középvezető vagy akár C-szintű vezető: könnyedén létrehozhatja saját adatelemzéseit.... ez szinte túl szép, hogy igaz legyen, nem igaz?

Nos, ez sajnos nem ilyen egyszerű, ezért ezt részletezzük kicsit. A cikkben maradjunk az "adat az új arany" hasonlatnál, mivel nagyon jól illik ide, ahogy a következő bekezdésekben láthatjuk! Először is, azt állítjuk, hogy az adatok még nem aranyat érnek, legalábbis nem abban az értelemben, ahogyan azt szeretnénk. Az adat csak... hát, adat. Szűretlen, nyers, és gyakran túlságosan technikai jellegű az emberi szem számára. Hasonlóan az aranyhoz, az adatok kitermelés, finomítás, átalakítás, majd az emberekhez való eljuttatás nélkül nem fognak sok értéket teremteni a vállalkozás számára, nyers formában nagyon ritkán használhatók az üzleti felhasználóknak. Az adatok tehát inkább olyanok, mint az érc / a kőzet, amely tartalmaz némi aranyat, de nem valószínű, hogy Ön megvenne egy nagy darab követ, hogy az ujján viselje. Ideális esetben nem csak adatokra, hanem olyan üzleti megállapításokra (Business Insights) van szükség, amelyek megvalósíthatóak, pontosak, megbízhatóak és nagyon fontos, hogy az üzletág számára könnyen érthetőek legyenek, akár az informatikusok vagy adatmérnökök (Data Engineer) segítsége nélkül is. Ez az igazi arany, amit a cégek manapság keresnek.

Rendben, tehát nem egyszerűen adatokra, hanem üzleti megállapításokra van szükség, ezt nem lehet olyan nehéz megszerezni, igaz? Végül is, mit tesz Ön, ha aranygyűrűt vagy bármilyen arany ékszert szeretne vásárolni? Elmegy az aranybányába? Persze, hogy nem! Általában egy ékszerboltba megy, egy olyan helyre, ahol a termékeket már előkészítették, megtisztították, kategorizálták stb. Rendben, de az ékszerboltban meg akarja tudni a részleteket arról, hogy a kiválasztott aranygyűrű hogyan került oda, meg akarja ismerni a készítés során lejátszódó bonyolult kémiai reakciókat, például a ciánlúgozást, és alig várja, hogy olyan technikai információkat olvashasson, mint "75% Au, 25% Ag". Nem? Tapasztalataink szerint a legtöbb üzleti felhasználót nem érdeklik a kifinomult ETL / ELT (Extract, Transform, Load) folyamatok, az adattárház adatbázis technikai mezőnevei, sem pedig a vállalati adatfolyam szkript szintű részletei. Amit inkább értékelnek, az egy egységes réteg, a komplex adatok absztrakciója, ahol megbízható, tisztított és már modellezett mérőszámokat (KPI) találnak. Mérőszámokat, amelyek követik a vállalat üzleti működésének logikáját, és a bonyolult technikai neveket olyan általános üzleti kifejezésekre redukálják, mint a nettó nyereség, az általános költségek vagy az éves árbevétel-növekedés. Ön egyszerűen csak egy 18 karátos gyűrűt szeretne, és azt az érzést, hogy megbízhat az ékszer forrásában és minőségében anélkül, hogy ismernie kellene a mögötte lévő összes részletet és folyamatot.

Ezért egyetlen és(!) egyszerű igazságforrásra van szüksége (single and simple source of truth), ha úgy tetszik, egy ékszerboltra, ahová nem szakértő üzleti felhasználóként besétálhat, a gondolkodásához és a mindennapi terminológiájához illeszkedő mérőszámok és dimenziók alapján pedig megtalálhatja a keresett válaszokat. Ekkor lép a színpadra az univerzális szemantikus réteg (Universal Semantic Layer - USL)! De mi is ez egyáltalán? Bár nincs egyetlen legjobb definíció (ironikus módon), a Kyligence¹ blogbejegyzése elég jól összefoglalja, amikor kijelenti:

„A szemantikus réteg a technikai megvalósítási rétegből levezetett üzleti absztrakció - egy modellréteg, amely egységesen fenntartja az üzleti logikát.”

A Gartner egy 2020-as jelentésében⁶ kiemeli, hogy a mai összetett üzleti környezetben a cégek nehezen tudják megosztani adatállományaikat és kulcsfontosságú mérőszámaikat, ami aláássa a jelentéstételi rendszerek megbízhatóságát és fejlesztési sebességét. Ráadásul az adatok puszta mennyisége és sokfélesége miatt egyre nehezebbé válik a vállalati adatvagyon egységes, közös üzleti definíciókkal rendelkező platformjának fenntartása. Ez az egyes üzleti egységeknél/funkcióknál⁶ adatsilókhoz, kis elszigetelt jelentésszigetekhez vezet. A probléma az, hogy ha nincsenek közösen elfogadott és megosztott definíciók, akkor e silók mérőszámai nem lesznek összehasonlíthatóak a többi silóban képzett adatokkal. Ezt a jelenséget csak felgyorsítja a szervezetekben a többféle önkiszolgáló BI-eszköz (korábban már említettük) valamint offline elérhető jelentések jelenléte. Ugyanakkor a túl sok ellenőrzés és központosítás túlterhelt IT/BI részleghez és a fejlesztési idők növekedéséhez vezet, mivel a vállalat informatikai szakembereinek nem csak kapacitásproblémái lesznek, hanem a kifinomult jelentések gyors elkészítéséhez szükséges speciális üzleti ismeretek is hiányoznak.

Most már látjuk a kihívásokat. Foglaljuk össze, mielőtt megpróbáljuk leküzdeni őket. A mai kaotikus és gyorsan változó üzleti környezetben a cégek nehézségekbe ütköznek a BI és az analitika terén, mert:

• A vállalaton belül rendelkezésre álló adatvagyon sokféle és hatalmas mennyiségű
• Az adatok sok esetben technikai jellegűek, távol állnak a működési logikától ahhoz, hogy az üzleti felhasználók könnyen felhasználhassák őket
• A közös definíciók hiánya lassítja az üzleti egységek adatintegrációját, silókat hoz létre, ami megnehezíti az „egy igazság” megtalálását
• Az önkiszolgáló BI ellenőrizetlen használata aláássa az integrált vállalati szintű jelentéskészítést

Hogyan segíthet tehát egy univerzális (egész vállalaton átívelő) szemantikus réteg megoldani ezeket a problémákat? Kutatómunkánk során számos szemantikus réteg eszközt (valamint adatkatalógus- és metaadat-kezelési megoldást) megvizsgáltunk, a témával kapcsolatban több cikket feldolgoztunk, a legtöbb megoldással gyakorlatban is dolgozunk / dolgoztunk. Ezek alapján azonosítottuk az univerzális szemantikus rétegek 7 kulcsfontosságú képességét. Véleményünk szerint ezeknek a követelményeknek kell megfelelnie egy megoldásnak ahhoz, hogy (univerzális) szemantikus rétegnek nevezhessük. Most egyenként folytatjuk e kulcsfunkciókkal, és megnézzük, hogyan segítik az üzleti felhasználókat és a BI-részlegeket a fent említett akadályok leküzdésében, amelyek a szervezet jelenlegi működése és a kívánt adatvezérelt működés között állnak.

Egy univerzális szemantikus rétegnek képesnek kell lennie arra, hogy gyakorlatilag bármilyen általános adatforrásból, például relációs adatbázisokból, fájlokból, felhőalapú forrásokból vagy nagy adatfeldolgozó alkalmazásokból adatokat szerezzen. Ez azonban aligha új követelmény. A nagyobb BI-platformok már régóta képesek kielégíteni ezt az igényt, és az adatkapcsolatok listája folyamatosan bővül. Másrészről viszont eddig kevés olyan platform volt, amely lehetővé tette, hogy más BI-alkalmazások csatlakozzanak a szemantikus rétegeikhez (ha egyáltalán rendelkeztek ilyennel). Ez érthető a BI-szállítók szemszögéből, akik valószínűleg nem szeretnék, ha a versenytársak front-end dashboardjai csatlakoznának a modelljükhöz. Egyes BI-platformok, mint például a MicroStrategy vagy az Oracle BI hajlandóbbak megnyitni "beépített" szemantikus modelljeiket más analitikai eszközök, például a Tableau, a Qlik stb. számára. Így a különböző dashboard eszközök egyetlen központilag menedzselt adatmodellhez kapcsolódhatnak. Megkülönböztetjük ezeket a megoldásokat az olyan független szemantikus réteggyártóktól, mint az AtScale, amelyek nem rendelkeznek saját front-enddel. Ezek a "független" cégek kizárólag a szemantikai és virtuális modellezési részre összpontosíthatnak, és arra törekednek, hogy terméküket minél több dashboard- és analitikai alkalmazással használhatóvá tegyék. Összefoglalva, egy univerzális szemantikus réteg legnagyobb hozzáadott értéke a kapcsolódás szempontjából az, hogy szükség esetén több (szinte minden) alkalmazással is össze tud kapcsolódni, miközben minden hozzá kapcsolódó alkalmazás számára ugyanazt a szemantikai modellt és adatokat biztosítja.

Alkalmanként egy központi adattárház (Data Warehouse - DWH) képes összegyűjteni az összes vállalati adatot, és egyetlen forrásként szolgálhat a jelentéstételhez; gyakrabban azonban számos és változatos forrás létezik, ahol adatvagyonunkat létrehozzák és tárolják. Az ERP, a CRM, az IoT-érzékelők adatai és sok más típusú forrás lehet szétszórva a cégen belül felhős vagy telepített (on-premise) rendszerekben. De mi történik például akkor, ha a gyártóüzem hatékonyságára vonatkozó komplex elemzést szeretnénk látni, amely az ERP-ből származó költségadatokat és a gyári sorszenzorok IoT-adatait foglalja magában? Nos, még ha a minket érdeklő rendszerek önmagukban jól megalapozottak és koherensek is, nagy az esélye annak, hogy egymáshoz képest jelentős különbségeket mutatnak. Lehet, hogy az azonos üzleti jelentéssel bíró adattípusok vagy mezőnevek különböznek, például ami "Factory_Line_ID" az egyik forrásban az "lineID" a másikban. Vagy az is lehet, hogy az adatok aggregálásának szintje eltér, például: a költségadatok csak napi vagy havi szinten állnak rendelkezésre, míg Önnek közel valós idejű érzékelőadatai vannak. E problémák megoldásához és az összes adat közös nevezőre hozásához a szemantikus rétegnek kifinomult modellezési képességekkel kell rendelkeznie, beleértve a JOIN, UNION operátorokat a különböző forrásokból származó adatok kombinálásához, valamint olyan transzformációs függvényekkel, amelyek segítenek az azonos jelentésű, de a forrásokban eltérő megnevezésű attribútumelemek összekapcsolásában. A megoldásunknak nemcsak fejlett virtuális modellezési képességekkel kell rendelkeznie, hanem rugalmasnak is kell lennie, hogy gyorsan alkalmazkodni tudjon a változó üzleti szabályokhoz vagy az újonnan integrált adatforrásokhoz. Ha a modellparaméterek és könnyen módosítható feltételek helyett sok „beégetett” változót tartalmaz, akkor azt kockáztatjuk, hogy egy nehezen karbantartható vagy továbbfejleszthető megoldást építünk. Az univerzális szemantikus réteg tehát azért előnyös, mert a felhasználók több forrásból, de modellezett és konszolidált módon férhetnek hozzá az adatokhoz.

BI-tanácsadási tapasztalataink alapján az egyik leggyakoribb kihívás, amikor egy partnercég BI-környezetét értékeljük, hogy kiderítsük, mit jelentenek és hogyan számítjuk ki a használatos mérőszámokat. Ami azt illeti, ez nem csak a külső felek számára jelent problémát, hanem gyakran az adott vállalatnál ténylegesen dolgozó emberek is nehezen tudják kitalálni, hogy mit is jelent valójában az 5,4%-os "YoY_oper_profit_var_dw2" a jelentésben. Ez a következő tényezőknek tudható be:

• A mérőszám kalkulálásokat gyakran különböző emberek és részlegek végzik eltérő időben, és minden alkalommal fennáll az esélye annak, hogy nem sikerül tökéletesen megismételni a számítási logikát
• A robusztusabb BI-környezetekben több száz mérőszám van, és egyszerűen nehéz nyomon követni őket valamilyen adat-szótár nélkül
• Az elszigetelt működés a mérőszámok üzleti egységek közötti elszigetelt meghatározását jelentheti (ha nincs közös platform az üzleti szabályok megosztására)
• Az objektumok technikai neveinek használata (amelyek az adattárházból vagy tranzakciós forrásokból származnak) megnehezítik az üzleti felhasználók számára az adatok megértését, mivel ezek a mezőnevek nem feltétlenül írják le az általuk lefedett üzleti fogalmakat / logikákat

Egy univerzális szemantikus réteg enyhíti ezeket a problémákat egy olyan közös platform létrehozásával, ahol a mérőszámok minden definíciója és számítása átlátható. Az objektumok a fizikai forrásuk helyett az üzleti jelentőségük alapján csoportosíthatók definíciós mappákba. Továbbá a mérőszámok és dimenziók elnevezési konvenciója az univerzális szemantikus rétegben az üzletmenet és nem a tárolórendszerek elnevezési konvencióit követi. A szemantikus rétegünk a mindennapi üzleti kifejezések, objektumleírások és alias-nevek használatával a végfelhasználók számára ismerős definíciókra fordítja le a komplexitást.

Tehát ehelyett:    YoY_oper_profit_var_dw2”

Ezt kapjuk:           Mérőszám neve: “Year-over-Year Operating Profit Change”
                              Definíció: A működési eredmény összehasonlítása az előző év azonos időszakával
                              Egység: %
                              Képlet: (([Actual Op Profit] – [Last Year Op Profit]) / [Last Year Op Profit]) * 100

Ez nyilvánvalónak tűnhet, mégis nagyon sok ellenpélda van, amit a vállalati BI-környezetekben látunk. Ugyanazon dolgok többszöri megépítése, ugyanazon KPI négy különböző ember által történő négyszeri létrehozása növeli az objektumok számát, a redundanciát, végül növeli a hibázás esélyét a folyamat során. Képzeljük el tehát Erikát, a szervezet egyik elemzőjét, aki egy csodálatos üzleti mérőszámot készített, ahol minden stimmel, a számok jók, a számítás hatékony. Sajnos ezt a számítást egy adott jelentésen belül végezte el, és nem egy központi tárolóban, ahol mások számára is elérhető lenne. Ezért 3 hónappal később, amikor Róbertnek, egy másik elemzőnek szüksége van egy ilyen mérőszámra, nem tudva a korábbi létezéséről, kidolgozza azt; ismét csak a saját BI jelentésében. Felismeri itt a kockázatokat és a hatékonysági hiányosságokat?

• A mérőszám kalkulációját újra ki kellett találni, ami időt vesz igénybe, ami költségeket jelent
• Semmi sem garantálja, hogy a két mérőszám ugyanazokat az eredményeket adja, mivel különböző forrásokat vagy különböző számítási módszereket használhatnak.

Egy univerzális szemantikus réteg csökkenti ezt a kockázatot azáltal, hogy az objektumokat egy központi, mindenki számára elérhető platformon tartja, így azok nem csak egy, hanem számos jelentésben felhasználhatók, ezáltal pedig csökken a fejlesztési idő. Ezenkívül biztosítja, hogy minden közzétett BI-tartalom ugyanazokat a definíciókat és képleteket használja, mivel maguk az objektumok (a jelentések építőkövei, mint például a dimenziók, mérőszámok, szűrők stb.) technikailag azonosak. Matthew Baird, az AtScale CTO-ja ezt mondta:

“Bizonyos szintű absztrakció nélkül az üzlet az IT-nek van alárendelve, hogy jelentéseket generáljon és futtasson, különben nagy, költséges, és ami a legrosszabb, rejtett hibákat követhet el. Megengedheti magának, hogy minden egyes alkalmazottja egymástól függetlenül próbáljon helyesen lemásolni egy logikát a táblázataikban és jelentéseikben?”

Mindent egybevetve, az újrafelhasználhatóság nem csak a hatékonyságról, hanem a pontosságról és a következetességről is szól. Gondoljon csak bele, mennyire frusztrált lenne, ha az egyik értékesítési jelentésében 42 millió, a másikban pedig 44,5 millió szerepelne! Lehet, hogy ez egy jogos különbség, de feltehetően néhány C-szintű vezetőben ez némi kétséget ébresztene a vállalat BI-rendszerének hitelességével kapcsolatban.

Kinek van joga látni a számainkat? Tudjuk a felhasználóknak csak azokat az adatokat mutatni, amelyek a munkájukhoz szükséges? De mi van akkor, ha a "szükséges" felhasználóról felhasználóra eltérő? Kinek kellene tudnia egyáltalán megnyitni a jelentéseinket?

Hasonló kérdések előbb-utóbb felmerülnek, ha egy vállalat elér egy bizonyos analitikai érettséget és / vagy BI-tartalom mennyiséget. Jó hír, hogy egy univerzális szemantikus réteg nagyban hozzájárulhat egy központosított, de rugalmas jogosultságkezelési rendszer kialakításához. Mint már említettük, a nagyvállalatoknál számos olyan alkalmazás és üzleti intelligencia eszköz lehet, amely a vállalat adatvagyonát használja. A felhasználói hozzáférési jogok korlátozása az egyes eszközökben egymástól függetlenül bonyolult és fenntarthatatlan irányítási modellt eredményezhet. Ha azonban az említett platformok által használt adatok egy központi virtuális modellben vannak, akkor az adatfelhasználás ezen egyetlen központi tárolóból ellenőrizhető. Ha bizonyos mérőszámokat vagy adatkészleteket el akarunk "rejteni" bizonyos felhasználók elől, vagy ha sorszintű biztonságot (Row Level Security, RLS) szeretnénk alkalmazni (az emberek ugyanazt az adatkészletet, de annak különböző szegmenseit lássák) a szemantikus réteg segíthet a szervezetnek ebben.

Egy egyszerű példa, hogy a pénzügyi adatkészlet és annak mérőszámai csak a pénzügyi osztály és a C-szintű vezetők számára legyen hozzáférhető. Ezt úgy lehet elérni, hogy csak ezeknek a felhasználóknak adunk hozzáférést, vagy létrehozunk egy új felhasználói csoportot ezeknek az embereknek a szükséges hozzáféréssel, miközben minden más felhasználót kihagyunk a csoportból.

De mi van akkor, ha kifinomultabb jogosultságkezelési követelményeink vannak? Képzeljük el, hogy van egy részletes értékesítési adatállományunk, amely számos releváns mérőszámot tartalmaz minden üzleti régióra vonatkozóan! Szeretnénk, ha a felsővezetés az összes régió értékesítési jelentését láthatná, de a regionális vezetők csak a saját régiójuk adataihoz férhetnének hozzá. Hozzunk létre több fókuszált adathalmazt és jelentést, hogy azokat a különböző vezetők rendelkezésére bocsássuk? Nem, ez nem lenne sem hatékony, sem fenntartható. Több objektumot használnánk, és a jelentés vagy az adatszerkezet bármilyen változását több adatkészletben kell kezelni, ami erőfeszítést igényel, és nagyobb teret enged a hibáknak. Ehelyett elég egy adatkészlet és egy jelentés, ha magára az adatra sorszintű biztonságot alkalmazunk az univerzális szemantikus rétegben. Ily módon a régió dimenzió dinamikus szűrőként működik, amely a jelentés megnyitásától függően kerül alkalmazásra. Ha a pénzügyi igazgató nyitja meg, akkor minden régió összes adata elérhető, de ha a déli régió vezetője nyitja meg, akkor csak a déli régió értékesítési adatai jelennek meg. Mindezt egy helyen, az univerzális szemantikus rétegben szabályozzuk, így nem számít, hogy milyen jelentés helyezkedik el rajta.

Természetesen senki sem szereti a lassú jelentéseket és a hosszú betöltési időket; ezért a szemantikus rétegek biztosítják, hogy minden jelentés és adatállomány frissítése optimalizálva legyen a lekérdezés szintjén. Mint már említettük, a szemantikus rétegek egyik fő erőssége, hogy több adatforráshoz is csatlakozik, majd ezeket integrált logikai modellekbe rendezi. Így amikor ezek a logikai modellek olyan kérést kapnak, hogy egy olyan adatkészlet szükséges, amely pénzügyi adatokat tartalmaz az ERP-ből és néhány műveleti adatot egy másik adathalmazból, a szemantikus rétegnek SQL vagy SQL-szerű lekérdezést kell indítania ezekhez a forrásrendszerekhez. Ez a lekérdezés állítja össze a nekünk szükséges összetett adathalmazt, hogy azt a jelentéseinkben felhasználhassuk. Mivel az adatforrások heterogének, összetett lekérdezés szükséges, hogy az összes adatot a megfelelő szűrési feltételekkel, megfelelő aggregációs szinten és erőforrás-igényes JOIN feltételekkel összehozzuk; ezért fontos, hogy mindez gyorsan és költséghatékony módon történjen.

Ezt többféleképpen lehet elérni, az egyszerű lekérdezés-optimalizálástól kezdve (bizonyos kevésbé erőforrás-igényes műveletek előnyben részesítése másokkal szemben) egészen a gépi tanulás vezérelte optimalizálásig, amely elemzi a forrásokat és a jelentésfogyasztók használati mintáit, hogy a frissítéseket okosabbá és gyorsabbá tegye.

Végezetül az univerzális szemantikus rétegnek az adatvagyon átláthatóság nagyköveteként kell fellépnie. A közös és központi definíciók megléte csak a munka egyik fele. Az embereknek meg kell bízniuk ezekben a mérőszámokban, szűrőkben és dimenziókban, mielőtt használni tudnák őket. Egy jó szemantikai réteg tehát két kritériumnak felel meg, hogy lehetővé tegye a bizalmat és az átláthatóságot:

• Naplóz minden olyan eseményt és műveletet, amely az adatobjektumokat érinti. Ha egy mérőszám számítási módja megváltozik, napló készül. Ha egy dimenzió új aliast kap, napló készül. Ha a "Termékcsalád" dimenzióobjektumot "Termékkategória"-ra nevezik át, napló készül. Fontos megmutatni az üzleti felhasználóknak, hogy a változások nyomon követhetők, így olyan rendszert kapnak, amelyben az adminisztrátorok és egyéb módosítók felelősek a sémában végzett saját műveleteikért.
• Az adatfolyam követése segít bármely objektumot nyomon követni a függő objektumokig és komponensekig. Ha egy jelentést nézegető menedzserben felmerül a "Honnan származik ez a szám?" kérdés, létfontosságú, hogy a számadat könnyen visszakövethető legyen egészen az eredeti forrásáig.

Egy olyan nagyvállalati BI-környezetben, ahol több elemzési eszköz, adatforrás és mérőszám van jelen, az ilyen típusú átláthatóság lehetővé teszi az adatfogyasztók számára, hogy megbízzanak a számokban, ugyanakkor segíti az elemzőket és a tartalomkészítőket abban, hogy megértsék és újra felhasználják saját és egymás munkáját.

Tehát, működhet-e a vállalati BI univerzális szemantikus réteg nélkül? Igen, működhet. Erre számos példát láttunk már. Az embereknek azonban szem előtt kell tartaniuk, hogy egy bizonyos komplexitás és méret meghaladása után (ez hazai szinten is abszolút értelmezhető, és nem csak a legnagyobb hazai vállalatoknak) egyre nehezebbé válik a konzisztencia és a rend fenntartása egy ilyen BI-környezetben. Egy jó, egész vállalatot átfogó szemantikus réteg kiépítése nyilván átgondoltságot, időt és költségeket igényel, de ez minden másra is igaz. Véleményünk szerint nincs sok értelme hatalmas összegeket költeni adatbázisokra és front-end eszközökre, ha az eredmény nem felhasználóbarát és nem bízik meg benne a szervezet. Tehát érdemes rászánni a plusz erőforrást, és beletenni a BI kirakósunkba az utolsó puzzle-darabkát is! Ha helyesen hajtjuk végre, egy univerzális szemantikus réteg áthidalhatja a szakadékot az üzlet és a technológia között, így mindenki profitál belőle. Ne felejtse el (még ha most nem is egyértelmű): amire szüksége van, az nem nyers arany a bányából, hanem egy minőségbiztosított és finomított ékszer, egy minőségbiztosított és finomított Business Insight!