کیفیت داده مالی؛ ماتریس منشأ و روانی داده
بیشتر مشکل‌هایی که به «ضعف نرم‌افزار» نسبت داده می‌شوند، در واقع مشکل داده‌اند. برای اصلاح کیفیت داده مالی لازم نیست از یک برنامه‌ی عظیم حاکمیت داده شروع کنید. دو پرسش ساده کافی است: داده در لحظه‌ی رویداد ثبت می‌شود یا نه، و پس از ثبت به جایی که لازم است می‌رسد یا نه. پاسخ این دو، نقشه‌ی اصلاح را مشخص می‌کند.
منشأ داده: رویداد واقعی چقدر وفادارانه ثبت می‌شود؟
منشأ داده یعنی هر رویداد مالی (سفارش مواد، استخدام، فروش) در همان لحظه چقدر به داده‌ی دقیق تبدیل می‌شود. چند پرسش محک است:
- ثبت در لحظه انجام می‌شود یا دسته‌ای و در پایان ماه؟
- در سطح واحد کالا ثبت می‌شود یا فقط مجموع؟
- چه اطلاعات توصیفی (مشتری، محصول، مرکز هزینه) همراه ثبت است؟
مدل کسب‌وکار اینجا نقش بزرگی دارد. در یک شرکت نرم‌افزاری، ثبت‌نام مشتری یا افزایش مصرف ابری خودبه‌خود داده‌ی دقیق می‌سازد. در نقطه‌ی مقابل، فروشنده‌ی دوره‌گردی را تصور کنید که نقد می‌خرد و نقد می‌فروشد: جز موجودی نقد و کالای اول و آخر روز هیچ داده‌ای تولید نمی‌شود. این به معنای ناممکن‌بودن داده‌ی خوب بدون پلتفرم نیست؛ فقط یعنی باید آگاهانه حلقه‌ی اتصال میان دنیای فیزیکی و دنیای دیجیتال را ساخت.
روانی داده: ثبت‌شده‌ها به مقصد می‌رسند؟
روانی داده یعنی اطلاعات ثبت‌شده چقدر راحت به جایی می‌روند که تصمیم در آن گرفته می‌شود. نمونه‌ی خوب، شرکتی است که تراکنش درگاه پرداخت به‌طور خودکار وارد انبار داده می‌شود و تیم مالی تقریباً بلافاصله آن را در گزارش می‌بیند.
نمونه‌ی بد را فرض کنید: یک تولیدکننده‌ی متوسط ERP مناسبی دارد و تولید، دستور کار و مصرف مواد را دقیق ثبت می‌کند. اما این داده در ماژول عملیات می‌ماند و تیم مالی نه دسترسی دارد و نه می‌داند چگونه بپرسد. برای دانستن حاشیه‌ی سود هر خط محصول باید از واحد فناوری خروجی بگیرند، با چند صفحه‌گسترده تلفیق کنند و سه روز کار بگذارند. داده گم نشده؛ در بن‌بست مانده است. همین وضع درباره‌ی داده‌ی فروش (قرارداد، تخفیف، شرایط پرداخت) در سامانه‌ی مدیریت مشتری تکرار می‌شود.
چهار وضعیت داده در یک جدول
اگر این دو محور را کنار هم بگذارید، چهار وضعیت پیدا می‌شود:
| وضعیت | منشأ داده | روانی داده | ماهیت مشکل |
|---|---|---|---|
| وضعیت ایده‌آل | خوب | بالا | فقط نگهداری و بهبود تدریجی |
| فقر فناوری | خوب | ضعیف | سیستم نامناسب یا پیاده‌سازی ضعیف |
| تجهیزات فراوان، ایده کم | ضعیف | بالا | مشکل فرایندی؛ ابزار گران، ثبت ناقص |
| عصر تاریکی | ضعیف | ضعیف | هر دو مشکل؛ دشوارترین نقطه‌ی شروع |
نکته‌ی مهم در وضعیت سوم است: خرید یک ERP گران برای حل مشکل داده، اگر شکاف میان فرایند واقعی و سیستم بزرگ باشد، جواب نمی‌دهد. فناوری فرایند معیوب را درست نمی‌کند؛ راه‌حل در خود فرایندهاست و میان‌بر ندارد.
واقعیت: معمولاً در هر چهار وضعیت هستید
یک شرکت کم پیش می‌آید که کاملاً در یک خانه باشد. ممکن است چرخه‌ی سفارش تا وصول و خرید تا پرداخت تمیز باشد، اما موجودی کالا (و در نتیجه بهای تمام‌شده و حاشیه‌ی سود) هنوز به شمارش پایان ماه تکیه کند که کسی کاملاً به آن اعتماد ندارد. یا یک واحد تجاری همه‌چیز را در لحظه ثبت کند و واحد دیگر با صفحه‌گسترده در پایان ماه جبران کند. مورد دوم مشکل توانمندی نیست، مشکل یکنواختی است و ساده‌تر حل می‌شود چون روش درست از قبل در شرکت وجود دارد.
پس اولین گام تفکیک است. مشکل داده را می‌توان بر اساس این‌ها نقشه‌کشی کرد:
- واحد کسب‌وکار یا گروه محصول
- منطقه‌ی جغرافیایی
- کارکرد سازمانی
- چرخه‌ی فرایندی
آن‌گاه یک مسئله‌ی غول‌آسا به چند مسئله‌ی کوچک‌تر تبدیل می‌شود و می‌بینید درد کجا بیشتر است. برای آشنایی با اصول گزارش‌دهی مبتنی بر داده‌ی قابل‌اتکا، داده‌ی قابل‌اتکا برای گزارش مالی را بخوانید.
چه چیزی اصلاح را سخت می‌کند؟
دو عامل ضریب پیچیدگی را بالا می‌برند:
- ریشه‌دواندن پشته‌ی فناوری. سیستم فقط با قدمت سنجیده نمی‌شود، با بار تحمل‌شده سنجیده می‌شود: سال‌ها سفارشی‌سازی، اتصال‌های وابسته، فرایندهای طراحی‌شده بر محدودیت‌های سیستم و دانشی که فقط داخل همان سیستم زندگی می‌کند. هرچه این وابستگی بیشتر، هزینه‌ی جابه‌جایی بالاتر.
- پیچیدگی مدل کسب‌وکار. یک محصول، یک قیمت، یک نهاد و یک ارز را به‌راحتی می‌شود ثبت کرد. چند منبع درآمد، صورت‌حساب مرحله‌ای، شناسایی درآمد پیچیده، ساختار چندنهادی و فعالیت فرامرزی، ثبت وفادارانه را گران و شکننده می‌کند.
کسب‌وکارهای قدیمی‌تر هر دو بار را با هم دارند و معمولاً فرهنگ مهندسی داده‌ی نزدیک به مالی هم ندارند.
اولویت: ابتدا منشأ، سپس ابزارها
یک استدلال رایج می‌گوید ابزارهای هوش مصنوعی اکنون می‌توانند داده‌ی نامرتب و بدون ساختار را سروسامان بدهند، پس لازم نیست پیش از استفاده منتظر داده‌ی کاملاً تمیز بمانیم. تا حدی درست است: یک انباشت بزرگ و ناهمگون از داده گاهی از مجموعه‌ی کوچک و بی‌نقص باارزش‌تر است. اما این ابزارها بدون داده کار نمی‌کنند. اگر شکاف میان آنچه در کسب‌وکار رخ می‌دهد و آنچه ثبت می‌شود بزرگ باشد، هیچ ابزاری آن را پر نمی‌کند. بنابراین بهبود منشأ داده حرکتی بی‌پشیمانی است، حتی اگر فعلاً داده‌ها نامرتب باشند. برای دیدن اینکه چرا زمینه‌ی داده برای عامل‌های هوشمند مهم است، عامل هوش مصنوعی در مالی؛ چهار پایه‌ی زمینه و داده مفید است.
هر کسب‌وکار را می‌توان سه چرخه دید: آنچه می‌خرد، آنچه می‌فروشد و آنچه می‌سازد. چرخه‌ی فروش معمولاً دیجیتال است، چون بدون آن صدور فاکتور ممکن نیست؛ خرید هم با سفارش‌خرید منظم تا حد خوبی پوشش داده می‌شود. چرخه‌ی ساخت سخت‌تر است، چون رابطه‌ی میان ورودی‌ها و خروجی‌ها را می‌گیرد: هزینه‌ها، تبدیل‌ها و مراحل عملیاتی میان خرید و فروش. ارزش تحلیلی هم همین‌جاست.
مثال: حاشیه‌ی سود
سطح قابل‌ردیابی هزینه در چرخه‌ی ساخت، سطحی را که حاشیه‌ی سود در آن دیده می‌شود تعیین می‌کند. فرض کنید فقط هزینه‌ی کل کارخانه را می‌دانید؛ حاشیه را فقط در سطح کارخانه می‌بینید. اگر هزینه را به شیفت، سپس به دسته‌ی تولید، بعد به محصول و در نهایت به واحد برسانید، حاشیه را هم در همان سطوح می‌بینید. برای ساده‌سازی ساختار حساب‌ها در این مسیر، ساده‌سازی سرفصل حساب‌ها هم کمک می‌کند.
پرسش‌های متداول
اگر داده‌هایمان نامرتب است، باید قبل از هر کاری آن را تمیز کنیم؟
لزوماً نه. مهم‌تر آن است که داده در منبع ثبت شود و در یک‌جا گرد آید. ساختاردهی دقیق را می‌توان بعداً و با ابزارهای ارزان‌تر انجام داد.
مسئول داده در شرکت کیست؟
داده مالک واحد ندارد؛ همه از مدیرعامل تا کارمند انبار در آن سهم دارند. به همین دلیل بهتر است به‌جای جست‌وجوی مالک، از اصلاح یک چرخه‌ی مشخص شروع کنید.
چرا خرید نرم‌افزار گران مشکل داده را حل نمی‌کند؟
چون اگر فرایند واقعی با سیستم همخوان نباشد، داده‌ی ناقص وارد سیستم می‌شود. ابزار فقط جابه‌جا می‌کند، نه جبران.
از کجا شروع کنیم؟
نقشه‌ی مشکل را به تفکیک واحد، منطقه، کارکرد یا چرخه بکشید، سپس جایی را که بیشترین ضرر را دارد اول اصلاح کنید.
جمع‌بندی
کیفیت داده مالی را با دو سنجه ارزیابی کنید: منشأ (آیا رویداد در منبع به‌دقت ثبت می‌شود) و روانی (آیا داده به مقصد می‌رسد). پاسخ، ماهیت مشکل را مشخص می‌کند: فناوری، فرایند یا هر دو. مشکل را تفکیک کنید، پیچیدگی هر بخش را بسنجید و از ثبت در منبع شروع کنید، زیرا هیچ ابزاری جای داده‌ی غایب را نمی‌گیرد.