«لنمنحها أسبوعين إضافيين للانتقال.» إن سبق أن قلت هذه الجملة أثناء إطلاق برنامج جديد، فأنت تعرف نهايتها: الأسبوعان يصيران شهرين، والأداة الجديدة لا تُقلع أبداً. أمضيت نحو عشر سنوات مديراً لتقنية المعلومات أبني برامج الشركة الداخلية، وتلك الجملة — المقولة بأصدق النوايا — كانت وراء معظم إطلاقاتي الفاشلة.
الجواب المختصر
كيف تجعل فريقك يعتمد برنامجاً جديداً؟ أشركهم مبكراً، واختر أداة سهلة البديهة، ودرّبهم على سير العمل الحقيقي، واحتفِ بالنجاحات الأولى. هذا هو جواب الكتب، وهو ليس خاطئاً. فالاعتماد مسألة إدارة تغيير بقدر ما هو مسألة أدوات.
لكن جواب الكتب لم يكن كافياً وحده يوماً. ما نجح فعلاً كان أبسط من ذلك، وأقل راحة بكثير:
أزلنا النظام القديم.
في كل مرة أطلقنا فيها برنامجاً جديداً أو غيّرنا إجراءً، كنا نرفع الطريقة القديمة عن الطاولة. نقفل جدول Excel، ونوقف النموذج القديم. يتذمّر الناس أسبوعين، ثم يعتمدون الجديد. وحين صارت كل الإجراءات تمرّ عبر الأداة الجديدة، تمكّنا أخيراً من أتمتة كمّ هائل من العمل اليدوي، لأن الطريق الوحيد لتنفيذ الإجراء صار يمرّ ببرنامج نتحكم نحن به.
سأمرّ أولاً على الخطة التقليدية، لأنك ما زلت تحتاجها. ثم أدخل في تقنية التحوّل، بما في ذلك كيف تنفّذها دون أن يكرهك فريقك.
لماذا تقاوم الفرق البرامج الجديدة
السبب لا يكون البرنامج تقريباً أبداً.
العلامة. خلال عشر سنوات من إطلاق برامج داخلية، لم ألتقِ تقريباً بمستخدم يعترض على أداة جديدة لأسباب تقنية. ما واجهته مراراً وتكراراً كان خوفاً صريحاً من التغيير.
السبب الجذري. قد يكون جدول Excel القديم بطيئاً ومربوطاً بالنسخ واللصق، لكنه جدولهم هم. يعرفون أين يوجد كل شيء، وهم سريعون عليه. أما الأداة الجديدة، مهما كانت أفضل بوضوح، فتجعلهم يشعرون بالبطء وقلة الكفاءة لأسبوعين، ولا أحد يتطوّع لهذا الشعور. تقدير McKinsey الشهير يقول إن نحو 70% من برامج التغيير لا تبلغ أهدافها، والمتّهم المعتاد هو مقاومة الناس الذين سيعيشون مع هذا التغيير. وكل استطلاع عن بيئة العمل قرأته مؤخراً يقول صيغة من الكلام نفسه: الموظفون يشعرون أصلاً بأنهم مدفونون تحت الأدوات، ويفترضون أن كل أداة جديدة تعني عملاً إضافياً عليهم.
الحل ليس في البرنامج، بل في التعامل مع الإطلاق على حقيقته: مشروع إدارة تغيير صادف أن التقنية جزء منه. وكل ما يلي ينبع من ذلك.
الخطة التقليدية (ابدأ بها)
النصيحة التقليدية صارت تقليدية لأنها تنجح. تجاوزها، ولن تنقذك أي حيلة في التحوّل.
1. أشرك الفريق مبكراً
من سيعيشون داخل الأداة كل يوم هم من يجب أن يشاركوا في تشكيلها. خذ اثنين أو ثلاثة من أكثر المستخدمين المرتقبين استخداماً إلى داخل عملية البناء، واعرض عليهم النماذج الأولية، ودعهم يكسرون الأشياء. المستخدمون الذين ساهموا في تشكيل أداة يدافعون عنها بعد ذلك، وهم أنفسهم من ينتهي بهم الأمر يعلّمون من حولهم.
وهنا أيضاً يتفوّق بناء برامجك الداخلية بنفسك على شراء حل جاهز. حين يطلب أحدهم تعديلاً ويراه مطبّقاً في الأسبوع نفسه، يبدأ يشعر بأن الأداة أداته. أما أن يقول له مورّد «هذا مدرج في خطة التطوير» فيفعل العكس تماماً.
2. اختر أداة سهلة البديهة
كل نقرة إضافية تكلّفك جزءاً من الاعتماد. إذا احتاجت الأداة دليل استخدام لأبسط مهمة يومية، فالإطلاق في ورطة منذ البداية. كان معياري بسيطاً دائماً: أن ينجز مستخدم جديد سير العمل الأساسي من أول محاولة، دون مساعدة. فإن لم يستطع، أصلح الأداة قبل أن تصلح التدريب.
3. درّب على سير العمل الحقيقي، لا على المميزات
لا أحد يهتم بجولة في صفحة الإعدادات. درّب كل فريق على عمله الفعلي: «هكذا تسجّل شكوى عميل»، «هكذا تعتمد أمر شراء». استخدم بيانات حقيقية وحالات استثنائية حقيقية. جلسة من 30 دقيقة مبنية على يوم ثلاثاء حقيقي في حياة أحدهم تتفوّق على ساعتين تستعرضان كل ميزة في النظام.
4. احتفِ بالنجاحات الأولى
ابحث عن أول لحظة تفوّقت فيها الأداة الجديدة بوضوح على الطريقة القديمة — التقرير الذي كان يستغرق أربع ساعات وصار يستغرق عشر دقائق، من هذا النوع. أخبر الجميع، وسمِّ من شاركوا فيه بالاسم. النجاحات المبكرة تعطي المترددين دليلاً على أن الانتقال آمن، وتعطي الإدارة سبباً لمواصلة دعم المشروع.
التقنية التي نجحت فعلاً: إزالة النظام القديم
علّمتني عشر سنوات من الإطلاقات أمراً غير مريح: يمكنك أن تتقن الخطوات الأربع أعلاه وتشاهد الإطلاق يموت رغم ذلك. لسبب واحد.
العلامة. في كل مرة أطلقنا فيها أداة جديدة إلى جانب القديمة «خلال فترة انتقالية»، حدث الشيء نفسه: يرتفع الاستخدام في الأسبوع الأول، ثم يتسرّب عائداً إلى جدول Excel القديم.
السبب الجذري. ما دامت الطريقة القديمة موجودة، سيظل الناس يستخدمون الطريقة القديمة. والفترة الانتقالية لا تنتهي من تلقاء نفسها. الاعتماد الاختياري ليس في حقيقته سوى رفض بطيء.
الحل كان التوقف عن تشغيل نظامين بالتوازي. في يوم التحوّل، صار جدول Excel القديم للقراءة فقط، وأُغلق النموذج القديم. وصار البرنامج الجديد الطريق الوحيد لإنجاز العمل.
وكان الشيء نفسه يحدث في كل مرة فعلناها: ينتهي الجدل حول هل ننتقل أم لا ببساطة، وتتحوّل تلك الطاقة مباشرة إلى تعلّم الأداة الجديدة. الأسبوعان المحرجان كانا ينتهيان فعلاً، لأن الفريق كله يمرّ بهما معاً بدل تأجيلهما إلى ما لا نهاية. وتظهر المشكلات الحقيقية خلال أيام، لأن الجميع يصطدم بها في الوقت نفسه، فنصلحها والانتباه ما زال مرتفعاً. وأخيراً، تستقرّ كل البيانات في مكان واحد.
إنه مبدأ «إحراق السفن» مطبّقاً على برامج المكاتب. يُقال إن كورتيس أغرق سفنه حتى لا يبقى التراجع خياراً. لست بحاجة إلى شيء بهذه الدراماتيكية — ضبط جدول بيانات على وضع القراءة فقط يؤدي المهمة تماماً.
عائد الأتمتة
هذا هو الجزء الذي تتخطاه معظم المقالات عن الاعتماد، وكان بالنسبة لنا أكبر مكسب على الإطلاق.
حين صار الطريق الوحيد لتنفيذ إجراء يمرّ بالبرنامج الجديد، صارت كل خطوة في ذلك الإجراء مرئية لنظام — وهذا يعني أننا صرنا قادرين أخيراً على أتمتتها. بدأت الموافقات توجّه نفسها بنفسها. وتوقّفت التقارير الأسبوعية عن كونها عصر جمعة أحدهم. لم يكن أي من ذلك ممكناً قبلاً، لأن نصف كل إجراء كان مبعثراً في صناديق بريد وجداول شخصية لا يراها أي نظام.
لم يكن الاعتماد هدفنا النهائي يوماً. كان الشرط المسبق. المكسب الحقيقي يظهر بعده، حين يستقرّ الإجراء بكامله داخل نظام تتحكم أنت به فعلاً.
كيف تنفّذ تحوّلاً إلزامياً دون أن تستنزف فريقك
لنكن واضحين: إزالة النظام القديم ليست عذراً لتخطي عمل إدارة التغيير. بل إنها ترفع المخاطر، فيجب أن يكون التحضير أفضل لا أسوأ. وهذه الخطة التي استقررنا عليها بعد أن أخطأنا فيها بضع مرات.
- لا تسحب شيئاً قبل أن تكون الأداة الجديدة جاهزة فعلاً. التحوّل الإلزامي إلى شيء نصف مكتمل يحرق ثقة لا تستعيدها بسهولة. يجب أن يكون سير العمل الأساسي متيناً ومختبراً مع مستخدمين حقيقيين قبل إقفال أي شيء.
- أعلن التاريخ قبل أسابيع، وكرّره. «في الخامس عشر، يصبح السجل القديم للقراءة فقط.» لا مفاجآت. المفاجأة هي ما يخيف الناس؛ أما التاريخ فشيء يمكنهم الاستعداد له.
- انقل البيانات بنفسك. لا تطلب من المستخدمين نقل سجلاتهم أبداً. إن وجدوا تاريخهم داخل النظام الجديد من اليوم الأول، تكون قد أزلت أكبر اعتراض منطقي.
- اقفل النظام القديم، ولا تحذفه. يرتاح الناس حين يعلمون أن شيئاً لم يضِع، وتحتفظ أنت بسجل تدقيق في الوقت نفسه.
- ضاعف الدعم في الأسبوع الأول. ساعات مكتبية، وقناة محادثة مخصصة، وشخص يمشي بين المكاتب فعلياً. معظم المقاومة تذوب حين تصل المساعدة في أقل من خمس دقائق.
- تمسّك بالخط. سيطلب أحدهم «استثناءً واحداً فقط». ذلك الاستثناء الأول يصير النظام القديم الجديد. الجواب يجب أن يكون «لا» لطيفة وحازمة، مع حلّ فعلي لأي ثغرة حقيقية وراء الطلب.
- أصلح ما يبلّغ عنه الناس، بسرعة وعلى مرأى منهم. الأسبوع الأول من التحوّل يجلب سيلاً من الملاحظات الصادقة. وتطبيق الإصلاحات خلال أيام هو ما يكسب المتشككين.
أين يأتي دور AgentUI
التحوّل الإلزامي لا ينجح إلا إذا كانت الأداة الجديدة أفضل فعلاً، وإلا إذا كنت تستطيع تحسينها بسرعة وصول الملاحظات. هذا هو الجزء الصعب — وهو بالضبط ما يأتي AgentUI من أجله.
يتيح AgentUI لفرق الأعمال بناء برامج داخلية مخصصة بالذكاء الاصطناعي، بنسخة أولى تعمل خلال 30 دقيقة تقريباً، ثم مواصلة تحسينها مع تفاعل المستخدمين. هذه السرعة تغيّر معادلة الاعتماد كلها: حين يبلّغ أحدهم عن ثغرة يوم الاثنين ويراها مصلّحة يوم الأربعاء، تكسب الأداة الثقة أسرع من أي جلسة تدريب. كما يأتي AgentUI بتأهيل مخصص من اليوم الأول — فريق بشري حقيقي يساعدك على تخطيط الإطلاق ونقل بياناتك، حتى لا تحمل عبء التغيير وحدك.
كما أن تجميع إجراءاتك على منصة واحدة هو ما يفتح لك عائد الأتمتة. فحين يمرّ العمل عبر نظام واحد محكوم بدل جداول متناثرة، تصبح الأجزاء المتكررة قابلة للأتمتة أخيراً.
الأسئلة الشائعة
أليس إجبار المستخدمين على الانتقال مضرّاً بالمعنويات؟
في تجربتي، الغموض المفتوح أسوأ على المعنويات من تحوّل نظيف بتاريخ واضح. ما يضرّ المعنويات فعلاً هو أن تُجبر على أداة لا تعمل، بلا دعم وبلا صوت. أما إذا كانت الأداة جاهزة، والدعم حاضراً، والملاحظات تقود إلى إصلاحات مرئية، فمعظم الفرق تشعر بالارتياح — فقد اتُّخذ القرار، وتحرك الجميع معاً.
ماذا لو لم يستطع فريقي فعلاً أداء عمله داخل الأداة الجديدة؟
إذن تحوّلت مبكراً أكثر من اللازم. أعد الوصول إلى النظام القديم، وأصلح الثغرات مع مستخدمي المرحلة التجريبية، وحدد تاريخاً جديداً. التقنية هي «أزل النظام القديم حين يصبح الجديد جاهزاً»، لا «أزل النظام القديم وتمنَّ الأفضل».
كم ينبغي أن يعمل النظامان القديم والجديد بالتوازي؟
أياماً، إن استطعت. استخدم نافذة توازٍ قصيرة للتحقق من البيانات فقط، وأعلن لها تاريخ انتهاء، والتزم به. فترة التوازي التي يرتاح إليها الناس تميل إلى أن تصير دائمة.
كيف أقيس ما إذا كان الاعتماد قد نجح فعلاً؟
راقب ثلاثة أشياء: الاستخدام الفعلي (هل كل المستخدمين المقصودين داخل الأداة أسبوعياً؟)، واكتمال الإجراءات (هل يمرّ العمل عبرها من أوله إلى آخره؟)، والأنظمة الموازية (هل بدأت جداول جديدة تظهر بهدوء من جديد؟). هذا الثالث هو جرس الإنذار المبكر الذي تنسى معظم الفرق مراقبته.
ما السرعة التي أستطيع بها بناء برنامج داخلي يستحق الانتقال إليه؟
مع AgentUI، تستغرق النسخة الأولى العاملة نحو 30 دقيقة عادةً، ويستغرق برنامج داخلي جاهز للإنتاج نحو أسبوع. ويشمل ذلك دورات التحسين مع مستخدمي المرحلة التجريبية، وهي ما يجعل التحوّل الواثق ممكناً.
جاهز لبناء برنامج داخلي يستخدمه فريقك فعلاً، ولإحالة جدول Excel إلى التقاعد نهائياً؟