אין ספור מילים נכתבו על טרנספורמציה עסקית ועד כמה ארגונים צריכים להתאים את עצמם לסביבה חדשה/משתנה/מושפעת משינויים כאלה או אחרים. בדרך כלל השינויים העסקיים משפיעים ומצריכים התאמה בשלשה מרכיבים עיקריים – אנשים, תהליכים וטכנולוגיה.
ככלל, ארגונים מתאימים את האסטרטגיה העסקית שלהם במהלך השנים והנגזרות של ההתאמה שונות, חלקן מתמקדות באנשים, חלקן בתהליכים וחלקן בשילוב טכנולוגיות חדשות. אבל, אחת לתקופה יש צורך בביצוע של שלושת המרכיבים האלה יחד. זהו פרויקט טרנספורמציה.
פרויקטי טרנספורמציה הם מורכבים (complex projects) והשפעתם על הארגון היא קריטית, בדרך כלל בכל הרבדים. ברובד האישי ישנה השפעה על לא מעט stakeholders, על מיקומם וחשיבותם בהווה ובעתיד, ברובד העסקי/תהליכי ישנה השפעה על דרך ניהול הלקוחות, בניהול שרשרת האספקה והערך ובייצור, וברובד הטכנולוגי השפעה, בדרך כלל דרמתית, על כלל מערכות המידע ותפעולם העתידי.
מאפייני פרויקטים מורכבים Transformation Projects
- חוצה יחידות עסקיות בארגון (מחלקת כספים, לקוחות, ייצור, שרשרת הערך וכו') ובלא מעט מקרים חוצה תרבויות ואזורים גיאוגרפיים. במידה והפרויקט מתמקד במחלקה אחת, המורכבויות שיוזכרו בהמשך, פחות משמעותיות. פרויקט טרנספורמציה מטרתו להתאים את מבנה ותהליכי העבודה לסביבה המשתנה. בפרויקט מסוג זה אנו פותחים לדיון את התהליכים הקיימים, מקצרים ומייעלים אותם ומתאימים אותם לסביבה המשתנה (דיגיטציה, כדוגמה).
- כמות גדולה של מעורבים – נושא זה הוא קריטי כי מחד אנחנו רוצים שכולם יקחו חלק בשינוי ויהיו מעורבים, מאידך, אנו לא רוצים להשבית את הפעילות של החברה ולעשות ישיבות לא יעילות. כמובן, שנושא זה הוא נגזרת של התרבות הארגונית אבל חייבים לקחת בחשבון שהמבנה הארגוני של הפרויקט וציוות המעורבים הוא משמעותי להצלחתו ולעמידה בלוח הזמנים של הפרויקט.
- Diversity – בדרך כלל, בגלל הטרנספורמציה הכלל ארגונית, הפרויקט חוצה מדינות, שפות, תרבויות, או במקרים אחרים חוצה ישויות/מחלקות ממשלתיות בעלות אופי ותרבות עבודה שונים. כל אחד מהמעורבים בפרויקט מגיע עם תרבות משלו ועל מנת לגשר על פערים אלה, יש צורך לייצר שפה פרויקטלית אחידה, תרבות עבודה אחידה, תרבות דיבור ותרבות תקשור שמכבדת כל אחד מהמעורבים בפרויקט. לפעמים, מה שנראה ברור ומקובל בישראל לא מקובל בחו"ל. לא אחת שמעתי שהישירות שלנו, הרמת הקול וסגנון הדיבור ואף שיתוף בנושאים אישיים אינם מקובלים על כל המעורבים ויש צורך להסכים ולהתוות את הדרך הנכונה ליצירת אמון ועבודה שיתופית
- מרכיב הזמן – חייבים להבין שהאויב הכי גדול של הפרויקטים המורכבים הוא הזמן. בתחילה, נראה שיש זמן להכל וניתן לדחות פגישה כזו או אחרת, בעיקר עקב נושאים דחופים. המחיר של הדחיות האלה עצום, ובא לידי ביטוי בחריגה משמעותית מהתקציב.
מחויבות ההנהלה לפרויקט והגדרתו כסדר עדיפויות גבוה, בנוסף לניהול אגרסיבי וצמוד של מנהלת הפרויקט יכולים למזער את הבעיה.
תוכנית העבודה צריכה להיות "קדושה" ומעורבות ההנהלה הבכירה ביותר בבקרה ובפיקוח על לוח הזמנים משמעותית ביותר. התארכות הפרויקט עלולה לגרום לכניסת טכנולוגיות חדשות ולעתים אף מעבר מפלטפורמה אחת לאחרת שיכולות לשנות את מבנה הישויות ואת יכולות המערכת.
רכיב הזמן, באופן טבעי, גורם גם לתחלופה של אנשים ומומחים הן אצל הספק והן בארגון עצמו. משתמשים עסקיים או טכנולוגיים שמחפשים את האתגר הבא בקריירה שלהם. כדי למזער את ה- impact של התחלופה ניתן לעשות מספר דברים. הראשון והבסיסי ביותר הוא תיעוד מלא של קבלת ההחלטות וכלל המסמכים (דרישות, סיכומי ישיבות, אפיונים, בדיקות, ארכיטורה) בפרויקט. בתחילת הפרויקט יש להכין רשימה של כל המסמכים הנדרשים ולהקפיד לקבל כל מסמך בעיתו. אציין שכבר כיום ניתן להשתמש בתשתיות ה- AI המודרניות לצרכי תיעוד מלא של התהליכים והמסמכים הנדרשים וזאת על בסיס פתרונות שפותחו על ידי הספקים. ב- EY פותחו מספר כלים המסייעים בתיעוד בפרויקטי החלפת ויישום מערכות ERP. כלים אלה מסייעים באמצעות voice to text לתעד את הדרישות ואף ל"הכריח" את המיישמים של המערכת לא לדלג על אף פריט באיפיון, לדוגמה ממשקים, דוחות פיתוחים ספציפיים, הרשאות ועוד.
אלמנט נוסף של מרכיב הזמן הוא התקציב. בגלל גודל הצוותים המסייעים ביישום הפרויקט ומעורבים בו, כל יום עבודה, המקיף בין 20 ל- 50 ואף מגיע ל- 150 אנשים מעיב מאד על תקציב הפרויקט. לכן, יום שלא מתקדמים, או שמחליטים לשנות את האיפיון ודרך היישום או שממתינים לאישור כזה או אחר, עלותו יכולה להגיע ל- 20 אלף דולר ובמקרים אחרים גם ל- 150 אלף דולר. לכן התכנון של כל שלב ושלב בפרויקט ויישום התוכנית על פרטיה הוא קריטי לעמידה בתקציב של הפרויקט או לחריגה, מינימלית, מה שמקובל בדרך כלל.
ניהול תקציב
תכנון ותמחור של פרויקטים כאלה חייב להיעשות על ידי מומחים עם ניסיון, בדרך כלל, בינלאומי. קשה עד בלתי אפשרי לדעת מראש כיצד ינהג הארגון והספק. המרכיבים שבהם אנחנו תלויים כל כך רבים שקשה לעמוד אותם מראש. לכן, יש צורך לתקצב את הפרויקט בצורה הדרגתית ולעבור משלב לשלב תוך הגדרת תקציב כוללת, אך לא מחייבת את שני הצדדים. הלכה למעשה, צריך לתת לספק להכיר את הארגון ולהיפך ולייצר נקודות יציאה/בחינה מחדש של התקציב. אחד הפתרונות שחוויתי אותם, ואציין שהפכו את העבודה והפרויקט לפרויקט משותף הוא שקיפות והבנה שאף אחד מהצדדים לא יפסיד. במקרה זה, מתקצבים את הפעילות/האנשים ובצורה אמינה חולקים את המאמצים והסטטוס בכל שלב ושלב. דרך נוספת היא לעבוד על פי זמן וחומרים, אך במסגרת תקציבית ותכולה ברורה, לעבוד באתר הלקוח ולבצע בקרת שעות. הדרך, שכשלה לא פעם, היא דרך ה- Fix price. עם יד על הלב, אין הרבה ספקים שמוכנים לתרום מהרווח שלהם להצלחה של הלקוח ולעמידה ביעדיו. ניתן לעשות זאת בפרויקטים קטנים שמוגדרים כהשקעה, ניתן לעשות זאת בשילוב טכנולוגיות חדשות במטרה לצבור ניסיון, אך בדרך כלל, לא ניתן לעשות זאת בפרויקטי טרנספורמציה, שכן, הפסדים בסדרי גודל כאלה, יכולים לגרום להפסקת פעילות של הספק ולקריסתו.
ל- EY יש כלים המאפשרים להזין את כל הפרמטרים האופרטיביים ואף להתחשב בגורמים תרבותיים/ארגוניים המשפיעים משמעותית על תהליך זה ולבטח מאפשרים לצאת לדרך עם תקציב לכל שלבי הפרויקט. יחד עם זאת יש לאתגר את התקציב מתחילת הפרויקט ולא לחכות למשבר כזה או אחר על ידי מעקב ושקיפות.
ניהול הפרויקט
שאלה שעולה בכל פרויקט טרנספורמציה היא מי צריך לנהל אותו, האם היחידה העסקית או היחידה הטכנולוגית? נושא זה הוא קריטי להצלחת הפרויקט והיחסים בין המוביל העסקי למוביל הטכנולוגי משמעותיים ביותר להצלחתו. כמובן, שניהם צריכים להיות מעורבים בשאלה: "הראש של מי מונח על השולחן כשלא עומדים בתקציב, בזמן וביעדי הפרויקט?". בחירת האנשים שיובילו את התהליך היא קריטית. באחד הפרויקטים שהובלתי היחסים בין הסמנכ"ל מכירות (שהוביל את הצד העסקי) ובין מנהל מערכות המידע היו כל כך טובים, שכל הצוות הרגיש את האוירה החיובית, ההירתמות והעשייה היו של כולם והמחויבות להצלחה היתה יוצאת דופן, כך שהפוליטיקה הארגונית נזנחה לחלוטין וטובת הפרויקט היתה מעל הכל. בימיו הקשים ביותר של הפרויקט, אפשר היה לראות צוות אחד משנס מותניים, פותר אתגרים ביחד, מוותר אחד לאחר בתכולות אך מתעקש על הדברים החשובים, כך שהעיקר תמיד בוצע והטפל ירד מהפרק. דרך אגב, נושא העיקר והטפל הוא קריטי בפרויקטים מורכבים. התנהלות זאת היתה המפתח להצלחת פרויקט מורכב זה שערך 4 שנים!
EY מספקת ליווי כזה על ידי מומחים עסקיים (בשרשרת אספקה, כספים ייצור, מכירות…) בשילוב אנשים טכנולוגיים (SAP אורקל…) כדי מחד להבין את ההשקעה הנדרשת בפיתוחים והתאמות מול הערך העסקי של הבקשה (טפל או עיקר).
לעומת זאת, בפרויקט אחר שהייתי מעורב בו, התעסקות עם הטפל, הן בשלב האיפיון והן ביישום, גרמו לעיכוב מיותר בלוח הזמנים ולהוצאות כספים מיותרות, בשילוב עם תסכול רב של הלקוח ושל הספק. מוערבות חכמה יותר של הגורם העסקי, והבנת ההשלכות על הפרויקט מהבחינות המצוינות לעיל, בנוסף ליחסים פתוחים ואמינים בין הצד העסקי לצד הטכנולוגי, היו מונעים זאת.
טכנולוגיה
חשוב להבין שמורכבות טכנולוגית בפרויקט טרנספורמציה, בגלל היותה חוצת ארגון, היא משמעותית וחייבת לקבל את תשומת הלב הראויה. לכן, מומלץ להגדיר בתחילת הפרויקט את התכנון הטכנולוגי של הפרויקט ולגבות זאת במסמכים מפורטים. איזה רכיבים קיימים, רכיבים חדשים, תשתית אינטגרציה, מערכות BI ובימים אלו גם מערכות AI (וזרימת המידע), תשתית לניהול הפרויקט ולא פחות חשוב תשתית לתפעול כלל המערכות המעורבות ביום שאחרי הפרויקט. תכנון זה, מהווה את כוכב הצפון של הפרויקט וכל דרישה שעולה חשוב שה- CTO (האחראי הטכנולוגי על הפרויקט) ידע היכן ואיך היא מיושמת! ניתן לבצע זאת In-house, אך ניתן להיעזר ביועצים טכנולוגיים כמו אלה הקיימים ב-EY עם ראיה רחבה, המבינים את המערכות הישנות ומבינים את המערכות החדשות בשילוב תשתיות אינטגרציה (נתונים, תהליכים, בתצוגה).
עלייה לאוויר ב- one big bang או בצורה הדרגתית
האם עולים לייצור עם כל השירותים ובכל האזורים/מדינות ביום אחד, או עולים לייצור בשלבים. כמובן, כל מקרה לגופו ואין כללי אצבע. יחד עם זאת, על בסיס ניסיוננו, בעליה לאוויר אחת אני חוסך בממשקים למערכות שהשבתתי/ישנות וחווה פעם אחת את המעבר למערכת חדשה, אך הסיכון גדול מאד וזמן ההתייצבות ארוך במיוחד. בדרך כלל, בגישה זאת, הפרויקט נדחה מספר פעמים עד שהוא עולה לאוויר, שכן כולם מודעים לכך שמה שלא נקבל עכשיו (מיחידת ה- IT או מהספק), ספק אם נקבל מתישהו. גישה זאת יכולה לגרום להעברת מערכת עובדת לייצור בתהליך של שנתיים ויותר!
לעומת זאת, עליה הדרגתית לייצור ממזערת את הסיכונים, אבל מייצרת ממשקים רבים ותחזוקה של שתי מערכות לפחות, בו זמנית ולאורך זמן. מניסיוננו, מכיוון שהעלייה לאוויר הראשונה תמיד מאתגרת, כל המעורבים יושבים ולומדים מה לשפר לשלב הבא ואז השלב השני והשלישי נדחים, על מנת להימנע מטעויות ולאפשר זמן התייצבות. חשוב לציין כי ניהול הפרויקט לרוב נעשה על ידי אותם יחידות ואנשים קריטיים, שאחראים על השלב הראשון, השני והשלישי ולכן הפוקוס הניהולי והארגוני הוא קודם כל על העלייה הראשונית, מה שעלול לדחות את ההמשך. עם זאת, גישה זאת מאפשרת להראות תוצרים ויכולות כבר אחרי זמן קצר יותר ולא להמתין שנסיים הכל כולל הכל.
מדד ההצלחה
הגדרת פרויקט טרנספורמציה כמוצלח או לא היא בהתאם למדדי ההצלחה שהוגדרו בתחילתו. יש להגדיר את המטרות וכיצד אנו מודדים אותן בתחילת הפרויקט ולא להשאיר את הנושאים פתוחים. בסופו של דבר, יש לפרויקט מטרות עסקיות, ולכן יש להגדיר יעדים ומדדי הצלחה לכל מטרה ומטרה ולבחון לאורך כל שלבי הפרויקט, האם ההחלטות שאנו מקבלים תואמות את המדדים שלנו והאם לאו. לדוגמה, אם המטרה היא הנגשת פעולות מסוימות לאזרח וביצוע הפעולות בצורה אוטומטית ב- back offices, מדדי הצלחה כאן חייבים להיום ברורים, כמה אנשים משתמשים, האם שיפרתי את החווית עבודה שלהם מול הרשויות, האם ההשקעה בהנגשה של שירות זה או אחר היתה מוצדקת וכו'.
שמי דודי כרמי, במהלך 25 השנים האחרונות אני מיישם ומלווה פרויקטי טרנספורמציה וברצוני לחלוק אתכם את הניסיון שצברתי, על מנת לסייע לכם להצליח במקומות שאני הצלחתי ולא ליפול ל"בורות" שאני נפלתי אליהם.
