شركات متعددة، تثبيت واحد، بلا عملاء مشتركين

إذا كنت تدير أكثر من شركة — قابضة لها فروع، أو امتياز تجاري، أو علامتين تستهدفان سوقين مختلفين، أو وكالة والكيان الذي انبثقت عنها — فأنت تعرف بالفعل شكل المشكلة. العلامات تتقاسم الأشخاص والأدوات وقسم المالية. أما العملاء فلا تتقاسمهم، ويجب ألا يبدو أنها تتقاسمهم.

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

ما تتمكن المجموعة فعلًا من مشاركته

الفصل ليس عزلًا لمجرد العزل. الأشياء التي تستحق المشاركة عبر المجموعة تُشارك عمدًا، وهي في معظمها الأشياء المملة — وهذا صحيح تمامًا، لأن الأشياء المملة هي حيث تعيش التكلفة المكررة:

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

السؤال الذي تطرحه المجموعة دائمًا ثانيًا

«هل يمكننا إعداد تقارير عبرها جميعًا؟» نعم — من موقع المجموعة نفسها، عمدًا وصراحةً، لا كنتيجة جانبية لحد نافذ. هذا التمييز هو التصميم كله: عبور الخط يجب أن يكون فعلًا قام به شخص ما بقصد، وبالصلاحية لذلك. ويجب ألا يكون أبدًا شيئًا يستطيع معرّفٌ طائش إنجازه بالخطأ.

والسؤال الذي يطرحونه ثالثًا: «ماذا لو بِعنا إحدى العلامات؟» الحد الذي تحفظه قاعدة البيانات هو أيضًا حد يمكنك استخراج نسخة نظيفة منه. وهذا ليس مصادفة — الفصل وقابلية النقل هما الخاصية نفسها من منظور اجتماعين مختلفين.