Нормализация и подготовка данных и НСИ для проектов по внедрению систем класса ERP

02.10.25

Бизнес-анализ - Внедрение изменений

При внедрении новых систем подготовка данных и нормативно-справочной информации часто становится источником рисков: результат не удовлетворяет стороны, а сроки и бюджет проекта оказываются под угрозой. Разберемся, как эффективно организовать этот процесс. Обсудим распределение ответственности между исполнителем и заказчиком, оптимальные сроки начала подготовки и методы ее организации. Расскажем об основах теории классификации для структурирования данных, а также о подходах к оценке затрат и управлению рисками. Статья поможет сформировать четкое понимание объема работ, зон ответственности и ожидаемых результатов на каждом этапе.

Меня зовут Кирилл Чебанов, я руководитель проектов в компании «КРОК». В этой статье я опишу этапы нормализации и подготовки данных и нормативно-справочной информации. Разберемся, на что нужно обратить внимание и какие моменты не следует упускать.

Главная идея, которую я хочу донести, заключается в том, что качественные данные и правильная структура справочников являются критически важными. Без них ни одна система не сможет эффективно функционировать. Даже самая продуманная реализация не принесет пользы, если отсутствуют надежные данные.

Давайте рассмотрим три ключевых направления работы в данной задаче:

  • Определение новой структуры нормативно-справочной информации (НСИ) и данных: как мы будем их хранить и использовать.

  • Подготовка самих данных.

  • Нормализация существующей НСИ и создание новой НСИ.

 

 

Задачи три – проблем больше. На основе своего опыта выделю четыре типовые проблемы:

  • Объемность и продолжительность задачи,

  • Некорректное планирование и подход к данной работе,

  • Неявные зоны ответственности в выполнении данной работы,

  • Неготовность сторон к данной работе.

Главная проблема заключается в том, что заказчику работа с НСИ не всегда ясна. Айтишники понимают важность этих процессов, тогда как бизнес зачастую не видит ценности в значительных затратах на нормализацию данных. Заказчик не получает ничего осязаемого и может не понимать, как важны результаты вашей работы. Задача управленцев и аналитиков – донести до клиента ценность этой работы и тех результатов, которые он получит в результате вашей деятельности.

 

Этапы работ и их состав

 

К проекту можно приступить после прохождения следующих этапов:

  1. Обследование, ОТЗ

  2. Моделирование

  3. Проектирование и разработка

  4. ОПЭ

 

 

У кого-то этапы могут называться иначе и иметь другую детализацию, но часто допускается одна и та же ошибка: многие начинают заниматься работой с НСИ только на четвертом этапе. Заказчиков просят предоставить новые справочники, когда прибывают к этапу опытно-промышленной разработки. К сожалению, не все так просто.

 

Этап обследования

 

Для этого этапа необходимо:

  • Собрать информацию,

  • Выяснить источники и места хранения,

  • Выяснить количество объектов,

  • Выявить потребности в новых объектах,

  • Сформировать планы работ.

В ходе обследования мы определяем потребности заказчика по справочникам, выясняем, что у него уже есть, что необходимо, где это расположено и в каком объеме. Таким образом, мы формируем объемно-календарные рамки задачи для дальнейшей оценки и разработки плана работ.

 

Этап моделирования

 

Моделирование – ключевой этап, позволяющий глубже понять, как будут выглядеть данные и справочники заказчика в новой системе. Здесь мы планируем работы, оцениваем их и распределяем зоны ответственности в команде, вовлекая заказчика в процесс. Заказчик не может оставить все на нас, он не должен думать «Я заплатил, значит, вы должны все сделать».

 

 

В рамках проектной практики у нас в компании мы делимся лучшими кейсами. Сохраняя их, обрабатывая и обсуждая, мы создаем обширную внутреннюю базу знаний. На этапе моделирования сосредоточено предельно много информации, так как именно здесь закладываются основы будущей работы. Важно помнить, что в процессе разработки необходимо доработать объектную модель и учесть изменения в методах расчетов, чтобы заказчик мог адаптироваться к этим изменениям в своей подготовке.

Цели работ

Удовлетворить потребности бизнеса:

  • Обеспечить корректное отражение информации в новой системе,

  • Обеспечить достаточную детализацию информации в новой системе,

  • Обеспечить полноту данных в новой системе для работы всех частей системы.

Удовлетворить технические потребности:

  • Обеспечить повторяемость результата занесения данных,

  • Обеспечить обратную совместимость информации.

Если рассмотреть все задачи по подготовке нормативно-справочной информации и данных, их можно разделить на две основные группы:

  • направленные на удовлетворение бизнес-потребностей, чтобы обеспечить необходимый эффект проекта;

  • направленные на предоставление заказчику инструмента, который поможет подготовить информацию, чтобы работа не превратилась в неопределенный клубок активностей.

Мы анализируем потребности заказчика, моделируем различные варианты в системе и представляем их заказчику. Важно отметить, что этот процесс напрямую связан с НСИ. Создавая структуру хранения информации, мы определяем, какие справочники и в каких разрезах будут необходимы позже в проекте.

Базовые задачи моделирования

  • Смоделировать НСИ для новой системы,

  • Сформировать перечень необходимых НСИ,

  • Сформировать план создания/получения новых НСИ,

  • Определить перечень необходимых входных данных новой системы,

  • Сформировать план получения входных данных.

При формировании перечня задач мы составляем полный перечень работ, определяем временные рамки и доносим эту информацию до заказчика. Важно обсудить не только моделирование, но и детали справочников – как они выглядят и для чего предназначены, при этом согласовывая терминологию, поскольку у заказчика она часто отличается от вашей.

 

Этап обеспечения

 

На этапе обеспечения часто создаются шаблоны в Excel и небольшие базы данных для заказчика. Для этого на рынке есть множество инструментов, включая MDM-систему от 1С, однако универсальных решений нет. Выбор инструмента зависит от специфики задачи, ее масштаба, а также доступных финансовых, временных и технических ресурсов. Вы должны выбрать тот инструмент, который будет соответствовать задаче, которая перед вами стоит. Например, нет смысла внедрять MDM для справочника из ста элементов, так как это затратно. И наоборот, для десятков тысяч элементов использование блокнота будет неэффективным. Обеспечение заказчика подходящими инструментами, соразмерными задачам и бюджету – это обязанность вашей команды, так как вы отвечаете за результаты.

Задачи обеспечения

  • Проработать:

    • программу и план мероприятий по переносу,

    • вопрос и программу повторного обновления данных,

    • методику обратной совместимости данных,

  • Подготовить ландшафт и инструментарий для заказчика по формированию/нормализации НСИ и подготовки данных,

  • В случае необходимости реализовать запуск сопутствующего ПО,

  • Разработать ТЗ и правила загрузки/обмена.

Стоит также отметить готовность к инструменту. MDM существует давно, но используется нечасто, и даже в мире 1С многие о нем не знают, не говоря уже о заказчиках. Если вы решите использовать MDM, обязательно выделите время на обучение заказчика, чтобы сделать этот инструмент частью системы. Это логично: если мы предоставили инструмент, его следует использовать и далее.

Используемый инструментарий должен определяться практической ценностью:

  • Готовностью сторон к конкретному инструменту,

  • Соразмерностью используемого инструмента размеру задачи,

  • Особенностям порядка загрузки данных в конкретном случае,

  • Стоимостью работ и размером бюджета.

Полезным инструментом является использование реестров работ с информацией об объектах, об ответственных, о способах обработки, о состоянии и ключевых вехах.

Реестр, содержащий в себе такую информацию – сквозной инструмент всего проекта. В нашей работе мы накопили знание и опыт, на основе которых разработали простой инструмент – Excel-таблицу. Она заполняется с начала проекта и дополняется на всех его этапах. С помощью этой сводной таблицы мы отслеживаем прогресс разработки и подготовки справочной информации и данных, сохраняя все на входе и обеспечивая завершение всех процессов. Этот инструмент также позволяет делиться с заказчиком актуальным статусом задач и нашими ожиданиями от него, поскольку в таблицах мы фиксируем зоны ответственности.

 

Зоны ответственности сторон

 

Ключевым участником процесса является заказчик, а не автоматизаторы. Только заказчик обладает необходимой экспертизой по своим данным и объектам НСИ. Несмотря на нашу специализацию и знания в определенных отраслях, мы не сможем заменить технологов, конструкторов и инженеров, которые подготавливают данные для базы.

 

 

Таблица отражает список работ по этапам и зоны ответственности сторон. Важными элементами являются два вида работ:

  • Передача заказчику информации о том, что нужно сделать, зачем и как.

  • Подготовка данных.

Если заказчик не выполнит задачу подготовки данных, запуск проекта станет невозможным. Приведу пример, который показывает, почему не стоит недооценивать этот момент. Сначала заказчик хотел очень детальные ресурсные спецификации в базе, но позже сообщил, что не сможет предоставить необходимую информацию. В результате модель оказалась неактуальной и была переделана. Эффект, на который рассчитывали изначально, был потерян. Из-за недостаточной готовности заказчика проект столкнулся с серьезными проблемами, несмотря на подписанные официальные письма и признание рисков. В итоге продукт не соответствовал ожиданиям и не решал те задачи, которые стояли перед ним изначально.

В вопросах ответственности обе стороны отвечают за полноту информации. Заказчик должен подготовить данные, а ваша задача – проверить, что все сделано корректно и соответствует ожиданиям системы.

 

 

 

Требования бизнеса

 

НСИ и данные должны отвечать требованиям бизнеса.

  • Бизнес живет в окружении бизнес-партнеров. Важно понимать, что заказчик не существует в вакууме. Он принадлежит к бизнес-единице, которая взаимодействует с контрагентами, подчиняется отраслевым стандартам и законодательству, а также использует уже имеющиеся инструменты. Например, если заказчик активно работает с маркетплейсами, такими как Ozon, Wildberries или Яндекс, он имеет свои структуры хранения данных и справочников. Если мы предложим ему иную структуру для номенклатуры, это потребует дополнительной работы по мэппингу с маркетплейсами. Проще адаптировать имеющуюся информацию под его системы, чтобы облегчить ему задачу.

  • Бизнес существует в рамках отраслевых стандартов и нормативов. Применяя общепринятые стандарты, такие как ЕСКД, можно использовать готовые справочники, которые регулярно обновляются и доступны для интеграции с 1С, что делает возможной автоматизацию этого процесса.

  • Бизнес работает с существующими продуктами и системами. В настоящее время активно развиваются системы ФГИС, такие как «ВетИС» и «Сатурн», а также системы электронного документооборота и обмена с торговыми площадками. В рамках подготовки проекта важно обеспечить сохранение формата обмена данными с этими площадками. Заказчик уже выстроил процессы с партнерами, предоставляющими платформы, и не стоит вносить радикальные изменения. Если невозможно сохранить существующий инструментарий, создайте регистры обработки для корректного переноса данных.

  • Бизнес обязан выполнять требования законодательства РФ.

 

Методические рекомендации

 

  • Проходите всю объектную модель системы. При подготовке нормативно-справочной информации, независимо от того, насколько хорошо вы знаете систему или понимаете заказчика, выделите время для анализа всей структуры справочников внедряемой системы. Каждую категорию справочников нужно сопоставить с потребностями заказчика. Затем проанализируйте, есть ли место для хранения всех необходимых данных. Это позволит исключить неиспользуемые справочники и выявить те, которые необходимо добавить.

  • Выделяйте особенности бизнеса заказчика для определения объектной модели. Важно учитывать глубину анализа данных. Например, в сложном машиностроительном производстве заказчик может хотеть контролировать затраты вплоть до отдельных деталей. В таком случае нужна структура данных, позволяющая хранить информацию о всех компонентах, включая стоимость каждого элемента.

  • Формируйте таблицы соответствия справочников и документов.

  • При подготовке встреч с заказчиком готовьте примеры использования того или иного НСИ и данных. В примерах и материалах для заказчика используйте его бизнес-термины и конкретные данные. Поскольку заказчику тяжело привыкать к новому продукту, важно облегчить ему этот процесс.

 

Организационные рекомендации

 

  • Распределяйте задачи между аналитиками блоков соответственно местам возникновения данных.

  • Дополняйте группы представителями не только источника, но и потребителем данных.

  • Привлекайте владельцев специальных систем к моделированию всех связанных блоков. Ранжируйте задачи от маленьких к большим.

  • Для каждого проекта формируйте команду аналитиков, работающих в различных областях.

После определения зоны ответственности делите справочники и работу с ними между аналитиками – у каждого должен быть владелец и ответственный. Это важно, поскольку справочники используются не в одном месте. Рекомендуется делить их по месту возникновения. Главное, чтобы заказчики и команда пришли к единому мнению по этому вопросу.

 

Теория классификации

 

Существует наука, называемая теорией классификации, которая занимается обработкой равномерных массивов данных.

Представим себе огромный одномерный массив справочников номенклатуры, который нужно классифицировать для удобства работы заказчика. Например, в случае маркетплейса, выгружающего данные на витрину, клиент должен быстро и легко находить нужный товар. Он не готов тратить день на поиски в разных вкладках. Таким образом, теория классификации охватывает важный аспект упрощения использования данных.

Я вывел один из вариантов того, как надо проходить по таким структурам данных:

  • Выделение ярких отличительных черт исследуемого объекта,

  • Классификация всего множества объектов по данным чертам,

  • Выделение отличительных черт второго порядка,

  • Классификация первого множества объектов по данным чертам и т.д.

Если хотите погрузиться в тему глубже, вот литература, где эти идеи разбираются подробнее:

  1. Бир С. Кибернетика и менеджмент. URSS. 2006. Гл. 2.

  2. Любищев А.А. К логике систематики // Проблемы эволюции. Т. 2. 1972. Новосибирск, с. 45-68.

  3. Мейен С.В., Шрейдер Ю.А. Методологические аспекты теории классификации // Вопросы философии – 1976. –. № 12. – С. 67–79.

  4. Покровский М.П. Введение в классиологию. – Екатеринбург: ИГГ УрО РАН, 2014.

 

Варианты и способы оценки этапов НСИ

 

Так как справочники и задачи по ним неоднородные, вам придется проводить оценку самостоятельно.

  1. Выделяйте в рамках этапа обследования отдельный объем для изучения существующих НСИ и источников данных.

  2. Выделяйте в рамках обследования процессы по управлению НСИ.

  3. Включайте в этап моделирования (проектирования) отдельные задачи по:

  • формированию конечного перечня НСИ и данных новой системы,

  • сопоставлению новых НСИ и данных существующих источников информации,

  • определению технического объема на подготовку доработок по работе с данными.

  1. Если в рамках доработок предполагается доработка объектной модели, включайте в состав доработки методологическую работу по НСИ.

Рекомендую выделить работы, связанные с НСИ и данными, в отдельный трек в каждом блоке проекта. Каждая такая работа должна иметь четкие результаты, которые будут переданы заказчику и обособлены от других этапов. Важно, чтобы каждый этап проекта завершался конкретным результатом. Анализируйте объем работы по каждому справочнику и объекту данных, чтобы точно оценивать задачи.

 

Особые задачи

 

  1. В рамках конечной проработки НСИ выделяйте время на объяснение новой модели НСИ.

  2. Постарайтесь направить команду заказчика на базовое обучение системе, чтобы создать представление о типовых связях системы. Это поможет ей лучше понять систему и выровнять понятийный аппарат. Будьте готовы покрыть расходы на обучение, если заказчик не готов сделать это сам – это сэкономит вам время в будущем.

  3. Закладывайте время и ресурсы обеих сторон на тестовый перенос НСИ и данных. Помните, что управлять задачами по НСИ сложно из-за их дробности. Обязательно заложите больше времени на этапе моделирования, так как он включает много мелких задач.

  4. Закладывайте большее, нежели обычно, время на управление и администрирование данных задач. Учитывайте доступность управленца и его трудозатраты в проекте, чтобы обеспечить эффективность работы и учесть все расходы.

 

Риски данного типа работ

 

  • Невозможность нормализовать необходимый объем за отведенное время,

  • Отсутствие у заказчика информации для новой системы в принципе,

  • Отсутствие ресурсов со стороны заказчика на нормализацию,

  • Низкое качество предоставляемых заказчиком данных,

  • Неполные вводные от заказчика по задаче.

Стоит выделить две ключевые проблемы, с которыми мы сталкиваемся.

Отсутствие у заказчика информации для новой системы (неосведомленность заказчика). Чаще всего он не понимает, что происходит: зачем и для чего это нужно, кто за это отвечает, что ему с этим делать и что ему это даст. Ваша задача – информировать его, начиная с этапа пресейла. Объясните, какие действия вы собираетесь предпринять и какой ресурс ему потребуется для подготовки данных. Укажите на необходимость финансирования для разработки методик, регламентов и других необходимых материалов. Чем раньше заказчик осознает ценность вашей работы, тем меньше сложностей возникнет в проекте, так как любые проблемы приводят к затягиванию сроков и к дополнительным затратам.

Неполные вводные данные от заказчика по задаче. Заказчик часто не предоставляет необходимую информацию по различным причинам. В итоге, когда мы подходим к запуску, возникают вопросы о недостающих данных. И нам ничего другого не остается, кроме как повторно уточнять информацию у заказчика по всем процессам и блокам системы. Будьте готовы к этому и предусмотрите бюджет на возможные дополнительные затраты, связанные с этой доработкой.

 

Сложности в работе с заказчиком

 

  • Заказчик может не понимать, чего от него хотят,

  • Разный понятийный аппарат,

  • Разные точки зрения на сущности системы,

  • Проблема сдачи работ – плохо сформулированные критерии выполнения работы,

  • Недооценка объема работы с точки зрения исполнителя.

Одной из основных сложностей в работе с заказчиком является различие в восприятии информации. Мы живем в своем информационном пузыре, тогда как заказчик – в своем. Наша задача – сблизить эти миры.

Кроме того, мы можем неправильно оценить объем работы. Если мы недооценим задачу по подготовке данных и останется мало времени до запуска системы, это может привести к нехватке ресурсов – как наших, так и заказчика. В итоге, если система учетная, и мы не успеваем, например, к 1 января, запуск откладывается на следующий год, а это может быть уже никому не нужно.

***

В заключение хочу резюмировать: обязательно обеспечьте качественные данные для запуска системы. Поясните заказчику, зачем это нужно, и планируйте работы по подготовке информации, наполняя систему на каждом этапе. Это ключ к успешному запуску.

 

 

 

*************

Статья написана по итогам доклада (видео), прочитанного на конференции INFOSTART TECH EVENT.

См. также

Стандарты и документация Работа с требованиями Взгляд со стороны Заказчика Бесплатно (free)

«Без хорошего ТЗ — результат такой себе». Но что делать, если ТЗ все время получаются плохими? Вместо того, чтобы заставлять заказчиков следовать шаблонам, мы применили концепцию обучения Дэвида Колба. В статье делимся опытом проведения 8 мастер-классов для 60 коллег по основам написания ТЗ, декомпозиции требований и описанию ошибок. Вы не получите волшебную таблетку, но узнаете конкретный план действий, который поможет сократить время анализа требований и улучшить коммуникацию в команде.

25.09.2025    363    0    user1514417    0    

0

Стандарты и документация Россия Бесплатно (free)

Система менеджмента качества уже много лет активно применяется в среде "1С-Франчайзи". Но не все и не всегда используют ее на 100%. Делюсь, как это делаем мы уже достаточно давно.

04.09.2025    414    0    user1073387    1    

3

Стандарты и документация ИТ-компания Россия Бесплатно (free)

Организация ведения проектной документации на базе СППР. Как решить вопросы эффективности при проектах, направленных на доработку или внедрение новых продуктов от 1С, при "зоопарке" программ финансового учета и анализа, бухгалтерии ведения конструкторской документации и самое "любимое" это разработки, целые системы на 1С, которые не имеют документации.

02.09.2025    1351    0    user1023273    3    

3

Взгляд со стороны Заказчика Работа с требованиями Стандарты и документация Бесплатно (free)

Погружаемся в реалии крупных проектов, где тестирование – не просто этап контроля качества, а инструмент управления ожиданиями, снижения рисков и успешного внедрения.

29.08.2025    891    0    larandrey    0    

1

Стандарты и документация Оценка проекта Бесплатно (free)

Корректно формулировать предпосылки и цели проекта умеют немногие. Как показывает практика, с этим очень тяжело справляются функциональные заказчики. И даже для сотрудников, которые много лет занимаются проектами внедрения информационных систем, это не тривиальная задача. Расскажем о том, как проверить корректность целей, сформулировать предпосылки и правильно составить Устав проекта.

13.08.2025    712    0    INK2018    5    

6

Работа с требованиями Стандарты и документация Бесплатно (free)

Удивительно, но до сих пор большинство аналитиков не слышали о своде знаний по бизнес-анализу BABOK Guide и не знают, что фактически уже используют его техники в работе. Расскажем о том, как с помощью техник BABOK сделать ТЗ максимально «живым» – структурировать требования, визуализировать процессы, смоделировать данные и интерфейсы, чтобы ТЗ было понятно и заказчику, и разработчику.

31.07.2025    1363    41    otkalo    8    

2

Стандарты и документация Бесплатно (free)

Статья посвящена распространённой проблеме в разработке 1С – чрезмерному формализму технических заданий, превращающих гибкий процесс внедрения в бюрократический кошмар. Мы разбираем, почему объёмное ТЗ не гарантирует успех проекта, как оно может парализовать работу команды и что делать, чтобы перейти от «мертвых» документов к живому процессу разработки. На практических примерах из мира 1С показываем, какие форматы взаимодействия действительно работают и как сохранить баланс между ясностью требований и гибкостью решений.

29.07.2025    1655    0    Vasin86    19    

25

Архитектура решений Внедрение изменений 1С v8.3 1С:ERP Управление предприятием 2 Управленческий учет Бесплатно (free)

Расчет себестоимости — один из наиболее сложных этапов внедрения 1С:ERP. Фактически его можно считать завершающим шагом успешной автоматизации. Разбираем принципы формирования себестоимости в 1С:ERP, типичные проблемы при внедрении и способы их решения. Вы узнаете, в каких случаях применяются номенклатурные затраты, трудозатраты или постатейные расходы, как организовать учет незавершенного производства и вести раздельный учет по направлениям деятельности, а также какие доработки допустимы, а от каких лучше отказаться. Особое внимание автор уделяет статьям расходов и правильному формированию базы распределения, а также частым ошибкам, которые искажают расчеты.

29.07.2025    3804    0    user1455139    11    

18
Для отправки сообщения требуется регистрация/авторизация