מודל הנתונים של Celonis

כיצד נתונים גולמיים מהמערכות הארגוניות הופכים למציאות עסקית, להקשר תהליכי ולבסיס ל- AI

לרוב הארגונים כבר יש היום הרבה מאוד דאטה. מערכות ERP מחזיקות טרנזקציות. מערכות CRM מחזיקות אינטראקציות עם לקוחות. מערכות שרשרת אספקה מחזיקות נתוני מלאי ולוגיסטיקה. מערכות פיננסיות מחזיקות חשבוניות ותשלומים. מערכות שירות מחזיקות פניות ובקשות. ובכל זאת, למרות כל הדאטה הזה, רוב הארגונים עדיין מתקשים לענות על שאלות עסקיות בסיסיות וקריטיות, כמו:

למה ההזמנה הזו התעכבה?
איפה בדיוק “נוזל” ערך עסקי?
איזה צוואר בקבוק תפעולי פוגע בשביעות רצון הלקוחות?
ולמה יוזמות AI רבות לא מצליחות להתחבר לביצוע האמיתי של הארגון?

הסיבה פשוטה:
הדאטה הארגוני מאוחסן בדרך כלל ב-Silos ומאורגן כדי לשרת את המערכות – לא כדי לייצר הבנה עסקית.
וזו בדיוק הבעיה ש- מודל הנתונים של Celonis נועד לפתור.

בלב הפלטפורמה של Celonis נמצא מודל שונה מהותית: מודל שלא בנוי סביב טבלאות מבודדות או טרנזקציות טכניות, אלא סביב האופן שבו העסק באמת פועל במציאות.
זהו המודל שמאפשר ל-Celonis לבנותProcess Intelligence Graph (PIG) , לנתח תהליכים מקצה לקצה, לזהותRoot Causes, לכמת השפעה עסקית, ובסופו של דבר גם לאפשר יישוםAI ו-Automation בקנה מידה ארגוני.

למה מודלי נתונים ארגוניים “רגילים” לא מספיקים
רוב המערכות הארגוניות תוכננו כדי להריץ טרנזקציות, לא כדי להסביר את המציאות העסקית.
לדוגמה:

SAP עשויה לשמור את ה-Sales Order בטבלאות מסוימות
נתוני Delivery יישבו במקום אחר
Invoice ו-Payment יישבו בטבלאות אחרות
אינטראקציות לקוח עשויות להיות ב- Salesforce
פניות שירות יופיעו בכלל במערכת נפרדת

לכל מערכת יש היגיון פנימי משלה. אבל מבחינה עסקית – המציאות אינה מפוצלת.

מסע לקוח אמיתי הוא לא “טבלה”
הזמנה אמיתית היא לא “רשומה”
עיכוב אמיתי ב-Supply Chain  הוא לא “אירוע אחד במערכת אחת״

בפועל, Execution עסקי מורכב מ-ריבוי אובייקטים עסקיים מחוברים, שלכל אחד מהם ישLifecycle , קשרים ותלות באובייקטים אחרים. וזו בדיוק הלוגיקה שעליה בנוי מודל הנתונים של Celonis.

עקרון התכנון המרכזי: לחקות את המציאות העסקית

Celonis בנויה על רעיון יסודי וחשוב מאוד:
תהליך עסקי הוא לא רק רצף של פעילויות. הוא רשת של אובייקטים עסקיים אמיתיים, שמתקשרים זה עם זה לאורך זמן. כלומר, במקום “לשטח” את כל התהליך ל-Case ID אחד, Celonis ממדלת את העסק כפי שהוא באמת קיים:

Orders
Order Items
Deliveries
Invoices
Customers
Materials
Suppliers
Tickets
Assets
Applications
Payments

כל אחד מאלה מיוצג כ-Object עם:

זהות ייחודית,
מאפיינים עסקיים רלוונטיים,
Lifecycle
וקשרים לאובייקטים אחרים.

זה מה שהופך את המודל של Celonis להרבה יותר נאמן למציאות לעומת גישות BI מסורתיות או Process Mining קלאסי.

דוגמה: הזמנת לקוח אחת היא לא “דבר אחד”

הזמנה אחת של לקוח יכולה לכלול:

מספר Order Items
מספר Deliveries
מספר Invoices
תשלומים חלקיים
אינטראקציות שירות
הקצאות מלאי
ולעיתים גם החזרות

אם מכריחים את כל זה להיכנס ל- “Case” אחד ליניארי – מאבדים את המציאות.
Celonis עושה את ההפך: היא משמרת את המציאות.

ארבעת המרכיבים המרכזיים של מודל הנתונים ב- Celonis

ברמה הפרקטית, אפשר להבין את מודל הנתונים של Celonis דרך ארבעה אבני בניין מרכזיות:

Objects
Events
Attributes
KPIs

יחד, ארבעת המרכיבים הללו מייצרים את שכבת ההקשר העסקי שעליה נשענת כל הפלטפורמה.

2.1 Objects: על מה העסק באמת פועל

Objects הם הישויות העסקיות האמיתיות שסביבן מתבצעת הפעילות.

דוגמאות:

Sales Order
Order Item
Delivery
Invoice
Payment
Customer
Supplier
Service Ticket
Loan Application
Employee
Production Order

כל Object Type מייצג ישות שקיימת בעסק ומתפתחת לאורך זמן.

דוגמה:
Sales Order הוא .Object
הזמנה ספציפית כמו SO-104582 היא Instance (מקרה בודד) של אותו Object

ב-Celonis ה-Objects הם עמוד השדרה של המודל. לכל Object יש מזהה ייחודי, והוא יכול להיות מקושר גם ל-Events וגם ל-Objects אחרים.

Example Object Table

זה עדיין לא “Process Intelligence” אבל זו כבר שכבת הישויות העסקיות שעליה הוא נבנה.

2.2 Events: מה קורה לאותם Objects

אם Objects הם ה-“דברים”, אזEvents הם ה-“פעולות” או ה-“אירועים” שקורים להם.

דוגמאות:

Order Created
Credit Check Completed
Delivery Released
Invoice Posted
Payment Received
Ticket Reassigned
Document Uploaded
Application Approved

לכל Event יש Timestamp והוא מקושר ל-Object אחד או יותר.

וזו נקודה קריטית:
Events ב-Celonis הם לא רק Logs – אלא פעולות עסקיות שממוקמות בתוך הקשר עסקי.

דוגמה ל- Events Table

ב– Celonis, הEvents הם השכבה הכרונולוגית של המודל – אך בניגוד ל-Event Logs קלאסיים, הם יכולים להיות מחוברים למספר אובייקטים במקביל. זו אחת הסיבות המרכזיות לכך שהמודל משקף את המציאות טוב יותר.

2.3 Attributes: המשמעות העסקית של הדאטה

Attributes הם השדות התיאוריים שנותנים ל-Objects ול-Events את המשמעות העסקית שלהם.
בלי Attributes אפשר לדעת רק שמשהו קרה. עם Attributes אפשר להבין מה זה אומר עסקית.

דוגמאות ל- Object Attributes

Customer Segment
Payment Terms
Product Family
Region
Priority
Order Value
Risk Score
SLA Target
Channel

דוגמאות ל- Event Attributes

Performed By
Source System
Automation Flag
Approval Outcome
Delay Reason
Touchpoint Type

דוגמה לטבלת Attributes

זה השלב שבו Celonis מתחילה להפוך דאטה טכני שמגיע מהמערכות ל.Business Context –
וההקשר העסקי הזה הוא בדיוק מה שהופך גם את ה-Analysis וגם את ה-AI לשימושיים באמת.

2.4 KPIs: השכבה שהופכת דאטה לתובנה ניהולית

המרכיב הרביעי הוא KPIs. אבל חשוב להבין: ב-Celonis , KPI הוא לא רק מספר בדשבורד. זהו לוגיקה עסקית מוגדרת, שיושבת מעל מודל ה-Objects וה- Events ומכמתת ביצועים, חיכוך, בזבוז, סיכון והזדמנות.

דוגמאות ל- KPIs:

Order Cycle Time
Invoice Touchless Rate
On-Time Delivery %
Backlog Aging
Rework Rate
Credit Block Duration
First Contact Resolution
Value Leakage
Working Capital Impact

Example KPI Layer
זוהי השכבה שמאפשרת לארגון לעבור מ-“יש לנו דאטה” ל- “אנחנו יודעים מה לא עובד, למה, ומה הערך העסקי של זה”

מ-Raw Data ל-Business Context : איך המודל נבנה בפועל

כאן מודל הנתונים של Celonis הופך לעוצמתי במיוחד. כי הדאטה הגולמי שמגיע מהמערכות הארגוניות כמעט אף פעם לא מוכן ישירות לניתוח תהליכי.

בדרך כלל הוא מגיע בצורה של:

Transaction tables
Master data tables
Status tables
Header / item tables
Change logs
Audit trails
User action logs
System timestamps

אף אחד מאלה, בפני עצמו, אינו מייצג “תהליך עסקי”
Celonis לוקחת את הדאטה המפוצל הזה והופכת אותו למודל עסקי באמצעות לוגיקה סדורה.

שלב 1: Extract מהמערכות המקוריות
Celonis מתחברת למערכות ארגוניות כגון:

ERP
CRM
SCM
מערכות פיננסיות
מערכות שירות
Databases
APIs
Data warehouses / lakehouses

החיבור יכול להיעשות דרך:

Connectors מובנים
Connectors מותאמים
Database extraction
APIs
או סביבת Staging

שלב 2: זיהוי ה-Business Objects האמיתיים
השלב הבא הוא לא רק טכני – אלא בעיקר קונספטואלי.
השאלה שצריך לשאול היא: מהן הישויות העסקיות האמיתיות שבאמת חשובות בתהליך?
לדוגמה, ב-Order-to-Cash האובייקטים הרלוונטיים עשויים להיות:

Customer
Sales Order
Order Item
Delivery
Invoice
Payment
Material

זו החלטת Modeling קריטית, כי היא קובעת אם המודל ישקף את המציאות – או יעוות אותה.

שלב 3: שחזור Events מתוך הדאטה הגולמי
זהו אחד החלקים החשובים ביותר – ולעיתים גם הפחות מובנים.
ברוב המערכות לא קיים Event Log ״נקי״ ומוכן שמחכה פשוט לשימוש.
במקום זאת, Celonis משחזרת את ה-Events העסקיים מתוך הדאטה הגולמי, כגון:

זמני יצירת מסמכים
שינויי סטטוס
רשומות אישור
שינויי שדות
Posting records
Workflow steps
System logs

לדוגמה:

שורה מסוימת בטבלת SAP יכולה לייצג “Invoice Posted”
שינוי בקוד סטטוס יכול לייצג “Order Released”
עדכון שדה יכול לייצג “Customer Credit Approved”

שכבת הטרנספורמציה הזו היא קריטית, כי היא זו שהופכת דאטה טכני ברמת מערכת ל-Business Execution Events

שלב 4: חיבור בין Objects
זה השלב שבו דאטה מפוצל הופך למודל עסקי אמיתי.
לדוגמה:

Customer אחד יכול להחזיק מספר Sales Orders
Sales Order אחד יכול להכיל מספר Order Items
Order Item אחד יכול להוביל למספר Deliveries
Delivery אחד יכול להוביל ל-Invoice אחד או יותר
Invoice אחד יכול להיות קשור לתשלום אחד או יותר

לוגיקת הקשרים הזו היא מה שיוצרת Business Context

בלי זה – יש דאטה.
עם זה – יש הבנה תפעולית.

איך המודל מארגן נתונים מבודדים לכדי הקשר עסקי

זו אולי הנקודה החשובה ביותר במודל של Celonis – דוחות מסורתיים בדרך כלל יודעים לענות על שאלות כמו:

כמה חשבוניות הונפקו?
כמה פניות נסגרו?
מה היה זמן הטיפול הממוצע?

Celonis נועדה לענות על שאלות עמוקות בהרבה:

אילו Deliveries מאוחרים גרמו לעיכוב ב- Invoicing?
אילו לקוחות מייצרים באופן עקבי Rework ?
אילו Credit Blocks פוגעים בתזרים?
אילו Service Cases ״נתקעים” בגלל מסמכים חסרים?
אילו Variants של התהליך מייצרים הכי הרבה Value Leakage?

וזה אפשרי רק כי המודל לא משאיר את הדאטה בתוך ה-Silos של המערכות.
במקום זאת, הוא מארגן אותו מחדש סביב המציאות העסקית של ה- Execution.
וזו בדיוק הסיבה ש-Celonis יכולה לשמש כ-Execution Layer אמיתי מעל מערכות תפעוליות מפוצלות.

למה המודל הזה הוא הבסיס ל-Process Intelligence Graph (PIG)

ברגע שה-Object-Centric Model נבנה, Celonis יכולה לייצר מה שלמעשה מהווה גרף ביצוע עסקי.

הו ה- Process Intelligence Graph (PIG). ה-PIG הוא לא רק תרשים יפה. זהו ייצוג סמנטי מחובר של האופן שבו הארגון באמת פועל – בין מערכות, בין Objects ובין אירועים לאורך זמן.

ברמה הקונספטואלית, ה-PIG מאפשר ל-Celonis לענות על שאלות כמו:

מה קרה?
לאיזהז Object זה קרה?
באיזה רצף?
באיזה הקשר?
עם איזו השפעה עסקית?
ומה צריך לקרות עכשיו?

זו יכולת חזקה בהרבה לעומת דשבורדי BI מסורתיים או Process Maps מבודדים.

למה המודל הזה הוא הבסיס ל-Analysis ול- Insights

ברגע שהמודל קיים, Celonis יכולה לבצע Analysis ברמה הרבה יותר מדויקת, עמוקה ועסקית.
זה מאפשר בין היתר:
Process Discovery
להבין איך התהליך באמת מתבצע בפועל – לא איך תכננו אותו.
Variant Analysis
לזהות את מגוון מסלולי הביצוע האמיתיים שקורים בשטח.
Root Cause Analysis
להבין למה נגרמים עיכובים, Rework, חריגות SLA או חוסר יעילות.
Conformance Analysis
להשוות בין הביצוע בפועל לבין Policy, Design או Best Practice
Opportunity Analysis
לכמת איפה הארגון מאבד זמן, כסף או Capacity
Cross-Functional Visibility
לראות את שרשרת הביצוע המלאה בין פונקציות, מחלקות ומערכות.

ומכיוון שהמודל שומר את הקשרים בין היישויות ולא “משטח” אותן – התובנות הן בדרך כלל הרבה יותר אמינות והרבה יותר Actionable

למה מודל הנתונים הוא גם הבסיס ל-AI

וכאן המודל של Celonis הופך להיות קריטי ברמה האסטרטגית.
רוב יוזמות ה-AI בארגונים מתקשות לא בגלל שהמודל הלשוני (LLM) לא מספיק טוב – אלא בגלל שחסר להן Operational Context.

AI יודע לייצר טקסט.
AI יודע לסווג מסמכים.
AI יודע להציע פעולות.

אבל כדי ש-AI יוכל לפעול אפקטיבית בתוך הארגון, הוא חייב להבין:

על איזה Object הוא פועל
באיזה State הוא נמצא
מה קרה קודם
אילו Dependencies קיימים
אילו Business Rules חלים עליו
ואיזו פעולה באמת תייצר ערך

וזה בדיוק מה שמודל הנתונים של Celonis מספק.

בפועל, המודל מספק ל- AI:
Context

הוא אומר ל-AI האם הוא מתמודד עם:

Order
Delivery
Invoice
Service Case
Customer
Payment issue

State
הוא אומר ל-AI  באיזה שלב ב-Lifecycle  האובייקט נמצא כרגע.
Causality
הוא עוזר ל-AI  להבין מה כנראה גרם לבעיה הנוכחית.
Business Semantics
הוא מעניק משמעות לשדות, לסטטוסים ולקשרים.
Actionability
הוא מאפשר ל-AI  להבין מה ניתן – ומה נכון – לעשות עכשיו.

וזו בדיוק הסיבה ש-Process Intelligence הופכת בהדרגה לשכבה הכרחית בין המערכות התפעוליות לבין Enterprise AI. בלי השכבה הזו, AI נשאר לעיתים קרובות גנרי, מנותק מהביצוע, וקשה מאוד להטמעה אמיתית.

החשיבות האסטרטגית

מודל הנתונים של Celonis הוא לא רק בחירה ארכיטקטונית-טכנית.
זהו למעשה מודל תפעולי אסטרטגי לאופן שבו הארגון מבין, משפר ומנהל Execution
הוא הופך דאטה מפוצל ל:

שקיפות תפעולית
הקשר עסקי
תובנות מדידות
ידע תהליכי חוזר
ולוגיקת ביצוע מוכנה ל- AI

במילים אחרות:

מודל הנתונים של Celonis הוא מה שמאפשר להפוך דאטה ארגוני ל-Operational Intelligence אמיתי.

וזו בדיוק הסיבה שהוא כל כך חשוב. כי ארגונים לא צריכים עוד Raw Data
הם צריכים דרך להבין, לשפר, ובאופן הולך וגובר גם ליישם אוטומציה באופן שבו העסק באמת פועל.
וזה בדיוק מה שהמודל הזה נועד לעשות.

סיכום

מודל הנתונים של Celonis הוא הרבה יותר ממבנה דיווח או שכבת דאטה. זהו ייצוג Object-Centric של המציאות העסקית, שהופך נתונים מבודדים ממערכות שונות להקשר עסקי מחובר.

באמצעות ארגון הדאטה סביב: