Capability Map: كيف تقرر مصير كل نظام في مؤسستك

في مقال معمارية المؤسسة بدأنا بسؤال المدير «ماذا يتوقف إذا أوقفنا نظام HR القديم؟»، وفي هذا المقال سوف نجيب عن السؤال الذي يأتي بعده دائماً: لدينا أربعون نظاماً، فأيها نبقيه، وأيها ندمجه مع غيره، وأيها نستبدله أو نوقفه؟ والإجابة تحتاج مرجعاً ثابتاً تقيس عليه الأنظمة، فلا يصح أن تقيس نظاماً على الهيكل التنظيمي لأنه يتغير مع كل إعادة هيكلة، ولا على الإجراءات لأنها تتغير مع كل مشروع تحسين، وهذا المرجع الثابت هو خريطة قدرات الأعمال Business Capability Map، ثم تأتي إدارة محفظة التطبيقات Application Portfolio Management لتربط كل نظام بالقدرات التي يخدمها وتقيمه وتقرر مصيره.

وسوف نناقش في هذا المقال ما يلي:

ما هي القدرة Capability، وما الفرق بينها وبين الإجراء Process والإدارة Organizational Unit والنظام Application.
بناء خريطة قدرات بثلاثة مستويات لشركة توصيل افتراضية، خطوة بخطوة.
إدارة محفظة التطبيقات: ما الذي تجمعه عن كل نظام، ولماذا.
ربط التطبيقات بالقدرات لاكتشاف التكرار والفجوات.
نموذج TIME وتقييم كل نظام بالقيمة للأعمال والحالة التقنية، ثم قرارات الترشيد Rationalization.
جدول جاهز لسجل المحفظة، وأدوات مفتوحة المصدر تساعدك.

ما هي القدرة Capability؟

القدرة هي ما تستطيع المؤسسة فعله، بغض النظر عن من يفعله وكيف يفعله وبأي نظام. والتعريف الرسمي الذي تستخدمه هيئة الحكومة الرقمية في الدليل الاسترشادي لتطبيق المنهجية الوطنية للبنية المؤسسية (الإصدار 1.0، مارس 2026، صفحة 154 من النسخة العربية) يسميها «قدرة عمل» ويقول إنها «تمثل القدرة الإستراتيجية والتشغيلية التي تميز الجهة وتمكنها من تحقيق أهدافها، إذ تتضمن القدرات مجموعة متكاملة من الجوانب مثل المهارات، والمعرفة، والتقنيات، والموارد المالية، والعلاقات». ولاحظ آخر جزء من التعريف، فالقدرة ليست النظام، والنظام هو أحد الأشياء التي تحتاجها القدرة مع الأشخاص والمعرفة والمال.

والخلط الأشهر عند بناء أول خريطة هو أن ترسم الهيكل التنظيمي وتسميه خريطة قدرات، أو أن تكتب قائمة الإجراءات وتسميها قدرات، والصورة التالية تبين الفرق بقدرة واحدة من شركة التوصيل الافتراضية التي نستخدمها في مقالات هذه المرحلة، وهي «تتبع الشحنات Shipment Tracking»:

دائرة داكنة في الوسط مكتوب فيها CAPABILITY Shipment Tracking تتبع الشحنات ماذا What، وحولها أربع مناطق: PROCESS الإجراء كيف How فيها 1 Driver scans parcel و2 Event saved و3 Customer notified، وORG UNIT الإدارة من Who فيها Operations وCustomer Care، وAPPLICATION النظام بماذا With what فيها Driver App وTracking Portal، وDATA البيانات فيها Shipment وTracking event، وفي الأسفل: الإدارة والإجراء والنظام تتغير والقدرة تبقى — القدرة تجيب عن «ماذا»، والإجراء عن «كيف»، والإدارة عن «من»، والنظام عن «بماذا»

ونفس الدليل يعرف هذه المكونات منفصلة (صفحة 154 و155)، وفيما يلي الفرق بلغة بسيطة:

القدرة Business Capability: ماذا تفعل المؤسسة، مثل «تتبع الشحنات»، وتبقى ما دام هذا العمل مطلوباً.
الإجراء Business Process: سلسلة خطوات لتحقيق نتيجة، مثل «يمسح السائق الشحنة، ثم يحفظ الحدث، ثم يصل إشعار للعميل»، ويتغير كلما حسنت المؤسسة طريقة العمل.
الوحدة التنظيمية Organizational Unit: جزء من الهيكل التنظيمي له مهام محددة، مثل إدارة العمليات، ويتغير مع إعادة الهيكلة.
الخدمة Service: القيمة التي تقدمها المؤسسة للمستفيد عبر مجموعة من الأنشطة، مثل «تتبع شحنتك» في موقع الشركة.
التطبيق Application: النظام الذي يدعم القدرة، مثل تطبيق السائقين وبوابة التتبع، ويستبدل عندما يتقادم.

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

ولتسمية القدرات قواعد بسيطة تجعل الخريطة مفهومة: الاسم يصف عملاً وليس إدارة ولا نظاماً، فتكتب «تتبع الشحنات» وليس «إدارة التتبع» ولا «نظام Tracking Portal»، ولا يتكرر نفس الاسم في أكثر من قدرة كما ينص الدليل (صفحة 158)، ولا تتداخل قدرتان في نفس العمل، والسبب أن القدرة المكررة تعني أن نظامين سوف يربطان بها دون أن يظهر التكرار.

بناء خريطة القدرات بثلاثة مستويات

الخريطة تبنى من الأعلى إلى الأسفل في مستويات، والمستوى الأول Level 1 هو القدرات الرئيسية التي تراها الإدارة العليا في صفحة واحدة، والمستوى الثاني Level 2 هو تقسيم كل قدرة رئيسية إلى قدرات فرعية، والمستوى الثالث Level 3 تفصيل إضافي تحتاجه فقط حيث يوجد قرار يتطلبه. وفي النموذج المرجعي الوطني لبنية الأعمال (صفحة 156 إلى 158 من الدليل) تقسم القدرات إلى ثلاثة أنواع، وهو تقسيم مفيد لأي مؤسسة وليس للجهات الحكومية فقط:

القدرات الإدارية والتنظيمية: التي ترسم التوجهات الإستراتيجية وتحوكم الأعمال وتتابع الإنجاز، مثل الإستراتيجية والحوكمة والمخاطر والامتثال.
القدرات المحورية Core: التي تمثل سبب وجود المؤسسة، وتختلف من قطاع إلى قطاع، لذلك لا يضع لها الدليل قائمة جاهزة.
القدرات الداعمة Supporting: التي تمكن غيرها من العمل دون أن تحقق الأهداف مباشرة، وتنقسم إلى تشغيلية Operational مثل المرافق والعقود والمشتريات ورأس المال البشري، وتمكينية Enabling مثل تقنية المعلومات والدراسات والتميز التشغيلي.

والصورة التالية خريطة بالمستويين الأول والثاني لشركة التوصيل الافتراضية، والتقسيم إلى الأنواع الثلاثة من الدليل، أما القدرات نفسها فمثال من إعدادنا:

خريطة قدرات في ثلاثة أشرطة. MANAGEMENT فيها Strategy and Planning وGovernance, Risk, Compliance وPerformance Management. CORE فيها ست قدرات رئيسية بالبرتقالي: Customer Orders وتحتها Order Capture وQuotation وOrder Changes، وDelivery Operations وتحتها Route Planning وDispatch وShipment Tracking وProof of Delivery وReturns Handling، وHub and Warehouse وتحتها Inbound Sorting وStorage وOutbound Loading، وFleet Management وتحتها Vehicle Maintenance وTelematics وFuel Management، وCustomer Care وتحتها Inquiries وCustomer Relationship وNotifications، وPricing and Billing وتحتها Tariffs وInvoicing وCollections. وSUPPORTING فيها صف تشغيلي Human Capital وFinance and Accounting وProcurement and Contracts وFacilities وصف تمكيني IT Management وData and Analytics وInformation Security — صفحة واحدة تصف ما تفعله الشركة، وليس فيها اسم إدارة ولا اسم نظام

وفيما يلي خطوات بناء هذه الخريطة كما نقترحها، وهي قريبة من الإرشادات العامة في الدليل الوطني:

ابدأ من الإستراتيجية والخدمات: اقرأ إستراتيجية المؤسسة وقائمة خدماتها لعملائها، فكل خدمة تحتاج قدرة أو أكثر، وهذه بداية القدرات المحورية.
اكتب مسودة المستوى الأول بنفسك: لا تبدأ بورشة عمل وصفحة فارغة، لأن الورشة الفارغة تنتهي بالهيكل التنظيمي، وابدأ بمسودة صغيرة يتناقش حولها الحاضرون.
ورش عمل مع قادة الإدارات: لكل قدرة رئيسية جلسة مع من يملكها لتفصيل المستوى الثاني، وهذا ما يوصي به الدليل لفهم مستوى التفصيل المطلوب.
اختبر عدم التداخل: اسأل عن كل قدرتين متجاورتين: هل يوجد عمل يمكن أن يوضع في الاثنتين؟ إذا وجد فأعد التقسيم أو التسمية.
اربط القدرات بما حولها: كل قدرة لها مالك من الأعمال، وترتبط بالإدارات التي تنفذها، ثم بالخدمات والإجراءات، والدليل ينص على أن كل قدرة يجب أن ترتبط بخدمة أو إجراء واحد على الأقل، وإلا فراجعها.
انزل إلى المستوى الثالث عند الحاجة فقط: كما في الصورة التالية.
اعتمدها وحدد موعد مراجعتها: الخريطة تحدث عندما تتغير أنشطة المؤسسة أو إستراتيجيتها، وليس كل أسبوع.

ثلاث مناطق من اليمين إلى اليسار: LEVEL 1 فيها Delivery Operations عمليات التوصيل ومكتوب تحتها صفحة واحدة للإدارة العليا، ثم LEVEL 2 فيها Route Planning وDispatch وShipment Tracking مظللة وProof of Delivery وReturns Handling ومكتوب لكل مدير إدارة ومعماري التطبيقات، ثم LEVEL 3 فيها Tracking Event Capture وCustomer Status Inquiry وDelay Alerts وTracking History Archive ومكتوب فقط حيث يوجد قرار يحتاج هذا التفصيل — المستوى الثالث لقدرة «تتبع الشحنات» فقط، لأن الشركة تفكر في استبدال نظامها

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

إدارة محفظة التطبيقات Application Portfolio Management

محفظة التطبيقات Application Portfolio هي كل الأنظمة التي تملكها المؤسسة أو تشترك فيها، وإدارتها تعني ثلاثة أشياء تتكرر كل سنة: تعرف ماذا تملك، وتقيم كل نظام، وتقرر مصيره. والكلمة مأخوذة من إدارة المحافظ الاستثمارية، فالمستثمر لا يقيم كل سهم وحده، وإنما ينظر إلى المحفظة كاملة ويقرر أين يزيد وأين يبيع، وكذلك المؤسسة لا تسأل «هل هذا النظام جيد؟» فقط، وإنما «هل نحتاج هذا النظام مع وجود الأنظمة الأخرى؟».

والخطوة الأولى هي سجل التطبيقات Application Inventory، وفيما يلي الحقول التي نقترح جمعها لكل نظام مع سبب كل حقل:

المالك من الأعمال Business Owner والمالك التقني Technical Owner: والسبب أن النظام بلا مالك لا يقرر أحد مصيره، وأن قرار الإيقاف يحتاج موافقة الاثنين.
القدرات التي يخدمها: بالمستوى الثاني، وهذا الحقل هو الذي يكشف التكرار.
عدد المستخدمين وأهمية النظام Criticality: نظام يستخدمه عشرة موظفين مرة في الشهر يختلف عن نظام إذا توقف ساعة توقفت الشحنات.
البيانات وتصنيفها Data Classification: والسبب أن قرار الإيقاف أو النقل إلى السحابة يتغير إذا كان النظام يحفظ بيانات شخصية أو سرية.
التكاملات Integrations: عددها وأسماء الأنظمة الأخرى، لأن كل تكامل عمل إضافي عند الاستبدال.
الاستضافة Hosting والتقنية Tech Stack: أين يعمل، وبأي لغة وقاعدة بيانات، وهل الإصدار ما زال مدعوماً.
الترخيص والتكلفة السنوية وتاريخ انتهاء العقد: تاريخ انتهاء العقد هو اللحظة الطبيعية لقرار الاستبدال، فإذا فاتتك تجدد العقد سنة أخرى.
حالة الدعم Support Status: هل المورد ما زال يصدر تحديثات أمنية؟ وهل يوجد في الفريق من يعرف الكود؟

وهذا السجل هو نفسه جرد الأصول Asset Inventory الذي تطلبه ضوابط الأمن السيبراني، فالمكون 2-1 في الضوابط الأساسية للأمن السيبراني ECC هدفه أن تكون لدى الجهة قائمة جرد دقيقة وحديثة لأصولها المعلوماتية والتقنية، وقد شرحنا العلاقة بين الاثنين في مقال معمارية المؤسسة في الجهات الحكومية، والخلاصة أن تبني سجلاً واحداً يخدم الاثنين، ولا تبني سجلين يختلفان بعد ستة أشهر.

ربط التطبيقات بالقدرات: التكرار والفجوات

عندما يكتمل السجل، تضع كل نظام فوق القدرات التي يخدمها، وتلون كل قدرة حسب حالة الأنظمة تحتها، والنتيجة خريطة حرارية Heat Map تقرؤها الإدارة في دقيقة، كما في الصورة التالية للقدرات المحورية في شركة التوصيل:

ست قدرات رئيسية داكنة وتحت كل منها قدراتها الفرعية ملونة ومكتوب فيها اسم النظام: بالأخضر نظام واحد مناسب مثل Order Portal وRoute Optimizer وTracking Portal وDriver App وWMS وFleet System وHelpdesk وERP Finance، وبالأصفر نظام قديم أو ضعيف مثل Dispatch System وFuel cards site، وبالبرتقالي Excel أو عمل يدوي مثل Quotation وOutbound Loading وTariffs، وبالأحمر تكرار مثل Customer Relationship بنظامي CRM A + CRM B وNotifications بثلاث بوابات SMS، وبالرمادي فجوة بلا نظام في Returns Handling — كل لون يأتي من سجل التطبيقات، لذلك تتحدث الخريطة عندما يتحدث السجل

وفي الخريطة أعلاه لاحظ التالي:

التكرار Redundancy: قدرة «علاقات العملاء» يخدمها نظامان، CRM A الذي اشترته المبيعات وCRM B الذي تستخدمه خدمة العملاء، وقدرة «الإشعارات» تمر عبر ثلاث بوابات SMS لأن كل فريق تعاقد مع مزود مختلف، وهذا يعني تكلفة مكررة وبيانات عملاء متعارضة.
الفجوة Gap: قدرة «المرتجعات Returns Handling» لا يخدمها أي نظام، وتدار بمكالمات ورسائل، وهي فجوة قد تكون مقبولة إذا كانت المرتجعات قليلة، وقد تكون أولوية إذا كانت الشركة تتوسع في التجارة الإلكترونية.
الأنظمة الخفية Shadow IT: التسعير وعروض الأسعار في ملفات Excel، وهذا ليس خطأ دائماً، ولكنه يعني أن قدرة مهمة تعتمد على ملف واحد على جهاز موظف واحد، بلا نسخ احتياطية ولا صلاحيات.
نظام واحد يخدم قدرات كثيرة: نظام المستودعات WMS يغطي ثلاث قدرات، وهذا جيد، ولكنه يعني أن إيقافه يؤثر على المستودعات كلها، فيحتاج خطة استمرارية أقوى.

والمصفوفة التي تبنى منها هذه الخريطة بسيطة، فكل صف قدرة وكل عمود نظام، والجدول التالي جزء منها:

القدرة (المستوى الثاني)	CRM A	CRM B	Helpdesk	Tracking Portal	Driver App	Excel
علاقات العملاء Customer Relationship	✔	✔
الاستفسارات والشكاوى Inquiries		✔	✔
تتبع الشحنات Shipment Tracking				✔	✔
إثبات التسليم Proof of Delivery					✔
عروض الأسعار Quotation	✔					✔
المرتجعات Returns Handling

والصف الذي فيه أكثر من علامة يحتاج سؤالاً: هل النظامان يغطيان أجزاء مختلفة من القدرة، أم يتكرران فعلاً؟ والصف الفارغ فجوة، والعمود الذي فيه علامة واحدة فقط ونظامه مكلف يحتاج سؤالاً آخر: هل يستحق هذا النظام تكلفته؟

نموذج TIME: تقييم كل نظام

بعد أن تعرف أين التكرار والفجوات، تحتاج طريقة موحدة لتقييم كل نظام، وأشهر طريقة في إدارة المحافظ هي نموذج TIME، وهو اختصار لأربعة قرارات: التحمل Tolerate والاستثمار Invest والترحيل Migrate والإلغاء Eliminate. والنموذج ينسب عادة إلى شركة الأبحاث Gartner، ولكن أبحاثها الأصلية متاحة للمشتركين فقط، ولم نجد صفحة عامة منها تشرحه، لذلك نشرحه هنا كما يستخدمه الممارسون، ولا ننقل عنه أرقاماً أو تعريفات بعينها.

والفكرة أن تقيم كل نظام على محورين: القيمة للأعمال Business Value، أي مدى أهمية ما يقدمه النظام ومدى ملاءمة وظائفه لحاجة المستخدمين، والحالة التقنية Technical Fit، أي مدى صحة النظام من الداخل: هل هو مدعوم، وآمن، وسهل التكامل، ومعقول التكلفة في التشغيل. ومن تقاطع المحورين تظهر أربعة مربعات كما في الصورة التالية:

مصفوفة اثنين في اثنين. المحور الأفقي القيمة للأعمال وتزيد يساراً، والمحور الرأسي الحالة التقنية وتتحسن إلى الأعلى. في الأعلى يساراً INVEST طوره ووسعه وفيه Tracking Portal وERP Finance وDriver App وCRM A. في الأعلى يميناً TOLERATE أبقه كما هو بأقل تكلفة وفيه Intranet وRoom booking. في الأسفل يساراً MIGRATE انقل قيمته إلى منصة أفضل وفيه Dispatch System. في الأسفل يميناً ELIMINATE أوقفه وانقل بياناته وفيه HR (legacy) وCRM B — كل نظام نقطة على المصفوفة، والمربع يقترح القرار الأولي فقط

الاستثمار Invest (قيمة عالية وحالة تقنية جيدة): هذه أنظمتك الأساسية، فتطورها وتوسعها، وتنقل إليها وظائف الأنظمة المكررة. وفي المثال اختارت الشركة CRM A ليكون النظام الوحيد لعلاقات العملاء.
التحمل Tolerate (قيمة منخفضة وحالة تقنية جيدة): النظام يعمل ولا يسبب مشكلة، ولكنه لا يستحق استثماراً، فتبقيه كما هو بأقل تكلفة صيانة، مثل نظام حجز القاعات.
الترحيل Migrate (قيمة عالية وحالة تقنية سيئة): ما يقدمه النظام مهم، ولكن النظام نفسه قديم أو غير مدعوم أو مكلف، فتنقل قيمته إلى منصة أفضل، إما بإعادة بنائه أو باستبداله أو بنقله إلى نظام موجود. وفي المثال نظام توزيع الشحنات Dispatch System مبني بإطار قديم ولا يعرف كوده إلا موظف واحد.
الإلغاء Eliminate (قيمة منخفضة وحالة تقنية سيئة): توقفه بعد نقل بياناته ووظائفه المفيدة، مثل CRM B ونظام HR القديم الذي يستبدل.

والسؤال الذي يفسد التقييم دائماً هو: من يعطي الدرجات؟ والحل أن تكتب المعايير قبل التقييم، وأن يعطي درجة القيمة مالك الأعمال، ودرجة الحالة التقنية الفريق التقني، ثم تراجعهما معاً. وفيما يلي معايير نقترحها بمقياس من 1 إلى 5، وهي مثال يمكنك تعديله:

المحور	المعيار	السؤال
القيمة للأعمال	الأهمية Criticality	ماذا يحدث إذا توقف النظام يوماً كاملاً؟
	الملاءمة الوظيفية Functional Fit	هل يغطي حاجة المستخدمين دون ملفات Excel وحلول جانبية؟
	الاستخدام	كم مستخدماً يعتمد عليه، وكم مرة؟
	التوافق مع الإستراتيجية	هل يخدم قدرة تريد المؤسسة أن تكبرها؟
الحالة التقنية	الدعم Supportability	هل الإصدار مدعوم؟ وهل يوجد في الفريق أو عند المورد من يعرفه؟
	الأمن Security	هل تصله التحديثات الأمنية؟ وكم ملاحظة مفتوحة عليه من آخر اختبار اختراق؟
	التكامل Integration	هل له واجهة API موثقة، أم تكاملاته ملفات واستعلامات مباشرة؟
	تكلفة التشغيل	ما تكلفة الترخيص والسيرفرات والدعم مقارنة بالبدائل؟
	الاستقرار	كم عطلاً أثر على المستخدمين في السنة الماضية؟

ومتوسط كل محور يضع النظام في مربعه، فإذا كان متوسط القيمة 3 أو أكثر فهو في نصف القيمة العالية، وإذا كان متوسط الحالة التقنية 3 أو أكثر فهو في نصف الحالة الجيدة، وهذا الحد اختيار منا للتبسيط، والمهم أن تستخدم نفس الحد لكل الأنظمة.

من التقييم إلى القرار: ترشيد المحفظة

المربع يقترح اتجاهاً، ولكنه لا يكفي وحده لاتخاذ القرار، فالترشيد Application Rationalization هو تحويل هذا الاتجاه إلى قرار محدد لكل نظام، ومن أشهر هذه القرارات ما يلي:

الإبقاء Retain: يبقى كما هو، وغالباً لأنظمة التحمل.
الدمج Consolidate: نظامان لنفس القدرة يصبحان نظاماً واحداً، وهو القرار الأكثر توفيراً عادة.
الاستبدال Replace: بنظام جاهز أو خدمة سحابية أو نظام مفتوح المصدر، وقد ناقشنا معايير هذا الاختيار في مقال الاستضافة الذاتية كخيار إستراتيجي.
إعادة البناء Rebuild أو التحديث Modernize: عندما تكون القدرة مميزة للمؤسسة ولا يوجد نظام جاهز يغطيها.
الإيقاف Retire: مع أرشفة البيانات حسب متطلبات الحفظ.

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

في اليمين منطقة BEFORE فيها CRM A للمبيعات Sales وCRM B لخدمة العملاء Customer Care، ومكتوب عميل واحد له سجلان وتقرير المبيعات لا يطابق الشكاوى ورخصتان وعقدا دعم، و7 integrations to maintain. في الوسط ست خطوات مرقمة: 1 Pick the target اختر النظام الهدف بمعايير مكتوبة، 2 Map the data وحد تعريف العميل وطابق الحقول، 3 Migrate and dedupe رحل البيانات وأزل التكرار، 4 Move integrations انقل التكاملات واحداً واحداً، 5 Run in parallel شغل الاثنين فترة قصيرة وقارن، 6 Decommission أوقف CRM B وأرشف بياناته واسحب الصلاحيات. وفي اليسار منطقة AFTER فيها CRM A وسجل واحد لكل عميل — الخطوة السادسة هي التي ينساها الناس، والنظام الذي لم يوقف فعلاً ما زال أصلاً يحتاج حماية

وفي الخطوات أعلاه لاحظ التالي:

الخطوة 2 أصعب من الخطوة 3، فالنظامان لا يتفقان غالباً على تعريف «العميل»، فأحدهما يحفظ الشركة والآخر يحفظ الشخص، وتوحيد التعريف قرار أعمال وليس قراراً تقنياً.
الخطوة 4 تعتمد على سجل التكاملات، وإذا لم يكن لديك سجل فستكتشف التكامل الثامن بعد الإيقاف، عندما يتوقف تقرير لم يكن أحد يعرف أنه يقرأ من CRM B.
الخطوة 6 تعني إيقاف السيرفر، وأرشفة البيانات بحسب تصنيفها ومدة حفظها، وسحب حسابات المستخدمين وحسابات التكامل، وإلغاء الترخيص، وتحديث سجل التطبيقات، والسبب أن السيرفر المنسي الذي لا يحدثه أحد هدف سهل للمخترق.

جدول جاهز لسجل المحفظة

الجدول التالي هو الأعمدة التي نقترحها لسجل المحفظة مع ستة أنظمة من المثال، والقيم كلها افتراضية:

النظام	القدرات	المالك	الاستضافة	انتهاء العقد	القيمة	الحالة التقنية	TIME	القرار
Tracking Portal	Shipment Tracking	Customer Care	On-prem VM	لا يوجد (داخلي)	4.5	4.0	Invest	إضافة تنبيهات التأخير
Dispatch System	Dispatch	Operations	On-prem VM	لا يوجد (داخلي)	4.8	1.8	Migrate	إعادة بناء خلال سنتين
CRM A	Customer Relationship، Quotation	Sales	SaaS	2027-06	4.0	3.6	Invest	النظام الهدف للدمج
CRM B	Customer Relationship، Inquiries	Customer Care	On-prem VM	2026-12	2.2	2.0	Eliminate	دمج في CRM A قبل انتهاء العقد
HR (legacy)	Human Capital	HR	On-prem VM	2027-03	2.5	1.5	Eliminate	استبدال بنظام جديد
Room booking	Facilities	Admin	SaaS	2027-01	1.8	4.2	Tolerate	تجديد سنوي دون تطوير

ونفس الجدول بصيغة CSV بأعمدة أكثر، يمكنك نسخه وحفظه كملف portfolio.csv ثم فتحه في Excel أو استيراده في قاعدة بيانات بواجهة جداول:

app_id,name,business_owner,technical_owner,capabilities_l2,criticality,users,hosting,data_classification,integrations,licence,annual_cost_sar,contract_end,tech_stack,support_status,business_value,technical_fit,time,decision,next_review
APP-001,Tracking Portal,Customer Care,Web Team,Shipment Tracking,High,25000,On-prem VM,Restricted,4,In-house,0,,ASP.NET Core 8 + PostgreSQL,Supported,4.5,4.0,Invest,Add delay alerts,2027-04
APP-002,Dispatch System,Operations,Ops IT,Dispatch,High,120,On-prem VM,Restricted,6,In-house,0,,.NET Framework 4.x + SQL Server,One developer knows it,4.8,1.8,Migrate,Rebuild within two years,2027-01
APP-003,CRM A,Sales,Business Apps,Customer Relationship;Quotation,Medium,60,SaaS,Confidential,3,Subscription,90000,2027-06,Vendor SaaS,Supported,4.0,3.6,Invest,Target for consolidation,2027-04
APP-004,CRM B,Customer Care,Business Apps,Customer Relationship;Inquiries,Medium,40,On-prem VM,Confidential,7,Perpetual + support,45000,2026-12,PHP 7.4 + MySQL 5.7,End of life,2.2,2.0,Eliminate,Merge into CRM A before contract end,2026-11
APP-005,HR (legacy),HR,Corporate IT,Human Capital,High,900,On-prem VM,Confidential,6,Perpetual + support,70000,2027-03,Java 8 + Oracle,Vendor support ending,2.5,1.5,Eliminate,Replace with new HR system,2026-12
APP-006,Room booking,Admin,Corporate IT,Facilities,Low,300,SaaS,Internal,0,Subscription,8000,2027-01,Vendor SaaS,Supported,1.8,4.2,Tolerate,Renew yearly without changes,2027-01

في الجدول أعلاه لاحظ التالي:

العمود capabilities_l2 يربط النظام بأسماء القدرات من الخريطة نفسها، وإذا كتبت اسماً غير موجود في الخريطة فإما أن الخريطة ناقصة وإما أن الاسم خطأ.
العمود next_review يمنع أن يصبح الجدول صورة ثابتة، فكل نظام له موعد مراجعة، والأنظمة التي ستنتهي عقودها قريباً تراجع أولاً.
العمودان business_value وtechnical_fit متوسطا المعايير في القسم السابق، واحفظ تفاصيل الدرجات في ورقة منفصلة حتى يعرف من يقرأ لماذا حصل النظام على درجته.
الإصدارات القديمة في tech_stack مثل PHP 7.4 وMySQL 5.7 أمثلة على أنظمة انتهى دعمها، وهي التي يجب أن تظهر في تقرير المخاطر قبل أن تظهر في تقرير الاختراق.

أدوات مفتوحة المصدر تساعدك

في البداية يكفيك جدول مشترك، ولكن عندما يزيد عدد الأنظمة والعلاقات تحتاج أداة تحفظ العلاقات وتولد منها الرسوم، وفيما يلي ثلاثة خيارات مفتوحة المصدر تحققنا من مواقعها ورخصها:

قاعدة بيانات بواجهة جداول مثل NocoDB

إذا كان فريقك صغيراً، فأسرع طريقة لتحويل ملف Excel إلى سجل حقيقي هي قاعدة بيانات بواجهة جداول، مثل NocoDB الذي شرحنا تثبيته، فتستورد ملف CSV أعلاه، وتجعل عمود القدرات رابطاً إلى جدول القدرات، وتعطي كل مالك صلاحية تعديل أنظمته فقط.

نقاط القوة: سهل لكل الموظفين، ويحفظ تاريخ التعديلات، وله واجهة API تقرأ منها أنظمة أخرى.
نقاط الضعف: لا يعرف شيئاً عن معمارية المؤسسة، فلا توجد فيه خريطة قدرات جاهزة ولا رسوم ArchiMate، وكل تقرير تبنيه بنفسك.

أداة Archi للنمذجة بلغة ArchiMate

Archi أداة مجانية مفتوحة المصدر برخصة MIT كما في مستودعها، وآخر إصدار 5.10.0 يدعم ArchiMate 3.2، وفيها عناصر القدرة Capability والتطبيق Application Component وعلاقاتها، فترسم بها خريطة القدرات وعرض ربط التطبيقات بالقدرات، وقد شرحنا اللغة نفسها في مقال معمارية المؤسسة.

نقاط القوة: أداة نمذجة معروفة يستخدمها كثير من المعماريين، وتعمل على أجهزة مختلفة، وتحفظ النموذج كملف واحد يمكن وضعه في Git.
نقاط الضعف: أداة سطح مكتب للمعماري وليست سجلاً يحدثه مالكو الأنظمة، وحقول المحفظة مثل التكلفة وتاريخ العقد تضاف كخصائص Properties يدوياً.

مشروع Essential

The Essential Project مجموعة أدوات لمعمارية المؤسسة، ونسختها المفتوحة Essential Open Source متاحة مجاناً بحسب صفحة الترخيص تحت رخصة GPL الإصدار 3 أو ما بعده، أو رخصة AGPL الإصدار 3 بحسب الإصدار، دون دعم مدفوع. وتذكر صفحة المقارنة الرسمية أن النسخة المفتوحة تقوم على نسخة معدلة من أداة Protege، وأن فيها نفس النموذج Meta Model وأغلب العروض، بينما واجهات REST API والمحررات التي تعتمد عليها موجودة في النسختين السحابية وDocker المدفوعتين.

نقاط القوة: نموذج جاهز يغطي القدرات والتطبيقات والتقنية وعلاقاتها، وعروض جاهزة لربط التطبيقات بالقدرات.
نقاط الضعف: إدخال البيانات في النسخة المفتوحة عبر واجهة Java وليس الويب، وبعض الميزات المهمة في النسخ المدفوعة فقط، وتحتاج وقتاً لفهم نموذجها.

وقد تجد في المقالات القديمة اسم iteraplan كأداة مفتوحة المصدر لإدارة المحافظ، ولكننا لم نجد له موقعاً رسمياً يعمل عند كتابة هذا المقال، لذلك لا ننصح بالبدء به. ولم نجرب هذه الأدوات في بيئة إنتاج، والمقارنة أعلاه مبنية على مواقعها الرسمية، فإذا قررت أداة منها فابدأ بتجربة على نسخة من سجلك الحقيقي قبل أن تنقل إليها كل شيء.

أخطاء شائعة

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

تدريب عملي

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

الخلاصة

وصلنا لنهاية الموضوع، وأهم ما فيه:

القدرة تجيب عن «ماذا تفعل المؤسسة» وتبقى ثابتة، والإجراء والإدارة والنظام تتغير، لذلك تقاس الأنظمة على القدرات.
الخريطة تبنى بالمستويين الأول والثاني أولاً، والمستوى الثالث فقط حيث يوجد قرار، والقدرات إدارية ومحورية وداعمة كما في النموذج المرجعي الوطني.
إدارة المحفظة تعني سجلاً لكل نظام بمالكه وقدراته وبياناته وتكاملاته وعقده، وهذا السجل نفسه يخدم جرد الأصول في ضوابط الأمن السيبراني.
ربط التطبيقات بالقدرات يكشف التكرار والفجوات وملفات Excel التي تدير قدرات مهمة.
نموذج TIME يضع كل نظام في واحد من أربعة مربعات حسب القيمة للأعمال والحالة التقنية، والقرار النهائي يحتاج معه العقد والتكاملات وتصنيف البيانات وقدرة الفريق.
الإيقاف خطوة كاملة: أرشفة وسحب صلاحيات وإلغاء ترخيص وتحديث السجل.

وفي المقال التالي نرى كيف تطلب هيئة الحكومة الرقمية هذه الممارسة من الجهات الحكومية، وكيف ترتبط بضوابط الهيئة الوطنية للأمن السيبراني:

دليلمعمارية المؤسسة EA في الجهات الحكومية السعوديةما الذي تطلبه هيئة الحكومة الرقمية من الجهات في البنية المؤسسية بالنص، وكيف يقاس، وأين يلتقي مع ضوابط الأمن السيبراني.

دليلمعمارية المؤسسة Enterprise Architecture ببساطةعندما تملك المؤسسة عشرات الأنظمة لا يعرف أحد ماذا يتوقف إذا أوقفت أحدها، وهنا يأتي دور معمارية المؤسسة وأطرها المعروفة.

دليلNocoDB: جداول على طريقة Airtable على سيرفرككيف تنقل جداول فريقك من Excel أو Airtable إلى NocoDB على سيرفرك، فتبقى البيانات عندك ويعمل عليها الجميع من المتصفح.

دليلالتصميم والمعمارية: أربعة مستويات لنشاط واحدما الفرق بين تصميم البرمجيات ومعماريتها وتصميم الأنظمة ومعمارية المؤسسة، ومن يقرر في كل مستوى وكم يعيش قراره.

سجل التحديثات

أكتوبر 2026: كتابة المقال، ومراجعة الدليل الاسترشادي لتطبيق المنهجية الوطنية للبنية المؤسسية (مارس 2026) بنسختيه العربية والإنجليزية، وصفحة تحميل Archi 5.10.0، وصفحتي الترخيص والمقارنة في The Essential Project.