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

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

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

يوجد أسفل المقطع ما واجهناه وما تعلمناه عنه.

من أين بدأنا

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

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

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

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

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

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

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

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

هذا هو الشكل الذي يبدو عليه تخطيط لوحة التحكم الرئيسية لدينا:

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

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

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

التفاصيل 2. المؤشرات غير المضافة

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

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

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

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

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

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

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

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

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

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

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

الجزء الأول: الإيمان بالتابلوه

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

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

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

النتيجة:

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

المرحلة 2. نقوم بضبط حالات العرض، دون تجسيد، كل شيء سريعًا.

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

النتيجة:

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

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

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

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

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

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

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

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

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

أي أننا قمنا بعمل جدول إعداد - مصفوفة تبديل (21 × 21) وحصلنا على جميع المؤشرات في شكل تفصيلي صفًا تلو الآخر.

كان:


أصبح:


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

ونتيجة لذلك، انخفضت سرعة لوحة القيادة بنحو 3 مرات.

النتيجة:

1. 5 ثواني - تحليل لوحات المعلومات والمرئيات
2. 15-20 ثانية - التحضير لتجميع الاستعلامات مع إجراء العمليات الحسابية المسبقة في Tableau
3. 35-45 ثانية - تجميع استعلامات SQL وتنفيذها المتوازي والمتسلسل في Hana
4. 5 ثوانٍ - معالجة النتائج والفرز وإعادة حساب المرئيات في Tableau
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,3 ثانية. - تنفيذ استعلامات SQL إضافية للحصول على قيم التصفية ذات الصلة (العلامة التجارية، القسم، المدينة، المتجر)، وتحليل النتائج

لتلخيص ذلك لفترة وجيزة

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

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

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

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

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

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

المصدر: www.habr.com