Доработки системы: о чем нужно знать перед стартом работ

Для начала — немного теории.

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

И есть система, доработанная под нетиповые требования компаний с узкой спецификой деятельности.

По опыту внедрения Directum Lite мы знаем: 99% заказчиков начинают цифровизацию с «базовой комплектации». Это приемлемо для бюджета, быстро по времени установки, удобно для освоения и комфортно для работы. Постепенно стандартной функциональности для достижения целей растущей компании становится недостаточно. Требуется модификация, но к ней нужно подготовиться финансово, технически и даже морально.

Итак, что учесть перед тем, как позвонить вендору и попросить его доработать СЭД?

Обновлять модификации дольше и сложнее

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

С модифицированным ПО иначе: перед тем, как накатить обновления, специалист должен тщательно «осмотреть» систему, исключить конфликты с обновлениями и возможные сбои. В итоге, новая версия появляется минимум через 20 часов.

Для обслуживания доработанной системы нужен специалист

Поддерживать работу СЭД со стандартной функциональностью может администратор системы с навыками настройки Directum RX. Но в случае с модификациями нужен специалист-разработчик в штате вашей компании. Это дополнительная нагрузка и на ИТ-отдел, и на бюджет.

Отмечу, многие мои клиенты эту проблему решают с помощью аутсорсинга.

Бизнес-заказчикам модификаций нужно понимать их целесообразность

Еще один частый запрос клиентов: «Сделайте так же, как в… (название старой системы)». На наши вопросы о цели этой модификации, области применения и конкретных пользователях в 95% случаев ответов у заказчика нет. А они нам нужны для корректного построения и анализа бизнес-процесса и дальнейшей оценки.

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

Модификация должна быть четко расписана в ТЗ

Приведу в пример один из последних запросов на доработку. Клиент попросил просчитать стоимость и возможность добавления в карточку договора поля «Марка автомобиля». Казалось бы, тут и считать нечего, но давайте погрузимся в задачу и ответим на несколько вопросов.

Требуется просто свободное дополнительное поле, куда сотрудники будут вручную вносить названия автомобилей, или это должен быть выпадающий список? Если нужен перечень марок авто, то придется создать уникальный справочник. А это — уже вторая модификация.

Следующий вопрос: справочник должен быть в Directum RX или нужно подтягивать данные из сторонней базы ERP-системы? Целесообразнее, конечно, из ERP. И это — уже третья модификация ПО.

В итоге — доработка требует совсем других затрат и сроков, к которым клиент, возможно и не готов.

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

В этой статье я обозначила лишь самые необходимые моменты, которые вам нужно обсудить с рабочей группой перед стартом доработки ПО. А есть ли у вас свои примеры? Если да, делитесь ими в комментариях.