لسنوات عديدة، قبلت العديد من الشركات قاعدة ضمنية: إذا كانت العملية لا تتناسب مع البرنامج المتاح، فيجب تكييف العملية مع البرنامج.
البديل - بناء التطبيق الخاص بك - يمكن أن يتضمن فريق تطوير، وبنية تحتية، وعمليات تكامل، وأشهر من العمل، وتكلفة صيانة يصعب تبريرها لاحتياجات معينة. فقط العمليات الإستراتيجية الكافية أو الشركات واسعة النطاق هي التي يمكنها أن تفكر في ذلك بشكل مريح.
هذا الاقتصاد يتغير.
تقضي الخدمات السحابية على جزء كبير من البنية التحتية الأولية. تسمح لك واجهات برمجة التطبيقات (APIs) بربط الإمكانات الموجودة. تحل الأنظمة الأساسية ذات التعليمات البرمجية المنخفضة والتي لا تحتوي على تعليمات برمجية طبقات معينة دون التطوير التقليدي. المكونات القابلة لإعادة الاستخدام تقلل من إعادة العمل. تعمل أدوات تطوير الذكاء الاصطناعي على تسريع البرمجة والتوثيق والاختبار والاستكشاف الفني. وتسمح الأتمتة بتنسيق الأنظمة دون بناء كل قطعة من الصفر.
أصبح البناء أكثر سهولة في الوصول إليه. ولا يزال تصميم النظام الصحيح هو الجزء الصعب.
والنتيجة ليست أن جميع الشركات يجب أن تطور برامجها الخاصة. والنتيجة أكثر إثارة للاهتمام: لقد تحركت الحدود بين الشراء والبناء. فالقضايا التي لم تكن تستدعي في السابق وجود أداة محددة تستحق الآن إعادة التقييم.
1. ما الذي يعنيه حقًا إنشاء مبنى يسهل الوصول إليه
لا يعني "إمكانية الوصول بشكل أكبر" أنه مجاني أو فوري أو لا يحتاج إلى صيانة. وهذا يعني أن العديد من العوائق التي ظهرت سابقًا معًا يمكن حلها اليوم كخدمات مستقلة.
البنية التحتية كخدمة
لم يعد التطبيق يحتاج بالضرورة إلى خوادم تم شراؤها، وشبكات تتم إدارتها يدويًا، وفريق مخصص لتشغيل كل مكون. يمكن استهلاك قواعد البيانات المُدارة والتخزين والمصادقة والنشر وقابلية المراقبة كخدمات.
قدرات واجهة برمجة التطبيقات
يمكن دمج المدفوعات أو المراسلة أو التوقيع أو رسم الخرائط أو الهوية أو نماذج الذكاء الاصطناعي أو المستندات أو الاتصالات دون إعادة بناء القدرة بالكامل داخليًا.
واجهات ومكونات قابلة لإعادة الاستخدام
تحتوي الجداول والنماذج ولوحات المعلومات والمصادقة والأذونات وأنماط التنقل على مكونات ناضجة. يمكن أن يركز العمل بشكل أكبر على منطق عمل محدد.
الأتمتة والتنسيق
ليست كل حاجة تتطلب تطبيقًا متجانسًا. يمكن أن يجمع التدفق بين إدارة علاقات العملاء (CRM) وتخطيط موارد المؤسسات (ERP) وقاعدة البيانات والبريد الإلكتروني والنماذج والقواعد من خلال طبقة تنسيق.
تطبيق الذكاء الاصطناعي على التنمية
يمكن أن تساعد الأدوات الحالية في استكشاف قاعدة التعليمات البرمجية، أو إنشاء الهياكل، أو اقتراح الاختبارات، أو التوثيق، أو إعادة البناء، أو إنشاء الإصدارات الأولى. إنها تزيد من قدرة الفريق، على الرغم من أنها لا تحل محل التصميم أو المراجعة أو المعرفة بالعملية.
كل قطعة من هذه القطع تقلل نوعًا واحدًا من الاحتكاك. وهي مجتمعة تغير أي المشاريع يمكن أن تكون معقولة اقتصاديا.
2. في السابق، كانت تكلفة التخصيص تجبرنا على قبول التنازلات
تخلق البرامج القياسية قيمة لأنها توزع تكلفة التطوير على العديد من العملاء. وفي المقابل، يوافق كل عميل على نموذج البيانات والتدفق والأولويات المصممة لسوق واسعة.
لا يزال هذا التبادل رائعًا للمشاكل المشتركة. لا تحتاج المحاسبة أو البريد الإلكتروني أو مكالمات الفيديو أو التخزين إلى إعادة اختراعها في معظم الشركات.
تظهر المشكلة عندما تكون العملية التي تميز العمل محاصرة في أدوات عامة.
مثال افتراضي: تقوم شركة الصيانة الصناعية بتنسيق عمليات التفتيش وقطع الغيار والفنيين والتوثيق الفوتوغرافي والحوادث والشهادات. يمكنك محاولة تمثيل كل شيء ضمن نظام إدارة علاقات العملاء (CRM) العام، وذلك بإضافة أوراق متوازية ومجلدات ورسائل داخلية. تعمل كل أداة، لكن النظام بأكمله يتطلب إعادة بناء السياق يدويًا.
قبل بضع سنوات، ربما لم يكن إنشاء الأداة التشغيلية الخاصة بك يبرر الاستثمار. قد يكون من المعقول اليوم بناء طبقة محددة تربط الأنظمة الحالية وتضع نماذج دقيقة للأصول والزيارات والحادث والأجزاء والفنيين والحالة.
الفرصة ليست لاستبدال كل شيء. إنه قيد الإنشاء القطعة المفقودة.
3. عادةً ما تكون البرامج المخصصة الجديدة عبارة عن تكوين، وليس إنشاء من الصفر
الصورة الكلاسيكية للتطوير المخصص هي قيام فريق بإنشاء كل وحدة من صفحة فارغة. في العديد من المشاريع اليوم، تبدو الهندسة المعمارية الصحيحة أشبه بالتكوين:
- مزود للهوية؛
- قاعدة بيانات مُدارة؛
- واجهة أمامية محددة؛
- وإدارة علاقات العملاء (CRM) التي لا تزال مصدرًا للحقيقة التجارية؛
- ونظام تخطيط موارد المؤسسات (ERP) الذي يستمر في إدارة الفواتير؛
- الأتمتة لمزامنة الأحداث؛
- واجهات برمجة التطبيقات للقدرات الخارجية؛
- الذكاء الاصطناعي فقط في المهام التي توفر المرونة المعرفية.
تركز قيمة التطوير الذاتي على القواعد والواجهات والقرارات الخاصة بالشركة.
وهذا يقلل من نقيضين: لا إجبار الشركة بأكملها على منتج عام، ولا بناء القدرات داخليًا التي يحلها السوق بالفعل بشكل جيد.
4. لم يعد القرار يقتصر على البناء مقابل الشراء: بل الشراء والبناء والتأليف
يمكن للقرار التكنولوجي الناضج أن يقسم المشكلة إلى طبقات.
شراء
قم بشراء أو استخدام البرامج الجاهزة عندما تكون العملية شائعة، والتمايز منخفض، والمنتج الحالي يحل مشكلة 80-90٪ ذات الصلة بشكل جيد دون خلق احتكاك خطير.
بناء
يتم البناء عندما يكون المنطق محددًا، أو أن العملية تخلق ميزة، أو أن البرامج القياسية تفرض حلولاً باهظة الثمن، أو أن التجربة تحتاج إلى أن تتناسب تمامًا مع التدفق.
يؤلف
فهو يجمع بين الخدمات الحالية وطبقته الخاصة عندما يتم تحويل بعض القدرات إلى سلعة ولكن التنسيق بينها يكون محددًا.
السؤال المفيد لم يعد "هل نشتري أو نطور نظامًا بأكمله؟" ويصبح الأمر "ما هي الأجزاء التي يجب أن تكون قياسية وما هو الجزء الذي يستحق أن يكون من نصيبنا؟"
5. الواجهة الجميلة لا تحول النموذج الأولي إلى نظام أعمال
إن تقليل الاحتكاك أثناء البناء له أثر جانبي: فمن الأسهل أيضًا إنتاج برامج تبدو جاهزة قبل أن تكون كذلك.
يمكن للنموذج الأولي أن يُظهر واجهة وتدفقًا سعيدًا. تحتاج العملية الحقيقية أيضًا إلى:
- الهوية والأذونات؛
- مصادر الحقيقة؛
- التحقق من صحة البيانات؛
- الهجرات والإصدارات.
- معالجة الاستثناء؛
- السجلات وإمكانية الملاحظة؛
- النسخ الاحتياطية والاسترداد؛
- الأمن؛
- عمليات تكامل موثوقة؛
- إدارة التغيير؛
- الملكية والدعم.
إمكانية الوصول إلى التطوير تقلل من تكلفة إنتاج الإصدار الأول. ولا يلغي العمل على تحويلها إلى قدرة تشغيلية مستدامة.
6. يتحول الجزء الصعب من "هل يمكننا بنائه؟" نحو "ماذا يجب أن نبني؟"
عندما كانت البرمجة باهظة الثمن، ماتت العديد من الأفكار قبل أن تحتاج إلى قرار جيد بشأن المنتج. إذا كان بناء الأداة يكلف الكثير، فقد بحثت الشركة عن حل بديل.
عندما يصبح البناء أرخص، ينشأ خطر مختلف: إنشاء عدد كبير جدًا من الأدوات.
يمكن لفريق تطوير تطبيق لحل مشكلة محلية دون معرفة أن قسمًا آخر يحتاج إلى نفس البيانات. يمكن لآخر إنشاء لوحة معلومات عن طريق تكرار مصدر موجود. أضافت مبادرة ثالثة قاعدة جديدة لأنها كانت أسرع من دمج القاعدة السابقة.
وتنتهي الشركة ببرامج أكثر تخصيصًا وهندسة معمارية أسوأ.
القدرة على البناء بشكل أسرع تزيد من قيمة المعايير المعمارية، ولا تقلل منها.
7. إن التكلفة الأكثر خطورة ليست التنمية دائما: بل هي الديون التشغيلية
يمكن أن تكون الأداة رخيصة الإنشاء ومكلفة الامتلاك إذا كانت تقدم:
- مصدر آخر للحقيقة؛
- هوية مستخدم أخرى؛
- منطق الأذونات الأخرى؛
- التزامنات الهشة؛
- الاعتماد على شخص يفهم الكود؛
- البيانات دون سياسة الاحتفاظ؛
- التدفق الحرج دون الاسترداد اليدوي.
ولهذا السبب يجب أن يشمل التحليل الاقتصادي التكلفة الإجمالية للملكية وليس فقط ساعات البناء. في كيفية حساب عائد الاستثمار للتنفيذ نوضح كيفية الفصل بين الاستثمار الأولي والتكلفة المتكررة والقيمة التي يمكن التقاطها.
8. الشركات لديها بالفعل "برامج مخصصة"؛ غالبًا ما يتم إخفاؤه في العمليات اليدوية
ورقة تحتوي على الصيغ ووحدات الماكرو وأعمدة محددة ومجموعة من القوالب والرسائل المحددة مسبقًا وشخص يربط الأنظمة يدويًا تشكل تطبيقًا موزعًا عمليًا.
لقد صممت الشركة بالفعل منطقًا محددًا. فقط هذا المنطق يعيش في الناس والوثائق.
هذا يغير تحديد الفرص. ليست هناك حاجة للبحث عن "أفكار التطبيقات". يكفي ملاحظة مكان وجود القواعد الخاصة التي يتم تنفيذها يدويًا:
- يحتفظ الفريق بأوراق متوازية لأن النظام الرئيسي لا يمثل العملية.
- يقوم الشخص بنسخ البيانات بين تطبيقات متعددة.
- يتم إعادة بناء الحالة الحقيقية للقضية عن طريق السؤال.
- هناك قوالب مختلفة وفقا للعديد من الشروط.
- يتطلب القرار التكراري استشارة مصادر متعددة.
- يعمل المستخدمون حول البرنامج وليس داخله.
- تعد العملية الخاصة بك جزءًا مهمًا من ميزة العميل أو تجربته.
9. الإطار ProjectCore: قياسي → محدد → قابل للتكامل → قابل للتشغيل
قبل أن تقرر البناء، اسأل نفسك أربعة أسئلة.
1. أي جزء هو المعيار؟
تحديد القدرات التي لا تميز الشركة ولديها بالفعل حلول ناضجة. عادةً ما يؤدي بنائها مرة أخرى إلى إضافة تكلفة دون فائدة.
2. ما هو الجزء المحدد حقًا؟
فهو يحدد القواعد أو الأشياء أو الحالات أو القرارات أو الخبرة التي لا يتم تمثيلها بشكل جيد بواسطة البرامج الموجودة. يجب أن تكون الخصوصية ملموسة، وليست تفضيلاً جمالياً.
3. هل يمكن دمجها دون إنشاء جزيرة أخرى؟
حدد النظام الذي سيظل هو المرجع للعميل أو الطلب أو الفاتورة أو المستخدم أو المستند. تصميم التكاملات قبل ضرب القواعد.
4. هل يمكن تشغيله بعد الإطلاق؟
يحدد الصيانة والأخطاء والأذونات والنسخ الاحتياطية والتغييرات وإمكانية الملاحظة والمسؤولية. إن الأداة التي لا تحتوي على عملية هي مشروع وليست قدرة.
10. معيار بسيط: التخصيص حيث توجد معلومات أو قرار محدد
يوفر التخصيص قيمة أكبر عندما يكون لدى الشركة معرفتها الخاصة التي لا يمكن للمنتج العام أن يتحملها.
يمكن أن يكون:
- طريقة محددة لتسجيل الفرص؛
- قواعد التخطيط الخاصة؛
- تسلسل الموافقة الذاتية؛
- نموذج تشغيل يصعب تمثيله في البرامج الأفقية؛
- تجربة عملاء مختلفة؛
- مجموعة من البيانات الداخلية التي توجه القرارات.
بدلاً من ذلك، فإن التخصيص من أجل التخصيص - إنشاء التقويم أو التخزين أو المراسلة الخاصة بك دون سبب - يستخدم السعة التي يمكن تخصيصها للجزء المميز.
11. الذكاء الاصطناعي داخل البرمجيات: طبقة، وليس النظام بأكمله
يعمل الذكاء الاصطناعي على توسيع ما يمكن أن تفعله الأداة الداخلية بالمعلومات غير المنظمة. يمكنه تصنيف الرسائل أو استخراج حقول المستندات أو تلخيص التواريخ أو اقتراح الإجراءات أو المساعدة في البحث عن المعلومات.
لكن تطبيق المؤسسة لا يزال يحتاج إلى منطق حتمي حوله: أي مستخدم يمكنه رؤية الحالة، وما هي الحالة الصالحة، وما هو الحد الذي لا يمكن تجاوزه، وما هو السجل الذي يمثل مصدر الحقيقة، وما هو الإجراء الذي يحتاج إلى موافقة.
ولهذا السبب تجمع الهندسة المعمارية الحديثة بين الذكاء الاصطناعي والبرامج التقليدية بدلاً من محاولة جعل النموذج يحل محل جميع القواعد.
12. آثار الدرجة الأولى والثانية لجعل التنمية أرخص
الطلب الأول: يمكن للشركة اختبار أداة معينة باستثمار أولي أقل.
الأمر الإيجابي الثاني: يمكنك التكرار بشكل أقرب إلى المستخدمين الحقيقيين، والتخلص من الحلول البديلة وإنشاء أنظمة أكثر توافقًا مع العملية.
الترتيب الثاني السلبي: يمكن أيضًا أن تتكاثر البرامج الداخلية التي لا تحتوي على بنية مشتركة.
التأثير الثالث: إذا قام كل قسم ببناء الحل الخاص به بسرعة، فستزداد الحاجة إلى معايير الهوية والبيانات والتكامل والملكية.
إن إضفاء الطابع الديمقراطي على التنمية لا يلغي الحكم الفني. وهذا يجعل الأمر أكثر أهمية لأن هناك المزيد من الجهات الفاعلة القادرة على الإبداع.
13. مقاييس لمعرفة ما إذا كانت أداتك الخاصة تستحق الوجود
تجنب قياس النجاح بعدد الميزات. ربط البرنامج بالعملية.
- الوقت البشري لكل حالة.
- إجمالي وقت الدورة.
- عدد الأدوات اللازمة لإكمال المهمة.
- إدخالات يدوية مكررة.
- معدل الخطأ أو إعادة العمل.
- حان الوقت لدمج موظف جديد في هذه العملية.
- نسبة الحالات التي يمكن ملاحظة حالتها دون سؤال.
- تكلفة التشغيل لكل وحدة.
- توافر ومعدل الحوادث للأداة.
- إجمالي تكاليف التشغيل والصيانة الشهرية.
يمكن أن يكون للتطبيق الذي يقلل النقرات ولكنه يضيف الصيانة أو الأخطاء أو التجزئة عوائد سلبية حتى لو كان المستخدمون يفضلون الواجهة.
14. متى لا تبني؟
فقط لأنه ممكن لا يعني أنه مناسب.
- تتغير العملية كل أسبوع ولا أحد يعرف ما هي القاعدة الصحيحة.
- تم حل المشكلة جيدًا عن طريق تكوين أداة موجودة.
- لا يوجد مالك للعملية.
- البيانات الهامة ليس لها مصدر للحقيقة.
- الحجم أو التأثير لا يبرر الحفاظ على قدرة أخرى.
- ولا يمكن للشركة تشغيل النظام بعد ذلك.
- الدافع الرئيسي هو "أن يكون لدينا منصة خاصة بنا".
في كثير من الأحيان تكون المهمة الصحيحة هي توحيد الخطوات أو دمجها أو إزالتها أولاً. البناء على الغموض يحول المناقشة التنظيمية إلى كود.
15. كيفية تجربة أداة مخصصة دون الالتزام بالمنصة الكاملة
تسمح التكلفة المنخفضة للنماذج الأولية بتغيير تسلسل القرار.
- حدد احتكاكًا له تأثير قابل للقياس.
- إعادة بناء العملية الفعلية والاستثناءات.
- يحدد الكائن المركزي: النظام، الحالة، المشروع، الأصول، الفرصة.
- قرر أي الأنظمة الحالية ستستمر في كونها مصادر للحقيقة.
- قم ببناء القسم الذي يحل الفرضية الرئيسية فقط.
- حاول مع مجموعة صغيرة وحالات حقيقية.
- يقيس خط الأساس والنتيجة.
- تعرف على الاستثناءات التي تظهر.
- قرر ما إذا كنت تريد التوسع أو التكامل بشكل أفضل أو التخلي.
يتجنب هذا التسلسل تصميم المنتج لمدة اثني عشر شهرًا قبل معرفة ما إذا كان التدخل سيغير العملية.
16. الأصل ليس بالضرورة الرمز
يمكن إعادة كتابة الكود. ما يصعب تكراره عادة هو تحويل المعرفة التشغيلية إلى نظام متماسك: نموذج البيانات، والقواعد، والاستثناءات، والأذونات، والتكاملات، والقرارات.
يمكن للشركة التي تفهم عمليتها بعمق أن تغير التكنولوجيا مع الحفاظ على هذا التصميم. شركة لديها الكثير من التعليمات البرمجية ولكن القواعد الضمنية لا تزال تعتمد على من قام ببنائها.
يتكون النضج من فصل منطق الأعمال عن الأداة المحددة التي تنفذه اليوم.
17. إن الفرصة المتاحة للشركات المتوسطة الحجم مثيرة للاهتمام بشكل خاص
يمكن للمنظمات الكبيرة تاريخياً تمويل التنمية الداخلية. يمكن للشركات الصغيرة تكييف عملياتها مع SaaS القياسي لأن تعقيدها كان أقل. بين الاثنين هناك منطقة تكون فيها العمليات محددة بالفعل، ولكن قبل ذلك كان من الصعب تبرير تكلفة النظام الأساسي الخاص.
إن تقليل الاحتكاك الفني يجعل هذا الشريط يستحق إعادة التقييم. ليس لاستبدال المجموعة بأكملها، ولكن لبناء طبقات تشغيلية حيث تبدأ البرامج الأفقية في توليد الكثير من التنسيق اليدوي.
18. البرامج المخصصة لا تعني برامج معزولة
يجب أن تقلل الأداة الاحتكارية من التجزئة وليس زيادتها. يجب عليك التواصل مع المصادر التي تدعم الشركة بالفعل وتوضيح البيانات المسؤولة في كل مكان.
وهذا أيضًا منطق صفحتنا برامج مخصصة: يكون تطبيق محدد منطقيًا عندما يتكامل مع العمليات والأنظمة الحقيقية، وليس عندما يصبح جزيرة أخرى.
19. أسئلة القرار للإدارة
- ما هي المشكلة التشغيلية القابلة للقياس التي تحلها؟
- ما هو الجزء الذي يمكن شراؤه بالفعل؟
- أي جزء محدد حقًا؟
- ما هي البيانات التي ستكون مصدرا للحقيقة؟
- ما هو التكامل الحاسم؟
- ماذا يحدث عندما تفشل؟
- من سيحافظ على القواعد والأذونات؟
- ما هي تكلفة عدم القيام بأي شيء؟
- ما هو المقياس الذي يبرر التوسع؟
- هل يمكننا اختبار الفرضية بنسخة أصغر؟
الاستنتاج
إن العوائق التي تحول دون بناء برامج المؤسسات آخذة في الانخفاض. يؤدي ذلك إلى توسيع خيارات التصميم للمؤسسات التي كان عليها في السابق الاختيار بين منتج عام ومشروع تطوير كبير جدًا.
لكن الوفرة الجديدة من الأدوات لا تجعل الهندسة المعمارية أقل أهمية. فهو يسهل بناء الحل الصحيح وأيضا بناء عشرة حلول خاطئة.
تتمثل الفرصة في الاستفادة من السحابة وواجهات برمجة التطبيقات والأتمتة والمكونات والذكاء الاصطناعي لتركيز التطوير الخاص بالضبط حيث توجد المعرفة أو العمليات التفاضلية.
أصبح البناء أكثر سهولة في الوصول إليه. ولا يزال تصميم النظام الصحيح هو الجزء الصعب.
ProjectCore يصمم أدوات محددة عندما تبرر العملية ذلك، وليس لإضافة البرامج. تستطيع أن ترى التركيز على كيف نعمل.