На ошибках учатся: топ-10 факапов команды Doczilla, которые сделали платформу лучше

Doczilla позволит

Запросить демо

Полностью исключить простые ошибки;

Ускорить подготовку документов в 10 раз;

Избавиться от рутины и перепроверок;

Забыть про неактуальные шаблоны;

На ошибках учатся: топ-10 факапов команды Doczilla, которые сделали платформу лучше

⏱13 мин | 13.06.2024

На вебинаре LegalTech fuckups CEO и основатель Doczilla Кирилл Буряков рассказал, какие ошибки допускала команда Doczilla в проектах клиентов. В этой статье раскрываем 10 наших главных промахов и говорим о выводах, которые сделали.

Автоматизация договорной работы стала нормой для крупных компаний. Документ готовится в пару кликов, в тексте ноль ошибок, а юристы наконец избавились от рутины — звучит заманчиво, но что происходит на самом деле? С какими трудностями сталкиваются вендор и клиент, когда внедряют LegalTech-продукты?

В этой статье CEO и основатель Doczilla Кирилл Буряков поделится опытом команды Doczilla и покажет 10 наших ошибок в клиентских проектах. Для защиты интересов клиентов все кейсы приведены анонимно.

Клиент всегда прав

Если продукт автоматизации работает не так, как следует, — пенять нужно на вендора. Заказчик не обязан знать всех тонкостей LegalTech-процессов. Автоматизация документооборота — разовый проект для клиента, а для подрядчика — целый бизнес. Поэтому мы как вендоры знаем все о своем продукте, технических особенностях интеграции с СЭД клиента, рисках и возможных проблемах. Именно наша команда должна предугадывать трудности в будущем и купировать риски. Поэтому все ошибки, о которых дальше пойдет речь, — это промахи команды Doczilla.

1. Масштабирование без опытной эксплуатации

Клиент;Крупный банк, входящий в топ-10 российских финансовых организаций по размеру активов Продукт;Конструктор документов Запрос;Автоматизация договорной работы. Целевая аудитория продукта — 1500 пользователей Что сделали;Обнаружили проблему, установили конструктор в защищенный контур заказчика, провели тестирование, получили отличные результаты и активно готовились к масштабированию для промышленной эксплуатации Ошибка;На этапе обучения сотрудников клиента новому инструменту выяснилось, что конструктор не справляется с объемными спецификациями в формате excel. Когда пользователи формировали документ, данные из таблиц не подгружались автоматически и их приходилось заносить вручную. Этой задачи не было в ТЗ, но процесс не соответствовал изначальному запросу и оказался стоп-фактором внедрения платформы Как решали;Проблема возникла за 2 недели до дедлайна по проекту. Наша команда оперативно искала решение и через месяц представила заказчику полностью готовый инструмент Результат;Данные из объемных спецификаций подтягиваются в шаблоны автоматически, а пользователи готовят документы за пару минут

Вывод

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

2. «Мы все сделаем сами»

Вывод

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

3. Слишком амбициозная задача

Вывод

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

4. Команде вендора не хватило лидерства

Вывод

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

5. Адское ТЗ в несколько сотен требований

Клиент;Промышленная компания Продукт;Конструктор документов Запрос;Автоматизация договорной работы. Клиент объявил тендер на свой проект, провел исследование рынка вендоров и приготовил огромное техническое задание. Документ состоял из 57 страниц 12-м шрифтом, включал в себя 85 разделов и более 425 функционально-технических требований к ПО исполнителя. На первый взгляд команда клиента проделала огромную и классную работу — изучила продукты всех вендоров на рынке и объединила их функционал в одно техническое задание. Победитель тендера был обязан реализовать все требования без исключения Что делали;Выиграли тендер и приступили к реализации проекта. Добились того, чтобы наше ПО соответствовало всем пунктам ТЗ, добавляли новые фичи, тестировали и перестраивали продукт. То есть проделали титаническую работу по доработке платформы Doczilla Pro Ошибка;Закончили проект и отдали заказчику. Через некоторое время посмотрели статистику использования платформы, и выяснилось, что клиент, заплатив уйму денег, в итоге использует менее 43% того функционала, который команда Doczilla так долго и упорно разрабатывала. Для клиента это не только лишние траты, но и увеличение срока интеграции и расход ресурса команды

Вывод

Когда техническое задание разрабатывается без участия исполнителя, клиент не всегда может объективно оценить, какие функции ПО ему действительно нужны, а от каких можно смело отказаться. В этом случае вендору следует прийти на помощь и объяснить, как решить проблему заказчика самым быстрым и доступным способом. Чем проще проект — тем быстрее и дешевле его можно реализовать.

6. Нет тестового сервера

Вывод

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

7. Использование waterfall-подхода в управлении проектом

Вывод

Для управления LegalTech-проектами идеально подходит продуктовая, или ping-pong-методология, когда вендор отдает заказчику MVP (минимально жизнеспособный продукт), получает фидбэк и доделывает решение до тех пор, пока не получит стабильный результат.

8. Автоматизация старых процессов

Вывод

LegalTech-продукты позволяют ускорить документооборот и помогают юристам выполнять свою работу быстрее и качественнее. Следует помнить, что внедрить технологичный инструмент, не поменяв бизнес-процесс, не получится. Автоматизация не только решает конкретную задачу, но и трансформирует работу компании. Поэтому нужно быть готовыми к переменам и адаптироваться к новым условиям.

9. Ошибки интеграции

Вывод

Перед началом внедрения продуктов автоматизации вендору нужно провести аудит бизнес-процессов в компании заказчика, чтобы четко понимать, какие данные будут передаваться от системы к системе, и на основе этого выстраивать интеграцию.

10. Консервативный подход

Вывод

Требования ИБ не должны становиться стоп-фактором внедрения передовых технологий, потому что в долгосрочной перспективе консервативный подход и отказ от нововведений приведет компанию к поражению в конкурентной борьбе.

Предлагаем также узнать больше →
Об опыте клиентов Doczilla

Применение Doczilla

Ускорить подготовку документов в 10 раз
Полностью исключить простые ошибки
Забыть про неактуальные шаблоны
Избавиться от рутины и перепроверок

Запросить демо