נקודת ביקורת 1, שרטטו והגנו על תכנון הנתונים של Steve Trucking

🌐 זמין גם ב-28 שפות

English · Español · 日本語 · Português (Brasil) · Français · Deutsch · Italiano · 한국어 · 简体中文 · Português (Portugal) · 繁體中文 · Bahasa Indonesia · Türkçe · Polski · Tiếng Việt · ไทย · Nederlands · العربية · Українська · हिन्दी · Русский · Svenska · Dansk · Norsk bokmål · Suomi · Español (México) · Français (Canada) · Deutsch (Schweiz)

תורגם בבינה מלאכותית. הקהילה עוד לא בדקה את התרגום. לקריאה באנגלית

תרגול מקורי, מבוסס תרחיש. אף פעם לא מבוסס על שאלות מבחן אמיתיות. הוא כתוב בסגנון “איך אני הייתי מתכנן”: המטרה היא להפוך את שיקול הדעת שלכם לגלוי, לא לבחור אות. האתגר הזה סוגר את חלק 1 של הקורס Data Architect; הפתרון שלי מגיע ב-נקודת ביקורת 1, אז נסו קודם בעצמכם.

התרחיש

Steve Trucking היא חברת משלוחים של המייל האחרון. שותפים קמעונאיים (Retail Partners) גדולים מוכרים מכשירי חשמל, טלוויזיות ורהיטים; הצוותים של Steve Trucking, שני אנשים בכל צוות, מובילים אותם ללקוחות של השותפים הקמעונאיים (הנמענים, Recipients), מתקינים חלק מהם ומפנים את הישנים. קראו את התדריך של Steve Trucking, סעיפים 1–8. אל תיגעו בסעיף 9 (השינויים המאוחרים); הם מגיעים בסוף הקורס.

דרישות

כל מה שבסעיף 5 של התדריך (R1–R15) ובסעיף 6 (S1–S5). אלה שנקודת הביקורת הזו נשענת עליהם הכי הרבה:

• R1. לקבל את המניפסטים של כל שותף קמעונאי בפורמט שלו (קובץ SFTP, API, EDI) ולהפוך אותם למסלולים, לעצירות ולפריטים בלי הקלדה מחדש.
• R3. מנהלי מרכזי ההפצה (DC) של כל שותף קמעונאי רואים בפורטל את המשלוחים, החריגים, התמונות והתביעות שלהם, ואף פעם לא של שותף אחר.
• R4. מניפסטים מתעדכנים במהלך היום; צריך לטפל בשינויים שמגיעים אחרי תכנון המסלולים.
• S2. שותף קמעונאי לעולם לא יראה את המשלוחים, התמחור, הנפחים או הנמענים של שותף אחר.
• S3. קישור המעקב של הנמען מציג רק את המשלוח האחד הזה, בלי חשבון משתמש, ופג תוקף.
• S4. הכתובות, מספרי הטלפון והערות המשלוח של הנמענים הם מידע אישי; הצוותים רואים אותם רק בעצירות שלהם, ורק ביום עצמו.

אילוצים

• כ-3,300 משלוחים ביום עבודה, מיליון בשנה, עם צמיחה של 30% בשנה; כ-1.6 פריטים ושמונה שינויי סטטוס לכל משלוח; ארבעה עד חמישה מיליון תמונות בשנה; כ-200,000 קריאות GPS ביום.
• org אחד של Salesforce בארה”ב, שכבר מריץ את Service Cloud, את Field Service ופורטל שותפים; יש רישיון ל-MuleSoft; יש רישיון ל-Data 360 אבל הוא לא מיושם.
• שלושה שותפים קמעונאיים, שלושה סגנונות אינטגרציה; תשעה מרכזי הפצה.

המשימה שלכם

שרטטו והגנו על התכנון של חלק 1. השתמשו במה שלמדתם בפרקים 1–6:

1. מפת המערכות (פרק 4): שרטטו את מפת המערכות של המצב הנוכחי של Steve Trucking בפריסה של Steve, כשעל כל חץ כתוב מה עובר ואיך.
2. המודל (פרק 2): מדלו את תחום המשלוחים ברמה המושגית, ואז ברמה הלוגית. שותפים קמעונאיים, מרכזי הפצה, מניפסטים, משלוחים, פריטים, מסלולים, משאיות, צוותים, רשימות בדיקה להתקנה, תמונות, חתימות, חריגים ונמענים. (אתגר D1.)
3. התכנון הפיזי (פרק 3): אילו מהם הם אובייקטים סטנדרטיים (ב-Field Service יש הזמנות עבודה, פגישות שירות, משאבי שירות וטריטוריות שירות) ואילו מותאמים אישית? אילו רישיונות צריכים משתמשי השותפים והנמענים? איפה חי כל סוג של נתונים: ב-org, מחוץ לליבה, במחסן הנתונים?
4. המפתח (הפרק הזה): איזה מפתח מתאים שורת הזמנה של שותף קמעונאי למשלוח שלכם, ומה קורה כשהמניפסט מתעדכן אחרי תכנון המסלולים? (אתגר D3.)
5. הנמען (הפרק הזה): איש קשר (Contact), חשבון אישי (person account), או אף אחד מהם? נמקו את זה מתוך הקשר, הנפח, הבידוד בין השותפים ומחזור החיים של הנתונים.
6. לאחד או לא (הפרק הזה): נמענים מופיעים במניפסטים של כמה שותפים, לפעמים יותר מפעם אחת בשנה. האם הייתם מאחדים אותם, או בכוונה לא? מה הסיכון, בהינתן S2? (אתגר DC1, בלי השינויים המאוחרים.)
7. סמכות: לחמישה שדות מפתח (מספר ההזמנה של השותף, סטטוס המשלוח, הטלפון של הנמען, חלון המשלוח, השם המשפטי של השותף), אמרו מי יוצר אותו, מי הבעלים שלו, איזו מערכת סמכותית ומי רשאי לשנות אותו.

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

דיון

הפתרון שלי הוא נקודת ביקורת 1: Steve Trucking, איך אני הייתי מתכנן. השוו את הנימוקים שלכם, לא רק את הקופסאות. איפה שבחרתם אחרת, אתם יכולים להגיד מה הייתם מרוויחים ועל מה הייתם מוותרים?

סקירת תכנון

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

יעדי המבחן שמתורגלים כאן

• DM-1, DM-2 (תכנון מודל הנתונים; המודל מכבד את השיתוף)
• MDM-1, MDM-2, MDM-3, MDM-4 (ניהול נתוני אב, סמכות, התאמה, יכולת התחקות)
• SDM-1 (רישיונות), SDM-3 (תמונה אחת, ומתי לא לבנות אותה)