👏🏻 👩🏾‍⚖️ 🔽 تقنيات التصميم لتنفيذ أنظمة الفوترة للعملاء من الشركات (الجزء 1) 🏪 👨🏽‍⚖️ 🎅🏿

نعم ، تمت كتابة كل شيء 100 مرة حول إدارة المشروع

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

صعوبات نموذجية

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

فيما يلي الصعوبات النموذجية التي نواجهها غالبًا في المشاريع:

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

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

, , , , . CRM . , CRM - , : « / ?».
«» open-source .

- IT-, , . : “ open-source, ”, — , . - « , !»

. , - , , . open-source , - . , 1 .
التوقعات حسب التوقيت.
في السابق ، تم اختيار أنظمة المعلومات للفوترة من قبل خدمة تكنولوجيا المعلومات للمؤسسة. الآن أكثر وأكثر يتم الاختيار من قبل الوحدات المسؤولة عن المبيعات والتسويق. إن الافتقار إلى الخلفية التقنية وانتشار الخدمات السحابية ونمو المعلومات العامة للحياة يخلقان الوهم بالبساطة. لا أحد يعتقد أنه بالنسبة للعمل المريح الحالي مجانًا للمستخدمين العاديين ، فقد تم إنفاق موارد Gmail الخاصة بمؤسسة ضخمة لسنوات عديدة.

لذلك ، نسمع باستمرار أن توقعات توقيت تنفيذ الفواتير هي 3-4 أشهر. من النادر أن يقدر العميل حجم العمل بستة أشهر أو سنة.

إذا قمت بتجميع الأنظمة الفرعية TOP التي تنشأ بها مشكلات مختلفة في المشاريع المعقدة ، فستكون هذه:

CRM
مكتب الخدمات،
المحاسبة الفنية / المخزون.

الآن دعنا ننتقل إلى ثلاث حالات صغيرة ومبالغ فيها قليلاً. تعتبر جميع المصادفات مع أشخاص حقيقيين حادثًا. لم يصب أي خلد الماء في إنتاج الفيلم.

عندما ينعكس الشلال

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

تبدأ المشاكل

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

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

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

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

إعادة بدء

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

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

إن اتباع المنهجية الكلاسيكية لم يساعد في تحديد أوجه القصور في بيان المتطلبات الفنية ، وتطلب مراجعة كاملة لجميع الاتفاقيات مع العميل وإعادة كتابة جميع وثائق المشروع.

اسحب الكرمة

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

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

ظهرت نتيجة لن نفخر بها. أظهرت المشاكل التي كان من الممكن توقعها في البداية بكل مجدها:

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

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

وبالتالي ، فإن الخروج من المشروع هو النتيجة أيضًا ، على الرغم من أنها ليست إيجابية.

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

رشيقة مع قيود الوقت والميزانية والوظائف - WTF ؟!

نعم، هناك شيء من هذا القبيل. قد يرغب العميل في العمل على Agile ، ولكن في الوقت نفسه إصلاح المواعيد النهائية والميزانية والوظائف. بالنسبة لنا ، هذا يسبب التنافر.

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

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

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

هل حفظ الهجين؟

الوضع مشابه للحالة السابقة - يرغب المالك في إطلاق Full MVNO بالإضافة إلى النوع الرئيسي من الأعمال. لدى العميل مواعيد نهائية ضيقة ، ويرتبط مشروع إطلاق MVNO بالعديد من مشاريع الأتمتة الداخلية ذات الصلة.

يضع العميل قيودًا كبيرة على الميزانية وتوقيت المشروع ويتطلب تكامل أنظمة Forward مع أنظمة المعلومات الداخلية باستخدام Oracle DBMS. بالإضافة إلى ذلك ، كما تم إطلاق MVNO الكامل ، مطلوب شراء وتركيب وتكوين معدات الاتصالات السلكية واللاسلكية. سيتم العمل بالاشتراك مع فريق تكنولوجيا المعلومات الخاص بالعميل والعديد من فرق المقاولين الآخرين.

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

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

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

ما هي المشاريع التي لا نأخذها للعمل؟

محو الأمية تصميم منخفض

بالنسبة لنا ، يتم التعبير عن معرفة القراءة والكتابة للمشروع في المقام الأول في وجود خبرة في تنفيذ المشاريع مع موظفي العملاء والعملاء الوظيفيين وصناع القرار و RP من العميل. نقوم بإجراء تقييم في مرحلة المفاوضات الأولية. نحاول التواصل مع DM و RP شخصيًا. إذا كانت التجربة غير واضحة من التواصل ، فيمكننا أن نسأل مباشرة.

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

يمكنك العمل مع أولئك الذين ليس لديهم خبرة في المشروع ، ولكنهم مهتمون بالنتيجة ، يتعمقون في المهام ويستخدمون خبرة الزملاء والمقاولين.

لا يمكنك العمل مع المديرين العنيدين والفخورين والصم.

متطلبات غير كافية

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

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

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

مؤهلات منخفضة من المتخصصين التقنيين العملاء

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

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

المقالة التالية عن المخاطر.

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

في غضون ذلك ، ندعوك في التعليقات لمشاركة تجربتك حول الصعوبات والمشكلات في المشاريع!

تقنيات التصميم لتنفيذ أنظمة الفوترة للعملاء من الشركات (الجزء 1)