מהפיכת ה-AI: מה ארגונים חייבים לדעת?

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

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

 

הגדרה ברורה של המטרות העסקיות (Clear Business Objectives): כפי שאנחנו אומרים כל הזמן ללקוחות שלנו: הטכנולוגיה היא תמיד האמצעי ולא המטרה עצמה. כל ארגון חייב להגדיר לעצמו את המטרות העסקיות שהוא מנסה להשיג (במסגרת האסטרטגיה הכללית), ועל בסיס מטרות אלו לבחון אילו אמצעים (טכנולוגיים ואחרים) יכולים לשרת ולקדם אותה לקראת השגת מטרות אלו. במקרה של טכנולוגיות GenAI/AI  מדובר באותה התפיסה בדיוק: ארגונים צריכים להגדיר לעצמם מטרות עסקיות ברורות ומוגדרות היטב, ורק אז לבחון כיצד AI יכול לסייע בהשגת המטרות.

דאטה איכותית, מטויבת ונגישה (Data Quality and Accessibility): חשוב לזכור שטכנולוגיות מבוססת AI חייבות להסתמך על דאטה איכותית, מטויבת ונגישה. לכן ארגונים חייבים לוודא שהדאטה שלהם מדויקת, מגוונת ורלוונטית מספיק במטרה לאפשר תשתית אופטימלית לתרגול ולימוד אלגוריתם ה-AI. מדובר בשלב בסיסי וקריטי לכל ארגון שרוצה לבנות יכולות, כלים וערך אמיתי. יותר מזה, החשיבות של איכות ונגישות הדאטה רלוונטית גם לצורכי ניהול, מעקב ובקרת הדאטה, הן בהיבט הפנים ארגוני, ולא פחות חשוב עבור דרישות רגולטוריות, סוגיה שנתייחס אליה בסעיפים הבאים.

דרישות רגולטוריות, אתיות וציות (Ethical and Regulatory Compliance): לצד ההזדמנויות הרבות ש-AI מייצרת, עלו בשנים האחרונות גם חששות רבים לגבי השפעתה על נושא הפרטיות ואבטחת המידע. בנוסף, יכולות הטכנולוגיה מאפשרות לייצר דברים שלא היו קיימים לפני: דיפ פייק תוך שימוש בקולות ופניהם של בני אדם, הפקת סרטוני ווידאו ותמונות שנראות אוטנטיות אך הן אינם כאלו ועד התחזות ברמת דיוק חסרת תקדים. כלים כמו ChatGPT ואחרים מבוססים על מידע עשיר כדי לספק את התוצרים הללו, וכשלא קיימת שקיפות לגבי האופן הספציפי שבו המידע מנוצל ולאן הוא יכול לזלוג, הדבר רק מגביר את החששות הגוברים.

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

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

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

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

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

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

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

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

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

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

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

 

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

אתם שואלים את השאלה הלא נכונה: מדריך הישרדות בגלקסיית ה-AI Powered SDLC

למה הבטחות הפרודוקטיביות של ה-AI דורשות בחינה מחודשת, ואיך מנווטים את הארגון הרחק "מחומת ה-18 חודשים"?

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

בעידן ה-AI Powered SDLC ארגונים רבים חווים תופעה דומה. אנו רואים הנהלות שרוכשות רישיונות של GitHub Copilot, Cursor או Claude, מקבלות דוחות המציגים "חיסכון של 40% בזמן כתיבת קוד", ומכריזות על הצלחה.

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

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

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

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

  1. ירח הדבש, חוב ההבנה ו"חומת ה-18 חודשים"

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

אבל מתחת לפני השטח מתחיל להצטבר "חוב הבנה" (Comprehension Debt).

חוב הבנה הוא המחיר העתידי שהארגון ישלם כדי להבין, לתקן, לשנות ולאבטח קוד שנוצר על ידי מכונה – מבלי שגורם אנושי מבין במלואה את הלוגיקה שלו. כאשר קוד מאושר בקליק ללא תהליכי Code Review מותאמים, הארגון צועד לקראת התנגשות עם מה שאנו מכנים "חומת ה-18 חודשים":

 

  1. סיור בגלקסיה הארגונית: עדכון תפקידי הליבה

מהפכת ה-AI SDLC היא אירוע הוליסטי. היא דורשת עדכון של ה-Operating Model הארגוני כולו כדי לשמור על סנכרון מלא בין היחידות השונות:

  • אנשי מוצר (Product Managers) כארכיטקטים של הקשר: בעבר, איש המוצר העביר User Story לפיתוח. כיום, הדרישה לדיוק עולה מדרגה. תפקידם מתרחב ל"ארכיטקטים של הקשר" (Context Architects) – עליהם להגדיר דרישות, חוקים עסקיים ומגבלות בצורה מדויקת (Specifications) שכן אלו מהווים את חומר הגלם למנוע ה-AI.
  • בדיקות ואיכות (QA) כמומחי וולידציה: כאשר ה-AI כותב גם את הקוד וגם את הבדיקות האוטומטיות, מוקד ה-QA משתנה מבדיקות תרחישים ידניות לוולידציה מערכתית מורכבת. האחריות שלהם היא לאתגר את ה-AI במצבי קצה (Edge Cases) ולוודא עמידה מדוקדקת בלוגיקה העסקית.
  • שיווק ומכירות – תיאום ציפיות עסקי: הנגישות לכלים אלו עלולה לייצר לחץ עסקי לשחרור פיצ'רים בזק. מנגד, זו הזדמנות עבור גופי השיווק להשתמש ב-AI ליצירת אבות-טיפוס (Mockups) מול לקוחות, ולבסס פיתוח על דרישות שוק מוכחות, כל עוד נשמר התיאום מול יכולות הייצור.
  • תמיכה ותפעול (Support & Ops) – לתקן את החוקים, לא את הקוד: במקום פתרון נקודתי של באגים בקוד (מה שמייצר "קוד ספגטי"), צוותי התפעול נדרשים לעבוד במודל שבו מתקנים את האפיון (The Spec) או את מערכת החוקים (Rulebook), ומאפשרים ל-AI לייצר את המקטע מחדש.
  • סיכונים ורגולציה (Risk & Compliance) – ניהול סיכוני ה-Shadow AI: יוזמות עצמאיות של מפתחים (Shadow AI) חושפות את הארגון לזליגת מידע, הפרת רישיונות קוד פתוח וסוגיות פרטיות. האתגר הניהולי הוא יצירת AI Governance ברור שמאפשר חדשנות בטוחה בסביבה הארגונית.

 

  1. שינוי תפיסתי: המעבר ל"קוד מתכלה"  (Disposable Code)

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

כאן אנו רואים צורך בשינוי פרדיגמה מהותי: התייחסות לקוד כאל משאב "מתכלה" (Disposable Code).

במציאות החדשה, הקניין הרוחני (IP) האמיתי אינו שורות הקוד עצמן, אלא ההקשר הארגוני, החוקים העסקיים והאפיונים שהוגדרו (Specifications & Rules).

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

 

השורה התחתונה: בניית סביבת Sandbox מבוקרת

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

הצעד הראשון והנכון ביותר הוא הקמת AI Software Factory Sandbox. סביבה מבוקרת, מאובטחת ומדידה שעבורה נבחר צוות אחד, פרויקט ממוקד או רכיב ספציפי. שם נוכל להגדיר את מנוע הקונטקסט, לנסח את סט החוקים הראשוני (Rulebook) ולבנות את היכולות – ללא סיכון למערכות הליבה הקיימות.

רק לאחר הצלחה מוכחת וגיבוש מודל עבודה נכון (Spec-Driven Development), ניתן להרחיב את הפעילות לארגון כולו בביטחון, הרבה לפני ההגעה אל אותה חומת 18 החודשים.

הגלקסיה החדשה כבר כאן. נשמח לשבת יחד, לשתף מתובנות השטח שלנו, ולחשוב איך לבנות את מפת הדרכים הנכונה עבור הארגון שלכם. דברו איתנו Hello@s-strategy.com

 

 

יש לכם AI בארגון. אז למה שום דבר לא השתנה?

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

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

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

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

אבל במקרים רבים זו בכלל לא הבעיה.

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

"אימוץ AI" הוא שם לארבע בעיות משלימות.

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

מה ההבדל בין גישה לשימוש ב-AI לבין ערך עסקי מ-AI?

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

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

מודל ארבעת השלבים של אימוץ AI:

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

 

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

חיסכון במשימה לא בהכרח מקצר את התהליך

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

אבל מה קורה למסמך אחר כך?

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

המשימה התקצרה. התהליך כמעט לא השתנה.

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

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

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

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

שימוש הוא אינדיקציה. לא תוצאה.

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

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

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

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

לכן השאלה "כמה עובדים משתמשים ב-AI?" היא רק נקודת פתיחה.

השאלה המעניינת יותר היא: איזו עבודה מתבצעת היום אחרת בגלל AI?

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

לא רק מה התקצר. מה השתנה או נעלם?

כדי לזהות ערך אמיתי, כדאי להסתכל על תהליכי עבודה ולא רק על משימות.

ניקח לדוגמה תהליך הכנת הצעה ללקוח.

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

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

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

השינוי המשמעותי מתחיל כשהתהליך עצמו משתנה.

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

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

AI יוצר ערך כשהוא מקצר שלבים בתהליך.

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

איזו החלטה מתקבלת אחרת בזכות AI?

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

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

עכשיו AI מאפשר לעדכן ולסכם את אותו מידע מדי בוקר.

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

השינוי מתחיל כשגם שגרת הניהול משתנה.

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

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

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

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

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

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

איזה מדד עסקי אמור להשתפר?

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

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

"אם המהלך הזה מצליח, אנחנו מצפים לראות שינוי ב…"

התשובה לא צריכה להיות "כמות המשתמשים".

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

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

אם צוות שירות מזהה בעיות מוקדם יותר, האם זמן הטיפול ירד?

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

אם מדד לא השתנה – לא קרה שינוי.

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

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

זו נקודת מוצא אחרת לגמרי.

ומה עושים עם הזמן שהתפנה – זו השאלה הניהולית החשובה ביותר ב-AI

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

זמן שנחסך ולא מנוהל – נעלם.

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

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

זו כבר אינה החלטה טכנולוגית. זו החלטה ניהולית.

חיסכון בזמן אינו סוף החישוב. השאלה היא לאיזה ערך הארגון מתכוון להמיר את הזמן הזה.

 

כלי ניהולי להערכת אימוץ AI

במקום להתחיל מהכלי, כדאי לבחור תהליך עבודה מוגדר ולשאול עליו חמש שאלות:

1איזו עבודה באמת השתנתה?

לא האם העובדים משתמשים ב-AI, אלא מה הם עושים היום אחרת.

2איזה שלב נעלם?

האם שיפרנו משימה נקודתית או את זמן המחזור של התהליך כולו?

3איזו החלטה מתקבלת אחרת?

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

4איזה מדד עסקי אמור להשתפר?

מה אמור להשתנות אם ההטמעה מצליחה?

5מה עושים עם הקיבולת שהתפנתה?

איך ממירים יעילות נקודתית לערך ארגוני?

 

השאלות האלה משנות גם את הדיון בהנהלה.

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

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

זה כבר דיון אחר לגמרי על הטמעת AI.

הטמעת AI היא שינוי בדרך שבה הארגון עובד

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

אבל אף אחד מאלה אינו היעד.

היעד הוא לשנות עבודה בצורה שמייצרת ערך.

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

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

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

 

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

 

מרישיונות AI ל-ROI

לא מרכיבים מנוע סילון על עגלה עם סוס 

מה השתנה?

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

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

זו לא בעיית AI – זה כשל תפעולי "בקילומטר האחרון".

 

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

 

הדרך להפוך השקעה טכנולוגית לערך עסקי מדיד

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

אנחנו לא שואלים "איך לשלב AI בתהליך" אלא "למה התהליך עדיין בנוי כפי שהוא?".
זהו "פער האימוץ" שכל מנהל מכיר: הארגון משקיע הון ברישיונות וכלים, אך רק כ-5% מפיילוטי ה-AI בארגונים באמת מחוללים שינוי ומגיעים ל-ROI מדיד, כך עולה *ממחקר MIT שבחן מעל 300 יישומי AI ארגוניים ב-2025.

**טרנספורמציות AI מוצלחות עוקבות אחר דפוס 1:3:5: 

על כל דולר שמושקע בטכנולוגיה, 

מושקעים 3 דולרים בעיצוב מחדש של תהליכים, 

ו-5 דולרים בבניית יכולות ובאימוץ. 

"פער האימוץ" הוא לא בעיית עובדים – הוא כשל ניהולי.

* MIT– The GenAI Divide: State of AI in Business 2025 

 ** 08/2026 Mckinsey- How to close the agentic adoption gap 

 

הפתרון: מומחה למצוינות תפעולית שמצטרף לצוות ומצמצם את הפער   

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

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

 

הדרישות מהמומחה:

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

 

המודל פותר שלושה פערים מרכזיים:

  • פער ב-ROI: רישיונות שנרכשו והוכחות היתכנות (PoCs) שהצליחו טכנית, אך לא תורגמו לערך עסקי.
  • פער בין הנהלה לשטח: תפיסת התהליכים בהנהלה שונה לעיתים קרובות ב-50% ויותר מהמציאות התפעולית היומיומית.
  • פער האחריות: מי אמון על שינוי תהליכי והרגלי העבודה במחלקות העסקיות והתפעוליות? הפער כיום בלי בעלים.

 

ההתחייבות שלנו: אימפקט ראשון שניתן למדוד תוך 30 יום   
תהליך מובנה עם התחייבות לתוצאה בזמן קצר:

שבועפעילות
שבוע 1-2אבחון ובחירת "כאב"

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

שבוע 3בניית הפתרון הראשון

נבנה פתרון Hands-on – סוכן, אוטומציה, Skill או Workflow –
על גבי הכלים הקיימים אצלכם, בשיתוף מלא עם הצוות.

שבוע 4מדידת השינוי

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

*הצוות- מחלקות עסקיות ותפעוליות:
מחלקות עסקיות, שרות לקוחות, משאבי אנוש, לשכה משפטית, כלכלית, שיווק, לוגיסטיקה, רווחה וכו'

 

רגע לפני שממשיכים   

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

 

איך ההצלחה נראית בשטח?   

הערך אינו תיאורטי. אצל לקוחותינו התהליך הזה כבר הוביל לתוצאות דרמטיות:

– תהליך ניתוח דוחות שנמשך 9 ימי עבודה בכל חודש, קוצר לשעה אחת בלבד.

– משימה תפעולית שנמשכה 5 שעות, ירדה ל-2 דקות באמצעות סוכן AI ומייל אוטומטי.

 

הצעד הבא: פיילוט. נתחיל מתהליך אחד שכואב    

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

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

oren@s-strategy.com