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