مالک داده پایه در ERP دقیقاً چه کسی است؟
در پروژههای ERP، مالک داده پایه معمولاً مدیر یا مسئول فرایندِ همان حوزه است؛ برای مثال، مالک داده مشتری میتواند در فروش، مالک داده کالا در زنجیره تأمین یا تولید، و مالک داده کارکنان در منابع انسانی تعریف شود. منطق این تقسیمبندی روشن است: کسی باید مالک باشد که اثر خطا را در عملیات، گزارشگیری و تصمیمسازی میبیند و میتواند درباره قواعد کسبوکار تصمیم بگیرد.
منابع راهنمای مایکروسافت برای مدیریت داده در پیادهسازیهای ERP تأکید میکنند که باید مالکیت داده، قواعد و معماری داده بهصورت روشن مشخص شود و یک steward برای اعمال و پایش اصول حاکمیت داده تعیین گردد. در ادبیات IBM نیز data owner مسئول دقت، کیفیت و یکپارچگی حوزه داده معرفی میشود و data steward مسئول مدیریت روزمره آن حوزه است.
از این زاویه، مالک داده پایه «کاربر سیستم» نیست و با «کارشناس ورود اطلاعات» هم یکی نیست. مالک، صاحب تصمیم است؛ نه لزوماً اجراکننده عملیات.
- مالک داده پایه باید از کسبوکار باشد.
- فناوری اطلاعات معمولاً مالک کسبوکار نیست، بلکه توانمندساز است.
- مالک باید بتواند درباره تعریف، تغییر و اولویت اصلاح خطا تصمیم بگیرد.
- برای هر دامنه داده، یک نفر پاسخگو و چند نقش پشتیبان لازم است.
چرا مالکیت داده را نباید به فناوری اطلاعات واگذار کرد؟
اگر مالکیت داده پایه بهطور کامل به فناوری اطلاعات سپرده شود، پروژه معمولاً به سمت کنترل فنی میرود نه کنترل معنایی. در این حالت، سیستم از نظر ساختار شاید درست کار کند، اما دادهها هنوز با زبان کسبوکار، قوانین فرایندی و نیازهای گزارشگیری همراستا نیستند. نتیجه، اختلاف بر سر «تعریف درست» است؛ نه فقط بر سر «ثبت درست».
راهنماهای رسمی مایکروسافت برای معماری داده، داشتن نمای جامع از مخازن داده، روابط و مالکیت را شرط همراستایی تیمهای کسبوکار و فنی میدانند. IBM هم در چارچوب حاکمیت داده، ownership را بخشی از سیاستهای داده و کیفیت میداند که باید توسط تیمهای کسبوکار و داده بهصورت مشترک پشتیبانی شود.
بنابراین نقش فناوری اطلاعات در استقرار ERP حیاتی است، اما ماهیت آن مالکیت نیست. IT باید محیط، امنیت، دسترسی، یکپارچگی سامانهها و کیفیت فنی را مدیریت کند؛ در حالی که کسبوکار مالک قواعد، معنای داده و پذیرش نهایی دادههای مرجع است.
- IT مالک بستر است، نه الزاماً مالک معنای داده.
- اختلافات دادهای معمولاً مسئله فرایند و تعریفاند، نه فقط مسئله فنی.
- حاکمیت داده بدون صاحب کسبوکار به چرخهای از اصلاحهای موقت تبدیل میشود.
- تعریف مالکیت باید در شروع پروژه نوشته شود، نه بعد از Go-Live.
نقشهای کلیدی در حاکمیت داده پایه چه تفاوتی دارند؟
در یک استقرار بالغ، مالک داده، steward، کارشناس فرایند و تیم IT نقشهای متفاوتی دارند. مالک داده تصمیمگیر نهایی در حوزه خود است. steward کیفیت روزمره، تطبیق با استانداردها و پیگیری اختلافها را هدایت میکند. کارشناس فرایند جزئیات عملیاتی و نیازهای واقعی واحد را توضیح میدهد. IT هم مسئول پیادهسازی کنترلها، گردشکارها، سطوح دسترسی و اتصال سامانههاست.
اگر این نقشها با هم خلط شوند، دو مشکل رایج رخ میدهد: یا همهچیز به IT ارجاع میشود و تصمیم کسبوکاری شکل نمیگیرد، یا مسئولیت مالکیت آنقدر پراکنده میشود که هیچکس پاسخگو نیست. در اسناد آموزشی مایکروسافت نیز توصیه شده است که data steward زودهنگام تعیین شود و با یک کاربر بیطرف کسبوکاری برای جمعآوری نیازها و مدیریت اختلافها همکاری کند.
بهترین الگو این است که مالک داده از کسبوکار بیاید، steward برای اجرای قاعده در سطح روزمره تعیین شود، و کمیته حاکمیت داده اختلافهای بینواحدی را حل کند.
- مالک داده: پاسخگوی تصمیمهای حوزهای.
- Data steward: نگهبان کیفیت و پیگیریکننده قواعد.
- کارشناس فرایند: منبع فهم عملیاتی و نیاز واقعی.
- فناوری اطلاعات: مجری کنترلهای فنی و یکپارچگی سامانهای.
در زمان استقرار ERP، مالک داده پایه چه مسئولیتهایی دارد؟
در فاز استقرار، مالک داده باید ابتدا دامنه داده را مشخص کند: چه چیزی داده پایه است، چه چیزی داده مرجع است، و چه چیزی داده تراکنشی محسوب میشود. سپس باید تعریف مشترک فیلدها، قواعد اعتبارسنجی، سطح جزئیات، چرخه تغییر و معیار پذیرش داده را تأیید کند. این بخش از کار معمولاً مهمتر از خود بارگذاری اولیه داده است، چون اگر تعریفها اشتباه باشند، مهاجرت داده هم اشتباه خواهد بود.
مالک داده همچنین باید درباره پاکسازی و اولویتبندی خطاها تصمیم بگیرد. همه دادههای ناقص یا ناسازگار ارزش یکسان ندارند؛ بعضی خطاها عملیات را متوقف میکنند و بعضی فقط کیفیت گزارش را پایین میآورند. مالک حوزه باید مشخص کند کدام خطاها در زمان استقرار باید قبل از Go-Live اصلاح شوند و کدامها میتوانند در فاز بعدی مدیریت شوند.
در کنار اینها، مالک داده باید معیارهای کیفیت را تعریف و پایش کند: کاملبودن، یکتایی، سازگاری، بهروزبودن و اعتبار. این معیارها در ERP فقط برای زیبایی گزارش نیستند؛ مستقیماً بر خرید، فروش، تولید، حقوق و دستمزد و بستن دوره مالی اثر میگذارند.
- تعریف دامنه و مرز داده پایه.
- تأیید قواعد اعتبارسنجی و کدگذاری.
- تعیین اولویت پاکسازی خطاها.
- تعیین معیارهای کیفیت و پذیرش داده.
- تصمیم درباره زمان و روش اصلاح دادههای ناسازگار.
چه الگوی تصمیمگیریای برای مالکیت داده پایه مناسبتر است؟
در عمل، بهترین الگو این است که برای هر دامنه داده یک مالک مشخص شود، اما تصمیمهای بیندامنهای در یک سازوکار مرکزی حاکمیت داده جمع شود. برای مثال، مشتری ممکن است در فروش مالک داشته باشد، اما آدرس، شرایط پرداخت و طبقهبندی اعتباری به هماهنگی مالی، حقوقی و عملیات هم نیاز داشته باشد. در چنین شرایطی، مالکیت منفرد بدون سازوکار هماهنگی مرکزی کافی نیست.
الگوی موفق معمولاً سه لایه دارد: لایه دامنهای برای مالکیت، لایه اجرایی برای steward و لایه راهبری برای حل تعارض. این مدل با رویکردهای مطرح در DAMA و راهنماهای MDM همخوان است که داده را دارایی سازمانی میبینند و برای آن ساختارهای governance، stewardship و policy تعریف میکنند.
اگر سازمان کوچک باشد، این نقشها میتوانند همپوشانی داشته باشند؛ اما حتی در سازمان کوچک هم باید مشخص باشد چه کسی تصمیم میگیرد، چه کسی اجرا میکند و چه کسی اختلاف را حل میکند. ابهام در نقشها معمولاً از کمبود ساختار هزینهبرتر است.
- مالکیت را دامنهای تعریف کنید، نه کلی و مبهم.
- اختلافهای بیندامنهای را به کمیته حاکمیت داده بسپارید.
- در سازمان کوچک هم نقشها را مکتوب کنید.
- بدون سازوکار حل تعارض، مالکیت فقط یک عنوان است.
چطور از نظر کیفیت داده، مالکیت را در استقرار قابلاجرا کنیم؟
مالکیت داده وقتی واقعی میشود که به شاخص و فرایند وصل شود. برای هر دامنه باید شاخصهای کیفیت تعریف شود، وضعیت خطاها دیده شود، و مسیر اصلاح روشن باشد. اگر مالک فقط نام داشته باشد اما داشبورد، گزارش استثنا و اختیار اقدام نداشته باشد، در عمل مالکیتی شکل نگرفته است.
بهتر است قبل از استقرار نهایی، فهرست دادههای حساس و حیاتی تهیه شود، سطح تحمل خطا مشخص شود و مسئول رسیدگی به هر دسته خطا معلوم باشد. این کار کمک میکند تیم پروژه بداند کدام دادهها باید پیش از مهاجرت پاکسازی شوند و کدامها میتوانند با کنترلهای بعدی تثبیت شوند.
در نهایت، کیفیت داده یک فعالیت یکباره نیست. همانقدر که مهاجرت داده مهم است، پایش پس از استقرار هم اهمیت دارد. مالک داده باید در چرخهای مستمر از پایش، بازبینی و بهبود قرار بگیرد تا ERP بهجای انبار دادههای ناسازگار، به مرجع عملیاتی قابلاتکا تبدیل شود.
- مالک را به شاخص کیفیت وصل کنید.
- داشبورد خطا و مسیر اقدام تعریف کنید.
- دادههای حیاتی را پیش از مهاجرت اولویتبندی کنید.
- پایش کیفیت باید پس از Go-Live هم ادامه داشته باشد.
پرسشهای متداول
آیا مالک داده پایه همان مدیر پروژه ERP است؟
خیر. مدیر پروژه هماهنگکننده است، اما مالک داده پایه کسی است که درباره معنای داده، کیفیت و تغییرات حوزه خود تصمیم میگیرد.
آیا واحد فناوری اطلاعات میتواند مالک داده پایه باشد؟
معمولاً نه؛ IT بهتر است مالک بستر و کنترلهای فنی باشد. مالک داده باید از کسبوکار بیاید تا تصمیمها با نیاز عملیاتی همراستا بماند.
Data steward چه فرقی با مالک داده دارد؟
مالک تصمیمگیر است، اما steward مسئول اجرای روزمره قواعد کیفیت و پیگیری اصلاحها در داده است.
در استقرار ERP چند مالک داده لازم است؟
به تعداد دامنههای اصلی داده. برای هر حوزه کلیدی مثل مشتری، کالا، تأمینکننده یا کارکنان باید یک مالک مشخص وجود داشته باشد.
منابع و مطالعه بیشتر
- Checklist for data management and governance - Dynamics 365 — Microsoft Learn
- Manage your data effectively with the right architecture - Dynamics 365 — Microsoft Learn
- What is Data Governance? — IBM