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

עקרונות המפתח להצלחה

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

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

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

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

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

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

איש המפתח בארגון – SPOC, כשמו כן הוא, בידיו המפתחות להצלחת הפרויקט. מנהל הפרויקט מטעם הארגון, מכיר טוב את הארגון והתהליכים שלו (360°) מחובר לכל הגורמים, מסוגל לקחת החלטות ויודע על איזה כפתורים צריך ללחוץ כדי שהדברים יקרו בפועל. הוא צריך להיות בעל יכולת והבנה במערכת, מוקדם ככל שניתן, על מנת שיהיה "מפיץ הבשורה" בתוך הארגון והגורם המרכזי שאליו מגיעות הסוגיות לפתרון, מסוגל לענות על רובם בעצמו ומהווה צינור הקשר למיישם בהתאם לצורך. חשוב מאוד שהוא יהיה זמין ב-100% לטובת הפרויקט על מנת שהפרויקט יתקדם על פי התכנית.

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

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

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

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

עקרון הפשטות

כבר אמר מי שאמר וצדק – "מה שלא פשוט, פשוט לא עובד!".

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

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

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

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

בחמש השנים האחרונות – 95% מהפרויקטים של Odoo בעולם הצליחו על פי הפרמטרים האלה (תוצאה חריגה ביותר לטובה).

מעבר לכל הכללים חשוב לזכור ששכל ישר תמיד גובר על כל חוק !

שלבי הפרויקט

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

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

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

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

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

במסגרת התהליך בודקים במשותף כל דרישה עסקית אם יש לה פתרון סטנדרטי במערכת או שיש פער ואז מבצעים תחקור עומק לגבי חשיבות הדרישה והחזר ההשקעה מהפיתוח ומשמעויות התחזוקה העתידיות שלו. כאן ישנו תפקיד משמעותי למנהל הפרויקט שתפקידו לצמצם ככל שניתן את הפיתוחים הנדרשים ובעיקר את כמות הפיתוחים לפני עליה לאוויר, סיכוי סביר שאחרי תחילת העבודה עם המערכת, המשתמש בעצמו ישתכנע שאין צורך בפיתוח, וגם אם יש צורך, האפיון שלו יהיה הרבה יותר מדויק. לעומת התהליכים המייגעים ועמוסי הניירת של שיטת ה-RFI/RFP התהליך הזה שאנו מבצעים בפרויקטים הוא תהליך פנים מול פנים, של מעבר על דרישות, הצגת הפתרון המוצע במערכת על ידי הדגמה או ביצוע הוכחת היתכנות של פיתוח מוצע (POC)  או פרוטוטייפ על ידי כלי פיתוח מהיר, כמו ה-Studio מבית Odoo המאפשר פיתוח וויזואלי ללא כתיבת קוד. התוצר העיקרי של התהליך הוא מסמך – Fit/Gap המפרט את הדרישות , הפערים, הפתרונות המוצעים לפערים עם הערכת היקפים ותעדוף מבחינת הארגון / מורכבות הפיתוח. 

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

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

סבבי הטמעה – Agile 

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

- קונפיגורציה של המערכת לפי התהליכים שהוגדרו

- טעינת נתונים נדרשים, כולל טיוב והשלמות

- פיתוחים של התאמות שהינם קריטיות ואין להם פתרון סטנדרטי או ממשקים למערכות אחרות

- הדרכת המשתמשים

- בדיקות מוכנות 

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

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

כלי ניהול משימות ובקרה – פרט טכני אך חשוב הוא כלי משותף לניהול ומעקב המשימות, מומלץ להימנע מאקסלים, מצגות PowerPoint או מיילים כפי שמקובל בהרבה פרויקטים אלא לאמץ כלי מתאים לניהול משימות, כמו אפליקציית ה-Project של Odoo עם תצוגת ה-Kanban המתאימה לניהול Agile.

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

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

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

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

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

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

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

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

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