من يستطيع اليوم العثور على المعلومات الصحيحة في شركتك؟

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

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

1. العَرَض ليس "لدينا الكثير من الملفات"

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

• أين يأتي الطلب الجديد؟
• أي سجل يمثل الحالة الحقيقية؟
• من لديه الخطوة التالية؟
• ما هو الإصدار المعتمد؟
• ما هو القرار الذي تم اتخاذه ولماذا؟
• ماذا يحدث عندما تكون المعلومات مفقودة؟
• من يستطيع حل الاستثناء؟

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

لا يقوم المجلد الأساسي بحد ذاته بإنشاء عملية أساسية.

2. التكلفة الخفية لإعادة بناء السياق

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

قد تشمل التكلفة الإجمالية ما يلي:

• وقت البحث.
• الانقطاعات الداخلية.
• انتظر.
• إعادة العمل بسبب استخدام إصدار غير صحيح.
• قرارات مكررة
• أخطاء النقل بين المناطق.
• الاعتماد على الأشخاص الرئيسيين.
• - صعوبة دمج موظفين جدد.

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

3. ميّز بين أربع مشاكل غالباً ما تكون مختلطة

معلومات متناثرة

توجد البيانات ذات الصلة في أدوات متعددة دون وجود قاعدة واضحة بشأن أي منها له الأسبقية.

معلومات غير منظمة

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

المعلومات دون ملكية

ولا يتحمل أحد مسؤولية واضحة عن تحديثه وجودته.

معلومات بدون سياق تشغيلي

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

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

4. ابدأ بكائنات الأعمال

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

لكل كائن تحديد:

السؤال ليس "في أي مجلد نحفظ هذه البيانات؟"، بل "ماذا تمثل هذه البيانات ضمن العملية وما هي القرارات التي تعتمد عليها؟"

5. ماذا يعني أن يكون لديك مصدر للحقيقة؟

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

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

مصدر الحقيقة يحتاج إلى أربع خواص

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

إذا فقد أي من الأربعة، تتدهور الثقة.

6. قواعد تزامن التصميم، وليس النسخ العشوائية

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

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

لكل حقل مشترك من المستحسن أن تقرر:

• حيث يتم إنشاؤه.
• أين يمكن تحريره؟
• ومن يصدق ذلك؟
• ما هي الأنظمة التي تستهلكها.
• ماذا يحدث إذا فشلت المزامنة.

7. تقوم الدول بتحويل المعلومات إلى عملية

حفظ البيانات لا يكفي. تحتاج العملية إلى معرفة الوضع الذي تمر به كل حالة.

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

يسمح لنا نموذج الحالة الجيد بالإجابة على ما يلي:

• ماذا يمكن أن يحدث بعد ذلك.
• من لديه المسؤولية؟
• ما هو الشرط الذي يسمح بالتقدم.
• كم من الوقت كان واقفاً؟
• ما هي الحالات التي تتطلب الاهتمام.

8. اجعل الملكية واضحة

عادةً ما تنتهي مهمة "الفريق" إلى أن تكون مهمة لا أحد. لكل حالة يجب أن يكون هناك مالك حالي أو قاعدة مهمة واضحة.

الملكية لا تعني أن يقوم شخص واحد بكل العمل. وهذا يعني أن شخصًا ما مسؤول عن المضي قدمًا في القضية أو تصعيدها.

ومن السهل أيضًا التمييز بين مالك البيانات ومالك العملية والشخص الفني المسؤول عن النظام. يمكن أن يكونوا أشخاصًا مختلفين.

9. سجل القرارات، وليس كل نقرة

التتبع المفيد لا يعني تخزين ضوضاء لا نهائية. إنه يسجل ما يسمح لنا بإعادة بناء القرار ذي الصلة:

• تغيير الحالة الهامة.
• الموافقة أو الرفض.
• تعديل البيانات الهامة.
• الشخص المسؤول الذي صنع التغيير.
• لحظة التغيير.
• السبب عند الضرورة.

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

10. تصميم الوصول للضرورة، وليس الراحة

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

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

11. لا تحاول حل التنظيم بالبحث الدلالي

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

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

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

12. تجنب تكرار المعلومات "فقط في حالة"

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

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

13. تصميم تدفق الطلب من البداية إلى النهاية

يجب أن يربط نظام المعلومات المدخلات والسياق والجهة المسؤولة والقرار والنتيجة.

1. يدخل الطلب من خلال قناة محددة.
2. تم تسجيله مع الحد الأدنى من البيانات.
3. يتعلق الأمر بالكائن الصحيح.
4. يتم تعيين المسؤول.
5. يتم التحقق من صحة المعلومات اللازمة.
6. تم تنفيذ الإجراء أو الموافقة عليه.
7. يتم تسجيل النتيجة.
8. يتم تفعيل الخطوة التالية.
9. يتم تصعيد الاستثناءات مع السياق.

توضح هذه الرحلة المجالات التي تستحق الأتمتة والأماكن التي تحتاج إلى الحكم البشري.

14. قم بقياس ما إذا كانت البنية تتحسن بالفعل

قبل التغيير، سجل خط الأساس. ثم قم بالقياس مرة أخرى.

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

15. تمرين عملي لكشف ديون المعلومات

اختر من بين خمس إلى عشر حالات حديثة أثارت شكوكًا أو تأخيرات أو إعادة صياغة. لكل واحد إعادة البناء:

• الأدوات المستخدمة.
• تمت استشارة المحفوظات.
• الرسائل المرسلة.
• الناس الذين كان لا بد من سؤالهم.
• بيانات مكررة.
• قرارات بدون تسجيل.
• انتظر.
• النقاط التي لم يكن من الواضح فيها من يجب أن يتصرف.

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

16. كيفية تحديد أولويات التحسينات

لا تحاول مركزة كل شيء في وقت واحد. قم بإعطاء الأولوية للكائنات والتدفقات التي تولد التأثير الأكبر.

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

الاستنتاج

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

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

في وقت لاحق فقط يصبح من المنطقي إضافة الأتمتة أو الذكاء الاصطناعي. يمكن للتكنولوجيا تسريع النظام الواضح؛ لا يمكن أن تقرر للمنظمة ما هي المعلومات الصحيحة.

لمعرفة كيف نقوم بتحليل العمليات والبيانات والتبعيات قبل تصميم الحل، راجع طريقتنا.