דלגו לתוכן

שרטטו את מפת המערכות לפני ה-org

זמין גם ב-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)

פרק 4 בקורס Data Architect, חלק 1: להפוך לארכיטקט נתונים. הקודם: ארכיטקטורת הנתונים של Salesforce.

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

אנשים מופתעים מהסדר. אנחנו ארכיטקטי נתונים; לא כדאי שנתחיל ממודל הנתונים? הנה למה אני לא. אם אני משרטט קודם את מודל הנתונים, כבר החלטתי מה שייך ל-Salesforce. אם אני משרטט קודם את מפת המערכות, אני רואה את כל מה שצריך לעצב את ההחלטה הזו: ה-ERP שהוא הבעלים של הלקוחות והמוצרים, מחסן הנתונים שעונה על שאלות של חמש שנים, ספק הזהויות שמחליט מי נכנס, השותף ששולח קובץ בכל אחר צהריים, מערכת ה-legacy שכולם אומרים שהיא בדרך החוצה.

פרקים 2 ו-3 תכננו את ה-org: מה המודל צריך להיות, ואיך הוא חי ב-Salesforce. הפרק הזה מרחיק את המצלמה ומשרטט את מה שמקיף את ה-org, לפני שה-org מתוכנן. Salesforce היא מערכת אחת מתוך רבות, ולעיתים קרובות היא לא זו שהנתונים בבעלותה.

ארכיטקט מוביל משרטט מפת מערכות סביב Salesforce על לוח מחיק בשביל שני עמיתים, בבוקר ערפילי

התמונה נוצרה באמצעות בינה מלאכותית.

  • מפת המערכות באה קודם. מצאו את המערכות, אחר כך את הנתונים שזזים ביניהן, אחר כך מי הבעלים של כל חלק. רק אז החליטו מה התפקיד של Salesforce.
  • חץ תלוי בחצים אחרים. הזמנות שיוצאות ל-ERP צריכות קודם לקוחות, מוצרים ומחירים שנכנסים. בכל פעם שאני רואה אינטגרציה עם זרימה אחת בלבד, אני מתחיל לדאוג.
  • לנתונים יש סוגים, ויש עומסי עבודה. נתוני אב, נתוני ייחוס, נתוני תנועות, מטא-דאטה, נתונים אנליטיים ונתונים לא מובנים משתנים, גדלים ומשמשים בדרכים שונות; עומסי עבודה תפעוליים (OLTP), אנליטיים (OLAP) וזורמים רוצים בתים שונים. ה-org מריץ את העסק; מחסני נתונים ואגמי נתונים מנתחים אותו.
  • למערכות יש תפקידים, לא רק לוגואים. רשומה, מעורבות, ייחוס, תובנות. “Salesforce היא מערכת הרשומה שלנו”: של מה?
  • המקום שבו האנליטיקה חיה הולך אחרי המקום שבו הנתונים חיים. הכול על הליבה: דוחות סטנדרטיים. נתונים במאגרים אחרים: פלטפורמת אנליטיקה, ומחסן הנתונים כשנתוני Salesforce מתמזגים איתו.
  • Data 360 הוא קרוב לליבה (near-core): מנוהל על הליבה, מתארח מחוץ לליבה. משתמשים אף פעם לא מתחברים אליו, אז הוא יושב עם הצנרת.
  • נתונים שה-ERP הוא הבעלים שלהם נקראים מקומית ונכתבים תחת בקרה, עם קידומת erp_ כדי שהסכמה תראה מי הבעלים של כל שדה.
  • במפת המערכות, חץ מתחיל במערכת שפותחת את החיבור, והתווית שלו אומרת מה זז ולאיזה כיוון. שתי זרימות הן שני חצים; חץ דו-ראשי הוא רק למחבר (connector).
  • לכל חץ יש לקוח ושרת, וכל אחד מהם אחראי על החצי שלו. שום דבר מזה לא נכנס למפת המערכות, אבל לכל חץ זה קיים.
  • ספרו לפני שאתם משרטטים את החצים. האפסים נכנסים למלאי, והם בוחרים את המנגנון: אצווה, סינכרוני או אירועים.
  • אסטרטגיית ה-org היא החלטה ברמת מפת המערכות, שמתקבלת בדקות הראשונות: org אחד או כמה, ואיפה הוא רץ.
  • מצב נוכחי מראה מה לא תקין. אדום לתהליך גרוע, מקווקו לעבודה ידנית, נקודות אדומות למה שחסר.

פריסת מפת המערכות של Steve

Section titled “פריסת מפת המערכות של Steve ”

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

איפהמה נמצא שם
שמאלהאנשים, מלמעלה למטה: משתמשים פנימיים, שותפים, לקוחות
מרכזSalesforce, קופסה פשוטה אחת, והקהילות שלה נוגעות בה מלמטה
למעלהספקי זהויות מעל Salesforce; AppExchange מוזז ימינה; אתרים ציבוריים למעלה משמאל
ימיןשכבת האינטגרציה, ואחריה המערכות הפנימיות: ERP, כספים, מחסן נתונים
מתחת לשכבת האינטגרציהData 360, קרוב לליבה, עם הצנרת
למטהערוצי לקוחות: דוא”ל, טפסי אינטרנט, טלפון, הודעות
למטה מימיןנתונים נכנסים ויוצאים: ארכיונים, טעינות נתונים, מקורות חיצוניים, שותפים

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

מפת המערכות עם החצים אותה מפת מערכות כמו קודם, עכשיו עם חצים; כל אחד מתחיל במערכת שפותחת את החיבור, והתווית שלו אומרת מה עובר ולאיזה כיוון. משתמשים פנימיים מגיעים ל-Salesforce, משתמשי שותפים ל-Partner Community, לקוחות ל-Customer Community. כל ספק זהויות ו-Salesforce חולקים תעודה, שמוצגת כקו ירוק מנוקד עם תעודה בכל קצה: אמון, לא קריאה ישירה, כי הכניסה עוברת דרך הדפדפן של המשתמש כהפניות. ספק הזהויות של העובדים שולח גם עדכוני משתמשים ל-Salesforce. Salesforce שולחת מסמכים החוצה לאפליקציית AppExchange לחתימה אלקטרונית, והזמנות החוצה לשכבת האינטגרציה, ששולחת מוצרים פנימה ל-Salesforce. שכבת האינטגרציה שולחת הזמנות החוצה ומביאה מוצרים מה-ERP; ה-ERP שולח סטטוס הזמנה לשכבת האינטגרציה; שכבת האינטגרציה מביאה תשלומים מהכספים. Data 360, מתחת לשכבת האינטגרציה, פותחת את החיבורים שלה: נתוני CRM החוצה מ-Salesforce, zero copy למחסן הנתונים, והפניה לנתונים החיצוניים. מלמטה, דוא"ל שולח פניות פנימה וטפסי אינטרנט שולחים לידים פנימה ל-Salesforce; Salesforce שולחת פניות ישנות החוצה לארכיון; טעינות נתונים שולחות רשומות פנימה. למעלה: זהות, APPEXCHANGE, אתר אנשים מימין: מערכות פנימיות למטה: ערוצי לקוחות בפינה הימנית התחתונה: נתונים נכנסים ויוצאים משתמשים פנימיים מכירות, שירות, תפעול משתמשי שותפים לקוחות אתר ציבורי IdP של העובדים כניסה יחידה IdP של השותפים כניסה יחידה אפליקציית AppExchange חתימה אלקטרונית Partner Community Customer Community Data 360 קרוב לליבה: מנוהל על הליבה, מתארח מחוץ לליבה שכבת האינטגרציה (ESB) ERP הזמנות, חשבוניות כספים תשלומים ניהול הזמנות מחסן נתונים אנליטיקה דוא"ל דוא"ל לפנייה טפסי אינטרנט מהאתר לליד טלפון מוקד שירות הודעות SMS, צ'אט ארכיון פניות ישנות טעינות נתונים הגירה נתונים חיצוניים בהפניה, לא מועתקים Salesforce ה-org שסביבו אנחנו מתכננים תעודה משותפת עדכוני משתמשים תעודה משותפת מסמכים יוצאים הזמנות יוצאות מוצרים נכנסים הזמנות יוצאות, מוצרים נכנסים סטטוס הזמנה נכנס תשלומים נכנסים נתוני CRM יוצאים zero copy בהפניה פניות נכנסות לידים נכנסים פניות ישנות יוצאות רשומות נכנסות Salesforce קהילה אנשים זהות, אפליקציות, אתר מערכת פנימית ערוץ לקוחות נתונים נכנסים ויוצאים שכבת האינטגרציה מקווקו: עוד לא פעיל, או בהפניה מתחיל במערכת שפותחת את החיבור; התווית אומרת מה עובר תעודה משותפת: אמון, בלי קריאה ישירה © 2026 Twinshark LLC · stevetecharc.com
Click to enlarge

מפת המערכות מיחידה 4, עם החצים שלה.

שש יחידות, כל אחת עומדת בפני עצמה.

  1. Salesforce היא מערכת אחת מתוך רבות. למה מפת המערכות באה לפני הקופסה, האינטגרציה שאני רואה שוב ושוב וזרימות החזרה שהיא תלויה בהן, נתונים בגלים, וליבה, קרוב לליבה ו-Hyperforce.
  2. סוגי הנתונים בארגון. שישה סוגים; נוצרים, נערכים, מופנים; OLTP ו-OLAP; זמן אמת, כמעט זמן אמת ואצווה; ארבע השאלות שמאחורי הקטגוריות.
  3. המערכות סביב Salesforce. תפקידי מערכות; ה-ERP, מחסן הנתונים וה-Lakehouse; האנליטיקה הולכת אחרי הנתונים; MDM; אינטגרציה ואירועים; ספק הזהויות שמפתחים שוכחים; איפה Data 360 יושב.
  4. שרטטו את מפת המערכות. הפריסה שלי, נבנית מדף ריק; האפסים לפני החצים; חצים שמתחילים ביוזם; הלקוח והשרת שמאחורי כל חץ, בשני הכיוונים; תרשימי מסלולים לשיחות; המלאי שמאחורי התמונה.
  5. אסטרטגיית ה-org היא החלטה ברמת מפת המערכות. התחילו מ-org אחד; מה מצדיק עוד אחד; האזור, לא הספק; פיצול ל-AMER ול-EMEA בגלל GDPR; מה ה-org השני מוסיף.
  6. מפת המערכות של Steve Trucking. היום, לפני מימוש מסודר, מסומן: מניפסטים שנוחתים ב-RouteDesk, מסלולים שמוקלדים מחדש ל-Salesforce ובחזרה ידנית, אי של נתוני GPS, גיליון אלקטרוני שמזין את הכספים, ו-108,000 שיחות “איפה המשלוח שלי?” בשנה.

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

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

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

הבא: איכות נתונים וממשל נתונים