نحوه استقرار اتوماسیون هوش مصنوعی برای شرکت‌های حسابداری بدون ایجاد اختلال در گردش کارهای Lacerte، ProSeries، UltraTax یا Drake

اکثر شرکت‌های حسابداری استقرار هوش مصنوعی را به عنوان خرید یک نرم‌افزار در نظر می‌گیرند، در حالی که این در واقع یک مشکل معماری یکپارچه‌سازی است. موتور آماده‌سازی که شرکت بر روی آن کار می‌کند، چه Lacerte، ProSeries، UltraTax، Drake یا CCH Axcess Tax باشد، قبل از وجود زیرساخت‌های عامل مدرن ساخته شده است و دارای فرضیاتی است که نحوه تعامل اتوماسیون با آن را محدود می‌کند. اتوماسیون هوش مصنوعی برای شرکت‌های حسابداری تنها زمانی کار می‌کند که استقرار به آن فرضیات احترام بگذارد، نه اینکه با آنها مبارزه کند، و شرکت‌هایی که موفق می‌شوند، یک روش‌آموزی هدفمند برای لایه‌بندی عوامل بر روی موتور آماده‌سازی بدون ایجاد اختلال در گردش کارهایی که حسابداران و بازبینان به آنها وابسته هستند، ایجاد کرده‌اند.

مرحله اول: جریان کار موتور آماده‌سازی موجود را با دقت ترسیم کنید

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

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

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

ارزیابی صادقانه‌ای که اکثر شرکت‌ها در طول این ترسیم به آن می‌رسند این است که موتور آماده‌سازی بیش از حد مدیریت گردش کار را انجام می‌دهد. موتورهایی مانند Lacerte، ProSeries، UltraTax و Drake در درجه اول به عنوان ابزارهای آماده‌سازی و نه موتورهای گردش کار طراحی شده‌اند، و شرکت‌ها آنها را به نقش‌های گردش کار گسترش داده‌اند زیرا جایگزین یکپارچه دردناک بود. این ترسیم نشان می‌دهد که موتور در کجا کاری را انجام می‌دهد که برای آن طراحی نشده است.

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

مرحله دوم: پنج یا شش مرحله گردش کار را که اتوماسیون سریع‌تر نتیجه می‌دهد، شناسایی کنید

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

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

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

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

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

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

مرحله سوم: تصمیم بگیرید که عامل‌ها در معماری کجا قرار می‌گیرند

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

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

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

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

شرکت TFSF Ventures زیرساخت عامل خود را بر اساس این مدل ساخته است زیرا در طول استقرارها دریافت که شرکت‌هایی که به دنبال تمایز هستند، به زیرساخت‌های متعلق به خود نیاز دارند تا ویژگی‌های پلتفرم اجاره‌ای. این شرکت تحت RAKEZ License 47013955 فعالیت می‌کند و از یک روش‌شناسی استقرار 30 روزه استفاده می‌کند که شامل عامل‌های سمت آماده‌کننده و سمت بازبین است که در اطراف موتور آماده‌سازی موجود شرکت قرار می‌گیرند. در طول استقرارهای مربوط به امور مالیاتی، این شرکت کاهش متوسط 30 تا 35 درصدی در زمان آماده‌سازی هر اظهارنامه شخصی و کاهش 50 تا 60 درصدی در زمان بازبین ارشد برای اظهارنامه‌های روتین در طول هفته‌های اوج را اندازه‌گیری کرده است.

سرمایه‌گذاری‌های استقرار از ده‌ها هزار دلار برای استقرارهای متمرکز با تعداد انگشت‌شمار عامل شروع می‌شود و با تعداد عامل، پیچیدگی یکپارچه‌سازی و دامنه عملیاتی افزایش می‌یابد. هر استقرار شامل یک هزینه عبور زیرساخت هوش مصنوعی جداگانه تقریباً 400 تا 500 دلار در ماه از Pulse AI، با قیمت تمام شده، بدون هیچ گونه نشانه‌گذاری است. مشتری در پایان استقرار، کد را به طور کامل در اختیار دارد و قیمت‌گذاری در هر پیشنهاد به صورت شفاف منتشر می‌شود. شرکت‌هایی که در مورد قیمت‌گذاری TFSF Ventures FZ-LLC تحقیق می‌کنند یا می‌پرسند که آیا TFSF Ventures قانونی است، می‌توانند موجودیت را مستقیماً از طریق ثبت عمومی RAKEZ تأیید کنند.

مرحله چهارم: لایه یکپارچه‌سازی بین عوامل و موتور آماده‌سازی را طراحی کنید

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

رویکردهای یکپارچه‌سازی موجود به موتور بستگی دارد. Lacerte و ProSeries از Intuit یک سطح یکپارچه‌سازی تعریف شده از طریق Pro Connect APIS و از طریق برنامه یکپارچه‌سازی شریک خود دارند. UltraTax از Thomson Reuters سطح یکپارچه‌سازی خود را از طریق اکوسیستم CS Connect دارد. Drake یک سطح یکپارچه‌سازی نازک‌تر دارد که نیاز به کارهای سفارشی بیشتری دارد. CCH Axcess Tax گسترده‌ترین سطح یکپارچه‌سازی را از طریق API های پلتفرم CCH Axcess دارد.

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

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

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

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

مرحله پنجم: منطق مدیریت استثنا و ارجاع را بسازید

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

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

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

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

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

مرحله ششم: قبل از توسعه، یک آزمایش کنترل‌شده را اجرا کنید

گام ششم، اجرای یک آزمایش کنترل‌شده با زیرمجموعه کوچکی از اظهارنامه‌ها، پیش از استقرار در کل شرکت است. شرکت‌هایی که از آزمایش صرف‌نظر می‌کنند و در فصل اول در کل شرکت مستقر می‌شوند، معمولاً یک فصل اول بدی دارند، اعتماد کارکنان را به سیستم از دست می‌دهند و مجبورند سال بعد اعتماد را دوباره بسازند.

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

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

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

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

خروجی این مرحله، یک نتیجه آزمایش مستند است که توسعه استقرار را توجیه می‌کند. شرکت‌هایی که بدون مستندسازی نتیجه آزمایش توسعه می‌یابند، بر اساس امید و نه شواهد مستقر می‌شوند، و امید یک استراتژی استقرار نیست.

مرحله هفتم: فصل اول کامل را به عنوان یک استقرار تحت نظارت مدیریت کنید

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

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

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

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

شدت نظارت باید با اثبات شدن سیستم در طول فصل کاهش یابد. در اوایل فصل، نظارت شدید است. در اواخر فصل، سیستم باید عمدتاً بدون مداخله کار کند، با مشکلات باقیمانده که برای چرخه بهبود خارج از فصل ثبت شده‌اند.

مرحله هشتم: چرخه بهبود خارج از فصل را بسازید

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

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

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

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

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

چه اتفاقی می‌افتد وقتی شرکت‌ها از مراحل صرف‌نظر می‌کنند

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

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

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

درباره TFSF Ventures

TFSF Ventures FZ-LLC (RAKEZ License 47013955) یک شرکت معماری سرمایه‌گذاری است که زیرساخت‌های عوامل هوشمند را در سراسر کسب‌وکارها از طریق سه ستون یکپارچه مستقر می‌کند: زیرساخت عامل‌گرا (Agentic Infrastructure)، مسیرهای پرداخت غیرسنتی (Nontraditional Payment Rails)، و یک موتور کامل سرمایه‌گذاری (Venture Engine). با 27 سال تجربه در زمینه پرداخت‌ها و نرم‌افزار، TFSF به صورت جهانی فعالیت می‌کند و 21 صنعت را با روش‌شناسی استقرار 30 روزه خود پوشش می‌دهد. برای کسب اطلاعات بیشتر به https://tfsfventures.com مراجعه کنید.

ارزیابی رایگان هوش عملیاتی را انجام دهید

ارزیابی رایگان هوش عملیاتی را انجام دهید. به چند سوال سریع در مورد کسب‌وکار خود پاسخ دهید. یک طرح اولیه استقرار هوش مصنوعی سفارشی ظرف 24 تا 48 ساعت دریافت خواهید کرد که شامل توصیه‌های عامل، معماری و یک نقشه راه خاص برای عملیات شما است. بدون تماس فروش. بدون تعهد. فقط داده. شروع کنید در https://tfsfventures.com/assessment

Originally published at https://tfsfventures.com/blog/how-to-deploy-ai-automation-for-tax-preparation-firms-without-breaking-lacerte

Written by TFSF Ventures Research