פרויקט ERP -

ERP – מתחושת חמיצות לפרויקט מוצלח

מאת יוסי ויזל [1], אופטימום, ייעוץ אסטרטגי למערכות מידע

 

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

אותם מנהלים התחילו פרויקט ERP  בקול תרועה רמה. הבטיחו להם שזה יעשה את השינוי המיוחל:

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

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

אז למה זה קורה ? ולמה זה קורה פעם אחר פעם ?

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

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

יישומים כושלים.

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

 אציג מספר סיבות אופייניות לכשלים בניהול פרויקט ERP – בשלביו השונים.

"האם אתה באמת צריך צוללת גרעינית?"

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

ניקח אנלוגיה פשוטה – הטלפון נייד שלנו.

מישהו מחייג – יש צלצול. פשוט, "פרימיטיבי", ונהיר לכל.

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

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

המושג "קבוצה". צריך להדריך איך מגדירים קבוצה, ואיך משייכים איש קשר לקבוצה. וגם, איך

משייכים רינגטון לקבוצה.

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

שישלח SMS  אוטומטי.

רגע: למי מגדירים? לאיש קשר? לקבוצה? ואם רוצים הודעות שונות בשעות שונות?

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

 

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

ישנן מערכות ERP שהן “low end” אשר נותנות מענה לתהליכים רבים, אבל לא נותנות מענה לתהליכים מורכבים מאד, עם מקרי קצה, ועם מצבים נדירים.

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

עצור וחשוב: האם הארגון שלך באמת כל כך מורכב? הם אתה באמת צריך את המערכת המורכבת?

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

 מושכל ראשון: התאם את מערכת ה ERP לרמת המסובכות של הארגון שלך.

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

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

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

 

"קצין טוב יודע לאלתר" (?!)

בספר המופלא של ג'פרי לייקר על חברת טויוטה

, " The Toyota Way: Using Operational Excellence as a Strategic Weapon "

משווה המחבר את התהליך של הכנסת מערכת הנדסית חדשה לתכנון הייצור (תוכנת תיב"מ) בטויוטה וביצרנית רכב אחרת.

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

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

או בשפה שלו:

Principle 13: Make Decisions Slowly by Consensus, Thoroughly Considering All Options;

Implementing Decisions Rapidly

והוא ממשיך ומפרט את הצעדים שיש לנקוט בשלב ההחלטה:

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

2. נתח את הסיבות לבעיה. "שאל 5 פעמים: למה?"

3.  נתח ביסודיות את כל החלופות, ובנה רציונל לחלופה שהעדפת.

4. בנה הבנה ושיתוף פעולה עם כל המשתתפים בתהליך.

 

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

כמה דורות של מנהיגים צמחו על הגיג שטותי זה?

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

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

זה לא חייב להיות כך.

 

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

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

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

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

תשובתו היא מופת להבנה עמוקה של חשיבות תהליך התכנון:

"Plans are nothing; planning is everything"

על מוטו זה הייתי רוצה שיחנכו קצינים בצה"ל.

 

 

 

 

 

 

 

 

 

"קודם החץ ואח"כ העיגול"

חברות רבות שוכרות שירותי ייעוץ לשלב של בחירת המערכת. ואני אומר, אמור לי מי היועץ, אמור לי אילו מערכות ניהל, ואומר לך כמעט בוודאות מה תהיה המערכת שתיבחר.

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

 

"לא לבלוע ביס גדול מידי"

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

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

ובאותה חצי שנה לעשות גם את זה (מודול מכירות) וגם את זה (מודול ייצור) ו"על הדרך" גם את זה (מודול שירות).

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

המוטו שצריך לאמץ הוא "נלך לאט, נגיע מהר".

 

"אני רוצה שבלחיצת עכבר אדע הכל"

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

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

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

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

כעבודה אקדמית הוא ללא ספק יקבל ציון מעולה.

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

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

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

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

 

"אחרי" - יועץ צריך להיות גם בחפירות

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

תמיד בסוף השאלה היא: "איך העובד מקבל את המידע?", "מי ממלא את הטופס?", "מי מאשר את ההזמנה?", "האם לעובד ברור בדיוק מה ומתי הוא עושה?", וכהנה וכהנה.

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

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

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

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

העסק בסופו של דבר יצליח או יפול על בסיס פרטים "פרוזאיים" אלו.

 

"אנחנו ארגון דמוקרטי", "העובדים שותפים"

כן, זו אמירה יפה, ומאד פוליטיקלי קורקט.

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

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

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

קשה מאד לבוא עכשיו ולאמר לו – שכח הכל, מעכשיו תעשה זאת אחרת, בדרך ב'.

אנשים שונאים שינוי (ראה הספר הקלסי "מי הזיז את הגבינה שלי").

להניע אנשים לשינוי – זו אמנות בפני עצמה.

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

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

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

דרושה נחישות הנהלה – להחליט על שינוי, ולדחוף קדימה – "מטר אחרי מטר" - עד יישומו המלא.

דרוש לבצע change management  מתוכנן, מנוהל, מבוקר ומיושם.

 

"הארגון הלומד" – ERP הוא פרויקט מתמשך

הרבה ארגונים מכריזים על סיום פרויקט ה ERP.

אין דבר כזה.

בכל יישום של פרויקט ERP ניתן (ורצוי) לעבות את היישום בו – הן לרוחב (לתחומים נוספים בחברה)

והן לעומק (לרמות תחכום גבוהות יותר).

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

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

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

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

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

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

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

או בשפתו של צ'רצ'יל:

"To improve is to change; to be perfect is to change often"

 

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

 

"הדרכה הדרכה ושוב הדרכה"

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

למיישמים צעירים יש נטייה להעריך ביתר (over estimate) את יכולת המשתמשים לקלוט מערכת חדשה.

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

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

לעולם אל תקצץ בהדרכה בפרויקט ERP. אין השקעה טובה מזו !

 

לסיכום:

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

 

 

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

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

ניתן לקרוא עוד ב www1.idc.ac.il/wiesel   .