מי אמור להוביל הטמעה של מערכות חדשות? כך תבחרו את ה-Owner הנכון

בעל התפקיד הנכון להובלת התהליך תלוי במוצר הליבה (צילום מסך מתוך SNL)

מאת סהר דולב, סמנכ"ל טכנולוגיות במלם תים

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

זאת לא רק הטכנולוגיה – הכל מתחיל באנשים

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

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

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

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

ניקח לדוגמה הטמעת פתרונות של Business process management או Workflow management system שמחברים בין מערכות, מבצעים אוטומציה ומאיצים תהליכים ארגוניים (כמו Workato או Emakin, חלקם מיושמים אפילו ב-Low code). כדי להטמיע אותם בצורה מוצלחת חייבים לשבת קודם עם המחלקה הארגונית הרלוונטית, שעולמה הולך להשתנות מקצה לקצה.

כל עדכוני ה-IT, תשתית וטכנולוגיה בערוץ הטלגרם של ITtime

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

רק אל תעלו לאוויר מהר מדי

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

בהקשר הזה קיימות שתי אסכולות: הראשונה היא גישת ה-Big bang, המפץ הגדול, שבה עולים בבת אחת ובכל הארגון – ממש מנתקים את חבל הטבור מהמערכת הישנה. מתי כדאי לנקוט בגישה הזאת? הנה דוגמה: בהרבה ארגונים יש מערכות ERP או CRM שנתפרו עבורם אינהאוס, או על ידי קבלן אינטגרציה ותיק. השנים עוברות והמערכת משודרגת טלאי על טלאי, ובנקודה מסוימת הארגון מבין שהגיע הזמן לשינוי: השפה כבר מיושנת, המערכת לא מאפשרת טרנספורמציה דיגיטלית והגיע הזמן להיפרד מה-Legacy system ולעבור לפלטפורמה מודרנית כגון Priority ,SAP ,Salesforce וכדומה. החיסרון המרכזי בגישת המפץ הגדול הוא התמודדות עם סיכונים כגון ריבוי תקלות, אי שלמות פונקציונלית, מחסור בזמן הנדרש לטיוב הדאטה (שהוא כמובן הבסיס למערכות) וההימור על הרושם הראשוני שייווצר אצל המשתמשים.

הגישה השנייה היא Make before break: מתחילים לנסות את המערכת החדשה, אבל עוד לא מתנתקים מהישנה. אפשר לעלות תחילה בגרסת בטא או MVP, או לערוך פיילוט באחת המחלקות בארגון. אותה מחלקה תחוש גאוות יחידה, תייצר FOMO אצל האחרות, תגלה סבלנות רבה יותר לתקלות ותתרום ל"ניחוח של הצלחה", שלאט לאט יחלחל בשדרות הארגון. בגישה זאת, השימוש במערכת החדשה מתרחב בסדרה של Rollouts, ורוב המשתמשים יקבלו אותה בגרסה בשלה ובוגרת יותר. אבל גם בכפילות המערכות הזמנית הזאת יש חסרונות: החיבוריות דורשת עוד משאבים ועלולה להסתבך; וקיימת אפשרות ריאלית שמרוב Make נישאר בלי ה-Break. כלומר, המערכת החדשה עלולה להפוך למעין Nice to have שלא באמת בשימוש, ודינה ייחרץ בשלב מוקדם מאוד.

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

אז מה עושים? הגישה הנכונה לארגון תלויה בהנהלה, בתיאבון הסיכון שלה, בדנ"א הארגוני, בתהליכים העסקיים עצמם וההתאמה ביניהם לגישה הנבחרת וכדומה. בארגונים גדולים נראה שיש הגיון בללכת על הגישה המשולבת, ובכל מקרה חשוב לזכור: תכנון יסודי, גם על חשבון Time to market, הוא קריטי להצלחה. תוך כדי התכנון וההכנה אפשר לשחרר פיילוטים קטנים, MVPs, כדי לנסות פונקציות קרדינליות על משתמשים אמיתיים ולקבל מהם פידבק. גם אם זה דורש יותר עבודה, ואפילו עבודה ידנית על מסדי נתונים, הניסויים האלה חשובים להסרת סיכונים, הפחתת התנגדויות ויצירת באזז. ה-Owner של תהליך ההטמעה חייב להביא את כל זה בחשבון. ואם כבר מדברים עליו…

מי מוביל? לא מי שחשבתם

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

אז אם לא ה-IT, מי כן? מי אמור להגדיר את הצרכים, להסיר התנגדויות, להסביר שהולכים לעבוד קצת אחרת, להבין את המתח שבין איכות למהירות, להכריע בין Big bang ל-Make before break? הנה כלל אצבע: מי שהטמעת הטכנולוגיה תשפיע עליו הכי הרבה, הוא ה-Business owner שלנו. אם זו מערכת CRM, סביר שזה יהיה אגף המכירות או אגף שירות הלקוחות. כמי שנמדד על יעדים עסקיים, הוא מבין היטב את המשמעות של פלטפורמת ניהול קשרי לקוחות אפקטיבית יותר. לכן, סביר שיש לו אינטרס שהטכנולוגיה תשמש את הארגון בפועל – מה שמגדיל את הסיכוי לעבודה יעילה ומגייסת שתוריד חסמים בקרב המשתמשים העתידיים.

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

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

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

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