تخطَّ إلى المحتوى

أنصت إلى الأسماء

متاح أيضًا بـ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)

An empty distribution center at dawn: a truck backed to the dock, pallets of parcels, a route board, crew vests on hooks and a manifest on a clipboard.
صورة مولّدة بالذكاء الاصطناعي

الوحدة 1 من 6 في فصل نمذجة البيانات من أجل المعنى، الفصل 2 من دورة Data Architect. كل وحدة قائمة بذاتها. السابق: نظرة عامة على الفصل · التالي: ارسم العلاقات

السؤال الذي تجيب عنه هذه الوحدة: كيف أجد بدايات نموذج البيانات في محادثة عمل؟

من الأشياء التي أفعلها في أول مكالمة مع عميل أن أُنصت إلى الأسماء.

لا أتحدث عن جلسة التصميم الأولى. بل أتحدث عن تلك المحادثة الأولية التي ما زلت أحاول فيها أن أفهم العمل وما يحاولون تحقيقه.

هم يتحدثون. وأنا أُنصت.

وأُنصت إلى كلمات مثل:

شريك التجزئة (Retail Partner). المستلم (Recipient). مركز التوزيع (Distribution Center). بيان الشحنة (Manifest). التوصيلة (Delivery). المسار (Route). الطاقم (Crew). الشاحنة (Truck).

هذه الأسماء تلفت انتباهي فورًا، لأن في مكان ما من تلك المحادثة تكمن بدايات نموذج بياناتي.

لا أنتظر حتى أظن أنني فهمت المشكلة تمامًا. أبدأ في رؤية البيانات وأنا ما زلت أُنصت: أسمع الأسماء، وأبدأ في رسم كيف ترتبط ببعضها، وذلك الرسم يساعدني على صياغة المحادثة التالية. أحيانًا، بنهاية أول اجتماع مع عميل، يكون لدي بالفعل نموذج بياناتي الخاص مرسومًا.

بالنسبة لي، يبدأ ذلك بالأسماء.

هنا أريدك أن تقاوم غريزة تكون قوية بشكل خاص إذا كنت مسؤول Salesforce (admin) منذ فترة.

يقول العميل عميل، فتفكر:

Account.

ويقولون شخص، فتفكر:

Contact.

ويقولون مركز توزيع، فتتساءل فورًا عمّا إذا كنت تحتاج إلى كائن مخصص.

لا تفعل ذلك بعد.

في هذه المرحلة، لا يهمني ما إذا كان العميل سيصبح في النهاية حسابًا (Account)، أو حسابًا شخصيًا (Person Account)، أو كائنًا مخصصًا، أو شيئًا آخر. أريد أولًا أن أفهم العمل.

هذا هو الفرق بين نمذجة العمل وإعداد Salesforce. إذا بدأت بكائنات Salesforce، فقد قيّدت تفكيري مسبقًا بتنفيذ واحد. قد أنتهي تمامًا حيث توقعت، لكنني أريد أن أصل إلى هناك لأن العمل قادني إليه، لا لأن Account وContact كانا أول كائنين عرفتهما.

لذلك، لبضع دقائق، انسَ Salesforce. أنصت إلى الطريقة التي يصف بها من يديرون العمل فعلًا عالمهم.

قبل أن نُنصت إلى عمل تجاري، لنُنصت إلى شيء يفهمه الجميع بالفعل. عندما أعلّم هذا مباشرة، أبدأ بالكلاب.

إليك كلبًا: Marcus يملك Bella. وقد ربّتها Maple Ridge Kennels. إنها من سلالة لابرادور، وتعرف «اجلس» و«ابقَ» و«صافح».

أنصت إلى الأسماء: Marcus، وBella، وMaple Ridge Kennels، ولابرادور، و«اجلس». لكن هذه أسماء علم: أشياء بعينها. ما أريده هو نوع الشيء الذي ينتمي إليه كل اسم. Bella كلب (Dog). Marcus مالك (Owner). Maple Ridge Kennels مربٍّ (Breeder). لابرادور سلالة (Breed). «اجلس» حيلة (Trick). خمسة أسماء، خمسة مربعات مرشّحة.

أسماء نموذج الكلب مربعاتٍ بسيطة خمسة مربعات بسيطة، بلا خطوط بينها: المالك والمربّي جنبًا إلى جنب في الأعلى، والكلب تحتهما وبينهما، والسلالة والحيلة فوق بعضهما على اليمين. المالك المربّي الكلب السلالة الحيلة © 2026 Twinshark LLC · stevetecharc.com
Click to enlarge

ثم السؤال الذي أطرحه على كل اسم: هل هو شخص يؤدي وظيفة، أم قطعة من البيانات؟ Marcus شخص. لكن امتلاك Bella ليس وظيفة؛ إنه حقيقة عن Bella، وعاجلًا أو آجلًا سيسأل أحدهم: «من يملك هذا الكلب؟» لذلك ينتمي المالك إلى النموذج. أما المدرّب الذي علّم Bella المصافحة فهو شخص يؤدي وظيفة، وقد لا يحتاج أبدًا إلى مربع، إلا إذا بدأ العمل يسأل من علّم أي حيلة.

ولاحظ كلمة مرشّح. هل السلالة فعلًا مربع قائم بذاته، أم مجرد كلمة مكتوبة على الكلب؟ احتفظ بهذا السؤال؛ سنجيب عنه عندما نطبّق التطبيع في الوحدة 4.

هذه هي التقنية كلها، على شيء صغير. والآن لنُنصت إلى عمل حقيقي.

الأسماء تمنحك كيانات مرشّحة

Section titled “الأسماء تمنحك كيانات مرشّحة ”

لنُنصت إلى Steve Trucking، الشركة العائلية التي سنستخدمها طوال هذه الدورة. إنها توصل الأغراض الكبيرة (الثلاجات، والغسالات، وأجهزة التلفاز) من مراكز توزيع متاجر التجزئة الكبرى إلى منازل الناس، وتركّب بعضها.

في المحادثة الأولى نسمع:

  • شريك التجزئة (Retail Partner)
  • المستلم (Recipient)
  • مركز التوزيع (Distribution Center)
  • بيان الشحنة (Manifest)
  • التوصيلة (Delivery)
  • المسار (Route)
  • الطاقم (Crew)
  • الشاحنة (Truck)

هذا مفيد بالفعل. أستطيع أن أبدأ في وضع المربعات على السبورة.

لذلك ضع الأسماء في مستطيلات. هذا كل ما هي عليه في هذه المرحلة: مربعات. بلا خطوط، ولا ألوان، ولا شيء يقول Salesforce. لاحقًا في الدورة، ستبدأ الأشكال والألوان في أن تعني شيئًا. أما الآن، فالمستطيل مجرد شيء يتحدث عنه العمل.

ثم ابدأ في توجيهها. وأنت تضع كل مربع، عليك أن تفكر في أمرين: كيف ترتبط ببعضها، وما نوع البيانات التي تمثلها. بعضها بيانات عملاء: الشركات والأشخاص الذين نعمل معهم. وبعضها بيانات معاملات، مثل الطلبات وبنود الطلبات: الأشياء التي تحدث، مرة بعد مرة. وبعضها بيانات مرجعية، مثل المنتجات أو الخدمات التي يقدمها العمل: الأشياء التي يعتمد عليها العمل.

في Steve Trucking، شريك التجزئة والمستلم بيانات عملاء. وبيان الشحنة والتوصيلة والمسار معاملات. ومركز التوزيع والطاقم والشاحنة هي ما يعتمد عليه العمل.

الأسماء على السبورة ثمانية مربعات بسيطة، واحد لكل اسم سُمع في المحادثة الأولى مع Steve Trucking، مجمّعة حسب نوع البيانات. بيانات العملاء: شريك التجزئة والمستلم. بيانات المعاملات: بيان الشحنة والتوصيلة والمسار. البيانات المرجعية: مركز التوزيع والطاقم والشاحنة. لا خطوط بينها بعد. بيانات العملاء بيانات المعاملات البيانات المرجعية شريك التجزئة المستلم بيان الشحنة التوصيلة المسار مركز التوزيع الطاقم الشاحنة © 2026 Twinshark LLC · stevetecharc.com
Click to enlarge

لكن هناك كلمة مهمة هنا: مرشّح.

الاسم دليل. ليس تلقائيًا كيانًا، وبالتأكيد ليس تلقائيًا كائنًا في Salesforce.

عندما أكون في جلسة استكشاف، أكتب كل اسم. وكل اسم يقولونه، أسأل نفسي عنه سؤالًا واحدًا: هل هذا شخص يؤدي وظيفة، أم قطعة من البيانات؟ مدير تطوير الأعمال شخص يؤدي وظيفة. هذا مستخدم، أو دور، وربما مجموعة أذونات. الطلبات والفواتير وبنود الطلبات: هذه قطع من البيانات. كلاهما مهم، لكنهما ينتهيان في أماكن مختلفة جدًا من التصميم، وفرزهما مبكرًا يوفّر عليّ رسم مربع لكل مسمى وظيفي في الهيكل التنظيمي.

والآن، بعض تلك الأسماء سيكون أشخاصًا. في Steve Trucking، هؤلاء هم المستلم الذي ينتظر الثلاجة، والأشخاص لدى شريك التجزئة الذين يرسلون بيان الشحنة، والطاقم: السائقون والمساعدون على الشاحنة. هذه أدوار، وقد لا يبدو الدور بيانات. لكن عندما يتصرف الناس في البيانات، أو يرتبطون بها، فهم يحتاجون إلى أن يُمثَّلوا هم أنفسهم في البيانات. من وصّل هذا؟ من وقّع على استلامه؟ من أرسل بيان الشحنة؟ لذلك ينتهي كثير من الأدوار، وأحيانًا كلها، في النموذج أيضًا.

أنصت إلى طريقة حديث Steve Trucking، وستلاحظ شيئًا. إنهم لا يقولون «العميل» فحسب أبدًا. هناك نوعان من العملاء. شريك التجزئة هو متجر التجزئة الكبير الذي توصل Steve Trucking لصالحه: يرسل بيان الشحنة ويدفع عن كل توصيلة. والمستلم هو الشخص الذي تُوصَّل الثلاجة إليه. اشتراها المستلم من المتجر، وقد لا يكون سمع بـSteve Trucking قط.

لو كتبت مربعًا واحدًا اسمه العميل، لكنت مزجت شيئين مختلفين تمامًا.

ربما يكون مركز التوزيع مهمًا بما يكفي ليكون له سجله الخاص، وتاريخه، وعلاقاته، وسماته.

وربما يتضح أن اسمًا آخر ليس أكثر من سمة لشيء آخر.

هذا ما نحاول اكتشافه. لسنا ننشئ كائنات بعد. بل نبني فهمنا للعمل.

والآن أنصت إلى العلاقات

Section titled “والآن أنصت إلى العلاقات ”

الأسماء تمنحني نقطة بداية. ثم أُنصت إلى الطريقة التي يربط بها العمل بينها.

شريك التجزئة يُشغّل مراكز توزيع.

شريك التجزئة يرسل بيان شحنة لكل مركز توزيع (DC) ويوم توصيل.

بيان الشحنة يسرد التوصيلات.

التوصيلة تذهب إلى مستلم.

المسار هو جولة يوم واحد من نحو عشر محطات (Stops).

طاقم من شخصين يُشغّل شاحنة.

الآن يحدث شيء ما. لم أعد أنظر إلى قائمة أسماء. بل بدأت أرى نموذجًا.

أول الخطوط بين الأسماء مربعات Steve Trucking الثمانية من الوحدة 1، لا تزال مجمّعة بوصفها بيانات عملاء وبيانات معاملات وبيانات مرجعية، وقد رُبطت الآن بخطوط بسيطة عليها تسميات ودون علامات على أطرافها: شريك التجزئة يُشغّل مراكز توزيع ويرسل بيانات شحنة، وبيان الشحنة يسرد التوصيلات، والتوصيلة تذهب إلى مستلم، والطاقم يُشغّل شاحنة. أما المسار فلا خط له بعد. بيانات العملاء بيانات المعاملات البيانات المرجعية يُشغّل يرسل يسرد تذهب إلى يُشغّل شريك التجزئة المستلم بيان الشحنة التوصيلة المسار مركز التوزيع الطاقم الشاحنة © 2026 Twinshark LLC · stevetecharc.com
Click to enlarge

وهنا أيضًا تبدأ الأسئلة في الظهور.

هل يمكن أن يكون لشريك التجزئة أكثر من مركز توزيع؟

هل التوصيلة هي الشيء نفسه مثل المحطة؟

هل يمكن لمحطة واحدة أن توصل إلى مستلمَين اثنين؟

هل الطاقم دائمًا الشخصان نفسهما؟

هل يهمنا أي طاقم كانت لديه أي شاحنة الشهر الماضي، أم فقط أي شاحنة يقودونها اليوم؟

لاحظ ما نفعله. لسنا نطرح أسئلة عن Salesforce بعد. بل نطرح أسئلة عن العمل. وتلك الإجابات هي التي ستقود في النهاية تصميم Salesforce.

نموذجك الأول لا يحتاج إلى أن يكون مثاليًا

Section titled “نموذجك الأول لا يحتاج إلى أن يكون مثاليًا ”

لا أتوقع أن تصمد المربعات الأولى التي أرسمها دون تغيير. بل إنني سأرتاب لو صمدت.

الغرض من النموذج الأول ليس أن يكون صحيحًا. الغرض أن يمنحنا شيئًا ملموسًا بما يكفي لنكتشف أين نخطئ.

ضع التوصيلة والمسار والطاقم والشاحنة على السبورة، وسيستطيع الناس التفاعل معها.

«في الحقيقة، التوصيلة ليست دائمًا غرضًا واحدًا. قد تكون غسالة ومجففًا ونقل القديمين بعيدًا.»

جيد. أخبرني بالمزيد.

«نحن لا نكلّف طاقمًا بتوصيلة. بل نكلّف الطاقم بمسار.»

رائع. ما الذي على المسار؟

«وإذا كان هناك تركيب، لا يستطيع الطاقم إغلاق المحطة حتى تكتمل قائمة التحقق والصور.»

الآن نتعلم شيئًا مهمًا.

حوّل المخطط محادثة غامضة إلى شيء نستطيع تحدّيه. هذا أحد الأسباب التي تجعلني أحب النمذجة مبكرًا. لا أحاول إبهار الحاضرين بمخطط جميل. بل أحاول أن أتعلم أسرع.

النموذج جزء من المحادثة.

هذا هو نموذجك المفاهيمي

Section titled “هذا هو نموذجك المفاهيمي ”

هناك اسم رسمي لما بدأنا في بنائه: نموذج بيانات مفاهيمي.

على هذا المستوى، يهمني الأشياء المهمة التي يهتم بها العمل وكيف ترتبط ببعضها. لا يشغلني بعد الكائنات القياسية مقابل المخصصة، ولا أسماء API للحقول، ولا علاقة البحث مقابل رئيسي-تفصيلي، ولا الحقول الإلزامية، ولا الفهارس، ولا الأتمتة، ولا Apex أو عمليات Flow. هذه الأشياء مهمة، وسنصل إليها. لكن إذا قررناها قبل أن نفهم ما ننمذجه، فنحن نحل المشكلة الخطأ أولًا.

ينبغي أن يكون النموذج المفاهيمي مفهومًا للحاضرين الذين لا يعرفون Salesforce. هذا اختبار مفيد. إذا احتجت إلى شرح معنى Delivery__c قبل أن يستطيع مدير العمليات قراءة مخططي، فقد انتقلت إلى التنفيذ مبكرًا جدًا.

أريدهم أن ينظروا إلى النموذج ويقولوا:

«نعم، هكذا يسير عملنا.»

أو، وهذا أفضل:

«لا، ليس هكذا يسير.»

لأن لدي الآن شيئًا أصلحه.

التقنية نفسها تنجح عندما لا يتحدث أحد

Section titled “التقنية نفسها تنجح عندما لا يتحدث أحد ”

هذا ليس شيئًا أستخدمه في استكشاف العملاء فقط. بل ينجح أيضًا عندما يكون «العميل» وثيقة.

عندما أعمل على وثيقة متطلبات، أفعل الشيء نفسه تقريبًا. ما مفاهيم العمل المهمة؟ ما العلاقات التي تُوصف؟ ما الذي يتكرر ظهوره؟ ما الذي له دورة حياته الخاصة، أو يحتاج إلى أن يُعرَّف بذاته، أو يحتاج إلى تاريخ؟ ما الذي يُنشأ، أو يُغيَّر، أو يُسند، أو يُنقل، أو يُجدوَل، أو يُوقَف؟

هذه هي الأشياء نفسها التي أُنصت إليها في ذلك الاجتماع الأول. وعلى الورق، تحوّل تلك الأدلة فقرات المتطلبات إلى نموذج أستطيع التفكير فيه، وإلى أسئلة أفضل للمحادثة التالية.

النموذج ليس مجرد شيء تُنتجه بعد أن تحل المشكلة. إنه من الأدوات التي تستخدمها لحل المشكلة.

ما الذي يقرره المعماري هنا

Section titled “ما الذي يقرره المعماري هنا ”

بنهاية هذه الجولة الأولى، أحاول أن أقرر:

  • أي الأسماء تمثّل كيانات مرشّحة ذات معنى.
  • أي الكلمات المختلفة تمثّل مفهوم العمل نفسه، وأي كلمة واحدة تُخفي مفهومين (مثل «العميل»).
  • أي المفاهيم تحتاج إلى سجل ودورة حياة خاصين بها.
  • كيف ترتبط المفاهيم الرئيسية ببعضها.
  • ما الأسئلة التي يحتاج العمل إلى الإجابة عنها قبل أن أستطيع نمذجتها بثقة.

أنا لا أقرر تنفيذ Salesforce بعد. علينا أولًا أن نفهم العمل جيدًا بما يكفي لنرسمه. وبمجرد أن تصبح الأسماء على السبورة، فإن الشيء التالي الذي أريد أن أفهمه هو الخطوط بينها.

ما بعد الاختبار: ما الذي يغيّره الذكاء الاصطناعي. أعطِ أداة ذكاء اصطناعي وثيقة متطلبات، وستجد الأسماء، وتقترح الكيانات، وترسم العلاقات في ثوانٍ. استخدمها لتسريع الاستكشاف، لكن لا تُسند الفهم إلى غيرك: لا تستطيع أن تعرف أن «العميل» يعني شيئين مختلفين في Steve Trucking ما لم يخبرك العمل بذلك. ضع نموذجها الأول أمام من يديرون العمل واسألهم: «هل هكذا يسير عملكم حقًا؟»