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