لماذا تفشل الحلول الصناعية؟ — ونادرًا ما يكون السبب هو البرمجيات
لماذا تفشل الحلول الصناعية؟ — ونادرًا ما يكون السبب هو البرمجيات
يمكنك شراء نظام يحقق بدقة كل ما ورد في المواصفات، ونشره بسلاسة، وتدريب الموظفين عليه، ثم تكتشف أن شيئًا لم يتغير فعليًا على أرض الواقع.
تعرض لوحة التحكم الأرقام الصحيحة، لكن لا أحد يتخذ قرارات مختلفة بناءً عليها. ويجمع نظام التدقيق جميع البيانات المطلوبة، بينما تظل معدلات الامتثال على حالها دون تحسن. كما تربط طبقة التكامل بين الأنظمة المختلفة كما هو مخطط لها
، لكن الجزر التنظيمية والانفصال بين الإدارات يبقيان كما هما.
هذه هي الطريقة الأكثر شيوعًا لفشل البرمجيات الصناعية، وغالبًا لا تبدو كفشل على الإطلاق.
فالبرنامج يعمل كما ينبغي، لكنه يبقى مجرد أداة خاملة؛ صحيح من الناحية التقنية، لكنه غير مرئي من الناحية التشغيلية.
والسبب في ذلك يكاد يكون دائمًا واحدًا: ما تم تقديمه كان برنامجًا، بينما ما كانت تحتاجه المؤسسة هو حل. وهذان أمران مختلفان تمامًا.
فالبرمجيات هي منتج أو أداة تنفذ ما تصفه المواصفات الفنية. أما الحل، فهو شيء مختلف كليًا؛ إذ يبدأ بتشخيص المكان الحقيقي الذي تتعطل فيه العمليات، ثم تصميم الاستجابة المناسبة لحجم المشكلة وطبيعتها، وأخيرًا إحداث التغيير السلوكي
والتشغيلي المطلوب لتحقيق النتائج.
قد تكون البرمجيات جزءًا من الحل، لكنها ليست الحل دائمًا.
فأحيانًا تكون الجزء الخطأ من الحل، وأحيانًا تكون جزءًا صغيرًا منه فقط. وفي بعض الحالات — كما سيتضح في إحدى القصص التالية — قد لا يتضمن الحل الحقيقي أي برمجيات جديدة على الإطلاق.
وهنا تكمن الفجوة الأساسية:
الوصف ليس هو التشخيص.
فما يطلبه العميل، أو ما تنص عليه المواصفات، نادرًا ما يكون جوهر المشكلة.
أما التشخيص الحقيقي، فيوجد في مستوى أعمق؛ في كيفية تنفيذ العمل فعليًا، ومن يتحمل المسؤولية عن كل خطوة، وأين تكمن نقاط الاحتكاك والتعطل التي لم يسمِّها أحد. ليس لأنها غير موجودة، بل لأن أحدًا لم يمتلك الوقت الكافي لاكتشافها وفهمها.
وتوضح تجربتان من مشاريعنا كيف يبدو هذا الفرق على أرض الواقع.
عندما كان الحل هو عدم استخدام أي برمجيات على الإطلاق
تواصلت معنا إحدى الشركات الصناعية وهي مقتنعة تمامًا بأن لديها مشكلة برمجية.
كانت الأعراض واضحة ومحددة:
- أوامر الشراء والطلبات تتحرك بوتيرة أبطأ من المتوقع.
- انتقال المهام بين الفرق المختلفة يؤدي إلى فقدان بعض المعلومات.
- شحنات تصل إلى المستودع، بينما لا يملك فريق الاستلام أي سجل أو إشعار مسبق بوجودها.
وبناءً على ذلك، بدأت الشركة البحث عن نظام جديد لسد هذه الفجوات، وافترضت أننا سنبدأ مباشرةً بالتوصية بمنصة أو برنامج جديد.
لكننا اتخذنا مسارًا مختلفًا.
فبدلًا من البحث عن الحل التقني أولًا، بدأنا بالبحث عن المشكلة الحقيقية.
أمضينا عدة أسابيع في دراسة العمليات التشغيلية من البداية إلى النهاية، مرورًا بإدارة المشتريات، والمستودعات، والإنتاج، وضمان الجودة، والخدمات اللوجستية.
جلسنا مع كل قسم على حدة، وطرحنا المجموعة نفسها من الأسئلة على الجميع. ثم ركزنا على نقطة واحدة بالغة الأهمية: أين تبدأ الإجابات بالتباين؟
وعندما وُضعت خرائط سير العمل الخاصة بكل قسم جنبًا إلى جنب، ظهر أمر لم يكن مرئيًا لأي فريق من الداخل.
كان كل قسم يؤدي عمله بصورة جيدة.
كانت الأدوات تعمل.
وكانت الأنظمة تعمل.
وكانت الإجراءات الداخلية تعمل.
لكن المشكلة لم تكن داخل أي قسم.
بل كانت في المساحة الفاصلة بين الأقسام.
فالمعلومات التي كان من المفترض أن تنتقل من إدارة إلى أخرى لم يكن لديها مسار واضح أو مسؤولية محددة تضمن انتقالها. لم يكن هناك خلل في النظام، بل كان هناك فراغ في العملية نفسها.
وبعبارة أخرى: كانت كل إدارة تدير جزءها من العمل بكفاءة، لكن أحدًا لم يكن يدير نقاط التسليم بين الإدارات.
وعندها أوضحنا للعميل ما توصلنا إليه:
أنتم لا تحتاجون إلى برنامج جديد.
ما تحتاجونه هو إعادة تصميم الطريقة التي تتبادل بها الإدارات المهام والمعلومات فيما بينها.
ساعدناهم على تنفيذ هذا التغيير، ولم نبع لهم أي منتج أو نظام.
لأن الحل الذي كانوا يحتاجونه لم يكن تقنيًا في المقام الأول.
كان تشغيليًا.
وبعد سنوات من ذلك المشروع، أصبحت تلك الشركة واحدة من أكثر مصادر الإحالات والتوصيات موثوقية بالنسبة لنا.
ولم يكن السبب جودة البرمجيات التي قدمناها.
بل لأننا لم نقدم برمجيات عندما لم تكن البرمجيات هي الحل.
لقد قمنا بحل المشكلة الحقيقية، لا المشكلة التي ظنوا أنهم يعانون منها.
عندما كان الحل جزءًا بسيطًا مما طلبه العميل
عاد إلينا أحد أوائل عملائنا، وهو مصنع للدهانات، بعد عدة أشهر من بدء التعاون معنا، طالبًا نظامًا متكاملًا لإدارة نشرات بيانات السلامة للمواد الكيميائية (MSDS).
وبدا الطلب واضحًا ومحددًا:
- تخزين نشرات بيانات السلامة.
- إدارة الإصدارات والتحديثات.
- إعداد التقارير التنظيمية والامتثالية.
وعلى الورق، كان هذا النوع من المشاريع يتطلب شهرين إلى ثلاثة أشهر من العمل. كما كان فريقنا يعمل بطاقته القصوى في ذلك الوقت، لذا كان الخيار الأسهل — والأكثر شيوعًا في مثل هذه الحالات — هو الموافقة على الطلب وإدراجه ضمن خطة التطوير للربع القادم.
لكننا لم نبدأ من المواصفات.
بدأنا من الواقع.
سألنا العميل عن الطريقة التي تُدار بها نشرات بيانات السلامة داخل المصنع فعليًا:
- من هم الأشخاص الذين يتعاملون مع هذه الوثائق؟
- أين يتم حفظها؟
- من يحتاج إليها، وفي أي مرحلة من مراحل العمل؟
- ما الذي يتعطل عندما تكون إحدى النشرات مفقودة أو غير محدثة؟
وكانت الإجابة مختلفة تمامًا عما أوحى به الطلب الأصلي.
فبعد دراسة سير العمل اليومي، اكتشفنا أن العميل لا يحتاج إلى نظام متكامل بكل ما يحتويه من وظائف وخصائص.
بل كان يحتاج إلى جزء صغير جدًا من تلك المنظومة.
جزء يتيح له تحويل إجراءاته الحالية إلى نموذج رقمي منظم، دون تغيير جذري في طريقة العمل، ودون الحاجة إلى تدريب مكثف، ودون فرض إجراءات جديدة على المستخدمين.
وبدلًا من قضاء أشهر في بناء نظام كامل، ركزنا على حل المشكلة الأكثر إلحاحًا.
وخلال أسبوعين فقط، كانت النسخة الأولية العملية جاهزة بين أيديهم.
وبدأ استخدامها مباشرة.
ومنذ ذلك الحين، لم تُضف أي وظيفة جديدة لأن أحدًا افترض أنها ستكون مفيدة، بل لأن الاستخدام الفعلي كشف الحاجة إليها.
فكل ميزة أُضيفت لاحقًا جاءت استجابة لسلوك حقيقي، أو مشكلة حقيقية، أو حاجة ظهرت أثناء التشغيل اليومي.
أما النظام الذي يستخدمونه اليوم، فهو مختلف تمامًا عن النظام الذي طلبوه في البداية.
لكنه أكثر نجاحًا.
لأنه لم يُبنَ على قائمة متطلبات نظرية، بل تطوّر تدريجيًا استنادًا إلى واقع العمل نفسه.
وهذه هي إحدى الحقائق التي تتكرر باستمرار في المشاريع الصناعية:
العملاء نادرًا ما يحتاجون إلى كل ما يطلبونه منذ اليوم الأول.
وكلما اقترب الحل من المشكلة الحقيقية، صغر حجمه في البداية، وازدادت قدرته على تحقيق أثر ملموس بسرعة.
لماذا لا يستطيع معظم المورّدين العمل بهذه الطريقة؟
لا يوجد شيء استثنائي أو بطولي في القصتين السابقتين.
ومع ذلك، فإن معظم الشركات الموردة للحلول الصناعية غير قادرة، من الناحية الهيكلية، على اتخاذ قرارات مشابهة.
ومن المهم أن نكون صريحين بشأن السبب.
فمندوب المبيعات الذي يحمل أهدافًا ربع سنوية يصعب عليه أن يقول لعميل مستعد للشراء:
“ربما لا تحتاج إلى هذا الآن.”
وفريق المنتج الذي يُقاس أداؤه بناءً على حجم ما يطوره أو ينجزه لا يستطيع بسهولة تبرير بناء جزء صغير فقط من المطلوب.
فالاقتصاديات الداخلية للشركات — من أهداف المبيعات، وخطط تطوير المنتجات، ومؤشرات الأداء، والالتزامات المرتبطة بخارطة الطريق — تكافئ تنفيذ المواصفات المطلوبة.
لكن تنفيذ المواصفات يختلف جذريًا عن تحسين طريقة عمل المؤسسة.
فالمنظومة التجارية تشجع على تحقيق الهدف الأول، وتفترض ضمنيًا أنه سيؤدي تلقائيًا إلى الهدف الثاني.
وفي كثير من الأحيان، لا يحدث ذلك.
ولهذا السبب تمتلئ بعض المؤسسات بأنظمة عديدة صحيحة من الناحية التقنية، لكنها محدودة الأثر من الناحية التشغيلية.
كل نظام منها يقدّم بالضبط ما طُلب منه.
ومع ذلك، تظل المشكلات الحقيقية قائمة في المساحات الفاصلة بين تلك الأنظمة.
خمسة أسئلة يجب طرحها قبل الالتزام بأي حل
إذا كنت بصدد تقييم مزود خدمة أو شريك تقني، فهذه الأسئلة تساعدك على التمييز بين من يفهم عملياتك حقًا، ومن سيكتفي بتنفيذ ما طلبته حرفيًا.
1. هل قضوا وقتًا في مشاهدة العمل الفعلي، أم اكتفوا بالاستماع إلى العرض التقديمي؟
ما يُقال في غرفة الاجتماعات ليس بالضرورة ما يحدث على أرض الواقع.
اسألهم عمّا شاهدوه بأنفسهم، لا عمّا أخبرتهم به فرق العمل.
2. هل يستطيعون وصف نقاط الاحتكاك في عملياتك بلغتهم الخاصة؟
المورّد الذي فهم عملياتك فعلًا سيكون قادرًا على وصف مشكلاتك بصورة أدق من الوصف الوارد في وثائق المتطلبات.
أما المورّد الذي يكرر ما سمعه منك فقط، فغالبًا لم يصل بعد إلى جذور المشكلة.
3. هل يبدأون بشيء صغير يمكن استخدامه بسرعة، أم يعدونك بنظام متكامل بعد عدة أشهر؟
حل صغير يعمل فعليًا داخل منشأتك الشهر المقبل أكثر قيمة من نظام ضخم يُسلَّم بعد عام كامل اعتمادًا على افتراضات لم تُختبر.
4. هل هم مستعدون لإخبارك بأنك تحتاج إلى أقل مما طلبت — أو أنك لا تحتاج إلى الشراء أصلًا؟
إذا كان المورّد غير قادر على رفض عملية بيع، فمن الصعب الوثوق بقدرته على تقديم الحل المناسب لحجم المشكلة الحقيقي.
5. هل سيتطلب الحل تدريبًا مكثفًا حتى يتمكن الموظفون من استخدامه؟
عندما ينسجم الحل مع طريقة عمل الأشخاص الحالية، فإنه يُتبنى بصورة طبيعية.
أما الحاجة إلى برامج تدريبية كبيرة ومستمرة، فغالبًا ما تكون مؤشرًا على أن الحل لا يتوافق بالكامل مع الواقع التشغيلي.
إذا لم يكن المورّد قادرًا على التعامل بجدية مع هذه الأسئلة، فقد يكون ما يقدمه صحيحًا تمامًا من الناحية الفنية، ومع ذلك لا يغير شيئًا على أرض الواقع.
كيف نعمل في iSaned — بغض النظر عن طبيعة التحدي
في معظم الحالات، لا يكون الطلب الذي يصلنا هو المشكلة الحقيقية التي تحتاج إلى حل.
ولهذا السبب، سواء كان الموضوع متعلقًا بـ:
- السلامة والصحة المهنية (HSSE).
- الرؤية الحاسوبية والذكاء الاصطناعي.
- إنترنت الأشياء والمراقبة الذكية.
- الطاقة والمرافق.
- أنظمة التحكم بالدخول.
- إدارة الزوار.
فإننا نبدأ بالطريقة نفسها دائمًا.
نفهم أولًا كيف يتم تنفيذ العمل فعليًا قبل أن نلتزم بتغيير أي جزء منه.
ثم نضع حلاً صغيرًا وواقعيًا أمام المستخدمين في مرحلة مبكرة.
وبعد ذلك نراقب كيفية استخدامه في بيئة العمل الحقيقية.
وما نتعلمه من هذا الاستخدام هو ما يحدد الخطوة التالية.
وعندما تكون البرمجيات جزءًا من الحل، فإنها تبقى جزءًا منه فقط.
ليست الحل بأكمله.
وليست نقطة البداية.
الفرق بين البرمجيات والحلول
هذا النهج له تكلفة نتحملها عن قصد.
فعندما تقضي وقتًا كافيًا داخل العمليات التشغيلية لفهم أماكن التعثر الحقيقية، تصبح عملية البيع السهلة مستحيلة.
لم يعد بإمكانك تسليم نظام للعميل ثم تأمل أن يناسبه.
بل تصبح مسؤولًا عن تقديم ما تحتاجه العملية فعلًا.
وعندما تكون الإجابة الصادقة أن المؤسسة تحتاج إلى أقل مما توقعت، أو لا تحتاج إلى أي نظام جديد أصلًا، فإنك تقول ذلك بوضوح.
وفي المقابل، فإن هذا هو النهج الوحيد القادر على تقديم الشيء الذي تشتريه المؤسسات في الحقيقة.
فهي لا تشتري منصة.
ولا تشتري لوحة معلومات.
ولا تشتري قائمة طويلة من المزايا والخصائص.
إنها تشتري نتيجة.
تشتري طريقة عمل أفضل.
وتشتري قدرة أكبر على اتخاذ القرار.
وتشتري تحسنًا ملموسًا في الأداء التشغيلي.
وهذا هو الحد الفاصل بين البرمجيات والحلول.
فالبرمجيات تنفذ ما طُلب منها.
أما الحلول، فتعالج ما يحتاج إلى المعالجة فعلًا.
ولهذا السبب كانت الفكرة الأساسية في هذا المقال بسيطة:
الوصف ليس تشخيصًا.
فما يبدو مشكلة تقنية قد يكون في حقيقته مشكلة عملية.
وما يبدو مشروعًا ضخمًا قد يحتاج فقط إلى خطوة صغيرة.
وما يبدو حاجة إلى نظام جديد قد لا يتطلب أي برمجيات إضافية على الإطلاق.
إذا كنت تقيّم حلاً حاليًا، ولست متأكدًا مما إذا كانت المتطلبات المطروحة تعكس المشكلة الحقيقية أم مجرد أعراضها، فهذه هي المحادثة التي تستحق أن تُجرى قبل أن يلتزم أي طرف بشراء نظام جديد.
