под рубрикой УПРАВЛЕНИЕ

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

ERP-системы – мэйнстрим или тупик?

С. А. ДЗЮБА,
Иркутский государственный технический университет
E-mail: dfirk@mail.ru

Всё ли благополучно в королевстве?

На любом крупном или динамично развивающемся предприятии система класса ERP[1] в том или ином виде уже функционирует или её планируют внедрить. Производители и поставщики этих систем убеждают: именно здесь мэйнстрим средств корпоративного управления. Потребители вроде бы отвечают согласием, и ERP оказывается базовым средством построения системы управления предприятием.

Динамичный рост рынка ERP-систем также говорит в пользу благополучной картины. Действительно, при наличии каких-либо системных проблем в этой сфере логично ожидать негативной реакции потребителей. Но имеется ряд причин полагать, что потребители ERP-систем, так же как их поставщики, не заинтересованы в правдивой информации о результатах внедрения.

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

2. Обладание ERP-системой, причём не какой-нибудь, а одного из мировых брендов, считается важнейшим средством увеличения капитализации компании, независимо от эффективности её эксплуатации. Отчасти такое положение дел оправданно, поскольку простое наличие системы уже подтверждает отсутствие управленческого хаоса. В этом плане здесь ситуация аналогична управлению качеством: сертификация по стандарту ISO-9001 о реальном качестве продукции, в общем-то, ничего не говорит, но сигнализирует, что этой проблемой хотя бы занимаются. Иными словами, есть заинтересованность в приобретении системы вне связи с экономическим эффектом.

3. Отсутствие у потребителя альтернативы: если он испытывает потребность в обработке больших потоков пространственно распределённой управленческой информации, то иных средств, кроме ERP, ему не предлагают.

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

Косвенно об этом свидетельствует такой факт. Среди клиентов фирмы «Альт»[2], предлагающей решения в сфере финансового и инвестиционного анализа, реализованные на MS Excel, много обладателей ERP-систем. Дублирование указанной функциональности, имеющейся в ERP-системах, продуктами «Альт» сигнализирует, что в «больших» системах они не востребованы.

Немногочисленные публикации в периодических изданиях говорят, что за утверждением «внедрение ERP» стоит реальный запуск только отдельных модулей систем[3].

ERP: стандарт управления или маркетинговая ловушка?

Аббревиатура ERP настолько популярна, что уже укоренилась убежденность, будто она определяет не просто тип информационных систем, но и стандарт управления. Такое представление имеет место не только на «бытовом» уровне, но и в специальных изданиях. Так, в «Лекциях по ERP»[4] со ссылкой на Gartner Group приводится цепочка, именуемая эволюцией стандартов: MRP 0g MRP Ig MRP IIg MRP II+g ERPg ERP+g ERP II.

Мало того, что она нанизана на маркетинговый стержень («наш новый продукт на 50% лучше отмывает…»), в действительности из всех её звеньев стандартом в прямом смысле этого слова является только MRP II (Manufacture Resource Planning – планирование ресурсов производства). Последняя его версия, осуществлённая Американской ассоциацией управления производственными ресурсами (APICS), датируется 1989 г. Она образовалась как слияние двух более ранних стандартов MRP (Material Requirements Planning – планирование потребности в материалах) и CRP (Capacity Requirements Planning – планирование потребности в средствах производства). Индекс «II» появился вследствие ненамеренного совпадения аббревиатур. В приведённой выше цепочке MRP обозначен как MRP 0, а CRP отсутствует вообще.

Так ли уж важно, является ли ERP стандартом? Той же APICS это нисколько не мешает активно продвигать системы этого типа. В отношении влияния на продажи это, видимо, действительно не важно. Однако превращение ERP из технического понятия в маркетинговое позволяет продавцам приписывать системам свойства, которыми те не обладают[5].

Полезно взглянуть на ERP-системы с позиции процессного подхода. По стандартной классификации все бизнес-процессы предприятия делятся на основные и вспомогательные. Иногда вспомогательные подразделяются на процессы управления и обеспечения. К основным относятся процессы, обеспечивающие производство основной продукции предприятия, к вспомогательным – стабильное течение основных процессов. Из табл. 1 видно, что система класса MRP II будет использовать только основные процессы, а ERP – ещё и вспомогательные.

Таблица 1
Наполнение функциональности MRP II и её расширение в рамках ERP

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

Опыт специалистов по процессному управлению свидетельствует, что тотальное описание процессов предприятия на нижнем уровне детализации (т.е. доведённое до первичных документов) оказывается некорректной задачей. А именно: даже если все процессы предприятия удаётся описать и каким-то чудом их непротиворечиво согласовать, то любая попытка внести изменения окажется невыполнимой из-за чрезмерной сложности. Поэтому специалисты-практики ограничиваются описанием только важных и проблемных бизнес-процессов.

Стандартизация системы MRP II реализована через детальное описание типового основного производственного процесса. Можно заключить, что причиной отсутствия подобной стандартизации для систем ERP, скорее всего, является невозможность описания всех вспомогательных процессов с требуемой степенью детализации. Что не исключает стандартизированности ERP на более высоких уровнях. В качестве типичного примера можно опять привести систему менеджмента качества ISO-9001. Она стандартизирует основной производственный процесс на верхнем уровне описания, без технической детализации. Результат: данный стандарт превратился в инструмент маркетингового воздействия на потребителя, что, быть может, не столь очевидно и в случае ERP.

Конкурентные преимущества обращаются в недостатки

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

В этом есть очевидные выгоды в сравнении с информационной системой, построенной в виде набора разрозненных автоматизированных решений. В отечественной практике они известны под названием АРМ (автоматизированное рабочее место). Более удачен термин «трансакционные системы»[6]. Он означает, что каждая система предназначена для обработки ограниченного набора бизнес-трансакций и работает на базе собственной структуры данных. Такие системы могут быть изолированными друг от друга, либо, в лучшем случае, организовывать между собой ограниченный обмен в режиме экспорта и импорта.

Унификация среды и интегрированность структур данных в централизованных системах устраняют основные недостатки, присущие трансакционным системам. Именно в этом причина их впечатляющего успеха, но централизация породила и свои логические противоречия. Они особенно выпукло проявляются в ERP-системах.

Унификация среды приводит к эффекту, который можно назвать эффектом кухонного комбайна. Главный потребитель ERP-систем – крупный бизнес, а он нуждается не столько в универсальных, сколько в специализированных решениях. Действительно, размещение проживающих в отеле аналогично складской логистике: заселение и высвобождение номеров полностью идентично движению товара в разрезе ячеек хранения. Точно так же и процессы, происходящие на кухне любого ресторана, укладываются в рамки стандарта MRP II. Но представление этих процессов в рамках ERP потребует от пользователей невероятно развитого абстрактного мышления.

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

Централизованность структур данных, помимо очевидных преимуществ, порождает и не столь очевидные недостатки. Крупный бизнес испытывает потребность в системах с большой пропускной способностью информации. Одним из важнейших способов её увеличения является стабильность участвующих процессов. В рамках ERP-системы происходит интеграция основных и вспомогательных процессов. Они разнородны, поскольку вспомогательные процессы (как процессы управления) служат для стабилизации основных. В кибернетике их взаимодействие описывается законом необходимого разнообразия[7]. Он гласит, что стабильность управляемых (в данном случае основных) процессов тем выше, чем выше нестабильность управляющих (в данном случае вспомогательных).

Централизация структур данных, в рамках которой интегрируются стабильные и нестабильные процессы, неизбежно приводит к снижению пропускной способности системы в целом. Нестабильность здесь понимается в кибернетическом смысле как высокое разнообразие управления. Так, Росс Эшби в качестве примера приводит фехтовальщика: вероятность уцелеть (то есть не допустить дестабилизации основного процесса) для него тем выше, чем более разнообразно он орудует шпагой. Под снижением пропускной способности также понимается не уменьшение объёма передаваемых сообщений в битах, а снижение актуальности и достоверности информации из-за постоянной борьбы с её структурной противоречивостью.

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

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

На какой бизнес ориентированы ERP-системы?

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

В таком случае логично перейти к вопросу: быть может, ERP-системы именно вследствие этих качеств в большей степени соответствуют запросам среднего бизнеса? (Подобно тому, как кухонный комбайн более приемлем на семейной кухне, чем в крупном ресторане.) Этому, в частности, способствует свойство масштабируемости ERP-систем, то есть способность поддерживать стабильную производительность для любого разумного количества пользователей. И система с малым количеством пользователей за приемлемые деньги будет доступна бизнесу соответствующего масштаба.

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

Типовой процесс внедрения ERP-системы включает следующие стадии.
1. Заключение договора, в котором формулируются принципиальные требования к системе.
2. Написание технического задания, где основные требования будут сформулированы более развёрнуто. Здесь заказчик подтверждает, что он действительно хочет получить именно такой результат.
3. Составление календарного плана с указанием функциональности системы и сроков реализации. Здесь заказчик узнаёт, что полноценно работающую систему ему предстоит увидеть только на самом последнем этапе. При этом основные работы оплачиваются на предыдущих этапах. Поскольку это не противоречит подписанному им договору и соответствует утверждённому им техническому заданию (по-другому, действительно, невозможно), он вынужденно соглашается.
4. Разработку технического проекта. Здесь формируются наиболее детальные требования к системе, по которым она и будет настроена. На этом этапе заказчик старается максимально обезопасить себя, придираясь к каждой детали. Но оказывается, что в рамках утверждённого им же календарного плана на удовлетворительную проработку у него нет времени. А изменение календарного плана в соответствии с подписанным им же договором влечёт за собой и изменение финансирования проекта. Заказчик ставит подпись в надежде отшлифовать систему во время приёмки.
5. Составление требований к контрольному примеру. Тут заказчик подтверждает, что действительно, если на основе таких-то исходных данных будет получен такой-то результат, это будет означать, что система обеспечивает необходимую функциональность. Заказчик понимает, что контрольный пример хоть и соответствует техническому проекту, но будет моделировать идеальную ситуацию.
6. Составление требований к пусконаладочным испытаниям. Здесь заказчик узнаёт, что принимать ему предстоит некую демоверсию системы, построенную на утверждённых им контрольных примерах.
7. Составление требований к пусконаладочным работам. Из этого документа следует, что на данном этапе заказчик может рассчитывать только на обучение персонала и исправление недочётов в рамках технического проекта.

Приведённый пакет документов прикрывает исполнителя внедрения со всех сторон. И съедает до 70% сметы проекта. Иными словами, заказчик только 30% сметы использует на собственно реализацию проекта, а за счёт оставшихся 70% оплачивает страховку исполнителя от своих же дополнительных требований и претензий.

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

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

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

Процессные системы

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

На первый взгляд, здесь есть сходство с описанием трансакционных систем – те же собственные структуры данных и обмен между ними. Но разница между ними такая же, как между доморощенными АРМами и решениями на платформе 1С (табл. 2). Трансакционные системы не конкурируют ни с централизованными, ни с процессными системами. Это пройденный этап эволюции. Их наследником являются процессные системы, поскольку ни одно из свойств этих систем не хуже, чем у трансакционных. Для централизованных систем это не верно, они хуже по конфликтности процессов и адаптивности среды.

Таблица 2
Сравнение ключевых свойств различных типов информационных систем

Свойство

Системы

трансакционные

централизованные

процессные

Структура данных

Подсистемы имеют собственные структуры

Структура данных принадлежит системе в целом. Подсистемы могут владеть только отдельными элементами структур.

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

Дублирование информации в подсистемах

Одна и та же информация может содержаться в разных подсистемах

Информация формируется системой в целом и не дублируется

Информация распределена между процессами и может дублироваться

Владение информацией

Kаждой подсистеме требуется собственный ввод информации (несколько владельцев). Возможен частичный обмен

Используется принцип однократного ввода (единственный владелец). Необходимость в обмене отсутствует

При обмене между подсистемами у дублирующейся информации назначается единственный владелец. Эта мера сохраняет принцип однократности ввода

Kонфликт процессов

Изолированность подсистем исключает возможность конфликта процессов

Использование разными процессами одних и тех же структур данных способствует возникновению конфликтов

Дублирование информации позволяет адаптировать структуры данных под специфику процессов и снимает конфликты

Унификация среды пользователя

Среда и средства разработки у каждой подсистемы могут быть индивидуальными

Среда и средства разработки едины для всей системы

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

Адаптивность подсистем под индивидуальные процессы пользователя

Подсистемы специально разработаны под процессы пользователя

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

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

Процессные решения уже давно применяются на практике. С одной стороны, это частичное (то есть как раз процессное) внедрение ERP-систем. С другой стороны, это процессные конфигурации 1С: «Торговля», «Бухгалтерия», «Кадры». Их пользователи (а это малый и средний бизнес), как правило, предпочитают именно эти решения в противовес комплексной конфигурации, где те объединены по принципу централизации. Причина – конфликт процессов, который значительно проще преодолеть их децентрализацией, чем регламентацией.

Сложившуюся ситуацию в целом можно определить как деформацию рынка. Несмотря на фактическую востребованность именно процессных систем, производители с невероятным упорством продвигают системы централизованные. В той же линейке решений от 1С, чуть ли не единственной, предлагающей процессные системы, в качестве вершины позиционируется 1С «Управление промышленным предприятием» (УПП) – система, очень близкая к централизованной ERP (в ней не реализован лишь блок MRP II). Характерно, что за значительное время присутствия на рынке она так и не принята потребителями. Пользователи процессных решений от той же фирмы совсем не спешат пересаживаться на более «прогрессивную» систему. И трудно сказать, какой потребуется срок, чтобы производители осознали истинные нужды потребителей.

[1] ERP – Enterprise Resource Planning (планирование ресурсов предприятия) – класс корпоративных информационных систем комплексной автоматизации учёта и управления.

[2]http://www.alt-invest.ru/software/users/index.htm

[3]Коржов О. В., Суковатин И. В. и др. Управление бизнес-процессами контроля и регулирования финансового плана в системе SAP R\3 ОАО «НТМК» // Менеджмент в России и за рубежом. 2005. №4. С. 65–73; Криворученко Е., Никитин Б. Решения SAP управляют строительными проектами компании «Ямалгазинвест» // Технологии ТЭК. 2006. №4. С. 106–108.

[4]Балахонова И. В., Волчков С. А. и др. Лекции по ERP (http://www.cfin.ru/itm/kis/erp.shtml).

[5] Верников Г. Г. Корпоративные информационные системы: не повторяйте пройденных ошибок // Менеджмент в России и за рубежом. 2003. №2. С. 52–64.

[6] Кинг Д. Продолжая начинания ERP (http://www.cfin.ru/itm/kis/erp_mpc.shtml).

[7] Эшби У. Р. Введение в кибернетику. М.: Иностранная литература, 1959. – 432 с.