تحليل وتصميم النظم ودورة حياة تطوير النظم

محلل النظم

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

مهارات محلل النظم

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

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

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

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

أدوار محلل النظم

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

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

محلل الأعمال

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

محلل المتطلبات

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

محلل البنية التحتية

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

محلل إدارة التغيير

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

مدير المشروع

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

تداخل وتكامل الأدوار

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

دورة حياة تطوير النظم

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

يتبع بناء نظام معلومات مجموعة مماثلة من أربع مراحل أساسية: التخطيط والتحليل والتصميم والتنفيذ. تتكون كل مرحلة من سلسلة من الخطوات التي تعتمد على التقنيات التي تنتج مخرجات (مستندات وملفات محددة تشرح عناصر مختلفة من النظام).

التخطيط

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

1. أثناء بدء المشروع، يتم تحديد قيمة عمل النظام بالنسبة للمؤسسة – كيف سيخفض التكاليف أو يزيد الإيرادات؟ تأتي معظم الأفكار للأنظمة الجديدة من خارج منطقة نظم المعلومات Information Systems (من قسم التسويق، قسم المحاسبة، إلخ) في شكل طلب نظام. يقدم طلب النظام ملخصًا موجزًا ​​لاحتياجات العمل، ويوضح كيف أن النظام الذي يدعم الحاجة سيخلق قيمة تجارية. يعمل قسم نظم المعلومات مع الشخص أو القسم الذي ينشئ الطلب (يسمى راعي المشروع) لإجراء تحليل الجدوى. يفحص تحليل الجدوى الجوانب الرئيسية للمشروع المقترح:

  • الجدوى الفنية (هل يمكننا أن نبنيها؟)
  • والجدوى الاقتصادية (هل ستوفر قيمة تجارية؟)
  • الجدوى التنظيمية (إذا قمنا ببنائها، فهل سيتم استخدامها؟)

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

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

التحليل

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

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

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

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

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

التصميم

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

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

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

3. يتم تطوير مواصفات قاعدة البيانات والملفات. تحدد هذه بالضبط البيانات التي سيتم تخزينها وأين سيتم تخزينها.

4. يطور فريق التحليل تصميم البرنامج، والذي يحدد البرامج التي يجب كتابتها وما سيفعله كل برنامج بالضبط.

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

التنفيذ

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

تتكون هذه المرحلة من ثلاث خطوات:

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

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

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

تحديد المشروع والبدء فيه

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

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

إدارة عمليات الأعمال

اليوم، تنمو العديد من مشاريع نظم المعلومات الجديدة من مبادرات إدارة عمليات الأعمال (BPM). BPM هي منهجية تستخدمها المؤسسات لتحسين العمليات التجارية الشاملة بشكل مستمر. يمكن تطبيق إدارة عمليات الأعمال على العمليات التنظيمية الداخلية والعمليات التي تشمل شركاء أعمال متعددين. من خلال دراسة العمليات التجارية الأساسية وتحسينها، يمكن للمنظمات تحقيق العديد من الفوائد المهمة، بما في ذلك:

  • تحسين سرعة العمليات، مما يمنح المنظمة القدرة على التكيف بشكل أسرع وأكثر فعالية مع بيئة الأعمال المتغيرة؛
  • تحسين مواءمة العمليات مع “أفضل الممارسات” الصناعية؛ و
  • زيادة كفاءات العملية حيث يتم تحديد التكاليف وإزالتها من عمليات سير العمل.

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

  1. تحديد وتخطيط الخطوات في عملية الأعمال،
  2. إيجاد طرق لتحسين خطوات العملية التي تضيف قيمة،
  3. إيجاد طرق لاستبعاد أو توحيد الخطوات التي لا تضيف قيمة في العملية،
  4. إنشاء أو تعديل تدفقات العمل الإلكترونية لتتناسب مع خرائط العملية المحسنة.

الحاجة إلى نظم المعلومات

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

يدرك ممارسو BPM، مع ذلك، أنه ليس من المستحسن دائمًا إضافة الأتمتة لتسريع العمليات الحالية (الخطوة 4 أعلاه). في العديد من المواقف، ينتج تحسين عمليات الأعمال من دراسة العمليات التجارية، وإنشاء عمليات جديدة ومعاد تصميمها لتحسين سير عمل العمليات، و/ أو استخدام تقنيات جديدة تمكن من هيكلة عمليات جديدة (الخطوات 2 و3 و4 أعلاه)، على سبيل المثال، هل يمكن إعادة تصميم عملية الدفع لمتجر بيع بالتجزئة على غرار نظام تحصيل رسوم المرور عبر EZPass على الطرق السريعة؟

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

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

إعادة هندسة عمليات الأعمال

قد تكشف إدارة عمليات الأعمال أيضًا عن الحاجة إلى التجديد الكامل للعمليات التجارية للمؤسسة، والتي يطلق عليها إعادة هندسة عمليات الأعمال (BPR). تعني إعادة هندسة الأعمال تغيير الطريقة الأساسية التي تعمل بها المنظمة – “طمس” الطريقة الحالية لممارسة الأعمال التجارية وإجراء تغييرات كبيرة للاستفادة من الأفكار الجديدة والتكنولوجيا الجديدة، كما قد يُتوقع أن تنطوي مشاريع إعادة هيكلة الأعمال على مخاطر كبيرة بسبب التغييرات التنظيمية والتشغيلية الكبيرة التي تنتج عن ذلك. يُعد دعم الإدارة العليا والإدارة التنفيذية أمرًا بالغ الأهمية في هذه الأنواع النادرة نسبيًا من المشاريع.

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

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

متطلبات العمل

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

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

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

طلب النظام

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

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

المراجع

  • SYSTEM ANALYSIS AND DESIGN, ALAN DENNIS, Indiana University – BARBARA HALEY WIXOM, University of Virginia – ROBERTA M. ROTH, University of Northern Iowa
  • تحليل وتصميم النظم – ترجمة وإعداد، د. مصطفى عبيد، مركز البحوث والدراسات متعدد التخصصات، 2020م.
تحليل وتصميم النظم ودورة حياة تطوير النظم
تحليل وتصميم النظم ودورة حياة تطوير النظم
error:
Scroll to Top