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

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

הכלל שקודם לכל השאר

אי אפשר לתמחר אינטגרציה בלי לראות את ההתקנה.

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

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

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

חמשת הגורמים שמזיזים את המספר

1. כמה זרימות, ולאיזה כיוון

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

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

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

2. התאמת זהויות - הסעיף שאף אחד לא מתקצב

זו בדרך כלל העבודה הגדולה ביותר, והיא לא נראית בתיאור הפרויקט.

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

מה שמשפיע על המחיר:

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

השאלה ששווה לשאול ראשונה: "יש שדה משותף שמזהה לקוח בוודאות בשתי המערכות?" תשובה שלילית מכפילה את ההערכה.

3. האם זה יוצר התחייבות בעולם

זה ההבדל שהכי מפתיע לקוחות.

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

ספק שמתמחר זרימת חשבוניות באותו מחיר כמו זרימת קריאה או לא מבין את זה או לא יבנה את זה.

4. דחיפות

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

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

5. מי מתחזק, ומה קורה כשנשבר

הסעיף שהכי מרבים להשמיט - ואינטגרציה אינה מוצר שנמסר.

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

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

מה שהופך בקשה לניתנת לתמחור

אלה השאלות שאני שואל, וכל אחת מהן מזיזה את המספר:

1. אילו מערכות, ובאיזו גרסה והתקנה?
2. יש גישה לסביבת בדיקות? אם לא, זה מייקר ומאט.
3. כמה זרימות, ולאיזה כיוון?
4. יש מפתח משותף לזיהוי לקוח?
5. מה נקי בנתונים הקיימים?
6. יש כאן פעולה שיוצרת התחייבות?
7. מה חייב להיות מיידי?
8. מי מתחזק אחרי המסירה?

בקשה שאין לה תשובות לאלה אינה ניתנת לתמחור - וזו תשובה לגיטימית מספק.

מה שמייקר בלי שאף אחד התכוון

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

ומה שמוזיל

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

השאלה שכדאי לשאול לפני הכול

כמה זמן העבודה הידנית הזו לוקחת בחודש?

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

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