«Монди Бизнес Пейпа Сыктывкарский ЛПК»: В стремлении к балансу

Ссылка на резервное размещение материала

«Монди Бизнес Пейпа Сыктывкарский ЛПК»: В стремлении к балансу

Плановые неувязки

Проблемы в логистике появились уже после того, как на предприятии про­изошла большая реорганизация. В 2002 году, вскоре после завершения приватизации, Сыктывкарский лесо­промышленный комплекс, гигант со­ветской бумажной индустрии, был приобретен стратегическим инвесто­ром, группой Mondi Business Paper (МБР входит в состав Anglo American PLC Group — мирового лидера в обла­сти добычи драгоценных металлов и полезных ископаемых).

Преобразования на комбинате но­вые владельцы начали с инвестиций, направленных на увеличение загрузки производственных мощностей. Войдя в состав группы, комбинат стал выпус­кать больше качественной офисной и офсетной бумаги — профилирующей продукции Mondi. Объем производства бумаги вырос за два года нат, а офисной бумаги — утроился. Рост производства и стал одной из причин образования узких мест на комбинате.

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

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

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

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

Нужно было срочно сбалансировать всe звенья производственной цепи, чтобы сократить потери. Оптимизм внушало то, что мы подошли к этой задаче, обладая серьезным преимуществом: на предприятии давно, с 1997 года, использовалась ERP-система R/3, соответственно, в нашем распоряжении была вся необходимая информация по учету затрат, объемам продаж, количеству продукции на складах и пр. Но система не покрывала производственное планирование, оно до последнего времени велось у нас вручную — в электронных таблицах, которые рас­сылались всем подразделениям, задействованным в процессе производства.

В поисках решения

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

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

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

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

Как я уже говорил, производствен­ное планирование не было реализова­но в системе R/3. По каким-то причи­нам прежний менеджмент отказался от идеи внедрения этого модуля, хотя он и был изначально приобретен. Его эксплуатировали только как вспомога­тельный, чтобы поставлять информа­цию другим частям системы, напри­мер контроллингу. Но само по себе внедрение модуля проблемы не реша­ло. Мы довольно скоро поняли это: процесс планирования портфелей не осуществляется стандартными функ­циями R/3. Тем не менее разработчик, который сопровождал модуль, Денис Вежев, был уверен, что возможности системы позволяют нам самостоятель­но автоматизировать процесс. Со­блазн довериться ему был велик, одна­ко и сомнения у нас были весьма серьезными.

Успех подобного начинания зависит не только от технических способнос­тей разработчика, но и от его умения ладить с людьми. В группе программи­стов (всего их у нас 20) Денис держал­ся особняком: программисты у нас в основном женщины, а он к тому же был значительно моложе своих коллег. На него часто жаловались: мол, замк­нут, грубоват с коллегами. Поручить ему такой крупный и важный проект было рискованно, тем более что в ходе его реализации Денису пришлось бы активно общаться с другими разра­ботчиками, в первую очередь с Еленой Головкиной. Она сопровождала мо­дуль продаж, в который предстояло внести множество изменений и дора­боток. Как раз с Еленой у Дениса сло­жились особенно непростые взаимо­отношения, и на этой почве не раз возникали конфликты. Вместе с тем я видел, что Денис очень хочет внедрить свой модуль в полноценную эксплуа­тацию. А если ему удастся встроить процесс планирования в R/3, это зна­чительно облегчит нашу жизнь. Сло­вом, я решил доверить Денису реали­зацию проекта.

Начало работы

Делать более или менее точный заказ транспортники могут, только заблаго­временно получая информацию о по­требности в вагонах. Такую информа­цию могут предоставить менеджеры по продажам, вводя в свои заказы дан­ные, необходимые для планирования транспорта. Казалось бы, все просто, однако попутно нам пришлось решать множество технических проблем. На­пример, для заказа вагонов необходи­мо знать станцию назначения, значит, в системе нужно держать справочник с кодами станций МПС. Кроме того, нам пришлось внести туда перечень типов вагонов, снабдив его нормати­вами по каждому виду продукции ком­бината (без этого невозможно было рассчитать, сколько вагонов понадо­бится для отгрузки заказа покупате­лю). Вся эта работа ложилась на плечи Елены Головкиной, она же должна бы­ла довести все новшества до сотрудни­ков отдела продаж.

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

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

Информационное хранилище давно предлагается на рынке как инструмент для углубленного анализа данных (data mining). Однако примеров его ус­пешного использования пока совсем немного. Один из самых известных проектов — хранилище данных интер­нет-магазина Amazon, который перио­дически публикует сведения о прист­растиях и вкусах покупателей, полученные при анализе продаж книг, музыкальных записей и прочей про­дукции. Для Amazon возможность изу­чать спрос на основе огромного хранилища данных — одно из серьезных конкурентных преимуществ. Однако возникал вопрос: насколько пригоден этот инструмент в нашем бизнесе и для наших пользователей? Мы ведь собирались использовать его не для анализа прошлых событий, а для построения планов на будущее, которое та­ит в себе немало сюрпризов.

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

Время перемен

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

венное планирование, работая сразу же с реальными данными.

Отправной точкой внедрения стала большая презентация проекта, на ко­торую мы собрали всех будущих поль­зователей и просто заинтересованных в проекте людей. Первым выступил руководитель группы разработчиков: он обстоятельно изложил концепцию решения, рассказал об изменениях в процессах, новых правилах, а также о преимуществах, которые должно дать внедрение. Однако его рассказ не вызвал энтузиазма у собравшихся. По­сле долгой презентации завязалась дискуссия — она только подтвердила, что люди не готовы к переменам. «Тео­рия нашей повседневной работы, рас­сказанная нам кем-то со стороны, яв­но не вызывала одобрения» — так впоследствии охарактеризовала меро­приятие одна из его участниц.

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

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

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

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

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

Люди высказывали не только замеча­ния, но и пожелания по расширению перечня функций системы. Одни пред­ложения были приняты и реализова­ны, от других пришлось отказаться. В частности, кто-то высказал идею раз­делить производственный портфель между менеджерами продаж путем вве­дения индивидуальных лимитов — ли­миты нужны для того, чтобы разграни­чить доступные объемы продукции между менеджерами. Это очень чувст­вительный вопрос, ведь своего рода квота определяет размер бонуса, и, ес­ли не управлять ее распределением, в команде может разгореться нешуточ­ная конкуренция. Но от этой идеи при­шлось отказаться из-за сложности ее реализации.

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

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

Первые итоги

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

Одна из первых реакций была нега­тивной: сотрудники отдела продаж вы­разили недовольство в связи с тем, что при введении заказа клиента в систему им приходится указывать еще и тип транспортного средства (вагона): они по-прежнему полагали, что это дело транспортников. Зато теперь, в новой системе, если при планировании со­трудники отдела транспорта обнару­живают в отчетах что-то подозритель­ное, они сразу понимают, к какому сейлз-менеджеру обращаться за разъ­яснениями. В свою очередь, работа транспортников тоже стала гораздо прозрачнее и понятнее для остальных подразделений.

Недовольство проявлялось в виде весьма эмоциональных стычек на со­вещаниях. Однажды начальник транс­портного отдела негативно высказал­ся по поводу данных из заказов на продажу — заметил, что они недоста­точно точны для заказа вагонов. Одна из руководителей службы продаж от­реагировала мгновенно и весьма эмо­ционально: «Все заварилось ради вас же, транспортников, и теперь вдруг выясняется, что R/3 вам не годится! Объясните тогда, пожалуйста, что за система вас устроит?»

Так или иначе, проект начал жить и развиваться самостоятельно, вмеша­тельства высшего руководства уже не требовалось. Сплоченный коллек­тив, словно экосистема, сам выявлял проблемы и разбирался с шероховато­стями, возникавшими при внедрении. Первый месяц эксплуатации системы прошел в целом успешно. В систему оперативно заводились данные по портфелям и заказам на следующий месяц, что позволяло отказаться от использования файлов с электронны­ми таблицами. Многочисленные изме­нения и корректировки, внесенные разработчиками по замечаниям поль­зователей, дали положительный эф­фект. Наряду с дополнительной на­грузкой сотрудники начали ощущать |и первые преимущества от использо­вания системы. Менеджеры, занимав­шиеся планированием, теперь видели, как распределены заказы клиента по производственным портфелям. Преж­де такую информацию им приходи­лось собирать вручную из нескольких таблиц, на что уходило немало време­ни. Кроме того, теперь не нужно было самостоятельно отслеживать заплани­рованные остановы производств, ин­формация поступала автоматически от технологов.

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

Интересно, что при внедрении систе­мы самые большие трудности пользо­вателей были психологического свой­ства. Большинство наших людей уже имели навыки работы в R/3, содержа­щей большое количество данных о транзакциях на предприятии — таких, например, как выставление счета кли­енту, оформление продукции, посту­пившей на склад или отгрузки заказа покупателю. Соответственно, ежеднев­ная работа в системе с информацией, подлежавшей минимальной интерпре­тации, в условиях, когда система дает четкую инструкцию относительно дальнейших действий, у многих давно вошла в привычку.

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

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

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

Жизнь налаживается

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

Следует отметить, что одновременно с внедрением автоматизированной сис­темы планирования принимались и дру­гие меры для ослабления напряжения на складах и в логистике. В частности, что­бы отладить отгрузку оплаченных зака­зов, мы перешли на ежедневную двухра­зовую проверку поступления платежей. Мы также отработали процедуру пере­мещения готовой продукции со склада на склад в случае переполнения храни­лища. Все эти меры позволили снизить значение среднемесячной пиковой загрузки складов более чем на 10%. Но важнее было то, что склады перестали быть нашим узким местом. Одновре­менно благодаря реорганизации мы добились снижения издержек на транспортировку готовой продукции и те­перь экономим евро в месяц, и, похоже, это еще не предел.

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

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

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

Сергей Павлов, заместитель гене­рального директора по информаци­онным процессам «Монди Бизнес Пейпа Сыктывкарский ЛПК»

«Harvard Busines Review Россия» май 2005г.