מערכת ניהול עסק מבוססת AI

ארבעה מקומות שעובדים

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

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

שלושה מקומות שבהם זו טעות

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

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

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

למה לא צריך להחליף את המערכת

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

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

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

מה המודל רשאי לראות

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

שלוש שאלות, בסדר הזה:

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

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

מאיפה להתחיל, בסדר הנכון

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

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

איך אני עובד על זה

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

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