От офертата до плащането: как да се намали зависимостта от дълги ИТ проекти

Представете си един вторник със заседание на комитета. Търговският директор иска промяна, която звучи малка: продукт за защита с различна тарифа за нов сегмент и отстъпка за онзи, който сключва през дигиталния канал. Директорът по технологиите отговаря с оценка от няколко месеца, между анализ, разработка, тестове и пускане. Никой на масата не греши. Търговската област има възможност с дата; технологичната знае, че тази тарифа живее разпръсната в офертата, в издаването, в плащането, в системата за комисиони и в таблицата на актюера.

Този модел заслужава да се погледне: когато правилото е написано в кода на няколко системи, всяка промяна на продукт или тарифа клони да се превърне в проект. Не непременно защото идеята е сложна, а защото промяната налага преглед и валидиране на засегнатите системи.

Статията е насочена към ръководители на застрахователни компании в Мексико, отговарящи за растежа, операциите, технологиите, актюерството, правните въпроси или съответствието. Принципите на проследимостта могат да са полезни и в други сектори, но регулаторните им задължения изискват различен анализ. Излага три идеи:

1. Времето за една промяна зависи от това къде живее правилото, не от това колко е сложно.
2. Да конфигурирате не значи да заобикаляте контрола. За да оцени едно решение за конфигуриране, комитетът трябва да поиска доказателство кой е одобрил всяка промяна, коя версия е била в сила и как е изчислена всяка цена.
3. Един инструмент не замества актюера, нито регистрацията на продукта. Онова, което може да направи, е тази работа да бъде легитимното тясно място, а да не бъде такова и опашката на ИТ.

Къде отива времето

Когато промяната на тарифа отнема повече от очакваното, добре е да се провери дали забавянето е в логиката на изчислението, в нейното дублиране, в одобренията или в зависимостите между системите. Времето обикновено отива на четири места:

• Правилото е дублирано. Офертата изчислява по един начин; издаването — по друг, почти същия; плащането и анулирането — по трети. Всяко копие трябва да се промени и да се тества.
• Трудно е да се види цялото правило. За да се разбере защо клиент е платил определена сума, трябва да се попита онзи, който е програмирал всяка система.
• Промяната се състезава в опашката. Корекция на тарифа чака зад една миграция, една корекция за сигурност и графика на екипа.
• Пускането в експлоатация е събитие. Тества се всичко наведнъж, пуска се в един прозорец и, ако нещо не излезе, се връща всичко.

Доставчиците на софтуер за застраховане го знаят и го продават. Като пазарна референция, един доставчик обяви през април 2026 г. инструмент, който според неговото съобщение намалява до 50 % усилието за генериране на изисквания и манускрипти на продукта (manuscripts) и скъсява сроковете за внедряване от месеци до седмици, с първоначални резултати [1]. Това е твърдение на самия доставчик, без независимо измерване и с първоначален обхват чрез неговите професионални услуги; не е основа за оценка на случая на една мексиканска застрахователна компания. Цитираните тук източници не дават съпоставимо измерване на времето за пускане на продукти в мексиканските застрахователи, и затова тук не поставяме цифра за «колко време отнема днес в Мексико». Важната е вашата и я измерва вашият комитет.

Да конфигурирате с контрол, не само с бързина

Основната идея е проста: продуктът, покритието и тарифата да са данни с отговорно лице и със запис на всяка версия, а не разпръснати редове код. Но е добре да се уточни какво значи «с контрол», защото конфигурация без контрол е само по-бърз начин да се сгреши.

За един комитет четири характеристики отличават сериозната конфигурация от опасната:

Кой одобрява. Промяна на тарифа не я публикува онзи, който я въвежда. Има процес на преглед, с ясни роли: кой предлага, кой валидира технически и кой разрешава пускането.

Коя версия се продава. Всяка тарифа има версия с начална и крайна дата. Оферта, издадена днес, трябва да може да се възстанови утре с версията, която е била в сила, а не с онази, която е активна в този момент.

Как е изчислена. Всяка цена трябва да може да се обясни с разбивката си: базова премия, надбавки, отстъпки, такси, данъци и, когато е приложимо, комисиона. Когато клиент, агент или одитор попита «защо тази сума?», отговорът не може да бъде «системата го изчислява».

Кои правила са приложени. Освен резултата остава записът кои правила са участвали и в какъв ред. Това е разликата между число и обяснение.

Сценарий (илюстративен, без клиент). Застрахователна компания иска да коригира тарифата на един продукт за един сегмент. Днес промяната минава през отдела по технологии в четири системи. Ако правилото се управлява от обща дефиниция и засегнатите системи са интегрирани, процесът би могъл да раздели актюерското предложение, прегледа, разрешението и датата на влизане в сила. При по-късно уточнение целта е да могат да се видят разбивката, периодът на действие и приложените правила, без да се разчита на ръчно възстановяване. Времето на ИТ не изчезва: влага се в изграждането и поддържането на механизма веднъж, вместо да се повтаря при всяка промяна.

Актюерът не се замества

Това е точката, около която има най-много шум, и си струва да бъдем ясни. В застраховането покритията и премиите трябва да почиват на техническа записка (nota técnica), а тази записка се изготвя и подписва от професионалист.

Комисията (Comisión Nacional de Seguros y Fianzas, CNSF, националният застрахователен регулатор) публикува сред своите системи за регистрация Регистъра на продуктите (Registro de Productos), заедно с този на образците на договори и този на техническите записки за гаранции [2]. Ley de Instituciones de Seguros y de Fianzas (LISF, законът за застрахователните и гаранционните институции) изисква техническата записка да се изготвя и подписва от актюер с професионално удостоверение (cédula profesional) и с професионалните изисквания, предвидени в закона (или който е доказал знанията си пред CNSF), договорната документация да има юридическо становище, а становището за съответствие между двете да се подписва от актюера и от лицето, подписало юридическото становище (чл. 201) [5]. Circular Única de Seguros y Fianzas (CUSF) урежда регистрацията на продукти в глава 4.1 и регистрацията на актюерите, които изготвят и подписват технически записки, в глава 30.5 [3]. За всяко решение към днешна дата юридическият отдел трябва да се консултира с LISF, CUSF и техните изменения, публикувани в Diario Oficial de la Federación (DOF). Онова, което илюстрира всичко това, е принципът: има професионални подписи, които една конфигурация не заменя.

Добре е да се разграничат два изхода. Когато един застрахователен продукт се предлага чрез договори по присъединяване, LISF изисква регистрирането му пред CNSF със съответната техническа и договорна документация; тази регистрация не предрешава допусканията на техническата записка, нито жизнеспособността на нейните резултати [5]. За тези договори застрахователят трябва освен това да впише образците им в Регистъра на договорите по присъединяване в застраховането (Registro de Contratos de Adhesión de Seguros, RECAS) на Националната комисия за защита и отбрана на ползвателите на финансови услуги (Comisión Nacional para la Protección y Defensa de los Usuarios de Servicios Financieros, CONDUSEF), който е публичен за справка, след регистрацията пред CNSF и преди продуктът да се предлага; вписването не означава, че CONDUSEF е прегледала договора [4][5][6]. Това е още един изход, който вашият юридически отдел трябва да впише в календара на пускането.

Онова, което една добра система за конфигурация наистина може да направи, е да подреди пътя:

• техническата записка, договорите и конфигурираната тарифа да съответстват на една и съща версия, така че онова, което се продава, да е онова, което е регистрирано;
• продажбата на една версия да не се разрешава, докато не е одобрена вътрешно и регистрирана там, където е необходимо;
• допусканията, които подкрепят тарифата, да са вързани с нейната версия, за да може тя да се защити пред проверка.

Казано иначе: не става дума актюерът да подписва по-малко. Става дума неговата работа да бъде легитимното тясно място на пускането, а да не бъде такова и дълга опашка в технологиите.

От офертата до плащането: една верига

Заглавието на тази статия не казва «оферта» случайно. Правилото, с което се оферира, трябва да може да се съгласува с издаването, плащането и, когато е приложимо, с данъчните документи, анулирането и анексите. Когато всеки етап има свое копие на правилото, могат да се появят разлики като тези:

• офертираната цена не съвпада с издадената;
• платената разписка не съвпада с онова, което казва полицата;
• комисионата на агента се изчислява върху друга основа;
• при анулиране възстановяването използва правило, което никой не помни.

Комитетът може да го провери с неотдавнашна извадка от корекции и уточнения, която представя неговите видове застраховане, канали и основни системи. Управляваната конфигурация може да намали несъответствията, когато дефиницията на продукта и тарифата е интегрирана със съответните етапи и запазва доказателство за изчислението и за периода му на действие.

И се свързва с онова, което се случва след плащането. Тарифа, която се изчислява с разбивка, е тарифа, която се съгласува: съгласуването може да свърже полученото плащане с премията, надбавките, таксите и данъците, които се прилагат, а комисионите запазват собствена проследимост и основа на изчисление. Това е същата проследимост, която иска всяко счетоводно приключване, погледната от произхода на цената.

Какво конфигурацията не обещава

Добре е да се каже, за да не купи комитетът погрешно очакване:

• Не премахва работата по проектирането на продукта. Някой трябва да реши какво се продава, на кого и на каква цена.
• Не заменя юридическата валидация, нито актюерския подпис. Подрежда ги и ги поставя в процеса.
• Не заменя дефиниран процес на одобрение. Без управление по-гъвкавата конфигурация може да увеличи въздействието на грешките.
• Сама по себе си не компенсира липсващи интеграции или несъвместими данни между издаването, плащането и други системи. Ако издаването и плащането не споделят една дефиниция, конфигурацията трябва да стигне до двете. Това е тема на интеграция, не само на тарифи.
• Цифрите на доставчиците не са вашите. Едно «от месеци до седмици» зависи от това колко от вашата дейност е днес разпръснато.

Пет въпроса за вашия следващ комитет

1. Колко време отнема днес, от край до край, промяна на тарифа или продукт? От момента, в който я поиска търговската област, до момента, в който се продава, и колко от това време е опашка на технологиите и колко е актюерски и регулаторен преглед.
2. В колко системи живее правилото за една и съща тарифа? Ако отговорът е «повече от една», усилието за координация и валидиране обикновено расте; комитетът трябва да измери колко точно в своята дейност.
3. Можем ли да възстановим всяка издадена цена? С нейната разбивка, версията на тарифата и правилата, които са участвали, без да се обаждаме на онзи, който е програмирал системата.
4. Кой одобрява промяна на тарифа и къде остава доказателство? Един изолиран имейл, без версия, процес на одобрение и възстановимо доказателство, трудно осигурява достатъчен контрол.
5. Онова, което продаваме, съвпада ли с онова, което сме регистрирали? Техническа записка, договори и конфигурирана тарифа от една и съща версия, преди да се отвори продажбата.

Ако два или повече отговора са «не знам», има ясен случай да се измерят проследимостта, отговорниците и зависимостите, преди тясното място да се припише на разработката.

От къде да започнете тази седмица

Първоначалната диагностика може да започне, без все още да се решава програма за трансформация. Изберете един продукт и направете лист на една страница с три колони: в кои системи се появява неговата тарифа, кой я променя във всяка и как се доказва, че две системи дават една и съща цена. След това помолете някого да възстанови, с този лист, оферта отпреди три месеца. Ако възстановяването изисква няколко души или системи, това е сигнал да се измери проследимостта и да се оцени цената на промяната с реални случаи. Този лист върши работа с всеки инструмент или без никакъв.

Какво прави Hábil

Hábil работи в пространството между продукта, тарифата и останалите системи. Ако вашата диагностика потвърди разпръснати правила, Pauta е предложението на Hábil за управление на конфигурируеми продукти и тарифи спрямо системите, които вече имате; обхватът, приложимите интеграции и контролите се преглеждат с вашия случай. За свързване на вашата дейност и вашите канали има страницата Обединяване на дейността и каналите; а за случая, в който трудността е в системата на заден план — Модернизиране на основната система без спиране на бизнеса.

Първият разговор за диагностика е безплатен. Нека поговорим за продукт или тарифа, които днес изискват промени в няколко системи; пишете ни в WhatsApp.