האם הנתונים שלכם בשלים ל-AI, ואיך בודקים את זה לבד

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

מה אומר ‘נתונים בשלים ל-AI’#

ארבע תכונות, ו’נקיים’ אינה אחת מהן.

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

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

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

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

בדיקה שאפשר לעשות לבד, לפני שמזמינים יועץ#

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

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

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

כמה עולה לסדר את זה, ומה קובע את העלות#

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

• כמה מערכות צריך להצליב. מערכת אחת היא חשבון פשוט. שלוש מערכות עם שלושה מזהי לקוח שונים הן פרויקט.
• האם הזהות עקבית. שאלה 4 שלמעלה היא גורם העלות. התאמה של מעל 90% היא סדר וניקיון; התאמה של כ-60% אומרת שמישהו בונה ומתחזק מנגנון התאמה קבוע.
• האם צריך לשחזר היסטוריה. שחזור תקופה שמעולם לא נרשמה כראוי הוא סוג עבודת המוכנות היקר ביותר, ולרוב עדיף להחליף אותו בתיחום המודל לתקופה האיתנה.
• לאן התשובה צריכה להגיע. דוח שנשלח במייל זול. המלצה שמופיעה בתוך Priority או SAP מול הקניין בזמן ההזמנה עולה יותר, ושווה יותר, כי היא זו שמשנה החלטות בפועל.

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

מתי התשובה הכנה היא ‘עדיין לא’#

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

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

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

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

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

איפה עבודת הנתונים יושבת אצלנו#

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

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

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