סשן אימוץ AI אצלי נראה ככה: שעה עד שעתיים שבהן המנהלים זורקים עליי את כל הכאבים שלהם, ואז אחד עד שלושה תהליכים, ולכל אחד מהם יעד מדיד. הסשן האחרון נמשך 3.5 שעות והיה אצל מותג אופניים עם שני סניפים ומכירות אונליין, וטיפלנו בשני תהליכים.
הראשון היה ניהול הוצאות: כל קבלה תועדה ידנית דרך Monday form, צולמה והועלתה ידנית ל-Drive — כמה שעות בשבוע של המנהל עצמו. בסוף כל חודש, כשמשווים את ההוצאות מהאתר של ויזה לקובץ ב-Monday, מתגלה שכ-15% מההוצאות בכלל לא מתועדות.
זה לא כאב תיאורטי. הוצאה בלי קבלה היא לא הוצאה מוכרת, ובחברה בע"מ זה גם עושה בלגן בדיווח לרשויות. כלומר התהליך הידני לא רק אכל שעות של המנהל — כל קבלה שנופלת בדרך היא הוצאה שלא תוכר בסוף השנה.
למה זה קורה דווקא בעסקים שגדלים
העסק הזה מצליח וגדל מהר, וזאת בדיוק הבעיה. ככל שהעסק גדל, הניהול היומיומי נהיה מורכב יותר והמנהלים נשאבים אליו. אין רגע להרים את הראש ולסדר את התהליכים עצמם כך שיחזיקו בסקייל.
התוצאה היא תהליכים שנבנו כשהעסק היה חצי מהגודל שלו, ועדיין מוחזקים בחיים על ידי בן אדם שמעביר מידע ידנית ממקום למקום. זה עובד. זה פשוט לא מחזיק בסקייל, וזה נשבר בשקט — 15% מההוצאות שנעלמות זה בדיוק סוג הכשל שאף אחד לא שם לב אליו עד שסופרים.
איך סשן כזה בנוי
שעה-שעתיים של פריקה
מתחילים בשעה עד שעתיים שבהן המנהלים והמנהלות זורקים עליי את כל הכאבים שלהם. בלי אג'נדה ובלי סדר. חלק מזה זה מיפוי תהליכים, וחלק מזה זה פשוט לפרוק — וגם לזה יש ערך, בלי קשר.
מה שאני מחפש בשיחה הזאת הוא מקומות שבהם מידע יושב במערכת אחת ונדרש במערכת אחרת, ובן אדם משמש כצינור ההעברה ביניהן. שם נמצא כמעט תמיד הזמן המבוזבז.
השעה הזאת גם עושה טוב למנהלים עצמם. בעסק שגדל מהר אין הרבה הזדמנויות לשבת ולהגיד בקול רם מה לא עובד, בלי שמישהו מיד מבקש פתרון.
בוחרים אחד עד שלושה תהליכים
אחרי הפריקה מגדירים אחד עד שלושה תהליכים שרוצים לשפר, לא יותר. לכל אחד מהם מגדירים יעד מדיד, ומוודאים שהוא כזה שמייצר ROI אמיתי לעסק. בגדול, יעד טוב נופל לאחת מארבע קטגוריות:
- שעות עבודה של עובד
- שעות עבודה של מנהל
- צמצום הוצאות
- הגדלת הכנסות
אם היעד לא נופל לאחת מארבע האלה, הוא לא באמת יעד. "לעבוד בצורה חכמה יותר" זה לא משהו שאפשר למדוד בסוף החודש.
ההגבלה למספר קטן של תהליכים היא לא צניעות. מהניסיון שלי, סשן שנוגע בשמונה דברים משאיר שמונה דברים חצי עשויים, והם לא שורדים את השבוע העמוס הראשון.
שמים את קלוד במרכז
מכאן מתחילים לעבוד. ברוב המוחלט של התהליכים אני לא ממציא כלום מיוחד: אני מנסה לשבור את חסמי המידע ולשים את קלוד במרכז באמצעות קונקטורים. חלק מהקונקטורים רשמיים וקיימים, וחלק אני בונה במקום, תוך כדי הסשן.
זאת הסיבה שאני עובד עם Claude Code ולא רק עם צ'אט. כשחסר חיבור לכלי מסוים, אפשר לבנות אותו באותו יום במקום להוסיף אותו לרשימת המשאלות.
חשוב להגיד מה זה לא: אני לא מחליף להם מערכות. Monday נשאר Monday, וה-Drive נשאר Drive כמו שהוא. המטרה היא לשבור את החסם בין המערכות, לא להתחיל פרויקט החלפת מערכות בעסק שגם ככה אין לו זמן.
דואגים שימשיכו בלעדיי
השלב האחרון הוא להשאיר אותם עצמאיים. ברגע שקלוד יושב במרכז והחיבורים עובדים, הם יכולים להמשיך בלי שאני בתמונה — עם scheduled tasks לדברים שקורים בקצב קבוע, ועם עבודה מול Cowork בכל השאר.
זה המבחן האמיתי של סשן כזה. אם הם צריכים אותי בשביל השינוי הבא, לא עשיתי את העבודה.
הקבלות: המקרה הקונקרטי
התהליך הראשון שטיפלנו בו הוא זה שתיארתי בהתחלה. שווה לפרק אותו לגורמים, כי הוא נראה כמו הרבה תהליכים אחרים שאני פוגש.
הזרימה הישנה הייתה: מישהו מצלם את הקבלה, מעלה אותה ידנית ל-Drive, וממלא Monday form כדי לתעד אותה. שלושה מגעים אנושיים לכל קבלה. בעסק עם שני סניפים ומכירות אונליין, זה כמה שעות עבודה בשבוע — של המנהל עצמו, לא של עובד זוטר.
שווה לעצור על הפרט הזה: זאת עבודה של המנהל. תיעוד קבלות הוא בדיוק סוג המשימה שהיינו מצפים שתואצל למישהו אחר, והיא לא הואצלה. כשעבודה כזאת נדבקת לאדם הכי יקר בעסק, זה בדרך כלל סימן שהתהליך לא באמת מוגדר — הוא מוחזק בראש של מישהו.
ואז יש את הבקרה. בסוף כל חודש משווים את דף החיוב מהאתר של ויזה לקובץ ב-Monday, ומחפשים חורים. הפער שהם מצאו היה כ-15%. כלומר לא רק שהתהליך יקר בזמן — הוא גם לא עובד. הבקרה החודשית הזאת היא מנגנון גילוי, לא מנגנון תיקון: היא מספרת לך באיחור של חודש מה כבר איבדת.
שימו לב גם מה הפער הזה אומר על המספרים של העסק. אם 15% מההוצאות לא מתועדות, הקובץ במאנדיי הוא לא תמונת ההוצאות של העסק, הוא 85% ממנה — וכל מי שיסתכל עליו רואה תמונה חלקית.
הפתרון עצמו היה יחסית פשוט לבנייה. זה כמעט תמיד המצב, וזאת הנקודה: רוב הזמן בסשן כזה הולך על להבין ולהגדיר, לא על לבנות. החלק הקשה הוא להסכים מה בדיוק התהליך אמור לעשות ואיך נדע שהוא עבד.
מה שאין לי הוא המספר של אחרי. ההשוואה הבאה בסוף החודש, מול אותו דף חיוב ומול אותו קובץ, היא זו שתגיד אם הפער נסגר. עד אז יש כאן מספר של לפני בלבד.
התהליך השני
התהליך השני שטיפלנו בו הוא שירות לקוחות, והוא מסובך ומעניין מספיק כדי לקבל פוסט משלו. אכתוב עליו בנפרד.
מה באמת קרה שם
ברמה הטכנית לא בניתי שם שום דבר מרשים. אין אלגוריתם, אין מודל, אין שום דבר שמישהו יכתוב עליו מאמר.
מה שקרה זה שבעל עסק ראה בפעם הראשונה את Claude Code ו-Cowork עושים דברים ולא רק עונים על שאלות. זה שינוי תפיסה, ולדעתי הוא שווה יותר מכל תהליך בודד שבנינו באותו יום — כי אחרי שמישהו רואה את זה, הוא מתחיל לזהות לבד את התהליכים הבאים.
כל הקרדיט על החלק הקשה הולך לאנשים ב-SF שמניעים את המהפכה הזאת. אני נהנה להיות המאסף שלהם כאן בישראל.
מה שלמדתי מזה
בסוף היום הזה יצא עסק שמוכן לגדול קצת יותר ממה שהיה בבוקר. לא בגלל שהוספתי לו יכולת מרשימה, אלא בגלל ששני תהליכים מרכזיים קיבלו הגדרה ויעד מדיד במקום להישען על הזיכרון של מישהו.
הדבר הכי חשוב בסשן כזה הוא לא הכלים. זה הסירוב לגעת ביותר משלושה תהליכים, וההתעקשות שלכל אחד מהם יהיה מספר שאפשר להסתכל עליו בסוף החודש. עסק שגדל מהר לא סובל ממחסור ברעיונות לשיפור — הוא סובל מעודף שלהם.
הכלים עצמם ימשיכו להשתנות כל כמה חודשים. מה שלא משתנה זה השאלה איפה בן אדם עדיין משמש כצינור העברת מידע בין שתי מערכות, ומה זה עולה לעסק בשעות ובכסף. אם התיאור הזה נשמע כמו משהו שהעסק שלכם צריך, ככה נראה התהליך אצלי.