Импортозамещение. Перевод промышленного предприятия с M3 Infor на 1С:ERP за 2 месяца по технологии SCRUM

Меня зовут Дмитрий Изыбаев, я заместитель руководителя дивизиона и по совместительству руководитель проектов. Автоматизацией я занимаюсь более 15 лет, из них 10 лет – на платформе 1С.

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

Это кейс о том, как за два месяца запустить крупное промышленное предприятие на платформе 1С.

Все началось с того, что ко мне подошел наш менеджер отдела продаж и говорит: «Пойдем, внедрим ERP за два месяца на крупном производственном предприятии».

Я ему сказал: «Артем, вон там дверь, иди закрой с той стороны и не отвлекай меня». Но у нас продажники – довольно настойчивые ребята, и он меня все-таки убедил: «Давай хотя бы съездим, познакомимся с клиентом – узнаем, откуда такая срочность, в чем суть проекта вообще».

Оказалось следующее. Дело было в феврале 2022 года. В связи с известными событиями шведский собственник выходил из бизнеса. Программа, которая работала на производственном предприятии, была шведская. Он сказал: «Я ухожу и программу с собой забираю».

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

Адаптируем 1С:ERP под существующие бизнес-процессы компании за два месяца. Что на входе

При первом знакомстве с клиентом мы смогли выяснить следующее.

• У клиента была внедрена система M3 Infor. Причем она была значительно адаптирована под специфику предприятия. Программа была внедрена на группе заводов (там восемь заводов по всему миру). Ее очень много лет затачивали, разрабатывали функциональность по планированию, по вводу начальных данных, оттачивали каждую операцию. Поэтому она была очень узкоспециализированная.

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

• Планирование производства и закупок частично велось в Excel, частично – в программе, но оно было, были отработаны действующие процессы. Планирование велось на месяц, на квартал, на год вперед.

• Функциональность по контролю качества практически полностью велась в Excel. Предприятие выпускало высокопрочный крепежный инструмент, проще говоря, болты для конвейера ГАЗа. А конвейер ГАЗа предъявляет очень высокие требования к контролю качества. По сути, мы для любого болта точно должны знать, из какого металла он сделан, из какой партии, какой сотрудник его делал. Это все вели в Excel.

• Предприятие выпускало порядка 200 SKU различной готовой продукции. При этом они использовали 7500 инструментов. То есть всего 200 позиций и 7500 инструментов, чтобы их произвести. Причем большую часть инструментов они производили сами – это различные резцы, муфты и другие инструменты. В связи с этим у них было порядка 10000 действующих спецификаций, потому что и готовую продукцию, и инструмент можно произвести по-разному.

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

• И их обслуживало восемь ордерных складов с ячеистым хранением. Что самое интересное, у них была очень хорошо организована и отлажена процедура работы со складами. Было четко прописано, где что лежит, как располагаются ячейки. Даже если сотрудник попытается совершить ошибку, ему система подсказывала. И они уже привыкли к тому, что достаточно дать сотруднику задачу, и сотрудник особо голову не включает. Он точно знает, куда идти, откуда и что забрать, как и где разместить – это система подсказывала ему сама.

Входящие требования к тому, чтобы перейти на ERP-систему, были очень высокие. Нельзя было просто поставить коробочное решение и сказать: «Вот ERP-система, пользуйтесь».

Совместно с заказчиком мы сели и стали думать – как же нам вообще выйти из этой ситуации и за такой короткий промежуток времени хоть что-то запустить?

Было однозначно понятно, что запустить полностью всю функциональность за такое короткое время нереально, и заказчик это адекватно понимал. Не было такого, что: «Через два месяца у меня все должно быть идеально с бантиками, с кружочками». Нет, он нормально и адекватно подошел к этому. Мы стали с ним вместе обсуждать, как же будем это делать.

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

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

• Тогда мы стали фантазировать и придумывать некую новую технологию, как же нам выкрутиться и за два месяца запустить этот проект. У нас получилась смесь всех известных нам технологий – что-то наподобие SCRUM+ТБР.
  Почему именно SCRUM? Мы с заказчиком договорились, что мы как исполнители будем в большинстве своем выступать разработчиком какого-то готового решения. Так как очень мало времени, мы договорились, что заказчик будет, по сути, внедрять его сам. Мы ему даем готовое решение, рассказываем, как им пользоваться, а он прикладывает максимальные усилия, чтобы это запустить.

О чем мы в конце концов договорились с заказчиком:

• Понятно, что проект был крайне высокорискованный. Поэтому, чтобы подстраховать себя, мы договорились, что работаем двухнедельными спринтами и, по сути, закрываемся двухнедельными актами. Мы раз в две недели подготавливали рабочие отчеты, выставляли акты, а они оплачивали эти акты. За счет этого мы смогли хотя бы как-то себя обезопасить. Чтобы не получилось, что мы два месяца рвём себе все неприличные места, а нам за это еще и не заплатят.

• Чтобы уложиться в срок, мы изначально с заказчиком договорились, что будем вести ежедневные планерки. У нас было зафиксировано время: ровно в 09:15 вся наша команда и все специалисты заказчика (порядка 7 человек) собирались в отдельной комнате и проводили быструю планерку. Отчитывались: кто что делает, кто что вчера сделал, какие задачи сейчас в приоритете, какие возникли проблемы, какие нам нужны сотрудники, в какой момент.

• Мы договорились, что заказчик окажет нам максимальную вовлеченность в проект. Поэтому на этих ежедневных планерках мы четко говорили: «Нам нужен сотрудник отдела планирования сегодня на два часа». Они смотрели свое расписание и говорили: «Окей, с 10 до 12 он полностью ваш». Или мы говорили: «Нам нужен сотрудник со склада, причем надолго». Нам говорили: «Окей, сегодня за него поработает другой. Этот сотрудник полностью ваш».

• Но и заказчик со своей стороны выдвинул довольно жесткие требования. Он понимал, что на типовой системе ERP они не взлетят. И нам поставили очень жесткое условие: мы не переводим предприятие на ERP, а подстраиваем ERP под бизнес-процессы компании. Нам нужно было за довольно короткое время разобраться, как работают процессы компании и адаптировать ERP под это.

• Загрузку НСИ, документов, остатков мы начали буквально с первого дня. Выловили айтишного специалиста со стороны заказчика, выделили своего отдельного программиста, посадили их вместе и сказали: «В ближайшие два месяца вы – лучшие друзья. Занимайтесь – достаньте нам нужные данные».

• Дополнительно мы с заказчиком договорились практически полностью убрать всю бумажную документацию. Мы ему четко донесли, что на написание любого документа уходит время, это нужно понимать. Если мы пишем большое и красивое ТЗ, это у нас съест довольно большой кусок работы. Если мы пишем большую красивую учетную модель, это съест довольно большой кусок работы. С другой стороны, встал вопрос, а как же нам вообще жить без бумажной документации? Заказчик решил, что все инструкции он будет писать сам. Для чего это было нужно? Во-первых, сотрудники заказчика начинают максимально рано включаться в проект и учиться работать с программой. Во-вторых, они пишут инструкции, понятные именно им. Они были с корявыми картинками, где-то не отформатированные – у меня слезы шли из глаз, когда я видел эти инструкции. Но самое главное – эти инструкции были понятны им, и они могли работать.

• И последнее ключевое требование от заказчика: нам необходимо было разработать примерно такие же автоматизированные рабочие места по вводу первичной информации, которые были в предыдущей системе. Чтобы сотрудники на производстве, в цехе, в планировании, в закупках не вводили типовые документы, а работали примерно с тем же интерфейсом, к которому они привыкли. Нам не нужно было переучивать людей, не нужно было изменять процессы. Мы должны были быстрее подстроиться под них.

Ход проекта

Расскажу, какой у нас по факту получился план-график проекта.

• Первые два месяца (апрель и май) мы усиленно занимались сбором требований, разработкой контрольных примеров, показывали эти контрольные примеры.
  Причем мы показывали контрольные примеры и тут же сажали заказчика: «Вот тебе ERP-система. Мы тебе в первый раз показали, дальше прогоняй сам, чтобы потихоньку учиться работать с системой, понимать, что мы тебе показываем. Чтобы не получилось, что вы нам головой покивали, а по факту все совсем не то».
  Мы занимались загрузкой начальных данных, обучали ключевых пользователей работать с 1С – собирали людей в отдельной аудитории и рассказывали, как пользоваться отчетами и управляемыми формами. На это уходило довольно много времени, потому что до этого у них большая часть пользователей 1С не видела никогда. У них была другая программа, они привыкли жить в другой программе.

• По факту на последней неделе мая мы уже смогли вести полностью двойной учет – на последнюю неделю мая заказчик уже работал в двух системах. Благо там в автопромышленности был небольшой спад, и у нас было время на то, чтобы вести документы и в новой системе 1С:ERP, и в старой системе.

• 3-го июня мы полностью отказались от старой системы и начали вести все первичные документы уже в 1С:ERP. Весь июнь мы полностью всем составом команды находились на территории заказчика, бегали к каждому сотруднику, и если у кого что-то не получалось, подсказывали. Программисты у нас там днем и ночью пытались исправить свои ошибки, что-то оптимизировали, что-то дописывали.

• Примерно к концу июня ажиотаж спал, люди все-таки научились работать и постепенно начали работать самостоятельно.

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

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

Что было сделано в первые три месяца работы.

• В первые два месяца мы сделали основную функциональность, а в третий месяц – по сути, исправляли наши косяки.

• Мы разработали порядка 14-ти ключевых автоматизированных рабочих мест по вводу первичных данных – места на производстве в каждом цехе, для склада, для отдела закупок, для планирования. При этом был изменен довольно большой объем типовых документов.

• Сделали 22 дополнительных специализированных отчета, в которых они жили раньше. В этих отчетах было то, к чему они привыкли – те цифры, которые нужны. Чтобы получить эти цифры, нужно было довольно сильно перестраивать типовую функциональность системы.

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

• Дополнительно мы сделали две новые подсистемы: для контроля качества и по работе с претензиями.

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

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

Результаты применения SCRUM+ТБР

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

Из ключевых плюсов:

• Мы делали только то, что нужно делать. Когда мы брали двухнедельный спринт, мы изначально с заказчиком договаривались брать только те задачи, которые нужны. Никакие задачи типа «У нас раз в пятилетку встречается» или «Было бы неплохо сделать». Мы сразу это отрезали. Когда-нибудь в следующей жизни мы посмотрим на это. Как оказалось, это было правильно – бОльшая часть задач из тех, которые мы оставляли с пометкой «Отложить до лучших времен», так и не понадобилась. И я думаю, что больше и не понадобится.

• Еще один очень ключевой плюс: у нас не было потерь во времени на согласование и утверждение ТЗ. За счет того, что мы ежедневно контактировали с заказчиком на планерках и ежедневно работали с функциональными потребителями, у нас все согласования, все утверждения ТЗ делались практически в онлайн-режиме. Мы показывали: «Первый вариант будет такой» – «Да, похоже». И отправляли программистам. Программист делал первый небольшой кусочек, мы опять показывали. «Правильно делаем?» – «Да». В результате разработка шла ну очень быстро.

• Тут же и быстрая обратная связь. Если мы что-то делали неправильно, нам сразу после демонстрации сообщали, что это работает не так. И мы сразу могли переделать.

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

Но, конечно, были минусы:

• По некоторым ключевым доработкам количество подходов к сдаче работ было очень большое. Один из ключевых АРМ – «Запуск заказов в производство» – мы сдавали двенадцать раз, потому что на входе мы слабо представляли, как это должно быть. Ни заказчик, ни мы не представляли. Я потом подробнее расскажу, почему подходов к доработке было двенадцать.
  Но другие доработки могли сдаваться очень быстро. Когда на втором месяце работы мы уже научились понимать заказчика, все пошло много быстрее. Мы с полуслова понимали, что и как нужно сделать.

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

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

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

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

• Очень высока стоимость ошибки. Если мы где-то за два месяца косячнем, это означало, что переделать это назад уже будет нельзя. Поэтому для каждого решения, которое мы делали, мы внутри команды постоянно собирали планерки, где один из разработчиков говорил: «Я сейчас хочу идти туда, давайте устроим мозговой штурм. Точно мне туда надо идти, или нам нужно как-то по-другому?» И совместно мы принимали решение – подходит этот вариант или не подходит.

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

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

Ключевые АРМы

Касаемо ключевых АРМ, о которых я рассказывал.

Один из ключевых АРМ – это был АРМ «Производство». На производстве стояли информационные киоски, и каждый сотрудник вносил свои данные именно в этот информационный киоск.

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

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

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

Если что-то шло не по плану, он звал начальника производства и говорил: «Люся, у меня возврат» или «Я накосячил, давайте исправлять».

Вот так выглядит АРМ «Запуск заказа в производство», который мы сдавали двенадцать раз.

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

Чтобы планово запустить в производство заказ на 5000 болтов, нужен бунт в 2 тонны. Но при этом бунта в 2 тонны не существует. Есть бунт весом 1 тонна 950 кг или весом 2 тонны 100 кг – они неровные идут, чуть больше или чуть меньше.

Раньше это работало так:

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

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

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

Он целый день между всеми бегал.

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

• Он видит заказ, что нужно выпустить 5000 болтов, которые производятся на основном рабочем центре 5160.

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

• Ему было видно, в какой ячейке этот металл лежит, в каком объеме.

• Заказ сразу автоматически пересчитывался. Если металла на 5000 болтов не хватало, там вставало количество 4900, он смотрел: «Ну окей, 4 900 мне хватает, чтобы обеспечить продажи».

• После этого создавалось вся цепочка документов: этапы производства, расходные ордера, маршрутные карты.

Теперь, вместо того чтобы целый день бегать, он работал в этом АРМ и видел там всю ключевую информацию.

За счет сложности этого АРМ мы его двенадцать раз создавали. Когда мы начали его разрабатывать, у заказчика в принципе ничего подобного не было, и нам приходилось что-то придумывать, моделировать.

По сути, этот АРМ мы писали все два месяца. Он у нас переходил из спринта в спринт, и мы его постоянно адаптировали и дорабатывали.

Еще один интересный АРМ – это АРМ «Планирование производства».

Когда мы показали заказчику типовую функциональность планирования производства в 1С:ERP, он сказал: «Цифры вроде прохожие, но я как сотрудник планово-экономического отдела не вижу, из чего у меня сложились эти цифры».

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

• Список всех заказов клиентов нужно разузловать до всех полуфабрикатов.

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

• Потом нужно определить, на каких рабочих центрах эти партии можно произвести – заняты эти рабочие центры или не заняты.

• И дальше уже принимать решение – запускать такой заказ или не запускать, планировать или не планировать его.

• Плюс дополнительно отслеживалась информация по доступности металла – можем мы это сделать или не можем.

Здесь видно 10 колонок, но у них на самом деле там 24 колонки вбок уходило.

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

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

Итоги проекта и выводы о технологии

Какие получились итоги внедрения для заказчика?

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

• Мы смогли обеспечить сквозную прослеживаемость производства. Они по каждому болту (они были все со штрихкодами в коробочках) полностью видели полную цепочку, вплоть до партии металла, которая пришла от поставщика. Все лабораторные данные, все этапы: на каком станке какой сотрудник его обрабатывал, когда обрабатывал – все эти данные есть. И сейчас все контрольные проверки от ключевых клиентов – того же ГАЗа, УАЗа и всех остальных – проходят без проблем. Они просто распечатывают все карты и показывают, что все это есть в системе. Проверки сейчас проходят намного быстрее.

• Мы оптимизировали процессы планирования производства и закупок.

• Мы разработали автоматизированные рабочие места по вводу этих данных. За счет этого введение нового сотрудника производства в курс дела стало очень быстрым. Ему дают инструкцию буквально на двух-трех листах, и через 5 минут сотрудник готов с этим работать.

• Отдельное спасибо нам высказала бухгалтерия за то, что мы наконец-то наладили нормальный человеческий обмен. Сейчас бухгалтер заходит в 1С:Бухгалтерию, нажимает «Получить данные», у него появляются все документы. Раньше сотрудники производства выгружали в отдельные отчеты информацию о том, что они произвели, сохраняли это в Excel и отдавали этот Excel бухгалтерии. Бухгалтерия открывала обработку «Загрузка данных из табличных частей», что-то шаманила в Excel, пыталась это как-то объединить, свести и получить данные. Конечно, такой способ занимал очень много времени и вызывал миллион ошибок – они каждый раз мучились с тем, чтобы хоть как-то месяц закрыть. А с нормальным обменом между 1С:Бухгалтерией и 1С:ERP мы сняли им этот головняк, они в любой момент могут получить все, что надо.

Какие итоги внедрения мы получили для себя?

• Самый главный, самый большой итог – мы смогли донести до нашего отдела продаж и до других руководителей проектов, что необязательно все делать по классической технологии. Бывают исключительные ситуации, и мы можем на проект посмотреть по-другому.

• До продажников мы смогли донести, что есть ряд клиентов, которые ждут результат, а не процесс. Когда мы работаем с коммерческими предприятиями относительно небольшого объема – до 5-10 миллиардов годового оборота – они больше смотрят на результат. А если это корпоративные клиенты, для них чаще важен процесс.
  Мы переделали наши речевки для продажников – как заходить в клиента, как продавать проект. И после запуска этого клиента мы продали по этой технологии уже два проекта. Один из них сейчас уже находится на стадии опытной эксплуатации – они уже ведут двойной учет в системах. Я надеюсь, что в октябре (прим. ред. доклад от 6 октября 2022 года) они уже полностью запустятся и перейдут на новую систему. Второй проект сейчас на начальной стадии, мы отрабатываем его.

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

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

Это все, что я хотел вам рассказать.

Вопросы

Сколько рабочих мест было автоматизировано?

В системе работало порядка 50 пользователей.

А решение о том, что регламентированный учет ведется в отдельной системе – кем было принято и почему?

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

Система для лаборатории, которая проводит контроль качества, у них была своя?

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

Вы рассказывали, что делали АРМ без ТЗ. Когда результат получался не таким, как хотел заказчик, и нужно было переделывать, кто платил за эту переделку?

Мы изначально с заказчиком шли в такой формат работы, что мы работаем по Time & Material. Мы ничего заказчику не обещали. Мы ему выделили шесть экспертных специалистов. Подтвердили их компетенции сертификатами, опытом и всем. И сказали: «Эти шесть специалистов за два месяца постараются тебе сделать все по максимуму, насколько смогут». У нас не было претензий от заказчика, что мы там что-то сделали не так. Да, мы там очень много делали не так, и не с первого раза эти АРМ запускались, но мы изначально договорились с заказчиком, что мы живем в такой парадигме.

Производство было многопередельное и длинноцикличное?

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

И с точки зрения сбора затрат по выполнению Гособоронзаказа предприятие не работает?

Нет, у них не Гособоронзаказ. Они производят комплектующие конвейера для ГАЗа. Производят болты, высокопрочный крепеж.

Использовали ли вы в ERP направления деятельности? Если себестоимость в ERP не считается, и все переносится в Бухгалтерию – понятно, вопросов нет. А если же они все-таки собирают управленческую отчетность, каким образом вы решали этот вопрос?

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

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

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

Вопрос по контролю качества – в системе был какой-то контроль невозможности использования сырья, которое еще не прошло сертификацию?

Да, у нас был ордерный склад с ячеистым хранением, и когда сырье приходило на склад, оно изначально помещалось в зону приемки. И пока лаборатория не давала на это сырье свое заключение, сырье из зоны приемки нельзя было разместить в ячейку – программа выдавала ошибку.

И точно так же, если сырье было забраковано по тем или иным причинам, оно у нас помещалось на склад брака, и такие забракованные серии нельзя было списать в производство, программа выдавала ошибку.

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

Контроль сертификации регулировался заполненностью дополнительного реквизита «Серия», поскольку лабораторное исследование было связано с серией.

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

Использовался партионный учет?

Полностью велся партионный учет. Каждая партия сырья, которая приходила – это была отдельная серия, каждая производственная партия – это была отдельная серия. Там очень-очень детальный партионный учет.

В фарминдустрии применяется аналогичная система, но не такая.

Возможно. Еще раз подчеркну: поскольку мы были очень ограничены по времени, у нас было только два месяца, мы не смогли все решения сделать оптимально или воспользоваться какими-то готовыми наработками. Мы пилили очень быстро и на ходу. Может быть, есть и другие системы, но мы не смогли их увидеть и запустить.

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

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