פיתוח מערכת CRM בהתאמה אישית

שלושה מקרים שבהם מדף נשבר

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

הגבול בין פיתוח להגדרה

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

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

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

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

הבדיקה שמכריעה, בחצי יום

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

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

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

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

למי בונים את המערכת

הטעות הנפוצה ביותר בפרויקט CRM, והיא לא טכנית: המערכת נבנית למנהל.

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

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

מה חייב להיות בחוזה

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

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

איך אני עובד על זה

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

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