Версия платформы — лишь один слой информационной системы. На результат влияют конфигурация, режим совместимости, расширения, внешние обработки, оборудование, интеграции, права пользователей и регламентные задания.
Главный критерий готовности: критичные операции выполняются в тестовой копии базы после обновления, а их результаты проверены владельцами процессов. Успешный запуск программы и новый интерфейс сами по себе не подтверждают готовность к промышленной эксплуатации.
Для ERP, КА и УТ порядок перехода следует сверять с официальной документацией 1С для конкретных релизов. Не переносите условия этих решений автоматически на «1С:Бухгалтерию», «1С:ЗУП» и отраслевые конфигурации.
1Составьте паспорт текущей базы
Перед пилотом зафиксируйте исходное состояние:
- точная версия платформы и конфигурации;
- режим совместимости;
- активные расширения, внешние отчёты и обработки;
- оборудование и версии драйверов;
- обмены с банком, ЭДО, сайтом, складом, кассами и маркировкой;
- регламентные задания и их расписание;
- роли, права и группы доступа;
- дата резервной копии и подтверждение возможности восстановления.
Назначьте владельцев критичных сценариев: бухгалтерия проверяет закрытие месяца и отчётность, кадровая служба — кадровые и зарплатные операции, логистика — складские процессы, ИТ — платформу, интеграции и восстановление. Один технический специалист не должен подтверждать корректность всех бизнес-результатов.
2Подготовьте безопасный тестовый контур
1. Используйте копию рабочей базы
Создайте копию с репрезентативными данными. Исключите реальные отправки писем, чеков, ЭДО и сообщений во внешние системы. При необходимости обезличьте данные и ограничьте доступ к копии.
2. Зафиксируйте последовательность обновления
Запишите версии платформы, конфигурации, расширений и внешних компонентов до и после изменения. Последовательность обновления определяйте по документации соответствующего релиза и рекомендациям сопровождающего специалиста.
3. Проверьте восстановление
Сохраните резервную копию и выполните пробное восстановление. Зафиксируйте место хранения, ответственного, требуемую инфраструктуру, длительность восстановления и допустимую потерю данных. Важно понимать, что откат может потребовать возврата не только базы, но и связанных компонентов.
4. Разделите технические и пользовательские тесты
ИТ-специалист проверяет запуск, сервер, журнал регистрации и обмены. Владельцы процессов проверяют документы, движения, отчёты, расчёты и права доступа.
3Матрица тестов перед рабочим переходом
| Блок | Что проверить | Доказательство |
|---|---|---|
| Вход и права | Вход под рабочими ролями, отсутствие лишних доступов | Протокол и снимки экрана |
| Продажи | Заказ, реализация, возврат, корректировка, печатная форма | Документы и сравнение движений |
| Закупки | Заказ, поступление, возврат, дополнительные расходы | Документы и контрольный отчёт |
| Склад | Перемещение, инвентаризация, резерв, серии и характеристики | Остатки и обороты |
| Казначейство | Платёж, загрузка выписки, распределение оплаты | Протокол обмена и обороты |
| Учёт | Проводки, закрытие периода, ОСВ | Сравнение контрольных отчётов |
| Отчётность | Формирование форм без реальной отправки | Тестовые экземпляры и контрольные соотношения |
| Интеграции | Безопасный цикл каждого критичного обмена | Журнал обмена |
| Производительность | Открытие ключевых форм, тяжёлые отчёты | Замеры на одинаковых данных |
Для каждого теста отдельно запишите исходные данные, ожидаемый и фактический результат, ответственного, критичность и ссылку на подтверждение. Не ограничивайтесь проверкой внешнего вида формы.
4Что проверить в интерфейсе 8.5
- Находят ли пользователи основные команды и действия без обходных решений?
- Работают ли сценарии на используемых разрешениях экрана и в веб-клиенте, если он применяется?
- Доступны ли предупреждения, отборы, команды расширений и необходимые элементы управления?
Замечание оформляйте по схеме: роль — форма — действие — ожидаемый результат — фактический результат — подтверждение — критичность. Такая запись позволяет воспроизвести проблему.
5Расширения, обработки и интеграции
Для каждого доработанного компонента укажите версию, назначение, владельца и тестовый сценарий. Для оборудования сохраните сведения о драйверах, для интеграций — настройки тестовых контуров и учётные записи.
Если компонент не проверен, его статус — «не проверено», а не «совместимо». Для критичных компонентов отсутствие проверки должно учитываться при решении о запуске.
6Критерии допуска в рабочую среду
- Все критичные сценарии пройдены без блокирующих ошибок.
- Контрольные отчёты совпали либо различия документально объяснены.
- Интеграции и оборудование проверены.
- Роли и права подтверждены владельцами процессов.
- Резервная копия восстановлена в тесте, план отката согласован.
- Пользователи получили инструкцию по изменившейся навигации.
- Определены окно перехода и команда поддержки.
Некритичные замечания можно перенести в план исправлений с ответственным и сроком. Непроверенные операции закрытия месяца, расчёта зарплаты, отчётности, касс и маркировки — основание отложить запуск.
7Практический шаблон протокола пилота
| Поле | Что указать |
|---|---|
| Тестовый контур | Дата копии и расположение |
| Платформа до / после | Полные номера версий |
| Конфигурация до / после | Название и релизы |
| Режим совместимости | Фактическое значение |
| Расширения и интеграции | Список и результаты проверки |
| Критичные сценарии | Перечень и ссылки на протоколы |
| Блокирующие ошибки | Описание, владелец и статус |
| Восстановление копии | Результат и время |
| Решение | Допустить / повторить тест / отложить переход |
| Ответственные | Владельцы процессов и дата согласования |
8Типичные ошибки при переходе
- Обновлять сразу рабочую базу без пилота.
- Считать успешный запуск подтверждением корректности учёта.
- Не проверять расширения и внешние компоненты.
- Выполнять реальные отправки из тестовой копии.
- Хранить резервную копию без проверки восстановления.
- Сравнивать результаты на разных наборах исходных данных.
- Запускать работу при незакрытых критичных замечаниях.
9Итог
Переход на «1С:Предприятие 8.5» следует организовать как управляемое изменение. Сначала зафиксируйте состояние базы, затем разверните безопасную копию, проверьте критичные сценарии, обмены, права и восстановление. Решение о рабочем переходе принимайте по подтверждённым результатам тестов, а даты и условия обновления сверяйте с документацией конкретной конфигурации и релиза.
