Западные интегрированные системы управления предприятием: российские подводные камни

В последнее время наблюдается медленно, но верно растущий интерес российских предприятий к внедрению интегрированных автоматизированных систем управления предприятием класса MRP II / ERP

Валерий Супер — консультант отдела промышленных и финансовых систем компании «ФОРС-Холдинг». Ему можно написать по электронной почте: vsuper@fors.ru

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

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

Полномасштабные западные ERP-системы

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

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

Ориентированность на события и ориентированность на документы

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

Если внимательно посмотреть, то учет и регистрация материальных потоков в западных системах базируются на регистрации событий в учетном регистре. Рассмотрим, например, прием товарно-материальных ценностей (ТМЦ) на склад. В большинстве систем применительно к данной ситуации событие трактуется как однократный акт приема определенного количества ТМЦ одного вида. Каждое такое событие заносится в специальный учетный регистр системы (или в несколько регистров, в зависимости от типа операции приема). Именно таким образом в систему вводятся первичные данные. Если представить себе, что автоматизированной системы нет, а данные хранятся и обрабатываются по старинке на бумажных носителях, то такой стиль работы соответствует ведению записей в журнале («амбарной книге»). Этот журнал и есть множество первичных данных. Каждая строка журнала соответствует одному учетному событию. Таким образом, можно сказать, что системы ориентированы на события.

Посмотрим теперь, как та же самая ситуация реализуется в российской практике. Российская культура учета ставит во главу угла первичный документ. Транзакции системы будут считаться легитимными только при наличии соответствующих первичных документов. Документ трактуется традиционно, как некий бумажный носитель, обладающий набором атрибутов, на котором можно расписаться и поставить печать. Для приема ТМЦ на склад таким документом является приходный складской ордер. Первичные документы по учету и регистрации ТМЦ и, в частности, приходный складской ордер состоят из заголовка и позиций. В общем случае позиций может быть много, и это очень важно. С одной стороны, нетрудно видеть, что позиция приходного ордера прямо соответствует одной строке учетного регистра, то есть учетному событию, с другой — эти позиции объединены в документ, рассматриваемый как единое целое. То есть позиции такого документа обрабатываются синхронно. Получается, что первичный документ соответствует группе учетных событий, которые всегда должны обрабатываться синхронно. Таким образом, можно сказать, что российская культура учета ориентирована на документы.

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

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

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

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

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

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

Итальянское конто и англосаксонское конто

Российские стандарты бухгалтерского учета строят формат учетной фразы на так называемом итальянском конто. То есть формат бухгалтерской проводки имеет вид:

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

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

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

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

Попробуем ответить на вопрос: какова сумма оборотов с кредита счета № 5 в дебет счета № 1? Только не надо говорить, что сумма равна 60, так как эта операция вполне могла соответствовать, например, следующей группе российских проводок:

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

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

Трактовка многовалютного учета

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

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

Реинжиниринг бизнес-процессов

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

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

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

Проблемы преодолимы

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

Таким образом, лучшим решением было бы появление версий западных систем, локализованных для Восточной Европы (проблемы, обозначенные выше, характерны не только для стран бывшего СССР, но и для всего бывшего соцлагеря). Необходимо отметить, что этот процесс идет. С одной стороны, многие поставщики закрытых систем объявили о работах по созданию восточноевропейских версий своих продуктов. С другой — российские партнеры поставщиков открытых ERP-систем за последние несколько лет приобрели необходимые опыт и знания и достаточно успешно локализуют их своими силами.

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