Легкие, средние и тяжелые ERP-системы

--> Дата: Фев 18, 2008 1 462

Андрей Сухобоков
chimaf@mail.ru

Множество действующих в экономике предприятий можно разбить на следующие основные категории (по численности работающих): большие корпорации (более 10 тыс. сотрудников); средние корпорации — от 1000 до 10 тыс. человек; средние (от 100 до 1000) и малые предприятия (до 100 сотрудников). Большинству этих предприятий, независимо от их размеров, требуется комплексная система управления, которая охватывала бы все аспекты их деятельности: внутренний учет, планирование и управление, взаимоотношения с клиентами, поставщиками и партнерами. Иными словами, это должна быть система, соответствующая концепции ERP II.

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

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

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

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

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

Один из общепризнанных подходов к сопоставлению ERP-систем по функциональности был разработан аналитической компанией Arlington Software Corporation в рамках проекта ERP Evaluation Center. Согласно этому подходу для оценки функциональности используется дерево критериев, содержащее более 3600 частных критериев. Критерии нижнего уровня входят в критерии более высокого уровня со своими весовыми коэффициентами. Вершина дерева представляет собой комплексную численную оценку функциональности системы. В рамках проекта разработана таблица весов критериев и программные средства для решения многокритериальных задач.

Помимо критериев функциональности для ERP-систем компания разработала иерархии частных критериев для отдельных систем, входящих в состав ERP II: CRM (более 1100 критериев), PLM (более 1300 критериев), SCM (более 2200 критериев), BI (более 1300 критериев).

Имеющийся у автора опыт применения оценок ERP Evaluation Center показывает, что получаемые с помощью этих средств оценки функциональности систем разных классов располагаются в разных интервалах и почти не пересекаются. Так, оценки функциональности тяжелых систем лежат выше отметки 0,9, для средних систем они располагаются в интервале 0,6-0,7, а оценки легких систем находятся ниже точки 0,5. Это закономерно, поскольку большие корпорации уже давно оплачивают развитие тяжелых ERP-систем. Кроме того, их бизнес-процессы, как правило, значительно более сложны, а следовательно, и функциональность тяжелых систем изощреннее и учитывает большее число нюансов.

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

Масштабируемость технологической платформы

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

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

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

Характеристики технологической архитектуры измеримы и стабильны (в конкретной версии технологическая архитектура зафиксирована и не меняется). Именно поэтому ниже мы предложим прямые определения классов ERP-систем через свойства технологической архитектуры.

Легкая ERP-система

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

Рис. 1. Технологическая архитектура легкой ERP-системы.

Из ERP-систем этого класса на российском рынке наиболее известны "Управление производственным предприятием" на платформе "1С:Предприятие 8.0" и Microsoft Business Solutions-Navision с использованием Microsoft SQL Server Option.

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

Комплекс легких ERP-систем

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

Рис. 2. Пример технологической архитектуры комплекса из трех легких ERP-систем (обозначения см. на рис. 1).

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

Однако использование комплекса ERP-систем целесообразно только тогда, когда выполняются следующие условия:

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

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

Если же сформулированные условия не выполняются (нарушается хотя бы одно из них), например:

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

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

Средняя ERP-система

Определим среднюю ERP-систему как систему, использующую только один сервер баз данных и произвольное число серверов приложений. Известный пример такой системы — Microsoft Business Solutions-Axapta. Два варианта технологической архитектуры систем управления, построенных на основе средней ERP-системы с использованием трех серверов приложений, представлены на рис. 3 и 4.


Рис. 3. Архитектура системы управления на основе средней ERP-системы с централизованной библиотекой приложений (обозначения см. на рис. 1).	Рис. 4. Архитектура системы управления на основе средней ERP-системы, где каждый сервер приложений работает с собственной библиотекой приложений (обозначения см. на рис. 1).

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

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

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

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

Комплексы на основе средней ERP-системы

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

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

Рис. 5. Архитектура комплекса из одной средней ERP-системы с централизованной библиотекой приложений и двух легких (обозначения см. на рис. 1).

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

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

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

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

Тяжелая ERP-система

Определим тяжелую ERP-систему как систему, использующую произвольное число серверов баз данных и обеспечивающую работу произвольного числа серверов приложений с каждым сервером баз данных. Наиболее распространенный пример тяжелой системы — mySAP Business Suite. Два варианта технологической архитектуры тяжелой ERP-системы в составе четырех серверов приложений и четырех серверов баз данных представлены на рис. 6 и 7.

Рис. 6. Архитектура тяжелой ERP-системы с выделенной распределенной библиотекой приложений (обозначения см. на рис. 1).

Рис. 7. Архитектура тяжелой ERP-системы, в которой каждый сервер приложений работает с собственной библиотекой (обозначения см. на рис. 1).

Для работы с несколькими независимыми серверами баз данных тяжелая система должна иметь внутри себя описание структуры баз, расположенных на каждом сервере, чтобы строить запросы к ним, исходя из необходимости обработки конкретных данных. Иными словами, тяжелая система по определению включает в себя как один из компонентов систему управления распределенной базой данных, для работы которой используются серверы СУБД (см. рис. 6 и 7).

Как и в случае средних систем, рассматриваемые варианты технологической архитектуры различаются способом организации библиотеки приложений. В варианте на рис. 6 для библиотеки выделяются отдельные серверы, каждый из которых может использоваться несколькими серверами приложений, что обеспечивает сокращение затрат на сопровождение системы из большого числа серверов приложений, объединенных в компактные группы. В варианте на рис. 7 каждый сервер приложений работает с собственной библиотекой приложений, обеспечивается независимость серверов приложений и высокая масштабируемость системы. Этот вариант реализован в mySAP Business Suite.

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

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

Рис. 8. Архитектура тяжелой ERP-системы с пообъектным размещением серверов (обозначения см. на рис. 1).

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

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

Выводы

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

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

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

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

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

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

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