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