STKI Market Pulse – עדכונים מהירים על קצה המזלג:

מיהו ה- CTO החדש?

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

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

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

שימוש במוצרי BI במודל קוד פתוח

לאחרונה קיבלנו כמה פניות מארגונים ששוקלים שימוש בכלי BI קוד פתוח. המניע לשאלות אלה בתחום ה-BI ספציפית הנו ברובו הגדול של המקרים בו אנו נתקלים – חיסכון בעלויות רישוי. חלק מהארגונים מעוניינים להרחיב משמעותית את השימוש בשירותי BI אל מעבר למשתמשי ה-BI הקלאסיים (כיום % משתמשי ה-BI עומד על כ-30% מכלל העובדים), לשותפים חיצוניים או ללקוחות. במקרה זה, ה Business case של שימוש במוצרי קוד פתוח הנו ברור. כאשר בוחנים כלי BI קוד פתוח, מעניין לראות כי בתחום זה ספציפית, כל שלושת המוצרים הבולטים נרכשו על ידי חברות טכנולוגיות:

  • Pentaho – אשר נרכשה לפני מספר חודשים על ידי HDS במטרה המוצהרת להיכנס לתחום האנליטיקה ב-IoT analytics
  • JasperReport – נקנו על ידי Tibco
  • BIRT – חלק מ Eclipse, נדחף על ידי Actuate- כיום חלק מ-Open Text.

רוב השימוש בכלים אלה עד כה הנו לחברות טכנולוגיות המעוניינות לפתח רכיבי BI ולשלבם בתוך האפליקציות שלהם אותן הן מוכרות לשוק (Embedded BI). אולם מודלי הרישוי – המאפשרים גישה למסה של משתמשים, הרבה יותר מותאמים ל Customer facing BI מאשר אלה של רוב ספקי ה-BI המסורתיים. כתוצאה מכך, אנו צופים שארגונים אשר יהיו מעוניינים להציע שירותי BI אל מחוץ לגבולות הארגון יבחנו ברצינות מודל קוד פתוח. ייתכן והדבר יוביל בסופו של דבר לרצון לממש כלי קוד פתוח גם לשימוש של BI פנים ארגוני לעובדים (אך כיום ובעתיד הנראה לעין אנו לא רואים מגמה כזו בארגוני Enterprise).

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

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

ניהול סיכוני טכנולוגיות המידע

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

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

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

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

מודעות פרסומת
STKI Market Pulse – עדכונים מהירים על קצה המזלג:

מתוך המלצות לרכש IT

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

המלצות כלליות:

  • הגדרת ההצלחה של הפרויקט. רצוי לבנות מודל שבו התשלום לספק\אינטגטור יהיו מבוססים על ההצלחה של הפרוייקט. דברים כמו (בדוגמה לפרוייקט של CRM כשהמטרה העקרית היא להוריד את זמן הטיפול בקריאות) "במידה ומצליחים להוריד את זמן הטיפול הממוצע בקריאה ב- 5% אז התשלום יהיה  X. במידה ומצליחים להוריד את זמן הטיפול הממוצע לקריאה ב- 10% התשלום יהיה Y".
  • כיצד מחשבים את תאריך תחילת התשלום עבור הרישוי (תחילת הפרויקט/עלייה לאוויר)
  • אי עמידה בחוזה – מה קורה אם לא עומדים בחוזה?
  • הערה כללית חשובה – שינויים בהסכם יתבצעו רק מול הרכש באופן ספציפי (אחד הלקוחות תאר מצב שבו האנשים הטכניים התקינו גרסה חדשה של מוצר ובמסגרת ההתקנה לחצו על I AGREE ששינה את תנאי הרישוי – איך סופרים רישיונות).
  • הגדרת האחריות בין גורמים השונים המעורבים בפרויקט (לקוח/ ספק בינ"ל, ספק מקומי/ אינטגרטור)
  • יש להגדיר גבולות של מערכת וגם אפשרות לחרוג לעיתים מהגבולות. לדוגמה, נניח שהספק מספק מערכת שמבוססת על microfocus cobol. נניח שהלקוח מעדיף לעבור ל- cobol-IT. רצוי שיהיה סנריו שבו (במידה ומעדיפים לבצע מהלך כזה באופן עצמאי ולא על ידי הספק) הלקוח יוכל לבצע את ההחלפה בעצמו ולהחזיר את המערכת לאחריות הספק. הדוגמה כאן היא מתחום התשתיות אבל העקרון צריך להיות כללי.
  • אם אפשר- במידה ויש חילוקי דעות לקיים בוררות\משפט בישראל תל אביב.
  • במידה והתוכנה יקרה per seat רצוי לכלול בפתרון רכיב של usage\metering אשר בוחן את מידת השימוש בתוכנה. כך למשל תוסר התוכנה מלקוחות אשר לא ישתמשו באופן מהותי בתוכנה (לפי מדידות רכיב ה- usage\metering) .
  • שהספק לא יתקין כלום – אפילו לא לבדיקה- מבלי שקיבל אישור של רכש
  • רצוי לנסות ולהבין כמה שיותר מוקדם כיצד מתוגמלים אנשי המכירות הן של היצרן והן של האינטגרטור הגלובלי והמקומי. האם מתוגמלים לפי סה"כ הכנסות? האם רק לפי רישוי חדש? האם לפי גידול? ואז לנסות ולהתאים את המשא ומתן לפי ידע זה.
  • רצוי לקבל התחייבות שהתנאים בהסכם יהיו תקפים גם עם היצרן או האינטגרטור (הישראלי\חו"ל) ירכשו או יתמזגו על ידיד אחרים (כולל תוקפו של הסעיף על מוצרים עתידיים).
  • רצוי שיהיה פירוט מחירים ברמת השורה הבודדת של העסקה (לא מחיר כללי לעסקה) כך שבמידה ויש שינוי אפשר להשליך על משמעות השינוי.
  • באופן כללי רצוי לבנות את ההסכם "מוכן לשינויים" כלומר באופן שיקל על ביצוע שינויים בתכולה כמה שיותר.
  • באופן כללי – צריך לבנות את ההסכם הנוכחי כך שיכין את התנאים להסכם הבא. כלומר אם חותמים על הסכם ל- 5 שנים רצוי להוסיף פסקה שמדברת כל כך שהתנאים בהסכם זה יהיו תקפים גם להסכם הבא (הסכם התחזוקה). כך שהספק לא יוכל להעלות מחירי תחזוקה וכד'.

 

מוצר ורישוי

  • התחייבות לכמות הפעמים (בכל פעם שיוצאת גרסה חדשה/ אחר)
  • מה בדיוק מקנה הרישוי: רישיון תמידי perpetual license)) ותחזוקה או מנוי (subscription license)
  • במידה ומדובר על perpetual – לוודא שיש אפשרות להשתמש במוצר ללא תשלום דמי תחזוקה.
  • במידה ובוחרים ב- subscription מה המשמעות לעבור "חזרה" ל- perpetual
  • בכל מודל – צריך לוודא שהנתונים הם בבעלות הלקוח.
  • לנסות לקבל מראש מידע איזה שדרוגים אמורים לקבל ומתי.
  • להתייחס לסוגיה של עדכוני תשתיות – כלומר שעלות התחזוקה כוללת עדכון המוצר\פתרון לגרסאות חדשות של לינוקס\windows IOS ANDROID וכד'.
  • האם יש אפשרות לעבור מהמודלים השונים ל"בעלות על התוכנה והקוד" (כמו שאמדוקס מוכרים את התוכנה שלהם – והלקוח מקבל את התוכנה ויכול לשנות אותה בעצמו)
  • לוודא שכאשר כותבים קוד במסגרת הפרוייקט (אפילו קסטומצזיה של המוצר) – שהלקוח הוא הבעלים של הקוד שנכתב.
  • להגדיר מראש איך סופרים את רישוי התוכנה. הדבר הכי טוב הוא לציין שבארגון משתמשים ב- SMS או CA או משהו כזה – ולפי הדו"ח של הכלי יקבעו הכמויות. כך מונעים מהספק לבוא ולבצע ספירה בעצמו (עם כלים שהוא מתקין).
  • לגבי רכיבי משנה של תוכנה – האם ניתן יהיה להעביר את הרישוי (perpetual ) או זכות השימוש (אם ב- subscription) למערכות אחרות בלקוח? לדוגמא, אם במסגרת העסקה רוכשים\שוכרים 10 רישיונות של המוצר אבל בפועל מסתבר שמשתמשים רק ב- 8, האם ניתן להעביר את 2 הרישיונות לשימוש במקום אחר בלקוח? האם ניתן להעביר רישוי בין שרת פיזי לוירטואלי , לענן ובין פלטפורמות שונות (לינוקס, WINDOWS , מ- IOS ל- android)?
  • האם יש אפשרות להקפיא רישוי? לדוגמה אם רוכשים 10 רשיונות אבל תקופה מסויימת מבינים שצריך להשתמש רק ב- 8 רשיונות, האם אפשר "להקפיא את הרישוי" ולאחר תקופת הזמן לחזור לשימוש ב- 10 רשיונות?
  • האם אפשר יהיה להעביר את הרשיונות לגורם שלישי (לשכת שירות)?
  • האם ניתן ל"הביא רישוי" מהבית (של מוצרי תשתית)?
  • מודולים / מנועים / גרסאות עתידיות:
    1. מהי מדיניות התמחור לגרסאות חדשות? האם יש גרסאות משמעותיות שיצריכו רכישה מחודשת של רישוי?
    2. מה קורה עם המוצר (או חלק ממנו) מפסיק להיות נתמך (discontinues) או לחילופין מה קורה אם מאחדים מוצר (או מודול) עם מוצר אחר (או מפצלים מוצר לכמה תתי מוצרים)- האם צריך כעת לשלם על המוצר המורחב? רצוי לנסח בצורה כזו "ש"החברה מתחייבת לשמור על הפונקציונליות הנוכחית של המוצר\פתרון לאורך זמן על פי התמחור הבסיסי של ההסכם. במידה והפונקציונליות אינה מתקיימת במוצר הנוכחי, הספק יבצע החלפה למוצר או מוצרים תחליפים ללא עלות ובכדי לשמור על התנאים של הסכם זה".
    3. האם המחיר כולל "מנועים" (ניהול ארכיון מסמכים / BI מובנה / תשתית אינטגרציה ועוד)
    4. % הנחה ממחירון למנועים / מודולים נוספים
    5. במידה ומוזכרים מחירונים בעסקה – יש לציין ספציפית באיזה מחירון מדובר, להדפיס מחירון זה ביום תחילת ההסכם (לייתר בטחון).
    6. עדיף כמובן להשתמש במחירים גלובליים ולא במחירונים ישראלים או regional.
מתוך המלצות לרכש IT

STKI Market Pulse – עדכונים מהירים על קצה המזלג:

To GRC or not to GRC? זאת השאלה!

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

בעולם 54% מהחברות משתמשות בטכנולוגית של GRC אך בישראל השימוש בפתרונות GRC הנו בשיעור של פחות מ –15%!

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

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

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

פרויקטי IT – מסיוט ליצירת ערך עסקי אמיתי

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

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

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

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

בניית DC – רק אם אין ברירה!

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

בין המגמות שתרמו לשינוי גישה זו ניתן לציין את הקושי גובר והולך בתכנון וניצול שטחים בתחום והתוצאה היא שישנם ארגונים רבים אשר "נתקעו" עם שטחים רבים לא מנוצלים ואשר מחייבים אחזקה (מערכות האלקטרו-מכניות) יקרה. כמו כן הענן הציבורי שנכון להיום לא תופס נפח גדול בפעילות ארגוני ה- enterprise בישראל מוסיף גם הוא לתחושת האי הוודאות בתכנון ה- DC. במקביל היה שיפור בפתרונות lights out management המאפשרים השתלטות מרחוק על אתר DC ובכך לצור dark site – אתר המנוהל לגמרי מרחוק דבר המקל על שימוש באתר hosting. בנוסף לכך ההיצע והאיכות של פתרונות ה- Hosting בישראל גדל והשתפר –  ישנם יותר שחקנים שמציעים יותר פתרונות בין היתר שירותים מנוהלים כגון NOC (מרכז בקרה) בשעות הלילה שירותי גיבוי, שירותי רפליקציה של מכונות וירטואליות. ספקי ה- hosting הישראליים המתקדמים מציעים פתרונות ענן שעשויים להקל מהותית על שימוש בענן ללקוחותיהם – ענן ציבורי ב- latency של LAN !

שורה תחתונה: שימוש ב- DC ציבורי לצרכי hosting או DR הופך להיות הסטנדרט המקובל בקרב ארגוני Enterprise בישראל.

האתגר הבא בעולם השיווק (הטכנולוגי): Hub שיווקי לניהול אינטראקציות שיווקיות עם הלקוח

מנהלי שיווק ומנהלי חויית לקוח חייבים כיום להתחיל לבחון יישום כלים טכנולוגיים לבניית ה- HUB המרכזי לניהול כלל פעילויות השיווק עם לקוחות הארגון. מספר כוחות המניעים צורך זה: הראשון, במלים פשוטות – פשוט אין למנהלי שיווק ברירה אחרת. הקמפיינים הקלאסיים (והכלים הטכנולוגיים המנהלים אותם) כבר אינם מספקים. כלי שיווק קלאסיים עוצבו על מנת לענות על צרכי טכניקות שיווקיות שכיום כבר אינן רלוונטיות. הזירה השיווקית עברה לדיגיטל וכלי הנשק בזירה זו הנו טכנולוגיה. תוצר לוואי של מעבר זה הנו היכולת למדוד ולנטר כל פעילות שיווקית. אנשי השיווק לא רק הופכים להיות יותר טכנולוגיים (הגדרה חדשה בתחום – CTMO Chief Technology Marketing Officer – מעין CTO לעולם השיווק), אלא הם במידה רבה הופכים להיות אנשי נתונים ואנליטיקה.

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

שורה תחתונה: האתגר העיקרי של מנהלי השיווק, CMOs ומנהלי חויית לקוח יהיה בניית ה- Hub הארגוני שיסייע בקבלת תמונה מלאה ורחבה של האינטראקציות השיווקיות עם הלקוחות ויסייע להן בקבלת החלטות אסטרטגיות (כיצד לעצב חוייה יותר טובה) וטאקטיות (מתי ואיך לפנות ללקוח, באיזה ערוץ ובאיזה רגע) יותר טובות. זוהי הזדמנות מצוינת לחיזוק הקשר בין  IT/CIOs למנהלים אלה, שבמידה רבה תלויים בטכנולוגיה ככלי הנשק העיקרי שלהם באתגרים חדשים אלה.

STKI Market Pulse – עדכונים מהירים על קצה המזלג: