feat: add 1c-analyst skill — 1С business analyst for pre-project, gap-analysis, TZ review, migration planning
Modes: pre-project questionnaires, TZ/concept review, gap-analysis (typical/simple/complex customization), architecture selection (KA vs ERP vs UT), migration planning, BSL code/reports. References: KA 2.5 capabilities, ERP 2.5 diff, architecture patterns, TZ review checklist, customization catalog (ERF/EPF/MXL/CFE/BSP/config), migration plan template, questionnaire structure. Based on real project experience (ALREADICOM, MLRZ, Teplowin). Customization catalog adapted from 1C AI Development Kit (Arman Kudaibergenov).
This commit is contained in:
Claude
@@ -0,0 +1,232 @@
|
||||
# Каталог типов доработок 1С
|
||||
|
||||
> Маппинг: тип доработки → выходной артефакт → трудозатраты → риск обновления.
|
||||
> Использовать при gap-анализе для оценки каждой нетиповой функции,
|
||||
> а также при проектировании конкретной доработки.
|
||||
>
|
||||
> Источник базовой классификации: 1C AI Development Kit (Arman Kudaibergenov), адаптация.
|
||||
|
||||
---
|
||||
|
||||
## Приоритет выбора подхода
|
||||
|
||||
От безопасного к рискованному. Каждый шаг «глубже» = выше стоимость сопровождения
|
||||
на весь жизненный цикл системы. Всегда выбирать минимально инвазивный подход.
|
||||
|
||||
```
|
||||
1. Типовая настройка (параметры, справочники, доп. реквизиты через УФ)
|
||||
↓ если невозможно
|
||||
2. Внешний отчёт (ERF) / внешняя обработка (EPF) по существующим регистрам
|
||||
↓ если невозможно
|
||||
3. Расширение конфигурации (CFE) — перехват событий, доп. формы, модификация
|
||||
↓ если невозможно
|
||||
4. Дополнительная обработка через механизмы БСП (подключаемые команды, доп. отчёты)
|
||||
↓ если невозможно
|
||||
5. Изменение конфигурации (снятие с поддержки) — крайний случай
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Шкала сложности доработки
|
||||
|
||||
| Уровень | Объём | Ориентир трудозатрат | Типичные артефакты |
|
||||
|---------|-------|---------------------|--------------------|
|
||||
| **S** | Точечное изменение, 1-2 объекта | 4–16 ч | Внешний отчёт, печатная форма, доп. реквизит |
|
||||
| **M** | Несколько связанных объектов | 16–80 ч | Расширение CFE, новый документ + формы + права |
|
||||
| **L** | Новая подсистема или интеграция | 80–240 ч | Комплект: документы + регистры + отчёты + роли + тесты |
|
||||
| **XL** | Архитектурные изменения ядра | 240+ ч | Изменение типовых регистров, переделка логики проведения |
|
||||
|
||||
---
|
||||
|
||||
## Типы доработок: детальный каталог
|
||||
|
||||
### 1. Внешний отчёт (ERF)
|
||||
|
||||
**Артефакт:** файл `.erf` — отчёт на базе СКД или произвольный
|
||||
**Когда:** нужен отчёт, данные для которого уже есть в регистрах, но типового отчёта нет
|
||||
**Риск обновления:** нулевой — внешний файл, не затрагивает конфигурацию
|
||||
**Уровень:** обычно S (8–16 ч)
|
||||
|
||||
**Примеры:**
|
||||
- Aging дебиторской задолженности (по регистру взаиморасчётов)
|
||||
- EBITDA (по регистру доходов и расходов)
|
||||
- P&L по проектам с рентабельностью (по НД)
|
||||
- Сводка план/факт в нетиповом разрезе
|
||||
|
||||
**Структура артефакта:**
|
||||
```
|
||||
ВнешнийОтчёт
|
||||
├── Макет СКД (схема компоновки данных)
|
||||
│ ├── Набор данных — запрос к регистрам
|
||||
│ ├── Вычисляемые поля
|
||||
│ ├── Ресурсы (итоги)
|
||||
│ └── Настройки (группировки, отборы, оформление)
|
||||
└── Форма отчёта (опционально — для доп. параметров)
|
||||
```
|
||||
|
||||
### 2. Внешняя обработка (EPF)
|
||||
|
||||
**Артефакт:** файл `.epf` — обработка для массовых операций, загрузок, сервисных задач
|
||||
**Когда:** нужна автоматизация рутины, не покрытая типовым функционалом
|
||||
**Риск обновления:** нулевой (внешний файл)
|
||||
**Уровень:** S–M (8–40 ч)
|
||||
|
||||
**Примеры:**
|
||||
- Массовое заполнение доп. реквизитов
|
||||
- Загрузка данных из Excel
|
||||
- Формирование пакета документов по шаблону
|
||||
- Сверка данных между базами
|
||||
|
||||
### 3. Печатная форма (MXL)
|
||||
|
||||
**Артефакт:** макет `.mxl` — табличный документ для печати
|
||||
**Когда:** нужна нестандартная печатная форма для существующего документа
|
||||
**Риск обновления:** нулевой при подключении через БСП «Дополнительные печатные формы»
|
||||
**Уровень:** S (4–12 ч)
|
||||
|
||||
**Примеры:**
|
||||
- Нестандартный формат счёта на оплату
|
||||
- Внутренний акт с доп. реквизитами
|
||||
- Этикетка / стикер для складского учёта
|
||||
|
||||
### 4. Расширение конфигурации (CFE)
|
||||
|
||||
**Артефакт:** файл `.cfe` — расширение, подключаемое без снятия с поддержки
|
||||
**Когда:** нужно изменить поведение типовых объектов, добавить реквизиты, перехватить события
|
||||
**Риск обновления:** средний — может «отвалиться» при обновлении, если изменены те же модули
|
||||
**Уровень:** M–L (20–120 ч)
|
||||
|
||||
**Что можно:**
|
||||
- Добавлять реквизиты к типовым документам/справочникам
|
||||
- Перехватывать события (&Перед / &После)
|
||||
- Заимствовать и модифицировать типовые формы
|
||||
- Добавлять новые объекты (документы, справочники, регистры)
|
||||
- Добавлять подсистемы и команды
|
||||
|
||||
**Ограничения:**
|
||||
- Нельзя удалять типовые объекты или реквизиты
|
||||
- Конфликты при обновлении, если фирма «1С» изменила тот же модуль
|
||||
- Перехватчики добавляют накладные расходы на производительность
|
||||
|
||||
**Примеры:**
|
||||
- Добавление поля «Проект» к документу, где его нет
|
||||
- Автозаполнение реквизитов по бизнес-правилам
|
||||
- Доп. проверки при проведении документов
|
||||
|
||||
### 5. Доп. обработка через БСП
|
||||
|
||||
**Артефакт:** EPF, подключаемая через механизмы Библиотеки стандартных подсистем
|
||||
**Когда:** нужно интегрировать обработку в интерфейс типовой конфигурации без расширения
|
||||
**Риск обновления:** низкий — БСП-механизмы стабильны между версиями
|
||||
**Уровень:** S–M (8–40 ч)
|
||||
|
||||
**Механизмы БСП для подключения:**
|
||||
- Дополнительные отчёты и обработки (регистрация через справочник)
|
||||
- Подключаемые команды (кнопки на формах типовых документов)
|
||||
- Дополнительные печатные формы
|
||||
- Обработки заполнения документов
|
||||
|
||||
### 6. Новый объект метаданных (в конфигурации)
|
||||
|
||||
**Артефакт:** объекты конфигурации — документы, справочники, регистры, роли
|
||||
**Когда:** задачу нельзя решить расширением/обработкой
|
||||
**Риск обновления:** высокий — конфигурация снята с поддержки, обновления через сравнение/объединение
|
||||
**Уровень:** L–XL (80–300+ ч)
|
||||
|
||||
**Типичный комплект для нового бизнес-процесса:**
|
||||
```
|
||||
Новая подсистема
|
||||
├── Справочник(и) — классификаторы
|
||||
├── Документ(ы) — бизнес-операции
|
||||
│ ├── Табличные части
|
||||
│ ├── Формы (документа, списка, выбора)
|
||||
│ └── Модуль объекта (проведение, проверки)
|
||||
├── Регистр(ы) накопления / сведений — хранение движений
|
||||
├── Отчёт(ы) — аналитика по регистрам
|
||||
├── Роль(и) — разграничение доступа (RLS при необходимости)
|
||||
└── Подписки на события — интеграция с типовыми объектами
|
||||
```
|
||||
|
||||
**Примеры:**
|
||||
- Подсистема таймшитов (учёт трудозатрат по проектам)
|
||||
- Подсистема трансфертного ценообразования между ЦФО
|
||||
- Нетиповая интеграция с внешней системой
|
||||
|
||||
### 7. Изменение типового объекта
|
||||
|
||||
**Артефакт:** модификация существующих модулей, форм, макетов типовой конфигурации
|
||||
**Когда:** задачу нельзя решить **ни одним** из способов выше
|
||||
**Риск обновления:** критический — каждое обновление = ручное сравнение/объединение
|
||||
**Уровень:** M–XL
|
||||
|
||||
**Правило:** крайний случай. Перед тем как изменять типовой объект, дважды убедиться,
|
||||
что задачу нельзя решить расширением. Документировать каждое изменение:
|
||||
что именно изменено, зачем, какой код затронут, кто автор, дата.
|
||||
|
||||
---
|
||||
|
||||
## Сводная таблица для gap-анализа
|
||||
|
||||
| Тип | Артефакт | Риск обновления | Обычный уровень | Стоимость сопровождения |
|
||||
|-----|----------|-----------------|-----------------|-------------------------|
|
||||
| Внешний отчёт | .erf | Нулевой | S | Низкая |
|
||||
| Внешняя обработка | .epf | Нулевой | S–M | Низкая |
|
||||
| Печатная форма | .mxl через БСП | Нулевой | S | Низкая |
|
||||
| Через БСП | .epf (подключаемая) | Низкий | S–M | Низкая |
|
||||
| Расширение | .cfe | Средний | M–L | Средняя |
|
||||
| Новый объект | Конфигурация | Высокий | L–XL | Высокая |
|
||||
| Изменение типового | Конфигурация | Критический | M–XL | Очень высокая |
|
||||
|
||||
---
|
||||
|
||||
## Оценка совокупной стоимости доработки (TCO)
|
||||
|
||||
При оценке трудозатрат учитывать не только разработку, но и весь жизненный цикл:
|
||||
|
||||
| Компонент | % от общей стоимости (ориентир) |
|
||||
|-----------|-------------------------------|
|
||||
| Аналитика и проектирование | 15–25% |
|
||||
| Разработка | 30–40% |
|
||||
| Тестирование | 15–20% |
|
||||
| Документирование | 5–10% |
|
||||
| Внедрение (обучение, настройка) | 10–15% |
|
||||
| Сопровождение при обновлениях (в год) | 10–30% от стоимости разработки |
|
||||
|
||||
Для доработок с высоким/критическим риском обновления — стоимость сопровождения
|
||||
превысит стоимость начальной разработки уже через 2–3 года эксплуатации.
|
||||
|
||||
---
|
||||
|
||||
## Workflow разработки доработки (режим «Код/Отчёт»)
|
||||
|
||||
Адаптация 9-фазного pipeline (1C AI Dev Kit → 6 фаз для Claude.ai):
|
||||
|
||||
### Фаза 0: Оценка и классификация
|
||||
- Определить тип доработки по каталогу выше
|
||||
- Определить уровень сложности (S / M / L / XL)
|
||||
- Выбрать подход (ERF → EPF → CFE → конфигурация)
|
||||
|
||||
### Фаза 1: Требования и уточнения
|
||||
- Формализовать требования: что должно делать, входы/выходы, ограничения
|
||||
- Выявить неоднозначности, граничные случаи, зависимости от типовых объектов
|
||||
- Все вопросы пользователю — ДО начала проектирования
|
||||
|
||||
### Фаза 2: Проектирование
|
||||
- Определить затрагиваемые объекты конфигурации (регистры, справочники)
|
||||
- Спроектировать структуру данных (реквизиты, табличные части, регистры)
|
||||
- Спроектировать запросы (для отчётов — текст запроса СКД)
|
||||
- Спроектировать UI (формы, команды, расположение в интерфейсе)
|
||||
- Описать права доступа (роли, RLS)
|
||||
|
||||
### Фаза 3: Ревью плана → Одобрение пользователем
|
||||
- Представить план пользователю
|
||||
- **Не начинать реализацию без одобрения**
|
||||
|
||||
### Фаза 4: Реализация
|
||||
- Писать код BSL с комментариями
|
||||
- Для СКД — описать схему компоновки (наборы данных, ресурсы, настройки)
|
||||
- Для форм — описать элементы и обработчики
|
||||
|
||||
### Фаза 5: Ревью и документирование
|
||||
- Проверить код на соответствие стандартам 1С и плану
|
||||
- Создать описание доработки (для передачи клиенту / другому разработчику)
|
||||
Reference in New Issue
Block a user