Логистические цепочки как зеркало мирового развития

Однако важнейшей «глобальной» новинкой в области управления бизнесом, на мой взгляд, сегодня стала концепция «логистических цепочек» (supply chain). Информационная поддержка данной методологии — обязательное требование для крупных компаний. Характерно, что еще в прошлом году R/3, которая позиционируется как система управления прежде всего для крупного бизнеса, активно критиковалась именно за недостаточный уровень поддержки данной концепции.

Переход в практике и теории управления от манипулирования поставками (supply management) к управлению цепочками поставок (supply chain management) или, точнее, управлению логистическими цепочками (рис. 4) произошел совсем недавно — в течении последних двух—трех лет. Кстати, разница (в английском варианте особенно) на первый взгляд улавливается с трудом, хотя является принципиальной. Например российская специфика состоит в том, что фактически с самого начала все сколько-нибудь значительные компании имели дело с управлением именно логистическими цепочками, которые им приходилось создавать «с нуля», а не с «простыми продажами», хотя некоторые не осознали этого до сих пор. Неумение или непонимание сущности управления сложным бизнесом обернулось для многих из таких компаний уходом с рынка.

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

Возникновение теории и практики управления логистическими цепочками существенно связано с прогрессом информационных технологий, который позволил даже мультинациональным корпорациям проводить операции и анализ деятельности в режиме on-line. Естественно это потребовало осмысления и формализации методологий управления глобальным бизнесом и разработки соответствующих инструментов. Поддержка логических цепочек с прошлого года стала практически обязательным требованием для программных продуктов, предназначенных для автоматизации торговых и холдинговых структур. Такие продукты должны поддерживать конфигурации позволяющие размещать объекты автоматизации на нескольких физически удаленных территориях, причем как с возможностью разделения финансового (бухгалтерского) учета (поддержки нескольких юридических лиц), так и с возможностью поддержки «распределенного», но единого юридического лица, со всеми вытекающими отсюда требованиями к распределенной структуре базы данных. Во многих случаях также необходим вариант «тонкого» клиента для обеспечения рабочих мест на удаленных складах или, например, для дистанционного формирования заказа или мониторинга в представительских учреждениях.

 

Рис. 4. Управление логистическими цепочками

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

• Специфические потребности поставок для каждой страны (региона), требующие использования специальных комплектующих или материалов. Например, детский трикотаж с вышитым рисунком изготавливается в Юго-Восточной Азии, а поставляется всюду — от Северного полюса до Южного. Естественно, для Саудовской Аравии и Канады требования к рисунку совершенно различны, что диктует необходимость привлекать специалистов соответствующих стран. Кроме того, в «рождественский» подарочный набор должны быть включены подарки, специфичные для каждой страны, соответственно, их нужно заказать, поставить, упаковать.

• Популярная ныне идеология CFM (Customer Focused Manufacturing) —производство «ориентированное на покупателя». Собственно говоря, приведенный пример также может быть отнесен к данной категории, однако в общем случае «фокус» CFM находится не просто в адаптации товара к потребностям конкретного покупателя, а в постоянной поддержке «обратной связи» с покупателем и адаптации цепочки под них. Это может выражаться, например, в том, что в одном магазине покупают компьютеры с большими дисками, а в другом — с самыми современными видеоплатами и большой памятью, следовательно и ассортимент программного обеспечения для этих магазинов скорее всего должен быть различен. Корпуса также требуются разные, то же можно сказать и о мониторах, и так далее, если компания ориентируется не на «колоночную» сборку, а на «типовые решения», то, как легко понять, различия существенны. Причем важно, что подобные «приоритеты» могут существенно меняться, иногда в течении одного—двух месяцев.

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

В последнем случае интересно провести различие концепции Supply Chain и Distribution Requirements Planning (планирование распределенных ресурсов), которая фокусируется на проблеме планирования «пополнения» распределенной складской системы, причем не только из «центрального» склада, но и за счет перемещения товара между складами одного уровня, в том числе и путем перемещения из магазина в магазин, не фокусируясь на проблемах снижения операционной стоимости и обратной связи. Данный подход оптимален для пополнения, скажем, системы складов сервисных центров, обменных фондов, или, например, системы оптовых складов продовольственной продукции массового спроса, как например, сахар, соль, крупа и тому подобные товары, которые мало подвержены «капризам» покупателей по упаковке и мало дифференцируются по качеству. Концепция DRP реализована достаточно давно, например, в таких продуктах как СА-PRMS, а также в заказных системах. Особенность системы в том, что она вполне качественно работает и с off-line информацией. В принципе ее можно успешно реализовать и на Excel.

Сущность анализа логистических цепочек очень проста и сводится к ряду очевидных, но не тривиальных фактов:

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

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

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

Введение понятия логистическая цепочка было не менее революционным, нежели переход в производственном менеджменте к концепции MRP II (и, кстати — это практически эквивалент этого понятия, если рассматривать процесс закупки-продажи как своего рода «производственный»).

Типичными вопросами, решаемыми системой управления логистическими цепочками, являются:

· какова должна быть структура складов сырья и готовой продукции для уменьшения операционных издержек;

· каким образом оптимизировать схему транспортных операций (с точки зрения издержек);

· где производить товар для поставки на конкретный региональный рынок.

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

Тяни vs Толкай, или «куда ни крути, а главное — кто будет отвечать»

Не претендуя на абсолютную точность могу предположить, что идея управления логистическими цепочками зародилась в недрах методов производственного управления известных как JIT (Just in Time — «точно вовремя» заказать и установить) и Kanban (точно во-время привезти). По сути дела это модификации одного и того же метода, первая ориентирована на push, вторая — на pull технологию. В какой-то момент эти технологии казались «панацеей» от всех производственных болезней, но их недостатки не позволили сделать их «универсальными». Возможно что на пути их распространения стала как раз их существенная трудоемкость реализации,

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

Интересно, что распространение JIT и Kanban оказалось значительно меньше, чем первоначальный интерес к ним. И этому есть несколько весьма важных причин. Избежать ошибок в ассортименте и срывов сроков поставок очень трудно даже в условиях Японии и США, а каждый такой «сбой» приводит, в условиях «точных» технологий, к остановке производства. Поэтому приходится держать «горячий запас» в размере по меньшей мере разовой загрузки оборудования, что, в условиях крупных производств, может оказаться довольно накладно. Поэтому не удается избежать кардинальной статьи затрат — капитальные вложения в складские помещения и оборудование, а ее то больше всего и хотелось «редуцировать». Однако, в некоторых секторах производства, например малосерийная сборка и строительство, данная технология весьма распространена, в частности, в большинстве высокотехнологичных компаний: Nortel, Xerox, HP, Honda, Toyota, Sony. Для тех отраслей, где она применяется, характерна малая мощность обрабатывающих центров, как правило многоцелевых, стабильные сборочные спецификации и технологические карты.

Еще один важнейший момент в понятии «логистическая цепочка» — уже упомянутое и мало пока привычное понятие push/pull технологии. Сущность данного понятия — различные точки инициирования операций по всей «цепочке». Например, вариант «выталкивания» продукции. Предприятие произвело продукт, далее продает — «с глаз долой, из сердца вон». Или технология «выдергивания» — «надо — вот возьмите». Естественно это упрощенный подход. К тому же концепция push/pull не вполне очевидна — она показывает довольно тонкое различие между методологиями управления системой закупок или продаж, к тому же практически применяемые системы продаж часто являются некоторой смесью двух базовых техник. Опять же очень упрощенно можно сказать, что система продаж по заказам — это технология выдергивания, а производство на склад — технология выталкивания.

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

Различие между методами JIT и Kanban принципиально, что станет ясно если включить в рассмотрение не только общую схему товародвижения, но и схему ответственности за процесс. В случае «выдергивания» ответственность фокусируется на «конечном» исполнителе. В случае «выталкивания» она распределяется по уровням логистической цепочки, в результате чего повышается устойчивость системы управления в целом и снижается риск принятия неверных решений (естественно, при ответственном отношении каждого менеджера и исполнителя, что также не всегда имеет место). Однако при этом ответственность становится менее гибкой — снижается «обратная связь» с последних стадий производства, что в принципе может создать проблемы с исправлением выявленных недостатков в качестве продукции и увеличивает проблемы в случае возникновения непредвиденных ситуаций. Например, изменение строительной спецификации при «выталкивании» приводит к существенно большим проблемам, чем при «выдергивании». Действительно, спецификация доведена до всех уровней, включена в производственные планы. Определить на какой стадии и где нужно вмешаться, достаточно сложно. При схеме «выдергивания» процесс разбит на маленькие звенья, связанные в цепь, и «спускаясь» по цепочке значительно легче обнаружить «активное» звено и произвести изменения.

 

Рис. 5. «Виртуальный бизнес»

Баланс

Однако, вернемся к логистическим цепочкам. Уже сама по себе, логистическая цепочка представляет собой весьма интересный инструмент управления бизнесом. Но кроме того, с использованием соответствующих финансовых инструментов возможно создание «виртуального бизнеса» (рис. 5) из распределенной системы нескольких компаний, охватывающего полный «жизненный цикл» товара, или, наоборот, разделение одной компании на несколько «виртуальных бизнесов». При этом для каждого «виртуального бизнеса» возможна поддержка полного спектра «виртуальных систем управления», характерных для единой компании. Однако такая система работает корректно только в случае «прозрачности» всей «виртуальной» сети, входящей в компанию. При наличии «черной растаможки», что характерно для наших условий, да и «серой», применяемой повсеместно, корректность определения полной стоимости товара и операционных издержек весьма условна, что сводит на нет все усилия по финансовому управлению виртуальным предприятием с помощью «простых рецептов» логистических цепочек. Для этих случаев применяются методы управления финансовыми холдингами, о которых следует говорить отдельно.

В заключение хотелось бы обратить внимание на один аспект, который пока ускользнул от внимания аналитиков. Методологии Supply Chain и CSRP взаимно дополняют друг друга. Первая фокусируется на «глобальной» логистике и связанных с ней, «внешних», по отношению к производству, процессах, вторая — на «внутренних», в частности, на тонком управлении заказами и расширенном управлении издержками, благодаря трактовке бизнес-цикла товара, как «расширенного» производственного цикла, и, что важно, не «товара вообще», как MRP, а «товара в конкретном заказе», что точно соответствует идеологии Supply Chain.

Учитывая, что «ядром» логистических цепочек является производитель (в глобальном толковании — производитель добавочной стоимости), можно сказать, что методология CSRP — это методология производственного ядра Supply Chain. Объединение этих двух методологий в единой системе позволило бы выйти на новый качественный уровень систем и методологий управления ресурсами бизнеса. Автоматизированные системы, поддерживающие «тонкое» управление заказами и логистическими цепочками, могут дать очень значительные конкурентные преимущества. Исходя из общих тенденций развития делового программного обеспечения можно предположить, что такого рода предложения должны появиться уже к концу текущего года.

СОТВОРИ ИЗ ХАОСА ПОРЯДОК

Появляющиеся Web-системы наконец-то действительно могут привнести управление в ИТ-проекты

Кэтлин Меламьюка

COMPUTERWORLD РОССИЯ, 25 мая 1999 г.

Слова «управление ИТ-проектами» звучат почти как оксюморон — сочетание взаимоисключающих понятий.

Спросите Дэйва Бэнко о том, как он обычно следит за выполнением плана-графика, и этот руководитель проектов из Pentamation Enterprises, фирмы — разработчика административного ПО, скажет вам, что никак. «Мы всегда составляли планы проектов только для заказчиков, а сами ничем таким не пользовались. План-график обычно чертим на бумаге».

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

Неудивительно, что, по заключению Standish Group, 84% ИТ-проектов оканчиваются сорванными сроками, превышением бюджета или вовсе ничем. Это данные из исследования под названием «Хаос», проводимого этой фирмой на основе информации о тысячах проектов, почерпнутой из различных обзоров, сообщений рабочих групп и интервью.