- المشاركات
- 22
- مستوى التفاعل
- 0
- النقاط
- 1
بحث حول تصميم نظم المعلومات من منظور اداري اعداد الباحث حسوني محمد عبد الغني
بحث حول تصميم نظم المعلومات من منظور إداري
مقدمة
أصبحت نظم المعلومات عنصرًا حاسمًا في رفع كفاءة المنظمات وتحسين جودة القرار والرقابة وتنسيق الموارد. غير أن نجاح تصميم نظام معلومات لا يتحقق بمجرد توافر التكنولوجيا، بل يتوقف أساسًا على حسن المواءمة بين أهداف المؤسسة ومتطلبات المستخدمين والحوكمة وإدارة التغيير. لذلك يركز المنظور الإداري لتصميم نظم المعلومات على النظام باعتباره مشروعًا تنظيميًا واستثماريًا يغيّر طرق العمل ويعيد توزيع الأدوار والمسؤوليات، لا مجرد برنامج أو أجهزة.
أهمية الموضوع: تكمن في أن كثيرًا من مشاريع نظم المعلومات تفشل أو تتعثر بسبب ضعف تحليل الاحتياجات، أو غياب الدعم الإداري، أو مقاومة التغيير، أو سوء الحوكمة وإدارة المخاطر، رغم سلامة الحل التقني.
هدف البحث: (1) بيان مفهوم تصميم نظم المعلومات إداريًا، (2) تحديد المراحل الإدارية للتصميم من التخطيط إلى التشغيل، (3) إبراز عوامل النجاح والضوابط (الحوكمة، المخاطر، التغيير، جودة البيانات).
إشكالية البحث: كيف يتم تصميم نظم المعلومات بطريقة تحقق قيمة تنظيمية فعلية للمؤسسة، وما أهم الضوابط الإدارية التي تحكم هذا التصميم لضمان الملاءمة والنجاعة؟
المنهج المتبع: المنهج الوصفي التحليلي؛ من خلال عرض الأطر النظرية (حوكمة/قيمة/مخاطر/خدمة) ثم تحليل مراحل التصميم إداريًا وربطها بممارسات معيارية (SDLC، ITIL، COBIT، ISO 38500).
المبحث الأول: الإطار المفاهيمي لتصميم نظم المعلومات من منظور إداري
المطلب الأول: مفهوم نظام المعلومات ووظيفته الإدارية
الفرع الأول: تعريف نظام المعلومات إداريًا
نظام المعلومات هو منظومة متكاملة تجمع الأفراد والإجراءات والبيانات والتقنيات لإنتاج معلومات تدعم التخطيط والتنظيم والرقابة واتخاذ القرار. ومن منظور إداري، تُقاس قيمة النظام بقدرته على تحسين الأداء وتقليل التكلفة ورفع جودة الخدمة لا بحداثة التكنولوجيا.
الفرع الثاني: وظائف نظام المعلومات داخل المؤسسة
يخدم النظام وظائف إدارية أساسية: دعم القرار (تقارير ولوحات قيادة)، تحسين الرقابة (مؤشرات أداء)، تعزيز التنسيق (تدفق معلومات بين الوحدات)، وتوثيق المعاملات (أثر قانوني/إداري)، وهو ما يجعل التصميم مرتبطًا ببنية العمل (Business Processes) أكثر من ارتباطه بالجانب البرمجي فقط.
المطلب الثاني: مبادئ الحوكمة والمواءمة الاستراتيجية
الفرع الأول: حوكمة تكنولوجيا المعلومات
تؤكد ISO/IEC 38500 أن حوكمة تقنية المعلومات جزء من حوكمة المؤسسة، وتُعنى بتوجيه الاستخدام الحالي والمستقبلي لتكنولوجيا المعلومات عبر قرارات وإجراءات تضمن القيمة والمساءلة.
الفرع الثاني: المواءمة بين أهداف المؤسسة والنظام
يوضح COBIT 2019 أن الحوكمة/الإدارة في مجال المعلومات والتكنولوجيا تستهدف مواءمة التقنية مع أهداف المؤسسة عبر نموذج أهداف وضوابط (Governance & Management Objectives).
المطلب الثالث: تصميم النظام كمشروع تغيير تنظيمي
الفرع الأول: النظام كمشروع استثمار وقيمة
القرار بتصميم نظام معلومات هو قرار استثماري: يجب أن يثبت جدواه (تخفيض أخطاء، تسريع عمليات، شفافية) ويحدد مؤشرات قيمة واضحة قبل التنفيذ.
الفرع الثاني: أثر النظام على الهيكل والثقافة
يغيّر النظام الإجراءات ومسارات الموافقة والصلاحيات، وقد يصطدم بثقافة تنظيمية تقاوم الشفافية أو التحول الرقمي؛ لذا يُعد “إدارة التغيير” شرطًا إداريًا لنجاح التصميم.
المبحث الثاني: مراحل تصميم نظم المعلومات إداريًا
المطلب الأول: التخطيط وتحديد الاحتياجات (Requirements)
الفرع الأول: دراسة الوضع الحالي وتحديد الفجوة
تنطلق المرحلة بتشخيص الوضع الراهن (As-Is): خرائط العمليات، نقاط الاختناق، أخطاء البيانات، ازدواجية العمل. ثم تحديد الوضع المستهدف (To-Be) والفجوة بينهما.
الفرع الثاني: جمع المتطلبات الوظيفية وغير الوظيفية
المتطلبات الوظيفية (ما الذي يجب أن يفعله النظام)، وغير الوظيفية (الأمن، الأداء، التوفر، قابلية التوسع). وتُوثق عادة في مواصفات واضحة قبل التصميم التفصيلي، ضمن مراحل SDLC التي تضع التحليل والتصميم قبل التطوير والتشغيل.
المطلب الثاني: التصميم الإداري (Business Design) والتصميم التقني (Technical Design)
الفرع الأول: إعادة هندسة الإجراءات وتوزيع المسؤوليات
قبل الواجهات وقواعد البيانات، يجب تصميم “نظام عمل”: من ينجز ماذا؟ ما نقاط الرقابة؟ ما الصلاحيات؟ كيف يُضمن الأثر الرقابي والقانوني؟ أي أن التصميم يبدأ بـ تصميم العملية لا الشاشة.
الفرع الثاني: التصميم التقني كترجمة للمتطلبات
يتحول “تصميم الأعمال” إلى معمارية تقنية (قواعد بيانات، تكامل، أمن). وتؤكد أدلة SDLC أن التصميم مرحلة لإنتاج مخطط معماري قبل التطوير والاختبار والنشر.
المطلب الثالث: التنفيذ والتشغيل والتحسين المستمر
الفرع الأول: الاختبار، النشر، وإدارة الخدمة
بعد التطوير يأتي الاختبار والنشر ثم التشغيل والصيانة (ضمن SDLC). ومن منظور إداري، لا يُعد المشروع ناجحًا إلا إذا استقر التشغيل وقلّ عدد الأعطال وتحسنت الخدمة.
الفرع الثاني: إدارة الخدمات وفق منظور القيمة (ITIL 4)
يُركز ITIL 4 على تحقيق القيمة عبر “سلسلة قيمة الخدمة” (Service Value Chain) بوصفها نموذج تشغيل يستجيب للطلب ويحقق القيمة من خلال إدارة المنتجات والخدمات. وهذا يعزز فكرة أن تصميم النظام يجب أن يضمن قابلية التشغيل والدعم والتحسين، لا مجرد التسليم التقني.
المبحث الثالث: الضوابط الإدارية لنجاح تصميم نظم المعلومات
المطلب الأول: إدارة المخاطر والأمن وجودة البيانات
الفرع الأول: المخاطر (الوقت/التكلفة/النطاق/الأمن)
من أكثر أسباب الفشل: توسع النطاق (Scope creep)، ضعف الضبط الزمني، غياب إدارة المورد البشري، وتجاهل مخاطر الأمن. وتبرز أهمية الحوكمة (ISO 38500/COBIT) في ضبط القرارات والمسؤوليات.
الفرع الثاني: جودة البيانات وحوكمتها
إذا كانت بيانات الإدخال غير دقيقة أو غير موحدة، فإن مخرجات النظام (التقارير والقرارات) ستكون مضللة. لذلك يجب وضع سياسات: توحيد القواميس، صلاحيات الإدخال، تدقيق، وتتبع أثر التعديل (Audit trail).
المطلب الثاني: إدارة المشروع والموارد والتواصل
الفرع الأول: حوكمة المشروع وأصحاب المصلحة
نجاح المشروع يتطلب: راعٍ إداري (Sponsor)، لجنة توجيه، مالك منتج/عملية، ومستخدمين أساسيين. كما يلزم تواصل مستمر لتجنب فجوة “ما طلبته الإدارة” و”ما فهمه الفريق”.
الفرع الثاني: بناء القدرات والتكوين
التكوين ليس مرحلة ثانوية؛ بل هو أداة لتقليل مقاومة التغيير، ورفع الاعتمادية التشغيلية، وضمان الاستفادة من النظام.
المطلب الثالث: قياس الأداء والتحسين المستمر
الفرع الأول: مؤشرات أداء قبل/بعد (KPIs)
يجب تحديد مؤشرات قبل بدء المشروع: زمن معالجة معاملة، نسبة أخطاء، تكلفة تشغيل، رضا المستخدم، ثم قياسها بعد التشغيل لإثبات القيمة.
الفرع الثاني: التحسين المستمر والمرونة
التغير في بيئة الأعمال والقوانين يفرض تحديثات؛ لذا ينبغي أن يُصمم النظام بطريقة مرنة (قابلية تعديل)، مع دورة تحسين مستمرة على مستوى الخدمة (منطق ITIL).
خاتمة
يتضح أن تصميم نظم المعلومات من منظور إداري هو عملية حوكمة ومواءمة وإدارة تغيير بقدر ما هو عمل تقني. فالنجاح يتحقق عندما تُبنى المتطلبات على فهم عميق للعمليات، وتُربط أهداف النظام بمؤشرات قيمة، وتُضبط القرارات بالحوكمة (ISO 38500/COBIT)، وتُدار الخدمة بمنطق القيمة (ITIL 4)، مع اعتماد دورة حياة تطوير واضحة (SDLC). وعليه، فإن جوهر المنظور الإداري يتمثل في نقل النظام من “منتج تقني” إلى “قدرة تنظيمية” تعزز الأداء والشفافية وجودة القرار.
المصادر والمراجع
ISO. ISO/IEC 38500:2015 – Information technology — Governance of IT for the organization.
ISACA. COBIT 2019 resources (overview).
ISACA. COBIT 2019 Framework: Governance and Management Objectives (PDF).
Microsoft. Phases of the Software Development Life Cycle (SDLC).
Atlassian. SDLC overview and common phases.
SonarSource. SDLC definition and phases.
IFS Blog. ITIL 4 Service Value Chain definition (quoting ITIL 4 Foundation).
PeopleCert. ITIL 4 Foundation: Service Value Chain & dimensions.
بحث حول تصميم نظم المعلومات من منظور إداري
مقدمة
أصبحت نظم المعلومات عنصرًا حاسمًا في رفع كفاءة المنظمات وتحسين جودة القرار والرقابة وتنسيق الموارد. غير أن نجاح تصميم نظام معلومات لا يتحقق بمجرد توافر التكنولوجيا، بل يتوقف أساسًا على حسن المواءمة بين أهداف المؤسسة ومتطلبات المستخدمين والحوكمة وإدارة التغيير. لذلك يركز المنظور الإداري لتصميم نظم المعلومات على النظام باعتباره مشروعًا تنظيميًا واستثماريًا يغيّر طرق العمل ويعيد توزيع الأدوار والمسؤوليات، لا مجرد برنامج أو أجهزة.
أهمية الموضوع: تكمن في أن كثيرًا من مشاريع نظم المعلومات تفشل أو تتعثر بسبب ضعف تحليل الاحتياجات، أو غياب الدعم الإداري، أو مقاومة التغيير، أو سوء الحوكمة وإدارة المخاطر، رغم سلامة الحل التقني.
هدف البحث: (1) بيان مفهوم تصميم نظم المعلومات إداريًا، (2) تحديد المراحل الإدارية للتصميم من التخطيط إلى التشغيل، (3) إبراز عوامل النجاح والضوابط (الحوكمة، المخاطر، التغيير، جودة البيانات).
إشكالية البحث: كيف يتم تصميم نظم المعلومات بطريقة تحقق قيمة تنظيمية فعلية للمؤسسة، وما أهم الضوابط الإدارية التي تحكم هذا التصميم لضمان الملاءمة والنجاعة؟
المنهج المتبع: المنهج الوصفي التحليلي؛ من خلال عرض الأطر النظرية (حوكمة/قيمة/مخاطر/خدمة) ثم تحليل مراحل التصميم إداريًا وربطها بممارسات معيارية (SDLC، ITIL، COBIT، ISO 38500).
المبحث الأول: الإطار المفاهيمي لتصميم نظم المعلومات من منظور إداري
المطلب الأول: مفهوم نظام المعلومات ووظيفته الإدارية
الفرع الأول: تعريف نظام المعلومات إداريًا
نظام المعلومات هو منظومة متكاملة تجمع الأفراد والإجراءات والبيانات والتقنيات لإنتاج معلومات تدعم التخطيط والتنظيم والرقابة واتخاذ القرار. ومن منظور إداري، تُقاس قيمة النظام بقدرته على تحسين الأداء وتقليل التكلفة ورفع جودة الخدمة لا بحداثة التكنولوجيا.
الفرع الثاني: وظائف نظام المعلومات داخل المؤسسة
يخدم النظام وظائف إدارية أساسية: دعم القرار (تقارير ولوحات قيادة)، تحسين الرقابة (مؤشرات أداء)، تعزيز التنسيق (تدفق معلومات بين الوحدات)، وتوثيق المعاملات (أثر قانوني/إداري)، وهو ما يجعل التصميم مرتبطًا ببنية العمل (Business Processes) أكثر من ارتباطه بالجانب البرمجي فقط.
المطلب الثاني: مبادئ الحوكمة والمواءمة الاستراتيجية
الفرع الأول: حوكمة تكنولوجيا المعلومات
تؤكد ISO/IEC 38500 أن حوكمة تقنية المعلومات جزء من حوكمة المؤسسة، وتُعنى بتوجيه الاستخدام الحالي والمستقبلي لتكنولوجيا المعلومات عبر قرارات وإجراءات تضمن القيمة والمساءلة.
الفرع الثاني: المواءمة بين أهداف المؤسسة والنظام
يوضح COBIT 2019 أن الحوكمة/الإدارة في مجال المعلومات والتكنولوجيا تستهدف مواءمة التقنية مع أهداف المؤسسة عبر نموذج أهداف وضوابط (Governance & Management Objectives).
المطلب الثالث: تصميم النظام كمشروع تغيير تنظيمي
الفرع الأول: النظام كمشروع استثمار وقيمة
القرار بتصميم نظام معلومات هو قرار استثماري: يجب أن يثبت جدواه (تخفيض أخطاء، تسريع عمليات، شفافية) ويحدد مؤشرات قيمة واضحة قبل التنفيذ.
الفرع الثاني: أثر النظام على الهيكل والثقافة
يغيّر النظام الإجراءات ومسارات الموافقة والصلاحيات، وقد يصطدم بثقافة تنظيمية تقاوم الشفافية أو التحول الرقمي؛ لذا يُعد “إدارة التغيير” شرطًا إداريًا لنجاح التصميم.
المبحث الثاني: مراحل تصميم نظم المعلومات إداريًا
المطلب الأول: التخطيط وتحديد الاحتياجات (Requirements)
الفرع الأول: دراسة الوضع الحالي وتحديد الفجوة
تنطلق المرحلة بتشخيص الوضع الراهن (As-Is): خرائط العمليات، نقاط الاختناق، أخطاء البيانات، ازدواجية العمل. ثم تحديد الوضع المستهدف (To-Be) والفجوة بينهما.
الفرع الثاني: جمع المتطلبات الوظيفية وغير الوظيفية
المتطلبات الوظيفية (ما الذي يجب أن يفعله النظام)، وغير الوظيفية (الأمن، الأداء، التوفر، قابلية التوسع). وتُوثق عادة في مواصفات واضحة قبل التصميم التفصيلي، ضمن مراحل SDLC التي تضع التحليل والتصميم قبل التطوير والتشغيل.
المطلب الثاني: التصميم الإداري (Business Design) والتصميم التقني (Technical Design)
الفرع الأول: إعادة هندسة الإجراءات وتوزيع المسؤوليات
قبل الواجهات وقواعد البيانات، يجب تصميم “نظام عمل”: من ينجز ماذا؟ ما نقاط الرقابة؟ ما الصلاحيات؟ كيف يُضمن الأثر الرقابي والقانوني؟ أي أن التصميم يبدأ بـ تصميم العملية لا الشاشة.
الفرع الثاني: التصميم التقني كترجمة للمتطلبات
يتحول “تصميم الأعمال” إلى معمارية تقنية (قواعد بيانات، تكامل، أمن). وتؤكد أدلة SDLC أن التصميم مرحلة لإنتاج مخطط معماري قبل التطوير والاختبار والنشر.
المطلب الثالث: التنفيذ والتشغيل والتحسين المستمر
الفرع الأول: الاختبار، النشر، وإدارة الخدمة
بعد التطوير يأتي الاختبار والنشر ثم التشغيل والصيانة (ضمن SDLC). ومن منظور إداري، لا يُعد المشروع ناجحًا إلا إذا استقر التشغيل وقلّ عدد الأعطال وتحسنت الخدمة.
الفرع الثاني: إدارة الخدمات وفق منظور القيمة (ITIL 4)
يُركز ITIL 4 على تحقيق القيمة عبر “سلسلة قيمة الخدمة” (Service Value Chain) بوصفها نموذج تشغيل يستجيب للطلب ويحقق القيمة من خلال إدارة المنتجات والخدمات. وهذا يعزز فكرة أن تصميم النظام يجب أن يضمن قابلية التشغيل والدعم والتحسين، لا مجرد التسليم التقني.
المبحث الثالث: الضوابط الإدارية لنجاح تصميم نظم المعلومات
المطلب الأول: إدارة المخاطر والأمن وجودة البيانات
الفرع الأول: المخاطر (الوقت/التكلفة/النطاق/الأمن)
من أكثر أسباب الفشل: توسع النطاق (Scope creep)، ضعف الضبط الزمني، غياب إدارة المورد البشري، وتجاهل مخاطر الأمن. وتبرز أهمية الحوكمة (ISO 38500/COBIT) في ضبط القرارات والمسؤوليات.
الفرع الثاني: جودة البيانات وحوكمتها
إذا كانت بيانات الإدخال غير دقيقة أو غير موحدة، فإن مخرجات النظام (التقارير والقرارات) ستكون مضللة. لذلك يجب وضع سياسات: توحيد القواميس، صلاحيات الإدخال، تدقيق، وتتبع أثر التعديل (Audit trail).
المطلب الثاني: إدارة المشروع والموارد والتواصل
الفرع الأول: حوكمة المشروع وأصحاب المصلحة
نجاح المشروع يتطلب: راعٍ إداري (Sponsor)، لجنة توجيه، مالك منتج/عملية، ومستخدمين أساسيين. كما يلزم تواصل مستمر لتجنب فجوة “ما طلبته الإدارة” و”ما فهمه الفريق”.
الفرع الثاني: بناء القدرات والتكوين
التكوين ليس مرحلة ثانوية؛ بل هو أداة لتقليل مقاومة التغيير، ورفع الاعتمادية التشغيلية، وضمان الاستفادة من النظام.
المطلب الثالث: قياس الأداء والتحسين المستمر
الفرع الأول: مؤشرات أداء قبل/بعد (KPIs)
يجب تحديد مؤشرات قبل بدء المشروع: زمن معالجة معاملة، نسبة أخطاء، تكلفة تشغيل، رضا المستخدم، ثم قياسها بعد التشغيل لإثبات القيمة.
الفرع الثاني: التحسين المستمر والمرونة
التغير في بيئة الأعمال والقوانين يفرض تحديثات؛ لذا ينبغي أن يُصمم النظام بطريقة مرنة (قابلية تعديل)، مع دورة تحسين مستمرة على مستوى الخدمة (منطق ITIL).
خاتمة
يتضح أن تصميم نظم المعلومات من منظور إداري هو عملية حوكمة ومواءمة وإدارة تغيير بقدر ما هو عمل تقني. فالنجاح يتحقق عندما تُبنى المتطلبات على فهم عميق للعمليات، وتُربط أهداف النظام بمؤشرات قيمة، وتُضبط القرارات بالحوكمة (ISO 38500/COBIT)، وتُدار الخدمة بمنطق القيمة (ITIL 4)، مع اعتماد دورة حياة تطوير واضحة (SDLC). وعليه، فإن جوهر المنظور الإداري يتمثل في نقل النظام من “منتج تقني” إلى “قدرة تنظيمية” تعزز الأداء والشفافية وجودة القرار.
المصادر والمراجع
ISO. ISO/IEC 38500:2015 – Information technology — Governance of IT for the organization.
ISACA. COBIT 2019 resources (overview).
ISACA. COBIT 2019 Framework: Governance and Management Objectives (PDF).
Microsoft. Phases of the Software Development Life Cycle (SDLC).
Atlassian. SDLC overview and common phases.
SonarSource. SDLC definition and phases.
IFS Blog. ITIL 4 Service Value Chain definition (quoting ITIL 4 Foundation).
PeopleCert. ITIL 4 Foundation: Service Value Chain & dimensions.