ПМТ – это дочернее предприятие компании «Аскона». Мы производим мягкую мебель, текстиль для спальни и корпусную мебель для дома и офиса.
Компания ПМТ представляет собой вертикально интегрированный производственный холдинг:
-
У нас 10 производственных площадок по Владимирской области: семь из них находится в городе Ковров, три – во Владимире.
-
На производстве работает 3000 сотрудников.
-
Мы выполняем около 6,5 млн производственных операций в месяц.
-
В день выпускаем 10 000 единиц конечной продукции.
-
На текущий момент (май 2021 года – прим. ред.) объем базы данных – около 800 Гб.
Расскажу чуть более детально о масштабах проекта:
-
Поскольку мы многопередельная компания, у нас выпускается сырье и полуфабрикаты для продукции разных юрлиц, с которыми мы сотрудничаем. В день выпускается порядка 70 тысяч единиц сырья и полуфабрикатов в день (и порядка 21 млн в год).
-
Порядка 10 тыс. единиц в день – это готовая продукция.
-
Ежедневно нам нужно закрывать и выполнять порядка 20 тысяч этапов.
-
Итого в системе ежедневно отражается порядка 300 тысяч операций.
Начало проекта
Когда мы пришли в этот проект, у нас было пять баз УПП, где были сгруппированы несколько похожих производств. УПП было внедрено собственными силами – сами учились и внедряли. В этом были как преимущества, так и недостатки – где-то мы не использовали типовую функциональность, поскольку не знали, как это работает, использовали вместо этого какие-то дописки, какие-то вещи делали с нуля.
В итоге пришли к тому, что УПП нужно было очень активно развивать, поскольку требования к отслеживанию, к детализации и ко всему остальному серьезно выросли. Стали рассматривать возможность внедрения новой системы, потому что требовалось:
-
Детально отслеживать бизнес-процессы на каждом этапе: где достаточно сырья, как происходит выпуск, все ли выпустили и пр.
-
На основе существующих данных нужно было иметь возможность принимать управленческие решения – корректировать материалы, которые используем, менять и оптимизировать какие-то операции.
-
Нужно было оперативно получать детализированную себестоимость по материалам, труду, по использованию оборудования.
-
Сдельная оплата труда должна была полностью рассчитываться в системе. До этого у нас учет велся в Exel и никак не «бился» с реальным выпуском, т.е. не было возможности сопоставить, сколько же реально стоит каждое изделие. Теоретически по нормам и всему остальному мы понимали, сколько все стоит, но в общем масштабе сопоставить все операции было невозможно.
-
Также было необходимо создать ARM-ы, чтобы сотрудники могли работать в системе удобно, наглядно и не ошибаясь.
То есть цели были весьма типовыми.
Основные требования к внедряемой системе выделены на слайде жирным цветом. Расскажу, какие у нас были ожидания от внедрения:
-
Поскольку наша система состоит из 10 юридических лиц – 10 заводов, объединенных в холдинг с управляющей компанией, нужно было, чтобы система это поддерживала.
-
Изначально планировалось, что на базе производства будет создана еще и собственная розничная сеть, поэтому мы хотели иметь в системе дополнительно CRM блок и развитый блок для автоматизации розничной торговли.
-
Требовалась поддержка сложной системы разузловки заказа с учетом нескольких производств – типовая 1С:ERP и на текущий момент это не очень позволяет. Мы это доделывали сами.
-
Функциональность по управлению логистикой и закупками нас устроила типовая – мы совсем немного ее доработали под себя.
-
Параметрические ресурсные спецификации. Мы начинали проект, когда ERP была в версии 2.2, там параметрика была очень ограниченной. Потом появилась версия 2.4 с новыми возможностями – мы на нее в процессе проекта переходили, переписывая все, что сделали до этого с параметрикой. Плюс мы достаточно много параметризировали операции и труда – создавали это сами. Мы шли чуть быстрее фирмы 1С – в типовой ERP эти функции частично реализовали только в версии 2.5.
-
Требовалось иметь в системе достаточно развитую систему резервирования всех видов сырья, полуфабрикатов и готовой продукции под заказы клиентов.
-
Многоуровневое планирование. У нас собственный подход к планированию, он совсем не похож на типовой. У нас централизованный отдел планирования, который планирует производство и закупки для всех подразделений и цехов. Внутри цеха планирование происходит уже только внутри смены – решается, что выпускать в первую очередь с учетом поставленного плана.
-
Сдельная оплата труда. Хотелось, чтобы ее можно было отнести на конкретное изделие и понять общую сумму, которую мы потратили на зарплату, и чтобы было детально и четко понятно, как она отнесена на изделие.
-
И, естественно, нужна была отчетность, чтобы мы детально видели и понимали, что и как работает. В результате в системе нами самостоятельно были разработаны, настроены и сделаны тысячи отчетов.
На слайде перечислены подсистемы из 1C:ERP, которые мы внедрили – из основных типовых блоков 1С:ERP мы не внедрили только «Управление ремонтами» и «Управление взаимоотношениями с клиентами». Все остальные блоки были внедрены – проект был достаточно масштабный.
Очень много внимания уделили:
-
Управлению финансами
-
Казначейству
-
Управлению НСИ
-
Производству – это наш основной процесс
-
Блокам регламентированного учета, управления персоналом и расчета заработной платы – все эти процессы мы тоже ведем внутри нашей системы.
Подготовка к запуску
На слайде показано, как выглядел план-график, когда мы подходили к процессу.
Все по классическому подходу – обследование, моделирование. Заключили договор с подрядчиком, начали обследование, но в процессе пришли к выводу, что что-то идет не так – подрядчик недооценил объем и масштабы.
Было принято решение перевыбрать подрядчика и начать заново.
Так выглядел план-график с новым подрядчиком. Произошел сдвиг практически на год – пока мы сделали обследование, пока выбрали нового подрядчика…
-
В 2017 году мы начали с этапа моделирования, параллельно доуточняя обследование – эти два этапа продлились полгода. Сначала мы промоделировали небольшой кусочек, чтобы понять, насколько нас устраивает новый подрядчик. Потом за четыре месяца смоделировали всю систему и получили карту функционального покрытия – насколько я помню, у нас было зафиксировано порядка тысячи функциональных разрывов.
-
Дальше примерно полгода заняли проектирование, разработка, настройка, тестирование.
-
Потом – обучение.
-
Изначально мы планировали запуститься в январе 2019 года, и это должен был быть единовременный запуск. Скорее всего, нас ждал бы крупный провал, после которого пришлось бы откатываться назад. Но нам повезло, так как наши технологи и конструкторы, которые вводили в систему параметрические спецификации, просто не успевали, несмотря на то, что мы их усиливали. Это нам позволило увеличить длительность этапов – не было бы счастья, да несчастье помогло. И нормативная версия была готова только к марту.
-
В апреле мы еще раз протестировали все доработки и доделали все, что хотели доделать.
Запуск проекта
Поскольку у нас произошли изменения сроков, мы начали запускать проект частями.
-
Первую компанию запустили в мае.
-
Следующее юридическое лицо запустили в июне.
-
В июле запустили еще несколько юрлиц.
-
В августе мы запустили в функциональную эксплуатацию уже самые крупные предприятия и производства.
Изначально по проекту мы не планировали этап сопровождения, думали, что за месяц сможем стабилизировать систему. Но поскольку запуск был поэтапным, по факту нам понадобилось сопровождение в больших объемах все эти месяцы (май, июнь, июль, август) и около трех месяцев после запуска – пока мы не набрали собственную экспертизу и людей в команду.
Картинка показывает наш путь на этом проекте. Отражает, как мы двигались, какие у нас были ожидания и какие перегибы у нас происходили (с подрядчиками, с выбором, с техническим сложностями, которые мы встречали).
Сейчас мы находимся где-то на этапе последней пологой прямой – как только мы все требования бизнеса удовлетворим и все пожелания сделаем, будет полное счастье.
Риски и сложности
Расскажу про риски проекта, которые были зафиксированы в проектной документации – как мы их оценивали на начало и на конец проекта.
Одним из самых основных рисков у нас был НСИ, и он еще больше выстрелил, так как оказался наиболее сложным и наиболее тяжелым для создания, восприятия и переделывания. В нем было самое большое количество ошибок и самое большое количество функциональности. Многие из доработок мы не планировали, но нам их пришлось сделать для автоматизации работы конструкторов и технологов. Пришлось зашить туда много проверок для контроля над тем, что они делают.
Мы очень сильно недооценили быстродействие системы. Типовые механизмы 1С:ERP при тех масштабах и объемах, про которые я рассказывал, работают слишком долго. Нам не удалось кардинально улучшить их быстродействие даже при том, что мы работали со специализированным подрядчиком, который поддерживал производительность системы, помогал в настройке SQL-сервера и по проблемам с ним.
Условно говоря, для небольших производств, где количество этапов и операций маленькое, это работает нормально. Но когда за смену выпускается несколько тысяч изделий, и тебе нужно массово закрыть сменные задания, где для каждого изделия – пять-шесть операций, то при закрытии приходится проводить десятки тысяч документов. Это занимает много времени.
Нам пришлось очень долго заниматься оптимизацией с точки зрения параллельного проведения, параллельного закрытия и распараллеливания этих процессов, чтобы каждая операция и этап проводились быстрее. Фирма «1С» обещала нам, что этап будет проводиться по одной секунде, а операция еще быстрее. Но все, чего нам удалось добиться, даже глобально отключая серьезные пересчеты, которые там происходят – это 2-3 секунды на этап и порядка 1,5-2 секунд на операцию. В какой-то момент смогли довести обработку одной операции до 1 секунды.
Очень ждем, когда фирма «1С» переведет операции в регистр сведений, как они обещают, тогда операции не нужно будет проводить, и это должно будет кардинально ускорить работу.
Мы очень высоко оценивали риск мотивации на обучение и работу в переходный период, но здесь нам повезло с нашей внутренней командой. Наверное, сказались те меры, которые мы приняли после оценки этого риска. Мы добавили дополнительных людей, замотивировали их – сделали на их работу премиальный фонд.
Мы много коммуницировали. Все понимали важность этого проекта, генеральный директор много участвовал в проекте: минимум раз в месяц проводили общее собрание с участием генерального директора, где он участвовал и не только высокоуровнево смотрел на процесс, но и глубоко погружался в мелкие проблемы и разбирал их.
Изначально очень много людей пыталось саботировать внедрение из-за отсутствия времени: «Это ваш проект, только ИТ-отделу это нужно». Но участие генерального директора помогло изменить этот подход и глобально погрузить людей в процесс внедрения. В какой-то момент количество перешло в качество, люди поняли, что проекту быть и от него никуда не деться.
Достаточно много мы сталкивались с ошибками системы. Мы были одним из первых масштабных проектов – масштабным по объему, по количеству процессов, по сложности производства, которое у нас было. Зачастую система работала нестабильно, нам удалось стабилизировать ее только к 2020-му году.
Чуть подробнее об организационных проблемах, которые мы зафиксировали по итогам проекта.
-
Сроки проекта мы увеличили на 5-6 месяцев;
-
Стоимость проекта увеличилась в 1,5 раза. Изначально, когда мы проводили оценку проекта, считали, что во всех производственных предприятиях процессы будут идентичными. И исходя из этого, на моделировании подрядчик и мы оценивали количество доработок и всего остального. После моделирования выяснилось, что каждое производство работает немного по-своему: и планирование имеет свои особенности, и само производство требует свою отчетность, свои настройки, и у НСИ есть свои особенности и т.д. Это увеличило количество доработок, которые нам необходимы, и стоимость проекта;
-
У нас внутри практически отсутствовал опыт. Человек с опытом ERP появился ближе к запуску, когда мы поняли, что рано или поздно нам нужно будет поддерживать систему и мы начали набирать людей;
-
У людей, которые формулировали запросы, в процессе изменились требования. Люди сначала рассказывают одно, потом пожелания изменяются, приходится функциональность дорабатывать и переделывать.
-
В процессе проекта у нас изменились ключевые функциональные заказчики – поменялось три главных бухгалтера, два финансовых директора и кадровая служба, что не добавило нам стабильности к требованиям и всему остальному.
-
Одна из больших ошибок (и это, наверное, в том числе и моя ошибка) была в том, что мы пытались получить результат очень быстро, используя подход «Все и сразу». Сразу получить все блоки, запустить сразу всю функциональность, в том числе и не основную, которую можно запускать позже (например, автоматизация закупок, работа с резервами и т.п.). При таких масштабных проектах более правильно сделать ядро и потом делать дополнительно небольшие проекты – когда люди уже научатся, поймут, как они работают. Это позволит сохранить и деньги, и сроки, и нервы. Потому что чем больше охват, тем сложнее этим всем управлять, тем больше проблем возникает так или иначе.
Технические проблемы, которые возникали при работе системы.
-
Работали с блокировками: где-то их отключали, где-то переписывали код, где-то меняли логику, переписывали функциональность с табличных частей документов на регистры.
-
Оперативное планирование, объемно-календарное планирование, выпуск, закрытие смены и задание, отражение взаиморасчетов, закрытие месяца – сильно переписывали с точки зрения включения параллельности. Там, где можно, мы везде пытались включать большую параллельность и ускорять процесс.
-
Тяжелые операции, которые были не очень оптимально написаны, вызывали серьезное торможение интерфейса у пользователей. Боролись с этим, и в какой-то момент благодаря развитию платформы, переходу с версии на версию мы получили более стабильную систему. И сейчас даже если какой-то процесс работает не очень оптимально, на все остальное это влияет гораздо меньше.
-
Нестабильное выполнение массовых запросов SQL. Иногда мелкие запросы, которые обычно выполняются в доли секунды, вдруг начинали выполняться десятки секунд. Когда таких запросов сотни тысяч, система вставала. Выяснялось, что слетела статистика. В поиске причин, почему она слетела, нам помогал наш подрядчик и мониторинг, который мы делали.
-
Вначале мы использовали полностью виртуализированную инфраструктуру и имели проблемы со скоростью работы СУБД, в том числе, необъяснимые. Когда обычно операция выполнялась секунду, а в какой-то момент начинала занимать 2-3 секунды – для массовых процессов это достаточно долго. Когда мы перевели MS SQL на физический сервер, количество таких проблем уменьшилось. Плюс, мы ускорили производительность за счет нового физического сервера.
-
Были и ошибки в типовом коде, которые нам приходилось править. Зачастую мы даже не пытались объяснить 1С эти ошибки, а вставляли «заплатки» и корректировали самостоятельно. Не было времени и возможности что-то доказывать и объяснять, нам нужно было работать и двигаться дальше.
-
Большое количество ошибок в НСИ. Это тот блок, который мы сильно недооценили. Пришлось сильно дорабатывать функциональность, чтобы перед каждым планированием запускалась проверка НСИ на корректность, связность и т.д. – мы сделали достаточно большой объем работы.
-
Проблемы с обменами со сторонними системами (неоптимальные порции, высокая нагрузка). Основных крупных заказчиков у нас примерно десяток. И с каждым из этих заказчиков настроена интеграция от получения заказа, передачи статуса того, что с заказом происходит, до передачи товародвижения, т.е. как товар дойдет до заказчика. Где-то используется ЭДО, где-то EDI, где-то более низкоуровневая интеграция. Объемы большие, и были проблемы, которые приходилось переделывать.
-
Ну и, естественно, ошибки, которые делают программисты в коде, никуда не деваются, и с ними приходилось работать. В какой-то момент мы пришли к выводу, что нам нужен SonarQube. Мы внедрили SonarQube – нам это позволило улучшить качество написания кода, его читаемости и изменить подход программистов. SonarQube требует подходить к написанию кода более структурированно, поэтому количество ошибок значительно снизилось.
С августа 2019 года (с момента запуска) мы начали считать, сколько мы платим подрядчикам за техподдержку.
В августе 2019 года количество заявок было более 2500. Затем мы вышли на пик порядка 1000 заявок в месяц – на графике показано, как менялось распределение заявок между нами и подрядчиками.
Мы учились, набирали персонал, и это позволило нам контролировать систему самим и снизить затраты на подрядчиков.
Одна из глобальных проблем, с которой мы очень долго боролись – это закрытие месяца. Сначала месяц вообще не закрывался, потому что мы постоянно правили НСИ и др. Затем мы эту операцию плотно и детально оптимизировали – где-то вводили параллельность, где-то плотно работали с фирмой «1С», и в результате дошли до стабильного результата.
С точки зрения скорости, например, компании «Литвуд», «Полиформ Трейд» и «ФомТех» объединились. Сейчас они закрываются около суток, но поскольку это закрытие идет стабильно и каждый раз выполняется без ошибок, то проблем нет. Но изначально, когда мы делали запуск, были проблемы со стабильностью – закрытие шло 12 часов, но успешно оно завершалось лишь один раз из пяти. Найти ошибку в таком масштабном закрытии – серьезный челлендж.
Здесь перечислены обмены, которые у нас есть:
-
Полный обмен с Галактикой через Rabbit MQ,
-
ЭДО/ЮЗДО, EDI – Диадок,
-
Директум.
В системе хранится финансовый архив: сканы и образы всех товарораспределительных документов, включая документы из ЭДО и ссылки на них.
В какой-то момент мы тестировали программную роботизацию и часть процессов успешно запустили. Бухгалтерия была очень довольна.
Кратко про архитектуру проекта:
-
Единая база банных НСИ по всем производствам.
-
Терминальный доступ.
-
Интеграция со внешними системами через Rabbit MQ.
-
«Распределенка» при помощи решения SOFTPOINT DB Replication. То есть SOFTPOINT не только поддерживал нас по производительности, но мы еще использовали их решение по разделению базы данных, по шардингу – нам это позволило быстрее двигаться на запуске.
На слайде приведено оборудование, которое мы использовали. Сначала была виртуализация, но на момент старта мы уже пришли к тому, что нужен физический сервер.
На текущий момент у нас три физических сервера:
-
на двух серверах работают сервера приложений – они достаточно хорошо параллелятся;
-
и на третьем физическом сервере размещен MS SQL – сейчас база занимает уже почти 1Тб памяти.
Результаты
На слайде показан экономический эффект, который мы заявили на конкурсе «Проект года» фирмы «1С» – ускорение отчетности, сокращение трудозатрат, снижение себестоимости за счет управляемости.
Здесь перечислены результаты проекта – нам удалось решить большинство изначальных задач.
Фирма «1С» признала нас проектом года 2019 в предметной области «Комплексное управление ресурсами предприятия (ERP)».
Сообщество профессионалов Global CIO тоже признали нас проектом года.
Признание – это «вишенка на торте», которую мы получили на фоне всего остального.
Вот так выглядела структура отдела разработки и эксплуатации платформы 1С на момент, когда мы поддерживали УПП. У нас в штабе было всего 8 человек, которые так или иначе поддерживали систему и около 10 человек на аутсорсе.
На этапе, когда мы уже вышли из проекта, работало уже около 23 человек и примерно 10 человек которые с нами постоянно работают на аутсорсе. Это – структура, которая нам позволяет двигаться и развиваться.
Уже собственными силами нашей команды мы реализовали некоторые проекты, которые перечислены в этом слайде.
Дальнейший процесс стал уже гораздо более гладким, т.к. люди уже достаточно хорошо понимали систему.
Мы работаем в Jira, используем базу знаний в Confluence.
У нас Agile-команды, где аналитики распределены на группы по три человека. Каждая задача обсуждается отдельно, программисты привлекаются в эти группы и решают задачи.
*************
Статья написана по итогам доклада (видео), прочитанного на конференции Infostart Event.
Приобретайте 1С:ERP в Инфостарт с бонусом 15%!
- Бесплатное демо продукта и консультация
- Команда экспертов 1С с опытом 10+ лет
- Оценка проекта, четкий план работ, документация, обучение и поддержка
Закажите расчет внедрения ERP - получите дорожную карту в подарок!
Внедрение 1С:ERP
Комплексное внедрение 1С:ERP на любое предприятие для повышения прибыльности и производительности компании