مراحل تحلیل داده از تعریف یک سؤال مشخص شروع می‌شود. بعد، داده مرتبط را جمع‌آوری و بررسی می‌کنیم، آن را برای محاسبه آماده می‌کنیم و به دنبال الگوها و تفاوت‌ها می‌گردیم. نتیجه باید همراه با محدودیت‌هایش توضیح داده شود تا بتوان بر اساس آن اقدامی را انتخاب و اثر آن را پیگیری کرد.
فرض کنید مدیر یک فروشگاه می‌گوید «سفارش‌ها بیشتر از قبل دیر می‌رسند». پیش از تغییر شرکت حمل یا استخدام نیروی جدید، باید بدانیم منظور از تأخیر چیست و کدام سفارش‌ها دیر رسیده‌اند. در این مقاله، همین مسئله را مرحله‌به‌مرحله دنبال می‌کنیم. عددهای مثال، فرضی و آموزشی‌اند و گزارشی از عملکرد یک کسب‌وکار واقعی نیستند.
مسیر تحلیل داده را چگونه پیش ببریم؟
برای این مثال، کار را در هشت مرحله پیش می‌بریم: تعریف سؤال، جمع‌آوری، بررسی کیفیت، آماده‌سازی شاخص‌ها، تحلیل، تفسیر، ارائه و اقدام. این ترتیب، چک‌لیست اجرای کار است؛ ممکن است وسط تحلیل متوجه شویم یک تاریخ اشتباه ثبت شده یا داده تازه‌ای لازم داریم و به مرحله قبل برگردیم.
راهنمای فرایند تحلیل داده مایکروسافت نیز هدف‌گذاری، گردآوری، پاک‌سازی، تحلیل و استفاده از نتیجه را به هم مرتبط می‌داند. تعداد نام‌گذاری‌شده مرحله‌ها در منابع یکسان نیست؛ مهم این است که معلوم باشد هر مرحله چه پرسشی را پاسخ می‌دهد و چه خروجی‌ای دارد.
۱. سؤال، محدوده و معیار را تعریف کنید
سؤال «چرا وضع ارسال بد شده؟» برای شروع محاسبه دقیق نیست. آن را به پرسشی قابل بررسی تبدیل می‌کنیم: «آیا سهم تحویل‌های دیرتر از موعد در چهار هفته اخیر بیشتر شده و این تغییر در کدام مسیر ارسال دیده می‌شود؟» دو دوره چهارهفته‌ای را بر اساس تاریخ تحویل واقعی سفارش‌ها جدا می‌کنیم و تاریخ استخراج اطلاعات را هم ثبت می‌کنیم.
در مثال ما، واحد بررسی یک سفارش تحویل‌شده است. سفارش وقتی دیر محسوب می‌شود که تاریخ تحویل واقعی از موعدی که هنگام ثبت سفارش به مشتری اعلام شده، عبور کند. اگر یک سفارش چند بسته داشته باشد، باید از ابتدا روشن کنیم تحویل کامل را چگونه ثبت می‌کنیم؛ در این مثال، تاریخ رسیدن آخرین بسته ملاک است.
شاخص مورد بررسی، «درصد تأخیر در سفارش‌های تحویل‌شده» است. این شاخص، وضعیت سفارش‌های هنوز تحویل‌نشده را نشان نمی‌دهد. برای آن‌ها، فهرست جداگانه‌ای از سفارش‌های بازِ گذشته از موعد می‌خواهیم تا مشکل‌های جاری از دید گزارش پنهان نمانند.
۲. داده‌های لازم و منبع آن‌ها را مشخص کنید
برای پاسخ به سؤال، همه ستون‌های اطلاعات مشتری لازم نیست. شناسه سفارش، تاریخ ثبت، موعد اعلام‌شده، تاریخ تحویل واقعی، وضعیت سفارش و شرکت حمل نقطه شروع مناسبی هستند. برای بررسی دقیق‌تر، ممکن است منطقه مقصد و زمان تحویل بسته به شرکت حمل هم لازم شوند. شماره تماس و نام مشتری در جدول تحلیلی این مثال کاربردی ندارند.
اطلاعات سفارش و ارسال ممکن است در دو فایل جدا باشند. آن‌ها را با شناسه‌ای مشترک وصل کنید و مطمئن شوید هر شناسه چه چیزی را نمایندگی می‌کند. اگر فایل فروش، برای هر قلم کالا یک ردیف داشته باشد و فایل ارسال برای هر بسته یک ردیف، اتصال مستقیم می‌تواند تعداد ردیف‌ها را چندبرابر کند. قبل از محاسبه، باید به سطح همان «یک سفارش» برسیم.
یک نسخه دست‌نخورده از خروجی منبع نگه دارید. نام منبع، زمان دریافت، محدوده تاریخی و توضیح ستون‌ها را ثبت کنید. در گزارش بعدی باید بتوان تشخیص داد تفاوت عددها از عملکرد کسب‌وکار آمده یا از تغییر روش استخراج داده.
۳. کیفیت داده را بررسی و اصلاح کنید
ابتدا تعداد سفارش‌ها، شناسه‌های تکراری و تاریخ‌های خالی را بشمارید. نبود تاریخ تحویل را خودکار به معنی «به‌موقع» یا «دیر» نگیرید. ممکن است سفارش هنوز باز باشد یا تحویل انجام شده ولی ثبت نشده باشد. هر دو حالت به بررسی نیاز دارند و رفتار یکسانی در محاسبه ندارند.
- تاریخ‌ها: قالب، تقویم و در صورت ثبت ساعت، منطقه زمانی را یکسان کنید. تاریخ تحویل زودتر از ثبت سفارش را بررسی کنید.
- نام گروه‌ها: نام‌های متفاوت برای یک شرکت حمل را پس از تطبیق منبع، یکدست کنید.
- تکرارها: مشخص کنید ردیف تکراری خطای ثبت است یا بخشی از جزئیات معتبر سفارش.
- مقادیر نامعمول: تأخیر طولانی را فقط به دلیل بزرگ‌بودن حذف نکنید؛ ممکن است همان مسئله‌ای باشد که باید بررسی شود.
در راهنمای چارچوب کیفیت داده دولت بریتانیا، ثبت داده‌های مفقود، تکرارها و اصلاحات انجام‌شده توصیه شده است. برای مثال ما نیز باید بگوییم چند سفارش به دلیل نبود موعد قابل بررسی نیستند و این کمبود ممکن است چه اثری بر نتیجه داشته باشد.
اصلاح را روی نسخه کاری انجام دهید و دلیل آن را ثبت کنید. توضیح آماده‌سازی داده در IBM هم میان پاک‌سازی، ساختاردهی و اعتبارسنجی ارتباط برقرار می‌کند و درباره حذف بیش از حد اطلاعات هشدار می‌دهد. هدف، ساختن جدول ظاهراً بی‌نقص به قیمت از دست رفتن شواهد نیست.
۴. ستون‌های محاسباتی و قواعد شاخص را بسازید
برای هر سفارشِ قابل بررسی، یک ستون «دیررسیده» بسازید: اگر تاریخ تحویل واقعی بعد از موعد اعلام‌شده باشد، مقدار آن «بله» است. اگر در همان روز موعد یا پیش از آن تحویل شده، «خیر» است. این قاعده روزمحور است؛ برای تعهدهای ساعتی، باید زمان دقیق را هم وارد تعریف کنید.
درصد تأخیر = تعداد سفارش‌های دیررسیده ÷ تعداد سفارش‌های تحویل‌شده با موعد معتبر × ۱۰۰
به هر سفارش برچسب دوره و شرکت حمل اضافه کنید. تعدادهای محاسبه‌شده را با گزارش منبع تطبیق دهید. اگر بعد از اتصال فایل‌ها، ۱۰۰ سفارش به ۱۴۰ ردیف تبدیل شده‌اند، قبل از رسم نمودار علت افزایش ردیف را پیدا کنید.
در مثال آموزشی، پس از بررسی کیفیت، برای هر دوره ۱۰۰ سفارش تحویل‌شده با موعد معتبر داریم. این تعداد، داده آماده محاسبه است. گزارش واقعی باید تعداد اولیه و موارد کنارگذاشته‌شده را هم نشان دهد.
۵. داده را تحلیل کنید؛ از کل به گروه‌ها برسید
در دوره قبل، ۷ سفارش از ۱۰۰ سفارش دیر رسیده‌اند؛ در دوره جاری، ۱۴ سفارش از ۱۰۰ سفارش. درصد تأخیر از ۷٪ به ۱۴٪ رسیده، یعنی ۷ واحد درصد افزایش. این تغییر با «۷ درصد رشد نسبی» یکسان نیست؛ در این مثال، رشد نسبی ۱۰۰٪ است. برای جلوگیری از ابهام، تعداد و درصد را کنار هم بنویسید.
بعد، نتیجه را بر اساس شرکت حمل جدا می‌کنیم. این جدول از همان ۲۰۰ سفارش فرضی ساخته شده است:
| گروه | دوره قبل: دیررسیده از کل | دوره جاری: دیررسیده از کل |
|---|---|---|
| شرکت حمل الف | ۳ از ۶۰؛ ۵٪ | ۲ از ۴۰؛ ۵٪ |
| شرکت حمل ب | ۴ از ۴۰؛ ۱۰٪ | ۱۲ از ۶۰؛ ۲۰٪ |
| مجموع | ۷ از ۱۰۰؛ ۷٪ | ۱۴ از ۱۰۰؛ ۱۴٪ |
نرخ ثبت‌شده برای شرکت الف ثابت مانده است. در شرکت ب هم نرخ تأخیر بیشتر شده و هم سهمش از سفارش‌های بررسی‌شده از ۴۰ به ۶۰ سفارش رسیده است. بنابراین تغییر عدد کل را باید همراه با تغییر ترکیب سفارش‌ها خواند؛ مقایسه تعداد تأخیرها به‌تنهایی کافی نیست.
در پروژه واقعی، می‌توان همین بررسی را برای منطقه مقصد یا فاصله ثبت تا خروج از انبار ادامه داد. راهنمای تحلیل اکتشافی NIST بر بررسی ساختار داده، مقادیر نامعمول و فرض‌ها تأکید می‌کند. برای این سؤال، جدول و مقایسه گروه‌ها نقطه شروع‌اند؛ الزاماً نیازی به مدل یادگیری ماشین نداریم.
۶. یافته را از تفسیر و علت جدا کنید
یافته: در داده‌های این دو دوره، نرخ تأخیر سفارش‌های ارسال‌شده با شرکت ب از ۱۰٪ به ۲۰٪ رسیده است. پرسش بعدی: آیا مسیرها عوض شده‌اند، بسته‌ها دیرتر از انبار خارج شده‌اند یا خود حمل طولانی‌تر شده است؟ جدول فعلی پاسخ قطعی این پرسش‌ها را نمی‌دهد.
از همین جدول نمی‌توان نتیجه گرفت شرکت ب علت تمام تأخیرهاست یا تغییر شرکت حمل حتماً مشکل را حل می‌کند. ممکن است سفارش‌های دشوارتر به آن واگذار شده باشند. برای تصمیم، باید زمان تحویل بسته به حمل، منطقه مقصد و شرایط هر سفارش را هم بررسی کنیم.
این محاسبه توصیف همین دو دوره است و به‌تنهایی ثابت نمی‌کند تفاوت، پایدار یا ناشی از یک عامل مشخص است. تعداد کم سفارش‌ها، تعطیلات، آب‌وهوا و ناقص‌بودن ثبت اطلاعات می‌توانند برداشت را تغییر دهند. اگر تصمیم پرهزینه است، شواهد بیشتری لازم داریم. مقاله اشتباهات رایج در تحلیل داده نمونه‌های بیشتری از این خطاهای برداشت دارد.
۷. نتیجه را برای تصمیم‌گیرنده قابل بررسی ارائه کنید
گزارش را با سؤال و پاسخ کوتاه شروع کنید: «در سفارش‌های تحویل‌شده این نمونه، درصد تأخیر بیشتر شده و بررسی جزئی‌تر شرکت ب اولویت دارد.» سپس جدول، تعریف شاخص و محدوده داده را نشان دهید. محدودیت‌ها باید کنار نتیجه باشند تا خواننده آن را به همه سفارش‌ها یا همه زمان‌ها تعمیم ندهد.
برای مقایسه دو دوره، نمودار میله‌ای ساده مناسب است؛ برای دنبال‌کردن تغییر هفتگی می‌توان نمودار خطی داشت. محور، واحد و اندازه گروه‌ها باید مشخص باشند. رنگ بیشتر یا نمودار سه‌بعدی، نبود تعریف درست شاخص را جبران نمی‌کند.
اگر گزارش مرتب تکرار می‌شود، می‌توان آن را به داشبورد تبدیل کرد؛ به شرط اینکه قواعد محاسبه و منبع اطلاعات ثابت و قابل پیگیری باشند. راهنمای تبدیل داده‌های اکسل به داشبورد مدیریتی این مسیر را توضیح می‌دهد.
۸. اقدام را تعیین و اثر آن را پیگیری کنید
اقدام اولیه می‌تواند بررسی مشترک چند سفارش دیررسیده با انبار و مسئول حمل باشد. پس از شناخت محل تأخیر، یک تغییر محدود را انتخاب کنید؛ مثلاً اگر خروج دیرهنگام از انبار تأیید شد، زمان آماده‌سازی سفارش را در یک مسیر مشخص تغییر دهید. مسئول اجرا، زمان شروع و موعد بازبینی را ثبت کنید.
در دوره بعد، همان شاخص را با همان تعریف اندازه بگیرید و هزینه یا پیامدهای جانبی را هم ببینید. بهترشدن عدد بعد از تغییر، به‌تنهایی اثبات اثر آن نیست؛ حجم سفارش، مقصدها یا شرایط حمل هم ممکن است عوض شده باشند. در صورت امکان، گروه قابل مقایسه و روش ارزیابی را پیش از اجرا تعیین کنید.
اگر اطلاعات اصلی ثبت نمی‌شوند، نخست باید ثبت داده اصلاح شود. تحلیل می‌تواند به همین تصمیم برسد و لازم نیست برای هر مسئله، یک نتیجه عددی قطعی یا یک مدل پیچیده تولید کند.
چه ابزارهایی برای این مراحل لازم است؟
برای یک فایل کوچک و محاسبه روشن، Excel می‌تواند کافی باشد. وقتی داده در چند جدول پایگاه داده است، SQL به استخراج و اتصال کمک می‌کند. برای پردازش تکرارشونده یا تحلیل قابل بازاجرا، Python یا ابزارهای دیگر قابل بررسی‌اند. انتخاب ابزار باید با حجم داده، نیاز به تکرار و توان تیم هماهنگ باشد.
راهنمای ابزارهای تحلیل داده از Excel تا Python تفاوت این کاربردها را توضیح می‌دهد. اگر داده‌های کسب‌وکارتان بین چند سامانه پراکنده‌اند، برای بررسی یکپارچه‌سازی، گزارش‌گیری و اتوماسیون می‌توانید حوزه خدمات هوش مصنوعی و اتوماسیون داپا را ببینید.
پرسش‌های متداول
آیا مراحل تحلیل داده همیشه همین ترتیب را دارند؟
این ترتیب برای سازمان‌دهی کار مفید است، اما فرایند رفت‌وبرگشت دارد. تحلیل ممکن است خطای ثبت را آشکار کند یا نشان دهد سؤال اولیه به داده دیگری نیاز دارد. تغییر سؤال و قاعده محاسبه را باید مستند کنید.
آیا داده ناقص را باید حذف کنیم؟
به علت نقص و کاربرد ستون بستگی دارد. در مثال تأخیر، نبود موعد معتبر مانع محاسبه آن سفارش است؛ ولی تعداد چنین سفارش‌هایی خودش بخشی از گزارش کیفیت داده است. حذف بی‌توضیح یا پرکردن حدسی می‌تواند نتیجه را منحرف کند.
خروجی تحلیل داده باید داشبورد باشد؟
خروجی می‌تواند یک جدول، گزارش کوتاه، فهرست موارد نیازمند بررسی یا داشبورد باشد. قالب مناسب به مخاطب و تکرار استفاده بستگی دارد. در همه حالت‌ها، سؤال، روش محاسبه و محدودیت نتیجه باید قابل فهم باشند.
