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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Power Apps מעניקות לצוותים ספציפיים דרך ממוקדת להשתתף בתהליך. Dataverse שומר על המידע העסקי מאורגן ומאובטח בזמן שהכלים האלו מבצעים את עבודתם. להבדל הזה יש חשיבות. אוטומציה היא לא מערכת תיוק, ולוח מכוונים הוא לא מסד נתונים של לקוחות. לכל כלי יש תפקיד נפרד, אך כולם יכולים לעבוד מאותו מקור נתונים. ההבנה הזו עוזרת לבחור את הכלי הנכון, במקום להתייחס לכל גיליון אלקטרוני או רשימה כאל כלי לניהול תהליך עסקי שלם. מתי Dataverse מתאים ומה הוא אינו מחליף? הנה העניין. בחרו בדטאברס כאשר אנשים ויישומים מרובים צריכים לעבוד עם נתונים עסקיים מקושרים. אתם זקוקים לכללי גישה ברורים ותהליכים הניתנים לשכפול. Dataverse מטפל בכך, אך הוא לא מחליף את כל השאר. אקסל הוא עדיין הבחירה המועדפת לניתוח אישי ולרשימות מהירות. רשימות SharePoint עובדות היטב עבור מעקב צוותי פשוט. ואם אתם מפתחים הזקוקים לשליטה מעמיקה, SQL נותר בחירה חזקה. אז, מתי Dataverse באמת מתאים? כשהנתונים שלכם צריכים להתחבר בין יישומי Dynamics 365, אוטומציות ודוחות מבלי ליצור העתק נוסף.

זה המקום שבו הוא מבריד. אבל, לסיכום, יסוד אחד, כלים עסקיים רבים. אז, זו השורה התחתונה. Dynamics 365 וDataverse עובדים בצורה הטובה ביותר כשכל הנתונים, הכללים, ההבטחה, היישומים, האוטומציות והדוחות שלכם חולקים בסיס משותף. הרשמו למיקרוסופט Knowledge Nuggets ב-M365.fm לקבלת מדריכים בשפה פשוטה על Dynamics 365, Power Platform ומיקרוסופט 365. לאחר מכן צפו בפרק שלנו על יישומים מונחי מודל כדי לראות איך תבלעות Dataverse הופכות ליישום עסקי עובד.