diff --git a/1c-analyst/SKILL.md b/1c-analyst/SKILL.md
new file mode 100644
index 0000000..5ca08ce
--- /dev/null
+++ b/1c-analyst/SKILL.md
@@ -0,0 +1,274 @@
+---
+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», «карта доработок».
+---
+
+# 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 с комментариями + спецификация |
+
+---
+
+## 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 — Ревью и документирование.** Проверить соответствие плану. Создать описание доработки для передачи клиенту/разработчику.
+
+---
+
+## Справочник типовых механизмов
+
+> **Для детальной информации по конкретной конфигурации — читать `references/` файлы:**
+> - `references/ka25-capabilities.md` — 1С:КА 2.5 (управленческий учёт, бюджетирование, казначейство, производство)
+> - `references/erp25-capabilities.md` — 1С:ERP 2.5 (отличия от КА, бюджетный процесс, MRP/MES)
+> - `references/architecture-patterns.md` — архитектурные паттерны и интеграции
+> - `references/migration-plan.md` — шаблон плана миграции
+> - `references/tz-review-checklist.md` — чек-лист экспертизы ТЗ
+> - `references/customization-catalog.md` — каталог типов доработок с трудозатратами и артефактами
+
+### Ключевые механизмы КА 2.5 (краткая сводка)
+
+**Финансовая структура:**
+- Справочник «Структура предприятия» — иерархия подразделений
+- Справочник «Направления деятельности» (НД) — сквозная аналитика для проектов, видов бизнеса, ЦФО
+- Организации — юрлица, управленческий учёт может быть межорганизационным
+
+**Управленческий учёт:**
+- Учёт по НД — выручка, себестоимость, валовая прибыль в разрезе направлений
+- Директ-костинг — через отнесение прямых затрат на НД, распределение косвенных
+- Отчёты: «Доходы и расходы», «Финансовый результат», «Валовая прибыль»
+
+**Казначейство:**
+- Заявки на расходование ДС с маршрутами согласования
+- Платёжный календарь, реестры платежей
+- Контроль лимитов по данным бюджетирования
+
+**Бюджетирование:**
+- Конструктор бюджетов (виды бюджетов, статьи, до 6 аналитик на статью)
+- БДР, БДДС, ББЛ — настраиваемые, не из коробки (требуют методической работы)
+- План-факт анализ — 3 источника факта (оперативный, регламентированный, СКД)
+- **НЕТ:** бюджетного процесса (workflow согласования) — только в ERP 2.5
+
+**Проектный учёт:**
+- Через НД = проект — привязка выручки и затрат
+- **НЕТ:** таймшитов (учёт трудозатрат по проектам) — доработка
+
+---
+
+## Правила формирования выходных документов
+
+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, это отдельный режим
+
+---
+
+## Интеграция с другими скиллами
+
+| Скилл | Когда использовать совместно |
+|-------|-----------------------------|
+| `docx` | **Всегда** — для генерации выходных документов |
+| `bulletproof` | При разработке кода BSL или архитектурных решений с кодовой частью |
+| `xlsx` | Для выходных таблиц с данными (реестры доработок, матрицы трассируемости) |
+| `pdf` | Для работы с входными документами клиента в PDF |
+| `pdf-reading` | Для чтения входных PDF-документов |
diff --git a/1c-analyst/references/architecture-patterns.md b/1c-analyst/references/architecture-patterns.md
new file mode 100644
index 0000000..cf95376
--- /dev/null
+++ b/1c-analyst/references/architecture-patterns.md
@@ -0,0 +1,141 @@
+# Архитектурные паттерны 1С: выбор конфигурации и топологии
+
+---
+
+## 1. Выбор конфигурации
+
+### Матрица выбора
+
+| Критерий | КА 2.5 | ERP 2.5 | УТ 11 + Бухгалтерия |
+|----------|--------|---------|---------------------|
+| **Масштаб** | До 200 пользователей | 200+ пользователей | До 50 пользователей |
+| **Производство** | Простое (сборка, комплектация) | Полное (MRP, MES, попередельное, позаказное) | Нет |
+| **Бюджетирование** | Конструктор (без workflow) | Конструктор + бюджетный процесс (workflow) | Нет |
+| **Казначейство** | Полное | Полное | Нет |
+| **Управленческий учёт** | Полный (НД, ЦФО, фин.результат) | Полный + расширенный | Ограниченный |
+| **Зарплата** | Встроенная | Встроенная | Нет (отдельно ЗУП) |
+| **Стоимость лицензии** | Средняя | Высокая | Низкая |
+| **Сложность внедрения** | Средняя | Высокая | Низкая |
+
+### Когда КА 2.5
+
+- Компания 50-200 сотрудников, нужен единый контур: торговля + бухгалтерия + зарплата + бюджетирование
+- Производство простое или отсутствует
+- Нет потребности в MRP/MES
+- Бюджетный workflow не критичен (можно согласовывать через Битрикс24)
+- Типичные клиенты: ИТ-интеграторы, торговые компании, сервисные компании
+
+### Когда ERP 2.5
+
+- Производственное предприятие со сложным планированием
+- Нужен полный бюджетный процесс с маршрутами согласования внутри 1С
+- Масштаб 200+ пользователей
+- Требуется MRP (планирование потребности в материалах)
+- Типичные клиенты: заводы, крупные производства, холдинги
+
+### Когда УТ 11 + Бухгалтерия
+
+- Торговая компания, бюджетирование и управленческий учёт не нужны
+- Малый бизнес, до 50 пользователей
+- Минимальная стоимость внедрения
+- Зарплата — отдельно (ЗУП или аутсорсинг)
+
+---
+
+## 2. Однобазовая vs многобазовая архитектура
+
+### Однобазовая (одна информационная база)
+
+**Плюсы:**
+- Единая точка правды — нет проблем с синхронизацией
+- Проще администрирование
+- Проще разграничение доступа (RLS внутри одной базы)
+- Быстрее внедрение
+
+**Минусы:**
+- Риск «тяжёлой» базы при большом объёме данных
+- Все пользователи зависят от доступности одной базы
+- Регламентные операции (закрытие месяца) блокируют работу
+
+**Когда выбирать:** одно юрлицо или группа компаний с единой учётной политикой, до 200 пользователей.
+
+### Многобазовая (несколько информационных баз)
+
+**Типовые варианты:**
+- **По юрлицам:** каждое юрлицо в отдельной базе КА/ERP
+- **По функциям:** УТ (торговля) + Бухгалтерия (учёт) + ЗУП (зарплата)
+- **Гибрид:** КА (оперативный учёт) + отдельная БП для РСБУ/МСФО
+
+**Плюсы:**
+- Изоляция: проблемы в одной базе не влияют на другие
+- Параллельные регламентные операции
+- Проще обновление (можно обновлять по одной)
+
+**Минусы:**
+- Синхронизация НСИ — главная проблема
+- Дублирование данных, расхождения
+- Сложнее консолидированная отчётность
+- Выше стоимость сопровождения
+
+### Синхронизация НСИ между базами
+
+**Проблема:** при многобазовой архитектуре справочники (номенклатура, контрагенты, договоры, подразделения) должны быть согласованы.
+
+**Решения:**
+1. **Типовой обмен данными (РИБ)** — распределённая информационная база. Один мастер, все остальные подчинённые. Ограничения: только между одноимёнными конфигурациями.
+2. **Планы обмена + правила обмена (КД 2)** — Конвертация данных 2.0. Настраиваемые правила, работает между разными конфигурациями. Стандарт для связки «УТ ↔ Бухгалтерия».
+3. **EnterpriseData (КД 3)** — формат обмена на базе XML/JSON, более гибкий, но требует доработки для нетиповых объектов.
+4. **Внешняя шина (RabbitMQ, Kafka)** — для высоконагруженных сценариев с большим объёмом обменов. Избыточна для большинства SMB-проектов.
+
+**Рекомендация:** если нет жёсткой необходимости в разделении — однобазовая архитектура. Каждая дополнительная база = дополнительные затраты на синхронизацию × всю жизнь системы.
+
+---
+
+## 3. Интеграция 1С ↔ Битрикс24
+
+### Типовые сценарии
+
+| Процесс | Направление | Механизм |
+|---------|-------------|----------|
+| Лиды, сделки → заказы | Б24 → 1С | Модуль интеграции 1С-Битрикс24 (типовой) |
+| Контрагенты | Двусторонний | Синхронизация справочника |
+| Счета, оплаты | 1С → Б24 | Передача статусов по API |
+| Каталог товаров | 1С → Б24 | Выгрузка номенклатуры |
+| Документы (акты, счета) | 1С → Б24 | Присоединённые файлы по API |
+
+### Варианты интеграции
+
+1. **Типовой модуль «1С + Битрикс24»** — простейший вариант, ограниченный набор сущностей (контрагенты, заказы, счета, товары). Бесплатный, но негибкий.
+2. **REST API Битрикс24** — полный контроль, любые сущности. Требует разработки обработки/расширения в 1С. Рекомендуется для нетиповых сценариев.
+3. **Промежуточная шина (n8n, Apache Camel)** — для сложных трансформаций и маршрутизации. Оправдана при 5+ системах в ландшафте.
+
+### Разграничение ответственности
+
+**Правило:** «воронка продаж и клиентская работа — в Битрикс24, учёт и финансы — в 1С».
+
+| Область | Где ведётся | Что передаётся |
+|---------|-------------|----------------|
+| CRM, лиды, сделки | Битрикс24 | Реквизиты контрагента + параметры сделки → 1С |
+| Заказы покупателей | 1С | Факт формирования заказа ← из Б24 |
+| Выставление счетов | 1С | PDF счёта → в Б24 к сделке |
+| Оплата | 1С | Статус оплаты → в Б24 |
+| Отгрузка | 1С | Статус отгрузки → в Б24 |
+| Воронка, конверсия, LTV | Битрикс24 | — (не дублировать в 1С) |
+
+---
+
+## 4. Интеграция с внешними системами
+
+### ЭДО (СБИС, Диадок, 1С-ЭДО)
+- Типовая — через модуль «1С-ЭДО» (DirectBank-подобный протокол)
+- СБИС — через внешнюю обработку от вендора, уточнять версию и перечень документов
+- При экспертизе ТЗ: «установка модуля СБИС» — недостаточное описание, нужен перечень типов документов, версия модуля, объём настройки
+
+### Банки (DirectBank)
+- Типовой — протокол DirectBank, поддерживается большинством банков
+- При многобазовой архитектуре: подключать к каждой базе с учётом юрлица
+
+### Государственные системы
+- ФНС (электронная отчётность) — через типовые механизмы регламентированной отчётности
+- ФГИС (Меркурий, Честный ЗНАК, ЕГАИС) — через типовые подсистемы в КА/ERP
+- Специализированные (СКК РЖД, ГИСП и др.) — требуют индивидуальной оценки
diff --git a/1c-analyst/references/customization-catalog.md b/1c-analyst/references/customization-catalog.md
new file mode 100644
index 0000000..a67eb8c
--- /dev/null
+++ b/1c-analyst/references/customization-catalog.md
@@ -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С и плану
+- Создать описание доработки (для передачи клиенту / другому разработчику)
diff --git a/1c-analyst/references/erp25-capabilities.md b/1c-analyst/references/erp25-capabilities.md
new file mode 100644
index 0000000..1721103
--- /dev/null
+++ b/1c-analyst/references/erp25-capabilities.md
@@ -0,0 +1,96 @@
+# 1С:ERP 2.5 — Отличия от КА 2.5
+
+> Этот файл фокусируется ТОЛЬКО на отличиях. Общие механизмы (торговля, склад, бухгалтерия,
+> казначейство) — практически идентичны КА 2.5, см. `ka25-capabilities.md`.
+> **Всегда верифицировать через web search** — различия меняются между релизами.
+
+---
+
+## 1. Бюджетный процесс (главное отличие)
+
+В ERP 2.5 (в отличие от КА 2.5) есть подсистема **«Бюджетный процесс»**:
+- Маршруты формирования и согласования бюджетов
+- Монитор задач бюджетирования
+- Статусы экземпляров бюджетов (черновик, на согласовании, утверждён)
+- Автоматическое формирование задач ответственным
+
+Это ключевое преимущество ERP для компаний, которым нужен формализованный бюджетный цикл.
+
+---
+
+## 2. Производство (MRP, MES)
+
+### MRP — Планирование потребности в материалах
+
+- Расчёт потребности на основе плана производства и спецификаций
+- Формирование заказов поставщикам и производственных заказов
+- Учёт страхового запаса, минимальных партий
+
+### MES — Управление цеховым уровнем
+
+- Маршрутные карты (последовательность операций)
+- Планирование по рабочим центрам
+- Учёт выработки, нормы времени
+- Попередельное производство
+- Планирование по узким местам (TOC — Theory of Constraints)
+
+### Производственные подсистемы ERP vs КА
+
+| Функция | КА 2.5 | ERP 2.5 |
+|---------|--------|---------|
+| Спецификации | Да | Да (+ ресурсные спецификации) |
+| Заказ на производство | Да | Да (+ этапы, графики) |
+| MRP | Нет | Да |
+| MES / маршрутные карты | Нет | Да |
+| Попередельное производство | Нет | Да |
+| Планирование по рабочим центрам | Нет | Да |
+| Управление ремонтами (ТОИР) | Нет | Да (через доп. модуль) |
+
+---
+
+## 3. Управление данными об изделиях (PDM-элементы)
+
+ERP 2.5 поддерживает:
+- Версионирование спецификаций
+- Конструкторско-технологическая подготовка (КТП)
+- Альтернативные спецификации для одного изделия
+
+---
+
+## 4. Документооборот и согласование
+
+ERP 2.5 имеет расширенные механизмы:
+- Бизнес-процессы (типовые маршруты согласования)
+- Задачи с контролем сроков
+- Интеграция бизнес-процессов с документами учёта
+
+В КА 2.5 согласование ограничено заявками на ДС и некоторыми закупочными документами.
+
+---
+
+## 5. Управленческий учёт — расширения
+
+| Функция | КА 2.5 | ERP 2.5 |
+|---------|--------|---------|
+| Учёт по НД | Да | Да |
+| Директ-костинг | Да | Да |
+| Полный управленческий план счетов | Нет | Да (опционально) |
+| Фин. результат с распределением косвенных | Да | Да (+ расширенные базы) |
+| Управленческий баланс | Через бюджетирование | Через бюджетирование + план счетов |
+
+---
+
+## 6. Когда мигрировать с КА на ERP
+
+Миграция оправдана, если:
+1. Нужен полный MRP/MES (производственное планирование)
+2. Нужен формализованный бюджетный процесс (workflow)
+3. Масштаб перерос 200 пользователей
+4. Нужны бизнес-процессы с маршрутами согласования
+
+Миграция НЕ оправдана, если:
+1. Бюджетный workflow можно реализовать через Битрикс24
+2. Производство простое (сборка, комплектация)
+3. Нет потребности в MRP
+
+**Риск миграции:** стоимость лицензии ERP значительно выше, сложность внедрения выше, более длинный проект. Всегда считать TCO (Total Cost of Ownership) на 5 лет.
diff --git a/1c-analyst/references/ka25-capabilities.md b/1c-analyst/references/ka25-capabilities.md
new file mode 100644
index 0000000..f781af2
--- /dev/null
+++ b/1c-analyst/references/ka25-capabilities.md
@@ -0,0 +1,235 @@
+# 1С:Комплексная Автоматизация 2.5 — Типовые возможности
+
+> Справочник для gap-анализа. Для каждой подсистемы указаны типовые механизмы,
+> их ограничения и типичные доработки.
+> **Всегда верифицировать через web search** — механизмы меняются между релизами.
+
+---
+
+## Содержание
+
+1. [Финансовая структура и ЦФО](#1-финансовая-структура-и-цфо)
+2. [Управленческий учёт](#2-управленческий-учёт)
+3. [Казначейство](#3-казначейство)
+4. [Бюджетирование](#4-бюджетирование)
+5. [Управленческая отчётность](#5-управленческая-отчётность)
+6. [Проектный учёт](#6-проектный-учёт)
+7. [Торговля и склад](#7-торговля-и-склад)
+8. [Производство](#8-производство)
+9. [Зарплата и HR](#9-зарплата-и-hr)
+10. [Регламентированный учёт](#10-регламентированный-учёт)
+
+---
+
+## 1. Финансовая структура и ЦФО
+
+### Типовые механизмы
+
+| Объект | Путь в меню | Назначение |
+|--------|-------------|------------|
+| Структура предприятия | НСИ → Структура предприятия | Иерархический классификатор подразделений, не привязан к юрлицу |
+| Организации | НСИ → Организации | Юрлица, между которыми можно вести управленческий учёт |
+| Направления деятельности (НД) | НСИ → Направления деятельности | Сквозная аналитика: проект, вид бизнеса, направление |
+
+### Как настроить ЦФО
+
+В КА 2.5 **нет отдельного справочника ЦФО**. Роль ЦФО выполняет комбинация:
+- **Подразделение** (из «Структуры предприятия») — организационная единица
+- **НД** — вид деятельности / проект / бизнес-линия
+
+Тип ЦФО (центр прибыли, центр затрат, центр инвестиций) — методологическая надстройка. Типовой механизм не хранит тип ЦФО как реквизит.
+
+**Доработка (простая):** добавить доп. реквизит «Тип ЦФО» к элементам справочника «Структура предприятия» через механизм расширений.
+
+### Ограничения
+
+- Иерархия подразделений плоская в плане финансовой аналитики — нет встроенной консолидации «снизу вверх»
+- Один элемент НД = одна аналитика. Если нужно вести учёт одновременно по «проект + вид бизнеса» — нужны два измерения (НД для одного, подразделение для другого)
+
+---
+
+## 2. Управленческий учёт
+
+### Механизм учёта по направлениям деятельности
+
+Регистр накопления `ВыручкаИСебестоимостьПродаж` — основной источник данных. Содержит измерения:
+- Организация, Подразделение, НД
+- Номенклатура, Характеристика, Серия
+- Контрагент, Договор, Заказ
+
+**Что учитывается типовыми средствами:**
+- Выручка по НД (при оформлении реализации с указанием НД)
+- Прямая себестоимость продаж (по НД)
+- Валовая прибыль = Выручка − Себестоимость (по НД)
+- Коммерческие расходы (если привязаны к НД через статьи расходов)
+- Управленческие расходы — распределение через типовую «Базу распределения»
+
+### Директ-костинг
+
+Типовой. Прямые затраты относятся на НД при проведении документов (поступления, производство, зарплата). Косвенные — через документ «Распределение расходов на направления деятельности».
+
+Базы распределения (типовые): выручка, прямые затраты, фиксированные доли. Можно настроить произвольную базу через формулу.
+
+### Трансфертное ценообразование
+
+**НЕТ** в типовом решении. Между подразделениями одного юрлица нет механизма «внутренней продажи». Есть только между организациями (документ «Передача между организациями»).
+
+**Доработка (сложная):** если требуется трансфертное ценообразование между ЦФО одного юрлица — нужен механизм внутренних актов с виртуальными проводками по управленческому плану счетов.
+
+---
+
+## 3. Казначейство
+
+### Типовые механизмы
+
+| Механизм | Описание | Оценка |
+|----------|----------|--------|
+| Заявки на расходование ДС | Документ с маршрутом согласования, статусами, лимитами | Типовое |
+| Платёжный календарь | Визуальное отображение план/факт ДС по дням | Типовое |
+| Реестры платежей | Группировка заявок для массовой оплаты | Типовое |
+| Контроль лимитов | Блокировка заявок при превышении бюджета | Типовое |
+| Согласование заявок | Маршруты согласования (N уровней) | Типовое |
+| Расчётные счета и кассы | Справочники с привязкой к организациям | Типовое |
+| Контроль взаиморасчётов | По контрагентам и договорам | Типовое |
+| Aging дебиторской задолженности | Типового отчёта нет | Простая доработка |
+
+### Ограничения
+
+- Маршруты согласования заявок — без визуального конструктора, настраиваются через «Настройки согласования»
+- Автоматическое формирование платёжных поручений из реестра — типовое, но требует настройки правил заполнения
+- Мультивалютный платёжный календарь — типовой, но курсы нужно актуализировать
+
+---
+
+## 4. Бюджетирование
+
+### Архитектура
+
+Подсистема бюджетирования КА 2.5 — **конструктор**, а не готовое решение. Из коробки нет готовых БДР/БДДС — всё настраивается.
+
+**Ключевые объекты:**
+- **Модель бюджетирования** — верхний уровень (обычно одна на компанию)
+- **Вид бюджета** — конкретный бюджет (БДР, БДДС, бюджет закупок и т.д.)
+- **Статья бюджета** — строка бюджета с аналитиками (до 6 произвольных)
+- **Показатель бюджета** — расчётная величина (ДС на конец периода, ДЗ, и т.д.)
+- **Экземпляр бюджета** — документ ввода плановых данных
+- **Сценарий** — версия плана (оптимистичный, пессимистичный, факт)
+
+### Что типовое
+
+| Функция | Оценка | Комментарий |
+|---------|--------|-------------|
+| БДР | Типовое | Настраивается как вид бюджета со статьями доходов/расходов |
+| БДДС | Типовое | Привязка к хозяйственным операциям казначейства |
+| ББЛ (управленческий баланс) | Типовое | Через показатели бюджетов и связи |
+| Бюджеты по ЦФО | Типовое | Аналитика «Подразделение» в статьях |
+| План-факт анализ | Типовое | 3 источника факта: оперативный, регламентированный, СКД |
+| Контроль перерасхода ДС | Типовое | Лимиты по данным бюджетирования |
+| Контроль не-ДС статей | Сложная доработка | Подписки на события при проведении документов |
+| Бюджетный процесс (workflow) | **Отсутствует** | Есть только в ERP 2.5 |
+
+### Аналитики статей бюджета
+
+Каждая статья поддерживает до 6 аналитик из предустановленного каталога (~30 видов):
+- Подразделение, Направление деятельности, Организация
+- Номенклатура, Контрагент, Договор
+- Статья ДДС, Валюта, Банковский счёт
+- И другие
+
+### Источники фактических данных
+
+Три типа для автоматического сбора факта:
+1. **Оперативный учёт** — данные из регистров накопления (выручка, затраты, ДС)
+2. **Регламентированный учёт** — обороты по счетам бухгалтерского учёта
+3. **Произвольные запросы** — СКД-запросы к любым данным
+
+---
+
+## 5. Управленческая отчётность
+
+### Типовые отчёты
+
+| Отчёт | Раздел | Аналитики |
+|-------|--------|-----------|
+| Доходы и расходы | Финансовый результат | НД, подразделение, организация |
+| Финансовый результат | Финансовый результат | НД, организация |
+| Валовая прибыль | Продажи | Подразделение, клиент, менеджер, сделка, номенклатура |
+| Бюджетные отчёты | Бюджетирование | По настройке вида бюджета |
+| Движение ДС | Казначейство | Статья ДДС, расчётный счёт, организация |
+
+### Что нужно дорабатывать
+
+| Отчёт | Сложность доработки |
+|-------|---------------------|
+| EBITDA | Простая — внешний отчёт по данным регистра «Доходы и расходы» |
+| Aging ДЗ (просроченная задолженность по периодам) | Простая — внешний отчёт по регистру взаиморасчётов |
+| P&L по проектам с менеджерской рентабельностью | Простая — внешний отчёт по НД + поле «Менеджер» |
+| Утилизация инженеров (% времени на проектах) | Сложная — нет таймшитов, нужен новый документ и регистр |
+| Консолидированная отчётность (элиминация ВГО) | Сложная — только при многобазовой архитектуре или нескольких организациях |
+
+---
+
+## 6. Проектный учёт
+
+### Типовой механизм
+
+**Направление деятельности = Проект.** Элемент НД создаётся для каждого проекта. Все доходы и расходы проходят с указанием НД-проекта.
+
+**Что отслеживается типовыми средствами:**
+- Выручка проекта (реализации с НД)
+- Прямые затраты (закупки, субподряд, ФОТ — если привязаны к НД)
+- Себестоимость продаж проекта
+- Рентабельность проекта (валовая прибыль / выручка)
+
+**Что НЕ отслеживается:**
+- Трудозатраты по проекту (таймшиты) — нет механизма
+- Этапы / вехи проекта — нет Gantt, нет WBS
+- Бюджет проекта (план/факт) — только через подсистему бюджетирования с аналитикой НД
+
+### Рекомендация
+
+Для полноценного управления проектами интегрировать с внешней системой (Битрикс24, MS Project, Wrike) и использовать 1С только для финансовой аналитики проекта.
+
+---
+
+## 7. Торговля и склад
+
+Подсистема торговли в КА 2.5 аналогична 1С:УТ 11. Типовые механизмы:
+- Заказы покупателей / поставщикам
+- Ценообразование (виды цен, формулы, скидки)
+- Складской учёт (ордерный и неордерный)
+- Серийный учёт, характеристики, упаковки
+- Партионный учёт (FIFO, LIFO, по средней, по партиям)
+- Резервирование
+
+---
+
+## 8. Производство
+
+Простое производство: сборка, комплектация, разборка. Спецификации, производственные заказы.
+
+**Нет в КА 2.5 (есть в ERP 2.5):**
+- MRP (планирование потребности в материалах)
+- MES (управление цехом, маршрутные карты)
+- Попередельное производство
+- Планирование по узким местам (TOC)
+
+---
+
+## 9. Зарплата и HR
+
+Встроенная подсистема, аналогичная ЗУП 3 (с некоторыми ограничениями). Включает:
+- Кадровый учёт, штатное расписание
+- Начисление зарплаты, НДФЛ, страховые взносы
+- Табельный учёт
+- Отпуска, больничные, командировки
+
+---
+
+## 10. Регламентированный учёт
+
+Полноценный бухгалтерский и налоговый учёт:
+- План счетов РСБУ
+- Регламентированная отчётность (ФНС, ПФР, ФСС)
+- Учёт основных средств, НМА
+- Закрытие месяца (типовой помощник)
diff --git a/1c-analyst/references/migration-plan.md b/1c-analyst/references/migration-plan.md
new file mode 100644
index 0000000..00b4565
--- /dev/null
+++ b/1c-analyst/references/migration-plan.md
@@ -0,0 +1,143 @@
+# Шаблон плана миграции между конфигурациями 1С
+
+> Используется при переходе УПП→ERP, КА→ERP, БП→КА и других миграциях.
+> Каждый раздел — обязательный. Пустых разделов быть не должно.
+
+---
+
+## 1. Общие сведения
+
+- Исходная конфигурация: [название, версия, платформа]
+- Целевая конфигурация: [название, версия, платформа]
+- Количество пользователей: [число]
+- Объём базы: [размер файла .dt или SQL]
+- Целевая дата перехода: [дата]
+- Стратегия перехода: [Big Bang / Поэтапная / Параллельная]
+
+---
+
+## 2. Перечень объектов переноса
+
+Для каждого объекта:
+
+| № | Тип объекта | Объект | Кол-во записей | Источник (объект в старой базе) | Приёмник (объект в новой базе) | Правила маппинга | Ответственный | Статус |
+|---|-------------|--------|----------------|-------------------------------|-------------------------------|------------------|---------------|--------|
+
+### Обязательные категории:
+
+**Справочники (НСИ):**
+- Номенклатура (+ характеристики, серии, упаковки, ценовые группы)
+- Контрагенты (+ договоры, банковские реквизиты)
+- Организации (+ учётные политики)
+- Подразделения / Структура предприятия
+- Склады
+- Сотрудники / физические лица
+- Основные средства
+- Статьи расходов / статьи ДДС
+- Направления деятельности (если есть)
+
+**Остатки (на дату отсечки):**
+- Остатки ТМЦ на складах
+- Взаиморасчёты с контрагентами (ДЗ + КЗ)
+- Остатки ДС (банк + касса)
+- Авансы выданные и полученные
+- Основные средства (первоначальная стоимость, амортизация)
+- НМА
+- Остатки незавершённого производства
+- Остатки по расчётам с сотрудниками (задолженность по зарплате, отпускам)
+- Сальдо по налоговым регистрам
+
+**Документы (опционально):**
+- Открытые заказы покупателей / поставщикам
+- Незакрытые договоры
+- Текущие производственные заказы
+
+---
+
+## 3. Нормализация НСИ
+
+### Номенклатура
+- Количество элементов в источнике: [число]
+- Количество дубликатов (оценка): [число]
+- Стратегия нормализации: [автоматическая + ручная ревизия / только ручная]
+- Правила кодификации в новой системе: [описание]
+- Ответственный за ревизию: [ФИО, должность]
+
+### Контрагенты
+- Проверка по ИНН/КПП на дубли
+- Актуализация реквизитов через ФНС API
+- Пометка недействующих контрагентов
+
+### Общие правила
+- Элементы, помеченные на удаление — переносить? [да / нет]
+- Группы (папки) справочников — переносить структуру? [да / нет / пересмотреть]
+- Предопределённые элементы — маппинг один к одному
+- Дополнительные реквизиты и сведения — перечень для переноса
+
+---
+
+## 4. График миграции
+
+| Этап | Описание | Дата начала | Дата окончания | Ответственный |
+|------|----------|-------------|----------------|---------------|
+| Подготовка правил переноса | Настройка КД 2/3, тестовая выгрузка | | | |
+| Нормализация НСИ | Ревизия справочников, удаление дублей | | | |
+| Тестовый прогон №1 | Полный перенос в тестовую базу | | | |
+| Верификация прогона №1 | Сверка остатков, проверка целостности | | | |
+| Исправление ошибок | Доработка правил по результатам прогона | | | |
+| Тестовый прогон №2 | Повторный полный перенос | | | |
+| Верификация прогона №2 | Финальная сверка | | | |
+| Фиксация даты отсечки | Прекращение операций в старой базе | | | |
+| Боевой перенос | Перенос данных на дату отсечки | | | |
+| Верификация боевого переноса | Сверка остатков с бухгалтерией | | | |
+| Начало работы в новой базе | Ввод документов в новой системе | | | |
+
+---
+
+## 5. Переходный период
+
+- Период параллельной эксплуатации: [дней/месяцев]
+- Какие операции ведутся в старой базе во время перехода: [перечень]
+- Какие операции ведутся в новой базе: [перечень]
+- Механизм синхронизации данных в переходный период: [описание или «не предусмотрен»]
+- Порядок закрытия месяца в переходный период: [в какой базе, как]
+
+---
+
+## 6. Критерии качества миграции
+
+| Объект | Критерий | Допустимое отклонение |
+|--------|----------|----------------------|
+| Остатки ТМЦ | Совпадение количества и суммы по каждому складу | 0% |
+| Взаиморасчёты | Совпадение сальдо по каждому контрагенту/договору | 0 руб. |
+| Остатки ДС | Совпадение с банковскими выписками | 0 руб. |
+| ОС | Совпадение первоначальной стоимости и накопленной амортизации | 0% |
+| Справочники | Все активные элементы перенесены, нет потерь данных | 100% |
+| Открытые заказы | Все незакрытые заказы перенесены с корректными статусами | 100% |
+
+---
+
+## 7. План отката
+
+- Точка невозврата: [описание — после какого действия откат невозможен/нецелесообразен]
+- Действия при неуспешной миграции:
+  1. Возврат к работе в старой базе
+  2. Анализ причин сбоя
+  3. Повторная миграция по исправленным правилам
+- Максимальное время на принятие решения об откате: [часов]
+- Ответственный за принятие решения: [ФИО, должность]
+
+---
+
+## 8. Ресурсная модель
+
+| Роль | Количество | Период занятости |
+|------|-----------|------------------|
+| Руководитель проекта (Заказчик) | | |
+| Руководитель проекта (Исполнитель) | | |
+| Консультант-аналитик 1С | | |
+| Разработчик 1С | | |
+| Администратор БД | | |
+| Ключевые пользователи (бухгалтерия) | | |
+| Ключевые пользователи (склад) | | |
+| Ключевые пользователи (производство) | | |
diff --git a/1c-analyst/references/tz-review-checklist.md b/1c-analyst/references/tz-review-checklist.md
new file mode 100644
index 0000000..4ac819e
--- /dev/null
+++ b/1c-analyst/references/tz-review-checklist.md
@@ -0,0 +1,107 @@
+# Чек-лист экспертизы ТЗ на внедрение / миграцию 1С
+
+> Использовать при рецензировании ТЗ, Концепций проекта, ЧТЗ.
+> Каждый пункт — потенциальное замечание. Если ответ «нет» или «неясно» — фиксировать в отчёте.
+
+---
+
+## 1. Общая структура и полнота
+
+- [ ] Описано текущее состояние (AS-IS) по каждому функциональному блоку?
+- [ ] Описано целевое состояние (TO-BE) с конкретными требованиями, а не намерениями?
+- [ ] Требования детализированы до уровня, достаточного для оценки трудозатрат Исполнителем?
+- [ ] Нет массовых отсылок «будет уточнено в ЧТЗ/на этапе проектирования» без базовых параметров?
+- [ ] Для каждого требования указан приоритет (MoSCoW или аналог)?
+- [ ] Определены границы проекта (что НЕ входит в скоуп)?
+
+## 2. Измеримые критерии успешности
+
+- [ ] Определены KPI проекта (не «повышение эффективности», а конкретные метрики)?
+- [ ] Для каждого KPI указан способ измерения и целевое значение?
+- [ ] Определены критерии приёмки для каждого этапа?
+- [ ] Описана процедура приёмочных испытаний?
+
+## 3. Миграция данных
+
+- [ ] Определён перечень объектов переноса (справочники, остатки, документы)?
+- [ ] Для каждого объекта указан источник, приёмник, правила маппинга?
+- [ ] Определена стратегия нормализации НСИ (дубли, устаревшие элементы, кодификация)?
+- [ ] Указан объём данных (количество элементов справочников, документов)?
+- [ ] Определена дата отсечки для переноса остатков?
+- [ ] Определены ответственные за подготовку данных со стороны Заказчика?
+- [ ] Запланированы тестовые прогоны миграции (минимум 2)?
+- [ ] Определены критерии качества миграции (допустимый % расхождений)?
+- [ ] Описана процедура верификации перенесённых данных?
+- [ ] Есть план отката в случае неуспешной миграции?
+
+## 4. Переходный период
+
+- [ ] Описан режим работы предприятия в переходный период для каждого блока?
+- [ ] Определён период параллельной эксплуатации (старая + новая система)?
+- [ ] Описано, как предприятие будет работать, если блоки 2-й очереди ещё не внедрены?
+- [ ] Определена стратегия перехода: Big Bang / поэтапная / параллельная?
+
+## 5. Нефункциональные требования
+
+- [ ] Требования к производительности (время формирования ключевых отчётов, одновременные пользователи)?
+- [ ] Требования к доступности (RTO, RPO, режим работы)?
+- [ ] Требования к масштабируемости (рост пользователей, объёма данных)?
+- [ ] Требования к информационной безопасности (роли, RLS, журналирование)?
+- [ ] Требования к резервному копированию?
+- [ ] Архитектура серверов (1С:Предприятие, СУБД, веб-сервер, терминальный сервер)?
+
+## 6. Управление изменениями
+
+- [ ] Определена процедура Change Request (оценка влияния на сроки и бюджет)?
+- [ ] Описан процесс согласования изменений в скоупе?
+- [ ] Указано, кто имеет право инициировать и утверждать изменения?
+- [ ] Определён порядок пересмотра стоимости при изменении объёма работ?
+
+## 7. Обучение и оргизменения
+
+- [ ] Определено количество пользователей по ролям и функциональным блокам?
+- [ ] Описана программа обучения с достаточным объёмом часов?
+- [ ] Определены ключевые пользователи (key users) и их роль в проекте?
+- [ ] Описана стратегия организационных изменений (OCM)?
+- [ ] Предусмотрено освобождение key users от основных обязанностей на период проекта?
+- [ ] Определены требования к пользовательской документации?
+
+## 8. Риски
+
+- [ ] Описаны риски ОБЕИХ сторон (не только Заказчика)?
+- [ ] Для каждого риска определена вероятность, влияние, мера реагирования?
+- [ ] Рассмотрены: текучесть команды Исполнителя, ошибки проектирования, недостаточная экспертиза в отрасли?
+- [ ] Рассмотрены: сопротивление персонала, неготовность данных, задержки согласований?
+
+## 9. План-график и ресурсная модель
+
+- [ ] Сроки этапов реалистичны (особенно обучение и опытная эксплуатация)?
+- [ ] Определён состав команды проекта (обе стороны)?
+- [ ] Указаны требования к квалификации участников?
+- [ ] Есть буфер на непредвиденные работы (обычно 15-20%)?
+- [ ] Определено гарантийное сопровождение после приёмки?
+
+## 10. Интеграции
+
+- [ ] Для каждой интеграции определены: протокол, формат, сценарии обмена, обработка конфликтов?
+- [ ] Интеграции не описаны «одной строкой» типа «установка модуля от вендора»?
+- [ ] Определена ответственность за интеграционные модули (кто разрабатывает, тестирует, поддерживает)?
+- [ ] Рассмотрена синхронизация справочников между интегрируемыми системами?
+
+## 11. Разделение на очереди
+
+- [ ] Обоснован порядок очерёдности (почему именно эти блоки в 1-й очереди)?
+- [ ] Для каждой очереди определён самодостаточный набор функций?
+- [ ] Описана работоспособность предприятия на каждом промежуточном этапе?
+- [ ] Зависимости между очередями явно указаны?
+
+---
+
+## Формат замечания в отчёте
+
+Для каждого замечания указывать:
+1. **Раздел/пункт ТЗ** — где обнаружен недостаток
+2. **Суть замечания** — что не так (коротко и конкретно)
+3. **Влияние** — к чему приведёт, если не исправить
+4. **Рекомендация** — что конкретно нужно добавить/изменить
+5. **Критичность** — Критическое / Существенное / Рекомендательное
diff --git a/1c-analyst/templates/questionnaire-structure.md b/1c-analyst/templates/questionnaire-structure.md
new file mode 100644
index 0000000..5288e3b
--- /dev/null
+++ b/1c-analyst/templates/questionnaire-structure.md
@@ -0,0 +1,119 @@
+# Структура предпроектной анкеты для внедрения 1С
+
+> Адаптировать под конкретного клиента: убирать неактуальные разделы,
+> добавлять отраслевую специфику.
+
+---
+
+## Принципы составления анкеты
+
+1. **Вступление с инструкцией** — объяснить, зачем анкета, как заполнять, дедлайн
+2. **Таблица респондентов** — ФИО, должность, контакты, какой раздел заполнял
+3. **От общего к частному** — сначала общие сведения, потом детали по процессам
+4. **Таблицы для заполнения** — не свободный текст, а структурированные формы
+5. **Подсказки** — в скобках давать примеры ответов, чтобы респондент понимал ожидания
+6. **Запрос документов** — если нужны регламенты, учётная политика, штатка — просить приложить
+
+---
+
+## Типовая структура
+
+### Раздел 1: Общие сведения о компании
+
+- Полное наименование, ИНН, юрлица
+- Год основания, основные виды деятельности
+- Количество сотрудников (общее, в офисе, на производстве/объектах)
+- География (головной офис, филиалы, обособленные подразделения)
+- Основные заказчики / клиенты (государственные, коммерческие, категории)
+- Среднее количество одновременно выполняемых проектов/заказов
+- Особенности ценообразования (сметы, спецификации, каталожные цены, ВДЦ)
+
+### Раздел 2: Организационная структура и регламенты
+
+**2.1. Организационная структура:**
+- Схема организационной структуры (приложить или описать)
+- Ключевые подразделения и их руководители
+- Проектная структура (если есть): как формируются проектные команды
+
+**2.2. Действующие регламенты:**
+Просить приложить (если есть):
+- Учётная политика для целей бухгалтерского и налогового учёта
+- Положение о казначейском контроле
+- Положение о договорной работе
+- Положение о бюджетировании
+- Положение о системе управленческого учёта
+- Должностные инструкции ключевых позиций
+
+**Подсказка для респондента:** «Если документ не утверждён или не существует — укажите "отсутствует". Можно выгрузить штатное расписание из ЗУП без зарплат.»
+
+### Раздел 3: ИТ-ландшафт
+
+**3.1. ИТ-персонал:**
+- Количество ИТ-специалистов
+- Специализация/квалификация (администрирование 1С, разработка 1С, системное администрирование)
+
+**3.2. Используемое ПО:**
+
+| Категория | Программное обеспечение | Версия | Кол-во пользователей | Примечания |
+|-----------|------------------------|--------|---------------------|------------|
+| ERP / Бухгалтерия | (1С:Бухгалтерия, КА, ERP, УПП, УТ...) | | | |
+| Зарплата | (1С:ЗУП, встроенная в КА/ERP...) | | | |
+| CRM | (Битрикс24, amoCRM...) | | | |
+| Управление проектами | (MS Project, Битрикс24, Excel...) | | | |
+| Документооборот | (1С:ДО, Битрикс24, Directum...) | | | |
+| Сметное ПО | (Гранд-Смета, Смета.ру...) | | | |
+| CAD/BIM | (AutoCAD, Revit...) | | | |
+| Другое | | | | |
+
+**3.3. Инфраструктура 1С (если 1С уже используется):**
+- Версия платформы 1С:Предприятие
+- Конфигурация и версия
+- Режим работы: файловый / клиент-серверный
+- СУБД: MS SQL / PostgreSQL / другая
+- Количество одновременных пользователей
+- Были ли доработки типовой конфигурации? Какие? Документированы ли?
+- Используется ли обмен данными между базами? Какой?
+
+### Раздел 4-N: По каждой предметной области в скоупе
+
+Адаптировать под конкретный проект. Примеры блоков:
+
+**Управление проектами:**
+- Как ведётся планирование проекта (график, вехи)?
+- Как контролируется бюджет проекта?
+- Как учитываются трудозатраты?
+- Кто принимает решения по проекту?
+
+**Управление договорами (заказчики):**
+- Жизненный цикл договора: от конкурса/запроса до закрытия
+- Как формируется цена контракта?
+- Этапность работ по договору
+- Кто согласует и подписывает?
+
+**Управление договорами (поставщики/субподряд):**
+- Как выбираются поставщики/субподрядчики?
+- Процедура закупки (запрос предложений, тендер, прямая закупка)
+- Контроль исполнения (сроки, качество, акты)
+
+**Бухгалтерский учёт:**
+- Основные участки учёта (ОС, ТМЦ, касса, банк, зарплата)
+- Объём документооборота (документов в месяц по типам)
+- Проблемные области в текущем учёте
+
+**Казначейство:**
+- Как согласуются платежи?
+- Есть ли лимиты на расходы?
+- Количество расчётных счетов
+
+**Бюджетирование (если есть):**
+- Какие бюджеты формируются?
+- Периодичность (месяц, квартал, год)
+- Кто формирует, кто утверждает?
+
+### Финальный раздел: Требования и ожидания
+
+- Какие проблемы вы хотите решить в первую очередь?
+- Какие отчёты критичны для принятия решений?
+- Сроки реализации проекта (ожидания)
+- Бюджет проекта (порядок: до 1 млн / 1-3 млн / 3-10 млн / 10+ млн)
+- Готовность к изменениям бизнес-процессов (готовы адаптировать процессы под типовую систему / хотят сохранить текущие процессы / готовы к компромиссу)