چگونه چهار عامل میتوانند عملیات وصول مطالبات را بدون ارسال حتی یک پیگیری توسط انسان مدیریت کنند
روشی تولیدی که نشان میدهد چگونه چهار عامل هماهنگ، یک بخش وصول مطالبات را به طور کامل اداره کرده و از روز اول نتایج هوش مصنوعی متعلق به خود را بدون وابستگی به فروشنده ارائه میدهند.
وصول مطالبات یکی از بخشهایی است که شرکتها به طور مداوم پولی را که قبلاً به دست آوردهاند، در آن از دست میدهند. فاکتورها صادر میشوند، مشتریان آنها را نادیده میگیرند، تیمهای مالی تعداد کمی از بزرگترین بدهیها را پیگیری میکنند و بدهیهای کوچک به تدریج تبدیل به بدهی سوختشده میشوند. روش زیر توضیح میدهد که چگونه چهار عامل تولیدی میتوانند یک بخش وصول مطالبات را به طور کامل اداره کنند، بدون اینکه انسانی حتی یک ایمیل پیگیری ارسال کند، و در عین حال نتایج عوامل هوش مصنوعی تولیدی را بدون وابستگی به فروشنده ارائه دهند، زیرا کد اصلی در داخل کسبوکاری که مالک آن است، اجرا میشود.
چرا وصول مطالبات اولین وظیفه مناسب برای خودکارسازی است
وصول مطالبات در یک تقاطع غیرمعمول قرار دارد. این کار حجیم، تکراری، با مهلتهای زمانی مشخص و از نظر احساسی برای انسانهایی که مسئول آن هستند، ناراحتکننده است. اکثر تیمهای مالی به آرامی اعتراف میکنند که پیگیری یک فاکتور شصت روزه از موعد گذشته به تعویق میافتد، زیرا هیچکس از نوشتن آن لذت نمیبرد. نتیجه قابل پیشبینی است. میانگین دوره وصول (DSO) هر سه ماه یک بار سه تا پنج روز افزایش مییابد، نرخ مطالبات سوخت شده به بالای دو درصد از درآمد میرسد و پولی که باید از قبل در حساب باشد، به جای آن سرمایه در گردش مشتری را تأمین میکند.
خودکارسازی در اینجا کارآمد است زیرا هر مرحله از فرآیند تحت قوانین مشخصی قرار دارد. فاکتوری وجود دارد. تاریخ سررسید وجود دارد. توافقنامه شرایط پرداخت وجود دارد. روال ارتباطی وجود دارد. مسیر تشدید وجود دارد. هیچ چیز در گردش کار استاندارد وصول مطالبات نیازی به قضاوت انسانی ندارد که نتوان آن را به عنوان یک خط مشی بیان کرد. در جایی که به قضاوت نیاز است، مانند تأیید یک برنامه پرداخت با مبلغی بیش از آستانه مشخص، عامل به جای ارائه یک پاسخ ساختگی، موضوع را به بالا ارجاع میدهد.
دلیل عمیقتر اینکه وصول مطالبات یک نقطه شروع قوی است، این است که نتایج مالی قابل اندازهگیری را ظرف سی روز پس از استقرار تولید میکند. میانگین دوره وصول یک معیار شفاف است. وجه وصول شده یک معیار شفاف است. نرخ مطالبات سوخت شده یک معیار شفاف است. هنگامی که کنترلر میپرسد که آیا استقرار ارزش هزینه را داشته است، پاسخ یک عدد است، نه یک احساس.
در میان استقرارهایی که توسط TFSF Ventures مدیریت شدهاند، الگوی معمولی در شصت روز اول، کاهش هشت تا چهارده روزه در میانگین دوره وصول و بازیابی هفتاد تا نود درصد از ماندههایی است که قبلاً از صد و بیست روز گذشته بودند. اعداد تغییر میکنند زیرا عوامل هر روز در هر حساب، هر مرحله را انجام میدهند، کاری که هیچ تیم مالی کمتعدادی هرگز انجام نداده است.
چهار عامل و مسئولیت هر یک
معماری از دقیقاً چهار عامل استفاده میکند که هر یک مسئولیت مشخص و واحدی دارند. تقسیم کار به چهار نقش، به جای ساختن یک عامل یکپارچه، چیزی است که سیستم را قابل اشکالزدایی، قابل مشاهده و قابل جایگزینی میسازد. اگر منطق یک عامل نیاز به تغییر داشته باشد، سه عامل دیگر دستنخورده باقی میمانند.
اولین عامل، ناظر عدم پرداخت (Aging Monitor) است. این عامل به طور مداوم در برابر سیستم حسابداری اجرا میشود و هر فاکتور باز را رصد میکند. تاریخ سررسید اصلی، شرایط پرداخت، رفتار پرداخت تاریخی مشتری و مانده حساب فعلی را میداند. هنگامی که یک فاکتور از آستانه تعریف شده عبور میکند، چه هفت روز، سی روز، شصت روز یا نود روز از موعد گذشته باشد، یک رویداد را ایجاد میکند. این عامل مستقیماً با مشتری مکاتبه نمیکند. بلکه یک سیگنال ساختاریافته تولید میکند که عامل بعدی را فعال میکند.
دومین عامل، پیشنویسساز ارتباط (Communication Drafter) است. وقتی فعال میشود، پیام مناسبی را برای مرحله عدم پرداخت، سابقه رابطه مشتری، مبلغ دلاری و زبان قرارداد اصلی تدوین میکند. یک یادداشت هفت روزه بعد از سررسید کوتاه است و بر فرض اشتباه سهوی استوار است. یک یادداشت شصت روزه به ارتباطات قبلی اشاره میکند، مانده حساب را مجدداً اعلام میکند و گزینههای حل و فصل را پیشنهاد میدهد. پیشنویسساز پیام را ارسال نمیکند. بلکه پیامها را تولید کرده و برای مرحله بعدی در صف قرار میدهد.
سومین عامل، فرستنده کانال (Channel Dispatcher) است. این عامل تصمیم میگیرد که هر پیام چگونه تحویل داده شود. ایمیل پیشفرض است. برای مبالغ بزرگتر یا مشتریانی که قبلاً پاسخ ندادهاند، فرستنده به تماس تلفنی از طریق یک کانال صوتی که متن آماده را میخواند، پاسخ را ثبت میکند و نتیجه را در سابقه پرونده مینویسد، ارجاع میدهد. برخی از حسابها اعلان پورتال دریافت میکنند. برخی دیگر نامهای فیزیکی که توسط یک شریک چاپی تولید میشود، دریافت میکنند. فرستنده قوانین را میداند و از آنها پیروی میکند.
چهارمین عامل، نهاییکننده تطبیق (Reconciliation Closer) است. هنگامی که پرداختی انجام میشود، این عامل تشخیص میدهد که پرداخت کدام فاکتور را تسویه میکند، آن را اعمال میکند، رسید را برای مشتری ارسال میکند، پرونده را میبندد و پروفایل رفتار پرداخت مشتری را به روز میکند تا ناظر عدم پرداخت بداند که دفعه بعد این مشتری را چگونه مدیریت کند. اگر پرداخت جزئی یا بدون سابقه باشد، نهاییکننده یا آن را بر اساس اطلاعات پرداخت تطبیق میدهد یا، در صورت عدم امکان تطبیق، استثنا را با یک خلاصه ساختاریافته به یک انسان ارجاع میدهد.
چگونه چهار عامل بدون دخالت انسان هماهنگ میشوند
یک حالت شکست رایج در طراحی عوامل این است که عوامل مستقیماً یکدیگر را فراخوانی کنند. این امر باعث اتصال محکم و شکنندگی سیستم میشود. معماری اینجا از مدل وضعیت مشترک استفاده میکند. هر فاکتور یک رکورد پرونده دارد. هر عامل از رکورد پرونده میخواند و در آن مینویسد. ناظر عدم پرداخت وضعیت را تنظیم میکند. پیشنویسساز پیام را مینویسد. فرستنده تحویل را ثبت میکند. نهاییکننده پرونده را حل شده علامت میزند.
این رویکرد چیزی است که نگهداری سیستم را برای سالها به جای ماهها امکانپذیر میسازد. هنگامی که شرکت سیاست دریافت مبالغ معوق خود را تغییر میدهد، فقط لازم است اعلان پیشنویسساز و آستانههای ناظر به روز شوند. فرستنده و نهاییکننده بدون تغییر به کار خود ادامه میدهند. هنگامی که شرکت یک پردازشگر پرداخت جدید اضافه میکند، فقط منطق تطبیق نهاییکننده تغییر میکند. سه عامل دیگر دستنخورده باقی میمانند.
مدل وضعیت مشترک همچنین قابلیت مشاهده را فراهم میکند. هر عملی که هر عامل انجام میدهد، با برچسب زمانی، ورودیهایی که عامل دیده است، خروجیهایی که تولید کرده است و نسخه اعلان یا منطق آن در زمان اجرا، در برابر رکورد پرونده ثبت میشود. هنگامی که کنترلر میپرسد چرا یک مشتری خاص پیام خاصی دریافت کرده است، پاسخ یک ردیابی کامل حسابرسی است، نه یک حدس.
یک قانون طراحی حیاتی این است که هیچ عاملی بدون دلیل ثبت شده مجاز به اقدام نیست. پیشنویسساز نمیتواند پیامی تولید کند مگر اینکه ناظر یک رویداد محرک را ایجاد کرده باشد. فرستنده نمیتواند ارسال کند مگر اینکه پیشنویسساز یک پیام تأیید شده را تولید کرده باشد. نهاییکننده نمیتواند پرداختی را اعمال کند مگر اینکه فاکتوری برای اعمال آن وجود داشته باشد. این همان چیزی است که استقرار تولیدی در عمل به نظر میرسد. هر عملی منشأیی دارد.
روال ارتباطی که پیشنویسساز بر اساس آن عمل میکند
روال ارتباطی توسط عامل ایجاد نمیشود. بلکه به عنوان یک سند خط مشی به عامل داده میشود و عامل از آن پیروی میکند. یک روال ارتباطی تجاری معمولی برای فاکتورهای سی روزه به این صورت است: سه روز قبل از تاریخ سررسید، یک یادآوری مودبانه. صبح روز سررسید، یک تأیید مودبانه مبنی بر انتظار پرداخت در همان روز. هفت روز بعد از سررسید، یک درخواست واضح همراه با فاکتور ضمیمه. پانزده روز بعد از سررسید، یادداشتی قاطعتر که به شرایط اصلی اشاره دارد.
در سی روز بعد از سررسید، لحن تغییر میکند. پیشنویسساز به صراحت به ارتباطات قبلی اشاره میکند، مانده حساب را مجدداً اعلام میکند، میپرسد که آیا اختلافی وجود دارد، و یک مسیر حل و فصل ساختاریافته ارائه میدهد. در شصت روز، پیام تأیید میکند که رابطه در معرض خطر است. در نود روز، پرونده برای تشدید علامتگذاری میشود. عامل به تنهایی تصمیم نمیگیرد که از یک آژانس وصول یا وکیل استفاده کند. بلکه پرونده را با تاریخچه کامل و اقدام توصیه شده به یک انسان منتقل میکند.
آنچه این را در صدها یا هزاران حساب به طور همزمان کارآمد میکند این است که عامل خسته، حواسپرت یا ناراحت نمیشود. یادداشت شصت روزهای که یک انسان به دلیل احساس ناخوشایند دو هفته آن را به تعویق میاندازد، در روز شصت و در ساعت نه صبح ارسال میشود. در یک مجموعه، فقط همین انضباط، پولی را بازپرداخت میکند که در غیر این صورت به بدهی سوخته تبدیل میشد.
پیشنویسساز همچنین مسئول تنظیم لحن است. مشتریای که سه سال تمام فاکتورهای خود را به موقع پرداخت کرده است، یک پیام شصت روزه متفاوت از مشتریای با سابقه پرداخت کند دریافت میکند. هر دو پیام قاطع هستند. فقط یکی فرض حسن نیت دارد. این تنظیم در اعلان و سابقه مشتری کدگذاری شده است. بداههسازی نمیشود.
چگونه فرستنده بدون دخالت انسان، تشدید را مدیریت میکند
فرستنده نقطهای است که اکثر معماریها در آن شکست میخورند، زیرا سیستم در آنجا با دنیای خارج ارتباط برقرار میکند. ایمیلها برگشت میخورند. شماره تلفنها تغییر میکنند. پورتالها منقضی میشوند. یک فرستنده با طراحی ضعیف یا به طور کورکورانه مجدداً تلاش میکند یا همه چیز را به انسان ارجاع میدهد که هدف از خودکارسازی را از بین میبرد.
روش اینجا از یک پشتیبانی چند لایه استفاده میکند. اولین تلاش، ایمیل به مخاطب اصلی در حساب است. اگر ایمیل برگشت بخورد، فرستنده به دنبال مخاطب ثانویه میگردد و دوباره تلاش میکند. اگر هر دو برگشت بخورند، یک تماس صوتی با شماره ثبت شده برقرار میکند. اگر تماس ناموفق باشد، یک اعلان پورتال را فعال میکند. اگر پورتال سوابقی از مشتری نداشته باشد، یک نامه فیزیکی را در صف قرار میدهد. تنها پس از طی شدن کامل زنجیره پشتیبانی، پرونده به انسان ارجاع داده میشود و حتی در آن صورت، ارجاع شامل سابقه کاملی از هر تلاش است.
این تفاوت بین یک دمو و یک استقرار تولیدی است. یک دمو نشان میدهد که عامل یک ایمیل زیبا ارسال میکند. یک سیستم تولیدی نشان میدهد که چه اتفاقی میافتد وقتی ایمیل برگشت میخورد، وقتی مخاطب شرکت را ترک کرده است، وقتی سیستم حسابداری مشتری پیام را رد میکند، زیرا به یک مرجع سفارش خرید نیاز دارد که روی فاکتور نیست. این روش همه این موارد را در نظر میگیرد.
فرستنده همچنین محدودیتهای نرخ و ساعات آرامش را اعمال میکند. هیچ مشتری بیش از یک ارتباط خروجی در روز از این سیستم دریافت نمیکند. هیچ تماسی قبل از ساعت نه صبح یا بعد از ساعت پنج بعدازظهر در منطقه زمانی محلی مشتری برقرار نمیشود. هیچ ایمیلی در یک تعطیلی عمومی شناخته شده در کشور مشتری ارسال نمیشود. این حفاظها اختیاری نیستند. آنها بخشی از استقرار هستند زیرا سیستمهای تولیدی که آنها را نادیده میگیرند، سریعتر از آنکه پول را بازیابی کنند، شکایت تولید میکنند.
کاری که نهاییکننده تطبیق واقعاً انجام میدهد
تطبیق، بخشی از وصول مطالبات است که انسانها بیش از همه از آن متنفرند. پرداختی میرسد. مبلغ آن عجیب است. اطلاعیه پرداخت به سه شماره فاکتور اشاره دارد اما کل مبلغ با هیچ ترکیبی از آنها مطابقت ندارد. پرداخت دومی روز بعد بدون هیچ مرجعی میرسد. مشتری اعتباری را که شش ماه پیش صادر شده بود، اعمال کرده است. دفتردار صفحه گسترده را باز میکند و سردرد شروع میشود.
نهاییکننده این کار را با خواندن اطلاعات پرداخت، مطابقت با فاکتورهای باز، اعمال اعتبارات موجود و تطبیق پرداختهای جزئی با قدیمیترین فاکتور انجام میدهد، مگر اینکه دستور دیگری داده شده باشد. هنگامی که پرداختی قابل تطبیق نباشد، نهاییکننده یک رکورد استثنا با مبلغ پرداخت، تاریخ، منبع، فاکتورهای کاندیدایی که بررسی کرده و یک توصیه تولید میکند. یک انسان استثنا را بررسی میکند، تصمیم میگیرد، و نهاییکننده از این تصمیم میآموزد تا موارد مشابه دفعه بعد به طور خودکار مطابقت یابند.
حجم پرداختهایی که یک نهاییکننده میتواند پردازش کند، بخشی است که رهبران مالی را شگفتزده میکند. یک عامل واحد که در برابر یک سیستم حسابداری استاندارد اجرا میشود، میتواند ده هزار پرداخت را در روز بدون هیچ مشکلی اعمال کند. گلوگاه، محدودیت نرخ API سیستم حسابداری است، نه عامل. به همین دلیل است که خودکارسازی در اینجا چنین بهبود فوری در جریان نقدی ایجاد میکند. زمان بین دریافت پرداخت و اعمال پرداخت از روزها به دقایق کاهش مییابد.
نهاییکننده همچنین با مشتری ارتباط را کامل میکند. هنگامی که پرداختی اعمال میشود، رسیدی به طور خودکار با بیانیهای واضح از مانده جدید ارسال میشود. پروفایل رفتار پرداخت مشتری به روز میشود تا ناظر عدم پرداخت این مشتری را در چرخه فاکتور بعدی به طور متفاوتی در نظر بگیرد. این همان چیزی است که سیستم بدون آموزش صریح کسی میآموزد.
مدل قیمتی که این را ممکن میسازد
دلیل اینکه این معماری به عنوان یک استقرار متعلق به شرکت و نه یک اشتراک قابل دستیابی است، به نحوه ساخت و آنچه خریداری میشود، مربوط میشود. یک پلتفرم اشتراکی هزینه هر عامل یا هر اقدام را دریافت میکند، زیرا پلتفرم مالک کد است و مشتری دسترسی را اجاره میکند. اقتصاد نیاز به درآمد تکراری دارد. در سراسر گردش کارهای وصول مطالبات که دهها هزار فاکتور را در ماه پردازش میکنند، این محاسبات گران میشود.
TFSF Ventures FZ-LLC مدل متفاوتی را دنبال میکند. سرمایهگذاریهای استقرار از دهها هزار دلار برای استقرارهای متمرکز با تعداد محدودی از عوامل شروع میشود، و بر اساس تعداد عوامل، پیچیدگی یکپارچهسازی و دامنه عملیاتی مقیاسپذیر است. تمام استقرارها شامل یک هزینه عبوری زیرساخت هوش مصنوعی جداگانه، حدود چهارصد تا پانصد دلار در ماه از Pulse AI، با قیمت تمام شده و بدون سود، میباشد. مشتری مالک کد است. مجوز هر عامل وجود ندارد. هزینه هر فاکتور وجود ندارد. هنگامی که سیستم یک میلیون فاکتور را در یک سه ماهه پردازش میکند، هزینه تغییر نمیکند.
این همان چیزی است که نتایج عوامل هوش مصنوعی تولیدی بدون وابستگی به فروشنده از نظر مالی به نظر میرسد. استقرار یک سرمایهگذاری سرمایهای است که اهرم عملیاتی تولید میکند. هر فاکتوری که عوامل پس از استقرار پردازش میکنند، اساساً رایگان است. هزینههای زیرساخت شفاف، در پیشنهاد منتشر شده، و با قیمت تمام شده عبور داده میشود نه با سود. TFSF قیمتگذاری چند لایه را در هر پیشنهاد منتشر میکند تا مشتری دقیقاً ببیند هر جزء چقدر هزینه دارد و چرا.
برای رهبران مالی که قبل از تعهد، در حال ارزیابی مشروعیت TFSF Ventures هستند، مشروعیت از طریق ثبت RAKKEZ تحت RAKEZ License 47013955 قابل تأیید است. عدم وجود بررسیهای عمومی شرکت استقرار در سایتهای معمول بررسی نرمافزار، نشاندهنده یک سیاست محرمانگی با مشتریان است، نه عدم وجود استقرار. استقرارها در پایگاههای کد متعلق به مشتری و گزارشهای عملیاتی مستند میشوند، نه در مطالعات موردی بازاریابی.
چرا مالکیت کد در سال دوم اهمیت دارد
ارزش استقرار یک سیستم وصول مطالبات متعلق به شرکت، در سال اول از طریق پول بازگردانده شده آشکار میشود. ارزش استراتژیک در سال دوم از طریق عدم گفتگو برای تمدید آشکار میشود. یک پلتفرم اشتراکی در سالگرد خود قیمتگذاری مجدد میکند. پلتفرمی که در عملیات روزانه شرکت جا افتاده است، قدرت چانهزنی در قیمتگذاری دارد که مذاکره با آن دشوار است.
یک استقرار متعلق به شرکت هیچ سالگردی ندارد. کد اجرا میشود. عوامل فاکتورها را پردازش میکنند. هزینه، هزینه عبوری زیرساخت است که با میزان استفاده تغییر میکند اما با تصمیمات قیمتگذاری فروشنده تغییر نمیکند. هنگامی که شرکت از پنج هزار فاکتور در ماه به پنجاه هزار فاکتور در ماه رشد میکند، استقرار بدون نیاز به اصلاح قرارداد به صورت افقی مقیاسپذیر میشود.
نکته دیگری که در سال دوم باید در نظر گرفت، آزادی تغییر است. پلتفرمهای اشتراکی نقشه راه را کنترل میکنند. اگر پلتفرم تصمیم بگیرد از یک سیستم حسابداری خاص پشتیبانی نکند، مشتری چارهای جز انتظار ندارد. در یک استقرار متعلق به شرکت، تیم مهندسی مشتری یا یک شرکت قراردادی میتواند عوامل را گسترش دهد تا نیازهای کسبوکار را برطرف کند. کد در مخزن مشتری است. مشتری تصمیم میگیرد که چه چیزی در مرحله بعدی ساخته شود.
این همان معنای عملی عوامل هوش مصنوعی مستقل از فروشنده است. عوامل به یک پلتفرم وفادار نیستند. آنها به شرکتی وفادار هستند که مالک آنهاست. هنگامی که مدیر مالی سیستمهای حسابداری را تغییر میدهد، یکپارچهسازی تغییر میکند و عوامل ادامه میدهند. هنگامی که شرکت به کشوری جدید با الزامات فاکتورینگ متفاوت گسترش مییابد، عوامل گسترش مییابند به جای اینکه به فروشنده جدیدی نیاز داشته باشند.
معماریای که شرکت معماری استقرار مستقر میکند، از روز اول برای این چرخه عمر طراحی شده است. عوامل برای نیاز به یک زمان اجرای تیم زیرساخت عامل، یک داشبورد شریک استقرار، یا یک API ارائهدهنده زیرساخت ساخته نشدهاند. آنها بر روی زیرساخت استاندارد باز که مشتری مالک آن است و آن را اداره میکند، اجرا میشوند. جدول زمانی سی روزه استقرار شامل تحویل پایگاه کد، مستندات و راهنماهای عملیاتی است. پس از روز سیام، مشتری میتواند در صورت تمایل، سیستم را بدون دخالت شرکت استقرار اجرا کند.
استقرار تولیدی در عمل چگونه است
یک استقرار تولیدی معمولی برای یک کسبوکار متوسط با پنج هزار تا بیست هزار فاکتور ماهانه، یک جدول زمانی سی روزه را دنبال میکند. هفته اول یکپارچهسازی است. عوامل به سیستم حسابداری، ارائهدهنده ایمیل، کانال صوتی و پردازشگر پرداخت متصل میشوند. هفته دوم کدگذاری خط مشی است. روال دریافت مبالغ معوق، قوانین تشدید، کالیبراسیون لحن و آستانههای استثنا به عنوان پیکربندی در عوامل بارگذاری میشوند.
هفته سوم اجرای تحت نظارت است. عوامل فاکتورهای واقعی را پردازش میکنند اما هر ارتباط خروجی قبل از ارسال توسط انسان بررسی میشود. این بررسی تأیید میکند که لحن درست است، مبالغ صحیح هستند و روال با خط مشی مطابقت دارد. تا پایان هفته سوم، چرخه بررسی به اندازهای اعتماد به خروجیها ایجاد کرده است که بررسی انسانی برای فاکتورهای زیر یک آستانه دلاری تعریف شده از حلقه حذف میشود.
هفته چهارم تولید کامل است. عوامل به طور مستقل در کل مجموعه فاکتورها اجرا میشوند. کنترلر یک خلاصه روزانه را بررسی میکند که رویدادهای جدید عدم پرداخت، ارتباطات ارسال شده، پرداختهای اعمال شده و استثنائات ایجاد شده را نشان میدهد. این خلاصه تنها نقطه تماس روزانه تیم مالی با سیستم است. همه چیز بدون دخالت اجرا میشود.
آنچه این در قالب مالی ارائه میدهد، بازیابی تقریباً دوازده روز از میانگین دوره وصول برای یک مجموعه تجاری معمولی در طی شصت روز پس از راهاندازی، کاهش هشتاد درصدی زمان صرف شده برای وصول مطالبات توسط تیم مالی، و نرخ مطالبات سوخت شدهای است که در سه ماهه اول به نصف کاهش مییابد. این اعداد وعده نیستند. آنها نتیجه میانه در بین استقرارهایی هستند که این روش را دنبال میکنند. بهبود جریان نقدی به تنهایی معمولاً هزینه استقرار را در سه ماهه اول تولید کامل پوشش میدهد.
رفتار سیستم در هنگام افزایش حجم
حجم کاری وصول مطالبات در طول تقویم یکنواخت نیست. پایان هر سه ماهه موجی از پرداختهای مشتریان را به همراه دارد، زیرا چرخههای حسابداری خود آنها به پایان میرسد. پایان سال موج بزرگتری تولید میکند. فصل مالیاتی موج دیگری را ایجاد میکند. یک تیم وصول مطالبات انسانی این امواج را به عنوان دورههای اضافه کاری و سپس دورههای کمکاری تجربه میکند. سیستمی که حول چهار عامل طراحی شده است، آنها را به گونهای دیگر تجربه میکند، زیرا عوامل ساعات کاری ندارند.
وقتی حجم فاکتورها برای یک هفته سه برابر میشود، ناظر عدم پرداخت سه برابر رویدادها را پردازش میکند. پیشنویسساز سه برابر پیامها را مینویسد. فرستنده سه برابر ارتباطات را ارسال میکند. نهاییکننده سه برابر پرداختها را اعمال میکند. هزینه نهایی، محاسبات نهایی است که در زیرساختهای مدرن بدون دخالت مقیاسپذیر است. گلوگاه در طول افزایش حجم، عوامل نیستند. بلکه محدودیتهای نرخ سیستم حسابداری و ارائهدهنده ایمیل هستند که میتوان آنها را از قبل برای تطبیق با اوجهای مورد انتظار پیکربندی کرد.
این انعطافپذیری دلیل عملی است که رهبران مالی جمعآوری مبتنی بر عامل را پذیرفتهاند. استخدام دو گردآورنده فصلی برای رسیدگی به پایان سه ماهه، دو هزینه تمام وقت جدید را ایجاد میکند که برای بقیه سال کمکار هستند. اجازه دادن به عاملها برای جذب این افزایش، هیچ نیروی انسانی اضافی و هزینه مجوز اضافی ایجاد نمیکند. کار به سادگی انجام میشود.
چرا این معماری استاندارد آینده است
هر وظیفه عملیاتی در یک کسبوکار مدرن به سمت همان الگوی معماری حرکت میکند. وظیفه را شناسایی کنید. قوانین را تعریف کنید. قوانین را در عاملها کدگذاری کنید. عاملها را به سیستمهایی که دادهها را تولید میکنند و خروجیها را دریافت میکنند، متصل کنید. عاملها را به طور مداوم اجرا کنید. استثنائات را با زمینه ساختاریافته به انسان ارجاع دهید. همان الگویی که برای وصول مطالبات کار میکند، برای حسابهای پرداختنی، برای استخدام فروشندگان، برای مرتبسازی پشتیبانی مشتری و برای نظارت بر انطباق نیز کار میکند.
آنچه وصول مطالبات را به یک پیشگام تبدیل میکند این است که تأثیر مالی مستقیم است و قرار گرفتن در معرض مقررات محدود است. سیستم هزینه خود را در پول بازیابی شده در یک سه ماهه پرداخت میکند و برای عملیات نیازی به تأیید هیئت بررسی انطباق ندارد. با پذیرش این الگو توسط وظایف بیشتر، اثر تجمعی در سراسر یک شرکت همان چیزی است که رهبران عملیاتی وقتی در مورد زیرساخت عامل به عنوان یک دسته صحبت میکنند، منظورشان است. این یک عامل نیست که یک کار را انجام دهد. بلکه دهها عامل است که دهها وظیفه را اجرا میکنند، همه متعلق به شرکت، همه نتایج قابل اندازهگیری تولید میکنند، همه بر روی نتایج هوش مصنوعی تولیدی بدون وابستگی به فروشنده به عنوان یک اصل اساسی اجرا میشوند تا یک خط بازاریابی.
درباره TFSF Ventures
TFSF Ventures FZ-LLC (RAKEZ License 47013955) یک شرکت معماری سرمایهگذاری است که زیرساخت عامل هوشمند را از طریق سه ستون مستقر میکند: زیرساختهای عاملمحور، ریلهای پرداخت غیرسنتی، و موتور سرمایهگذاری. TFSF با 27 سال سابقه در پرداختها و نرمافزار، با متدولوژی استقرار 30 روزه خود در 21 صنعت در سراسر جهان خدمات ارائه میدهد. برای اطلاعات بیشتر به https://tfsfventures.com مراجعه کنید.
ارزیابی رایگان هوش عملیاتی را انجام دهید
چند سؤال کوتاه را پاسخ دهید. یک طرح اولیه استقرار هوش مصنوعی سفارشی را ظرف 24 تا 48 ساعت دریافت کنید که شامل توصیههای عامل، معماری و نقشه راه است. بدون تماس فروش. بدون تعهد. فقط داده. از https://tfsfventures.com/assessment شروع کنید.
منتشر شده در اصل در https://tfsfventures.com/blog/how-four-agents-can-handle-accounts-receivable-collections-without-a-human-sending
نوشته شده توسط TFSF Ventures Research