אין כאן מחירון - התעריפים משתנים יותר מדי מכדי להיות שימושיים. מה שכן עובר הוא חמשת הגורמים שמזיזים הערכה בסדרי גודל, והשאלות שהופכות בקשה בלתי-ניתנת-לתמחור לניתנת.
עיקרי הדברים
- כל מי שמתמחר אינטגרציה לפני שראה את ההתקנה מנחש. אותן שתי מערכות אצל שני לקוחות יכולות להיות שונות בסדר גודל בגלל שדות מותאמים שאף אחד לא תיעד.
- התאמת זהויות היא בדרך כלל הסעיף הגדול ביותר וזה שאף אחד לא מתקצב. ההחלטה מתי שתי רשומות הן אותו לקוח היא לוגיקה עסקית, לא קוד.
- האם הזרימה יוצרת התחייבות בעולם האמיתי משנה את המחיר. קריאת נתונים זולה; הפקת מסמך מס או הזמנת שליח דורשים הגנה מכפילות, התאמה ותור שגיאות.
- לתקצב תחזוקה שוטפת בנפרד. אינטגרציה אינה מוצר שנמסר - היא תלויה במערכות שמשתנות בלי להודיע לך.
אני לא מפרסם כאן מחירון, ולא מתוך התחמקות. תעריפי אינטגרציה משתנים לפי המערכות, ההתקנה הספציפית, ומי מבצע - וכל טווח שהייתי כותב היה שגוי עבור רוב הקוראים, ומישהו היה בונה עליו הצעת מחיר. מה שכן עובר בין פרויקטים הוא מה מזיז את המספר, וזה מה שמאפשר לך לשאול את השאלות הנכונות ולזהות הצעה שנשענת על ניחוש.
הכלל שקודם לכל השאר
אי אפשר לתמחר אינטגרציה בלי לראות את ההתקנה.
זה נשמע כמו הסתייגות של ספק, וזו עובדה: אותן שתי מערכות אצל שני לקוחות יכולות לדרוש קוד שונה לגמרי. בפריוריטי, ב-SAP Business One וב-CRM - בכולן ההתקנה צוברת שדות וטפסים מותאמים לאורך שנים.
מה שזה אומר מעשית: הצעה שניתנה אחרי שיחת טלפון בלבד היא הערכה, לא תמחור. הפער בין הערכה מהתיעוד להערכה אחרי שראית את הסכימה הוא פי כמה - לא אחוזים.
מה שכן אפשר: לתמחר יום אפיון קצר, שבסופו יש מספר אמיתי. ספק שמציע את זה עובד נכון; ספק שנותן מספר מיד לוקח סיכון שאתה תשלם עליו בסוף.
חמשת הגורמים שמזיזים את המספר
1. כמה זרימות, ולאיזה כיוון
"לחבר את המערכות" אינו פרויקט אחד. הוא מתפרק לזרימות חד-כיווניות, ולכל אחת עלות משלה.
זרימה שקוראת נתונים זולה. זרימה שכותבת יקרה יותר. סנכרון דו-כיווני של אותו שדה הוא הכי יקר - ולרוב גם הפתרון השגוי.
מה לשאול: "כמה זרימות נפרדות יש כאן, ולאיזה כיוון?" אם התשובה היא "שהכול יתעדכן בשני הכיוונים", זו לא דרישה - זו בקשה שצריך לפרק.
2. התאמת זהויות - הסעיף שאף אחד לא מתקצב
זו בדרך כלל העבודה הגדולה ביותר, והיא לא נראית בתיאור הפרויקט.
מערכת אחת מזהה לקוח במייל. השנייה בכרטיס עם מספר. ההחלטה מתי שתי רשומות הן אותו לקוח היא לוגיקה עסקית, ולפעמים אין לה תשובה נקייה.
מה שמשפיע על המחיר:
- יש מפתח משותף? ח"פ בשני הצדדים מוזיל דרמטית.
- הנתונים הקיימים נקיים? אם יש כפילויות בבסיס, זו עבודת ניקוי לפני האינטגרציה - ולא במקומה.
- מה קורה בלי התאמה ודאית? תור לבדיקה אנושית עולה יותר לבנות ופחות לתקן.
השאלה ששווה לשאול ראשונה: "יש שדה משותף שמזהה לקוח בוודאות בשתי המערכות?" תשובה שלילית מכפילה את ההערכה.
3. האם זה יוצר התחייבות בעולם
זה ההבדל שהכי מפתיע לקוחות.
| הזרימה | מה נדרש |
|---|---|
| קריאת נתונים לדוח | בסיסי |
| עדכון שדה במערכת | + טיפול בשגיאות |
| הפקת מסמך מס | + הגנה מכפילות, התאמה, תור שגיאות |
| הזמנת שליח, חיוב אשראי | אותו דבר |
הסיבה: מסמך מס לא נמחק, שליח שהוזמן פעמיים מגיע פעמיים. פעולות כאלה דורשות אידמפוטנטיות, תהליך התאמה יומי ותור שגיאות שאדם רואה - וזה שליש עד חצי מהעבודה, לא תוספת.
ספק שמתמחר זרימת חשבוניות באותו מחיר כמו זרימת קריאה או לא מבין את זה או לא יבנה את זה.
4. דחיפות
"בזמן אמת" מייקר. תשאול מתוזמן פשוט וזול; דחיפת אירועים דורשת נקודת קצה ציבורית, אימות, תור וטיפול בכפילויות.
וברוב המקרים רק זרימה אחת באמת דחופה. ההכרה בזה מורידה עלות בלי לפגוע בתוצאה - וזו שאלה ששווה לשאול: "מה באמת חייב להיות מיידי, ומה יכול לחכות שעה?"
5. מי מתחזק, ומה קורה כשנשבר
הסעיף שהכי מרבים להשמיט - ואינטגרציה אינה מוצר שנמסר.
היא תלויה במערכות שמשתנות: גרסה שמשנה מגבלה, טוקן שפג, משתמש שעוזב. אלה לא באגים - זו מציאות.
מה שצריך להיות מוגדר מראש: מי מטפל כשזה נשבר, בתוך כמה זמן, ומי משלם.
מה שהופך בקשה לניתנת לתמחור
אלה השאלות שאני שואל, וכל אחת מהן מזיזה את המספר:
- אילו מערכות, ובאיזו גרסה והתקנה?
- יש גישה לסביבת בדיקות? אם לא, זה מייקר ומאט.
- כמה זרימות, ולאיזה כיוון?
- יש מפתח משותף לזיהוי לקוח?
- מה נקי בנתונים הקיימים?
- יש כאן פעולה שיוצרת התחייבות?
- מה חייב להיות מיידי?
- מי מתחזק אחרי המסירה?
בקשה שאין לה תשובות לאלה אינה ניתנת לתמחור - וזו תשובה לגיטימית מספק.
מה שמייקר בלי שאף אחד התכוון
- אין סביבת בדיקות. פיתוח מול ייצור אומר עבודה זהירה יותר ותיקון טעויות אמיתיות.
- אין מי שיענה. אם השאלות לספק המערכת נענות בשבוע, לוח הזמנים נגזר מזה.
- מודול שצריך לרכוש. מתגלה באמצע, ואז זו החלטת רכש שעוצרת הכול.
- "בזמן אמת" שלא נדרש באמת.
- דרישה שהתגלתה מאוחר כי אף אחד לא תיאר את התהליך במלואו.
ומה שמוזיל
- מפתח משותף בשתי המערכות.
- לוותר על דו-כיווני לטובת נקודת מסירה אחת.
- לקבל תשאול במקום זמן אמת היכן שאפשר.
- להתחיל בזרימה אחת שמייצרת ערך, ולהרחיב.
- לנקות נתונים לפני ולא לבקש מהקוד לפצות.
שישה ממשקים, שש עבודות שונות
לפני שמדברים על שעות צריך לדעת מה בדיוק נמסר לכם. זה ההבדל הראשון והגדול ביותר:
| הממשק | מה הוא נותן לכם | איפה מתרכז המאמץ |
|---|---|---|
| REST מתועד עם מפרט | משאבים מוגדרים, קודי סטטוס, כללי עימוד | מיפוי שדות והכללים העסקיים |
| SOAP עם WSDL | חוזה נוקשה ולקוח שנוצר אוטומטית | מעטפת ומרחבי שמות, טיפוסי XML, פענוח fault |
| קובץ שהספק תומך בו, ב-SFTP או בתיקייה | קובץ שטוח בלוח זמנים קבוע | זיהוי סיום כתיבה, סדר, קידוד, עיבוד חוזר, ארכיון |
| View או עותק קריאה בבסיס הנתונים | SQL ישיר על נתונים אמיתיים | סחיפת סכימה, אין התראה על שינוי, תקרה של קריאה בלבד |
| דוח או קובץ שמגיע בדוא"ל | מה שהשולח בחר לצרף | אימות שולח, שונות בפורמט, זיהוי כפילויות |
| מסך בלבד | שום דבר תוכניתי | תחזוקה מתמשכת. המאמץ לא הופך לחד-פעמי |
שתי שורות בטבלה הזו מטעות אם קוראים אותן מהר. קובץ נראה הפשוט מכולם, ובאמת אין בו כמעט עבודת הזדהות - אבל כל מה שממשק HTTP נותן בחינם עובר לאחריותכם: מאיפה יודעים שהכתיבה הסתיימה, מה קורה כששני קבצים הגיעו בסדר הפוך, ומה עושים כשצריך לטעון מחדש יום שכבר נטען. View בבסיס נתונים נראה זול מאוד, והוא מהיר להתחלה, אבל סכימה של מערכת סגורה אינה חוזה: שדרוג גרסה יכול לשנות שם טבלה או משמעות של שדה בלי הודעה, כי מבחינת הספק זה פנימי.
למה ההזדהות מזיזה את האומדן יותר מהנתונים עצמם?
כי עבודת הנתונים חסומה - יש מספר סופי של שדות ושל כללים - ואילו עבודת ההזדהות חוזרת. מנגנון שפג תוקפו מפיל אינטגרציה שעבדה חודשים, ולרוב בשקט:
| מנגנון | מה הוא מוסיף לעבודה |
|---|---|
| מפתח קבוע בכותרת | אחסון מאובטח והחלפה מתוזמנת בלבד |
| Basic מעל TLS | אותו דבר, בתוספת משתמש אמיתי שצריך לייחס אליו פעולות |
| נקודת קצה לטוקן עם תוקף קצר | תזמון חידוש, פער שעונים, ניסיון חוזר על 401 בלי להיכנס ללולאה |
| OAuth 2.0 עם קוד הרשאה וטוקן רענון | שלב אישור שאדם חייב לבצע, אחסון והחלפה של טוקן הרענון, וחזרה לאישור כשההרשאה נשללת |
| TLS הדדי או חתימת בקשות | מחזור חיים של תעודה ומפתח, מאגר מפתחות, ותפוגה שמפילה הכול בלי אזהרה |
| רשימת כתובות מותרות או VPN | פנייה לגורם תשתית לכל סביבה ולכל שינוי כתובת, בלוח זמנים שאינו בשליטתכם |
שתי השורות התחתונות הן אלה שמפתיעות. הן כמעט לא מוסיפות קוד, והן מוסיפות תלות בגורם שלישי לכל שינוי - וזה מה שהופך שינוי קטן לשבוע.
האם קיימת סביבת בדיקות, ומה מוסיף היעדרה?
סביבת בדיקות היא מתחם נפרד עם נתונים משלו, שבו קריאה שנכשלה לא משאירה נזק. כשאין - העבודה לא נעלמת, היא עוברת מקום:
- כל בדיקה שמשנה נתונים דורשת תוכנית ביטול שנכתבת לפני ההרצה.
- רשומות בדיקה נכנסות לדוחות אמיתיים, ולכן צריך שדה סימון ומעבר ניקוי.
- שחזור תקלה מחייב להמתין למקרה אמיתי במקום לייצר אותו.
- אי אפשר לבדוק התנהגות במגבלת קצב, ולכן המגבלה מתגלה בייצור.
- חלק מהבדיקות יכולות לרוץ רק מחוץ לשעות הפעילות.
וסביבה שהנתונים בה אינם דומים לייצור היא חצי סביבה. היא לא תחשוף את הלקוח הכפול, את הרשומה עם מזהה ריק ואת השם עם תו שאינו נתמך - ואלה בדיוק המקרים שמפילים העלאה לייצור.
מי אחראי לצד השני
זה הנהג היחיד ברשימה שאינו נמדד בשעות פיתוח בכלל:
- ספק עם חוזה תמיכה ותור קריאות. תשובה תגיע, בלוח הזמנים שלו.
- ספק עם צוות שירותים מקצועיים או שותף מוסמך. תשובה עולה כסף ומגיעה.
- צוות פנימי. המהיר ביותר, אם יש לו פנאי.
- אף אחד. מפתח שעזב, מוצר שהופסק. כל דבר לא ידוע הופך לניסוי.
שני פרויקטים עם אותו היקף בדיוק יכולים להסתיים בהפרש של חודשים בגלל השורה הזו בלבד, ולכן היא צריכה להופיע באומדן במפורש ולא כהערת שוליים.
השאלה שכדאי לשאול לפני הכול
כמה זמן העבודה הידנית הזו לוקחת בחודש?
זה המספר שהופך את השיחה מ"כמה זה עולה" ל"האם זה משתלם". שעתיים בחודש כמעט אף פעם לא מצדיקות אינטגרציה עם תחזוקה. עשרים שעות - כן.
ולפעמים התשובה הכנה היא שלא כדאי, וזו תשובה שספק טוב אמור לתת.
שאלות נפוצות
כמה עולה אינטגרציה בין מערכות בישראל?
אין מספר מפורסם שימושי, כי העלות תלויה בהתקנה הספציפית, במספר הזרימות ובכיוונן, ובשאלה אם הזרימה יוצרת התחייבות בעולם האמיתי. כל מי שמתמחר לפני שראה את ההתקנה מעריך ולא מתמחר - אותן שתי מערכות אצל שני לקוחות יכולות להיות שונות בסדר גודל בגלל שדות מותאמים שאף אחד לא תיעד.
מהי בדרך כלל העלות הנסתרת הגדולה ביותר באינטגרציה?
התאמת זהויות - ההחלטה מתי שתי רשומות במערכות שונות הן אותו לקוח. זו לוגיקה עסקית ולא קוד, היא בלתי נראית בתיאור הפרויקט, והיא מכפילה הערכה כשאין מפתח משותף כמו ח"פ בשני הצדדים. כפילויות בנתונים קיימים מוסיפות עבודת ניקוי לפני האינטגרציה ולא במקומה.
למה אינטגרציית חשבוניות עולה יותר מאינטגרציית דוחות?
כי הפקת מסמך מס היא התחייבות בעולם האמיתי שלא ניתן לבטל - וכך גם הזמנת שליח או חיוב כרטיס. הזרימות האלה דורשות אידמפוטנטיות, תהליך התאמה יומי ותור שגיאות שאדם מנטר, וביחד אלה שליש עד חצי מהעבודה. ספק שמתמחר אותן כמו זרימת קריאה או לא מבין את זה או לא יבנה את זה.
אילו שאלות הופכות בקשת אינטגרציה לניתנת לתמחור?
אילו מערכות ובאיזו גרסה והתקנה; האם יש גישה לסביבת בדיקות; כמה זרימות ולאיזה כיוון; האם מפתח משותף מזהה לקוח בשתיהן; כמה נקיים הנתונים הקיימים; האם יש פעולה שיוצרת התחייבות; מה חייב להיות מיידי; ומי מתחזק אחרי המסירה. בקשה בלי התשובות האלה אינה ניתנת לתמחור, ולומר זאת זו תשובה לגיטימית.
האם לתקצב תחזוקת אינטגרציה בנפרד?
כן, כי אינטגרציה אינה מוצר שנמסר - היא תלויה במערכות שמשתנות בלי להודיע לך. גרסה שמשנה מגבלת אצווה, טוקן שפג, חשבון משתמש שמושבת: אלה מציאות ולא באגים. יש להגדיר מראש מי מטפל בתקלה, בתוך כמה זמן, ומי משלם.
למה אי אפשר לתת מחיר לכל סוג ממשק?
כי שתי התקנות של אותו מוצר אצל שני לקוחות שונות זו מזו: שדות מותאמים, גרסאות שונות, ונתונים היסטוריים בדרגות ניקיון שונות. הנהגים עוברים בין פרויקטים, המספר לא. מספר שמתפרסם בלי לראות התקנה יהפוך אצל מישהו לבסיס להצעת מחיר שגויה.
האם SOAP תמיד יקר יותר מ-REST?
לא. WSDL מייצר לקוח אוטומטית וחוסך עבודת מיפוי ידנית, וזה יתרון אמיתי. העלות בשירותי SOAP מגיעה ממקום אחר: פענוח מבנה fault, טיפוסי XML שאינם מתיישבים עם השפה שלכם, וסביבת בדיקות שלרוב אינה קיימת במערכות ותיקות.
איזו תשובה אחת משנה את האומדן הכי הרבה?
האם קיימת סביבת בדיקות עם נתונים שדומים לייצור. תשובה חיובית מקצרת כל מחזור בדיקה ומאפשרת לשחזר תקלה בזמן. תשובה שלילית מוסיפה עבודה בכל שלב, מגבילה בדיקות לשעות מסוימות, ומעבירה את הגילוי של מגבלות המערכת לייצור.
להמשך קריאה
שירות רלוונטי
אינטגרציות
לגרום למערכות שאתם כבר משלמים עליהן לדבר זו עם זו.
על הכותב
יהונתן סעדיה
מפתח פרילנסר לאוטומציה, אתרים ו-MVP
אני יהונתן סעדיה, מפתח בכיר שבונה אוטומציה עסקית, אתרים מותאמים ומוצרי MVP לעסקים קטנים ובינוניים בארה"ב, אירופה וישראל. המדריכים האלה נכתבים מתוך עבודה אמיתית עם לקוחות, לא מתיאוריה.
בוא נעבוד יחדיש לך פרויקט דומה?
ספר לי מה אתה רוצה לבנות או איזה תהליך להפוך לאוטומטי. אני חוזר תוך 24 שעות עסקים עם כמה שאלות ממוקדות, ואז עוברים על זה יחד בשיחת היכרות חינמית של 30 דקות, בלי התחייבות. בסוף יש לך היקף עבודה, לוח זמנים ומחיר קבוע - או תשובה כנה שלא שווה לבנות את זה.