Производственный консалтинг или как подготовиться к внедрению проекта 1С

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

Сегодня наш фокус внимания будет ориентирован на автоматизацию и цифровизацию компаний.

Как правило, к мысли о необходимости автоматизации или развитии исторической системы приводят проблемы и требования бизнеса, которые трудно или невозможно удовлетворить на существующем уровне автоматизации:

• Нужно гибкое планирование производства;
• Хотим вести учет доходов и расходов по проектам и сделкам;
• Нужно отслеживать поставки на всем протяжении времени;
• Нужно внедрить учет госзаказов;
• Требуется планирование перевозок;
• Необходимо ведение продаж со множеством разрезов учета;
• Внедрение управленческого учета;
• Добавить еще три аналитики в отчеты;
• Необходимо вести материальную себестоимость и полную тоже;
• Т. д и т. п.

Тут же подливает масло в огонь и отдел ИТ:

• Дорабатывать дальше нашу систему просто опасно, она может рухнуть;
• Слишком дорого обходится;
• Обновить не можем, остатки разъезжаются;
• Чтобы эти интеграции поддерживать нам нужно еще 10 человек;
• Что вы хотите, система морально устарела еще 5 лет назад;
• И т.д и т.п

И вот решение принято — нужно внедрить комплексную систему автоматизации уровня ЕРПИ, но тут появляется новый пул вопросов:

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

Вот на этот последний вопрос мы с вами и попробуем дать ответ — «А как начать?».
Для успешного проекта автоматизации должна быть проведена достаточно большая подготовительная работа:
1. Подготовлена база нормативно-справочной информации;
2. Разработаны правила отражения затрат и расчета себестоимости;
3. Зафиксированы требования к будущей системе.

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

Часто на проектах автоматизации мы сталкиваемся с такой ситуацией:
Накоплена база данных справочной информации и большое количество проблем:

• Неактуальные данные;
• Задвоение данных;
• Не до конца заполненные аналитики и признаки;
• Отсутствие систематизации;
• Множество точек ввода;
• Отсутствие ответственных за полноту и правильность внесения новой информации;
• Нерегламентированная работа с названиями номенклатуры поставщиков;
• Частичное ведение партионного учета;
• Не соблюдаются правила систем хранения данных;
• Отсутствие автоматических проверок данных для взаиморасчетов (неправильные ИНН и КПП для контрагентов).
• Пр…

При этом времени на исправление и нормализацию данных в организации выделить не готовы или просто не хватает людей. Оправдание звучит, как правило, так — перенесем как есть, а потом проведем работу по выравниванию данных. В результате все «исторические» беды переходят в новую систему.

Для того, чтобы избежать таких проблем, перед началом проекта необходимо разработать методику построения архитектуры НСИ, в которой полностью будут регламентированы все правила отражения и заполнения основных справочников системы (от номенклатурных до взаиморасчетных), выстроено их взаимодействие между собой и отражение в будущей отчетности. Также в методике отражают правила для построения обменов между системами и мейпинга данных. Выделяют наборы характеристик и признаков для более глубокой аналитики данных. Утверждают регламент ввода данных в «одно окно», выделяют систему мастер-данных, назначают конкретных ответственных за ведение справочников.

Примерный план разработки методики НСИ для системы уровня ERP:

• Разработка структуры предприятия (ЦФО);
• Разработка структуры видов номенклатуры;
• Разработка распределения характеристик и сведений;
• Разработка правил партионного учета;
• Разработка правил ведения номенклатуры поставщиков;
• Разработка схемы работы складов;
• Разработка правил ввода данных о партнерах/контрагентах;
• Разработка правил использования соглашений и договоров;
• Разработка структуры статей движения денежных средств.

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

• Расчет себестоимости не подкреплен первичными данными;
• Необходимые данные не вносятся в нужное, ограниченное количество времени (в основном относится к предприятиям с ежедневным расчетом себестоимости);
• Хочется иметь сразу несколько расчетов (плановый, полный, материальный, маржинальный и т. д);
• Нет учетной политики управленческого учета;
• Необходим поэтапный расчет;
• Не хватает баз для распределения затрат;
• Не хватает аналитик для анализа;
• Нет подробных спецификаций и технологического процесса в системе;
• Нет возможности вести доходы и расходы в рамках конкретных проектов;
• Т.д.

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

Примерный план разработки методики расчета себестоимости для системы уровня ERP:

• Разработка структуры себестоимости продукции;
• Формализация структуры предприятия;
• Разработка структуры справочника «Статьи калькуляции»;
• Разработка структуры справочника «Статьи расходов»;
• Методология включения прямых расходов в себестоимость продукции;
• Методология включения накладных переменных расходов в расчет себестоимости продукции;
• Методология учета накладных постоянных расходов для финансового результата от реализации произведенной продукции;
• Описание правил реклассификации расходов;
• Подготовка пакета отчетности по расчету плановой и фактической себестоимости продукции;
• Создание набора целевых показателей эффективности по блоку учета затрат и расчета себестоимости продукции.

Для новой системы очень важно собрать как можно больше пользовательских пожеланий, а затем проработать их и сформировать «Реестр требований».

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

Необходимо понимать, что «пользовательские требования» — это пожелания пользователей и они могут быть сформулированы не полностью или приблизительно, в Реестре же они должны быть проработаны и отвечать следующим основным правилам:

• Требование должно быть полным;
• Требование должно быть непротиворечивым;
• Требование должно быть недвусмысленным;
• Требование должно быть понятным;
• Требование должно быть поддающимся проверке;
• Требование должно быть упорядоченным по важности и стабильности.

Также в Реестре должна быть отражена классификация требований:

• Требования к функциональности ПО;
• Требования нефункциональные к ПО;
• Ограничивающие требования.

Казалось бы, эту работу можно провести собственными силами и в кратчайшие сроки, но на пути возникают преграды:

• Синдром «Да, Но» — будет всегда, главная задача выяснить все или большинство «НО».
• Синдром «неоткрытых руин» — чем больше найдено требований, тем сильнее кажется, что это еще не все.
• Синдром «пользователя и разработчика» — как правило, сбором таких требований занимаются сотрудники ИТ-отдела, а они и ответственные со стороны бизнеса принадлежат к различным мирам, говорят на разных языках и имеют различный опыт, мотивацию и цели.

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

Правильно разработанный «Реестр пользовательских требований» сокращает необходимое время на предпроектное обследование, позволяет выявить все «тонкие» места между разными функциональными областями учета, вскрыть проблемы коммуникаций между разными отделами и выявить непосредственно ответственных сотрудников, из которых потом формируется проектная команда Заказчика.


В заключение хочется повторить, что правильно выполненная и в полном объеме подготовка к проекту увеличивает шансы его успешного внедрения на 50% и позволяет сократить время внедрения на 25%, а, следовательно, уменьшить затраты.