Представьте: для выступления на важном мероприятии вам нужен новый костюм. У вас 3 варианта:

• Пойти в магазин (а лучше хотя бы 3–5) и попытаться найти подходящий. Дешевле и проще всего, но не факт, что удастся выбрать нужное.

• Купить готовую одежду и переделать под себя: брюки чуть короче, пуговицу переставить и т.д. Дороже и дольше, зато удобнее и выглядит лучше.

• Или обратиться к портному и сшить костюм полностью на заказ. Самый дорогой и долгий вариант, много сопутствующих хлопот (ткань подобрать, несколько раз приехать на примерку и т.д), зато итоговый результат идеально сидит по фигуре.

1. Купить стандартное решение («коробку»): продукты для отдельных этапов или целую CLM-систему.
2. Приобрести готовый продукт и доработать под себя.
3. Разработать систему полностью с нуля.

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

Стандартное решение работает и на отдельных этапах жизненного цикла документа, и на уровне CLM-системы. Вы можете автоматизировать, например, только подписание документов, а можете — весь процесс контрактного менеджмента.

На схеме показано, какие этапы контрактного менеджмента можно автоматизировать.

• Быстрое подключение. Достаточно купить ПО и использовать в нашем облаке или установить в своем защищенном контуре, и можно работать.

• Легкая поддержка. Как правило, у вендора есть собственная техподдержка, которой достаточно для полноценной работы с системой. Все необходимые исправления и обновления вносятся централизованно без дополнительных усилий со стороны заказчика.

• Низкая адаптивность. Готовое «коробочное» решение без доработок или интеграций не получится бесшовно встроить в уже имеющееся ПО компании.

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

Вариант с «коробкой» хорошо подходит для малого и среднего бизнеса, которому достаточно стандартных систем. Но крупным компаниям в любом случае нужно адаптировать готовый продукт под свои потребности и встраивать его в уже существующую экосистему. Для этого подойдут только кастомизированные решения.

Кастомизация — это доработка готового продукта под конкретную компанию.

Основное требование к кастомизированным системам — максимальная гибкость. Так, чтобы легко и безболезненно встроиться в существующие бизнес-процессы компании. Чем крупнее бизнес, тем сложнее устроены его процессы. Любая доработка должна не только сделать их эффективнее, но и ничего не разрушить.

«Коробочное» решение для хранения файлов

Интерфейс адаптирован под конкретную компанию

2) Функциональные доработки.

Позволяют решать задачи, с которыми не справится «коробочная» версия.

Пример такой доработки — анонимайзер. Нужен, чтобы автоматически скрывать чувствительные данные: названия контрагентов, адреса, суммы, условия оплаты и т.д.

Анонимайзер разработали в Doczilla для крупного банка, который входит в список 13 системно значимых банков России. Клиент работает с многостраничными контрактами клиентов для выдачи банковских гарантий. С помощью AI юристы вытаскивают из договоров ключевые сущности и сводят все данные в таблицу. А анонимайзер позволяет сделать работу с AI безопасной — чувствительные данные клиентов скрыты шифром, а риск утечки информации практически исключен.

Договор до и после обработки анонимайзером

Другие функциональные доработки Doczilla:

• Миграция данных. Doczilla позволяет сохранять данные из одной анкеты во внутренний справочник и использовать их в другой анкете. Это особенно полезно для автоматизации повторяющихся процессов, таких как выдача кредитов.

Схема процесса миграции

• Матрица полномочий. Позволяет автоматизировать выбор подписантов в документе. Например, если сумма договора от 10 до 30 тысяч, его могут подписывать Литвин, Суриков, Иванов и Петров. Если сумма свыше 30 тысяч, то только Суриков и Иванов. Эта логика настраивается внутри конструктора, и при заполнении договора пользователю будут предложены только релевантные подписанты в зависимости от значения переменной.

• Заполнение карточки в СЭД для нетиповых договоров. С типовой документацией проблем нет — данные спокойно подтягиваются из конструктора во внутреннюю систему. Но для многих компаний важно ускорить процесс сбора информации и по нетиповым документам. Здесь на помощь приходит AI. Технология анализирует текст, вытаскивает из него нужные данные и заполняет карточку во внутренней системе.

3) Доработки по безопасности

У всех компаний свои требования к безопасности: лимит нагрузки на внутреннюю систему, способ аутентификации, метод передачи данных в интеграции и так далее. Новый продукт должен легко подстраиваться под существующие требования, чтобы работать корректно и подружиться с другими компонентами экосистемы компании.

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

Пример журнала безопасности

Все эти доработки позволяют решить задачи крупных компаний и максимально эффективно встроить систему документооборота в существующее ПО.

• Возможность гибко подстроиться под бизнес-процессы. Это значит, что вендор сможет своими силами или при участии команды клиента быстро вносить необходимые изменения в функционал и интерфейс, а также интегрировать программу со всем необходимым ПО.

• Экономия на доработках. У крупных компаний часто есть «дочки» или структурные единицы в компаниях, которые сами занимаются разработкой ПО. Если вендор передает им исходный код, заказчик потом, как правило, не платит за обновления и улучшения.

• Более высокие затраты на поддержку. Если вендор не отдает исходный код, нужно контролировать выход обновлений, проверять их, устанавливать в контур и т.д. Как правило, требуется отдельная линия техподдержки и личный аккаунт-менеджер.

• Дольше происходит внедрение. Понадобится время на настройку, интеграцию, проверку службы безопасности и т.д. Как правило, промышленная или тестовая эксплуатация начинается через 2–3 месяца после подключения.

Но какая бы гибкая ни была система, иногда заказчик хочет сделать все под себя. В этом случае разработка происходит с нуля.

• Можно полностью настроить под себя функционал и интерфейс, спроектировав его с нуля.
• Нет привязки к срокам разработки вендора

• Высокие риски. Непонятно, какой стек использовать, насколько получится воплотить в жизнь процессы, необходимые бизнесу.

• На разработку уходит много управленческих ресурсов. Это процесс связан с постоянной постановкой задач и тестированием: сделали, протестировали, не получилось, доработали, опять сделали, опять не получилось, доработали…

• Дорого. При разработке с нуля приходится задействовать больше людей и ресурсов. Кроме того, нужны деньги не только на разработку ПО, но и на аналитику, проектирование, интеграции и т.д. Иногда приходится нанимать целую команду.