WEBVTT

00:00:00.000 --> 00:00:02.040
איש מחירות מעדכן כתובת של לקוח.

00:00:02.200 --> 00:00:05.940
מאוחר יותר, מחלקת הכספים פותחת את אותו הרשומה ועדיין רואה את הכתובת הישנה.

00:00:06.060 --> 00:00:07.260
אז איזו כתובת היא הנכונה?

00:00:07.440 --> 00:00:09.700
במשך שנים, תיקון כזה דרש ממי שהוא לייצא נתונים,

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

00:00:13.360 --> 00:00:15.860
דיינמיקס 365 דול רייט משנה זאת.

00:00:16.000 --> 00:00:19.740
הוא מחבר בין אפליקציות כספים ותפעול לבין אפליקציות לקוחות מבוססות דייטוורס,

00:00:19.740 --> 00:00:23.160
כך שרשומות משותפות כמו לקוחות והזמנות נשארות מסונקרנות אוטומטית.

00:00:23.240 --> 00:00:26.260
אתם איתי, אני מלכו פיטרס מ-M365FM,

00:00:26.480 --> 00:00:28.960
ופיסת הידע הזו מסבירה את דול רייט בשפה פשוטה.

00:00:29.080 --> 00:00:33.240
אנחנו נחסה מה עובר, איך זה עובר, איפה דול רייט מתאים ואיפה הוא לא מתאים.

00:00:33.400 --> 00:00:37.060
ראשית, בואו נתחיל עם הבעיה העסקית שיצרה את הצורך בזה.

00:00:38.420 --> 00:00:40.140
הבעיה שדואל רייט פותר

00:00:40.140 --> 00:00:43.240
דמיינו עסק שבו שתי קבוצות עובדות על אותו לקוח,

00:00:43.380 --> 00:00:45.640
אבל משתמשות באפליקציות שונות לחלוטין ביומיום.

00:00:45.820 --> 00:00:48.740
אפליקציות כספים ותפעול מטפלות בעבודה של המשרד האחורי.

00:00:48.880 --> 00:00:52.300
זה כולל כסף, מלאי, מוצרים, הזמנות, רכש ושרשרת ההספקה.

00:00:52.400 --> 00:00:55.200
כאן חברה עוקבת אחרי מה שהיא מוכרת, מה שהיא יכולה לספק,

00:00:55.400 --> 00:00:57.120
מה שהיא חייבת ומה שלקוח צריך לשלם.

00:00:57.120 --> 00:00:59.920
אפליקציות לקוחות מתמקדות בעבודה קרובה יותר ללקוח.

00:00:59.920 --> 00:01:02.480
צוותי מחירות עוקבים אחרי לידים ובונים הזדמנויות.

00:01:02.680 --> 00:01:04.760
שירות לקוחות מטפל בשאלות ובפניות.

00:01:05.000 --> 00:01:07.500
שירות שטח מתכנן עבודות ושולח אנשים לאתרים.

00:01:07.700 --> 00:01:10.200
צוותי פרויקטים עוקבים אחרי עבודה שהובטחה ללקוח.

00:01:10.360 --> 00:01:12.080
עבודה שונה דורשת מסכים שונים.

00:01:12.320 --> 00:01:16.640
איש מחירות לא אמור לחטט במסך כספים רק כדי לעדכן איש קשר אחרי שיחה.

00:01:16.640 --> 00:01:21.360
אבל משתמש כספים צריך פרטי לקוח והזמנה שטועמים למה שהמחירות רואות

00:01:21.360 --> 00:01:23.760
כחשבוניות ומשלוחים תלויים במידע הזה.

00:01:23.920 --> 00:01:27.040
ללא חיבור, לקוח אחד הופך בשקט לשתי רשומות.

00:01:27.160 --> 00:01:29.220
המחירות עשויות לרשום את Northwind Bikes.

00:01:29.440 --> 00:01:31.800
הכספים עשויים לרשום את Northwind Bicycle Company.

00:01:31.940 --> 00:01:34.080
או רשומה אחת כוללת את כתובת הרחוב החדשה.

00:01:34.280 --> 00:01:36.260
השנייה עדיין שולחת חשבוניות למשרד הישן.

00:01:36.460 --> 00:01:38.340
שתי הרשומות נראות סבירות כשלעצמן,

00:01:38.340 --> 00:01:40.780
אך הן כבר לא מתארות את אותה מערכת יחסים עסקית.

00:01:40.940 --> 00:01:42.400
בעיות קטנות צצות תחילה.

00:01:42.520 --> 00:01:45.640
מי שהוא לא מצליח למצוא לקוח כי השם שונה באפליקציה אחרת.

00:01:45.640 --> 00:01:48.080
נציג מחירות מבטיח מחיר או בודק מלאי,

00:01:48.260 --> 00:01:49.980
אבל המידע לא תואם לצד התפעולי.

00:01:50.080 --> 00:01:51.580
הכספים צריכים לאבד הזמנה,

00:01:51.760 --> 00:01:54.800
אבל פרטי הלקוח דורשים בדיקה, מייל ועדכון ידני נוסף.

00:01:54.900 --> 00:01:56.760
ואז הבעיות הקטנות האלה נערמות.

00:01:56.900 --> 00:01:59.240
מי שהוא מייצא נתוני לקוחות לגיליון אלקטרוני.

00:01:59.240 --> 00:02:02.180
אדם אחר מתקן כמה שורות ומייבא את זה למקום אחר.

00:02:02.300 --> 00:02:04.600
מי שהוא אחר מזין לקוח חדש בשתי האפליקציות

00:02:04.600 --> 00:02:06.540
כי אף אחד לא יודע איזו רשומה תופיע קודם.

00:02:06.540 --> 00:02:08.380
בקרוב יש כפילויות, כתובות שונות,

00:02:08.480 --> 00:02:11.120
ויותר זמן מבוזבז על בדיקת נתונים מאשר על שימוש בהם.

00:02:11.240 --> 00:02:13.420
שום דבר מזה לא קורה בגלל שאנשים לא זהירים.

00:02:13.560 --> 00:02:16.140
זה קורה בגלל שהמערכות מבקשות מאנשים להיות החוליה המקשרת.

00:02:16.240 --> 00:02:17.300
אנשים מעתיקים נתונים.

00:02:17.520 --> 00:02:19.440
אנשים צריכים לזכור איזו אפליקציה מגיעה קודם.

00:02:19.440 --> 00:02:22.040
אנשים מוצאים טעויות אחרי שהן כבר הגיעו לצוות אחר.

00:02:22.140 --> 00:02:25.840
הגישה הזו עבדה כשמערכות עסקיות נשארו נפרדות וצוותים קיבלו עיכובים.

00:02:25.840 --> 00:02:30.160
אבל כשמחירות, שירות, כספים ותפעול צריכים את אותו מידע לקוח במהלך היום,

00:02:30.380 --> 00:02:32.380
גיליון אלקטרוני הופך לכלי העברה גרוע.

00:02:32.540 --> 00:02:34.140
חישבו על שיחת הזמנה פשוטה.

00:02:34.300 --> 00:02:37.340
לקוח מתקשר למחירות ושואל איך תוכלו לספק בשבוע הבא.

00:02:37.480 --> 00:02:38.260
וכמה זה יעלה?

00:02:38.520 --> 00:02:39.060
גרשיים.

00:02:39.060 --> 00:02:42.580
צוות המחירות זקוק לפרטי מוצר, מחיר ומלאי כדי לענות.

00:02:42.740 --> 00:02:48.200
ברגע שהלקוח מסכים, הכספים והתפעול זקוקים למידע הנכון על הלקוח וההזמנה כדי לאבד את המחירה.

00:02:48.200 --> 00:02:50.020
שני הצדדים צריכים את אותן עובדות.

00:02:50.180 --> 00:02:53.340
המחירות צריכות את העובדות האלו באפליקציה שבה אנשי המחירות עובדים.

00:02:53.500 --> 00:02:57.820
הכספים והתפעול צריכים אותן באפליקציה שבה הם מנהלים הזמנות, כסף ומשלוחים.

00:02:57.980 --> 00:03:00.920
המטרה היא לא לנסות לכפות על כל צוות מסך ענק אחד.

00:03:00.920 --> 00:03:04.580
המטרה היא שרשומות משותפות יעקבו אחרי מסלול ברור ומוסכם.

00:03:04.680 --> 00:03:07.420
כאן נכנסת לתמונה הכתיבה הכפולה, Do Right.

00:03:08.000 --> 00:03:09.740
אז מה היא בעצם כתיבה כפולה?

00:03:10.120 --> 00:03:11.860
הנה ההגדרה הפשוטה ביותר.

00:03:11.860 --> 00:03:19.500
כתיבה כפולה היא חיבור מובנה של מייקרוסופט ששומר על נתונים נבחרים מסונקרנים בין אפליקציות Dynamics 365 Finance and Operations לבין DataVars.

00:03:19.660 --> 00:03:23.460
DataVars הוא בסיס הנתונים המשותף מאחורי אפליקציות עסקיות רבות של מייקרוסופט.

00:03:23.460 --> 00:03:28.300
Dynamics 365 Sales, Customer Service, Field Service וחלקים מפרויקט אופרישונס משתמשים בו כולם.

00:03:28.460 --> 00:03:30.900
גם Power Apps וPower Automate יכולים להשתמש בו.

00:03:31.000 --> 00:03:34.420
אתם לא צריכים לדעת איך DataVars מאחסן כל רשומה כדי להבין כתיבה כפולה.

00:03:34.420 --> 00:03:38.560
פשוט תחשבו על זה כאזור הנתונים המשותף בצד אפליקציות הלקוח של Dynamics 365.

00:03:39.060 --> 00:03:41.840
דמיינו בניין משרדים עם משרד קדמי ומשרד אחורי.

00:03:41.980 --> 00:03:44.380
המשרד הקדמי מטפל בשיחות עם לקוחות.

00:03:44.520 --> 00:03:47.240
אנשי מחירות, נציגי שירות, עובדי שטח.

00:03:47.240 --> 00:03:51.920
כולם זקוקים למסקים שעוזרים להם לדבר עם אנשים, לעקוב אחר בקשות ולנהל את העבודה.

00:03:52.060 --> 00:03:54.960
המשרד האחורי מטפל בעבודה ששומרת על פעילות החברה.

00:03:55.040 --> 00:03:58.540
הרשומות הפיננסיות שלנו, מלאי, הזמנות, רכש, משלוחים.

00:03:58.540 --> 00:04:04.300
שני המשרדים עובדים עבור אותה חברה, אבל ללא חיבור תקין ביניהם מי שהוא צריך להעביר מידע מצד אחד לשני.

00:04:04.460 --> 00:04:08.240
הם נושאים תופס מודפס, שולחים אימייל או מעתיקים נתונים למערכת אחרת.

00:04:08.360 --> 00:04:12.220
העבודה עדיין מתבצעת, אבל זה לוקח יותר זמן ופרטים יכולים להשתנות בדרך.

00:04:12.220 --> 00:04:15.700
כתיבה כפולה היא כמו דלת פנימית מאוישת בין שני המשרדים האלו.

00:04:15.800 --> 00:04:20.620
כאשר רשומה נתמכת משתנה בצד אחד, כתיבה כפולה מעבירה את השינוי הקשור דרך אותה דלת לצד השני.

00:04:20.760 --> 00:04:23.020
זה לא משלב כל אפליקציה לאפליקציה אחת ענקית.

00:04:23.180 --> 00:04:24.900
המחירות עדיין יכולות לעבוד במחירות.

00:04:25.060 --> 00:04:26.780
הכספים עדיין יכולים לעבוד בכספים.

00:04:26.940 --> 00:04:28.820
כל צוות שומר על המסקים שנבנו עבור עבודתו.

00:04:29.000 --> 00:04:31.120
בעוד מידע משותף נבחר נשאר מחובר מאחורי הקלעים.

00:04:31.260 --> 00:04:32.800
המילה, נתמך, היא קריטית.

00:04:32.800 --> 00:04:36.440
כתיבה כפולה, Dual Write, לא מעתיקה בעברון כל פיסת מידע לשתי המערכות.

00:04:36.520 --> 00:04:39.620
היא עובדת באמצעות חיבורים מוגדרים בין רשומות ששייכות יחד.

00:04:39.620 --> 00:04:42.480
מייקרוסופט מכנה את החיבורים האלה, מיפויי טבלאות.

00:04:42.640 --> 00:04:45.660
טבלאה היא פשוט מקום שבו אפליקציה שומרת סוג אחד של רשומה.

00:04:45.760 --> 00:04:47.640
טבלת לקוחות שומרת רשומות של לקוחות.

00:04:47.800 --> 00:04:49.680
טבלת מוצרים שומרת רשומות של מוצרים.

00:04:49.860 --> 00:04:51.660
טבלת כתובות שומרת פרטי כתובת.

00:04:51.660 --> 00:04:56.860
מיפוי טבלאות אומר ל-Dual Write איזו טבלאה בצד הפיננסי והתפעולים מתחברת לאיזו טבלאה בדטאברס.

00:04:56.980 --> 00:04:59.340
חישבו על מיפוי טבלאה כעל דף תרגום מוסכם.

00:04:59.500 --> 00:05:01.560
עמודה אחת מזהה רשומה בצד אחד.

00:05:01.720 --> 00:05:04.600
עמודה אחרת מזהה את הרשומה התואמת שלה בצד השני.

00:05:04.800 --> 00:05:07.420
שאר הגיליון מסביר אילו שדות שייכים זה לזה.

00:05:07.620 --> 00:05:09.840
שם, מספר טלפון, שורת כתובת.

00:05:09.960 --> 00:05:11.900
ההסכם הזה מספק את כללי החיבור.

00:05:11.940 --> 00:05:15.860
בלעדיו, שתי אפליקציות עלולות להשתמש בתוויות שונות או להכסן את אותו פרט במקומות שונים.

00:05:16.020 --> 00:05:18.560
מיפוי אומר ל-Dual Write כיצד הפרטים הללו קשורים.

00:05:18.680 --> 00:05:21.560
כך, האפליקציות לא צריכות אדם שיפרש אותן בכל פעם מחדש.

00:05:21.560 --> 00:05:26.540
ובכן, אנשים לעיתים קרובות שומעים את השם Dual Write ומניחים שזה אומר שכל שינוי תמיד עובר לשני הכיוונים.

00:05:26.700 --> 00:05:27.620
לפעמים זה נכון.

00:05:27.820 --> 00:05:32.480
עבור מיפוי דו-כיווני נתמך, שינוי בדטאברס יכול להדכן את הרשומה הקשורה ב-Finance and Operations.

00:05:32.780 --> 00:05:36.680
שינוי נתמך ב-Finance and Operations יכול גם להדכן את הרשומה הקשורה בדטאברס.

00:05:36.840 --> 00:05:39.480
שני הצדדים יכולים לקחת חלק באותה רשומה משותפת.

00:05:39.540 --> 00:05:41.020
זהו החלק הכפול, Dual.

00:05:41.180 --> 00:05:42.880
העדכון מתרחש כמעט בזמן אמת.

00:05:42.880 --> 00:05:47.080
זה נע במהירות תוך כדי עבודה, במקום לחכות לעבודה המתוזמנת שרצה במהלך הלילה.

00:05:47.180 --> 00:05:52.320
משתמש מעד כן רשומה נתמכת, והחיבור שולח את העדכון הזה בזמן שהעבודה עדיין רלוונטית.

00:05:52.400 --> 00:05:55.060
כמעט זמן אמת לא אומר קסם או אפס עיכוב.

00:05:55.220 --> 00:05:59.060
זה אומר שהחיבור בנוי לעבודה עסקית חיה, לא להחלפת קבצים פעם ביום.

00:05:59.240 --> 00:06:03.080
אם מישהו משנה פרט, הצוות הקשור לא צריך לחכות עד מחר בבוקר כדי לראות זו.

00:06:03.200 --> 00:06:05.120
זה משנה את הדרך שבה צוותים יכולים לעבוד.

00:06:05.120 --> 00:06:07.980
החזית העסקית יכולה להשתמש בנתונים שמגיעים מהמערך התפעולי.

00:06:08.060 --> 00:06:11.120
המערך התפעולי יכול לקבל עדכונים נתמכים מאפליקציות מול לקוחות.

00:06:11.260 --> 00:06:15.860
Dataverse הופכת לבסיס הנתונים בצד אחד, Finance and Operations נשארת הבסיס התפעולי בצד השני,

00:06:16.080 --> 00:06:18.700
ודואל רייט שומרת על הרשומות המשותפות המאושרות מחוברות.

00:06:18.840 --> 00:06:21.360
ובכל זאת, דלת פנימית חיה זקוקה לכללים.

00:06:21.540 --> 00:06:27.260
לפני שנותנים לרשומה לנוע בשני הכיוונים, צריך לדעת איפה הרשומה הזו אמורה להתחיל, מי רשאי לשנות אותה,

00:06:35.120 --> 00:06:39.440
המחוברות. הדוגמאות הנפוצות מתחילות ברשומות שמחלקות רבות משתפות מדי יום.

00:06:39.600 --> 00:06:46.860
רשומות לקוחות, כתובות, אנשי קשר, מוצרים, ספקים, פרטי חברה ומידע עזר המשמש לכשפים ולמיסים.

00:06:47.160 --> 00:06:48.940
חישבו לרגע על רשומת לקוח.

00:06:49.140 --> 00:06:54.040
אנשי המחירות צריכים את שם הלקוח, איש הקשר הראשי, מספר טלפון וכתובת למשלוח.

00:06:54.240 --> 00:06:59.120
צוות הכשפים צריך את רשומת הלקוח המשפטית, פרטי חיוב ומידע הדרוש להזמנות וחשבוניות.

00:06:59.120 --> 00:07:04.700
אם כל מחלקה מנהלת רשימת לקוחות נפרדת משלה, החברה מבזבזת זמן בהשוואת רשומות במקום בשירות הלקוח.

00:07:04.860 --> 00:07:08.920
עם ניפויי דול רייט הנכונים, הצוותים האלה יכולים לעבוד על בסיס פרטי לקוח מקושרים.

00:07:09.120 --> 00:07:12.280
זה לא אומר שמשתמשי המחירות צריכים פתאום ללמוד את אפליקציית הכשפים.

00:07:12.480 --> 00:07:16.120
זה אומר שהם יכולים לעבוד עם פרטי הלקוח בדיינמיקס 365 סיילס.

00:07:16.780 --> 00:07:19.800
בעוד משתמשי הכשפים עובדים עם פרטי הלקוח הקשורים בפייננס.

00:07:19.960 --> 00:07:23.120
הלקוח נשאר מזוהה כאותו לקוח בשני המקומות.

00:07:23.120 --> 00:07:24.760
גם לכתובות יש חשיבות.

00:07:24.880 --> 00:07:29.800
ללקוח עשויה להיות כתובת לחיוב, כתובת למשלוח, ואולי אתר שבו תכנאי שירות צריך לבקר.

00:07:29.920 --> 00:07:34.900
אי אפשר להתייחס לפרטים אלו כאל טקסט פשוט שמועתק לטבע אחת, כי לכל כתובת יש תפקיד שונה.

00:07:35.100 --> 00:07:38.160
דול רייט תומך במבנה הרשומות המשותף הדרוש לקשר הזה.

00:07:38.320 --> 00:07:40.120
אנשי קשר פועלים לפי אותו דפוס.

00:07:40.320 --> 00:07:44.340
לחברה לקוחה אחת עשויים להיות קניין, איש קשר לחשבונות, לתשלום ומנהל שירות.

00:07:44.340 --> 00:07:46.520
המחירות צריכות לדעת מי מקבל את ההחלטות.

00:07:46.640 --> 00:07:48.980
הכספים צריכים לדעת למי להפנות שאלות חיוב.

00:07:49.120 --> 00:07:51.020
השירות צריך לדעת מי ממתין באתר.

00:07:51.160 --> 00:07:56.240
רשומות מקושרות עוזרות לכל צוות לראות את האנשים הקשורים ללקוח בלי לבנות את המידע מחדש בכל אפליקציה.

00:07:56.400 --> 00:07:58.180
מוצרים הם דוגמה נפוצה נוספת.

00:07:58.340 --> 00:08:02.800
איש מחירות צריך לדעת מה החברה מוכרת, מה עלות המוצר, והאם יש מלאי זמין.

00:08:02.800 --> 00:08:08.700
התשובות האלה מגיעות בדרך כלל מהצד התפעולי של העסק, כי שם מנוהלים המוצר, המלאי, הרכש וההספקה.

00:08:08.840 --> 00:08:12.300
זו הסיבה שמידע על מוצרים מתחיל לעיתים קרובות בכספים ובתפעול.

00:08:12.440 --> 00:08:14.800
צוות תפעול יוצר ומכין מוצר שם.

00:08:15.020 --> 00:08:21.100
ברגע שהמוצר מוכן לעבודה מול לקוחות, דול רייט יכול לשלוח את פרטי המוצר הקשורים לתוך דייטווארס.

00:08:21.240 --> 00:08:27.280
משתמשי המחירות יכולים אז לבחור ולדון במוצר באפליקציה שלהם, מבלי שמישהו יזין את רשימת המוצרים פעם שנייה.

00:08:27.280 --> 00:08:31.480
זה עוזר לשיחות המחירה להישאר מעוגנות במה שהעסק באמת יכול לספק.

00:08:31.560 --> 00:08:35.620
פרטי תמחור ומלאי יכולים להגיע למחירות גם דרך האפליקציות המחוברות.

00:08:35.780 --> 00:08:43.940
במקום לנחש אם פריט קיים, אם המחיר השתנה או אם המלאי יכול לתמוך בהבטחה, צוות המחירות יכול לעבוד על בסיס מידע הקשור לצד התפעולי.

00:08:44.060 --> 00:08:46.580
זה לא מבטל את הצורך בשיקול דעת מחירתי טוב.

00:08:46.780 --> 00:08:51.360
זה מסיר סיבה אחת מיותרת לנציג מחירות להתקשר למחסן רק כדי לוודא פרטים בסיסיים.

00:08:51.360 --> 00:08:54.880
מידע על ספקים יכול גם להתחבר היכן שתהליך עסקי זקוק לו.

00:08:54.980 --> 00:09:01.920
פרטי חברה, מבנים ארגוניים, נתוני עזר פיננסיים ונתוני מס יכולים להיות רלוונטיים גם בצד הלקוח וגם בצד התפעולי.

00:09:02.020 --> 00:09:06.780
הרשומות המדויקות תלויות באפליקציות ובתהליכים שחברה משתמשת בהם, אך הדפוס נשאר זהה.

00:09:06.940 --> 00:09:10.280
שתפו את הרשומות שצריכות להיות בעלות משמעות זהה בשני המקומות.

00:09:10.320 --> 00:09:13.140
כעת, אל תניחו שכל רשומה צריכה לעבור בשני הכיוונים.

00:09:13.140 --> 00:09:15.620
חלק מהאפליקציות תומכות בעדכונים דו-כיווניים.

00:09:15.740 --> 00:09:21.060
שינוי יכול להתחיל בדטאברס ולעבור לפייננס ואופוריישונס, או להתחיל בפייננס ואופוריישונס ולעבור לדטאברס.

00:09:21.180 --> 00:09:25.260
גישה זו מתאימה לרשומות שבהן לשני הצדדים יש סיבה עסקית מאותה לעדכן פרטים מאושרים.

00:09:25.440 --> 00:09:27.420
מיפויים אחרים פועלים בכיוון אחד בלבד.

00:09:27.580 --> 00:09:29.280
מוצרים נותנים לנו דוגמה שימושית.

00:09:29.280 --> 00:09:37.840
בעסקים רבים, פייננס ואופוריישונס, אחראית על יצירת מוצרים כי התפעול שולט במאסטר המוצר, במלאי, בחידות ובפרטים אחרים הדרושים למחירה והספקה.

00:09:37.980 --> 00:09:42.320
לאחר מכן המוצר זורם אל דייטאברס, שם צוותי המחירות והשירות יכולים להשתמש בו.

00:09:42.440 --> 00:09:43.280
זהו כלל ברור.

00:09:43.440 --> 00:09:46.320
המוצר לא צריך שני צוותים שיוצרים גרסאות מתחרות.

00:09:46.480 --> 00:09:50.860
צד אחד יוצר ומנהל את המוצר, הצד השני מקבל ומשתמש בו כחלק מעבודתו.

00:09:50.860 --> 00:09:53.280
כל רשומה משותפת זקוקה להחלטה מסוג זה.

00:09:53.400 --> 00:09:54.780
היכן הרשומה הזו מתחילה?

00:09:54.880 --> 00:09:55.840
מי יכול לארוך אותה?

00:09:55.900 --> 00:09:58.500
עם שם, כתובת, מחיר או סיווג נראים שגויים?

00:09:58.700 --> 00:09:59.700
איזה צוות מתקן זאת?

00:09:59.780 --> 00:10:02.880
השאלות האלה נשמעות פשוטות, אבל הן מונעות הרבה בלבול בהמשך.

00:10:03.000 --> 00:10:04.980
חיבור יכול להעביר שינוי במהירות רבה.

00:10:05.140 --> 00:10:08.580
אם אף אחד לא הסכים מאחראי על השינוי הזה, הוא יכול להעביר טעות באותה מהירות.

00:10:08.700 --> 00:10:12.600
בחרו בעלים לרשומה ובמידת הצורך לפרטים בודדים בתוך אותה רשומה.

00:10:12.600 --> 00:10:16.940
לדוגמה, המחירות עשויות להחזיק בפרטי הקשר של הלקוח ובפרטי ההתקשרות העיקריים.

00:10:17.080 --> 00:10:21.220
הכספים עשויים להחזיק בפרטים הקשורים לתשלום, והתפעול עשוי להחזיק בפרטי מוצר ומלאי.

00:10:21.340 --> 00:10:27.060
החלוקה המדויקת שלכם תלויה באופן שבו העסק שלכם עובד, אך היא צריכה להיות מתועדת ומובנת על ידי האנשים המשתמשים באפליקציות.

00:10:27.160 --> 00:10:32.740
ישנם גם שני מונחים שייתכן שתראו לאחר שדואל רייט ירחיב את הדטאברס, פארטי וקומפני.

00:10:32.740 --> 00:10:36.920
פרטי היא הדרך של מייקרוסופט לטפל באדם או בארגון בצורה עקבית.

00:10:37.100 --> 00:10:44.240
זה עוזר לחבר בין אנשים, ארגונים, אנשי קשר וכתובות מבלי להתייחס לכל מערכת יחסים כי רשומה נפרדת ובלתי קשורה.

00:10:44.420 --> 00:10:48.880
קמפני עוזרת לדטאברס להבין את הקשר החברה העסקית המשמש את Finance and Operations.

00:10:49.180 --> 00:10:52.300
אתם לא צריכים להפוך למומחים באף אחד מהמונחים האלה ביום הראשון.

00:10:52.300 --> 00:10:59.240
רק דעו שהם קיימים כי כספים ותפעול מטפלת במבנים עסקיים שאפליקציות לקוחות צריכות לזהות כשינתונים עוברים בין שני הצדדים.

00:10:59.380 --> 00:11:04.540
ברגע שינתונים יכולים לנוע בשני הכיוונים, התהליך סביבם חשוב לא פחות מהנתונים עצמם.

00:11:04.720 --> 00:11:06.560
איך שינוי עובר בין האפליקציות?

00:11:06.940 --> 00:11:10.220
בואו נעקוב אחרי שינוי אחד במערכת ונראה מה באמת קורה.

00:11:10.380 --> 00:11:13.960
נציג מחירות נמצא בשיחה עם לקוח שזה עתה עבר למשרד חדש.

00:11:13.960 --> 00:11:19.720
במהלך השיחה, הנציג פותח את רשומת הלקוח בדיינמיקס 365 סיילס ומעדכן את כתובת הרחוב.

00:11:19.840 --> 00:11:22.540
פשוט מספיק, נכון, ואז הוא שומר את הרשומה.

00:11:22.660 --> 00:11:24.100
כאן מתחיל החלק המעניין.

00:11:24.260 --> 00:11:28.480
המערכת שומרת את השינוי בדטאברס, שזה צד הנתונים עבור אפליקציות הפונות ללקוחות.

00:11:28.580 --> 00:11:33.680
לאחר מכן, הדואל רייט בודק את המיפוי שמחבר בין פרטי הלקוח והכתובת באתר זה לבין כספים ותפעול.

00:11:33.780 --> 00:11:36.280
הוא שולח את השינוי התואם לצד השני באופן אוטומטי.

00:11:36.280 --> 00:11:39.620
אין קובץ ייצור שיושב בתיקייה משותפת ומחכה שמישהו יאסוף אותו.

00:11:39.760 --> 00:11:41.900
אף אחד לא צריך לשלוח אימייל לכשפים עם הערה,

00:11:42.120 --> 00:11:43.860
היי, בבקשה תעדכנו את הכתובת הזו.

00:11:43.980 --> 00:11:46.020
המיפוי כבר יודע אילו שדות מקושרים,

00:11:46.300 --> 00:11:49.960
והוא שולח את השינוי ישירות לרשומת הלקוח הקשורה בכשפים ותפעול.

00:11:49.960 --> 00:11:53.400
כך שמשתמש במחלקת כספים יכול לפתוח את רשומת הלקוח מאוחר יותר,

00:11:53.640 --> 00:11:56.860
לראות את הכתובת המעודכנת ולאבד הזמנה או להכין חשבונית ללא הפרעה.

00:11:56.980 --> 00:11:58.980
זו התוצאה הפרקטית, פשוט וברור.

00:11:59.180 --> 00:12:01.080
שני אנשים ממשיכים לעבוד באפליקציות שונות,

00:12:01.260 --> 00:12:03.860
אך אף אחד מהם לא צריך להקליד מחדש את אותם פרטי לקוח.

00:12:04.040 --> 00:12:07.000
נציג המחירות עובד במסך המיועד לשיחות עם לקוחות.

00:12:07.180 --> 00:12:10.200
משתמש הכספים עובד במסך שנבנה עבור עבודה פיננסית.

00:12:10.200 --> 00:12:14.420
כל אדם רואה את פרטי הלקוח שהוא באמת צריך בדיוק איפה שהוא צריך אותם,

00:12:14.560 --> 00:12:16.600
והתהליך עובד גם בכיוון ההפוך.

00:12:16.740 --> 00:12:20.780
דמיינו שמחלקת כספים מעדכנת פרטי לקוח נתמכים בכספים ותפעול.

00:12:20.780 --> 00:12:24.800
נניח שמשתמש כספים מתקן פרט ששייך לרשומת הלקוח התפעולית.

00:12:24.940 --> 00:12:29.700
הדואל רייט משתמש במיפוי התואם בכיוון ההפוך ושולח את העדכון הקשור לדטאברס.

00:12:29.860 --> 00:12:34.000
ואז המחירות, או כל אפליקציה מבוססת דייטאברס אחרת, יכולות לקלוט אותו.

00:12:34.000 --> 00:12:36.780
חיבור זה הוא סינכרוני עבור עבודה יומיומית רגילה.

00:12:36.880 --> 00:12:40.760
סינכרוני אומר שהאפליקציות מנסות להשלים את העדכון כחלק מאותו רגע עבודה,

00:12:41.020 --> 00:12:44.320
במקום להפיל אותו למשימת רקע שעשויה לרוץ 20 דקות מאוחר יותר.

00:12:50.780 --> 00:12:53.860
התנהגות זו היגיונית עבור רשומות עסקיות משותפות.

00:12:54.020 --> 00:12:59.260
אתם לא רוצים שכתובת לקוח, פרטי מוצר או מידע משותף אחר יסתו זה מזה במשך שעות כי משימת הצווה עדיין לא הופעלה.

00:12:59.400 --> 00:13:02.320
אנשים מקבלים החלטות על סמך מה שהם רואים על המסך שלהם כרגע.

00:13:02.320 --> 00:13:05.820
אז החיבור שומר על שני הצדדים מסונקרנים בזמן שהעבודה מתבצעת.

00:13:05.940 --> 00:13:08.560
עבודה חיה עדיין זקוקה לעיתים להצירה מבוקרת.

00:13:08.780 --> 00:13:11.620
דול רייט כולל אפשרויות הפעלה, השיה והתעדכנות.

00:13:11.620 --> 00:13:14.900
הפעולה אומרת שהמיפוי רץ ושינויים נתמכים עוברים כרגיל.

00:13:15.080 --> 00:13:20.620
השיה עוצרת זמנית את המיפוי כאשר צוות צריך לבצע עבודה מתוכננת, לחקור בעיה או לנהל שינוי בביטחה.

00:13:20.740 --> 00:13:22.420
אך השיה אינה חנייה קבועה.

00:13:22.420 --> 00:13:26.220
בזמן שהמיפוי מושהה, שינויים יכולים להמתין בתור לזמן ומקום מוגבלים.

00:13:26.400 --> 00:13:29.880
כשהמיפוי מתחדש, תהליך ההתעדכנות מאבד את השינויים הממתינים.

00:13:30.040 --> 00:13:32.600
זה עוזר לצוותים להתאושש לאחר הפרעה מתוכננת.

00:13:32.600 --> 00:13:36.960
אך מי שהוא צריך להיות אחריי על ההשיה הזו ולדעת מתי המיפוי צריך להתחיל לרוץ שוב.

00:13:37.140 --> 00:13:40.840
לפני שכל זה מתחיל בעבודה היומיומית, יש שלב נוסף, סינקרון ראשוני.

00:13:40.840 --> 00:13:44.800
סינקרון ראשוני מביא רשומות קיימות משני הצדדים לנקודת התחלה משותפת.

00:13:44.920 --> 00:13:49.360
חישבו על חברה שכבר יש ללקוחות ב-Finance and Operations ורשומות לקוחות ב-Dataverse.

00:13:49.520 --> 00:13:53.760
החיבור לא יכול פשוט להידלק ולהניח שכל רשומה קיימת כבר תואמת באופן מושלם.

00:13:53.900 --> 00:13:54.960
דרוש קו זינוק.

00:13:54.960 --> 00:13:59.880
סינקרון ראשוני עוזר להעביר נתונים קיימים לפני שאנשים מסתמכים על עדכונים חיים.

00:13:59.880 --> 00:14:07.440
העבודה הזו דורשת זהירות כרשומות כפולות, כתובות חסרות ונתוני בדיקה ישנים לא מנקים את עצמם רק כסינקרון התחיל.

00:14:07.580 --> 00:14:11.480
הם עלולים למעשה ליצור בעיות מהר יותר אם הרשומות לא עומדות בכללים המוסכמים.

00:14:11.660 --> 00:14:16.300
ברגע שהמיפויים רצים, האנשים שמנהלים את דול רייט צריכים מקום ברור לבדוק את תקינות המערכת.

00:14:16.300 --> 00:14:22.720
דול רייט מספק יומני פעילות ושגיאות משולבים כדי שמנהלי מערכת יוכלו לראות מה החיבור איבד ואיפה הוא נתקל בבעיות.

00:14:22.900 --> 00:14:24.960
הם יכולים גם להגדיר התראות וספים.

00:14:25.140 --> 00:14:30.660
כלומר, האנשים הנכונים שומעים על בעיות לפני שמשתמשים מגלים אותן דרך עדכון חסר או כושל.

00:14:30.840 --> 00:14:33.640
מבט תמיכה זה חשוב כי לכל שגיאה יש סיבה.

00:14:33.880 --> 00:14:35.200
אולי שדה חובה חסר.

00:14:35.360 --> 00:14:37.240
אולי רשומה קשורה עדיין לא הגיעה.

00:14:37.380 --> 00:14:39.940
אולי מישהו שינה נתונים באופן שלא מתאים למיפוי.

00:14:39.940 --> 00:14:44.660
ניסיון חוזר על רשומה כושלת מבלי לתקן את הסיבה בדרך כלל רק יוצרת אותה השגיאה שוב.

00:14:44.820 --> 00:14:52.860
מערך דול רייט שמנוהל היטב מפקח על החיבור מתקן את הסיבות לשגיאות ושומר על המיפויים ממוקדים ברשומות שבאמת צריכות להישאר מחוברות.

00:14:53.040 --> 00:14:54.640
איפה דול רייט מתאים ביותר?

00:14:54.640 --> 00:15:04.200
דול רייט מתאים ביותר כאשר העסק שלך משתמש ב-Dynamics 365 Finance או Supply Chain Management לצד אפליקציות מול לקוחות כמו מחירות, שירות לקוחות, שירות שטח או ניהול פרויקטים.

00:15:04.340 --> 00:15:07.440
אפליקציות אלו תומכות בחלקים שונים של אותה שיחה עסקית.

00:15:07.660 --> 00:15:13.540
צוות אחד מדבר עם הלקוח, צוות אחר מתכנן משלוח, מנהל מלאי, עוקב אחר עלויות או שולח את החשבוני.

00:15:13.540 --> 00:15:20.860
כאשר שתי קבוצות צריכות לעבוד על רשומות קשורות במהלך היום, כתיבה כפולה, דול רייט, יכולה לחבר את העבודה הזו מבלי לאלץ את כולם להשתמש באותה אפליקציה.

00:15:21.020 --> 00:15:23.720
קחו לדוגמה תהליך, מליד לי מזומן, Prospect to Cash.

00:15:23.940 --> 00:15:27.460
איש מחירות עובד עם לקוח פוטנציאלי ב-Dynamics 365 Sales.

00:15:27.620 --> 00:15:31.700
הוא עוקב אחר איש הקשר, דן במוצרים, בונה הצעת מחיר ומתקדם לקראת הזמנה.

00:15:31.700 --> 00:15:39.120
במהלך השיחה הזו, איש המחירות זקוק לפרטי הלקוח, למידע על המוצרים, למחירים ולמידע על הזמנות שקשור לצד הפיננסי של החברה.

00:15:39.200 --> 00:15:44.980
ברגע שהמחירה הופכת למציאות, מערכת הפיננסים וניהול שרשרת ההספקה לוקחת אחריות על העבודה שמתבצעת לאחר ההבטחה.

00:15:45.120 --> 00:15:48.300
היא מטפלת בביצוע ההזמנה, בחיוב המלאי וברשומות הפיננסיות.

00:15:48.480 --> 00:15:51.400
כתיבה כפולה עוזרת לשני החלקים הללו להישאר מחוברים.

00:15:51.400 --> 00:15:57.920
אנשי מחירות יכולים לעבוד באפליקציית הלקוחות שמתאימה לתפקידם, בעוד שמערכות הפיננסים והתפעול מנהלות את העסקה באפליקציה שנבנתה עבור עבודתם.

00:15:58.040 --> 00:16:02.260
הלקוח לא הופך לשני סיפורים נפרדים, אחד שמסופר על ידי המחירות ואחר על ידי הפיננסים.

00:16:02.440 --> 00:16:04.980
שירות שטח, פילד סארוויס, נותן לכם דוגמה טובה נוספת.

00:16:05.120 --> 00:16:09.240
דמיינו חברה ששולחת טכנאים להתקין, לתקן או לתחזק ציוד באתרים של לקוחות.

00:16:09.240 --> 00:16:15.420
עובד השטח זקוק לפרטי הלקוח, לפרטים על העבודה ולמידה על נכס הלקוח של הפריט שהחברה התקינה או תומכת בו.

00:16:15.540 --> 00:16:20.840
מאחורי הקלעים, החברה צריכה גם לעקוב אחר חלקים, עלויות, רכישות והכסף הקשור לעבודה ההיא.

00:16:21.000 --> 00:16:23.640
שירות שטח מתמקד בתכנון ובביצוע של הביקור.

00:16:23.800 --> 00:16:27.360
מערכות פיננסים ותפעול מתמקדות ברישום התפעולי והפיננסי שסביבו.

00:16:27.360 --> 00:16:34.560
כאשר הרשומות הללו מתחברות כראוי, עבודתו של הטכנאי אינה מנותקת מהחלקים שבהם נעשה שימוש, מעלות העבודה או מרשומת הלקוח הקשורה אליה.

00:16:34.700 --> 00:16:39.180
ניהול פרויקטים טיפוליים מתאים לאותו דפוס, במיוחד עבור חברות שמוכרות עבודה לפי פרויקט.

00:16:39.340 --> 00:16:44.240
צוות פרויקט עשוי לנהל עבודה מול לקוחות, זמן של אנשים, עלויות מתוכננות ואבני דרך בפרויקט.

00:16:44.360 --> 00:16:48.560
הפיננסים צריכים לראות את הצד הפיננסי של רכש, עלויות, חיוב ודיווח.

00:16:48.560 --> 00:16:56.740
ללא חיבור, מנהלי פרויקטים עלולים לבזבז זמן רב מדי ברדיפה אחר הפיננסים לקבלת עדכונים, בעוד הפיננסים ממתינים שצוותי הפרויקט יאשרו מה קרה.

00:16:56.920 --> 00:17:02.660
רשומות פרויקט מחוברות נותנות לשתי הקבוצות תמונה ברורה יותר של העבודה כשהיא עוברת מהבטחת לקוח לפעילות פיננסית.

00:17:02.840 --> 00:17:05.000
יש כאן גם יתרון רחב יותר של Power Platform.

00:17:05.220 --> 00:17:10.920
מכיוון שצד אפליקציית הלקוח משתמש בדטאברס, נתונים מאושרים בדטאברס יכולים לתמוך בפאור אפס ובאהור אוטומייט.

00:17:10.920 --> 00:17:16.980
חברה עשויה לבנות אפליקציה קטנה לצוות פנימי או ליצור זרימה שמגיבה כאשר רשומה עסקית מגיעה לנקודה מסוימת.

00:17:17.180 --> 00:17:20.980
זה לא אומר שכל רשומה של פיננסים ותפעול שייכת פתאום לכל פאור אפ.

00:17:21.080 --> 00:17:27.960
המשמעות היא שרשומות מקושרות יכולות להפוך לחלק ממערך רחב יותר של כלים עסקיים, כל עוד החברה בוחרת במטרה זו בזהירות ומגנה על הנתונים כראוי.

00:17:28.060 --> 00:17:29.600
גבול אחד חייב להישאר ברור.

00:17:29.800 --> 00:17:33.180
דול רייט אינו תומך בדיינמיקס 365 ביזנס סנטרל.

00:17:33.180 --> 00:17:42.460
ביזנס סנטרל יכול להתחבר למוצרי מייקרוסופט אחרים בדרכים אחרות, אך דול רייט מיועד לצד הפיננסי והתפעולי של דיינמיקס 365 ולאפליקציות לקוח מבוססות דייטוורס.

00:17:42.620 --> 00:17:45.260
זה גם לא כלי להעתקת כל טבלה שניתן למצוא.

00:17:45.420 --> 00:17:51.220
רשומה צריכה לעבור כי אנשים זקוקים לאותו רישום תפעולי בשני המקומות, לא כי העתקת נתונים מרגישה בטוחה יותר.

00:17:51.220 --> 00:17:58.200
דול רייט גם לא מחליף תוכנית אינטגרציה רחבה יותר כאשר חברה זקוקה להזנת דוחות, קישורים למערכות צד שלישי או הגירת נתונים גדולה.

00:17:58.300 --> 00:18:02.240
התייחסות לכל חיבור נתונים כאל אותה משימה יוצרת בעיות במהירות.

00:18:03.020 --> 00:18:05.340
מגבלות, הכנה וטעויות נפוצות.

00:18:05.520 --> 00:18:08.840
חישבו על דול רייט כעל הסכם לחיצת יד בין שתי מערכות.

00:18:09.060 --> 00:18:14.760
הן מסכימות לשמור על רשומות משותפות מסוימות בסינקרון, אבל זה לא צינור קסמים לכל טבלה, דוח או מערכת חיצונית.

00:18:14.760 --> 00:18:17.780
לפני ההגדרה, בדקו אילו אינטגרציות כבר קיימות.

00:18:17.920 --> 00:18:23.100
אם חיבור ישן ודואל רייט מעדכנים שניהם את אותה רשומת לקוח, אתם עלולים ליצור התנגשויות מהר מאוד.

00:18:23.300 --> 00:18:24.700
זו כאב ראש שאתם לא רוצים.

00:18:24.840 --> 00:18:26.520
אז, הסכימו על היסודות תחילה.

00:18:26.640 --> 00:18:27.480
איך תזינו שמות?

00:18:27.640 --> 00:18:29.640
איזו ישות משפטית מחזיקה בכל רשומה?

00:18:29.760 --> 00:18:30.880
מי יכול לבצע שינויים?

00:18:31.080 --> 00:18:32.860
אילו תפקידי הבטחה כל צוות צריך?

00:18:33.000 --> 00:18:35.640
טפלו בכפילויות וברשומות חסרות לפני הסינקרון הראשון.

00:18:35.640 --> 00:18:37.820
התחילו עם המיפויים המוכנים מראש של מייקרוסופט.

00:18:37.940 --> 00:18:39.400
הם כבר מחברים רשומות מפוצות.

00:18:39.560 --> 00:18:42.040
טבלאות ושדות מותאמים אישית דורשים בדיקה זהירה.

00:18:42.100 --> 00:18:43.720
ובדקו טבלאות קשורות ותלויות מיפוי,

00:18:43.880 --> 00:18:47.120
כי לעיתים רשומה אחת צריכה שרשומה אחרת תהיה קיימת כדי להסתמכרן.

00:18:47.240 --> 00:18:49.980
תכננו את הסינקרון הראשון שלכם בהתבסס על כמות הנתונים שיש לכם.

00:18:50.100 --> 00:18:52.640
אל תתייחסו לזה כמו למתג אור שמדליקים בזמן ארוחת הצהריים.

00:18:52.840 --> 00:18:53.700
זה יגרום לי בעיות.

00:18:53.700 --> 00:18:56.580
מיפוי מושהי עדיין זקוק לבעלים ולתוכנית הפעלה מחדש.

00:18:56.720 --> 00:18:59.260
שינויים בתור ורשומות שנכשלו לא נשארים לנצח.

00:18:59.400 --> 00:19:02.500
עקבו אחר יומני הפעילות, השגיאות, ההתראות וספי המערכת.

00:19:02.660 --> 00:19:06.760
כשמה שהוא נכשל, מיצאו את השדה החסר, הרשומה הפגומה או הכלל השבור שמאחורי זה.

00:19:06.940 --> 00:19:09.020
ניסיונות חוזרים לא יתקנו נתונים פגומים.

00:19:09.220 --> 00:19:12.520
שרואים בדואל רייט גשר מבוקר, הכל מתחבר למקומו.

00:19:13.280 --> 00:19:13.760
סיכום.

00:19:13.980 --> 00:19:15.520
שיחה עסקית משותפת אחת.

00:19:15.520 --> 00:19:21.920
דול רייט שומר על רשומות משותפות נתמכות בתנועה בין הפיננסים והתפעול לבין אפליקציות הלקוח מבוססות הדטאברס שלכם.

00:19:22.040 --> 00:19:25.120
כך, צוותים יכולים לעבוד מתוך נתונים עסקיים מחוברים.

00:19:25.380 --> 00:19:29.240
הרשמו בפלטפורמת הפודקסטים המועדפת עליכם לעוד פניני ידע איתי,

00:19:29.240 --> 00:19:37.820
מרקו פיטרס ב-m365.fm ושתפו את הפרק הזה עם מישהו שעדיין מחבר מחירות, שירות וחשפים דרך עוד גיליון אלקטרוני.