Проверили свою же 1С и получили 55 из 100: что показывает диагностика базы
29 августа 2026 · 8 минут
Диагностика базы звучит как процедура для тех, у кого всё сломалось. На деле чаще наоборот: базу смотрят, когда она работает — просто медленнее, чем раньше, и с ощущением, что где-то что-то подтекает. Мы решили показать, что именно видно со стороны. Взяли два настоящих отчёта: обезличенный клиентский и свой собственный, по базе, в которой работает команда iTeal. У обоих индекс здоровья вышел одинаковый — 55 из 100.
Зачем смотреть на базу, если она работает
Учётная система редко ломается целиком. Она деградирует по частям, и каждая часть по отдельности выглядит терпимо: бухгалтер руками разносит десяток платежей, менеджер заводит контрагента заново, потому что поиск не нашёл существующего, программист получает полные права «на время внедрения» и остаётся с ними на два года. Каждое из этих событий — мелочь. Вместе они складываются в состояние, когда система формально работает, а доверия к её цифрам нет.
Диагностика — это замер, а не поиск виноватых. Мы разбираем копию базы: конфигурацию и платформу, журнал регистрации, регламентные задания, обмены, права доступа, качество справочников. На выходе — отчёт с находками, оценкой и планом работ. Сотрудники в это время продолжают работать: копия снимается один раз, дальше мы работаем с ней.
Из чего складывается индекс здоровья
Чтобы результат можно было сравнивать — с прошлым замером, с другой базой, с состоянием после работ, — мы приводим оценку к одному числу. Индекс здоровья считается по девяти критериям с весами: у каждого своя оценка от 1 до 5, итог приводится к шкале от 0 до 100%. Ниже 35% — критично, до 75% — требует внимания, выше — норма.
Самый тяжёлый вес — у стабильности работы (20%), затем идут актуальность платформы и качество данных (по 15%). Это не абстрактная методика: критерии подобраны так, чтобы результат совпадал с тем, что чувствуют люди за экраном. База с чистыми справочниками и пустым журналом ошибок действительно кажется быстрой, даже если она большая.
Первый отчёт: 946 дублей, из-за которых не грузились выписки
Клиентская база: 1С:Бухгалтерия КОРП, группа компаний из трёх ООО и двух ИП, 79 пользователей, 73 тысячи поступлений на расчётный счёт за период. Обращение было сформулировано мягко: «бухгалтерия жалуется, что стало неудобно».
В журнале регистрации за 28 дней — 200 ошибок, и 109 из них об одном и том же: не грузятся банковские выписки. При загрузке система пытается создать контрагента или банковский счёт, операция падает, платёж остаётся без привязки. Дальше бухгалтер разносит его руками — каждый день, по несколько платежей, и давно считает это нормальной частью работы.
Причина обнаружилась в справочнике. В базе 25 923 контрагента, из них уникальных записей с корректным ИНН — 563. Остальные либо без ИНН, либо участвуют в дублях: 946 номеров ИНН встречаются по нескольку раз, у одного контрагента нашлось 15 карточек. Автоматическое сопоставление в такой ситуации не работает — система не может выбрать, к какой из пятнадцати карточек привязать платёж.
Здесь важна связка, ради которой диагностика и делается: жалоба была про «неудобно», ошибка — про выписки, а причина — в справочнике контрагентов. Чинить по симптому бесполезно: можно сколько угодно перенастраивать обмен с банком, пока в базе пятнадцать одинаковых карточек.
Второй отчёт: наш собственный, и он не лучше
В июле мы прогнали ту же процедуру на своей базе — 1С:ERP с модулем CRM, в ней живёт поддержка, обращения клиентов и учёт команды. Результат: те же 55%.
За неделю в журнале — 14 806 ошибок. Цифра выглядит катастрофой ровно до момента, когда смотришь на источники: 98% приходятся на три штуки, и главный из них — конфликт настроек интеграции с мессенджером. У служебного бота одновременно был включён приём событий двумя способами, которые друг друга исключают, и регламентное задание падало каждые несколько секунд. Около десяти тысяч записей об ошибках в неделю из-за одной галочки, которую снимают за час.
Дальше — то, что мы регулярно находим у других и спокойно нашли у себя. Полные права у 33 пользователей из 132 — каждый четвёртый мог менять что угодно, включая закрытые периоды. Дата запрета изменения стояла на январе 2025 года, при том что месяцы закрывались вплоть до мая 2026: полтора года закрытых периодов были открыты для правок задним числом. Настройка занимает час, а риск закрывает существенный — вплоть до расхождения с уже сданной отчётностью.
Публиковать собственный отчёт немного неловко, и именно поэтому мы его показываем. 55% — это не приговор и не редкость. Это обычное состояние живой базы, в которой несколько лет работали люди, что-то настраивали, что-то не доводили до конца. Разница между компаниями не в том, у кого чисто, а в том, кто знает свои цифры.
Пять находок, которые повторяются почти всегда
- Полные права у четверти пользователей. В обеих базах — 25 и 27%. Обычно это следы внедрений и авралов: права выдали «на время», снять забыли. Норма — три-пять администраторов, остальным профили по должностям.
- Дата запрета редактирования не установлена или устарела. Признак включён, все довольны, но защиты нет: закрытый и сданный период можно поправить задним числом.
- Дубли в справочниках. Контрагенты, номенклатура, физлица. Они не мешают работать до тех пор, пока не понадобится автоматика — загрузка выписок, обмен с площадкой, акт сверки.
- Шум в журнале ошибок. Одна сломанная интеграция генерирует тысячи записей, и на их фоне не видно ничего важного. Почти всегда чинится за час-два.
- Доработки, о которых не знает никто. Объекты, добавленные в конфигурацию напрямую, а не расширением. Работать не мешают, но каждое обновление превращается в лотерею — особенно если автор давно ушёл. Отдельный разговор — самописные конфигурации, там это правило, а не исключение.
Что делать с отчётом
Отчёт заканчивается планом работ, и в нём важен порядок. Сначала идёт то, что даёт наибольший эффект за наименьшее время: в нашем случае это была галочка в интеграции, у клиента — чистка дублей, после которой выписки начали грузиться сами. Дальше — права, защита периодов, гигиена данных. Такой порядок позволяет увидеть результат в первую же неделю, а не через квартал.
Отдельно стоит сказать, чего диагностика не делает. Она не заменяет постоянный мониторинг: замер показывает состояние на дату, а обмены встают ночью в любой другой день. Она не решает вопрос обновлений — только показывает, чем они рискуют. И она не отвечает на вопросы про железо: если тормоза идут от сервера, нужен отдельный разбор по журналам и замерам.
Частые вопросы
Нужно ли останавливать работу на время диагностики?
Нет. Мы работаем с копией базы, сотрудники в это время работают как обычно. Снятие копии — единственное действие, которое требует участия ваших администраторов.
Сколько это занимает?
Обычно около пяти рабочих дней от получения копии до готового отчёта. Дольше бывает, когда в базе много нетиповых доработок и приходится разбираться, что именно они делают.
Что именно мы получим на руки?
Отчёт на 15–20 страниц: паспорт базы, индекс здоровья с расшифровкой по критериям, найденные проблемы с оценкой влияния на бизнес, разбор обменов, регламентных заданий и прав доступа, план работ с приоритетами. Документ остаётся у вас — с ним можно идти к любому подрядчику, не обязательно к нам. Образец отчёта можно посмотреть заранее.
А если у нас всё в порядке — деньги на ветер?
Тогда вы получите отчёт, в котором это написано, с цифрами. Это тоже результат: понятно, что тормоза не в базе, и искать причину надо в другом месте — в железе, в канале связи или в процессах. Пока замера нет, спор «база виновата или нет» не имеет решения.
Мы сами обслуживаем свою 1С. Диагностика имеет смысл?
Да, и часто больше, чем у тех, кто на аутсорсе: свой специалист привыкает к базе и перестаёт замечать то, что делается руками годами. Взгляд со стороны здесь и нужен — как раз потому, что он не знает, «как у нас принято».
С чего начать
Если вы дочитали и поймали себя на мысли «у нас наверняка то же самое» — скорее всего, так и есть. Хорошая новость в том, что почти все находки из этой статьи чинятся часами, а не неделями; плохая — что без замера непонятно, с чего начинать, и работы обычно начинают не с того конца.
Мы делаем AI Диагностику 1С: разбираем копию базы и отдаём отчёт с индексом здоровья, находками и планом работ. Дальше вы решаете, что с ним делать — чинить самим, отдать своему подрядчику или нам. Если хочется сначала посмотреть, как выглядит документ, — вот образец отчёта на 18 страниц.
Замерим состояние вашей базы
Напишите, какая конфигурация и что именно беспокоит — тормоза, ошибки, ручная работа бухгалтерии. Снимем копию, разберём и вернёмся с отчётом: индекс здоровья, находки и план работ по порядку. Сотрудники в это время работают как обычно.
Статья описывает нашу практику работы с нетиповыми и самописными конфигурациями 1С. Состав и порядок работ по конкретной базе определяются после её разбора: то, что подходит одной компании, для другой может быть лишним. Pavel.Stupko@iteal.expert · @pgstupko