Компания выбрала стратегию интеграции, которая предполагала создание единого хранилища стандартных данных и одного ядра интеграции для изолированных и изменяющихся процессов. В некоторых странах и регионах эти процессы стандартизировались, а в других, где этому препятствовали, в частности, особенности местного законодательства, они приводились в соответствие с местными условиями.
   Сложная ситуация и «системное спагетти», которое получила вышеописанная компания, нельзя назвать чем-то необычным. Представленные в примере проблемы и расхождения во взглядах знакомы любой команде менеджеров, участвующей в слиянии компаний или пытающейся приспособить 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 в различных областях.
   В принятии стратегических решений
   • Освобождение от обработки транзакций, например для автономного сценарного планирования и моделирования.
   • Гибкость, позволяющая справляться с частыми и существенными организационными изменениями – консолидация и исключение прибыли при расчетах между подразделениями.
   • Возможность управлять стоимостью нематериальных активов, например исследований и разработок.
   • Получение полной картины событий и транзакций в реальном времени.
 
   В производственной деятельности
   • Взаимодействие с внешними партнерами, например нашей ERP с вашей ERP, нашего модуля учета расчетов по счетам с вашим модулем расчетов по счетам.
   • Внутреннее сотрудничество (через частные сети), например общие центры обслуживания – проверка счетов, разрешение споров, внутренний биллинг. Совместная работа – прогнозирование бизнеса, ценообразование по видам деятельности.
   • Централизованная обработка транзакций, децентрализация оценок и отчетности или, наоборот, – централизованный учет в общих центрах обслуживания при децентрализации операций сбыта и снабжения.
 
   В управлении информацией
   • Принятие стратегических решений.
   • Принятие решений на операционном уровне.
   • Финансы и бухгалтерский учет.
 
   В интеграционной инфраструктуре
   • Маршрутизация (управление документооборотом между несовместимыми системами).
   • Преобразование данных (согласование данных в несовместимых системах).
   • Совместно используемые унифицированные данные (совместное использование данных, общих для несовместимых систем).
 
   Общие центры обслуживания позволяют компаниям фокусироваться на том, что они делают наилучшим образом, и объединить административные функции с целью снижения их себестоимости и повышения эффективности. Разбивка пакета ERP на составляющие дает возможность устанавливать на каждой площадке только те элементы, которые там действительно необходимы. Свобода выбора и перекомпоновки позволяет компаниям централизовать и минимизировать административные функции, сохраняя распределенными другие функции, например производственные.
ПРИМЕР
Как обрести гибкость, необходимую для создания общего центра обслуживания
   Крупнейшая компания, работающая в сфере высоких технологий, рассматривала вопрос о создании общего центра обслуживания. Структурно эта компания представляет собой совокупность приобретенных в разное время предприятий, разбросанных по территории США и Канады. Каждое предприятие придерживалось собственного подхода к ведению дел и имело собственный набор программных средств. До недавнего времени эти предприятия самостоятельно осуществляли административные функции, включая набор и обучение персонала.
   Из-за различий в подходах к ведению дел сотрудники компании не были взаимозаменяемыми. Эксплуатация 35 разных пакетов программного обеспечения требовала наличия такого же количества курсов обучения персонала. Помимо прочего, ощущалась нехватка некоторых специалистов (например, в области налогового учета). По целому ряду причин компания решила создать общий центр обслуживания для контроля счетов кредиторов. Во-первых, расчеты по этим счетам осуществлялись в денежной форме и потому были важным элементом; во-вторых, на разных предприятиях использовались разные процедуры, не обеспечивающие единообразного качества данных; в-третьих, обработка счетов требовала больших затрат ручного труда, а при высокой текучести кадров это повышало издержки на обучение.
   Компанию очень интересовали возможности среды Beyond ERP, потому что она уже пробовала объединить существующие гетерогенные системы путем создания интеграционной инфраструктуры, но столкнулась с серьезными проблемами. Идея заключалась в выполнении процессов ввода и проверки счетов в ядре интеграции над 35 существующими системами. Счета должны были вводиться в новом общем центре обслуживания во Флориде и контролироваться на основе данных о поставках, поступающих от децентрализованных систем. После утверждения счета должны направляться обратно в децентрализованные системы для оплаты и отражения в учетных регистрах. В ближайшие пять лет предполагалось значительно увеличить долю централизованных услуг вплоть до практически полной централизации финансового и бухгалтерского учета.
   Проблемы, которые пришлось решать в ходе реализации этого проекта, были невероятно сложными. Поскольку первоначально в режим централизованной обработки переводилась только часть процесса «покупка-оплата», новому разрабатываемому своими силами решению требовалась совместимость со всеми 35 существующими системами: в каждой системе были свои коды поставщиков, счетов главной книги и т. п. Любое изменение в одной из этих базовых систем влекло изменения и в новом программном средстве, что чрезвычайно затрудняло его поддержку.
   Первоначальный план компании – наложить новый общий шаблон на существующие системы – оказался намного более трудным в реализации и потенциально обеспечивал меньшую стабильность, чем ожидалось. Несмотря на это, было решено выделить 35 млн долл. на реализацию пилотного проекта, поскольку экономия оценивалась почти в 90 млн долл. По окончании эксперимента в функции общего центра обслуживания могут быть включены подготовка финансовой и управленческой отчетности и, возможно, обработка счетов продажи.