מפת המערכות של 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)

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

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

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

השאלה שהיחידה הזו עונה עליה: מה מפת מערכות אמיתית מספרת לנו לפני שאנחנו מתכננים משהו?

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

מתחילים ממה שאנחנו יודעים

ל-Steve Trucking יש org אחד של Salesforce, בארה”ב. Service Cloud מטפל בפניות של נמענים (Recipients) ושל שותפים קמעונאיים (Retail Partners); Field Service מנהל את הפגישות, הצוותים ואפליקציית המובייל; Experience Cloud נותן לשותפים הקמעונאיים פורטל, שמשמש היום רק לתביעות ולדוחות; Sales Cloud עוקב אחרי חוזי השותפים ואחרי הצעות למרכזי הפצה (DCs) חדשים. אז Salesforce נכנס באמצע.

משמאל, האנשים: 45 רכזי שיבוץ שעובדים בתוך מרכזי ההפצה של השותפים הקמעונאיים, כ-700 אנשי צוות על 330 משאיות, 60 נציגי שירות לקוחות, 40 אנשי תפעול, כספים ומכירות, וכ-300 משתמשים של השותפים הקמעונאיים. זה כבר מספר לנו משהו: זה לא CRM של מחלקה אחת. זו פלטפורמה תפעולית לרוב העסק. אבל זו עדיין קופסה אחת. עכשיו בואו נראה מה מקיף אותה.

Click to enlarge

Steve Trucking היום, לפני מימוש מסודר. כל מניפסט נוחת ב-RouteDesk; הרכזים מקלידים מחדש את המסלולים ל-Salesforce ואת העצירות שהושלמו בחזרה, ידנית; ל-FleetLink חסר החיבור שלו.

מסמנים מה לא תקין

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

שלושה שותפים, שלוש אינטגרציות

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

Keystone מניחה מניפסט CSV על שרת SFTP בכל אחר צהריים, למשלוח יומיים אחר כך, ורוצה קובץ סטטוס בחזרה בכל לילה. שני חצים: מניפסט נכנס בקובץ, ש-Keystone יוזמת, וסטטוס יוצא בקובץ, ש-RouteDesk יוזם. אסינכרוני, עם חלון זמנים רחב.

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

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

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

ואז עברו עליהן. Keystone: איך חיבור ה-SFTP מאמת את עצמו, איפה הקובץ נוחת, מה אוסף אותו, איך יודעים שכל הקובץ עובד, מה קורה לשורה פגומה, ואיך Keystone שומעת על שינוי לפני הקובץ של הלילה? Redrock: איך ה-API מאמת, מה קורה כשאחד הצדדים למטה, מה נחשב webhook מוצלח, ומה אם אותו סטטוס מגיע פעמיים? Brightwave: מי מפעיל את רשת ה-EDI, איפה התרגום, אילו אישורי קבלה חוזרים? אנחנו לא מתכננים מחדש שום דבר. אנחנו מגלים את השאלות. זה התפקיד של מפת המערכות.

RouteDesk עדיין שם

RouteDesk הוא כלי השיבוץ והמסלולים הישן, אפליקציית דסקטופ, שהרכזים בכל מרכז הפצה משתמשים בו כדי להפוך מניפסטים למסלולים. הוא מחזיק שמונה שנים של היסטוריית משלוחים, ומתוכנן לצאת משימוש. שרטטו אותו בכל זאת. טעות נפוצה היא להשמיט את המערכת “שאנחנו נפטרים ממנה”. מתי? נניח שהתשובה היא שמונה עשר חודשים. אז היא חלק מהארכיטקטורה לפחות שמונה עשר חודשים, ושמונה שנות ההיסטוריה שלה, כחמישה מיליון משלוחים, לא נעלמות כשהאפליקציה נעלמת. ותראו מה מפת המערכות חושפת: RouteDesk ו-Salesforce לא מחוברים. הצוותים עובדים על העצירות שלהם באפליקציית Field Service של Salesforce, אבל המסלולים נבנים ב-RouteDesk, אז הרכזים מקלידים אותם מחדש ל-Salesforce בכל ערב, ואז מקלידים את העצירות שהושלמו בחזרה ל-RouteDesk כדי שהוא יוכל לשלוח סטטוס לשותפים. כ-3,300 עצירות ביום, פעמיים, ידנית. זה מקווקו ואדום על השרטוט. זה גם אומר לכם שה-webhook של Redrock, “ברגע שהם קורים”, לא באמת קורה ברגע שהם קורים. במה RouteDesk מחזיק היום? מה תלוי בו? איזו היסטוריה חייבת לשרוד אחריו, ואיפה: ב-Salesforce, במחסן הנתונים, בארכיון? אנחנו עוד לא עונים. מפת המערכות רק חשפה את השאלות.

FleetLink הוא אי

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

ואז ספרו את האפסים: 200,000 ביום זה יותר מ-70 מיליון בשנה. זה לא “יש לנו נתוני GPS”. זה מקור נתונים זורם עם הרבה אפסים, שיושב מחוץ לחוויית Salesforce. האם Salesforce צריך 70 מיליון קריאות בשנה? כנראה לא את כולן. זו שאלת תכנון להמשך.

לכספים יש אמת משלהם

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

Snowflake מקבל ייצוא שבועי

Snowflake מחזיק את האנליטיקה של התפעול והכספים, ומוזן מייצוא שבועי. Snowflake לא עושה את זה בעצמו; משהו באמצע עושה את זה: משימת ייצוא מתוזמנת, שרצה מחוץ ל-Salesforce, שולפת דרך ה-Bulk API וטוענת ל-Snowflake. המקום שבו האנליטיקה חיה הולך אחרי המקום שבו הנתונים חיים, ו-Snowflake כבר הבית האנליטי. אבל גם התזמון מספר לנו משהו. “מה קרה בחודש שעבר?” הזנה שבועית זה בסדר. “איפה המשלוח הזה עכשיו?” Snowflake הוא לא המקום שממנו הייתי מתחיל. אותו ארגון, עומס עבודה שונה, טריות שונה, תשובה שונה.

הזהות לא מגיעה לכולם באותה דרך

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

בחוויית הנמען יש פער

ספק ה-SMS והדוא”ל שולח לנמענים הודעה כללית מ-RouteDesk: “המשלוח שלכם מגיע מחר”. אין קישור למעקב. ובינתיים יש כ-180,000 פניות בשנה, וכ-60% מהן הן “איפה המשלוח שלי?”: בערך 108,000 פניות בשנה ששואלות את אותה שאלה. עכשיו שימו את זה ליד FleetLink. החברה יודעת איפה המשאיות שלה. הנמענים שלה ממשיכים להתקשר ולשאול. והמערכת שיודעת לא מחוברת לזו שעונה. אני עוד לא צריך לתכנן את הפתרון. מפת המערכות כבר מספרת את הסיפור.

מכניסים את האפסים למלאי

עכשיו ספרו מה זז. כמו ביחידה 4, האפסים לא הולכים על החצים; הם הולכים למלאי שמאחורי התמונה, שם הם יכתיבו את המנגנונים כשנתכנן. כמיליון משלוחים בשנה, כ-3,300 ביום, עם צמיחה של 30% בשנה; כ-1.6 פריטים לכל משלוח; כשמונה עדכוני סטטוס לכל משלוח, כלומר שמונה מיליון עדכוני סטטוס בשנה כבר היום; ארבעה עד חמישה מיליון תמונות בשנה, כרגע בטלפונים הפרטיים של אנשי הצוות; כ-200,000 קריאות GPS ביום; כ-180,000 פניות בשנה. חץ עם התווית “סטטוס משלוח” הוא לא הודעה מזדמנת. הקופסאות אומרות לכם מה קיים. החצים אומרים לכם מה זז. האפסים אומרים לכם אם ההנחות שלכם שורדות את המציאות.

Click to enlarge

המלאי שמאחורי מפת המערכות של Steve Trucking: הנפח ליד המנגנון שהוא יכתיב.

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

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

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

קחו צעד אחורה. שלושה שותפים, שלושה סגנונות אינטגרציה. כלי שיבוץ ישן שמחזיק שמונה שנות היסטוריה, ורכזים שמקלידים מחדש 3,300 עצירות ביום ל-Salesforce ובחזרה. פלטפורמת טלמטיקה עם 200,000 קריאות ביום, מנותקת. כספים שסופרים משלוחים מגיליון אלקטרוני חודשי. אנליטיקה שמפגרת בשבוע. כניסה אחידה לחלק מהמשתמשים, לא לאחרים. אין קישור למעקב, ו-108,000 פניות בשנה שואלות איפה משלוח. והכול צומח ב-30% בשנה.

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

מה הארכיטקט מחליט כאן

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

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

הפרק הזה התחיל מרעיון אחד: שרטטו את מפת המערכות לפני שאתם מתכננים את ה-org. אילו הייתי מתחיל ממודל הנתונים של Steve Trucking, יכולתי לבזבז שעות על אובייקטים וקשרים בזמן ש-FleetLink ישב בחוץ עם 200,000 קריאות ביום, RouteDesk החזיק שמונה שנות היסטוריה, שלושה שותפים דיברו שלוש שפות, הכספים עבדו עם גיליון אלקטרוני, ומאה אלף פניות בשנה שאלו איפה משלוח. אלה לא שאלות של מודל אובייקטים. אלה שאלות של נתוני ארגון. שרטטו את האינטגרציות המכוערות, את הגיליון האלקטרוני, את המערכת שאתם כביכול מוציאים משימוש. רשמו את האפסים. עברו על כל חץ. ואז אתם מוכנים לשנות את זה.

להרחבה

• התדריך של Steve Trucking, סעיפים 2–4, ותרשים מפת המערכות שלו.