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