материал_для_чтения_курсовик

Введение понятия логистическая цепочка было не менее революционным, нежели переход в производственном менеджменте к концепции 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% ИТ-проектов оканчиваются сорванными сроками, превышением бюджета или вовсе ничем. Это данные из исследования под названием «Хаос», проводимого этой фирмой на основе информации

о тысячах проектов, почерпнутой из различных обзоров, сообщений рабочих групп и интервью.

Выправить положение может Web

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

Кроме страниц участников, есть еще Web-страница руководителя с обобщенной точкой зрения на ход проектов.

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

Одна из первейших причин провала проектов лежит в отсутствии должного уровня связи между участниками, — утверждают глава Standish Group Джим Джонсон, — a Web

— великое и многообещающее средство общения». Нужно понимать, что стронуть управление проектами с мертвой точки только инструментарием невозможно. «Дурак останется таковым даже с инструментом, и Web ему не поможет», — говорит Джонсон.

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

Глядя назад

По мнению Тома Джакоба, руководителя проектов из компании — производителя радиологического оборудования Medrad, фактически управление проектами — это движение затылком вперед. «Руководители проектов подобны гребцам в лодке: те тоже видят, где проплыли, но не могут увидеть, что впереди».

Причина в том, что до сих пор своевременно вносить в проект изменения было очень трудно, говорит Дэвид Чад из British Aerospace. Как руководитель по интеграции систем, он внедряет систему управления ресурсами предприятия. «У нас месячный цикл отчетности, и это очень неприятный режим, — поясняет он. — Пока все отчеты будут собраны, может пройти шесть—семь недель с появления проблемы».

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

— говорит Стив Тол, координатор расписаний в отделении дизелей из General Motors Canada. — Пометки подытоживаются, мы обновляем расписание и распечатываем снова».

Глядя вперед

Первые Web-ориентированные средства управления проектами позволяют руководителям видеть статус проекта сегодня и планировать его на завтра. Это системы компаний Primavera Systems, ABT, PlanView, Welcom, Business Engine Software, NextPrise

и других.

Для Бэнко, использующего систему Webster компании Primavera с февраля 1998 года, это означало колоссальные изменения. Раньше участники проекта должны были заполнять листки учета времени на бумаге, потом все это вводилось в базу данных, а

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

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

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

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

Взгляд сверху

Как говорит руководитель проекта Джефф Эйблз из First Union, Web-средства к тому же дают обобщенное видение всех проектов, что невозможно в системах клиент-

сервер, хранящих информацию о каждом проекте в отдельном файле: «В Web-системах это непросто, но все же намного проще».

С помощью генератора Reporter в системе PlainView Эйблз получает обобщенный отчет, что позволяет усовершенствовать процесс управления проектами. «Мы можем

подключить модем и выйти на Web-страницу. Отметки поступают в реальном времени,

даже если наш клиент находится далеко».

Аеще новые средства помогают улучшить взаимодействие партнеров по проекту.

Кпримеру, British Aerospace ведет территориально распределенные проекты с привлечением внешних партнеров и поставщиков. «Web-подход позволяет нам собрать всю соответствующую информацию вместе, причем своевременно», — объясняет Чад.

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

— поясняет Бэнко.

Время рассудит

Несмотря на энтузиазм пользователей, Джонсон полагает, что основные проблемы

Web-инструментарию еще предстоит решить: «Значительный успех Web-систем в небольших проектах очевиден, но небольшие проекты в целом и так бывают успешнее».

Смогут ли новые средства справиться с большими проектами? «Время покажет, — говорит он. — Пока можно лишь сказать, что это многообещающие средства».

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

За и против Web-систем управления проектами

ЗА:

Легко изучить Легко пользоваться

Хорошо подходят техническому персоналу Хорошо подходят директорам Доступны с любой персоналки

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

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

ПРОТИВ:

Совсем новые инструменты; есть только первые версии Неизвестна масштабируемость