كيف تعطل عمليات الحلقة المفتوحة تدفق المعلومات في الأعمال

نشرت: 2022-03-11

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

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

يمكن أن تكلف الحلقات المفتوحة ملايين الدولارات

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

اتصال أحادي الاتجاه بين مجالات المسؤولية

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

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

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

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

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

إنشاء تدفقات معلومات ثنائية الاتجاه

إنشاء تدفقات معلومات ثنائية الاتجاه
تدفق المعلومات في اتجاهين

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

الخطوةالاولى

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

الخطوة الثانية

يزود التصنيع التمويل بتفصيل لمكونات X التي سيتم استبدالها خلال فترة الخدمة. ينشئ Finance علامات الأصول لكل مكون ويؤكد مع التصنيع. يتم ملء كلتا وحدتي تخطيط موارد المؤسسات (ERP) بعلامات أصول مطابقة لكل مكون ، مما يسمح بالتتبع عبر دورة حياة الأصول.

الخطوة الثالثة

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

الخطوة الرابعة

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

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

ضمان إجراءات الطوارئ

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

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

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

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

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

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

تأكيد الأحداث الرئيسية

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

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

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

إجراءات معالجة استثناء التصميم

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

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

إجراءات معالجة استثناء التصميم

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

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

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

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

تعلم كيفية إنشاء عمليات الحلقة المغلقة من SQL

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