قبل ما تصرف على ERP: العلامات التي تقول إن مشروعك سيفشل

هذه الحلقة مختلفة قليلاً. ليست عن كيف تختار سيستماً، بل عن متى لا تبدأ أصلاً. مع المهندس عز الدين ممدوح، نمرّ على أهم المشاكل التي تواجه أي مشروع ERP — سواء كنت في Partner أو في Vendor أو في ناحية العميل الذي ينفّذ المشروع — وعلى الكرايتيريا التي لو وجدتَ نفسك فيها، فالأفضل لك أن تصلح شيئاً في شركتك قبل أن تدفع في سيستم.

المشكلة المشتركة بين كل المشاريع: الماستر داتا

النصيحة الأزلية، والمشكلة الأولى المشتركة بين كل مشاريع الـ ERP بلا استثناء: الماستر داتا.

Garbage in, garbage out. تريد داتا كويسة لتخرج النتيجة حلوة ويطلع الـ Graph والـ Dashboard والدنيا ظريفة. فأول حاجة: Make sure أن الداتا عندك صح. لا تكون Duplicate، ولا تكون Redundant، ولا تكون غير حقيقية — أي لا تمثّل الواقع — ولا يكون فيها أي تكرار.

وحقيقة ينبغي أن تُقال بوضوح: لو معك أحسن Consultant في العالم، لو معك SAP نفسها أو Odoo نفسها هي التي تعمل الـ Configuration — المشروع لن ينجح بداتا غلط. حتى لو كل ما سبق صحيح.

وانتبه لماذا هذه المشكلة تحديداً هي المشتركة بين كل المشاريع: الداتا هي الشيء الوحيد الذي لا يستطيع الفندور أن يعمله عنك. الـ Configuration يعمله هو، والـ Training يعطيه هو، والتقارير يبنيها هو. أما أصنافك وعملاؤك ومورّدوك وأسعارك ومخزونك فهي بتاعتك أنت، ولا أحد في الدنيا يعرف أيها صحيح غيرك.

هل الـ Business Process عندك Up to Standard؟

الحاجة الثانية: أن تكون فاهماً أن الـ Business Process بتاعتك ماشية صح، وأنها Up to Standard.

فكرة الـ Best Practices في SAP أو في Odoo أنهم جايبونها من عِلم. تجد مثلاً أن هناك موافقات لأن الـ ISO يقول كذا، ولأن هناك Segregation of Duties، ولأن هناك Internal Audit. هو يُشبِع Needs حقيقية. فلو عندك Gap في الـ Business Process بتاعتك، أنصحك أن تبدأ بقتله — وهذا هو الجزء الذي يأخذ وقتاً في التغيير.

مثال رأيته في شركة: إدارة معيّنة هي المسؤولة عن البضاعة وهي نفسها التي تبيعها في نفس الوقت. لا. المسؤول عن البضاعة هو الـ Supply Chain، والذي يبيع هو المبيعات. الفكرة كلها أن نطبّق الـ Segregation of Duties.

الفرق بين المرونة والعشوائية

أكثر مشكلة رأيتها في المشاريع: أن يحيد العميل عن الـ Standard الخاص بالسيستم. وطول ما أنت تزوّد Enhancement وModification وCoding، تصير صيانة السيستم صعبة جداً، وتظهر مشاكل في الـ Upgrades.

خذها ببساطة: لا بد أن تكون فاهماً بزنسك عامل كيف، وصناعتك نوعها إيه، ومتطلباتك بالنسبة للسيستم إيه — ثم تختار من الـ Cycles والـ Processes ما يتماشى مع بزنسك، ولا تحيد كثيراً. أكيد ستكون هناك مرونة، وأكيد سيكون هناك Deviation Factor موجود، لكن لا يصير الانحراف عن الستاندرد هو الستاندرد بتاعك.

وهنا الفرق الذي لا تعرفه معظم الشركات: فرق بين المرونة والعشوائية. يقول لك «أنا مرن»، وفي النهاية تجد العشوائية هي المتحكمة. ثم لما لا يمشي السيستم يقول: العيب في السيستم. لا، العيب في الـ Process التي كانت ماشية في الشركة.

أجهّز الداتا أولاً أم أتعاقد أولاً؟

سؤال يسأله كل من هو مُقبِل على مشروع: أحضّر الماستر داتا ثم أشتغل مع الشركة، أم أشتغل مع الشركة ثم أحضّرها؟

الأفضل Agile — الاثنان في نفس الوقت. تعاقد مع الفندور، وأول حاجة قل له: هات الـ Script أو الـ Templates بتاعة الماستر داتا. فتبدأ تدرّب الناس عندك وترى الداتا التي عندك وتعرف متى ستصل إليها. في نفس الوقت يكون الفريق شغالاً، والفندور يعطي الـ Sessions التعريفية بالسيستم — سواء SAP أو Odoo.

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

فأنت محتاج معك Consultant يقول لك: لا، هذه الداتا محتاجة الشكل الفلاني. يأخذ Sample منها ويستخدمها على السيستم ويقول لك هل هي مظبوطة أم لا، فتعطيه Validation عليها، ثم يكمل. هكذا تشتغل مع الفندور في هذا الجزء.

الداتا ليست شيئاً تُسلّمه مرة واحدة

أي عميل يشتغل مع NGS ستجد المشكلة الأزلية معه: نحن طالبون الداتا، والداتا تأخّرت، فالمشروع تأخّر. والمشروع لم يتأخر — نحن طلبنا حاجات ولم تأتِ في ميعادها.

والسبب أن هناك فرقاً جوهرياً بين نوعين من الداتا:

• Configuration Data / Structure Data: تعملها مرة واحدة. وتعيد لمسها في مواضع محدودة — لو الشركة فتحت فرعاً جديداً، أو عملت Purchasing Group جديدة، أو Configuration جديداً.
• Master Data: تتغيّر كل يوم. كل يوم عندك منتج جديد، وكل يوم السعر يتغيّر في ظل الـ Devaluation والأسعار المتحركة، وأنت كل يوم تغيّر السعر على السيستم.

فأنت محتاج شيئاً Dynamic. ولو هذه لم تكن صح، لن تنجح.

مواصفات العميل الذي لا يصلح للمشروع الآن

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

١. ليس عندك Project Manager. لا يوجد شخص متخصص مسؤول عن المشروع.

٢. ليس عندك Sponsor، أو الـ Sponsor غير موجود عملياً. وارد جداً أن يكون صاحب الشركة نفسه — وعندنا عميل كان مرة في أفريقيا ومرة في فرنسا ومرة لا أعرف أين، ولا أستطيع أن أصل إليه. وهذا صعب: الـ Sponsor هو الفلوس، وهو صاحب القرار، وهو الذي يحرّك المشروع.

٣. ليس عندك Stakeholders للأقسام. لا يوجد شكل من الأشكال يمكّنني أن أذهب فيه إلى Project Manager وإلى Sponsor وأن أتحرك مع الإدارة.

٤. ليس عندك Process واضحة. ولاحظ الفرق: أنا ليس عندي مشكلة أن الشركة ليس فيها القسم أو ليس فيه ناس، ما دام القسم واضحاً بالـ Workflow بتاعه وبتفاصيله. تقول لي الشركة لسه تبدأ وليس عندي إدارة مشاريع؟ أنا سأركّب لك الـ Project Management في Odoo أو في SAP — بناءً على ماذا؟ أنا محتاج Stakeholder موجوداً، هو مدير المشاريع، يقول لي أريد أن أمشّي الشركة بالطريقة الفلانية فأمشّيها. أما وهو غير موجود، فسأعمل لك الستاندرد بنسبة 90%، ولما تأتي بمدير مشاريع ليشتغل على السيستم لن يوافق عليه، فسترجع تعيد الشغل من الأول.

٥. الإدارة العليا تريد السوفت وير ولا يوجد Delegation ولا إقناع داخل الشركة. المقاومة هنا تكون عالية جداً. ولا بد أن تكون هناك مقاومة، هذا طبيعي، لكن Make sure أن هناك Influence على الناس بأننا داخلون على تغيير. الـ Change Management عندي أهم من الـ Project Management وقبله. لأن السوفت وير في النهاية: مَن الذي سيشغّله؟ ومَن الذي سيعمل Input؟ ومَن الذي سيدخل الداتا؟ ومَن الذي سيُطلِع التحليل؟ الناس. فلو لم يكن عنده الـ Capacity ولا الـ Willingness ولا الـ Need — فهو لا يريد أن يكون معنا، وهذه بالنسبة لي كبيرة.

٦. الأقسام نفسها غير موجودة. الـ ERP هو الذي يربط الأقسام ببعضها. فإن لم تكن الأقسام موجودة، فأنت لست محتاجاً ERP من الأصل.

ولاحظ أن هذه الكرايتيريا متشابكة، وليست ستّ مشاكل منفصلة. اسأل: لماذا الداتا عندك غير مظبوطة؟ لأنه لا يوجد Stakeholders. فلو وُجد Stakeholder ووُجد مدير مشروع ووُجد شغل يتم، ستقدر — حتى لو لم تعمل الداتا الآن — أن تبنيها بالشكل الصح لما تصل إليها بالـ Data Sheets والتمبليتس. المشاكل الظاهرة في الداتا هي في الغالب عَرَض، وأصلها في الناس والأدوار.

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

أما «ليس عندي داتا» فهذه ليست مشكلة

هذه النقطة تحديداً تُقلَب. لو ليس عندك داتا فهذا أنسب وقت أن تبدأ فيه. ليس عندك داتا أحسن بكثير من أن تكون عندك داتا غلط.

فلو أنت تبدأ بزنسك الآن، فأنت أمام فرصة ذهبية: اعمل الـ Business Process، ثم عيّن الـ Stakeholders، ثم وفّر لهم سيستماً. هذه من الخطوات المهمة جداً لأي بزنس جديد.

وليس شرطاً أن تذهب إلى SAP وأنت لسه تبدأ — روح على Odoo. وبعد فترة قد تجد نفسك محتاجاً SAP، وستجد الانتقال أسهل عليك بكثير لأنك بدأت من سيستم موحّد. ولو أردت أن تبقى في نفس الـ Ecosystem، من SAP Business One تستطيع أن تذهب إلى S/4HANA بشكل أبسط بكثير — القفزة داخل نفس البيت أسهل من القفزة من Odoo إلى SAP، وإن كانت الثانية ممكنة أيضاً. المهم أنك لا تبدأ بحاجات بسيطة مبعثرة من غير سيستم موحّد يبني لك أو ينفّذ لك الـ Processes داخل الشركة.

الترتيب الصحيح، بهذا التسلسل

1. Business Process واضحة — أنا عارف أنا عايز إيه بالضبط.
2. الناس التي ستطبّق هذه الـ Process — Stakeholders وأصحاب قرار.
3. شخص متخصص يطبّق لك السيستم — هو الذي يعمل الـ Scope، ويعمل الـ Gap Analysis، ويظبط لك كل حاجة، ثم هو الذي يجيب الفندور.

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

تسعون في المئة من المشاريع تتأخر

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

فأنا كصاحب شركة، قبل أن أفكر أنني سأعمل Odoo أو SAP، محتاج أن أفكر: هل عملت صح على التشيك ليست كلها؟ عندي Business Process، عندي Stakeholders، عندي Project Manager. عند هذه النقطة فقط: يلا بينا ندوّر على الـ ERP الذي سنشتغل به. وساعتها أي ERP تجيبه ستستفيد منه الاستفادة الكبرى — حتى لو استخدمت Zoho أو حاجات أقل من Odoo ستجد نفسك مستفيداً بشكل أحسن بكثير جداً مما لو جئت بـ SAP وأنت غير مؤهل له، فلا تستفيد منه بـ 10%.

وكما لخّصها عز في ثلاث كلمات بعد نصف ساعة كلام: طول ما الـ Roles والـ Responsibilities واضحة، وطول ما أنت مطبّق الـ Segregation of Duties، وطول ما هناك Departments وناس تتكلم مع بعضها، وطول ما الـ Gray Areas صغيرة أو منعدمة — المشروع سينجح.

والحلول موجودة لمن يريد أن يعبر هذه المرحلة بشكل مظبوط: استشارة مدفوعة، أو Gap Analysis نسلّمه لك حتى لو لم نستلم المشروع، أو حتى مساعدتك في اختيار الفندور المناسب لك ولو لم يكن NGS ولو كان السوفت وير مختلفاً عن Odoo وSAP. وفي مشاريع الـ SAP تحديداً قد تحتاج Outsourcing لمدير مشروع يقعد عندك ستة شهور داخل شركتك، يستلم المشروع من بدايته لنهايته. المهم ألا تبدأ وأنت واقف على أرض رخوة.