ما هو موضوع المقال؟

هذه مقالة عامة حول ماهية "أتمتة الميزانية" ، والمشكلات التي تتكون منها هذه المنطقة وما هي أدوات تكنولوجيا المعلومات المستخدمة فيها.



إذا كنت ترغب في فهم كيفية ترابط ذكاء الأعمال ، ومستودعات البيانات (DWH) ، وأنظمة أتمتة الميزانية (Cognos ، و Anaplan ، و 1C: Holding Management ، Bit.Finance) وكيف تختلف عن أنظمة معلومات الشركة الأخرى - فأنت هنا.



إذا كنت مهندسًا تقنيًا لم تعمل أبدًا في مجال تخطيط الأعمال ، فهذه المقالة مناسبة لك أيضًا.





أحذرك على الفور أنني حاولت كتابة المقال بأبسط لغة ممكنة حتى يكون مفهومًا للجميع.

لماذا قررت كتابته؟

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

1. ? ?
2. (PowerBI, Tableau, Qlik, Cognos, IBM Planning analytics, Anaplan, ., 1: ) ?
3. BI – ?

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



لذلك ، في المحاسبة ، يعمل المستند -> الجدول (التسجيل) -> مخطط التقرير على النحو الأمثل (والذي تم استخدامه قبل الأتمتة بوقت طويل ، والعودة إلى محاسبة العصور الوسطى).





الشكل: 1. مخطط المحاسبة "مستند -> تسجيل -> تقرير"





تم توسيع الخطط في البداية. لذلك ، من المناسب إدخالها بالضبط "من أعلى" (أي بنفس الأشكال التي يتم إنشاء التقارير بها).



لذلك ، عند محاولة بناء أتمتة الموازنة بالقياس مع المحاسبة التقليدية (الشكل 3) ، تواجه الشركات على الفور ثلاث مشكلات رئيسية.





الشكل: 3



المشكلة 1: إدارة القواعد . من غير الملائم والمكثف لليد العاملة إدارة قواعد تحويل البيانات (من أدنى مستويات المحاسبة إلى تنسيق الميزانية) ، المكتوبة في رمز التقرير.



المشكلة الثانية: سرعة "جمع الحقائق" . يتم عرض الخطط في التقارير بسرعة كبيرة (حيث تم تخزينها بالفعل في نموذج مكبر) ، ويتم حساب البيانات الفعلية ببطء شديد.



المشكلة 3: نماذج دخول الخطة... الشكل الأكثر ملاءمة لإدخال الخطط هو تقرير حقائق الخطة. لكن التقارير في نظم المعلومات عادة لا تسمح بإدخال البيانات.



لا تتعلق المسألتان الأوليان بالميزنة فحسب ، بل تمثلان بشكل عام أساس المجال الكامل لموضوع تخزين البيانات وتكامل البيانات و ETL.



المشكلة الثالثة هي مشكلة التخطيط المحددة. وهي ، في الواقع ، إحدى المشكلات المهمة لأنظمة تخطيط موارد المؤسسات كأدوات في الوقت الفعلي (مصممة ليس فقط للمحاسبة "بعد الوفاة" للأحداث التي حدثت ، ولكن للتخطيط والتحكم التشغيلي في الأعمال).

المشكلة 1: إدارة قواعد التحويل

في التين. 1-3 ، يتم توضيح جميع القواعد الخاصة بتحويل البيانات الفعلية (من أدنى مستوى محاسبي إلى مستويات التقارير العليا) مباشرة في رمز التقرير.



هذا سيء:

• لا يمكن إدارة القواعد دون تغيير الرمز ؛
• لا يمكن استخدامها إلا في هذا التقرير.
  مما يعني:

  – , , ,
  
  – - ,
  
  

تعقيد قواعد التحول

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





يمكنك أن تتخيل مقدار مشكلة الحفاظ على مثل هذا الرمز بالنسبة للمبرمجين ، إذا كان هناك عدة مئات من هذه المقالات ، يتم استخدامها في عشرات التقارير المختلفة ، ويمكن تعديل قواعد تحديدها في المحاسبة الإدارية كل 3-4 أشهر.

حل المشكلة 1: رسم الخرائط

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





الشكل: 4



هذا له ميزتان في وقت واحد:

• القواعد أسهل في الإدارة. يمكن جعلها تفاعلية وتهيئتها بدون رمز ، مما يعني أنه حتى المستخدمين العاديين يمكنهم في كثير من الأحيان القيام بذلك ؛
• يمكن استخدام قاعدة واحدة في تقارير مختلفة و / أو خوارزميات أخرى

هذا النهج ليس له عيوب كبيرة.



لكن تطوير أداة لرسم خرائط ملائمة لأحجام كبيرة من الأدلة ليس بالأمر السهل.

المشكلة الثانية: سرعة تحويل البيانات الفعلية

حل المشكلة 2: تخزين البيانات المحولة

من أجل عدم حساب بيانات التقرير "أثناء التنقل" ، يمكن تخزينها بالفعل في شكل موسع ومحول.



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



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





الشكل: خمسة

DWH

يرتبط مجال مستودع البيانات (DWH) بهذه المشكلة.



بشكل تقريبي ، DWH هو مكان (جدول أو ، في الممارسة العملية ، مجموعة من الجداول ذات الصلة) لتخزين البيانات المحسوبة الوسيطة (المجمعة أو المحولة بطريقة أخرى).



ما هي الايجابيات:

• سرعة قراءة البيانات. إذا كانت التقارير "تقرأ" بالفعل البيانات المحولة من الجدول ، فإنها تفعل ذلك بسرعة كبيرة.
• التحقق. عندما يتم تخزين البيانات مسبقًا في المستودع ، يكون من السهل التحقق منها.

سلبيات:

• صحة. في الواقع ، هذا الطرح نظري إلى حد ما (يتم ضمان الدقة القصوى على وجه التحديد عندما نأخذ البيانات من المصدر الأساسي للمعلومات).
  في الممارسة

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

عمليات ETL

يمكن استدعاء ETL أي عملية يتم فيها أخذ البيانات من مكان ما وتعديلها ثم تحميلها في مكان ما. هذا اختصار شائع لكلمة Extract و Transform و Load.



ولكن عادةً ما يتم استخدام هذا المصطلح على وجه التحديد في الحالات التي تتم فيها كتابة البيانات بعد التحويل في مكان ما للتخزين.



هذا النهج له مزايا:

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

لا يوجد سوى ناقص واحد:

• تعقيد التحكم في سلامة البيانات المحملة. قم ببناء عملية ETL لا تفقد البيانات ، وتكون شفافة بما فيه الكفاية ويمكن التحكم فيها - هذا ممكن ، لكن هذا يتطلب فريقًا عالي الكفاءة ومشاركة مستخدمين وتكاليف عمالة ملحوظة.

المشكلة 3: نموذج إدخال الميزانية

الحقيقة هي أنه في الشكل الكلاسيكي ، تعد التقارير في منتجات البرامج وسيلة لإخراج البيانات. لكن لا يمكنك إدخال البيانات فيها.





ولكن لوضع الميزانية للمخطط الكلاسيكي "نموذج الإدخال" (مستند) -> الجداول الداخلية -> نموذج الإخراج (تقرير) "غير مناسب.



على سبيل المثال ، قمنا في وقت من الأوقات بتطوير تقرير مشتريات شهري (كما في الشكل 2) ، والآن نبدأ التخطيط ، ويريد المدير المالي إدخال ميزانية المشتريات بنفس النموذج.



ما تبقى القيام به؟ يمكنك إنشاء نموذج إدخال خطة يبدو مشابهًا جدًا لهذا التقرير (كما هو موضح في الشكل 3).

حل المشكلة 3: نماذج الإدخال / الإخراج التفاعلية

الحل هو أيضا واضح: بدلا من "وثائق" المعتادة والتقارير "، يجب عليك إنشاء كائن من شأنها في وقت واحد و قراءة و إدخال البيانات.



بل من الأفضل أن يكون من الممكن أيضًا في هذا الكائن إجراء عمليات حسابية بين البيانات المدخلة و / أو القراءة - أي للعمل بالطريقة التي يسمح بها Excel لك بالعمل.



في هذه الحالة ، يمكن "إضافة" الخطط ، بعد إدخالها ، إلى نفس مستودع البيانات حيث توجد البيانات الفعلية (انظر الشكل).





الشكل: 6



لكن مثل هذه النماذج يصعب تنفيذها أكثر من التقارير العادية أو المستندات في أنظمة المحاسبة.



يمكن أن تكون درجة التفاعل مختلفة: من الأسهل تنفيذ النماذج المكونة مسبقًا ، والأكثر صعوبة - الديناميكية (حيث لا يكون عدد الأعمدة / الصفوف معروفًا مسبقًا ، ولكن أنواعها محددة مسبقًا). بل إنه من الأصعب السماح للمستخدم "بتدوير" البيانات ، وبناء نماذج جديدة وتعيين صيغ حساب عشوائية ، وتغيير هيكل التقارير.

حل المشكلة 4: المكعبات

هناك أداة أخرى تحل مشكلة غير مذكورة أعلاه.

الحقيقة هي أنه مع وجود كميات كبيرة من البيانات ، مع تفاعل عالٍ ومع صيغ معقدة ، فإن جداول SQL العلائقية العادية ، حيث من المعتاد تخزين البيانات من أنظمة تخطيط موارد المؤسسات ، لا توفر السرعة القصوى لمعالجة البيانات في الوقت الفعلي.



لحل هذه المشكلة ، يمكنك استخدام تخزين البيانات ليس في شكل جداول ، ولكن على الفور في شكل مكعبات.





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

أنواع منتجات البرامج في وضع الميزانية

لننظر الآن في أنواع تقنيات المعلومات التي تحل المشكلات المهمة في أتمتة الموازنة:

• أنظمة البيانات الأولية (أنظمة المحاسبة ، أنظمة تخطيط موارد المؤسسات)
• أدوات ETL
• مستودعات البيانات (العادية ومكعبات OLAP)
• أنظمة ذكاء الأعمال
• أنظمة EPM
• اكسل بالطبع

كل نوع من الأنظمة له وظيفة أساسية من الناحية النظرية (انظر الجدول):







ولكن في الواقع ، فإن الحدود غير واضحة قليلاً ، وغالبًا ما تعرف المنتجات "كيف" تفعل الأشياء ذات الصلة. تبدو الوظائف المتداخلة تقريبًا كما يلي:







هام: يرجى ملاحظة أن تداخل الوظائف لا يكون عادةً 100٪.



وهذا يعني أن الأداة التي تقدم وظائف إضافية لا تؤديها عادةً كأداة متخصصة منفصلة!

خريطة لأنواع البرامج في الميزانية

بشكل عام ، يمكن عرض تغطية المهام المختلفة لأتمتة الموازنة من خلال أنواع مختلفة من أنظمة المعلومات بشكل مرئي كما يلي:





الشكل. 7



الآن دعونا نفكر في بنية إعداد الميزانية التي تقدمها بعض منتجات البرامج الشائعة.

إعداد الموازنة في أنظمة تخطيط موارد المؤسسات

يتغير مفهوم تخطيط موارد المؤسسات بمرور الوقت ، ويتم دمج إمكانات جديدة في أنظمة تخطيط موارد المؤسسات.



في رأيي ، تتضمن وظيفة تخطيط موارد المؤسسات "الكلاسيكية" نظام محاسبة ؛ مصممي التقارير وظائف التحكم التشغيلي للخطط ، وبالطبع القدرات الأساسية لمدخلاتها.



يستبعد: القدرة على جمع البيانات من مصادر متعددة ؛ مكعبات البناء والتحليلات التفاعلية



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

1C: SCP

تقوم UPP بتنفيذ المخطط التالي ، ولكن ضمن قاعدة واحدة.





الشكل: 8. هيكل الميزانية في 1C: UPP



مزايا الميزنة في UPP:

• إن SCP شفاف للغاية وسهل التعديل. من السهل التحقق من البيانات الموجودة فيه ومن غير المكلف تطوير وظائف جديدة.

رسم الخرائط - في SCP على مستوى متوسط. هذه ليست علامة زائد أو ناقص. تحديد متوسط ​​كثافة العمالة.



عيوب الميزنة في SCP:

• عدم وجود أشكال تفاعلية للمدخلات والمخرجات. يتم إنشاء أي بيانات من خلال المستندات (إدخال الخطط ؛ الحصول على البيانات الفعلية المجمعة ؛ إجراء العمليات الحسابية) ، حيث لا يوجد تفاعل ولا يمكن أن يكون والقدرة على رؤية الصورة الكبيرة.
• عدم وجود واجهة ETL. يوجد تخطيط ، ولكن يتم تحميل البيانات الفعلية مباشرة من نموذج المستند ، وهو أمر غير مريح.
• المنصة القديمة. لا يمكنك استخدام تقنية 1C Managed Forms Technology ، التي تزود المستخدم بإمكانيات حديثة للتصفية / الفرز الشامل للقوائم والتقارير. هذا يحط من القدرات التحليلية للمستخدم.

بشكل عام ، في SCP ، يتم تنفيذ أتمتة الميزنة بشكل أكثر وضوحًا وفقًا لمبدأ المحاسبة العادية: لا يعمل المستخدم من الصورة العامة ، ولكن من المستندات الأولية (إدخال خطة ؛ تحميل حقيقة ؛ تقديرات) ، ويمكن رؤية الصورة العامة فقط في التقارير التي لا يمكن إدخال أي شيء فيها.

1 ج: تخطيط موارد المؤسسات

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





الشكل: 9. بنية الميزنة في 1C: ERP



مزايا الميزنة في 1C: ERP:

• أشكال وظيفية كافية للمدخلات والمخرجات

عيوب الميزنة في 1C: تخطيط موارد المؤسسات:

• صلابة النموذج. من حيث المبدأ ، كما هو الحال في معظم أنظمة تخطيط موارد المؤسسات (ERP) ، لا يتسامح نموذج الميزانية مع التغييرات المتكررة بل إنه صعب الإرضاء بشأن الإعداد المسبق
• رسم الخرائط ضعيف. لسبب ما ، تكون وظيفة التعيين أسوأ مما كانت عليه في UPP
• صلابة المنتج. على عكس SCP ، من الصعب للغاية والمكلف إعادة صياغة إطار المنهجية هنا. أنت بحاجة إلى دراسة القائمة الموجودة جيدًا ، وبناء الميزانية على 1C: ERP ، إذا كانت تناسب الشركة حقًا
• أداء. النماذج التفاعلية فعالة للغاية ، لكن الجهاز التقني يجعلها بطيئة للغاية على كميات كبيرة من البيانات

أيضًا في 1C: لا توجد وظيفة جادة لتخطيط موارد المؤسسات من حيث إعداد عملية إعداد الميزانية التنظيمية (سير العمل) والعمل متعدد المستخدمين. على سبيل المثال ، يتم تضمين عمليات الموافقة في منتج منفصل 1C: سير العمل ، والذي يتم تنفيذه عادةً فوق ERP.

1 ج: كاليفورنيا

الأتمتة المتكاملة هي نسخة مجردة من 1C: ERP ، لذا فإن تطويرها يتبع نفس المسار ، ولا توجد منهجية خاصة بالميزنة.

MS Axapta / MS Dynamics AX

يوفر فقط نموذجًا "عبر الإنترنت" لعرض البيانات الفعلية للميزانيات - تتم قراءتها مباشرةً من وحدات المحاسبة الخاصة بها ، بينما لا يتم توفير احتمالات التحول الجاد.





الشكل: 10. بنية إعداد الميزانية في MS Dynamics على



حد سواء زائد وناقص للنظام - "شحذ" لوحدات المحاسبة الخاصة به Dynamics وهيكلها الجاهز.



الايجابيات:

• التكامل مع وحدات المحاسبة. يعد إعداد الحصول على البيانات الفعلية من الوحدات النمطية المختلفة لنظام تخطيط موارد المؤسسات أمرًا بسيطًا للغاية.
• دمج. هناك العديد من الاحتمالات لتحميل الخطط الجاهزة من الأنظمة الخارجية. وبالتالي ، تتبع Microsoft بوضوح منطق فصل EPM عن ERP ، ونتيجة لذلك فإن أنظمة EPM "معلقة" بشكل جيد على Dynamics
• سير العمل. نموذج تنظيمي وظيفي وشفاف وقابل للتخصيص لعملية الموازنة

سلبيات:

• ETL. بشكل عام ، لا يوفر المنتج إمكانات تحويل بيانات ذات مغزى
• صلابة المنتج. تم وضع منهجية جاهزة ولكنها محدودة هنا. و (كما في حالة 1C: ERP) ، ليس من الصعب فقط إعادة تدويره ، ولكن أيضًا بلا فائدة عمليًا.

SAP S4 HANA

منتج SAP الرئيسي الذي حل محل نظام تخطيط موارد المؤسسات SAP R / 3.



لوضع الميزانية ، يتم الآن استخدام منتج EPM منفصل ، والذي في إصدار سطح المكتب (SAP BPC) لا يزال من الممكن اعتباره نظام EPM منفصل "أعلى" من تخطيط موارد المؤسسات ، ولكن في الإصدار السحابي (SAP Analytics Cloud) تم دمجه أخيرًا في نظام ERP (في SAP S4 سحابة HANA). ستجد المزيد من التفاصيل حول SAP BPC أدناه.



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



وبالتالي ، ينتقل SAP إلى بنية عكس ما هو معروف الآن في الممارسة "العادية". في ذلك ، لا يتم إنشاء قاعدة البيانات التحليلية "فوق" التخزين (SAP BW) ، ولكن يتم تنفيذها "ضمن" نظام تخطيط موارد المؤسسات (ERP). في هذه الحالة ، يقوم مخزن البيانات (SAP BW) ، عندما يعمل المستخدم ببياناته من نظام EPM ، بنقل البيانات لإجراء العمليات الحسابية مرة أخرى إلى قاعدة البيانات المدمجة الأصلية هذه.



في الواقع ، تحقق SAP نفس التأثير الذي تم تصميم OLAP لـ IN-Memory من أجله بطريقة معاكسة: عن طريق تعظيم الحسابات من ذاكرة الوصول العشوائي.

Oracle Cloud ERP

اتخذت Oracle أيضًا مسار تضمين نظام EPM داخل تخطيط موارد المؤسسات.



تعمل الشركة بنشاط على نقل منتجاتها إلى الإصدار السحابي (ربما يكون ذلك أكثر نشاطًا مما تفعله SAP). لذلك ، بالنسبة إلى حل EPM الرئيسي ، Oracle Hyperion (والذي سنتحدث عنه أيضًا أدناه) ، تقوم الشركة بالترويج لبديل في شكل Oracle EPM Cloud المستندة إلى السحابة ، والتي يتم تضمينها في Oracle Cloud ERP المستندة إلى السحابة.

أنظمة ثنائية

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



أنظمة ذكاء الأعمال الشائعة:

• Power BI
• تابلوه
• QlikView / QlikSense
• IBM Cognos TM1
• SAP BusinessObjects

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

أنظمة EPM

EPM تعني إدارة أداء المؤسسة. أيضًا ، تمت مصادفة مصطلحات إدارة أداء الشركات (CPM) ، وأقل شيوعًا ، إدارة أداء الأعمال (BPM).



مصطلح واسع جدًا يمكن أن يشير إلى وظائف ذات صلة ، ولكن في أغلب الأحيان يمكن اعتبار هذه الأنظمة على أنها منشآت لأشكال "حقيقة الخطة" التفاعلية. لم يصبح مفهوم EPM معروفًا بشكل عام بعد ، ولكن الحلول مثل تحليلات IBM Planning و Oracle Hyperion و Anaplan ، والتي تُعتبر أحيانًا في سياق Business Intellegence ، تسمى بشكل صحيح أنظمة EPM.



في بعض الأحيان يتم إنشاء أنظمة EPM لأغراض أوسع (على سبيل المثال ، SAP EPM أو 1C: إدارة القابضة) ، ولكننا سنأخذها في الاعتبار بدقة من حيث أنظمة أتمتة الميزانية. لذلك ، سوف نطلق على SAP Business Planning & Consolidation (SAP BPC) - نظام EPM ، على الرغم من أن SAP نفسها تسمي هذا منتج SAP EPM الأكبر ، والذي يتضمن SAP BPC.



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



أنظمة EPM البارزة:

• أوراكل هايبريون
• IBM Planning Analytics
• أنابلان
• SAP BPC
• بت التمويل
• 1 ج: إدارة القابضة

لنبدأ مع الصغار.

بت التمويل

يعتمد Bit.Finance على منهجية إعداد الموازنة UPP ، ومع ذلك ، على عكس ذلك ، أولاً ، يتم دعمه وتطويره ، وثانيًا ، يتم تنفيذه كنظام EPM على رأس ERP (وبالتالي ، فإنه يسمح لك بدمج البيانات الفعلية من مصادر خارجية مختلفة).





الشكل: 11. بنية الميزنة في Bit.Finance



مزايا أتمتة الميزنة في Bit.Finance:

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

رسم الخرائط أكثر تطوراً من SCP.



الحصول على البيانات الفعلية يعمل بثلاث طرق:

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

عيوب أتمتة الميزانية في Bit.Finance:

• العمل من خلال نماذج الوثائق. على الرغم من حقيقة أن أشكال المستندات أصبحت مرنة (انظر الإضافة الأولى) ، وبشكل عام ، في هذا الجانب ، تم إحراز الكثير من التقدم مقارنةً بـ SCP ، إلا أن المنتج لم يبتعد عن نموذج العمل المستند إلى المستندات بقدر ما نود. وهو ، كما قلنا ، غير مناسب لوضع الميزانية.
• عدم وجود أشكال تفاعلية للمدخلات والمخرجات. بخلاف 1C: ERP ، لا يوجد أي شيء هنا.

أنابلان

منتج رائد اكتسب مؤخرًا شعبية كبيرة في السوق العالمية. متوفر فقط في النسخة السحابية.



على عكس الحلول الشائعة الأخرى (بما في ذلك Hyperion and Planning Analytics) ، فإن لها تخصصًا محددًا بعض الشيء: فهي تعمل بشكل أفضل كخدمة لتقدير التكاليف تسمح لك بإعادة حساب نماذج الميزانية الحجمية تلقائيًا مع عدد كبير من التبعيات.





الشكل: 12. هندسة الميزانية Anaplan (سيناريو الأتمتة الشائعة)



الايجابيات:

• التكلفة. يركز المنتج على العمليات الحسابية ، ويخزن جميع البيانات في In-Memory OLAP ، مما يسمح بإعادة حساب جميع النماذج عبر الإنترنت
• العمل الجماعي (ضمن إعداد بيانات التخطيط)
• UX والنمذجة الحرة.
• ETL. أداة ETL الخاصة والمريحة للغاية
• يتطلب الحد الأدنى من دعم تكنولوجيا المعلومات. خاصة عندما يتعلق الأمر بالنمذجة
• كلفة. باهظة الثمن بعض الشيء بالنسبة للسوق الروسي ، ولكن بالمقارنة مع القادة الدوليين (نفس Oracle Hyperion) ، فإن التكلفة الإجمالية للملكية أقل
• سرعة التنفيذ. مقارنةً بـ Hyperion and Planning Analytics ، فإن المنتج أسهل في الاستخدام وأسهل في التنفيذ

سلبيات:

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

كل من Anaplan's plus و ناقص هما تخصصها الواضح نسبيًا وحقيقة أنها لا تتعدى على نظام تكنولوجيا المعلومات الخاص بالشركة. الميزة الإضافية هي أن المنتج قد حدد بوضوح الغرض الوظيفي الخاص به ، وأن اتجاهات تطويره يمكن التنبؤ بها تمامًا. إنها خدمة لإجراء تحليل ماذا لو وحساب الخطط (الميزانيات) والموافقة عليها ، وتحتاج إلى تخطيط بنية العميل بناءً على ذلك. الجانب السلبي هو أن المنتج لا يمكن أن يحل محل مستودع بيانات الشركة الكامل ، ولا يمكن أن يحل محل جميع قدرات BI ، والبنية التحتية ETL الشركة المعقدة ليست مبنية عليه ، وفي الواقع نظام الحوسبة الكاملة للشركة. كل هذا لن يكون مشكلة إذا لم يتم تقديم المنتج في إصدار السحابة فقط.



على عكس Oracle و SAP (وكلاهما يدعي أنهما نظام بيئي) ، لا يؤكد Anaplan على القدرة على "نقل" البيانات والأدوات بسهولة بين السحابة وخوادم الشركة. وبالتالي ، في حالته ، تظهر عيوب المنتج السحابي (مع الأخذ في الاعتبار التعرفة اعتمادًا على كمية البيانات المستخدمة على الخادم) بشكل ملحوظ.



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





الشكل: 13. هندسة الميزانية Anaplan (سيناريو الأتمتة البديلة)



بشكل عام ، يعد استخدام نظامي EPM و BI ممارسة عادية.

أوراكل هايبريون

يأتي في نسختين على الأقل: Oracle Hyperion Planning و Oracle Hyperion Financial Management.

يتم الآن استبداله بنشاط بمنتج Oracle EPM Cloud الجديد.



بسبب النظام البيئي ، يمكن للبنى أن تأخذ أنواعًا متنوعة ، لكن النموذج النموذجي يبدو شيئًا كهذا.





الشكل: 14. بنية الميزنة في Hyperion (خيار محتمل)



في الشكل ، قدمت نظام BI كمثال ، حيث أن قاعدة بيانات Oracle Essbase التحليلية هي قاعدة بيانات ممتازة لتحليلات البيانات الضخمة في أدوات ذكاء الأعمال.



يتم تقديم Oracle Data Integrator كحل ETL ، والذي يعمل كآلية عالمية لتكامل البيانات في نظام Oracle البيئي.



مزايا أتمتة الميزنة في Oracle Hyperion:

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

عيوب أتمتة الميزنة في Oracle Hyperion:

• النظام البيئي. سأشير أيضًا إلى أنه ، وفقًا للمعلومات المتاحة ، يتم اختيار Hyperion بشكل أساسي من قبل الشركات العاملة في Oracle Technology stack ، ومن استخدامه في بيئة غير تابعة لـ Oracle على المدى الطويل ، يكون تأثير أقل ممكنًا.
• . , Anaplan.
• . , UX ( ).

IBM Planning Analytics

مصمم بشكل أساسي للشركات الكبيرة ، ليس من السهل جدًا نشره وإدارته ، ولكنه نظام EPM فعال للغاية. حاليًا ، تحليلات IBM Planning مبنية على تقنيات TM1 (Cognos الأساسية).



بالنسبة لعمليات ETL ، تقترح شركة IBM استخدام منتج منفصل ، IBM DataStage (مستخدم سابقًا بواسطة Cognos DataManager) ، أو Turbo Integrator ، أو Cognos Integration Server ، أو أداة ETL خارجية.



الهندسة النموذجية تشبه إلى حد بعيد Hyperion.





الشكل: العمارة 15. الموازنة في Analytics التخطيط (اختياري)



قدرات IBM التخطيط تحليلات:

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

سلبيات

• تعقيد. كما هو الحال مع Hyperion: يتطلب تدريبًا كبيرًا للمستخدم ، وليس البنية الأساسية الأخف.

SAP BPC

بشكل عام ، السمات المميزة لـ SAP هي النظام البيئي ، وتعقيد البنية والبنية التحتية للحلول.



كما قلت من قبل ، دعمت SAP ودعمت خيارات بنية مختلفة في أوقات مختلفة ؛ وفقًا لأحدث المعلومات ، يبدو الإصدار الرئيسي للهندسة التي أوصى بها البائع اليوم كما يلي:





الشكل. 15. بنية الميزنة في SAP Business Planning & Consoldation (مثال)



مزايا الميزنة على أساس SAP BPC:

• تكامل البيانات. على الرغم من تعقيده ، إلا أنه عملي وسريع ، وهو أمر ضروري للشركات الكبيرة.
• التصور.
• سير العمل.

عيوب الموازنة على أساس SAP BPC:

• UX . SAP, , .
• . , SAP . , : . , . , SAP SAP BW MS SQL Server, NetWeaver; BW/4 HANA NetWeaver; , EPM- SAP Analytics Cloud, .
• السعر. من حيث التكلفة الإجمالية للملكية ، فقد تبين في الواقع أنه أحد أغلى أنظمة EPM في العالم ، والذي يتأثر بالتغيرات في الهندسة المعمارية.

ETL- أدوات

تُستخدم أدوات ETL المعروفة لبناء عمليات ETL ، من بينها العديد من المنتجات من نفس البائعين الذين ينتجون حلول BI / EPM:

• IBM DataStage
• انفورماتيكا باور سنتر
• Talend
• اباتار
• خدمات بيانات SAP
• Oracle Data Integrator
• مصنع بيانات Microsoft Azure
• واشياء أخرى عديدة الدكتور.

من المخطط أن يتم تحديث المقالة تدريجياً ، ربما مع إضافة معلومات حول المنتجات الجديدة ومبادئ تطوير منتجات البرمجيات لوضع الميزانية "من البداية".