תפריט נגישות

למה נופל לי ה-C.R.M חלק ב'

מטרת המאמר לאתר נקודות כשל אפשריות בפרויקטי C.R.M על מנת לנטרלם ולמנוע פגיעה בפרויקט בעוד מועד. .

טעויות טקטיות נפוצות:

טעויות אופייניות למערכות CRM מחולקות לשלוש קטגוריות:

טעויות אנוש.

טעיות תהליכיות.

טעויות במוצר.

טעויות אנוש.

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

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

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

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

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

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

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

מוטיבציה נמוכה

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

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

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

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

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

הכוונה חד משמעית למשימה תוך שמירה קפדנית על כבוד והגינות.

צוות פרויקט שאינו מתאים.

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

סימנים רבים בחיי הפרויקט מעידים על בעייתיות בצוות הפרויקט:

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

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

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

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

האקדוחן הבודד וה"סופר" גיבור.

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

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

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

יותר מידי פעילות, מאוחרת מידי.

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

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

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

תנאי עבודה בלתי מספקים.

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

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

עימות עם חברי הצוות.

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

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

אי מימוש ציפיות.

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

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

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

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

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

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

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

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

קיצורי דרך מסוכנים.

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

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

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

טעויות תהליכיות

לוח זמנים לא הגיוני.

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

להלן מספר "סימנים" ללוח זמנים לא מציאותי:

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

הקדם תרופה למכה.

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

ניהול הסיכונים הינו תהליך מתמשך ומבוקר לאורך כל חיי הפרויקט. אי פרסום הסיכונים וניסיונות להסוות סיכונים ע"י לקיחת סיכונים לא מחושבים או התעלמות בוטה מהסיכונים תורמים תרומה משמעותית לנפילת פרויקטים.

סמני האזהרה של ניהול סיכונים לקוי:

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

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

אי הבנת הדרישות.

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

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

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

סימני אי הבנת הדרישות הם:

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

טעויות קבלן.

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

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

קידום לוח הזמנים.

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

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

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

תכנון לקוי 

תכנון לא מדוקדק או לקוי של הפרויקט מאופיין ב:

  • אי הסכמה בין חברי הצוות .
  • חוסר במידע שיאפשר קבלת החלטות.
  • חוסר במידע באשר לחלופות אפשריות בפרויקט.

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

פיקוח לקוי

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

עדכון התוכנית

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

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

עבודה...עבודה

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

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

מצב זה קל יחסית לזיהוי :

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

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

אישור וחתימת המשתמשים הסופיים על מסמך הדרישות

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

שימוש ו"ניפנוף" באישור המשתמשים יחד עם מערכת שינויים ושיפורים קשוחה תגן על תוכנית הפיתוח מפני פיגורים הנובעים משינויי דרישות.  

הערכת מורכבות הפרויקט

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

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

גורמים עיקריים המשפיעים על הפרויקט בתחום זה:

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

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

טעויות במוצר

"תפירת יתר"

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

יתרונות רבים גלומים בשמירה על יישום פשוט:  

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

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

האם הארגון צריך לשנות ו/או להתאים את התהליכים בתוכו לתוכנת ה – CRM ? חד משמעית לא.

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

עלייה לאוויר במכה אחת

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

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

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

עליה מדורגת תוך הצמדות לתוכנית המקורית עשויה לתרום:

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

קידוש תהליכים ודרישות

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

איך מתמודדים עם זה?

ראשית יש לאבחן את אותם תהליכים ודרישות קדושים ולהבין מהו מקור הקידוש ומה משמעתו. באותם פרמטרים המאובחנים כתהליכים ו/או דרישות העלולים להוות מכשלה ליישום הפרויקט יש לטפל פרטנית.

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

ללא שינויים

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

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

אי ביצוע שינויים

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

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

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

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

חזון הפרויקט

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

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

כותב המאמר: מנחם רוזנבלום, מנהל ושותף בחברת אלטרנטיבה מומחי IT

 manny@alternative.biz

פרסום באתר