فريق مشروع Salesforce: الأدوار، المسؤوليات، ونموذج العمل مع المورد

الأدوار التي تحدد وتيرة المشروع

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

لذلك، فإن التقسيم الفعال للأدوار لا يعتمد على من يفعل ماذا، بل على من يقرر ماذا وفي أي وقت استجابة. يمكن مراجعة الخطوات التي يتطلبها كل دور في دليل تنفيذ Salesforce.

الأدوار التسعة وصلاحيات كل منها

Executive Sponsor (الراعي التنفيذي) — يتخذ القرارات بين الإدارات، ويوافق على التنازلات في نطاق العمل، ويدافع عن الأولوية في مواجهة الضغوط المتزامنة. إذا لم تكن لديه صلاحية ميزانية، فهو ليس راعيًا بل ممثلًا.

Process Owner (مالك العملية) — يحدد كيفية تنفيذ العمل فعليًا بعد التغيير، ويؤكد أن العملية المُنشأة تتوافق مع الواقع. يجب أن يكون هناك مالك واحد لكل عملية أساسية، وليس لجنة.

Product Owner / CRM Manager (مالك المنتج / مدير CRM) — يدير أولويات قائمة المهام المتأخرة (backlog)، ويتخذ القرارات بين الطلبات المتنافسة، ويحافظ على العلاقة بين المتطلبات والقيمة.

Project Manager (مدير المشروع) — مسؤول عن الجدول الزمني، والتبعيات، والمخاطر، وتنسيق الموردين، وإعداد التقارير.

Solution Architect (مهندس الحلول) — يتخذ القرارات بشأن نموذج البيانات، والصلاحيات، وحدود النظام، وطريقة التنفيذ؛ ومسؤول عن توثيق البدائل التي تم النظر فيها.

Salesforce Admin (مسؤول Salesforce) — مسؤول عن التهيئة (configuration)، والبيئات، وإدارة المستخدمين، والصيانة الروتينية بعد الإطلاق.

Developer (المطور) — مسؤول عن المنطق المخصص (custom logic)، والتكاملات (integrations)، والاختبارات الآلية (automated tests).

Data Owner (مالك البيانات) — يحدد مصدر الحقيقة، وما يعتبر سجلًا صحيحًا، ومن يوافق على تحميل البيانات.

Adoption & Training Lead (مسؤول التبني والتدريب) — مسؤول عن التواصل، والتدريب حسب الدور، وإدارة المقاومة، وقياس الاستخدام.

في المشاريع الصغيرة، يمكن لشخص واحد تولي دورين، ولكن هناك زوجان من الأدوار لا ينصح بالجمع بينهما: المهندس المعماري ومدير المشروع (تضارب بين الدقة والسرعة)، ومالك العملية ومسؤول الاختبارات (يختبر عمله الخاص).

من يجب أن يكون داخليًا

جدول RACI لنقاط اتخاذ القرار الرئيسية

عمود وقت الاستجابة هو الجزء المثير للاهتمام في الجدول. جدول RACI بدون اتفاقية مستوى الخدمة (SLA) للقرار هو وصف لطيف لا يغير الوتيرة.

التوفر الواقعي — الخطأ المتكرر في التخطيط

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

مثال توضيحي: كلية أكاديمية

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

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

نموذج العمل مع المورد

ثلاث آليات كافية لمعظم المشاريع:

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

في المؤسسات الكبيرة، تتطلب طبقة إضافية من الحوكمة بين الوحدات التجارية، كما هو موضح في دليل تنفيذ Salesforce في المؤسسات الكبرى.

نقاط الالتقاء مع المراحل الأخرى

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

فحص سريع قبل بدء المشروع

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