اخبار

ما هو منطق العمل وأين يجب أن يعيش


لنتحدث عن منطق الأعمال.

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

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

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

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

الآن بعد أن عرفنا ما هو منطق العمل وما يمكن أن يقدمه للأعمال ، دعنا نسأل لماذا هو مهم ، ما هي أفضل الخيارات وأين يجب أن تعيش داخل المؤسسة.

لماذا يهم؟

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

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

ما هي الخيارات؟

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

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

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

أين تخزن منطق الأعمال؟

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

  • وثائق: لقد نجح وضع منطق الأعمال في المستندات لعقود ، ويرجع ذلك إلى حد كبير إلى عدم وجود خيارات أخرى. خلقت هذه الجمل والفقرات المرتبة بعناية حجة وقدمت أدلة وأقنع القراء. الحد الأدنى؟ إنها طريقة جيدة لإنشاء منطق الأعمال وتأسيسه ، لكنها ليست أداة لإدارة المؤسسة.
  • شفرة: إذا لم يكن الأمر كذلك في المستندات ، فلماذا لا نضع منطق الأعمال في الكود؟ يبدو معقولًا لأنه في مرحلة ما يتم تنفيذ منطق الأعمال في نهاية المطاف في أو بواسطة أجهزة الكمبيوتر التي تم توجيهها بطريقة ما من قبل لغات البرمجة. لكن منطق الأعمال لا يمكن أن يعيش في الكود لأنه لا يمكن الوصول إليه حقًا إلا للمبرمجين. لإدارة منطق الأعمال بشكل فعال ، يجب أن يكون قادة الأعمال قادرين على رؤيته على أنه معبر عنه ومشاركته علنًا. الحد الأدنى؟ يجب أن ينتهي النقاش: الكود مخصص للمبرمجين ؛ منطق العمل هو للأعمال التجارية.
  • لغة النمذجة الموحدة (UML): هذه أداة جيدة ، وفي المؤسسات الكبيرة ، فهي واحدة من تلك المجالات التي سيقضي فيها منطق الأعمال بعض الوقت. ومع ذلك ، هناك مشكلتان أساسيتان في UML. الأول هو قلة الكلمات. حيث يتخيل UML المخططات المعمارية للنظام في رسم تخطيطي ويكون أقرب إلى PowerPoint ، فهو في الحقيقة مجرد بديل جميل بدلاً من التفكير الفعلي / الملموس (المكتوب). ثانيًا ، يكره معظم مهندسي البرمجيات UML. لذا ، في حين أن تسليم منطق الأعمال للمبرمجين من خلال تضمينه في التعليمات البرمجية ليس حلاً مثاليًا ، فإن إبعادهم عن طريق تضمينه في قطعة أثرية يحتقرونها ليس خيارًا أيضًا. الحد الأدنى؟ UML مفيد وليس الخيار الأسوأ ، لكنه ليس الأفضل أيضًا.
  • قواعد بيانات: نعلم جميعًا أن منطق الأعمال موجود في قواعد البيانات ، تمامًا كما هو الحال في الأماكن الأخرى المذكورة أعلاه. في الواقع ، يمكن أن توجد الإجراءات المخزنة كنوع من التسوية بين قسمي “منطق biz في التعليمات البرمجية” و “منطق biz في قاعدة البيانات”. أثناء وجود الإجراءات المخزنة في قاعدة البيانات ، فهي في الواقع رمز. كحد أدنى ، لا يوجد شيء مكسور حول هذا الموضوع ليس بالفعل وظيفة للانهيار الأساسي لنظام RDBMS. بدلاً من ذلك ، تفاعل تفوق نموذج البيانات العلائقية وتسربه كتجريد ، وهي المشكلة مع كل شيء تقريبًا في إدارة البيانات. إن وضع منطق الأعمال في نظام مبني على التجريد الخاطئ هو السبب في أن وضع منطق الأعمال في قاعدة البيانات “” ليس هو الأسلوب الأفضل. الحد الأدنى؟ في حين أن النهج قد يكون مقبولًا ، فإن النموذج العلائقي معطل ، مما يعني أن التشوهات في منطق الأعمال ستزداد سوءًا مع مرور الوقت.

إذا أين يتركنا هذا؟

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

نظرًا لاتساع الرسوم البيانية للمعرفة الدلالية ، فإن تضمين منطق الأعمال هناك أمر منطقي نظرًا لإدراكه السياقي وإعادة استخدامه وعوامل أخرى.

الحقيقة هي أن منطق الأعمال ينتهي في أماكن عديدة. الشاغل الحقيقي هو كيف يجب أن يحدث ، من أين يجب أن يأتي وما هي دورة حياته. تعد المستندات والتعليمات البرمجية ومخططات UML ومكونات قاعدة البيانات معقولة تمامًا كأهداف تجميعية لمنطق العمل الذي ، كمنطق ، يتم التعبير عنه وإدارته وتخزينه في رسم بياني معرفي.

Navin Sharma هو نائب الرئيس للمنتجات في Stardog.

صانعي القرار

مرحبًا بك في مجتمع VentureBeat!

DataDecisionMakers هو المكان الذي يمكن للخبراء ، بما في ذلك الأشخاص الفنيون الذين يقومون بعمل البيانات ، مشاركة الأفكار والابتكارات المتعلقة بالبيانات.

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

يمكنك حتى التفكير في المساهمة بمقال خاص بك!

قراءة المزيد من DataDecisionMakers

اترك تعليقاً

لن يتم نشر عنوان بريدك الإلكتروني. الحقول الإلزامية مشار إليها بـ *

زر الذهاب إلى الأعلى