موازنة قائمة المشاريع
استخدام السحابة هو جهد لإدارة قائمة المشاريع، تم إخفاءه بذكاء على أنه تنفيذ تقني. مثل أي تمرين لإدارة قائمة المشاريع، فإن موازنة قائمة المشاريع أمر بالغ الأهمية. على المستوى الاستراتيجي، يعني هذا موازنة الترحيل والابتكار والتجريب لتحقيق أقصى استفادة من السحابة. عندما يميل جهد استخدام السحابة بعيدا جدا في اتجاه واحد، يجد التعقيد طريقه إلى جهود الاعتماد. ستوجه هذه المقالة القارئ من خلال نهج لتحقيق التوازن في قائمة المشاريع.
توسيع النطاق العام
إن تحقيق التوازن بين حافظة المشاريع أمر استراتيجي في طبيعته. وعلى هذا النحو، فإن النهج المتبع في هذه المادة هو نهج استراتيجي بنفس القدر. لاستئناف الاستراتيجية في القرارات المستندة إلى البيانات، تفترض هذه المقالة أن القارئ قد قيم الملكية الرقمية الحالية أو بدأ هذه العملية. والهدف من هذا النهج هو المساعدة في تقييم أحمال العمل لضمان التوازن السليم عبر الحافظة من خلال الأسئلة النوعية وتحسين الحافظة.
توثيق نتائج الأعمال
قبل موازنة قائمة المشاريع، من المهم توثيق نتائج الأعمال ومشاركتها التي تقود جهود ترحيل السحابة. يمكن أن يساعد الجدول التالي في توثيق نتائج الأعمال المطلوبة ومشاركتها. من المهم ملاحظة أن معظم الشركات تسعى إلى تحقيق العديد من النتائج في كل مرة. أهمية هذا التمرين هي توضيح النتائج التي ترتبط بشكل مباشر بجهد الترحيل السحابي:
| النتيجة | يتم قياسه بواسطة | الهدف | الإطار الزمني | أولوية هذا الجهد |
|---|---|---|---|---|
| تقليل تكاليف تكنولوجيا المعلومات | ميزانية مركز البيانات | تقليل بقيمة 2 مليون دولار أمريكي | 12 شهر | #1 |
| خروج مركز البيانات | الخروج من مراكز البيانات | مركزان للبيانات | 6 أشهر | #2 |
| زيادة سرعة الأعمال | تحسين الوقت في السوق | تقليل وقت النشر بمقدار ستة أشهر | سنتان | #3 |
| تحسين تجربة العملاء | رضا العملاء (CSAT) | تحسين بنسبة 10٪ | 12 شهر | #4 |
هام
الجدول أعلاه هو مثال خيالي ولا ينبغي استخدامه لتعيين الأولويات. في كثير من الحالات، يمكن اعتبار هذا الجدول مضادا من خلال وضع وفورات في التكاليف أعلى من تجارب العملاء.
يمكن أن يمثل الجدول أعلاه بدقة أولويات فريق استراتيجية السحابة وفريق اعتماد السحابة. نظرا للقيود القصيرة الأجل، يركز هذا الفريق بشكل أكبر على تقليل تكلفة تكنولوجيا المعلومات وتحديد أولويات خروج مركز البيانات كوسيلة لتحقيق التخفيضات المطلوبة في تكلفة تكنولوجيا المعلومات. ومع ذلك، من خلال توثيق الأولويات المتنافسة في هذا الجدول، يتم تمكين فريق اعتماد السحابة لمساعدة فريق استراتيجية السحابة على تحديد الفرص لمواءمة تنفيذ استراتيجية قائمة المشاريع الشاملة بشكل أفضل.
التحرك بسرعة مع الحفاظ على التوازن
تشير الإرشادات المتعلقة بالترشيد المتزايد للملكية الرقمية إلى نهج يبدأ فيه الترشيد بوضع غير متوازن. يجب على فريق استراتيجية السحابة تقييم كل حمل عمل للتوافق مع نهج إعادة الاستضافة. ويقترح هذا النهج لأنه يسمح بالتقييم السريع لملكية رقمية معقدة استنادا إلى البيانات الكمية. يسمح إجراء مثل هذا الافتراض الأولي لفريق اعتماد السحابة بالمشاركة بسرعة، ما يقلل من الوقت في نتائج الأعمال. ومع ذلك، وكما ورد في تلك المادة، ستوفر المسائل النوعية التوازن اللازم في الحافظة. توثق هذه المقالة عملية إنشاء الرصيد الموعود.
أهمية قرارات الغروب والتقاعد
يفتقد الجدول الموجود في قسم توثيق نتائج الأعمال أعلاه إلى نتيجة رئيسية من شأنها أن تدعم الهدف الأول لخفض تكاليف تكنولوجيا المعلومات. عندما تصنف تخفيضات تكاليف تكنولوجيا المعلومات في أي مكان في قائمة نتائج الأعمال، من المهم مراعاة إمكانية غروب أو إيقاف أحمال العمل. في بعض السيناريوهات، يمكن أن تأتي وفورات التكلفة من عدم ترحيل أحمال العمل التي لا تضمن استثمارا قصير الأجل. أبلغ بعض العملاء عن وفورات في التكاليف تزيد عن 20٪ من إجمالي تخفيضات التكلفة عن طريق إيقاف أحمال العمل غير المستغلة بشكل كامل.
لتحقيق التوازن بين قائمة المشاريع وعكس قرارات الغروب والإيقاف بشكل أفضل، يتم تشجيع فريق استراتيجية السحابة وفريق اعتماد السحابة على طرح الأسئلة التالية لكل حمل عمل أثناء مراحل التقييم والترحيل:
- هل تم استخدام حمل العمل من قبل المستخدمين النهائيين في الأشهر الستة الماضية؟
- هل نسبة استخدام الشبكة للمستخدم النهائي متسقة أو متزايدة؟
- هل سيكون حمل العمل هذا مطلوبا من قبل الشركة بعد 12 شهرا من الآن؟
إذا كانت الإجابة على أي من هذه الأسئلة هي "لا"، فقد يكون حمل العمل مرشحا للتقاعد. إذا تم تأكيد إمكانية الإيقاف مع مالك التطبيق، فقد لا يكون من المنطقي ترحيل حمل العمل. هذا يطالب ببعض أسئلة التأهيل:
- هل يمكن إنشاء خطة إيقاف أو خطة غروب الشمس لحمل العمل هذا؟
- هل يمكن إيقاف حمل العمل هذا قبل إنهاء مركز البيانات؟
إذا كانت الإجابة على كلا السؤالين هي "نعم"، فسيكون من الحكمة التفكير في عدم ترحيل حمل العمل. ومن شأن هذا النهج أن يساعد في تحقيق أهداف خفض التكاليف والخروج من مركز البيانات.
إذا كانت الإجابة على أي سؤال هي "لا"، فقد يكون من الحكمة وضع خطة لاستضافة حمل العمل حتى يمكن إيقافه. يمكن أن تتضمن هذه الخطة نقل الأصول إلى مركز بيانات أقل تكلفة أو مركز بيانات بديل، والذي من شأنه أيضا تحقيق أهداف خفض التكاليف والخروج من مركز بيانات واحد.
اعتماد تغييرات العملية
تتطلب موازنة حافظة المشاريع تحليلا نوعيا إضافيا خلال مرحلة "اعتماد"، مما سيساعد على دفع ترشيد بسيط للمحفظة.
استنادا إلى البيانات الواردة من الجدول في قسم توثيق نتائج الأعمال أعلاه، هناك احتمال أن تميل قائمة المشاريع بعيدا جدا إلى نموذج تنفيذ يركز على الترحيل. إذا كانت تجربة العملاء ذات أولوية قصوى، فإن محفظة الابتكار الثقيلة ستكون أكثر احتمالا. لا يعد ذلك صحيحا أو خاطئا، ولكن الميل بعيدا جدا في اتجاه واحد يؤدي عادة إلى تقليل العائدات، وإضافة تعقيد غير ضروري، وزيادة وقت التنفيذ المتعلق بجهود اعتماد السحابة.
لتقليل التعقيد، يجب اتباع نهج تقليدي لترشيد قائمة المشاريع، ولكن في نموذج تكراري. توضح الخطوات التالية نموذجا نوعيا لمثل هذا النهج:
- يحتفظ فريق استراتيجية السحابة بتراكم أولويات لأحمال العمل التي سيتم ترحيلها.
- يستضيف فريق استراتيجية السحابة وفريق اعتماد السحابة اجتماعا لتخطيط الإصدار قبل إكمال كل إصدار.
- في اجتماع تخطيط الإصدار، تتفق الفرق على أعلى 5 إلى 10 أحمال عمل في التراكمات ذات الأولوية.
- خارج اجتماع تخطيط الإصدار، يطرح فريق اعتماد السحابة الأسئلة التالية لمالكي التطبيقات والخبراء المعنيين:
- هل يمكن استبدال هذا التطبيق بما يعادل النظام الأساسي كخدمة (PaaS)؟
- هل هذا التطبيق تطبيق تابع لجهة خارجية؟
- هل تمت الموافقة على الميزانية للاستثمار في التطوير المستمر للتطبيق في الأشهر ال 12 القادمة؟
- هل سيؤدي التطوير الإضافي لهذا التطبيق إلى تحسين تجربة العملاء؟ هل تريد إنشاء مفاضلة تنافسية؟ هل تدفع إيرادات إضافية للأعمال؟
- هل ستساهم البيانات داخل حمل العمل هذا في ابتكار انتقال البيانات من الخادم المتعلق بذكاء الأعمال أو التعلم الآلي أو إنترنت الأشياء أو التقنيات ذات الصلة؟
- هل حمل العمل متوافق مع الأنظمة الأساسية للتطبيقات الحديثة مثل Azure App Service؟
- ومن شأن الإجابات على الأسئلة المذكورة أعلاه وأي تحليل نوعي آخر مطلوب أن يؤثر بعد ذلك على التعديلات على التراكمات ذات الأولوية. قد تتضمن هذه التعديلات ما يلي:
- إذا كان من الممكن استبدال حمل العمل بحل PaaS، فقد تتم إزالته من تراكم الترحيل بالكامل. كحد أدنى، ستتم إضافة العناية الواجبة الإضافية لاتخاذ قرار بين إعادة الاستضافة والاستبدال كمهمة، ما يقلل مؤقتا من أولوية حمل العمل هذا من تراكم الترحيل.
- إذا كان حمل العمل يخضع (أو يجب أن يكون) للتقدم في التطوير، فقد يتناسب بشكل أفضل مع نموذج إعادة بناء التعليمات البرمجية. نظرا لأن الابتكار والترحيل يتطلبان مهارات تقنية مختلفة، يجب إدارة التطبيقات التي تتوافق مع نهج إعادة بناء التعليمات البرمجية من خلال تراكم الابتكار بدلا من تراكم الترحيل.
- إذا كان حمل العمل جزءا من ابتكار انتقال البيانات من الخادم، فقد يكون من المنطقي إعادة بناء التعليمات البرمجية للنظام الأساسي للبيانات، ولكن اترك طبقات التطبيق كمرشح لإعادة استضافة. غالبا ما يمكن معالجة إعادة بناء التعليمات البرمجية الثانوية للنظام الأساسي لبيانات حمل العمل في الترحيل أو تراكم الابتكار. قد تؤدي نتيجة الترشيد هذه إلى عناصر عمل أكثر تفصيلا في التراكم، ولكن بخلاف ذلك لا يوجد تغيير في الأولويات.
- إذا لم يكن حمل العمل استراتيجيا ولكنه متوافق مع الأنظمة الأساسية الحديثة لاستضافة التطبيقات المستندة إلى السحابة، فقد يكون من الحكمة إجراء إعادة بناء التعليمات البرمجية الثانوية على التطبيق لتوزيعه كتطبيق حديث. يمكن أن يساهم هذا في الوفورات الإجمالية من خلال تقليل متطلبات ترخيص IaaS ونظام التشغيل الإجمالية لترحيل السحابة.
- إذا كان حمل العمل تطبيقا تابعا لجهة خارجية ولم يتم تخطيط بيانات حمل العمل هذا للاستخدام في ابتكار انتقال البيانات من الخادم، فقد يكون من الأفضل تركه كخيار إعادة استضافة في التراكم.
لا ينبغي أن تكون هذه الأسئلة هي مدى التحليل النوعي المكتمل لكل حمل عمل، ولكنها تساعد في توجيه محادثة حول معالجة تعقيد محفظة غير متوازنة.
تغييرات عملية الترحيل
أثناء الترحيل، يمكن أن يكون لأنشطة موازنة قائمة المشاريع تأثير سلبي على سرعة الترحيل (السرعة التي يتم بها ترحيل الأصول). ستتوسع الإرشادات التالية حول سبب وكيفية محاذاة العمل لتجنب الانقطاعات في جهود الترحيل.
يتطلب ترشيد قائمة المشاريع تنوع الجهد التقني. من المغري لفرق اعتماد السحابة أن تتطابق مع تنوع قائمة المشاريع هذا ضمن جهود الترحيل. يطلب أصحاب المصلحة في الأعمال فريق اعتماد سحابة واحد لمعالجة تراكم الترحيل بأكمله. ونادرا ما يكون هذا نهجا مستحسنا، وفي كثير من الحالات يمكن أن يكون ذلك مردودا عكسيا.
يجب تقسيم هذه الجهود المتنوعة عبر فريقين أو أكثر من فرق اعتماد السحابة. باستخدام نموذج من فريقين كمثال على وضع التنفيذ، الفريق 1 هو فريق الترحيل والفريق 2 هو فريق الابتكار. ولبذل جهود أكبر، يمكن تقسيم هذه الفرق بشكل أكبر لمعالجة نهج أخرى مثل جهود استبدال/PaaS أو إعادة بناء التعليمات البرمجية الثانوية. يوضح ما يلي المهارات والأدوار اللازمة لإعادة الاستضافة أو إعادة بناء التعليمات البرمجية أو إعادة بناء التعليمات البرمجية الثانوية:
إعادة استضافة: تتطلب إعادة الاستضافة من أعضاء الفريق تنفيذ تغييرات تركز على البنية الأساسية. بشكل عام، استخدم أداة مثل Azure Site Recovery لترحيل الأجهزة الظاهرية أو الأصول الأخرى إلى Azure. يتوافق هذا العمل بشكل جيد مع مسؤولي مراكز البيانات أو منفذي تكنولوجيا المعلومات. فريق الترحيل السحابي منظم بشكل جيد لتقديم هذا العمل على نطاق واسع. هذا هو أسرع نهج لترحيل الأصول الموجودة في معظم السيناريوهات.
إعادة بناء التعليمات البرمجية: تتطلب إعادة بناء التعليمات البرمجية من أعضاء الفريق تعديل التعليمات البرمجية المصدر أو تغيير بنية التطبيق أو اعتماد خدمات سحابية جديدة. بشكل عام، سيستخدم هذا الجهد أدوات التطوير مثل Visual Studio وأدوات البنية الأساسية لبرنامج ربط العمليات التجارية للتوزيع مثل Azure DevOps لإعادة توزيع التطبيقات المحدثة إلى Azure. يتوافق هذا العمل بشكل جيد مع أدوار تطوير التطبيقات أو أدوار تطوير البنية الأساسية لبرنامج ربط العمليات التجارية DevOps. فريق الابتكار السحابي هو الأفضل تنظيما لتقديم هذا العمل. قد يستغرق استبدال الأصول الحالية بأصول سحابية في هذا النهج وقتا أطول، ولكن يمكن للتطبيقات الاستفادة من الميزات الأصلية للسحابة.
إعادة بناء التعليمات البرمجية الثانوية: يمكن تحديث بعض التطبيقات مع إعادة بناء التعليمات البرمجية الثانوية على مستوى البيانات أو التطبيق. يتطلب هذا العمل من أعضاء الفريق نشر البيانات إلى الأنظمة الأساسية للبيانات المستندة إلى السحابة أو إجراء تغييرات طفيفة في التكوين على التطبيق. قد يتطلب هذا دعما محدودا لخبراء موضوع تطوير البيانات أو التطبيقات. ومع ذلك، يشبه هذا العمل العمل الذي يقوم به منفذو تكنولوجيا المعلومات عند نشر تطبيقات الجهات الخارجية. يمكن أن يتوافق هذا العمل بسهولة مع فريق ترحيل السحابة أو فريق استراتيجية السحابة. في حين أن هذا الجهد ليس بنفس سرعة ترحيل إعادة الاستضافة تقريبا، فإنه يستغرق وقتا أقل للتنفيذ من جهود إعادة بناء التعليمات البرمجية.
أثناء الترحيل، يجب تقسيم الجهود بالطرق الثلاث المذكورة أعلاه وتنفيذها من قبل الفريق المناسب في التكرار المناسب. في حين أنه يجب عليك تنويع محفظة المشاريع، تأكد أيضا من أن الجهود تظل مركزة للغاية وفصلها.
الخطوات التالية
فهم كيف يمكن أن تؤثر قرارات السوق العالمية على رحلة التحول الخاصة بك.