من الذي يستطيع تغيير سعر في الثانية صباحًا

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

ولا أحد في الغرفة يعرف من هو admin. هناك أربعة مرشحين: مدير المالية الذي أنشأ الحساب، ومقاول تقنية المعلومات الذي يدعم الخادم، والاستشاري من شريك تنفيذ لم يتعامل معه أحد منذ سنتين، ثم أي شخص آخر أُعطي كلمة المرور بعدهم. السجل مكتمل تقنيًا وعديم القيمة كدليل.

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

هذا المقال عن ذلك القرار وعائلته: كيف تُضبط الصلاحيات فعلًا في مشاريع الشركات المتوسطة، وما الذي يعنيه الفصل بين المهام حين يكون قسم المالية عندك أحد عشر شخصًا، وأي الضوابط يستحق الاحتكاك الذي يسبّبه.

قرار الأسبوع الثالث

يجري الأمر هكذا في كل مشروع تقريبًا.

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

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

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

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

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

ما الذي يعنيه الفصل بين المهام فعلًا

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

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

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

سطر البيانات الرئيسية هو الذي تبدأ منه

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

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

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

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

مصفوفات الاعتماد: الحدّ ليس ضابطًا

كل تنفيذ يبني مصفوفة اعتماد. أوامر الشراء فوق قيمة معيّنة تذهب لمدير؛ وفوق قيمة أعلى، لمدير تنفيذي. تُرسَم المصفوفة في ورشة، وتُعتمَد، وتُهيَّأ، ثم يهزمها السلوك البشري العادي بهدوء.

وأربعة أنماط فشل تفسّر أغلب ذلك.

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

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

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

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

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

سؤال سجل التدقيق الذي لا يسأله أحد حتى يحتاجه

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

والسجل الذي يستحق الاحتفاظ به يجيب عن أربعة أسئلة في أي تغيير:

من — فرد مسمّى، لا حساب مشترك، ولا حساب خدمة، ولا admin.

ماذا — الحقل، والسجل، والقيمة قبل والقيمة بعد. أما قيدٌ يقول إن سجل عميل قد عُدِّل فلا يخبرك بشيء.

متى — طابع زمني تثق به، بمنطقة زمنية تعرفها.

لماذا — سبب، يُلتقَط لحظة التغيير، للمجموعة الصغيرة من التغييرات التي يستحق طلب سبب لها.

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

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

ماذا تفعل حين لا تستطيع الفصل

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

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

وهذه بعض ما ينفع في الفرق الصغيرة، بكلفة زهيدة:

تقرير تغييرات الحسابات البنكية. كل تغيير في حساب بنكي لمورّد خلال الفترة، يراجعه شخص من خارج الحسابات الدائنة، قبل دورة الدفع. عشر دقائق في الشهر.

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

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

قائمة المورّدين الجدد. المورّدون المُنشَؤون في الفترة، ومعهم أول حركة لكل منهم. وتُقارَن بعناوين الموظفين وبياناتهم البنكية مرة في السنة على الأقل.

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

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

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

الحسابات التي لا ينبغي أن توجد

ثلاثة أشياء محدّدة تذهب لتفحصها اليوم، قبل أي مراجعة أوسع.

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

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

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

كيف ينبغي أن يبدو الأسبوع الثالث بدل ذلك

لا شيء مما سبق يدعو إلى مشروع أثقل. هو يدعو إلى أن يُتخذ قرار واحد بطريقة مختلفة تحت الضغط.

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

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

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

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

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