Как правильно выбирать ERP-систему

Оглавление журнала

Владимир Чаадаев - выпускник МИФИ (специальность - экспериментальная ядерная физика). С 1980 г. занимался разработками научной аппаратуры, систем сбора и обработки информации. С 1993 г. - менеджер проектов в области системной интеграции (сети, базы данных). C 1996 г. работает руководителем проектов и консультантом по финансам в области внедрения ERP. Имеет опыт работы с BAAN, Oracle E-Business Suite, SAP/R3. С 2004 г. основное направление деятельности - организация управления компаниями с применением информационных систем.

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

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

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

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

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

Кто и как должен выбирать

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

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

Сбор требований к системе

Мы будем рассматривать здесь только функциональные требования, основными источниками которых являются:

• стратегические цели и задачи компании;
• оперативные бизнес-процессы;
• требования финансового учета;
• сопрягаемые информационные системы.

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

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

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

Требования оперативного управления

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

Рассмотрим в качестве примера функциональную модель "Управление основной деятельностью производственного предприятия" (для наглядности показаны только декомпозиция функций и информационные потоки, связанные с бизнес-функцией "Комплектация и отгрузка"). В основе модели лежит иерархическая функциональная структура компании. На рис. 1 приведен верхний уровень модели. На этом уровне обычно представлены функциональные области (ФО) управления компанией. Каждая ФО декомпозируется на бизнес-функции (БФ1). На рис. 2 представлена декомпозиция бизнес-функции "Производство и логистика". Этот уровень будет примерно соответствовать составу пакетов ERP. Следующий уровень декомпозиции (рис. 3) уже соответствует уровню бизнес-функций второго порядка (БФ2). Как правило, большая степень детализации модели не требуется. Каждая из БФ2 реализуется посредством одного или нескольких бизнес-процессов. При построении модели следует приводить только основные информационные потоки - те, что инициируют запуск бизнес-процессов или отражают результат их выполнения.

Сущность бизнес-функции. Необходимо дать краткую формулировку, в которой описана основная задача данной функции: "Отбор, комплектация, отгрузка продукции и подготовка товаро-сопроводительной документации (ТСД)".

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

Описания бизнес-процессов. Каждая функция реализуется посредством одного или нескольких бизнес-процессов, например: "Отбор, комплектация и отгрузка продукции железнодорожным транспортом", "Отбор, комплектация и отгрузка экспортной продукции автотранспортом".

Необходимо кратко описать бизнес-процессы, реализующие функцию. Очень удобно использовать для этого модели в стандарте UML (Use Сase). Наиболее важно отражение особенностей, связанных со спецификой вашего бизнеса. Так, по бизнес-процессу "Отбор и комплектация поставок" может быть приведена следующая информация:

• отбор продукции производится только из свободного и зарезервированного для данного клиента запаса;
• при комплектации мелкие товары упаковываются в контейнеры, которые являются возвратной тарой и должны быть включены в накладную;
• при погрузке "поставка" разбивается на "отгрузки" по количеству мест (вагонов или автомобилей). На каждую отгрузку формируются комплект сопроводительной документации и счет-фактура.

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

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

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

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

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

Ожидания. Данный раздел заполняется после создания всей функциональной модели "as is". Производится оценка текущего состояния, предлагаются решения выявленных проблем управления и описывается, как, согласно ожиданиям, должна работать каждая функция и какие задачи должна решать информационная система.

Ключевые бизнес-потоки

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

Требования к данным

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

В первую очередь следует обратить внимание на статические объекты, которые, как правило, не изменяются в ходе выполнения бизнес-процессов: "Номенклатурный справочник", "Поставщики", "Клиенты", "Банки", "Склады", "Оборудование", "Производственные спецификации". Наиболее важным из них является "Номенклатурный справочник", который содержит описание позиций товарно-материальных ценностей и услуг, используемых или производящихся компанией. Для каждой номенклатурной позиции справочник содержит массу информации, используемой многими бизнес-функциями. Кроме того, существует ряд непосредственно связанных с номенклатурным справочником объектов: "Партии", "Производственные спецификации", "Производственные маршруты", "Себестоимость". Необходимо отразить в требованиях важнейшие характеристики вашей продукции. В частности, для некоторых типов производства большое значение имеет возможность работы с переменными характеристиками изделий, например длиной или концентрацией раствора. Для таких объектов, как "Поставщики' и "Клиенты", иногда требуется вести отдельные расчеты по каждому контракту.

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

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

Финансовые требования

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

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

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

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

Интерфейсы с другими системами

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

Результаты сбора требований

Итак, по завершении перечисленных работ у нас собраны основные требования к системе в виде:

• функциональной модели;
• требований к данным;
• ключевых бизнес-потоков;
• финансовой модели;
• описаний интерфейсов с другими системами.

Выбор системы

Отбор по критерию "функциональность - стоимость"

Вначале необходимо выбрать систему в диапазоне "требуемая функциональность - доступная стоимость". В настоящее время на российском рынке предлагается несколько систем, позиционируемых поставщиками как ERP. Несомненными лидерами как по производительности, так и по функциональности являются SAP R/3 и Oracle E-Business Suite. Именно эти системы позволяют решить заявленную в наименовании класса систем задачу планирования корпоративных ресурсов. Они являются наиболее универсальными, но и в их функциональности есть существенные различия: для одних целей лучше использовать R/3, а для других - Oracle E-Business Suite. На рынке представлено несколько систем среднего уровня, и задача выбора усложняется.

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

Выбор на основе функциональных требований

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

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

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

Одним из условий тендера должно быть предоставление списка предприятий с аналогичным типом бизнеса, где эта система уже внедрена. Если такие предприятия существуют, постарайтесь их посетить или установить контакт с ними. Задайте ряд ключевых вопросов, которые у вас неизбежно накопятся. Необходимо проверить оценку производительности системы и оборудования, причем очень важно подтвердить, что там используется именно необходимая вам функциональность. Если такого предприятия не найдется, то имеются значительные риски; для того чтобы их снизить, перед запуском основного проекта необходимо выполнить "пилотный" проект или его упрощенный вариант - Conference Room Pilot.

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

Результаты подготовки к внедрению

Основными результатами подготовки к внедрению являются:

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

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

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

[an error occurred while processing this directive]

Версия для печати