Информационные технологии управления / Учебные пособия / ИТУ_Мастеров А.Г., Орлова

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

Кроме того, в 80-х сформировались новые характеристики рынка, которые существенно изменили требования к программному обеспечению менеджмента:

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

•резкое снижение времени жизни продукта на рынке;

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

•рост конкуренции и, в результате, снижение средней маржи, получаемой производителем, как следствие — резкое увеличение интереса к «тонкому» управлению издержками;

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

•«спуск» проблем сбыта и логистики к мелкому и среднему производителю.

Перечисленные изменения потребовали переработки концепций, заложенных в основу автоматизированных систем управления. Первыми среагировали поставщики «последней волны» (поставщики, предложившие решения достаточно поздно: Baan, Symix и не имевшие в своем багаже портфеля «унаследованных» проблем, как у SAP и Oracle) — была предложена концепция ERP — интегрированного планирования всех «бизнес» ресурсов предприятия. Фактически она формализовала представление об «интегрированных» решениях, охватывающих и связывающих планирование и управление всеми сферами деятельности

предприятия, включая производственные мощности, материальные

71

(товарные) и финансовые ресурсы. Предложенная, насколько известно автору, компанией Baan, она была быстро подхвачена практически всеми основными поставщиками MRP II систем, так как фактически не предлагала ничего нового, а лишь констатировала достигнутый уровень «постановки задач» для тиражируемых решений «больших» производственных систем.

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

Так как в бизнес-системах большое значение имеет схема финансового управления, то представим на следующем рисунке систему финансового планирования (FRP), в рамках ERP (рис. 2.)

Фокус — на потребителя, или как получить преимущества на рынке с помощью компьютера

Концепция управления производственными ресурсами — CSRP (customer synchronized resource planning) — «планирование ресурсов,

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

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

Реализация концепции CSRP позволяет управлять заказами клиентов и в целом, всей работой с ними на порядок «тоньше», нежели это было возможно раньше. Действительно, стало реальностью ежечасное изменение

72

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

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

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

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

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

73

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

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

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

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

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

74

«Логистическая цепочка»

Пр-во

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

•Популярная ныне идеология CFM (Customer Focused Manufacturing) —производство «ориентированное на покупателя».

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

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

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

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

75

вполне качественно работает и с off-line информацией. В принципе ее можно успешно реализовать и на Excel.

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

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

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

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

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

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

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

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

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

рынок.

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

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

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

Идея данных методологий состоит в том, что затраты на производство можно существенно сократить, если кардинально уменьшить складские

76

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

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

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

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

77

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

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

«Виртуальное предприятие»

Виртуальное предприятие

Пр-во

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

Баланс

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

78

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

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

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

4.6. Сотвори из хаоса порядок

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

Кэтлин Меламьюка, Computerworld Россия

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

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

И такая практика — не исключение. Как говорят многие руководители, настоящее управление проектами почти невозможно. Современный клиентсерверный инструментарий для управления проектами труден в освоении и

79

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

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

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

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

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

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

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

Глядя назад

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

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

80