الاختيار بين تطبيق على ServiceNow ومنتج مستقل
قد يكون المتطلب نفسه تطبيقًا محدد النطاق، وقد يكون بناءً مستقلًا للويب والموبايل. والخطأ في الاختيار مكلف في الاتجاهين. هذا هو إطار القرار الذي نستخدمه، بما في ذلك الحالات التي تكون فيها الإجابة البديهية هي الخاطئة.
يصل طلب بسيط: «نحتاج نظامًا لـ X». وإذا كنت تملك ServiceNow أصلًا، فهناك ميل قوي إلى بنائه تطبيقًا محدد النطاق. أحيانًا يكون ذلك صحيحًا. لكنه كثيرًا ما يكون صحيحًا لأسباب خاطئة، لأن الترخيص مدفوع أصلًا، لا لأن المنصة مناسبة فعلًا.
وهذه هي الطريقة التي نقرر بها فعليًا.
ابنِه على ServiceNow حين يكون العمل سير عمل
تتفوق ServiceNow في شكل محدد من المشكلات: سجل ينتقل بين حالات، ويتعامل معه أشخاص مختلفون في مراحل مختلفة، وتحتاج المؤسسة إلى تاريخ قابل للتدقيق يبيّن من فعل ماذا.
العلامات التي تشير إلى تطبيق محدد النطاق:
- المستخدمون الأساسيون يملكون ترخيص ServiceNow أصلًا
- العملية كثيفة الموافقات أو لها متطلبات امتثال حقيقية
- تحتاج إلى قراءة بيانات CMDB أو الموارد البشرية أو ITSM القائمة أو كتابتها
- يجب أن تظهر التقارير إلى جانب تقارير منصتك الأخرى
- سيستمر سير العمل في التغيّر، وتريد أن يكون هذا التغيير ضبطًا للإعدادات لا نشرًا برمجيًا
وهذه النقطة الأخيرة لا تُقدَّر حق قدرها. تغييرات سير العمل على المنصة تصل أسرع من تغييرات الكود، وينفّذها أشخاص ليسوا مهندسين.
ابنِه مستقلًا حين يكون العمل منتجًا
يضعف الميل إلى المنصة بسرعة في ظروف معينة:
- المستخدمون خارجيون: عملاء أو موردون أو عامة الناس. وترخيص المستخدمين الخارجيين عادةً ما يُنهي النقاش.
- الواجهة هي الغاية. تفاعل بمستوى تطبيقات المستهلكين، وعمل دون اتصال، وعتاد الجهاز، والإشعارات الفورية، واستجابة في أقل من ثانية.
- يجب أن يكون على متجر تطبيقات.
- نموذج البيانات لا يشبه سجل المهمة إطلاقًا.
- تتوقع حركة مرور مجهولة كثيفة.
إذا تحقق ثلاثة من هذه الشروط، فإن إجباره على المنصة ينتج شيئًا يصارعها طوال عمره.
نمطا الفشل
الإفراط في الاعتماد على المنصة. بوابة موجّهة للعملاء بُنيت تطبيقًا محدد النطاق لأن الترخيص موجود. تعمل، لكن كل تعديل على الواجهة معركة، وترخيص المستخدمين الخارجيين يكلّف أكثر من البناء نفسه، وتجربة الموبايل حل وسط لا يدافع عنه أحد.
التقصير في الاعتماد على المنصة. أداة موافقات مستقلة بُنيت لأن الفريق أراد حزمة تقنية حديثة. وبعد ستة أشهر تعيد تنفيذ الإشعارات وتاريخ التدقيق والتحكم في الوصول بحسب الأدوار ومحرك الموافقات، وكلها كانت موجودة في المنصة، ومختبَرة، ومتوافقة.
يكلّف الخطآن تقريبًا القدر نفسه. لكنهما يظهران في وقتين مختلفين: الأول يؤلم فورًا وباستمرار، والثاني يؤلم بعد أن تزول حداثة البناء من الصفر.
الحل الوسط شائع
صياغة «منصة أو منتج» كثيرًا ما تكون خاطئة. وهذا شكل متكرر:
- سير العمل والسجلات والموافقات والتدقيق تعيش على ServiceNow
- الواجهة التي يلمسها المستخدمون الخارجيون تطبيق ويب أو موبايل منفصل
- ويتحدث الطرفان عبر حدود API موثّقة
فتحصل على محرك سير العمل في المنصة وما تقدمه من امتثال، وعلى واجهة أمامية لا تقيّدها أدوات البوابة. والثمن تكامل عليك امتلاكه، وهو حقيقي لكنه محدود.
أسئلة تحسم الأمر سريعًا
حين يكون الأمر غير واضح فعلًا، فغالبًا ما تحسمه هذه الأسئلة:
- من يسجّل الدخول، وهل هم مرخَّصون؟ المستخدمون الخارجيون بأي حجم يدفعون بقوة نحو الحل المستقل.
- إذا تغيّرت العملية في الربع القادم، فمن يغيّرها؟ إن كان الجواب محلل أعمال، فهذا يرجّح المنصة.
- ماذا سيحدث لهذه البيانات عند التدقيق؟ إن كان أحدهم سيسأل «من وافق على هذا ومتى»، فقد حلّت المنصة هذه المسألة أصلًا.
- هل كنت ستبنيه هنا لو كان الترخيص مجانيًا؟ هذا السؤال يزيل منطق التكلفة الغارقة أفضل من أي سؤال آخر.
فإن كان الجواب الصادق عن السؤال الأخير لا، فقد وجدت إجابتك، والترخيص الذي دفعته سابقًا ليس سببًا لبناء الشيء الخاطئ.
ما نفعله حيال ذلك
نعمل في الممارسات الثلاث جميعها، أي أنه لا دافع بنيويًا لدينا لدفعك نحو واحدة منها. محادثة تحديد النطاق تدور فعلًا حول الملاءمة، وأحيانًا تكون التوصية الصادقة مشروعًا أصغر مما طلبت، أو مشروعًا يُبنى في مكان غير الذي افترضته.