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

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

מה אפשר ללמוד מתקלה בחישוב דמי חופשה?

במרץ 2024 דיווח Retail Gazette על תקלה במערכת השכר של Asda. לפי הודעת החברה שצוטטה בכתבה, כ־9,500 עובדים שעתיים הושפעו מחישוב חופשה שגוי בעת המעבר למערכות חדשות. החברה אמרה שבדיקות מקדימות זיהו את הבעיה ושהיא פועלת לתיקונה; ארגון העובדים דיווח שחלק מהעובדים עדיין קיבלו פחות מהמגיע להם. זהו דיווח היסטורי עם עמדות שונות, לא ממצא חקירה שלנו.

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

בונים לוח עסקי לפני רשימת בדיקות

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

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

בוחרים דוגמאות שמכריחות את הכלל לעבוד

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

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

משווים תוצאה עסקית, לא רק סכום כולל

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

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

דוגמה מתועדת מהכלים של Julius

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

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

מתי אפשר לאשר מעבר?

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

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