Типовой функционал каждая команда описывает заново

Жалоба, которая повторяется в каждом обсуждении СППР

В чатах про проектирование на 1С одна тема возвращается постоянно, в разных словах:

Функции типовой системы нигде не описаны. В СППР их приходится описывать самим и переописывать с каждым релизом. Это трудоёмко.

Каждая компания вынуждена заново описывать бесконечно меняющиеся части типового решения.

Где методика, как получить связное описание, если мы не проектируем систему с нуля, а актуального описания типового функционала нет?

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

Почему описание типовой невозможно поддерживать руками

Типовая ERP — это тысячи объектов, и вендор меняет её каждым релизом. Описание, сделанное под один релиз, через два релиза уже расходится с системой в деталях: появились новые реквизиты, изменились движения, перестроились подсистемы. Хуже всего, что расхождения не видны: документ выглядит актуальным, пока на него не опираются в проектировании.

В чатах об этом говорят прямо: без постоянного обновления информация в СППР «тихо устареет и умрёт».

Так появляется выбор без хорошего варианта. Поддерживать описание — значит выделить на это людей, которых и так не хватает. Не поддерживать — значит делать GAP-анализ по памяти.

Во что это превращает GAP-анализ

GAP-анализ отвечает на простой вопрос: что из требования уже закрывает типовая, а что придётся дорабатывать. Чтобы ответить, нужно точно знать, что в типовой есть.

Без актуального описания ответ строится так:

аналитик вспоминает, что «в ERP такое вроде было»;
идёт проверять в демобазу или на ИТС;
находит механизм, но не уверен, что он работает с нужными доработками;
на всякий случай закладывает доработку.

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

Как это устроено, когда типовая проиндексирована

Мы проиндексировали типовые конфигурации: ERP, КА, УХ и УНФ. Индекс строится не по документации, а по самой конфигурации: объекты метаданных, связи между ними, код, роли. У клиента к этому добавляется индекс его конфигурации с доработками.

Описание типовой при этом никто не пишет руками. Оно берётся из конфигурации, и когда конфигурация меняется, обновляется индекс, а не документ.

На этой основе 1Yes Аналитик разбирает требование:

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

Состав решения: типовые настройки и доработки разведены явно — Требование про автоматическое создание счёта с согласованием. Три пункта закрываются типовыми настройками: функциональные опции, роль в справочнике, расписание регламентного задания. Два требуют доработки. Названы конкретные объекты конфигурации.

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

Что меняется для аналитика

Исходная точка. Раньше разбор требования начинался с чистого листа и поиска «что там есть в типовой». Теперь он начинается с перечня: вот что уже есть, вот где разрыв, вот два способа его закрыть.

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

Когда это не сработает

Конфигурация клиента не проиндексирована. Тогда анализ идёт по типовой, и ваши доработки в нём не участвуют. Для оценки механизма это полезно, для GAP-анализа на реальной базе — нет.
Индекс отстал от конфигурации. Если базу активно дорабатывают, индекс нужно обновлять. Это услуга с понятной периодичностью, а не автоматика.
Требование описано слишком общо. Система задаст вопросы, но если отвечать на них некому, варианты будут такими же общими.
Система может ошибиться. Поэтому в составе решения названы объекты: спорный пункт проверяется по конфигурации, а не принимается на веру.

С чего начать

Замер конфигурации. Передаём скрипт-отчёт 1С, по нему считается объём индексации.
Индексация. Ваша конфигурация с доработками разбирается так же, как типовая.
Разбор ваших требований. Лучше всего взять те, где уже спорили, типовое это или доработка.