خريطة أنظمة 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 في فصل فهم بيانات المؤسسة، الفصل 4 من دورة Data Architect. كل وحدة قائمة بذاتها. السابق: استراتيجية الـ org قرار على مستوى خريطة الأنظمة · التالي: الفصل التالي، جودة البيانات وحوكمتها
السؤال الذي تجيب عنه هذه الوحدة: ماذا تخبرنا خريطة أنظمة حقيقية قبل أن نصمم أي شيء؟
ظلّ هذا الفصل يُرجِع الكاميرا إلى الخلف خطوة بعد خطوة: Salesforce بوصفه نظامًا واحدًا بين أنظمة كثيرة، وأنواع البيانات، والأنظمة المحيطة بـ Salesforce، وكيف نرسم خريطة الأنظمة، واستراتيجية الـ org. والآن لنجمع كل ذلك على Steve Trucking. لكننا لن نصلح أي شيء بعد. هذا هو الانضباط المطلوب: ارسم ما هو موجود، وتتبّع كل سهم، وانظر ماذا تخبرك به خريطة الأنظمة.
لنبدأ بما نعرفه
Section titled “لنبدأ بما نعرفه ”تشغّل Steve Trucking مؤسسة Salesforce (org) واحدة، في الولايات المتحدة. يتولى Service Cloud الحالات الواردة من المستلمين (Recipients) وشركاء التجزئة (Retail Partners)؛ ويدير Field Service المواعيد والطواقم وتطبيق الهاتف المحمول؛ ويمنح Experience Cloud شركاء التجزئة بوابة لا تُستخدم اليوم إلا للمطالبات والتقارير؛ ويتتبّع Sales Cloud عقود الشركاء والعطاءات الخاصة بمراكز توزيع (DCs) جديدة. لذلك يوضع Salesforce في المنتصف.
على اليسار، الناس: 45 منسّق إرسال يعملون داخل مراكز التوزيع التابعة لشركاء التجزئة، ونحو 700 فرد من الطواقم على 330 شاحنة، و60 موظفًا في خدمة العملاء، و40 موظفًا في العمليات والمالية والمبيعات، ونحو 300 مستخدم من شركاء التجزئة. هذا وحده يخبرنا بشيء: ليس هذا نظام CRM لقسم واحد، بل منصة تشغيلية لمعظم أعمال الشركة. لكنه لا يزال صندوقًا واحدًا. لنرَ الآن ما الذي يحيط به.
Steve Trucking اليوم، قبل تنفيذ سليم. كل بيان شحنة يصل إلى RouteDesk؛ ويعيد المنسقون إدخال المسارات في Salesforce والمحطات المكتملة في الاتجاه المعاكس، يدويًا؛ وFleetLink ينقصه الاتصال.
ضع علامة على ما هو خاطئ
Section titled “ضع علامة على ما هو خاطئ ”هذه حالة راهنة، قبل تنفيذ سليم، وأنا أكتب ذلك على الرسم نفسه. ثم أفتح لوحة الألوان. على خريطة نظام مكتمل لا أستخدم الأحمر؛ أما على الحالة الراهنة فأستخدمه. الأحمر يدل على عملية سيئة أو غير سليمة، والخط المتقطع يدل على شيء يُنجَز يدويًا، والنقاط الحمراء تدل على اتصال مفقود. وحذف سهم يقول شيئًا أيضًا. لا شيء من هذا للزينة: كل خط أحمر متطلّبٌ ينتظر أن يُكتب.
ثلاثة شركاء، ثلاث عمليات تكامل
Section titled “ثلاثة شركاء، ثلاث عمليات تكامل ”يرسل شركاء التجزئة الثلاثة بيانات الشحنات بثلاث طرق مختلفة، لذا ارسم كل واحد منهم على حدة.
تضع 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 لا يزال موجودًا
Section titled “RouteDesk لا يزال موجودًا ”RouteDesk هو أداة الإرسال وتخطيط المسارات المكتبية القديمة التي يستخدمها المنسقون في كل مركز توزيع لتحويل بيانات الشحنات إلى مسارات. يحتفظ بتاريخ ثماني سنوات من التوصيلات، ومن المقرر إيقافه. ارسمه على أي حال. من الأخطاء الشائعة حذف النظام «الذي سنتخلص منه». متى؟ لنقل إن الجواب ثمانية عشر شهرًا. إذن هو جزء من المعمارية لمدة ثمانية عشر شهرًا على الأقل، وتاريخه الممتد ثماني سنوات، نحو خمسة ملايين توصيلة، لا يختفي حين يختفي التطبيق. وانظر إلى ما تكشفه خريطة الأنظمة: RouteDesk وSalesforce غير متصلين. تعمل الطواقم على محطاتها في تطبيق Field Service في Salesforce، لكن المسارات تُبنى في RouteDesk، فيعيد المنسقون إدخالها في Salesforce كل مساء، ثم يعيدون إدخال المحطات المكتملة في RouteDesk حتى يتمكن من إرسال الحالة إلى الشركاء. نحو 3,300 محطة يوميًا، مرتين، يدويًا. هذا متقطع وأحمر على الرسم. ويخبرك أيضًا أن webhook شركة Redrock «لحظة حدوثها» ليس لحظيًا فعلًا. ما الذي يملكه RouteDesk اليوم؟ ما الذي يعتمد عليه؟ أي تاريخ يجب أن يبقى بعده، وأين: في Salesforce، أم في مستودع البيانات، أم في أرشيف؟ لن نجيب بعد. خريطة الأنظمة كشفت الأسئلة فحسب.
FleetLink جزيرة معزولة
Section titled “FleetLink جزيرة معزولة ”يتلقى FleetLink، منصة التتبّع عن بُعد (telematics)، بيانات GPS من كل شاحنة: نحو 200,000 قراءة يوميًا، من كل شاحنة، في كل دقيقة تعمل فيها. وهو غير متصل بأي شيء. ينظر إليه المنسقون على شاشة منفصلة. لذا ارسم FleetLink بلا أسهم. لا خط تكامل سحري لمجرد أننا نظن أنه يجب أن يكون هناك واحد.
ثم عُدّ الأصفار: 200,000 يوميًا تعني أكثر من 70 مليونًا في السنة. هذا ليس «لدينا بيانات GPS». إنه مصدر بيانات متدفقة بأصفار كثيرة، يقع خارج تجربة Salesforce. هل يحتاج Salesforce إلى 70 مليون قراءة في السنة؟ على الأرجح ليس كلها. هذا سؤال تصميم لوقت لاحق.
للمالية حقيقتها الخاصة
Section titled “للمالية حقيقتها الخاصة ”يصدر نظام ERP المالي فواتير لكل شريك تجزئة عن كل توصيلة وتركيب وإزالة للقديم، ويدفع حوافز الطواقم. وتصل إليه أعداد التوصيلات عبر جدول بيانات شهري. ارسم جدول البيانات. لا تستبدل به سهم API أنيقًا لأننا معماريون ونعرف أفضل؛ إنه جزء من المعمارية الحالية. وبمجرد رسمه تأتي الأسئلة: من يُعدّه، ومن أي نظام، ومن يراجعه، وماذا لو تغيّرت توصيلة بعد إرساله، ورقم مَن يُعتمد؟ هناك مال مرتبط بالإجابات.
Snowflake يتلقى تصديرًا أسبوعيًا
Section titled “Snowflake يتلقى تصديرًا أسبوعيًا ”يحتفظ Snowflake بتحليلات العمليات والمالية، ويُغذّى بـتصدير أسبوعي. لا يستطيع Snowflake فعل ذلك بنفسه؛ هناك شيء في المنتصف يفعله: مهمة تصدير مجدولة، تعمل خارج Salesforce، تسحب البيانات عبر Bulk API وتحمّلها في Snowflake. مكان التحليلات يتبع مكان البيانات، وSnowflake هو بالفعل البيت التحليلي. لكن التوقيت يخبرنا بشيء أيضًا. «ماذا حدث الشهر الماضي؟» التغذية الأسبوعية كافية. «أين هذه التوصيلة الآن؟» لن أبدأ من Snowflake. المؤسسة نفسها، وحمل عمل مختلف، وحداثة بيانات مختلفة، وجواب مختلف.
الهوية لا تصل إلى الجميع بالطريقة نفسها
Section titled “الهوية لا تصل إلى الجميع بالطريقة نفسها ”يوضع مزوّد الهوية المؤسسي فوق Salesforce. يستخدم موظفو المكاتب تسجيل الدخول الموحّد (single sign-on). لكن المنسقين والطواقم يسجلون الدخول ببيانات اعتماد Salesforce. لذا فإن خط ثقة واحدًا من مزوّد الهوية (IdP) إلى Salesforce سيُخفي نصف القصة. السؤال الحقيقي هو أي المستخدمين يسجلون الدخول عبر أي مسار، ومكان ذلك على خريطة الأنظمة.
في تجربة المستلم فجوة
Section titled “في تجربة المستلم فجوة ”يرسل مزوّد الرسائل النصية والبريد الإلكتروني إلى المستلمين رسالة عامة من RouteDesk مفادها «توصيلتك غدًا». لا يوجد رابط تتبّع. وفي الوقت نفسه هناك نحو 180,000 حالة في السنة، ونحو 60% منها «أين توصيلتي؟»: قرابة 108,000 حالة في السنة تطرح السؤال نفسه. ضع هذا الآن بجانب FleetLink. الشركة تعرف أين شاحناتها. ومستلموها يواصلون الاتصال ليسألوا. والنظام الذي يعرف غير متصل بالنظام الذي يجيب. لست بحاجة إلى تصميم الحل بعد. خريطة الأنظمة تروي القصة بالفعل.
ضع الأصفار في الجرد
Section titled “ضع الأصفار في الجرد ”الآن عُدّ ما يتحرك. كما في الوحدة 4، لا توضع الأصفار على الأسهم؛ بل في الجرد الذي يقف خلف الصورة، حيث ستقود الآليات حين نصمم. نحو مليون توصيلة في السنة، ونحو 3,300 يوميًا، بنمو 30% سنويًا؛ ونحو 1.6 بند لكل توصيلة؛ ونحو ثمانية تحديثات حالة لكل توصيلة، أي ثمانية ملايين تحديث حالة في السنة اليوم؛ وأربعة إلى خمسة ملايين صورة في السنة، محفوظة حاليًا على هواتف الطواقم الشخصية؛ ونحو 200,000 قراءة GPS يوميًا؛ ونحو 180,000 حالة في السنة. السهم المعنون «حالة التوصيلة» ليس رسالة عابرة. الصناديق تخبرك بما هو موجود. والأسهم تخبرك بما يتحرك. والأصفار تخبرك إن كانت افتراضاتك ستصمد أمام الواقع.
الجرد الذي يقف خلف خريطة أنظمة Steve Trucking: الحجم بجانب الآلية التي سيقودها.
لا معمارية مستهدفة بعد، ومع ذلك أستطيع أن أرى أين تعيش البيانات المهمة، وما نوعها، وما سرعة حركتها، وكيف تتبادلها الأنظمة.
ما بعد الاختبار: ما الذي يغيّره الذكاء الاصطناعي. لنفترض أن Steve Trucking بنت وكيلًا يجيب عن سؤال المستلم «أين توصيلتي؟». أي نظام ينبغي أن يسأل؟ Salesforce يعرف الموعد، وFleetLink يعرف مكان الشاحنة، وبيان شحنة الشريك هو الذي عرّف التوصيلة. خريطة الأنظمة الحالية هي خريطة الوكيل، وقبل أن يتمكن الوكيل من الإجابة بأمان، على المعماري أن يعرف أي نظام هو النظام المرجعي المعتمد لكل معلومة ومدى حداثتها. وجّه وكيلًا إلى المصدر الخطأ، فتتحول البيانات القديمة إلى إجابة واثقة.
اقرأ الألم، ولا تصلحه بعد
Section titled “اقرأ الألم، ولا تصلحه بعد ”تراجع خطوة إلى الوراء. ثلاثة شركاء، وثلاثة أنماط تكامل. أداة إرسال قديمة تحتفظ بتاريخ ثماني سنوات، ومنسقون يعيدون إدخال 3,300 محطة يوميًا في Salesforce ثم في الاتجاه المعاكس. منصة تتبّع عن بُعد بـ 200,000 قراءة يوميًا، غير متصلة. المالية تعدّ التوصيلات من جدول بيانات شهري. التحليلات متأخرة أسبوعًا. تسجيل دخول موحّد لبعض المستخدمين دون غيرهم. لا رابط تتبّع، و108,000 حالة في السنة تسأل أين التوصيلة. وكل ذلك ينمو 30% سنويًا.
هذه معمارية كثيرة من صورة واحدة. والإغراء هو أن تبدأ في إصلاحها. لا تفعل. ليس بعد. أريدك أن ترتاح لترك رسم الحالة الراهنة قبيحًا، لأن الحالة الراهنة أحيانًا قبيحة. الهدف ليس إبهار أحد برسم نظيف؛ بل فهم مشترك للواقع. أعِد التصميم وأنت توثّق، فتفقد خط الأساس. لاحقًا أريد أن أقول: هذا ما كان موجودًا، وهذه هي المشكلة التي حللناها، وهذا ما غيّرناه، ولماذا. يبدأ الفصل 6 باتخاذ قرارات حول الملكية والهوية، وتجمع نقطة التحقق 1 الجزء 1 كله. أما دورة Integration Architect فتصمم تدفقات الشركاء بعمق.
ما الذي يقرره المعماري هنا
Section titled “ما الذي يقرره المعماري هنا ”في هذه المرحلة لا يقرر المعماري المعمارية المستهدفة. القرار هو ما إذا كانت الحالة الراهنة مفهومة بما يكفي لتصميم واحدة:
- أي الأنظمة وفئات المستخدمين ومخازن البيانات والشركاء الخارجيين موجودون فعلًا اليوم.
- ما البيانات التي تعبر كل حدّ مهم، وفي أي اتجاه، وبأي تواتر، وبأي آلية.
- أين تعيش الآن البيانات التشغيلية والتحليلية والمتدفقة والتاريخية وغير المهيكلة.
- أي التدفقات تحمل أكبر حجم وتستحق الاهتمام مبكرًا.
- أي الفجوات والخطوات اليدوية والأنظمة غير المتصلة والمرجعيات غير الواضحة والأنماط غير المتسقة تصبح أسئلة تصميم صريحة.
بدأ هذا الفصل بفكرة واحدة: ارسم خريطة الأنظمة قبل أن تصمم الـ org. لو بدأت بنموذج بيانات Steve Trucking، لربما قضيت ساعات في الكائنات والعلاقات بينما FleetLink يقبع في الخارج بـ 200,000 قراءة يوميًا، وRouteDesk يحتفظ بتاريخ ثماني سنوات، وثلاثة شركاء يتحدثون ثلاث لغات، والمالية تستخدم جدول بيانات، ومئة ألف حالة في السنة تسأل أين التوصيلة. هذه ليست أسئلة نموذج كائنات. إنها أسئلة بيانات مؤسسة. ارسم عمليات التكامل القبيحة، وجدول البيانات، والنظام الذي يُفترض أنك ستوقفه. اكتب الأصفار. تتبّع كل سهم. عندها تكون مستعدًا لتغييره.
للاستزادة
Section titled “للاستزادة ”- الملخص الخاص بـ Steve Trucking، الأقسام 2–4، ومخطط خريطة الأنظمة الخاص به.