Разработка конфигурации 1С бывает двух видов: создание собственного прикладного решения с нуля на платформе «1С:Предприятие» или доработка типовой конфигурации под процессы компании. С нуля имеет смысл разрабатывать, когда автоматизируется узкая или нестандартная область, для которой типовые решения избыточны. Если же типовая конфигурация закрывает большую часть задач, выгоднее взять её и доработать: она обновляется вендором, протестирована на тысячах компаний, и найти специалиста по ней проще.
Ниже — как принять это решение, из каких этапов состоит проект и что заказчику стоит проверить, чтобы получить работающую систему, а не бесконечную разработку.
Почему компании выбирают платформу 1С
Платформа «1С:Предприятие» — это среда разработки учётных и управленческих систем. Её выбирают по понятным причинам:
- готовые механизмы: справочники, документы, регистры, отчёты на СКД, права доступа, обмены — не нужно писать инфраструктуру;
- большое количество специалистов на рынке;
- клиент-серверная работа на Windows и Linux, с PostgreSQL или другими СУБД;
- веб-клиент, мобильная платформа, HTTP-сервисы для интеграций;
- типовые и отраслевые решения, которые можно взять за основу.
Важно не путать: «гибкость» платформы не означает, что любая доработка дешёвая. Стоимость владения зависит от того, насколько грамотно спроектировано решение.
Типовая с доработками или своя: как выбрать
| Критерий | Типовая + доработки | Своя конфигурация |
|---|---|---|
| Покрытие задач | Типовая закрывает большую часть | Типовые решения не подходят по модели учёта |
| Регламентированный учёт | Обновляется вендором | Придётся поддерживать самим (или интегрироваться с типовой бухгалтерией) |
| Обновления платформы и законодательства | Выпускает фирма «1С» | На вашей команде |
| Скорость старта | Быстрее: функциональность уже есть | Медленнее: всё проектируется заново |
| Сложность и «лишние» подсистемы | Много того, что не используется | Только нужное, проще и быстрее работает |
| Зависимость от подрядчика | Ниже: специалистов по типовым много | Выше: без документации и стандартов — критическая |
Мой практический принцип: регламентированный учёт — в типовых решениях, уникальные процессы — в своих конфигурациях или расширениях, связанных обменом. Например, учёт сервисных заявок в своей небольшой конфигурации, а бухгалтерия и зарплата — в типовых «1С:Бухгалтерии» и ЗУП.
Ещё один вариант, о котором часто забывают, — отраслевые решения партнёров фирмы «1С». Прежде чем писать с нуля, стоит проверить, нет ли готового продукта для вашей отрасли с отметкой «1С:Совместимо».
Этапы проекта разработки
1. Требования
Начинается всё с требований заказчика:
- функциональные — что система должна делать: какие процессы автоматизируются, какие документы, расчёты, отчёты, кто и что делает в системе;
- нефункциональные — как она должна работать: число пользователей, нагрузка, доступность, безопасность, интеграции, режимы работы (веб, мобильные устройства).
Цель этого документа — чтобы сам заказчик осознал модель будущей системы. Даже краткое описание процессов со схемами экономит недели на следующем этапе.
2. Обследование и концепция
Интервью с ключевыми сотрудниками, описание процессов «как есть» и модели «как будет»: структура компании, функции подразделений, документооборот, информационные потоки между системами. Результат — концепция системы, которую согласует заказчик.
3. Выбор основы
Решение «с нуля или на базе типовой» принимается здесь — по таблице выше и после изучения типовых и отраслевых решений.
4. Архитектура
По каждому процессу определяется структура метаданных: справочники, документы, регистры, перечисления, роли. На этом этапе нужен архитектор — разработчик, который хорошо понимает идеологию платформы. Ошибки архитектуры (например, неверный выбор регистров) потом исправляются очень дорого.
5. Техническое задание
Документ для разработчика: структура метаданных с реквизитами и типами, алгоритмы расчётов, права пользователей, правила хранения данных, схема интеграций, требования к отчётам. Чем точнее ТЗ, тем меньше споров при приёмке.
6. Разработка
По системе стандартов и методик разработки фирмы «1С», с использованием БСП. При разработке с нуля нужно сразу заложить общие механизмы — права, печать, файлы, обновление версий, — которые в типовых конфигурациях уже есть. Код — в системе контроля версий с первого дня.
7. Тестирование
Проверка всех сценариев на подготовленных примерах с эталонными результатами: правильно ли считаются суммы, формируются движения, строятся отчёты. Для ключевых процессов имеет смысл сразу писать автотесты — они окупятся при первой же доработке.
8. Документация и обучение
Инструкции пользователя по каждому процессу, обучение ключевых пользователей, проверка, что они действительно умеют работать в системе. Без этого даже хорошая разработка встречает сопротивление.
Риски своей конфигурации и как их снизить
| Риск | Как снизить |
|---|---|
| Зависимость от одного разработчика | Стандарты кода, документация, код в Git, ревью |
| Нет обновлений от вендора | Регламентированный учёт держать в типовых решениях |
| «Бесконечная» разработка | Этапы с приёмкой, MVP на ключевом процессе |
| Ошибки архитектуры | Архитектор на этапе проектирования, прототип |
| Сложно найти специалиста на поддержку | БСП и стандартные подходы вместо самописных механизмов |
Сроки и стоимость
Честно оценить проект можно только после обследования и проектирования: небольшая конфигурация для одного процесса и система уровня ERP различаются на порядки. Чтобы контролировать бюджет:
- разбивайте проект на этапы с отдельной приёмкой;
- начинайте с минимально полезной версии на одном ключевом процессе;
- фиксируйте изменения требований отдельно от исходного ТЗ.
Для ориентира по трудозатратам у меня почасовая ставка 2 500 ₽/ч; итоговая оценка — по результатам проектирования.
Чек-лист для заказчика
- Описаны процессы, которые нужно автоматизировать, и ожидаемый результат.
- Проверены типовые и отраслевые решения.
- Принято осознанное решение «своя или типовая» с учётом поддержки.
- Есть архитектура и ТЗ, согласованные до начала разработки.
- Код хранится в системе контроля версий, есть документация.
- Предусмотрены тестирование, обучение и поддержка после запуска.
Если вы на этапе выбора, могу помочь с обследованием и оценкой вариантов: разработка конфигураций 1С, доработка 1С, консультация по 1С.
Итог
- Разработка конфигурации 1С с нуля оправдана для узких и нестандартных процессов; в остальных случаях выгоднее типовая с доработками.
- Регламентированный учёт лучше держать в типовых решениях, уникальные процессы — в своих конфигурациях или расширениях.
- Проект идёт по этапам: требования, концепция, выбор основы, архитектура, ТЗ, разработка, тестирование, обучение.
- Главные риски своей конфигурации — зависимость от разработчика и отсутствие обновлений; их снижают стандарты, БСП и документация.
- Бюджет контролируют этапами с приёмкой и запуском минимальной версии на ключевом процессе.
