כיצד קהילת ה Data Science מסייעת במלחמה נגד קורונה?

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

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

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

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

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

ואכן – בחודש האחרון אנחנו רואים התגייסות אדירה של קהיליית מדעני הנתונים לסייע באתגר.  ה קהיליות מאורגנות כמו לדוגמה Data Natives (כ 80K מדעני נתונים), Kaggle (גוגל) ודומיהן כבר "על זה" ומריצות האקטונים – דוגמת #HACKCORONA, תחרויות ואתגרים שקשורים למלחמה בנגיף. הרווארד פתחה קורס ייעודי ל Data Science for Covid19 ועוד שלל דוגמאות.

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

הסיבה העיקרית היא היעדר דאטה. או יותר נכון – היעדר Data governance!

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

החדשות המעודדות הן שיש התקדמות אדירה ומואצת בימים אלה ממש. קהילת ה data science כבר "על זה" ומנסה להתארגן על מקורות מידע טובים. יש כמה יוזמות מעניינות בתחום זה שמנסות להנגיש data sets לכל העולם, כמו לדוגמה Cord 19 – דאטה סט פתוח של Allen Institute המכיל 30K מאמרים ומחקרים בנושא; יוזמות רבות נוספות כמו זו של הבית הלבן בשיתוף עם Kaggle ומיקרוסופט ועוד רבות נוספות שואפות לכנס את קהילת ה AI ומדע הנתונים ולנסות לקדם אתגרים באמצעות אלגוריתמים.

מהם סוגי הפתרונות להם ניתן לצפות משימוש ב Data Science בהקשר של הקורונה?

• בראש ובראשונה, הבנת הבעיה (במלים אחרות, איסוף נתונים והנגשתם למי שצריך):  היכן ההתפרצויות? מה היקף ההתפרצות? מה אחוז החולי?  טכנולוגיות רלוונטיות: ויזואליזציה, דשבורדים, GIS. המחסור העיקרי כאן הוא בתמונת מצב ברורה סוג של Data governance עם "אמת אחת".
• סיוע באבחון: אחת הדוגמאות המעניינות כאן היא סיוע באבחון בשלבים מוקדמים, כדוגמת Project Baseline של חברת האחות של גוגל Verily שמציע (כרגע לתושבי קליפורניה) ערכת בדיקה אונליין ל Covid19.
  

 לקריאה נוספת: https://www.projectbaseline.com/study/covid-19/

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

בתמונה – מודל המזהה בדיוק של 90-92% באמצעות Keras, TensorFlow ו Deep Learning. המודל למד בעצמו, ללא נתונים גיאוגרפיים או דמוגרפיים. המודל מתבסס על data set שפורסם על ידי רופא במונטריאול ב GitHub (לינק ל data set כאן) והושוו מול Data Set קיים של Kaggle לצילומי חזה.  עליבאבא פיתחה מודל שמזהה את הנגיף בסריקות CT באחוז דיוק של 96%. המודל אומן על 5000 דוגמאות והמערכת אומצה על ידי 100 בתי חולים בסין וזהו לא המודל היחיד. מודל נוסף פותח באמצעות Deep Learning (תוך שימוש ב 45K סריקות CT) על ידי אוניב' בווהאן – גם שם אחוז הדיוק עמד על 95%.

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

בהקשר למניעה/מציאת חיסון –  בהחלט יש ציפייה ש AI יאיץ את התהליך (שתאורטית לוקח 12 שנה). DeepMind של גוגל הכריזו על שימוש ב Deep Learning על מנת לזרז את הבנת מבנה הנגיף ותהליך קיפול החלבונים באמצעות פרויקט AlphaFold שלה – מערכת שיודעת לנבא מבנה חלבון.

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

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

לסיכום

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

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

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

בברכת בריאות טובה לכולם וחזרה במהרה לשגרה "משעממת".

צוות המחקר של STKI.

COVID-19 implications on IT – We love Opex

Traditional IT and especially its technology procurement wing love Capex i.e. perpetual licensing and HW ownership. This enables more control. For example it enables to substitute the original software product vendor with 3rd party software support (leading example of a firm in the industry of 3rd party maintenance is Rimini Street. If you don’t now this firm, you should look at it). When technology procurement got a proposal based on renting software they would fight to change the license method to perpetual.

However, COVID-19 changed this abruptly. Perpetual licensing does not support drastic change in business capacity.

In a recent technology procurement virtual meetup we found that many technology procurement organization feel they are stuck with extra software licenses and extra hardware.

“Our branches were 80% closed in the last two months but still we need to pay 100% software maintenance to the supplier of the branches software” said procurement manager from a leading bank.

A flexible Opex based software license model (rental) would be much more appropriate in these uncertain days and so we see technology procurement managers negotiate in order to get this kind of deals.

This is 180° change from the reality we had 3 months ago.

We will talk more about COVID-19 implications and IT in our annual summit (hopefully) on the 13th of July.

Pini Cohen

EVP & Senior Analyst at STKI

 

על הכרזה משמעותית בכנס re:Invent שירות ה- AWS Outposts

 כפי שמקובל בכנסים חשובים גם בכנס שנערך בלאס וגאס בשבוע שעבר הוכרזו מספר דברים חשובים ביניהם שירות חדשני במיוחד AWS Outposts.

מדובר על הרחבה של הענן של AWS לתוך ה- data center של הארגונים. דבר שהנו לא פחות מדרמטי!!

ספציפית, הלקוח יבחר את סוג השרתים הרצוי ומספרים. וכמו כן דברים כמו צורת החיבור וה- security policy ולאחר זמן מה יקבל את השרתים בדואר, מקונפגים, ולאחר חיבורם לחשמל ולאינטרנט, הלקוח יראה שרתים אלו כחלק מהסביבה שהוא מקבל ה- AWS – כאשר פיזית הם נמצאים ב data center שלו.

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

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

שירות ה- AWS Outposts עדיין לא זמין. תאריך היעד שלו הוא המחצית השניה של 2019. תמחור השירות עדיין לא התפרסם.

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

כמו כן יש לציין שמדובר על אפישור השירותים שמתבססים על EC2 , שירותי ה- compute של AWS, ולא איפשור של שירותים אחרים כגון S3, Lambda וכד'. כלומר עדיין לא מדובר על כך שכל AWS זמין ב- data center  הארגוני.  אבל בהחלט מדובר בצעד משמעותי מאוד.

יש לציין שאנו רואים כאן המשך המגמה של הרחבת השירותים של AWS לתוך "חצר הארגון". פתרונות ה- Snowball וה- Snowmobile המספקים העברה של מידע פיזית לתוך AWS (במקרה שמדובר על מידע רב ולא רוצים להשתמש בקווי תקשורת) מאפשרים כבר זמן רב הרצה של שירות Lambda ומלפני שנה גם הרצת שרתי EC2 – וכל זאת ללא חיבור לאינטרנט כלל!! כפי שציינו כבר ב- 2016 בבלוג של STKI  ש-"שמבחינה טכנולוגית תוכל AWS במידה ותרצה להרחיב יכולת זו לספק שירותים שלמים באתר הלקוח, כלומר לספק סוג של ענן פנימי!"

 

 

 

תפקידים חדשים לניהול חוויית הלקוח

"מנהל/ת חווית לקוח" Customer Experience Manager הנו תפקיד יחסית חדש בשוק העבודה ולכן עדיין ניתן למצוא הגדרות שונות לתפקיד זה, כמו גם שמות שונים המתארים אותו:

• Chief Customer Officer

• VP of Customer Experience

• Customer Success Manager (רווח בעיקר בקרב חברות מוצר SaaS)

 

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

על פי נתוני ה CCO (Chief Customer Council), 35% מחברות ה Fortune 500 איישו את תפקיד ה CCO (עלייה מ22% לפני כשנתיים, במצב בו רק ל39% מהארגונים היה גורם או כמה גורמים שבאופן בלתי פורמלי עסקו בנושא חווית הלקוח – על פי מחקר של Russell Reynolds).

רוב החברות מבינות את חשיבותו הגוברת לחברה ומתפקיד בגדר Nice to Have הוא הפך לחיוני ליצירת מנגנוני צמיחה עסקית, בנוף תחרותי בו חויית לקוח טובה = צמיחה.

אם בעבר אנשים רבים חשבו כי אין צורך בתפקיד מנהל לקוח כיום הם מסתכלים עליו כתפקיד הכרחי ובמקרים רבים (50%), כהרחבה לתפקיד CMO – מנהל/ת השיווק.

אחד המאמרים החשובים בתחום, ששימש כרקע לעליית יוקרת התפקיד, היה מאמר מפורסם ב Forbes שנכתב בסוף 2016 בשיתוף עם מקינזי בשם “Why Your Company Needs a Chief Customer Officer".

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

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

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

נתון נוסף ומעט קודר: נכון למחקרים שנעשו ב 2017, CCOs הנם בין התפקידים הבודדים ברמת ניהול גבוהה בארגון בעל משך תעסוקה ממוצע של 26 חודשים בלבד! במלים אחרות, קשה "להחזיק מעמד" זמן רב בתפקיד זה בגלל פער הציפיות שמתרחש בכל ארגון כמעט. ההנהלה הבכירה מצפה לתוצאות מיידיות בכל מה שקשור ביוזמות חויית לקוח. אולם המסלול ליצירת תרבות מוכוונת חויית לקוח הוא מסלול ארוך טווח עם תוצאות משמעותיות ביותר – אולם בטווח הרחוק ולרוב לא המיידי. ה “Quick wins” המפורסמים לא מצליחים לרוב לענות על הציפיות הגבוהות ומנהלים רבים לא עומדים באתגר ומוצאים דרכם החוצה. וכך פעמים רבות קורה (ומי שעוסק בעולם CX יוכל להזדהות) שבשלב מסוים הסבלנות אוזלת, רוצים לראות תוצאות מוחשיות, ואז הלחץ לייצר quick wins מסיט אותנו מאותה דרך ואסטרטגיה ארוכת טווח.

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

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

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

1. הגדלת ערך לקוח, ההתמקדות צריכה להיות במדדי הערך ללקוח – שביעות רצון, הפחתת ה CES (Customer Effort Score), שיפור ה CSAT (Customer Satisfaction), ושיפור חוויית הלקוח בראייה של כלל נקודות המגע. CCOs מקשרים מדדים אלה למדדי היעדים העסקיים (רווחיות, צמיחה, התייעלות וכד') כדי להוכיח ולהמחיש את הערך שבשיפור חויית הלקוח, אולם הם לא אמורים להימדד על גידול ברווחיות/הכנסות, אלא רק על שיפור הערך ללקוח.
2. יצירת תרבות ממוקדת לקוח בכל אגפי החברה (כולל עובדי החברה שאינם במגע ישיר עם הלקוחות). כדי להשיג מטרה זו, CCOs עוסקים רבות ב"שיווק ותקשור, וב Storytelling בתוך הארגון" על החשיבות ב Customer – Centricity ואיך הדבר מיתרגם לגידול בהכנסות, בהעלאת שביעות רצון, בצמיחה וכד'. לטובת מטרה זו, CCOs נדרשים יותר ויותר לעסוק בדאטה ואנליטיקה, לגבש מדדים ולקשר אותם ישירות למטרות העסקיות, וכמובן – לתקשר כמה שניתן את התוצאות.
3. הנגשה והוכחה של חשיבות הנושא למנכ"ל, ההנהלה, העובדים, בעלי המניות וכל גורמי העניין (Storytelling). מכיוון שזהו תפקיד חדש יחסית לא כולם מבינים את הערך שלו וצריך לעסוק רבות ב"שיווק" חשיבות הנושא לארגון.

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

דרישות התפקיד:

1. יכולות אנליטיות, ניתוח והסקת מסקנות. שימוש בסקרים ומדדים מוכרים כדוגמת NPS, CSAT, CES ועוד.
2. עבודת צוות וראייה מערכתית.
3. ניהול והנעת צוותים
4. הבנה טכנולוגית (עד רמה מסוימת), למידה עצמאית של טכנולוגיות חדשות
5. יכולות Storytelling

מיצוב תפקיד מנהל חוויית הלקוח במבנה הארגוני:

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

בשל כך, כ-80% מCCOs ומנהלי חווית לקוח יכהנו בהנהלה הבכירה (כפופים ומדווחים ישירות למנכ"ל). כמו כן, כ- 50% כ-CMOs מנהלי השיווק יהפכו להיות מנהלי חווית לקוח כחלק מהרחבת ה SCOPE של עולם השיווק.

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

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

 

טקטיקות וכלי "עבודה":

CCOs / CXOs עושים שימוש בין היתר בסקרים ובכלי VOC – Voice of the Customer, מדדים (NPS, CSAT, CES), מתודולוגיות ליצירת אמפתיה (פרסונות, Empathy maps), ו Co-Creation (Service Design, Design Thinking).

חלקם יגבשו נהלים שמחייבים עובדי Back Office "לצאת לשטח" ולהיפגש עם לקוחות, לחייב עובדים לעשות שימוש בעצמם במוצרי ושירותי הארגון מפעם לפעם, על מנת להיכנס לנעלי הלקוחות ולגבש תפיסת Outside-in. לדוגמה, Cleveland Clinic שעוסקת רבות ביצירת אמפתיה באופן שיטתי בארגון עם הלקוחות שלה, שולחת את עובדי המחלקה הפיננסית ובראשה ה CFO, להצטרף לסבבי רופאים ולהיות עדים לאינטראקציות שלהם עם הלקוחות.

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

 

לסיכום, בסופו של דבר CCOs / CXOs הם סוכני שינוי שאמורים לייצר תרבות ארגונית ממוקדת לקוח בכלל יחידות הארגון, מה-CEO ועד אחרון העובדים (לא רק ב Front Lines). לכן, תיאור ואופי התפקיד משתנה בהתאם למצב בו הארגון נמצא. לדוגמה, בחברות שכבר ממילא מאוד ממוקדות-לקוח, התפקיד יתמקד יותר במציאת דרכים חדשות לשפר את חויית הלקוח. בארגונים בהם התרבות הארגונית ממוקדת מוצר/תהליכים, עיקר המאמץ יתרכז סביב יצירת תרבות ארגונית ממוקדת לקוח וגיבוש אסטרטגיה לניהול השינוי.

אחד המקצועות שמשקפים תפיסת חויית לקוח כוללת ומתמשכת – CSM:

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

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

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

Source: Antavo

מנהלי חויית לקוח מוודאים שהלקוחות אכן עושים שימוש בשירות ומקבלים ערך, בין השאר על ידי מדידה וכלי דאטה, סקרים ושיטות שמגיעות מעולם ה Voice of the customer. הם מקיימים אינטראקציות יזומות מול הלקוחות, מוודאים שהם מקבלים את הערך שהם מבקשים מהשירות/מוצר, ולעתים גם נושא ה Cross/up-sell הנו אחד מהתפקידים, אולם לרוב מנהלי CSM יימדדו על ערך (שמשתקף בrenewals מתוך ההנחה שלקוח מרוצה הוא לקוח שמחדש) ולא על מכירות!

מיקום CSMים בהיררכיה האירגונית משתנה מארגון לארגון, הוא יכול להימצא:

• בדרג הניהולי ( (C Level
• מדווח למנהל הפיתוח העסקי (Business Manager).

תפקיד ה CSM הוא לדאוג שלקוחות החברה יהיו שבעי רצון מהשירות ומהמוצר שלהם, ולשנות את מה שטעון שיפור. ואף יותר מכך, לוודא שיש שימוש משמעותי ( Adoption rate  גבוה) במוצר/שירות שהם נותנים. משום שבסופו של דבר מטרתו לבנות קשרי לקוחות לטווח ארוך, וכאלו שיהפכו את הלקוחות ל- Advocates.

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

התכונות והכישורים הנדרשים מה CSM הינם:

• יכולות מכירה ושיווק – אדם בעל יכולות שכנוע, שיכול לשכנע לקוחות שאינם מבינים את התועלת להשתמש ביכולות המוצר.
• בטחון ויכולות בינאישיות גבוהות – מקשיב ופתוח, אך עם זאת לא חושש מעימות עם לקוח: היכולת להקשיב לרצון הלקוח ויחד עם זאת לעתים לסרב לבקשות ולהציע הצעה שמתאימה יותר לצרכיו מתוך ראייה כוללת של הערך ללקוח.
• פרואקטיביות – נותן ללקוח הרגשה שהוא שומר עליו ודואג לאינטרסים שלו.
• אנליטי – יכולות שהולכת ונעשית חשובה יותר, טיפול בנתונים, ניתוח ואנליזה
• אמפתיה גבוהה, היכולת להיכנס לנעליים של אדם אחר
• כישורים טכניים, CSMים הם ברובם אנשי דאטה, ואם מדובר על חברת מוצר – יכולת למידה עצמאית כדי לספק מידע ללקוחות מבלי להיות תלוי במנהלי המוצרים.
• דמות מוערכת וסמכותית בארגון שיוצרת קשר טוב עם מנהלי המוצר בחברה. עליו להתעמק בנושאים כדי לקבל ידע רב ככל האפשר מבלי להיות תלוי במנהלים כל הזמן. מכיוון שגם קולגות וגם אנשי הצוות שלו פונים אליך לקבלת תמיכה, הדרכה וייעוץ.
• Soft & Hard Skills המשלבים ידע וכישורים טכנולוגיים, בינאישיים, יכולות מכירה, והבנה עסקית באילו ממגוון המדיות הקיים כדאי להשתמש.

 

"האם ניתן לישון בשקט לאחר קבלת ייעוץ משפטי?"

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

המלצות:
על חברות לפעול באופן הגון בכל הנוגע לשימוש בנתונים האישיים המצויים ברשותם (לקוחות, עובדים, ספקים, וכד') – ולא רק לפי הנחיות החוק\רגולציה.
יש להפסיק ולאגור מידע ללא גבולות אלא לבצע רק איסוף מושכל של מידע
GDPR (General Data Protection Regulation) הנה רגולציה אירופאית שתיכנס לתוקף במאי 2018. ל- GDPR השלכות לא טריוויאליות להתנהלותם של כלל הארגונים בישראל ולא רק לארגונים הפעילים באירופה.
ארגונים ישראלים צריכים לאמץ את עקרונות ה- GDPR, גם אם הם לא מחויבים להם על פי חוק כעת, תוך הבנה שעקרונות אלו יהפכו עם הזמן להיות סטנדרטיים גם בישראל, וכמו כן עקרונות אלו מכוונים את ההתנהלות העסקית באופן יעיל, מדויק ובאופן שיוצר יותר אמון.

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

ניתן לקבלו על ידי פנייה ל-STKI

 

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

Data Driven Enterprise
בהמשך לשינויים בכלכלה, אשר תוארו קודם, אחת מהיוזמות הרוחביות ש-STKI מיפתה הנה Data driven enterprise. מהות יוזמה זו היא ניצול המידע הקיים לביצוע החלטות ופעולות טובות יותר באופן גורף ושיטתי על ידי כל חלקי הארגון. בארגונים אשר שמו להם כמטרה לקיים את יוזמת ה- Data driven חשוב ביותר למנות Chief Data Office. ה- CDO הנה פונקציה ניהולית בכירה הנושאת באחריות לארגון רחב של נתונים ואסטרטגיית מידע, ממשל (governance), בקרה, פיתוח מדיניות דאטה, ניצול יעיל, מינוף הדאטה לטובת היעדים העסקיים ואף מוניטיזציה של המידע. תפקידם של CDOs ישלב אחריות להגנה על מידע ופרטיותו, ניהול מידע, איכות הנתונים וניהול מחזור חיי נתונים, יחד עם ניצול נכסי הנתונים ליצירת ערך עסקי, ולמינוף המידע לטובת המטרות העסקיות.
חברות מניחות שאם כל עניינן הוא לאסוף מידע באמצעות מערכות אינטרנט המבוססות על מודלים עסקיים של freemium או שהן פעילות רק בישראל, הרי שתפקידן הוא רק להגן על המידע כך שלא ייגנב ולעמוד בדרישות החוק\רגולציה. הנחה זו הנה הנחה מוטעית. מידע אישי שנאסף כחלק מטראנזאקציות עסקיות (שאינן מבוססות freemium), כמו גם מידע שנאסף ממערכות פנימיות או מהאינטרנט (במסגרת freemium), מחויב כאמור בעמידה בנהלים בתחום זה ולא פחות חשוב הטיפול במידע חייב להיתפס כ"הגון" על ידי הציבור הכללי.

על שערוריית הנתונים של פייסבוק
אפליקציה תמימה למראה בשם thisisyourdigitallife שהושקה ב-2014 הציעה למשתמשי פייסבוק שאלון פסיכולוגי מטופש, מהסוג שלא נדיר למצוא בפייסבוק. האפליקציה התיימרה להיות ‘כלי מחקר לפסיכולוגים’ ולכן היא גם קיבלה מפייסבוק אישור לאסוף מידע ולשמור אותו.
אבל בניגוד לשאר החידונים המעיקים שאנחנו מכירים, האפליקציה שאבה את כל ההרשאות שהיא רק יכלה לקבל מפייסבוק – גם מהמשתמשים, וחמור מזה, גם על החברים והמכרים שלהם – והחברים והמכרים של החברים שלהם. כך, למרות ש”רק” 270 אלף איש התקינו אותה, הצליח קוגן לקצור פרטים על 50 מיליון משתמשי פייסבוק אחרים.
המידע הרב והחשוב שהשיגו כותבי האפליקציה הועבר לחברת קיימברידג’ אנליטיקה, תוך כדי הפרת תנאי השימוש של פייסבוק, שאוסרים על איסוף המידע והעברתו לגורם חיצוני. אך נראה שפייסבוק עצמה לא עברה על החוק. קיימברידג’ אנליטיקה הנה חברת מחקר וייעוץ פוליטי בריטית. החברה עלתה לכותרות כאשר היא לקחה חלק פעיל בקמפיין הבחירות של המתמודד דונלד טראמפ במסע הבחירות לנשיאות 2016 ואף בקמפיין ההיפרדות של בריטניה מהאיחוד האירופאי – הברקזיט.
המידע המדובר שנאסף מהפייסבוק אפשר לחברה לייצר פרופילים של משתמשים, לסגמנט ולטרגט אותם, ולפמפם קמפיינים פוליטיים בפייסבוק אשר עושים שימוש בכלים פסיכולוגיים שונים ומנצלים את הפחדים והאמונות של האנשים השונים. לדוגמא, במידה ומגלים על פי נתוני השימוש בפייסבוק שאדם מסוים חובב מרוצי סוסים, ניתן לבנות קמפיין אישי שמדגיש עד כמה המתחרה במסע הבחירות "שונא סוסים ואמר שיחוקק חוקים להגבלת מרוצי הסוסים" (לא משנה אם מידע זה נכון או לא) והדבר ישפיע ככל הנראה על הצבעתו של האדם. דובר על כך שבבחירות בארה"ב עיקר המאמץ הופעל במדינות ה"מתנדנדות" וישנן טענות שפעולות אלו גרמו להטיית תוצאות הבחירות.
כאשר נושא זה התפרסם, הפסידה פייסבוק מעל 50 מיליארד דולר מערכה, ואנשים רבים כולל ידוענים (כולל לדוגמא אלון מאסק, הבעלים של טסלה ושל SpaceX וממייסדי Paypal) הודיעו שסגרו את החשבון שלהם בפייסבוק. קמפיין זה מופיע תחת #leavefacebook. מרק צוקרברג, מייסד ומנכ"ל פייסבוק, נאלץ לתת עדות פומבית למחוקקים האמריקאים ולהתנצל למול כל המשתמשים.
הנקודה המעניינת ביותר היא שעל פי המידע שהתפרסם עד כה נראה שפייסבוק, שפעלה תחת ייעוץ משפטי צמוד, ככל הנראה לא עברה על החוק! נראה ששותפים שלה עברו אולי על החוק ועל הצהרות הפרטיות שקיבלו מהמשתמשים, אך לא פייסבוק עצמה. ועדיין הפגיעה בפייסבוק חמורה. כלומר, קבלת ייעוץ משפטי ועמידה בחוק (כפי שנראה עד לנקודה זו) לא סייע לפייסבוק מבחינה עסקית!
לפיכך, ארגונים צריכים להפעיל "common sense" ולהתנהל באופן הגון בהתייחסות שלהם לנתונים אישיים של לקוחות, עובדים, ספקים וכד', ולא להיות בטוחים שכיסוי ואישור משפטי יספיקו בכל מצב. זהו המסר העיקרי של מסמך זה.

 

כשל השוק בערוצי שירות הדיגיטליים

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

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

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

אני זוכרת שרק לפני 4 שנים נתקלתי בלא מעט מחקרים שניבאו ש% הפניות למוקד הטלפוני יצנחו מ 80%~ לכ 25% עד 2018 עקב זינוק חד בהיקפי השירות העצמי. 2018 כבר החלה, וירדנו לא ל 25% אלא ל70% (68% בחודש טוב). ועד כמה שזה נשמע מוזר, הנתון הזה לא מאוד שונה בפלחי אוכלוסייה שונים (נתון דומה גם בקרב בני 18-34 על פי מחקרים בינלאומיים). חידוד חשוב: לא מדובר על נפח /זמן השיחות – אלה אכן יורדים, אלא על זה שבמהלך אינטראקציה מתישהו יעורב גם המוקד הטלפוני, לצד ערוצים אחרים (שהשימוש בהם עולה כל הזמן). למה אי אפשר לוותר עליו? מה התפקיד הכ"כ חשוב שהוא ממלא?

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

בשנים האחרונות ערוצים דיגיטליים חדשים התחילו להיכנס בקצב גובר: בוטים, conversational, personal assistants, messaging, visual IVR, video chat… מצד אחד, חברה לא יכולה להרשות לעצמה "לפספס" ערוץ עם פוטנציאל עסקי, מצד שני, צריך להבין שיש תמיד tradeoff להוספת ערוץ:

ככל שמוסיפים ערוצים, קשה יותר לייצר חויית לקוח רציפה (“Seamless”: חסרת תפרים).

מובילות ה Omni channel בעולם על פי דירוגי הלקוחות (דיסני, סטארבקס ודומיהן…) משתמשות במעט ערוצים דיגיטליים, ברוב התרחישים הן יערבו 2-3 ערוצים שאחד מהם יהיה הערוץ הפיזי. אבל הן עובדות קשה מאוד על למקסם את השימוש במכלול הערוצים שבהם הן כן עושות שימוש. האופטימיזציה נעשית ברמת המסע הכולל, ולא ברמת הערוץ. קחו לדוגמה את מסע ה Omnichannel המהולל של סטארבקס (מסע הבוקר לקפה של פרסונה שבטח יכלה לענות לשם ג'יין, האמא הקרייריסטית שנוסעת לעבודה בכל בוקר באותו המסלול ובדרך עוצרת לקפה). המסע מתחיל מהבית, עוד לפני היציאה לדרך (לרוב באפליקציה שמבקשת אישור לקפה הקבוע של הבוקר) ממשיכה בסניף הפיזי (הקפה כבר מוכן וה QR code קופץ לתשלום מהיר בקופה), תכנית ה rewards מתעדכנת אוטומטית. החיבורים בין הערוצים האלה (במקרה זה, בסה"כ 2) עובדים כ"כ יפה וחלק, כל צעד עתידי נצפה מראש ו"מוזנק" ויש הרגשה שמישהו פה החליק את הדרך.

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

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

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

• פונקציה לבחינת ערוצים חדשים (Channel innovation lab) – יכול להיות כחלק ממעבדת חדשנות אחרת או אדם שתפקידו לעקוב אחר החידושים בתחום ולבחון אותם.
• בחינת ROI לכל ערוץ במונחים של חוויית לקוח, עלות תפעולית, או תועלות אחרות (לדוגמה, ערוצים שמסייעים בבניית פלטפורמת דאטה – כמו לדוגמה ערוצי messaging)
• יכולת התחברות לערוץ הקודם/הבא במסע – המעברים בין הערוצים יותר מעניינים מהערוצים עצמם. 90% מהאינטראקציות כיום הן רב-ערוציות!
• מיפוי "תפקיד" הערוץ בכל מסע / מקטע
• התמקדות – אחד מ3 כללי הזהב שפורסטר הגדירה לתחום (You can’t please everyone)

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

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

 

Organizational Design ו-StoryVesting: למה הם כל כך חשובים לעיצוב ארגוני העתיד?

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

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

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

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

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

ההשראה וכוכב הצפון

די ברור מי מהווה את ההשראה של ארגונים כיום: כמו תמיד, אלה המגניבים, כמובן.

אותם סטארטאפים קלילים, בעלי מבנה מושטח ורשתי (בזמן שאנחנו עוד עסוקים במעבר ממבנה פונקציונאלי למבנה מטריציוני), שנולדו למציאות שבה ארגוני data-driven customer experiences הם המובילים, שעבורם Agile היא שיטת עבודה ברורה כשמש, שחשיבות חוויית הלקוח היא אקסיומה שהם נולדו לתוכם, שבהם החיבור בין חויית העובד לחויית הלקוח ולתוצאות העסקיות הרבה יותר שקוף, ברור ואף מדיד, שמושרשת בהם תרבות של התנסות ולמידה אדפטיבית כל הזמן כטכניקה של Growth ולא משהו שהוא בגדר "נחמד" ומרגיש נעים. הם לא צריכים להוכיח כל הזמן ROI להנהלה הבכירה, לא צריכים למנות סוכני שינוי כדי לייצר את השינוי, הם לא צריכים לשטח שום מבנה או למוטט מחיצות ארגוניות ודפוסי חשיבה מיושנים (כל זה בהגזמה, כמובן, to prove a point).

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

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

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

למה אנחנו מדברים היום על Organizational Design?

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

StoryVesting: עד כמה העובדים שלכם מאמינים בסיפור של הארגון שלכם ומחויבים לו?

לא מדובר רק ב"עד כמה העובדים מאמינים ומזדהים עם המטרות של הארגון שבו הם עובדים", מדובר על תחושה של מחוייבות ברמה הרגשית. Story drives Growth – הגדרה יפה שקל להתחבר אליה. אבל בדרך כלל כשאנחנו אומרים את זה, אנחנו מיד חושבים על הלקוח – אם הלקוח מזדהה עם ה"סיפור" של המותג ורוצה להיות חלק ממנו, זה מתכון להצלחה עסקית ולצמיחה. אבל תדמיינו מצב בו כל אחד מעובדי הארגון הזה מזדהה ומחויב לסיפור, לערכים, לחזון ולמטרות, איזה כוח אדיר זה. לזה קוראים StoryVesting ואחת הדוגמאות הבולטות שללא ספק השיגו זאת היא Zappos שכל אחד מהעובדים שלה יודע מה המהות שלה, מה מניע אותה, מכיר את הערכים והמטרות שלה (“Delivering Happiness to People”). אבל גם אין ספק שאחוז מאוד גבוה מהם מרגיש מחויבות רגשית לערכים האלה. מה שנחמד בסיפור של זאפוס זה שהיא לא בדיוק חברה שפועלת להצלת כדור הארץ ולמיגור הרעב בעולם, אלא חברה שמוכרת נעליים אונליין. ועדיין – יש לה סיפור, וחשוב מזה – העובדים שלה מאמינים ותשוקתיים לגבי הסיפור הזה, מה שגורם ללקוחות שלה להפוך לכאלה.

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

כדי להבין למה מבני ארגונים כיום כ"כ לא מתאימים ואף מכשילים את מימוש חזון CX בארגונים, אפשר לבחון את ההיסטוריה של מבנים ארגוניים:

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

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

ההמשך: מבנים פונקציונליים מטריציוניים

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

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

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

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

1. עקרון #1: ארגונים רשתיים

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

2. עקרון #2: Flatter is Better

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

שתי דוגמאות קיצוניות מאוד במבנה שטוח, רשתי (ואף נטול בוסים!): Valve ו- Zappos.

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

3. עקרון #3: מבנה סביב "משימה" ולא "מוצר"

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

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

 מקור: HBR – Competing on Customer Journeys

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

במחקר מעולה שפורסם ב HBR, תואר מודל ההפעלה האולטימטיבי של "מכונת השיווק העתידית". באותו המחקר מתוארים 3 סוגי בעלי תפקידים בארגון בהקשר של שיווק וחויית לקוח: Think, Feel, Do:

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

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

"In the battle between culture and capability, culture wins every time". -Chamath Palihapitiya

 

 

 

 

 

 

הדרך למימוש חזון Employee Empowerment

Once upon a time…

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

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

מקור: Josh Bersin – Deloitte

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

And then came Talent Management

כבר לפני 10 שנים ספקים שונים בתחומי ה Talent (גיוס/למידה/ניהול ביצועים/פיתוח כישורים ועוד) הבינו כי ארגונים רוצים תמונה אינטגרטיבית והחלו לרכוש ספקים אחרים. לאט לאט הושלם פורטפוליו המוצרים והתחלנו לראות "סוויטות" של ניהול ה Talent שמנהלות את כל מחזור החיים של עובד בארגון Hire-to-Retire.

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

טרנד חזק לסוויטות Talent = טרנד חזק לענן

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

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

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

From Talent to People

על פי Bersin, למרות שאנחנו בישראל רק מתחילים לאמץ סוויטות Talent לאחרונה, ה"דבר הבא" כבר בדרך: People Management. לאחר שיש לנו את התמונה השלמה של ה Talent הארגוני, אנחנו משפרים את היכולת שלנו להעמיק את ההתייחסות שלנו לעובדים כ… אנשים 😊 למקסם את חוויית העובד, להשקיע ביצירת employee engagement, לרתום את העובדים למטרות הארגוניות, לייצר הזדהות ומוטיבציה ועוד.

מקור: Josh Bersin – Deloitte

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

ניהול חוויית העובד

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

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

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

 

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

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

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

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

יש כאן בעיה – כלומר, הזדמנות!

לפונקציית ה-HR בארגון יש הזדמנות מאוד גדולה להפוך להיות חלק גדול ממאמץ השינוי הארגוני שמתרחש כעת בכל כך הרבה רבדים. ה"טרנספורמציות" השונות שמתרחשות כרגע בתחומים רבים בארגון – בין אם זה בתחום חוויית הלקוח, יצירת תרבות של חדשנות, הפיכת הארגון ליותר מונע-נתונים (Data Driven) ועוד, אין ספק שמשאבי אנוש חייבים להתחבר למטרות עסקיות אלה, ולראות כיצד הם מסייעים ומשפיעים ישירות (ואף לכמת השפעה זו!) על מה שמעניין את הארגון בימים אלה.

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

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

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

איפה פונקציית ה-HR במאמץ זה? כיצד היא מסייעת לארגונים לייצר את אותה יכולת ארגונית?

 

אז מה עושים כדי לקשר יוזמות HR/Talent עם האתגרים העסקיים של הארגון?

כאן אנחנו מסתמכים על השימוש בעולם הנתונים והאנליטיקה. KPMG הגדירו תהליך שהם קראו לו בשם Evidence-based HR והוא נראה כך:

כלומר, Evidence-based HR עושה שימוש בדאטה, אנליטיקה ומחקר על מנת להבין את הקשר בין יוזמות ניהול ההון האנושי, לבין תוצאות עסקיות (כמו ביצועים פיננסים, שביעות רצון לקוחות, איכות וכו').

Data-Driven HR

כבר שוחחנו רבות על תחום ה Data-Driven שנוגע בכל רובד אפשרי בארגונים כיום. גם בתחום משאבי אנוש, אנו חושבים שיותר ויותר פעילויות (לא רק "החלטות" אלא הפעולות בפועל) יתבססו על תובנות, שנשענות על נתונים.

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

גם בגזרת האנליזה וביצוע המחקר אנחנו לרוב מתחילים משלב די בסיסי. ישנם ארגונים בהם קיימת פונקציה של אנליסט/ית לעולם משאבי אנוש, אולם זה עדיין לא דבר נפוץ. גם אם ישנה כזו פונקציה, לרוב היא פונקציה של אנליסט/ית BI, שעוסק בשאלה "מה קרה בעבר?". אם אנחנו רוצים לעסוק בתחזיות ומגמות, אנחנו צריכים לגייס או להכשיר אנליסטים שמכירים את עולם המודלים אנליטיים ו- predictive analysis. כלומר, יש כאן אבולוציה של יכולות בחקר הנתונים, כאשר השאיפה צריכה תמיד להיות להתקדם צעד אחד קדימה (ולא לקפוץ משלב 0 לשלב 4, לדוגמה).

לסיכום:

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

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

הענן פה – אז מה עושים?

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

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

הטמעת תמידית של תהליכים עסקיים ומערכות המידע התומכות בהם

רובם המכריע של הפתרונות המוצעים בענן מבוססים על ארכיטקטורה של multi-tenant והמשמעות היא שכל המשתמשים בעולם נמצאים באותו בסיס של קוד ומסד נתונים ולכן כאשר מתבצע שדרוג – הוא מתבצע לכל המשתמשים בעולם באותו זמן ולא ניתן לדחות שדרוג זה. רוב יצרני הפתרונות בענן מבצעים שדרוג פעמיים בשנה והמשמעות היא שארגונים צריכים (תלוי בגודל השינוי של הגרסה החדשה לעומת הגרסה הישנה) לבצע הטמעה של הגרסה החדשה של המערכת, כולל שינוי של תהליכים עסקיים המתבקשים משינויי המערכת. זאת לעומת המצב הקודם שבו שינויים (אמנם גדולים יותר) היו מתרחשים רק פעם במספר שנים. לפיכך, מאמץ ההטמעה הארגוני אמור לגדול, כאשר הטמעת מערכות הופכת להיות פעולה שהיא יותר on going ולא פעולה שמתרחשת פעם במספר שנים. הגורמים העסקיים צריכים לקבל את העובדה שתהליכים העסקיים משתנים\מתפתחים כל הזמן.

מעבר מ- CAPEX ל- OPEX

צריך להבין שהענן הוא 'שירות', ללקוח אין בעלות על הענן אפילו אם מבצע עסקה ארוכת טווח. לפיכך מדובר בהוצאה שוטפת הנרשמת ב- OPEX. זאת לעומת התוכנה שמותקנת בארגון – שהיא בבעלות הלקוח והסכום ששימש לרכישה מופיע בתקציב ההשקעות הארגוני CAPEX. התוכנה בבעלות הארגון הוא נכס שמופיע כחלק מנכסי הארגון במאזן ומופחת עם השנים. בארגונים מסחריים רבים ישנה העדפה ל- CAPEX לעומת ה- OPEX ומשום כך יחסי ה- CAPEX \OPEX משפיעים על מדד חשבונאי EBITDA- רווח לפני ריבית, מיסים, הפחתות ופחת (כלומר הפחת אינו חלק ממדד זה). במסגרת המעבר לענן הגורמים הפיננסיים (CFO, חשבות, קשרי בורסה וכד') יצטרכו "לעכל" את העובדה שהתמונה הפיננסית של הארגונים השתנתה ויצטרכו להסביר זאת לגורמים הרלוונטיים, כגון המשקיעים בבורסה.

סייבר ורגולציה בקצב מואץ

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

מבנה ארגוני חדש ושדרוג תהליכי תפעול ללא דריסת ה"ישן"

במאמר הקודם כבר דיברנו על כך שהענן מחייב התארגנות שונה ובניית תהליכים חדשים בין הגורמים הבאים: תפעול תשתיות, רגולציה, רכש ,מטה ה- IT (העוקב אחרי התקציבים ומתעדף משאבים) ואבטחת מידע\סייבר. במאמר גם הזכרנו כלים אשר באים לתת מענה לסוגיות אלו – תחום ה- cloud management platforms. הפעם נשים את הדגש על שילוב הישן עם החדש. לארגונים יש נטייה לבנות צוות ענן המופרד מהצוותים הקיימים בארגון. למרות היתרון במיקוד ובמקצועיות מדובר על מהלך שגוי, מכיוון שבניית צוות נפרד אשר מטפל בענן גורם ליצירת שני מחנות בארגון "ישן" מול "חדש", דבר שמהווה מתכון לכישלון בטווח הארוך. הדרך המומלצת היא לשלב את החדש בתוך הישן – במידת האפשר. כלומר, לדוגמא, צוות הסיסטם יטפל בשרתים בענן וגם בשרתים on prem. צוות ה- DBA יטפל בנתונים גם בענן וגם ב- on prem וכד'. רק האזורים שלא קיימים כלל בסביבת ה- on prem צריכים להיות מטופלים על ידי צוות הענן – דברים כמו ניהול הקשר מול ספק הענן בהקשר של תקציבים, מידת השימוש וכד'.

עד כאן להפעם.

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

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

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

1. Cloud First/ Cloud Only: ככל שעובר הזמן ישנה יותר ויותר פונקציונליות עסקית מתקדמת אשר קיימת אך ורק בענן. (כמעט) כל האפליקציות החדשניות העסקיות המפותחות כעת נמצאות בענן. לגבי אותם פתרונות להם קיימים גם גרסאות ענן וגם גרסאות on premise, על פי תמונת המצב שנמצאת בידינו כעת, החברות מפתחות ומקדמות את גרסאות הענן יותר ויותר לעומת גרסאות ה- on premise אשר "קופאות על שמריהם" ובמקרים הפחות טובים מפסיקות להיתמך. משמעות ניתוח זה היא שארגון אשר ירצה להמשיך ולהשתמש בפונקציונליות עסקית מתקדמת יהיה חייב לעבור לענן באותו האזור ולכן במובנים רבים, בגלל שיקול זה, הענן הוא לא אופציונלי אלא בגדר הכרח. כלל הארגונים המתקדמים יהיו, בדרך כזו או אחרת, בענן.
2. הענן מספק גמישות ועדכניות טכנולוגית משופרת בעשרות מונים על הגמישות והעדכניות הקיימת בארגוני ה- IT ואף המתקדמים ביותר. כל היכולות הטכנולוגיות החדשניות נמצאות בענן וניתן להתחיל להשתמש בהן על ידי "לחיצה על קליק" (כמעט…). לעומת ארגון מסורתי אשר רוצה להשתמש ביכולות חדשניות: תחילה, עליו לרכוש את הטכנולוגיה החדשה, לאחר מכן להתקין אותה, להטמיע, לתפעל אותה (עדכוני גרסאות וכד'). ולכן ארגונים אשר שואפים להשתמש בטכנולוגיות החדשניות ביותר באופן מהיר עושים זאת באמצעות הענן. אגב, אלטרנטיבה מסוימת לזריזות הטכנולוגית המתקבלת בענן היא הקוד הפתוח שגם הוא מאפשר זריזות גבוהה עקב האפשרות להשתמש ולנסות בפונקציונליות חדשה באופן נוח (ללא רכישה). עם זאת, תפעול הקוד הפתוח (התקנה, קינפוג, עדכון גרסאות וכד') יותר מורכב בסביבת קוד פתוח ב- on prem מאשר בענן ועלול להיות גם יותר מורכב משימוש במוצרים מסחריים.
3. עלויות באופן כללי ויכולת גידול\קיטון בפרט. ישנם מספר לא מבוטל של מקרים שבהם הענן יכול לספק שירותים זולים משמעותית מאשר הארגון המסורתי. עם זאת, יש גם מקרים שבהם הענן לא ייתן שירות זול יותר מאשר הארגון המסורתי.

לסיכום, כל עוד תימשך המגמה של "יותר ויותר פונקציונליות עסקית אשר קיימת רק בענן" – ארגונים יהיו מחויבים להשתמש בענן, אפילו אם לא יעשו זאת בשמחה מרובה. הרי במערכת היחסים "ספק – לקוח" בענן, הלקוחות מאבדים חלק מכוחם היחסי והספקים מתחזקים. זאת מכיוון שביישומי on prem מסורתיים הלקוח הוא הבעלים של התכנה ויכול באופן תאורטי (וגם מעשי) להחליט שהוא מפסיק את ההתקשרות ונשאר בגרסה הנוכחית שלו של התכנה. דבר זה לא קיים בענן ולכן יכולת התמרון של הלקוח למול הספק נמוכה באופן משמעותי. למרות שיקול זה, לארגוני ה- IT אין נכון להיום ברירה והם חייבים להיכנס לענן כי הספקים פשוט אינם מאפשרים להם להתקדם בסביבת ה- on prem. לגבי אותם ארגונים אשר באופן מסורתי לא מחוברים לאינטרנט או מפוקחים באופן משמעותי על יד הרגולציה, קיימים גם פתרונות לגבי מידע רגיש שלא יכול לצאת מתוך הארגון. מעבר לפתרונות ההצפנה השונים (שמירת המפתחות בתוך הארגון או בענן) ישנם גם פתרונות של tokenization שמשמעותם היא שהמידע הרגיש נשמר בתוך הארגון ב-DBMS\טבלה ומה שיוצא החוצה הוא "מספר סידורי" בתוך הטבלה. ולכן גם אם פתרונות ההצפנה נפרצים, התוקף יגלה בסך הכל את המספר הסידורי בטבלה ולא את הנתון הרגיש (שנמצא רק בתוך הארגון).

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

המוביל ביניהם הוא Amazon – AWS. AWS היו הראשונים בתחום של IaaS ו- PaaS, הם הגדולים בתחום מבחינת הכנסות מספר שירותים ומבחינת היצירתיות בתחום. לדוגמה, AWS היו הראשונים שיצאו עם שירות serverless (בשם Lambda). מהות השירות (אשר כעת קיים גם ב- Azure וב- GCP) הוא קוד שמחכה ל- trigger כלשהו ומתבצע כאשר ה- trigger מתקיים. התשלום מתבצע לפי מספר הפעמים שהקוד רץ (ולא מחייב שימוש ותשלום לפי שרת). דוגמה נוספת למובילות של AWS היא העובדה שכל הפתרונות החיצוניים אשר מבצעים אופטימיזציה של עלויות ענן (כלומר מסתכלים על השימוש בענן וממליצים המלצות כגון "במקום 5 שרתים גדולים כדאי לעבור ל-20 שרתים קטנים") יודעים לעבוד מעל AWS אבל לא תמיד על שאר העננים. כלומר, AWS הוא המוביל.

Azure של מיקרוסופט גם הוא נחשב בין המובילים בתחום עקב ההשקעות הגדולות של מיקרוסופט בתחום (שאגב תומכת ביישום כל הטכנולוגיות בענן שלה כמו לינוקס ולא רק ב- windows) וגם עקב הנוחות של ארגונים להשתמש בסביבה המוכרת להם – לדוגמה שכפול של Active directory מתוך הארגון ל- Azure מתבצע באופן שהוא seamless. אגב, מיקרוסופט הוציאו לאחרונה פתרון חדשני AzureStack שהוא יישום חלק מיכולות הענן הציבורי Azure בתוך הארגון על ידי מכונה שמתנהגת כמו Azure הציבורי. פתרון זה יכול להקל מאוד על מעבר ארגונים לענן.

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

עננים בולטים נוספים מעבר לשלישייה הפותחת הנם הענן של אורקל והענן של IBM. אורקל משקיעה רבות בענן שלה, רוכשת חברות רבות, הן חברות SaaS והן חברות המספקות טכנולוגיות ענן אחרות (לדוגמה רכישת ravello הישראלית). מן הסתם לאורקל יתרון בהרצה של טכנולוגיות מסורתיות כמו oracle dbms , יתרון בהפעלת bare metal ועוד. IBM בצעו רכישה של softlayer אחד העננים המתקדמים שכלל יכולת ייחודית של bare metal (הקמה ושימוש בשרתים פיזיים ולא רק וירטואליים). וכמו אורקל גם היא מאפשרת חיבור מתקדם בין מה שרץ בתוך הארגון לבין מה שרץ בענן הציבורי.

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

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

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

כלומר הענן מחייב התארגנות שונה ובניית תהליכים חדשים בין הגורמים הבאים:

1. תפעול תשתיות
2. רגולציה
3. רכש
4. מטה (העוקב אחרי התקציבים)
5. אבטחת מידע\סייבר

ישנם גם כלים אשר באים לתת מענה לסוגיות אלו. מדובר על תחום cloud management platforms עם יצרנים כמו rightscale scalr cliickR (cisco) cloudform redhat ועוד. אנחנו ממליצים לארגון ללמוד סוגיות אלו (וכמו כן, לא לבצע רכש של כלים כאלה כעת).

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