יישומי ERP בשוק ה-SMB: פרק ב'
פרק א' – התסמונת
מעשה שהיה
לאחרונה זומנתי לפגישה במפעל שעוסק בהרכבת מוצרי מתכת, שם הוצגה לי הבעיה הבאה: 
"אנחנו נמצאים מזה כ-5 חודשים בפרויקט ERP ועכשיו כחודש לפני סיום הפרוייקט, החלטנו לעצור הכל כי פתאום קלטנו שאנחנו לא באמת יודעים מה נקבל בסוף". שאלתי: "האם לא הוגדרו התהליכים העסקיים? האם חברת היישום לא הציגה אותם לאישורכם?", ונעניתי "כן, ראינו המון תהליכים ואישרנו מסמכים באבן דרך ראשונה ושניה, אבל במהלך שלב ההדרכות תפסנו שנקבל מערכת שונה לחלוטין מציפיותינו".
"אנחנו נמצאים מזה כ-5 חודשים בפרויקט ERP ועכשיו כחודש לפני סיום הפרוייקט, החלטנו לעצור הכל כי פתאום קלטנו שאנחנו לא באמת יודעים מה נקבל בסוף". שאלתי: "האם לא הוגדרו התהליכים העסקיים? האם חברת היישום לא הציגה אותם לאישורכם?", ונעניתי "כן, ראינו המון תהליכים ואישרנו מסמכים באבן דרך ראשונה ושניה, אבל במהלך שלב ההדרכות תפסנו שנקבל מערכת שונה לחלוטין מציפיותינו".רגע חושבים
אז איך זה קורה? איך קורה שפרוייקט מסודר נקלע למצב שכזה, מיהם הגורמים האחראים למצב זה, האם ניתן לצפות מצבים שכאלו מראש, האם אפשר למנוע את קיומם? נקדים ונאמר שכל פרוייקט ERP מהווה מצע גידול נוח להפתעות, טעויות, תקלות ושאר מריעין בישין. כל אחת מהבעיות הללו עלולה לפגוע בהצלחת הפרוייקט, ולשמחתנו רובן מתגלות ומטופלות באופן
שוטף. מאמר זה בחר להתמקד בבעיות המאפיינות את שוק הלקוחות הקטנים-בינוניים (שוק ה-SMB), שוק גדול בהיקפו וייחודי מאוד בהתנהגותו במהלך פרוייקט יישום ה-ERP. דגש נוסף ניתן במאמר לתוכנות הבינלאומיות שנכנסות לשוק זה ולשיטת היישום החדשה שהם נעזרים בה.
רשת מזון מהיר
שוק יישומי ה-ERP עובר בתקופה האחרונה שינוי בעקבות כניסתן של מערכות ERP בינלאומיות לארגונים קטנים ובינוניים. בפרוייקטים שהתקיימו עד לכניסתן לשוק זה נדרשו חברות היישום להליך ארוך ומורכב של ניתוח מערכת ועיצוב פתרון משלב "אפס". מהלך זה האריך את משך הפרוייקט וייקר משמעותית את עלותו.
כדי להתאים את התוכנות לפעילות בסביבה החדשה פותחה מתודולוגית יישום חדשה המבוססת על עיקרון של מערכת דרוכה מראש ((Pre Configured הכוללת סל של פתרונות מוכנים הנותנים "מענה סטנדרטי ללקוח ממוצע".
המתודולוגיה כוללת מהלך שתחילתו בהצגת התהליכים הקיימים במערכת הדרוכה, במקרה של זיהוי פערים מול צרכי הארגון חיפוש אחר פתרון מוצלח יותר בסל הפתרונות, וכל זאת תוך הקפדה על הימנעות משינויים במערכת המקורית. לאורכו של תהליך זה מצויות אבני דרך בהן הארגון נדרש לראות, לדון ולאשר את ההחלטות שהתקבלו. המדובר בשיטת יישום מהירה וזולה יחסית, ומכאן שגם הפכה לאטרקטיבית בקרב לקוחות SMB אשר יכולים ליהנות משימוש במערכות ERP גדולות במחירים סבירים.
ארגון SMB ומאפייניו
השינוי המהפכני בגישת היישום והכנסת מערכות דרוכות מראש, פתר את בעיית משך הפרוייקט ועלותו אך עורר בעיות אחרות. חלק מבעיות אלו נובע מהמאפיינים הארגוניים של לקוח SMB, והמפגש של תכונות אלו עם דרישות הפרוייקט.
ניתן להצביע על מספר מאפיינים אצל לקוחות אלו:
- מדובר בארגונים "רזים" יחסית מבחינה תקציבית (הסכום המוקצה לפרוייקט) ואנושית (היקף כוח האדם הניהולי).
- בשכבה הניהולית המצומצמת רבים מהמנהלים עוסקים בעיקר זמנם בביצוע מטלות שוטפות ורק מעט מזמנם מוקדש לניהול ובקרה.
- בחלק מהארגונים נמצא מחלקות המונות אדם אחד (לדוגמא מחלקות תפ"י ורכש). במקרים רבים בעל תפקיד נושא במספר משרות בו זמנית.
- חלק מהארגונים צמחו במהלך השנים מגופים ועסקים קטנים ועדיין לא שינו והתאימו את התרבות הארגונית שלהם למציאות החדשה – לחשוב ולהתנהג "כמו גדולים".
- מחלקת מערכות מידע קטנה (אם בכלל קיימת) ויכולותיה מצומצמות, לעיתים כל עיסוקה הוא בתחזוקת מחשבים אישיים והרשת.
השלכות על הפרויקט
התנהלותו של כל ארגון בפרוייקט ERP היא קשה ובעייתית, אך על רקע המאפיינים הנ"ל צומחת בארגוני SMB מציאות קשה כפליים:
- חלק מהבעיות מתחילות כבר בשלב המקדים של בחירת המערכת. נמצא כי מגבלות תקציב, חוסר ידע והיעדר מודעות דוחפים חלק מהארגונים לקיצורי דרך באפיון והגדרת הדרישות, בחינת החלופות השונות וזיהוי מידת התאמתן לצורכי ארגון.
- המפגש של תוכנות ERP "גדולות" עם ארגוני SMB מפחיתה ממידת ערנותו של הארגון בשלביהבחינה והבחירה, ונותנת לו תחושה ש"אין מה לדאוג, התוכנה עובדת בארגונים גדולים אז וודאי שאם אבחר בה אז היא תיתן מענה גם אצלי".
- עם תחילת הפרוייקט מתגלה בעיה בהתארגנות צוותי העבודה ומשתמשי המפתח. הנושא הופך בעייתי במיוחד במחלקות הקטנות. במחלקות אלו זמינותו של משתמש המפתח מהווה צוואר בקבוק בעבודה השוטפת של הארגון. מכאן שקשה לו למצוא את הזמן הנדרש לקיום מטלותיו בפרוייקט ה-ERP: ישיבות ודיונים, הכנת חומר רקע ובסיסי נתונים.
- השכבה הניהולית המצומצמת והיעדר בקרות ניהוליות, מותירות את משתמש המפתח להתמודד בכוחות עצמו עם הדילמה הקשה: בחירה בין ה"חשוב" (פרוייקט ה-ERP) ל"דחוף" (העבודה השוטפת שתמיד ממתינה). בדילמה זו כרגיל ידו של ה"דחוף" על העליונה.
- פרוייקט ה-ERP מהווה חוויה חדשה ולא מוכרת לכלל גורמי הארגון – מנכ"ל, הנהלה, משתמשי מפתח ומערכות מידע. היעדר ניסיון מוקדם הופך אמירות אודות "מחויבות הנהלה", "הפרוייקט כמשימה ארגונית – ולא של מערכות מידע", לסיסמאות ריקות וחסרות תוכן, ומכאן גם שהתייחסותם של גורמים אלו לקורה בפרוייקט היא בהתאם.
חברת היישום
מול הארגון ניצבת חברת היישום. גוף אשר מביא עמו מתודולוגית עבודה וניסיון מפרוייקטים קודמים וכן צוות מיישמים שמכיר את יכולות התוכנה. חברת היישום נדרשת לקשר את היכולות הללו עם צרכי הלקוח תוך שמירה על מסגרות הזמן והתקציב.
תנאי הפתיחה של פרוייקט שכזה (מוצר ERP גדול ולקוח SMB) עלולים להתגלות כבעייתיים מבחינת
חברת היישום:
- מטבע הדברים שעם תחילתו של הפרוייקט חברת היישום אינה מכירה עדיין לעומק את הארגון וצרכיו. מידת היכרותה מתבססת על התנהלות השלבים שקדמו לפרוייקט. לעיתים נמצא שעיקר הזמן בשלבים אלו הוקדש למו"מ סביב מחיר התוכנה ועלות האחזקה (החשובים כשלעצמם), ולא בתהליכים העסקיים המרכזיים ובהצגת יכולות התוכנה להתמודד עם תהליכים אלו.
- במטרה להיות אטרקטיבי בתהליכי המכירה ובהתמודדות עם חברות מתחרות, נקבעת לפרוייקט מסגרת מאוד לחוצה של זמן ותקציב. הבסיס למסגרת זו היא ההנחה שנצמדים לקיים במערכת הדרוכה, וכך מתקדמים במהירות בין שלבי הפרוייקט ואישור אבני הדרך.
המפגש!
המפגש בין חברת היישום עם מתודולוגית היישום החדשה ובין לקוח ה-SMB על
מאפייניו הייחודיים, עלול להתגלות כמפגש טעון.
כאמור, מתודולוגיה זו מתמקדת בהצגת הקיים בסל הפתרונות ולא בניתוחים "ארוכים ומייגעים" של
המצב הנוכחי. מצב זה צמצם למינימום את השלב שהוקדש בגישה הישנה
להתעמקות בהבנת הבעיות וניתוחן.
- זה טוב כי נחסכת המון ברברת, הלקוח רואה מערכת עובדת ולא דיבורים באוויר, לא מפליגים לפנטזיות רחוקות ולפתרונות שעולים כסף רב ומתגלים כלא ישימים.
- זה רע כי הלקוח נדרש לפחות חשיבה ומעורבות בדיונים ונחשף ליותר מצגות. המצגות מטבען מהירות לעין אך פחות מעמיקות, הלקוח לא מספיק לקלוט ולהבין את מה שמוצג לו.
אם עוד נוסיף את לוח הזמנים קצר, גודש המשימות ועמידה באבני דרך, הרי שקיבלנו מצב בעייתי שבו הלקוח מאשר תהליכי עבודה מרכזיים ובוחר בין חלופות מבלי שיבין לעומק את מהותם, ובוודאי ללא שום יכולת לצפות את המשמעויות וההשלכות שכרוכות בעבודה במתכונת המוצגת לו.
בקיצור שינוי המתודולוגיה וביטול שלב ניתוח המערכת פגע בזמן האיכות של הלקוח בפרוייקט, ומנע ממנו את ההתמודדות עם הפרטים, והשטן כידוע נמצא שם – בפרטים אלו… .
ובחזרה לסיפורנו
וכך בדיוק קרה לידידינו במקרה המדובר. חברת היישום דהרה לה אל סיומו של הפרוייקט, עד שלפתע גילתה שעגלת הלקוח אינה רתומה לסוס.
בדרך לפתרון המשבר התקיים דיון עם הלקוח וחברת היישום, בו הבינו שני הצדדים שהכישלון הזה
למזלו יש לו גם אבא וגם אמא. חברת היישום מצידה הכירה בכך שעל אף שהתקבלו האישורים הפורמליים היה עליה לזהות ולוודא שהארגון מבין ומחובר למה שקורה בפרויקט. מאחר שלא עשתה כך התפתח לו פרוייקט שהתבסס על "מי שהיה פנוי בסביבה", במקרה האמור היה זה מנהל מערכות המידע, גורם חיובי עם רצון טוב, אך חסר מעמד ארגוני מחייב, ושאינו נושא באחריות לקורה בשטח. הארגון הבין שדרכי הקיצור שבחר בהם רק האריכו את הדרך, ומעורבותו בפרוייקט חיונית.
חברת היישום והארגון נדרשו לחזור ולבצע את אותם מהלכים שכבר בוצעו בעבר:
- זוהו הנושאים שהתגלתה בהם אי הסכמה.
- חברת היישום הציגה לנושאים אלו פתרונות חלופיים עובדים כולל נתוני אמת.
- המעורבות של כלל גורמי הארגון בפרוייקט אפשרה לבחון ולהחליט הפעם על שינויים בהרגלי
- העבודה – שינויים שנדחו בסיבוב הראשון בשל היעדר גורם מחליט.
- גורמי הארגון בחנו ואישרו את המשך הדרך. בחלק מהתהליכים הם חזרו ואשרו את אותם סעיפים
- שכבר נחתמו על ידם בעבר, אלא שהפעם הבינו את משמעות האותיות הקטנות.
אפילוג
כך קרה שפרוייקט שעבד לכאורה "לפי הספר" היגיע למצב משברי שבו כולם הפסידו:
- הפרוייקט גלש מעבר למסגרת הזמן והתקציב,
- חברת היישום ספגה נזק כספי ותדמיתי בשל התארכות הפרוייקט,
- הלקוח שילם עבור פיתוחים ייחודיים שבוצעו ללא צורך,
- הלקוח נדרש להשקיע אנרגיה ארגונית רבה בישיבות ומצגות שהתגלו כחסרות תכלית,
- נגרמה פגיעה מיותרת במידת האמון של הארגון במערכת החדשה.
- קצר תקשורתי ועסקי בין הלקוח וחברת היישום.
מוסר השכל
כדי להימנע מלהיקלע למצבים דומים לאלו נדרשים הרבה ניסיון, הבנה מקצועית
והכרה במורכבותו של פרוייקט ה-ERP. המדובר בפרוייקט משותף ל-2 גופים: הלקוח וחברת היישום. שניהם חולקים באופן שווה באחריות להצלחתו, אך כאן מסתיים השוויון.
בשעה שחברת היישום משפרת בהתמדה את ניסיונה, הבנתה ויכולותיה, וכל פרוייקט חדש מציב אותה בנקודת פתיחה טובה יחסית לפרוייקט הקודם, הרי שהלקוח לעומת זאת נותר תמיד חסר ניסיון, עבורו מדובר תמיד בפרוייקט ראשון!
אז איך נכון לאותו לקוח להתמודד עם מציאות לא מוכרת שכזו? ניתן להמשיל מצב זה לפרוייקט בניה אשר בו אדם חסר ניסיון נדרש לנהל את מלאכת הבניה של ביתו מול קבלן ביצוע.
במצבים אלו ראוי היה שייבחן את האפשרות להיעזר במפקח בנייה מקצועי, מנוסה, ואובייקטיבי אשר ייצג את האינטרסים שלו מול הקבלן, יידע להתמודד עם הבעיות שיתעוררו במהלך הפרוייקט, ייבחן וינתח עבורו הצעות ודרכי פתרון שונות אותן מעלה הקבלן, וכל זאת תוך שימת דגש על טובת הלקוח והפרוייקט (ולא רק נוחות ורווחיות הקבלן…).
זהו בדיוק תפקידה של חברת ייעוץ המתמחה בניהול פרוייקטי ERP מטעם הלקוח. לספק לארגון את אותו ניסיון וידע קודמים אשר יבטיחו את הצלחתו של הפרוייקט. מהם הכישורים הדרושים מחברה שכזו? איך היא משתלבת בפרוייקט? מהן התועלות הצומחות לגורמי הארגון השונים ממהלך שכזה? ולמה כדאי גם לחברת היישום שילוב שכזה?
על כל אלו ועוד בפרק ב' – המרשם.
מאמרים קשורים
