معماری اتوماسیون هوش مصنوعی برای شرکتهای آمادهسازی مالیاتی در SurePrep، GruntWorx، CCH Axcess و موتورهای ورودی سند مستقل
رویکردی برای ترکیب SurePrep, GruntWorx, CCH Axcess و موتورهای ورودی مستقل به یک لایه عملیاتی که در اوج فصل مالیاتی پایدار بماند.
معماری اتوماسیون هوش مصنوعی برای شرکتهای آمادهسازی مالیاتی در SurePrep، GruntWorx، CCH Axcess و موتورهای ورودی سند مستقل، مسئله انتخاب پلتفرم نیست. بلکه مسئله نحوه ترکیب آنها در یک لایه عملیاتی است که کل چرخه حیات یک پروژه مالیاتی را بدون وادار کردن بازبینان به جبران درزهای بین فروشندگان مدیریت کند. شرکتهایی که این موضوع را درست انجام میدهند، ترکیب را به عنوان مشکل اصلی طراحی و انتخاب پلتفرم را به عنوان پیامد ثانویه آن طراحی در نظر میگیرند.
آنچه در ادامه میآید، روشی برای معماری آن لایه است که بر اساس تصمیماتی سازماندهی شده است که تعیین میکنند آیا سیستم تحت حجم اوج فصلی دوام میآورد یا در بدترین زمان ممکن از کار میافتد.
با چرخه حیات پروژه شروع کنید، نه با پلتفرم
بیشتر شرکتهای مالیاتی با پرسیدن این سوال که کدام پلتفرم گردش کار ترجیحی آنها را مدیریت میکند، به اتوماسیون نزدیک میشوند. این سوال پشتهای را تولید میکند که متناسب با پلتفرم است اما نه با پروژه. سوال شروع صحیح برعکس است. یک پروژه واقعاً از پایان تا پایان چگونه به نظر میآید، از لحظهای که مشتری اولین سند را بارگذاری میکند تا لحظهای که اظهارنامه ثبت و پروژه بسته میشود.
این چرخه حیات در بیشتر شرکتها شش مرحله مجزا دارد. پیش از آغاز پروژه، که در آن مشتری اسناد منبع را ارسال میکند و شرکت تصمیم میگیرد که آیا پروژه را بپذیرد یا خیر. ورودی، که در آن اسناد سازماندهی و دادهها استخراج میشوند. آمادهسازی، که در آن اظهارنامه ساخته میشود. بررسی، که در آن اظهارنامه اعتبار سنجی میشود. تحویل، که در آن اظهارنامه به مشتری میرسد و امضاها جمعآوری میشوند. و پس از اتمام پروژه، که در آن تأییدیه ثبت الکترونیکی پیگیری میشود و پروژه بسته میشود.
هر مرحله دارای تنگناهای خاص خود، الگوهای خطای خاص خود و فرصتهای خاص خود برای اتوماسیون هوش مصنوعی برای شرکتهای آمادهسازی مالیاتی است تا کاری را که هرگز نیازی به توجه انسانی نداشته است، حذف کند. تصمیمات معماری که در ادامه میآید، ناشی از درک این است که کدام مراحل برای شرکت خاص تنگنا هستند و کدام مراحل در حال حاضر به طور تمیز در حال اجرا هستند.
شرکتی که هر مرحله را به یک اندازه مهم میداند، در نهایت با پشتهای روبرو میشود که در همه جا متوسط است. شرکتی که دو یا سه مرحله را که بیشترین ساعات preparer را به خود اختصاص میدهند، شناسایی و بیش از حد در آن مراحل سرمایهگذاری میکند، در نهایت با پشتهای روبرو میشود که بازده نامتناسبی را از سرمایهگذاری استقرار ارائه میدهد.
لایه ورودی سند را بر اساس تغییرات اسناد منبع ترسیم کنید
ورودی سند مرحلهای است که در آن بیشتر شرکتهای مالیاتی بیشترین تفاوت را در عملکرد دارند، زیرا تفاوت در خود اسناد منبع بسیار زیاد است. شرکتی که عمدتاً W-2 و 1099 را مدیریت میکند، میتواند یک لایه ورودی نسبتاً ساده را مستقر کند. شرکتی با فعالیت قابل توجه K-1، مشارکت یا تراست، به یک لایه ورودی نیاز دارد که فرمهایی را که استخراجکنندههای استاندارد به خوبی مدیریت نمیکنند، اداره کند.
روش ترسیم لایه ورودی با موجودی سند آغاز میشود. شرکت نمونهای نماینده از اظهارنامههای فصل قبل را میکشد و هر نوع سند منبع متمایزی را که در آن اظهارنامهها ظاهر شده است، فهرست میکند. نتیجه معمولاً دنباله طولانیای از انواع اسناد فراتر از W-2، 1099، K-1 و 1098 استاندارد است، شامل فرمهای خاص ایالتی، اسناد مالیاتی خارجی، صورتهای تلفیقی کارگزاری با طرحبندیهای غیر استاندارد و اسناد یکبار مصرف که فقط در تعداد انگشتشماری از اظهارنامهها ظاهر میشوند.
لایه ورودی باید اسناد با فرکانس بالا را با اتوماسیون کامل و اسناد با دنباله طولانی را با رویکردی ترکیبی که استخراج را با بررسی انسانی ترکیب میکند، مدیریت کند. تلاش برای اتوماسیون کامل دنباله طولانی، نرخ خطایی را تولید میکند که اعتماد بازبین را به کل سیستم از بین میبرد. دستی رها کردن کامل دنباله طولانی، تنگناهایی را تولید میکند که در طول اوج فصل، زمانی که اسناد با دنباله طولانی به صورت عمده میرسند، بروز پیدا میکند.
الگوی صحیح معمولاً یک لایه استخراج دو مرحلهای است. مرحله اول اسناد با فرکانس بالا را با اتوماسیون کامل و امتیاز اطمینان مدیریت میکند. مرحله دوم اسناد با دنباله طولانی را با استخراج جزئی که فیلدهایی را که مدل در مورد آنها نامطمئن است پرچمگذاری میکند، مدیریت میکند. مرحله سوم اسناد واقعاً جدید را با تصمیم مسیریابی مدیریت میکند که آنها را به یک بازبین خاص آموزشدیده در مورد آن نوع سند ارسال میکند.
شرکتهایی که لایه ورودی را به این روش میسازند، گزارش میدهند که دنباله طولانی دیگر یک مشکل تعیینکننده فصل نیست. اسناد با فرکانس بالا به طور تمیز جریان مییابند، اسناد با دنباله طولانی اتوماسیون جزئی دریافت میکنند که هنوز زمان preparer را صرفهجویی میکند و اسناد جدید بدون پرش در شرکت به شخص مناسب میروند.
لایه آمادهسازی را برای چگالی گردش کار طراحی کنید، نه عمق ویژگی
پلتفرمهای آمادهسازی مالیاتی بر اساس عمق ویژگی رقابت میکنند. آنها هر فرمی را که پشتیبانی میکنند، هر ایالتی را که پوشش میدهند، هر محاسباتی را که خودکار میکنند، فهرست میکنند. شرکتهایی که اتوماسیون هوش مصنوعی را برای شرکتهای آمادهسازی مالیاتی طراحی میکنند، به سرعت متوجه میشوند که عمق ویژگی کمتر از چگالی گردش کار در مقیاس اهمیت دارد.
چگالی گردش کارMeasure of an efficient workflow for a preparer, measured by the number of returns processed per hour without errors that surface during review. یک پلتفرم با ویژگیهای عمیق اما چگالی گردش کار پایین، preparerهایی را تولید میکند که زمان خود را صرف پیمایش در پلتفرم میکنند تا کار بر روی اظهارنامهها. یک پلتفرم با ویژگیهای کافی اما چگالی گردش کار عالی، preparerهایی را تولید میکند که در هر ساعت اظهارنامههای بیشتری را با تعداد کمتر ارجاع برای بررسی به پایان میرسانند.
روش ارزیابی چگالی گردش کار نیاز به اجرای اظهارنامههای نماینده از طریق پلتفرم با مشاهده زمانبندی شده دارد. شرکت پنج یا ده نوع اظهارنامه رایج را انتخاب میکند، هر کدام را با یک preparer ارشد از طریق پلتفرم اجرا میکند و زمان صرف شده برای ورود داده، پیمایش، اعتبار سنجی و بررسی را اندازهگیری میکند. نتیجه یک پروفایل زمانی برای هر اظهارنامه است که نشان میدهد پلتفرم در کجا کمک میکند و در کجا preparerها را کند میکند.
شرکتهایی که این ارزیابی را انجام میدهند، اغلب متوجه میشوند که پلتفرم با عمیقترین مجموعه ویژگیها، پلتفرمی با بهترین چگالی گردش کار برای ترکیب اظهارنامه خاص خود نیست. پلتفرم مناسب، پلتفرمی است که سربار پیمایش را برای اظهارنامههایی که شرکت واقعاً بایگانی میکند، به حداقل میرساند، نه پلتفرمی که بیشترین تیک را در مقایسه ویژگیها دارد.
تصمیم معماری از این ارزیابی ناشی میشود. شرکت پلتفرمی را با بهترین چگالی گردش کار برای حجم عمده اظهارنامههای خود انتخاب میکند و میپذیرد که برای اظهارنامههای پیچیده با دنباله طولانی به راهحلهای موقت نیاز خواهد داشت. این راهحلهای موقت معمولاً به شکل preparerهای ارشد هستند که اظهارنامههای پیچیده را مستقیماً بدون وادار کردن آنها از طریق پلتفرم رسیدگی میکنند، یا یک پلتفرم ثانویه که نوع خاصی از اظهارنامه را که پلتفرم اصلی به خوبی مدیریت نمیکند، رسیدگی میکند.
لایه بررسی را به عنوان یک خط لوله چند مرحلهای بسازید
بررسی جایی است که بیشتر شرکتهای مالیاتی یا خطاها را مهار میکنند یا اجازه میدهند آنها به مشتریان برسند. روش طراحی لایه بررسی آن را به عنوان یک خط لوله چند مرحلهای در نظر میگیرد تا یک بار بررسی، با هر مرحله که دسته متفاوتی از خطا را تشخیص میدهد.
مرحله اول، اعتبار سنجی خودکار است که با تکمیل اظهارنامه توسط preparer اجرا میشود. این مرحله خطاهای ریاضی، فیلدهای گمشده و تناقضات آشکار را تشخیص میدهد. preparer نتایج اعتبار سنجی را در زمان واقعی میبیند و آنها را قبل از ارسال اظهارنامه برای بررسی اصلاح میکند.
مرحله دوم، بررسی مبتنی بر قوانین است که پس از علامتگذاری اظهارنامه به عنوان کامل توسط preparer اجرا میشود. این مرحله قوانین خاص شرکت را اعمال میکند که پلتفرم آمادهسازی به طور پیشفرض آنها را اجرا نمیکند. مثالها شامل آستانهها برای بررسی مرحله دوم در فعالیت Schedule C، بررسی اجباری اظهارنامههای با اعتبار مالیاتی خارجی و تأییدیه ارشد اجباری اظهارنامههای با فعالیت K-1 قابل توجه است.
مرحله سوم، بررسی انسانی توسط یک بازبین مشخص است که اظهارنامه را با نتایج اعتبار سنجی و قوانین از قبل پیوست شده بررسی میکند. بازبین بر تصمیمات قضاوتی تمرکز میکند که مراحل خودکار نمیتوانند انجام دهند، مانند اینکه آیا فعالیت تجاری اعلام شده مشتری با اظهارنامه آماده شده مطابقت دارد یا اینکه کسرها با توجه به دانش شرکت از مشتری منطقی هستند.
مرحله چهارم، تأییدیه در سطح شریک در زیرمجموعهای از اظهارنامهها است که معیارهای بررسی شریک را برآورده میکنند. این مرحله برای پیچیدهترین پروژهها رزرو شده و برای تشخیص خطای نادری است که تمام مراحل قبلی از دست دادهاند.
شرکتهایی که این خط لوله را اجرا میکنند، گزارش میدهند که نرخ خطا در زمان تحویل در مقایسه با شرکتهایی که یک بار بررسی انجام میدهند، به یک مرتبه کاهش مییابد. هزینه، یک گردش کار پیچیدهتر است، اما چگالی گردش کار لایه آمادهسازی بیشتر این پیچیدگی را جذب میکند زیرا preparerها مراحل پشتیبان را مستقیماً نمیبینند.
ارتباط با مشتری را وارد چرخه حیات کنید، نه اطراف آن
ارتباط با مشتری مرحلهای است که اکثر شرکتها آن را جدا از بقیه پروژه در نظر میگیرند. این جدایی منبع مقدار زیادی از زمان preparer است، زیرا preparerها در وسط کار بر روی اظهارنامهها به سوالات روتین مشتری پاسخ میدهند.
روش وارد کردن ارتباط با مشتری به چرخه حیات، هر تعامل preparer-مشتری را به عنوان یک نامزد برای اتوماسیون در نظر میگیرد. درخواستهای سند، به روزرسانیهای وضعیت، یادآوریهای امضا و پاسخهای سوالات اساسی همگی در الگوهایی قرار میگیرند که یک عامل ارتباطی مشتری مالیاتی هوش مصنوعی میتواند بدون دخالت preparer مدیریت کند.
این معماری سه لایه دارد. لایه اول یک پورتال مشتری است که بارگذاری سند، قابلیت مشاهده وضعیت و فرمهای اساسی را مدیریت میکند. لایه دوم یک عامل ارتباطی خودکار است که سوالات روتین، درخواستهای سند و به روزرسانیهای وضعیت را مدیریت میکند. لایه سوم ارجاع preparer برای سوالاتی است که عامل نمیتواند به آنها پاسخ دهد و برای پروژههایی که مشتری صراحتاً درخواست مکالمه با preparer را دارد.
شرکتهایی که این معماری را به طور تمیز میسازند، گزارش میدهند که زمان preparer صرف شده برای ارتباط روتین با مشتری در طول اوج فصل، شصت تا هفتاد درصد کاهش مییابد. صرفهجویی در اوایل فصل، زمانی که پیگیری سند سنگینتر است و در اواخر فصل، زمانی که جمعآوری امضا بیشتر لمسهای روتین را به خود اختصاص میدهد، متمرکز است.
مبادله این است که معماری نیاز به طراحی دقیق دارد تا از پاسخ دادن عامل به سوالاتی که باید ارجاع دهد، جلوگیری شود. الگوی صحیح یک آستانه اطمینان است که برای هر سوالی خارج از دامنه تعریف شده، به طور پیشفرض به ارجاع میپردازد. شرکتهایی که این را اشتباه انجام میدهند، در نهایت مشتریانی را خواهند داشت که از عامل پاسخهای اشتباه دریافت میکنند و اعتماد خود را به شرکت از دست میدهند. شرکتهایی که آن را درست انجام میدهند، در نهایت مشتریانی را خواهند داشت که پاسخهای سریعتر به سوالات روتین و همان کیفیت توجه preparer را به سوالات اساسی دریافت میکنند.
مدیریت استثنائات را قبل از طراحی اتوماسیون مسیر مثبت طراحی کنید
اکثر استقرارهای اتوماسیون در لایه مدیریت استثنائات شکست میخورند. مسیر مثبت به طور تمیز کار میکند زیرا تیمی که اتوماسیون را طراحی میکند بر مسیر مثبت تمرکز کرده است. استثنائات سیستم را از کار میاندازند زیرا تیم به اندازه کافی برای تصمیمگیری در مورد اتفاقی که وقتی استخراج اشتباه است، وقتی مشتری سندی را بارگذاری میکند که با هیچ الگوی شناخته شدهای مطابقت ندارد، یا وقتی اظهارنامه قانونی را فعال میکند که نیاز به تصمیمی دارد که سیستم نمیتواند بگیرد، سرمایهگذاری نکرده است.
روش طراحی مدیریت استثنائات قبل از ساخت اتوماسیون مسیر مثبت آغاز میشود. شرکت دستههای استثنائات را که در عملیات فعلی خود رخ میدهند، کاتالوگ میکند، آنها را بر اساس فرکانس و تأثیر رتبهبندی میکند و مسیریابی برای هر دسته را قبل از استقرار هر اتوماسیونی طراحی میکند.
دستهها معمولاً به سه گروه تقسیم میشوند. استثنائات خودکار حلشونده، که سیستم میتواند با تلاش مجدد، بازگشت به یک استخراجکننده ثانویه، یا اعمال یک قانون پیشفرض، آنها را مدیریت کند. استثنائات با حل کمکی، که نیاز به تصمیم انسانی دارند اما میتوانند با تمام زمینه از قبل جمعآوری شده به انسان ارائه شوند. و استثنائات ارجاعی، که نیاز به قضاوت ارشد دارند و باید بدون پرش از طریق واسطهها به شخص مناسب هدایت شوند.
معماری برای مدیریت هر دسته متفاوت به نظر میرسد. حل خودکار به طور کامل در لایه اتوماسیون زندگی میکند و فقط در گزارشدهی به عنوان شمارش کلی ظاهر میشود. حل کمکی به عنوان یک صف با استثناء، زمینه و اقدامات پیشنهادی به طور همزمان ظاهر میشود. ارجاع به عنوان یک اعلان به بازبین ارشد مناسب با زمینه کامل پروژه پیوست میشود.
شرکتهایی که مدیریت استثنائات را به این روش طراحی میکنند، گزارش میدهند که سیستم تحت حجم اوج فصل دوام میآورد زیرا استثنائات متناسب با دشواری واقعی آنها مدیریت میشوند تا اینکه همگی به یک صف بررسی بیش از حد کار شده سرازیر شوند. شرکتهایی که این مرحله طراحی را نادیده میگیرند، گزارش میدهند که سیستم در اولین افزایش قابل توجه استثناء، معمولاً در اوایل مارس که حجم سند به اوج خود میرسد، از کار میافتد.
لایه داده را برای هوش متقابل پروژه معماری کنید
لایه داده بنیادی است که تعیین میکند آیا سیستم میتواند هوش را فراتر از یک پروژه واحد ارائه دهد. سیستمی که هر پروژه را جداگانه در نظر میگیرد، الگوهایی را که در کتاب تجاری شرکت ظاهر میشوند، از دست میدهد. سیستمی که یک لایه داده یکپارچه در بین پروژهها میسازد، میتواند این الگوها را آشکار کند و از آنها برای بهبود هر پروژه بعدی استفاده کند.
روش معماری لایه داده با تصمیمی در مورد اینکه چه دادههایی و با چه جزئیاتی باید ضبط شوند، آغاز میشود. شرکت تصمیم میگیرد که کدام رویدادها ثبت شوند، کدام مقادیر استخراج شده ذخیره شوند، کدام اقدامات preparer ردیابی شوند و کدام تعاملات مشتری ثبت شوند. تصمیمات باید با دقت گرفته شوند، زیرا ضبط بیش از حد مشکلات بهداشت داده ایجاد میکند و ضبط کمتر، شرکت را بدون ورودیهای لازم برای هوش متقابل پروژه رها میکند.
الگوی صحیح معمولاً ضبط رویدادها و نتایج است که تصمیمات عملیاتی را هدایت میکنند، ذخیره آنها در یک الگوی یکپارچه در بین پروژهها و ساخت لایه هوش بر روی آن الگو. مثالهایی از رویدادهای ارزشمند برای ضبط شامل مهر زمانی ورود سند، امتیازات اطمینان استخراج، نتایج اعتبار سنجی، ارجاعات بررسی و لمسهای ارتباط با مشتری است.
شرکتهایی که لایه داده را به این روش میسازند، میتوانند به سوالاتی مانند اینکه کدام نوع سند بیشترین استثنائات را برای کدام بخشهای مشتری ایجاد میکند، کدام preparerها کدام نوع اظهارنامه را به کارآمدترین شکل مدیریت میکنند و کدام مشتریان بیشترین سربار preparer را نسبت به هزینه تولید میکنند، پاسخ دهند. این پاسخها در طول زمان به تصمیمات مربوط به استخدام، تصمیمات مربوط به قیمتگذاری و تصمیمات مربوط به ترکیب مشتری بازخورد میدهند.
مبادله این است که ساخت لایه داده هزینه اولیه و نگهداری مداوم را به استقرار اضافه میکند. شرکتهایی که از آن صرف نظر میکنند، استقرار اولیه سریعتری دارند اما نمیتوانند بعداً به هوش متقابل پروژه دست پیدا کنند بدون بازسازی. شرکتهایی که در آن سرمایهگذاری میکنند، استقرار اولیه طولانیتری دارند اما میتوانند هوش را در طول چندین فصل ترکیب کنند.
زیرساخت تولید را به عنوان یک سرمایهگذاری چند ساله در نظر بگیرید
شرکتهایی که بیشترین بهره را از اتوماسیون هوش مصنوعی برای شرکتهای آمادهسازی مالیاتی میبرند، استقرار را به عنوان یک سرمایهگذاری چند ساله در زیرساخت تولید به جای خرید یکباره فروشنده در نظر میگیرند. روش مدیریت این سرمایهگذاری نیاز به وضعیت عملیاتی متفاوتی نسبت به چرخه خرید نرمافزار معمول دارد.
چرخه حیات سرمایهگذاری چهار مرحله دارد. استقرار اولیه، که اتوماسیون اصلی را اجرا میکند و ارزش را ثابت میکند. تنظیم فصل اول، که اتوماسیون را بر اساس آنچه اولین اوج فصل نشان داد، تنظیم میکند. مقیاسگذاری فصل دوم، که اتوماسیون را به انواع پروژه اضافی و عملیات شرکت اضافی گسترش میدهد. و نگهداری مداوم، که درزهای یکپارچگی را با تکامل پلتفرمهای زیربنایی به روز نگه میدارد.
هر مرحله به منابع متفاوتی نیاز دارد. استقرار اولیه عمدتاً یک سرمایهگذاری معماری و مهندسی است. تنظیم فصل اول عمدتاً یک سرمایهگذاری عملیاتی با پشتیبانی مهندسی است. مقیاسگذاری فصل دوم ترکیبی از معماری، مهندسی و عملیات است. نگهداری مداوم عمدتاً یک سرمایهگذاری مهندسی با پشتیبانی عملیاتی است.
یک روش استقرار 30 روزه فاز استقرار اولیه را با استقرار زیرساخت تولید در یک مرحله اول با دامنه محدود فشرده میکند و فازهای بعدی را به عنوان افزونههای طبیعی ساخت اولیه در نظر میگیرد. این روش فرض میکند که شرکت به سرمایهگذاری در اتوماسیون ادامه خواهد داد تا اینکه استقرار اولیه را پایان کار تلقی کند. سرمایهگذاریهای استقرار از دهها هزار دلار برای مراحل اولیه متمرکز با تعداد محدودی عامل آغاز میشود و با تعداد عامل، پیچیدگی یکپارچگی و دامنه عملیاتی مقیاسپذیر میشود.
مدل قیمتگذاری برای این نوع استقرار به اندازه معماری اهمیت دارد. مدلی که به ازای هر اظهارنامه یا هر کاربر هزینه دریافت میکند، انگیزانندههایی را ایجاد میکند که در مقیاس در برابر شرکت کار میکنند. مدلی که استقرار را بر اساس دامنه قیمتگذاری میکند و شامل انتقال زیرساخت با هزینه است، انگیزانندهها را در سراسر رابطه همسو میکند. هزینه انتقال زیرساخت معمولاً چهارصد تا پانصد دلار در ماه برای زیرساخت هوش مصنوعی است که با هزینه و بدون مارکآپ (افزایش قیمت) شارژ میشود.
الگوهای یکپارچهسازی را انتخاب کنید که تکامل پلتفرم را تحمل کنند
هر یکپارچگی در پشته، یک نقطه بالقوه شکست است زمانی که یکی از پلتفرمها بهروزرسانی میشود. روش انتخاب الگوهای یکپارچهسازی، الگوهایی را که تکامل پلتفرم را تحمل میکنند، بر الگوهایی که عمق یکپارچهسازی کوتاهمدت را به حداکثر میرسانند، اولویت میدهد.
الگوهای انعطافپذیرتر معمولاً آنهایی هستند که از APIهای مستند با قراردادهای پایدار استفاده میکنند. کمترین انعطافپذیری معمولاً آنهایی هستند که رابطهای کاربری پلتفرم را خراش میدهند یا به نقاط پایانی داخلی (endpoint) مستند نشده متکی هستند. بین این دو حد، الگوهایی که به صادرات فایل، وظایف دستهای برنامهریزیشده و فرمتهای تبادل داده به خوبی تعریف شده متکی هستند، تمایل دارند بهتر از الگوهایی که به جریانهای رویداد بلادرنگ یا هوکهای عمیق پلتفرم متکی هستند، دوام بیاورند.
تصمیم معماری شامل بده بستانها (trade-offs) است. یکپارچگیهای انعطافپذیر معمولاً قابلیتهای کمتری نسبت به یکپارچگیهای شکننده دارند. شرکتی که انعطافپذیری را اولویت میدهد، جریان داده کندتر و یکپارچگی کمتر جزئی را در ازای سیستمی میپذیرد که هر بار که یک پلتفرم بهروزرسانی میشود، از کار نمیافتد. شرکتی که عمق یکپارچهسازی را اولویت میدهد، بار نگهداری بالاتری را در ازای عملکرد غنیتر میپذیرد.
شرکتهایی که 5000 اظهارنامه و بیشتر را پردازش میکنند، معمولاً به یک راه میانه میرسند. آنها از الگوهای انعطافپذیر برای یکپارچگیهایی که بخش عمده حجم آنها را مدیریت میکنند، استفاده میکنند و الگوهای شکننده را برای یکپارچگیهای خاص با ارزش بالا که در آن عمق اهمیت بیشتری نسبت به انعطافپذیری دارد، میپذیرند. آنها برای نگهداری مداوم یکپارچگیهای شکننده بودجه در نظر میگیرند و از ایجاد وابستگی به آنها در جریان عملیاتی اصلی خودداری میکنند.
معماری همچنین از گنجاندن یک لایه بافر بین منطق عملیاتی شرکت و یکپارچگیهای پلتفرم بهره میبرد. بافر تغییرات پلتفرم را بدون اجبار منطق عملیاتی به تغییر در پاسخ جذب میکند. شرکتهایی که این بافر را میسازند، گزارش میدهند که بهروزرسانیهای پلتفرم به یک رویداد نگهداری روتین تبدیل میشوند تا یک تمرین اضطراری که عملیات را مختل میکند.
مالکیت کد و استقلال از فروشنده را تأیید کنید
آخرین تصمیم معماری، تصمیمی است که تعیین میکند چه اتفاقی میافتد وقتی شرکت میخواهد فروشندگان، معماران را تغییر دهد یا سیستم را در جهاتی تکامل بخشد که استقرار اولیه پیشبینی نمیکرد. روش محافظت از این انعطافپذیری بر مالکیت کد و استقلال از فروشنده متمرکز است.
شرکت باید مالک کدی باشد که اتوماسیون آن را اجرا میکند. نه مجوز استفاده از آن. نه اشتراک در نسخه میزبانی شده آن. کد واقعی، در مخزنی که شرکت کنترل میکند، با حق تغییر، گسترش، فورک یا بازسازی هر بخش از آن بدون مذاکره با کسی. مالکیت کد چیزی است که به شرکت امکان تغییر مسیر را بدون رها کردن سرمایهگذاری میدهد.
استقلال از فروشنده مفهوم مرتبطی است. شرکت باید بتواند هر فروشندهای را در پشته بدون بازسازی کل سیستم جایگزین کند. فروشنده ورودی، پلتفرم آمادهسازی، لایه بررسی، عامل ارتباط با مشتری و لایه هماهنگی هر کدام باید قابل جایگزینی باشند بدون اینکه بقیه از کار بیفتند.
معماری برای استقلال از فروشنده نیاز به لایه بافر ذکر شده در بحث یکپارچهسازی دارد، به علاوه یک تصمیم عمدی برای جلوگیری از اتصال عمیق بین منطق عملیاتی شرکت و مدل داده هر فروشنده. بده بستان این است که معماریهای مستقل از فروشنده معمولاً کمتر از معماریهای با اتصال محکم، ظریف هستند. مزیت این است که شرکت گزینه تکامل سیستم را در طول زمان بدون مواجهه با بازسازی اجباری حفظ میکند.
روایت قیمتگذاری برای استقرار باید این استقلال را تقویت کند. قیمتگذاری شفاف و طبقاتی در هر پیشنهاد به شرکت امکان میدهد که بر اساس دامنه واقعی بودجهبندی کند تا اینکه بر سر اهداف متحرک مذاکره کند. قیمتگذاری باید منتشر شود، نه مورد به مورد مذاکره شود، تا شرکت قبل از شروع کار بداند به چه چیزی متعهد میشود.
آنچه این روش تولید میکند
شرکتی که این روش را به طور کامل به کار میبرد، یک پشتهای را تولید میکند که حجم اوج فصل را بدون وادار کردن بازبینان به جبران درزها مدیریت میکند. لایه ورودی اسناد را در طبقات مدیریت میکند. لایه آمادهسازی برای چگالی گردش کار بهینه میشود. لایه بررسی خطاها را در مراحل تشخیص میدهد. لایه ارتباط با مشتری لمسهای روتین را از زمان preparer حذف میکند. لایه مدیریت استثنائات ناهنجاریها را به مسیر حل مناسب هدایت میکند. لایه داده رویدادهایی را که هوش متقابل پروژه را هدایت میکنند، ضبط میکند. چرخه حیات سرمایهگذاری، استقرار را چند ساله در نظر میگیرد. الگوهای یکپارچهسازی تکامل پلتفرم را تحمل میکنند. مالکیت کد استقلال از فروشنده را محافظت میکند.
نتیجه یک سیستم کامل نیست. آمادهسازی مالیاتی به اندازه کافی پیچیدگی دارد که سیستمهای کامل قابل دستیابی نیستند. نتیجه سیستمی است که تحت حجمی که شرکت واقعاً پردازش میکند دوام میآورد، به طور آرام از استثنائات رخ داده بازیابی میشود و با انباشته شدن ورودیها در لایه داده که تصمیمات بهتر را هدایت میکنند، در طول زمان بهبود مییابد.
شرکتهایی که به این نتیجه میرسند، یک ویژگی فراتر از معماری خود را به اشتراک میگذارند. آنها قبل از اینکه به پلتفرمها متعهد شوند، به روش متعهد شدند و انتخاب پلتفرم را نتیجه روش در نظر گرفتند تا نقطه شروع. این تعهد چیزی است که پشتهای را تولید میکند که اوج فصل را تحمل میکند تا پشتهای که در آن زیر شکسته میشود.
درباره 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/architecting-ai-automation-for-tax-preparation-firms-across-sureprep-gruntworx
Written by TFSF Ventures Research