يجب أن تظل الاستشارات والهندسة على اتصال لأن التحول يعتمد على السياق. يجب على الأشخاص الذين يقومون بتشخيص مشكلة العمل أن يفهموا البنية، ويجب على الأشخاص الذين يقومون ببناء النظام أن يفهموا نموذج التشغيل. عندما يتم تسليم الاستراتيجية للتنفيذ، تفقد القرارات سياقها. عندما تعمل الهندسة بدون استراتيجية، يمكن للفرق تقديم أنظمة صحيحة تقنيًا لا تغير نتائج الأعمال. تم إنشاء Hive Vault Arc حول الاعتقاد المعاكس: يجب أن تتحرك الاستشارات الإستراتيجية وهندسة الذكاء الاصطناعي والبرمجيات والسحابة والعمليات المُدارة في حلقة واحدة مسؤولة.
مشكلة التسليم
يقسم نموذج التحول المشترك العمل إلى مراحل مملوكة لفرق مختلفة. يقوم المستشار بتشخيص الحالة ويترك سطح السفينة. تتلقى وكالة البرمجيات نطاقًا وتبني ما تم كتابته. ترث العمليات النظام بعد الإطلاق وتكتشف حالات الحافة التي لم يتم تصميمها مطلقًا في الخطة.
هذا ليس انتقادًا للمستشارين أو الوكالات كأشخاص. إنها مشكلة هيكلية. يمكن لكل فريق القيام بدوره بشكل احترافي مع ترك العميل يحمل عبء ربط كل شيء. كلما زاد عدد عمليات التسليم، كلما زاد الحفاظ على السياق من خلال المستندات والاجتماعات والافتراضات والذاكرة.
في العمل التحويلي الحقيقي، هذا السياق هو العمل. لماذا يوجد سير العمل. ما هو الاستثناء المهم. أي قسم سوف يقاوم التغيير. ما هو حقل البيانات الحساس سياسيًا؟ ما هي القيادة المترية التي تهتم بها بالفعل؟ من السهل فقدان هذه التفاصيل عندما يتم التعامل مع التشخيص والهندسة المعمارية والبناء والعمليات كعوالم منفصلة.
ما الذي يضيع بين الإستراتيجية والتنفيذ
- قيد العمل الأصلي الذي جعل المشروع ضروريًا.
- سبب أهمية الميزة لنموذج التشغيل.
- تم سماع حالات الحافة أثناء الاكتشاف ولكن لم تتم كتابتها بوضوح في النطاق.
- القيد التنظيمي: حقوق الموافقة، أو قدرة الفريق، أو الحوافز، أو مخاطر التبني.
- مقياس النجاح الحقيقي وراء العمل.
- مسؤولية التشغيل بعد الإطلاق.
- منطق خريطة الطريق المستقبلية الذي يشرح سبب أهمية بعض الخيارات أكثر من غيرها.
الإستراتيجية بدون تسليم تصبح مجموعة. الهندسة بدون استراتيجية تبني الشيء الخطأ بشكل جميل.- منظور Hive Vault Arc
استراتيجية الاحتياجات الهندسية
الكود الجيد لا يكفي. قرارات التصميم هي قرارات عمل لأنها تقرر كيفية عمل الفرق، والبيانات التي سيتم الوثوق بها، والعمليات التي يمكن توسيع نطاقها، وأين ستظهر التكلفة المستقبلية. يمكن لنموذج البيانات إما توضيح الملكية أو تشفير الارتباك. يمكن أن تدعم واجهة المستخدم التبني أو تدفع الموظفين بهدوء إلى جداول البيانات والقنوات الجانبية WhatsApp.
تحمل قرارات البنية التحتية أيضًا عواقب تجارية. تؤثر الموثوقية والأمان والتكلفة وعمق التكامل وإمكانية الملاحظة على ما إذا كان النظام يصبح جزءًا من العمليات اليومية أو يظل مشروعًا هشًا. تجعل أنظمة الذكاء الاصطناعي هذا الأمر أكثر أهمية لأن المطالبات والنماذج وسير العمل وقواعد التصعيد البشري تحتاج إلى الملكية بعد الإطلاق.
تحتاج الفرق الهندسية إلى فهم منطق التشغيل، وليس فقط قائمة الميزات. وإلا فقد يقومون بشحن نظام يلبي النطاق ولكنه يفتقد عملية التحويل.
الاستراتيجية تحتاج إلى هندسة
يجب أن تحترم الإستراتيجية الواقع التقني. إن خريطة الطريق التي تتجاهل جودة البيانات وعمليات التكامل والأمان واعتماد المستخدم والأداء والعمليات ليست خطة تحويل. إنها نية.
إن أفضل عمل استراتيجي يعتمد على معرفة التسليم. فهو يفهم ما هي التبعيات التي ستؤدي إلى إبطاء المشروع، وما هو النظام الذي لا يمكن استبداله على الفور، وما هو سير العمل الذي يجب تبسيطه قبل أتمتته، وما هي القدرة التي يجب بناؤها الآن لأن المراحل المستقبلية ستعتمد عليها.
ولهذا السبب تعمل Hive Vault Arc كشريك في تحويل التكنولوجيا بدلاً من كونها شركة استشارية لتقديم المشورة فقط أو فريق برمجيات البناء فقط. يجب أن يتم تشكيل الخطة من قبل الأشخاص الذين يفهمون ما يتطلبه الأمر لجعل النظام حقيقيًا.
حلقة ARC
ARC هو نموذج التسليم العام لـ Hive Vault Arc: التقييم وإعادة الهندسة والقيادة. إنها ليست تسلسلاً للإدارات. إنه فريق واحد يتحرك عبر ثلاثة أنماط من المسؤولية.
تقييم
التقييم يعني التشخيص: سير عمل الأعمال، ونموذج التشغيل، والهندسة المعمارية، والبيانات، والمخاطر، والقيود، وخريطة الطريق. الإخراج ليس مجرد توصية. إنه فهم مشترك لما يجب أن يتغير ولماذا.
إعادة الهندسة
تعني إعادة الهندسة بناء طبقة الذكاء الاصطناعي والبرمجيات والسحابة والتكامل والعملية التي تدعم نموذج التشغيل المستهدف. ويظل التسليم مرتبطًا بالتشخيص الأصلي، وبالتالي فإن خيارات التنفيذ تخدم نتائج الأعمال.
القيادة
الأمر يعني العمليات المُدارة بعد الإطلاق: المراقبة والصيانة وضبط سير العمل وإعداد التقارير والتكرار. هذا هو المكان الذي يصبح فيه التحول حقيقة إنتاجية بدلاً من مشروع ينتهي عند النشر.
ما الذي يجب أن يبحث عنه العملاء
- هل يفهم الشريك سير العمل في العمل، وليس فقط البرامج المطلوبة؟
- هل يستطيع الشريك شرح الهندسة المعمارية من الناحية التجارية؟
- هل سيظل الأشخاص الذين يقومون بنطاق المشروع مشاركين أثناء التسليم؟
- هل هناك خطة عملياتية بعد الإطلاق؟
- هل تم تحديد المقاييس قبل التنفيذ؟
- هل الملكية واضحة عندما ينكسر شيء ما؟
يجب أن يكون الشريك الجاد قادرًا على التنقل بين استشارة اللغة والواقع الهندسي دون فقدان الخيط. ويجب عليهم فهم القيود التي يواجهها المشتري، وسير عمل المستخدم، وبنية النظام، ومسؤوليات التشغيل التي تستمر بعد بدء التشغيل.
إغلاق وجهة نظر
إن المستقبل ملك للشركات التي يمكنها أن تفكر وتتحرك في نفس الحلقة. تم إنشاء H.V.A حول هذا الاعتقاد: تقديم المشورة والبناء والتشغيل ومواصلة التعلم من النظام بعد تشغيله.
لا يفشل التحول فقط بسبب ضعف الأفكار أو ضعف الكود. يفشل عندما ينقطع السياق بين الفرق. يكون العمل أقوى عندما يظل التشخيص والهندسة المعمارية والتسليم والعمليات متصلة حتى يعمل النظام فعليًا في الإنتاج.
الأسئلة التي يطرحها القادة قبل الذكاء الاصطناعي
لماذا تفشل مشاريع التحول عند التسليم؟
غالبًا ما تفقد عمليات التسليم سياق العمل وراء القرارات الفنية. عندما يتم فصل الاكتشاف والهندسة المعمارية والتسليم والعمليات، قد تقوم الفرق بتحسين الجزء الخاص بها بينما تتغير نتائج التشغيل الإجمالية.
ماذا يعني ربط الاستشارات والهندسية؟
ويعني ذلك أن الأشخاص الذين يشكلون الإستراتيجية يفهمون المسار الفني، ويفهم الأشخاص الذين يبنون النظام سير عمل الأعمال. يتم التعامل مع النطاق والهندسة المعمارية والبيانات وتجربة المستخدم والعمليات كنظام واحد متصل.
كيف يقلل ARC من انحراف التنفيذ؟
تحتفظ ARC بنفس الحلقة المسؤولة عبر التقييم وإعادة الهندسة والقيادة. يقوم التشخيص الأصلي بإبلاغ عملية التسليم، وتقوم عمليات الإنتاج بتغذية التعلم مرة أخرى في النظام بعد الإطلاق.
ما الذي يجب أن تسأله الشركة قبل التعاقد مع شريك التحول؟
اسأل ما إذا كان الشريك يفهم سير العمل، ويمكنه شرح التصميم من الناحية التجارية، وسيظل مشاركًا أثناء التسليم، ويحدد المقاييس قبل التنفيذ، ولديه خطة عمليات واضحة بعد الإطلاق.
