بیمه

میانگین، محل نشت را پنهان می‌کند

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

پرسش «چقدر فروختیم؟» همیشه پاسخ دارد. پرسش «کجا و چرا پول از دست می‌دهیم؟» معمولاً بی‌پاسخ می‌ماند — نه چون داده‌اش نیست، چون پاسخ‌دادن به آن گران است. چهار جایی که ارزش از دست می‌رود:

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

هزینهٔ تأخیر

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

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

کاری که تغییر می‌کند

بخش دشوار، اجرای کوئری نیست؛ طرح پرسش درست است — و در بیمه، اختلاف دقیقاً سر همین صورت‌بندی است.

«چرا ضریب خسارت ما بالا رفته است؟»

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

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

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

به چه چیزی وصل می‌شود

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

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

کجا انتخاب درستی نیست

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