ERP عند العميل أم عند الشريك؟ الفرق الحقيقي بين الجهتين

الـ ERP ليس فقط أن تتعلم الثلاثة أدوار التي تكلمنا عنها من قبل — Functional أو Implementer أو Developer. هناك سؤال قبلها، وأغلب الناس لا تنتبه له وهي داخلة المجال: أنت في أي ناحية من الترابيزة؟

هل أنت في ناحية العميل، الشركة التي تشتري السيستم وتشغّله؟ أم في ناحية الشركة التي تنفّذ السيستم للعميل — الفندور أو الـ Partner؟ الاثنان يعملان في نفس المجال ويتكلمان نفس المصطلحات، والـ Mindset مختلف تماماً. هذه الحلقة مع المهندس عز الدين ممدوح، الذي قضى معظم عمره في ناحية العميل مع SAP، وعَمِل مشروعاً واحداً صغيراً في 2012 من ناحية الفندور.

ما الذي تكسبه وأنت عند العميل

وأنت شغّال عند الـ Customer، أنت تشرب الصناعة. تعرف كل الـ Business Process، وتعرف الـ Communication بين الإدارات ماشٍ كيف، وتفهم البزنس بطريقة قوية جداً — لأنك عايش جوّاهم. أنت تطبّق السوفت وير وأنت في نفس الوقت موجود داخل الشركة مع هؤلاء الموظفين.

من هنا يأتي التعلّم الحقيقي: Change Management. كيف يكون عندك استراتيجية، كيف تغيّر الـ Mindset والـ Culture، كيف تتعامل مع مقاومة الناس. هذا ما لا يعلّمك إياه أحد في كورس.

والعيب؟ العميل لا يعطيك Technical Capabilities. أنت لن تعمل Configuration كل يوم — العميل لن يفتح Plant جديداً ولا شركة جديدة كل يوم. فالجزء التقني عندك يتحرك ببطء. وأنت في ناحية العميل ماسك مشروعاً واحداً، فلا أحد يستطيع أن يقيس الـ Capacity بتاعتك.

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

ما الذي تكسبه وأنت عند الشريك

عند الفندور أنت شغّال في ثلاثة أو أربعة مشاريع في نفس الوقت. الشغل أكثر ضغطاً — More Stressful — والعائد المادي المفروض أنه أعلى، لكن بعد فترة، لا من أول يوم.

والمكسب الأساسي أنك تتعلم الـ Technical بسرعة جداً. كل يوم Configuration، كل يوم مشكلة جديدة، كل يوم Development. دورك في المشروع أن تأخذ بزنس العميل وتحوّله من الورق ومن الإكسل ومن السيستمات المتفرقة إلى سيستم واحد. وستمرّ على أنواع من الشركات:

• شركة ليس عندها سيستم أصلاً وشغالة بدونه.
• شركة شغالة بعدة سيستمات، كل واحد يعمل حاجة لوحده ولا يكلّمون بعضهم — QuickBooks للحسابات، Inventory System منفصل، كاشير مختلف، والمشاريع على Excel Sheets في ملفات على الكمبيوتر.
• شركة شغالة فعلاً بالسيستم الذي تقدّمه أنت، لكنه مطبَّق بطريقة غلط. وياما عملناها لشركة تستخدم Odoo وعندها مشاكل في Odoo. وبغضّ النظر عن مَن الغلطان — أوقات كثيرة جداً تكون الشركة التي نفّذت السيستم لم تفعل شيئاً خطأ، العميل هو الذي كان عنده المشكلة. رأيناها كثيراً جداً.
• شركة جابت Project Manager للسيستم لكن ليس عندها موظفون أصلاً، فهي تريد أن تضع سيستماً لشركة غير موجودة — إدارات غير موجودة وموظفون غير موجودين — وهي تبني الهيكل. وهذا ليس غلطاً بالضرورة، لكنه أوقاتاً كثيرة هدر للموارد: أنت تطلب مني أن أبني لك الـ Process التي ستشتغل بها الشركة، ثم أبني عليها السيستم. أنا أريد منك الـ Process، وعليها أبني السيستم.

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

الحلقة الناقصة التي تُفشِل المشاريع

وارد جداً أن تكون الشركة عايزة فعلاً تعمل ERP وعايزة تشتغل عليه، والفندور قادر أن يعطيها الـ ERP — ويفشل المشروع.

يفشل بسبب أنه لا توجد الحلقة التي في النص: الشخص الذي يفهم الـ ERP ويفهم شغل الـ ERP، وفي نفس الوقت قادر أن يتكلم لغة الفندور أو الـ Partner الذي يقدّم Odoo أو SAP أو غيرهما، وهو شارب بزنس العميل ويتعامل مع الموظفين.

هذا هو دور الـ ERP Consultant عند العميل. دورك الأساسي هناك ليس أن تكتب وثائق — دورك أن تُنجِح المشروع. ولهذا بدأنا مؤخراً نضع كرايتيريا للعميل الذي نشتغل معه: إن لم تكن هذه الحلقة موجودة، الاحتمال الأكبر أن يتعثر المشروع مهما كان الطرفان جادّين.

أي صناعة تختار إن ذهبت لناحية العميل

في ناحية الـ Partner، بنسبة كبيرة تستطيع أن تشتغل أي Industry في أي وقت — إلا إذا كان الشريك متخصصاً في قطاع معيّن، وهذا نادر. نحن في NGS متخصصون بعض الشيء في المجال الطبي، لكن في النهاية أي مشروع يأتي نشتغله عادي.

في ناحية العميل الموضوع يختلف، لأنك ستقعد سنوات في نفس الصناعة:

• الـ FMCG فيها فرص عمل كويسة عموماً وتقريباً لا تقف.
• الصناعات الـ Volatile مثل Oil & Gas: سعر البترول ينزل، فتُقفل شركات ويمشي ناس. هذه تحسب حسابها.
• التصنيع هو الأحبّ والأكثر استقراراً — Stable وDynamic في نفس الوقت. تتعلم فيه Business Process كويساً جداً، وفيه Level of Complexity وFluctuation رهيب: الديماند يقلّ، الناس تشوف اللي جنبها يعمل ماذا، نودّي المخزون فين، نجيب الحاجات منين، الـ Vendors سيساعدون أم لا. لا يوجد فيه روتين. والصناعة ستبقى شغالة ما دام هناك صانع.

ولو أنت الآن تبحث عن شغل، ابحث في المصانع التي تستخدم SAP أو Odoo. مصانع المياه الغازية، مصانع الـ Cosmetics، مصانع الأكل والشرب: بيبسي كولا، مونديليز، نستله. والأدوية: سانوفي وأسترازينيكا ونوفارتس. والـ Oil & Gas: هاليبرتون وشلمبرجير. كلهم شغالون SAP.

لماذا المصنع هو أفضل مدرسة

لو داخل على المصانع فأنت لن تدخلها من غير Production Planning. حتى لو أنت Project Manager، لا بد أن تدرس موديول الـ PP، ومعه الـ QM — Quality Management. والاثنان لا يشتغلان من دون الـ MM — Material Management. ولا بد أن تكون فاهماً Finance.

وفوقها الـ Planning المتخصص. الـ APO — Advanced Planning Optimizer — أدوان في SAP، غالٍ جداً بثمن الـ SAP نفسه، طبّقته في 2017، وتطوّر وتغيّر خالص في S/4HANA وصار اسمه IBP — Integrated Business Planning. هذا معمول للمصانع Pure: كيف أعمل Planning بـ Weekly Bucket، وكيف أردّ على الديماند الذي يتغيّر من العميل. وكمّ الماستر داتا الداخل فيه رهيب — تخيّل كل Production Line داخلاً بالـ Capacity بتاعته، وحجم ما يدخل وحجم ما يخرج، والمواد الخام مقابل الـ Finished Goods.

وخذ الجذر: تويوتا أول ناس في العالم تعمل Production Line على شكل حرف U. قبلها كان الخط مستقيماً، والـ Fork Lift يمشي إلى آخر الشارع ليجيب الـ Raw Material ويأخذ الـ Finished Goods. تويوتا هي التي عملت Lean Manufacturing، وهي التي عملت الـ Kanban، ومنها بدأت فكرة الـ Agile والـ Scrum Master أصلاً.

والتصنيع هو الذي غيّر الـ Supply Chain نفسها ورفعها لمستوى ثانٍ: منه خرجت الـ KPIs مثل Health of Inventory والـ Slow Moving والـ Obsolescence، ثم أخذت الصناعات الأخرى — الـ Oil & Gas وغيرها — نفس الترمنولوجي وطبّقتها عندها لتحسّن المخزون. لأنك في الأول وفي الآخر قيمة المخزون تأكل من الربح، فأنت محتاج أن تشتغل More Efficient. وتويوتا وصلت إلى الشغل بمخزون صفر: عندها أوردر تصنيع، تجيب الـ Spares من الفندورز الموجودين حول المصنع On the Spot، فتُصنَّع العربية وتمشي. هم الذين اختاروا الـ VMI — Vendor Managed Inventory.

سبعون في المئة من نجاح المشروع عند الإدارة العليا

هذا ليس كلامي، هذا كلام علم الـ Change Management: 70% من نجاح المشروع مبني على الإدارة العليا، و30% على كل الباقي.

ولهذا في الـ Project Management وفي الـ PMP عندنا Project Sponsor، وهو بنسبة كبيرة جداً رئيس مجلس إدارة الشركة. أنا مدير المشروع، لكن مدير المشروع Management Facilitator يُدير Resources. لو الشركة لا تريد أن تطبّق، المشروع سيفشل. ولو كانت المقاومة عالية من الإدارة العليا فدوري أنا أن أحلّ هذه المقاومة.

والمقاومة نفسها طبيعية. الرجل شغّال بطريقته منذ سنوات، وتأتي أنت لتقول له غداً ستشتغل بسيستم جديد — طبيعي أن يقول لك: أنا عايش في مكان X وستوديني مكان Y وأعيد التعوّد على الناس من جديد. التغيير عكس الطبيعة البشرية. فلا بد وأنت تغيّر أن تمهّد للذي أمامك.

الأربع فئات: صنّف الناس قبل أن تبدأ

الأداة هنا هي الـ Stakeholder Analysis. تقيّم الذي أمامك على أربع نواحٍ:

1. يعرف ويريد — هذا هو الـ Key بتاعك. يعرف المعلومة ويريد التغيير. وهؤلاء لا يكونون كثيرين في الشركة.
2. يريد ولا يعرف — هذا تحتويه وتعلّمه وتعطيه Training ويحضر معك، ويصير Key User.
3. يعرف ولا يريد — هذا تحيّده. أنا لا أحبّ الرفد بصراحة، قطع العيش آخر حاجة، لكن ممكن يذهب إلى إدارة ثانية، أو يبقى تحت مراقبة. ولاحظ: أوقاتاً كثيرة خلال المشروع، لما يرى النتيجة تطلع، يغيّر الـ Mindset بتاعه. الناس لما تشوف النتيجة تتغيّر.
4. لا يعرف ولا يريد — هذا بالنسبة لي كأنه غير موجود.

وبعد الاحتواء والـ Training والـ Coaching — وأن تقول له إن هذا السيستم سيفرّق في الكارير بتاعك وفي مرتّبك — إن كان ما زال يقاوم، هنا فقط تُصعِّد للإدارة العليا. وهذه حالات نادرة جداً لا نحبّ أن نصل إليها.

مَن هم أصحاب المصلحة في المشروع

في مشروع ERP: الـ Partner أولاً. ثم الفريق الموجود داخل الشركة، وهو يعني كل الإدارات — الـ Business Process Owners، والـ Key Users، والـ Project Manager، والـ Project Sponsor، والفريق الـ Functional، والفريق الـ Technical.

Make sure أن هؤلاء كلهم Aligned. أنت راكب مركباً وهؤلاء كلهم سيجدّفون — لا بد أن يجدّفوا في نفس الوقت وفي نفس الاتجاه، وإلا لفّت المركب حول نفسها.

لا تبدأ من الصفر لمجرد أنك تريد أن تبدأ من الصفر

من الحاجات التي تؤرقني: عميل يريد أن يطبّق ERP From Scratch، يبنيه باسمه ويسمّيه X. طيب — هذا ممكن أن يُعمل فعلاً، لكن انتبه: أنت بذلك تُلغي ما وصل إليه الآخرون.

الـ SAP من كثرة ما اشتغل صارت عنده Best Practices. عندك مصنع أدوية؟ هو شغّال مع سانوفي وأسترازينيكا ونوفارتس وكل مصانع الدواء تقريباً. فالسيستم يعطيك فرصة أن تطبّق ما وصل له الآخرون، وأن تبدأ من حيث انتهوا لا من حيث بدأوا.

ولذلك حين تدخل شركة جديدة عندك Mindset من اثنين: إما «الذي قبلي كان لا يفهم شيئاً، فكّه من أوله»، وإما «الذي قبلي وصل إلى أين؟ سأكمل من هناك أو أعدّل». الثاني هو الذي يكمّل.

Functional أم Developer أم Basis؟

بعد أن تختار الجهة والصناعة، يبقى الدور.

لو ستشتغل Developer — سواء في SAP أو Odoo — فأنت محتاج أن تدرس برمجة صِرفة أولاً. لا ينفع أن تدخل تطوير ERP وأنت لست خريج Computer Science إلا إذا درست الـ IT فعلاً: Data Structure، وDesign Patterns، وProblem Solving، ولغة برمجة أياً كانت. البرمجة قد تأخذ منك ستة شهور أو سنة أو سنتين حسب سرعتك. لكن بعدها، لو أردت أن تبرمج Mobile Application ستتعلمها في ثلاثة أو أربعة أسابيع، ولو أردت Web Application نفس الحكاية، ولو أردت أن تبرمج Odoo ستجد نفسك تعملها في ثلاثة أو أربعة أسابيع كذلك. وأكثر ناس رأيتهم ناجحين كـ Developers في SAP كانوا أصحاب Background في C#. في النهاية اللغة أداة: مثل الملحّن الذي يتعلم جيتار أو عود — المهم أن تُطلِع اللحن، أن تفكّر في الحل صح وتعمل له Design صح وتقسّمه Objects صح. لو ذاهب إلى Odoo فأنت محتاج Python يميناً وشمالاً ومعها JavaScript.

لو أنت دارس بزنس فأنت أحسن واحد يشتغل Functional. أنت درست في الكلية ما معنى مشتريات، وما معنى إنتاج، وما معنى Quality، وما معنى Finance. والـ Finance هو عمود الشركة: كل حاجة تعملها داخل الشركة وداخل السيستم تُسمَّع في الـ Finance — فلو سمّعت صح فهي معمولة صح، ولو سمّعت غلط فهناك مشكلة. وأول ناس تريد السيستم أن يشتغل هم الـ Finance، لأنهم يرون الشركة كلها من بعده، والـ CFO في الغالب هو الـ Sponsor إن لم يكن صاحب الشركة نفسه — عنده الـ Reporting والـ Analysis وحاجة اسمها COPA وتكلفة المنتجات والـ Costing. ورأيت مهندسين شغالين FI/CO Consultants: درسوا محاسبة، ثم درسوا SAP، وهم أصلاً خريجو هندسة. ولو كان Background هندسة فأنت محتاج تدرس Administration وFinance واستراتيجية البزنس واللوجستيك — كلما فهمت البزنس أكثر كلما نجحت أكثر في أن تطبّق Implementation صح وConfiguration صح.

والفرع الثالث في SAP هو الـ Basis. هذا لا بد أن يكون IT خالصاً، وليس مبرمجاً بالضرورة. لا بد أن يفهم قواعد البيانات وعلى أي DB سيشتغل الـ SAP.

الفريق الرابع الذي لا يوجد عند الفندور

الفرق التي كانت عندي في SAP ثلاثة: Functional وDeveloper وBasis. لكن هناك فريق رابع، وهو موجود في ناحية العميل فقط: فريق الـ Master Data. الناس التي تعمل Entry للماستر داتا وتُديرها وتعمل لها Governance — أن تدخل صح، بالكيفية الصح، بالكودنج الصح، بالتعريف الصح، بالـ Assignment الصح.

الـ Partner ليس عنده Master Data أصلاً، لأن المفروض أن العميل هو الذي يوفّرها. ونحن الذين نطلع عين العميل كي يبعث لنا الداتا. وهل تأتي صحيحة من أول مرة؟ لا. لم تأتِ صحيحة من أول مرة ولا مرة واحدة — إلا في حالة واحدة: الشركة التي ليس عندها داتا أصلاً وتبدأ بأرصدة افتتاحية فقط.

الانتقال بين الجهتين

الانتقال من Partner إلى Client أسهل. الانتقال من Client إلى Partner أصعب قليلاً، والسبب بسيط: من الأسئلة التي نسألها لأي حد يشتغل معنا — أنت هندلت كم مشروعاً في نفس الوقت؟ الجاي من ناحية العميل اشتغل على مشروع واحد، فأنا لا أستطيع أن أقيس الـ Capacity بتاعته.

ولو ذاهب من العميل إلى الفندور، الذي تحتاج مذاكرته هو الـ Configuration والـ Project Management. والـ Developer غالباً لن يذهب إلى ناحية العميل — هو بنسبة كبيرة في ناحية الـ Partner، وحتى لو احتاج العميل Development فهو يجيبه Freelance.

والعكس له حسابات أخرى. العميل الذي يطلب حداً من Partner يكون عنده مشاكل كبيرة جداً، فلا بد أن تكون فاهماً بزنس. وانتبه لفرق العادات بين الجهتين: عند الفندور، العميل يقعد معك ستة شهور — وفي SAP سنة — وأنت لا تزور المصنع ولا تتعامل مع الناس، تتعامل مع موديل المشروع ومع الـ Key Users. في ناحية العميل لا بد أن تنزل بيديك المصنع وترى التصنيع، وأن تتعامل مع أمين المخزن ومع الموظف. مستوى الـ Ownership مختلف تماماً، والريسك أعلى: الـ Partner لو فشل عنده مشروع فعنده عشرة شغالون؛ أما أنت عند العميل فأنت الذي جاؤوا بك من أجل هذا الشيء، ولو فشل فليس هناك اختيار ثانٍ.

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

في النهاية، قرارك أنت. كل ناحية لها Pros وCons، والاثنتان تكمّلان بعضهما: الفندور وحده لا ينجح إن لم يكن عند العميل مَن يفهم، والعميل وحده لا ينجح كذلك. اعرف أي القبّعتين تلبس، وذاكر لها بالضبط.