خصّص النموذج الفوقي — بخفّة

النموذج الفوقي في Turbo EA قابل للتهيئة بالكامل من قبل المسؤول — كل نوع بطاقة وحقل ونوع فرعي وعلاقة ودور صاحب مصلحة هو بيانات، لا شيفرة. ستُغرى بإعادة تصميمه. لا تفعل.

الفرق التي تنجح تخصّص النموذج الفوقي فقط عندما لا تستطيع الحقول الافتراضية الإجابة عن سؤالها. الفرق التي تفشل تقضي شهرها الأول في إعادة تسمية Application إلى Solution، وإضافة 30 حقلًا مخصصًا، ولا تصل أبدًا إلى تقرير عامل.

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

قبل إضافة أي شيء، اعرف ما لديك بالفعل. نوع البطاقة المدمج Application يأتي بهذه الحقول جاهزة (من بين أخرى):

الحقل المدمج	النوع	لِمَ هو موجود
businessCriticality	single_select	حرج للمهمّة / مهم / مفيد / هامشي
functionalSuitability	single_select	مثالي / مناسب / غير كافٍ / غير معقول
technicalSuitability	single_select	مناسب تمامًا / كافٍ / غير معقول / غير ملائم
timeModel	single_select (مطلوب)	التحمّل / الاستثمار / الترحيل / الإلغاء — تصنيف TIME القياسي من Gartner
riskLevel	single_select	منخفض / متوسط / مرتفع / حرج
businessValue	single_select	يقود محور Y في تقرير المحفظة
costTotalAnnual	cost	إجمالي التكلفة السنوية
lifecycle.*	تواريخ	Plan / Phase In / Active / Phase Out / End of Life

كل ما يحتاجه ترشيد محفظة التطبيقات موجود بالفعل، بما في ذلك نموذج TIME. لست بحاجة إلى إضافة حقل TIME — أنت تعبّئه (يدويًا أو عبر حساب، راجع أول تحليل لك). الأمر نفسه ينطبق على functionalSuitability وtechnicalSuitability، وهما بُعدا الملاءمة اللذان يقودان تقليديًا تحديد موضع TIME.

اختبار السؤالين قبل إضافة حقل

عندما تجد نفسك فعلًا بحاجة إلى حقل غير موجود فعليًا في النموذج الفوقي، اسأل نفسك:

1. هل سأرشّح أو أجمّع أو أُعِدّ تقريرًا على هذا الحقل؟ إذا كانت الإجابة لا، فهو ينتمي إلى الوصف أو إلى وسم — لا إلى حقل.
2. هل الإجابة نفسها مطلوبة على كل بطاقة من هذا النوع؟ إذا كانت الإجابة لا، فهي علاقة أو مرفق، لا حقل.

إذا لم تستطع الإجابة بـ "نعم" على كليهما، فلا تضِف الحقل.

إذا كنت تحتاج فعلًا إلى حقل مخصص

للحالة النادرة التي يكون فيها حقل جديد فعلًا مطلوبًا (مثل علامة cloudReadiness، أو تصنيف تنظيمي، أو علامة شريحة عملاء)، سير العمل هو:

1. اذهب إلى الإدارة ← النموذج الفوقي، انقر النوع، وبدّل إلى تبويب الحقول.
2. اختر القسم (أو أنشئ قسمًا جديدًا) وانقر + إضافة حقل.
3. عبّئ:
   • المفتاح بصيغة lower camel-case (مثل cloudReadiness) — يصبح مفتاح السمة في JSON وفي الصيغ.
   • التسمية (وترجمة لكل لغة تدعمها — وإلا سيرى المستخدمون غير الناطقين بالإنجليزية المفتاح الخام).
   • النوع — text أو number أو cost أو boolean أو date أو url أو single_select أو multiple_select.
   • الوزن — 0 للاستبعاد من جودة البيانات، 1+ للتضمين والترجيح.
   • مطلوب — اتركه معطّلًا للطرح الأول؛ "مطلوب" يحجب الموافقة على كل بطاقة موجودة.
4. لأنواع التحديد، أضف الخيارات (المفتاح + التسمية + اللون) وترجم كل خيار.
5. احفظ.

يصبح الحقل متاحًا فورًا في المخزون (الأعمدة، المرشّحات)، وفي تفاصيل البطاقة، وفي صيغ الحسابات بصيغة <fieldKey>. المرجع الكامل: الإدارة ← النموذج الفوقي.

خيار: اشتقاق حقل تلقائيًا بحساب

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

المثال القياسي هو حساب نموذج TIME الذي يشتقّ الحقل المدمج timeModel على Application من بُعد ملاءمة الأعمال وبُعد الملاءمة التقنية. يأتي كأحد الإدخالات في لوحة مرجع الصيغ داخل الإدارة ← النموذج الفوقي ← الحسابات عند إنشاء حساب جديد، بحيث يمكنك اختياره من اللوحة مباشرة. النوع الهدف = Application، الحقل الهدف = timeModel؛ والصيغة المتوفرة في اللوحة مُعاد إنتاجها في الإدارة ← الحسابات ← أمثلة الصيغ.

تفترض الصيغة وجود حقلَي single_select باسمَي businessFit وtechnicalFit بالخيارات excellent / adequate / insufficient / unreasonable. وهما ليسا في النموذج الفوقي المدمج — أضفهما على Application وفق خطوات الحقل المخصص أعلاه إذا أردت استخدام هذا الحساب.

لا تفعل

TIME المحسوب هو فرضية انطلاقية، لا حكم نهائي. إما أن تراجع كل نتيجة مع مالك التطبيق قبل الوثوق بها، أو أن تُوقف الحساب وتعتمد على الإدخال اليدوي بمجرد انتهاء ورشة التحقق.

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

بديل: استخدم مجموعة وسوم بدلًا من ذلك

إذا كانت القيمة معلوماتية لا قابلة للاستعلام، فإن مجموعة وسوم (الإدارة ← الوسوم) أخفّ من حقل مخصص — لا تغيير في النموذج الفوقي، لا ترحيل، أسهل في التطوّر. استخدم مجموعة وسوم عندما:

• تكون القيمة وصفية ("مواجِه للعملاء"، "داخلي فقط"، "مُستحوَذ عليه في 2024").
• قد تضيف خيارات جديدة بشكل متكرر.
• لا تحتاج إليها في قائمة مرشّح منسدلة بل تكفي رقاقة وسم بحث-أثناء-الكتابة.

استخدم حقلًا مخصصًا عندما:

• تحتاج إلى القيمة على محاور تقرير المحفظة (X، Y، اللون).
• تريدها مرجّحة في جودة البيانات.
• تكون مفردات مضبوطة لن تتغير كثيرًا.

الأنماط المضادّة التي يجب تجنّبها

هذه أكثر أخطاء النموذج الفوقي شيوعًا في عمليات الطرح الأولى:

لا تُعِد تسمية أنواع البطاقات المدمجة

إعادة تسمية Application إلى Solution تبدو مرتّبة لكنها تكسر التعيين المفاهيمي الذي تفترضه خريطة القدرات الحرارية وتقرير المحفظة والكتالوجات جميعًا. إذا كانت مؤسستك تسمّيها "حلول"، فاضبط ترجمة التسمية — يبقى key الأساسي كما هو Application.

لا تضِف 30 حقلًا مخصصًا في اليوم الأول

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

لا تكرّر الحقول المدمجة

قبل إضافة timeDisposition أو funcFit أو techFit أو appBusinessValue، تحقّق من قائمة الحقول الموجودة — على الأرجح يوجد بالفعل حقل مدمج مكافئ (timeModel، functionalSuitability، technicalSuitability، businessValue). التكرارات تقسّم بياناتك وتكسر التقارير.

لا تجعل الحقول الجديدة required في اليوم الأول

Required يحجب الموافقة على كل بطاقة موجودة لا تحمل قيمة. اجعل حقلًا مطلوبًا فقط بعد أن تكون قد عبّأته لما يزيد على 80% من المجتمع.

لا تنشئ أنواع بطاقات مخصصة بدلًا من حقول مخصصة

"تطبيق الجوال" ينبغي أن يكون نوعًا فرعيًا من Application، لا نوع بطاقة جديدًا. الأنواع الجديدة لا تحصل على ربط القدرات أو تقارير المحفظة أو عمليات استيراد الكتالوج مجانًا.

امتدادات خفيفة أخرى قد تريدها

هذه امتدادات شائعة في المرحلة الثانية، لكن لا تضفها حتى تحتاج إليها فعلًا:

الحاجة	أين تُضاف	النوع
الجاهزية للسحابة	Application	single_select (جاهز / يحتاج إعادة هيكلة / يبقى في الموقع)
علامة مواجِه للعملاء	Application	boolean
التصنيف التنظيمي	Application، DataObject	multiple_select (GDPR، PCI-DSS، …)
فئة خطر الفقدان	Application، IT Component	single_select (نقطة فشل وحيدة، إلخ)
تقسيم التكلفة	Application	حقول cost إضافية لـ costRunTotalAnnual وcostChangeTotalAnnual

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

التالي: أول تحليل لك: مواءمة التطبيقات.