תפריט נגישות

אפיון צרכי הארגון, בחינה ובחירת פתרון מחשובי

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

כללי

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

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

יש לחלק את התהליך לשלושה שלבים:

שלב א – אפיון צרכי הארגון

שלב ב – הפניה לספקים

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

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

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

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

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

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

1. רישיונות תוכנה

2. מהלך יישום והטמעה לשם הפעלה אופרטיבית של המערכת

3 .תחזוקה שוטפת

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

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

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

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

תיאור החברה וסביבתה העסקית

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

הגדרת הדרישות מהמערכת החדשה

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

הצהרות והתחייבויות הספק

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

מבנה הצעת המחיר של הספק

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

שלב ב – הפניה לספקים

כיצד ניצור SHORT LIST

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

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

מהם הנושאים החשובים במענה הספק

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

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

כיצד לוודא שהספק אכן מבין את תכולת הפרויקט

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

תסריט דרישות – כאשר היקף הדרישות מאפשר מימושן והצגתן טרם להתקשרות.

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

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

כיצד ניצור התרשמות נכונה מפתרונות תוכנה

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

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

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

חשיבותם של לקוחות ממליצים

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

1. מהו היקף כוח האדם הקיים אצל הלקוח  הממליץ והנדרש לתחזוקת הפתרון המוצע.

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

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

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

לסיכום

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

כותב המאמר: שמואל מרדלר, מנכ"ל פעילות ERP.ORG

ליצירת קשר: Shmuel.merdler@erp.org.il

פרסום באתר