דאטה AI משנה את הדרך שבה ארגונים שואלים שאלות על הנתונים שלהם. מה נדרש כדי לקבל תשובות נכונות?
לפני כמעט עשר שנים כתבתי מאמר בשם "מגמות בתחום בינה עסקית 2017/8". באותה תקופה דיברנו על Big Data, על מעבר לענן, על Self Service BI, על Machine Learning, על Embedded BI ועל המעבר ההדרגתי מדוחות סטטיים לכלי אנליזה אינטראקטיביים. חלק גדול מהדברים שנראו אז כמו העתיד הם היום פשוט חלק מהתשתית.
בשנת 2027 השינוי הבא בעולם הדאטה AI כבר כאן. והפעם השינוי משמעותי הרבה יותר.
אנחנו עוברים מעולם של Business Intelligence לעולם של Data AI – עולם שבו המשתמש לא בהכרח פותח דשבורד, מחפש פילטר ובונה Pivot. הוא פשוט שואל שאלה.
"מה קרה למכירות באזור הצפון בשלושת החודשים האחרונים?" "למה הרווחיות ירדה?" "אילו לקוחות נמצאים בסיכון נטישה?" "מי מחמשת אנשי המכירות השתפר הכי הרבה לעומת השנה שעברה?" ובתוך שניות הוא מצפה לקבל תשובה, הסבר, טבלה ולעיתים גם גרף. זה נשמע פשוט.
הטכנולוגיה שמאחורי זה ממש לא פשוטה.
ה-AI כבר מספיק טוב. הבעיה היא הדאטה
ההתפתחות של ChatGPT, Claude ומודלים מתקדמים אחרים שינתה לחלוטין את הדרך שבה אנשים מצפים לעבוד עם מערכות מידע. מי שהשתמש בכלים האלה בשנים האחרונות יודע עד כמה הם השתפרו.
הם יודעים לכתוב SQL, לנתח קבצי Excel ו-CSV, לזהות מגמות, לייצר גרפים, לכתוב קוד Python, להסביר תוצאות ולבצע ניתוחים שבמשך שנים דרשו אנליסט.
כלים כמו Julius בנויים מלכתחילה סביב הרעיון הזה: מעלים או מחברים מידע, שואלים שאלות בשפה רגילה, והמערכת יודעת לבצע ניתוח, לייצר ויזואליזציות ואפילו לבצע מודלים סטטיסטיים ו-Machine Learning. כלומר, מבחינת יכולת החשיבה והניתוח, עברנו דרך ארוכה מאוד. אבל כאן מגיע ה"אבל" הגדול.
AI יודע לנתח מידע טוב מאוד כאשר המידע שמונח לפניו מסודר, מוגדר ומובן.
וזו בדיוק הנקודה שבה המציאות הארגונית מתחילה להסתבך.
לחבר את ChatGPT ישירות ל-ERP? לא כל כך מהר
רעיון שאני פוגש לא מעט הוא: "יש לנו בסיס נתונים. למה שלא נחבר אליו Claude או ChatGPT ופשוט ניתן למנהלים לשאול שאלות?" ברמת הדגמה זה יכול לעבוד מצוין. יש טבלה בשם Sales. יש CustomerID. יש Amount. מבקשים: "תן לי מכירות לפי חודש." ה-AI כותב SQL ומחזיר תשובה. קסם.
עכשיו נעבור לארגון אמיתי. יש 350 טבלאות. יש ORDERS, ORDER_LINES, INVOICE, INVOICE_LINES, CUSTOMERS, CUSTOMERS_OLD, CUSTOMERS_NEW, ITEMS, ITEMS2. בחלק מהטבלאות סכום העסקה כולל מע"מ. באחרות לא. זיכוי מופיע בסכום שלילי במערכת אחת ובסוג מסמך נפרד במערכת אחרת. ללקוח יש שלושה מזהים שונים.
חלק מהעסקאות נחשבות הכנסה ביום ההזמנה, אחרות ביום החשבונית ואחרות ביום אספקת המוצר. ואז שואל המנכ"ל: "מה היו ההכנסות שלנו החודש לעומת שנה שעברה?" איזו טבלה היא הנכונה? מהי בכלל "הכנסה"? האם כוללים ביטולים? האם כוללים מע"מ? מה קורה עם עסקאות בין חברות בקבוצה?
באיזה תאריך משתמשים? כאן כבר לא מדובר בבעיה של SQL. מדובר בבעיה של הבנת העסק. ולכן, לדעתי, הניסיון לחבר כלי AI בצורה ישירה למאות טבלאות של מערכת ERP, CRM, מערכות תפעוליות ו-API שונים ולצפות שהוא "יבין לבד את העסק" – ברוב הארגונים המורכבים נדון לכישלון. המודל יכול להיות גאון.
אבל אם לא הסברנו לו מה הנתונים אומרים, הוא בסך הכול גאון שמסתכל על אלפי עמודות עם שמות מוזרים.
דאטה AI והשכבה החשובה ביותר של 2027: השכבה הסמנטית
כאן נכנס אחד המושגים שלדעתי ישמעו הרבה יותר בשנים הקרובות:
Semantic Layer – שכבה סמנטית.
במילים פשוטות, השכבה הסמנטית היא המקום שבו אנחנו מתרגמים את בסיס הנתונים לשפה העסקית של החברה. אנחנו אומרים למערכת: זה לקוח. זו מכירה. כך מחשבים הכנסה. כך מחשבים רווח גולמי. אלה הקשרים בין טבלת הלקוחות, החשבוניות והמוצרים. כאשר מנהל אומר "השנה", הכוונה היא לשנת הכספים הזאת.
כאשר מנהלת השירות אומרת "לקוח פעיל", זו ההגדרה העסקית שלו. במקום שכל דשבורד, אנליסט או מערכת AI ימציאו מחדש את הנוסחה, מגדירים אותה פעם אחת. זה לא רעיון חדש לחלוטין. גם מערכות BI ותיקות השתמשו במשך שנים בשכבות מטא-דאטה ומודלים עסקיים.
אבל AI הופך את השכבה הזאת ממשהו ש"טוב שיהיה" למשהו קריטי. גם dbt, לדוגמה, מציגה כיום Semantic Layer שמרכזת הגדרות של מדדים ולוגיקת חיבורים כך שכלי צריכה שונים יעבדו עם אותן הגדרות עסקיות. והגישה הזאת נמצאת בלב כלים חדשים יותר.
Credible Data, לדוגמה, בנויה סביב הרעיון שקודם מגדירים את המשמעות של הדאטה – הגדרות, מדדים וקשרים – ורק לאחר מכן מאפשרים לדשבורדים, אפליקציות וסוכני AI לצרוך אותו. המודלים שלה מבוססים על Malloy וניתנים לניהול כקוד.
גם ThoughtSpot מדגישה כיום Semantic Layer כחלק מהבסיס שעליו פועל סוכן האנליטיקה שלה, ולא גישה שבה נותנים למודל שפה פשוט "לנחש SQL" על בסיס בסיס הנתונים הגולמי. בעיניי זה אחד השינויים החשובים ביותר בעולם הדאטה AI.
ה-AI לא מבטל את הצורך במידול הנתונים. הוא דווקא הופך אותו לחשוב יותר.
הדור החדש: AI Native Analytics
לצד מערכות ה-BI המוכרות נוצר דור חדש של מוצרים שבהם ה-AI איננו תוסף למערכת. הוא הממשק המרכזי שלה. במקום להתחיל מדשבורד ולשאול "איזה פילטר אני צריך?", מתחילים משאלה. Julius, לדוגמה, מאפשר למשתמש לשאול שאלות על נתונים, לבצע ניתוחים, לייצר גרפים ואף לבצע חיזוי ומודלים דרך ממשק שיחתי.
ThoughtSpot הולכת בכיוון דומה עם Spotter – סוכן אנליטי שמאפשר לחקור נתונים בשפה טבעית, תוך הישענות על שכבה סמנטית ומודלים ארגוניים. Credible Data לוקחת את הנושא צעד לכיוון התשתיתי יותר: לא רק לשאול שאלות, אלא לנסות ליצור בסיס משותף שבו אותה משמעות עסקית משרתת גם AI, גם דשבורדים וגם אפליקציות.
ויש גם פתרונות מקומיים וממוקדים יותר, כמו Simm.AI, שמאפשרת לשאול שאלות עסקיות דרך Chat ואף דרך WhatsApp, ומדגישה אפשרות לעבודה בסביבת הלקוח ללא העלאת המידע לענן. המשותף לכולם הוא שינוי בתפיסה.
פעם בנינו מסך ואז ביקשנו מהמשתמש ללמוד לעבוד איתו. עכשיו אנחנו רוצים שהמערכת תלמד להבין את המשתמש.
ומה קורה לכלי ה-BI המסורתיים?
הם כמובן לא נעלמים. להפך. Power BI, Yellowfin, Metabase ומוצרים אחרים מוסיפים יכולות AI במהירות. Microsoft מאפשרת כיום להשתמש ב-Copilot בתוך Power BI כדי לסייע ביצירת דוחות, לסכם מידע, לכתוב DAX ולעבוד גם מול המודל הסמנטי.
Yellowfin הוסיפה Natural Language Query מבוסס AI ובהמשך הרחיבה אותו לממשק Conversational Analytics שבו ניתן לשאול שאלות המשך, לשמור הקשר ולהפוך את התוצאה לדוחות ו-Stories.
Metabase מציעה כיום Metabot, שיכול לענות על שאלות, ליצור גרפים ולנתח ויזואליזציות. היא גם מאפשרת להטמיע Chat באפליקציה, ואף מספקת MCP Server שמאפשר לכלי AI חיצוני להתחבר ל-Metabase בהתאם להרשאות של המשתמש. כל אלה התפתחויות משמעותיות מאוד. אבל צריך להבין את ההבדל.
מרבית כלי ה-BI נבנו במקור בתקופה שבה מרכז העולם היה דוח ודשבורד. ועכשיו מוסיפים להם שכבה שיחתית ו-AI. זה לא בהכרח דבר רע. למערכות האלה יש יתרונות עצומים: הרשאות, ניהול משתמשים, דוחות, הפצה, Embedded Analytics, Governance וניסיון של שנים.
אבל הארכיטקטורה הבסיסית שלהן שייכת לעולם שקדם למהפכת ה-Generative AI. ועד כמה שזה נשמע מוזר – בעולם הטכנולוגיה של היום לפעמים מוצר שתוכנן לפני שלוש או ארבע שנים כבר תוכנן בעולם אחר. לכן בשנים הקרובות נראה לדעתי שילוב של שני העולמות. הדשבורד לא ייעלם. אבל לידו יהיה Chat.
ולעיתים בכלל נתחיל ב-Chat ורק כאשר נרצה לעקוב אחר מדד באופן קבוע נבקש מהמערכת: "שמור לי את זה כדשבורד."
ומה קורה מאחורי הקלעים? מהפכת ה-ELT
אם בחלק הקדמי אנחנו עוברים מגרפים לשיחה, מאחורי הקלעים קורה שינוי לא פחות מעניין. במשך שנים עולם ה-ETL נע לכיוון כלים ויזואליים. Talend, Pentaho וכלים רבים אחרים אפשרו לבנות תהליכים באמצעות Drag & Drop. מחברים Input. גוררים Transformation. מחברים Output. וזה עבד – ועדיין עובד – במערכות רבות.
אבל בשנים האחרונות חלק משמעותי מעולם הדאטה חוזר דווקא לקוד. לא בהכרח לקוד מורכב. אבל לקוד שאפשר לשמור ב-Git, לבדוק, לבצע לו Version Control, להריץ אוטומטית ולתת גם ל-AI לעזור לכתוב ולתחזק אותו. בארכיטקטורת ELT טיפוסית אנחנו מפרידים בין שני שלבים.
ראשית מעבירים את הנתונים ממערכת המקור למחסן הנתונים באמצעות כלי אינטגרציה כגון Sling Data, Stitch, ETLworks, Hevo ואחרים. לאחר מכן מבצעים את הטרנספורמציות בתוך בסיס הנתונים עצמו.
dbt היא אחת הדוגמאות הבולטות למגמה הזאת: המודלים נכתבים בעיקר כ-SQL ונבנים בתוך ה-Data Warehouse, כאשר הקוד, התיעוד, הבדיקות וה-Lineage הופכים לחלק מהפרויקט. גם Sling, לדוגמה, מאפשרת להגדיר Replications בצורה של YAML או JSON ולהעביר מספר גדול של Streams בין מקורות ויעדים.
זה פחות "ציור של קופסאות" ויותר Software Engineering לדאטה. ולדעתי המגמה הזאת רק תתחזק. במיוחד בגלל AI. כי באופן אירוני, ככל שה-AI יודע לכתוב יותר קוד – כך קוד הופך להיות נגיש יותר.
אבל ב-Data Engineering ה-AI עדיין רחוק מלהחליף אנשים
אם בתחום האנליזה אנחנו כבר רואים מערכות שמבצעות עבודה מרשימה מאוד, ב-Data Engineering התמונה מורכבת יותר. AI יכול לעזור מאוד. הוא יכול לכתוב SQL. לייצר מודל dbt. לעזור בפיתוח API. להסביר שגיאות. לבנות בדיקות. לכתוב YAML. אבל הפרויקט האמיתי מתחיל הרבה לפני כתיבת הקוד.
מישהו צריך להבין כיצד מתחברים למערכת המקור. אילו הרשאות נדרשות. מה מותר לקרוא. איזה API זמין. האם הנתונים מלאים. מה משמעות כל שדה. ולעיתים, בעיקר במערכות Custom Made שנכתבו לפני עשר או עשרים שנה, אין אפילו אדם אחד בארגון שיודע להסביר את כל המערכת. ואז מגיע החלק הקשה באמת:
החיבור בין מקורות המידע.
יש ERP. יש CRM. יש מערכת שירות. יש נתונים מאתר החברה. יש API מספק חיצוני. אבל אין Customer ID אחד שמופיע בכולם. אז איך יודעים שלקוח 19382 ב-ERP הוא אותו לקוח שמופיע תחת contact_88371 במערכת אחרת? זו אינה רק שאלת קוד. צריך לאפיין. צריך לדבר עם האנשים. צריך להבין את התהליך העסקי.
ולעיתים צריך לקבל החלטה שאין לה תשובה טכנית אחת "נכונה". אותו הדבר נכון לגבי נוסחאות. מהי עסקה פעילה? מהו לקוח חדש? מהי נטישה? כיצד מחשבים רווחיות? אלו שאלות שדורשות שיחות עם הנהלה, כספים, מכירות, תפעול ומערכות מידע. AI בהחלט יכול להיות חבר צוות מצוין.
אבל נכון ל-2027, הוא עדיין לא מחליף את שלב ההבנה העסקית.
אבטחת מידע תהפוך לחלק מהארכיטקטורה, לא לסעיף בסוף
ככל שאנחנו נותנים ל-AI גישה ליותר מידע ארגוני, השאלה "האם המערכת מאובטחת?" כבר אינה מספיקה. צריך לשאול שאלות הרבה יותר מדויקות. איפה המודל רץ? איזה מידע יוצא מהארגון? איזה מידע נשלח לספק AI? האם המידע נשמר? האם הוא משמש לאימון? מי יכול לשאול מה? האם עובד במחסן יכול לראות נתוני שכר?
האם מנהל אזורי יכול לשאול על נתונים של אזור אחר? האם הרשאות Row Level Security ממשיכות לעבוד כאשר השאלה מגיעה דרך ChatGPT או Claude? ופה שוב אנחנו חוזרים לשכבות שבין המשתמש לבין בסיס הנתונים.
לדוגמה, Metabase מציינת שה-MCP Server שלה עובד תחת ההרשאות של המשתמש המתחבר. ThoughtSpot מדגישה Row-Level ו-Column-Level Security כחלק מתשתית האנליטיקה שלה. המשמעות היא שאי אפשר לחשוב על AI כממשק צדדי שעוקף את מערכת ה-BI וה-Governance. הוא צריך להיות חלק מהן.
ענן או On-Premise? אין תשובה אחת
אחת הטעויות הנפוצות בעולם הטכנולוגיה היא לחפש את "הכלי הטוב ביותר". לדעתי אין דבר כזה. יש כלי שמתאים לסיטואציה מסוימת. ארגון אחד יכול לעבוד כולו בענן ולהרגיש נוח להעביר מידע לספק AI חיצוני. ארגון אחר עובד עם מידע רפואי, ביטחוני, פיננסי או מסחרי רגיש וידרוש שחלק מהמערכת תפעל On-Premise.
חברה אחת מנתחת עשרה מיליון רשומות. חברה אחרת מאות מיליארדים. בחברה אחת הלוגיקה פשוטה מאוד. בחברה אחרת חישוב "מחזור" דורש 14 טבלאות, שלושה סוגי תאריכים ושיחה של שעה עם סמנכ"ל הכספים. לכן גם בעולם של Data AI אין ארכיטקטורה אחת נכונה. צריך לשאול:
האם אפשר לעבוד בענן או שחייבים לעבוד מקומית? מה כמות המידע? כמה משתמשים יהיו? עד כמה הלוגיקה העסקית מורכבת? איזו רמת אבטחה נדרשת? האם המשתמשים צריכים דשבורדים קבועים או בעיקר שאלות Ad Hoc? האם המידע כבר מסודר במחסן נתונים? האם קיימת שכבה סמנטית?
והאם הארגון רוצה AI שיעזור למשתמש – או AI שגם יבצע פעולות?
התפקיד שלנו משתנה גם הוא
כשכתבתי על BI לפני כמעט עשור, חלק גדול מעבודת אנשי התחום היה בניית ETL, מודלים, דוחות ודשבורדים. העבודה הזאת לא נעלמת. אבל מרכז הכובד משתנה. יותר ויותר מהקוד עצמו ניתן לייצר בעזרת AI. יותר דוחות ניתן לבנות אוטומטית. יותר שאלות יכול המשתמש לשאול לבד.
ולכן הערך עובר בהדרגה מ-"לדעת ללחוץ על הכפתורים בתוכנה" ליכולת להבין את הארגון ולבנות עבורו ארכיטקטורה נכונה. וזה בעיניי המקום שבו חברות כמו Inflow צריכות להיות בשנים הקרובות.
הערך שלנו אינו לבחור את הכלי שאנחנו רגילים לעבוד איתו – אלא לבחור עבור הלקוח את שילוב הכלים הנכון בהתאם לצורך.
לעיתים זה יהיה Power BI. לעיתים Metabase. לעיתים Credible Data או ThoughtSpot. לעיתים פתרון AI ייעודי. לעיתים dbt. לעיתים הכל יעבוד בענן. ולעיתים חלק משמעותי ממנו יישאר בתוך הרשת של הלקוח. הטכנולוגיה הופכת חזקה יותר. אבל דווקא בגלל שיש יותר אפשרויות, האפיון הופך חשוב יותר.
לסיכום – ה-AI לא הורג את ה-BI. הוא משנה אותו
אני לא חושב שב-2027 נקום בבוקר ונגלה שהדשבורדים נעלמו. אני גם לא חושב שאנליסטים או Data Engineers ייעלמו. אבל אני כן חושב שאנחנו נמצאים בתחילתו של שינוי משמעותי מאוד. ממשק המשתמש עובר בהדרגה מדוחות ושדות חיפוש לשפה טבעית. כלי BI מסורתיים הופכים לשיחתיים. כלים חדשים נבנים כ-AI Native מהיום הראשון.
תהליכי Data Engineering הופכים יותר מבוססי קוד ויותר נגישים ל-AI. והשכבה הסמנטית הופכת לחיבור הקריטי בין היכולת המרשימה של מודלי ה-AI לבין המציאות המבולגנת של הנתונים הארגוניים.
בסופו של דבר, המודל הגדול והחכם ביותר בעולם לא יכול לדעת לבד מה החברה שלכם מתכוונת כאשר היא אומרת "מכירות", "לקוח פעיל" או "רווח". מישהו צריך ללמד אותו. מישהו צריך לבנות את החיבורים. מישהו צריך להחליט מי רשאי לראות מה.
ומישהו צריך לוודא שהתשובה שהמנכ"ל קיבל בשפה טבעית היא לא רק תשובה שנשמעת מצוין – אלא גם תשובה נכונה.
וזה, מבחינתי, יהיה הסיפור הגדול של דאטה AI בשנת 2027: לא רק AI חכם יותר, אלא דאטה שמוכן לעבוד איתו.
הכותב הוא שטינברג איתמר, מנכ"ל Inflow, המתמחה בפתרונות Data, Business Intelligence, Data Engineering ו-AI לארגונים
