السؤال الأبدي حول شراء أو بناء برنامجك (جيمس موناغان)

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

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

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

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

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

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

ولا يتعين عليهم حتى أن يكون لديهم أطراف ذات صلة مشتركة حتى تكون المنفعة واضحة. صناعات مماثلة وعملاء عملاء مماثلين، ماذا لو كان البائعون/الموردون العملاء هم أيضًا عملاء أنفسهم؟ هذا يقودنا إلى كيفية معالجة المعلومات
ولماذا تحتاج المؤسسات إلى النظر عبر المؤسسة عند التفكير في البرامج هذه الأيام. إذا نظرت إلى المشكلة بشكل منفصل وتعاملت معها على هذا النحو، من خلال وضع الميزانيات وإصدار طلبات تقديم العروض لكل مكون من مكونات إدارة علاقات العملاء (CRM)، وFincrime، والتواصل مع العملاء (CRM)، فسوف ينتهي بك الأمر إلى حل المشكلة.
مع إنفاق المزيد من الموارد في محاولة دمج كل شيء معًا أكثر من أي ادخار محتمل كان مأمولًا في البداية. قم الآن بتطبيق ذلك على كل منطقة أو مجال عمل قد يحصل على ميزانيات وإشراف منفصل، وسينتهي بك الأمر بـ 8 إصدارات
من نفس البرنامج الذي يحتاج إلى التكامل مع نفسه بسبب التخصيص الكبير لكل منطقة مما يلغي أي وفورات الحجم التي يمكن تحقيقها.

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

كل هذا جيد وجيد من وجهة نظر الأعمال. والعمل معروف وما يجب القيام به. ولكن عندما نحاول أن نقرر ما إذا كان ينبغي علينا شراء البرنامج أو بنائه بأنفسنا، كيف يؤثر ذلك في الأمور؟ حسنًا لنفترض أن هناك مصادر متعددة
البيانات عبر أنظمة متعددة. من المتوقع أن يعتمد أي نظام حديث على واجهة برمجة التطبيقات (API) وأن يتمتع بقدرات منخفضة على التعليمات البرمجية/بدون تعليمات برمجية. افتراض معقول لبرامج أسرع ومرنة. يجب التعامل مع كل شيء هذه الأيام على أنه خدمة صغيرة يجب تجنبها
وحدات البرمجيات ذات الطراز القديم. يجب تثبيت البرامج واستخدامها لأنها أفضل البرامج المتوفرة والمثبتة مستقبليًا للتكيف مع التغيير حسب الحاجة. يتم ترسيخ عدد كبير جدًا من العروض ولا يتم الحفاظ عليها إلا لأنها صعبة للغاية وتستغرق وقتًا طويلاً
ليحل محل. يرجع معظم هذا إلى أن القواعد مشفرة بشكل صارم، وربما تكون متشابكة مع البيانات نفسها، ولا يتم دمج البيانات فحسب، بل يتم تكرارها عدة مرات لكل جزء منفصل من البرنامج في سلسلة المعلومات، وإذا حاولت استبدال جزء واحد، فإن
النظام بأكمله يمكن أن ينكسر. الكثير من عملية التفكير القديمة، إذا لم يتم كسرها فلا تقم بإصلاحها. ما نحتاجه حقًا هو أن تكون جميع هذه الأجزاء المكونة عبارة عن خدمات صغيرة، تأخذ البيانات المطلوبة، وتطبق القواعد الآلية أو مدخلات/مراجعات المستخدم و
وتمريره إلى الخدمة الصغيرة التالية. لا ينبغي تخزين البيانات في أكثر من مكان واحد. قد يتم توحيدها ولكن لا يمكن نسخها خارج النسخ الاحتياطية. يجب أن تصل أنظمة CRM وOnboarding وKYC والتواصل مع العملاء وما إلى ذلك إلى البيانات التي تحتاجها فقط وليس ذلك
تكون مستودعات للبيانات نفسها إلا إذا اخترت واحدة لتكون كذلك. إن تكرار نفس البيانات عبر مواقع متعددة والقواعد التي تحكمها هو ممارسة غير مجدية حيث أن كل نظام إضافي يضاف سوف يضاعف التعقيدات المعنية.

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

لذا، عندما ننظر الآن إلى السؤال القديم المتمثل في شراء البرامج أو إنشائها، فإننا نعلم أننا بحاجة إلى تنسيق متعدد القنوات، وأتمتة العمليات حيثما أمكن ذلك، ومنطق القواعد المرنة، وإدارة الحالة للرقابة وقابلية التدقيق، والتعليمات البرمجية المنخفضة وواجهة برمجة التطبيقات (API)، وملخص
طبقة بيانات ومحرك قواعد ذكي يمكنه الوراثة من طبقات منطقية مختلفة. سوق التكنولوجيا مليء بالمبتكرين الذين يرضون بكل سرور كل مشكلة متخصصة يمكن التفكير فيها، ولكن عند أي نقطة يصبح من المنطقي أن تكون "على الرف"
المنتجات التي تحتاج جميعها إلى تخصيصها ودمجها مع بعضها البعض بدلاً من بنائها بنفسك. يمكن أن تتيح لك الأنظمة الأساسية ذات التعليمات البرمجية المنخفضة توفير 80% من متطلباتك وتحتاج فقط إلى تكوين دلتا 20%. أفضل ما في العالمين هو المستوى المنخفض
منصة التعليمات البرمجية التي قام الآخرون أيضًا ببناء مكونات قابلة لإعادة الاستخدام من أجلها حتى تتمكن من الحصول على المنتجات "الجاهزة" كمسرّعات لأعمالك بينما تتمتع أيضًا بالقدرة على موظفيك أو الجهات الخارجية المعتمدة لبناء بقية المتطلبات المحددة
إلى مؤسستك. للشراء أو البناء؟ حقا ينبغي أن يكون على حد سواء.