إدارة التغيير (الهندسة)
تُعرّف عملية إدارة طلبات التغيير في هندسة النظم بأنها عملية طلب التغييرات على النظام ، وتحديد إمكانية تحقيقها، والتخطيط لها، وتنفيذها، وتقييمها . وتتمثل أهدافها الرئيسية في دعم معالجة التغييرات وتتبعها لمجموعة مترابطة من العوامل. [ 1 ]
مقدمة
يوجد تداخل كبير وخلط بين إدارة طلبات التغيير، والتحكم في التغيير ، وإدارة التكوين . ولا يدمج التعريف أدناه هذه المجالات بعد.
حظيت إدارة طلبات التغيير بقبول واسع لقدرتها على تحقيق فوائد ملموسة من خلال تحسين النظام المتأثر، وبالتالي تلبية "احتياجات العملاء"، إلا أنها وُجهت إليها انتقادات أيضاً لاحتمالية تسببها في إرباك عملية إدارة التغيير وتعقيدها بلا داعٍ. في بعض الحالات، ولا سيما في مجال تكنولوجيا المعلومات ، يُخصص قدر أكبر من الأموال والجهود لصيانة النظام (وإدارة طلبات التغيير) مقارنةً بإنشاء النظام في البداية. [ 2 ] عادةً ما يتراوح استثمار المؤسسات خلال مرحلة التنفيذ الأولي لأنظمة تخطيط موارد المؤسسات (ERP) الكبيرة بين 15 و20 بالمئة من الميزانية الإجمالية.
وعلى نفس المنوال، يصف هينلي اثنين من قوانين ليمان لتطور البرمجيات : [ 3 ]
- قانون التغيير المستمر : يجب أن تتغير الأنظمة المستخدمة، وإلا ستصبح أقل فائدة تلقائيًا.
- قانون التعقيد المتزايد : من خلال التغييرات، يصبح هيكل النظام أكثر تعقيدًا، وتتطلب عملية تبسيطه المزيد من الموارد.
تُعدّ إدارة طلبات التغيير ذات أهمية بالغة في مجال التصنيع، الذي يواجه العديد من التغييرات نتيجةً لتزايد المنافسة العالمية ، والتقدم التكنولوجي، ومتطلبات العملاء المتزايدة. [ 4 ] ولأن العديد من الأنظمة تميل إلى التغيير والتطور مع الاستخدام، فإن مشاكل هذه الصناعات تُعاني منها صناعات أخرى بدرجات متفاوتة.
ملاحظات: في العملية أدناه، يمكن القول بأن لجنة التغيير يجب أن تكون مسؤولة ليس فقط عن قرارات القبول/الرفض، ولكن أيضًا عن تحديد الأولويات، مما يؤثر على كيفية تجميع طلبات التغيير للمعالجة.
العملية ومخرجاتها
لوصف عملية إدارة طلبات التغيير، تُستخدم تقنية النمذجة الفوقية . يوضح الشكل 1 مخطط البيانات والعملية ، والذي سيتم شرحه في هذا القسم.
أنشطة
تتألف عملية إدارة طلبات التغيير من ستة أنشطة رئيسية، وهي: تحديد التغيير المحتمل، وتحليل طلب التغيير، وتقييم التغيير، وتخطيط التغيير، وتنفيذ التغيير، ومراجعة التغيير وإغلاقه. تُنفَّذ هذه الأنشطة بواسطة أربعة أدوار مختلفة ، موضحة في الجدول 1. أما الأنشطة (أو أنشطتها الفرعية، إن وُجدت) نفسها، فتُشرح في الجدول 2.
| دور | وصف |
|---|---|
| عميل | العميل هو الدور الذي يطلب التغيير بسبب المشاكل التي واجهها أو متطلبات الوظائف الجديدة؛ يمكن أن يكون هذا شخصًا أو كيانًا تنظيميًا ويمكن أن يكون داخل الشركة أو خارجها التي يُطلب منها تنفيذ التغيير. |
| مدير المشروع | مدير المشروع هو المسؤول عن المشروع الذي يتعلق به طلب التغيير. وفي بعض الحالات، يوجد مدير تغيير مستقل يتولى هذا الدور. |
| لجنة التغيير | تتولى لجنة التغيير تحديد ما إذا كان سيتم تنفيذ طلب التغيير أم لا. وفي بعض الأحيان، يتولى مدير المشروع هذه المهمة أيضاً. |
| أداة تغيير البناء | إن الشخص الذي يقوم بتخطيط وتنفيذ التغيير هو الشخص الذي يخطط وينفذ التغيير؛ ويمكن القول إن عنصر التخطيط يتم (جزئياً) بواسطة مدير المشروع. |
| نشاط | النشاط الفرعي | وصف |
|---|---|---|
| تحديد التغيير المحتمل | يتطلب وظائف جديدة [ 5 ] | يرغب العميل في وظائف جديدة ويضع متطلبات محددة. |
| مشكلة المواجهة [ 5 ] | يواجه أحد العملاء مشكلة (مثل خلل برمجي ) في النظام، وهذا يؤدي إلى تقديم تقرير مشكلة. | |
| طلب تغيير | يقترح العميل تغييرًا من خلال إنشاء طلب تغيير. | |
| تحليل طلب التغيير | تحديد الجدوى الفنية | يحدد مدير المشروع الجدوى الفنية لطلب التغيير المقترح، مما يؤدي إلى تحديد الجدوى الفنية للتغيير. |
| تحديد التكاليف والفوائد | يُحدد مدير المشروع تكاليف وفوائد طلب التغيير المقترح، مما ينتج عنه تكاليف وفوائد التغيير. يمكن تنفيذ هذا النشاط الفرعي والنشاط الفرعي المذكور أعلاه بأي ترتيب، وهما مستقلان عن بعضهما البعض، ولذلك يُنمذجان كأنشطة غير مرتبة. | |
| تقييم التغيير | استنادًا إلى طلب التغيير، وجدواه الفنية، وتكاليفه وفوائده، تتخذ لجنة التغيير قرار الموافقة أو الرفض. وقد صُممت هذه الخطوة كنشاط منفصل نظرًا لأهميتها في العملية، ولأنها تُنفذ من قِبل جهة أخرى. كما صُممت كنشاط فرعي (دون أن يتضمنها أي نشاط آخر) وفقًا لتوصية ريمكو هيلمز (تواصل شخصي). | |
| تغيير الخطة | تحليل تأثير التغيير | يُحدد نطاق التغيير (أي العناصر الأخرى التي يؤثر عليها) من خلال تحليل أثر التغيير. ويمكن القول إن هذا النشاط يؤدي إلى قرار آخر بالموافقة أو الرفض، أو أنه يُعد جزءًا من نشاط تحليل طلب التغيير. وقد صُمم هنا كمهمة تخطيطية لمنشئ التغيير نظرًا لارتباطه بنشاط نشر التغيير. |
| وضع خطة | يتم إعداد خطة تغيير لتنفيذ التغيير . توضح بعض أوصاف العمليات (مثل ماكارينن، 2000) أنه من الممكن أيضًا "حفظ" التغييرات ومعالجتها لاحقًا دفعةً واحدة . يمكن اعتبار هذا النشاط نقطةً مناسبةً للقيام بذلك. | |
| تنفيذ التغيير | تنفيذ التغيير | التغيير "مبرمج"؛ هذا النشاط له علاقة قوية بنشر التغيير، لأنه في بعض الأحيان يجب تكييف التغيير مع أجزاء أخرى من النظام (أو حتى أنظمة أخرى) أيضًا. |
| نشر التغيير | يجب نشر التغييرات الناتجة عن تنفيذ التغيير إلى أجزاء النظام الأخرى المتأثرة به. ولأن هذا النشاط الفرعي والنشاط الفرعي المذكور أعلاه يعتمدان على بعضهما البعض بشكل كبير، فقد تم تصميمهما كنشاطين متزامنين. | |
| تغيير الاختبار | يختبر مُنشئ التغيير ما إذا كان ما أنشأه يعمل بالفعل ويلبي طلب التغيير. وكما هو موضح في الرسم التخطيطي، يمكن أن ينتج عن ذلك عملية تكرارية بالإضافة إلى النشاطين الفرعيين المذكورين أعلاه. | |
| تحديث الوثائق | تم تحديث الوثائق لتعكس التغييرات المطبقة. | |
| تغيير الإصدار | تم إصدار نسخة جديدة من النظام تعكس التغيير المطبق. | |
| مراجعة وإغلاق الباقي | تحقق من التغيير | تم التحقق من تطبيق التغيير في إصدار النظام الجديد للمرة الأخيرة، وهذه المرة من قبل مدير المشروع. ربما كان من الضروري القيام بذلك قبل الإصدار، ولكن نظرًا لتضارب المصادر المرجعية وتعقيد المخطط، تم اختيار هذا الأسلوب في التصميم وإدراج هذه المسألة. |
| فكة قريبة | اكتملت دورة التغيير هذه ، أي تم الانتهاء من إدخال سجل التغييرات. |
المخرجات
إلى جانب الأنشطة، يُظهر مخطط البيانات والعمليات (الشكل 1) أيضًا مخرجات كل نشاط، أي البيانات. هذه المخرجات أو المفاهيم موضحة في الجدول 3؛ وفي هذا السياق، أهم المفاهيم هي: طلب التغيير وإدخال سجل التغييرات.
بعض المفاهيم مُعرَّفة من قِبَل المؤلف (أي تفتقر إلى مرجع)، إما لعدم وجود تعريفات (جيدة) لها، أو لأنها نتيجة طبيعية لنشاط ما. هذه المفاهيم مُشار إليها بعلامة النجمة (*). تم استبعاد خصائص المفاهيم من النموذج، لأن معظمها بديهي، وإلا فقد يصبح الرسم التخطيطي معقدًا للغاية. علاوة على ذلك، فإن بعض المفاهيم (مثل طلب التغيير، إصدار النظام) تُناسب أسلوب الترقيم كما اقترحه ويرد [ 6 ] ، ولكن تم استبعاد هذا الأسلوب أيضًا بسبب قيود تعقيد الرسم التخطيطي.
| مفهوم | وصف |
|---|---|
| متطلبات | الوظيفة المطلوبة لمكون (أو عنصر؛ ناسا، 2005). |
| تقرير المشكلة | وثيقة تصف مشكلة لا يمكن حلها بواسطة موظف مكتب المساعدة من المستوى 1؛ تحتوي على عناصر مثل التاريخ، ومعلومات الاتصال بالشخص الذي أبلغ عن المشكلة، وما الذي يسبب المشكلة، وموقع المشكلة ووصفها، والإجراء المتخذ والتصرف، ولكن هذا غير موضح في الرسم التخطيطي (دينيس وآخرون، 2002). |
| طلب تغيير | وثيقة تصف التغيير المطلوب وأهميته؛ يمكن أن تنشأ من تقارير المشكلات، أو تحسينات النظام، أو مشاريع أخرى، أو تغييرات في الأنظمة الأساسية، أو من الإدارة العليا، وهي مُلخصة هنا باسم "المتطلبات" (دينيس وآخرون، 2002). السمة المهمة: "قرار التنفيذ/الرفض"، أي هل سيتم تنفيذ التغيير أم لا؟ |
| سجل التغييرات* | يُعدّ هذا إدخالاً مميزاً ضمن مجموعة جميع التغييرات (مثلاً لمشروع ما)؛ ويتألف من طلب تغيير، وجدوى التغيير الفنية، وتكاليف وفوائد التغيير، وتحليل أثر التغيير، وتخطيط التغيير، وتقرير الاختبار، والتحقق من التغيير. ولا يلزم تضمين جميع هذه العناصر إذا تم إنهاء العملية مبكراً (أي إذا لم يتم تنفيذ التغيير). |
| تغيير الجدوى التقنية | مفهوم يشير إلى ما إذا كان من الممكن الحصول على "الأجهزة والبرامج الموثوقة والموارد التقنية القادرة على تلبية احتياجات النظام المقترح [أي طلب التغيير] أو تطويرها من قبل منظمة في الوقت المطلوب" (فوغل، 2004). |
| تكاليف وفوائد التغيير | الجهد المتوقع المطلوب لتنفيذ التغيير والمزايا (مثل توفير التكاليف، وزيادة الإيرادات) التي يتم الحصول عليها من خلال تنفيذه. ويُطلق عليه أيضًا الجدوى الاقتصادية (فوغل، 2004). |
| تحليل أثر التغيير | تقييم لمدى التغيير. [ 7 ] |
| تخطيط التغيير | "مخطط أو طريقة أو تصميم لتحقيق هدف ما أو لتحقيق شيء ما [أي التغيير]" (جامعة جورج تاون، بدون تاريخ)، وفي هذه الحالة التغيير. |
| غرض | "مصطلح غير محدد يستخدم للدلالة على أي منتج ، بما في ذلك الأنظمة والأنظمة الفرعية والتجميعات والتجميعات الفرعية والوحدات والمجموعات والملحقات وبرامج الكمبيوتر وبرامج الكمبيوتر أو الأجزاء" (ريجبي، 2003)؛ له أنواع فرعية (متداخلة) العنصر المضاف والعنصر المتغير. |
| عنصر إضافي* | واضح بذاته: عنصر تم إنشاؤه حديثًا؛ نوع فرعي من العنصر. |
| تم تغيير المنتج* | واضح بذاته: عنصر موجود بالفعل، ولكن تم تغييره؛ نوع فرعي من العنصر. |
| تقرير الاختبار | "وثيقة تصف سلوك ونتائج الاختبارات التي أجريت لنظام أو مكون [متأثر بالتغيير]" (IEEE، 1991). |
| الوثائق | بحسب تعريف مكتبات جامعة ولاية بنسلفانيا (2004)، فإن الوثائق هي "مواد مطبوعة تُرفق بمواد أخرى (عادةً ما تكون غير كتب)، وتشرح أو تقدم تعليمات الاستخدام، أو تعمل كدليل للمواد الرئيسية". وفي هذا السياق، يمكن أن تشمل أيضاً المواد الرقمية أو حتى التدريب، طالما أنها تتعلق (بأجزاء من) النظام. |
| إصدار النظام | «[السلع] المعروضة للبيع أو العرض العام» (جامعة برينستون، 2003). تتكون من عنصر واحد أو أكثر والوثائق المصاحبة له. |
| التحقق من التغيير | تحديد ما إذا كانت نتيجة تنفيذ التغيير تفي بالمتطلبات التي تم تحديدها سابقًا (ريجبي، 2003). |
إلى جانب "التغييرات" فحسب، يمكن التمييز أيضًا بين الانحرافات والإعفاءات. [ ٨ ] الانحراف هو إذن (أو طلب إذن) بالخروج عن أحد متطلبات عنصر ما، قبل إنشائه. أما الإعفاء فهو مماثل له، ولكنه يُمنح أثناء إنشاء العنصر أو بعده. ويمكن اعتبار هذين النهجين بمثابة إدارة مبسطة لطلبات التغيير (أي لا يقدمان حلاً جذريًا للمشكلة المطروحة).
أمثلة
يُعدّ تطوير البرمجيات مثالًا جيدًا على عملية إدارة طلبات التغيير . فكثيرًا ما يُبلغ المستخدمون عن الأخطاء أو يرغبون في وظائف جديدة لبرامجهم، مما يؤدي إلى طلب تغيير . تقوم شركة البرمجيات بدراسة الجدوى التقنية والاقتصادية لتنفيذ هذا التغيير، ومن ثمّ تُقرر ما إذا كان سيُنفّذ بالفعل. إذا كان الأمر كذلك، فيجب التخطيط للتغيير، على سبيل المثال باستخدام نقاط الوظائف . يؤدي التنفيذ الفعلي للتغيير إلى إنشاء و/أو تعديل شفرة البرنامج ، وعند نشر هذا التغيير، فإنه يُحتمل أن يُؤدي إلى تغيير أجزاء أخرى من الشفرة أيضًا. بعد أن تبدو نتائج الاختبار الأولية مُرضية، يُمكن تحديث الوثائق وإصدارها مع البرنامج. أخيرًا، يُدقّق مدير المشروع التغيير ويُغلق هذا الإدخال في سجل التغييرات.
يُعدّ مجال التصنيع مثالًا نموذجيًا آخر لإدارة طلبات التغيير، كما هو مُبيّن هنا . لنأخذ على سبيل المثال تصميم وإنتاج سيارة . فإذا تبيّن، على سبيل المثال، أن الوسائد الهوائية في السيارة تنتفخ تلقائيًا بالهواء بعد قطع مسافات طويلة، فسيؤدي ذلك بلا شك إلى شكاوى من العملاء (أو، نأمل، تقارير عن مشاكل خلال مرحلة الاختبار). وهذا بدوره يُنتج طلب تغيير (انظر الشكل 2 على اليمين)، والذي يُرجّح أن يُبرّر إجراء التغيير. ومع ذلك، يجب إجراء تحليل - غالبًا ما يكون مبسطًا - للتكاليف والفوائد، وبعد ذلك يُمكن الموافقة على طلب التغيير. بعد تحليل تأثير التغيير على تصميم السيارة وجداول الإنتاج، يُمكن وضع خطة لتنفيذه. وبناءً على هذه الخطة، يُمكن تنفيذ التغيير فعليًا، وبعد ذلك، نأمل، يتم اختبار النسخة الجديدة من السيارة بدقة قبل طرحها للجمهور.
المصانع قيد المعالجة
نظراً لحساسية العمليات المعقدة الشديدة حتى لأصغر التغييرات، يُعدّ الإدارة السليمة للتغييرات في المصانع الصناعية أمراً بالغ الأهمية للسلامة. فالتغييرات غير الموثقة وغير المدروسة جيداً للمخاطر تُنذر بكارثة. ومن الأمثلة البارزة على ذلك انفجار فليكسبورو ، حيث كانت التغييرات الارتجالية التي تضمنت تجاوز مرحلة في سلسلة المفاعل سبباً رئيسياً للحادث. لم يُدرس التغيير جيداً، ولم يُوثق، ولم تُقيّم مخاطره، ما حال دون اكتشاف حادثة الاختراق. [ 9 ] في الولايات المتحدة، لدى إدارة السلامة والصحة المهنية (OSHA) لوائح تنظم كيفية إجراء التغييرات وتوثيقها. ويتمثل الشرط الأساسي في إجراء مراجعة شاملة للتغيير المقترح من قِبل فريق متعدد التخصصات لضمان استخدام أكبر عدد ممكن من وجهات النظر لتقليل احتمالية إغفال أي خطر. في هذا السياق، تُعرف إدارة طلبات التغيير باسم إدارة التغيير (MOC). وهي أحد مكونات إدارة سلامة العمليات ، القسم 1910.119(l).1.
انظر أيضاً
ملاحظات ومراجع
- ^ كرنكوفيتش وبيرسون دالكفيست (2003).
- ^ دينيس، ويكسوم وتيجاردن (2002).
- ↑ هينلي 1996 .
- ↑ هوانغ وماك 1999 .
- في الواقع، ليس من الضروري وجود كل من متطلبات وظيفة جديدة واكتشاف مشكلة للحصول على طلب تغيير. عادةً ما يتحقق أحدهما فقط. ويمكن تقريب هذا المعنى من خلال نمذجة هذه العمليات كأنشطة غير مرتبة. وثمة بديل يتمثل في إنشاء نقطتي بداية منفصلتين (أي حالتين ابتدائيتين)، تشير كلتاهما إلى طلب التغيير .
- ↑ غريب (2006).
- ↑ راجليتش 1999 .
- ↑ سكوت ونيس (2001).
- ↑ مانان (2012).
المراجع والمصادر الإضافية للقراءة
- كرنكوفيتش، آي.، أسكلوند، يو.، وبيرسون-دالكفيست، أ. (2003). تطبيق ودمج إدارة بيانات المنتج وإدارة تكوين البرمجيات . لندن: دار أرتيك هاوس.
- دينيس، أ.، ويكسوم، ب.هـ.، وتيغاردن، د. (2002). تحليل وتصميم النظم: منهج كائني التوجه باستخدام لغة النمذجة الموحدة (UML ). هوبوكين، نيويورك: جون وايلي وأولاده.
- جامعة جورجتاون (بدون تاريخ). مستودع البيانات: مسرد المصطلحات . تم استرجاعه في 13 أبريل 2006 من : https://web.archive.org/web/20060423164505/http://uis.georgetown.edu/departments/eets/dw/GLOSSARY0816.html
- هينلي، ديفيد س. (نوفمبر 1996). "إدارة تطور البرمجيات: منظور موجه نحو العمليات". تكنولوجيا المعلومات والبرمجيات . 38 (11): 723-730 . doi : 10.1016/0950-5849(96)01122-6 .
- هوانغ، جي كيو؛ ماك، كي إل (1999). "الممارسات الحالية لإدارة التغيير الهندسي في الصناعات التحويلية في المملكة المتحدة". المجلة الدولية لإدارة العمليات والإنتاج . 19 (1): 21-37 . doi : 10.1108/01443579910244205 .
- معهد مهندسي الكهرباء والإلكترونيات (1991). معجم المصطلحات القياسي لهندسة البرمجيات (ANSI) . معهد مهندسي الكهرباء والإلكترونيات. تم استرجاعه في 13 أبريل 2006 من: http://www.ee.oulu.fi/research/ouspg/sage/glossary/#reference_6 . مؤرشف في 21 أكتوبر 2009 على موقع Wayback Machine .
- ماكارينن، م. (2000). عمليات إدارة تغيير البرمجيات في تطوير البرمجيات المدمجة . أطروحة دكتوراه. إسبو: منشورات VTT. متاح على الإنترنت : http://www.vtt.fi/inf/pdf/publications/2000/P416.pdf
- مانان، سام (2012). الوقاية من الخسائر في الصناعات التحويلية (الطبعة الرابعة). أكسفورد: باتروورث-هاينمان . ISBN 978-0-12-397189-0.
- ناسا (2005). برنامج بيانات مقاييس مرافق التحقق والتدقيق المستقل التابع لناسا - مسرد المصطلحات والتعريفات . تم استرجاعه في 4 مارس 2006 من: https://web.archive.org/web/20060307232014/http://mdp.ivv.nasa.gov/mdp_glossary.html
- مكتبات جامعة ولاية بنسلفانيا (2004). دليل CCL: مسرد المصطلحات والاختصارات . تم استرجاعه في 13 أبريل 2006 من: https://web.archive.org/web/20060615021317/http://www.libraries.psu.edu/tas/cataloging/ccl/glossary.htm .
- جامعة برينستون (2003). WordNet 2.0 . تم استرجاعه في 13 أبريل 2006 من: http://dictionary.reference.com/search?q=release .
- رايليخ، فاكلاف (1999). "تغيير البرمجيات وتطورها". SOFSEM'99: نظرية وممارسة المعلوماتية . سلسلة محاضرات في علوم الحاسوب. المجلد 1725. الصفحات 189-202 . doi : 10.1007/3-540-47849-3_12 . ISBN 978-3-540-66694-3.
- ريجبي، ك. (2003). إدارة المعايير: مسرد المصطلحات . تم استرجاعه في 1 أبريل 2006 من: https://web.archive.org/web/20060412081603/http://sparc.airtime.co.uk/users/wysywig/gloss.htm
- سكوت، جيه إيه ونيس، دي. (2001). إدارة تكوين البرمجيات، دليل إلى مجموعة معارف هندسة البرمجيات ، الفصل 7، مطبعة جمعية الحاسبات IEEE.
- فوغل، ج. (2004). نظم المعلومات الإدارية: مسرد المصطلحات . تم استرجاعه في 13 أبريل 2006 من موقع جامعة شهداء أوغندا الإلكتروني: https://web.archive.org/web/20060411160145/http://www.321site.com/greg/courses/mis1/glossary.htm
- ويرد، آي. فان دي (2006). تقنية النمذجة الفوقية: مسودة لدورة هندسة المنهجية 05/06 . تم استرجاعها في 1 مارس 2006 من: https://bscw.cs.uu.nl/bscw/bscw.cgi/d1009019/Instructions for the process-data diagram.pdf [وصول مقيد].
- إدارة التغيير
- هندسة النظم
- سلامة العمليات