Библиотека управления

ERP-системы — мэйнстрим или тупиковая ветвь?

Дзюба Серегей АнуфриевичДоцент кафедры Финансы и кредит ИрГТУ

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

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

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

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

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

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

Косвенным признаком неблагополучия в королевстве является приверженность потребителей к «лоскутной» автоматизации. Действительно, если ERP предлагает комплексное решение всех сфер производственного и финансового управления, то внедрение отдельных модулей (функциональностей) выглядит как покупка кухонного комбайна с одной или двумя насадками. А ведь именно такое решение является самым распространенным среди потребителей. Разумеется, прямого подтверждения этому невозможно найти на официальных сайтах владельцев систем, поскольку никто никогда публично не признается, что, обладая системой SAP, он рассчитывает зарплату в 1C. Но в качестве косвенного подтверждения можно взглянуть на перечень клиентов фирмы «Альт-Инвест»2, продвигающей решения в сфере финансового и инвестиционного анализа, реализованные на MS Excel. Здесь будет много обладателей ERP-систем, в которых эта функциональность также реализована. Дублирование ее продуктами «Альт-Инвест» сигнализирует о том, что у «больших» систем эта функциональность не востребована.

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

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

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

Аббревиатура ERP настолько популярна, что представляется само собой разумеющейся, будто она определяет не просто тип информационных систем, но и стандарт управления. Такое представление имеет место не только на «бытовом» уровне, но и в специальных изданиях. Так в «Лекциях по ERP»4 со ссылкой на Gartner Group приводится цепочка, именуемая эволюцией стандартов: MRP 0 → MRP I → MRP II → MRP II+ → ERP → ERP+ → 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. Из него видно, что MRP II покрывает только основные процессы, а ERP — еще и вспомогательные.

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

Функциональность

MRPII

ERP

Управление материальными ресурсами

Формирование заказов поставщикам исходя из производственной программы, складских запасов и условий поставки. Отпуск материалов в производство, приход готовой продукции

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

Управление производственными ресурсами

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

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

Управление людскими ресурсами

Планирование человеко-часов в разрезе специальностей для выполнения производственной программы

Управление движением и затратами на персонал

Управление финансовыми ресурсами

 

Управление сводными бюджетами распределения финансовых ресурсов

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Типовой процесс внедрения ERP-системы включает следующие стадии:

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

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

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

4. Разработку технического проекта. Здесь формируются наиболее детальные требования к системе, по которым она и будет настроена. На этом этапе заказчик старается максимально обезопасить себя, придираясь к каждой детали. Но оказывается, что в рамках утвержденного им же календарного плана на удовлетворительную с его точки зрения проработку этого у него нет времени. А изменение календарного плана в соответствие с подписанным им же договором, влечет за собой и изменение финансирования проекта. Заказчик подписывает в надежде отшлифовать систему во время приемки.

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

6. Составление требований к пусконаладочным испытаниям. Здесь заказчик узнает, что принимать ему предстоит некую демо-версию системы, построенную на утвержденных им контрольных примерах.

7. Составление требований к пусконаладочным работам. Из этого документа заказчик узнает, что на этом этапе он может рассчитывать только на обучение персонала и исправление недочетов в рамках технического проекта.

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

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

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

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

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

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

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

Свойство

Транзакционные системы

Централизованные системы

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

7 Кинг Д. «Продолжая начинания ERP». http://www.cfin.ru/itm/kis/erp_mpc.shtml

8 Эшби У.Р. «Введение в кибернетику». — М.: «Иностранная литература». — 1959. — 432 с.