لوحة في تجارة التجزئة ، حقا؟

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

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



تحت قص ما واجهناه وما تعلمناه.

من أين بدأنا؟

يحتوي "M. Video-Eldorado" على نموذج بيانات تم تطويره جيدًا: معلومات منظمة مع عمق التخزين المطلوب وعدد كبير من تقارير النموذج الثابت (انظر هذه المقالة للحصول على التفاصيل). من بين هؤلاء ، يقوم المحللون إما بإعداد الجداول المحورية أو المراسلات المنسقة في Excel ، أو العروض التقديمية الجميلة في PowerPoint للمستخدمين النهائيين.

منذ حوالي عامين ، وبدلاً من تقارير النموذج الثابت ، بدأنا في إنشاء تقارير تحليلية في تحليل SAP (وظيفة إضافية لبرنامج Excel ، في الواقع - جدول محوري على محرك OLAP). لكن هذه الأداة لم تكن قادرة على سد احتياجات جميع المستخدمين ، واصل معظمهم استخدام المعلومات التي تمت معالجتها بشكل إضافي من قبل المحللين.

ينقسم المستخدمون النهائيون إلى ثلاث فئات:

الإدارة العليا . يطلب معلومات بشكل جيد ومفهوم بوضوح.

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

المستخدمين الشامل . غير مهتم بالتحليل الذاتي للبيانات ، استخدم التقارير بدرجة محدودة من الحرية ، بتنسيق النشرات الإخبارية والجداول المحورية في Excel.

كانت فكرتنا هي تغطية احتياجات جميع المستخدمين ومنحهم أداة ملائمة واحدة. قرروا البدء بالإدارة العليا. كانوا بحاجة إلى لوحات معلومات مريحة لتحليل نتائج الأعمال الرئيسية. لذلك ، بدأنا مع Tableau وبالنسبة للمبتدئين ، اخترنا مجالين: مبيعات التجزئة والمبيعات عبر الإنترنت مع عمق محدود واتساع التحليل ، والتي تغطي حوالي 80 ٪ من البيانات التي طلبتها الإدارة العليا.

نظرًا لأن مستخدمي لوحات المعلومات كانوا من الإدارة العليا ، فقد ظهرت سرعة استجابة أخرى في مؤشر الأداء الرئيسي. لن ينتظر أحد من 20 إلى 30 ثانية حتى يتم تحديث البيانات. كان يجب أن يكون التنقل ملائمًا خلال 4 إلى 5 ثوان ، وكان من الأفضل التمرين على الفور. ونحن ، للأسف ، فشلنا في تحقيق ذلك.

هذا ما بدا عليه شكل لوحة القيادة الأساسية لدينا:



الفكرة الأساسية هي الجمع بين برامج تشغيل KPI الرئيسية ، والتي يوجد 19 منها في النهاية ، على اليسار وتقديم ديناميكياتها وتفاصيل السمات الرئيسية على اليمين. تبدو المهمة غير معقدة ، والتصور منطقي ومفهوم ، حتى تحصل على التفاصيل.

التفاصيل 1. حجم البيانات

يشغل جدول المبيعات الرئيسي لهذا العام حوالي 300 مليون صف. نظرًا لأنه من الضروري عكس ديناميكيات العام الماضي والعام الماضي ، فإن كمية البيانات عن المبيعات الفعلية وحدها تبلغ حوالي مليار خط. كما يتم تخزين المعلومات المتعلقة بالبيانات المخططة ووحدة المبيعات عبر الإنترنت بشكل منفصل. لذلك ، على الرغم من أننا استخدمنا SAP HANA داخل الذاكرة DB في الذاكرة ، كانت سرعة الاستعلام مع اختيار جميع المؤشرات لمدة أسبوع واحد من التخزين الحالي على الطاير حوالي 15-20 ثانية. الحل لهذه المشكلة يوحي نفسه - تجسيد البيانات الإضافية. ولكن لديها أيضا مطبات ، عنهم أدناه.

الجزء 2. مؤشرات غير المضافة

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



لصحة العمليات الحسابية ، يمكنك:

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

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

التفاصيل 3. مقارنة البيانات

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

مقارنة بالفترة السابقة (يوم إلى يوم ، أسبوع إلى أسبوع ، شهر إلى شهر)

في هذه المقارنة ، من المفترض ، استنادًا إلى الفترة التي حددها المستخدم (على سبيل المثال ، الأسبوع 33 من العام) ، يجب أن نظهر الديناميات بحلول الأسبوع 32 ، إذا حددنا البيانات لهذا الشهر ، على سبيل المثال ، مايو ، فإن هذه المقارنة ستعرض الديناميات بحلول أبريل.

مقارنة مع العام الماضي

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

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

الجزء 1. الإيمان في تابلوه

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

المرحلة 1. كل شيء في Live ، بدون تحسينات لارتداء النوافذ.

في هذه المرحلة ، قمنا بتوصيل Tableau بواجهات المتاجر الحالية وقررنا معرفة كيف سيتم حساب عدد الشيكات في عام واحد.

النتيجة:

كان الجواب محبطًا - 20 دقيقة. شبكة تقطير البيانات ، تحميل عالية على تابلوه. لقد أدركنا أن المنطق باستخدام المقاييس غير المضافة يجب تنفيذه على HANA. هذا لم يخيفنا كثيرًا ، لقد كان لدينا بالفعل تجربة مماثلة مع BO and Analysis وتمكنا من بناء واجهات عرض سريعة في HANA تنتج مؤشرات غير مضافة محسوبة بشكل صحيح. الآن بقي لتعديلها تحت Tableau.

المرحلة 2. نحن لحن النوافذ ، لا تجسيد ، كل شيء على الطاير.

لقد صنعنا عرضًا جديدًا منفصلاً ، والذي أنتج على الفور البيانات المطلوبة لـ TABLEAU. بشكل عام ، حصلنا على نتيجة جيدة ، قللنا من وقت تشكيل جميع المؤشرات في أسبوع واحد إلى 9-10 ثواني. وتوقعنا بصدق أن يكون زمن استجابة لوحة المعلومات في Tableau من 20 إلى 30 ثانية عند الافتتاح الأول ومن ثم بسبب ذاكرة التخزين المؤقت من 10 إلى 12 ، والتي تناسبنا بشكل عام.

النتيجة:

أول لوحة معلومات مفتوحة: 4-5 دقائق
أي نقرة: 3-4 دقائق
لا أحد يتوقع مثل هذه الزيادة الإضافية في عمل نافذة المتجر.

الجزء 2. الغمر في تابلوه

المرحلة 1. تحليل أداء اللوحة وضبط سريع

بدأنا في تحليل ما تنفقه Tableau معظم الوقت. ولهذا هناك مجموعة أدوات جيدة ، والتي ، بالطبع ، بالإضافة إلى تابلوه. كانت المشكلة الرئيسية التي حددناها هي استعلامات SQL المعقدة للغاية التي بنى عليها تابلوه. كانت مرتبطة في المقام الأول مع:

- نقل البيانات. نظرًا لعدم توفر Tableau أدوات لنقل مجموعات البيانات ، لإنشاء الجانب الأيسر من لوحة القيادة مع عرض تفصيلي لجميع مؤشرات الأداء الرئيسية ، كان علينا إنشاء جدول من خلال الحالة. بلغ حجم استعلامات SQL في قاعدة البيانات 120.000 حرفًا.



- اختيار الفترة الزمنية. استغرق هذا الاستعلام على مستوى قاعدة البيانات وقتًا أطول للترجمة من التنفيذ:



أي طلب معالجة 12 ثانية + 5 ثوان التنفيذ.

قررنا تبسيط منطق العمليات الحسابية على الجانب Tableau ونقل جزء آخر من الحسابات إلى واجهة المتجر ومستوى قاعدة البيانات. جلبت نتائج جيدة.

أولاً ، قمنا بعملية النقل على الطاير ، وقمنا بذلك من خلال صلة خارجية كاملة في المرحلة الأخيرة من حساب VIEW ، وفقًا لهذا النهج الموضح في wiki Transpos - Wikipedia ، الموسوعة المجانية والمصفوفة الابتدائية - Wikipedia ، الموسوعة المجانية .



وهذا هو ، قمنا بإعداد جدول ضبط - مصفوفة التحويل (21 × 21) وحصلنا على جميع المؤشرات في تحليل تفصيلي.

كان:


أصبح:


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

نتيجة لذلك ، تم تقليل سرعة لوحة أجهزة القياس بمقدار 3 مرات تقريبًا.

النتيجة:

1. 5 ثانية - تحليل لوحات المعلومات ، تصورات
2. 15-20 ثانية - التحضير لتجميع الاستعلامات مع تنفيذ عمليات التقييم المسبق في Tableau
3. 35-45 ثانية - تجميع استعلامات SQL وتنفيذها المتسلسل المتوازي في Hana
4. 5 ثوان - نتائج المعالجة ، والفرز ، وإعادة حساب المرئيات في تابلوه
5. بالطبع ، هذه النتائج لا تتناسب مع الأعمال ، وقد واصلنا تحسينها.

المرحلة 2. الحد الأدنى من المنطق في تابلوه ، تجسيد كامل

لقد فهمنا أنه كان من المستحيل إنشاء لوحة معلومات بوقت استجابة لعدة ثوانٍ في نافذة متجر عملت لمدة 10 ثوانٍ ، وقد درسنا خيارات لتجسيد البيانات في جانب قاعدة البيانات خصيصًا للوحة القيادة المطلوبة. ولكن تواجه المشكلة العالمية المذكورة أعلاه - مؤشرات غير المضافة. لم نتمكن من تحقيق ذلك حتى عند تغيير المرشحات أو المسح ، فإن Tableau يتم التبديل بمرونة بين واجهات المتاجر المختلفة والمستويات المحسوبة للتسلسلات الهرمية المختلفة للمنتجات (في المثال ، ثلاثة استعلامات بدون UTE ، مع UTE1 و UTE2 تشكل نتائج مختلفة). لذلك ، قررنا تبسيط لوحة المعلومات ، والتخلي عن التسلسل الهرمي للمنتج في لوحة المعلومات ومعرفة مدى السرعة التي يمكن أن تكون عليه في الإصدار المبسط.

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

الافتتاح الأول: 8-10 ثواني
أي نقرة: 6-7 ثواني

يتكون الوقت الذي تقضيه Tableau من:

1. 0.3 ثانية - تحليل لوحات المعلومات وتجميع استعلامات SQL
   
2. 1.5-3 ثانية - تنفيذ استعلامات SQL في Hana لتصور أساسي (يبدأ بالتوازي مع النقطة 1)
   
3. 1.5-2 ثانية - تقديم ، إعادة حساب المرئيات
   
4. 1،3sek. - تنفيذ استعلامات SQL إضافية للحصول على قيم عامل التصفية ذات الصلة (العلامة التجارية ، والشعبة ، والمدينة ، والتسوق) ، وتحليل النتائج
   

لتلخيص

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

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

1. لا يعرف Tableau كيفية التعامل مع كميات كبيرة من البيانات. إذا كان لديك أكثر من 10 غيغابايت من البيانات في نموذج البيانات الأصلي (حوالي 200 مليون × 50 سطرًا) ، فسيتم تباطؤ لوحة القيادة بشكل خطير - من 10 ثوانٍ إلى عدة دقائق لكل نقرة. جربنا كل من الاتصال المباشر واستخراج. سرعة العمل قابلة للمقارنة.
   
2. تقييد عند استخدام عدة مخازن (مجموعات البيانات). لا توجد وسيلة للإشارة إلى علاقة مجموعات البيانات باستخدام الأدوات القياسية. إذا كنت تستخدم الحلول البديلة لتوصيل مجموعات البيانات ، فسيؤثر ذلك بشكل كبير على الأداء. في حالتنا ، نظرنا في خيار تجسيد البيانات في كل قسم مطلوب من التمثيلات ، وفي مجموعات البيانات الملموسة هذه للقيام بالتبديل مع حفظ المرشحات المحددة مسبقًا - اتضح أن ذلك مستحيل في تابلوه.
   
3. في Tableau ، لا يمكن عمل معلمات ديناميكية. لا يمكنك استخدام المعلمة المستخدمة لتصفية مجموعة البيانات في المستخلص إما أثناء الاتصال المباشر ، لملء نتيجة تحديد آخر من مجموعة البيانات أو نتيجة استعلام SQL آخر ، أو إدخال المستخدم الأصلي فقط أو الثابت.
   
4. القيود المرتبطة ببناء لوحة معلومات تتضمن عناصر OLAP | PivotTable.
   في MSTR ، SAP SAC ، تحليل SAP ، إذا قمت بإضافة مجموعة بيانات إلى تقرير ، فإن كل الكائنات الموجودة عليه متصلة ببعضها البعض بشكل افتراضي. في Tableau ، لا يجب تكوين الاتصال يدويًا. قد يكون هذا أكثر مرونة ، ولكن بالنسبة لجميع لوحات المعلومات ، يعد هذا مطلبًا إلزاميًا للعناصر - لذلك فهذه تكلفة عمل إضافية. علاوة على ذلك ، إذا قمت بإنشاء عوامل تصفية ذات صلة بحيث ، على سبيل المثال ، عند تصفية منطقة ما ، فإن قائمة المدن تقتصر فقط على مدن هذه المنطقة ، فسوف تحصل على الفور على استعلامات متتالية في قاعدة البيانات أو الاستخراج ، مما يؤدي إلى إبطاء لوحة القيادة بشكل ملحوظ.
5. قيود الميزة. في كل من الخلاصة وأكثر من مجموعة البيانات من Live-connecta ، لا يمكنك إجراء تحويلات كبيرة. يمكن القيام بذلك من خلال تابلوه الإعدادية ، ولكن هذا عمل إضافي وأداة أخرى يجب دراستها وصيانتها. أنت ، على سبيل المثال ، لا يمكنك نقل البيانات ، وجعلها تنضم إلى نفسك. ما يغلق من خلال التحويلات على الأعمدة الفردية أو الحقول التي يجب تحديدها من خلال الحالة أو إذا كان هذا يولد استعلامات SQL معقدة للغاية ، حيث تنفق قاعدة البيانات معظم الوقت في تجميع نص الاستعلام. كان لابد من حل هذه الأدوات الصلبة على مستوى واجهة المتجر ، مما يؤدي إلى تخزين أكثر تعقيدًا وتحميلات إضافية وتحولات.
   

نحن لم نضع حدا ل Tableau. ولكن كأداة يمكنها إنشاء لوحات معلومات صناعية وأداة يمكنك من خلالها استبدال نظام تقارير الشركة بالكامل ورقمنته ، لا يعتبر Tableau.

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

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