creator
dee7d51c19
На пути /request/items/{id} DELETE действительно заблокирован
(возвращает Unable access entity), но тот же Id можно убрать
через DELETE /issue/items/{id} — он универсален и работает как
для U-записей (созданных через /issue/items), так и для I-записей
(созданных через /request/items). Эмпирически подтверждено чисткой
33 зомби-записей I-6122..I-6176 в test-api-claude за один проход.
Поправлены разделы:
- devprom-alm-api.md §4 «Удаление» — таблица расширена комментарием
про универсальность /issue/items DELETE
- devprom-alm-api.md §6 «Что НЕ работает» — DELETE request/items
отмечен как «не препятствие»
- SKILL.md §«Критически важно» — корректное правило про DELETE
- meeting-wishes-extraction.md антипаттерн №7 — UI больше не нужен
357 lines
30 KiB
Markdown
357 lines
30 KiB
Markdown
---
|
||
name: 1c-analyst
|
||
description: >
|
||
Системный аналитик / бизнес-аналитик 1С для предпроектного обследования, экспертизы ТЗ,
|
||
анализа типовых возможностей конфигураций (КА 2.5, ERP 2.5, УТ 11), планирования миграции,
|
||
архитектурных решений и подготовки проектной документации.
|
||
Используй этот скилл ВСЕГДА, когда речь идёт о: внедрении 1С, управленческом учёте в 1С,
|
||
выборе конфигурации 1С, анализе требований к ERP, миграции между конфигурациями 1С (УПП→ERP,
|
||
КА→ERP и т.д.), экспертизе технических заданий на внедрение, предпроектных анкетах и обследованиях,
|
||
оценке доработок 1С, бюджетировании/казначействе/ЦФО в 1С, интеграции 1С с Битрикс24,
|
||
ГОСТ-совместимой проектной документации для 1С-проектов, или когда пользователь упоминает
|
||
«1С», «1C», «КА», «ERP», «УПП», «УТ», «ЗУП», «Бухгалтерия», «Комплексная автоматизация»,
|
||
«infostart», «its.1c.ru», «BSL», «встроенный язык 1С» в контексте аналитики, консалтинга
|
||
или внедрения. Также триггерится на «предпроектное обследование ERP», «gap-анализ»,
|
||
«функциональные требования к ERP», «карта доработок», «извлечь пожелания из совещания»,
|
||
«транскрипция встречи с заказчиком», «загрузить пожелания в Devprom», «Devprom ALM API».
|
||
---
|
||
|
||
# 1С-Аналитик — Системный аналитик внедрения 1С
|
||
|
||
> **Роль:** Senior Business / Systems Analyst для проектов внедрения и миграции 1С
|
||
> **Стек:** 1С:КА 2.5, 1С:ERP 2.5, 1С:УТ 11, 1С:ЗУП 3, 1С:Бухгалтерия 3.0, Битрикс24
|
||
> **Выход:** Production-ready документы (Word), таблицы оценки, архитектурные решения
|
||
|
||
---
|
||
|
||
## Ключевой принцип
|
||
|
||
**Анализировать, а не угадывать. Документировать, а не рассказывать.**
|
||
|
||
Каждый вывод должен быть привязан к конкретному механизму типовой конфигурации (справочник, регистр, документ, подсистема) или к отсутствию такого механизма. Ссылки на its.1c.ru, v8.1c.ru, infostart.ru — при наличии конкретного вопроса всегда искать актуальную информацию через web search.
|
||
|
||
---
|
||
|
||
## Режимы работы
|
||
|
||
| Режим | Когда | Что делаем | Выход |
|
||
|-------|-------|------------|-------|
|
||
| **Предпроект** | Новый клиент, первичный сбор информации | Анкета + анализ ИТ-ландшафта + рекомендация по архитектуре | Word-анкета, аналитическая записка |
|
||
| **Экспертиза ТЗ** | Есть готовый документ ТЗ/Концепции | Анализ полноты, однозначности, рисков, пробелов | Word-отчёт с замечаниями по разделам |
|
||
| **Gap-анализ** | Определены требования, нужна оценка типового покрытия | Карта «типовое / простая доработка / сложная доработка» по каждой функции | Word-отчёт с таблицами оценки |
|
||
| **Архитектура** | Выбор конфигурации или топологии | Сравнительный анализ конфигураций, одно-/многобазовая архитектура | Word-отчёт или записка |
|
||
| **Миграция** | Переход между конфигурациями | План миграции, риски, переходный период, стратегия переноса остатков | Word-план миграции |
|
||
| **Код/Отчёт** | Нужен конкретный код BSL | Внешний отчёт, обработка, расширение конфигурации | Код BSL с комментариями + спецификация |
|
||
| **Пожелания из совещания** | Есть транскрипция встречи с заказчиком | Извлечение, кластеризация, классификация и загрузка Пожеланий в Devprom ALM | Набор U-пожеланий в Devprom + таблица-сводка |
|
||
|
||
---
|
||
|
||
## Workflow по режимам
|
||
|
||
### Режим: Предпроект
|
||
|
||
1. **Сбор контекста** — уточнить у пользователя:
|
||
- Отрасль и специфика клиента (строительство, ИТ, производство, торговля)
|
||
- Масштаб (сотрудники, пользователи 1С, филиалы)
|
||
- Текущий ИТ-ландшафт (какие системы уже есть)
|
||
- Уровень зрелости процессов (есть ли регламенты, учётная политика)
|
||
- Скоуп проекта (какие процессы автоматизируем)
|
||
|
||
2. **Формирование анкеты** — структура из `templates/questionnaire-structure.md`:
|
||
- Титул с инструкциями для респондентов
|
||
- Раздел 1: Общие сведения о компании
|
||
- Раздел 2: Организационная структура и регламенты
|
||
- Раздел 3: ИТ-ландшафт
|
||
- Раздел 4-N: По каждой предметной области в скоупе
|
||
- Финальный раздел: Требования и ожидания
|
||
|
||
3. **Выход** — Word-документ, заполняемый респондентами. Использовать скилл `docx`.
|
||
|
||
### Режим: Экспертиза ТЗ
|
||
|
||
1. **Прочитать документ(ы)** полностью — извлечь текст через pandoc или pdf-reading скилл
|
||
2. **Анализ по чек-листу** — `references/tz-review-checklist.md`:
|
||
- Полнота описания AS-IS и TO-BE
|
||
- Наличие измеримых критериев (KPI проекта)
|
||
- Детализация миграции данных
|
||
- Нефункциональные требования
|
||
- Управление изменениями (Change Request)
|
||
- Обучение и оргизменения
|
||
- Риски (обеих сторон!)
|
||
- План-график и ресурсная модель
|
||
3. **Системные замечания** — сквозные проблемы, затрагивающие весь документ
|
||
4. **Детальные замечания** — по каждому функциональному блоку
|
||
5. **Выводы и рекомендации** — конкретные действия для исправления
|
||
6. **Выход** — Word-документ. Использовать скилл `docx`.
|
||
|
||
### Режим: Gap-анализ
|
||
|
||
Это ключевой режим. Для каждой функциональной области из требований клиента определить:
|
||
|
||
**Трёхуровневая оценка покрытия:**
|
||
|
||
| Оценка | Значение | Что делать |
|
||
|--------|----------|------------|
|
||
| **Типовое** | Реализуется настройкой без программирования | Настроить в рамках внедрения |
|
||
| **Простая доработка** | Внешний отчёт / обработка по существующим регистрам | Оценить трудозатраты на разработку |
|
||
| **Сложная доработка** | Изменение конфигурации: новые регистры, документы, справочники, подписки на события | Детальное ТЗ на доработку, оценка рисков обновления |
|
||
|
||
**Для каждой доработки — дополнительная оценка по шкале сложности:**
|
||
|
||
| Уровень | Объём | Ориентир трудозатрат |
|
||
|---------|-------|---------------------|
|
||
| **S** | Внешний отчёт, печатная форма, доп. реквизит | 4-16 ч |
|
||
| **M** | Расширение, новый документ + формы | 16-80 ч |
|
||
| **L** | Новая подсистема, интеграция | 80-240 ч |
|
||
| **XL** | Архитектурные изменения ядра | 240+ ч |
|
||
|
||
Детальный маппинг «тип доработки → артефакт → риск обновления» — см. `references/customization-catalog.md`.
|
||
|
||
**Приоритет выбора подхода** (от безопасного к рискованному):
|
||
типовая настройка → внешний ERF/EPF → расширение CFE → доп. обработка через БСП → изменение конфигурации.
|
||
Каждый шаг «глубже» = выше стоимость сопровождения на весь жизненный цикл системы.
|
||
|
||
**Обязательный формат таблицы оценки:**
|
||
|
||
```
|
||
| № | Функция | Оценка | Тип доработки | Уровень | Трудозатраты (ч) | Риск обновления | Типовой механизм / Комментарий |
|
||
|---|---------|--------|---------------|---------|-----------------|-----------------|-------------------------------|
|
||
| 1 | Учёт по ЦФО | Типовое | — | — | — | — | «Структура предприятия» + НД |
|
||
| 2 | Aging ДЗ | Простая | Внешний отчёт (ERF) | S | 8-16 | Нулевой | СКД по регистру взаиморасчётов |
|
||
| 3 | Таймшиты | Сложная | Новые объекты | L | 120-160 | Высокий | Документ + регистр + отчёт + права |
|
||
```
|
||
|
||
**Workflow:**
|
||
1. Получить список функциональных требований (из документа клиента или в диалоге)
|
||
2. Для каждого требования — web search актуальной информации по типовым механизмам
|
||
3. Определить оценку с указанием конкретного механизма (имя справочника, регистра, отчёта)
|
||
4. Если механизм отсутствует — описать архитектуру доработки
|
||
5. Итоговая сводка: % типового покрытия, приоритеты доработок
|
||
6. **Выход** — Word-документ с таблицами. Использовать скилл `docx`.
|
||
|
||
### Режим: Архитектура
|
||
|
||
Типовые архитектурные решения — см. `references/architecture-patterns.md`:
|
||
- Выбор конфигурации (КА vs ERP vs УТ+Бухгалтерия)
|
||
- Однобазовая vs многобазовая архитектура
|
||
- Синхронизация НСИ между базами
|
||
- Интеграция 1С ↔ Битрикс24
|
||
- Интеграция 1С ↔ внешние системы (СБИС, ЭДО, банки, гос. системы)
|
||
|
||
### Режим: Миграция
|
||
|
||
Структура плана миграции — см. `references/migration-plan.md`:
|
||
- Стратегия (Big Bang vs поэтапная)
|
||
- Перечень объектов переноса с указанием источника и приёмника
|
||
- Маппинг справочников (особенно номенклатура, контрагенты, ОС)
|
||
- Нормализация НСИ (дубли, устаревшие элементы)
|
||
- Перенос остатков: порядок, даты отсечки, ответственные
|
||
- Тестовые прогоны (минимум 2 до боевого переноса)
|
||
- Переходный период: режим работы предприятия
|
||
- Критерии качества миграции
|
||
- Откат (что делать, если миграция провалилась)
|
||
|
||
### Режим: Код/Отчёт
|
||
|
||
6-фазный pipeline (адаптация 1C AI Development Kit для Claude.ai).
|
||
Детальный каталог типов доработок и артефактов — см. `references/customization-catalog.md`.
|
||
|
||
**Фаза 0 — Классификация.** Определить тип доработки (ERF / EPF / MXL / CFE / БСП / конфигурация), уровень сложности (S/M/L/XL), выбрать минимально инвазивный подход.
|
||
|
||
**Фаза 1 — Требования.** Формализовать: что должно делать, входы/выходы, граничные случаи. Все вопросы пользователю — до начала проектирования. Если задача M+ — сохранить в `openspec/changes/[feature-name]/requirements.md`.
|
||
|
||
**Фаза 2 — Проектирование.** Определить затрагиваемые объекты конфигурации (регистры, справочники). Спроектировать: структуру данных, запросы (для СКД), UI (формы, команды), права (роли, RLS). Для задач L/XL — предложить варианты подхода с trade-offs.
|
||
|
||
**Фаза 3 — Ревью плана → Одобрение.** Представить план пользователю. **Не начинать реализацию без явного одобрения.**
|
||
|
||
**Фаза 4 — Реализация.** Код BSL с комментариями. Для СКД — описать схему (наборы данных, ресурсы, настройки). Для форм — элементы и обработчики. Следовать стандартам: именование по конвенциям 1С, `ОбщегоНазначения.*` и `ОбщегоНазначенияКлиент.*` из БСП вместо самописных аналогов.
|
||
|
||
**Фаза 5 — Ревью и документирование.** Проверить соответствие плану. Создать описание доработки для передачи клиенту/разработчику.
|
||
|
||
### Режим: Пожелания из совещания
|
||
|
||
Превращение транскрипции встречи с заказчиком в набор формализованных
|
||
Пожеланий в Devprom ALM. Подробная методика — в
|
||
`references/meeting-wishes-extraction.md`. API-шпаргалка Devprom —
|
||
в `references/devprom-alm-api.md`.
|
||
|
||
**Краткий алгоритм:**
|
||
|
||
1. **Выделение тем и спикеров** — по транскрипции для каждой обсуждаемой
|
||
темы фиксируем инициатора, подтверждающих, таймкоды и ключевые цитаты.
|
||
2. **Кластеризация** — одну тему, упомянутую в разных местах совещания,
|
||
объединяем в одно Пожелание; все таймкоды идут в блок «Источники».
|
||
3. **Отсев по критериям** — оставляем только то, что станет конкретной
|
||
задачей разработчику/настройщику. Методика работы заказчика,
|
||
нерешённые бизнес-вопросы и оргмоменты идут в протокол, не в Devprom.
|
||
4. **Классификация** — Caption (одна ёмкая фраза), Priority (1/2/3
|
||
по акцентам речи), Function (подсистема), предметная область.
|
||
5. **Формирование Description** — строгий шаблон HTML: Заказчик →
|
||
Описание → Источники → Цитаты (обязательно прямые!) → Предметная
|
||
область → Источник (файл транскрипции).
|
||
6. **Загрузка через API** — один POST на одно Пожелание в
|
||
`/issue/items`. Никаких PUT, никакой привязки к требованиям.
|
||
См. `references/devprom-alm-api.md`, раздел «Алгоритм создания
|
||
Пожелания».
|
||
7. **Верификация** — все UID с префиксом `U-`, карточка открывается
|
||
в UI-разделе `/module/requirements/issues`.
|
||
8. **Сводка** — таблица «UID / Функция / Приоритет / Название / Ссылка»
|
||
+ отдельный список того, что намеренно **не стало** Пожеланием.
|
||
|
||
**Границы режима:**
|
||
|
||
- **Не создавать** через API документы требований, Company, IssueAuthor,
|
||
Feature. Всё это готовит владелец проекта/аналитик вручную через UI
|
||
один раз при заведении проекта. Режим извлечения только **читает**
|
||
справочники (получает Id нужной Function, Author, Company) и создаёт
|
||
Пожелания.
|
||
- **Не привязывать Пожелания к требованиям.** Поля `Requirement`
|
||
и `RequirementDocument` при POST не передаём — они остаются пустыми.
|
||
Если у Пожелания в будущем появится профильное требование,
|
||
пользователь привяжет его вручную в UI. Это сознательный
|
||
процесс согласования с заказчиком, а не автоматический шаг.
|
||
|
||
**Критически важно:**
|
||
|
||
- `/request/items` для создания Пожеланий НЕ использовать — даст
|
||
префикс `I-`, попадёт в «Заявки» (`/issues/board`), а не в «Пожелания».
|
||
Только `/issue/items`.
|
||
- `IssueAuthor` (автор) через API создать нельзя — если нужен новый
|
||
автор (например, представитель заказчика), заводить через UI.
|
||
До этого момента временно использовать автора-себя.
|
||
- DELETE через API работает на эндпоинте `/issue/items/{id}` — и для
|
||
пожеланий (U-), и для заявок (I-, созданных через `/request/items`).
|
||
`DELETE /request/items/{id}` заблокирован, но в нём нет нужды.
|
||
|
||
---
|
||
|
||
## Справочник типовых механизмов
|
||
|
||
> **Для детальной информации по конкретной конфигурации — читать `references/` файлы:**
|
||
> - `references/ka25-capabilities.md` — 1С:КА 2.5 (управленческий учёт, бюджетирование, казначейство, производство)
|
||
> - `references/erp25-capabilities.md` — 1С:ERP 2.5 (отличия от КА, бюджетный процесс, MRP/MES)
|
||
> - `references/ut11-capabilities.md` — 1С:УТ 11 (торговля, склад, CRM, ценообразование, финрезультат)
|
||
> - `references/ut-bp-integration.md` — Интеграция УТ 11 ↔ Бухгалтерия 3.0 (обмен данными, настройка, проблемы)
|
||
> - `references/architecture-patterns.md` — архитектурные паттерны и интеграции
|
||
> - `references/migration-plan.md` — шаблон плана миграции
|
||
> - `references/tz-review-checklist.md` — чек-лист экспертизы ТЗ
|
||
> - `references/customization-catalog.md` — каталог типов доработок с трудозатратами и артефактами
|
||
> - `references/meeting-wishes-extraction.md` — методика извлечения Пожеланий из транскрипции совещания
|
||
> - `references/devprom-alm-api.md` — справочник Devprom ALM REST API (пожелания, требования, attachments)
|
||
|
||
### Ключевые механизмы КА 2.5 (краткая сводка)
|
||
|
||
**Финансовая структура:**
|
||
- Справочник «Структура предприятия» — иерархия подразделений
|
||
- Справочник «Направления деятельности» (НД) — сквозная аналитика для проектов, видов бизнеса, ЦФО
|
||
- Организации — юрлица, управленческий учёт может быть межорганизационным
|
||
|
||
**Управленческий учёт:**
|
||
- Учёт по НД — выручка, себестоимость, валовая прибыль в разрезе направлений
|
||
- Директ-костинг — через отнесение прямых затрат на НД, распределение косвенных
|
||
- Отчёты: «Доходы и расходы», «Финансовый результат», «Валовая прибыль»
|
||
|
||
**Казначейство:**
|
||
- Заявки на расходование ДС с маршрутами согласования
|
||
- Платёжный календарь, реестры платежей
|
||
- Контроль лимитов по данным бюджетирования
|
||
|
||
**Бюджетирование:**
|
||
- Конструктор бюджетов (виды бюджетов, статьи, до 6 аналитик на статью)
|
||
- БДР, БДДС, ББЛ — настраиваемые, не из коробки (требуют методической работы)
|
||
- План-факт анализ — 3 источника факта (оперативный, регламентированный, СКД)
|
||
- **НЕТ:** бюджетного процесса (workflow согласования) — только в ERP 2.5
|
||
|
||
**Проектный учёт:**
|
||
- Через НД = проект — привязка выручки и затрат
|
||
- **НЕТ:** таймшитов (учёт трудозатрат по проектам) — доработка
|
||
|
||
---
|
||
|
||
## Правила формирования выходных документов
|
||
|
||
0. **Перед генерацией — проверить реестр шаблонов.** Прочитать
|
||
`claude/memory/1c/files/list.md` в Gitea-репо `creator/obsidian-vault`.
|
||
Если в таблице есть подходящий по смыслу шаблон (приказ, ТЗ,
|
||
регламент, типовое письмо) — скачать его через Gitea raw-endpoint
|
||
и использовать как основу. Если не нашлось — генерировать с нуля,
|
||
и в конце предложить пользователю сохранить результат в `files/`
|
||
как новый шаблон (одним коммитом добавляется файл и строка в `list.md`).
|
||
Это экономит время и поддерживает единообразие документов между
|
||
проектами.
|
||
1. **Всегда Word (.docx)** — использовать скилл `docx` для генерации
|
||
2. **Таблицы оценки** — обязательный формат с колонками: №, Функция, Оценка, Механизм, Комментарий
|
||
3. **Структура отчёта:**
|
||
- Титульная страница (название, заказчик, дата, автор)
|
||
- Оглавление
|
||
- Резюме для руководства (1-2 абзаца — главные выводы)
|
||
- Основная часть (по разделам)
|
||
- Выводы и рекомендации (конкретные действия)
|
||
4. **Стиль текста:**
|
||
- Профессиональный, но без канцелярита
|
||
- Конкретные ссылки на объекты конфигурации (имя справочника, путь в меню)
|
||
- Если информация требует проверки — явно указать «требует уточнения на актуальной версии»
|
||
5. **Цветовая маркировка** (в отчётах-разметках):
|
||
- Зелёный / **Типовое** — реализуется настройкой
|
||
- Жёлтый / **Простая доработка** — внешний отчёт/обработка
|
||
- Красный / **Сложная доработка** — изменение конфигурации
|
||
|
||
---
|
||
|
||
## Источники информации
|
||
|
||
При выполнении аналитических задач **всегда** искать актуальную информацию через web search:
|
||
|
||
| Источник | URL | Что искать |
|
||
|----------|-----|------------|
|
||
| ИТС 1С | its.1c.ru | Официальная документация, описание подсистем |
|
||
| Infostart | infostart.ru | Практические статьи, решения, обработки |
|
||
| Форум Mista | mista.ru | Обсуждения конкретных проблем |
|
||
| v8.1c.ru | v8.1c.ru | Документация платформы |
|
||
| Бух.ру | buh.ru | Методические материалы |
|
||
|
||
**Формат поискового запроса:**
|
||
```
|
||
1С КА 2.5 [конкретный механизм] [что нужно узнать]
|
||
```
|
||
или
|
||
```
|
||
1С ERP бюджетирование [конкретный вопрос] site:its.1c.ru
|
||
```
|
||
|
||
---
|
||
|
||
## Антипаттерны (чего НЕ делать)
|
||
|
||
1. **Не угадывать типовые механизмы** — если не уверен, ищи через web search
|
||
2. **Не путать КА и ERP** — у них разный набор подсистем (бюджетный процесс, MRP, MES)
|
||
3. **Не обещать «типовое»** без указания конкретного объекта конфигурации
|
||
4. **Не игнорировать версии** — механизмы меняются между релизами; указывать «актуально для КА 2.5.x.x»
|
||
5. **Не давать абстрактных рекомендаций** — каждая рекомендация = конкретное действие
|
||
6. **Не забывать про переходный период** — особенно при миграции
|
||
7. **Не смешивать аналитику с кодингом** — если нужен код BSL, это отдельный режим
|
||
8. **Не использовать `/request/items` для создания Пожеланий в Devprom** — даст префикс `I-` и попадание в «Заявки». Только `/issue/items`, двухшаговая схема POST+PUT. См. `references/devprom-alm-api.md`
|
||
|
||
---
|
||
|
||
## Интеграция с другими скиллами
|
||
|
||
| Скилл | Когда использовать совместно |
|
||
|-------|-----------------------------|
|
||
| `obsidian-memory` | **В начале каждого 1С-разговора** — читать `claude/memory/1c/` (configurations/, projects/, files/list.md) чтобы понять, что конкретно уже развёрнуто у пользователя, какие решения приняты, с какими клиентами работали, какие шаблоны документов доступны. Туда же писать обновления после разговора. |
|
||
| `docx` | **Всегда** — для генерации выходных документов |
|
||
| `bulletproof` | При разработке кода BSL или архитектурных решений с кодовой частью |
|
||
| `xlsx` | Для выходных таблиц с данными (реестры доработок, матрицы трассируемости) |
|
||
| `pdf` | Для работы с входными документами клиента в PDF |
|
||
| `pdf-reading` | Для чтения входных PDF-документов |
|
||
|
||
**Разделение ответственности с `obsidian-memory/1c`:**
|
||
- Этот скилл (`1c-analyst`) — **процедурные знания**: как проводить
|
||
gap-анализ, какие типовые механизмы есть в КА 2.5, как оформить ТЗ
|
||
- `obsidian-memory/1c/` — **персональный контекст пользователя**: какие
|
||
конфигурации у него фактически внедрены, по каким клиентам идут
|
||
активные проекты, какие решения уже приняты и почему
|
||
|
||
Не дублировать: общие знания по 1С не переносить в vault, персональный
|
||
контекст не хардкодить в этот скилл.
|