روایت تحول فناوری اطلاعات در گروه سرمایه‌گذاری صندوق بازنشستگی کشوری
تحول فناوری اطلاعات در یک سازمان بزرگ، صرفا با خرید تجهیزات جدید، نصب چند نرم‌افزار یا ایجاد چند داشبورد مدیریتی اتفاق نمی‌افتد. تجربه نزدیک به دو دهه فعالیت من در حوزه فناوری اطلاعات نشان داده است که مهم‌ترین پیش‌نیاز هر تحول جدی، تغییر نگاه مدیریت به نقش فناوری اطلاعات در سازمان است.
فرهنگ اقتصاد _به نقل از روابط عمومی گروه سرمایه‌گذاری صندوق بازنشستگی کشوری، وحید مهاجر مدیر فناوری اطلاعات و ارتباطات در گفتگو با روابط‌عمومی هلدینگ صباانرژی بیان کرد: در طول این سال‌ها، دوره‌های مدیریتی مختلفی را تجربه کرده‌ام و طبیعتا رویکرد مدیران نسبت به فناوری اطلاعات یکسان نبوده است. در برخی مقاطع، اولویت اصلی حفظ وضع موجود، کنترل هزینه و استمرار سرویس‌های جاری بوده و در برخی دوره‌ها امکان حرکت به سمت توسعه، بازطراحی فرآیندها و استفاده جدی‌تر از فناوری فراهم شده است.
وی گفت: در دوره مدیریت آقای علی پناهی، مدیرعامل وقت گروه سرمایه‌گذاری صندوق بازنشستگی کشوری، این فرصت به شکل جدی‌تری ایجاد شد. نگاه مهندسی، سیستمی و علت و معلولی ایشان به مسائل، توجه به تحلیل کارشناسی و فراهم کردن امکان طرح دیدگاه‌های متفاوت، فضای مناسبی برای بررسی مجدد برخی مسائل قدیمی و اجرای پروژه‌هایی ایجاد کرد که پیش از آن، تجربه‌های متفاوتی از آنها در مجموعه وجود داشت. نقش مدیریت ارشد در چنین پروژه‌هایی صرفا صدور یک دستور یا تأمین بودجه نیست. پروژه‌ای مانند هوش تجاری، یکپارچه‌سازی اطلاعات شرکت‌های تابعه یا سیستم‌سازی فرآیندهای هلدینگ، مستقیماً با داده، ساختار سازمانی، حوزه‌های تخصصی مختلف و حتی شیوه سنتی انجام برخی امور درگیر می‌شود.
وی افزود: بدون حمایت مدیرعامل و همراهی تیم مدیریتی، عبور از این موانع عملا بسیار دشوار خواهد بود. یکی از ویژگی‌های مهم این دوره آن بود که انتظارات مدیریت ارشد از فناوری اطلاعات به‌تدریج از سطح خدمات روزمره فراتر رفت. این پرسش مطرح شد که فناوری اطلاعات چگونه می‌تواند به کسب‌وکار، پایش شرکت‌ها، افزایش شفافیت و تصمیم‌گیری سریع‌تر مدیریت کمک کند. همین نگاه، نقطه شروع بخشی از مسیری شد که امروز آن را حرکت از IT Support به سمت Data Governance، Business Intelligence و Digital Management می‌دانیم.
فناوری اطلاعات باید کسب‌وکار را بفهمد
وحید مهاجر گفت: سال‌هاست اعتقاد دارم فناوری اطلاعات در یک هلدینگ نباید صرفا واحدی باشد که مسئول روشن بودن رایانه‌ها، شبکه، پرینترها، اتوماسیون اداری یا Help Desk است. این خدمات ضروری هستند، اما کف خدمات فناوری اطلاعات محسوب می‌شوند، نه مأموریت نهایی آن.IT زمانی برای سازمان ارزش راهبردی ایجاد می‌کند که بتواند فرآیندهای کسب‌وکار را بفهمد، داده‌های آنها را شناسایی کند، نقاط ضعف فرآیندی را ببیند و سپس با استفاده از فناوری، آن فرآیندها را ساده‌تر، سریع‌تر، شفاف‌تر و قابل اندازه‌گیری کند.
برای کمک به واحد مالی باید ساختار مالی، خزانه، دریافت و پرداخت، بودجه و صورت‌های مالی را شناخت. برای کمک به یک هلدینگ سرمایه‌گذاری نیز باید مفهوم شرکت‌داری، مجامع، حاکمیت شرکتی، شرکت‌های مدیریتی، کنترلی و سرمایه‌پذیر، بودجه، عملکرد و نحوه پایش شرکت‌های تابعه را فهمید. به همین دلیل، همواره بر این موضوع تأکید داشته‌ام که قبل از دیجیتال کردن یک فرآیند، باید خود آن فرآیند را شناخت.
مدیر فناوری اطلاعات و ارتباطات بیان کرد: فناوری بدون شناخت کسب‌وکار معمولا فقط فرآیند سنتی را به یک فرآیند الکترونیکی تبدیل می‌کند؛ در حالی که تحول دیجیتال به معنی بازنگری در خود فرآیند است.
از تجربه‌های گذشته تا طراحی معماری جدید BI
پروژه هوش تجاری برای ما پروژه‌ای کاملا جدید و بدون سابقه نبود. در دوره‌های گذشته نیز اقداماتی برای BI انجام شده بود و همین تجربه‌ها کمک کرد نقاط قوت، نقاط ضعف و برخی دلایل متوقف شدن پروژه‌های قبلی را بهتر بشناسیم. یکی از درس‌های مهم این بود که BI نباید به چند داشبورد، چند فایل Excel، یک پیمانکار یا چند فرد مشخص وابسته باشد. اگر معماری داده و فرآیند انتقال اطلاعات سازمانی نباشد، با تغییر افراد یا مدیریت، کل پروژه می‌تواند متوقف شود.
بر این اساس، در معماری جدید هدف اصلی ایجاد یک Single Source of Truth بود؛ یعنی تا حد امکان برای هر شاخص مدیریتی، منبع داده مشخص و قابل ردیابی وجود داشته باشد. در فاز نخست، ابتدا منابع داده موجود در شرکت‌ها شناسایی شدند. سیستم‌های مالی، خزانه، دریافت و پرداخت، منابع انسانی، تولید، فروش، انبار و سایر سامانه‌های عملیاتی هر یک بخشی از اطلاعات مورد نیاز مدیریت هلدینگ را در اختیار داشتند. به جای اینکه از شرکت‌ها بخواهیم مرتباً گزارش‌های جدید تولید کنند، تلاش شد از طریق دسترسی‌های کنترل‌شده و عمدتاً Read-Only، اطلاعات مستقیماً از منابع عملیاتی دریافت شود.
داده‌ها پس از Extract شدن، در فرآیندهای ETL پاک‌سازی، تبدیل و استاندارد شده و در لایه متمرکز اطلاعاتی و Data Warehouse قرار می‌گیرند و سپس ابزارهای BI بر روی این لایه قرار می‌گیرند. این تفاوت بسیار مهم است؛ زیرا Power BI یا هر ابزار Visualization دیگری تنها آخرین لایه‌ای است که مدیر مشاهده می‌کند.ارزش واقعی پروژه در زیر این لایه قرار دارد؛ یعنی معماری داده، مدل اطلاعاتی، کیفیت داده، Transformation، Dictionary شاخص‌ها و کنترل منبع اطلاعات.
BI فقط داشبورد نیست
یکی از برداشت‌های اشتباه درباره هوش تجاری این است که BI را معادل طراحی داشبورد بدانیم. داشبورد فقط Visualization است. ممکن است یک داشبورد از نظر گرافیکی بسیار حرفه‌ای باشد، اما اگر Data Model آن صحیح نباشد یا داده‌هایی که به آن وارد می‌شود تعریف یکسانی نداشته باشند، آن داشبورد می‌تواند تصمیم مدیریتی را به مسیر اشتباه ببرد.
در اجرای پروژه به موارد متعددی برخورد کردیم که یک محصول، یک شاخص یا حتی یک مفهوم مالی در شرکت‌های مختلف یا سیستم‌های مختلف با تعاریف متفاوت ثبت شده بود. برای مثال در حوزه تولید، ممکن است طبقه‌بندی یک محصول در ERP شرکت با طبقه‌بندی گزارش‌های رسمی متفاوت باشد. در این شرایط صرفاً جمع زدن اعداد کار درستی نیست؛ ابتدا باید Data Mapping و استانداردسازی انجام شود. به همین دلیل، بخش مهمی از پروژه BI نه برنامه‌نویسی و نه طراحی نمودار، بلکه Data Quality Management و ایجاد زبان مشترک اطلاعاتی میان شرکت‌ها بوده است.
هدف این است که وقتی مدیر عددی را در داشبورد مشاهده می‌کند، بتواند در صورت نیاز از شاخص کلان تا سطح جزئیات و منبع داده حرکت کند؛ همان چیزی که در ادبیات BI از آن به عنوان Drill Down و Traceability یاد می‌شود.
دسترسی مدیریت از شاخص کلان تا منشا داده
یکی از نتایج مهم فاز نخست این بود که امکان مشاهده اطلاعات از سطح هلدینگ تا جزئیات عملیاتی شرکت‌ها فراهم شد.امروز می‌توان روند تولید، فروش، منابع انسانی، وضعیت مالی، نقدینگی یا موجودی را در سطح گروه بررسی کرد، شرکت‌ها را با یکدیگر مقایسه کرد و در صورت مشاهده یک عدد غیرعادی، به سطوح پایین‌تر اطلاعات رفت. اهمیت این موضوع فقط در دیدن یک عدد نیست. ارزش اصلی در کاهش فاصله زمانی میان ایجاد یک سؤال مدیریتی و رسیدن به داده‌ای است که می‌تواند به آن سؤال پاسخ دهد.
در مدل سنتی، ممکن است مدیر اطلاعاتی را درخواست کند؛ نامه‌ای تهیه شود، موضوع به شرکت‌ها ارسال شود، فایل‌ها دریافت شوند، کارشناسان آنها را تجمیع کنند و نهایتاً بعد از چند روز یا حتی چند هفته گزارش تولید شود. در معماری مطلوب ما، اطلاعاتی که همین امروز در سیستم‌های سازمان ثبت شده است، نباید دوباره از طریق مکاتبه جمع‌آوری شود. داده باید یک‌بار تولید شود و بارها مورد استفاده قرار گیرد.
امنیت و زیرساخت، بخشی از معماری BI است
طبیعتا اتصال اطلاعات شرکت‌های تابعه به یک بستر مرکزی بدون طراحی امنیتی قابل قبول نیست. از ابتدا تلاش شد امنیت به‌عنوان بخشی از Architecture پروژه دیده شود، نه اینکه پس از پایان پروژه به آن اضافه شود. تفکیک دسترسی‌ها، استفاده از ارتباطات امن، دسترسی Read-Only، کنترل کاربران، Role-Based Access Control، RLS، MFA، WAF و سایر کنترل‌های امنیتی، بخشی از همین رویکرد است. در کنار آن، BI و سیستم‌سازی بدون زیرساخت پایدار امکان‌پذیر نیست. افزایش حجم اطلاعات، توسعه Data Warehouse و اتصال شرکت‌های بیشتر به معنای افزایش نیاز به Storage، Compute، Backup و Network است.
بنابراین موضوع نوسازی زیرساخت ذخیره‌سازی، بازنگری معماری Backup، افزایش تاب‌آوری سرویس‌ها و طراحی Disaster Recovery نیز هم‌زمان با توسعه سیستم‌های اطلاعاتی دنبال شده است. اگر Storage پایدار نباشد، Backup قابل بازیابی وجود نداشته باشد یا ارتباط شبکه دچار اختلال دائمی باشد، نمی‌توان درباره Data-Driven Management صحبت کرد. به همین دلیل من زیرساخت، امنیت، داده و نرم‌افزار را چهار موضوع جدا از هم نمی‌بینم؛ همه اینها اجزای یک معماری واحد هستند.
فاز دوم؛ جایی که داده هنوز تولید نمی‌شود
پس از اتصال به سامانه‌های موجود، با مسئله مهم دیگری روبه‌رو شدیم. در بسیاری از حوزه‌ها اساسا سیستم عملیاتی متمرکزی وجود ندارد. برای مثال، ممکن است مدیرعامل بخواهد در یک لحظه بداند وضعیت پروژه‌های شرکت‌های تابعه چیست، هر پروژه چند درصد پیشرفت دارد، چه میزان انحراف زمانی یا مالی دارد، یا پرونده‌های حقوقی شرکت‌ها چه تعداد هستند و در چه مرحله‌ای قرار دارند.
ممکن است این اطلاعات در سازمان وجود داشته باشد، اما در Excel، PDF، نامه یا فایل‌های مختلف پراکنده باشد. اینجا دیگر BI به‌تنهایی پاسخگو نیست. BI زمانی می‌تواند تحلیل انجام دهد که Data وجود داشته باشد. بنابراین فاز دوم را بر مبنای Systemization یا سیستم‌سازی تعریف کردیم. در حوزه‌هایی مانند بودجه و عملکرد، مدیریت پروژه، حقوقی، قراردادها، املاک، مجامع و پایش هیئت‌مدیره، ابتدا باید فرآیند اطلاعاتی ساختارمند شود تا Data Pointهای استاندارد ایجاد شود و سپس این داده‌ها وارد BI شوند.این تفاوت میان «سامانه عملیاتی» و «سامانه تحلیلی» بسیار مهم است. BI سیستم تولید داده نیست؛ BI مصرف‌کننده و تحلیل‌کننده داده‌ای است که توسط فرآیندهای سازمان تولید شده است.
سپهر؛ لایه سیستم‌سازی اطلاعات مدیریتی
یکی از راهکارهایی که برای این مسئله طراحی شد، «سپهر» یا سامانه یکپارچه پایش و راهبری اطلاعات مدیریتی بود. ایده سپهر از یک مسئله کاملا عملیاتی شکل گرفت. در بسیاری از فرآیندهای گروه، فایل‌های Excel چندلایه برای شرکت‌ها ارسال می‌شوند. افراد مختلف بخش‌هایی از فایل را تکمیل می‌کنند، نسخه‌های مختلف ایجاد می‌شود و نهایتاً کارشناسان ستاد باید این فایل‌ها را کنترل و تجمیع کنند. این مدل نه فقط زمان‌بر است، بلکه مشکلاتی مانند Version Control، خطای انسانی، نبود Audit Trail و دشواری کنترل کیفیت اطلاعات ایجاد می‌کند. در سپهر تلاش شده این مدل به یک فرآیند Web-Based و Workflow-Oriented تبدیل شود. هر کاربر بر اساس سطح دسترسی اطلاعات مربوط به خود را ثبت می‌کند، گردش تأیید تعریف می‌شود، تغییرات قابل ردیابی هستند و در پایان، داده ساختاریافته مستقیماً می‌تواند وارد لایه BI شود.
در نتیجه زنجیره اطلاعات از حالت: Excel → Email → Excel → تجمیع دستی → گزارش به سمت: Data Entry → Workflow → Validation → Database → Data Warehouse → BI حرکت می‌کند. این تغییر از نظر من یکی از پایه‌های واقعی تحول دیجیتال است.
از گزارش عملکرد به سیستم مدیریت عملکرد
مرحله بعدی، فراتر رفتن از گزارش‌گیری است. BI عمدتا به ما می‌گوید اکنون کجا هستیم و در گذشته چه اتفاقی افتاده است. اما مدیریت عملکرد سؤال مهم‌تری دارد:
قرار بود اکنون کجا باشیم؟
اگر یک شرکت ۱۰۰ واحد تولید کرده است، خود عدد ۱۰۰ به‌تنهایی خوب یا بد نیست. باید بدانیم برنامه چه بوده، بودجه چه عددی را پیش‌بینی کرده، هدف استراتژیک چیست و نسبت به زمان چه میزان انحراف داریم. بنابراین برنامه استراتژیک، بودجه، عملکرد و KPIها باید به یکدیگر متصل شوند.
در معماری کامل‌تر، برنامه استراتژیک باید به اهداف کمی شکسته شود، اهداف به بودجه و برنامه اجرایی متصل شوند و عملکرد ماهانه یا فصلی در مقابل Target اندازه‌گیری شود. در این نقطه دیگر فقط با Business Intelligence روبه‌رو نیستیم؛ به سمت Performance Management حرکت می‌کنیم. یعنی سیستم باید علاوه بر Actual، مقدار Target، Variance، Trend و در آینده Forecast را نیز در اختیار مدیر قرار دهد.
داده؛ پیش‌نیاز واقعی هوش مصنوعی در سال‌های اخیر همه درباره هوش مصنوعی صحبت می‌کنند، اما به نظر من پیش‌نیاز اصلی استفاده سازمانی از AI کمتر مورد توجه قرار می‌گیرد. هوش مصنوعی بدون داده سازمان‌یافته و قابل اعتماد، ابزار تصمیم‌سازی قابل اتکایی نیست. پیش از هر چیز باید Data Infrastructure ایجاد شود.
بعد Data Quality، Data Governance، Access Control و Data Warehouse شکل بگیرند و سپس AI می‌تواند روی این بستر قرار گیرد. چشم‌اندازی که دنبال می‌کنیم این است که در آینده مدیر حتی برای دریافت بسیاری از اطلاعات مجبور نباشد میان صفحات مختلف داشبورد حرکت کند. مدیر باید بتواند به زبان طبیعی بپرسد: روند سه‌ساله تولید این شرکت چگونه بوده است؟ کدام شرکت بیشترین انحراف از بودجه را دارد؟ وضعیت نقدینگی شرکت‌ها نسبت به دوره مشابه چگونه تغییر کرده است؟ و سیستم بتواند با استفاده از داده مورد اعتماد سازمان پاسخ دهد. در اینجا ترکیب Data Warehouse + BI + AI معنا پیدا می‌کند.ولی اگر داده صحیح نباشد، هوش مصنوعی صرفا پاسخ نادرست را سریع‌تر تولید خواهد کرد.
تغییر نقش کارشناسان؛ از جمع‌آوری داده
به تحلیل داده یکی از مهم‌ترین اهداف این معماری، تغییر نقش کارشناسان سازمان است. کارشناس متخصص نباید بخش زیادی از وقت خود را صرف تماس، نامه‌نگاری، دریافت Excel و تجمیع دستی اطلاعات کند.کارشناس بودجه باید بودجه را تحلیل کند. کارشناس امور شرکت‌ها باید عملکرد شرکت‌ها را پایش کند. کارشناس حقوقی باید ریسک پرونده‌ها را تحلیل کند. و کارشناس فناوری اطلاعات باید معماری، امنیت، داده و سرویس را مدیریت کند. جمع‌آوری و انتقال تکراری اطلاعات تا حد امکان باید توسط سیستم انجام شود. این همان نقطه‌ای است که فناوری می‌تواند Productivity واقعی ایجاد کند.
داده‌محوری را از خود واحد فناوری اطلاعات آغاز کردیم
طبیعتا اگر قرار باشد درباره اندازه‌گیری عملکرد و Data-Driven Management صحبت کنیم، باید ابتدا این تفکر را در واحد خودمان اجرا کنیم.بر همین اساس، مدیریت Taskها و فعالیت‌های واحد فناوری اطلاعات به‌صورت ساختاریافته‌تر دنبال شده است. صرف تعداد Task معیار مناسبی برای ارزیابی عملکرد نیست. یک کارشناس ممکن است ده‌ها فعالیت روزمره انجام دهد، در حالی که یک متخصص زیرساخت یا امنیت با حل یک Incident بحرانی از توقف چندین ساعت سرویس‌های سازمان جلوگیری کند. بنابراین در ارزیابی باید متغیرهایی مانند Priority، SLA، Impact، Progress، Delay، Complexity و Weight نیز دیده شوند. این نگاه کمک می‌کند عملکرد افراد، حجم کار تیم و نقاط Bottleneck بر اساس داده بررسی شود، نه صرفاً برداشت شخصی.
نقش تیم؛ تحول فناوری یک پروژه فردی نیست
یکی از مهم‌ترین واقعیت‌هایی که در این مسیر وجود دارد این است که هیچ پروژه تحول فناوری با یک فرد اجرا نمی‌شود. در کنار حمایت مدیریت ارشد، همراهی مدیران، معاونت‌ها، شرکت‌های تابعه و کارشناسان تخصصی، وجود یک تیم فنی حرفه‌ای ضروری است. زیرساخت، امنیت، تحلیل داده، توسعه سیستم، Help Desk و مدیریت پروژه هر یک دانش تخصصی خود را نیاز دارند. حفظ نیروهای متخصص نیز به اندازه جذب آنها اهمیت دارد. دانش سازمانی و شناخت Architecture موجود چیزی نیست که بتوان آن را صرفا با خرید خدمات بیرونی جایگزین کرد. پیمانکار می‌تواند بخشی از کار را انجام دهد، اما مالکیت دانش، Data Model، Architecture و فرآیند باید در داخل سازمان باقی بماند.
تحول دیجیتال، قبل از فناوری یک تغییر فرهنگی است
در نهایت، هیچ‌کدام از این پروژه‌ها بدون تغییر فرهنگ سازمانی به نتیجه مطلوب نمی‌رسد. تحول دیجیتال یعنی روش انجام کار نیز تغییر کند. وقتی یک فرآیند سال‌ها با نامه و Excel انجام شده است، تبدیل آن به سیستم طبیعتاً مقاومت‌هایی ایجاد می‌کند. هدف فناوری اطلاعات حذف کارشناسان یا کم‌رنگ کردن نقش آنها نیست؛ برعکس، هدف حذف کارهای کم‌ارزش و تکراری است تا نیروی متخصص بتواند وقت خود را صرف تحلیل، کنترل و تصمیم‌سازی کند. فرهنگی که باید ایجاد شود، فرهنگ ساختاریافته، قابل اندازه‌گیری، ساده و هوشمندانه کار کردن است.
اگر اطلاعات یک‌بار در سیستم تولید شده است، منطقی نیست همان اطلاعات دوباره با نامه از شرکت مطالبه شود. اگر فرآیندی را می‌توان با Workflow کنترل کرد، نباید وابسته به گردش دستی فایل باشد. و اگر داده‌ای به‌صورت آنلاین وجود دارد، نباید برای تولید گزارش آن چند روز زمان صرف شود.
مسیر آینده؛ از فناوری اطلاعات به زیرساخت تصمیم‌سازی
مسیری که آغاز شده را می‌توان در چند لایه متوالی دید. در لایه نخست، باید زیرساخت پایدار، امن و قابل اتکا داشته باشیم. در لایه دوم، سامانه‌های عملیاتی و فرآیندهای سازمان باید Data تولید کنند.در لایه سوم، داده‌ها باید استاندارد، پاک‌سازی و در Data Warehouse یکپارچه شوند. در لایه بعد، BI این اطلاعات را به شاخص‌های مدیریتی تبدیل می‌کند. سپس Performance Management عملکرد واقعی را با اهداف و برنامه مقایسه می‌کند. و در مرحله بلوغ بالاتر، Analytics و Artificial Intelligence می‌توانند بر اساس همین داده معتبر، تحلیل، Forecast و ابزارهای هوشمند تصمیم‌سازی ایجاد کنند.
به بیان خلاصه، معماری مورد نظر ما چنین مسیری را دنبال می‌کند: Secure Infrastructure → Digital Process → Structured Data → Data Governance → Data Warehouse → Business Intelligence → Performance Management → Advanced Analytics & AI تمام تلاش ما این است که فناوری اطلاعات از یک واحد صرفا پشتیبان، به بخشی از سیستم مدیریت سازمان تبدیل شود.
در این مسیر، حمایت و نگاه توسعه‌محور دکتر پناهی و همراهی تیم مدیریتی وقت، امکان آغاز و پیشبرد بخشی از این تغییرات را فراهم کرد و زمینه‌ای ایجاد شد تا تجربه‌های گذشته، نیازهای واقعی مجموعه و ظرفیت‌های فناوری در قالب یک معماری منسجم‌تر کنار یکدیگر قرار گیرند. هدف نهایی نیز صرفا تحویل چند پروژه فناوری نیست.
هدف این است که سازمان به نقطه‌ای برسد که داده یک دارایی مدیریتی باشد، اطلاعات به‌موقع در اختیار تصمیم‌گیر قرار گیرد، انحرافات سریع‌تر دیده شوند و تصمیمات بر مبنای شواهد واقعی سازمان اتخاذ شوند. در چنین نقطه‌ای، فناوری اطلاعات دیگر صرفاً پاسخ‌دهنده مشکلات روزانه نیست؛ بلکه به زیرساخت شفافیت، پایش، کنترل و تصمیم‌سازی هوشمند سازمان تبدیل می‌شود. کل‌گیری فرهنگ سازمانی مبتنی بر داده نیاز دارد.
به اشتراک بگذارید:
لینک خبر: