Как извлечь бизнес-правила из старой системы с помощью ИИ?

Бизнес-правила из старой системы извлекаются в 3 шага: ИИ читает код и записывает каждое правило понятным предложением со ссылкой на строку, из которой оно взято; владелец процесса проверяет его и подтверждает или исправляет; а вы сравниваете его с тем, что система на самом деле делает на реальных счетах. Инструмент вроде AWS Transform для мейнфреймов записывает правила как проверяемые требования, а в объявлении Thought Machine и Amazon от 29 сентября 2026 года извлечение проходит 4 этапа, последний из которых — утверждение человеком. Не пишите новый код, пока правила не подтверждены.

В части 3 вы получили инвентаризацию и предварительное решение по каждой системе. Системы, которые вы решили перестроить или конвертировать, нуждаются в этом шаге в первую очередь.

Почему бизнес-правила — самое ценное в вашей старой системе

Бизнес-правило — это то, как ваша компания что-то рассчитывает или решает: как считается скидка оптового клиента, когда начисляются пени за просрочку, кто согласует заказ на закупку выше определённого лимита, как округляется сумма платежа в рассрочку. Эти правила накапливались годами изменений, и многие из них никогда не записывались ни в одном документе.

• В коде: условия и расчёты, которые программист написал много лет назад по просьбе руководителя, давно ушедшего из компании.
• В базе данных: прайс-листы, ставки и лимиты, которые кто-то меняет вручную, не зная, что от них зависит.
• В головах сотрудников: исключения, которые бухгалтер обрабатывает вручную, потому что система этого не делает.
• В электронных таблицах: формулы, восполняющие пробелы системы, как мы объясняли в статье какая таблица и есть система.

Если вы перестроите систему без этих правил, то получите новую систему, которая считает по-другому, и узнаете об этом, только когда клиент оспорит счёт. Переносить нужно именно правила; старый язык программирования — лишь оболочка.

Как ИИ читает код и записывает правила

Извлечение правил было долгой ручной работой: программист читал код строка за строкой и записывал то, что понял. Современные инструменты читают весь код, отслеживают, откуда приходит каждое число и куда уходит, и излагают найденное понятным языком. Пример: Amazon утверждает на странице AWS Transform для мейнфреймов, что сервис извлекает каждое бизнес-правило из исходного кода и связывает его с источником, а затем формирует готовые к разработке требования, которые может проверить ваша команда, причём каждое можно проследить до кода, из которого оно взято. Это описание Amazon своего сервиса, а не гарантированный результат.

Формат записи правила важен. Один из известных форматов — EARS, Easy Approach to Requirements Syntax, разработанный Алистером Мэвином и его коллегами в Rolls-Royce и впервые опубликованный в 2009 году. Идея в том, что каждое правило записывается в фиксированном порядке: состояние, затем триггер, затем то, что должна сделать система. У него 5 базовых шаблонов; вот наглядные примеры из бизнеса:

Ценность этого формата в том, что владелец процесса может прочитать и оценить правило, не умея программировать. Одно предложение на правило, и ответ: да, нет или неполно.

Пример из банковской сферы: бизнес-намерение, а не построчный перевод

Самый наглядный свежий пример — из банков, где правила по процентам, комиссиям и погашению десятилетиями живут в коде на COBOL на мейнфреймах. COBOL — старый язык программирования, на котором до сих пор работают многие системы в банках и страховании. В объявлении от 29 сентября 2026 года банковская технологическая компания Thought Machine сообщила, что работает с Amazon над процессом, который не переводит код построчно, а извлекает чистое бизнес-намерение. Согласно объявлению, процесс состоит из 4 этапов:

1. Извлечение: AWS Transform читает устаревшие приложения и извлекает бизнес-логику в спецификации, записанные в формате EARS.
2. Консолидация: сотни избыточных вариантов одного и того же продукта объединяются в компактные современные спецификации.
3. Синтез: ИИ-агенты создают финансовые продукты и тесты к ним на Python.
4. Валидация: проверка людьми, в которой инженерная команда и команда по рискам банка имеют явное право утверждения.

Обратите внимание на два урока: консолидация показывает, что старая система несёт множество копий одного и того же правила, а последний этап полностью человеческий. Это заявления двух компаний о своём процессе, и их пример банковский, но метод подходит любой компании: извлечь, объединить дубликаты, затем строить и ничего не утверждать до подписи ответственного за решение.

Почему владелец процесса должен подтверждать каждое правило

ИИ читает то, что делает код, а не то, чего хочет компания. Именно в разрыве между ними возникают ошибки модернизации:

• Мёртвый код: ИИ может извлечь правило из фрагмента, который не используется уже много лет, и оно будет выглядеть действующим.
• Старая ошибка, ставшая привычкой: система неправильно округляет сумму, а сотрудники исправляют это вручную. Извлечённое правило перенесёт ошибку, если никто не скажет, что это ошибка.
• Правило вне кода: исключение, которое бухгалтер обрабатывает вручную, никогда не появится в результатах извлечения.
• Противоречащие правила: две версии расчёта скидки в двух разных местах. Какая из них верна — решение бизнеса, а не техническое.

Поэтому назначьте каждому правилу владельца со стороны бизнеса, который его подпишет: коммерческого директора для правил скидок, финансового директора для пеней и согласований. Подтверждённые правила становятся основой технического задания на новую систему, а как его составить, мы объясняли в нашем руководстве по требованиям к программному обеспечению. Учтите, что код и базы данных могут содержать данные клиентов или сотрудников, поэтому любой инструмент, читающий их за пределами Королевства, требует проверки, о которой мы говорили в части 3, вместе с рекомендациями Саудовского управления по данным и искусственному интеллекту (SDAIA).

Взгляд Origami

Когда мы модернизируем старую систему, мы считаем главным для переноса её бизнес-правила, а не код. Мы используем инструменты ИИ, чтобы читать код и записывать правила понятными предложениями с недоступной раньше скоростью, но не считаем ни одно правило окончательным, пока владелец процесса не прочитал и не подписал его.

Затем мы проверяем каждое подтверждённое правило на реальных данных старой системы, прежде чем строить вокруг него новую, чтобы новая система считала так, как ожидает компания, а не так, как предполагает инструмент. Если хотите увидеть, как мы работаем, загляните в раздел наших услуг.

Упражнение недели: одно правило, три счёта

Чтобы начать, не нужно ждать инструмента. Выберите правило, вокруг которого часто возникают споры, например скидку или пени за просрочку, и выполните следующие шаги:

1. Попросите владельца процесса записать правило одним предложением в форме: Когда..., система должна...
2. Выгрузите из системы 3 реальных счёта, к которым применялось правило: обычный, пограничный и с исключением.
3. Рассчитайте каждый счёт вручную по записанному предложению и сравните результат с тем, что выдала система.

Если все три совпадают, правило задокументировано. Если один расходится, вы нашли скрытое правило или старую ошибку, а это именно то, что нужно знать до любой модернизации.

В следующей части

Теперь у вас есть подтверждённые правила для вашей системы. Дальше — главное решение: перенести систему как есть, конвертировать её код на современную платформу, перестроить её вокруг извлечённых правил или заменить готовым продуктом и сохранить только данные? В части 5 мы сравним эти пути в таблице: когда подходит каждый, что он сохраняет, чем рискует и кто должен участвовать.

Источники

• AWS Transform для мейнфреймов: официальная страница — извлечение бизнес-правил с привязкой к исходному коду, проверяемые требования и тесты эквивалентности.
• Thought Machine и AWS: объявление от 29 сентября 2026 года — четыре этапа: извлечение в EARS, консолидация, синтез и проверка людьми.
• EARS: официальное руководство Алистера Мэвина — формат, его пять шаблонов и первая публикация в 2009 году.
• SDAIA: защита персональных данных.