البوابات والحسابات الفرعية والمؤسسات المتداخلة: سؤال تعدّد المستأجرين لمزوّدي التدريب

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

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

ما يطلبه العميل فعلاً

جرِّد وثيقة المتطلبات تبقَ أربعة طلبات. تصل بهذا الترتيب تقريباً، ويطلبها كل عميل تقريباً يدفع لك لتدرّب أشخاصه.

1. نطاقهم الخاص. `learn.acmecorp.com`، لا `yourcompany.lms-vendor.com/acme`. بشهادة لا تجعل المتصفّح يشتكي.
2. مسؤولوهم هم. شخص من جهة العميل يستطيع إضافة مستخدمين، ونشر مقرر، وسحب تقرير دون أن يراسلك أولاً.
3. تقاريرهم هم. أرقام عن أشخاصهم لا عن أشخاص أحد غيرهم، بشكل يستطيعون وضعه أمام مجلس إدارتهم.
4. بياناتهم منفصلة عن بيانات العملاء الآخرين. يُسأل عنها عادةً بوصفها سؤالاً أمنياً، وهي دائماً التي تصعّدها المشتريات.

كل بنية تجيب عن بعض هذه وتُخفق في غيرها. والإخفاقات متوقّعة ما إن تعرف على أي نموذج تقف.

ثلاث بنى، وثلاثة سقوف

النماذج الثلاثة أدناه ليست سلّم نضج. بل هي منتجات مختلفة لمشترين مختلفين، ولكلٍّ منها نقطة بعينها يتوقّف عندها.

البوابات

البوابة باب أمامي منفصل يطلّ على كومة مشتركة من المحتوى والمستخدمين. تعرّف جمهوراً — موظفين، أو شركاء، أو شركة عميلة واحدة — وتعطيه رابطاً ومظهراً، وتُسنِد إليه أشخاصاً. وعدة منصات مؤسسية مبنية حول هذا الشكل؛ وLearnUpon أوضح مثال، إذ التسليم عبر بوابات متعددة هو صلب المنتج.

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

وقائمة البوابات مسطّحة، وهناك يتوقّف الأمر. فعميل له ثلاثة أقاليم ومدير تدريب على مستوى المجموعة ليس بوابةً واحدة، وليس ثلاث بوابات لا صلة بينها كذلك. والمزوّدون على نموذج مسطّح ينتهون إلى ترميز التسلسل الهرمي الغائب في الأسماء — `Acme` و`Acme - EMEA` و`Acme - APAC` — ثم إعادة تركيب رؤية المجموعة يدوياً في جدول بيانات كل ربع سنة. ولأدوار المسؤولين المشكلة نفسها: فالحقوق تُمنَح لكل بوابة، فيحصل مدير المجموعة على ثلاثة منح لا يتذكّر أحد سحبها حين يُغلَق إقليم.

الحسابات الفرعية

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

والسؤال الجدير بالطرح هو أين يُفرَض الحدّ. فإن كان الحساب الفرعي عموداً في صف، فالفصل هو ما يتذكّر كود التطبيق أن يرشِّح به.

-- حدّ يعيش في كود التطبيق
select * from enrolments where account_id = :current_account;

-- حدّ يعيش في قاعدة البيانات
create policy tenant_read on enrolments
  for select using (org_id = any (current_org_scope()));

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

المؤسسات المتداخلة

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

Your training company              you administer everything below
├── Acme Corp                      learn.acmecorp.com
│   ├── Acme EMEA                  regional admin, EMEA data only
│   └── Acme APAC
├── Borden Group                   training.bordengroup.com
│   └── Borden Manufacturing
└── Public catalogue               open enrolments, your brand

ويتبع ذلك أمران لا يستطيع نموذج مسطّح أن يعطيك إياهما. الأول أن شكل العميل نفسه قابل للتمثيل دون اصطلاحات تسمية — فأنت لا ترمّز التسلسل الهرمي في نصوص. والثاني هو النطاق: فالدور الممنوح عند عقدة ينطبق على كل ما تحت تلك العقدة. فمدير التدريب في Acme يرى Acme والإقليمين معاً. ومدير EMEA يرى EMEA. وأنت ترى ذلك كله. ولا أحد في Borden يرى شيئاً منه، ولا شيء من ذلك تقرير كتبه أحد يدوياً.

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

كيف يجيب كل نموذج عن الطلبات الأربعة

• نطاقهم الخاص. البوابات: نعم عادةً، واحد لكل بوابة، وبكلفة إضافية أحياناً. الحسابات الفرعية: مسار أو نطاق فرعي من نطاق المزوّد في الغالب، لا نطاق العميل نفسه. المؤسسات المتداخلة: نطاق لكل مؤسسة، عند أي عمق، إن كانت المنصة تُصدر الشهادات تلقائياً.
• مسؤولوهم هم. البوابات: نعم، لكن بنطاق البوابة الواحدة، فالمسؤول على مستوى المجموعة يحتاج منحاً لكل بوابة. الحسابات الفرعية: مسؤولو الأصل عادةً برؤية مرشَّحة. المؤسسات المتداخلة: مسؤول عند أي عقدة، بحقوق تتدرّج إلى كل ما تحتها.
• تقاريرهم هم. البوابات: لكل بوابة، مع تجميعات عابرة للبوابات بحسب المنتج. الحسابات الفرعية: تقرير واحد بمرشِّح عادةً، وهو مقبول حتى يطلب عميل أن يراه بنفسه. المؤسسات المتداخلة: كل عقدة نطاق تقارير، فرؤية المجموعة ورؤية الإقليم هما الاستعلام نفسه عند ارتفاعين مختلفين.
• بياناتهم منفصلة. البوابات والحسابات الفرعية: منفصلة بقدر ما يجعلها كود التطبيق. المؤسسات المتداخلة: منفصلة بقدر ما تفرضه المنصة تحت مستوى التطبيق — واسأل تحديداً هل القاعدة موضوعة في قاعدة البيانات.

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

خمسة أسئلة تطرحها على مزوّد

1. هل تستطيع المؤسسة أن تحتوي مؤسسة أخرى، وإلى أي عمق يصل ذلك؟
2. إن منحت شخصاً دور مسؤول عند عقدة واحدة، فهل ينطبق على كل ما تحتها، أم أمنحه مرة أخرى عند كل مستوى؟
3. هل يُفرَض حدّ المستأجر في قاعدة البيانات أم في كود التطبيق؟
4. هل يستطيع كل عميل أن يحصل على نطاقه وشهادته، أم على مجلّد فرعي من نطاقكم فقط؟
5. حين يغادر عميل، ما الذي تحذفه إزالته بالضبط — وهل تستطيعون أن تروني ذلك؟

واطلب الإجابات في مستند مشترك لا في مكالمة. فالسؤال الثاني بخاصة يميل إلى أن يُنتج عرضاً لشاشة لا جواباً، والفرق بين الاثنين سنةٌ من المنح اليدوية.

لماذا يحدّد الجواب ما تستطيع بيعه

إن كانت منصتك لا تستطيع تخصيص مظهر إلا لباب أمامي واحد، فأنت تبيع مقاعد على نظامك أنت. فموظفو العميل يسجّلون الدخول إلى علامتك، ومدير التدريب عند العميل يطلب منك الأرقام، وكل تجديد محادثة عن كلفة منصتك لكل مستخدم.

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

والنصف الآخر تشغيلي. فالمزوّدون الذين يتجاوزون نموذجاً مسطّحاً ينتهون غالباً إلى تشغيل تنصيب لكل عميل. وMoodle صريحة في أن تعدّد المستأجرين ليس جزءاً من المنتج الأساسي — ففصل الحرم الجامعية أو مؤسسات العملاء يعني Moodle Workplace، أو عقد شريك، أو تنصيبات متوازية. والتنصيبات المتوازية تعني ترقيات متوازية، ونسخاً احتياطية متوازية، وترقيعات أمنية متوازية، وطبقة تقارير تعيد بناءها خارج المنصة. وهو يعمل ما دام عدد موظفيك أكبر من عدد عملائك.

أين تقع Lurno

Lurno مبنية على النموذج الثالث. فالمؤسسة تستطيع أن تحتوي مؤسسات فرعية، لكلٍّ منها هويتها البصرية ونطاقها المخصّص بشهادة TLS تلقائية. وداخل المؤسسة شجرة ثانية من الفروع، والدور الممنوح عند فرع يتدرّج إلى ما تحته — وهو الجواب عن السؤال الثاني من أسئلة المزوّدين أعلاه، والسبب في أن مدير التدريب على مستوى المجموعة منحٌ واحد لا منح لكل إقليم.

والحدّ مفروض في Postgres لا في التطبيق: 868 سياسة أمان على مستوى الصف عبر 676 ترحيلاً، فمرشِّح ناقص في نقطة نهاية جديدة يُرجع لا شيء بدل أن يُرجع متعلّمي شخص آخر. وذلك هو الادّعاء الجدير بالتحقّق منه مع أي مزوّد، ونحن منهم — والتفاصيل في صفحة الأمان، وجانب الهوية البصرية والنطاقات في العلامة البيضاء.

شكلان يعمل بهما هذا بالفعل، دون تسمية أحد: أكاديمية مؤسسية تقدّم التدريب لـ15 شركة عميلة من مستأجر واحد، ودار نشر K-12 تدير 114 مدرسة على منصة واحدة. وكلاهما البنية نفسها بعرضين مختلفين.

وقيدان يستحقان الذكر صراحةً، لأنهما يغيّران التقييم. الدفع والسداد قيد التطوير — فاليوم يُفوتَر العميل خارج المنصة، فإن كنت تحتاج أن يدفع المتعلّمون بالبطاقة عند نقطة التسجيل، فتلك محادثة لا ميزة. وتسجيل الدخول عبر الشريك (SSO الصامت) متاح، لكن SAML وOIDC ضمن خطة التطوير ولم يُطرحا؛ فإن كان قسم تقنية المعلومات عند عميل قد حسم كيف سيصادق موظفوه، فاسأل عن ذلك قبل أي شيء آخر. وبقية النموذج للمزوّدين الذين يعيدون بيع التدريب مبيّنة في صفحة مزوّدي التدريب.

الخلاصة

البوابات تعطي العميل باباً أمامياً. والحسابات الفرعية تعطيه رؤية مرشَّحة. والمؤسسات المتداخلة تعطيه حدّاً، والحدّ هو ما تستطيع أن تضع له سعراً. فاعرف أيّها تشتري قبل أن يطلب منك عميل الشيء الذي لا يستطيع نموذجك أن يقوله.