Gov-Labs: תשע תובנות על איך חדשנות ציבורית מתורגמת לרעיונות למוצרים אמיתיים

פשוט WoW   

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

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

מהי Gov-Labs? 

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

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

 

מאז, שנתיים אחרי 

גאה לשתף שהתקיימו שש תוכניות Gov-Labs:
18 קבוצות, מעל 200 משתתפים ומשתתפות, מ-23 גופים ציבוריים שונים. 

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

לכל תוכנית יש את האופי הייחודי שלה, אבל המכנה המשותף ברור: 

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

 

רגע אישי 

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

 

שותפויות על הדרך 

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

  • גורמים רבים במערך הדיגיטל (מעבר ליחידת ההאצה) 
  • Google Cloud ישראל (GCP) 
  • Amazon Web Services (AWS) 
  • Salesforce ישראל (חלק ממיזם Nimbus) 
  • ג’וינט ישראל 
  • נציבות שירות המדינה 

חברות טכנולוגיה וייעוץ שתרמו לפיתוח: 

  • Moveo
  • Designit 
  • Matrix 
  • Proceed 

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

 

9 תובנות עיקריות מהדרך שאני לוקח איתי וחשוב לי לשתף (בלי סדר חשיבות): 

 

  1. תמיד, אבל תמיד – להתכונן לגמישות.

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

  

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

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

  

  1. לפתח כבר על התשתיות של המשרד, מהיום הראשון.

זה אולי מפתה לעבוד על סביבה זמנית, להעתיק GIT או להקים משהו חיצוני “רק לשלב הפיילוט”, אבל זה מתנקם בהמשך. כדי לשמור על המשכיות, האימפקט האמיתי נוצר כשכבר מהשלבים הראשונים עובדים על סביבת הפיתוח הממשלתית – עם הכללים, ההנחיות והתשתיות של המשרד. כך המוצר הופך לחלק מה-DNA הארגוני, לא רק ניסוי חולף. 

  

  1. כל הקבוצה מעורבת כל הזמן.

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

  

  1. לדבר בשפה אחת. באמת אחת.

זה נשמע פשוט – כולנו מדברים עברית. בפועל, גילינו שלכל תחום יש שפה משלו: עולם היזמות, עולם הממשל, עולם הטכנולוגיה. ההבדלים האלו יצרו לא פעם תסכול – טבעי ומובן. אבל לאורך הדרך נבנה שריר חדש: היכולת לתרגם, להסביר, וליצור שפה משותפת. זו אולי אחת המתנות הגדולות ביותר של Gov-Labs, היא מלמדת לדבר “יזמות ממשלתית”. 

  

  1. לצאת כמה שיותר מוקדם לשטח.

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

  

  1. לספר סיפור – כמו יזם אמיתי.

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

  

  1. לזכור שהקבוצה היא הכוח.

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

  

  1. יש אנשים מדהימים במגזר הציבורי. באמת.

מאות משתתפות ומשתתפים הגיעו מכל רחבי הארץ – אנשים עמוסים, נוגעים ביום-יום באזרח, ובכל זאת בוחרים לפנות זמן, להיכנס לעולם חדש, ללמוד, ולהתמסר. הם לובשים את “חליפת היזמות” שלהם ובאים לשנות מבפנים. לראות את זה מקרוב, זה מרגש כל פעם מחדש. אני גאה להיות חלק מהמסע הזה, ולהגיד בקול רם: יש כאן אנשים נפלאים שעושים שינוי אמיתי. 

 

לסיום 

זה לא באמת סיכום – הדרך רק ממשיכה.
תוכניות 7 ו-8 כבר מעבר לפינה. 

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

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

אשמח לשמוע מכם, ליאור lior.israel@s-strategy.com 

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

העבודה שלא רואים: מה באמת קורה אחרי שמטמיעים AI

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

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

עכשיו תשבו ליד הנציגה.

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

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

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

 

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

 

AI לא רק מחליף משימות. הוא משנה אותן

מחקר של Workday שפורסם ב-2026 מצא שכמעט 40% מהזמן שעובדים מדווחים כי חסכו באמצעות AI נאבד מחדש בתיקון טעויות, ניסוח מחדש ובדיקת התוצרים. [1]

בקרב משתמשים יומיומיים 77% אמרו שהם בודקים עבודה שהפיק AI לפחות באותה קפדנות שבה הם בודקים עבודה אנושית.

BCG מצאה תמונה דומה מזווית אחרת. בסקר גלובלי בקרב 11,749 עובדים, 52% מהנשאלים דיווחו שהם מקדישים יותר זמן מבעבר לבדיקה ולתיקון של תוצרים שנוצרו באמצעות AI. במקביל, 47% מהעובדים ציינו שהזמן שהם משקיעים בהנחיית כלי AI, בבדיקת התוצאות ובתיקונן כבר גדול מהזמן שהם משקיעים בביצוע המשימה עצמה. [2]

 

כלומר במקרים רבים העבודה לא נעלמת, היא עוברת מקום:

מכתיבת המסמך לבדיקתו.

מחיפוש המידע לאימות שלו.

מביצוע הפעולה להנחיית המערכת.

מהפקת התוצר לאחריות על מה שהמערכת הפיקה.

 

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

 

איך זה נראה בארגון ישראלי?

אנליסטית בחברת אשראי שמכינה ניתוח להנהלה.

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

נשמע מצוין.

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

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

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

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

 

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

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

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

 

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

 

לעבודה החדשה הזו כבר נתנו שם

בדוח Work AI Index של Glean היא נקראת botsitting.

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

לפי הסקר של Glean, עובדים משקיעים בכך 6.4 שעות בשבוע בממוצע. 37% מהזמן שהם עובדים עם AI מוקדש ל-botsitting, מעט יותר מ-36% שמוקדשים לשימוש בכלי לצורך הפקת העבודה עצמה. [3]

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

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

 

הבעיה אינה שהשכבה הזאת קיימת, להפך – היא חיונית.

הבעיה מתחילה כשהיא בלתי נראית.

 

ההנהלה רואה את הכלי. העובד רואה את העבודה

נניח שארגון הטמיע Copilot Enterprise או פתרון ארגוני אחר.

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

קשה הרבה יותר לראות את מה שקורה דקות לאחר מכן בשטח:

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

 

אם המידע הזה לא חוזר להנהלה נוצר פער מסוכן בין adoption לבין value.

אפשר להגיע לשיעורי שימוש גבוהים מאוד ועדיין לא לדעת אם הארגון באמת עובד טוב יותר.

זו בדיוק הסיבה ש-BCG טוענת כיום שהשלב הבא באימוץ AI אינו עוד כלי אלא עיצוב מחדש של תהליכי עבודה. [4] רק 36% מהעובדים בסקר שלה אמרו שקיבלו הכשרה מספקת למיומנויות הנדרשות לטרנספורמציית AI.

 

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

Gallup מצאה שבעולם רק אחד מכל ארבעה עובדים מסכים מאוד שהדעה שלו נחשבת במקום העבודה.[5]

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

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

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

שהכלי מקצר הכנת הצעת מחיר אבל מחייב מעבר ידני על כל סעיף.

שה-agent חוסך עבודה מצוות אחד אבל מייצר חריגים והזיות שעלולים להגיע לצוות אחר.

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

 

זהו ידע תפעולי יקר ערך.

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

 

הבעיה אינה התנגדות לשינוי

זו אולי הנקודה החשובה ביותר שעל הנהלות להבין.

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

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

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

הוא עלול לחשוב שהתגובה תהיה "אתה לא יודע לכתוב prompt טוב מספיק."

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

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

 

אז מה הנהלה צריכה למדוד?

לא רק שימוש, לא רק מספר רישיונות, אפילו לא רק "שעות שנחסכו".

 

אנחנו מציעים להסתכל על AI כעל שינוי במערכת העבודה ולשאול ארבע שאלות מפתח בכל תהליך מרכזי:

1מה באמת התקצר?

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

2איזו עבודה חדשה נוצרה?

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

3לאן העבודה עברה?

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

4מה העובדים יודעים שאנחנו עדיין לא יודעים?

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

 

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

אלה שאלות של אסטרטגיה, תפעול, טכנולוגיה וניהול.

 

השלב הבא באימוץ AI הוא לא בהכרח עוד AI

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

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

פחות לשאול "מי משתמש?" ויותר לשאול "איך העבודה השתנתה?"

פחות למדוד את מה שהמערכת עשתה ויותר להבין את המאמץ האנושי שנדרש סביבה.

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

 

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

 

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

 

מקורות

[1] Workday Research 2026 – Companies Are Leaving AI Gains on the Table

[2] BCG – AI at Work 2026

[3] Glean – Work AI Index 2026

[4] BCG – Why AI Change Is Actually a People Change

[5] Gallup – Employee Voice

[6]  McKinsey – AI transformations run on trust

 

אתם שואלים את השאלה הלא נכונה: מדריך הישרדות בגלקסיית ה-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 בארגונים. בהמשך הסדרה נעמיק גם בזווית האנושית – איך השינוי הזה נראה מנקודת המבט של העובד עצמו.