top of page

פורטל ידע

דרוויניזם דיגיטלי

 

מאת: רמי גור, מנהל Matrix Digital


 



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


משבר הקורונה יצר חוק הישרדות כלכלי חדש של "דרוויניזם דיגיטלי" – הארגונים השורדים הם הארגונים שיש להם את היכולת להשתנות מבחינה דיגיטלית, ולהתאים את עצמם לסביבה המשתנה, ובמיוחד לצרכים המשתנים של הלקוחות. והתוצאות: גידול של 200% במכירות אונליין, האצה של 10 שנים ב-eCommerce ב-30 יום (STKI, 2021) וארגונים עם למעלה מ-55% תוספת למוצרים הדיגיטליים שלהם. כיום, שנה וחצי אחרי ההתפרצות הראשונה של הקורונה, רוב הארגונים מחזיקים כבר במערך דיגיטל, שכולל יותר מנכס אחד, ועל מנת לשמר יתרון תחרותי, הם צריכים לטפס לשלב הבא באבולוציה.

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


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


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


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


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


2) החלטתם לפתח אפליקציה לענן, אבל אתם לא רוצים להגביל את עצמכם לספק אחד? השתמשו בארכיטקטורה אגנוסטית (Cloud Agnostic) שתאפשר לכם לפעול על גבי כל ענן ציבורי עם מינימום שינויים


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

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


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

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

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

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

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


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


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


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


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


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

Comments


bottom of page