أنماط حلول مرجعية
أنظمة للعمل الذي لا يتّسع له قالب جاهز.
الأمثلة أدناه أنماط حلول مرجعية، وليست ادعاءات بشأن عملاء بأعيانهم ولا منتجات جاهزة. وهي تبيّن كيف تتعامل Kerah مع حاجات تشغيلية متكررة. وكل ارتباط فعلي يبدأ بتحديد المستخدمين والقيود والتكامل مع الأنظمة القائمة والبيانات والنتائج المرجوّة.
كيف تُقرأ المخططات
- يَرِد من خارج النظام
- خطوة يؤديها النظام
- يقرّر شخص
- بيانات مُخزَّنة
- يخرج من النظام
كل مخطط رسمٌ بنيويّ، لا مواصفة فنية. وموضع الاهتمام فيه عادةً هو الموضع الذي يبقى فيه القرار بيد إنسان، والموضع الذي تستقرّ فيه البيانات.
نمط حلٍّ مرجعي
بوابة العمليات التشغيلية
الحاجة المتكررة هنا هي مكان واحد يكون فيه العمل ظاهرًا ومُسنَدًا ومُنفَّذًا ومُسجَّلًا، بديلًا عن جدول بيانات وبريد مشترك ومجموعة من العادات المتوارثة. والصعوبة نادرًا ما تكون في الشاشات، بل في نموذج الصلاحيات وسجل التدقيق والتقارير التي يجب أن تصدر عن البيانات نفسها التي يعمل عليها الناس.
وحدات هذا النمط
- إدارة آمنة للمستخدمين والأدوار
- الطلبات وقوائم انتظار المهام
- الاعتمادات والتصعيد
- لوحات المؤشرات والتقارير
- الإشعارات
- الوثائق وسجل التدقيق
- التكامل مع الأنظمة القائمة
أسئلة تُحسم مبكرًا
- تحديد الصلاحية التي تسري عند كل خطوة اعتماد، وما يجري عند غياب صاحبها
- حجم السجل الواجب الاحتفاظ به، والمدة المقرَّرة لذلك
- مدى حاجة التقارير إلى الزمن الفعلي، أو الاكتفاء بتاريخ إقفال محدَّد
- آلية مراجعة صلاحيات الوصول وسحبها عند تغيّر الأدوار الوظيفية
يتضمّن عادةً: الأنظمة المؤسسية, الاستكشاف والتصميم المعماري
نمط حلٍّ مرجعي
إدارة الحالات والطلبات
حين تتلقّى المؤسسة طلبات يلزمها تقييمها والردّ عليها، تكون المهمة الحقيقية للنظام هي الأدلة. فكل حالة تحتاج إلى وضع معلوم ومسؤول عنها والوثائق التي بُني عليها القرار وتسجيلٍ لسببه. ثم تقوم مستويات الخدمة ومنطق التصعيد على هذا الأساس، بدلًا من إلحاقها بأداة تتبّع.
وحدات هذا النمط
- تلقٍّ قابل للتهيئة
- وضع الحالة وإسنادها
- مستويات الخدمة ومنطق التصعيد
- سجلات الأدلة والوثائق
- المراسلات
- سجل قرارات كامل
- التقارير الإدارية
أسئلة تُحسم مبكرًا
- مدى الحاجة إلى تعديل نموذج التلقّي دون إصدار برمجي، ومَن يُؤتمن على تعديله
- سلوك التصعيد خارج أوقات العمل
- ما يجب إفصاحه لمقدِّم الطلب، وتوقيت ذلك
- قواعد الاحتفاظ بالأدلة المرفقة بحالة مُغلقة وحذفها
يتضمّن عادةً: الأنظمة المؤسسية, الاستكشاف والتصميم المعماري
نمط حلٍّ مرجعي
تلقّي الوثائق وفرزها بالذكاء الاصطناعي
تصل الوثائق بصيغ غير متسقة، وبأكثر من لغة أحيانًا، ويقرأ كلَّ وثيقة إنسانٌ ليقرِّر وجهتها. والأتمتة تُفيد هنا، لكن بشرط التحقق من الصحة ومعالجة التكرار ووجود نقطة اعتماد بشري صريحة. ولا تقلّ أهمية المُخرَج القابل للتتبّع عن أهمية الاستخراج نفسه.
وحدات هذا النمط
- الرفع الآمن والالتقاط
- الاستخراج والتحقق من الصحة
- التصنيف
- معالجة التكرار والحالات الاستثنائية
- الاعتماد البشري
- توجيه مسار العمل
- مُخرَجات قابلة للتتبّع
أسئلة تُحسم مبكرًا
- الحقول التي يجوز قبولها آليًا، والحقول التي تستوجب المراجعة دائمًا
- مصير الوثيقة التي يعجز النظام عن تصنيفها بثقة كافية
- مدى جواز خروج محتوى الوثائق من بيئتكم، وبموجب أي اتفاق
- كيفية إثبات قرار استخراج بعد مرور أشهر عليه
يتضمّن عادةً: الذكاء الاصطناعي والأتمتة الذكية, الأنظمة المؤسسية
نمط حلٍّ مرجعي
تجربة رقمية ثنائية اللغة
المنتج ثنائي اللغة ليس منتجًا مترجَمًا. فاتجاه الكتابة يؤثّر في تصميم الواجهة وفي الأيقونات وسلوك النماذج وبنية المحتوى، وهذه قرارات زهيدة الكلفة في البداية باهظة بعد حين. كما أنّ تصميم الاتجاهين معًا يميل إلى إنتاج واجهة أوضح في كليهما.
وحدات هذا النمط
- تجربة استخدام بالعربية والإنجليزية
- نظام تصميم يراعي الاتجاه من اليمين إلى اليسار
- تجربة ويب أو تطبيق محمول متجاوبة
- المصادقة وإدارة حسابات المستخدمين
- نماذج ومحتوى يراعيان إمكانية الوصول
- الإشعارات
- تحليلات المنتج
أسئلة تُحسم مبكرًا
- الجهة المالكة للمحتوى العربي، وإجراء مراجعته قبل النشر
- طريقة عرض الأرقام والتواريخ والعملة في كل لغة
- الأيقونات الاتجاهية التي تحمل معنى ويجب من ثَمّ أن تنعكس
- مدى لزوم تطابق اللغتين دائمًا، أو جواز تقدُّم إحداهما على الأخرى
يتضمّن عادةً: هندسة المنتجات الرقمية, الاستكشاف والتصميم المعماري
نمط حلٍّ مرجعي
طبقة البيانات والتكامل
حين يتعيّن على عدة أنظمة أن تتفق، تصبح الواجهة البينيّة هي المنتج. وما يميّز طبقة تكامل متينة ليس المسار المثالي، بل أمان إعادة المحاولة، ووضوح الرؤية حين تتعطّل إحدى التبعيات، ومطابقةٌ تستطيع المؤسسة إجراءها دون مساعدة.
وحدات هذا النمط
- بوابة واجهات برمجية (API) أو خدمات تكامل
- مواءمة البيانات
- التكامل مع أنظمة الهوية
- الأحداث وقوائم الانتظار
- ضوابط إعادة المحاولة وعدم تكرار الأثر
- الرصد والتنبيه
- تقارير المطابقة
أسئلة تُحسم مبكرًا
- تصرُّف النظام حين تتعطّل إحدى التبعيات اللاحقة
- إمكانية أن تُحدث رسالة مُعادة أثرًا مكرَّرًا
- مَن يُنبَّه عند الإخفاق، وما المتوقَّع منه فعله
- كيف تُثبت المؤسسة تطابق الطرفين عند الطلب
يتضمّن عادةً: الحوسبة السحابية والبيانات والتكامل, الاستكشاف والتصميم المعماري
نمط حلٍّ مرجعي
تحديث الأنظمة على مراحل
غالبًا ما يُستبدَل النظام القديم استبدالًا سيئًا لأنه يُستبدَل دفعةً واحدة. أما الاستبدال المرحلي فينقل قدرةً واحدة في كل مرة خلف واجهة بينيّة ثابتة، مع مطابقة عند كل خطوة وخطة تراجع مُجرَّبة عمليًا. وهو أطول زمنًا وأقلّ إخفاقًا.
مراحل هذا النمط
- تقييم الوضع القائم
- خريطة المخاطر والتبعيات
- البنية المعمارية المستهدفة
- خطة استبدال مرحلية
- ترحيل البيانات ومطابقتها
- إطلاق منضبط وخطة تراجع
- إخراج النظام القديم من الخدمة ونقل المعرفة
أسئلة تُحسم مبكرًا
- القدرة الأسلم نقلًا في البداية، والقدرة التي يجب أن تُنقل في النهاية
- المدة اللازمة لبقاء النظامين عاملين بالتوازي، وكلفة ذلك
- كيفية إبقاء النظامين متطابقين ما داما في الخدمة
- ما الذي يستوجب التراجع، ومَن يملك صلاحية إعلانه
يتضمّن عادةً: الأنظمة المؤسسية, الحوسبة السحابية والبيانات والتكامل
لا ينطبق أيٌّ من هذه تمامًا على مشكلتكم.
هذا هو الحال في الغالب. ويكفي وصف ما يجري فعلًا لنقول لكم أي أجزاء هذه الأنماط تعنيكم وأيها لا يعنيكم.