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

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

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

ניהול קפדני ומפורט של תוכנית עבודה

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

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

מעורבות הנהלה

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

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

הגדרת תכולת עבודה (Scope Of Work) מדויקת וברורה

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

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

אינטגרציה ו – Cross Function

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

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

הימנעות משינויי תוכנה ועבודה עם מערכת "Plain Vanilla"

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

בניית צוות מנוסה וקבוע לפרויקט

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

הגדרת פונקצית בקרה פנימית

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

	השתתפות בישיבות מנהלת הפרויקט - בקרה על תוכנית העבודה והעלאת סיכונים ו"צווארי בקבוק"
	בקרה על יישום מסמך התכולה (SOW) בשלב מימוש הפרויקט
	בקרה מדגמית על תקינות תשתיות הנתונים המרכזיות המועברות למערכת
	בקרה נוספת על סגירות התהליכים ונושאי Cross Function
	בקרת מסמכים ורמת התיעוד בפרויקט
	בקרה על יישום תקני איכות תפעולים (ISO) או חשבונאים (SOX) לאורך הפרויקט

תגבור משתמשי המפתח לאורך הפרויקט

בתחילת הפרויקט מוגדרים צוותי העבודה ומשאבי הארגון, הנדרשים להיות מעורבים בפרויקט. אחת הפונקציות המהותיות הינה פונקציית משתמש המפתח (Key user/Track leader).

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

טיוב נתונים, בנית תשתיות ושמירת הסטוריה

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

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

ניהול שינויים

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

בדיקות קבלה

סמוך לתקופת ה"עלייה לאוויר" מתבצעות בדיקות קבלה של המערכת. בדיקות קבלה נעשות הן ברמת מודול/תחום ספציפי (Unit test) והן ברמת תהליכי העבודה כוללים (Integration test). יש להקפיד לבצע את בדיקות הקבלה על תהליכי העבודה הספציפיים לארגון ועל בסיס תסריטים שנבנו והוגדרו מראש בשיתוף משתמשי המפתח ולתעד את ממצאי הבדיקות. בנוסף, מומלץ לשים דגש על בדיקות קבלה בנושאי ממשקים/התאמות פרטיות שנעשו ביישום הספציפי.