صلاحيات الموظفين في الباك أوفيس: كيف توزّع الأدوار في شركة الفوركس
كيف توزّع صلاحيات الموظفين في الباك أوفيس: الوحدة والإجراء ونطاق البيانات، وخريطة أدوار لكل فريق، ومهام لا يجمعها شخص واحد، وتعيين الموظف ومغادرته، ومراجعة دورية.
بقلم فريق QUANTIX التحريري9 دقائق للقراءة
يستقيل موظف سيلز يوم الأحد، وبعد أسبوعين ينضم إلى شركة منافسة. في الأسبوع نفسه يبدأ عملاء من قائمته باستلام اتصالات من الشركة الجديدة. حين يراجع المدير النظام يكتشف أن الموظف كان يستطيع تصدير قائمة العملاء كاملة، لا ليدزه فقط، وأن أحدًا لم يسأل يومًا لماذا يملك هذه الصلاحية.
الإجابة المختصرة: كل صلاحية في الباك أوفيس تجيب عن ثلاثة أسئلة: أي جزء من النظام، وأي إجراء، وسجلات من. صمّم الأدوار انطلاقًا من عمل كل فريق لا من المسمى الوظيفي، وامنح كل دور أقل ما يحتاجه لإنجاز عمله، وافصل المهام التي يجب ألا يجمعها شخص واحد، واكتب خطوات تعيين الموظف ونقله ومغادرته، ثم راجع الصلاحيات كلها في موعد ثابت.
نكتب هذا الدليل في QUANTIX، ونحن نقدّم نظام CRM وباك أوفيس لشركات الفوركس، فلنا مصلحة تجارية في الموضوع. لذلك صغنا المبادئ بطريقة تصلح لأي نظام، وتركنا الحديث عن QUANTIX للقسم الأخير. والدليل ليس استشارة قانونية: ما تطلبه جهتك الرقابية من الرقابة الداخلية يؤكده مسؤول الامتثال لديك.
ثلاثة أسئلة وراء كل صلاحية
تقسيم الموظفين إلى «مدير» و«مستخدم» لا يصنع نموذج صلاحيات. النموذج المفيد يجمع ثلاثة أبعاد:
| البعد | السؤال | أمثلة |
|---|---|---|
| الوحدة | أي جزء من النظام؟ | الليدز، العملاء، المعاملات، طلبات KYC، الصفقات، الإعدادات |
| الإجراء | ماذا يستطيع أن يفعل فيه؟ | عرض، إنشاء، تعديل، حذف، استيراد، تصدير |
| نطاق البيانات | سجلات من يرى؟ | سجلاته فقط، سجلات من يتبعونه مباشرة، فريقه، الجميع |
البعد الثالث هو ما تغفله الأنظمة البسيطة. قد يحمل موظفا سيلز الصلاحية نفسها على وحدة العملاء، لكن الأول يرى عملاءه فقط والثاني يرى قاعدة العملاء كلها. وهذا هو الفرق بين موظف يغادر بأرقام عملائه وموظف يغادر بقاعدة بيانات الشركة.
وانتبه إلى إجراءين يُستهان بهما عادة: التصدير والحذف. التصدير يُخرج البيانات من النظام إلى ملف لا تتحكم فيه بعد ذلك. والحذف يمحو أثرًا قد تحتاجه في نزاع أو تدقيق، والأسلم في أغلب الحالات إيقاف السجل أو تغيير حالته بدل حذفه.
ابدأ من عمل الفريق لا من المسمى الوظيفي
تختلف المسميات من شركة إلى أخرى، أما العمل فمتشابه. اكتب لكل فريق ما يحتاجه، ونطاقه المعتاد، وما لا يحتاجه أصلًا. الجدول التالي نقطة بداية، لا قالب نهائي:
| الفريق | يحتاج | النطاق المعتاد | لا يحتاج |
|---|---|---|---|
| السيلز | الليدز والاتصال والملاحظات وتحويل الليد إلى عميل | ليدزه وعملاؤه | تصدير القوائم، اعتماد الإيداع والسحب، قرار KYC |
| مدير السيلز | توزيع الليدز وإعادة تعيينها ومتابعة الفريق | فريقه | تعديل المعاملات، إعدادات المنصة |
| الريتنشن | ملف العميل وتداوله ومعاملاته للاطلاع، والملاحظات | عملاؤه أو فريقه | اعتماد السحب، تعديل الصفقات |
| الدعم | بيانات التواصل وحالة الطلبات | بحسب توزيع الطلبات | تفاصيل الدفع الكاملة، التصدير |
| الامتثال | المستندات وطلبات KYC وسجل التدقيق | الجميع | تحويل الليدز وتوزيعها |
| المالية | المعاملات والاعتماد والتصدير للمطابقة | الجميع | تعديل البيانات الشخصية للعميل، إعدادات الأدوار |
| الديلينغ | مراكز التداول والأوامر، وإعدادات الأدوات المالية عند الحاجة | الجميع | اعتماد السحب، تعديل الليدز |
| مدير النظام | المستخدمون والأدوار والإعدادات | الجميع | العمل اليومي على العملاء من الحساب نفسه |
السطر الأخير يستحق وقفة. من يدير الأدوار لا ينبغي أن يعمل على ملفات العملاء من حساب الإدارة نفسه. اجعل هذا الحساب منفصلًا وقليل الاستخدام، حتى يكون كل تغيير يُجرى به مقصودًا ومسجلًا.
نطاق البيانات يعتمد على هيكل صحيح
نطاقا «من يتبعونني» و«فريقي» لا يعملان إلا إذا كان الهيكل الوظيفي داخل النظام صحيحًا: من يتبع من، ومن في أي فريق. ومن هنا ثلاث عادات:
- حدّث الهيكل قبل الصلاحيات. موظف ما زال مسجلًا تحت مشرفه السابق يبقى ظاهرًا لذلك المشرف، ولا يظهر لمشرفه الجديد.
- انقل المسؤولية مع العميل. حين ينتقل العميل من فريق السيلز إلى فريق الريتنشن بعد أول إيداع (FTD)، غيّر الموظف المسؤول في ملفه. وإلا بقي ظاهرًا للأول وغاب عن الثاني.
- امنح نطاق «الجميع» بالاسم. احتفظ بقائمة بمن يملك هذا النطاق على أي وحدة، ولماذا. إذا ظلت القائمة تطول، فالتصميم يحتاج إلى مراجعة.
مهام لا يجمعها شخص واحد
مبدأ فصل المهام بسيط: الخطوة الحساسة لا يبدؤها الشخص نفسه وينهيها. ويطلب إطار NIST SP 800-53، وهو من أشهر أطر الضوابط الأمنية، تحديد المهام التي تحتاج إلى فصل وتوثيقها، ومنح كل مستخدم الوصول اللازم لمهامه فقط، وهو ما يُعرف بمبدأ أقل صلاحية ممكنة. في شركة الفوركس تظهر الأزواج المتعارضة عادة هكذا:
- تسجيل إيداع يدوي واعتماده. من يُدخل القيد لا يعتمده. فصّلنا ذلك في دليل موافقات الإيداع والسحب.
- تعديل بيانات الدفع للعميل واعتماد سحبه. تغيير وجهة الدفع ثم اعتماد السحب إليها من الحساب نفسه أقصر طريق إلى الاحتيال الداخلي.
- جلب العميل والحكم على ملف KYC الخاص به. موظف السيلز يستفيد من قبول الملف، فلا يكون صاحب القرار فيه. تصميم المراجعة نفسها شرحناه في دليل مسار مراجعة KYC.
- تغيير إعدادات الأدوات المالية والتداول نيابة عن العملاء. تعديل السبريد أو الرافعة المالية ثم فتح صفقة أو تعديلها يحتاج إلى عين ثانية، أو على الأقل إلى مراجعة لاحقة منتظمة.
- إدارة الأدوار ومنح النفس صلاحية. كل تغيير في الأدوار يراجعه شخص غير الذي أجراه.
وإذا كان فريقك صغيرًا ويجمع شخص واحد بين مهمتين من هذه، فلا تتظاهر بأن الفصل قائم. عوّضه بمراجعة دورية مكتوبة: يطّلع المدير أو المالك كل أسبوع على قائمة الإيداعات اليدوية والسحوبات المعتمدة وتغييرات الأدوار.
الصلاحيات الأكثر حساسية
اجعل عدد من يملكون الصلاحيات التالية قليلًا، وراجعها أكثر من غيرها:
- التصدير بنطاق «الجميع» في أي وحدة فيها بيانات عملاء.
- الحذف في الليدز والعملاء والمعاملات.
- الاستيراد، لأنه يغيّر سجلات كثيرة دفعة واحدة.
- إنشاء الصفقات أو تعديلها نيابة عن العميل.
- الإيداع اليدوي واعتماد السحب.
- قرار KYC والاطلاع على مستندات الهوية.
- إدارة المستخدمين والأدوار.
ولكل صلاحية منها ثلاثة أسئلة: من يملكها اليوم بالاسم؟ متى استخدمها آخر مرة؟ وهل يظهر كل استخدام لها في سجل التدقيق مع القيمة قبل التعديل وبعده؟
التعيين والنقل والمغادرة
أغلب مشكلات الصلاحيات لا تحدث يوم تصميم الأدوار، بل بعده بأشهر، حين يتغير الموظفون. اكتب ثلاثة إجراءات ثابتة:
- التعيين: طلب مكتوب من مدير الفريق يحدد الدور والفريق والمشرف، ويوافق عليه شخص غير مقدّم الطلب. ابدأ بالدور القياسي، ولا تضف صلاحيات «مؤقتة» بلا تاريخ انتهاء.
- النقل: حين ينتقل موظف من السيلز إلى الريتنشن مثلًا، أزل صلاحيات دوره القديم قبل إضافة الجديد. تراكم الصلاحيات مع كل انتقال هو ما يجعل موظفًا قديمًا يملك صلاحيات أوسع من مديره.
- المغادرة: أوقف الحساب في يوم المغادرة نفسه، وأعد توزيع ليدزه وعملائه، وراجع ما صدّره في الأسابيع الأخيرة. والإطار نفسه (NIST SP 800-53) ينص على تعطيل حسابات المستخدمين عند انتهاء عملهم أو نقلهم.
واسأل كذلك عن حماية دخول الموظفين: قواعد كلمات المرور، ومن يحق له الدخول، ومن أي أجهزة. هذا جزء من سياستك الأمنية، ولا تغطيه مصفوفة الصلاحيات وحدها.
مراجعة الصلاحيات في موعد ثابت
حدد موعدًا ثابتًا، كل شهر أو كل ثلاثة أشهر بحسب حجم فريقك، واطرح الأسئلة نفسها في كل مرة:
- هل يخص كل حساب نشط موظفًا ما زال يعمل في الدور نفسه؟
- من يملك نطاق «الجميع»، ومن يملك التصدير والحذف؟ وهل ما زال يحتاج إليها؟
- ما الأدوار المخصصة التي أُنشئت أو عُدّلت منذ المراجعة السابقة، ومن عدّلها؟
- هل في سجل التدقيق تصدير كبير، أو تعديل لبيانات دفع، أو تعديل لصفقة، لا يعرف أحد سببه؟
واحفظ نتيجة كل مراجعة: التاريخ، ومن راجع، وما الذي تغيّر. وحين يُسأل فريقك لاحقًا عن الرقابة على الوصول إلى البيانات، تكون هذه السجلات هي الجواب.
ما لا يغطيه هذا الدليل
لا يتناول هذا الدليل أمن البنية التقنية (الشبكات والأجهزة والخوادم)، ولا سياسات الموارد البشرية والتحقق من الموظفين قبل التعيين، ولا متطلبات جهة رقابية بعينها. ولا يكرر متطلبات نظام CRM كاملة، فهي في دليل ما الذي يجب أن يفعله نظام CRM لشركة فوركس فعلًا.
أين يأتي دور QUANTIX
في منصة QUANTIX، تعمل الصلاحيات داخل CRM والباك أوفيس الذي يشترك مع بوابة المتداول ولوحة إدارة المنصة في محرك تداول واحد وسجل تدقيق واحد. بالتحديد:
- مصفوفة صلاحيات من 19 وحدة × 6 إجراءات (عرض وإنشاء وتعديل وحذف واستيراد وتصدير) × 4 نطاقات بيانات (بياناتي، موظفيّ المباشرون، فريقي، الكل)، فوق هيكل هرمي للموظفين.
- خمسة أدوار جاهزة: مدير النظام، ومدير، وموظف سيلز، وموظف دعم، ومسؤول امتثال، إضافة إلى الأدوار التي تنشئها بنفسك، مثل دور لفريق المالية أو لفريق الديلينغ.
- موظفون بمسمياتهم الوظيفية ومشرفيهم، ومخطط هيكلي. وتختفي القوائم والأزرار عندما لا يملك الدور الصلاحية.
- يستطيع الموظف الذي يملك الصلاحية إنشاء الصفقات أو تعديلها نيابة عن العميل من ملفه في CRM والباك أوفيس، ويسجّل الموظفون المخوّلون الإيداع اليدوي من ملف العميل ضمن نظام الإيداعات والسحوبات.
- سجل تدقيق يغطي أكثر من 70 نوع حدث مع القيم قبل التعديل وبعده، يمكن تصفيته وتصديره، ويظهر في ملف كل عميل.
- لكل علامة تجارية مساحة مستقلة بمستخدميها وبياناتها، تُدار من لوحة إدارة المنصة.
وللوضوح: لا تتضمن المنصة حاليًا المصادقة الثنائية (2FA) ولا الدخول الموحد (SSO) لحسابات الموظفين، فخطط سياسة كلمات المرور والأجهزة على هذا الأساس. أما توزيع الأدوار ومراجعتها فقرار شركتك. QUANTIX تقدّم أدوات للعمليات والامتثال، واستخدامها لا يجعل شركتك ممتثلة ولا يمنحها ترخيصًا.
إذا أردت أن ترى مصفوفة الصلاحيات على هيكل فريقك، احجز عرضًا مباشرًا، وأحضر معك قائمة فرقك ومن يعتمد ماذا اليوم.