На каждом проекте наступает момент, когда заказчик говорит «у нас так не работает», и нужно решить: менять систему под процесс или процесс под систему. Ответ «всегда дорабатывать» ведёт к неподдерживаемой конфигурации, ответ «всегда использовать типовое» — к тому, что системой не пользуются. Разберём критерии, по которым это решается.
Три вопроса к каждому требованию
- Это специфика или привычка? Часть требований отражает реальные особенности бизнеса, часть — сложившийся порядок, который никто не пересматривал. Автоматизировать второе значит закрепить его навсегда.
- Влияет ли это на результат для клиента или на экономику? Если нет — требование, скорее всего, не стоит доработки.
- Есть ли обходной путь штатными средствами? Часто требование закрывается настройкой, дополнительным реквизитом или отчётом, а не изменением логики.
Первый вопрос звучит неудобно, но задавать его необходимо. Формулировка «мы всегда так делали» — не обоснование, а сигнал разобраться, зачем.
Что обычно закрывается настройкой
- дополнительные реквизиты заявок, нарядов, оборудования;
- собственные классификаторы и справочники;
- печатные формы под требования клиентов;
- отчёты в нужных разрезах;
- роли и права доступа;
- правила расчёта стоимости работ;
- шаблоны уведомлений.
Существенная часть требований, которые заказчик считает доработкой, попадает именно сюда. Прежде чем оценивать разработку, стоит проверить каждый пункт на возможность настройки.
Что почти всегда требует доработки
| Требование | Почему типового не хватает |
|---|---|
| Сложная статусная модель с развилками | Типовые маршруты линейны |
| Расчёт сроков по рабочему календарю и приостановкам | Обычно считается календарное время |
| Гарантия с разделением плательщика | Признак есть, контура работы нет |
| Обменный фонд | Отсутствует как механизм |
| Учёт запаса у мастера | Нет отдельного места хранения |
| Мобильное место с офлайн-режимом | Требует отдельного приложения |
| Показатели сервиса | Считаются иначе, чем стандартные отчёты |
| Подбор исполнителя по квалификации и загрузке | Типового механизма нет |
Эти позиции стоит закладывать в бюджет проекта сразу: попытка обойтись без них обычно заканчивается ведением параллельных таблиц.
Что лучше не дорабатывать
- Складской учёт. Реализован хорошо, вмешательство создаёт риски.
- Расчёты с контрагентами и закрытие периода. Регламентированный участок, доработки дороги в сопровождении.
- Механизмы обмена и обновления. Изменение платформенных механизмов усложняет каждое обновление.
- Воспроизведение чужого интерфейса. Требование «сделайте как в старой программе» почти всегда обходится дороже переобучения.
Как дорабатывать, чтобы не создать проблему
- Расширения вместо изменения типовых объектов. Сохраняет возможность штатного обновления.
- Отдельные объекты вместо перегрузки типовых. Собственный документ понятнее, чем типовой с десятью дополнительными реквизитами и изменённой логикой.
- Документирование. Назначение, автор, дата, обоснование. Без этого через год доработку никто не рискнёт трогать.
- Регулярный пересмотр. Часть доработок со временем входит в типовой функционал или перестаёт быть нужной.
- Оценка сопровождения. Стоимость доработки — это не только разработка, но и проверка при каждом обновлении.
Порядок принятия решения
- Собрать требования списком, без привязки к решениям.
- По каждому задать три вопроса из начала статьи.
- Отсеять привычки, не влияющие на результат.
- Проверить возможность закрытия настройкой.
- Оставшееся оценить в трудозатратах.
- Сопоставить стоимость доработки со стоимостью изменения процесса.
- Проверить, не воспроизводит ли совокупность доработок отдельный продукт.
Шестой пункт часто пропускают, а он ключевой: изменить процесс иногда дешевле и полезнее, чем автоматизировать существующий.
Итог
Граница между настройкой и доработкой проходит там, где требование перестаёт быть привычкой и начинает влиять на результат для клиента или на экономику. Значительная часть требований сервиса закрывается настройкой, но восемь позиций — статусная модель, расчёт сроков, гарантия, обменный фонд, запас у мастера, мобильное место, показатели и подбор исполнителя — почти всегда требуют разработки, и их стоит закладывать в бюджет заранее.
Готовый сервисный контур с возможностью настройки под специфику даёт решение «1С:Сервисный Ремонт».
Компания «Сайфилд» разделяет требования сервисной службы на закрываемые настройкой и требующие доработки и реализует и то, и другое в «1С». Опишите свои требования, и мы дадим оценку.