أنظمة · تبنّي2026-06-26·8 دقائق قراءة

دفعت ثمن النظام — وفريقك ما زال يعمل بالطريقة القديمة: فجوة التبنّي

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

بقلم فلوكا
[ القصة باختصار ]

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

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

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

[ المخططات ]
الشكل 1 · فجوة التبنّي — المُشترى ليس المُستعمَل
"WE HAVE A SYSTEM" IS THE TOP BAR · "WE RUN ON IT" IS THE BOTTOM ONE Bought & licensed 100% Logged in at least once Used every week Run on it return starts here Every bar above the bottom one is money spent for a fraction of the value — and reports built on partial data.
كل من اشتريتَ له ترخيصاً يقع في الشريط العلويّ. أقلّ منهم يسجّل الدخول ولو مرّة؛ وأقلّ يعود كل أسبوع؛ ولا يدير العمل على النظام بوصفه المصدر الوحيد للحقيقة إلّا شريحةٌ ضيّقةٌ في القاع. والعائد على الإنفاق كلّه لا يبدأ إلّا عند ذلك الشريط الأخير — وكل شريطٍ فوقه مالٌ دُفع مقابل جزءٍ من القيمة، وتقاريرُ بُنيت على بياناتٍ ناقصة.
الشكل 2 · إطلاقان للبرنامج نفسه
BOLT IT ON DESIGN THE ADOPTION 1 · Buy the licences 2 · Send a link, announce it once 3 · Leave the old spreadsheet running 4 · Two places hold the truth Shadow system wins adoption stalls 1 · Map the workflow people use 2 · Migrate the data — old place emptied 3 · The new system is the only path 4 · Capture at source · measure usage One source of truth adoption sticks Same software, same team. The rollout is the difference between a login and a habit.
الإطلاق المُلصَق يشتري التراخيص، ويرسل رابطاً، ويترك الطريقة القديمة تعمل — فيفوز النظام الظلّ ويتعثّر التبنّي. أمّا الإطلاق المُصمَّم فيرسم سير العمل الحقيقيّ، وينقل البيانات حتى يفرغ المكان القديم، ويجعل النظام الجديد الطريق الوحيد لإنجاز العمل، ويقيس الاستخدام — فيصير تسجيل الدخول عادة. البرنامج نفسه والفريق نفسه؛ الإطلاق هو الفارق كلّه.
[ الشرح ]

ابدأ بمعدّل الفشل، فهو أعلى بكثيرٍ ممّا يوحي به الكتيّب، ولم يتحرّك تقريباً منذ عقد. تقدّر فورستر حصّة مشاريع الـCRM التي تقصُر عن التوقّعات بنحو 49 بالمئة [1]؛ ووجدت دراسة ميركل المُستشهَد بها كثيراً أنّ 63 بالمئة من مبادرات الـCRM تفشل، والرقم لم يتحسّن في السنوات اللاحقة [2]. وحين تنبش عن السبب تكفّ عن العثور على برمجيّاتٍ معطوبة. السبب الأكبر، في دراسةٍ بعد دراسة، هو ضعف تبنّي المستخدمين — نحو نصف عمليّات التركيب الفاشلة يعود إليه [3]. الأداة كانت سليمة. والناس لم يأتوا قطّ.

وليست هذه خصوصيّةً في الـCRM؛ إنها الشكل العامّ لكل إطلاق نظام. ترى ماكنزي منذ زمنٍ أنّ نحو 70 بالمئة من جهود التغيير والتحوّل الكبرى تقصُر عن أهدافها، والسبب نادراً ما يكون أنّ التقنيّة لم تعمل — بل أنّ الناس لا يغيّرون سلوكهم [4]. النظام الجديد تغييرٌ سلوكيٌّ يرتدي زيّ برنامج. أنت لا تطلب من فريقك فعلاً أن يثبّت تطبيقاً؛ بل أن يتخلّى عن عادةٍ يتقنها بسرعةٍ وراحة، وأن يكون أبطأ وأخرق فترةً مقابل منفعةٍ تعود غالباً على العمل لا عليه في تلك اللحظة. وبهذه الصياغة لا تكون المقاومة كسلاً. إنها عقلانيّة.

و"مُتبنّى" ليس ضوءاً يُشعَل أو يُطفأ. حتى بين من يسجّلون الدخول، يستعمل نحو 43 بالمئة أقلّ من نصف ميزات النظام الذي يدفعون ثمنه [5]، وفي ستٍّ من كل عشر شركاتٍ أكثر من عُشر من يُفترَض أن يستعملوه لا يفعلون عملياً [6]. والتبنّي السطحيّ ضريبةٌ بذاته: تدفع السعر الكامل مقابل جزءٍ من القدرة، و — الأسوأ — يصير كل تقريرٍ وتوقّعٍ ينتجه النظام مبنياً على بياناتٍ ناقصة. وهنا بالضبط تنكسر سلسلة الأنظمة. فالتقارير التي اشتريت الأداة لأجلها صادقةٌ بقدر ما دخل من الواقع إليها فقط.

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

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

[ وجهات النظر ]
المعسكر أ — إنها مشكلة أشخاص؛ المستخدمون يحتاجون أن يلتزموا فقط

البرنامج سليمٌ والإطلاق كان واضحاً — الفجوة انضباط. افرضه، وزِد التدريب، واربطه بتقييم الأداء، وسيتبع التبنّي. الناس يقاومون أيّ تغيير؛ ومهمّة الإدارة أن تثبت حتى تصير الطريقة الجديدة روتيناً. أنفِق على الإلزام والمساءلة، لا على إعادة هندسة أداةٍ تؤدّي عملها أصلاً.

المعسكر ب — إنها مشكلة أداة؛ اشترِ واحدةً ألطف

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

المعسكر ج — إنها مشكلة تصميمٍ وسير عملٍ، تُهندَس قبل الإطلاق

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

أين نقف

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

[ أسئلة مفتوحة ]
  1. 01بالنسبة للأنظمة التي تدفع ثمنها أصلاً، ما حصّة من يُفترَض أن يستعملوها ويُجرون عملهم اليوميّ عبرها فعلاً — وهل قِستَ ذلك يوماً، أم افترضته فقط؟
  2. 02حين اشتريت نظامك الأخير، كم من الميزانيّة ذهب إلى الإطلاق — النقل وتصميم سير العمل والتدريب وتتبّع الاستخدام — مقابل التراخيص والبناء؟ وأيّ نصفٍ قرّر هل نجح؟
  3. 03هل ما زال ثمّة طريقٌ موازٍ — جدولٌ أو محادثةٌ أو نموذجٌ ورقيّ — يتيح لفريقك إنجاز العمل دون لمس النظام الجديد؟ فإن وُجد، أيّهما يستعملون فعلاً؟
  4. 04كم من التقارير التي تعتمد عليها مبنيٌّ على بياناتٍ ناقصةٍ لأنّ التبنّي سطحيّ — وهل كنت ستتّخذ القرارات نفسها لو عرفت أيّ جزءٍ من الواقع غائبٌ عنها؟
  5. 05حين يتعثّر التبنّي، كيف تميّز هل المشكلة الحقيقيّة انضباطٌ أم الواجهة أم إطلاقٌ لم يُزِل العادة القديمة قطّ — وهل يلائم علاجك السبب الفعليّ أم أسهل سببٍ تلومه؟
[ المراجع ]
  1. [1]Forrester — "نجاح الـCRM يتطلّب التركيز على الناس لا على التقنيّة وحدها": نحو 49٪ من مشاريع الـCRM تقصُر عن التوقّعات، والتبنّي مشكلة أشخاصٍ قبل أن يكون مشكلة تقنيّة.
  2. [2]DMNews — "63٪ من مبادرات الـCRM تفشل" (دراسة مجموعة ميركل): معدّلات فشل الـCRM لم تتحسّن في عقد، والتبنّي السبب الأوّل.
  3. [3]Radin Dynamics — "أزمة تركيب الـCRM: 50٪ تفشل بسبب ضعف تبنّي المستخدمين": نحو نصف عمليّات تركيب الـCRM الفاشلة يعود مباشرةً إلى عدم تبنّي المستخدمين للنظام.
  4. [4]McKinsey & Company — "لماذا تفشل أغلب التحوّلات؟ حوارٌ مع هاري روبنسون": نحو 70٪ من جهود التغيير الكبرى تقصُر عن أهدافها، وغالباً لأنّ الناس لا يغيّرون سلوكهم، لا لأنّ التقنيّة فشلت.
  5. [5]DesignRush — "إحصاءات الـCRM: اتّجاهات الاستخدام والأثر والعائد": نحو 43٪ من مستخدمي الـCRM يستعملون أقلّ من نصف الميزات المتاحة، غالباً لأنّهم يجدونها معقّدة.
  6. [6]FullEnrich — "معدّلات تبنّي الـCRM: رؤى وتحدّيات واستراتيجيّة": 40٪ فقط من الأعمال تدّعي نسبة تبنٍّ 90٪، وفي ستٍّ من كل عشر شركاتٍ أكثر من 10٪ ممّن يُفترَض أن يستعملوا الـCRM لا يفعلون.
[ تدفع ثمن نظامٍ لا يستعمله أحد؟ ]

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

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

احجز استشارةً مجّانيّةً 15 دقيقة