דילוג לתוכן
HIVO

הטמעת AI בארגון

עמית אמיר · מייסד שותף ומנכ"ל

פיילוט AI הצליח. אז למה הוא עדיין לא מגיע לפרודקשן?

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

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

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

הפער הזה כבר ניכר בנתונים. בסקר The State of AI in 2026 של McKinsey, כמעט תשעה מתוך עשרה משיבים דיווחו על שימוש קבוע ב-AI לפחות בפונקציה עסקית אחת, ו-44% דיווחו שה-AI כבר נמצאת בשלב של Scaling ברמת הארגון. למרות זאת, רק 37% ייחסו לשימוש ב-AI השפעה חיובית כלשהי על ה-EBIT.

הטכנולוגיה נכנסה לארגון מהר יותר מהיכולת הארגונית להפיק ממנה ערך עקבי.

הדמו הוא החלק הקל

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

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

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

בפרודקשן פוגשים את הארגון האמיתי

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

הנתון שהמערכת קוראת לא השתנה. המשמעות שלו כן.

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

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

יותר מידע לא מחליף הבנה של הארגון

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

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

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

הדאטה הוא חומר הגלם. המודל הוא הנכס שמאפשר להפוך אותו להבנה ארגונית.

AI יכולה לסייע לגלות קשרים, להציע עדכונים ולתמוך בתחזוקה של המודל, אבל היא אינה המודל עצמו. ההבחנה הזאת חשובה במיוחד בפרודקשן, כי היכולת צריכה להישען על ייצוג יציב של הארגון גם כשהמודל, ה-Agent או ה-Use Case משתנים.

מה צריך להפוך למפורש לפני שעוברים לסקייל?

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

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

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

כשהבסיס קיים, הערך מתחיל להצטבר

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

כאשר קיים Operational Model משותף, הידע שנלמד על הארגון נשאר כנכס. Use Case חדש יכול להישען על אותם אובייקטים, קשרים, אירועים וכללי אחריות במקום להתחיל מאפס. יכולת אחת עשויה לעסוק בזיהוי סיכון, אחרת בתמונת מצב ניהולית, ובהמשך יכולות Agentic יכולות להישען על אותו בסיס. הערך כאן הוא מצטבר: לא רק עוד שימוש ב-AI, אלא תשתית ארגונית שנעשית שימושית יותר ככל שנוספים אליה תהליכים והקשר.

זו גם הדרך הנכונה לקרוא את הנתון המפורסם של Project NANDA. בנייר העבודה המקדמי The GenAI Divide: State of AI in Business 2025 נקבע כי 95% מהארגונים שנבדקו אינם רואים תשואה מדידה. הנקודה החשובה בדוח אינה ש-AI לא עובדת, אלא שהפער נוצר כאשר כלים אינם לומדים את ההקשר, אינם משתלבים בעבודה הקיימת ואינם הופכים ליכולת שהארגון יודע לתחזק לאורך זמן.

הנתון של Project NANDA מתייחס לארגונים ולא לפיילוטים. לפי המשפך שבנייר העבודה עצמו, 60% מהארגונים בחנו כלים, 20% הריצו פיילוט ו-5% הטמיעו בהצלחה, כלומר כרבע מהארגונים שהריצו פיילוט הגיעו להטמעה. זהו נייר עבודה מקדמי שלא עבר ביקורת עמיתים. התיקון המלא של המספר הזה מתפרסם אצלנו באנגלית.

זו השכבה ש-HIVO בונה

HIVO היא The Operational System of Record for Enterprise AI. היא בונה ומתחזקת Operational Model משותף מעל מערכות המקור, כך שהאובייקטים העסקיים, הקשרים, המצבים, האירועים, האחריות וההחלטות מיוצגים בתוך מסגרת אחת שמתעדכנת יחד עם הארגון.

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

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

להרחבה על ההבחנה בין מידע להקשר תפעולי, ראו את המאמר בינה מלאכותית כבר נמצאת בארגון. אז למה היא עדיין לא מבינה את הארגון?.

מפיילוט שעובד ליכולת שעובדת

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

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

זה המקום שבו דמו מוצלח יכול להתחיל להפוך ליכולת ארגונית אמיתית.

שאלות נפוצות

למה פיילוט AI מצליח לא תמיד מגיע לפרודקשן?

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

מה ההבדל בין Proof of Concept לבין מערכת AI בפרודקשן?

Proof of Concept נועד להוכיח יכולת נקודתית. מערכת בפרודקשן צריכה להשתלב בעבודה באופן רציף, עם גבולות אחריות, בקרה, חריגים ואימוץ של האנשים שמשתמשים בה.

האם חיבור AI לכל מערכות הארגון מספיק כדי להגיע לסקייל?

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

מה ההבדל בין Operational Context לבין Operational Model?

Operational Context הוא ההקשר שהמערכת צריכה כדי להבין מצב ולפעול נכון. Operational Model הוא הנכס המובנה שמייצג ומתחזק את הישויות, הקשרים, המצבים, האירועים והאחריות שמהם ההקשר נבנה.

למה בסיס תפעולי משותף חשוב גם ל-Use Cases עתידיים?

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

מקורות

  1. The state of AI in 2026: On the road to ROI

    McKinsey and Company. 25 באוגוסט 2026, n=1,719.

  2. The GenAI Divide: State of AI in Business 2025 (נייר עבודה מקדמי)

    Project NANDA, MIT Media Lab. יולי 2025, 52 ראיונות ו-153 משיבים.

איפה זה נשבר אצלכם בארגון?

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

דברו איתנו

להמשך קריאה