چرا پروژههای هوش مصنوعی در واحد مالی شکست میخورند؟ پاسخ سریع
شکست پروژههای هوش مصنوعی در واحد مالی معمولاً فقط به ضعف خود فناوری مربوط نیست. بسیاری از پروژهها زمانی به مشکل میخورند که سازمان از ابزار شروع میکند، نه از مسئله؛ دادههای مالی نامرتب است؛ مسئول مشخصی برای نتیجه وجود ندارد؛ شاخص موفقیت تعریف نشده؛ سیستم هوشمند به نرمافزارهای واقعی شرکت وصل نیست؛ یا کنترل انسانی از ابتدا در طراحی دیده نشده است.
مسیر بهتر این است:
مسئله مالی مشخص ← وضعیت فعلی قابل اندازهگیری ← داده قابل اعتماد ← مسئول مشخص ← اجرای محدود ← کنترل انسانی ← اتصال به سیستمها ← اندازهگیری نتیجه ← توسعه مرحلهای
یعنی قبل از اینکه بپرسیم «از کدام ابزار هوش مصنوعی استفاده کنیم؟» باید بپرسیم:
«کدام مشکل مالی ارزش حلکردن دارد و از کجا میفهمیم واقعاً بهتر شده است؟»

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

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

مشکل هفتم: تیم مالی به سیستم اعتماد نمیکند
حتی اگر فناوری از نظر فنی خوب باشد، اگر حسابداران به خروجی آن اعتماد نکنند، استفاده واقعی اتفاق نمیافتد.
یکی از دلایل بیاعتمادی این است که سیستم فقط نتیجه را اعلام میکند اما توضیح نمیدهد چرا.
مثلاً میگوید:
«این مشتری پرریسک است.»
حسابدار حق دارد بپرسد:
«بر چه اساسی؟»
برای ایجاد اعتماد، بهتر است مشخص باشد سیستم از چه دادهای استفاده کرده، کدام قاعده اجرا شده و چرا یک مورد بهعنوان استثنا علامت خورده است.
این موضوع در حسابرسی، خزانهداری، مالیات، اعتبار و پرداخت اهمیت بیشتری دارد.
مشکل هشتم: تیم مالی در طراحی حضور ندارد
ممکن است یک پروژه از نظر فنی قوی باشد اما فرایند واقعی حسابداری را درست درک نکند.
مثلاً برنامهنویس ممکن است فرض کند هر فاکتور یک سند ساده است؛ در حالی که حسابدار با پیشپرداخت، فاکتور اصلاحی، فاکتور تکراری، تعدیلات و ثبتهای خاص مواجه است.
به همین دلیل متخصص مالی باید از ابتدای طراحی پروژه حضور داشته باشد.
ترکیب مناسب معمولاً شامل سه گروه است:
تیم مالی + تیم فناوری + متخصص داده و هوش مصنوعی
هیچکدام بهتنهایی کافی نیستند.
مشکل نهم: فرایند خراب را خودکار میکنیم
اگر فرایند فعلی ناکارآمد باشد، هوش مصنوعی فقط آن فرایند بد را سریعتر میکند.
فرض کنید یک درخواست پرداخت ۱۲ مرحله تأیید دارد.
سؤال اول نباید این باشد که:
«چطور این ۱۲ مرحله را با هوش مصنوعی سریعتر کنیم؟»
ابتدا باید پرسید:
«آیا واقعاً به هر ۱۲ مرحله نیاز داریم؟»
قبل از خودکارسازی، فرایند را ترسیم کنید، گلوگاهها را پیدا کنید، مراحل اضافی را حذف کنید و بعد سراغ فناوری بروید.
مشکل دهم: مدیریت تغییر فراموش میشود
بعضی پروژهها نه به دلیل ضعف فناوری، بلکه به دلیل مقاومت کارکنان متوقف میشوند.
اگر کارکنان تصور کنند هوش مصنوعی فقط برای حذف شغل آنها آمده است، ممکن است با سیستم همکاری نکنند یا همچنان روش قدیمی را ادامه دهند.
مدیریت باید روشن توضیح دهد:
- چرا این ابزار وارد شده است؟
- چه کاری از کارکنان کم میشود؟
- چه مسئولیت جدیدی به آنها اضافه میشود؟
- کدام مهارتها باید تقویت شوند؟
- چه زمانی باید خروجی سیستم را کنترل کنند؟
در سال ۲۰۲۶ نیز گزارشهای تخصصی مالی بر نقش اعتماد، آموزش، آمادگی نیروی انسانی و بازطراحی فرایندها در موفقیت هوش مصنوعی تأکید دارند.
برای آشنایی با ابزارهایی که میتوانند به حسابداران در تحلیل و خودکارسازی کمک کنند، مقاله بهترین ابزارهای هوش مصنوعی برای حسابداران در ۱۴۰۵ را ببینید.
مشکل یازدهم: پروژه بعد از راهاندازی رها میشود
هوش مصنوعی یک سیستم ثابت نیست.
داده تغییر میکند، مشتری تغییر میکند، فرایند تغییر میکند و شرایط کسبوکار عوض میشود.
بنابراین بعد از راهاندازی باید مرتب بررسی شود:
- دقت سیستم کاهش پیدا نکرده است؟
- تعداد موارد ردشده توسط حسابداران زیاد نشده است؟
- تعداد استثناها رو به افزایش نیست؟
- پیشنهادهای سیستم هنوز با واقعیت کسبوکار سازگار هستند؟
رد یا اصلاح پیشنهاد سیستم، یک منبع یادگیری است
اگر حسابدار پیشنهاد سیستم را رد کرد، فقط نباید این اتفاق ثبت شود؛ باید علت آن بررسی شود.
مثلاً سیستم مشتری را پرریسک اعلام کرده، اما مدیر اعتبارات میداند مشتری قرارداد بلندمدت تضمینشده دارد.
این نوع بازخورد میتواند برای اصلاح قواعد و بهتر شدن عملکرد سیستم استفاده شود.
پروژه موفق هوش مصنوعی در واحد مالی چه شکلی است؟
مسیر پیشنهادی این است:
مسئله مالی ← ثبت وضعیت فعلی ← ترسیم فرایند ← آمادهسازی داده ← تعیین مسئول پروژه ← انتخاب یک کاربرد کوچک ← تعریف کنترل انسانی ← اتصال به سیستمهای واقعی ← اندازهگیری نتیجه ← دریافت بازخورد ← توسعه مرحلهای

کوچک شروع کنید، نه با خودکارسازی کل واحد مالی
لازم نیست اولین پروژه، خودکارسازی کامل واحد مالی باشد.
یک مسئله محدود انتخاب کنید، مثل:
- مغایرتگیری بانکی
- طبقهبندی هزینهها
- تطبیق فاکتورها
- اولویتبندی وصول مطالبات
- پیشبینی نقدینگی
اگر نتیجه قابل اندازهگیری بود، پروژه را توسعه دهید.
تفاوت یک نسخه نمایشی جذاب با یک سیستم واقعی این است که سیستم واقعی باید در یک روز کاری عادی، با صدها سند و خطای واقعی نیز کار کند.
مثال عملی: مغایرتگیری بانکی هوشمند
این مثال فرضی است و فقط برای توضیح روش طراحی پروژه آمده است.
روش ضعیف:
«یک ابزار هوش مصنوعی برای بانک بسازیم.»
روش بهتر:
هدف: کاهش زمان مغایرتگیری بانکی.
داده: گردش بانک و اطلاعات ثبتشده در حسابداری.
نقش سیستم: پیشنهاد تطبیق تراکنشها.
قواعد: کنترل مبلغ، تاریخ و شناسههای مشخص.
نقش حسابدار: بررسی موارد حلنشده و پرریسک.
شاخصها: زمان پردازش، درصد تطبیق، تعداد اصلاحات انسانی و نرخ خطا.
در این حالت پروژه قابل اندازهگیری است.
مثال عملی: هوش مصنوعی برای وصول مطالبات
هدف ضعیف:
«هوش مصنوعی مطالبات را مدیریت کند.»
هدف بهتر:
«متوسط زمان وصول مطالبات کاهش پیدا کند.»
سیستم میتواند مشتریان را اولویتبندی کند، احتمال تأخیر را تخمین بزند و پیشنویس پیام یا یادآوری آماده کند.
اما مسئول وصول باید شرایط رابطه با مشتری، قرارداد و سابقه همکاری را در تصمیم نهایی وارد کند.
موفقیت پروژه را با چه شاخصهایی بسنجیم؟
تعداد ورود به سامانه یا تعداد دستورهایی که کاربران برای هوش مصنوعی نوشتهاند، معیار خوبی برای موفقیت مالی نیست.
معیارهای مفیدتر عبارتاند از:
- ساعت کاری صرفهجوییشده
- کاهش هزینه
- کاهش خطا
- کاهش زمان انجام فرایند
- بهبود وصول مطالبات
- بهبود دقت پیشبینی
- کاهش زمان رسیدگی به موارد استثنایی
ارزش اقتصادی پروژه را قبل از توسعه بررسی کنید
ممکن است یک پروژه از نظر فنی بسیار جذاب باشد اما از نظر اقتصادی توجیه نداشته باشد.
مثلاً اگر اجرای و نگهداری یک سیستم هزینه زیادی داشته باشد اما فقط چند ساعت کار دستی در سال کاهش دهد، احتمالاً انتخاب خوبی نیست.
هر پروژه باید یک منطق اقتصادی روشن داشته باشد:
چه هزینهای دارد و چه صرفهجویی، کاهش ریسک یا بهبود تصمیمی ایجاد میکند؟
مهمترین سؤال مدیر مالی چیست؟
مدیر مالی نباید فقط بپرسد:
«بهترین ابزار هوش مصنوعی کدام است؟»
سؤال مهمتر این است:
«کدام مسئله مالی آنقدر ارزش دارد که برای حل آن از هوش مصنوعی استفاده کنیم؟»
همین سؤال میتواند تفاوت میان یک پروژه نمایشی و یک پروژه اقتصادی و قابل توسعه باشد.
جمعبندی
بخش بزرگی از مشکلات پروژههای هوش مصنوعی در واحد مالی از خود مدل هوش مصنوعی شروع نمیشود.
مسئله اشتباه، داده ضعیف، مسئول نامشخص، شاخص نامناسب، اتصال ناقص، حذف کنترل انسانی، بیاعتمادی تیم، حضور نداشتن متخصص مالی، فرایند ناکارآمد، ضعف مدیریت تغییر و رها کردن پروژه بعد از راهاندازی، همگی میتوانند یک ایده خوب را به پروژهای کماثر تبدیل کنند.
مسیر حرفهای این است:
مسئله را پیدا کنیم ← فرایند را بفهمیم ← داده را آماده کنیم ← نتیجه قابل اندازهگیری تعریف کنیم ← کاربرد کوچک را اجرا کنیم ← انسان را در جای درست نگه داریم ← نتیجه را اندازه بگیریم ← سپس پروژه را توسعه دهیم.
در واحد مالی، موفقیت هوش مصنوعی بیشتر از آنکه به انتخاب جذابترین ابزار وابسته باشد، به طراحی درست مسئله، داده، فرایند، کنترل و مسئولیت وابسته است.
مقالات مرتبط
هوش مصنوعی در حسابداری چیست؟ ۱۰ کاربرد، مزایا و آینده حسابداران در ۱۴۰۵
حسابداری لحظهای چیست؟ نقش هوش مصنوعی در ثبت، کنترل و گزارش مالی

