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

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

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

От MRP II к ERP

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

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

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

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

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

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

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

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

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

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

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

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