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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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