הפיכתה של קבוצת Business Applications לדיגיטלית

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

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

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

זרמי עבודה וסוגי אישיות

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

התמונה הבאה ממחישה כיצד 35 יישומים מעוצבים בחמשת זרמי עבודה אלה.

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

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

תרחיש פיתוח מוצרים

1. Microsoft מעורב ומקיים אינטראקציה עם הלקוח. בזרם העבודה של לקוחות ושותפים קיימות אפליקציות רבות, למשל מעורבות לקוחות, מעורבות ניהולית, אפליקציות FastTrack ו- Power CAT. כל אחד מאלה מתמקד באישיות ספציפית.
2. Microsoft אוסף משוב מלקוחות. בזרמי העבודה 'לקוחות ושותפים' ו'קהילה' קיימות אפליקציות רבות, למשל, רעיונות, Pulse, ופעימה (עבור FastTrack).
3. ניתן לצבור ולתעדף משוב ובקשות באמצעות אפליקציית המשוב Fusion/One בזרם העבודה ProductOps.
4. יישם את המשוב והבקשות של התכונה באמצעות אפליקציות תכנון בזרם העבודה ProductOps.
5. הכרז ללקוחות על התוכנית באמצעות תוכנית ההפצה בביקורות המנהליות של זרם העבודה ProductOps. הדבר נעשה אוטומטית בפורטל התשתית, המהווה חלק מזרם העבודה BusinessOps.

תרחיש יכולת תמיכה

1. לקוח יוצר בקשת תמיכה. הדבר נעשה באמצעות חלק D4M של זרם העבודה של DevOps.
2. מהנדס בודק את האירוע כדי למנוע אירועים עתידיים. זה נעשה באמצעות אפליקציית סקירת האירועים, שהיא חלק מזרם העבודה של DevOps.
3. צוות המוצר מתכנן לבצע את העבודה. זה נעשה באמצעות אפליקציית תכנון המוצר בזרם העבודה של Product Ops.
4. סגור את הלולאה עם לקוחות שנתקלים בבעיה בשימוש באפליקציות שבזרם העבודה 'לקוחות ושותפים'.
5. סגור את הלולאה עם לקוחות ששלחו את המשוב באמצעות שימוש באפליקציות שבזרם העבודה 'לקוחות ושותפים'.

מודל פיתוח משותף של מרכז ההצלחה

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

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

1. יישור טווח: סקירת חוויית משתמש ברמה גבוהה ושינויים בסכימה.
2. עדכון Microsoft Azure DevOps: הוסף תכונה וסיפורי משתמש ועדכן אותם באמצעות שינויים בסכימה.
3. אישור שותף: הודעת אישור נשלחה בדואר האלקטרוני לבעלי העניין המושפעים.
4. הסכמת הפניה של זרם עבודה: מתן הסכמה לשינויים שעל-ידי ההפניות של זרם העבודה.
5. שינויים שנפרסו: PR בוחנים ומאמתים שינויי סכימה ופריטי עבודה.

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

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

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

• שינויים בטבלה משותפת: אלה הם משני סוגים:

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

פריסה ואתר פועל

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

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

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

• מודל של ניהול מחזור חיי אפליקציה (ALM), המורכב מהרכיבים הבאים:
  • סביבת פיתוח (לכל אפליקציה)
  • סביבת בדיקה (סביבה יחידה)
  • סביבת בדיקה של קבלת משתמש (UAT) (סביבה יחידה)
  • סביבת ייצור (סביבה יחידה)
  • סביבת הוכחת רעיון לבחינת האפליקציות בידי הצוותים
• צינורות הבנייה והשחרור מנוהלים באמצעות Azure DevOps על ידי שימוש ב- Power Platform‏ Build Tools.
• סביבות פיתוח ובדיקה מתרעננות בכל שבוע באופן אוטומטי באמצעות בנייה שבועית.
• בדיקות אוטומטיות מופעלות בסביבות בדיקה ובסביבות UAT. הדבר עוזר להבטיח פיתוח משותף חלק יותר.
• כל אפליקציה היא פתרון ונמצאת בתהליך הפיכה לפתרון מנוהל.

שילוב אבטחה ותאימות

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

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

שילוב עם מקורות נתונים אחרים

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

• Microsoft נתוני לקוחות, מכירות ושותפים (לדוגמה, Microsoft ניסיון במכירות, שירותי מחזור חיים, שירות לקוחות)
• DevOps ויכולת שירות (Azure DevOps וניהול אירועים של IcM, לדוגמה)
• היררכיית ארגון ופרופילי משתמשים (Microsoft Entra ו Microsoft גרף)

ערוצי תמיכה ותחזוקה

הערוצים הבאים מאפשרים פיתוח, תמיכה ותחזוקה של כל אפליקציה:

• Wiki, הדרכה ושעות עבודה שבועיות עבור שאלות
• תחזוקה (התראות ומעקב) הנעשית על-ידי צוות יחיד (זרם עבודה Microsoft Power Platform)
• לוח מחוונים של מדידת שימוש למעקב אחר מדדי ביצועים ותקינות