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

"מנהל/ת חווית לקוח" 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

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

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

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

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

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

2

לאחרונה, רווחת התפיסה כי תפקיד ה 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, הלקוח לא רכש מוצר אלא הצטרף לשירות וכל הזמן צריך להרגיש שהשירות מספק לו ערך על מנת להישאר בשירות.

3

Source: Antavo

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

4

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

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

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

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

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

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

 

מודעות פרסומת
תפקידים חדשים לניהול חוויית הלקוח

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

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

המסר הלא כל כך חבוי באסטרטגיית הערוצים הנוכחית של רוב הארגונים הוא שהתייעלות תפעולית ו"הסטה לדיגיטל" מסיטה את תשומת הלב מחוויית הלקוח. לגבי אותם מחקרים על העדפות הצרכנים, אכן פלח משמעותי מאוד (על פי פורסטר, כ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”). אבל גם אין ספק שאחוז מאוד גבוה מהם מרגיש מחויבות רגשית לערכים האלה. מה שנחמד בסיפור של זאפוס זה שהיא לא בדיוק חברה שפועלת להצלת כדור הארץ ולמיגור הרעב בעולם, אלא חברה שמוכרת נעליים אונליין. ועדיין – יש לה סיפור, וחשוב מזה – העובדים שלה מאמינים ותשוקתיים לגבי הסיפור הזה, מה שגורם ללקוחות שלה להפוך לכאלה.

1.jpg

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

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

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

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

2

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

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

3

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

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

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

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

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

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

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

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

5

6

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

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

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

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

77

 מקור: HBR – Competing on Customer Journeys

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

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

8

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

10

1112

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

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

 

 

 

 

 

 

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

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

Once upon a time…

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

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

1

מקור: Josh Bersin – Deloitte

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

And then came Talent Management

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

2

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

3

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

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

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

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

From Talent to People

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

10

מקור: Josh Bersin – Deloitte

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

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

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

4

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

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

5

 

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

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

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

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

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

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

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

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

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

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

 6

7

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

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

8

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

Data-Driven HR

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

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

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

9

לסיכום:

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

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

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

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

בסקירה הקודמת בנושא זה הבענו את הדעה שפונקציונליות עסקית מהותית תתבצע בענן הציבורי, מה שלא מותיר לארגונים ברירה או בחירה אם כן או לא להיות בענן. הסיבה העיקרית לכך היא שהספקים הבולטים מציעים פונקציונליות מתקדמת רק בענן. ספקים רבים מציעים את המוצרים\שירותים שלהם רק בענן ואחרים מציעים גרסאות 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 ועוד. אנחנו ממליצים לארגון ללמוד סוגיות אלו (וכמו כן, לא לבצע רכש של כלים כאלה כעת).

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

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

ניהול חדשנות על ידי Design thinking

The future cannot be analyzed, it must be designed" – Edward de Bono"

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

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

Design thinking מוכרת בעיקר כמסגרת מתודולוגית עבור ניהול החדשנות, אך היא באה לנער את כל התחום של התכנון העסקי באשר הוא. עקרונות של חשיבה עיצובית באו לתת מענה לתכנית ארגונית מסורתית, אשר נפרסת על מאות דפים (יש מי שהצליחו לסיים לקרוא אותה?!), ונכתבת במהלך 4-8 חודשים בממוצע (ברגע שנכתבה – חייבים לשכתב ולהתאים למציאות העסקית החדשה).

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

DT

Design-centric organization מסייע לאנשים להביא רעיונות על פי העקרונות הבאים:

אמפתיה:

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

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

הגדרת בעיה

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

רעיונות

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

קבלת החלטות – HiPPO VS Geek

ארגון תלוי בקבלת החלטות, כיצד לבצע את העבודה ומה חשוב לעשות בשלב הבא, בכל יום ובכל רמה – אסטרטגית וטקטית. כאשר אנו מסתכלים כיצד ארגונים מקבלים החלטות (לאיזה שוק להיכנס, באיזה פלח לקוחות להתמקד, מהי האסטרטגיה השיווקית וכדומה) אנחנו מתבססים על ניתוח נתונים ומחקרי שוק, אבל ברגע מסוים מישהו חייב לקחת החלטה "מהבטן". ההחלטה הזאת היא בדרך כלל החלטת ה –HiPPO – Highest paid person's opinion. בכל חברה יש את אותו האדם בעל המוניטין המרשים ביותר, בעל הטייטל הארוך ביותר, עם המשכורת הגבוהה ביותר, שבסופו של דבר, לאחר איסוף מידע, ניתוח נתונים ויועצים, יהיה זה שיחליט. אנו מקבלים את החלטת ה HiPPO והדבר מקובל על כולם.

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

בניית אב טיפוס

לבניית ה prototype כדאי לאמץ את שני העקרונות הבאים:

  1. MVPMinimal Viable Product. פיתוח מהיר של מוצרי אב טיפוס יכול לעבוד אך ורק אם דוגלים בהבנה של מהו הפיצ'ר הקטן והרזה ביותר שיכול לספק ערך חיוני ללקוח. לא מערכת חלומותינו, לא "אם כבר, אז כבר", אלא מוצר מינימלי בעל ערך ברור. היתרון של בניית Minimal Viable Product טמון ביכולת לפתח מוצר תוך מספר שבועות, ולספק ללקוח פיצ'ר חיוני, גם אם קטן.
  2. לבנות -> לבדוק -> לבנות מחדש. מכיוון שמדובר בבניית אב טיפוס בלבד, ארגון יפתח מספר מוצרים קטנים כאלה במקביל, והם יובילו, בסופו של דבר, למוצר הסופי או המערכת. ארגונים יתפתחו, יבדקו וישפרו את הפתרונות החדשים המון פעמים לפני שיגיעו למוצר הסופי. לפי שיטה זו ארגון לומד גם מהכישלון. למעשה, מוצרים חדשניים אמתיים שהצליחו להשפיע באופן מהותי או לשנות לגמרי את המציאות שלנו נעשו לכאלה בעזרת תהליך מתמשך של בנייה, בדיקות, כישלון, ועיצוב מחדש.

לסיכום

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

 

 

ניהול חדשנות על ידי Design thinking