Как внедрить 1С:ERP за 2 года и не сойти с ума

ПМТ – это дочернее предприятие компании «Аскона». Мы производим мягкую мебель, текстиль для спальни и корпусную мебель для дома и офиса.

Компания ПМТ представляет собой вертикально интегрированный производственный холдинг:

• У нас 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.