שיתוף
תוכן העניינים
הירשמו לניוזלטר שלנו
אנחנו כאן כדי להצמיח את העסק שלכם
EFP ל-ERP, או בקשה להצעת מחיר לתכנון משאבים ארגוניים, הוא מסמך רשמי שארגונים מנפיקים לספקי תוכנות, במטרה לבקש הצעות מפורטות לפרויקט ERP ספציפי.
בשונה מ-RFI (בקשת מידע), שנועדה לצורכי גישוש, RFP הוא מסמך מנחה שמגדיר את צורכי הארגון שלכם הן מבחינה פונקציונלית והן מבחינה טכנית, ומבקש תשובות מובנות לגבי האופן שבו הספקים מתכוונים לענות לצרכים הללו.
מסמך RFP מבטא את הדרישות, האילוצים, מדדי ההצלחה, ציפיות הפריסה, צורכי השילוב, פרמטרים תקציביים ועוד, במטרה ליצור את הבסיס להערכת ספקים, הכנת תקציב פנימי ותוכנית ביצועית.
מסמך RFP מציע מסגרת עקבית להערכת התאמתם התפעולית של הספקים באופן שווה.
במקום להסתמך על רשמים אנקדוטיים או על תבניות שונות של הצעות, תוכלו לבקש מכל הספקים להשיב לאותן הדרישות, באותו המבנה ובאותה רמת פירוט.
כך תוכלו לבצע השוואה ישירה ומדויקת שמפחיתה הטיות, מבטיחה שכל הספקים יענו לרשימת דרישות זהה, ומייעלת את ההערכה האובייקטיבית על סמך מדדים מתועדים (התאמה טכנית, תמחור, לוחות זמנים להטמעה ומדרגיות) והתאמה לתרחישי השימוש.
רוב הכשלים בתחום ה-ERP אינם נובעים מטכנולוגיה, אלא מחוסר תיאום ציפיות.
בקשת EFP כתובה היטב ממזערת את הסיכון לציפיות לא מתואמות מכיוון שהיא מחייבת אתכם להגדיר מראש את היקף הפרויקט, את מדדי ההצלחה, את אילוצי המערכת ואת הציפיות של בעלי העניין.
בממשקים הפנימיים, היא מבטיחה תיאום בין בעלי העניין, ובממשקים החיצוניים היא נותנת לספקים את המידע הדרוש להם כדי להציע את הפתרון הטוב ביותר, ובו-זמנית גם להפחית את הסבירות לחריגות, לשינוי הזמנות ולמחלוקות לאחר החוזה, במהלך שלב ההטמעה.
הכנת RFP למערכת ERP מחייבת את בעלי העניין בארגון (פיננסים, תפעול, שרשרת אספקה, משאבי אנוש ועוד) לזהות ולתעד דרישות פונקציונליות, תפעוליות וטכניות בין המחלקות, ולחשוף פערים בתהליכי העבודה הקיימים, נקודות אינטגרציה עם מערכות ותיקות, ודרישות ציות שאינן תמיד מתועדות במקומות אחרים.
עבודת החשיפה הזו היא לעתים קרובות חשובה יותר מהכנת ה-RFP עצמו.
RFP יעיל ל-ERP מגדיר פרמטרים של עלות, צפי ללוחות זמנים, תוצרי מפתח והקצאת משאבים.
הספקים יהיו חייבים לנסח תשובה עם מבני תמחור שמבוססים על מרכיבי הפרויקט המפורטים, כולל מודלים של רישוי, עלויות להתאמה אישית, שירותי הטמעה, תמיכה והכשרה.
כך הארגון יוכל לבנות תקציב מציאותי להטמעת מערכת ERP ולתאם בין תכנון המשאבים הפנימיים למועדי האספקה של הספק.
המדריך יוביל אותך והצוות שלך להצלחה
תקציר המנהלים מפרט את ההקשר, המטרה והציפיות הכלליות של פרויקט ה-ERP – כאן תגדירו את מטרת והיקף ה-RFP במונחים עסקיים. לא מדובר בהכרח בסעיף טכני, אלא בהצהרת כוונות.
הוא אמור לענות על שאלות כמו:
התקציר נותן לספקים הקשר מידי וקובע את הטון באופן פנימי לבעלי עניין, שייתכן שלא יקראו את המסמך המלא.
סעיף זה מעניק לספקים את ההקשר התפעולי הדרוש להם. הוא מספק נתונים ארגוניים רלוונטיים לגבי גודל הארגון, מספר העובדים, טביעת הרגל הגלובלית שלו, מספר היחידות העסקיות, יכולות טכנולוגיות נוכחיות ועוד. הפרטים הללו משפיעים על כל ההיבטים, כמו מודלי הרישוי, ארכיטקטורת הפריסה וכל מה שביניהם.
הגדרה ברורה של המטרות התפעוליות, האסטרטגיות והטכניות הקשורות לפרויקט ה-ERP. במילים אחרות, תצטרכו להגדיר איך ההצלחה תיראה, לא רק לצוות ה-IT, אלא לכל העסק.
האם אתם מעוניינים בסגירות פיננסיות מהירות יותר? דיוק מלאי טוב יותר? דיווח בזמן אמת?
הגדירו מדדי ביצועים מדידים כמו שיעורי אוטומציה של תהליכים, הפחתת עלויות, שיפור דיוק הדיווח, או יעדים לזמני פעילות תפעוליים. הם ינחו בשלב מאוחר יותר את סדרי העדיפויות בשלב ההטמעה ואת ההערכות לאחר העלייה לאוויר.
ה-RFP חייב לכסות את הדרישות הפונקציונליות – על פי המודול או תחום הפעילות העסקית (כספים, רכש, ייצור, מלאי, כ"א, CRM) ואת הציפיות הטכניות, כמו הארכיטקטורה, מדדי הביצועים, פרוטוקולי אבטחה, מבני נתונים ומדרגיות.
סווגו את הדרישות כ"חובה", "מומלץ" או "רשות" ותנו לספקים דרך מובנית להשיב (לדוגמה "ברירת מחדל נתמכת", "דורש התאמה אישית", "לא נתמך").
פרטו את ארכיטקטורת הפריסה המועדפת ואת מודלי האירוח הדרושים, כמו ענן לדייר-יחיד, תוכנת כשירות למספר דיירים, או מרכז נתונים פרטי. הבהירו מהם אילוצי התאימות, ההשהיה או האבטחה שמשפיעים על מודל הפריסה. הספקים יצטרכו להוכיח התאמה למדיניות התשתיות ולספק דיאגרמות ארכיטקטורה בהתאם לרלוונטיות.
ציינו מה הן מערכות צד ג' שדורשות יכולת פעולה הדדית עם פלטפורמת ה-ERP, כולל מערכות לניהול קשרי לקוחות, ניהול שרשרת האספקה, מערכות מידע לגבי כ"א וכלים ספציפיים אחרים של הענף. צרפו מפרטי ממשקים, פורמטים לחילופי נתונים ותדירות סינכרוניזציה. הספקים יצטרכו לפרט את אסטרטגיות ה-middleware שלהם או את המחברים המובנים-מראש שלהם על פי הרלוונטיות.
הגדירו תאריך עלייה לאוויר, ציינו תאריכי יעד שאינם ניתנים לשינוי (כמו תחילת שנת הכספים, סגירה בעקבות מכירה, או תאריכי תאימות רגולטוריים), ציוני דרך חשובים (אימות דרישות, קונפיגורציה, בדיקות, UAT והדרכה) וזמינות משאבים פנימיים (כולל תקופות שבהן לא ניתן להקצות משאבים) – הספקים נדרשים להתאים את מתודולוגיית היישום שלהם ללוחות הזמנים ולזהות כל התנגשות אפשרית במשאבים או בזמנים.
ציינו את הציפיות לתמיכה לאחר העלייה לאוויר, את הדרישות להעברת ידע, את תוצרי התיעוד ואת מודלי ההכשרה – הבהירו אם אתם מעדיפים מפגשים באתר החברה, הכשרה מרחוק או מודל הכשרה למדריכים.
הגדירו הסכמי תנאי שירות (SLA), שעות תמיכה, נהלי העברת תקלות לגורמים בכירים יותר, זמנים לפתרון פניות, שדרוגי גרסאות וגישה לבסיסי ידע.
חשוב לכלול גם את הציפיות לגבי התיעוד. הגורמים הללו מדורגים לעתים קרובות בתחתית רשימת העדיפויות אבל הם חיוניים לאימוץ המערכות בטווח הארוך.
הבהירו אילו נתונים יש להעביר (נתוני אב, היסטוריית עסקאות, ארכיוני תאימות) ומאילו מערכות.
ספקו הערכות נפח ושיקולים לגבי איכות הנתונים, אם הם זמינים. הדגישו את הציפיות שלכם לגבי בקרת גישה, רישום ביקורות, הצפנה, גיבוי ומסגרות תאימות (לדוגמה GDPR, HIPAA, ISO 27001). כך תאפשרו לספקים להציע אסטרטגיות להעברת הנתונים ולאשר את ההסמכות.
פרטו את הקריטריונים (מבחינת הכמות והאיכות) שישמשו להערכת ההצעות.
הגדירו קטגוריות דירוג משוקללות כמו פונקציונליות, גישה להטמעה, תמחור, ניסיון הספק, תמיכה, צמצום סיכונים וכו'. ציינו קריטריונים ברורים כדי שהספקים יוכלו לתעדף את התשובות שלהם בהתאם.
גישה כזו תזרז את תהליך קבלת ההחלטות הפנימי ותבטל את הצורך בדיונים סובייקטיביים במהלך השלבים הסופיים.
לא מצופה מכם לשתף את כל התקציב שלכם, אבל כן תצטרכו להגדיר פורמט לתמחור. בקשו פירוט לפי מודול, סוג משתמש, שירותי הטמעה, שילובים, הכשרה, תמיכה ותחזוקה שנתית.
ציינו אם אתם מעדיפים רישיון לצמיתות או מינוי. כך תוכלו להשוות באופן עקבי ולהציף עלויות חבויות בשלב מוקדם. הבהירו גם את כל האילוצים התקציביים או את קווי מדיניות הרכש שאליהם הספקים צריכים להיות מודעים.
חשוב לכלול שאלות לגבי היסטוריית החברה, היציבות הפיננסית שלה, בסיס לקוחותיה, התמחות בענפים שונים, הסמכות ויכולת אספקה.
דרשו מידע מפורט לגבי מבנה הצוות, אנשי מפתח בחברה, קבלני משנה וניסיון קודם עם הטמעות ERP דומות. כך תוכלו לתמוך בצמצום הסיכונים ובבדיקת נאותות של הספקים.
סעיף זה יסנן ספקים חסרי ניסיון או יכולת. בקשו הוכחה ליציבות כספית, מידע על בסיס הלקוחות מהענף שלכם, הסמכות רלוונטיות, רקורד בתחום ההטמעות והמלצות. בקשו גם קורות חיים של אנשי מפתח בצוות, מתודולוגיות לפרויקטים ומבני תמיכה כדי להעריך את רמת הסיכון ביכולת האספקה.
סיימו עם סעיף אדמיניסטרטיבי ברור ומדויק שמגדיר את פורמט התשובה (Word, Excel, PDF), שיטות ההגשה, מועדים אחרונים ואנשי קשר, ומבהיר את הציפיות בנוגע לשאלות ותשובות של מגישי הצעות המחיר, הדגמות חיות או ראיונות עם רשימת ספקים מועדפים.
ראשית, חשוב שתהיו ברורים וישירים ככל האפשר. הימנעו מניסוחים סובייקטיביים או עמומים. לדוגמה, ל"ממשק ידידותי למשתמש" או ל"יכולות דיווח חזקות" יש משמעויות שונות עבור ספקים שונים.
במקום זאת, ציינו מה תרצו להשיג, לדוגמה "לוחות מחוונים מבוססי-תפקידים, עם הסתעפות החל מספר החשבונות הראשי (GL) ועד לרמת העסקה" או "יכולת להגדיר תהליכי אישור על פי מרכז עלות". הספקים אינם יכולים לענות באופן מדויק אם הדרישה אינה ברורה, ולא תוכלו להטיל עליהם אחריות בשלב מאוחר יותר. שפה ישירה ופשוטה מפחיתה אי הבנות.
מסמך ה-RFP חייב לשקף את הצרכים האמיתיים והאילוצים של כל היחידות העסקיות שיושפעו מהטמעת מערכת ה-ERP. סביר להניח שתחמיצו דרישות קריטיות אם בעלי העניין הרלוונטיים לא יהיו מעורבים בתהליך הכנת הטיוטה. גרוע מכך – אתם תסבלו משיעור אימוץ נמוך לאחר ההטמעה מכיוון שהמערכת לא תשקף את הצרכים התפעוליים האמיתיים.
ערבו את ראשי המחלקות בשלב מוקדם בתהליך. קיום סדנאות או ראיונות מובנים יאפשר להכין סקירה מדויקת של הדרישות ויגביר את תחושת המעורבות בפרויקט.
אל תאפשרו לספקים להגיש הצעות בטפסים משלהם. אם תעשו זאת, תקבלו פורמטים שונים, מודלים שונים של תמחור ופרשנויות שונות לדרישות שלכם. במצב זה, ההשוואה בין ההצעות תהיה כמעט בלתי-אפשרית.
הגדירו תבניות תגובה סטנדרטיות, כמו מטריצות לדרישות, טבלאות תמחור, לוחות זמנים להטמעה והסכמי תנאי שירות לתמיכה. בקשו מהספקים להשיב באמצעות הטופס שלכם. דבר זה יאפשר לכם לחסוך זמן רב במהלך ההערכה ולזהות בקלות רבה יותר פערים ואת הנקודות בהן ניתן להתפשר.
תוכלו לצפות שהספקים יבקשו הבהרות, גם אם ה-RFP שלכם מנוסח היטב.
הכינו חלון רשמי לשאלות ותשובות לפני מועד ההגשה האחרון. השתמשו ביומן הבהרות משותף כדי שכל הספקים יקבלו את אותו המידע באותו הזמן.
נקטו בגישה יוזמת. בדקו את ה-RFP עם הצוותים כדי לזהות תחומי בלבול אפשריים לפני שהספקים מעלים אותם. אם תחכו עד לאחר ההגשה כדי לטפל בהם, תצטרכו להאריך את לוחות הזמנים או לבדוק הצעות שאינן תואמות לכוונות שלכם.
הבעיה הנפוצה ביותר במסמכי RFP ל-ERP היא חוסר ספציפיות. דרישות כמו "תפעול יעיל", "שיפור הדיווח" או "שיפור חוויית המשתמש" אינן מגדירות מרחב פעולה מדויק.
אם הספקים אינם יודעים כיצד אתם מגדירים הצלחה, הם יצטרכו להניח, וההנחות הללו יהיו שונות מהצעה להצעה.
הניסוח צריך להיות ברור ברמת התהליך. לדוגמה, תוכלו להגדיר את מחזור הזמן שאתם רוצים לצמצם, את הדוחות שתרצו להפוך לאוטומטיים או את כללי התאימות שבהם אתם חייבים לעמוד.
כל דרישה עמומה היא פתח לשונות, שתהפוך לגורם סיכון במהלך ההטמעה ובמהלך המו"מ על החוזה.
שגיאה נפוצה נוספת היא הגדרת תאריכי עלייה לאוויר אגרסיביים מדי או שרירותיים, ללא בדיקה בתוך הארגון.
הטמעת מערכת ERP דורשת משאבים רבים. היא מחייבת עיצוב מחדש של תהליכים, הגירת נתונים, בדיקה, ניהול שינויים והכשרה, ואלו שלבים שלא ניתן לדחוס ללא הגבלה.
אם ציר הזמן מוכתב על ידי מועדי סיום חיצוניים, או יעדים בלוח השנה מבלי להתחשב במוכנות הפנימית, הספקים יבחרו שלא להגיש הצעות מחיר או להגיש הצעות עם מרווחי ביטחון גבוהים יותר, כדי להגן על עצמם מפני הסיכון.
לוח זמנים מציאותי צריך להיות מבוסס על זמינות הארגון, מהירות קבלת ההחלטות והמורכבות, ולא על העדפות ניהוליות או יעד כספי.
הערכה ללא מבנה תוביל לדירוג לא עקבי ולאי הסכמה בין בעלי העניין.
אם לא תיעדתם את אופן הערכת ההצעות ואת אופן שקלולן בהתאם להערכות אלו, סביר להניח שתבססו את ההחלטות שלכם על איכות המצגת או על המוניטין לכאורה של הספק.
הגדירו את מודל הדירוג שלכם מראש. תנו עדיפות להתאמה לעסק, למתודולוגיית ההטמעה, להתאמה הפונקציונלית ולתמיכה לטווח הארוך, במקום להתמקד ביתרונות יחסיים שטחיים.
גישה כזו אף תכוון את הספקים לתחומים שבהם אתם רוצים להתמקד ותשפר את איכות ההצעות שהם יגישו.
רוב הארגונים מסתמכים על פלטפורמות חיצוניות לצורכי CRM, כ"א, לוגיסטיקה, מסחר אלקטרוני וניתוח. אם המערכות הללו אינן נלקחות בחשבון ב-RFP, מורכבות השילוב תתגלה מאוחר מדי, בדרך כלל במהלך ההטמעה.
באופן דומה, הערכה לא מספקת של המאמץ הדרוש להעברת הנתונים תוביל להחמצת מועדי ההגשה ולאיכות נתונים ירודה בעת העלייה לאוויר. תצטרכו להגדיר את דרישות הממשקים, ולהבהיר את את תחומי האחריות על הבעלות על הנתונים ועל ניקויים – לפני שתהליך בחירת הספקים מתחיל.
לסיכום, כדי לנסח היטב מסמך RFP ל-ERP, יש להתייחס אליו כאל כלי תפעולי שתפקידו להגדיר את סדרי העדיפויות של הארגון, לשלוט על ההיקף והעלות ולהניח את היסודות להטמעה מוצלחת.
הוא כופה בהירות במקרים שבהם עמימות משביתה בדרך כלל פרויקטים. הוא חושף סיכונים לפני חתימת החוזים ומספק לצוותים הפנימיים ולשותפים החיצוניים שלכם מסגרת עבודה משותפת מובנה.
השקעת זמן בהגדרת הדרישות, עירוב בעלי העניין, סטנדרטיזציה של תגובות הספקים ומניעת שגיאות נפוצות תשתלם לא רק במהלך בחירת הספקים, אלא גם במשך כל מחזור החיים של ה-ERP.
התייחסו ל-RFP כאל התוצר הראשון האמיתי של פרויקט הטמעת מערכת ERP ובנו אותו ברמת הדיוק והאמינות שאתם מצפים לקבל מהמערכת עצמה.
תכנון ביקושים הוא תהליך בניהול שרשרת האספקה המסייע לחברות לתכנן ביקוש עתידי למוצר או שירות וליישם אסטרטגיה תפעולית כדי להתאים בהצלחה את התפוקה בהתאם לביקוש, תוך איזון בין רמות מלאי מספקות לרמות ביקוש הלקוחות מבלי שיהיו עודפים.
כיצד מסייע תכנון וניתוח פיננסי (FP&A) לעסקים לקבל החלטות מושכלות, וכיצד השינויים הטכנולוגיים בשנים האחרונות הופכים אותו ליעיל יותר
