תפריט נגישות

יישומי ERP בשוק ה-SMB, פרק א' - התסמונת

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

מעשה שהיה

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

רגע חושבים

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

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

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

רשת מזון מהיר

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

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

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

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

ארגון SMB ומאפייניו

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

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

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

השלכות על הפרויקט

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

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

      ישיבות ודיונים, הכנת חומר רקע ובסיסי נתונים.

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

 חברת היישום

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

תנאי הפתיחה של פרויקט שכזה (מוצר ERP גדול ולקוח SMB) עלולים להתגלות כבעייתיים מבחינת חברת היישום:

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

המפגש!

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

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

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

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

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

ובחזרה לסיפורנו

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

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

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

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

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

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

אפילוג

כך קרה שפרויקט שעבד לכאורה "לפי הספר" היגיע למצב משברי שבו כולם הפסידו:

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

מוסר השכל

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

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

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

אז איך נכון לאותו לקוח להתמודד עם מציאות לא מוכרת שכזו?

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

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

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

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

על כל אלו ועוד בפרק ב' העוסק במרשם - היערכות וצעדי מניעה.

כותב המאמר: אלי גרומט, מנכ"ל משותף

דעת הנדסה ומערכות מידע בע"מ

eli@da-at.com

פרסום באתר