Оптимизация процессов снабжения

За три года в ООО «Распадская угольная компания» была проведена масштабная трансформация модели снабжения, которая позволила сократить уровень запасов и оптимизировать издержки на дистрибуцию  ТМЦ  на сумму 72 млн руб. в год. Изменения напрямую отразились на работе более чем 600 сотрудников 15 предприятий, находящихся под управлением  РУК . Применение технологий бизнес-проектирования позволило команде проекта успешно синхронизировать перестройку бизнес-процессов, организационной структуры, информационных систем и данных. Представленный в нашем материале кейс был отмечен наградой «Специальный приз жюри» национального конкурса «BPM-проект года 2019».

О компании

ООО «Распадская угольная компания» , занимается поставкой угля большинству ведущих металлургических заводов и предприятий России и СНГ. По уровню механизации и автоматизации производственных процессов шахты компании занимают одно из лидирующих мест в угольной отрасли страны: 100% добычи приходится на комплексно-механизированные забои. 

Новокузнецкая площадка компании объединяет пять шахт, две обогатительные фабрики и специализированные вспомогательные предприятия. Сегодня добыча угля ведется на шахтах «Алардинская», «Есаульская», «Осинниковская», «Усковская» и «Ерунаковская-VIII». Территориально шахты находятся в трех городах Кузбасса: Новокузнецке, Осинниках и Калтане.

подробнее

Предпосылки к проекту

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

Особенности системы до внедрения изменений

1. Основной материальный поток направлен на центральные склады отдельных предприятий.

2. Использовалась схема транзитных поставок, т.е. поставки осуществлялись на предприятия по документам управляющей компании с последующим перевыставлением документов реализации.

   На УК замкнут функционал по поиску поставщиков и заключению договоров на поставку, поэтому поставщик не может выставить счет-фактуру напрямую, так как по договору покупателем является УК.

3. Все, что невозможно поставить на конкретное предприятие, доставляется сначала на  Новокузнецкую материальную базу ООО «РУК», а потом продается компаниям.

4. Приходится управлять запасами 15 отдельных предприятий. Один материал может храниться в каждой организации.

5. Транзитные поставки существенно тормозят процессы учета из-за задержек товарно-сопроводительных документов.

6. Процесс перепродажи трудоемкий, но количество транзакций незначительное.

Цели проекта 

Основная цель проекта – показать положительную динамику развития функции снабжения: 

• улучшить  Lead-Time поставок; 

• уменьшить  плечо доставки за счет сокращения перевалочного пункта; 

• сократить транзакционность; 

• снизить стоимость функции снабжения.

Для этого предстояло решить ряд задач:

• ликвидировать распределительную базу и направить материальный поток напрямую на склады управляемых предприятий; 

• настроить ИТ-систему, чтобы она была способна обеспечить целевой процесс;

• распределить имеющиеся запасы с ликвидируемой базы, но при этом не потерять адресное хранение;

• решить инфраструктурные вопросы, связанные с регистрацией опасных производственных объектов в Ростехнадзоре, оборудованием на предприятиях подъемных механизмов, изменением ИТ-инфраструктуры и т.п.;

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

На старте

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

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

Как работает команда

Сформированная  рабочая группа  проекта условно состояла из трех подгрупп: 

1. управляющий комитет, в который входили руководители верхнего уровня; 

2. инициативная группа – это узкий круг специалистов, которые прорабатывали гипотезы и выносили предложения на обсуждение расширенному составу РГ;

3. в расширенный состав РГ входили специалисты, назначенные ответственными по направлениям: дирекция по контролю, запасники, закупщики, складская логистика, первичный учет, юристы, специалисты от ИТ. 

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

• Первым шагом предстояло объединить склады четырех территориально удаленных предприятий в один кустовой склад. 

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

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

Как решались проблемы

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

Неопределенность

Первая сложность, с которой мы столкнулись, – это неопределенность.

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

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

Была разработана принципиальная схема логистической цепочки документов, которая соответствовала текущей версии системы дистрибуции. На такой  схеме  показана последовательность формирования документов на стороне предприятия и на стороне УК.

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

Чтобы оценить масштабность изменений, мы использовали верхнеуровневую диаграмму процесса снабжения. Процессы верхнего уровня, как правило, не меняются, не дублируются, не пересекаются, поэтому их удобнее отображать в нотации  IDEF0 . Основная задача диаграммы верхнего уровня – показать, что все процессы направлены на достижение единого результата. На диаграмме красным подсвечен процесс А5 «Процессы движения и хранения ТМЦ на складе». Именно в этом процессе должны были произойти изменения. Таким образом, мы локализовали масштаб изменений, обеспечили уверенность в наших дальнейших действиях.

Далее предстояло спуститься на уровень ниже и проработать целевую модель документооборота, выдать функциональные требования на изменение ИТ-системы. 

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

1. Кто создает документ и в какой программе?

2. Зачем и кому нужен документ, где он будет храниться?

3. Сколько раз документ передается из рук в руки?

4. Какой документ электронный, а какой бумажный?

5. Сколько необходимо экземпляров бумажного документа и т.д.

Чтобы детально ответить на эти вопросы, мы использовали диаграммы, разработанные в программе  Business Studio . Этот продукт мы также применяли в качестве базы данных о бизнес-процессах снабжения. 

Архитектура процессов

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

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

При описании деятельности предприятия на нижнем уровне мы использовали нотацию «Процедура» в Business Studio. 

1. Ролевые дорожки мы применяли для формирования коротких памяток для пользователей. Эта система наглядно показывает, как часто документ кочует из рук в руки.

2. Ссылка на программу и транзакцию, в которой создается документ, помогает легко найти инструкцию по техническому номеру транзакции. Например, если забыл, как распечатать Накладную М11, то нужно посмотреть в транзакцию Vl10b.

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

4. Отдельно жирным шрифтом помечены бумажные документы. 

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

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

• Описывать процессы сплошным методом – это трудозатратно и непрактично.

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

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

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

Трудоемкость ручных операций

До начала проекта оптимизации системы снабжения выдача ТМЦ сопровождалась перемещением в подотчет получателю. Но в целевой модели процесс перемещения превратился в куплю-продажу, поскольку заявитель ТМЦ теперь получал ТМЦ не со склада своего предприятия, а со склада «чужой» управляющей компании. По своей сути это напоминает приобретение ТМЦ в магазине, но только не в розницу, а между двумя юридическими лицами с последующим выставлением счета-фактуры и оплатой по нему. Операция купли-продажи более трудоемкая по сравнению с операцией перемещения ТМЦ. Замеры показали, что в среднем на перевыставление транзитного счета-фактуры уходит 15 дней. Сама операция занимает в среднем 45 минут. Именно по этой причине процедура выдачи ТМЦ в производство стала объектом № 1 для оптимизации.

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

В результате вместо 15 дней фактурирование осуществляется в течение одного рабочего дня. Время на оформление самой операции сократилось на шесть минут. За 2019 год было создано 33 тысячи документов по оптимизированной схеме.

Отторжение моделей процессов

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

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

В рабочей группе эта идея прижилась, и мы договорились использовать общий язык для общения. Графический язык Business Studio вполне оправдал свои ожидания, и группа охотно стала использовать схемы при обсуждении целевой модели предприятия. 

Смежные проекты

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

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

Результаты

По итогам проекта реинжиниринга системы дистрибуции ТМЦ в ООО «Распадская угольная компания» удалось добиться значимых успехов в повышении эффективности функции снабжения. Показатели по сравнению с 2018 г.:

• оптимизация затрат на 72 млн рублей в год;

• сокращение численности сотрудников, обеспечивающих функцию снабжения, на 59 человек;

• сокращение площади складов на 75 тыс. кв. м;

• снижение уровня запасов ТМЦ на 39%;

• увеличение  OTIF с 68% до 84%.