كيف كشفت الأتمتة ما لم تكشفه التقارير اليومية وكيف تغيرت رؤيتي إلى عالم التدقيق : تجربتي في بناء نظام مراقبة و تدقيقة في مجموعة فخر الدين

أنا أيوب يوسف أيوب، وما بحكي هنا عن مشروع نظري ولا عن فكرة عامة عن الـ Automation أو الذكاء الصناعي داخل الشركات. بحكي عن تجربة عملية عشتها داخل بيئة IT حقيقية، فيها أنظمة إدارية وتشغيلية ومالية متداخلة، وكل نظام منها يمس جزءاً حساساً من عمل الشركة: Active Directory، Exchange، أنظمة محاسبة، أنظمة إدارة مخزون، أنظمة مبيعات، أنظمة حجوزات غرف مثل Opera، قواعد بيانات، صلاحيات مستخدمين، موافقات، تقارير يومية، وحركة تشغيل لا تتوقف.

في البداية كنت أتعامل مع هذه الأنظمة بالطريقة الطبيعية التي يتعامل بها أي شخص في الـ IT: أتأكد أن الخدمة تعمل، أن المستخدمين قادرون على الدخول، أن البريد يرسل ويستقبل، أن النظام المالي متاح، أن برنامج المبيعات يعمل، أن الحجوزات تظهر، وأن المشاكل اليومية يتم حلها وقت حدوثها. لكن مع الوقت، ومع بداية بناء طبقة Monitoring + Audit + Reporting خاصة ببيئتنا، بدأت أكتشف أن السؤال الحقيقي ليس: هل النظام شغال؟ بل: ماذا يحدث داخل النظام؟ ومن يستخدمه؟ وما الذي تغير؟ وما الذي لا يظهر في التقرير التقليدي؟ وهل ما نراه على الشاشة يعكس الحقيقة التشغيلية فعلاً؟

هذه النقلة غيّرت طريقة تفكيري في الـ IT. لأن الأنظمة الكبيرة داخل الشركة لا تكون خطيرة فقط عندما تتوقف. أحياناً تكون أخطر وهي تعمل، لكنها تعمل بدون رؤية كافية. نظام المحاسبة يعمل، لكن هل نرى العمليات غير الطبيعية؟ نظام المخزون يعمل، لكن هل نعرف أين تظهر الفروقات أو الحركات التي تحتاج مراجعة؟ نظام المبيعات يعمل، لكن هل نرى الخصومات والاستثناءات والـ Voids والحركات غير المعتادة؟ نظام Opera يعمل، لكن هل نعرف نمط الحجوزات والتعديلات والإلغاءات والصلاحيات؟ Exchange يعمل، لكن هل نعرف من يرسل ماذا، وأين تكبر الـ Mailboxes، وما أكبر الرسائل، وهل هناك مرفقات تحتاج انتباه؟ Active Directory مستقر، لكن هل نعرف بدقة من أضاف مستخدماً، ومن عدّل على Group، ومن غيّر Policy، ومن يملك صلاحيات لا يستخدمها فعلياً؟

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

من متابعة الأنظمة إلى فهم سلوك الشركة

في الشركات الكبيرة، كل نظام يحكي جزءاً من القصة. Active Directory يحكي قصة الصلاحيات والهوية. Exchange يحكي قصة التواصل وحركة البريد والمرفقات. نظام المحاسبة يحكي قصة القيود والمعاملات والاعتمادات المالية. نظام المخزون يحكي قصة الحركة بين المستودعات، الصرف، الإدخال، الفروقات، والتعديلات. نظام المبيعات يحكي قصة الخصومات، الإلغاءات، الـ Voids، المستخدمين، والأداء اليومي. Opera يحكي قصة الحجوزات، الغرف، التعديلات، الإلغاءات، أسعار الغرف، وصلاحيات موظفي الاستقبال والحجوزات.

المشكلة أن كل قصة من هذه القصص تكون منفصلة إذا بقيت داخل شاشة النظام فقط. كل Vendor يعطيك تقريراً حسب طريقته، وكل نظام له Logs أو Reports أو Database أو شاشة متابعة مختلفة. لكن الإدارة لا تحتاج أن تعرف أن كل نظام “شغال” فقط. الإدارة تحتاج أن تعرف: هل التشغيل مضبوط؟ هل هناك Bottlenecks؟ هل هناك تغييرات غير مفسرة؟ هل هناك صلاحيات زائدة؟ هل هناك عمليات تحتاج مراجعة؟ هل هناك فرق بين ما يحدث فعلياً وما يظهر في التقارير اليومية؟

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

Active Directory: ليس مجرد Users وGroups

Active Directory بالنسبة لي صار من أهم الأنظمة التي يجب أن يكون حولها Audit واضح. لأنه ليس مجرد مكان للمستخدمين والجروبات. هو خريطة السلطة داخل الشركة. من يستطيع الدخول؟ من لديه صلاحية؟ من انضم إلى مجموعة حساسة؟ من خرج منها؟ من تم تعطيله؟ من بقي Enabled رغم أنه لا يستخدم النظام؟ من غيّر GPO؟ من عدّل على Computer Object؟ من قام بتغيير قد يؤثر على عشرات الأجهزة أو المستخدمين؟

الخطأ الشائع أن يتم التعامل مع Active Directory كأنه خدمة خلفية مستقرة طالما المستخدمين يدخلون على أجهزتهم والبريد يعمل. لكن الحقيقة أن أي تغيير صغير داخل AD قد يكون له أثر أمني وتشغيلي كبير. إضافة مستخدم لمجموعة معينة قد تفتح له صلاحيات واسعة. تعطيل حساب قد يوقف Workflow. جهاز قديم داخل الدومين قد يكون ثغرة تنظيمية. GPO غير موثق قد يغير سلوك أجهزة كثيرة. DNS Record معدل بطريقة خاطئة قد يربك خدمات داخلية كاملة.

لذلك تقرير Active Directory الحقيقي لا يجب أن يكون فقط عن Failed Logins أو Locked Accounts. هذه مهمة، لكنها ليست كافية. التقرير الناضج يجب أن يجيب عن آخر 24 ساعة: من أضاف؟ من عدّل؟ من حذف؟ من عطّل؟ ما الـ Object المتأثر؟ ما الجروب؟ ما المستخدم؟ ما الجهاز؟ ما الـ Domain Controller؟ ما مستوى الخطورة؟ وهل هذا التغيير طبيعي أم يحتاج مراجعة؟

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

Exchange: البريد ليس خدمة إرسال واستقبال فقط

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

السؤال التقليدي يقول: هل البريد يعمل؟ هل الـ Mail Flow طبيعي؟ هل في Queue؟ لكن السؤال الأقوى هو: ماذا حدث خلال آخر 24 ساعة؟ كم رسالة خرجت؟ كم رسالة دخلت؟ من أكثر المرسلين؟ من أكثر المستقبلين؟ ما أكبر الرسائل حجماً؟ ما أكبر Mailboxes داخل الـ Datastore؟ هل هناك نمو غير طبيعي؟ هل هناك Attachments تحتاج انتباه؟ هل هناك Failed أو Rejected Messages؟ هل الحركة داخلية أكثر أم خارجية؟ هل هناك نمط جديد أو غير معتاد؟

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

واحدة من أهم التجارب بالنسبة لي كانت التفكير في الوصول إلى معلومات Exchange من خلال الطريق الصحيح، سواء عبر Shell أو أدوات الإدارة أو التقارير المتاحة، ثم تحويل المادة الخام إلى تقرير يفهمه أكثر من طرف: الإدارة ترى الوضع العام، فريق البنية التحتية يرى الضغط والنمو، والأوديت يرى Evidence خلال آخر 24 ساعة.

هنا فهمت أن التقرير القوي ليس الذي يقول “Exchange Healthy” فقط، بل الذي يشرح لماذا هو Healthy، وأين توجد المؤشرات التي تحتاج عيناً بشرية.

أنظمة المحاسبة: البيانات المالية تحتاج رقابة لا مجرد تشغيل

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

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

هنا تأتي فكرة Accounting Intelligence Layer. ليس المقصود أن نعدل على النظام الأصلي أو نتدخل في تشغيله. بالعكس، المطلوب قراءة آمنة، غالباً Read-only، أو من خلال Views مخصصة أو تقارير منظمة. الهدف أن نبني طبقة فهم فوق البيانات، لا أن نكسر النظام أو نغير منطقه.

وهذه النقطة مهمة جداً في النقاش مع أي Vendor. Read-only access المصمم صح ليس خطراً بحد ذاته. الخطر في الصلاحيات الزائدة، أو في الدخول غير المنظم، أو في تعديل بيانات Production. أما القراءة المنظمة لأغراض Audit وMonitoring فهي حاجة طبيعية في بيئة تريد أن ترى بياناتها بوضوح.

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

نظام إدارة المخزون: الحقيقة تظهر في الحركة لا في الرصيد فقط

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

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

السؤال الحقيقي: ما الحركات غير الطبيعية؟ هل هناك تسويات متكررة؟ هل هناك Items تتحرك بشكل غريب؟ هل هناك مستودع تظهر فيه فروقات أكثر من غيره؟ هل هناك مستخدم يقوم بتعديلات كثيرة؟ هل هناك حركة تمت في وقت غير معتاد؟ هل هناك فرق بين المبيعات الفعلية والصرف من المخزون؟ هل هناك مواد حساسة تحتاج متابعة خاصة؟

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

نظام المبيعات وPOS: الخصومات والاستثناءات لا تحتاج تخميناً

أنظمة المبيعات وPOS من أكثر الأنظمة حساسية، لأنها في قلب التشغيل اليومي. كل Check، كل Discount، كل Void، كل Refund، كل سعر، كل مستخدم، كل عملية إغلاق، كل تعديل، قد يعكس إجراءً صحيحاً أو استثناءً يحتاج تفسيراً. والمشكلة أن كثيراً من هذه العمليات تحدث بسرعة، وسط ضغط العمل، وبين أكثر من طرف: كاشير، مدير، تطبيق خارجي، إعدادات خصومات، سياسات إدارة، وتكاملات.

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

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

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

Opera وحجوزات الغرف: النظام الذي يكشف نمط التشغيل لا الحجوزات فقط

Opera أو أي نظام لإدارة حجوزات الغرف ليس مجرد شاشة لحجز غرفة أو تعديل إقامة. هو نظام يعكس جزءاً حساساً من عمل الفنادق والضيافة: الحجوزات، الإلغاءات، التعديلات، الأسعار، الـ Rate Codes، صلاحيات المستخدمين، تغيرات الغرف، No-show، المدفوعات، وربما الربط مع بوابات دفع أو أنظمة خارجية.

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

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

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

الموافقات وWorkflows: المشكلة أحياناً ليست تقنية بل إدارية

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

هنا التقرير لا يجب أن يكتفي بعدد الطلبات. يجب أن يعرف: كم طلباً ينتظر عند كل شخص؟ ما قيمتها؟ منذ متى؟ ما نوعها؟ من صاحب الطلب؟ هل الشخص الذي ينتظر عنده الطلب نشط فعلياً؟ هل هناك بديل؟ هل هذا التأخير متكرر؟ هل هذا Bottleneck مؤقت أم نمط دائم؟

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

Local DB AI: سؤال قواعد البيانات بلغة الإنسان

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

في الشركات، قواعد البيانات كبيرة ومعقدة. قد يكون فيها مئات الجداول، علاقات كثيرة، أسماء غير واضحة، Views، Stored Procedures، وأعمدة لا يعرف معناها إلا من عاش مع النظام. لا تستطيع أن ترسل كل Schema للموديل في كل سؤال. هذا غير عملي ومربك. لذلك الفكرة الأصح أن تبني Catalog للقاعدة، ثم تختار الجداول الأقرب للسؤال، ثم تسمح فقط باستعلامات SELECT آمنة.

هنا يصبح الذكاء الصناعي طبقة مساعدة. المستخدم يسأل بلغة طبيعية، النظام يختار السياق المناسب، ثم يتم توليد SQL مقيد وآمن، مع منع أي UPDATE أو DELETE أو DROP. هذه الحدود مهمة جداً. لأن الذكاء الصناعي داخل بيئة قواعد بيانات يجب أن يكون تحت رقابة هندسية صارمة. لا مجال للمغامرة.

القيمة هنا أن البيانات تبقى محلية قدر الإمكان، والـ AI يساعد في الفهم لا في العبث. وهذا مهم خصوصاً عندما نتعامل مع بيانات محاسبة، مبيعات، مخزون، حجوزات، صلاحيات، وبريد. الخصوصية ليست تفصيلاً.

الذكاء الصناعي الداخلي يبدأ من بيانات منظمة

فكرة أن يكون للشركة ذكاء صناعي خاص فيها فكرة جذابة، لكنها لا تبدأ بالموديل. تبدأ بالبيانات المنظمة. تبدأ بالتقارير، الـ Logs، الـ Snapshots، الـ Catalogs، الـ Metrics، وربط الأنظمة بلغة موحدة. بدون هذا الأساس، سيكون الـ AI مجرد كاتب جميل فوق فوضى.

إذا أردت AI يفهم الشركة، يجب أن تعطيه ذاكرة منظمة عن الشركة. ليس Logs خام بلا سياق، ولا جداول مبعثرة، ولا تقارير غير موحدة. يجب أن تعطيه مادة نظيفة: ماذا حدث في Exchange؟ ماذا تغير في Active Directory؟ ماذا تحرك في المخزون؟ ماذا حدث في المبيعات؟ ماذا تغير في الحجوزات؟ أين تراكمت الموافقات؟ ما الاستثناءات؟ ما المؤشرات؟

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

أكثر شيء تغير فيّ: لم أعد أثق بتقرير لا يشرح منطقه

بعد هذه التجربة، صرت أقل ثقة بأي تقرير يقول “OK” بدون أن يشرح كيف وصل إلى OK. ما معنى OK؟ هل فحص آخر 24 ساعة؟ هل قرأ من المصدر الصحيح؟ هل قارن بالتاريخ؟ هل يميز بين المستخدم النشط فعلياً والمستخدم الفعال على الورق؟ هل يعرف أكبر Mailboxes؟ هل يعرف تغييرات الصلاحيات؟ هل يعرف الخصومات غير العادية؟ هل يعرف تعديلات الحجوزات؟ هل يعرف فروقات المخزون؟ هل يحفظ Evidence؟ هل يمكن الرجوع لتقرير أمس؟

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

الخبرة الحقيقية ليست في الأدوات بل في الأسئلة

بعد كل هذه التجارب، أقدر أقول إن أكبر تطور حصل معي لم يكن فقط في Python أو SQL أو Shell أو APIs. التطور الأكبر كان في نوع الأسئلة التي صرت أسألها. سابقاً قد أسأل: كيف أفحص هذا النظام؟ الآن أسأل: ما الحقيقة التي أحتاج إثباتها؟ أين مصدرها؟ ما المؤشر الذي يدل على خلل؟ ما الفرق بين خلل حقيقي وضجيج؟ كيف أحفظ الدليل؟ كيف أجعل التقرير مفهوماً؟ كيف أعرف أن المشكلة انتهت؟ كيف أوحد هذا كله بدون أن أخلق فوضى؟

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

الـ IT كطبقة رؤية داخل الشركة

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

كل نظام داخل الشركة يترك أثراً. Active Directory يترك أثراً. Exchange يترك أثراً. المحاسبة تترك أثراً. المخزون يترك أثراً. المبيعات تترك أثراً. Opera يترك أثراً. الموافقات تترك أثراً. قواعد البيانات تترك أثراً. هذه الآثار إذا بقيت متفرقة فهي مجرد Logs وتقارير. وإذا جمعتها بعقل، تصبح Intelligence.

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

الخلاصة: لم أبنِ سكربتات فقط، بل بنيت طريقة رؤية

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

تعلمت أن النظام الذي يعمل ليس بالضرورة سليماً. وأن التقرير الذي يقول OK ليس بالضرورة كافياً. وأن الأنظمة الإدارية والمالية والتشغيلية لا يجب أن تراقب من سطحها فقط. Active Directory ليس Users وGroups فقط، بل سلطة وصلاحيات وتاريخ تغييرات. Exchange ليس Mail Flow فقط، بل حركة وأحجام ومرفقات ومؤشرات تشغيلية. نظام المحاسبة ليس شاشة قيود فقط، بل ذاكرة مالية تحتاج قراءة. نظام المخزون ليس رصيداً فقط، بل حركة وفروقات وأنماط. نظام المبيعات ليس فواتير فقط، بل خصومات واستثناءات وسلوك مستخدمين. Opera ليس حجوزات فقط، بل أسعار وتعديلات وإلغاءات وصلاحيات. والذكاء الصناعي ليس عصا سحرية، بل طبقة مساعدة فوق بيانات منظمة ومنطق واضح.

لماذا الأنظمة الإدارية أهم من الأجهزة نفسها؟

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

الـ Active Directory ليس مهماً لأنه خدمة تعمل على سيرفر فقط، بل لأنه يحدد من يستطيع الوصول.
Exchange ليس مهماً لأنه Mail Server فقط، بل لأنه يعكس حركة التواصل والملفات والموافقات اليومية.
نظام المحاسبة ليس مهماً لأنه قاعدة بيانات فقط، بل لأنه يحتوي أثر القرارات المالية.
نظام المخزون ليس مهماً لأنه برنامج لإدخال وإخراج مواد فقط، بل لأنه يكشف الانضباط التشغيلي.
نظام المبيعات ليس مهماً لأنه يطبع فواتير فقط، بل لأنه يبين الخصومات والاستثناءات والسلوك اليومي.
Opera ليس مهماً لأنه يدير حجوزات فقط، بل لأنه يمس الإيراد، الأسعار، التعديلات، الإلغاءات، وصلاحيات المستخدمين.

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

لأن الشركة لا تتأثر فقط بتوقف السيرفر. أحياناً تتأثر أكثر بعملية صغيرة تمت داخل نظام يعمل بشكل طبيعي.

Active Directory: خريطة القوة داخل الشركة

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

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

لذلك بدأت أنظر إلى AD كدفتر يومي للصلاحيات. ماذا حدث خلال آخر 24 ساعة؟ من أضاف مستخدماً؟ من عدّل مجموعة؟ من أزال صلاحية؟ من غيّر جهازاً؟ من عدّل Policy؟ من قام بتغيير في DNS؟ ما التغيير الذي يحتاج مراجعة؟ وما التغيير الطبيعي الذي لا يحتاج ضجيجاً؟

القيمة هنا ليست فقط في كشف “الخطر”، بل في بناء عادة مراجعة. أن تعرف أن كل تغيير حساس له أثر، وأن كل أثر محفوظ، وأن أي سؤال لاحق يمكن الرجوع له بدليل. هذه النقطة وحدها ترفع مستوى السيطرة داخل الشركة بشكل كبير.

Exchange: البريد كمرآة لحركة الشركة

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

قبل هذه التجربة، كان من الطبيعي أن يكون السؤال: هل البريد يرسل ويستقبل؟ هل هناك Queue؟ هل الخدمة شغالة؟ لكن بعد التفكير بطريقة Audit وMonitoring، أصبح السؤال أعمق: ماذا يقول البريد عن الشركة خلال آخر 24 ساعة؟

إذا كان هناك Mailbox يكبر بسرعة، فهذا ليس مجرد رقم. قد يكون سوء استخدام، غياب سياسة أرشفة، تراكم ملفات، أو اعتماد زائد على البريد كمستودع دائم. إذا كانت هناك رسائل ضخمة جداً، فقد تكون مجرد عمل طبيعي، وقد تكون مؤشراً أن المستخدمين ينقلون ملفات كبيرة عبر البريد بدل القنوات المناسبة. إذا كانت هناك Attachments معينة تتكرر، فهذا يستحق عيناً أمنية وتشغيلية. إذا كان هناك عدد كبير من الرسائل الفاشلة أو المرفوضة، فهذا قد يدل على مشكلة إعدادات، Spam، Block، أو خلل في التدفق.

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

هنا يصبح Exchange أكثر من Mail Flow. يصبح مصدر قراءة يومية لسلوك الشركة.

نظام المحاسبة: أين تتحول التقنية إلى رقابة مالية؟

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

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

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

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

Read-only Access: حق رقابي وليس تهديداً

واحدة من أكثر النقاط التي صارت عندي قناعة قوية فيها هي موضوع الـ Read-only access. في أنظمة المحاسبة والمخزون والمبيعات والحجوزات، الوصول المنظم للبيانات لأغراض التقارير والأوديت ليس رفاهية. هو حاجة طبيعية لأي شركة تريد أن تفهم بياناتها.

طبعاً لا أحد عاقل يطلب تعديل بيانات Production بشكل عشوائي. ولا أحد يريد الدخول بحسابات خطيرة أو كسر النظام أو تجاوز الـ Vendor. لكن فرق كبير بين تعديل النظام وبين قراءة آمنة. حساب Read-only مضبوط، أو Views مخصصة، أو تقارير تصديرية منظمة، أو API رسمي، كلها طرق طبيعية لبناء رؤية بدون المساس بالنظام الأصلي.

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

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

نظام المخزون: الحركات أهم من الأرصدة

في إدارة المخزون، كثير ناس تركز على الرصيد النهائي. كم عندنا من هذا الصنف؟ كم بقي؟ كم دخل؟ كم خرج؟ وهذا مهم، لكنه لا يكفي. لأن الرصيد النهائي قد يخبرك بالنتيجة، لكنه لا يخبرك بالقصة.

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

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

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

وهنا يظهر دور IT بطريقة مختلفة. ليس فقط تشغيل نظام المخزون، بل مساعدة الإدارة على قراءة ما يحدث داخله.

نظام المبيعات: الخصم ليس رقماً بسيطاً

في أنظمة المبيعات، خصوصاً في بيئات المطاعم أو الضيافة أو أي نشاط فيه POS، الخصومات والاستثناءات والـ Voids ليست تفاصيل هامشية. هي قلب الرقابة التشغيلية. لأن كل خصم يعني قراراً، وكل Void يعني تراجعاً عن عملية، وكل تعديل سعر يعني استثناء، وكل مستخدم يملك صلاحية معينة يعني ثقة يجب مراقبتها.

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

هنا فهمت أن مشاكل الخصومات لا تحتاج تخميناً، بل تحتاج مساراً واضحاً. Audit Trail يشرح العملية من البداية للنهاية. من المستخدم؟ أي Check؟ أي وقت؟ أي Rule؟ أي صلاحية؟ أي تطبيق خارجي؟ ما النتيجة؟ وهل الإعداد مطابق للسياسة المعتمدة؟

بدون هذه القراءة، يصبح IT في موقع دفاع. يراجع الإعدادات، يختبر، يحاول الفهم، لكن لا يملك دائماً المسار الكامل. أما عندما تبني تقريراً يقرأ هذه العمليات، فأنت تنقل النقاش من “مين السبب؟” إلى “ماذا تقول البيانات؟”

وهذا فرق كبير جداً في بيئة العمل.

Opera: الحجوزات ليست مجرد Rooms

نظام Opera في بيئات الفنادق والضيافة ليس مجرد نظام حجوزات. هو نظام يمس الإيراد والتشغيل وتجربة الضيف والصلاحيات والتسعير والتحصيل. لذلك مراقبته يجب أن تكون أعمق من مجرد التأكد أنه يعمل.

في Opera، كل تعديل على حجز له معنى. كل تغيير سعر له معنى. كل إلغاء له معنى. كل No-show له معنى. كل تغيير Room Type أو Rate Code أو Payment Method قد يكون طبيعياً تماماً، وقد يكون مؤشراً يحتاج مراجعة. المشكلة أن هذه العمليات كثيرة ومتداخلة، ولا تظهر دائماً في التقرير اليومي بالشكل الذي يساعد الإدارة أو الأوديت.

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

هذه الأسئلة تجعل Opera ليس فقط نظام تشغيل، بل مصدر فهم للإيراد والسلوك والتشغيل. وإذا كانت الشركة تعتمد عليه في جزء مهم من أعمالها، فمن غير المنطقي أن يكون دوره داخل الـ IT فقط “النظام شغال أو لا”. يجب أن يكون هناك قراءة أعمق لما يحدث داخله.

بوابات الدفع والحجوزات: أين تضيع الحقيقة بين الأنظمة؟

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

هنا لا يكفي أن تقول كل نظام يعمل وحده. ربما كل نظام يعمل فعلاً، لكن التكامل بينهما لا يعرض الحقيقة بشكل كامل. قد تكون هناك عملية دفع تمت ولم تنعكس بشكل واضح. قد يكون هناك Refund أو Cancel أو Failed Transaction يحتاج مطابقة. قد يكون هناك فرق توقيت بين نظامين. وقد تكون هناك مشكلة في طريقة عرض الحالة، لا في العملية نفسها.

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

هذا النوع من الأسئلة هو الذي يحول الـ IT من مراقبة تقنية إلى رقابة تشغيلية حقيقية.

الموافقات: عندما تكون المشكلة في مكان القرار

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

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

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

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

الصلاحيات داخل الأنظمة: الخطر الذي يكبر بهدوء

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

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

التقرير الجيد يجب أن يساعد على الإجابة: من يملك ماذا؟ من يستخدم صلاحياته فعلياً؟ من لديه صلاحية لا يستخدمها؟ من يملك صلاحية أعلى من دوره؟ هل هناك حسابات مشتركة؟ هل هناك مستخدمون قدامى ما زالوا موجودين؟ هل هناك صلاحيات مؤقتة لم تتم إزالتها؟

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

التقرير اليومي يجب أن يخدم القرار

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

التقرير ليس الهدف. القرار هو الهدف. والتقرير الممتاز هو الذي يجعل القرار أسهل، لا الذي يزيد الضجيج. لذلك لا أحب التقارير التي ترمي كل شيء أمام القارئ وتتركه يغرق. ولا أحب التقارير التي تختصر لدرجة تخفي الحقيقة. المطلوب توازن: Summary واضح، Priority حقيقية، تفاصيل قابلة للمراجعة، وEvidence محفوظ.

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

بناء ذاكرة تشغيلية للشركة

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

الناس تنشغل، تغيب، تنتقل، تنسى، أو تترك العمل. لذلك الشركة تحتاج ذاكرة تشغيلية مكتوبة ومحفوظة. ليست Documentation جامدة فقط، بل ذاكرة يومية: ماذا حدث؟ ماذا تغير؟ ما المؤشرات؟ ما الاستثناءات؟ ما الذي تكرر؟ ما الذي انحل؟ ما الذي يحتاج قراراً؟

بالنسبة لي، هذا أحد أهم معاني المشروع. كل Report، كل Snapshot، كل Run log، كل JSON محفوظ، هو جزء صغير من ذاكرة الشركة. ومع الوقت، هذه الذاكرة تصبح أقوى من أي متابعة يدوية. لأنها لا تنسى، ولا تتعب، ولا تتأثر بالانشغال.

لماذا هذه التجربة أكبر من Automation؟

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

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

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

الخاتمة: ما الحقيقة التي لا نراها الآن؟

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

هل نرى تغييرات Active Directory؟
هل نفهم حركة Exchange؟
هل نقرأ نظام المحاسبة كذاكرة مالية لا كشاشة إدخال فقط؟
هل نفهم المخزون من خلال الحركة لا الرصيد فقط؟
هل نراقب المبيعات من خلال الخصومات والاستثناءات والـ Voids؟
هل نقرأ Opera من خلال الحجوزات والتعديلات والإلغاءات والصلاحيات؟
هل نعرف أين تتوقف الموافقات؟
هل نستطيع سؤال قواعد البيانات بأمان؟
هل لدينا Evidence؟
هل لدينا ذاكرة تشغيلية؟
هل تقاريرنا تساعد على قرار، أم فقط تطمئننا؟

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

تعلمت أن الأتمتة الحقيقية لا تبدأ من الكود. تبدأ من سؤال بسيط لكنه عميق:

ما الحقيقة التي لا نراها الآن؟

ثم يأتي الكود، والتقارير، والـ Logs، والـ AI، وقواعد البيانات، وكل الأدوات الأخرى لتخدم هذا السؤال.