זווית ראיה - הדרך הבטוחה לכישלון פרויקט ERP או סקר דרישות המשתמשים – אם כל חטאת

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

• שלב ראשון של הפרויקט: ניתוח מצב קיים וסקר משתמשים בו כל משתמש יציג את דרישותיו מהמערכת.
  • הערה: המשתמש לא יכול להציב דרישות באופן מועיל לפני שלמד על בוריים את המודולים הרלוונטיים הקיימים והבין לעומק את שיטות העבודה במערכת.
• שלב שני: דוח הפערים המזיק – רשימה ארוכה של נושאים שיש לפתח בכדי "להתאים את המערכת לדרישות המשתמשים".
  • הערה II: 90% מההתאמות המבוצעות (במימון הלקוח כמובן), לא רק שאינן תורמות, אלא מזיקות בכך שהן:
    • מהוות סטייה משיטות העבודה הנהוגות במערכת אשר בד"כ מבוססות על ידע רב
    • מגבילות את יכולת השדרוג של המערכת בעתיד
    • מגבילות את יכולת התמיכה במערכת (מתן שירות)
    • כובלות את הלקוח למיישם בעבותות (כאן האינטרס של המיישם)
    • מגבילות את יכולת השימוש בחלק מהדוחות והכלים המסופקים עם המערכת
    • והגרוע מכול; גורמות ליישום תהליכי עבודה מעוותים המבוססים על אוסף של ראיונות של משתמשים שלא ביצעו חשיבה מסודרת על התהליך לכל אורכו ולא למדו לעומק מה שיש למערכת להציע.
• שלב שלישי: אישור וביצוע הפיתוחים – ההוצאה לפועל של גזר הדין.
• שלב רביעי: יישום המערכת על פיתוחיה.
• שלב חמישי: עלייה לאוויר.
• שלב שישי: גילוי האמת המרה בטווח הקצר– חלק מהפונקציונאליות של המערכת חסומה לשימוש בגלל פיתוחים, תהליכי העבודה אינם זורמים ואינם מנוטרים, איכות הנתונים ירודה וכך גם הדוחות.
• שלב שביעי גילוי האמת המרה בטווח הארוך: אין אפשרות ליהנות מפיתוחים חדשים של בית התוכנה, קשה לקבל תמיכה ואי אפשר להתנתק מחברת היישום!
• שלב שמיני: הריב – חילופי האשמות בין הלקוח ובין הגוף המיישם, שבסיום ידו של הגוף המיישם על העליונה היות והוא ביצע "רק את מה שהמשתמשים ביקשו וההנהלה אישרה".
• שלב שמיני – דיסוננס קוגניטיבי: הלקוח הבין שאין טעם להלחם ומבצע אידיאליזציה מדומה של המצב הקיים. 

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

כתב: עמית גורן

amit@goren-ltd.co.il