תפריט נגישות

יישומי ERP בשוק ה-SMB, פרק ב' - המרשם

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

תקציר פרק א' – התסמונת

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

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

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

דילמת "בנה ביתך"

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

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

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

פרויקט ERP או החלפת תוכנה?

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

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

תבשיל בטעם ביתי

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

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

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

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

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

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

הנוסחה להצלחה

פרויקט ERP הינו פאזל מורכב של מגוון חלקים שניתן לחלקם ל- 3 קבוצות עיקריות:

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

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

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

ארגון x יישום x תוכנה = תוצאת הפרויקט

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

היכולת לדעת 

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

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

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

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

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

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

 השלב האחרון הוא שלב הפרויקט

 

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

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

דוח רווח והפסד

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

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

אז זהו, שכל מה שמתואר פה אמנם נכון, וטוב שכך!

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

 

ולכן זכרו:

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

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

מהות השינוי

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

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

שאלות אלו שכלל אינן קשורות ל"החלפת תוכנה" אך קשורות בטבורן ל"פרויקט ERP", יידונו בהרחבה בפרק ג' – השינוי.

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

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

eli@da-at.com

פרסום באתר