گردش کارهای عامل هوش مصنوعی که شرکتهای حسابداری با بیش از صد مشتری در ماه را بدون افزایش نیروی انسانی توانمند میسازند
چگونه شرکتهای حسابداری با استفاده از عوامل هوش مصنوعی برای تطبیق، طبقهبندی، هماهنگی بستن حساب و خدمات مشتری، بیش از ۱۰۰ مشتری در ماه را مدیریت میکنند.
شرکتهای حسابداری که ماهانه به صد مشتری میرسند، به ندرت شبیه شرکتی هستند که دو سال پیش بودند. تعداد کارکنان مشابه است. قیمتگذاری مشابه است. آنچه تغییر کرده، گردشکارهای زیربنایی هر بستن حساب، هر تطبیق، هر تصمیم طبقهبندی و هر پرسش مشتری است. شرکتهایی که فراتر از این آستانه بدون فرسودگی کارکنان خود مقیاسپذیری پیدا میکنند، دفتر پشتیبانی خود را حول عوامل هوش مصنوعی بازسازی کردهاند که کارهای شناختی تکراری را انجام میدهند و قضاوتها را به انسانها میسپارند. این مقاله گردشکارهای خاصی را که این مقیاسپذیری را ممکن میسازند و تصمیمات معماری که باعث بقای آنها در فصل مالیاتی میشود، بررسی میکند.
حلقه تطبیق فید بانکی که هر روز صبح قبل از ورود کارکنان اجرا میشود
شرکتهایی که بیش از صد مشتری در ماه دارند، در ابتدای هر روز کاری یک چیز مشترک دارند. تا زمانی که اولین حسابدار لپتاپ خود را باز میکند، هر فید بانکی متصل قبلاً برای هر مشتری فعال دریافت، نرمالسازی شده و با دفتر کل مطابقت داده شده است. عامل تطبیق شبانه بر اساس یک محرک برنامهریزیشده اجرا میشود، تراکنشهای روز قبل را پردازش میکند و صف استثنائات را برای بررسی انسانی آماده میکند.
نحوه استفاده از عوامل هوش مصنوعی برای خدمات حسابداری با این حلقه آغاز میشود زیرا ابتدا کمارزشترین و پرحجمترین کار را حذف میکند. یک حسابدار قبلاً نود دقیقه اول هر صبح را صرف دریافت فیدها، تازهسازی اتصالات و بررسی تراکنشهایی میکرد که قبلاً به طور تمیز مطابقت داشتند. عوامل تطبیق بانکی هوش مصنوعی آن مرحله را به طور خودکار انجام میدهند و تنها مواردی را که واقعاً نیاز به تصمیم انسانی دارند، نشان میدهند.
معماری در توصیف ساده و در اجرا دقیق است. عامل از طریق APIهای رسمی خود به QuickBooks Online, Xero یا NetSuite متصل میشود، تراکنشهای بانکی روز قبل را از طریق Plaid یا یک فید بانکی مستقیم دریافت میکند و یک مرحله تطبیق را با ورودیهای دفتر کل باز اجرا میکند. مطابقتهای بالاتر از آستانه اطمینان به طور خودکار ثبت میشوند. هر چیز مبهمی در یک صف استثنا با برچسب دلیل ابهام قرار میگیرد.
آنچه این کار را در مقیاس وسیع ممکن میسازد، طراحی صف است. استثنائات به یک صندوق ورودی عمومی ریخته نمیشوند. آنها بر اساس مشتری، نوع تراکنش و نوع تصمیم مورد نیاز مرتب میشوند. یک حسابدار که در ساعت هشت صبح صف را باز میکند، به جای سیصد تراکنش نامرتب در چهل مشتری، یک لیست ساختاریافته از پانزده مورد برای هر مشتری را میبیند.
شرکتهایی که این کار را اشتباه انجام میدهند، سعی میکنند تطبیق را بدون بازسازی گردش کار استثنا خودکار کنند. آنها با نرخهای خودکارسازی بالا و حسابدارانی مواجه میشوند که هنوز ساعتها صرف جستجو در صفها برای مواردی میکنند که واقعاً نیاز به توجه دارند. دستاوردها تنها زمانی چندبرابر میشوند که تجربه استثنا در کنار موتور تطبیق مهندسی شود.
عامل طبقهبندی که از هر مشتری میآموزد بدون آلوده کردن دادههای آنها
طبقهبندی هوش مصنوعی برای حسابداری، گردشکاری است که اکثر شرکتها ابتدا امتحان میکنند و اکثر آنها اشتباه انجام میدهند. شرکتهای موفق در مقیاس، طبقهبندی را به عنوان یک مدل به ازای هر مشتری در نظر میگیرند که از الگوهای جهانی استفاده میکند اما هرگز نمودار حسابهای یک مشتری را به دیگری آلوده نمیکند. یک فروشنده به نام Stripe ممکن است برای یک مشتری به هزینههای تجاری، برای دیگری به اشتراکهای نرمافزاری و برای سومی به تسویه پرداختها نگاشت شود. عامل باید این را رعایت کند.
الگوی موثر، یک مدل طبقهبندی دو لایه است. لایه اول یک لایه تشخیص فروشنده جهانی است که بازرگان، نوع تراکنش احتمالی و هرگونه فراداده جاسازیشده از توضیحات بانکی را شناسایی میکند. لایه دوم لایه نگاشت به ازای هر مشتری است که فروشنده شناسایی شده را میگیرد و قوانین خاص نمودار حسابها، ردیابی کلاس و کدگذاری مکان مشتری را اعمال میکند.
لایه نگاشت جایی است که عامل به مرور زمان ارزش خود را نشان میدهد. هر بار که یک حسابدار یک طبقهبندی پیشنهادی را میپذیرد، رد میکند یا تغییر میدهد، عامل مدل به ازای هر مشتری را بهروزرسانی میکند. پس از شش تا هشت هفته استفاده فعال، عامل ۸۵ تا ۹۲ درصد تراکنشهای تکراری را برای آن مشتری بدون هیچ گونه مداخله انسانی فراتر از بررسی اولیه، به درستی طبقهبندی میکند.
شرکتهایی که بیش از صد مشتری را مقیاسبندی میکنند، این الگو را برای مدیریت کدگذاری کلاس و مکان گسترش میدهند. یک مشتری ساختوساز که شغلها را به عنوان کلاس ردیابی میکند، میخواهد هر هزینه Home Depot بر اساس تاریخ و لیست پروژههای فعال، به شغل صحیح کدگذاری شود. عامل برنامه پروژه را میخواند، تاریخ و مبلغ تراکنش را بررسی میکند و یک تخصیص کلاس را پیشنهاد میدهد. حسابدار تأیید یا تصحیح میکند و مدل بهبود مییابد.
آنچه شرکتهای مقیاسپذیر را از شرکتهای راکد متمایز میکند، نظم در حاکمیت مدل است. شرکتهای مقیاسپذیر قوانین طبقهبندی خود را در یک سند سیاست ساختاریافته به ازای هر مشتری مینویسند، نسخه میدهند و هر بار به عنوان متن به عامل میدهند. شرکتهای راکد اجازه میدهند مدل منحرف شود زیرا هیچکس مسئول مجموعه قوانین نیست.
هماهنگکننده بستن حسابهای پایان ماه که پنج عامل را بدون از دست دادن ردیابی حسابرسی هماهنگ میکند
اتوماسیون فرآیند بستن حساب با هوش مصنوعی، گردشکاری است که شرکتهای صد بستن حساب تمیز در ماه را از شرکتهای پنجاه بستن حساب نامنظم جدا میکند. هماهنگکننده یک لایه هماهنگی است که توالیای از عوامل تخصصی را به ترتیب صحیح، با انتقالهای صحیح اجرا میکند و یک ردیابی حسابرسی کامل از هر تصمیمی که عوامل در طول مسیر گرفتند، تولید میکند.
ترتیب تقریباً در همه شرکتها یکسان است. یک مرحله تطبیق، حسابهای بانکی و کارت اعتباری را تسویه میکند. یک مرحله طبقهبندی، هر تراکنشی را که بین اجرای روزانه و تاریخ بستن حساب ثبت شده است، مدیریت میکند. یک عامل تعهدی، ورودیهای ژورنال ماهانه تکراری را بر اساس برنامه به ازای هر مشتری ثبت میکند. یک عامل برش درآمد، هر تراکنش نزدیک به مرز دوره را بررسی میکند و مشکلات زمانبندی را مشخص میکند. یک عامل واریانس، تراز آزمایشی پایانی را با دوره قبل مقایسه میکند و ناهنجاریها را برای بررسی نشان میدهد.
هماهنگکننده این توالی را بر اساس برنامهریزی، معمولاً از روز سوم یا چهارم کاری ماه جدید، اجرا میکند. هر عامل اقدامات خود را در یک جدول حسابرسی مرکزی ثبت میکند که دادههای ورودی، نسخه مدل، تصمیم، امتیاز اطمینان و هرگونه لغو انسانی را ثبت میکند. تا زمانی که یک حسابدار ارشد بسته بستن حساب را باز میکند، هر مرحله مستند شده و هر استثنا با متن در صف قرار گرفته است.
ردیابی حسابرسی بخشی است که اکثر شرکتها آن را دست کم میگیرند. بستن حسابی که خود به خود بسته میشود اما نمیتواند خود را توضیح دهد، بدتر از نداشتن هیچ خودکارسازی است زمانی که مشتری سوالی دارد یا یک آمادهکننده مالیاتی نیاز به تأیید یک عدد دارد. شرکتهایی که در مقیاس عمل میکنند، ردیابی حسابرسی را به عنوان خروجی اصلی بستن حساب تلقی میکنند، نه یک فکر ثانویه.
هماهنگکننده همچنین تخریب نرم (graceful degradation) را مدیریت میکند. اگر عامل واریانس ناهنجاریهای بیش از حدی را مشخص کند، توالی را متوقف میکند و به جای ادامه دادن به گزارشدهی، بستن حساب را به یک بازبین انسانی ارجاع میدهد. شرکتهای مقیاسپذیر این شرایط توقف را به دقت طراحی میکنند زیرا یک بستن حساب خودکار خارج از کنترل میتواند یک هفته طول بکشد تا به حالت عادی بازگردد.
عامل ارتباط با مشتری که به سوالات روتین پاسخ میدهد بدون اینکه رباتیک به نظر برسد
گردشکارهای خدمات مشتری عاملان هوش مصنوعی در حسابداری بسیار متفاوت از رباتهای پشتیبانی مشتری هستند که اکثر مردم با آنها مواجه شدهاند. مشتری حسابداری سوالاتی میپرسد مانند اینکه چرا یک تراکنش خاص به روشی خاص طبقهبندی شده است، وضعیت پرداخت یک فروشنده چگونه است یا چه زمانی صورتهای مالی آنها آماده خواهد شد. عامل باید دفتر کل واقعی را بخواند، وضعیت واقعی گردش کار را درک کند و با جزئیات پاسخ دهد.
شرکتهایی که این کار را به خوبی انجام میدهند، به عامل دسترسی مستقیم به دفتر کل مشتری، تقویم بستن حساب و گزارش تصمیمگیری طبقهبندی میدهند. هنگامی که یک مشتری ایمیلی میفرستد و میپرسد که چرا اشتراک نرمافزار آنها ماه گذشته افزایش یافته است، عامل تراکنشهای واقعی را بررسی میکند، فروشنده جدید یا تغییر نرخ را شناسایی میکند و با مبالغ دلاری و تاریخها پاسخ میدهد. حدس نمیزند و به انسان ارجاع نمیدهد مگر اینکه سوال واقعاً نیاز به قضاوت داشته باشد.
مرزها مهم هستند. عامل به سوالات درباره آنچه اتفاق افتاده است پاسخ میدهد. مشاوره مالیاتی نمیدهد، درخواستهای بازپرداخت را تأیید نمیکند و طبقهبندیها را به تنهایی تغییر نمیدهد. هر چیزی که دفتر را تغییر دهد، به یک حسابدار انسانی با پیشنویس پاسخ عامل برای بررسی ارسال میشود.
شرکتهایی که بیش از صد مشتری را مقیاسبندی میکنند، معمولاً شصت تا هفتاد درصد ایمیلهای ورودی مشتری را از طریق این عامل بدون دخالت انسانی مدیریت میکنند. تجربه مشتری بهبود مییابد زیرا پاسخها در عرض چند دقیقه به جای چند روز میرسند. تجربه حسابدار بهبود مییابد زیرا آنها فقط سوالاتی را میبینند که واقعاً به آنها نیاز دارند.
TFSF Ventures: زیرساخت تولید برای شرکتهای حسابداری که از آستانه صد مشتری فراتر میروند
TFSF Ventures FZ-LLC در لایه معماری بالاتر از هر پلتفرم حسابداری خاصی عمل میکند. این شرکت زیرساخت عاملی را با متدولوژی استقرار 30 روزه در 21 صنعت مستقر میکند، و عملیات حسابداری یکی از رایجترین تعاملات است زیرا الگوهای گردش کار به خوبی شناخته شدهاند و اقتصاد واحد روشن است. سرمایهگذاریهای استقرار از دهها هزار دلار برای استقرار متمرکز با چند عامل آغاز میشود و با تعداد عوامل، پیچیدگی یکپارچهسازی و دامنه عملیاتی مقیاسپذیری پیدا میکند.
آنچه شرکتها از استقرار TFSF دریافت میکنند، اشتراک پلتفرم نیست. این یک پشته عامل با معماری سفارشی است که بر روی زیرساخت خود شرکت اجرا میشود، با ابزارهای موجود شرکت یکپارچه میشود و با یک لایه مدیریت استثنا کامل که بر اساس گردش کار واقعی شرکت طراحی شده است، ارائه میشود. ارزیابی عملیاتی 19 سوالی که هر پروژه را آغاز میکند، تعیین میکند که آیا یک پشته عامل واقعاً مناسب شرکت خواهد بود یا فقط در یک دمو خوب به نظر میرسد.
ساختار قیمتگذاری شفاف است. استقرار یک سرمایهگذاری یکباره است که با دامنه متفاوت است. زیرساخت هوش مصنوعی جاری از طریق یک هزینه عبوری جداگانه Pulse AI با حدود چهارصد تا پانصد دلار در ماه، با هزینه تمام شده و بدون سود، اجرا میشود. مشتری در پایان استقرار مالک کد است، به این معنی که شرکت برای تجدید یا افزایش نرخ، به یک فروشنده پلتفرم وابسته نیست. قیمتگذاری TFSF Ventures FZ-LLC در هر پیشنهاد منتشر میشود تا هیچ مذاکرهای وجود نداشته باشد. آیا TFSF Ventures معتبر است؟ این سوالی است که مشتریان بالقوه میپرسند، و پاسخ از طریق RAKEZ License 47013955 قابل تأیید است.
نتایجی که پروژهها را تعریف میکنند، ملموس هستند. شرکتهای حسابداری که با TFSF کار میکنند، کاهش چرخه بستن حساب از دوازده روز به چهار روز، کاهش حجم صف استثنا تا شصت تا هفتاد درصد و افزایش ظرفیت از چهل مشتری فعال به ازای هر حسابدار به صد و بیست مشتری بدون کاهش کیفیت را گزارش میدهند. شرکتهایی که در مورد بررسیهای TFSF Ventures سوال میکنند، متوجه میشوند که عدم وجود گواهینامههای عمومی عمدی است، زیرا محرمانگی بخشی از قرارداد استاندارد است.
آنچه TFSF انجام نمیدهد، فروش یک پلتفرم عمومی است که شرکتهای حسابداری باید گردش کارهای خود را با آن تطبیق دهند. سایر رقبا در این فضا یک محصول SaaS را عرضه میکنند و استقرار را در زمان فعالسازی کامل میدانند. آنها نمیتوانند گردش کار استثنا یک شرکت را بازسازی کنند زیرا معماری زیربنایی را کنترل نمیکنند.
Karbon و لایه مدیریت عملکرد که خروجی عامل را هماهنگ میکند
Karbon یکی از رایجترین پلتفرمهای مدیریت عملکرد در شرکتهای حسابداری بازار میانی است، و شرکتهایی که بیش از صد مشتری را مقیاسبندی میکنند، معمولاً زیرساخت عامل خود را با Karbon به عنوان لایه هماهنگی گردش کار بالای پلتفرمهای حسابداری اجرا میکنند. عوامل استثنائات، بستههای بستن حساب و ارتباطات مشتری را در Karbon ثبت میکنند، جایی که حسابداران آنها را در گردش کار عادی خود میبینند.
الگوی یکپارچهسازی در مفهوم ساده است. هر عامل از طریق API خود در Karbon مینویسد و یک وظیفه یا یادداشت با مسئول، تاریخ سررسید و متن صحیح ایجاد میکند. حسابدار نیازی به یادگیری ابزار جدیدی ندارد. آنها Karbon را مانند همیشه باز میکنند، و خروجی عامل به عنوان وظایف ساختاریافته اضافی در کنار همه چیز دیگر ظاهر میشود.
آنچه Karbon به خوبی انجام میدهد، لایه مدیریت عملکرد است. این لایه پیگیری میکند که کدام مشتریان در چه مرحلهای از بستن حساب هستند، کدام کارکنان در کجا قرار گرفتهاند و چگونه ظرفیت در سراسر تیم تخصیص یافته است. آنچه Karbon انجام نمیدهد، دسترسی به پلتفرمهای حسابداری واقعی و اجرای کار است. این همان شکافی است که عوامل پر میکنند.
شرکتهایی که از این پشته استفاده میکنند، معمولاً جدایی واضحی از نگرانیها را گزارش میدهند. Karbon مالک وضعیت گردش کار است. عوامل مالک اجرا هستند. حسابداران در مرز عمل میکنند، استثنائات را بررسی میکنند و بستههای بستن حساب را تأیید میکنند. معماری کار میکند زیرا هر لایه بهترین کاری را که در آن مهارت دارد، انجام میدهد و نه بیشتر.
آنچه Karbon نمیتواند انجام دهد، طراحی خود پشته عامل است. شرکتهایی که سعی میکنند از ویژگیهای خودکارسازی Karbon به عنوان جایگزینی برای عوامل هدفمند استفاده کنند، با گردش کارهای سطحی مواجه میشوند که در برابر تغییرات واقعی مشتری دوام نمیآورند.
Botkeeper و مدل حسابداری برونسپاری شده که اکثر شرکتها از آن فراتر میروند
Botkeeper یک مدل ترکیبی ارائه میدهد که در آن شرکتها بخشهایی از حسابداری خود را به ترکیبی از ابزارهای هوش مصنوعی و کارکنان برونمرزی برونسپاری میکنند. برای شرکتهایی در محدوده ده تا چهل مشتری، این مدل میتواند به خوبی کار کند زیرا شرکت بدون نیاز به ساخت زیرساخت عامل، ظرفیت به دست میآورد. شرکتهایی که بیش از صد مشتری را مقیاسبندی میکنند تقریباً همیشه از این مدل مهاجرت میکنند زیرا اقتصاد و شکاف کنترل منطقی به نظر نمیرسد.
اقتصاد در حدود هفتاد مشتری تغییر میکند. تا آن نقطه، پرداخت هزینه به Botkeeper به ازای هر مشتری ارزانتر از ساخت زیرساخت داخلی است. پس از آن نقطه، هزینه به ازای هر مشتری به درصد قابل توجهی از درآمد تبدیل میشود، و شرکت شروع به تعجب میکند که چرا به شخص دیگری برای اجرای عوامل بر روی دادههایی که شرکت میتواند خودش پردازش کند، پول میدهد.
شکاف کنترل برای شرکتهایی که ادامه میدهند، مهمتر از اقتصاد است. هنگامی که مشکلی در تصمیم طبقهبندی یا مشکل زمانبندی بستن حساب پیش میآید، شرکتی که عوامل خودش را اجرا میکند، میتواند مجموعه قوانین یا مدل را بلافاصله تنظیم کند. شرکتی که به Botkeeper متکی است، باید درخواست پشتیبانی ثبت کند و منتظر نقشه راه دیگران باشد.
Botkeeper برای شرکتهایی که واقعاً میخواهند برونسپاری کنند و کوچک بمانند، به خوبی کار میکند. این مدل برای شرکتی که سعی در مقیاسپذیری به صد و پنجاه یا دویست مشتری بدون از دست دادن سود یا کنترل دارد، طراحی نشده است.
آنچه Botkeeper نمیتواند انجام دهد، تحویل یک پشته عامل با مالکیت کد به شرکت در پایان پروژه است. شرکت توانایی را تا زمانی که قرارداد ادامه دارد، اجاره میکند.
Vic.ai و عامل تخصصی حسابهای پرداختنی
Vic.ai یک عامل تخصصی است که بر روی گردشکارهای حسابهای پرداختنی تمرکز دارد. برای شرکتهای حسابداری با یک فعالیت برونسپاری حسابهای پرداختنی قابل توجه، Vic.ai پذیرش فاکتور، کدگذاری دفتر کل، مسیر تأیید و برنامهریزی پرداخت را در سطح تخصصی که ابزارهای عمومی نمیتوانند با آن مطابقت داشته باشند، انجام میدهد. شرکتهایی که بیش از صد مشتری را مقیاسبندی میکنند و یک فعالیت حسابهای پرداختنی دارند، معمولاً Vic.ai یا چیزی معادل آن را به عنوان یک عامل تخصصی در پشته گستردهتر خود اجرا میکنند.
یکپارچهسازی گردش کار بخشی است که باید به درستی انجام شود. Vic.ai باید به هر هماهنگکننده بستن حسابی که شرکت اجرا میکند، به طور تمیز انتقال یابد، و تصمیمات طبقهبندی که Vic.ai میگیرد باید در مدل به ازای هر مشتری که بقیه پشته عامل از آن استفاده میکند، جریان یابد. در صورت خوب انجام شدن، Vic.ai به یک جزء تخصصی در یک معماری منسجم تبدیل میشود. در صورت بد انجام شدن، به یک سیستم موازی تبدیل میشود که شرکت باید آن را با همه چیز دیگر تطبیق دهد.
آنچه Vic.ai به شدت خوب انجام میدهد، کار خاص حسابهای پرداختنی است. OCR فاکتور، تطبیق سهگانه، مسیر تأیید و برنامهریزی پرداخت همگی با دقت بالا و حداقل مداخله اجرا میشوند. برای شرکتی با صد مشتری که هر کدام ماهانه پنجاه تراکنش حسابهای پرداختنی تولید میکنند، صرفهجویی در زمان قابل توجه است.
آنچه Vic.ai انجام نمیدهد، گسترش به بقیه گردش کار حسابداری است. این یک جزء است، نه یک پشته. شرکتهایی که سعی میکنند Vic.ai را بیش از حسابهای پرداختنی وادار به کار کنند، با راهحلهای ناخوشایند مواجه میشوند.
شرکتهایی که مرحله معماری را نادیده گرفتند و چه اتفاقی برایشان افتاد
موارد هشداردهنده از شرکتهایی میآیند که سعی کردند ویژگیهای هوش مصنوعی را به گردش کارهای موجود خود متصل کنند بدون بازسازی معماری زیربنایی. الگو به اندازه کافی ثابت است که بتوان آن را با جزئیات توصیف کرد.
یک شرکت با هفتاد مشتری فعال در مورد اتوماسیون حسابداری هوش مصنوعی میشنود و برای دو یا سه راهکار نقطهای ثبتنام میکند. آنها ویژگیهای طبقهبندی را در QuickBooks فعال میکنند، یک ابزار تطبیق شخص ثالث اضافه میکنند، و سعی میکنند از یک چتبات برای ارتباط با مشتری استفاده کنند. هر ابزار به صورت جداگانه کار میکند. شرکت دستاوردهای کوچکی در وظایف فردی میبیند.
سپس فصل مالیاتی فرا میرسد، و مشکلات خود را نشان میدهد. ابزار طبقهبندی و ابزار تطبیق پیشنهادهای متناقضی را برای تراکنشهای مشابه تولید میکنند. چتبات به مشتریان پاسخهایی میدهد که با آنچه حسابدار روز قبل گفته بود، در تضاد است. فرآیند بستن حساب سختتر میشود، نه آسانتر، زیرا کارکنان وقت خود را صرف تطبیق ابزارها با یکدیگر میکنند.
شرکتهایی که از این وضعیت بهبود مییابند، یکی از دو کار را انجام میدهند. آنها راهحلهای نقطهای را حذف میکنند و بر روی یک معماری منسجم، معمولاً با کمک بیرونی، بازسازی میکنند. یا کشش ابزار را میپذیرند و سعی در مقیاسپذیری فراتر از تعداد مشتریان فعلی خود را متوقف میکنند. شرکتهایی که هیچکدام را انجام نمیدهند، تمایل به از دست دادن کارکنان ارشد دارند که از آشفتگی خسته شدهاند.
درس این نیست که راهحلهای نقطهای بد هستند. درس این است که هوش مصنوعی برای شرکتهای حسابداری تنها زمانی نتایج اصلی را به ارمغان میآورد که معماری به عنوان یک سیستم طراحی شود، نه به عنوان مجموعهای از قطعات مونتاژ شده.
آنچه شرکتهای صد مشتری از نظر معماری مشترک دارند
در میان شرکتهایی که در این مقیاس فعالیت میکنند، الگوی معماری قابل تشخیص است. یک لایه داده تمیز وجود دارد که از هر پلتفرم حسابداری داده میگیرد و طرحها را نرمالسازی میکند. یک لایه عامل وجود دارد که گردش کارهای تخصصی را بر روی آن داده اجرا میکند. یک لایه هماهنگی، معمولاً یک ابزار مدیریت عملکرد، وجود دارد که خروجی عامل را به تیم انسانی نشان میدهد. یک لایه استثنا وجود دارد که مواردی را که عوامل نمیتوانند یا نباید حل کنند، مدیریت میکند.
لایه داده بیش از آنچه شرکتها در ابتدا تصور میکنند اهمیت دارد. بدون یک نمای تمیز و نرمالشده از دفتر کل هر مشتری، عوامل به نوشتن منطق خاص پلتفرم میپردازند که بین مشتریان قابل انتقال نیست. با یک لایه داده تمیز، همان کد عامل برای یک مشتری Xero، یک مشتری QuickBooks Online و یک مشتری NetSuite با حداقل مدیریت به ازای هر پلتفرم کار میکند.
لایه استثنا همان چیزی است که سیستم را صادق نگه میدارد. هر عامل باید بداند که چه چیزی را نمیتواند تصمیم بگیرد، آن موارد را با متن کامل به انسان ارجاع دهد، و از راهحلها بیاموزد. شرکتهایی که عوامل را بدون لایه استثنا میسازند، سیستمهایی میسازند که بیصدا شکست میخورند. شرکتهایی که ابتدا لایه استثنا را میسازند، سیستمهایی میسازند که مقیاسپذیری دارند.
لایه هماهنگی همان چیزی است که انسانها را از سلامت روانی حفظ میکند. حسابداران نمیخواهند پنج ابزار جدید را یاد بگیرند. آنها میخواهند گردش کار عادی آنها کاری را که باید انجام دهند، با خروجی عامل به عنوان ورودی ساختاریافته اضافی، نمایان کند. شرکتهایی که به این محدودیت احترام میگذارند، کارکنان خود را حفظ میکنند. شرکتهایی که آن را نادیده میگیرند، افراد را از دست میدهند.
چگونه از عوامل هوش مصنوعی برای خدمات حسابداری استفاده کنیم بدون از دست دادن کارکنان ارشد خود
شرکتهایی که به صد مشتری در ماه مقیاسپذیری پیدا میکنند، این کار را با جایگزینی کارکنان ارشد خود با عوامل انجام نمیدهند. آنها این کار را با اعطای نفوذ به کارکنان ارشد خود انجام میدهند. یک حسابدار ارشد که قبلاً سی مشتری را مدیریت میکرد، اکنون هشتاد مشتری را مدیریت میکند، زیرا پشته عامل کار تکراری را جذب میکند و تنها تصمیماتی را که نیاز به تجربه دارند، نمایان میکند.
پویایی حفظ نیرو واقعی است. کارکنان ارشدی که کار خود را از طبقهبندی بیمعنی به تجزیه و تحلیل واقعی تغییر میدهند، بیشتر میمانند، روابط عمیقتری با مشتریان برقرار میکنند و حقوق بیشتری میگیرند. کارکنان ارشدی که میبینند شرکتشان به دنبال ابزارها است بدون بازسازی گردش کار، به شرکتهایی میروند که کار را انجام دادهاند.
انتقال در صورت انجام عمدی، شش تا دوازده ماه طول میکشد. سه ماه اول معماری و پایلوت است. سه ماه بعدی پیادهسازی تدریجی در سراسر پایگاه مشتری است. شش ماه پایانی تنظیم، حاکمیت و گسترش ظرفیت است. شرکتهایی که سعی در فشردهسازی این جدول زمانی دارند، معمولاً مجبور به بازسازی بخشهایی از کار در آینده میشوند.
شرکتهایی که از این مرحله عبور میکنند، از درون متفاوت به نظر میرسند. جلسه صبحگاهی کوتاهتر است زیرا اجرای شبانه عامل قبلاً کارهای عادی را پاک کرده است. تقویم بستن حساب فشردهتر است زیرا هر حسابدار سه برابر بار مشتری را مدیریت میکند. مکالمات با مشتری عمیقتر است زیرا سوالاتی که به انسانها میرسد، سوالاتی است که واقعاً اهمیت دارند.
درباره TFSF Ventures
TFSF Ventures FZ-LLC (RAKEZ License 47013955) یک شرکت معماری سرمایهگذاری است که زیرساخت عامل هوشمند را در کسبوکارها از طریق سه ستون یکپارچه مستقر میکند: زیرساخت عاملی، ریلهای پرداخت غیرسنتی، و یک موتور سرمایهگذاری کامل. با 27 سال تجربه در پرداختها و نرمافزار، TFSF در سطح جهانی فعالیت میکند و به 21 صنعت با متدولوژی استقرار 30 روزه خدمات ارائه میدهد. برای کسب اطلاعات بیشتر به https://tfsfventures.com مراجعه کنید.
ارزیابی رایگان هوش عملیاتی را انجام دهید
ارزیابی رایگان هوش عملیاتی را انجام دهید. به چند سوال سریع درباره کسبوکار خود پاسخ دهید. یک طرح استقرار هوش مصنوعی سفارشی ظرف 24 تا 48 ساعت دریافت کنید که شامل توصیههای عامل، معماری و یک نقشه راه خاص برای عملیات شما است. بدون تماس فروش. بدون تعهد. فقط داده. از https://tfsfventures.com/assessment شروع کنید.
این مقاله در ابتدا در https://tfsfventures.com/blog/the-ai-agent-workflows-powering-bookkeeping-firms-closing-over-a-hundred-client منتشر شده است.
نوشته شده توسط تیم تحقیقاتی TFSF Ventures