In the Scope or out of the Scope… בתכולה או מחוץ לתכולה

 

מאת: אבי עסיס

 

רקע

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

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

כדי להבין את הבעיה, אציג תחילה את התהליך האופייני ואת נקודות הכשל האפשריות בכל שלב, כפי שרווח במרבית הארגונים, המתעדים ליישם מערכת CRM (או מערכת  ERP– אך במאמר זה אדגיש ואתמקד בעיקר בתחום ה- CRM):

 

שלבי התהליך:

*  התחלת הפרויקט – על אחד מן הגורמים המובילים בארגון מוטלת המשימה ליישם מערכת CRM. לצורך הדיון נניח כי המשימה מוטלת על מנהל מערכות המידע בארגון.

*  קיומו של מסמך אפיון – מנהל מערכות המידע מגייס לעזרתו את אחד ממנתחי המערכות בארגון ומטיל עליו משימה: לכתוב מסמך אפיון או מסמך ייזום לפרויקט, כאשר מסמך זה מכיל את עקרונותיו של הפרויקט, יעדים ותכולה כללית. במקרה הטוב, כאשר אותו מנהל מערכות מידע מרגיש, כי אין בארגון את הידע הנדרש לכתוב מסמך ייזום או מסמך איפיון ראשוני, הוא פונה לסיוע של גורמי חוץ כגון יועצים למיניהם (לא תמיד ליועצי CRM מומחים). יחד הם מכינים מסמך איפיון עקרוני לפרויקט ובחלק מהמקרים מסמך לקבלת הצעות מחיר – RFP (Requset For Proposal).  במקרים הפחות טובים הדבר לא מתבצע והדבר עלול להוות את תחילתה של הבעיה.

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

– המערכת תאפשר תמיכה בתהליכי טלשיווק

– המערכת תתמוך בתהליכי מכירה מול לקוחות

– המערכת תכלול מימשק למערכת הפיננסית

– המערכת תאפשר מנגנון לניהול מסמכים

– ועוד ועוד…

בנוסף משפטים רבים הכוללים סיומות כגון: וכו'…ועוד, וכדומה.

*  אופן ביצוע המכרז – מסמך ה-RFP מופנה לספקים שונים, כאשר לעיתים חלקם מייצגים כלי CRM שונים. מכאן, שאותו מסמך RFP עקרוני וכללי מופנה בו זמנית לספק Dynamics CRM, לספק SAP-CRM, לספק שלישי, שאולי מייצג את Siebel ולספק אחר שיתכן ומייצג כלי CRM אנונימי. תארו לכם עכשיו, כי הספקים הללו מקבלים את אותו מסמך RFP לידיהם והמשימה היחידה שעומדת מולם היא כיצד לזכות בפרויקט. ברור בשלב זה, שהמחיר הוא אחד הקריטריונים המרכזיים אצל הלקוח בעת קבלת ההחלטה בנוגע לספק הנבחר – ומאחר וגם הספק יודע זאת, הרי ללא כל ספק ינסה "לנצל" את המשפטים הכלליים, ייתן הערכה נמוכה לגבי הסעיפים הרלוונטיים ובכך יגביר את הסיכוי שיבחרו בו.

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

– רכב מכיל 4 גלגלים

– הרכב מכיל מנוע בנפח 2000 סמ"ק

– הרכב מכיל 5 מושבים

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

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

 

*   הסכם ומציאות –  ואולם, יש נייר והסכם, ויש מציאות! עם התחלת הפרויקט, השלב הראשון והחשוב ביותר הינו ביצוע אפיון מפורט לפרויקט – וכאן מתחיל להתגלות הפער העצום בין הדרישה ה"כללית" במסמך ה-RFP לבין המציאות והדרישות המפורטות של לקוח. פתאום מתגלה, כי אותה שורה צנועה ותמימה כדוגמת: "המערכת תאפשר יצירת מכתבים ללקוח…", מסתירה מאחוריה עולם שלם ומורכב של דרישות מצד הלקוח כמו: יכולת קלה ופשוטה לייצר מכתבים ללקוחות, שילוב של נתונים מבסיסי הנתונים בתוך המכתב ללקוח, שמירת סוגים שונים של טמפלטים של מכתבים לפי סוגי לקוחות, שימוש אוטומטי בטמפלטים בהתאם לסוג פניית לקוח ועוד. כלומר, אם ספק דמיין כי יוכל להיענות לדרישה זו בהשקעת עבודה של X שעות, הרי שלאחר הבנת הדרישות וביצוע האפיון המפורט מתגלה, כי יש צורך להשקיע לעיתים 100X שעות עבודה……ומי יממן זאת? צדקתם – הלקוח בלבד! הרי ספק לעולם לא יפסיד בפרויקט והדרך היחידה שלו לשרוד הינה להקטין את ההפסדים, אז כיצד מקטינים הפסדים ? להלן כמה שיטות:

 

–  לבצע את המינימום ההכרחי בפרויקט

–  לפרש את מסמך ה-RFP על הצד הפשוט והקל יותר

–  לספק כ"א זול יותר ופחות מיומן

–  לבוא ללקוח בבקשה לשלם עבור "פיתוחים" נוספים שלא הוגדרו ב-RFP

–  לחייב באופן מוגזם עבור פיתוחים "פשוטים" יחסית

–  לחייב את הלקוח בעתיד בסכומים גבוהים יותר על פיתוחים ודרישות לאחר  העלייה לאוויר

–  ועוד ועוד…

 

איך מנהלים פרויקט CRM אחרת?:

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

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

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

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

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

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

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

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

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

 

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

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

 

*אבי עסיס (M.Sc.) – מנכ"ל חברת Widelink  פתרונות עסקיים בע"מ. מומחה בעל ניסיון רב ביישום וניהול פרויקטי CRM בפרט ומחשוב ארגוני בכלל.

לתגובות, הערות והארות ניתן להפנות

למייל: avi@widelink-crm.com

 

 

קישורים רלבנטים באתר: