תפריט נגישות

בחירת מערכת ERP לארגוני SMB

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

יעדים ומטרות

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

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

אפיון דרישות RFQ

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

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

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

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

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

 מבנה המסמך יהיה:

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

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

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

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

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

 בחינת חלופות

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

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

שקלול החלופות

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


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

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

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

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

 לסיכום

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

 ליצירת קשר: amit@goren-ltd.co.il