Итоги тысячелетия, столетия, года александр Прохоров

Вид материала

Статья

Содержание Из истории автоматизации методологий управления предприятия Сергей Колесников Модель одна — реализаций много Рис. 1. Взаимосвязь систем планирования

Подобный материал:

• Объединенная компания «Российский Алюминий», 2149.38kb.
• Итоги Второй мировой войны для Великобритании, 536.44kb.
• Конец двадцатого столетия и первые годы нашего нового тысячелетия в ретроспективе составляют, 116.51kb.
• Методичні рекомендації по розділу "Поліклініка", 2465.5kb.
• Итоги 2011 года дмитрий Медведев и Владимир Путин подвели в правительстве итоги года, 428.81kb.
• Декларация тысячелетия Организации Объединенных Наций, 150.18kb.
• Итоги ivстолетия. Культура XII-XIII в в. III четверть: V ст.(1262-1362). Образование, 402.83kb.
• В. М. Розин (Институт философии ран), 3988.06kb.
• Б. Б. Прохоров Экология человека: понятийно-терминологический, 2497.75kb.
• Унас в гостях блистательный писатель Александр Мелехов, 29.83kb.

ИЗ ИСТОРИИ АВТОМАТИЗАЦИИ МЕТОДОЛОГИЙ УПРАВЛЕНИЯ ПРЕДПРИЯТИЯ

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

Сергей Колесников

Computerworld Россия. 8 июня 1999

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

Для решения задачи управления была разработана методология планирования материальных ресурсов предприятия — MRP (Material Requirements Planning), однако оказалось, что кроме методических трудностей здесь имеются и математические, которые полностью были решены только с приходом вычислительной техники. Использование этой методологии подразумевает, как правило, применение MPS “Master planning schedule” — старой и хорошо известной под названием “объемно-календарное планирование”, методологии, которая является базовой практически для всех планово — ориентированных методологий.

После этого достаточно быстро был реализован вариант планирования производственных ресурсов (мощностей) — CRP “Capacity Requirements Planning”, методология которого принципиально была похожа на MRP, но речь шла о расчетах необходимых производственных мощностей, а не материалов и компонентов. Эта задача была существенно сложнее, поскольку требовала учета большого числа параметров, а окончательный расчет обязательно включал не только мощностной параметр, но и временную последовательность. Стандартная задача расчета производственных ресурсов “знает” об ограниченных мощностях обрабатывающих центров, но максимум, что она может сделать — это рассчитать “потребность” в рабочем времени для выполнения запланированной производственной программы при неограниченном горизонте планирования, либо показать превышения (недостаток) потребных мощностей при ограниченном. Если результат оказывался неудовлетворительным, то требовалось изменить производственную программу и повторить процесс сначала. Поскольку это весьма ресурсоемкая вычислительная задача, которая даже на современной технике может выполняться часами, то ясно как была нетехнологична эта процедура.

Объединение названных методологий дало задачу MRP “второго уровня” MRP II “Manufacturing Resource Planning” — интегрированную методологию планирования, включающую MRP\CRP. При использовании данной методологии обязательно подразумевается анализ финансовых результатов производственного плана, а также применение MPS и FRP “Finance resource/requirements Planning” — планирование финансовых ресурсов, правда без их интеграции в “динамическую систему”. (Часто пишется без добавления индекса II, так что в некоторых публикациях нужно ориентироваться по контексту, какая из методологий имеется ввиду.)

В целях ускорения проведения расчетов, особенно с учетом малой мощности компьютеров того времени, были разработаны методологии чернового планирования производственных ресурсов (или мощностей) — RCCP, которые позволили “утрясать” производственный график без проведения полной процедуры расчета, а затем уже производить окончательный баланс ресурсов по обеим “ветвям” планирования — как MRP, так и CRP. На этом уровне данная задача предлагается до сегодняшнего дня в виде тиражируемых решений — так называемых “MRP II систем”.

Однако в таком виде задача планирования ресурсов представляет интерес только для ограниченного числа “типичных MRP (MRP II) — производств”, среди которых: машиностроение, приборостроение и некоторые другие серийные сборочные производства, для которых задача расчета потребных ресурсов самоценна ввиду своей вычислительной сложности.

Модель одна — реализаций много

Естественно, для большинства производств “расчет чистых потребностей” оказался недостаточен и началось дальнейшее развитие “постановок” задач. Поэтому сразу было выделено несколько основных направлений развития методологии MRP, часть которых позже выделилась в самостоятельные методологии управления:

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

• интегрированное управление для заказного и мелкосерийного производства (машиностроение, автомобилестроение и др.);

• управление сложными финансово-сбытовыми и производственными структурами — холдинговое управление (“финансовое управление” — финансово-промышленные группы, “логистические цепочки” и “управление распределенными потребностями” — крупные торгово-производственные компании).

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

Кроме этого, сформировались самостоятельные задачи, потенциально реализуемые в виде “слабоинтегрированной” или даже автономной, как например управление складами, подсистемы:

• управление складским хозяйством (автоматизированные склады);

• управление “оперативным” контуром (интенсивной отгрузкой продукции);

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

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

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




Рис. 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 (автор не исключает что существуют неизвестные ему реализации этой задачи и, в этом случае, будет весьма признателен за возможность познакомиться с ней “вживую”).

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