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