Финансовый директор как интегратор бизнеса

Основные аспекты интеграции и выгоды, которые она обеспечивает, представлены в табл. 2.1.

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

Ликвидация «системного спагетти»

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

ERP-системы должны приспосабливаться и к внутренним (структурным), и к внешним (рыночным) изменениям.

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

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

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

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

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

ПРИМЕР

Формирование новой стратегии интеграции после мегаслияния

До слияния рассматриваемая глобальная химическая компания установила программное обеспечение SAP на всех своих предприятиях в США, странах Европы и Латинской Америки. Одна ERP-система использовалась для обслуживания производства и поставок, другая – для обеспечения работы коммерческой и финансовой служб. При этом элементы производственной и финансовой систем были взаимосвязаны и охватывали почти 200 глобальных бизнес-процессов, сконфигурированных в системе mySAP ERP и требующих существенной поддержки со стороны внутреннего и внешнего обслуживающего персонала.

Компания получила значительную выгоду от первоначальной синергии и решила выйти на следующий уровень интеграции на основе использования решений SAP для поддержки работы других служб. В то же время она продолжала включать в свою ИТ-среду хотя и лучшие, но разрозненные решения, что неизменно вело к появлению «системного спагетти». Финансовому директору и ИТ-директору постоянно приходится решать двойную проблему – как расширить функциональность базового программного обеспечения при одновременном упрощении структур, систем и процессов. Много времени отнимала проблема координации централизованного управления обслуживанием, региональными и локальными центрами поддержки в отдельных странах.

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

Различия корпоративных культур проявились в совете директоров объединенной компании. Представители первой компании настаивали на применении решений SAP в производственной сфере и поначалу убедили всех продолжить внедрение SAP на приоритетных участках. Но согласие длилось недолго. ИТ-директор объединенной компании, который ранее отвечал за внедрение ERP-систем в приобретенной компании, не торопился переходить к более сложному решению. В то же время финансовый директор объединенной компании говорил: «Пора бы уже добиться синергии как на уровне компании, так и на уровне финансовой службы».

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

• Новые системные требования, обусловленные слиянием: необходимость синергии, сокращения затрат, максимального использования объединенного потенциала – законодательство (соответствие производства нормам и правилам), информация (порталы), технология (e-Procurement), синергия в сфере продаж/связей с клиентами (CRM), изменение межфункциональных потребностей, например в области прогнозирования и отчетности.

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

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

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

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

Программа действий и стратегия ИТ-директора предусматривают:

• полную интеграцию и достижение максимальной синергии;

• получение прибыли от инвестиций в информационные технологии;

• оптимизацию цепочек поставок, коммерческих и финансовых процессов;

• использование лучших решений e-Business в отрасли.

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

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

2. «Раскрыть» системы и добиться совместимости процессов и данных на детальном уровне. Это дорогое и сложное в поддержке решение, но в этом случае все системы должны функционировать более надежно.

ИТ-директор предложил два взаимодополняющих решения.

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

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

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

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

Вот некоторые рекомендации для финансового директора, которому приходится иметь дело с «системным спагетти»:

• постарайтесь упорядочить системную среду – стандартизация и глобализация приводят к упорядочению;

• превратите свои инициативы развития из множества децентрализованных проектов в глобально скоординированную программу – управляйте обработкой и стандартизацией данных в масштабах всей компании из корпоративного центра;

• для управления крупными проектами на местах выбирайте централизованное управление;

• используйте глобальные бизнес-процессы – вы не сможете ввести ИТ-стандарты, обеспечивающие максимальную выгоду, пока бизнес-процессы не будут согласованными.

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

Что такое Beyond ERP

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

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

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

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

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

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

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

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

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

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

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

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

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

Упрощение

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

• нарастающая глобализация – слияния и поглощения (рост масштабов), изменение взаимоотношений в бизнесе, ослабление торговых барьеров, глобальная конкуренция;

• изменение отношений с клиентами – защита прав потребителей, управляемое обслуживание, Интернет и решения e-Business;

• ценовое и законодательное давление – структура себестоимости, изменения в оплате труда, законы о защите интеллектуальной собственности, новое законодательство;

• прогресс в обновлении продукции – технологические и научные прорывы, усиление конкуренции, повышение ожиданий инвесторов и рынка, проблема поиска и удержания талантов.

Поскольку процессы изменения любой отрасли определяются примерно тем же набором факторов, разумно поставить вопрос так: какое соотношение централизации и децентрализации оптимально для вашей компании? Централизованная модель исходит из представлений об интегрированном глобальном бизнесе – со стратегическим контролем, общими клиентами, общими продуктами и общими процессами. Децентрализованная модель предполагает существование холдинговой компании с самостоятельными бизнес-единицами, имеющими разные клиентские базы, разные рынки, разные каналы сбыта, разные продукты и уникальные процессы. Так, в фармацевтическом секторе[5] примером реализации централизованной модели бизнеса может служить Bristol-Myers Squibb, примером полуавтономной модели – AstraZeneca, а примером довольно высокой степени децентрализации – Johnson & Johnson.

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

Существует три корпоративных ИТ-модели.

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

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

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

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

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

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

На рис. 2.7 представлены обе модели бизнеса – централизованная и децентрализованная – вместе с характеристиками соответствующих ИТ-моделей.

Возможности изменения соотношения централизации и децентрализации в ERP-инфраструктуре таковы:

• максимально централизованная ИТ-модель – единственный «клиент» на центральном сервере базы данных;

• степень децентрализации может задаваться и регулироваться путем задания и распространения корпоративного шаблона или путем использования собственной технологии распределенной обработки информации;

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

Итак, можно выбрать один из следующих вариантов.

1. Развертывание единой глобальной ERP-системы.

2. Развертывание системы обработки унифицированных данных «клиент-сервер».

3. Установка ядра интеграции корпоративных приложений.

Какой из вариантов вы считаете наиболее приемлемым для своей компании?

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

Что грядет за эпохой ERP

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

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

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

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

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

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

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

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

Давайте рассмотрим выгоды от модели Beyond ERP в различных областях.

В принятии стратегических решений

• Освобождение от обработки транзакций, например для автономного сценарного планирования и моделирования.

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