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