אפיון וריאציות בתהליך עסקי: מה יהיה הגדרה ומה ידרוש פיתוח?

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

מה מדגים המקרה של Mercedes?

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

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

אוספים מקרים לפני שמשרטטים מסך

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

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

מחלקים את השונות לשלוש קבוצות

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

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

מתי צריך מסך הגדרות ומתי שינוי קוד?

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

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

דוגמה מתועדת ממערכת התוכן שלנו

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

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

בודקים שילובים ודרך יציאה לחריג

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

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