اختيار نظام وثائق لمجموعة قابضة وشركات تابعة مستقلة

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

لماذا تختلف المجموعة القابضة عن شركة كبيرة واحدة؟

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

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

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

ثلاث بنى ممكنة وما يترتب على كل منها

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

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

ما الوثائق التي تعيش في المستويين؟

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

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

الصلاحيات: أين يفشل التصميم عادة

الصلاحيات في مجموعة قابضة لها بعدان: الكيان (أي شركة) والوظيفة (أي عمل). المدير المالي في الشركة (أ) يرى مالية (أ) فقط. المدير المالي للمجموعة يرى مالية كل الشركات. مراجع داخلي يرى ما يُسند إليه في خطة المراجعة، ولمدة المهمة. محامٍ في الإدارة القانونية المشتركة يرى العقود التي أُحيلت إليه، لا كل العقود.

المصفوفة التالية نموذج مبسط لما يجب أن تطلب من المورد إثباته عمليًا، وليست تصميمًا نهائيًا:

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

الهوية والتكاملات عبر شركات مختلفة الأنظمة

قليلة هي المجموعات التي تستعمل نظامًا موحدًا في كل شركاتها. الأغلب أن تجد شركة تعمل على SAP، وأخرى على Odoo، وثالثة على نظام محاسبي محلي، وأن يكون للمجموعة دليل نشط (Active Directory) واحد أو عدة نطاقات. قبل العرض التوضيحي، ارسم خريطة بسيطة: لكل شركة، ما مصدر هوية موظفيها؟ وما النظام الذي تُولد فيه الفواتير وأوامر الشراء؟ وأين تُحفظ مرفقاتها اليوم؟

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

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

الاستحواذ والانفصال: اختبر الخروج قبل الدخول

سيناريوهان يجب أن يُغطيا في أي عرض لمجموعة قابضة:

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

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

سيناريو عرض توضيحي لمجموعة قابضة

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

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

كيف يتعامل وثيقة مع هيكل المجموعة؟

وثيقة نظام سعودي لإدارة الوثائق والأرشفة الإلكترونية (DMS) يقدّم المستودع المركزي والتصنيف والصلاحيات والتدقيق التي يقوم عليها التصميم أعلاه:

• هيكل مجلدات وفئات هرمي يسمح بأن يبدأ التصنيف بالكيان ثم الوظيفة ثم نوع الوثيقة، مع وسوم وفلاتر مخصصة للبحث عبر المستويات لمن يملك الصلاحية.
• صلاحيات مبنية على الأدوار (RBAC) تُطبق على مجموعات المستخدمين، على مستوى المجلد أو المستند المنفرد، مع صلاحيات هرمية تتبع الهيكل التنظيمي. وهذا ما تحتاجه مصفوفة «الكيان × الوظيفة».
• تكامل مع Active Directory وLDAP لاستيراد المستخدمين والأقسام، وتكاملات مع Microsoft 365 وSAP وOracle والبريد الإلكتروني، وواجهة REST API لربط أنظمة أخرى مثل Odoo أو الأنظمة المحاسبية المحلية، ويُحدَّد نطاق هذا الربط لكل شركة في العرض الفني.
• سجل تدقيق لكل فتح وتعديل وتنزيل وتسجيل دخول، محمي من التلاعب وقابل للتصدير بصيغة PDF أو Excel، وهو ما تحتاجه المراجعة الداخلية ولجنة المراجعة.
• سير عمل للموافقات متعدد المراحل بحسب نوع المستند، يصلح لإحالة العقود من الشركة إلى القانونية المشتركة ثم إلى المعتمد.
• أربعة نماذج نشر: سحابة مشتركة بعزل بيانات كل مؤسسة بمفاتيح تشفير مستقلة، وسحابة خاصة، واستضافة على خوادم المؤسسة، ونشر هجين يسمح بعزل شركة بعينها في بيئة مستقلة. ويُصمَّم شكل البيئة الهجينة لمجموعتك، أي الشركات في أي بيئة، في النطاق الفني.

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

اتفقوا على البنية قبل أي مورد

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

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