عندما يصبح الإفراط في المعرفة بتقنية المعلومات أمرًا خطيرًا

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

أندرو مكافي

في السنوات الأخيرة، استثمرت الشركات الكبرى قدرًا كبيرًا من المال -والثقة- في أنظمة تقنية المعلومات (IT) بعدّها وسيلة لقيادة التغيير التنظيمي أو التنافسي الحيوي. وأكثر من نصف هذا الاستثمار كان في ما أسميه “تقنية المعلومات المُمكِّنة للعمليات” (process-enabling information technology)، أي التقنية التي تيسّر تنفيذ العمليات التجارية بأكملها بدلًا من المهمّات الفردية فقط. وتشمل هذه التقنية أنظمة تخطيط موارد المؤسسة (ERP)، وإدارة سلسلة التوريد (SCM)، وإدارة علاقات العملاء (CRM)، وعمليات التجارة الإلكترونية (e-commerce operations). إن التنسيق، والإشراف الإداري، وحشد الموارد اللازمة لتنفيذ أي من هذه الأنظمة يجعل من عملية التغيير هذه جهدًا لا مثيل له.

ومع ذلك، كثيرًا ما تتحطم الآمال ويُعتبر الجهد فاشلًا؛ فقد أظهرت دراسات متعددة أن الأنظمة الجديدة في ما بين 30% إلى 75% من الحالات لا ترقى إلى مستوى التوقعات، ولا تحقق أثرًا ماليًّا ملموسًا، ولا تحسن عمليات العمل، ولا تجلب التغيير التنظيمي المنشود. وفي بعض الحالات، تكون النتيجة كارثية. فعلى سبيل المثال، أنفقت شركة Nike مئات الملايين من الدولارات على نظام توقّع المبيعات بشكل غير دقيق؛ وعانت شركة Hershey Foods خلال موسم الهالوين من عدم قدرتها على توفير الحلوى في مخزون كبار تجار التجزئة، كما تقدمت شركة FoxMeyer Drug بطلب الحماية من الإفلاس (Chapter 11) جزئيًّا بسبب مشكلات في تنفيذ نظام تخطيط موارد المؤسسة (ERP).

وليس السبب في هذه الإخفاقات وغيرها هو الأعطال التقنية (technical snafus). كما أن المشكلة لا تكمن في ندرة النصائح الجيدة للمديرين. فقد أجرى الأكاديميون، والمستشارون، وبائعو تقنية المعلومات، والمديرون أنفسهم بحوثًا أفرزت الكثير من الإرشادات الصحيحة حول جانب أو آخر من جوانب التنفيذ. كما أن هذه الإرشادات لا تُهمل. فمعظم التنفيذيين الذين عملت معهم يدركون تمامًا أن عمليات التنفيذ مشاريع ضخمة ومحفوفة بالمخاطر، وقد سعوا بجدية للحصول على أحدث النصائح من خلال القراءة، وحضور المؤتمرات والدورات، وتوظيف الخبراء. وفي بحثي، وجدت أن المشكلة -أي القضية الأساسية- هي أن المديرين غالبًا ما يتبعون ما يشبه قائمة مراجعة عالمية، يُفترض أنها مناسبة لجميع الحالات، عند تنفيذ تقنية معلومات مُمكِّنة للعمليات جديدة. وتُجمع هذه القائمة من طيف واسع من بحوث تنفيذ تقنية المعلومات حول موضوعات مثل قبول المستخدم، وإعادة تصميم العمليات التجارية، وتكوين النظام، وإدارة التغيير. والافتراض هو أنه إذا تم الاعتناء بجميع عناصر القائمة، فإن النجاح سيتحقق.

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

خمسة مزالق في تنفيذ تقنية المعلومات

تظهر المزالق حتى عندما تُتبع القواعد الأساسية للتنفيذ الجيد (ولمناقشة هذه القواعد، انظر “قائمة المراجعة العالمية المختصرة”). لقد حددت خمسة مزالق قد تظهر رغم أفضل الجهود الإدارية، هي: الجمود (inertia)، والمقاومة (resistance)، وسوء التحديد (misspecification)، وسوء الاستخدام (misuse)، وعدم الاستخدام (nonuse). ورغم أن هذه المزالق تُعرض هنا بشكل منفصل، فإنها لا تظهر بهذه الصورة في الواقع العملي، ويحتاج المديرون إلى القدرة على مواجهة مزيج من المشكلات التي سيواجهونها على الأرجح. إن وجود المزالق لا يضمن فشل التنفيذ، لكنه يجعله أكثر احتمالًا. وعلى أقل تقدير، فإن تجاهل المزالق سيؤدي إلى تأخير المشروع أو تقليل فوائده.

فالجمود، على سبيل المثال، هو من أبرز المذنبين؛ والجمود هنا هو غياب التقدم مع مرور الوقت في تحقيق معالم التنفيذ واتخاذ القرارات، حتى بعد اتفاق جميع الأطراف على أن الجهد فكرة جيدة. ومن السهل تمييزه، إذ يظهر في صورة مواعيد نهائية فائتة، وجداول زمنية للمشروع يتم تمديدها باستمرار، وتواريخ “التشغيل الفعلي” (go live) التي تتراجع إلى المستقبل. والجمود مكلف؛ فالموظفون والمستشارون الخارجيون يستمرون في استهلاك المال حتى في ظل غياب التقدم الفعلي.

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

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

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

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

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

اشترت شركة Nike النظام من بائع البرمجيات i2 Technologies في أواخر التسعينيات، وبدأت تشغيله في عام 2000م، وسرعان ما اكتشفت Nike أن دقة التنبؤات التي يوفرها النظام كانت منخفضة، ما أدى إلى مشكلات في الإنتاج الزائد ونقص الإنتاج على حد سواء. بالإضافة إلى ذلك، وجدت Nike أن بعض أوامر الإنتاج كانت تُسجّل مرتين داخليًّا، بينما سقطت أوامر أخرى من الحساب ولم تُنتَج قط. في عام 2001م، ادعت Nike أن المشكلات المتعلقة بالبرمجيات قد خفضت مبيعات أحد أرباع السنة بمقدار وصل إلى 100 مليون دولار. غير أن شركة i2 اتهمت Nike بأنها أجرت تعديلات كبيرة على البرمجيات بدلًا من اعتماد العمليات التجارية المضمنة في التطبيق. ونتيجة لذلك، أكدت i2 أن برمجيات Nike لم تُضبط بشكل صحيح لتخطيط العرض والطلب. لم تتفق الشركتان على أسباب فشل المشروع، لكن من الواضح أن العمليات التجارية كانت معقدة، وأن قوالب البرمجيات قد عُدلت لتلائم ما عدّته Nike متطلباتها الفريدة، وقد جعلت هذه الخصائص من تطبيق النظام بيئة خصبة لحدوث أخطاء في التحديد والتوصيف.

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

لقد عانى سوء الاستخدام شركة Rich-Con Steel، أقدم الشركات العائلية في مدينة كانساس، بعد أن ركبت نظامًا مؤسسيًّا أساسيًّا في أواخر عام 1996م؛ فبعد فترة وجيزة، اكتشف المديرون أنهم غير قادرين على الحصول على صورة دقيقة عن المخزون، والحسابات الدائنة والمدينة، وحالة طلبات العملاء. وكشفت التحقيقات أن العديد من الموظفين، الذين لم يكن لأي منهم خبرة سابقة مع الحواسيب، كانوا يستخدمون النظام الجديد بشكل خاطئ. فعند تسريع معالجة الطلبات المتراكمة خلال الانتقال إلى النظام الجديد، على سبيل المثال، أهمل بعض الموظفين إغلاق الطلبات التي تم شحنها بالفعل. ونتيجة لذلك، أشار النظام إلى أن المخزون لتلك الطلبات ما زال متوفرًا، رغم أن الفولاذ قد غادر شركة Rich-Con؛ بالإضافة إلى ذلك، لم يكن بالإمكان إصدار فواتير للعملاء عن الطلبات التي لم تُغلق، ما أدى إلى تأخير المدفوعات المستحقة للشركة. وجزئيًّا نتيجة للآثار السلبية التي تلت تطبيق النظام، اضطر مالكو Rich-Con إلى بيع الشركة لمشترٍ خارجي في عام 1999م.

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

وقد واجهت شركة CoSine Communications، وهي بائع لمعدات الشبكات، مشكلة عدم الاستخدام بعد أن ركبت نظام إدارة علاقات العملاء (CRM) في عام 2001م. كان من المفترض أن تساعد التكنولوجيا الجديدة فريق المبيعات في تخطيط الزيارات البيعية، والتنبؤ، وإدارة الطلبات وحسابات العملاء. في البداية، لم يكن مطلوبًا من مندوبي المبيعات استخدام النظام الجديد، وبعد أربعة أشهر من تشغيل البرمجيات، كان 20% فقط من فريق المبيعات يستخدمه. لم يثِق مندوبو المبيعات في دقة المعلومات التي يقدمها النظام، وشعروا أنه يجعل العملاء يظنون أنهم لا يعرفون ما يفعلونه. وقد حلت CoSine المشكلة بإجراء تعديلات على البرمجيات وتثقيف مندوبي المبيعات حول الطرق التي يمكن أن يسهل بها النظام عملهم ويزيد من أرباحهم.

تعاني العديد من مشاريع التطبيق المتعثرة بعمق من “دوامة الموت” الناتجة عن تفاعل اثنتين أو أكثر من هذه المشكلات. فعلى سبيل المثال، يبدو أن النظام في شركة Rich-Con Steel كان على الأقل محددًا بشكل خاطئ جزئيًّا؛ إذ لم يكن يسمح بشحن الطلبات المكتملة جزئيًّا، رغم أن الشحن الجزئي كان ممارسة شائعة في الصناعة. وعندما بدأ الموظفون في استخدامه، أصيبوا بالإحباط سريعًا وبدؤوا يلجؤون إلى حلول يدوية أو بديلة داخل النظام. وقد جعل هذا الاستخدام الخاطئ من مشكلة التحديد الأولي للنظام أكثر ضررًا.

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

ما بعد قائمة المراجعة

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

مستوى قيادة المشروع

عادةً ما تُدار جهود تفعيل تكنولوجيا المعلومات الداعمة للعمليات (process-enabling IT efforts) بوساطة فريق تنفيذ مخصص يتبع لمكتب برنامج يشرف عليه مدير مشروع. وغالبًا ما تراقب هذه الجهود لجنة توجيهية مكوّنة من مديرين كبار وراعٍ تنفيذي رفيع المستوى. ولتجاوز عقبات الجمود أو المقاومة، من الضروري أن يكون لمنصب مدير المشروع والراعِي التنفيذي وزنٌ رفيع. فلا بد أن يقود المشروع أشخاص يمتلكون السلطة لاتخاذ قرارات صعبة. وفي غياب تلك السلطة، تميل المجموعات التنظيمية ذات المصلحة في المشروع إلى التصرف بتحفظ (الجمود) أو إلى التشبث بمواقفها (المقاومة). وكلما زاد عدد تلك المجموعات، ازدادت احتمالية أن تؤدي إحدى هاتين العقبتين أو كلتاهما إلى إلحاق الضرر بتنفيذ المشروع.

ومن الأساليب الفاعلة في مثل هذه الظروف التفكير في إدارة المشروع “فوق واجهات” المجموعات المعنية، أي أن صاحب القرار النهائي في المشروع يجب أن يكون شخصًا يتفوّق في رتبته على جميع أفراد المجموعات المتأثرة. هكذا تمكنت شركة Cisco من التغلب على الجمود؛ إذ أُسند مشروع نظام تخطيط موارد المؤسسات (ERP) في نهاية المطاف إلى رئيس قسم المعلومات (CIO) ونائب رئيس التصنيع، وكلاهما كان يرفع تقاريره مباشرة إلى مجلس الإدارة. وقد ساعدت الإدارة على ذلك المستوى الشركة في تنفيذ نظامها الجديد الشامل في أقل من تسعة أشهر، وهو إنجاز سريع بشكل لافت بالنظر إلى ضخامة المهمة.

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

أما بعض المشاريع والجهود الأخرى، فلا يمكن إدارتها بسهولة على مستويات عليا كافية لتحقيق النجاح. وتلك المعضلة تفسّر جزئيًّا بطء معدل تبني تقنيات الأعمال بين الشركات (B2B) وفتور الحماس تجاه الأسواق الإلكترونية (e-marketplaces). فبما أن تقنيات وأساليب B2B والأسواق الإلكترونية تشمل شركات عديدة، لا يمكن قيادتها فوق واجهات المجموعات المتأثرة، وبالتالي تفتقر إلى وسيلة مباشرة لمواجهة الجمود والمقاومة. وهناك العديد من الهيئات الصناعية التي تضع حاليًّا معايير للوثائق الإلكترونية (مثل أوامر الشراء الرقمية الموحدة وتحديثات حالة المخزون) ولعمليات الأعمال التي تستفيد منها، إلا أن هذه الاتحادات نادرًا ما تستطيع فرض التزام الشركات الأعضاء بمقترحاتها. ونتيجة لذلك، من المرجح أن تظل جهود تكنولوجيا المعلومات بين الشركات حذرة وبطيئة وتدريجية، فهي ببساطة لا يمكن إدارتها بقوة من الأعلى لتحقيق تقدم أسرع وأعمق.

أسلوب الإدارة

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

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

لقد استُخدم الأسلوب التوجيهي في تطبيق أنظمة مؤسساتية واسعة النطاق في شركات مثل IBM وTektronix وHarley-Davidson؛ ففي جميع هذه الحالات، لم تكن عمليات الأعمال معقدة للغاية، وكان المستخدمون على دراية متقدمة بتكنولوجيا المعلومات، وكانت الأنظمة إلزامية، أي أن الناس لم تكن لديهم حرية الاختيار في استخدامها. وفي مثل هذه الظروف، لا يُشترط التوافق الواسع أو التدرج في التنفيذ.

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

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

تأسست شركة أليبريس (Alibris) في عام 1994م على يد تاجر كتب مرموق استثمر خبرته في هذا المجال وعلاقاته لإقناع مجموعة أولى من التجار بالانضمام إليها. ومنذ ذلك الحين، كلما غيّرت الشركة تقنياتها أو عملياتها التجارية -على سبيل المثال، عندما انتقلت من فرض رسوم على قوائم الكتب إلى اقتطاع نسبة مئوية من كل كتاب يُباع- كانت تستشير عملاءها، موضحة لهم الدوافع والفوائد، وتقوم بإجراء التعديلات بناءً على آرائهم. كما أبدت أليبريس استعدادها لتلبية رغبات كبار عملائها في جانب التوزيع، مثل أمازون (Amazon). وقد أدركت الشركة منذ البداية أنها تسيطر فقط على جزء ضئيل من الموارد اللازمة لتحقيق النجاح، فعملت على بناء التوافق والمشاركة مع جميع عملائها.

نطاق المشروع

يُعد تحديد نطاق الجهد أحد أقوى الأدوات وأكثرها بساطة في يد مدير التنفيذ؛ إذ يمكن أن تكون حدود المشروع تقسيمية (هل ينبغي أن يشمل قسم المبيعات والتسويق؟)، أو جغرافية (هل ينبغي أن يشمل العمليات في أمريكا اللاتينية؟)، أو تقنية (هل ينبغي أن يتضمّن مستودع بيانات؟ Data Warehouse). وغالبًا ما توجد أسباب قوية لاعتماد نطاق شامل؛ فالمشاريع الكبرى تزيل جميع الاضطرابات التنظيمية دفعة واحدة، وغالبًا ما تتضاعف الفوائد التجارية مع تغيير المزيد من العمليات.

ومع ذلك، عندما تكون الجمود والمقاومة وسوء التحديد من المخاطر المحتملة، ينبغي لقادة التنفيذ التفكير في تقليص النطاق؛ فالمشاريع الصغيرة تتحرك بسرعة أكبر، وتؤدي إلى نزاعات أقل، وتقل فيها فرص تهيئة التقنية بشكل خاطئ. (لاحظ أن تقليص النطاق لا يعني منع الميل الطبيعي للمشاريع إلى “تسلل النطاق” Scope Creep؛ فالتقليص خيار، أما منع تسلل النطاق فهو ضرورة).

إن أمكن، فمن الأفضل تقليص نطاق المشروع قبل انطلاقه، ولكن حتى تقليصه أثناء التنفيذ قد يكون فاعلًا؛ فقد وجدت شركة بيكتون، ديكنسون (Becton, Dickinson) المصنعة للأجهزة الطبية أن تنفيذ نظامها المؤسسي تعثر في عام 2000م، بسبب الجمود وبعض المقاومة، فقام قادة الشركة بمراجعة الجهد بأكمله وقرروا استبعاد بعض المواقع والوظائف والوحدات. بعد ذلك، تمكن فريق التنفيذ من التركيز بشكل أفضل على ما تبقى، ووجد أن المشروع أصبح أسهل في تسويقه داخل الشركة. وبعد تقليص النطاق، أصبح المشروع يسير وفق معالمه الرئيسية بشكل جيد.

توقيت المشروع

ضمن بعض القيود، يتمتع المديرون بقدر كبير من الحرية في توسيع أو تقليص الجداول الزمنية، وتحريك الأنشطة إلى الأمام أو إلى الخلف، وتقسيم تنفيذ كبير إلى عدة مراحل أصغر. نادرًا ما تُنفّذ المشاريع الكبرى حاليًّا بأسلوب “الانطلاق الكبير” Big-Bang، حيث يتم إدخال جميع التقنيات والعمليات التجارية الجديدة دفعة واحدة.

معظم عمليات التنفيذ تسير عبر سلسلة من المراحل، كل منها يُحدد بمزيج من الوظائف أو الأقسام أو المناطق الجغرافية (أو مزيج من الثلاثة). ويمكن للتنفيذ المرحلي أن يبني زخمًا إيجابيًّا للمشروع (وبذلك يتغلب على عدم الاستخدام)، لكن ميزته الأهم تكمن في قدرته على مواجهة سوء التحديد؛ فإطلاق النظام عبر مراحل تدريجية يوفر فرصة للتعلم مع مرور الوقت حول ما ينجح وما لا ينجح، ولتصحيح الأخطاء السابقة من خلال مراجعة قرارات تكنولوجيا المعلومات وعمليات الأعمال. ويبدو أن شركة نايكي (Nike) حاولت إطلاق نظام إدارة سلسلة التوريد (SCM) الذي اشترته من شركة i2 دفعة واحدة وبسرعة مفرطة.

أما البديل الرئيس للتنفيذ المرحلي فهو أسلوب الانطلاق الكبير، حيث تُستخدم التقنية الجديدة بالكامل دفعة واحدة. ويمكن أن يكون هذا النهج فاعلًا عندما لا يكون سوء التحديد أو سوء الاستخدام أو عدم الاستخدام من التهديدات الجدية. فعلى سبيل المثال، في عام 1996م قامت شركة كوانتوم (Quantum) المصنعة لأقراص التخزين بتشغيل برنامج تخطيط موارد المؤسسة (ERP) الجديد دفعة واحدة في جميع أنحاء الشركة التي تبلغ قيمتها 4.4 مليار دولار.

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

الاستعداد التنظيمي

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

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

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

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

فن القيادة

على الرغم من أن العديد من الشركات قد اختبرت بالفعل الإحباط الناتج عن نظام مؤسسي داخلي أو فشل في التعاملات بين الشركات (B2B)، فإن التغيير في العمليات التجارية المدعوم بالتقنية لم ينتهِ بعد. وستواصل الشركات استبدال أنظمتها ودمجها، وكذلك أتمتة وتبسيط وتحسين عملياتها بوساطة أنظمة تقنية المعلومات (IT) الجديدة. وعلى وجه الخصوص، تحمل التقنيات الناشئة لما يُعرف بـ “خدمات الويب” (Web services) وعودًا كبيرة لربط الأنظمة والمجموعات والشركات التي كانت مجزأة في السابق.

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

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

المراجع

1. B.J. Gomolski, J. Grigg and K. Potter, “2001 IT Spending and Staffing Survey Results” (Stamford, Connecticut: Gartner Group, 2001).

2. Studies concentrating on process-enabling information technology have found 70% failure rates among IT-based change initiatives (T.H. Davenport, “The Fad That Forgot People,” Fast Company, November 1995, 70–75); 75% among sales force automation efforts (M. Blodgett, “Vendor Tries To Simplify Sales Force Automation,” Computerworld, Dec. 26, 1995, 62); and 30% to 60% among general efforts to improve work processes (J. McDermott, “Improving Productivity Through Technological Innovation,” Merck Bulletin 67 (1987): 3–5; T.K. Bikson and B. Gutek, “Implementation of Office Automation” (Santa Monica, California: Rand, 1984). A recent study of 100 projects by H. Sirkin and K. Dickel, “Getting Value From Enterprise Initiatives” (Boston: Boston Consulting Group, 2000), found that their sponsors considered them fully successful in only one-third of the cases and that tangible financial impact was achieved in only 37% of cases.

3. There is almost universal agreement that large-scale IT failures occur for managerial reasons, not because of technical problems. For a review of literature on this topic, see J. McDonagh, “Not for the Faint-Hearted: Social and Organizational Challenges in IT-enabled Change,” Organization Development Journal 19 (spring 2001): 11–20.

4. As C. Christensen and D. Sundahl maintain, “Unless researchers ground their theory upon robustly defined categories of phenomena, they cannot make statements that have contingent explanatory power — explanations of how the outcomes caused by actions or events will vary, depending upon the circumstances of the categories. … If researchers attempt to short-circuit the process by leaping from phenomena to theory, their work is of less value to future researchers and practitioners than it could be.” See “The Process of Building Theory,” Harvard Business School working paper no. 02-016, Boston, 2001.

5. Of course, simply avoiding the pitfalls described is not a guarantee of implementation success. The model presented assumes that, among other things, a company is capable of maintaining a robust IT infrastructure, employs good project-management techniques (including those listed here as ground rules) and has purchased a process-enabling technology that largely works as promised and is appropriate for its business goals.

6. R. Austin, R. Nolan, M. Cotteler, “Cisco Systems, Inc.: Implementing ERP,” Harvard Business School case no. 9-699-022 (Boston: Harvard Business School Publishing, 1999).

7. Temporary “performance dips” appear to be common following the adoption of process-enabling systems. For an example, see A.P. McAfee, “The Impact of Enterprise Technology Adoption on Operational Performance: An Empirical Investigation,” Production and Operations Management 11 (spring 2002): 33–53.

8. For news accounts of the problem between Nike and i2, see S. Konicki, “Nike Just Didn’t Do It Right, Says i2 Technologies,” Informationweek, March 5, 2001, 32; and T. Wilson, “Supply Chain Debacle —Nike Faces Yearlong Inventory Problem After i2 Implementation,” InternetWeek, March 5, 2001, 1–3.

9. A.P. McAfee, “Rich-Con Steel,” Harvard Business School case no. 9-699-133 (Boston: Harvard Business School Publishing, 1999).

10. M. Boslet, “CRM: The Promise, the Peril, the Eye-Popping Price,” Industry Standard, Aug. 6–13, 2001, 61–65.

11. See, for example, S.J. Kafka, B.D. Temkin, et al., “The eMarket-place Shakeout” (Cambridge, Massachusetts: Forrester Research, 2000); L. Gomes, “Fruitless Ventures: How Lower-Tech Gear Beat Web ‘Exchanges’ at Their Own Game,” Wall Street Journal, Friday, Mar. 16, 2001, sec. A, p. 1 and p. 6; and B. Tedeschi, “As the Shake-out Proceeds, Some Business-to-Business Marketplaces Show Their Staying Power,” New York Times, Monday, July 16, 2001, sec. C, p. 4. According to one estimate, less than 1% of the world’s suppliers are connected to an e-marketplace (S. Kennedy, “Business-to-Business Exchanges Fail To Deliver,” Reuters, Apr. 11, 2001. The article can be accessed at http://www.itweb.co.2a/sections/business/2001/0104111132.asp).

12. The high-tech manufacturing sector’s RosettaNet is one of the best known of these industry-level IT standards bodies.

13. A.P. McAfee and K. Herman, “Alibris (A),” Harvard Business School case no. 9-601-111 (Boston: Harvard Business School, 2002).

14. L. Radosevich, “Quantum’s Leap: One Computer Manufacturer’s Risky Decision To Overhaul Its Worldwide Business Systems in a Single Bound Paid Off,” CIO Magazine, Feb. 15, 1997, 40–44.

15. For a guide on handling small releases, see R.G. Fichman and S.A. Moses, “An Incremental Process for Software Implementation,” MIT Sloan Management Review 40 (winter 1999): 39–43.

16. For a managerial overview of Web services, see J. Hagel III and J.S. Brown, “Your Next IT Strategy,” Harvard Business Review 79 (October 2001): 105–113.

i. See A. McAfee, “When Too Much IT Knowledge is a Dangerous Thing,” MIT Sloan Management Review 44, no. 2 (winter 2003): 83–89; and A. McAfee, “Will Web Services Really Transform Collaboration?” MIT Sloan Management Review 46, no. 2 (winter 2005): 78–84.