יישום / הטמעת מערכת ERP ידועה כאחת מהמשימות היקרות ומהמסוכנות שלוקחת על עצמה חברה. הפוטנציאל לעיכוב והוצאות בלתי צפויות עשוי לארוב לכם בפינה ולהכשיל אתכם המנמ"רים ,מנהלי הפרויקט ומיישמי המערכת לאורך הדרך משלב התנעת הפרויקט ועד לאחר העלייה לאוויר.
במאמר הבא אציג לכם את השגיאות הנפוצות בהטמעת מערכת הERP פריוריטי וכל הדרכים להימנע מהן.
עצות אלו נכתבו כחלק מפעילות הכשרה שבצעתי למיישמי מערכת פריוריטי ( Priority ) והופקו כלקחים מול המנמ"רים במסגרת עשרות פרויקטי יישום והטמעה – אסור לפספס!!!.
להלן 10 הטעויות – בהמשך תגלו מהן דרכי המניעה לצורך הצלחת פרויקט יישום הפריוריטי:
- תכנון פרויקט לקוי.
- לא לבצע מחקר שוק על חברת היישום או מנהל הפרויקט שיוביל את תהליך היישום.
- אי ניצול מערכת המידע לשיפור תהליכים עסקיים וטיוב נתונים.
- הדרכת משתמשי פריוריטי ללא תיעוד הוראות הפעלה / מסמכי הדרכה יעודיים לתהליכים שהוגדרו.
- ביצוע פיתוחים שאינם חיוניים.
- חוסר היכרות של יכולות המערכת לקידום תהליכים עסקיים.
- המעטת השימוש במשאבי חברה החיוניים להצלחת הפרויקט.
- פיילוט – ניסוי כלים ובדיקות מערכת על סביבת נתונים הזרה למשתמשים הסופיים.
- המנעות מחיפוש חלופות של ספקי שירות.
- הגדרת משתמשים סופיים בחוקים עסקיים ומסגרת BPM .
להלן פירוט 10 הטעויות הנפוצות והדרך להמנע מהן בפרויקט יישום / הטמעת פריוריטי
טעות מס' 1 – תכנון פרוייקט לקוי
1.1 תכנון הפרויקט הוא הכרחי בכדי להצליח הן בהיבט של אפיון, פיתוח והדרכה.
1.2 הכירו את משתמשי המפתח הבינו מהם מה כואב להם היום ע"מ למנוע זאת מחר באמצעות המערכת.
1.3 בצעו אפיון מעמיק של הצרכים ותכננו את שלבי היישום וההדרכה.
1.4 בקשו לקבל ממנהל הפרויקט תוכנית עבודה מפורטת הכוללת שעות מוערכות לכל אחד משלבי הפרויקט:
i. אפיון
ii. הסבות נתונים
iii. התאמות תוכנה חיוניות
iv. כתיבת מסמכי הפעלה / הדרכה יעודיים לתהליכים עסקיים.
v. הדרכה פרונטאלית
vi. ליווי שוטף לאחר עלייה לאוויר .
1.5 מעקב אחר תכנון הפרויקט והתוכנית המפורטת, יאפשר לכם בקרה על ניהול תקין או חריגה הצפויה מהתקציב הכולל כבר בשלבים הראשונים של הפרויקט.
טעות מס' 2 – לא לבצע מחקר שוק על חברת היישום או מנהל הפרויקט שהוקצה לכם
2.1 לרב חברות יישום מבצעות את תהליך השיווק עם מנהל המכירות או מנהלי הפרויקטים הבכירים שלהם , אך כשזה מגיע לניהול בפועל של הפרויקט אתם עלולים למצוא את עצמכם מול מדריכים מתחילים עם ניסיון של שנים ספורות.
2.2 דרשו להפגש עם מנהל הפרויקט לפני תחילת היישום ולקבל המלצות מלקוחות בתחום דומה בהם ביצע בעבר פרויקט יישום.
2.3 בקשו לפחות 3 לקוחות ממליצים בתחום עיסוקכם , בהם ביצע מנהל הפרויקט המיועד פרויקטים דומים. במהלך פגישת הפתיחה עם מנהל הפרויקט, בקשו דוגמאות ליישומים מורכבים שביצע בעבר , בכדי לקבל התרשמות מהניסיון שלו ומהיכרותו עם תחום עיסוקכם.
2.4 כשמדובר בפרויקטים גדולים ומורכבים מומלץ ביותר לשלב כחלק מתהליך הבקרה על חברת היישום וניהול הפרויקט – יועץ חיצוני שביצע פרויקטים בהיקף דומה ומתמחה במערכת הפריוריטי ויכולותיה.
טעות מס' 3 – לא מנצלים את חידוש מערכת המידע לשיפור תהליכים עסקיים וטיוב נתונים
3.1 תהליך הסבות נתונים מתבקש כחלק מיישום המערכת.
i. מומלץ לנצלו לטיוב נתוני תשתית כגון מק"טים , עצי מוצר , תהליכי ייצור וזמני תקן באופן שישרת את יכולתכם להפקת דוחות אפקטיביים בעלי ערך מוסף גבוה המאפשרים לכם לתמחר נכון את המוצרים / שירות שלכם.
ii. חשוב להקפיד על דיוק הנתונים המוכנסים ע"מ להקטין טעויות ולהעלות בעיני המשתמשים את האמון במערכת החדשה.
3.2 שינוי תהליכים עסקיים – שלב ההטמעה בו גם נחשפים פרטנית לכל אחד מהתהליכים העסקיים מהווה בסיס מצוין להבנת נקודות הכשל הקיימות. שכנעו בעלי תפקיד השומרים מידע / נתוני תפעול קריטיים בע"פ או בתוכנות ייעודיות /אקסל ,להזינם במערכת גם אם זה אומר שצריך לפתח עבורם מסכים ייעודיים. i. קחו בחשבון שאיבוד של בעל תפקיד בעל ידע רב (שאינו מתועד במערכת), עשוי לגרום למכה קשה בתהליך העסקי עליו הוא אמון – עד להשלמת הידע.
ii. הפיקו מנתונים אלו כלים תפעוליים לייעול התהליך כגון הפקת מדבקות הכוללות מידע טכני על המוצר ע"ב הפרמטרים הטכניים שלו.
iii. נצלו את המידע במערכת לקידום כלים לשיקוף עומסים. לדוגמא : שיוך כל מק"ט למודל השיווקי שלו עשוי להציף עומסים צפויים לייצור כבר בשלב הזנת הזמנת הלקוח ולאפשר פיזור תאריכי אספקה ריאליים.
3.3 עליכם להביא למצב שהמערכת משקפת את המציאות ולנסות ככל הניתן להימנע מדיווחים בדיעבד.
i. נתקלתי לא אחת בחברות שהכניסו מערכת מידע נגישה באולם היצור, אך במקום שעובדי היצור ידווחו בזמן אמת ויציגו בonline את ההתקדמות ,זה נופל על מזכירת מח' התפ"י שאינה עומדת בעומס.
ii. אי דיווח בזמן עשוי להשפיע בהתאם על קיזוז המלאי , וממילא גם על ערך המלאי ותוכנית ההצטיידות המבוססת על רמת המלאי הקיימת.
3.4 התפיסה במערכת ERP צריכה להיות , שהעובד המבצע את הפעולה בפועל, הינו זה שידווח עליה – התעקשו על נקודה זו כחלק מתהליך ההטמעה מול המשתמשים הסופיים.
i. אל תוותרו למשתמשים בתואנה של חוסר ידיעת השפה , קשיי מחשוב , במקום זאת פשטו את המסכים.
ii. הסירו שדות מסך מיותרים ,ויישויות (דוחות / מסכים / פרוצדורות) שאינן רלוונטיות והשתמשו במחוללי נתונים לצורך מילוי אוטומטי ומניעת טעויות.
iii. קחו בחשבון שאם התהליך והיישום לא יהיו פשוטים למשתמש הסופי , זה פשוט לא יעבוד.
טעות מס' 4 – הדרכת משתמשים ללא הוראות הפעלה / סיכום הדרכה
4.1 חשוב לשמר את הידע המועבר כבר בשלב היישום הראשוני כשמחליטים על תהליך העבודה הסופי.
4.2 שימור הידע יכול להתבצע ע"ב תוספת בתוכן יעודי באשפי המערכת או בהוראות ההפעלה הקיימות.
4.3 מומלץ לקשר לתפריטי המודולים מסמכי הדרכה או מקרים ותגובות לתרחישים השונים.
4.4 מומלץ מאוד להוסיף help ליישויות הפרטיות שנוספו בפיתוחים / התאמות תוכנה. הקפדה על האמור לעיל תאפשר לכם בהמשך העברת תפקיד מעובד אחד לאחר בצורה קלה וזורמת ע"ב תיק חפיפה המבוסס על החומר הרב שמופק במהלך הפרויקט היישום.
טעות מס' 5 – התאמות תוכנה , פיתוחים ועוד פיתוחים שלא ממש חיוניים בפריוריטי
5.1 חוקיות במסכי המערכת (הודעות אזהרה/שגיאה ,מיילים ועדכון נתונים) המבוססת על טריגרים של מסכים ולא על חוקים עסקיים, מקשיחה את האפשרות לשנותה או לשנות את תנאיה עצמאית, ע"כ העדיפו לבסס את החוקים העסקיים ע"ב חוקים עסקיים / מחוללי הנתונים שאינן דורשים כל פיתוח וגמישים מאוד לשינוי.
טיפ 😯 : במידה ולא ניתן לבסס חוק עסקי , מומלץ להוסיף שדה עזר שיאפשר לכם לבסס החוק העסקי.
i. לדוגמא : נניח שברצונכם לוודא שלא ניתן לקדם את ההזמנה למאושרת לפני שיזינו לכל שורת הזמנה את המק"ט החלופי המתאים לשורת סל המוצרים. הוסיפו שדה בוליאני בכותרת ההזמנה שיתעדכן בשלב יציאה מפירוט ההזמנה ובתנאי שלא נבחרו מוצרים חליפיים בסל. כל שיישאר מבחינתכם הוא לבסס חוק עסקי פשט המונע העברה לסטטוס 'מאושרת' במצב בו השדה מסומן.
5.2 אחת הסיבות בגללן חשוב שמנהל הפרויקט יהיה בעל ותק רב, נעוץ בהיכרות הטובה של מיישם מנוסה עם התהליכים ויישויות המערכת, כך שבמקום לפתח מאפס יישות פריוריטי (מסך/ שדה / דוח / פרוצדורה ) שאינו יודע על קיומה, יבצע שימוש בבסיס של דוחות קיימים / פרוצדורות סטנדרטיות – יאפשר לחסוך זמן פיתוח משמעותי.
i. המערכת עשירה בדוחות ומסכים העונים לצרכים שונים של אלפי משתמשים , קרוב לוודאי שדרישה שעולה מהמשתמשים כבר נענתה על בסיס דוח / מסך כלשהם גם אם לא במלואה , השתמשו בתשתיות הקיימות.
ii. נצלו את בקיאותו של מנהל הפרויקט / מיישם פריוריטי ודרשו להבין מהי הישות הקרובה ביותר ממנה ניתן לענות על הצורך שלכם.
5.3 המנעו מפיתוח דוחות חוזרים בווריאציות שונות לאותו נושא בקיבוצים / מיונים שונים.
i. כתחליף השתמשו בתבניות אקסל זה עשוי לפתור לכם בעיות גרפיקה בהם מערכת הפריוריטי חלשה. שימוש בטבלאות ציר ( pivot table ) מאפשר לכם משחק עם יכולת הקיבוץ והמיון ללא בנייה מחדש של מס' דוחות לפי הצרכים המשתנים.
ii. השתמשו במחוללי הדוחות למודולים השונים והוסיפו להם שדות ע"פ הצורך במקום מסמכי HTML מורכבים .
5.4 השתמשו בתבניות word המאפשרות גמישות רבה.
i. אפשרות להזנת טקסט קבוע ע"פ הצורך.
ii. יכולת עיצוב עצמאי של המסמך כרצונכם על בסיס שדות המסך הרלוונטי.
טעות מס' 6 – חוסר היכרות עם כל תכונות מערכת הפריוריטי בדגש על התהליכים העסקיים הקיימים.
6.1 במצב בו משתמשי המערכת אינם חשופים לתכונות המערכת וליכולות שלה , הם גם לא ידעו לדרוש את השינוי המתבקש ,וזה כמובן עלול לגרום לפספוס הזדמנויות עסקיות או לסרבול בתהליך העבודה הקיים.
6.2 כמנהלי המערכת , אל תשמרו את המידע קרוב לחזה , תנו כמה שיותר ידע למשתמשי הקצה , זה ישחרר אותם להיות עצמאים , ואתם תוכלו להתמקד בשיפור תהליכים רוחביים במקום לכבות שריפות קטנות וממוקדות.
6.3 בשלב ההדרכה למשתמשים הסופיים הסבירו להם מהי הלוגיקה של כל תת תפריט במערכת , ע"מ שידעו להגיע אליו עצמאית , הנחו אותם להשתמש בתפריטים עצמם במקום בקיצורי הדרך / התפריט האישי . באופן זה, המשתמשים יגלו בתפריט או בתתי התפריטים מהם הגיעו אליו , עוד יישויות שעשויות לעניין אותם (כגון אשפים , דוחות , פרוצדורות וכו' ) שעשויים לעזור להם בעבודה השוטפת.
טעות מס' 7 – להמעיט את הזמן והמשאבים הנדרשים
7.1 רבות מהחברות מנסות לצמצם משאבים בהיבט של כ"א , ללא הבנה שאי הקצאה של משאבים ובהם משתמשי המפתח בכל תהליך עסקי, עשוי להקטין את בשלות המשתמשים לקליטת מערכת הפריוריטי וליכולתם להטמיע אותה לשאר משתמשי הקצה.
7.2 שיתוף משתמשי מפתח ממחלקות החברה השונות עשוי לתרום לפרויקט ,שהרי מעצם לקיחת חלק בהחלטות גם ירגישו מחויבים יותר אליהם וכמובן שגם יוכלו לסייע בעיצוב מתאים יותר של התהליך לצרכים המוכרים להם.
7.3 ודאו שמנהל הפרויקט בעל ותק והיכרות טובה של התהליכים העסקיים – במצב בו לא מוקצה מנהל פרויקט יעודי המכיר היטב את החברה והתהליכים העסקיים שלה, החברה חוטאת לצרכי המשתמשים ואינה מספקת מוקד ידע פנימי – דבר שבסופו של דבר יעלה לה יותר בגין הפעלת כ"א חיצוני לתפעול וייעוץ.
7.4 השקיעו בהדרכת משתמשי הקצה – שכן חוסר בשעות הדרכה וליווי למשתמשים אלו מהווה אחת מהסיבות הנפוצות לכישלון הליך היישום.
בסופו של דבר משתמשים שלא חשו את המערכת מספיק לפני עלייתה לאוויר, גם פחות מבינים את המערכת ולכן לא יעדכנו באופן תקין את הנדרש מהם.
קחו בחשבון שללא הדרכות בהיקף מתאים ,יתכן שאתם משקיעים המון כסף ביישום מערכת בשביל לקבל גרסה יקרה מאוד של אקסל.
טעות מס' 8 – ביצוע פיילוט על סביבת בדיקות בסיסית שאינה תואמת לסביבת אמת
8.1 בדיקות המבוצעות על סביבת נתונים המוכרת למשתמשים , תקל עליהם את הבנת המערכת.
8.2 בדיקה מקיפה של התהליך על הסביבה המוכרת , גם תאפשר למשתמשי הפריוריטי לעלות על טעויות אותם ניתן למנוע בסביבת האמת.
8.3 עבודה על שרת האמת בעומס מלא תאשש את מוכנות השרת לעמוד בעומס הנתונים והמשתמשים.
טעות מס' 9 – הימנעות מחיפוש חלופות של ספקי שירות (צד ג')
9.1 חברות רבות נשענות על שירות מגוף היישום שבעזרתו הם עלו לאוויר כאוטוריטה מקצועית יחידה.
לא קיימת מודעות לכך שהחברה יכולה לקבל את השירות השנתי על תוכנת הפריוריטי גם מחברות יישום נוספות בשוק המחזיקות במרכז שירות.
מעבר שכזה עשוי לפקוח לכם את העיניים ולהעלות את רמת השירות שתקבלו.
9.2 מומלץ מאוד בשלב העמקת יישום מערכת הפריוריטי לפנות לחברת יישום שונה.
9.3 מטבע הדברים יקצו לכם מנהל פרויקטים ותיק, ותיהנו מניסיון רב יותר ומרוח חדשה במפרשים שתרענן לכם את תהליכי העבודה הקיימים.
טעות מס' 10 – הגדרת משתמשים סופיים בחוקים עסקיים ובמסגרת ה BPM
10.1 המערכת עשירה באפשרויות לחילול חוקים עסקיים , הן במסכים והן כחלק מניהול התהליך העסקי ה- BPM . אני חוזר ונתקל במנהלי מערכת שהגדירו בחוקים העסקיים – משתמשי מערכת ספציפיים ונתקלו בבעיה בשלב בו עובד שינה תפקיד או סיים את תפקידו בחברה, היה נדרש מהם לעבור על כל החוקים בהם מוגדר המשתמש המקורי ולשנותו לחדש.
10.2 במקום שימוש במיילים סופיים או משתמשי מערכת ספציפיים ,השתמשו במייל לקבוצת דואר :
מבוסס על מסך 'קבוצות' – בו ניתן להגדיר קבוצות דיוור מוכנות מראש.
במצב בו התחלף בעל התפקיד פשוט משייכים את בעל התפקיד החדש לקבוצה במקום הקודם לו ומעתה כל החוקים העסקיים ימשיכו לעבוד כסדרן גם עבור העובד החלופי באותו התפקיד.
טיפ 1 😯 – מסך קבוצות הינו מסך 'רב חברתי' הקפידו שתיאור הקבוצה יאפיין באופן ברור את נמעניה.
טיפ 2 😯 – קיימת פרוצדורה ל'מחיקת קבוצה' המקושרת לתפריט הנגיש בדר"כ לרב משתמשי המערכת.
ניהול משרד > אנשי קשר > מחיקת קבוצה
ודאו שאתם חוסמים זאת מהמשתמשים , בכדי למנוע מצב בו משתמש מוחק בטעות את כל קבוצות הדואר הקיימות…
מקווה שהפקתם מהמאמר לקחים ליישום מיידי אצלכם במערכת פריוריטי (Priority). אשמח מאוד לקרוא תגובות שלכם ולשמוע מכם על עוד טעויות יישום בהם נתקלתם, בכדי לסייע לקהילת משתמשי הפריוריטי להימנע מהם.