להחליף ERP או לחבר שכבת חישוב: מבחן סיבת הבעיה לפני פרויקט יקר

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

שתי תקלות שנראות זהות מבחוץ

מנהל אומר: "אני לא מצליח לדעת מה הרווחיות לפי לקוח". זה יכול להיות אחד משניים.

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

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

ההבדל בין השתיים הוא ההבדל בין פרויקט של שבועות לפרויקט של רבעונים. הטבלה הבאה מפרידה ביניהן לפי תסמין.

איך מבדילים בין השתיים לפי תסמין?

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

חמישה מבחנים שאפשר לסיים בשבוע

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

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

מה זו שכבת חישוב, ומה היא לא

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

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

והיא לא:

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

ראו גם חיבור CRM ו-ERP ל-BI לגבי מה קורה כשהשכבה הזו הופכת לדשבורד.

כמה עולה להריץ שכבה שרק קוראת?

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

בנוסף, מדיניות השימוש ההוגן מפרסמת מגבלות שאפשר לתכנן לפיהן:

• עד 100 קריאות API בדקה למשתמש.
• עד 15 בקשות בתור בו זמנית, מתוכן עד 10 מטופלות במקביל.
• בקשה שמעבדת יותר משלוש דקות נזרקת ומחזירה שגיאה.
• 5,000 בקשות בחלון נע של 300 שניות.
• בקשה שנחסמת מקבלת HTTP 429.

המשמעות התכנונית פשוטה: שכבה שקוראת בבת אחת עם $filter ו-$select וממעטת בקריאות היא זולה וצפויה, ושכבה שמושכת רשומה אחת בכל פעם תיתקל בקיר. לפירוט השגיאות עצמן ראו אבחון שגיאות OData ב-Priority.

מתי החלפה באמת התשובה

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

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

מקורות

• Priority REST API - Transaction Counting and Fair Use Policy
• Priority REST API - Querying data