Управленческие решения отличаются широтой принятия и полётом мысли. Поэтому трудно сказать, что среди них существует только одно безусловно правильное и единственно возможное.
Расскажу об одном из вариантов принятия решений в рамках проекта комплексного внедрения ERP в достаточно большом холдинге.
Очень часто я, как сотрудник отдела разработки ERP фирмы «1С», получаю вопросы: «Мы приобрели программу, а что с ней делать дальше? Как ее довести до состояния, когда она действительно будет соответствовать пожеланиям заказчика?» Расскажу наше видение о том, как это сделать.
Это один из возможных вариантов развития программы – по принципу «делай как я». Я считаю, что если получилось у меня, значит, есть шанс, что получится и у вас. Конечно, результата можно достичь и по-другому, а можно и повторить то, что уже обкатано, опробовано и дало определенные результаты.
Расскажу о проекте внедрения 1С:ERP в АО «Трансмашхолдинг». Это крупнейшее предприятие по производству электровозов, вагонов электропоездов и метро.
Компания – лидер отрасли, №1 в России и СНГ, №4 в мире. Представлена на международных рынках, имеет предприятия за рубежом. Ее продукцией вы пользуетесь постоянно.
Предпосылки внедрения
На протяжении достаточно большого промежутка времени АО «Трансмашхолдинг» использует программные продукты фирмы «1С»:
-
В 2010-2012 году компания внедрила у себя «1С:Управление производственным предприятием» и получила четко работающую и продуманную систему для управления производством и для подготовки всех видов управленческой и регламентированной отчетности.
-
Казалось бы, если это хорошо работает, зачем что-то менять? Но произошли определенные события – в 2019 году компания «Трансмашхолдинг» стала владельцем еще одного большого холдинга – «ЛокоТех», деятельность которого связана с ремонтом техники, произведенной «Трансмашхолдингом». Это вызвало потребность в систематизации и унификации управленческих процессов. Для использования в объединенном холдинге общих регламентов управления приняли решение построить единую систему.
-
Кроме этого, было решено избавиться от разнообразия программ, применяемых на отдельных предприятиях объединенного холдинга.
-
А также заместить те программные продукты, которые уже подошли к окончанию своего срока действия.
Сама группа «ЛокоТех», объединяющая сервисные ремонтные заводы, очень большая. Компания крупнейшая не только в России, но и в Европе. Имеет 250 производственных площадок, расположенных в разных часовых поясах, что накладывает особые требования к автоматизации.
На слайде – цели проекта, которые были поставлены для объединенного холдинга:
-
Самое главное – это унификация бизнес-процессов и учетных механизмов, которые позволят принимать финансовые решения и управлять всем холдингом по единым правилам.
-
Обязательства перед иностранными аудиторами. Компания международная, с французским капиталом, акции котируются на биржах. Интерес аудиторов к компании очень большой.
-
И поддержка развития бизнеса – компания развивается инновационно, внедряет серьезные технологии. Это все тоже требует определенных условий поддержки.
Контур проекта и стартовые условия
Проект интересен своим комплексным функциональным охватом.
Причем производственное планирование и управление материально-техническим обеспечением (позиции, которые выделены на слайде синим цветом) в проекте не типовые. Более того, они не являлись обязательными для такого большого комплексного проекта и скорее являются исключением из правил, потому что включать подобные функции в проект запуска системы имеет смысл только в единичных случаях.
Более классическая модель – когда сначала создается база на основе материального потока и финансового управления, и уже потом отдельным проектом на этой базе выстраивается система планирования производства и МТО.
Стартовые условия проекта в 2019 году были следующие:
-
Трансмашхолдинг – практически идеальная автоматизация на УПП;
-
ЛокоТех – УПП, частично переведенная на 1С:ERP версии 2.1. Обе системы – сильно переработанные.
Каждое из этих решений по отдельности было отличным, но не позволяло выбрать одно из них как единую учетную систему для автоматизации объединенного холдинга в целом. Требовались другие решения.
Основой единой учетной системы на 1С стали:
-
осознанный выбор холдинга в пользу продуктов фирмы «1С», опирающийся на большой опыт работы в этих продуктах;
-
большое количество хорошо обученных пользователей и специалистов техподдержки;
-
хорошая методическая проработка управленческой отчетности и регламентов, в том числе и производственных.
Хронология проекта
С чего начался проект?
-
В феврале 2019 года абсолютно по канонам проектного управления принимается решение о проекте автоматизации. Из аудиторских компаний приглашаются уважаемые консультанты – они начинают прорабатывать новые бизнес-процессы, которые должны быть переложены в информационную систему.
-
Были ожидания, что в августе 2019 года эта работа из методической проработки плавно перетечет в технологию непосредственного внедрения. Но, к сожалению, этого не произошло, потому что момент, помеченный на слайде красным – «Ожидание преобразования методических документов в документы непосредственного управления внедрением» – это самая сложная точка, с которой сталкивается любой внедренец на проектах такого уровня. В этот момент оказалось, что теоретически правильная методология, сформированная с точки зрения учетных подходов и управленческих принципов, не может быть отражена в программном продукте, потому что при разработке этих методических материалов возможности продукта изначально не были изучены. Хотя те люди, которые разрабатывают эти материалы, должны хорошо знать программный продукт и использовать те методические модели предприятия, которые представлены в ERP. К сожалению, по классике жанра этого не произошло.
-
И вот в сентябре 2019 года Трансмашхолдинг обратился к вендору за помощью, потому что эта объединенная система требовала немедленного применения. Дата запуска системы была определена 1 января 2020 года – времени оставалось совсем немного. Есть большой набор методических материалов, но как внедрять – не понятно. Сентябрь 2019 года стал, наверное, первой ключевой точкой, потому что произошло переформатирование команды проекта – туда вошли представители вендора. И была пересмотрена концепция подготовки проекта.
-
В октябре 2019 года был определён состав пилотной группы – было выбрано четыре предприятия, из них два предприятия из старого Трансмашхолдинга и два предприятия из «ЛокоТеха», на которых планировался запуск пилотной группы с 1 января 2020 года. И началась активная фаза проекта.
Что определило новую стратегию данного проекта?
-
Мы опирались на безусловный уровень доверия и поддержки со стороны собственников и руководителей предприятия.
-
Имел значение размер предприятий, которые вошли в пилотную группу – это большие производственные площадки. Со стороны «Трансмашхолдинга» это были площадки, которые собирают тепловозы и вагоны метро. А со стороны «ЛокоТеха» – большие ремонтные сервисные центры. В частности, «ЛокоТех-Сервис» – организация, которая объединяет 90 фактически самостоятельных производственных площадок, расположенных по всей территории страны. Каждая из этих площадок сопоставима по размеру со средним заводом и является отдельным филиалом компании.
-
Кроме этого мы опирались на хорошую организационную дисциплину. Говорили, как лучше делать, а организация не задавала вопрос: «Почему?»
На других проектах в этот момент часто возникают дискуссии: «А у нас такое мнение, у нас такая история…» Но для нас как вендора, когда мы участвуем в подобных проектах, обязательным условием всегда является то, что мы приходим со своими концепциями и методологией, которая заложена в продукт. Мы не изучаем конкретное предприятие, мы предлагаем решения. А руководство предприятия-заказчика должно четко это осознавать и делать выбор из тех решений, которые есть. Мы аргументируем возможный выбор и вместе ищем варианты, но основу составляет именно наше предложение. Таким образом убирается разрыв между чистой методологией и конкретным инструментарием для ее реализации.
Целевая модель в виде базы-прототипа
Все эти условия позволили начать проект в новом формате. Основой нового формата стало создание базы-прототипа.
Прототип – это фактически модель информационной системы для автоматизации производственных площадок на базе выбранного программного продукта 1С:ERP Управление предприятием.
База с настройками по утвержденной модели становится шаблоном. На ней:
-
проверяется исполнимость выбранной методологии управления и ведения учета – при обнаружении неисполнимости методология сразу корректируется;
-
определяются регламенты отражения хозяйственных операций, потому что в коробке программа предоставляет определенную вариативность действий – а здесь все идет очень четко уже под нужды конкретного внедрения.
Предметное наполнение модели (прототипа) происходит по нескольким направлениям:
-
Задаются системные настройки.
-
Происходит установка иерархии справочников для основных объектов учета, отражающих специфику технологических процессов на конкретных предприятиях: Номенклатура, Ресурсные спецификации, НИОКР и Направления деятельности – то, что может существенно отличаться в силу различий в деятельности организаций. На этом этапе не стоит задавать четкую структуру справочников – важно просто задать иерархию, чтобы каждое новое значение ложилось на четко определенное для него место и могло обрабатываться соответствующим образом.
-
Следующее – это иерархия и значения справочников, обеспечивающих основные аналитические разрезы для унификации финансового управления, признания расходов, регламентного отражения, алгоритмов расчета себестоимости (Организации, Структура предприятия, Склады и магазины, Статьи калькуляции, Статьи расходов, Статьи доходов, Виды номенклатуры, Единицы измерения, Политики учета серий, Группы настроек финансового учета и т.д.). Это те справочники, которые задают порядок разузлования сложной продукции до исходных затрат – именно они позволяют одинаково управлять этим процессом при разных видениях бизнеса.
-
И самое главное – это примеры отражения цепочек хозяйственных операций, которые соответствуют принятым в организации регламентам управления.
Внедрение «методом рубильника»
Для внедрения мы выбрали порядок «методом рубильника». Этот метод был придуман не нами – здесь сошлись наши представления и четкое желание заказчика запуститься быстро, потому что отступать было некуда.
«Метод рубильника» представляет собой одномоментный переход без дублирования в системах, которые исторически существовали на предприятии.
-
Мы одновременно запускаем два контура: контур финансовых расчетов и контур материального потока – их нельзя разрывать при запуске. Планирование производства и управление производством можно отложить – можно даже оставить их в тех исторических системах, которые используются на предприятии, обеспечив интеграцию. Зарплата – отдельно, потому что это отдельная задача. Но нельзя разрывать материальный и финансовый поток. Именно они обеспечивают единство алгоритмов расчета себестоимости.
-
Не имеет смысла вести параллельный учет в старой и в новой системе – данные будут заведомо разные. Вы только потеряете время и ресурсы в пиковой нагрузке, нагрузите людей и вызовете недовольство, а результата никакого. Данные заведомо будут другие – вы ничего не проверите.
-
И самый неприятный момент, который, как правило, напрягает управленцев заказчика – это то, что в части управленческой отчетности при запуске будут временные потери, а потом и пересмотр, возможно, некоторых действий. Мы сразу же договорились, что на определенном этапе формирование всей управленческой отчетности, к которой все привыкли, будет недоступно. По практике – сначала пауза, потом пересмотр. После пересмотра из всего количества отчетов осталась, в лучшем случае, где-то четверть. Потому что каждый отчет, по сути, представляет собой определенную идею или методику анализа данных.
-
Целевые параметры аналитики ведения учета закладываются сразу же. А потом постепенно: структура данных, обеспечивающая необходимую аналитику; инструменты анализа, проверки, контроля и так далее.
Жизненный цикл базы-прототипа
Модель информационной базы постоянно поддерживается на актуальном релизе в виде хранилища. Сейчас проекту уже три с половиной года (прим. ред. доклад от 26 мая 2023 года), но модель, которую мы создали на этапе подготовки проекта, до сих пор живет и развивается – я о ней чуть попозже расскажу.
Поскольку в проекте участвовали сотрудники нескольких партнерских организаций и служб предприятий самого холдинга, эта модель стала отправной точкой, которая синхронизировала работу разных проектных команд.
-
На этой единой модели и единых правилах моделировался процесс и отрабатывались связанные вещи, которые потом могли разделяться для разных организаций.
-
При этом сразу проверялось, как один процесс влияет на другой – как одна учетная схема перетекает в другую.
-
Оценивалась возможность отражения хозяйственных операций и получение требуемых отчетных форм – сами формы будем делать потом, но необходимая для них аналитика закладывается сразу.
-
Любой пример всегда считается корректным только при условии полного выполнения процедуры закрытия месяца. Сделали пример – выполните закрытие, чтобы все строчки в закрытии месяца стали зелененькие. Если не стали зелененькие, значит, что-то делаете не так – дальше эта ошибка начнёт разрастаться как рыбий хвост.
-
По итогам моделирования мы должны регистрировать функциональные разрывы и их отрабатывать.
-
В пользовательских инструкциях описываются только те скрины, которые созданы на основе примеров модели информационной базы. Любое дополнение, возникающее на текущем этапе, сначала отрабатывается на этом прототипе, потом пишется инструкция и отдаётся в работу.
На слайде показан процесс трансформации модели информационной системы.
Утверждённая модель на этапе до запуска раскладывается на:
-
отдельную базу, в которой хранится централизованная НСИ;
-
и хранилище, в которое идут все обновления, доработки и всё остальное;
Из хранилища получаются рабочие базы, которые мы используем на этапах запуска системы, переноса остатков и доведения до пользователя.
И параллельно идёт процесс поддержания прототипа в виде актуальной модели, где отрабатываются учётные принципы и происходит всё обучение пользователей.
Схема работает и на этапе эксплуатации системы, отрабатывая через доработки все изменения законодательства и требования бизнеса на всём протяжении жизненного цикла системы.
Т.е. эта схема в таком состоянии у нас и сейчас работает. То, что было создано три с половиной года назад, сейчас поддерживается в актуальном состоянии и продолжает работать именно так.
Синхронизация работы разных проектных команд
На слайде показан состав рабочей команды проекта. У структуры этой команды была особенность – обычно на проекте делается упор на ИТ, но здесь ситуация была несколько иная.
-
Был определен отвлечённый руководитель проекта Климова Оксана Александровна, которая отражала методическую составляющую. Под ней была создана методическая группа ТМХ, участником которой был, в том числе, и я.
-
И существовал технический блок, которым руководил Ушаков Анатолий Анатольевич – это руководитель ДИТ ТМХ.
В такой структуре рабочей команды проекта было четко отражено первенство методологической составляющей при решении вопросов. Оксана Александровна занималась проектом именно с точки зрения предметной части. А Анатолий Анатольевич решал все сопутствующие варианты технической поддержки. Получилась очень хорошая совместная работа – именно она привела к тому результату, который мы сейчас имеем.
Также я хотел бы высказать слова благодарности компании «Борлас» – за волю к победе и командную работу. И хочу особенно поблагодарить профессионализм, самоотверженность, трудолюбие сотрудников компании КРОК. А также руководство этих компаний – за очень чёткое, хорошо организованное взаимодействие с нами как с вендором по совместной работе. Потому что организовать работу многих людей с разными укладами и привычками на одну цель сложно, но это удалось.
Объединяя разные усилия, мы, в том числе, использовали базу-прототип. Каждый вносил свой кусочек. Допустим, один человек вносил в базу пример для отработки регламента, а другой независимый человек уже писал инструкцию.
Т.е. связующим звеном организации всех работ такого разношёрстного коллектива была именно общая цель – создание прототипа.
Трехуровневая поддержка и система обучения сотрудников
Дальше – обучение.
-
На первом этапе 150-200 сотрудников заказчика прошли стандартные курсы: «Концепция ERP», «Управленческий учёт затрат в ERP» и частично «Регламентированный учёт в ERP».
-
Дальше, когда мы начали разрабатывать на типовой конфигурации реализации новых учётных механизмов, специфичные для холдинга – по этим доработкам были записаны отдельные курсы и учебные семинары.
-
Также мы собрали все пользовательские инструкции с примерами отражения хозяйственных операций на едином информационном портале, куда пользователь имеет доступ. И на этом же портале в режиме просмотра находится доступная демобаза – база прототипа, созданная под этот проект, с примерами. Потому что в пользовательской инструкции, даже содержащей много скриншотов, очень сложно показать все имеющиеся параметры. А в базе человек может открыть инструкцию и посмотреть, как заполнены все поля, какие у документа зависимости, как формируются связанные документы. Здесь система работает именно на передачу информации новым сотрудникам. Потому что это не просто большое предприятие – там количество предприятий измеряется практически десятками и сотнями. Ротация сотрудников очень большая, квалификация исполнителей низкая – надо постоянно поддерживать. Поэтому изначально была продумана многоуровневая система обучения пользователей.
-
Система поддержки пользователей тоже была спроектирована изначально, потому что сначала наше участие в проекте планировалось в рамках передачи компетенций родственной для ТМХ компании – франчайзинговой фирме ПИИТ. При завершении проекта компании сдают работы, и уже сам заказчик дальше продолжает обслуживание системы – все обновления, все доработки выполняются уже специализированной фирмой ПИИТ. Это внутренняя служба заказчика – практически ИТ-отдел, только большой. В техподдержке пользователей – три уровня:
-
Консультации на рабочих местах оказывают ИТ-отделы и партнеры на предприятиях, которые разбросаны по всей стране.
-
Если вопрос не может быть решен, он поднимается на уровень ПИИТ.
-
И если ПИИТ не отвечает, вопрос поступает на уровень методической группы ТМХ, созданной на этапе проекта – она рассматривает особо сложные случаи, используя, в том числе, нашу методическую поддержку.
-
Хронология запуска внедрения на площадках холдинга
Инфографика проекта.
-
На предприятиях пилотной группы мы запустились без дублирования 1 января 2020 года – запуск провели на версии 1С:ERP 2.5.3.
-
Фактически весь первый квартал мы занимались отработкой учетных схем и донастройкой системы – те вещи, которые просто не успели охватить или где просто что-то упустили.
-
Полноценный переход на регулярную сдачу отчетности и закрытие месяц в месяц для этой пилотной группы выпали где-то на июнь.
-
За эти полгода мы провели очень большую работу по оптимизации производительности.
Достижения первых месяцев работы в системе:
-
«Естественное» выявление проблемных участков бизнес-процессов. Мы не ставили задачу искать финансовые огрехи, экономические провалы – мы запускали систему по уже устоявшемуся алгоритму, и она сама показывала нам организационные и операционные проблемы.
Большое спасибо руководству ТМХ за то, что оно не прятало голову и не говорило: «Да, у нас всё так заведено» – оно эти моменты исправляло. И взаимодействие с заказчиком – это, наверное, самый большой залог успеха того, что произошло. -
Корректные остатки на складах. Мы полностью ограничили внесистемную работу – все операции отражаются через систему.
-
Исключили борьбу производственной системы и финансового контура за достоверность данных – перестали тратить время на выяснение, кто прав. Нет такой проблемы. Система одна, правда одна.
-
Приняли аргументированные решения по составу доработок, потому что это наиболее дорогая часть внедрения.
Сложности такого большого массового запуска – стандартные. Но у нас было, на что опереться – это целевая модель в виде базы-прототипа и поддержка со стороны собственника.
Инфографика проекта пошла дальше.
-
В октябре 2020-го года был определён состав второй очереди, в который вошли все производственные площадки объединённого холдинга. Если запуск пилотной зоны мы делали фактически 9 месяцев, здесь мы уложились в 6 месяцев.
-
Мы начали в ноябре-декабре – провели обучение, подготовили запуск второй очереди, ввели остатки уже по отработанным механизмам переноса остатков.
-
В январе запустили систему без дублирования на версии ERP 2.5.5.
-
И на регулярную сдачу регламентированной отчётности из системы мы вышли в апреле 2021-го года. Т.е. фактически за полгода запустили десятки промышленных предприятий полностью по тем схемам, которые были отработаны в рамках пилотной зоны.
-
И сейчас идёт сопровождение системы, актуализация релизов, методическое развитие, запуск системы в новых организациях. Потому что ТМХ-Холдинг – это не только производственные площадки, это и торговые дома, инновационные организации. В них тоже работает единый шаблон – единая корпоративная учётная политика.
Рекомендации
При определении функциональных границ начального запуска нужно внимательно учитывать сложившуюся на предприятии ситуацию:
-
Объединять в проекте на запуск ERP контур управления производством и финансовый контур можно только при наличии формализованных и устоявшихся регламентов планирования производства. Потому что для планирования производства нужна достоверная обратная связь, а её обеспечивает материальный поток по принципам бухгалтерского экономического анализа. Хотите себестоимость – заложите её изначально. Детализация аналитики тоже закладывается изначально.
-
Мы не использовали типовую систему планирования производства в ERP – на конфигурацию была перенесена система, которая сложилась в ТМХ и в ЛокоТехе естественным образом. Мы не против таких подходов, потому что технология управления производством – это действительно то уникальное, что характеризует конкретное предприятие. А вот финансовые, бухгалтерские подходы, регламентированный и раздельный учет – они стандартизованы и унифицированы.
Еще одна рекомендация – не нужно упрощать.
-
Мы подходили к этому проекту комплексно и универсально, но мы это делали именно за счет совершенствования сервисов и за счет первоначальных ограничений по отчетности. Мы не ограничивали аналитику и структуру данных.
-
Не нужно делать «простой» запуск. Запуск должен быть спроектирован системой полноценно – должны быть запущены те контуры, без которых невозможно обеспечить логическую целостность системы. Исходя из этого результата, в качестве развития системы уже строить дальнейшее углубление процессов: в ремонтах, в управлении производством, в задачах обеспечения и других.
-
Самое главное – выбранная методика внедрения не должна растягиваться на года. Даже для большого предприятия при правильной организации работы достичь результата можно за 9-12 месяцев.
Я вам искренне желаю таких же успехов на этом пути.
Вопросы
Можете рассказать про техническую составляющую проекта? Все-таки у вас 60 тысяч пользователей, как это запущено на практике? Это десятки кластеров или единое облако?
Я больше все-таки не технический специалист, а предметный, больше занимаюсь организацией проектной деятельности, но в меру своих компетенций расскажу.
Так как в холдинг входят предприятия разноплановые, с разным ведением бизнеса, то при выборе целевой архитектуры мы пришли к выводу, что невозможно организовать все в одну базу, из которой было бы удобно брать информацию.
Мы пошли по пути шаблонного решения:
-
создали шаблон, в который определили единую корпоративную учетную политику бухгалтерского учета, и она три с половиной года неизменна – мы правильно ее определили;
-
определили набор централизованных справочников, которые задают значения аналитических разрезов – здесь предприятия не имеют свободы действий.
Но на локальных площадках больших предприятий – таких, как Тверской завод, ЛокоТех-Сервис – стоят отдельные базы. Они обновляются из общего хранилища, из общего шаблона. В каждой базе есть особенности по организации системы планирования производства. Но производственный учет и все, что дальше – однотипное.
По поводу обновлений:
-
отдельно идет обновление из хранилища всех баз заводов по изменениям конфигурации;
-
и отдельно – обновление значений централизованных справочников.
Есть небольшие предприятия – торговые дома, инновационные компании. Они могут вести учет в одной базе.
РИБ не используется – это самостоятельные локальные базы, размещенные у большинства заводов на собственных площадках.
Для консолидации данных используется «Управление холдингом». Это отдельная задача бюджетирования. Данные выгружаются, поднимаются на «Управление холдингом», причем не важно, в каком месте они находятся.
Технически доступ к системе организован по-разному – есть рабочие места, которые подключаются через интернет, есть и просто локальные подключения. Все зависит от того, где находится конкретное место.
60 000 пользователей – это общий объем пользователей, которые обслуживаются системой по единым правилам, но это не 60 000 пользователей в одной информационной базе.
Количество пользователей в самой большой информационной базе – у ЛокоТех-Сервиса – порядка 10-15 тысяч. Они работают в разных временных поясах – у них 90 производственных площадок.
Время операции расчета себестоимости в закрытии месяца – 24 часа. И это очень неплохой результат, потому что количество выпусков, определяющих вычислительную нагрузку, определяется именно размером графа распределения. Мы считаем, что для таких объемов – это очень хороший результат.
Чтобы этого добиться:
-
Мы оптимизировали платформу. Участие фирмы «1С» позволило разработчикам платформы видеть, как используется их продукт на реальных данных. За период нашей работы над этим проектом было выпущено три версии новой платформы со всеми нашими изысканиями – с 8.3.19 по 8.3.21.
-
Параллельно мы оптимизировали алгоритмы расчета себестоимости непосредственно в ERP – мы фактически на реальных данных проверили те решения, которые закладывались в платформу и в конфигурацию.
-
Плюс оптимизировали именно экономическую модель для использования.
Вот три направления, которые позволили нам бороться за производительность.
А технические аспекты – кластера и все остальное – я сейчас не буду затрагивать, это немного не моя тема.
*************
Статья написана по итогам доклада (видео), прочитанного на конференции Анализ & Управление в ИТ-проектах.
