Zohoשותפה עסקית
דברו איתנו
דברו איתנו
Zoho Flow

החיבור עובד. השאלה היא מה קורה ביום שהוא לא

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

שתי ריצות של אותו חיבור

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

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

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

ממה מורכב חיבור

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

מה מפעיל

הטריגר

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

כשעסקה עוברת לסטטוס "נסגרה בהצלחה"
מה מסנן

התנאי

מה שמונע מהחיבור לרוץ על כל דבר. בלעדיו הוא רץ אלפי פעמים ומייצר רעש.

רק אם הסכום מעל הסף, ורק ללקוחות חיצוניים
מה קורה

הפעולה

מה שהחיבור מבצע בצד השני, ומה הוא מחזיר בחזרה כדי שיהיה מעקב.

פתיחת הזמנה, ואז עדכון המספר חזרה בכרטיס

מתי Flow, ומתי משהו אחר

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

Flow מתאים

רוב החיבורים העסקיים

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

כדאי לבדוק

חיבור מובנה של Zoho

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

Flow לא מתאים

נפח גבוה או לוגיקה חריגה

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

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

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

מה באמת חייב לעבור?

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

לאיזה כיוון?

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

באיזו תדירות?

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

מי מקבל התראה כשזה נופל?

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

יש לכם חיבור קיים שאף אחד לא בטוח שהוא עובד?

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

מוכנים להתחיל? דברו איתנו

מה כוללת ההקמה

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

01מיפוי וצמצום

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

02כיוון ומקור קובע

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

03בנייה וטיפול בכשלים

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

04בדיקה ותיעוד

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

שאלות נפוצות

מה שנשאלנו בפועל מול מנהלי מערכות מידע.

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

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

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

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

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

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

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

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

מה משתלב עם Flow

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

נגדיר מה קורה בכשל לפני שנבנה את החיבור

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