ما هو تحليل الأنظمة؟
ما هو تحليل الأنظمة؟
كل مشروع برمجي يبدأ بمشكلة. عيادة تغرق في دفاتر المواعيد الورقية. متجر إلكتروني يفقد السيطرة على مخزونه. شركة لوجستية لا تستطيع إخبار عملائها بأماكن طرودهم. الجسر الذي يصل بين المشكلة المؤلمة والحل الناجح هو تحليل الأنظمة — الممارسة المنهجية لفهم الوضع بعمق كافٍ لتصميم نظام يعالجه فعلياً.
قبل أن نتمكن من تحليل النظام، علينا أن نعرف ما المقصود بالنظام أصلاً.
ما هو النظام؟
النظام هو مجموعة من المكونات المترابطة التي تعمل معاً نحو هدف مشترك. كل نظام، بصرف النظر عن مجاله أو تعقيده، يمكن وصفه بأربعة مفاهيم جوهرية:
- المدخلات — المادة الخام التي يستهلكها النظام (بيانات، طلبات، بضائع، طاقة).
- المعالجة — العمل الذي يؤديه النظام لتحويل المدخلات إلى شيء مفيد.
- المخرجات — النتائج التي تُسلَّم للمستخدمين أو للأنظمة المرتبطة.
- التغذية الراجعة — المعلومات الناتجة عن المخرجات والتي تعود إلى النظام لتنظيم سلوكه وتحسينه مستقبلاً.
لنأخذ نظام حجز مواعيد العيادة مثالاً. يُرسل المرضى طلبات مواعيد (مدخلات). يتحقق النظام من توافر الأطباء ويطبق قواعد الجدولة (معالجة). ينتج عنه حجوزات مؤكدة وتذكيرات (مخرجات). ثم تعود نسب الإلغاء وشكاوى المرضى لتُغذّي سياسات الجدولة (تغذية راجعة). إذا حذفنا أياً من هذه العناصر الأربعة، ينهار النظام أو يصبح غير قابل للتحكم.
ما معنى التحليل؟
التحليل يعني تفكيك الكل المعقد إلى أجزائه المكوّنة لفهم طريقة عمل كل جزء، وكيفية تفاعل الأجزاء مع بعضها، ومواطن الخلل فيها. في سياق نظم المعلومات، يجيب التحليل على ثلاثة أسئلة جوهرية:
- ماذا تفعل المنظمة حالياً؟ (فهم الوضع الراهن)
- ما المشكلات والفجوات والفرص القائمة؟ (تحديد المشكلة)
- ما الذي يجب أن يفعله النظام الجديد أو المُحسَّن لسد تلك الفجوات؟ (المتطلبات)
لاحظ أن التحليل يتوقف عمداً قبل الإجابة على سؤال كيف سيُبنى النظام — فذلك من اختصاص التصميم والتنفيذ. التحليل يسأل ماذا ولماذا؛ أما التصميم فيجيب على كيف.
لماذا تفشل المشاريع بدون تحليل؟
يرصد تقرير CHAOS الصادر عن مجموعة Standish نتائج المشاريع البرمجية منذ عام 1994. وتتكرر عاماً بعد عام الأسباب الجذرية ذاتها لفشل المشاريع: متطلبات ناقصة، وغياب مشاركة المستخدمين، وتوقعات غير واقعية — وهي جميعها إخفاقات في التحليل، لا في كتابة الكود.
إليك نمطاً متكرراً في شركات الخدمات اللوجستية: تقرر الإدارة بناء بوابة تتبع الطرود. يتحمس المطورون ويبدؤون ببناء الشاشات دون إجراء مقابلات مع أصحاب المصلحة. بعد ستة أشهر و180,000 دولار، تُطلق البوابة — لكن السائقين لا يستطيعون تحديث حالة التسليم من هواتفهم لأن أحداً لم يسأل كيف يعملون ميدانياً. ويرفض المشرفون اعتمادها لأنها لا تتكامل مع نظام إدارة المستودعات الحالي. فتُلغى البوابة.
مرحلة تحليل مدتها ستة أسابيع — مقابلات، رسم خرائط العمليات، تحليل الفجوات — كانت ستكشف عن كلتا المشكلتين قبل كتابة سطر كود واحد. تكلفتها؟ ربما 15,000 دولار. والتوفير؟ 165,000 دولار ونظام فعّال.
نطاق تحليل الأنظمة
لا يقتصر تحليل الأنظمة على البرمجيات؛ بل يمتد ليشمل أي مجموعة منظمة من الأشخاص والعمليات والبيانات والأدوات التي تعمل معاً نحو هدف. قد يدرس المحلل الذي يفحص متجراً إلكترونياً:
- الأشخاص — موظفو المستودع، وكلاء خدمة العملاء، شركاء التوصيل، العملاء.
- العمليات — استقبال الطلبات، الدفع، التحضير، التغليف، الشحن، المرتجعات.
- البيانات — كتالوج المنتجات، مستويات المخزون، سجلات العملاء، تاريخ الطلبات.
- التقنية — نظام ERP، بوابة الدفع، واجهات برمجة شركات الشحن.
يجب فهم الأبعاد الأربعة جميعها قبل التوصية بأي حل. المحلل الذي يكتفي بدراسة نماذج البيانات ويتجاهل الواقع اليومي للعاملين في المستودع سيُنتج متطلبات لا يمكن تطبيقها في بيئة حقيقية.
تحليل الأنظمة كممارسة مهنية
يسترشد تحليل الأنظمة بمنهجيات منظمة — من المناهج الكلاسيكية كالشلال (حيث يُعدّ التحليل مرحلة مستقلة) إلى الأطر التكرارية (حيث تُنسج أنشطة التحليل في كل دورة). بغض النظر عن المنهجية، تبقى المهارات التحليلية الجوهرية ذاتها: طرح الأسئلة الصحيحة، والإنصات باهتمام، وتوليف المعلومات من مصادر متعددة، وإيصال النتائج بوضوح إلى الجماهير التقنية وغير التقنية على حد سواء.
يعمل المحلل الماهر بوصفه مترجماً بين عالم الأعمال والعالم التقني. يتحدث أصحاب المصلحة التجاريون بلغة الأهداف والمشكلات والسياسات. أما المطورون فيتحدثون بلغة الكلاسات وواجهات برمجة التطبيقات ومخططات البيانات. يحول المحلل هذه اللغة إلى تلك — بدقة واكتمال — لضمان بناء النظام الصحيح.
خلاصة
- للنظام مدخلات ومعالجة ومخرجات وحلقات تغذية راجعة.
- التحليل يعني تفكيك النظام لفهم ما يفعله، وما الخلل فيه، وما المطلوب منه.
- تفشل المشاريع أساساً بسبب ضعف التحليل — لا بسبب الكود.
- على المحللين دراسة الأشخاص والعمليات والبيانات والتقنية معاً.
- دور المحلل هو الترجمة بين أهداف الأعمال ومتطلبات التقنية.