אינטגרציה בין מערכות

• נפילות

  הצד השני נעלם, וההבטחות שלכם עדיין עומדות.

• כפילויות

  ריצה כפולה חייבת להיות בטוחה, כי בסוף היא קורית.

• סתירות

  שתי מערכות, אמת אחת, וכלל שקובע מי מנצח.

• עקיבות

  שש שעות אחר כך, מישהו צריך לראות מה קרה.

הצד השני נעלם

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

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

אותו דבר קורה פעמיים

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

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

שתי מערכות לא מסכימות מה נכון

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

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

אף אחד לא יודע מה קרה

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

בנינו הרבה עבודה סביב WhatsApp Business API, כולל המוצר שלנו wagate.app, כך שזה מקרה שבו המציאות התפעולית היא כזו שאנחנו חיים איתה ולא כזו שקראנו עליה.

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

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

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

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

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

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

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

ספרו לנו מה צריך להתחבר