הארכיטקטורה התהליכית לחוויית לקוח

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

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

המשמעויות של ה"טרנספורמציה למוכוונות חוויית לקוח" הן רבות, וכוללות משמעויות ארגוניות (מבנים ארגוניים משתנים), משמעויות פוליטיות (בכ20% מהארגונים הגדולים ממנים CCO/CXO – Chief Customer Officer / Chief Experience Officer לעתים כיחידה נפרדת ולעתים תחת שיווק/גוף עסקי אחר), תהליכיות (הגדרה מחדש של יחסי הגומלין בין שיווק-IT-מכירות-דאטה ואנליזה-תפעול), תרבותיות, טכנולוגיות ועוד. אבל במאמר הזה אנו רוצים להתמקד במשמעויות שקשורות בבניית הארכיטקטורה התומכת שארגונים נדרשים לה, ה"בניין" שיתמוך במאמצי העיצוב, ההפעלה והשיפור המתמיד של חווית הלקוח.

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

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

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

CX Architecture

Data Platform: פלטפורמת הדאטה וניהול זהויות
הכל ייפול ויקום על הדאטה, זוהי מנטרה שאנחנו לא מפספסים הזדמנות להדגיש. דאטה = הלב של הארכיטקטורה. אין דבר חשוב יותר להשקיע בו בזמן הקרוב מאשר בפלטפורמת הדאטה שלכם.
אל תתפתו לקפוץ לשלב ה ENGAGEMENT והערוצים לפני שיש לכם גרעין טוב של פלטפורמת דאטה המכילה זהויות לקוחות עם "הכנה למזגן" להתחברות למקורות מידע רבים ככל האפשר.
אבל "דאטה" זה לא מספיק, אותה פלטפורמת דאטה צריכה להיות מאורגנת סביב "זהויות" של לקוחות. אחד העיסוקים המאתגרים בשנה הקרובה יהיה לנהל את אותן זהויות – Customer Identities, ולחבר כמה שיותר פיסות מידע לאותה הזהות, לא משנה באיזה ערוץ אותו לקוח משתמש, באיזה device/מכשיר, האם משוחח עם הארגון ב online או ב offline. כאן טמון האתגר של חיבור מידע בין לקוחות "מזוהים" ו"לא מזוהים", מידע על נקודות מגע "פרסומיות" לעומת "שיווקיות"/"שירותיות"/"תפעוליות", והרחבה מתמדת של אותה פלטפורמת דאטה שחייבת להיות אמינה, איכותית, רחבה ורלוונטית.
בשלב זה לא רק חשוב אלא קריטי לקיים שיתוף פעולה הדוק עם אגף הטכנולוגיות, ה- Data Officer, וכל מי שאמון על ניהול הדאטה בארגון (עוד שינוי מהותי שמתרחש במקביל בארגונים כיום – ההסתכלות על דאטה בצורה מרכזית והניהול היותר מסודר של הנתונים). לכל אחד מהשחקנים יש חלק חשוב בהקמת ה Data Platform, בתחזוקה, בניהול, ב Governance ובהרחבה שלה לאורך זמן.

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

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

איך זה עובד? איך נראה התהליך?
איך נראה תהליך העבודה של עיצוב חוייות לקוח? מהם השלבים?
1. בניית פלטפורמת הדאטה הרחבה: איסוף, התחברות למקורות מידע שונים, יצירת APIs, יצירת תשתיות דאטה תומכות
2. יצירת, ניהול וטיוב של זהויות לקוח (multi-device, multi-channel).
3. גילוי תובנות בדאטה הקיימת, תכנון והגדרת מטרות ו-KPIs למדידה.
4. עיצוב חויית הלקוח: עיצוב מסעות לקוח, מקטעים, קהלים, טריגרים ועוד
5. תכנון, יצירה והתאמת התוכן לכל חלק במקטע.
6. תכנון orchestration של ערוצי ההתקשרויות לפי המסעות, המקטעים והמטרות שהוגדרו.
7. יצירת המלצות לפעולה (עם או בלי סיוע אנליטי, עם אופציה לשימוש במודלים מבוססי Machine Learning)
8. הוצאה לפועל תוך עריכת נסיונות – Testing & Optimization
9. אופטימיזציה – בדיקה מה עובד בפועל לאיזה תרחיש ולאיזו מטרה, והתאמת התכנית.
10. המידע מוזרם לפלטפורמת הדאטה. חזרה לשלב 1.

נשמע דמיוני? כך חברות מוצר טכנולוגי (Digital Natives) עובדות כיום. בלב העיסוק של חברות כאלה – המוצר שלהן – יושבים אלגוריתמים שבעצם ממכנים את כל הסעיפים למעלה. בכל רגע נתון בו אנו עושים שימוש באמאזון/Uber/ AirBnB וכד', כל השלבים מתקיימים. אבל בחברות אלה זהו תהליך ממוכן לחלוטין, אלגוריתמי, מונע-נתונים, נערכים כל הזמן נסיונות כדי לטייב את המודל ולייצר המלצות פעולה יותר חכמות. יש המכנים תהליך זה “The Brand Algorithm”.
אז גם אם לא נהפוך להיות האמאזון הבא (למה לא בעצם?!) אפשר לשאוב השראה רבה מהמנגנונים שחברות אלה מצליחות לייצר, באופן שמשפיע על המוצר שלהן בזמן אמיתי – ה Brand Algorithm שייחודי רק להן. חויית הלקוח לא מלווה את המוצר, היא מוטמעת בו כ"כ חזק שהיא הופכת להיות המוצר עצמו במידה רבה.

מהם החסמים?
ישנם עדיין אתגרים רבים, שימשיכו ללוות אותנו, וכדאי להיות מודעים אליהם:
1. יצירה וניהול של "זהויות לקוח" מהווה סוגיה משמעותית, עדיין לא פתורה גם לא אצל "מיטיבי הלכת". בשוק ה AdTech, מסעות הרכישות של יכולות אלה (DataTech) כבר החלו, אורקל לאחרונה רכשה את Crosswise שמתמחה בניהול זהויות לקוחות cross-device (איך אפשר לזהות שאני בנייד ואני בדסקטופ זה אותו לקוח לא מזוהה?)
2. איסוף הדאטה (התחברות למקורות מידע שונים, חיצוניים-פרסומיים ב paid media, פנים ארגוניים ב owned media, מובנה ובלתי מובנה וכד') וניהול אפקטיבי של הדאטה
3. אקטיבציה והוצאה לפועל של התכניות אל מחוץ לחומות הדיגיטליים של הארגון (יכולת שליטה מועטה, קבלת מידע מוגבל בחזרה).
אלו רק חלק מהחסמים, והם כמובן טכנולוגיים (עוד לא נגענו בחסמים הארגוניים, תרבותיים, תהליכים, כישורים, אנשים, פוליטיקות וכד'). מעניין לראות שהחסמים ברובם נוגעים בדאטה ובאנליטיקה. עם ה"צנרת" – תשתית האוטומציה, Marketing automation כבר פחות או יותר הסתדרנו.

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

הארכיטקטורה התהליכית לחוויית לקוח

מה מעכב את תחום הבוטים בישראל?

בזמן שבשוק הבינלאומי תחום הבוטים מתחיל לפרוח, בישראל יש הרבה מאוד ניסיונות, בחינת יכולות, פיילוטים ומאמצים. אך מתחיל להיווצר פער משמעותי לרעת השוק המקומי. מי שהחל לעסוק בתחום הבוטים ה"נוצץ" מהר מאוד מגיע לשני הגורמים המעכבים את מימושו בישראל: ענן, ועברית.
* הערה: "בוט" הנו מונח גמיש, יש כאלו שיטענו שבוט יכול להיות תכנית מאוד פשוטה מבוססת חוקים (כשלקוח אומר X -> תענה Y), יש כאלה שיטענו שבוט "אמתי" הוא כזה המציג יכולת לנהל שיחה חופשית עם מכונה שיודעת להבין משפט, לפרק אותו למלות מפתח, לחלץ כוונה, לחולל תהליך בהתאם, להתחבר למערכות שונות, לשלוף את המידע ולהחזיר אותו לשואל תוך ניהול "שיחה" עם כל כללי השיחה וניהול הדיאלוג.
מבחינתנו, פלטפורמת בוטים מספקת 3 דברים: ניהול דיאלוג, הבנת כוונה, וחילול APIs.

הגורם הראשון המעכב את תחום הבוטים בישראל – הענן:
תחום הבוטים נשען על טכנולוגיות מאפשרות, שעוסקות בעיבוד דאטה, ניתוח טקסט, יכולות AI, ML, NLP, ושירותים כדוגמת ניתוח כוונה (Intent), ניתוח סנטימנט, מילונים, ועוד שירותים שאיכותם עולה ביחס ישיר לכמות הדאטה הקיימת. במלים פשוטות, היכולות ה"מתקדמות" של מוצרי הפלטפורמות נמצאות בענן.
בישראל אנו נמצאים בעיכוב משמעותי באימוץ ענן ציבורי (מוערך בכ-4 שנים). שתי תעשיות עיקריות שנתקלות בחסם זה ודווקא הן מהוות מועמדות מצוינות להפקת ערך עסקי משמעותי מעולם הבוטים, הן תעשיית הרפואה, וחברות בתחום השירותים הפיננסים. כתוצאה מכך, הפרויקטים שאנו רואים כיום בתעשיות אלה בישראל הם או כאלה המוגבלים לתחום בו נושא הענן אינו מהותי (לדוגמה, הזמנת פגישה – ללא פרטים מזהים/בירור פרטים כלליים/קבלת מידע רוחבי שאינו רלוונטי לי כלקוח), או לחלופין הולכים למודל של יישום מקומי On premise. כתוצאה מהיישום המקומי, לא נהנים מהיתרונות הטכנולוגיים שנמצאים בענן. כך או כך, ארגונים מפסידים חלק ניכר מהיכולות הפונקציונאליות.

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

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

מה מעכב את תחום הבוטים בישראל?

רשמים מכנס re:Invent של AWS

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

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

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

מגמה מרכזית שהודגשה בכנס היא תחום ה- AI – Artificial Intelligence.  AWS הרחיבו באופן מהותי את הצעת הפתרונות שלהם בתחום בעיקר סביב machine learning ותשתית לבנייה של Bots. שירות ראשון בתחום זה הנו AWS Polly אשר מתרגם טקסט לדיבור אנושי ב-24 שפות (עברית לא נמצאת בין שפות אלו). שירות שני הוא Amazon Recognition אשר מנתח תמונה וחוזר עם פרמטרים מובנים כגון "האם מרכיב משקפיים", "האם גבר או אישה" "האם שמח" וכד'. שירות מהותי נוסף הוא Amazon Lex  וזהו שירות ניתוח טקסט – ה"מוח" שמבין מה המשמעות (לפי קונוטציה) ומקבל החלטה. זהו הרכיב החכם שנמצא מאחורי Amazon Alexa המותקן ב- Amazon Echo הרמקול החכם שמקשיב ומבצע פקודות.

כחלק ממגמת ה- AI הכריזה AWS גם על שירותי מחשוב חדשים המאפשרים ביצועים משופרים הנדרשים במיוחד לשלב הראשוני של "לימוד" האלגוריתמים של machine learning. מדובר על שימוש במעבדים גרפיים (GPU) ואפילו על תכנות חומרה באמצעות תכנות מעבדי FPGA.

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

המגמה השלישית שנזכיר כאן היא השקעה גדולה יותר של AWS לכיוון ארגוני ה- enterprise. סממן ראשון למגמה זו היא ההסכם האסטרטגי עם VMWARE. ארגון יוכל להעביר שרת בין סביבת ה- vSphere המותקנת אצלו לענן של VMWARE שנמצא ב- AWS. מדובר על הורדת מחסום גדול לצוותי התשתיות אשר יכולים לנצל את יכולות הענן ללא ביצוע שינוי בתשתית (שינוי טכנולוגיית hypervisor) וללא לימוד של טכנולוגיה חדשה  תוך ניצול מלא של ההשקעה הקיימת שלהם בהקשר של ידע ואף בהקשר של רישוי.

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

והדבר הכי משמעותי בהקשר זה הנם הפתרונות המאפשרים להעביר כמויות מידע גדולות מתוך ה- enterprise לענן. בכנס הוכרזה גרסה חדשה ובעלת קיבולת גדולה יותר של ה- AWS Snowball Edge – סוג של מזוודה שלתוכה מעתיקים מידע מתוך הארגון. ואז שולחים את המזוודה (המידע בה מוצפן) ל- AWS. פתרון שני בתחום זה הוא ה- AWS Snowmobile שהוא משאית ענקית המאפשרת העברה של 100 PETA  של מידע (בכדי לתת סדר גודל, אני מעריך שבישראל נמכר פחות שטח אחסון לארגוני enterprise בשנה!!).

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

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

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

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

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

– פיני כהן.

רשמים מכנס re:Invent של AWS

שינויים בכישורים, בהכשרות ובמבנה של מחלקת התפעול והתשתיות

 

  • כ"א בתחום התשתיות (אחסון, שרתים, תקשורת DC) יקטן בשיעור של 20%-25%
  • באופן יחסי צוות הסיסטם יגדל, צוות האחסון יקטן
  • על כל חברי הצוות להיות מנוסים בתכנות ולכן יש לגייס כ"א חדש ולהכשיר את כ"א קיים
  • צוות הענן יהיה חלק מצוות התשתיות הכללי

הדרישות העסקיות החדשות, המעבר לענן הציבורי והפרטי וההבשלה ההדרגתית של טכנולוגיות כגון ענן ציבורי, ענן פנימי, SDN, SDS, Containers-Docker ועוד, גורמות לשינוי מהותי בהתנהלות צוותי התשתיות והתפעול.

במסמך זה ננסה לתאר את השינויים שיתרחשו בגודל, במבנה ובכישורים הנדרשים בצוותי תשתיות ה- DC (Data Center):  אחסון, סיסטם ותקשורת DC.

הפוטנציאל של שימוש בענן פנימי \ אוטומציה הוא גדול עד לפקטור של פי 10. לדוגמא, חברת אינטרנט ציינה שלפני 10 שנים (עוד לפני וירטואליזציה\DEVOPS, כאשר עבדו עוד על solaris) זמן ההפעלה/הקמה של 100 שרתים לקח בסביבות 3 חודשים. כעת מבצעים זאת ב- 3 שעות! עם זאת, מספר האנשים בצוות התשתיות\תפעול לא ירד כי כעת מבצעים פי 10 יותר פעולות, כלומר הם מהווים enabler עסקי באופן יותר משמעותי.

אולם על אף הפקטור של פי 10 שהוזכר כאן, כאשר מדברים על ארגוני enterprise, נראה שכאשר מיישמים ענן פנימי אמור להיות פקטור של חסכון של כ- 20%  – 25% ממספר האנשים, כאשר:

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

מבחינת מבנה ארגוני ישנן מספר גישות:

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

גישה אחרת מדברת על שמירת המבנה של אחסון-סיסטם-תקשורת אך מעלה את הצורך להוספת גוף מנחה-מקשר גם בין גורמי התשתיות וגם בין הפיתוח לתשתיות, שניתן לכנותו גוף Devops או "תשתיות Devops- ענן". בתוך כל צוות ספציפי (לדוגמה אחסון) יהיו אנשים אשר יטפלו באחסון "הישן" ואחרים באחסון "החדש" (כלומר ב- SDS). אנשי ה"ענן" מתוך כל הצוותים יוגדרו כ- COE – center of excellence  או "חוליית ענן" ויימדדו על פי הצלחתם.

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

לדוגמה:

  • לבנות "חוליית תקלות" משותפת לצוותים אשר מטפלת בתקלות באופן מאוחד. כלומר, כאשר יש תקלה ב- DC תמיד מתכנסת "חוליית התקלות" ומטפלת ביחד- לא מטפלים בנפרד האחסון, הסיסטם והתקשורת.
  • לבנות "חוליית התקנות" אשר אחראית באופן משותף על התקנה של פרוייקטים חדשים.
  • לבנות "חוליית design" אשר אחראית באופן משותף על design של מערכות חדשות (ביצוע sizing לפרויקטים, הכוונה בטכנולוגיות וכד').
  • לבנות "חוליית בדיקות" אשר אחראית באופן משותף על בדיקות של מערכות שנכנסות לייצור.
  • במידה ויש מערכת גדולה במיוחד, לבנות "חוליית מערכת" אשר תהיה אחראית באופן משותף על המערכת.
  • לבנות "חוליית DR" אשר אחראית באופן משותף על נושא ה- DR ב- DC.

וכד'. כלומר יש להתייחס לאחסון-תקשורת DC וסיסטם באופן מאוחד.

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

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

שינויים בכישורים, בהכשרות ובמבנה של מחלקת התפעול והתשתיות

האם בוטים הם "הדבר הבא" ב- Customer engagement?

האם Bots הם "הדבר הבא" באינטראקציה עם לקוחות?

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

  1. העובדה שרובנו – כאנשים/צרכנים/עובדים/חברים/בני משפחה – התרגלנו לתקשר באמצעות פלטפורמות messaging. השימוש בפלטפורמות אלו גם כצרכנים אל מול ספקי השירות שלנו נראית טבעית ומתבקשת, בין אם מדובר בבנק, קופת החולים, משרד ממשלתי, הזמנת מוצר או קבלת מידע.
  2. התפתחויות טכנולוגיות בעולם הבינה המלאכותית (AI) ובתוכו בענפי ה- ML וה–NLP, הביאו לפריצת דרך באופן בו מערכות מסוגלות להבין דברים 'מורכבים', כמו טקסט חופשי, כוונה או רצון. אולם חשוב גם להדגיש כי במובן זה – ייקח כנראה עוד זמן עד שטכנולוגיות אלה יבשילו משמעותית לכדי אפשור שיחה "טבעית".
  3. עייפות החומר בכל הנוגע לאפליקציות מובייל. הנתון המטריד הוא שכיום הסיכוי שאתם תצליחו לשכנע את הלקוחות שלכם להוריד אפליקציה חדשה מאוד נמוך (65% ממשתמשים כלל אינם מורידים יותר אפליקציות חדשות, ורובנו עושים שימוש ב-5 אפליקציות בלבד מבין העשרות המותקנות לנו על המכשיר).

האם Bots הם ה"דבר הבא" ב-Engagement של ארגונים אל מול לקוחותיהם? האם הם יחליפו ערוצים קיימים אחרים? האם יהוו "שכבת על" מעל ערוצים אחרים (אולי כתחליף לאפליקציות המובייל בתצורתן העדכנית כיום)?

ומהם תחומי היישום הרלוונטיים ביותר ל- bots? האם ל-e-Commerce/ אספקת מידע/ שירות/ אחר?

פחות מעניין לדבר על בוטים, ויותר מעניין לדבר על פלטפורמות.

המעבר הוא אינו מ"אפליקציות" ל"בוטים". המעבר הוא ל"פלטפורמות" ולמקומות שהן לוקחות אותנו אליהן (בין פלטפורמות אלה ניתן למנות את אמאזון, פייסבוק, מיקרוסופט, IBM, SLACK, KIK, WECHAT, TELEGRAM וכו'). פלטפורמות הן אלה המרגילות אותנו לעבוד בתצורת עבודה מסוימת (מי היה מאמין שיום אחר נעדיף לתקשר באמצעות messaging יותר מאשר שיחות קוליות?) ואם כיום messaging הנה צורת ההתקשרות המועדפת, בעתיד כנראה שהממשק יהיה Voice ובהמשך… מי יודע?

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

כן, אבל…

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

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

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

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

bots-hype

מהם האתגרים הקיימים כיום בתחום הבוטים?

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

ברמת ה UX בוודאי שישנה בעיה (כאמור, בוטים לא אפקטיביים, לא חכמים מספיק, שלא מבינים INTENT ומתסכלים את הלקוח);

חוסר בשלות של טכנולוגיות בינה מלאכותית AI, ובתוך כך נושא ה NLP (עיבוד שפה) – במיוחד בעברית!

theissues with bots today.png

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

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

  1. תחילה, האפשרות לקיים אינטראקציות ש"מרגישות" יותר פרסונליות ושיחתיות (לדוגמה, נושא ה eCommerce או כפי שהוא מתחיל להיקרא: Conversational Commerce – הצרכן משוחח עם המותג/סטייליסט/יועץ שמכיר אותו ויודע מה להציע לו). מעבר לכך, כשאנחנו מתחברים לפלטפורמות שצרכנים חיים בה – יש לנו מראש כבר מידע בעל ערך על אותו הצרכן, שיכול לאפשר לנו להתאים את השיחה לאותו הצרכן – פרסונליזציה שמתאפשרת תיאורטית כבר מהרגע הראשון, עוד לפני שהתחלנו לצבור מידע.
  2. בוטים הם כלי אפקטיבי מאוד למיכון של משימות פשוטות שחוזרות על עצמן. כמובן שהתוצאה צריכה להיות אפקטיבית והמדד הטוב ביותר הוא מדד הזמן – האם חסכנו זמן ללקוח? מסתבר שלקוחות מאוד מעריכים חיסכון בזמן, ובזה בוטים מצטיינים. בוטים צריכים לאפשר ללקוחות To get stuff done, מהר ופשוט.
  3. באופן תיאורטי – האינטראקציות עשויות להפוך להיות יותר חכמות – וכאן צריך לסייג. כשאנחנו מחברים את נושא הבינה המלאכותית, ועושים שימוש בכל הדאטה שאנחנו צוברים כתוצאה מהרבה אינטראקציות, אנחנו בהחלט מצפים לראות את האינטראקציות משתפרות ולומדות מניסויי העבר. למה הסיוג? בגלל שטכנולוגיות AI/ML עדיין לא במאה אחוז מאפשרות לנו את זה, עם כל ההתפחות האדירה בתחום זה, יש עדיין דרך ארוכה.

אם לסכם את הערך שבוטים יכולים להביא לנושא חויית הלקוח, זה יצירת אותם Magic moments (שניסינו ליצור באמצעות אפליקציות מובייל) – להבין מתי הזמן הנכון שאותו הלקוח צריך אותנו? איך לתת לו מה שהוא צריך? לייצר עבורו חוייה שהיא מה שפורסטר קוראים Zero-friction במינימום מאמץ מצידו. המונח 'מינימום מאמץ' כל הזמן מוגדר מחדש, דוגמת פיצה דומינוס שהצליחה לצמצם מאמץ זה לכדי אימוג'י אחד בודד של פיצה!

 what-is-their-big-promise

אז מה עושים בינתיים?

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

איזה סוגי בוטים קיימים?

3 הסוגים העיקריים:

  1. אין ספק שהיישום העיקרי כיום הוא בעולם ה- eCommerce. הבוטים מסייעים לייצר ecommerce שיחתי, מונח אותו טבע כריס מסינה של UBER במאמר זה. אינסוף דוגמאות, החל מהזמנת מונית UBER, דרך הזמנת פרחים 1-800-flowers, ומשלוחי אוכל (הפיצות לגמרי נכבשו על ידי בוטים), הזמנת טיסות ומלונות ועוד…
  2. בוטים של תוכן/חדשות. דוגמאות: CNN, Business Insider, וה – New York Times שמספקת לכתבים את Bloosom – בוט שממליץ לכתבים על מאמרים בעלי סיכוי גבוה להפוך להיות ויראליים.
  3. בוטים שמספקים את מוצר/שירות החברה ב Zero-friction/ magic moment. כאן מדובר יותר על בוטים שהם transactional, שמספקים את מהות המוצר/שירות עצמם, שהחברה מציעה, תוך תמיכה ב WORKFLOW השלם, ב Zero-friction – מינימום מאמץ מצד הלקוח. קחו לדוגמה את בוט ה "magic moment" של KLM:

klm-bot

כמה חוקים לבניית בוטים טובים (תוך התחשבות ברמת בשלות השוק):

  • בוטים טובים חיים בתוך פלטפורמה מוכרת – לכו להיכן שהלקוח שלכם חי, והפלטפורמה המתאימה לסוג השירות שאתם מספקים
  • בוטים טובים הם קונטקסטואלים – מבוססי הקשר (ולזה צריך דאטה!!!)
  • בוטים טובים הם מאוד מאוד אפקטיביים. תחשבו איך אתם יכולים להקל על חיי הלקוח שלכם (חיסכון בזמן זו תועלת עצומה)
  • בוטים טובים מבנים דברים שאנשים בכל מקרה כבר עושים היום (חיפשו מטלות שחוזרות על עצמן, שניתן לייעל/לקצר/לשפר אותן)
  • בוטים טובים תפרו מראש את התהליך, ללא הרבה מקום לסטייה ממנו, כדי להימנע מנקודות החלטה (בהתחשב במצב בשלות השוק כרגע, זוהי נקודה מאוד חשובה)
  • בוטים טובים הנם בעלי "קצוות סגורים"
  • בוטים טובים מאוד ברורים לגבי המגבלות שלכם (אם אנשים ירגישו שהבוט שלכם יכול לדבר על כל נושא, האם ישאלו אותו כל שאלה)
  • בוטים טובים נבנים סביב רעיון ה Magic moment / Zero-Friction

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

TO GET STUFF DONE

 הבעיה עם בוטים בעברית

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

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

  1. הבוט הממוקד של בנק לאומי במסנג'ר, המסייע באיתור סניפים, עוזר להבין היכן הסניף הקרוב אליי, מהן שעות הפתיחה, ומהם השירותים המוצעים שם.
  2. הבוט של פרטנר למידע על חבילות הגלישה, המאפשר ללקוחות לדעת מה היקף חבילת הגלישה שהם צרכו עד כה, כמה נותר להם לגלוש בחבילה ומועד חידוש חבילת הגלישה, הבוט הנונ במסנג'ר, כאשר ניתן לעבור לנציג אנושי בכל עת.
  3. הבוט של – הזכיין של UPS בישראל, גם הוא במסנג'ר, המאפשר ללקוחות לקבל מידע ולשאול שאלות על שטר המטען שלהם.
  4. "הבוט של תותית" (חלק ממהלך שיווקי דיגיטלי) מבית חוגלה-קימברלי עבור מותג Kotex, המספק במסנג'ר מידע לקהל יעד ספציפי (במקרה הזה צעירות לקראת גיוס) דרך שיחה עם "תותית".
  5. הבוט של השף הלבן – המתאים לאנשים מתכונים לפי העדפות ותנאים שונים
  6. מה שמסתמן כתחום יישום פופלרי ביותר – גם בישראל יש כבר בוטים פועלים להזמנות משלוחי אוכל, כמו לדוגמה זה של Tictuk.

מה משותף לדוגמאות האלה? ממוקדים במשימה ספציפית ומתוחמת/קהל יעד ספציפי. עונה על צורך דומה של מספר רב של לקוחות (קבלת מידע על X, צריכת שירות Y – עם עדיפות למספר מוגבל/מוגדר מאוד של אפשרויות בחירה).

טיפים:

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

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

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

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

האם בוטים הם "הדבר הבא" ב- Customer engagement?

Blockchain – מה למה ואיך?

Internet of value הנו שם למהפכת אינטרנט חדשה. היום ניתן לקחת כל טרנזקציה או כל ערך אחר ולהעבירו בין האנשים במהירות של העברת המידע.  בנוסף, Internet of value מקדם את תפיסת האקוסיסטם (ecosystem) בו מתנהלים העסקים בעולם הדיגיטלי. הכוונה לקהילה של אנשים ועסקים, הפועלים יחד, ומרוויחים משיתוף הפעולה הרבה יותר, אילולא היו פועלים לבדם ובנפרד.  טכנולוגיית הבלוקצ'יין (Blockchain) תאפשר לעסקים ליצור ecosystem לעסקים, שם יוכלו חברים להחליף פריטים בעלי ערך באמצעות ספר חשבונות (ledger), בעל תוכן זהה ומסונכרן בין כולם, ואשר נמצא בבעלות של כל חבר.

Bitcoin

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

סאטושי נקאמוטו (Satoshi Nakamoto), ממציא מטבע ביטקוין, פרסם ב-2009 מאמר בשם "מערכת שיתופית לכסף אלקטרוני " (Bitcoin: A Peer-to-Peer Electronic Cash System ), המדבר על מערכת מרכזית של תשלומים מאדם לאדם ללא גורם מרכזי. יחד עם המאמר פורסם קוד לתוכנה אשר מהווה בסיס לרשת הבלוקצ'יין של ביטקוין.

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

Block and blockchain

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

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

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

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

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

מהו בלוקצ'יין

  • ארכיטקטורה מבוזרת עם תחנות המורכבות מחברים באקוסיסטם.
  • Shared ledger (בסיס נתונים מבוזר) המהווה מקור אמת אחד לכל מי שעושה טרנזקציות blockchain.
  • Smart contract הכולל נכס דיגיטלי (מוחשי או לא) וסט של כללים להעברת הנכס לבעליו החדש. חוזה חכם הנו חוזה אוטומטי, אוטונומי שלא ניתן לשינוי. לדוגמא חוזה גידור, בו יש הימור בין שני אנשים על ערך שער הדולר בתאריך 1/1/2017. מגדירים את התנאים של חוזה גידור ומטמיעים אותם בבלוקצ'יין. בתאריך 1/1/2017 בלוקצ'יין באופן אוטומטי, ואוטונומי, על פי התנאים שקבענו מראש אותם לא ניתן לשנות, יפנה לגורם חיצוני (אורקל) – שירות חיצוני הקובע מה שער הדולר באותו היום, החוזה יבדוק מה שער הדולר ויחלק את הכספים שהופקדו מראש למי שניצח בהתערבות.
  • קונצנזוס מבטיח כי shared ledger אכן מקור אמת אחד, מדויק וזהה לכולם. קונצנזוס, בין אם הוא בנוי על שיטת Proof of Work ובין אם הוא בנוי על שיטה אחרת (proof of stake), מבטיח כי כל הטרנזקציות הנכנסות ל shared ledger (ספר חשבונות ראשי) הן מוסכמות ע"י כולם, זהות בהעתקים של כולם, ללא גורם מתווך מרכזי כלשהו.

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

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

דוגמא לבלוקצ'יין של רכישת רכב:

  1. נכס בעל ערך (רכב) אותו ניתן להפוך לנכס דיגיטלי ע"י הצגת תעודת בעלות וזיהוי חד ערכי של הנכס (מספר שלדה של הרכב)
  2. Ecosystem – קונה, בנק, משרד התחבורה, חברת ביטוח, דלקן
  3. Ledger – data base או ספר חשבונות שקוף לכולם עם היסטוריה כרונולוגית של הרכב מתי נקנה, ע"י מי, מתי אושרה ההלוואה, ממתי הביטוח
  4. חוזה חכם – ברגע שקיבלתי את הבעלות על הרכב – נפתח אוטומטית חוזה ביטוח ובקשה להתקנת דלקן

למה בלוקצ'יין?

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

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

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

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

בלוקצ'יין פרטי

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

דוגמאות לבלוקצ'יין אחרים, מעבר לביטקוין:

·        סחר בינלאומי. חברת WAVE יישמה את שטר המטען על בלוקצ'יין –Wave | Bill of Lading with the BlockChain

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

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

אם היה קיים בלוקצ'יין המחבר בין יצרני הרכב לבין מפעלי החלקים לבין המוסכים ניתן היה להגיע בזמן קצר למפעל המבוקש ולקבל את החלק החליפי. בנוסף בעולם של Internet of things היה ניתן לראות ישר, כי לחלקים הספציפיים הללו (אשר נוצרו בתאריך X במפעל Y) קיימת בעיה ביצור ופתרון לבעיה הוא Z.  קיים חיבור טבעי בין blockchain, לענן, ול Internet of things.

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

היום כל אחד מנהל את המידע במערכות נפרדות ולא מחוברות.

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

Blockchain as a Service

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

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

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

IBM  מציעה שירות של garage blockchain (בישראל garage נייד), שם ניתן לנתח use case מתאים, לתרגמו למושגים של בלוקצ'יין, לעשות design thinking יחד עם המומחים, ולהריץ גרסה ראשונה של אפליקציה או פתרון של בלוקצ'יין על הענן של IBM.

אתגרים:

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

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

Privacy נושא רגיש בבלוקצ'יין. בבלוקצ'יין ארגוני, לדוגמא, יש המון שותפי צד שלישי, כיצד דואגים שספק א' לא יהיה חשוף לתנאי ההתקשרות בין הארגון לספק ב'? כיצד רואים ב shared ledger  רק דברים שלי מותר לראות?

ולסיכום

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

Blockchain – מה למה ואיך?

מהי ארכיטקטורת הדאטה של תחום השיווק וחויית לקוח?

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

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

דוגמא אחת נהדרת לארכיטקטורה כזו, בעלת 5 שלבים:

Data architecture

מקור: ChiefMarTech

ארכיטקטורה זו מכילה 5 רכיבים שהם מהווים גם 5 שלבים:

  1. Backbone: זוהי תשתית הנתונים. השלב בו אנו אוספים ואוגרים נתונים (בין אם פנימיים או חיצוניים, מובנים או לא מובנים). יש כאן מספר שינויים עליהם נדבר בהמשך, החשוב שבהם הוא שמקורות המידע ילכו ויתרבו כל הזמן, חלקם לא ישבו פיזית אצלנו, ואנחנו צריכים לפעול כדי לנהל אותם וירטואלית בצורה מרכזית ולחבר אותם חיבורים לוגיים (לאו דווקא פיזיים) לישות אחת כדי להבין יותר טוב את חויית הלקוח הרציפה.
  2. Discover: השלב האנליטי בו אנחנו מייצרים מודלים אנליטיים, עושים סגמנטציות, עושים פרדיקטיב, דיגיטל אנליטיקס וכד'.
  3. Delivery: החלק של קבלת החלטה או "איך הנתונים משפיעים על קבלת ההחלטות בפועל" – ה SHARE של הנתונים בארגון, חשיפה שלהם, שילוב התובנות בתהליכי קבלת החלטות, תכנון מסעות הלקוח… "ניהול התובנות" וגם governance.
  4. Activation: החלק התפעולי – הוצאה לפועל של תהליכים המושפעים מהתובנות – לדוגמה קמפיינים שמערכות מרקטינג אוטומיישן מפעילות, אותם ניסיונות של AB testing שמועלים לאוויר….
  5. Automation: כשעושים "SCALE" לאותם טסטים, עוברים לשלב הסיסטמתי.

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

מהם השינויים בשכבת ה Backbone, שכבת איסוף וארגון הנתונים?

DW

הדבר הראשון הוא ההבנה שה- Data Warehouse הוא לא מענה מספק עבור הבנת חויית הלקוח, הוא מספק רק חלק מהתמונה, וזה נובע מכמה סיבות:

  • בתחום השיווק / חויית לקוח מתבקשת גישה "חקרנית" (Exploratory) לנתונים. ה- DW הקלאסי נבנה סביב סכימות דאטה מתוכננות היטב שבאות לספק מענה לחקר מבוסס שאילתות 'ידועות מראש'. כאן לא מדובר על שאילתות, אפשר להקביל את זה יותר ל"נבירה" בדאטה כדי למצוא דברים מעניינים, תובנות שעולות, קורלציות, קשרים שלא חשבנו שקיימים.
  • עבור צרכי השיווק (חלק מהם) לעתים המידע הגולמי עדיף ממידע מסוכם ואגרגטיבי.
  • אג'יליות ו Time to market הם קריטיים. DW הוא עדיין תהליך Batchy, והוספת נתונים נוספים אליו לוקחים זמן בשל הצורך לחבר לסכימות המידע.

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

מהם DMPs וכיצד הם מהווים חלק מארכיטקטורת הדאטה שלנו?

ה- DMPs (Data Management Platforms) הם סוג של DW שנבנה ספציפית לטובת ניהול נתוני "אנשים" (לא מזוהים / IPs) – בעיקר cookies, לבנות ממידע זה קהלים, לייצר סגמנטים, וגם להפיץ מסרים לאותם הקהלים תוך הפצתם לגופי מדיה ו DSPs שונים.

DMP

מקור: Yashi.

אותם DMPs מכילים 3 סוגי מידע:

1st Party Data: מידע בבעלותו של הארגון: CRM, DW, מערכות ליבה, נקודות המכירה, וגם מידע מה Owned media, מהאתר, אימיילים, מובייל…. לחברות בתחום B2C הכי קל להתחיל לשפוך מידע זה לתוך DMPs ולהתחיל ליצור קהלים מתוך מידע זה (ה"לבנה" הראשונה). עוד לפני הוספת מידע חיצוני על קהלים נוספים, ניתן לטרגט לקוחות עם מאפיינים שונים בהתבסס על הדאטה שכבר יש לנו.

2nd Party Data: מידע שאנו מקבלים מחברה אחרת, שמהווה שותפת-מידע שלנו (לדוגמה, אם אני חברת אשראי אני יכולה לחבור לרשת שיווק ולעשות שימוש, בהסכמת הלקוחות שלה, במידע הנצבר על לקוחותיה ממועדון הנאמנות שלה). יש כאן בעצם שימוש שלי ב 1st party data של חברה אחרת. כאן ניתן לטרגט ולהגיע לקהלים נוספים בעלי מאפיינים דומים ללקוחות הטובים שלי, ולבצע שילובים מעניין בין 1st party ל 2nd party כמו לדוגמה, להציג את המסר השיווקי ללקוחות שעונים על קריטריונים מסוימים, ובתנאי שהם לא לקוחות כבר של השירות הזה).

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

מימד נוסף בארכיטקטורת הדאטה שלנו הודות להתפתחות תחום ה-IoT והמידע הסנסוריאלי:

Context is King!

טשטוש הגבולות בין העולמות הפיזיים והדיגיטליים כבר מתרחש כיום, הרבה בזכות Internet of things. אינטרנט כבר חיבר בין האנשים, כעת הוא מחבר גם בין מכשירים ודברים שונים, והרבה מהם! יש לזה משמעות עצומה על חיי היום-יום שלנו, על התארגנות ארגונית ועל מאקרו כלכלה בכלל. מגזין "כלכלה דיגיטלית" (אשר הקדיש מהדורה שלמה רק לנושא אינטרנט של הדברים) ציין כי בתקופה הקרובה יצאו לשוק בין 3 ל-5 מיליארד "צרכנים חדשים", אותם נצטרך לשדרג, לתמוך,  להתקין ולתת להם שירות, אשר לא היו קיימים קודם לכן.

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

לחוויה דיגיטאלית כזאת, מתמשכת וכזאת המטשטשת גבולות במעברים בין מכשירים, מקומות ורגעים שונים במסע הלקוח, קוראים Ambient computing. מדובר בשירות מדויק המבוסס על הפעילות הפרסונלית וההעדפות האישיות של האדם. Internet of things יחבר בין נתונים ו"דברים" ויספק ניתוח מידע ותובנות בזמן אמת, וזה ירגיש מאוד מאוד טבעי ומתבקש.

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

לעתים, אותו מידע סנסוריאלי, הוא בדיוק ה"חוליה החסרה" בהבנה של הצורך/ההקשר או במלים אחרות ה “Magic moment” בו נוכל לספק ערך ממשי עבור הלקוחות שלנו.

 

 

 

מהי ארכיטקטורת הדאטה של תחום השיווק וחויית לקוח?