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

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

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

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

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

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

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

Технические аспекты

Централизованная или децентрализованная серверная площадка

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

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

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

При создании и эксплуатации серверной площадки в Москве или Санкт-Петербурге особых проблем не возникает. Можно даже не создавать ее физически, а арендовать необходимые вычислительные мощности в одном из расположенных в этих городах центров данных (связь с ними можно держать посредством «привычного» для локальных сетей канала в 100 Мбит/c), что позволяет заказчику, во-первых, использовать ровно тот объем вычислительных мощностей, какой необходим в данный момент, во-вторых, застраховаться от морального старения серверов, и в-третьих, получить гарантированное качество обслуживания.

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

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

Телекоммуникационная подсистема

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

Наиболее распространенная услуга, предлагаемая операторами в данном случае, — это услуга аренды каналов фиксированной полосы пропускания емкости (см. рис. 1). Стоимость аренды канала прямо пропорциональна его протяженности и емкости: чем длиннее и «шире» канал, тем он, разумеется, дороже. Количество требуемых каналов зависит от топологии сети заказчика: при топологии «звезда» оно на единицу меньше числа узлов сети (N-1), а при топологии «каждый с каждым» возрастает экспоненциально (число потенциальных связей пропорционально N!). Поскольку протяженность каналов изменить невозможно, можно оптимизировать только топологию и полосу пропускания (обычно применяются относительно неширокие полосы пропускания от 64 Кбит/с до 2 Мбит/с).

Следует учесть, что топология «звезда» крайне уязвима: при возникновении проблем на центральном узле «падает» вся сеть. Кроме того, фиксированная полоса пропускания неэффективна для передачи скачкообразного трафика: большую часть времени практически простаивая, она срезает «пики» трафика, когда необходимо в течение короткого времени передать значительный объем данных (например, когда готовится сводка финансовой отчетности).

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

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

Экономические аспекты

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

  • Головной офис корпорации находится в Москве, производственные и научно-исследовательские мощности — в Санкт-Петербурге, Екатеринбурге и Перми. Сбытовое подразделение выделено в самостоятельную компанию.
  • Управление корпорацией централизовано; из единого центра ведутся финансовое планирование, закупки, управление производством и т. п.
  • Предполагаемое количество и распределение активных пользователей ERP-системы таково: 400 пользователей в Москве и по 200 пользователей в других городах. Всего развернуто 1500 рабочих мест системы.
  • Объем трафика ERP-системы в расчете на одного активного пользователя составляет 0,4 Гбайт/месяц (значение получено на основе анализа реально функционирующих ERP-систем).
  • Поскольку точки регионального присутствия приходятся на крупные города с развитой телекоммуникационной инфраструктурой и достаточным количеством квалифицированных ИТ-специалистов, то для обеспечения функционирования ERP-системы применяются распределенные серверная площадка и система хранения данных, обмен данными при этом осуществляется через стандартные интерфейсы. Такая конфигурация позволяет существенно снизить объемы междугороднего трафика ERP-системы, «замкнув» значительную его часть внутри локальных сетей. Для рассматриваемой модели предположим, что объем локального и междугороднего трафика ERP-системы примерно одинаков.
  • Локальная сеть в каждом из офисов находится на довольно высоком технологическом уровне, позволяющем развернуть ERP-систему, и не нуждается в коренной модернизации; в офисах уже организован выход в Internet по выделенной линии достаточной пропускной способности (не менее 2 Мбит/с). Таким образом, рассматриваются затраты на создание и эксплуатацию именно магистральной составляющей телекоммуникационной подсистемы.
  • Для расчетов используются усредненные тарифы на соответствующие услуги операторов магистральных сетей связи, которые имеют точки присутствия во всех перечисленных регионах, и позволяющие реализовать все упомянутые ниже варианты. Также берутся средние тарифы на Internet-трафик местных провайдеров.

Расчет совокупной стоимости владения (Total Cost of Ownership, TCO) магистральной составляющей телекоммуникационной подсистемы целесообразно провести на примере двух уже упомянутых вариантов создания такой подсистемы — выделенные каналы и сеть на базе IP-VPN MPLS. Также имеет смысл сравнить TCO такой сети со стоимостью использования общедоступной части Internet (рис. 3) — вариант, при котором магистральная составляющая вообще не создается, а пользователи ERP-системы работают через Web-интерфейс по выделенной линии.

Итак, наиболее дешевым вариантом оказался IP-VPN MPLS: при более подходящей для рассматриваемого случая функциональности этот вариант почти на 50% дешевле варианта с выделенными каналами.

Весьма примечательный, хотя и не очевидный факт — практически равная стоимость IP-VPN и кажущегося значительно менее дорогим варианта работы через Internet (без учета затрат на шифрование трафика, с шифрованием на 20% дороже). Все дело в ценообразовании: тарифы операторов на передачу трафика в сети IP-VPN практически соответствуют тарифам на Internet-доступ для корпоративных заказчиков. Более того, вариант работы через «публичный» Internet имеет весьма условную применимость для целей создания телекоммуникационной подсистемы ERP-проекта, поскольку он крайне уязвим для атак извне. Существенные риски связаны даже не с тем, что злоумышленники могут получить доступ к информации передоваемой по сети (этого легко избежать, применив «абсолютно непроницаемые», с точки зрения математики, решения), а с тем, что фактически отсутствует защита от атак, преследующих цель парализовать работу Internet-портов телекоммуникационной подсистемы. Такая атака может привести к тому, что работа территориально распределенной ERP-системы будет парализована на срок от нескольких минут до нескольких дней, и помешать этому ни один провайдер не сможет.

Необходимо отметить, что создавать территориально распределенную телекоммуникационную среду корпорации только для передачи трафика ERP-системы нецелесообразно. Более практично перевести на создаваемую сеть и все остальные виды трафика предприятия: обмен данными других приложений (например, документооборота или электронной почты), голосовой (телефонный) трафик, а в перспективе и трафик внутрикорпоративной системы видео?конференц-связи. Разумеется, стоимость создания и эксплуатации мультисервисной сети будет выше: вырастет стоимость создания узлов сети, появится необходимость расширения выделенных каналов как минимум до уровня Е1 (2 Мбит/с), в случае применения IP-VPN вырастет трафик в сети, и, соответственно, ежемесячные платежи. Однако эта «прибавка» в цене будет существенно ниже, чем суммарная стоимость эксплуатации отдельных систем — телефонной, сети передачи данных и проч.

Помимо абсолютных цифр большой интерес представляют и относительные показатели стоимости владения магистральной составляющей телекоммуникационной подсистемы ERP-проекта. Согласно данным проведенных независимыми аналитиками опросов вырисовывается следующая картина: экономически обоснованный размер затрат на развитие и эксплуатацию территориально-распределенной телекоммуникационной системы составляет в среднем 0,1-0,2% от оборота предприятия. Если учесть, что рассматриваемую в примере весьма крупную ERP-систему обычно внедряет предприятие с годовым оборотом не менее 100 млн. долл., то 0,1% от такого оборота как раз и составляет сумму примерно 100 тыс. долл. в год, которую предприятие может потратить на магистральную телекоммуникационную подсистему, не нарушая сложившиеся объемы и структуру своего ИТ-бюджета.

Организационные аспекты

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

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

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

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

Александр Герасимов — руководитель группы анализа рынка, компания «Борлас», A.Gerasimov@borlas.ru

Коротко о главном

  1. Затраты на создание и эксплуатацию территориально-распределенной телекоммуникационной подсистемы вполне «вписываются» в объемы и структуру ИТ-бюджета крупного предприятия.
  2. Задача по созданию телекоммуникационной подсистемы не должна находиться в отрыве от реализации ERP-проекта в целом. Целесообразно передать весь комплекс работ в рамках ERP-проекта (включая телекоммуникационную составляющую) в руки одного генерального подрядчика, если он возьмет ответственность за конечный результат.
  3. На основе телекоммуникационной подсистемы ERP целесообразно организовать единую мультисервисную сеть предприятия, обеспечивающую обмен данными, голосовую связь и трансляцию видео.
  4. Необходимо провести анализ возможных решений исходя из конкретных условий. Как правило, наиболее экономичным вариантом создания магистральной составляющей телекоммуникационной инфраструктуры территориально-распределенной ERP-системы в настоящее время является IP-VPN MPLS. Возможен и комбинированный вариант, когда отдельные узлы сети (в регионах, где невозможно предоставление IP-VPN MPLS) подключены по выделенным каналам. Для стационарных пользователей доступ к ERP-системе через Internet не дает заметной экономии. Для мобильных пользователей он вполне оправдан. В любом случае для доступа через Internet необходимо обеспечение информационной безопасности.