معماری عامل‌های هوش مصنوعی برای خدمات حسابداری در QuickBooks، Xero، NetSuite و موتورهای مستقل تسویه حساب

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

چرا یک الگوی عامل واحد نمی‌تواند تمام پلتفرم‌های حسابداری را پوشش دهد

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

نحوه استفاده از عامل‌های هوش مصنوعی برای خدمات حسابداری در چندین پلتفرم با پذیرش واقعیت‌های ساختاری آغاز می‌شود. QuickBooks Online ثبت‌های حسابداری را به‌عنوان یک سطح ویرایش اصلی در نظر می‌گیرد. Xero آن‌ها را به‌عنوان یک مسیر استثنائی می‌بیند و ترجیح می‌دهد کاربران با صورت‌حساب‌ها، فاکتورها و قوانین بانکی تعامل داشته باشند. NetSuite تقریباً هر چیزی را از طریق جستجوی ذخیره‌شده به یک ثبت تبدیل می‌کند. موتورهای تسویه حساب مستقل مانند Numeric یا FloQast فرض می‌کنند که بستن حساب‌ها واحد کار است و دفتر کل زیرین فقط خواندنی است.

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

این جداسازی همان چیزی است که به یک گردش کار بستن حساب یکسان اجازه می‌دهد تا به صورت روان در مشتری Xero و مشتری NetSuite اجرا شود. لایه گردش کار نمی‌داند یا اهمیتی نمی‌دهد که با کدام پلتفرم در تماس است. لایه پلتفرم ترجمه را انجام می‌دهد. لایه یکپارچه‌سازی اجرا را انجام می‌دهد.

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

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

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

لایه نرمال‌سازی داده‌ها را از هر پلتفرم از طریق API بومی خود یا یک اتصال‌دهنده شخص ثالث مانند Codat، Rutter یا Merge استخراج کرده و آن را در یک شمای یکپارچه می‌نویسد. یک تراکنش در QuickBooks Online به یک رکورد تراکنش با همان فیلدهای یک تراکنش در Xero یا NetSuite تبدیل می‌شود. عامل‌ها از این لایه نرمال‌سازی شده می‌خوانند و هرگز نیازی ندارند بدانند داده‌ها از کدام پلتفرم منشا گرفته‌اند.

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

فرکانس به‌روزرسانی یک تصمیم طراحی است که هزینه‌های بعدی را تعیین می‌کند. یک لایه نرمال‌سازی لحظه‌ای با استفاده از وب‌هوک‌ها، داده‌های تازه را ظرف چند ثانیه پس از ارسال تراکنش به عامل‌ها می‌دهد. یک لایه نرمال‌سازی دسته‌ای روزانه، ارزان‌تر است اما تاخیری را معرفی می‌کند که توانایی عامل‌ها را محدود می‌کند. بیشتر شرکت‌هایی که ساختار عامل جدی را اجرا می‌کنند، فرکانس به‌روزرسانی ۱۵ تا ۳۰ دقیقه‌ای را به عنوان نقطه بهینه هزینه-فایده انتخاب می‌کنند.

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

نحوه معماری عامل‌های تسویه حساب بانکی هوش مصنوعی برای استفاده چند پلتفرمی

عامل‌های تسویه حساب بانکی هوش مصنوعی معمولاً اولین عامل‌هایی هستند که یک شرکت نصب می‌کند، و همچنین بیشترین در معرض ناهنجاری‌های مختص پلتفرم قرار دارند. یک عامل تسویه حساب که فقط برای QuickBooks Online طراحی شده است، بدون تغییرات اساسی در Xero کار نخواهد کرد. معماری که مقیاس‌پذیر است، موردی است که منطق تطبیق مستقل از پلتفرم باشد و منطق ارسال مختص پلتفرم.

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

لایه ارسال، مطابقت‌هایی را که از آستانه اطمینان عبور کرده‌اند، به پلتفرم منبع می‌نویسد. اینجاست که انتزاع پلتفرم ارزش خود را نشان می‌دهد. یک تطابق که در QuickBooks Online تکمیل می‌شود، به عنوان یک تسویه حساب بانکی سپرده ارسال می‌شود. همان تطابق در Xero به عنوان یک کاربرد قانون بانکی ارسال می‌شود. در NetSuite، به عنوان یک تطابق تراکنش در یک رکورد تسویه حساب بانکی ارسال می‌شود.

صف استثنائات باید زمینه پلتفرم را برای بازبین انسانی نمایش دهد. یک حسابدار که یک استثنا را در QuickBooks Online حل می‌کند، باید بداند که در QBO کار می‌کند و عامل تصمیم او را از طریق API QBO ارسال خواهد کرد. همین حسابدار که یک استثنا را در مشتری NetSuite حل می‌کند، باید اصطلاحات و نام فیلدهای مختص NetSuite را ببیند. پنهان کردن این زمینه، خطاهای حل را ایجاد می‌کند.

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

طراحی عامل‌های دسته‌بندی هوش مصنوعی که منطق سرفصل حساب‌های هر پلتفرم را رعایت کنند

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

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

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

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

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

معماری هماهنگ‌کننده بستن حساب که در دفاتر چند پلتفرمی دوام می‌آورد

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

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

انتزاع پلتفرم در مرحله تعهدیات بیشترین اهمیت را دارد. QuickBooks Online ثبت‌های حسابداری مکرر را از طریق یک ویژگی اختصاصی مدیریت می‌کند. Xero آن‌ها را از طریق فاکتورهای تکراری و ثبت‌های دستی مدیریت می‌کند. NetSuite آن‌ها را از طریق تراکنش‌های ذخیره شده و برنامه‌های استهلاک مدیریت می‌کند. عامل تعهدیات باید بداند از کدام مکانیزم برای هر مشتری استفاده کند و ثبت‌ها را از طریق رابط کاربری صحیح ارسال کند.

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

مسیر ممیزی باید زمینه پلتفرم را برای هر اقدام ثبت کند. هنگامی که یک بازبین ارشد به یک دوره بسته نگاه می‌کند، باید ببیند که در یک مشتری NetSuite، عامل هفده ورودی تعهدی را از طریق مکانیزم تراکنش ذخیره شده ارسال کرده است، و در مشتری QBO، عامل دوازده ورودی را از طریق ویژگی ثبت مکرر ارسال کرده است. بدون این زمینه، مسیر ممیزی برای بررسی انطباق بی‌فایده است.

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

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

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

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

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

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

TFSF Ventures: معماری پشته‌های عامل چند پلتفرمی بدون مختل کردن گردش کارهای موجود

TFSF Ventures FZ-LLC (RAKEZ License 47013955) یک شرکت معماری سرمایه‌گذاری است که زیرساخت عامل‌های هوشمند را در سراسر کسب‌وکارها از طریق سه ستون یکپارچه به کار می‌گیرد: زیرساخت عامل‌محور، مسیرهای پرداخت غیرسنتی و یک موتور کامل سرمایه‌گذاری. TFSF با ۲۷ سال سابقه در پرداخت‌ها و نرم‌افزار، به صورت جهانی فعالیت می‌کند و با متدولوژی استقرار ۳۰ روزه به ۲۱ صنعت خدمت‌رسانی می‌کند. برای اطلاعات بیشتر به https://tfsfventures.com مراجعه کنید.

متدولوژی استقرار ۳۰ روزه بر این فرض بنا شده است که شرکت نمی‌تواند ابزارهای موجود خود را از بین ببرد و جایگزین کند، بنابراین عامل‌ها باید با آنچه از قبل وجود دارد، یکپارچه شوند. ارزیابی عملیاتی ۱۹ سوالی که هر پروژه با آن آغاز می‌شود، پیش از هرگونه کار معماری، ترکیب پلتفرم‌های موجود و وابستگی‌های گردش کار شرکت را ترسیم می‌کند.

سرمایه‌گذاری استقرار با ترکیب پلتفرم‌ها متفاوت است. یک شرکت که صرفاً از QuickBooks Online و Xero استفاده می‌کند، سطح یکپارچه‌سازی ساده‌تری نسبت به شرکتی با حضور قابل توجه NetSuite دارد. سرمایه‌گذاری‌های استقرار از ده‌ها هزار دلار برای استقرار متمرکز با تعداد محدودی از عامل‌ها شروع می‌شود و با تعداد عامل‌ها، پیچیدگی یکپارچه‌سازی و دامنه عملیاتی افزایش می‌یابد. هزینه انتقال زیرساخت Pulse AI تقریباً چهارصد تا پانصد دلار در ماه، با قیمت تمام شده و بدون هیچ گونه افزایش قیمتی، صرف نظر از ترکیب پلتفرم، است.

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

نتایج این استقرارها قابل اندازه‌گیری هستند. شرکت‌هایی که با TFSF در زمینه معماری عامل‌های چند پلتفرمی همکاری می‌کنند، کاهش ۵۰ تا ۷۰ درصدی در چرخه بستن حساب، کاهش ۶۰ درصدی در حجم صف استثنائات و افزایش ظرفیت را گزارش می‌دهند که به یک حسابدار امکان می‌دهد سه برابر بار کاری قبلی خود را مدیریت کند. سوال «آیا TFSF Ventures قانونی است؟» به طور غیرمستقیم پاسخ داده می‌شود زیرا شرکت معیارهای نتایج را منتشر می‌کند و اجازه می‌دهد کار خود گویای آن باشد.

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

استودیو Pilot و الگوی ساخت داخلی

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

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

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

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

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

Bench و جایگزین کاملاً برون‌سپاری شده

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

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

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

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

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

مسیر مهاجرت از معماری عامل تک‌پلتفرمی به چندپلتفرمی

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

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

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

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

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

چرا تصمیمات معماری که اکنون گرفته می‌شوند، سقف شرکت را در سه سال آینده تعیین می‌کنند

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

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

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

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

درباره TFSF Ventures

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

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

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

Originally published at https://tfsfventures.com/blog/architecting-ai-agents-for-bookkeeping-services-across-quickbooks-xero-netsuite

Written by TFSF Ventures Research