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

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

Два последних направления лежат в основе методологий управления так называемыми компаниями типа FM-CG (fast moving consumer good — быстро движущиеся потребительские товары — напитки, сигареты, консервы — это практически все «товары повседневного спроса», которые не производятся в мелком частном секторе, как хлеб,

например).

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

Стратегическое

планирование

ERP

Обобщенное FRP планирование производства

MPS

MRP II

Цеховой

план

Рис. 1. Взаимосвязь систем планирования

Кратко описав первоисточники постановки задачи корпоративного управления,

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

«документооборотный».

Несмотря на то, что «чистых» решений, основанных на одном из таких подходов не существует, тем не менее, «истоки» очень сильно сказываются на возможностях и качественных характеристиках систем. Сегодня очевидны преимущества функционального подхода в области управления производством, типичными представителями которого являются решения от Ваап и Symix. Финансовый подход проповедует компания SAP в своем продукте R/3, действительно, это оказалось очень эффективно для управления бизнесом холдингового типа и чисто финансов ых институтов.

Исключительно популярный в России документооборотный вариант среди западных «больших систем» в чистом виде, по-видимому, не встречается вовсе, хотя его влияние сильно ощущается, например, в Oracle Application.

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

«внешние» по отношению к «основной» функциональности системы. Также распространенным является вариант интеграции систем финансово-экономического управления и системы, обеспечивающей реализацию того или иного варианта документооборота (в том числе таким, как Lotus Notes или Microsoft Outlook).

Итак, тиражируемые MRP системы, как правило, дополненные хотя бы элементарными системами управления складами и финансами, начали свое победное шествие где-то в начале 80-х (заказные и уникальные появились значительно раньше).

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

Часто можно услышать диалог заказчика с поставщиком решения примерно такого содержания: «но вы не можете решить нужные мне задачи, а делать так, как вы предлагаете — значит пользоваться кремниевым топором», — ответ поставщика: «да пожалуй, но чехол-то топора от Oracle, Microsoft, Sybase!». Самое поразительное, что стоимость таких решений, включающих запуск в промышленную эксплуатацию, иногда превышает стоимость внедрения SAP R/3, на сравнимых конфигурациях, при значительно

более низкой функциональности (данный расчет ведется достаточно просто: общая окончательная стоимость проекта делится на количество запущенных, а не проданных рабочих мест), кстати и стоимость поддержки, часто предлагается в размере 25 % от стоимости проекта, вместо типичных 15—18% от стоимости программного обеспечения.

Также сравнимы с параметрами R/3 оказываются такие показатели, как «стоимость внедрения/стоимость ПО» (стоимость внедрения превышает стоимость собственно программного обеспечения от 2 до 15 раз, при типичном показателе около 3—5, при этом стоимость ПО считается по количеству реально заработавших рабочих мест) и процент

«внедряемости» (процент внедренных решений от общего количества проданных, что составляет цифру иногда существенно ниже 70%, типично около 60%, для «успешных» систем).

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

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

Можно было бы об этом и не говорить, в конце концов бизнес на ПО — тоже бизнес. Но печальный факт состоит в том, что внедрение автоматизированной системы

«замораживает» «внедренные» управленческие решения — и лед очень трудно потом разморозить, практически можно только взорвать. Весьма модный у нас термин «бизнес-

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

От MRP II к ERP

Рис. 2. Система финансового планирования

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

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

•существенная географическая и концептуальная (диверсификационная)

глобализация как сбыта, так и поставок, в том числе для мелких и средних производителей;

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

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

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

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

•«спуск» проблем сбыта и логистики к мелкому и среднему производителю. Перечисленные изменения потребовали переработки концепций, заложенных в

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

«бизнес» ресурсов предприятия. Фактически она формализовала представление об

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

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

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

Так как в бизнес-системах большое значение имеет схема финансового управления,

то представим на следующем рисунке систему финансового план ирования (FRP), в рамках

ERP (рис. 2.)

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

Концепция управления производственными ресурсами — CSRP (customer synchronized resource planning) — «планирование ресурсов, синхронизированное с потребителем», была предложена компанией Symix. Сущность данной концепции состоит в том, что при планировании и управлении компанией можно и нужно учитывать не только основные производственные и материальные ресурсы предприятия, но и все те ресурсы, которые обычно рассматриваются как «вспомогательные» или «накладные». Это все ресурсы, потребляемые во время маркетинговой и «текущей» работы с клиентом, послепродажного обслуживания проданных товаров, перевалочных и обслуживающих операций, а также внутрицеховых ресурсов. Таким образом учитываются все этапы «жизненного цикла» товара. На рис. 3 показано соотношение между понятиями CSRP, ERP и различными стадиями жизненного цикла товара.

Производственный

цикл

MRP

Рис. 3. Системы планирования ресурсов и жизненный цикл товара

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

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

перепланирование с использованием полноценного графического интерфейса. Благодаря

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

Реализация концепции CSRP позволяет управлять заказами клиентов и в целом,

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

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

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

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

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

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

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

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

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

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

(поддержки нескольких юридических лиц), так и с возможностью поддержки

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

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

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

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

• Специфические потребности поставок для каждой страны (региона),

требующие использования специальных комплектующих или материалов.

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

• Популярная ныне идеология CFM (Customer Focused Manufacturing) —

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

CFM находится не просто в адаптации товара к потребностям конкретного покупателя, а в постоянной поддержке «обратной связи» с покупателем и адаптации цепочки под них.

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