המדריך סוקר את נושא ERP (Enterprise Resource Planning) ומגדיר את אופן שילוב פרויקט יישום מערכת ERP בנוהל מפת"ח. לצד מבוא והסבר כללי, מכיל המדריך הנחיות כיצד לנהל פרויקט ERP, היינו, כיצד להגדיר לו עץ מערכת וכיצד לנהל מחזור חיים מסודר, בדגש על שלבי שלבי האפיון-על ובקשה להצעות. המדריך מתמקד במאפיינים המיוחדים של מערכות ERP לעומת עץ המערכת ומחזור החיים האוניברסליים של מפת"ח. להבנת מדריך זה ואיך להשתמש בקיט זה ככלל, מומלצת הכרה מקדימה (וניסיון) של נוהל מפת"ח
למדריך זה שתי מטרות:
· לתת סקירה כללית על נושא ERP.
· לשמש כלי עבודה לניהול פרויקט יישום ERP החל מייזום ואפיון-על, דרך בקשה להצעות ופיקוח שוטף על הפרויקט (כולל בדיקות) וכלה בתחקור והערכת מערכות ERP קיימות וקבלת החלטות באשר ל"המשך דרכן".
מערכת ERP - Enterprise Resource Planning, או בשמה האחר ERM - Enterprise Resource Management, היא מערכת כוללת לניהול הפעילות העסקית של הארגון: רצפת ייצור, תחנות עבודה, לוגיסטיקה (רכש ומלאי), כוח אדם, כספים ועוד - הן בהיבט הפיסי והן בהיבט הכספי.
מערכות ERP מאופיינות בכך שהן מורכבות ממספר יישומים משולבים באופן אינטגרטיבי ליצירת חבילת תוכנה אחת. עם זאת מאפשרות רכישה מודולרית ומימוש בשלבים ובהדרגה. ליישום חבילת ERPמחזור חיים ייחודי הלוקח בחשבון את הצורך בשינויים הנדרשים בחבילה לצורך התאמתה לצרכים העסקיים של הארגון.
ארגונים בארץ ובעולם נוטים לעבור לעבוד במערכות ERP מהסיבות הבאות:
· מערכת רחבה הכוללת מגוון רחב של תהליכים שכבר עובדת ונבדקה.
· למערכת אותו ממשק משתמש בכל המודולים, קל יותר למשתמשים.
· במרכז המערכת עומד בסיס נתונים באמצעותו מקושרים המודולים השונים, דבר החוסך בממשקים בין המודולים, ומאפשר אינטגרציה יותר חלקה.
· לרוב למערכות אלה יש תשתית טכנולוגית המאפשרת התאמתן בקלות לצרכים הארגוניים, כאשר חלק מהכלים הללו אף עומדים לרשות הארגון (הלקוח / משתמש מפתח). למשל: שינוי ערכים בטבלאות, שינוי זרימת תהליכי (Workflow) ועוד.
גורמים מרכזיים בהצלחת הטמעת מערכות ERP הם:
· נכונות הארגון ויכולתו להתאים את תהליכי העבודה למערכת, כולל שינויי או"ש ותהליכים עסקיים ולבצע מינימום שינויים והתאמות במערכת הבסיסית. עם זאת, ברור שהארגון אינו יכול לוותר על פונקציות ותהליכים עסקיים התומכים ביתרון היחסי שלו למול המתחרים.
· נכונות וזמינות הדרג הניהולי הבכיר ודרג הביניים להיות מעורבים בפרויקט ולקבל החלטות אמיצות הן בשלבי התכנון וההתארגנות הכללית והן בזמן אמת במהלך הפרויקט.
· בחירת החבילה המתאימה לארגון, בשלבי התכנון (הייזום ואפיון-העל), על פי מידת ההתאמה שלה לתהליכים הקיימים בארגון כך שידרשו מינימום השינויים.
· במהלך מימוש הפרויקט ויישום המערכת, יש לעקוב ולוודא שאין גלישות והרחבות שלא אושרו באפיון-העל או לאחר מכן בתכולות המאושרות משלב ניתוח הפערים.
ללא מעורבות שוטפת של ההנהלה, נכונות ללכת לקראת החבילה ולהתמקד רק בהתאמות ההכרחיות והקצאת המשאבים הדרושים להטמעת המערכת, אין טעם להתחיל בפרויקט.
חבילת ERP מכילה את הנושאים (מודולים) הבאים:
· ניהול משאבי אנוש
· ניהול פיננסי
· ניהול לוגיסטי (מלאי, רכש ועוד)
· ייצור (רצפת ייצור, תכנון הייצור, אספקה וכדומה)
· שיווק ומכירות
· ניהול קשרי לקוחות (CRM)
· ניהול פרויקטים
· ניהול מסחר אלקטרוני
· תשתיות
התכונות המייחדות חבילת ERP לעומת חבילת תוכנה מנהלתית רגילה הנן:
· תפוצת החבילה
· היקף החבילה
· אינטגרטיביות
· גמישות
· בינלאומיות
· אי תלות בתשתיות
· טכנולוגיה
· תהליך המימוש
חבילות ERP הנפוצות מותקנות בארגונים רבים ברחבי העולם, עובדה המאפשרת ליצרן החבילה לספק שירותים מתקדמים כגון: מוקד שירות פעיל 24 שעות ביממה 7 ימים בשבוע, מהדורות עדכון תכופות, משאבי מו"פ להמשך פיתוח החבילה, תיעוד ברור ועדכני ויכולת הישרדות.
חבילת ERP מכילה מספר רב של מקטעי תוכנה משולבים עשירים בפונקציונליות והיא מקיפה את מירב הנושאים המנהלתיים בארגון. אין צורך לרכוש חבילות ממספר יצרנים ולפתח שילובים בין החבילות.
כל המקטעים משולבים בצורה הדוקה ביניהם. קיימת שקיפות של המידע הארגוני, וזה מאפשר ביצוע חיזוי מדויק יותר, מעקב מדויק אחר נתונים בתהליכים השונים.
חבילת ERP יכולה להכיל חלק או את כל הכלים שלהלן המאפשרים התאמת החבילה ללקוח ללא תכנות: עריכת טבלאות מערכת, שינוי תזרים תהליכים, מחוללי דו"חות, התאמת מבנה מסך למשתמש, יכולת הוספת שדות ייחודיים למסכים, שליטה פרמטרית בהרשאות, ניהול על פי ישויות, כלים למנהלים, ממשקים יעילים עם מערכות אחרות, כולל מערכות לניהול משרד ממוחשב (Office Automation) כגון תוכנתOffice של חב' מיקרוסופט.
חבילת ERP בד"כ, הינה חבילת תוכנה בינלאומית המותקנת בארץ ובחו"ל, על פי ראייה וניהול עסקיים המקובלים בעולם. החבילת יכולה להכיל כלים לניהול קונצרניאלי, ריכוזיות וביזוריות וניהול רב מטבעי. חבילות ה- ERP המשווקות בארץ עברו תרגום לעברית ולדרישות החוק והניהול הנהוגים בארץ.
ניתן ליישם חבילת ERP, בדרך כלל, על מגוון פלטפורמות, מערכות הפעלה ובסיסי נתונים.
חבילות ERP מושתתות על תשתית אחידה המתבטאת ב: GUI, שרת/לקוח, קשר לאינטרנט, מסחר אלקטרוני, EDI, בסיסי נתונים טבלאיים ומערכות הפעלה. יצרני החבילות משקיעים תשומות רבות להתאמת החבילות לחידושים הטכנולוגיים כך שכל חידוש שנכנס מוכל לרוב על כי רכיבי המערכת.
תהליך המימוש (יישום) של חבילת ERP מורכב יותר מאשר חבילה רגילה, עקב היקף התהליכים הארגוניים אשר מקבלים מענה חדש (ללא קשר להתאמתם לארגון), היקף הפיתוח הנדרש בזמן קצר. יצרני חבילות ה- ERP פיתחו, עקב כך, מתודולוגיות ליישום החבילה, חלקן אף ממוחשבות. לרוב הגורם המיישם את החבילה בארגון, אינו יצרן החבילה אלא בית תוכנה/יועצי מחשוב המתמחים בכך.
היתרונות והתועלות שהמערכת אמורה להביא לארגון הם בתחומים הבאים:
· ראייה עסקית כוללת, שיפור המידע המועבר להנהלה
· שילוב מערכות ואינטגרציה
· עושר פונקציונאלי (מגוון רחב של יישומים ופונקציות עסקיות)
· תהליכי עבודה משופרים
· שפה אחידה
· כתובת אחת
· טכנולוגיה מתקדמת
· המערכת הינה לתקופה ארוכה, מחזור חיים עד לגריטת המערכת ארוך משל מערכת רגילה.
חסרונות או המחיר שיש לשלם עבור השגת היתרונות/תועלות הנ"ל הם בתחומים הבאים:
· ויתור על פונקציות ייחודיות (יתרונות/סודות עסקיים), ואבדן יתרון למול המתחרים. קשיים הנובעים משינויים ארגוניים ושינוי דפוסי עבודה.
· יישום פרויקט בהיקף גדול כזה יכול להיות בעייתי.
· הפתרון יכול להיות יקר יותר ממערכות שאינו משולבות.
· שבויים בידי ספק החבילה, סיכוי לעליית מחיר התוכנה לשנה או לשינויים נדרשים.
· מורכבות
על מנת לנטרל חלק מחסרונות (קשיים) אלה וליהנות מהיתרונות שלעיל, יש לתת את הדעת על ההיבטים המפורטים בסעיפים הבאים ולוודא ביצוע הפרויקט באופן מסודר כמוסבר בהמשך מדריך זה.
ככלל, פרוייקטי ERP מתנהגים בדומה למחזור החיים התקני של מפת"ח. יש ליזום פרויקטים אלה, להכין אפיון על, לנהל באופן מסודר את שלב הבקשה להצעות ולבחור מוצר וחברה מיישמת. בכל מקרה יש לעבוד לפי מחזור חיים מסודר. שלבי הפיתוח והבדיקות שונים ממחזור חיים תקני כלהלן: נוסף שלב ניתוח פערים (Gap analysis) המבוצע לפני האפיון המפורט, ובו מוחלט על אופן מימוש המערכת, אילו תהליכים ייושמו, אילו שינויים מאושרים לביצוע וכדומה.
לפרוייקטי ERP יש השלכות מיוחדות על מחזור החיים, לא רק בהשוואה לפרויקט פיתוח של מערכת מידע, אלא גם בהשוואה ליישום חבילות תוכנה אחרות. השוני נובע מכך שהמימוש הנו כלל ארגוני וכרוך בעלויות רבות, בהשקעות בתשומות ניהוליות רבות מצד הארגון, בתיאומים בין מחלקתיים, בשינויים ארגוניים וכן בשינוי תהליכי עבודה. הראייה חייבת להיות כלל ארגונית ולא מחלקתית/ סקטוריאלית.
להלן פירוט הדגשים והייחוד, למימוש חבילת ERP, בשלבי מחזור החיים השונים.
עקב ההשלכות האסטרטגיות של חבילת ERP על הארגון, יש לבצע בשלב הייזום ניתוח מעמיק האם פתרון זה הוא הדרך המומלצת לארגון. התלבטות זו בין פתרון בגישת ERP מול פתרונות רגילים בדמות חבילות מנהלתיות רגילות או מערכות מידע שיפותחו בארגון, תבחן שוב, גם בשלבי האפיון והבקשה להצעות. אך יש להתמקד בה כבר בשלב הייזום ולהיערך בהתאמה בשלבים הבאים של הפרויקט. להלן השלבים העיקריים בתהליך הייזום:
· הגדרת הלקוח
· סקירת המצב הקיים בארגון
· בדיקה ולימוד של מערכות דומות במקומות אחרים
· סקירת שוק המחשבים הכללי
· בדיקת ישימות (היתכנות) ועלות/ תועלת
· כתיבת ואישור מסמך הייזום
מימוש חבילת ERP מחייב מעורבות אישית של מנכ"ל הארגון כולל הקצאת זמן מצדו להנחיה והובלת על של הנושא. המימוש יונחה ע"י ועדת היגוי אשר תכלול את הסמנכ"לים האחראים על התחומים שייושמו. מומחי היישום יהיו סמנכ"לים עצמם או נציג אמיתי (סגן) שיש בסמכותו לייצג את הסמנכ"ל ולקבל החלטות.
יש לבצע סקר מצב קיים ברמת-על של כל המערכות המנהלתיות בארגון. הסקר יכלול, לגבי כל מערכת, פירוט של הנושאים הבאים:
· בעיות פונקציונליות קיימות,
· היכולת לקבל מידע איכותי מהמערכת להחלטות ההנהלה,
· בעיות בממשקים עם מערכות אחרות,
· השלכות של הבעיות על יעדי הארגון,
· מצב טכנולוגי,
· אומדן השקעות הכרחיות נדרשות לפתרון הבעיות,
· מסקנה על מצב המערכת מבחינת מצב במחזור החיים.
הנחיצות במימוש חבילת ERP בארגון תגבר אם יתבררו הנושאים הבאים:
· חלק ניכר מהמערכות נמצא בסוף מחזור החיים שלהם ויש להחליפן במערכות חדשות.
· קיימות בעיות באינטגרציה בין המערכות הגורמות לבעיות בתפקוד הארגון.
· קיים חוסר במידע מהותי להנהלה לניהול וקבלת החלטות.
· קיימות בעיות תהליכיות כלל ארגוניות.
מומלץ לאחד את שלב סקירת המצב הקיים עם שלב הגדרת יעדים / בעיות, תועלות וחסכונות ולבצעם לפני לימוד מערכות דומות ומצב השוק. זאת, כדי למקסם את התועלות מסקר השוק.
קיימת חשיבות מרובה להפקת לקחים מניסיון של ארגונים דומים. לשים דגש על לקחים כגון:
· מידת התועלת שהושגה, יעדים שהושגו / לא הושגו,
· עלויות בפועל,
· תהליך ושיטת המימוש,
· חבילות קיימות ודירוגם לסוג הארגון.
קיים מגוון חבילות ERP המיושמות בארץ מתוצרת מקומית או מיובאות שעברו "גיור" והתאמות לתנאי הארץ. מומלץ להתמקד במערכות שכבר מיושמות בארץ ויש עמן ניסיון בשוק המקומי. מומלץ לערוך מצגת בת יום לכל נושא ראשי בחבילה. יש להתמקד בחבילות ERP עם פתרונות מוכנים בתחום העיסוק של הארגון.
סקר השוק יסייע רבות בשלב הייזום בנושאים הבאים:
· הגדרת היעדים אליהם יש לשאוף,
· רעיונות לגיבוש התהליכים המוצעים,
· סדרי גודל של עלויות ולוחות זמנים,
· סינון ראשוני של החבילות המועמדות למימוש.
מומלץ לערוך אומדן עלויות של חלופת ERP לעומת מימוש רגיל. לפירוט וכללי אצבע לאומדן עלויות ליישום חבילת ERP, ראה קיט אומדן עלויות בכרך נושאים תומכים.
מומלץ לבצע אומדן עלויות לשני טווחי זמן:
· עלויות הקמת המערכת (טווח קצר)
· עלויות כוללות למחזור החיים (10 שנים).
באומדן העלות לטווח ארוך, יש לקחת בחשבון שמחזור החיים של חבילת ERP ארוך מזה של חבילה רגילה, הן עקב השקעות הארגון במעבר והן עקב ההשקעות הרבות של יצרני החבילות בטכנולוגיה ובמחקר ופיתוח, והתקנת מהדורות תוכנה תכופות. כמו כן היצרן עשוי לשדרג את המערכת ולהאריך בכך את אורך חייה.
אומדן עלויות של פרויקט ERP כרוך באופן ישיר בהטמעת מערכת חדשה אך באופן עקיף גם במערכות הקיימות. חלק מהמערכות יצטרכו להתחבר באמצעות ממשקים למערכת זו וחלק מהמערכות יוחלפו על ידי חבילת ה-ERP וכתוצאה מכך יופסקו בהדרגה דמי התחזוקה שלהם. כל הנתונים הללו אמורים להילקח בחשבון בעת ביצוע חישובי העלות/תועלת.
במקביל יש לסכם את התועלות והחסכונות שיושגו בחלופות השונות.
יבוצע על פי הקיט ייזום בכרך יסודות/ מחזור חיים. מסמך הייזום יכיל ניתוחים, הנמקות, נתונים והמלצה האם ללכת על חבילת ERP. המסמך יאושר ע"י ועדת ההיגוי בראשות מנכ"ל הארגון.
אפיון העל יבוצע לאחר אישור ההנהלה לפרויקט. יש להסתייע בקיט אפיון סעיף פעילויות, בכרך יסודות / מחזור חיים. יש להקפיד לאפיין את הדרישות מהמערכת ולהימנע מהשקעה מיותרת באפיון וניתוח מפורטים המתרכזים בשיטה וב-"איך", היינו לאפיין את ה- "מה" ולאפשר למציעים להציג את השיטה (את ה-"איך").
צוות האפיון יונחה בצורה פעילה ע"י ועדת ההיגוי ויהיה מורכב מהגורמים הבאים:
· מנתח מערכות, מומחי מימוש, אנשי שטח בכל מקטע שעתיד להיות מיושם (רצוי אותו הצוות שהשתתף בשלב הייזום).
· מומחה ERP שתפקידו להציף דרישות חריגות באפיון לעומת המקובל בחבילות ERP, להציג משמעויות וחלופות ולאפשר קבלת החלטה מושכלת לגבי כל דרישה כנ"ל.
בשלב אפיון העל מומלץ להתמקד בנושאים הבאים:
· אפיון התהליכים העתידיים במערכת, שהוגדרו בשלב הייזום (רכיב 2.5).
· אפיון ממשקים למערכות אחרות בארגון, ולגורמים חיצונים (רכיב 2.22).
· אפיון ההסבות (יש להתייחס ברכיב 4.7).
ככלל, פנייה לספקים פוטנציאליים בבקשה להצעות למימוש חבילת ERP תתבצע בהתאם לקיט בקשה להצעות - RFP. ההבדלים במימוש חבילת ERP, לעומת מימוש חבילות מנהלתיות רגילות, בשלב זה הם:
במימוש חבילת ERP, פועלים שלשה סוגי ספקים:
· יצרן החבילה.
· נציג היצרן בארץ (עבור חבילה מיובאת) שאחראי גם לגיורה והתאמתה לישראל. לעיתים זהו סניף של היצרן בארץ.
· חברת יישום המתמחה בפרוייקטי ERP עם החבילה הנדונה, בד"כ מחלקה בבית תוכנה.
האפשרויות לפניה לספקים הן:
· מכרז סגור - קביעת המיישמים והחבילות שישתתפו בבקשה להצעות, לאחר בדיקה מקדימה.
· מכרז פומבי - מומלץ לקבוע תנאי סף כלהלן: גיור החבילה, עמידה בחוקי ישראל, תכולת החבילה ללא ממשקים לחבילות אחרות, קביעת נתונים מינימליים המייצגים את שרידות החבילה כגון השקעה שנתית במחקר ופיתוח שלה, מספר התקנות בארץ ובעולם.
שיטת הפנייה המומלצת הנה מכרז פומבי. במקרה כזה, יש להיערך לאפשרות שתתקבלנה מספר הצעות של מיישמים שונים לאותה החבילה. יש לשקול אפשרות לפיצול הבחירה במוצר ובחירת חברת היישום.
פרק חשוב במיוחד בשלב זה הוא פרק העלות. לפירוט מרכיבי העלות והסברים לגבי כל מרכיב ראה גלופת עץ מערכת בלשונית תוצרים בקיט זה.
יש לתת דגש מיוחד לעלויות התאמות והטמעות, היינו, כל מה שמעבר לעלות החבילה עצמה. הניסיון מלמד שעלויות נלוות אלה יכולות להגיע ליחס של 1:10 מעלות רכישת החבילה עצמה! יש לקבל החלטה, בשלב הבקשה להצעות, האם עלויות אלה תהיינה במחיר קבוע או לפי תשומות? החברות המיישמות מעדיפות שיטת התקשרות על פי תשומות, ללא מגבלת תקרה, מהסיבות הבאות:
· בשלב ההתקשרות אין הגדרה מפורטת של ההתאמות הנדרשות והמתכונת הסופית של המימוש. מתכונת זו נקבעת רק לאחר גמר התכנון והכנת מסמך ניתוח פערים Gap Analysis מאושר בין החבילה ודרישות הארגון.
· התגברות על בעיות בלתי צפויות שמתגלות במשך התהליך.
חסרונות התקשרות מסוג זה הם ברורים:
· התקשרות ללא מגבלה תקציבית.
· לא קיים תמריץ לייעול וחסכון בהשקעת תשומות של המיישם.
נקודות מומלצות, לשיקול דעת, הנן:
· האם כדאי לדרוש מחיר קבוע לפחות לגבי שלב התכנון (הגדרת מסמך הפערים) במימוש?
· האם אפשר לחלק את המכרז ולקבל עדכון הצעות מחיר לגבי מימוש יתר השלבים, במחיר קבוע, לאחר השלמת שלב התכנון על סמך מסמך הפערים שהוגדר. או לחילופין האם להגדיר מחירון לשינויים שיאושרו לביצוע?
· מומלץ ששלב "ליווי והטמעה" יהיה אכן על פי תשומות היות והוא תלוי במורכבות המימוש ודרישת ה"שטח". האם ההדרכה וההטמעה יהיו באחריות המיישם?
לעיתים הארגון מתמקד מראש בחבילה מסוימת (עקב אילוצים או קשר למכרזים אחרים) ואז ה-RFP מתמקד בספק המיישם ולא בחבילה. במקרה זה יש לשים דגש רב בפרק 4 על נתוני הספק, ממליצים, פרויקטים דומים ועוד.
בנוסף ל- RFP לבחירת החבילה ו/או חברת היישום, קיימים מסמכי RFP נוספים הקשורים לנושא הדרכות, בדיקות קבלה ורכש טכנולוגי. מסמכים אלה נכתבים לאחר בחירת החבילה/ספק כאשר קיימים פרטים רבים יותר אודות החבילה, התנהלות הפרויקט ולוחות הזמנים. כל אחד ממסמכים אלה נכתב על פי מפת"ח תוך התאמה לסוג הבקשה הרלוונטי.
במימוש חבילת ERP קיימים שני סוגי חוזי התקשרות:
· חוזה לרכישת זכויות שימוש המתבצע עם יצרן החבילה - חוזה זה הנו חוזה מוכתב מראש ע"י יצרן החבילה ויש לבודקו על פי הקיט חוזים והיבטים משפטיים, סעיף "רשימת תיוג למוצרי מדף".
· חוזה מימוש עם המיישם - מומלץ להתבסס על גלופת חוזה לעיצוב ובנייה (פיתוח) למערכת מידע, שבקיט חוזים והיבטים משפטיים בכרך נושאים תומכים.
התאמות
ההתאמות שיש להכניס בחוזה המימוש הן בנושאים הבאים:
· עלות המערכת (התמורה) - במחיר קבוע/ לפי תשומות על פי המתכונת שתקבע כמפורט לעיל.
· התחייבויות הספק - במקום "עיצוב ובנייה" יכיל שלב "תכנון והכנת מסמך פערים" ו"בנייה" על פי מתודולוגית המימוש של החבילה. כמו כן יש לקחת בחשבון אחריות מפוצלת בין המיישם ויצרן החבילה לדוגמא בנושא "בגים".
· שינויים עפ"י בקשת לקוח - יש לקחת בחשבון מגבלות החבילה.
· תמיכה - מחולקת לשני גורמים: מרכז תמיכה של היצרן והמיישם. יש לתכנן את התמיכה בצורה מיטבית למימוש.
· אחריות - שייכת ברובה ליצרן החבילה. בחלק מהחבילות לא ניתנת תקופת אחריות. תקופת השירות והאחזקה מתחילה מידית לאחר הרכישה.
· בעלות - הבעלות הנה של יצרן החבילה. השימוש מוסדר במסגרת זכויות שימוש בחבילה עם יצרן החבילה. יש מקום לזכויות בעלות לגבי מרכיבי תוכנה שפותחו במיוחד עבור הארגון.
נקודות נוספות
נקודות נוספות לשיקול דעת הארגון (מוציא המפרט) הן:
· מומלץ לפרסם חוזה מחייב עם המיישם וכן רשימת תיוג לגבי החבילה, לאחר התאמתם לחבילת ERP, כבר בשלב הבקשה להצעות. יש להיזהר ולא להכניס תנאים אשר אינם קבילים על יצרני החבילות ואשר אינם הכרחיים לארגון ולגרום בכך לפסילתם ללא כוונה מראש.
· קיימת אפשרות לדרוש אחריות כוללת של המיישם בפרויקט. דהיינו, הארגון יעמוד מול המיישם בלבד וכל הקשרים עם יצרן החבילה מבוצעים ע"י המיישם. חלופה זו, אינה מקובלת במימוש ERP, ואינה מומלצת.
· חבילות ERP מיוצרות על ידי יצרנים בינלאומיים גדולים ולעיתים לא ניתן להכתיב ליצרנים אלה תנאים מנהלתיים של הארגון. מומלץ לבדוק סעיפים "חשודים" כנ"ל מול הספקים ולהחליט לגופו של עניין האם להשאיר תנאים אלה כמות שהם, באיזה נוסח לנסחם והאם לסווגם כסעיפי סף (M -מנדטורי).
הנקודות העיקריות שיש לתת להן תשומת לב מיוחדת הן: התחייבות על שירות ותחזוקה ל- 5 שנים (0.6.6), התחייבות לרכש גומלין (0.6.7), נוסח חוזה.
עקב מורכבות המימוש מכילות חבילות ERP רבות מתודולוגיה מוכנה לשלב העיצוב והבנייה (בדרך כלל מלווה במערכת ממוחשבת מוכנה). מומלץ שמימוש חבילת ה- ERP יתבצע במסגרת המתודולוגיה של החבילה שנבחרה.
בדרך כלל מכילה מתודולוגית המימוש שני מסלולי מימוש חלופיים:
מימוש מהיר מקוצר מיועד לארגונים לא גדולים עם תהליכי עבודה סטנדרטיים. במסלול זה יותאמו תהליכי העבודה בארגון לברירות המחדל בחבילה למעט התאמות מועטות הכרחיות. שלב העיצוב והבנייה יתמקד בממשקים עם מערכות אחרות ובהסבות. התשומות שיידרשו למימוש במסלול זה הנן מועטות במידה משמעותית לעומת מימוש במסלול המלא.
מימוש מלא מיועד לארגונים גדולים ומורכבים עם תהליכי עבודה ייחודיים ודרישות ייחודיות. מומלץ לבדוק בשלב ראשון התאמת הארגון למסלול המימוש. במידת האפשר מומלץ לבחור, כמובן, במסלול המהיר והמקוצר.
תת השלבים העיקריים של שלב עיצוב ובנייה בחבילת ERP הנם:
· בניית צוותי עבודה משולבים - צוותי עבודה לכל נושא יכילו נציגי המיישם החיצוני ומומחי המימוש מטעם הארגון וכן ליווי פעיל של ועדת ההיגוי. הכרחי להקצות את היקף כוח אדם הנדרש מצד הארגון על פי דרישות המימוש של החבילה.
· הדרכה - צוותי העבודה מצד הארגון יעברו הדרכה מתאימה על החבילה.
· הגדרת צרכים עסקיים - רענון של דרישות ה- RFP לאור הגישה ותהליכי העבודה המומלצים ע"י החבילה.
· מיפוי דרישות עסקיות - הכנת מסמך פערים בין הפונקציונליות של החבילה והדרישות העסקיות לגבי כל מקטע, דרישות לגבי ממשקים, דרישות לגבי הסבות.
· עיצוב מסגרת היישום ודרישות טכנולוגיה - גיבוש מסגרת היישום והטכנולוגיה לאור הדרישות העסקיות ומסמך הפערים.
· בנייה - גיבוש פתרונות לכיסוי הפערים במסמך הפערים, באמצעות כלים מוכנים ופרמטרים המסופקים ע"י החבילה או כתוספת תכנות של רכיבים הכרחיים נדרשים. הכרחי למזער, במידת האפשר, פיתוח ותכנות ייחודיים ולהתגמש לפתרונות המוצעים במסגרת החבילה. פיתוח התאמות באמצעות תכנות מקשה על תחזוקת המערכת והתאמתה למהדורות עתידיות.
· תכנון ובניית הסבות - פיתוח תוכניות הסבה ליבוא נתונים מהמערכות הישנות הקיימות באמצעות כלים מוכנים המסופקים ע"י החבילה.
· תיעוד - התאמת התיעוד ליישום, על פי תקני החבילה. בכל מקרה יש לשמור על מסגרת מסמך מפת"ח כבסיס לתיעוד המפורט. באמצעות מסמך זה ניתן לוודא כי מתקיימת עקיבות בין שלב זה לדרישות שנקבעו במסגרת החוזה. בסעיף 2.5 יופיע אינדקס כל התהליכים הנסקרים בתהליך, בסעיף 2.22 יופיע אינדקס הממשקים וכו'. עבור כל תהליך ייכתב, בדרך כלל, מסמך הגדרת תהליך המשלב בתוכו את זרימת התהליך בארגון, ממשקים הקשורים בו, דוחות ועוד. פיתוח נוסף או הגדרת דוחות חדשים יופיעו בסעיפי מפת"ח הסטנדרטים.
שלב זה יתבצע, ככלל, כמוגדר בקיט בדיקות מערכת (Testing) בכרך יסודות / מחזור חיים. שיטת הבדיקה לא תתמקד בחיפוש באגים במסכים וישויות המידע של החבילה - מדובר באלפי תוכניות ופשוט "חבל על הזמן". מומלץ להתמקד בבדיקות בנושאים הבאים:
· פיתוחים ייחודיים לדרישות הארגון והממשקים בינם לבין החבילה
· ממשקים עם מערכות חיצוניות לחבילה
· הסבות
· תהליכי עבודה (דגש על תהליכים כלל ארגוניים ותהליכים ייחודיים)
יש לבצע סקר לפרקים: יעדים, טכנולוגיה, מימוש ועלויות, במסמך המערכת
יש לבצע בדיקות ביצועים ועומסים תוך שימוש, ככל האפשר, בכלים התומכים בבדיקות אלה.
שלב זה יתבצע, ככלל, כמוגדר בקיט התקנה והרצה הכללי בכרך יסודות / מחזור חיים. להלן הדגשים המיוחדים לשלב זה, בנושאים הבאים:
בהתקנה הראשונה של חבילת ה- ERP יש לבצע בדיקת תכולה מקסימליסטית, עם דגש לגבי הפיתוחים הייחודיים, הממשקים ושילובם בחבילה. בהתקנת מהדורות יש לבצע בדיקת תכולה מינימליסטית, עם דגש לגבי התוספות במהדורה והשפעתן על הפיתוחים הייחודיים והממשקים למערכות אחרות.
מספר המשתמשים בחבילת ה- ERP בארגון הוא רב ביותר ומקיף כמעט את כל אגפי/ מחלקות הארגון ותחומי הפעילות.
שלב ההדרכה וההטמעה הנו קריטי במערך זה, והתשומות שיידרשו בנושא יהיו רבות. כדי לחסוך בעלויות מקובלת במימוש מערכות ERP שיטת הדרכה מסוג הדרך את המדריכים (Train the trainers) שמשמעותה להדריך משתמש מוביל בכל מקטע יישום. משתמש זה יעביר את הידע ליתר המשתמשים עד להרצת המערכת. המדריכים המקצועיים יתמקדו בהדרכת המשתמשים המובילים ובסיוע להתגברות על תקלות. מומלץ לבחון מימוש על פי שיטה זו.
ראה קיט הטמעת מערכת בכרך נושאים תומכים.
שלב זה מכיל גם תהליך הטמעה מסודר בו יוקצו מחד מדריכים להטמעה בשטח בין העובדים ומאידך יוקם צוות Help desk אשר יתמוך במדריכים של הספק ובמדריכים שמועסקים מתוך הארגון. יש לזכור להקצות לנושא משאבי כוח אדם ומשאבים אחרים כגון: חדרים, עמדות מחשב, מערכת תיעוד הדרכות ועוד.
עקב ההיקף הנרחב ביותר של חבילת ERP, מימוש המערכת והכנסתה לייצור יתבצעו, בד"כ, באופן הדרגתי. לעתים קיים צורך במימוש הדרגתי אף של מקטע בתוך חבילת ה- ERP לדוגמא מימוש מערך לוגיסטי בארגון גדול המכיל מספר רב של מחסנים ופעילות רכש מבוזרת, יבוצע באופן הדרגתי על פי מחלקות.
משמעות הדבר הנה שיש להשקיע תשומות רבות ובלתי נמנעות בממשקים זמניים בין המקטע שייושם למקטעים במערכת הישנה המיועדים להחלפה בהמשך. סדר הכניסה של מקטעי המערכת תלוי ביישום.
יש לזכור כי כל הסביבה הטכנולוגית הייתה אמורה להיבדק עוד קודם לכן בצורה מעמיקה כבסיס להתקנת המערכת בסיבית היצור. הנושא הטכנולוגי הנו נושא בפני עצמו ליחידות התשתית בתוך יחידות המחשוב.
שלב זה יתבצע, ככלל, בהתאם לקיט תפעול בכרך יסודות / מחזור חיים. להלן הדגשים המיוחדים לשלב זה, בנושאים הבאים:
יצרני החבילה מפעילים מרכז סיוע בינלאומי הפעיל בדרך כלל 24 שעות ביממה. הסיוע ניתן כחלק מתחזוקת המערכת. בנוסף, יש להפעיל, בארגון, מרכז תחזוקה וסיוע לחבילה שיכיל:
· מנהל המערכת (מומחה יישום או מנתח מערכות)
· איש טכני שיטפל בבסיס הנתונים וסיוע טכני
· מומחי יישום על פי הצורך
· מתכנתים במידה וקיים פיתוחים והתאמות ייחודיים.
גודל צוות התמיכה וכן הרכב הצוות (חיצוני/ פנימי) יקבע בהתאם ליישום.
שלב התחזוקה מחייב ניהול שינויים מסודר הן בצד האפליקטיבי והן בצד התשתיתי. מבחינת האפליקציה קיימים שינויים נדרשים אשר עשויים להשפיע על תהליכים ונתונים רבים. תיעוד שינויים אלה ועבודה לפי גרסאות מסודרות חשוב ביותר. מומלץ לשמר בכל רגע נתון מסמך מערכת אשר מתעד כל תהליך ותהליך בצורה העדכנית ביותר.
השינויים ביישום מחייבים לשמור על עדכניות מערכי ההדרכה ותסריטי הבדיקות.
עדכון גרסת חבילה או עדכונים טכנולוגיים כגון שדרוג גרסת בסיס נתונים או שדרוג חומרה מרכזית מחייב היערכות פרויקטלית מיוחדת אשר מחייבת תיעוד מסודר של העדכונים וההשלכות הנדרשות מעצם השינוי. פרויקטים אלה ינוהלו על פי תיעוד סטנדרטי לפרויקט של מפת"ח.
גלופת מסמך מערכת למערכות ERP מכילה את עץ מערכת המותאם לפיתוח במערכות ERP. גלופה זו אינה מכסה את עץ המערכת כולו ומדגישה רק רכיבים מיוחדים למערכות ERP. אין לראות בתכנים שבגלופה, כמו בכל גלופות מפת"ח, יותר מאשר דוגמא/המלצה.
גלופה זו משרתת את כל שלבי מחזור החיים של המערכת. להבנה של אופן התאמת הגלופה לשלבי מחזור החיים השונים מומלץ לעיין בכרך יסודות/מחזור חיים בקיטים המתאימים לכל שלב: ייזום, אפיון, בקשה להצעות, עיצוב ובנייה וכו' ולהתאים את השימוש בגלופה לשלב במחזור החיים בו נמצאת המערכת. מומלץ לעיין גם בקיט תיעוד שבכרך נושאים תומכים.
לעבודה מעשית יש להשתמש בגלופת העבודה המקבילה.
חבילות ERP הנן חבילות רב תחומיות המכילות מספר רב של מקטעי תוכנה. לפיכך, קיימות מספר אפשרויות לגבי מבנה המסמך:
· בניית עץ מערכת מלא לכל מקטע תוכנה.
· מיון המסמך לפי: פרק ראשי, מקטע תוכנה, תת פרק. לדוגמא 1. יעדים: פיננסי עם פירוט, לוגיסטיקה עם פירוט וכו'.
· מיון המסמך לפי פרק ראשי, תת פרק, מקטע לדוגמא: 1.1 לקוח/מומחה יישום ובתוכו פיננסי, לוגיסטיקה וכו'.
· מיון משולב: חלק מהפרקים יהיו כללים וחלק ימוינו לפי מקטעים.
מבנה המסמך שייבחר יותאם ליישום בצורה המיטבית.
המבנה המומלץ למערכות ERP הנו כדלהלן:
· פרקים: 0 - מנהלה, 3 - טכנולוגיה, 4 - מימוש, 5 - עלות, יהיו משותפים לכל מקטעי החבילה.
· פרק 1- יעדים ו- 2 - יישום ייבנו לכל מקטע תוכנה בנפרד. החלוקה לתת מקטע/תת פרק תותאם ליישום.
· ייבנה בנוסף פרק 2 - יישום לאפיון נושאים כלליים של החבילה, כגון: מעקב תהליכים, התרעות, קשר לאינטרנט, ותק החבילה ועוד.
קיימות בקיט זה גלופות נוספות המשרתות את שלב התחזוקה על פי סוגי שינויים שונים וכן עבור שינוי מקיף יותר.
להלן רשימת הגלופות המצורפת בקיט. הדוגמאות וחלק מנתוני הגלופות ניתנו בהתאמה לתוכנת SAP אך ניתנים להתאמה למערכות ERP אחרות:
· טופס העברה ליצור – תיעוד התוכניות המועברות ליצור
· מסמך תפעול - מכיל אוסף של מהלכי BATCH הנדרשים לביצוע
· טופס בקשה לשינוי – תיאור השינוי תוך התייחסות למסך ו/או דוח על פי הצורך
· טופס שינוי/הוספת מסך
· טופס שינוי/הוספת תוכנית
· טופס שינוי/הוספת מהלך
· טופס שינוי/הוספת דוח
· טופס שינוי/הוספת טופס
· טופס שינוי/הוספת ממשק
· טופס הסבה
כל אחד מטפסים אלה יכול להשתלב במסמך לניהול שינוי אשר מכיל מספר נושאים לשינוי. כנספחים למסמך המסגרת יכולים להצטרף נספחים על פי פירוט השינוי (מסך, דוח, תוכנית וכו') על פי הטפסים המוזכרים לעיל.
אבטחת איכות בפרויקט ERP תתמקד הן בתוצרים והן בתהליך.
אבטחת איכות של התוצרים תתמקד בטיב כל אחד ממסמכי הפרויקט:מסמך יזום, מסמך אפיון, מסמך בקשה להצעות וכו'.
עבור כל אחד ממסמכי הפרויקט יבחנו נושאים רבים ובהם:
· האם המסמך תואם את מטרתו?
· מה מידת מחויבות המעורבים לתוכן המסמך?
· האם מכיל מספיק מידע על מנת לקבל החלטה להמשך?
· האם ברור מה הצעד הבא ומה משמעויותיו?
· האם קשור בתכנית העבודה השנתית או בתכנית אב (תכנון אסטרטגי)?
· מי אישר את המסמך?
· האם נכתב לפי הכללים הנהוגים בארגון?
אבטחת איכות של תהליך ביצוע הפרויקט תתמקד, בין היתר, בנושאים הבאים:
· האם בוצע ניהול סיכונים?
· האם בוצעה אמידת עלויות?
· האם הוערכה עלות/תועלת?
· האם הוגדרו משאבים לפרויקט לכל אחד משלביו?
· האם הוגדרו ועדות ובעלי תפקידים לפרויקט?
· מהם נוהלי העבודה בין המעורבים לאורך ביצוע הפרויקט?
· מהי מחויבות הארגון לתהליך? עד כמה מעורבת ההנהלה?
· האם הוגדרה תכולת הפרויקט ושלבים לביצועו?
· האם קיימת היערכות ארגונית להטמעה, הדרכה, שינוי נהלי עבודה וכו'?
בכל אחד מנושאים אלה ואחרים ידריך איש אבטחת איכות את המעורבים בפרויקט, יהיה נוכח בועדות היגוי למיניהן ויסייע בנושאים כגון אמידת עלויות, ניהול סיכונים ועוד. פרויקט מסוג הטמעת מערכת ERPבארגון הוא מורכב מאד ומעורבים בו בעלי תפקידים רבים. איש האיכות אמור לבדוק האם נלקחו בחשבון הקשרים השונים בין הפעילויות, התחשבות בתלויות ואילוצים, הכנסת פעולות ללוחות הזמנים הקשורות לניהול הסיכונים שבוצע ונושאים נוספים.