**مدیریت داده کلیدی (Master Data Management)** یک نظام تکنولوژی است که در آن تجارت و فناوری اطلاعات دست در دست هم گذاشته و یکنواختی، دقت، نظارت، انسجام معنایی و مسئولیت داده ی کلیدی و رسمی یک تشکیلات را تضمین می کنند.

دلایل استفاده از مدیریت داده کلیدی
----------------------------------

سازمان ها و یا گروهی از سازمان ها ممکن است احساس نیاز به مدیریت داده های کلیدی کنند وقتی که بیشتر از یک کپی از اطلاعات درباره ی یک موجودیت تجاری در اختیار دارند. ذخیره کردن بیش از یک کپی از داده ی کلیدی به معنی وجود یک نابهینگی در حفظ کردن "نسخه ی یکتایی از واقعیت" در میان تمامی کپی ها می باشد. مگر اینکه افراد، پروسه ها و فناوری هایی در کار باشند تا انسجام میان کپی ها را تضمین کنند، ذخیره شدن نسخه های مختلفی از اطلاعات درباره ی یک موجودیت تجاری اجتناب ناپذیر است. این مسئله از بهینگی استفاده ی عملیاتی از داده ها می کاهد و توانایی سازمان ها را در گزارش و بررسی مختل می کند. در سطح پایه مدیریت داده های کلیدی تلاش بر تضمین این دارد که یک سازمان چند نسخه (به طور بالقوه نامنسجم) از یک داده ی کلیدی را در عملیات های مختلف استفاده نمی کند، چیزی که در سازمان های بزرگ می تواند اتفاق بیافتد.

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

  

تعدادی از دلایل ریشه ای برای مشکلات داده های کلیدی در سازمان ها وجود دارد. این شامل:

1. بخش بندی واحد تجاری و خط محصول
2. ادغام و تملک

  

#### **بخش بندی واحد تجاری و خط محصول**

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

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

#### **ادغام ها و تملک ها**

یکی از رایج‌ترین دلایلی که برخی از شرکت‌های بزرگ با مشکلات بزرگی در مدیریت داده‌های کلیدی مواجه می‌شوند، رشد از طریق ادغام یا اکتساب است. هر سازمانی که ادغام می شود معمولاً یک موجودیت با داده های کلیدی تکراری ایجاد می کند (زیرا هر کدام احتمالاً حداقل یک پایگاه داده اصلی خود را قبل از ادغام داشتند). در حالت ایده آل، مدیران پایگاه داده این مشکل را از طریق حذف مجدد داده های کلیدی به عنوان بخشی از ادغام حل می کنند. با این حال، در عمل، تطبیق چندین سیستم داده اصلی به دلیل وابستگی هایی که برنامه های کاربردی موجود به پایگاه های داده اصلی دارند، می تواند مشکلاتی را ایجاد کند. در نتیجه، اغلب دو سیستم به طور کامل ادغام نمی شوند، اما از هم جدا می مانند، با یک فرآیند تطبیق ویژه تعریف شده است که سازگاری بین داده های ذخیره شده در دو سیستم را تضمین می کند. با این حال، با گذشت زمان، با وقوع ادغام ها و اکتساب های بیشتر، مشکل چند برابر می شود، پایگاه های داده اصلی بیشتر و بیشتر ظاهر می شوند و فرآیندهای تطبیق داده ها بسیار پیچیده و در نتیجه غیر قابل مدیریت و غیرقابل اعتماد می شوند. به دلیل این روند، می توان سازمان هایی با 10، 15 یا حتی 100 پایگاه داده اصلی مجزا و ضعیف یکپارچه پیدا کرد که می تواند مشکلات عملیاتی جدی در زمینه های رضایت مشتری ، کارایی عملیاتی، پشتیبانی تصمیم گیری و انطباق با مقررات ایجاد کند.

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

مردم، فرآیند و فناوری
---------------------

مدیریت داده کلیدی توسط فناوری *فعال* می شود، اما بیشتر از فناوری هایی است که آن را فعال می کنند. قابلیت مدیریت داده کلیدی یک سازمان شامل افراد و فرآیند نیز در تعریف آن می شود.

#### **مردم**

چندین نقش باید در MDM استخدام شوند. برجسته ترین آنها مالک داده و مباشر داده است. احتمالاً چندین نفر به هر نقش اختصاص داده می‌شوند که هر فرد مسئول زیرمجموعه‌ای از داده‌های کلیدی است (مثلاً یک مالک داده برای داده‌های کلیدی کارمند، دیگری برای داده‌های کلیدی مشتری).

مالک داده مسئول الزامات مربوط به کیفیت داده ها، امنیت داده ها و غیره و همچنین رعایت رویه های حاکمیت داده و مدیریت داده است. مالک داده همچنین باید پروژه های بهبود را در صورت انحراف از الزامات تأمین مالی کند.

Data Steward مدیریت اصلی داده را از طرف مالک داده اجرا می کند و احتمالاً مشاور مالک داده نیز می باشد.

#### **فرایند**

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

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

#### **فناوری**

یک ابزار مدیریت داده کلیدی را می توان برای پشتیبانی از مدیریت داده کلیدی با حذف موارد تکراری ، استانداردسازی داده ها (نگهداری انبوه)،  و ترکیب قوانینی برای حذف داده های نادرست از ورود به سیستم به منظور ایجاد یک منبع معتبر از داده های کلیدی استفاده کرد. داده های کلیدی محصولات، حساب ها و طرف هایی هستند که تراکنش های تجاری برای آنها تکمیل شده است.

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

  

  

**مدل های پیاده سازی**

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

1. منبع ثبت
2. ثبت
3. تحکیم
4. همزیستی
5. تراکنش/متمرکز

#### **منبع ثبت**

این مدل یک برنامه کاربردی، پایگاه داده یا منبع ساده تر (مثلاً صفحه گسترده) را به عنوان "منبع رکورد" (یا "سیستم رکورد "که در آن تنها پایگاه داده های برنامه کاربردی متکی است، شناسایی می کند. مزیت این مدل سادگی مفهومی آن است، اما ممکن است با واقعیت های توزیع داده های کلیدی پیچیده در سازمان های بزرگ مطابقت نداشته باشد.

منبع رکورد را می توان به عنوان مثال توسط گروه هایی از ویژگی ها (به طوری که ویژگی های مختلف موجودیت داده کلیدی ممکن است منابع رکورد متفاوتی داشته باشند) یا از نظر جغرافیایی (به طوری که بخش های مختلف یک سازمان ممکن است منابع اصلی متفاوتی داشته باشند) یکپارچه شود. فدراسيون فقط در موارد استفاده خاص قابل اجرا است، جايي كه مشخص باشد كه زيرمجموعه‌هاي سوابق در كدام منابع يافت مي‌شوند.

مدل منبع رکورد را می توان به طور گسترده تری نسبت به داده های کلیدی ، به عنوان مثال برای داده های مرجع، اعمال کرد.

#### **انتقال داده های کلیدی**

روش‌های مختلفی وجود دارد که داده‌های کلیدی را می‌توان جمع‌آوری و در سیستم‌های دیگر توزیع کرد.  این شامل:

1. ادغام داده ها - فرآیند جمع آوری داده های کلیدی از چندین منبع و ادغام در یک هاب واحد ( ذخیره داده های عملیاتی ) برای تکرار در سایر سیستم های مقصد.
2. فدراسیون داده - فرآیند ارائه یک نمای مجازی واحد از داده های کلیدی از یک یا چند منبع به یک یا چند سیستم مقصد.
3. انتشار داده – فرآیند کپی داده های کلیدی از یک سیستم به سیستم دیگر، معمولاً از طریق رابط های نقطه به نقطه در سیستم های قدیمی.

مدیریت تغییر در اجرا
--------------------

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

منابع
-----

1. ↑  "Gartner Glossary: Master Data Management". *Gartner*. Retrieved 6 June 2020.
2. ↑  Rouse, Margaret (2018-04-09). "Definition from WhatIs.com". *SearchDataManagement*. Retrieved 2018-04-09.
3. ↑  DAMA-DMBOK Guide, 2010 DAMA International
4. ↑  "Learn how to create a MDM change request – LightsOnData". *LightsOnData* (به انگلیسی). 2018-05-09. Retrieved 2018-08-17.
5. ↑  Jürgensen, Knut (2016-05-16). "Master Data Management (MDM): Help or Hindrance?". *Simple Talk*. Retrieved 2018-04-09.
6. ↑  "Creating the Golden Record: Better Data Through Chemistry", DAMA, slide 26, Donald J. Soulsby, 22 October 2009