صحبتهای آقای مصطفی امینی
آنچه جلسه امروز ما را از آنچه در گذشته نیز اتفاق افتاده است، متمایز میکند ، موضوع "مدیریت انبارش داده" یا "مدیریت فرایند انبارکردن دادهها" است. عمده مباحثی که دیگران در حوزه انبارش دادهها مطرح کردند، در محدوده فنی بوده و به خود انباره داده خلاصه میشود. و یا به موضوع مدیریت انبار داده مربوطه بوده است اما امروز ما میخواهیم اینجا به این مسئله بپردازیم که اگر قرار باشد دادههایی را در یک Data Warehouse (انباره داده) انبار کنیم، از لحاظ مدیریتی این فرایند چه ملاحضاتی نیاز دارد؟ چه قبل از ورود داده ها به انباره داده، چه در حین نگهداشت انباره داده و چه در رابطه با خروجیهایی که قرار است از انباره دادههایمان دریافت کنیم. مباحثی که ما اینجا خواهیم داشت از جنس حکمرانی، مدیریتی و سیاستگذاری انبارش داده خواهند بود. این نکته وجه تمایز بحث امروز با موضوعات گذشته است.
موضوع انباره داده و هوشمندی کسب و کار ( Business Intelligence –BI ) خیلی به همدیگر نزدیک هستند. اما از طرفی میشود اینها را جدای از هم نیز دانست، یعنی میشود راهکار انبار دادهای داشت که لزوما راهکار هوشمندی کسب و کار نباشد. اما حالت برعکس آن معنی ندارد، یعنی هرکس سراغ راهکارهای هوشمندی کسب و کار میرود معمولا باید دادههای خودش را انبار کرده و از آن یک پایگاه داده تحلیلی ساخته باشد. هوشمندی کسب و کار یک راهکار داده محور (Data-Driven Solution) است. انبارش داده همچون فرآیند ساخت فنداسیون ساختمان هوشمندی کسب و کار است.
ما در جلسه امروز، موضوع انبارش داده و هوشمندی کسب و کار را تقریبا مترادف هم گرفتیم. عمده مباحثی که امروز خواهیم داشت مباحث مدیریتی و تجربی هستند که دو مهمان ما در عمل و در کار اجرایی با آن برخورد کردند و متوجه شدند برخی مسائل و مشکلاتی که در حین کار با آن برخورد داشتند، از جنس مشکلات فنی نیستند، بلکه از جنس مشکلات مدیریتی و سیاستگذاری هستند.
در چارچوب مدیریت داده موسسه داما، یکی از دیسیپلین¬های (Discipline) که جدی گرفته شده، همین انبارش داده و هوشمندی کسب و کار است. به این صورت که موضوع حکمرانی داده را پیوند زده به موضوع انبارش داده و معتقد است هرکسی که به سراغ راهکارهای مدیریت داده میآید، یکی از مسائلی که باید به آن توجه داشته باشد، " حکمرانی انبارش داده " و " حکمرانی هوشمندی کسب و کار " است. و معتقد است اگر حکمرانی انبارش داده اتفاق نیافتد، هزینههای همچون هزینه کیفیت، هزینه پاکسازی دادهها را بالا میبرد و پروژههای حکمرانی داده را میتواند فرسایشی کند و در نتیجه هزینهها را افزایش بدهد.
ما وقتی در گزارشات موسسات تخصصی حوزه مدیریت داده هم که نگاه میکنیم، مثل موسسه DGI یا موسسه مشاوره Baseline، می بینیم که موضوع انبارش داده و موضوع هوشمندی کسب و کار یکی از محرکهایی بوده که مدیران عامل سازمانها را برای حرکت به سمت برنامههای حکمرانی داده مجاب کرده است و وقتی خواستند که طرح انبارش داده را در سازمان خود اجرا کنند متوجه پارهای مشکلات شدند که از جنس مدیریتی و سیاست گذاری داده بود و بخصوص در زمان ایجاد انباره داده. از اینرو آمدند شوراهای عالی حکمرانی داده را راه اندازی کردند.
صحبتهای دکتر صادق عبیات
موضوعی که من میخواهم به آن بپردازم مدیریت ساخت انباره داده است. در ابتدا قصد دارم به ترمینولوژی بحث بپردازم و بعد از آن فهرستی از کارهایی که برای مدیریت انباره داده لازم است را بصورت خلاصه عنوان خواهم کرد. وقتی مفهوم انباره داده آمد، بسیاری مدعی شدند که این مفهوم را از قبل میشناسند. اما برای آنکه مفهوم انباره داده را دقیق متوجه شویم لازم است به مفاهیم پایه ای تر برگردیم. از روزی که یک شرکت متولد میشود تا روزی که میمیرد، داده تولید میکند. این دادهها توسط دپارتمانهای مختلفی تولید میشود و بصورت جزایر پراکندهای ذخیره میشوند. برای مثال در حوزه بانک، سیستم تسهیلات، سپردهها، ضمانتنامه و ... وجود دارد که هرکدام بصورت جزایر جداگانهای در حال تولید داده هستند. یک عیبی که وجود این جزایر در پی خواهد داشت این هست که چشمانداز سازمان را از دید مدیران پنهان میکنند. یعنی اگر مدیری بخواهد چشمانداز سازمان را براساس دادهها و عملیات سازمان ببینید، خیلی برایش امکانپذیر نیست، چرا که برای دیدن چشمانداز سازمان باید تمام دادههای سازمان دیده شود. در نتیجه تصمیمگیری ها بر اساس چشم انداز سازمان عموما در حد حدس و گمان هستند. افراد کلیدی سازمان دیگر دسترسی به دادهها ندارند. و از طرفی چون ساختارهای دادهای برای درج طراحی شدند، برای بازیابی بهینه نیستند. در نتیجه برای تصمیمگیری های مدیریتی که نیاز است حجم زیاد داده پردازش و خوانده شوند، بازیابی این دادهها مقدور نخواهد بود.
اساسا پایگاههای داده برای خواندن حجم زیاد داده طراحی نشدند، بلکه برای خواندن سریع یک یا چند قلم داده طراحی شدهاند و این دو با هم خیلی فرق میکنند. و میتوان گفت پایگاههای داده برای بازیابی طراحی نشدند بلکه برای ذخیره طراحی شدند. چالش دیگری که جزایر دادهای به وجود میآورند این هست که هرکسی در سازمان مدعی است داده ی او درست و صحیحتر است. تمام این موارد باعث میشود مدیران یک سازمان تصویر درستی از سازمان خود و رقبا نداشته باشند و در رقابت با دیگر سازمانها واقعیات را نبینند. در حال حاضر عموما تصمیمات کلان مبتنی به حدس و گمان هست. این حدس و گمان نیز وابسته به سلیقه است و این نیز خود منجر به تصمیمات بد و دیر هنگام میشود. بطور خلاصه تصمیمگیران سازمان نیاز به دادههای جامع دارند و نیاز دارند دستیابی به این دادهها برایشان سریع و سهل الوصول باشد.
در حالتی که سازمان از انباره داده استفاده نمیکند، ما دو گروه سیستمها را داریم. در سازمان سیستمهای عملیاتی زیادی وجود دارند. سیستم فروش، سیستم حسابرسی، سیستم حقوق و دستمزد، سیستم انبارداری و ... که هرکدام وظایف مشخصی دارند و متناظر یک دپارتمان در سازمان هستند. اما گروه دیگر سیستمها برای کسی که میخواهد سازمان را تحلیل کند و بخواهد روی مشتریان سازمان، منطقه جغرافیایی مشخصی و یا یک محصول سازمان تحلیلی انجام دهد آنگاه تمام اطلاعات مربوط به مشتری باید از تمام سیستمهای عملیاتی جمعآوری شود، همینطور دادههای منطقه جغرافیایی و دادههای محصول. تفاوت سیستمهای عملیاتی و سیستمهای تحلیلی در همین است. سیستمهای تحلیلی موضوع محور هستند اما سیستمهای عملیاتی با این چالش روبرو نیستند. سیستمهای عملیاتی فقط نیاز دارند یک ورودی دریافت کنند، یک پردازش کنند و یک ذخیره سازی انجام دهند.
در مورد انباره داده ما یک چرخهای داریم که ابتدا باید ملاکها و معیارها مورد انتخاب شوند. در مرحله بعد این ملاکها و معیارها آنالیز شوند و از این تحلیل به یک بینشی میرسیم. با رسیدن به این بینش، نهایتا ما یا تصمیمگیری و اکشنی خواهیم داشت و یا ممکن است اکشنی نداشته باشیم. ساختار دادهها در انباره داده متفاوت است از آنچه در پایگاه دادهها وجود دارد. اینطور نیست که تصور کنیم انباره داده یک پایگاهی از دادههای تمیز است یا تجمیعی از دادههای پایگاههای مختلف که با هم یکپارچه شدهباشند. درواقع این فرایندهای سازمان است که در انباره داده قرار میگیرد و دیگر جدولهای دادهای به آن شکل که در سیستمهای عملیاتی وجود داشت، دیده نمیشود.
صحبتهای مهندس بهزادیپور
چون بحث انبار داده و هوش تجاری بیشتر مدیریتی است، من سعی میکنم خیلی وارد مباحث تخصصی و فنی نشوم و تجاربی که در بحث طراحی و پیادهسازی انبار داده با آنها روبرو بودیم را مطرح میکنم. مثل خیلی از سازمانهای دیگر، مسائل و مشکلاتی که قبل از انبار داده داشتیم، دادههای متنوع بودند، دادههایی که در واحدهای مختلف ذخیره شده بودند و هر واحد بسته به تخصصی که داشتند دادهها را جمعآوری میکردند. در چنین شرایطی نه تنها بحث انتقال دادهها از سامانههای عملیاتی مختلف رو داشتیم، خروجی ای که تهیه میکردیم نیز ما را با مشکلات زیادی روبرو میکرد.
یکی مسئلهای که خیلی مهم است در بحث هوش تجاری همان انبار داده است. اما من در اینجا میخواهم ابتدا یک مقدمهای از روند مکانیزه شدن سامانههای بانک ملی خدمتتان ارائه بدهم. ما در سال ۱۳۷۱ مکانیزه کردن سیستمهای شعب بانک ملی را شروع کردیم. یک سیستم غیر متمرکز برای پاسخگویی به نیازهای تحویلداری شعب. بعد از آن سیستمهای حسابداری، تسهیلات و بقیه سیستمهای بانکی اضافه شدند. مشکلی که وجود داشت این بود که این سامانهها غیرمتمرکز بودند در حالی که مدیران بانک نیاز داشتند این دادهها را بصورت متمرکز در اختیار داشته باشند. ایده متمرکز سازی مطرح شد، زیرساختها تهیه شد. با مکانیزمی که آن زمان وجود داشت، انتقال دادهها به سمت ادارات امور بانک، استانهای بانک و نهایتا انتقال دادهها از ادارات امور به سمت مرکز انجام میشد. عملیاتی روی این دادهها انجام میشد و یک داده متمرکز از تمام دادهها رسیده ایجاد میشد و نهایتا یک گزارش کاغذی به دست مدیریت بانک میرسید. و اینکار هر روز تکرار میشد. مدیریت کردن این فرایند بسیار سخت بود. تنها حسنی که داشت این بود که یک مرجع کار استخراج گزارش را انجام میداد و در اختیار مدیریت قرار میداد و هنوز بحث انتشار داده در دپارتمانهای دیگر مطرح نبود.
به مرور زمان وقتی موضوع متمرکز شدن دادهها مطرح شد، درخواستهای زیادی از واحدها دیگر به بخش IT میرسید که خواستار دسترسی به این دادههای متمرکز بودند. مشکلی که وجود داشت این بود که ما باید یک واحدی را راهاندازی میکردیم و تمام دادهها را به این واحدها منتقل میکردیم و باید مدیریت میشد که این دادهها به چه کسانی تحویل داده میشود. این اتفاق نه تنها باعث افزونگی دادهها و افزایش نیاز به سختافزار و نرمافزار شد، مشکل دیگری را برای ما به وجود آورد و آن اینکه هر واحدی میتوانست برای خود گزارش آماری جداگانهای با دید خودش تهیه کند. این گزارشهای مستقل که بعضا همدیگر را نقض میکردند برای بانک مشکلات مختلفی را ایجاد میکرد.
بحث بعدیای که ما بعد از متمرکز کردن دادهها داشتیم، طبق دستورالعمل سازمان پدافند غیر عامل ابلاغ کرد، تمام سرورهای بانک باید داخل سازمان قرار میگرفت. در سال ۱۳۹۲ یک تحولی که در بانک ایجاد شد این بود که یک مدیریت دفتر تحول در بانک ملی با رویکرد مدیران جدیدی که آمده بودند ایجاد شد. کار این دفتر تحول نظارت کامل روی پروژههای بانک در حوزه IT بود. کار مهمی که این دفتر انجام داد این بود که دپارتمان IT را به سه بخش مستقل تقسیم کردند. یکی اداره عملیات بود، یکی اداره توسعه و یک اداره آمار و اطلاعات بانکی بود که متولی موضوع مدیریت انباره داده و پیادهسازی هوش تجاری در سازمان شد. شروع پیادهسازی انبار داده هم از سال ۱۳۹۴ آغاز شد و در سال ۱۳۹۵ هوش تجاری در بانک ملی با شعار "رساندن اطلاعات مناسب در زمان مناسب به ذینفعان مناسب (به ویژه مدیران) برای اخذ تصمیم مناسب" پیادهسازی شد. تجربهای که ما داشتیم این بود که در پروژه پیادهسازی انباره داده اگر کارشناسان بخش کسب و کار به مهندسان IT در طراحی کمک نکنند کار که انجام میشود کامل بیهوده خواهد بود و به سرانجام نخواهد رسید و مدل اگر مشکل داشته باشد مطمئن باشید اون گزارش نهایی ای هم که از سیستم استخراج میشود هم کاراییای نخواهد داشت. و این حرف که انباره داده نباید در حوزه IT قرار بگیرد، کاملا حرف درستی است. کارشناسان IT باید زیرساخت را آماده کنند و بقیه را باید در اختیار واحدهای مربوطه قرار دهد تا خودشان گزارشهایی که نیاز دارند را با توجه به دسترسیهایی که برایشان تعریف شده دریافت کنند.
سخنان پایانی مصطفی امینی
بحثهایی که ما امروز داشتیم در طیف مدیریتی و حکمرانی حرکت میکرد. چند نکته در صحبتهای آقای مهندس بهزادیپور بود که از لحاظ سطح تصمیمگیری فراتر از سطح مدیریت میانی بود. بخصوص موضوعاتی که در حوزه جهت گیری سازمان درباره داده های موجود در سیستمهای سنتی مین¬فریم mainframe یا سیستمهای جدید بانکی، تصمیماتی نیستند که یک مدیر میانی و حتی یک معاون به تنهایی، بتواند اتخاذ کند و به سطح راهبردی باید سپرده شود. در موضوع حکمرانی انباره داده و هوشمندی کسب و کار هم کار حکمرانی آن در سطح راهبردی سازمان اتفاق میافتد. معمولا شورای عالی حکمرانی داده حتما یک یا دو عضو از هیئت مدیره را نیز در خود دارند.
معمولا روی یک انباره داده برای تحقق هوشمندی کسب و کار، چهار سرویس یا خروجی سوار می شود. یکی از خروجیها که عمده بحث امروز را تشکیل میداد گزارشات توصیفی هستند، یعنی گزارشاتی که به ما میگویند تا به اینجا چه اتفاقاتی افتاده است. نوع دیگر گزارشات، گزارشات مانیتورینگ لحظهای هستند، یعنی در همین لحظه وضعیت ما به چه صورت است. بخش دیگری از گزارشات، گزارشات تحلیلی چند بعدی هستند که چند نمونهش را دکتر عبیات اشاره کردند، که یک پدیده را از بعد محصول، از بعد زمان و ... تحلیل میکنیم. و نهایتا بخش دیگر گزارشات آینده نگرانه هستند، یعنی با استفاده از دادهکاوی، تحلیل روند میکنیم و آینده را پیش بینی میکنیم. انتظاری که از راهاندازی انباره داده میرود این هست که ما بتوانیم گزارشات آیندهنگرانه بگیریم ولی بلوغ سازمان و سطح نیازی که مدیران سازمان بیان میکنند، اکثرا موضوع را به سمت گزارشات توصیفی میکشانند. در سازمانهای سنتی معمولا مدیران فقط میخواهند بدانند الآن چه خبر است و چه اتفاقاتی افتاده است و آنچه مربوط به آینده میشود را به تفسیر و رای شخصی خودشان اطمینان میکنند. یکی از انتظاراتی که از افراد حاضر در لایه حکمرانی انباره داده میرود، سیاستگذاری، تعیین استانداردها، تعیین خط مشیها و جهتگیریها است تا داده از بدو تولیدش باکیفیت بالا تولید شود. در لایه مدیریت انباره داده مباحثی همچون طراحی فیزیکی و اجرا بیشتر مد نظر هستند. اگر امروز من حکمرانی انباره داده را با هوشمندسازی کسب و کار در کنار هم و مترادف استفاده میکنم به این دلیل است موسسه داما این دو را همواره در کنار هم استفاده میکند.
برای شنیدن فایل صوتی این نشست اینجا و برای مشاهده اسلاید ها اینجا و اینجا را کلیک کنید.