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

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

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

שני הצדדים צריכים את אותן עובדות. המחירות צריכות את העובדות האלו באפליקציה שבה אנשי המחירות עובדים. הכספים והתפעול צריכים אותן באפליקציה שבה הם מנהלים הזמנות, כסף ומשלוחים. המטרה היא לא לנסות לכפות על כל צוות מסך ענק אחד. המטרה היא שרשומות משותפות יעקבו אחרי מסלול ברור ומוסכם. כאן נכנסת לתמונה הכתיבה הכפולה, Do Right. אז מה היא בעצם כתיבה כפולה? הנה ההגדרה הפשוטה ביותר. כתיבה כפולה היא חיבור מובנה של מייקרוסופט ששומר על נתונים נבחרים מסונקרנים בין אפליקציות Dynamics 365 Finance and Operations לבין DataVars. DataVars הוא בסיס הנתונים המשותף מאחורי אפליקציות עסקיות רבות של מייקרוסופט. Dynamics 365 Sales, Customer Service, Field Service וחלקים מפרויקט אופרישונס משתמשים בו כולם. גם Power Apps וPower Automate יכולים להשתמש בו. אתם לא צריכים לדעת איך DataVars מאחסן כל רשומה כדי להבין כתיבה כפולה. פשוט תחשבו על זה כאזור הנתונים המשותף בצד אפליקציות הלקוח של Dynamics 365. דמיינו בניין משרדים עם משרד קדמי ומשרד אחורי.

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

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

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

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

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

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

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

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

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

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

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

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

מערך דול רייט שמנוהל היטב מפקח על החיבור מתקן את הסיבות לשגיאות ושומר על המיפויים ממוקדים ברשומות שבאמת צריכות להישאר מחוברות. איפה דול רייט מתאים ביותר? דול רייט מתאים ביותר כאשר העסק שלך משתמש ב-Dynamics 365 Finance או Supply Chain Management לצד אפליקציות מול לקוחות כמו מחירות, שירות לקוחות, שירות שטח או ניהול פרויקטים. אפליקציות אלו תומכות בחלקים שונים של אותה שיחה עסקית. צוות אחד מדבר עם הלקוח, צוות אחר מתכנן משלוח, מנהל מלאי, עוקב אחר עלויות או שולח את החשבוני. כאשר שתי קבוצות צריכות לעבוד על רשומות קשורות במהלך היום, כתיבה כפולה, דול רייט, יכולה לחבר את העבודה הזו מבלי לאלץ את כולם להשתמש באותה אפליקציה. קחו לדוגמה תהליך, מליד לי מזומן, Prospect to Cash. איש מחירות עובד עם לקוח פוטנציאלי ב-Dynamics 365 Sales. הוא עוקב אחר איש הקשר, דן במוצרים, בונה הצעת מחיר ומתקדם לקראת הזמנה. במהלך השיחה הזו, איש המחירות זקוק לפרטי הלקוח, למידע על המוצרים, למחירים ולמידע על הזמנות שקשור לצד הפיננסי של החברה.

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

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

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

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

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