איך לבחור מערכת ERP? צ’קליסט, טבלת ניקוד ותוכנית פיילוט

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

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

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

למה לא מתחילים בהשוואת פיצ’רים?

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

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

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

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

מה לבדוק בבחירת מערכת ERP? 10 קריטריונים

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

1. התאמה לתהליכים. המערכת בונה את התהליכים שלכם כמו שהם, כולל שרשראות אישור, סטטוסים וחריגים? בקשו לראות את התהליך שלכם, לא את התהליך הסטנדרטי של הספק.
2. גמישות בלי קוד. מי משנה שדות, טפסים, אוטומציות ודוחות אחרי העלייה לאוויר? מנהל מערכת דרך הגדרות, או מפתח וקריאת שירות לספק? הנקודה הזו קובעת אם המערכת תעמוד בקצב של העסק.
3. הרשאות. אפשר להגדיר הרשאות לפי תפקיד, מחלקה, חברה ושדה? שאלו מה קורה כשעובד אחד עובד מול כמה צוותים או ישויות.
4. מבנה רב-חברות ורב-מטבעי. כל חברה בת פועלת כישות עצמאית עם נתונים משלה, וההנהלה מקבלת תמונה מאוחדת? איך עובדים תהליכים בין חברות?
5. שפות. תמיכה אמיתית, לא רק תפריטים מתורגמים. בעברית ובערבית, תצוגה מימין לשמאל צריכה לעבוד בטפסים, במסמכים ובדוחות.
6. זמן הטמעה. בקשו תוכנית ריאלית: מה עולה ראשון, מה אחר כך, ומי צריך להיות מעורב מהצד שלכם. היזהרו מפרויקט שמייצר ערך רק בסוף.
7. אימוץ. מערכת שאנשים נמנעים ממנה היא מערכת שנכשלה. בדקו אם אפשר לפשט מסכים לפי תפקיד, כך שטכנאי שטח יראה משהו אחר מבקר כספים.
8. הסבת נתונים. איך יעברו הלקוחות, העסקאות הפתוחות, הפרויקטים, המסמכים וההיסטוריה? מי ממפה שדות, מי מנקה, ואיך בודקים לפני העלייה לאוויר?
9. API וממשקים. יש API פתוח? איך עובד האימות? יש חיבור ל-Active Directory או ל-Azure? אילו מערכות עדיין יצטרכו להתחבר, ואיך?
10. רוחב המודולים. המערכת מכסה את המחלקות שאתם צריכים: מכירות, תפעול, פרויקטים, שירות, איכות, משאבי אנוש וכספים? והאם המודולים חולקים מודל נתונים אחד?

מודולים שחוברו או מערכת אחת: מה ההבדל בפועל?

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

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

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

איך משווים בין מערכות ERP? טבלת ניקוד לספקים

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

הנוסחה: בכל שורה, המשקל (1-5) כפול הציון של הספק (1-5). מחברים את כל השורות ומקבלים ציון משוקלל לכל ספק.

קריטריון	משקל (1-5)	ספק א	ספק ב	ספק ג
התאמה לתהליכים
גמישות בלי קוד
הרשאות
מבנה רב-חברות ורב-מטבעי
שפות ותמיכה ב-RTL
זמן הטמעה
אימוץ
הסבת נתונים
API וממשקים
רוחב המודולים ומודל נתונים אחד
סה”כ משוקלל

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

אילו שאלות כל בעל תפקיד צריך לשאול?

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

• סמנכ”ל תפעול: נוכל לשנות תהליך עבודה בעצמנו בחודש הבא, כשהתהליך משתנה? איך תפעול, מכירות ושירות חולקים נתונים?
• מנהל IT: איך מנוהלים הרשאות, תיעוד פעולות וחיבור לניהול זהויות? מה ה-API חושף? כמה עבודת IT שוטפת המערכת תדרוש?
• סמנכ”ל כספים: מה העלות הכוללת לאורך כמה שנים, כולל הטמעה, יועצים ובקשות שינוי? נקבל דיווח אמין בין החברות בקבוצה בלי התאמות ידניות?

מה לבקש לראות בהדגמה של מערכת ERP?

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

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

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

איך מריצים פיילוט שמראה את האמת?

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

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

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

איך יודעים שאתם מוכנים לפנות לספקים?

סמנו מה כבר יש לכם:

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

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

איך זה נראה באוריגמי

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

לצוות ה-IT יש הרשאות מדויקות, חיבור ל-AD/Azure וAPI פתוח. קבוצות מקבלות ריבוי חברות ומטבעות עם תמונה מאוחדת, וההטמעה נמשכת בדרך כלל שבועות ולא חודשים.

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

קריאה נוספת: מתי להחליף מערכת ERP · הטמעת מערכת ERP בשלבים · אבטחת מידע במערכת עסקית אחת

שאלות נפוצות

מה לבקש לראות בהדגמה של מערכת ERP?

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

כמה ספקים כדאי לבדוק?

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

מה הקריטריון הכי חשוב בבחירת מערכת?

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

כמה זמן צריך להימשך פיילוט?

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

האם מחלקת IT צריכה להוביל את הבדיקה?

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

איזו מערכת ERP מומלצת לארגון בינוני?

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

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

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