Claude
e125973962
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).
108 lines
8.5 KiB
Markdown
108 lines
8.5 KiB
Markdown
# Чек-лист экспертизы ТЗ на внедрение / миграцию 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. **Критичность** — Критическое / Существенное / Рекомендательное
|