هذه المقارنة تُجرى غالبًا ضد السؤال الخطأ. كلا المنتجين يقيّد ويقفل الفترة ويوحّد حسابات مجموعة، والقرار لا يُحسم عند هذا الحد عادةً. يُحسم عند ما تملكونه أصلًا من أنظمة، وعند سؤال أعمق: هل تشترون نظامًا واحدًا أم تنضمّون إلى منظومة؟
Oracle NetSuite ERP تصفه أوراكل في وثائقها المنشورة بأنه حلٌّ سحابي متكامل لإدارة الأعمال: مجموعة واحدة تغطي المحاسبة والطلبات والمخزون والمشاريع والإنتاج وسلسلة الإمداد وعمليات المستودعات. أما Microsoft Dynamics 365 فليس منتجًا واحدًا أصلًا: توثّقه مايكروسوفت بوصفه عائلة من تطبيقات الأعمال، ولذلك فقرار تخطيط الموارد داخله هو أولًا قرارٌ بشأن أيّ تطبيق من العائلة — Business Central أم تطبيقات المالية والعمليات — قبل أن يكون قرارًا في مواجهة NetSuite.
هذا التباين هو المقارنة كلها، وأغلب المقارنات المنشورة تتجاوزه. مصلحتنا، معلنة قبل الحجة لا بعدها: نحن شركة استشارات وتنفيذ، ونكسب حين تنفّذون معنا، ولا نتقاضى عمولة من أيٍّ من الطرفين. وكل ما يرد هنا عن أيٍّ من المنتجَين مأخوذ من وثائق مالكه المنشورة، ولا نذكر نقصًا ولا حدًّا ولا «هذا لا يدعم كذا» عن أيٍّ منهما.
لا نعلن فائزًا مطلقًا، لأن الفائز يتغيّر بتغيّر وزن المعايير عندكم، وإعلانه يعني أننا قرّرنا نيابةً عنكم بلا معطياتكم. القاعدة التي نستطيع إعلانها: إن كان قراركم أن تشتروا مجموعة واحدة متكاملة وتقلّلوا عدد الجهات التي تديرونها، فاتجاه NetSuite هو الاتجاه الطبيعي لهذا القرار. وإن كانت مؤسستكم قائمة فعلًا على منظومة مايكروسوفت وتتعاملون مع الهوية والإنتاجية والبيانات داخلها، فالسؤال الأول ليس «NetSuite أم Dynamics 365» بل «أيّ تطبيق من عائلة Dynamics 365» — وحسم ذلك أولًا يوفّر عليكم جولة كاملة من التقييم. والقاعدة الثالثة التي لا يقولها أحد: إن لم يكن أيٌّ من هذين الاتجاهين واضحًا عندكم بعد، فالمشكلة ليست في الاختيار بل في أن القرار لم يُسمَّ بعد.
الجدول أدناه يقارن الطابع لا المزايا، وكل خانة فيه مأخوذة من وثائق مالك المنتج نفسه.
| المعيار | Oracle NetSuite | Microsoft Dynamics 365 |
|---|---|---|
| طبيعة المنتج | تصفه أوراكل بأنه حلٌّ سحابي واحد متكامل لإدارة الأعمال | توثّقه مايكروسوفت بوصفه عائلة من تطبيقات الأعمال، لا منتجًا واحدًا |
| أول قرار عليكم اتخاذه | هل هذه المجموعة تناسب عملياتكم؟ | أيّ تطبيق من العائلة أولًا: Business Central أم تطبيقات المالية والعمليات؟ |
| نمط النشر المنشور | تصفه أوراكل بوصفه حلًّا سحابيًا | توثّق مايكروسوفت السحابة والنشر المحلي لتطبيقات المالية والعمليات |
| الفوترة الإلكترونية وزاتكا | لا يَنسب أيٌّ من المالكَين في وثائقه المستشهد بها صفة امتثال لزاتكا إلى منتجه. القاعدة المنشورة من الهيئة نفسها هي أن الامتثال يتعلق بالحل المُطبَّق وتكامله مع الفوترة، لا بعلامة تجارية. | |
وصفوف امتنعنا عن وضعها بدل أن نخمّنها، ونقول ذلك هنا بدل حذفها بصمت: توحيد حسابات الكيانات المتعددة في جهة مايكروسوفت — إذ تنشر أوراكل ما يقابله صراحةً ولم نعثر على بيان مايكروسوفتي منشور مكافئ، والصف أحادي الجانب يوحي باستنتاج لم نصل إليه. وبنية الترخيص في جهة أوراكل — إذ تنشر مايكروسوفت حدًّا هيكليًا لترخيص الحجم ولا تنشر أوراكل بيانًا هيكليًا مقابلًا نستطيع الاستشهاد به. ومدة التنفيذ وتوفّر الشركاء والكوادر في المملكة — لا ينشرهما أيٌّ من المالكَين. والتكافؤ على مستوى الخصائص — خارج النطاق عمدًا: نقارن الطابع لا قوائم الخصائص.
لا ننشر سعرًا ولا نطاقًا ولا مضاعِفًا على هذه الصفحة. ما ننشره هو بنود الميزانية التي ينبغي أن تظهر في أي مقارنة صادقة، بلا قيم: الترخيص، والتهيئة والتخصيص، وترحيل البيانات من أنظمتكم القائمة، والتكامل مع كل نظام مصدر، والتدريب والانتشار على الفروع، والدعم السنوي، وكلفة الكادر الذي سيشغّل النظام بعد التسليم — وهذا البند الأخير هو الذي يُنسى دائمًا ويقلب المقارنة بعد سنة. أرقامنا لهذه البنود غير منشورة بعد؛ اطلبوها وستصلكم قبل أن تتحدثوا مع أي جهة. وعمل التقييم والترجيح نفسه يكون بأتعاب ثابتة يُتفق عليها قبل بدء التقييم، لا كنسبة من حجم الصفقة ولا كسعر معلن.
السؤال العملي ليس «أيهما يتوسّع أكثر» — كلاهما يخدم مؤسسات كبيرة — بل: كم يكلّفكم التخصيص الذي ستطلبونه حتمًا، ومن يملك صيانته بعد ثلاث ترقيات؟ اطلبوا من كل مورّد أن يريكم تخصيصًا مشابهًا لما تحتاجونه وقد نجا من ترقية، وكيف نجا. الإجابة عن هذا تكشف أكثر مما تكشفه أي قائمة قدرات.
لا يَنسب أيٌّ من المالكَين في وثائقه المستشهد بها صفة امتثال لزاتكا إلى منتجه، ونحن لا نَنسبها نيابةً عنه. القاعدة المنشورة من الهيئة نفسها أوضح وأنفع: الامتثال يتعلق بالحل المُطبَّق لديكم وبتكامله مع متطلبات الفوترة الإلكترونية وطريقة إصدار الفواتير وربطها، لا باسم علامة تجارية. لذلك لا تصف هذه الصفحة أي منتج بأنه «معتمد»، والسؤال الصحيح الذي تطرحونه على أي مورّد هو: أرونا عملية فوترة كاملة تعمل عند عميل في المملكة، ومن يتحمّل مسؤولية إبقائها مطابقة حين تتغير المتطلبات.
هنا يقع الفرق الحقيقي عمليًا، وهو فرق في الاتجاه لا في القدرة: كلما كان ما تملكونه أقرب إلى منظومة مايكروسوفت، قلّت المسافة التي يقطعها قرار البقاء داخلها؛ وكلما كان ما تملكونه متفرّقًا بين جهات عديدة، زادت قيمة المجموعة الواحدة المتكاملة. لا نصف أيًّا منهما بأنه «لا يتكامل» مع شيء — ذلك ادعاء نقص لا نملك مصدرًا منشورًا له.
لا ينشر أيٌّ من المالكَين بيانًا عن أعداد الشركاء أو الكوادر في المملكة، ولن نخترع رقمًا. بدل الرقم، إليكم اختبارًا تُجرونه بأنفسكم قبل التوقيع: اطلبوا أسماء ثلاث جهات نفّذ لها الشريك المقترح في قطاعكم داخل المملكة، واطلبوا التحدث إلى واحدة منها دون حضور الشريك. وتحقّقوا من أن فريق التنفيذ الذي قابلتموه في العرض هو نفسه الفريق الذي سيُسنَد إليه المشروع.
لا ينشر أيٌّ من المالكَين مدة تنفيذ معيارية، وأي مدة تُذكر لكم قبل رؤية مصادر بياناتكم ونطاق عملكم تخمين. الاختبار العملي بدل الرقم: اطلبوا من المورّد خطة بمراحل لها مخرجات قابلة للقبول أو الرفض، وابحثوا عن مرحلة صريحة لترحيل البيانات وتنظيفها — الخطة التي لا تفرد لهذه المرحلة موضعًا واضحًا ستتأخر فيها لاحقًا.
يميل الترجيح نحو NetSuite حين يكون قراركم المعلن تقليل عدد الأنظمة والجهات التي تديرونها، وحين لا تكون مؤسستكم مرتبطة ارتباطًا عميقًا بمنظومة مورّد آخر، وحين تريدون مجموعة واحدة تغطي المالية والمخزون والطلبات والمشاريع دون تركيب عدة تطبيقات وربطها. وحين يكون فريق تقنية المعلومات عندكم صغيرًا ويفضّل جهة واحدة يحاسبها بدل تنسيق بين أطراف. اقرؤوا التفاصيل في صفحة Oracle NetSuite ERP.
يميل الترجيح نحو Dynamics 365 حين تكون منظومة مايكروسوفت هي البيئة القائمة فعلًا عندكم — الهوية والإنتاجية وأدوات البيانات — فتصبح تكلفة البقاء داخلها أقل من تكلفة الخروج منها. وحين تريدون البدء بنطاق أضيق ثم التوسّع بتطبيق آخر من العائلة نفسها. وحين يكون لديكم فريق يعرف أدوات مايكروسوفت ويستطيع البناء عليها. وتذكّروا القاعدة الأهم هنا: احسموا أولًا أيّ تطبيق من العائلة تقصدون، فالمقارنة بين «العائلة كلها» و«منتج واحد» مقارنة غير متكافئة تنتهي غالبًا إلى نتيجة مضلّلة. التفاصيل في صفحة Microsoft Dynamics 365.
ثلاث حالات نقولها صراحةً ونخسر بها ارتباطًا: أن تكون بياناتكم الأساسية نفسها غير موثوقة — تعريفات متعارضة أو تسجيل ناقص — فأيّ نظام تختارونه سيرث الفوضى ويضاعف كلفتها، والترتيب الصحيح أن يُعالَج المصدر أولًا. وأن يكون حجم عملياتكم وتعقيدها دون ما يبرّر نظامًا مؤسسيًا من هذه الطبقة، وحينها تكون الحلول الأصغر أصدق مع حالتكم وأرخص. وأن يكون القرار الحقيقي تنظيميًا لا تقنيًا — ملكية العملية غير محسومة بين إدارتين — فالنظام لن يحسمها وسيصبح ساحة الخلاف بدل أن يكون حلّه.
نبدأ من القرار وصاحبه، ثم نكتب المعايير ونوزنها معكم قبل ذكر أي اسم، ثم نقيس كل خيار مقابلها بالدليل، ثم نعرض ترشيحًا مبرَّرًا ومعه البدائل وسبب استبعاد كل بديل — ومن بينها دائمًا بديلان يُهملان عادة: الإبقاء على ما لديكم بعد ضبطه، وعدم فعل شيء الآن. تفاصيل الإجراء في كيف نقيّم بحياد، وما يخصّ تخطيط الموارد تحديدًا في استشارات اختيار ERP. وإن كان سؤالكم أوسع من هذين المنتجَين فابدأوا من مقارنة الأنظمة المؤسسية.
لا. ولو كنا نتقاضاها لكان إعلانها واجبًا على هذه الصفحة نفسها لا في سياسة مدفونة في مكان آخر. وعلاقاتنا مع المورّدين — حيث وُجدت — تُنشر في صفحة الشركاء بوصفها مصدر الحقيقة المحدَّث، ولا تُلمَّح في ثنايا النص ولا تُرجّح كفّة في أي ترشيح.
نراجعها حين يتغيّر ما يغيّر القرار — بنية الترخيص أو الطرح الإقليمي أو ما ينشره المالك عن طبيعة منتجه — لا على جدول دوري شكلي. وكل ما ورد هنا مأخوذ من وثائق المالكَين المنشورة وقت الكتابة، وحين نعجز عن التحقق من تغيّر نقوله في الصفحة بدل تمريره. إن وجدتم بيانًا منشورًا يناقض ما هنا فأخبرونا وسنصحّحه.
هذا القسم معنون بالأرقام ولا يحتوي على أي رقم، وعليه أن يشرح نفسه: عدّادات المشاريع والعملاء وسنوات الخبرة قيمٌ لا يستطيع القارئ التحقق منها، ونحن لا ننشر ادعاءً لا نستطيع إسناده. السؤال الذي يستحق أن يُطرح علينا وعلى غيرنا في اجتماع مغلق: كم مرة انتهى تقييمكم بتوصية بعدم الشراء؟
لا ننشر اسم عميل إلا بإذن مكتوب منه لهذا الغرض تحديدًا، ولا نستخدم صيغة «جهة رائدة» المجهّلة — فهي القالب الذي يختبئ فيه الاختلاق. في جلسة خاصة نعرض ارتباطات من قطاعكم بتفاصيلها الحقيقية، بما فيها ما لم يكتمل.
حين تُنشر حالة هنا فستُنشر باسم صاحبها وبموافقته المكتوبة وبأرقام راجعها هو. دراسة الحالة التي لا يمكن التحقق من صاحبها إعلانٌ يرتدي ثوب دليل، وهي على صفحة مقارنة بين مورّدَين أخطر منها في أي موضع آخر: إذ تبدو سندًا لترجيح لم تُسنده.
لا ننشر شهادة عميل حتى يراجع العميل نصّها المنسوب إليه ويوافق عليه كتابة. الاقتباس المجهول لا يضيف شيئًا سوى مخاطرة بمصداقية الصفحة كلها، وهي مخاطرة غير مجزية: من يصدّقه لا يحتاجه، ومن يحتاجه لا يصدّقه.
لا ننسب لأنفسنا صفة اعتماد أو ترخيص أو شهادة من أي جهة، ولا نصف أنفسنا بشراكة لا يستطيع القارئ التحقق منها من مصدرها المنشور. والأساس الذي نقدّم عليه هذه المقارنة ليس صفة نمنحها لأنفسنا بل إجراء تستطيعون فحصه: معايير مكتوبة قبل الأسماء، ومصادر معلنة لكل ما نقوله عن منتج لا نملكه، وامتناع مُعلن عن كل صف لم نجد له سندًا منشورًا.
إن كنتم تميلون إلى أحد الاتجاهين فاقرؤوا صفحة المنتج المقابلة له أعلاه، ثم اكتبوا معاييركم وأوزانها قبل أن تطلبوا أي عرض — فالعرض الذي يصل قبل المعايير يُعيد تشكيلها. وإن كنتم لا تزالون بين الاثنين فالخطوة الأنفع ليست قراءة مقارنة أخرى بل تسمية القرار نفسه. وهذه المقارنة متاحة كذلك بالإنجليزية لمن يفضّلها أو يريد مشاركتها مع زميل لا يقرأ العربية: English.
المقارنة المنشورة تُرجّح بأوزان عامة، وحالتكم ليست عامة. في جلسة واحدة نكتب معاييركم وأوزانها ونقيس الخيارين مقابلها، وتخرجون بالورقة تملكونها حتى لو لم تكملوا معنا — ومنها تستطيعون محاكمة أي عرض يصلكم لاحقًا من أي جهة، بما في ذلك عرضنا.