پروپوزال استقرار سامانه هوش تجاری

گروه اقتصادی شیران، به‌عنوان یک حوزه سرمایه‌گذاری متنوع و چندوجهی، در ۱۲ حوزه موضوعی از تجهیزات پزشکی تا سنگ‌های قیمتی و در ۱۴ کشور از ایران تا کانادا فعالیت دارد. این گستردگی، مزیت رقابتی گروه است؛ اما در عین حال، چالشی جدی را ایجاد کرده است: مالک گروه قادر نیست تصویری یکپارچه، دقیق و بهنگام از وضعیت دارایی‌ها، عملکرد موجودیت‌ها و ریسک‌های پرتفوی خود داشته باشد.

در وضعیت فعلی، تصمیمات راهبردی مالک — اعم از توسعه، بهبود، اصلاح، توقف، ادغام یا واگذاری دارایی‌ها — بر اساس اطلاعات پراکنده، ناهمگن و غالباً تأییدنشده گرفته می‌شوند. سیستم‌های اطلاعاتی فعلی گروه (حسابداری، اتوماسیون) در حال تعویض هستند و هیچ سامانه نمایشگر یکپارچه‌ای وجود ندارد. این وضعیت، تصمیم‌گیری را به یک فرآیند «نیمه‌کور» تبدیل کرده است.

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

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

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

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

نتیجه عملی این وضعیت این است که تصمیمات راهبردی مالک — که بر سر پروژه‌های چند صد میلیاردی و حوزه‌های متفاوت است — بر اساس شهود و گزارش‌های تأییدنشده گرفته می‌شوند. در یک پرتفوی با این گستردگی، عدم visibility معادل پرواز در مه است.

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

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

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

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

این تمایز فقط نظری نیست. ترتیب اجرایی در عمل تعیین‌کننده است: اگر ابتدا به سراغ تعریف KPI و ساخت داشبورد برویم، در مرحله اجرا متوجه می‌شویم داده‌ای برای محاسبه آن KPIها وجود ندارد. این دقیقاً همان مشکلی است که در بسیاری از پروژه‌های BI ناموفق رخ می‌دهد — «garbage in, garbage out». رویکرد ساختارمند این است که ابتدا منابع داده را شناسایی کنیم، سپس ساختار یکپارچه را تعریف کنیم، بعد KPI را بر اساس داده واقعی طراحی کنیم، و در نهایت BI را استقرار دهیم.

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

این دو مسیر مستقل نیستند — مسیر اول خوراک مسیر دوم است. تحلیل داده موجود در مسیر اول، اطلاعاتی فراهم می‌کند که برای طراحی target schema و mapping rules در مسیر دوم ضروری است. بدون مسیر اول، تیم مسیر دوم می‌بایست از صفر شروع کند و نمی‌دانست داده‌های موجود چه ساختاری دارند. همچنین، موفقیت مسیر اول به مالک نشان می‌دهد که این تیم قادر به تحویل است و اعتماد لازم برای سرمایه‌گذاری در مسیر دوم را ایجاد می‌کند.

این مسیر از هفت نود متوالی تشکیل شده است. هر نود یک تحویل مشخص دارد و در پایان هر نود، تیم و کارفرما می‌دانند دقیقاً چه چیزی到手 reaching شده است. نودها به‌صورت خطی پیش می‌روند، ولی نود ۱ و شروع طراحی target schema در نود ۴ می‌توانند موازی با نود ۲ پیش بروند — تیم تحلیل داده می‌تواند شروع کند به طراحی schema در حالی که تیم مالی/حقوقی پروتکل را تدوین می‌کند.

نکته مهم درباره واقع‌بینی: داده دریافتی در نود ۳ ناقص، ناهمگن و با کاستی خواهد بود. این قابل پذیرش است — هدف این مسیر «داده ایده‌آل» نیست، «داده موجود» است. هر منبع داده با امتیاز کیفیت ثبت می‌شود تا در تحلیل نود ۶، وزن داده ضعیف کمتر از داده قوی باشد. گزارش تحلیلی نود ۶ باید صریحاً نشان دهد کدام تحلیل بر داده قوی است، کدام بر داده ضعیف (با هشدار)، و کجا اصلاً تحلیل ممکن نیست (داده غایب).

این مسیر از هشت نود تشکیل شده و هدف آن ساختن زیرساخت پایدار است. دو تیم می‌توانند موازی کار کنند: تیم مالی/حقوقی روی نودهای ۱، ۲ و ۴ (ساختار، پروتکل، KPI)، و تیم فنی روی نودهای ۳، ۵ و ۶ (schema، ماشین، داشبورد). این دو مسیر در نود ۶ به هم می‌رسند. نود ۸ پایان ندارد — چون نیاز مالک استمراری است و هزینه پایدار نگهداری باید جداگانه برآورد شود.

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

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

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

رویکرد صحیح این است که از بالا شروع کنیم: مالک چه می‌خواهد بداند؟ برای بدانیدن آن، چه شاخصی لازم است؟ آن شاخص از کدام داده محاسبه می‌شود؟ آن داده از کجا می‌آید و چگونه ثبت می‌شود؟ این ترتیب تضمین می‌کند که KPIهایی تعریف نشوند که داده‌ای برای محاسبه‌شان نیست.

در این مثال، مالک می‌پرسد «آیا این سرمایه‌گذاری سودآور است؟». برای پاسخ، شاخص ROI (بازده سرمایه‌گذاری) لازم است. ROI از داده‌های درآمد، هزینه و سرمایه اولیه محاسبه می‌شود. این داده‌ها از سیستم حسابداری موجودیت می‌آیند. اگر سیستم حسابداری این داده‌ها را نداشته باشد، یا کیفیت داده پایین باشد، می‌دانیم که اول باید داده را درست کنیم — نه اینکه KPI تعریف کنیم که قابل محاسبه نیست.

هر نوع تصمیم مالک به KPIهای متفاوتی نیاز دارد. این ماتریس نشان می‌دهد کدام KPI برای کدام تصمیم مرتبط است:

ما در schema خود ریسک را به‌عنوان یک دسته KPI اضافه کردیم، ولی ریسک سرمایه‌گذاری فقط یک شاخص نیست. برای یک پرتفوی با ۱۴ کشور و ۱۲ حوزه، چهار نوع ریسک باید جداگانه ارزیابی و پوشش داده شود. این ریسک‌ها در سطح هر موجودیت و در سطح تجمیعی پرتفوی باید تحلیل شوند.

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

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

سه نوع جریان نقدی باید ثبت و پایش شود: اول، وضعیت نقدی هر موجودیت (ماهانه) — موجودی ابتدا و انتهای دوره، ورود و خروج نقدی، خالص جریان. دوم، جریان نقدینگی بین موجودیت‌ها — سرمایه‌گذاری جدید مالک در یک موجودیت، سود تقسیمی به مالک، وام بین موجودیت‌ها. سوم، پیش‌بینی نیاز سرمایه‌ای آینده — بر اساس روند جریان نقدی، کدام موجودیت در ماه‌های آینده به تزریق نقدینگی نیاز خواهد داشت.

این پایش به مالک اجازه می‌دهد هشدارهای پیشگیرانه دریافت کند — مثلاً وقتی موجودیتی سه ماه پیاپی جریان نقدی منفی دارد، یا وقتی نقدینگی گروه در حال کاهش است. این هشدارها می‌توانند به تصمیمات توقف، تأمین مالی، یا واگذاری منجر شوند.

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

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

دو مسیر به‌صورت موازی پیش می‌روند. تیم مالی/حقوقی روی نودهای ساختار و پروتکل و KPI کار می‌کند، تیم فنی روی نودهای schema و ماشین و داشبورد. این دو مسیر در نود داشبورد BI (نود ۶ مسیر دوم) به هم می‌رسند — جایی که KPI تعریف‌شده توسط تیم مالی در داشبورد ساخته‌شده توسط تیم فنی نمایش داده می‌شود.

نقاط هم‌گام‌سازی مهم: خروجی نود ۱ مسیر اول (طبقه‌بندی موجودیت‌ها) ورودی نود ۱ مسیر دوم است. خروجی نود ۴ مسیر اول (target schema اولیه) ورودی نود ۳ مسیر دوم است. خروجی نود ۶ مسیر اول (تحلیل وضعیت) اولویت‌بندی مسیر دوم را تعیین می‌کند. و خروجی نود ۲ مسیر اول (پروتکل گزارش‌دهی) پایه نود ۲ مسیر دوم (پروتکل پایدار) است.

برآورد بر اساس نفر-ساعت نیروهای متخصص محاسبه می‌شود. هر نود در هر مسیر، نقش‌های مشخصی با ساعت مشخص نیاز دارد. هزینه هر نود = مجموع (ساعت نقش × ضریب تعدیل × نرخ ساعتی). این روش شفاف‌ترین روش برآورد است چون دقیقاً نشان می‌دهد چه کسی، چقدر، روی چه کاری وقت می‌گذارد.

نکته مهم: نود ۸ مسیر دوم (عملیات جاری) پایان ندارد و هزینه ماهانه پایدار دارد. این هزینه شامل نگهداری pipeline، رفع خطا، افزودن منبع داده جدید، و به‌روزرسانی KPI است. این هزینه باید در برآورد جداگانه لحاظ شود — نه در هزینه یک‌باره پروژه.

ماشین‌حساب تعاملی به کارفرما اجازه می‌دهد نودها را انتخاب/حذف کند و نتیجه را زنده ببیند. این یعنی کارفرما می‌تواند دامنه پروژه را بر اساس بودجه خود تنظیم کند — مثلاً فقط مسیر اول را اجرا کند، یا مسیر دوم را بدون نود ۸ (عملیات جاری) شروع کند.

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