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