پیش از تعهد به پروژه، امکان‌پذیری داده را چگونه بررسی کنیم؟

امکان‌پذیری داده (Data Feasibility) یعنی بررسی کنیم اطلاعات لازم برای پرسش، با تعریف، پوشش و دسترسی مناسب فراهم می‌شود یا نه. سازمان ممکن است سامانه پرسنلی داشته باشد، اما سابقه تغییر نقش، زمان واقعی رویداد یا اطلاعات کارکنان خارج‌شده در آن نباشد. پیش از قول زمان و نتیجه، این فرض‌های تعیین‌کننده باید بررسی شوند.

این مرحله، پاک‌سازی کامل یا ممیزی جامع سازمان نیست. یک بررسی هدفمند است که نشان می‌دهد پروژه با دامنه فعلی قابل‌طراحی است، به آماده‌سازی مشخص نیاز دارد یا باید اصلاح شود. اندازه بررسی باید با ریسک تعهد متناسب باشد. هرچه هزینه خطا و وابستگی بیشتر است، شواهد اولیه قوی‌تری لازم می‌شود.

امکان‌پذیری داده را از جدول نیاز بررسی کنید

فهرست داده موردنیاز را کنار منابع بگذارید. برای هر مورد بپرسید چه چیزی واقعاً موجود است، نه اینکه چه چیزی باید در سامانه باشد. ممکن است نام ستون مناسب باشد اما معنی، زمان یا جمعیت متفاوتی داشته باشد. بررسی باید شکاف میان تعریف موردنیاز و اطلاعات واقعی را روشن کند.

این جدول با ارزیابی بلوغ داده کل سازمان تفاوت دارد. ممکن است منبع برای یک پرسش کافی و برای پرسش دیگر نامناسب باشد. گزارش باید بگوید برای همین پروژه چه حدی از استفاده ممکن است. عبارت کلی «داده‌ها خوب‌اند» یا «داده‌ها ضعیف‌اند» تصمیم اجرایی روشنی ایجاد نمی‌کند.

چند مسیر واقعی را تا منبع دنبال کنید

یک یا چند مورد مرتبط و مرزی را با مسئول منبع مرور کنید. زمان رویداد از کجا آمده؟ تغییر بعدی چه اثری روی مقدار قبلی داشته؟ پرونده خارج‌شده قابل‌بازیابی است؟ این بررسی کمک می‌کند رفتار واقعی ثبت دیده شود. انتخاب موارد باید هدفمند باشد و محدودیت آن در گزارش باقی بماند.

اگر فقط فایل تمیز ارائه‌شده از سوی واحد را می‌بینید، بپرسید چه مراحلی برای تهیه آن انجام شده است. اصلاح دستی، حذف پرونده یا جایگزینی مقدار می‌تواند مهم باشد. هدف سرزنش تولیدکننده نیست؛ باید بدانیم اطلاعات چگونه ساخته شده و کدام قسمت برای تکرار و بررسی قابل‌ردیابی است.

کامل‌بودن ظاهری را با کفایت یکی نگیرید

ستونی بدون خانه خالی ممکن است مقدار پیش‌فرض، تعریف نادرست یا ثبت دیرهنگام داشته باشد. برعکس، اطلاعات محدود می‌تواند برای توصیف دامنه مشخص مفید باشد. معیار باید این باشد که آیا منبع می‌تواند ادعای لازم را پشتیبانی کند و محدودیت باقی‌مانده برای تصمیم قابل‌قبول است یا نه.

پوشش زمانی به‌ویژه مهم است. اگر سامانه فقط وضعیت فعلی را نگه می‌دارد، شاید نتوان وضعیت فرد هنگام رویداد گذشته را بازسازی کرد. استفاده از آخرین نقش به جای نقش زمان رخداد، می‌تواند رابطه‌ها را تغییر دهد. این کمبود با تغییر قالب فایل رفع نمی‌شود و ممکن است طرح را محدود کند.

در مقایسه دوره‌ها، تغییر تعریف و شیوه ثبت را ببینید. افزایش رویداد پس از راه‌اندازی سامانه ممکن است بخشی از بهبود ثبت باشد. لازم است نقطه تغییر و امکان هماهنگ‌سازی روشن شود. داده بیشتر در دوره جدید، به‌تنهایی شاهد افزایش واقعی مسئله نیست.

اتصال و تعداد رکوردها را در مقیاس محدود بررسی کنید

شناسه مشترک ممکن است تکراری، بازاستفاده‌شده یا میان منابع ناهماهنگ باشد. پیش از تعهد به اتصال، نسبت موردانتظار را تعریف کنید. اگر برای یک فرد چند رویداد یا چند وضعیت وجود دارد، مشخص باشد کدام رابطه به واحد تحلیل مربوط است. افزایش تعداد ردیف پس از اتصال باید توضیح داشته باشد.

نیازی نیست در این مرحله همه قواعد پاک‌سازی اجرا شوند. باید خطرهای تعیین‌کننده شناخته شوند و برآورد آماده‌سازی بر شواهد اولیه استوار باشد. اگر اتصال فقط با تطبیق دستی و اطلاعات حساس ممکن است، هزینه، خطا و ضرورت آن را جدا بررسی کنید. راهکار موقت نباید بی‌توضیح به زیرساخت دائمی تبدیل شود.

هشداررفع خطای قالب، نبود سابقه یا تعریف نامتناسب را جبران نمی‌کند. پیش از برآورد پاک‌سازی، نوع کمبود و اثر آن بر پرسش را مشخص کنید.

دسترسی و ظرفیت تحویل را واقعی بررسی کنید

توافق شفاهی درباره ارسال داده ممکن است با مسیر مجاز انتقال، محدودیت دسترسی یا نبود وقت مالک داده روبه‌رو شود. نقش تأییدکننده، سطح اطلاعات و قالب تحویل باید روشن باشند. برای شناخت ساختار، همیشه داده فردی کامل لازم نیست. از کمترین دسترسی کافی برای بررسی اولیه شروع کنید.

زمان آماده‌سازی منبع را از زمان تحلیل جدا برآورد کنید. اگر واحد دیگری باید استخراج یا تعریف را اصلاح کند، مسئول و شاهد تحویل را ثبت کنید. عبارت «داده به‌زودی می‌رسد» برای برنامه معتبر کافی نیست. موعد باید بر ظرفیت و پیش‌نیاز واقعی متکی باشد و عدم‌قطعیت آن بیان شود.

همچنین درباره تکرار استخراج بپرسید. اگر پروژه به به‌روزرسانی نیاز دارد، تحویل یک‌باره فایل دستی ممکن است برای کاربرد بعدی کافی نباشد. اکنون لازم است این وابستگی دیده شود، حتی اگر طراحی فنی و نگهداری در مرحله دیگری انجام خواهد شد.

مانع‌ها را بر اساس اثرشان بر تصمیم دسته‌بندی کنید

این دسته‌بندی، نتیجه را به اقدام وصل می‌کند. یک فهرست طولانی خطا بدون توضیح اثر، به مدیر کمک نمی‌کند درباره ادامه تصمیم بگیرد. برای هر مانع مهم بنویسید چه کاری، توسط چه نقشی و با چه شاهدی آن را برطرف می‌کند. اگر رفع ممکن نیست، پیام آن برای تعهد پروژه روشن شود.

گزارش کوتاه امکان‌پذیری و شرط ادامه

1. نیاز داده و ادعای موردانتظار را یادآوری کنید.
2. منابع و دامنه بررسی اولیه را مشخص کنید.
3. شواهد وجود، تعریف، پوشش و اتصال را خلاصه کنید.
4. مانع‌های تعیین‌کننده و گزینه رفع را بنویسید.
5. هزینه و زمان نامطمئن را با فرض توضیح دهید.
6. شروع، آماده‌سازی، اصلاح یا تعویق را پیشنهاد کنید.
7. شرط ادامه و مسئول تأیید رفع مانع را تعیین کنید.

پیشنهاد خانه منابع انسانی این است که گزارش به جای رنگ یا نمره کلی، یک گزاره کاربردی داشته باشد: «این اطلاعات برای این پرسش و این جمعیت قابل‌استفاده است، مشروط به …». شرط باید مشخص باشد و معلوم شود در چه زمانی کنترل می‌شود. عبارت کلی کیفیت مناسب، مسئولیت ایجاد نمی‌کند.

نکتهپیشنهاد خانه منابع انسانی: پیش از تعهد نهایی، مهم‌ترین فرض درباره داده را عمداً بررسی کنید؛ همان فرضی که نادرستی آن می‌تواند طرح یا موعد پروژه را عوض کند.

بررسی اولیه، تضمین بی‌خطابودن کل اطلاعات نیست. در اجرای بعدی ممکن است مسئله تازه دیده شود. باید مسیر بازگشت به طراحی و اصلاح تعهد وجود داشته باشد. ارزش این مرحله در کاهش ابهام تعیین‌کننده و ثبت حدود شناخت است، نه در وعده حذف همه ریسک‌های داده.