Оптимизация процессов снабжения в ПАО «Распадская угольная компания»

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

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

Так выглядела система дистрибуции к началу изменений (Рис. 1).

Рис. 1. Система дистрибуции «До изменений»

Особенности системы «До изменений»:

1. Основной материальный поток направлен на центральные склады отдельных предприятий.
2. При этом используется схема транзитных поставок, т. е. поставки осуществляются на предприятия по документам Управляющей компании (УК) с последующим перевыставлением документов реализации.
   На УК замкнут функционал по поиску поставщиков и заключению договоров на поставку, поэтому Поставщик не может выставить Счет-фактуру напрямую на предприятие, так как по договору покупателем является УК.
3. Все, что невозможно поставить на конкретное предприятие, доставляется сначала на Новокузнецкую материальную базу (НМБ) ПАО «РУК», а потом продается на предприятия.
4. Приходится управлять запасами 15 отдельных предприятий. Один материал может храниться на каждом предприятии.
5. Транзитные поставки существенно тормозят процессы учета из-за задержек товарно-сопроводительных документов.
6. Процесс перепродажи трудоемкий, но количество транзакций незначительное.

Цели проекта

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

• улучшить Lead-Time поставок;
• сократить плечо доставки за счет сокращения перевалочного пункта;
• сократить транзакционность;
• снизить стоимость функции снабжения.

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

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

На старте

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

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

Рис. 2. Фрагмент приказа о создании РГ проекта

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

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

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

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

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

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

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

Через тернии к звездам

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

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

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

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

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

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

Рис. 3. Логистическая цепочка документов

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

Рис. 4. Верхнеуровневая диаграмма процесса снабжения

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

Рис. 5. Пример обсуждения схем в рабочих группах

Целевая модель процессов и документооборота должна была отвечать на следующие вопросы:

1. Кто создает документ и в какой программе?
2. Зачем вообще нужен документ и кому нужен, и где будет храниться?
3. Сколько раз документ передается «из рук в руки»?
4. Какой документ электронный, а какой бумажный?
5. Сколько экземпляров бумажного документа и т. д.

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

Рис. 6. Диаграмма рабочего процесса целевой модели

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

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

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

При описании деятельности предприятия на нижнем уровне мы использовали нотацию «Процедура» в Business Studio. На рисунке ниже красными цифрами отмечены особенности этой нотации, которые помогли нам в проекте.

Рис. 7. Польза диаграмм процессов

1. Ролевые дорожки мы использовали для формирования коротких памяток для пользователей. Использование ролевых дорожек наглядно показывает, как часто документ кочует «из рук в руки».
2. Ссылка на программу и транзакцию, в которой создается документ, помогает легко найти инструкцию по техническому номеру транзакции. Например, если забыл, как распечатать Накладную М11, то иди в транзакцию Vl10b.
3. Можно отследить жизненный цикл документа от его формирования до места хранения. Штриховые линии показывают на операции с документами, которые автоматически протекают в фоновом режиме без участия пользователя.
4. Отдельно жирным шрифтом помечены бумажные документы.
5. И, наконец, на диаграмме мы легко можем показать ту часть процесса, которая подверглась оптимизации. Пример оптимизации мы еще рассмотрим ниже по тексту в разделе «Трудоемкость ручных операций».

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

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

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

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

Рис. 8. Типы поставок

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

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

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

Рис. 9. Пример оптимизации

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

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

В проекте мы столкнулись с банальной проблемой — схемы процессов сначала воспринимались рабочей группой неохотно.

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

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

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

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

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

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

Рис. 10. Оптимизируемые процессы в результате внедрения ЭЦП

Результаты

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

1. Оптимизация затрат на 72 млн рублей/год.
2. Сокращение численности сотрудников, обеспечивающих функцию снабжение на 59 человек.
3. Сокращение площади складов на 75 тыс. кв. м.
4. Снижение уровня запасов ТМЦ на 39%.
5. Увеличение OTIF (% поставок, выполненных вовремя и в полном объеме) с 68% до 84%.

Опубликовано по материалам:
https://kachestvo.pro/kachestvo-upravleniya/protsessnoe-upravlenie/optimizatsiya-protsessov-snabzheniya/

Июнь 2021 г.

Рекомендуемые материалы по тематике

Направления дальнейшего развития процессного управления в банках

Опыт построения организационного управления в ритейле (Процессный офис в ритейле)

Процессное управление с бирюзовым оттенком: оптимизация процесса управления бизнес-архитектурой банка в целях реализации гибких методологий

Управление компанией на этапе «Ранняя бюрократия»