هل تستبدلون برمجياتكم أم تربطونها؟

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

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

أين الخلل فعلًا؟

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

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

كيف تعرفون في أي حالة أنتم؟

عدّوا عمليات النقل اليدوي. هذا يستغرق صباحًا من وقتكم، ولا يحتاج إلينا.

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

القائمة ترتّب نفسها بنفسها. ثلاث أو أربع عمليات نقل ستستحوذ على معظم ما دوّنتموه، وسيكون كل من يعمل عند ذلك المكتب قد عرف مسبقًا أيها هي.

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

متى يكون الاستبدال هو الجواب الصحيح؟

ثلاثة اختبارات. يجب أن يخفق النظام في واحد منها، بوضوح، قبل أن تكون التوصية الصادقة هي استبداله.

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

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

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

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

لماذا يكون الاستبدال هو الجواب الذي تسمعونه عادةً؟

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

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

ما الذي ينبغي أن تصرّوا عليه إن اخترتم الربط؟

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

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

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

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

وماذا لو ربطتم وبقي الخلل؟

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

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

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