داشبورد مدیریتی شعبه - چرا تقویم شمسی یک جزئیات نمایشی نیست
وقتی می‌گوییم داشبورد باید تقویم شمسی داشته باشد، اولین برداشت این است که منظورمان نمایش تاریخ به شمسی است. این ساده‌ترین بخش ماجراست و هر ابزاری از پسش برمی‌آید. مسئله واقعی جای دیگری است: «دوره مشابه سال قبل» یعنی چه؟
محصول آماده کارن تکنولوژی
این را روی داده واقعی کسب‌وکار خودتان ببینید
آنچه در این مقاله می‌خوانید، در محصولات کارن پیاده‌سازی شده است. در جلسه دمو، همان را روی داده و فرآیند خودتان اجرا می‌کنیم.
درخواست دمو رایگان یا تماس بگیرید: ۰۲۱-۸۸۶۱۴۲۸۲در این صفحه
تقویم، مسئله محاسباتی است نه نمایشی
گزارش‌های بانکی بر پایه دوره‌های شمسی بسته میشوند: ماه، فصل و سال مالی. و تقریباً همیشه با دوره مشابه سال قبل مقایسه میشوند، چون بدون آن مقایسه، عدد فروش یا جذب سپرده معنایی ندارد.
حالا مسئله این است: ماههای شمسی طول یکسان ندارند - شش ماه اول ۳۱ روز، شش ماه دوم ۳۰ روز، و اسفند بسته به کبیسه ۲۹ یا ۳۰ روز. اگر ابزار این را نداند و صرفاً تاریخ میلادی را تبدیل کند، «مهر امسال در برابر مهر پارسال» میتواند دو بازه با تعداد روز کاری متفاوت باشد.
سه جایی که ابزار عمومی اشتباه می‌کند
۱. تعداد روز کاری
تعطیلات رسمی ایران با هیچ تقویم استانداردی منطبق نیست و هرسال تغییر می‌کند. مقایسه دوره‌ای بدون تعدیل روز کاری، گمراه‌کننده است.
۲. جابه‌جایی نوروز
تعطیلات نوروز نسبت به تقویم میلادی هرسال جابهجا می‌شود. گزارشی که بر پایه ماه میلادی بسته شود، اثر نوروز را در ماههای متفاوتی می‌بیند و روند کاذب می‌سازد.
۳. سال مالی
سال مالی از فروردین شروع می‌شود. ابزارهایی که سال را ژانویه تا دسامبر فرض می‌کنند، در گزارش‌های تجمیعی سال به سال، دو دوره ناهمگون را مقایسه می‌کنند.
هیچ‌کدام از این‌ها با «تبدیل تاریخ در لایه نمایش» حل نمی‌شوند. باید در لایه مدل‌سازی داده حل شوند - یعنی جدول تقویم شمسی با روز کاری، تعطیلات و دوره مالی، که همه گزارش‌ها به آن وصل میشوند.
گزارش‌های شعبه‌تان چقدر طول می‌کشد آماده شود؟
در جلسه ارزیابی، منابع داده و چرخه گزارش‌گیری فعلی شما بررسی می‌شود.
شاخص‌هایی که در سطح شعبه معنا دارند
داشبورد مدیریتی که فقط جمع کل را نشان بدهد، تصمیم‌ساز نیست. آنچه مدیر منطقه لازم دارد، مقایسه‌پذیری است:
- عملکرد هر شعبه نسبت به هدفش، نه نسبت به میانگین
- روند خودِ شعبه در چند دوره - رشد یا افت
- ترکیب محصولات هر شعبه، چون دو شعبه با فروش برابر می‌توانند ترکیب کاملاً متفاوتی داشته باشند
- شاخص‌های عملیاتی در کنار مالی - زمان انتظار، حجم مراجعه، نرخ تکمیل فرآیند
و یک نکته که در طراحی داشبورد اهمیت دارد: مقایسه شعب با هم بدون تعدیل، نتیجه معکوس می‌دهد. شعبه‌ای در مرکز شهر با شعبه‌ای در شهرک صنعتی قابل مقایسه نیست، و مدیری که این را ببیند به کل داشبورد بی‌اعتماد می‌شود.
انبار داده پیش از داشبورد
اشتباه رایج، ساختن داشبورد مستقیماً روی سامانه‌های عملیاتی است. دو مشکل دارد: بار روی سامانه اصلی، و ناسازگاری تعاریف میان سامانهها.
ترتیب درست این است: اول انبار داده با تعاریف یکسان و تقویم مشترک، بعد داشبورد روی آن. این کندتر شروع می‌شود ولی تنها راهی است که گزارش‌ها با هم بخوانند.
گزارش خودکار به‌جای درخواست موردی
در بسیاری از بانک‌ها، گزارش‌های مدیریتی از طریق درخواست به واحد IT تولید میشوند. نتیجه‌اش صف انتظار است و گزارشی که وقتی می‌رسد، تصمیمش گرفته شده.
هدف عملی این کاربرد، حذف همان صف است: گزارش‌های دوره‌ای خودکار تولید و ارسال شوند، و برای پرسش‌های موردی، امکان پرس‌وجو به زبان فارسی روی همان انبار داده وجود داشته باشد.
نکته: پرس‌وجوی زبان طبیعی جایگزین گزارش رسمی نیست. برای بررسی سریع خوب است؛ برای گزارشی که مبنای تصمیم یا ارائه به هیئت‌مدیره است، گزارش تعریف‌شده و تأییدشده لازم است.
سنجش و نقطه شروع
معیار عملی: فاصله میان پایان دوره و آماده شدن گزارش آن دوره. اگر گزارش ماهانه دو هفته بعد آماده می‌شود، هدف اول کوتاه کردن همین است.
معیار دوم: تعداد درخواست‌های گزارش موردی به واحد IT - که باید کم شود.
پیشنهاد ما شروع با یک حوزه گزارشی است، معمولاً جذب منابع یا عملکرد فروش محصول، نه کل شاخص‌های بانک.
جزئیات پلتفرم در صفحه هوش تجاری سازمانی است.
بقیه کاربردها در صفحه راهکارهای بانکداری است.
پرسش‌های متداول
نه. ماههای شمسی طول یکسان ندارند و تعطیلات رسمی هرسال جابهجا میشوند، پس «مهر امسال در برابر مهر پارسال» میتواند دو بازه با تعداد روز کاری متفاوت باشد. این اختلاف در گزارش شعبه معنادار است و کسی هم متوجهش نمیشود چون هر دو عدد درست به نظر میرسند.
نمایش تاریخ را بله، محاسبه دوره را معمولاً نه - چون سال مالی را ژانویه فرض می‌کنند و تقویم روز کاری ایران را ندارند. راه‌حل درست، جدول تقویم شمسی با روز کاری و تعطیلات و دوره مالی در لایه مدل‌سازی داده است که همه گزارش‌ها به آن وصل شوند.
با همان جدول تقویم. اگر گزارش بر پایه ماه میلادی بسته شود، اثر نوروز هرسال در ماه متفاوتی دیده می‌شود و روند کاذب می‌سازد. با دوره شمسی و تعدیل روز کاری، مقایسه معنادار می‌شود.
توصیه نمیکنیم. هم بار روی سامانه اصلی میگذارد و هم تعاریف میان سامانهها ناسازگار میماند. ترتیب درست، اول انبار داده با تعاریف یکسان و بعد داشبورد روی آن است.
چون شعبه مرکز شهر با شعبه شهرک صنعتی قابل مقایسه نیست. مقایسه بدون تعدیل، نتیجه معکوس می‌دهد و مدیری که این را ببیند به کل داشبورد بی‌اعتماد می‌شود. مقایسه باید با هدف خود شعبه و روند خودش باشد.
نه. برای بررسی سریع عالی است، ولی گزارشی که مبنای تصمیم یا ارائه به هیئت‌مدیره است باید تعریف‌شده و تأییدشده باشد. این دو مکمل‌اند نه جایگزین.
با فاصله میان پایان دوره و آماده شدن گزارش آن دوره، و با تعداد درخواست‌های گزارش موردی به واحد IT. هر دو باید کم شوند و هر دو قابل اندازه‌گیری‌اند پیش از شروع.
