סיום תכנית X-labs in a BOX  במכבי שירותי בריאות

תחשבו הכי גדול שאפשר, הכי רחוק שאפשר, כמו שדיויד בואי אמר – "המחר שייך למי שיכול לשמוע אותו מגיע."
כך אמרה אחת המשתתפות עם סיום תכנית Xlabs in a Box מבית שטראוס אסטרטגיה  שהתקיימה במשך 3 חודשים עם לקוח נפלא מכבי שירותי בריאות.

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

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

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

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

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

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

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

אנו בשטראוס גאים לקחת חלק בפרויקט האדיר הזה X-labs in a BOX  במכבי שירותי בריאות.

עוד כתבות עבורך

השלב הבא באימוץ AI: איך מנווטים את השינוי האקספוננציאלי בצורה מאוזנת?

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

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

לכן השאלה ״האם הארגון עושה AI?״ כבר פחות מעניינת.

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

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

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

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

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

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

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

 

הציר הראשון: האם יש מנוע ערך, או רק אוסף רעיונות?

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

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

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

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

כאן מתחיל ההבדל בין ארגון שיש לו רשימת Use Cases לבין ארגון שיש לו מנוע ערך.

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

 

הציר השני: האם אנשים באמת עובדים אחרת, או רק נחשפו ל-AI?

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

זו אחת האשליות הנפוצות באימוץ AI: לחשוב שהדרכה מייצרת אימוץ. הדרכה היא התחלה טובה, אבל היא לא שינוי. היא יכולה לייצר מודעות, התלהבות, אפילו כמה שימושים ראשונים. אבל חודשיים אחר כך צריך לשאול שאלה הרבה יותר מעשית: האם משהו השתנה בדרך שבה העבודה מתבצעת?

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

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

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

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

 

הציר השלישי: האם יש תשתית שמאפשרת להצליח יותר מפעם אחת?

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

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

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

כאן נכנס הציר התשתיתי: דאטה, ארכיטקטורה, ממשל, אבטחה, סביבת עבודה, ניטור, FinOps, Guardrails, יכולות אינטגרציה, ולעיתים גם רכיבים כמו LLM Gateway, Vector DB, EVALs או תשתיות Agentic. לא תמיד צריך את הכל בהתחלה, ובוודאי שלא נכון לבנות ״פלטפורמת-על״ לפני שמבינים את דפוסי השימוש החוזרים. אבל צריך לבנות מסלול שחוזר על עצמו.

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

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

ב-AI זה קורה מהר יותר.

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

 

הציר הרביעי: האם ההנהלה מנהלת AI, או רק נותנת לו חסות?

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

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

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

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

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

הנהלה רצינית לא צריכה עוד סיסמה על AI. היא צריכה להחליט מה היא מוכנה לשנות כדי ש-AI באמת יעבוד.

 

בסוף, בשלות AI היא היכולת לזהות איפה הארגון לא מאוזן

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

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

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

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

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

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

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

בסוף, זה ההבדל בין AI שקורה בארגון לבין ארגון שיודע לנהל AI.

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

AI לא מאמצים ביום אחד.
לומדים לנהל אותו.

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

 

בשטראוס אסטרטגיה פיתחנו את סרגל ההבשלה המתמדת (Continuous AI Maturity Compass) מתוך תפיסה שאינה רואה במודל בשלות AI תרגיל אבחוני מופשט או שאלון ציונים, אלא כלי עבודה ארגוני ומעשי לכל דבר.

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

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

מעבר למספרים | האמנות והמדע של מדידת ערך בבינה מלאכותית

בעולם העסקי של 2026, השאלה היא כבר לא האם להשקיע בבינה מלאכותית אלא כיצד להוכיח שההשקעה הזו אכן משתלמת. בעוד שהציפייה הארגונית היא לראות החזר השקעה מהיר, המציאות מציבה אתגר מורכב: 74% מיוזמות ה-AI בארגונים מתרסקות בשלב הפיילוט ואינן מבשילות לכדי ייצור. התופעה הזו – "בית הקברות של הפיילוטים", איננה נובעת מאתגרים טכנולוגיים אלא ניהוליים ותרבותיים, היעדר מסגרת עסקית מובנית.  

 

פרדוקס הערך | למה 60% מהארגונים נשארים מאחור? 

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

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

 

המתודולוגיה | מדידה המבוססת על זמן אמת ואימות 

כדי לנהל את המסע הזה בצורה מושכלת, עלינו להפריד בין שני עולמות של מדדי ביצוע (KPIs): 

  • מדדים מובילים (Leading KPIs): אלו מדדים הנמדדים בזמן אמת. הם מתפקדים כ "שעון חול" המאפשר ניהול, בקרת סטייה ותיקון מסלול לפני שהתקציב אוזל. דוגמאות לכך כוללות את אחוז אימוץ הקוד על ידי מפתחים או את רמת הדיוק של המודל בחיזוי לידים. בזירת הנדסת התוכנה (Engineering), מדדים אלו חיוניים במיוחד: אנו רואים קיצור של כ 45% בזמן מחזור ה PR בארגונים המטמיעים כלי AI בצורה נכונה.  
  • מדדים מאמתים (Lagging KPIs): אלו מדדי "המראה האחורית" המתקבלים לאחר תקופה של שימוש רצוף (לעיתים 9-12 חודשים). הם משמשים לאימות ה ROI הפיננסי ולהצדקת המשך התקצוב של הפרויקט.  

העיקרון הניהולי הוא שהתמקדות מוקדמת במדדים המובילים היא זו שמבטיחה את שורת הרווח המיוחלת בסוף התהליך.  

 

"המס" של הבינה המלאכותית | השחיקה שחובה להכיר 

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

  • חוב טכני מצטבר: הצבירה של חוב טכני ביוזמות AI מהירה עד פי 8 לעומת פיתוח מסורתי.  
  • עלויות תחזוקה: עלות התחזוקה השנתית של מודלים נעה בין 30% ל 45%, זאת בהשוואה ל 15% עד 25% במערכות רגילות.  

 

מה עושים מחר בבוקר? | חמשת עקרונות היסוד 

כדי לעבור למדידה המבוססת על ערך שקוף ומדיד, עלינו לאמץ חמישה צעדים קריטיים: 

  • הגדרת הבעיה העסקית: ודאו שכל השקעה מגובה במדד תפעולי קיים שניתן לשיפור כמו עלות, מהירות או איכות.  
  • קביעת קווי בסיס (Baselines): לעולם אל תשיקו פרויקט AI ללא תיעוד מדויק של ביצועי הארגון טרום ההשקה. ללא מדידת קו הבסיס ביום אפס, כל דיווח על שיפור הוא חסר משמעות. ה– Baseline הוא למעשה תשתית למשילות (Governance) המאפשרת להנהלה לקבל החלטות מבוססות נתונים לגבי הרחבת ההשקעה או עצירתה.  
  • הפרדת המדדים: עקבו אחר מדדי אימוץ ושימוש בטווח הקצר, ומדדי רווח והפסד בטווח הארוך.  
  • ראייה רב ממדית: שקללו ערך אסטרטגי, ניהול סיכונים ושיפור חוויית עובד או לקוח לתוך נוסחת ה– ROI המורחבת שלכם.  
  • התרחבות מבוססת נתונים: התחילו בפיילוטים מבוקרים והרחיבו השקעות רק ליוזמות שהוכיחו ערך מדיד במורד "מפל הערך".  

 

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

 

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

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

דברו איתי > gil.r@s-strategy.com 

 

מ"שומר סף" ל"מאפשר": המהפכה האסטרטגית של עולם ה- Vibe Coding

בשיח פתוח שקיימנו לאחרונה עם מנהלים ומנהלות בכירים ברמת C-Level צללנו לעומק האתגרים המורכבים שארגוני Enterprise פוגשים בעידן ה-AI. המציאות כיום מציבה ארגונים רבים בצומת דרכים טקטוני שבו פיתוח Vibe Coding על ידי עובדים שאינם מפתחים אינו רק "טרנד טכנולוגי", אלא שינוי אסטרטגי מהותי שמשנה את מאזן הכוחות בין ה-IT לשאר חלקי הארגון.

תפקיד יחידת מערכות המידע עובר טרנספורמציה ממצב של "שומר סף" החוסם יוזמות, למצב של "מאפשר" (Enabler) – גוף המגדיר פלטפורמה, ממשל (Governance) ותשתית, ומעניק ליחידות העסקיות את הכוח לבנות בעצמן.

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

 

שלושת מנועי השינוי האסטרטגי

מדוע ה-Vibe Coding הוא אירוע שאי אפשר להתעלם ממנו? לפי המומחים שלנו, קיימים שלושה מנועים מרכזיים:

  1. דמוקרטיזציה של הפיתוח: הכוונה (Intent) הופכת לכלי. יחידות עסקיות יכולות לבנות פתרונות בעצמן ללא תלות מלאה ב-IT.
  2. האצה דרמטית (Speed): מחזור פיתוח שנמשך בעבר חודשים ארוכים הופך כמעט לאפסי. Vibe Coding מייצר תוכנה בזמן קצר בהרבה מהמקובל.
  3. שינוי תפיסתי ב-IT: המעבר הוא מ"מתרגמים של צרכים עסקיים" לבעלי פלטפורמות המאפשרות לארגון כולו ליצור ערך.

 

המודל התלת-שכבתי: איך מסווגים את "השדים הדיגיטליים"?

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

רמההגדרהאחריות
רמה 1: מאקרו אישיכלי אישי לעובד, ללא ערך ארגוני רוחבינשאר אצל העובד. IT אינו מעורב
רמה 2: מחלקתימערכת המשרתת יחידה עסקית ספציפיתה-IT מספק תשתית, API ואבטחה. הביזנס הוא ה-Owner
רמה 3: ארגוני (Enterprise)מערכת ליבה עם השלכות חוצות ארגוןה-IT לוקח Ownership מלא על המערכת

 

ארבעת אזורי הנחיתה האידיאליים לתחילת העבודה

היכן הכי נכון להתחיל את מסע ה-Vibe Coding בארגון?

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

  • פיננסים: אוטומציה של עבודות רוטיניות המתבצעות כיום באקסלים ידניים. ניתן להגיע לחיסכון של 30 עד 40 שעות עבודה בשבוע ליחידה.
  • משאבי אנוש (HR): תחום שלרוב נמצא בתחתית סדר העדיפויות של ה-IT. יישומים כמו סינון קורות חיים ותהליכי גיוס יכולים להשתדרג דרמטית.
  • ניהול ידע (Knowledge): תהליכי Onboarding לעובדים חדשים, צ'קליסטים ובדיקות מובנות.
  • יזמות וחדשנות: בניית פרויקטים מהירים על בסיס Mock Data כדי להוכיח היתכנות בעלות אפסית.

 

Governance: הארכיטקטורה כעוגן של יציבות

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

  • API מאובטחים: חשיפת Read Only בלבד בשלב הראשון למניעת כתיבה לא מבוקרת למערכות הליבה.
  • סיווג דאטה: הגדרה ברורה של מה מותר לשימוש (ירוק), מה מוגבל (צהוב) ומה אסור לחלוטין (אדום).
  • סריקות אבטחה חובה: נתון מרתק מראה כי קוד שנוצר על ידי AI מועד ב-25% יותר לחולשות אבטחה לעומת קוד אנושי, ולכן סריקה אוטומטית היא תנאי סף.
  • מדד ה-Time to Switch: הארכיטקטורה חייבת לאפשר מעבר מהיר בין כלי AI שונים (למשל מ-Gemini ל-Claude) כדי למנוע נעילה טכנולוגית.

 

מה עושים מחר בבוקר? תוכנית פעולה למנהלים

הצלחה בעולם ה-Vibe Coding דורשת שילוב בין תשתית טכנולוגית לבניית אמון ארגוני:

  1. הקמת Sandbox ארגוני: בניית "מגרש משחקים" מבוקר עם זהות ארגונית מנוהלת (SSO) וגישה מוגבלת לנתונים.
  2. הצמחת שגרירים (Ambassadors): זיהוי העובדים שכבר בונים כלים "פיראטיים", והצמדת מפתח IT אליהם למשך 3 חודשים כדי להפוך אותם לשגרירים של פיתוח מבוקר.
  3. הטמעת Audit Log עסקי: לא לוותר על מדידה! יש לנטר כל שלב בכל אפליקציה כדי להבין את מסע הלקוח (Customer Journey) ואת הערך העסקי שנוצר.

 

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