تقریباً همه سازمانهای امروزی داده دارند. سیستم مالی، منابع انسانی، فروش، تولید، CRM، ERP، فایلهای Excel، سامانههای عملیاتی و حتی مکاتبات روزمره، هر روز حجم زیادی داده تولید میکنند. بسیاری از سازمانها گزارش هم کم ندارند؛ گزارش فروش، عملکرد، بودجه، منابع انسانی، تولید، پروژه و دهها خروجی دیگر بهصورت روزانه، هفتگی یا ماهانه تهیه میشود.
اما داشتن داده و گزارش الزاماً به معنای تصمیمگیری دادهمحور نیست.
ممکن است مدیرعامل برای پاسخ به یک سؤال ساده چند گزارش مختلف دریافت کند. ممکن است واحد مالی و برنامهریزی برای یک شاخص واحد دو عدد متفاوت داشته باشند. ممکن است داشبوردی زیبا در سازمان وجود داشته باشد، اما مدیر نداند افزایش یا کاهش یک شاخص دقیقاً به چه معناست و چه اقدامی باید انجام دهد. یا گزارش موردنیاز زمانی آماده شود که فرصت تصمیمگیری از دست رفته است.
اینجاست که هوش تجاری یا Business Intelligence (BI) معنا پیدا میکند.
هوش تجاری قرار نیست فقط گزارشهای سازمان را زیباتر کند. هدف اصلی آن ایجاد یک مسیر منسجم میان سؤال کسبوکار، داده، شاخص، تحلیل، گزارش و تصمیم است؛ مسیری که به مدیر و کارشناس کمک کند اطلاعات درست را در زمان مناسب، در چارچوب دسترسی مناسب و به شکلی قابل فهم دریافت کند. در چارچوب حوزه BI گروه توسعه اقتصادی نگار نیز مسئله دقیقاً همینگونه تعریف شده است: ایجاد پیوند عملیاتی میان سؤال کسبوکار، داده، گزارش، امنیت و تجربه مصرف کاربر.
هوش تجاری دقیقاً چیست و چه مرزی دارد؟
هوش تجاری را میتوان مجموعهای از روشها، فرآیندها، مدلهای داده و ابزارهایی دانست که دادههای پراکنده سازمان را به اطلاعات قابل اتکا برای تحلیل و تصمیمگیری تبدیل میکنند.
در یک سیستم BI مناسب، سؤال از فناوری شروع نمیشود.
شروع از این نیست که:
«چه داشبوردی بسازیم؟»
یا:
«Power BI چه نمودارهایی دارد؟»
سؤال اصلی این است:
«مدیر یا کاربر سازمان قرار است چه تصمیمی بگیرد و برای آن تصمیم به چه اطلاعاتی نیاز دارد؟»
برای مثال، مدیر فروش ممکن است بخواهد بداند چرا فروش یک منطقه کاهش پیدا کرده است. مدیر منابع انسانی ممکن است به دنبال شناسایی روند افزایش ترک خدمت باشد. مدیرعامل یک هلدینگ ممکن است بخواهد عملکرد شرکتهای زیرمجموعه را با یک مجموعه شاخص مشترک مقایسه کند. مدیر کارخانه نیز ممکن است بخواهد بداند کاهش تولید ناشی از توقف تجهیزات است، کمبود مواد اولیه یا افت بهرهوری.
BI باید بتواند این سؤالها را به شاخص، داده و تحلیل متصل کند.
بنابراین هوش تجاری را نباید معادل یک نرمافزار خاص دانست. همچنین BI صرفاً «داشبورد»، «انبار داده» یا «گزارشگیری» نیست. هرکدام از این موارد بخشی از یک معماری بزرگتر هستند.
در حوزه BI گروه توسعه اقتصادی نگار نیز این حوزه بهصورت یک اکوسیستم تعریف شده است که تحلیل کسبوکار و KPI، مدل داده، انبار داده، داشبورد، پرتال گزارش، حاکمیت دسترسی، خودخدمتی و توانمندسازی کاربران را به یکدیگر متصل میکند.
مسئله سازمانی؛ داده و گزارش هست، اما تصمیم قابل اقدام شکل نمیگیرد
یکی از مهمترین سوءبرداشتها درباره پروژههای BI این است که تصور کنیم مسئله اصلی سازمان «کمبود گزارش» است.
در بسیاری از سازمانها دقیقاً برعکس است: گزارش زیاد است.
مسئله این است که این گزارشها پراکندهاند، تعاریف شاخصها یکسان نیست، دادهها از منابع متفاوت استخراج میشوند، دسترسی به اطلاعات به افراد وابسته است و ارتباط روشنی میان گزارش و تصمیم مدیریتی وجود ندارد.
برای نمونه، تصور کنید مدیرعامل در جلسه بررسی عملکرد میپرسد:
«حاشیه سود این ماه نسبت به برنامه چقدر تغییر کرده و دلیل اصلی آن چیست؟»
واحد مالی یک فایل ارائه میکند. برنامهریزی عدد دیگری دارد. فروش گزارشی با طبقهبندی متفاوت ارائه میدهد. بخشی از دادهها مربوط به هفته گذشته است و برای بررسی دلیل تغییر نیز باید درخواست تحلیل جدیدی به تیم BI یا IT ارسال شود.
در ظاهر، سازمان داده و گزارش دارد؛ اما هنوز تصویر واحد و قابل اتکایی برای تصمیمگیری ندارد.
در مسئلهشناسی BI گروه توسعه اقتصادی نگار نیز از همین چالشها نام برده شده است: پراکندگی گزارشها در Excel، پوشهها و سامانههای مختلف، اختلاف نسخهها، تأخیر در تصمیمگیری، وابستگی کاربران به تیم فنی، پیچیدگی دسترسیها و نبود مسیر روشن برای تبدیل داده به تصمیم.
به همین دلیل ارزش BI زمانی ایجاد میشود که سازمان از «تولید گزارش» عبور کند و به طراحی نظام تصمیمگیری مبتنی بر داده برسد.
زنجیره سؤال کسبوکار تا تصمیم چگونه شکل میگیرد؟
یک پروژه BI مؤثر بهتر است از یک زنجیره روشن پیروی کند:
سؤال مدیریتی → KPI و نیاز اطلاعاتی → منبع داده → مدل تحلیلی → داشبورد و گزارش → مصرف کاربر → تصمیم و اقدام
هر حلقه این زنجیره اهمیت دارد.
اگر سؤال مدیریتی مشخص نباشد، احتمالاً تعداد زیادی شاخص تولید میشود که کسی از آنها استفاده نمیکند.
اگر KPI تعریف دقیق نداشته باشد، واحدهای مختلف ممکن است یک مفهوم را متفاوت محاسبه کنند.
اگر منبع داده قابل اتکا نباشد، حتی زیباترین داشبورد نیز قابل اعتماد نخواهد بود.
اگر مدل تحلیلی درست طراحی نشده باشد، رابطه میان دادههای مختلف روشن نمیشود.
اگر گزارش متناسب با نقش کاربر طراحی نشده باشد، مدیر با انبوه اطلاعات روبهرو خواهد شد.
و اگر داده در جلسه تصمیمگیری، فرآیند مدیریتی یا اقدام بعدی استفاده نشود، BI در نهایت به یک محیط گزارشگیری تبدیل میشود.
در سبد خدمات BI گروه توسعه اقتصادی نگار نیز ترتیب کار از شناخت تصمیمها و تعریف KPI آغاز میشود، سپس به داده و مدل تحلیلی، داشبورد و گزارش، حاکمیت انتشار و دسترسی و در نهایت توانمندسازی و بهبود مستمر میرسد. منطق این ترتیب نیز روشن است: داشبورد بدون KPI توافقشده، داده قابل اتکا و فرآیند مشخص استفاده از اطلاعات، نمیتواند یک ابزار تصمیمگیری پایدار باشد.
چهار جزء اصلی یک نظام هوش تجاری
داده؛ ماده اولیه تصمیمگیری
هوش تجاری بدون داده قابل اتکا شکل نمیگیرد.
داده ممکن است از سیستم مالی، ERP، CRM، منابع انسانی، تولید، فروش، فایلها، APIها یا پایگاههای داده مختلف وارد شود. مسئله فقط دریافت این اطلاعات نیست؛ باید مشخص شود کدام منبع معتبر است، داده چگونه پاکسازی میشود و قواعد تبدیل و تجمیع آن چیست.
اگر داده خام دارای خطا، تأخیر یا تعارض باشد، مشکل در لایه گزارش نیز تکرار خواهد شد.
به همین دلیل یکی از اجزای BI، ارزیابی منابع، کنترل کیفیت داده، یکپارچهسازی و در صورت نیاز ایجاد Data Mart یا Data Warehouse است. هدف این لایه ایجاد دادهای است که قابل ردیابی، قابل تفسیر و آماده تحلیل باشد.
مدل تحلیلی؛ تبدیل داده خام به مفهوم کسبوکار
داده خام الزاماً برای مدیر قابل استفاده نیست.
فرض کنید در پایگاه اطلاعاتی هزاران رکورد فروش وجود دارد. مدیریت به رکوردها نیاز ندارد؛ میخواهد بداند فروش واقعی نسبت به بودجه چقدر است، کدام محصول افت داشته، کدام شعبه خارج از روند معمول حرکت کرده و حاشیه سود چگونه تغییر کرده است.
مدل تحلیلی میان زبان سیستمها و زبان کسبوکار پل ایجاد میکند.
در این لایه، ساختار داده، روابط، تعاریف، محاسبات و منطق شاخصها شکل میگیرد تا بتوان از داده به سؤال مدیریتی پاسخ داد.
به همین دلیل تعریف KPI و مدل داده باید به یکدیگر متصل باشند. اگر سازمان ابتدا دهها نمودار طراحی کند و بعد درباره تعریف شاخصها بحث کند، مسیر عملاً معکوس شده است.
داشبورد و گزارش؛ تبدیل تحلیل به تصویر قابل فهم
داشبورد نقطهای است که بسیاری از کاربران BI را از طریق آن تجربه میکنند؛ اما داشبورد باید خروجی یک تحلیل باشد، نه نقطه شروع آن.
یک داشبورد مدیریتی خوب قرار نیست هر داده موجود را نمایش دهد.
باید به کاربر کمک کند سریع بفهمد:
وضعیت چگونه است؟
کدام شاخص نیاز به توجه دارد؟
تغییر نسبت به چه مبنایی اتفاق افتاده است؟
آیا امکان رفتن به جزئیات وجود دارد؟
و در نهایت، آیا اطلاعات نمایشدادهشده به یک تصمیم یا اقدام مرتبط است؟
در مدل خدمات گروه توسعه اقتصادی نگار، طراحی داشبورد شامل شاخص، UX/UI، فیلتر، Drill-down و «سناریوی تصمیمگیری» است؛ یعنی داشبورد صرفاً مجموعهای از نمودارها تلقی نمیشود، بلکه باید با سؤالهای کلیدی کسبوکار هماهنگ شود.
مصرف کاربر؛ اطلاعات باید واقعاً استفاده شود
یکی از بخشهایی که در پروژههای BI گاهی کمتر دیده میشود، تجربه مصرف گزارش است.
حتی اگر مدل داده و داشبورد درست باشند، کاربر باید بتواند گزارش موردنیاز خود را پیدا کند، سطح دسترسی مناسب داشته باشد و مطمئن باشد نسخهای که مشاهده میکند معتبر است.
مدیرعامل، مدیر مالی، تحلیلگر و کارشناس عملیاتی الزاماً به اطلاعات یکسان و سطح جزئیات مشابه نیاز ندارند.
به همین دلیل تجربه نقشمحور، مدیریت دسترسی، سازماندهی گزارشها، امنیت و ممیزی بخشی از BI سازمانی محسوب میشوند. در معماری حوزه BI گروه توسعه اقتصادی نگار نیز پرتال BI و «دادهنما» بهعنوان لایهای برای مدیریت، امنیت و تجربه مصرف گزارش در کنار زیرساخت گزارشگیری تعریف شدهاند؛ نه بهعنوان جایگزین مدل داده یا ابزار BI.
ارزش BI چیست و چه تفاوتی با گزارشگیری ساده دارد؟
گزارشگیری و هوش تجاری به هم مرتبطاند، اما یکسان نیستند.
گزارش ساده معمولاً میگوید چه اتفاقی افتاده است؛ برای مثال میزان فروش ماه قبل، تعداد درخواستها یا هزینه یک واحد.
BI تلاش میکند اطلاعات را در یک ساختار تحلیلی قرار دهد تا بتوان وضعیت را مقایسه کرد، روند را دید، از شاخص کلان به جزئیات رفت و تصمیم گرفت.
گزارشگیری ساده | هوش تجاری |
|---|---|
تمرکز بر ارائه اطلاعات | تمرکز بر پشتیبانی از تصمیم |
معمولاً خروجی ثابت و دورهای | تحلیل تعاملی و نقشمحور |
ممکن است از یک منبع تهیه شود | میتواند چند منبع داده را یکپارچه کند |
تعریف شاخص گاهی ضمنی است | KPI و منطق محاسبه باید مشخص باشد |
عمدتاً نشان میدهد چه اتفاقی افتاده | کمک میکند وضعیت، روند و نقاط نیازمند اقدام دیده شوند |
مصرف گزارش ممکن است فایلمحور باشد | دسترسی و مصرف میتواند متمرکز و کنترلشده باشد |
این تفاوت به این معنا نیست که گزارشهای ساده بیارزشاند. بسیاری از گزارشهای عملیاتی کاملاً ضروری هستند. مسئله زمانی ایجاد میشود که سازمان انتظار داشته باشد صرفاً با تولید گزارشهای بیشتر، کیفیت تصمیمگیری خودبهخود افزایش پیدا کند.
BI زمانی ارزش ایجاد میکند که داده را در خدمت یک تصمیم قرار دهد.
یک مثال سازمانی؛ از گزارش فروش تا تصمیم مدیریتی
فرض کنیم یک شرکت چند شعبه فروش دارد.
امروز هر شعبه در پایان ماه فایل فروش خود را ارسال میکند. واحد مالی اعداد را تجمیع میکند و مدیریت یک گزارش کلی دریافت میکند.
در گزارش مشخص میشود فروش ۸ درصد کاهش یافته است.
این گزارش مفید است، اما بلافاصله چند سؤال ایجاد میشود:
کاهش مربوط به کدام شعبه است؟
کدام محصول بیشترین تأثیر را داشته؟
کاهش ناشی از تعداد مشتری بوده یا ارزش متوسط خرید؟
این وضعیت از چه زمانی شروع شده؟
فروش واقعی در مقایسه با بودجه چگونه است؟
اگر پاسخ این سؤالها نیازمند تهیه فایلهای جدید باشد، مدیریت همچنان با تأخیر تصمیم میگیرد.
در یک رویکرد BI، ابتدا سؤالهای مدیریتی و KPIها مشخص میشوند. سپس منابع اطلاعاتی فروش، محصول، شعبه و بودجه بررسی و در مدل تحلیلی به یکدیگر متصل میشوند.
مدیر در داشبورد ابتدا شاخص کل را میبیند، سپس میتواند از فروش کل به شعبه، محصول یا دوره زمانی Drill-down کند.
ممکن است مشخص شود بیشتر کاهش فروش مربوط به دو شعبه خاص و یک گروه محصول است. در نتیجه مسئله از «فروش کاهش یافته» به یک سؤال دقیقتر تبدیل میشود.
اکنون داده فقط یک گزارش تولید نکرده؛ دامنه تصمیم را محدود کرده و نقطه مداخله را روشنتر ساخته است.
همین منطق را میتوان در حوزههای مالی، منابع انسانی، تولید، بانکداری، پروژه، مدیریت هلدینگ و عملیات نیز به کار برد. در پرونده BI گروه توسعه اقتصادی نگار نیز بانکها، هلدینگها، سازمانهای عمومی و صنایع از جمله سگمنتهایی هستند که برای آنها مسئلههایی مانند منابع داده متعدد، گزارشهای ناهمگون و نبود تصویر بهموقع از عملکرد مطرح شده است.
اشتباهات رایج در پروژههای هوش تجاری
یکی از مهمترین خطاها شروع پروژه از داشبورد است. سازمان ابتدا درباره رنگ، نمودار و صفحات تصمیم میگیرد، در حالی که هنوز KPI، مخاطب و سؤال مدیریتی توافق نشدهاند.
خطای دیگر، طراحی تعداد زیادی داشبورد در فاز اول است. تجربه مستندشده در مدل استقرار گروه توسعه اقتصادی نگار نیز نشان میدهد آغاز پروژه با دامنه وسیع، یکپارچهسازیهای نامشخص و تعداد زیاد داشبورد میتواند به اختلاف درباره KPI، تأخیر و کاهش پذیرش کاربران منجر شود؛ به همین دلیل شروع مرحلهای و مسئلهمحور پیشنهاد شده است.
ریسک مهم بعدی نادیدهگرفتن کیفیت داده است. اگر واحدها تعریف متفاوتی از یک شاخص داشته باشند یا داده اصلی قابل اعتماد نباشد، BI اختلاف را حل نمیکند؛ فقط آن را در یک صفحه زیباتر نمایش میدهد.
همچنین نباید BI را پروژه صرفاً IT دانست. تیم فناوری برای معماری، امنیت و پیادهسازی ضروری است، اما تعریف تصمیمها، KPIها و نیازهای اطلاعاتی بدون مشارکت مالک کسبوکار ناقص خواهد بود.
در نهایت، پروژه نباید با تحویل داشبورد تمام شود. آموزش کاربران، مدیریت Backlog تحلیلی، پایش استفاده و توسعه تدریجی نیز برای بهرهبرداری پایدار ضروریاند.
برای شروع BI از کجا باید آغاز کرد؟
شروع مناسب هوش تجاری الزاماً ساخت انبار داده بزرگ یا دهها داشبورد نیست.
برای بسیاری از سازمانها بهتر است یک دامنه محدود اما باارزش انتخاب شود.
برای مثال، یک تصمیم مهم مدیریتی یا یک حوزهای که گزارشدهی آن امروز زمانبر و پرخطاست.
سپس میتوان این مسیر را طی کرد:
تصمیم یا سؤال اصلی را مشخص کنید؛ مثلاً «چرا سودآوری کاهش یافته است؟»
KPIهای لازم و تعریف دقیق آنها را تعیین کنید.
منابع داده موردنیاز و کیفیت آنها را بررسی کنید.
یک مدل تحلیلی محدود ایجاد کنید.
یک یا چند داشبورد اولویتدار طراحی کنید.
مشخص کنید چه کسی، چه زمانی و برای چه تصمیمی از این اطلاعات استفاده خواهد کرد.
بعد از مشاهده ارزش، دامنه را مرحلهبهمرحله توسعه دهید.
این رویکرد با مدل «شروع منعطف» در سبد BI گروه توسعه اقتصادی نگار نیز همراستاست؛ نقطه آغاز میتواند عارضهیابی، یک داشبورد اولویتدار، مدل داده یا پرتال BI باشد و دامنه بر اساس نیاز واقعی سازمان رشد کند.
جمعبندی؛ BI از داده شروع نمیشود، از تصمیم شروع میشود
هوش تجاری فقط ساخت داشبورد یا مکانیزهکردن گزارشها نیست.
BI زمانی به یک قابلیت سازمانی تبدیل میشود که بتواند میان تصمیم، KPI، داده، مدل تحلیلی، گزارش و کاربر ارتباطی پایدار ایجاد کند.
یک سازمان ممکن است میلیونها رکورد داده و صدها گزارش داشته باشد، اما هنوز دادهمحور نباشد.
در مقابل، حتی یک پروژه محدود BI میتواند ارزشمند باشد اگر بتواند یک سؤال مدیریتی مهم را با داده قابل اتکا پاسخ دهد و آن پاسخ را به اقدام متصل کند.
شاید بهترین معیار برای تشخیص موفقیت BI همین سؤال باشد:
بعد از دیدن این داشبورد یا گزارش، مدیر دقیقاً چه چیزی را بهتر میفهمد و چه تصمیمی را میتواند بهتر بگیرد؟
اگر پاسخ این سؤال روشن نباشد، احتمالاً پروژه هنوز بیشتر درباره «گزارش» است تا «هوش تجاری».
و اگر قرار باشد یک اصل برای شروع در ذهن بماند، این است:
از سؤال مدیریتی شروع کنید؛ نه از نمودار.
گام بعدی
پس از شناخت مفهوم هوش تجاری، سؤال بعدی این است که سازمان چگونه باید این مسیر را از سؤال مدیریتی و تعریف KPI تا مدل داده، داشبورد، استقرار و بهرهبرداری پایدار طراحی کند.
ادامه مسیر: «نقشه راه BI؛ از سؤال مدیریتی تا داشبورد و بهرهبرداری پایدار»
سؤالات متداول
هوش تجاری برای چه سازمانهایی مناسب است؟
هوش تجاری بیشترین ارزش را برای سازمانهایی ایجاد میکند که داده و سیستم عملیاتی دارند، اما برای تجمیع، تحلیل یا استفاده مدیریتی از اطلاعات با مشکل مواجهاند. بانکها و مؤسسات مالی، هلدینگها، سازمانهای دولتی، شرکتهای صنعتی و سازمانهای دارای گزارشهای متعدد از جمله گروههایی هستند که در مستندات حوزه BI گروه توسعه اقتصادی نگار برای آنها سناریوهای مشخص مطرح شده است.
مهمترین پیشنیاز اجرای هوش تجاری چیست؟
پیش از فناوری، باید سؤال مدیریتی، KPI و نیاز اطلاعاتی مشخص شود. علاوه بر آن، منابع داده باید قابل شناسایی باشند و مالک کسبوکار نیز در تعریف شاخصها و پذیرش خروجی مشارکت داشته باشد. بدون توافق درباره سؤال کسبوکار و منبع داده، ریسک شروع پروژه در مسیر اشتباه افزایش پیدا میکند.
چه خطا یا ریسکی باید پیش از شروع کنترل شود؟
شروع با تعداد زیاد داشبورد، تعریف مبهم KPI، کیفیت نامناسب داده، نبود مالک داده یا مالک کسبوکار، تمرکز صرف بر فناوری و نادیدهگرفتن دسترسی و پذیرش کاربران از مهمترین ریسکها هستند. همچنین باید بین قابلیت آماده، پیکربندی و توسعه اختصاصی تمایز روشنی وجود داشته باشد تا انتظارات پروژه واقعبینانه بماند.
برای شروع با دامنه محدود چه گامی پیشنهاد میشود؟
یک سؤال مدیریتی مهم یا ۳ تا ۵ داشبورد اولویتدار میتواند نقطه شروع مناسبی باشد؛ مشروط بر اینکه KPI، منبع داده، کاربران هدف و معیار پذیرش آنها مشخص باشد. سپس بر اساس نتیجه فاز اول میتوان مدل داده، حوزههای جدید، حاکمیت گزارش، خودخدمتی یا سایر قابلیتها را توسعه داد.
دیدگاهها
نظر یا پرسش خود را درباره این مقاله ثبت کنید.