יישומי ERP בשוק ה-SMB: פרק א'
פרק ב' – המרשם
תקציר פרק א' – התסמונת
תקציבים מצומצמים ומגבלת כוח אדם הם חלק מהמאפיינים של ארגונים בשוק ה-SMB. לנתונים 
אלו השפעה דומיננטית על ההתנהלות ומידת ההצלחה של פרוייקטי ERP המתקיימים בהם. המפגש בין תכונות אלו ובין מתודולוגיות יישום המבוססות על מצגות ומהלכים מזורזים, יוצר תנאים בעייתיים בפרוייקט ה-ERP אשר חשוב להיות מודעים להם ורצוי להיערך נכון לקראתם. פרק א' התמקד בגורמי הסיכון שקיימים בפרוייקטים אלו והסיבות להיווצרותם. פרק זה עוסק בהיערכות וצעדי מניעה שיכולים להינקט לקראתם.
אלו השפעה דומיננטית על ההתנהלות ומידת ההצלחה של פרוייקטי ERP המתקיימים בהם. המפגש בין תכונות אלו ובין מתודולוגיות יישום המבוססות על מצגות ומהלכים מזורזים, יוצר תנאים בעייתיים בפרוייקט ה-ERP אשר חשוב להיות מודעים להם ורצוי להיערך נכון לקראתם. פרק א' התמקד בגורמי הסיכון שקיימים בפרוייקטים אלו והסיבות להיווצרותם. פרק זה עוסק בהיערכות וצעדי מניעה שיכולים להינקט לקראתם.דילמת "בנה ביתך"
כפי שצוין בפרק הקודם, מצבו של ארגון הנמצא על סף כניסה לפרוייקט ERP משול לאדם שרוצה לבנות את ביתו ועומד בפני דילמה: האם לנהל מבצע שכזה בעצמו (לעבוד ישירות מול כל קבלני הביצוע) או שעליו להיעזר בגורם חיצוני מקצועי אשר יסייע לו בכך (דוגמת מפקח בניה). אגב, בפני ידידנו עומדת אפשרות נוספת והיא לרכוש דירה מקבלן כאופצייה אשר תאפשר לו "ראש שקט" לחלוטין, אלא שכאן בדיוק נגמר הדמיון בין המשל לנמשל. להבדיל מסיפור הדירה, לא ניתן לרכוש מערכת ERP מוכנה ועובדת מבלי שלארגון תהייה מעורבות מלאה בעיצובה ובהקמתה.
נמצא כי חלק מהארגונים כלל אינם נדרשים לדילמה זו מהטעם הפשוט שאינם מודעים למורכבותו של הפרוייקט שעומד לפניהם. חלקם מניחים שמדובר ברכישת תוכנה, בדומה לרכישת מכונית או כל מוצר צריכה אחר ולכן גם לא נערכים לכך.
פרוייקט ERP או החלפת תוכנה?
ובכן, פרוייקט ERP אינו פרוייקט של רכישה או החלפת תוכנה. אמנם הרכישה וההחלפה מהווים חלק מתכולת הפרוייקט, אך ארגונים אשר רואים בכך את חזות הכל מפספסים את מהותה של תפיסת ה-ERP. בפספוס זה גם נכללת החמצת העיתוי לביצוע רה-ארגון תהליכי וארגוני שייתכן ונדחה במשך שנים ואשר פרוייקט ה-ERP מהווה הזדמנות כה טובה לביצועו.
ההשקעה העצומה הנדרשת מצד הארגון (בכסף, בזמן ובתשומת לב) יכולה להצדיק את עצמה רק אם ימומשו הערכים המוספים שב- ERP שעיקרם: אינטגרציה בין מערכות, ניהול וביצוע נכון של תהליכים עסקיים תחת מעטפת יישומית אחת, וכמובן שיפור יכולות התכנון, השליטה והבקרה.
במהלך הפרוייקט צפויות להתעורר שאלות רבות סביב השינויים הדרושים בתהליכי ונהלי עבודה, תחומי אחריות וממשקים בין גורמי הארגון. חלק ניכר משאלות אלו ניתן לצפות מראש וחשוב להיערך לקראתן עוד לפני תחילתו. התעלמות מנושא זה ודחיית הטיפול בו לתקופת הפרוייקט בלבד עלולה להתגלות כשגיאה קריטית.
תבשיל בטעם ביתי
כעת, לאחר שברורה לארגון מורכבות המשימה שניצבת בפניו, הוא יכול לבחון את סוגיית הניהול העצמי מול הסתייעות בגורם מקצועי חיצוני. נקדים ונאמר כי לאפשרות ה"בישול הביתי" יש מאפיינים ברורים לטוב ולרע. ארגון שנכנס בכוחות עצמו להרפתקה מורכבת מדי עם ניסיון מועט מדי עלול להקדיח את התבשיל ולפגום בתוצרי הפרוייקט.
בשלב זה על הארגון לאתר מתוכו מועמד פוטנציאלי שינהל את המשימה, ולבחון היטב את כשירותו לתפקיד. כשירות זו משקללת מספר גורמים:
- ידע והבנה: הבנה מהי מערכת ERP, הכרת התפיסה אותה ERP מייצג, תועלות והשלכות שיש לתפיסה זו על הארגון, הבנת התנהלות הפרוייקט ומרכיביו תוך אבחנה בין כללי "עשה" ו"אל תעשה".
- ניסיון: התנסות קודמת בביצוע פרוייקטי ERP בארגונים בסביבה דומה ותוך מילוי תפקיד דומה.
- זמן פנוי: יכולת המימוש ואיכות הביצוע תלויים בפרק הזמן שיכול להקדיש המועמד לטובת הפרוייקט וזאת מעבר למטלותיו השוטפות.
- מורכבות הנושא: פרוייקט בעל מאפיינים מורכבים וסבוכים במיוחד מחייב סיוע של גורמי מקצוע.
- הכרה ומעמד ארגוני: היחס וההכרה לה יזכה המועמד לתפקיד מצד שאר גורמי הארגון והשפעתם על התנהלות הפרוייקט.
מול אפשרות זו עומדת האפשרות להסתייע בגורם חיצוני מקצועי. גורם זה יידרש להוכיח את יכולותיו להתמודד בדיוק עם אותן סוגיות, ומן הראוי שהארגון ידרוש לראות קבלות מוכחות ליכולות אלו. ושוב כפי שכבר צויין, הסתייעות זו בניהול ובליווי המקצועי לא תחסוך מהארגון את הצורך במעורבות מלאה בהתנהלות הפרוייקט וביצוע המשימות השוטפות.
מהו אותו ערך מוסף שמביא עימו לפרוייקט גורם חיצוני מקצועי? מהן התועלות שבגללן כדאי להוסיף לחגיגה המורכבת גם כך עוד גורם נוסף?
הנוסחה להצלחה
פרוייקט ERP הינו פאזל מורכב של מגוון חלקים שניתן לחלקם ל- 3 קבוצות עיקריות:
- תוכנה\מיחשוב:
הפונקציונליות של המודולים השונים, גמישותה לשינויים ותוספות, זמינות דוחות
ושאילתות, מראה המסכים, מבנה הקבצים, טכנולוגיה וממשקים למערכות היקפיות,
שרתים, תקשורת ובסיס נתונים.
- יישום:
חברת היישום מנהל הפרוייקט וצוותו, ניסיונם הקודם בביצוע פרוייקטים דומים,
מתודולוגית היישום, מסגרות ארגוניות בהתנהלות הפרוייקט וניהולו.
- ארגון:
המנכ"ל, ההנהלה וצוות העובדים, ציפיותיהם מתוצרי הפרוייקט, מוכנות ואילוצים ביחס
לצפוי, צרכים ותהליכים העסקיים, נהלי העבודה, תשתיות הנתונים.
תוצאת הפרוייקט תלויה באיכויות של גורמים אלו ובשילוב הנכון המתקיים ביניהם. הנוסחה הבאה משקפת את התלות ההדדית שבין הגורמים והשפעתם על התוצאה הסופית:
ארגון x יישום x תוכנה = תוצאת הפרוייקט
מאחר שאף אחד מגורמי המשוואה אינו מושלם (ערכו תמיד קטן מ-100%), שיפור התוצאה מותנה
במיקסום הפוטנציאל שטמון בכל אחד ממרכיביה. יתרה מכך, כשלון מוחלט באחד המרכיבים ימוטט את הפרוייקט כולו.
היכולת לדעת
וכאן בדיוק נכנס תפקידו של גוף חיצוני מקצועי, לבצע את אותן פעילויות אשר יבטיחו מוכנות מירבית לקראת תחילת הפרוייקט מצד כל הגורמים, ובהמשך לשמש העין המשגיחה שלא ייעשו צעדים שעלולים למוטט את הפרוייקט או לפגום בהצלחתו.
הליווי של גוף זה מתחיל כבר בשלבי טרום הפרוייקט:
- משלב ניתוח הצרכים והבנת הביזנס, ועבור ברישום מסודר של דרישות אלו,
- התבוננות סביב והחיפוש אחר פתרונות נכונים ויעילים יותר להתנהלות מחלקות בארגון,
- חשיבה קדימה לעבר צרכים עתידיים שצפויים להתקיים ושרצוי להיערך לקראתם,
- בחינה אובייקטיבית של חבילות תוכנה אפשריות,
- בחירת הפתרון המתאים באמת ולא זה שרק נראה: "סקסי" יותר \ זול יותר \ קל יותר…
בהמשך, ולפי מידת מוכנות הארגון לפרוייקט והיקף השינויים הצפויים צריכה להיעשות ההכנה המקדימה. זהו שלב ההיערכות הארגונית:
- הכנה זו נועדה למקד את מתכונת העבודה העתידית בעיקר בנושאים בהם צפויים השינויים. לטפל
- בבנייה, איסוף וטיוב מקדים של תשתיות נתונים, וכן להכנה של טפסים ודוחות הכרחיים.
- הכנה זו מספקת תשובות ברורות ביחס לחלק מהשאלות, ומאפשרת לבודד שאלות אחרות שהתשובה
- ביחס אליהם תתברר במהלך פרוייקט היישום עפ"י יכולות התוכנה.
- הודות להכנה זו פרוייקט היישום ממוקד ומהיר יותר, בזבוזי זמן יקרים נחסכים, גורמי הארגון
- מגיעים לפרוייקט עם הבנה ומוכנות מנטלית טובים יותר לקראת הצפוי.
השלב האחרון הוא שלב הפרוייקט
- ניהול מקצועי של הפרוייקט מטעם הלקוח ולצד חברת היישום.
- שמירה על איכות הפתרון המוצע ללקוח,
- מיקוד הלקוח בעיקר ומניעת התבדרותו לתחומים שגויים.
האפקט והתועלת המירביים לפרוייקט מושגים כאשר אותו גורם מקצועי מלווה את הפרויקט לכל אורכו ושלביו, מבלי שנדרשת "החלפת סוסים" במהלכו. כך נשמרת הרציפות הנכונה החל מהבנת הצרכים והצבת היעדים בתחילה, ועד לאופן ההתמודדות עם תלאות הפרוייקט בדרך להשגת יעדים אלו.
דוח רווח והפסד
הכנסתו של גורם מקצועי חיצוני לפרוייקט ה-ERP נתפסת לעיתים כתוספת "אופן חמישי לעגלה".
גורם שלישי שבא בנוסף לארגון וחב' היישום, שמתחיל עוד לפני הפרוייקט לטפל בנושאים שבכל מקרה יטופלו בהמשך, מעלה שאלות ומצפה לתשובות מסודרות, שעוצר את ההתקדמות הפרוייקט אם התוצאות המושגות אינן מספקות, ועוד מצפה לתמורה כספית על כל הנ"ל.
אז זהו, שכל מה שמתואר פה אמנם נכון, וטוב שכך!
- תארו לכם לבצע פרוייקט כזה מורכב ללא תכנון ומחשבה מקדימה על מה הארגון צריך, פרוייקט בו כל הדיונים הכי מהותיים נעשים תחת איום מועד ה"עליה לאוויר".
- שוו בנפשכם לבחור תוכנה שתקבע את עתידו של הארגון לפחות לעשור הבא רק לפי מצגת שאף אחד לא זוכר מה נאמר בה.
- תעלו על דעתכם פרוייקט שבכל צומת החלטה בו המשפט הקובע יהיה "מה קיים בתוכנה" ולא "מהצריך הארגון".
- דמיינו שלקראת סיום הפרוייקט, ממש כמו שקרה בפרק א', אתם פתאום מבינים שאתם לא מבינים כלום, כי אף אחד לא באמת ייצג את האינטרס שלכם כלקוח.
ולכן זכרו:
א. לפני שאתם יוצאים לדרך כה ארוכה בידקו כי בין שאר הדברים שהצטיידתם בהם, נכלל גם
אופן חמישי – גלגל רזרבי (וזאת אלא אם אתם רכובים על "עגלה"…).
ב. אופן חמישי מבטיח לכל יושבי הרכב שיגיעו ליעדם במועד, ולכן שילוב גורם שכזה בפרוייקט ERP הוא בחזקת Win Win Situation.
מהות השינוי
אז כפי שכבר הוזכר לעיל, הערכים המוספים האמיתיים שמושגים בפרוייקט נובעים מהבדלי הגישות
ביחס לפרוייקט הצפוי: "פרוייקט ERP" או "פרוייקט החלפת תוכנה". עיקרו של ההבדל מתמקד בשינוי.
- מהו אותו רה-ארגון שכדאי לבצע במקביל להחלפת התוכנה?
- מה התועלות ששינויים אלו יספקו לארגון?
- האם הארגון ערוך לקראת ביצוע השינויים ואילו השלכות הם יגרמו לו בעתיד?
- האם כדאי או ניתן ליישם את כל השינויים במקביל?
- מהו העיתוי הנכון לתכנון השינוי ומה ליישומו?
שאלות אלו שכלל אינן קשורות ל"החלפת תוכנה" אך קשורות בטבורן ל"פרוייקט ERP", יידונו
בהרחבה בפרק ג' – השינוי.
מאמרים קשורים
