איך מחברים CRM, אוטומציות ומערכות עבודה?

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

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

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

למה חיבורים נכשלים

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

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

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

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

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

מפת הישויות: מה יש בעסק ואיפה הוא גר

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

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

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

בעלות ברמת השדה

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

שלושה דפוסי חיבור

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

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

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

מתי הנתון זורם: אירוע או לוח זמנים

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

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

שבעה שלבים לתכנון החיבור

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

טעויות נפוצות, ומתי זה לא מתאים

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

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

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

השורה התחתונה

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

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