Введение

Только ленивый не использует в качестве введения для своих аналитических, маркетинговых и Бог знает еще каких материалов изъезженный шаблон: «Мы живем в эпоху глобальных вызовов и беспрецедентного давления по всем фронтам, включая IT-инфраструктуру многих предприятий». Автор, не будучи ленивым, тоже вынужден упомянуть данный факт. Тем более что это святая правда. Но вернемся к цели данной статьи. Она весьма незамысловата и ставит перед собой задачу предложить читателю неформальный анализ ситуации, обрушившейся на бизнес. Не секрет, что перед бизнесом в полный рост встал вопрос о доступности IT-решений, на которые он полагался в течении многих лет и в развитие которых были инвестированы значительные ресурсы. Однако данная публикация не содержит исчерпывающего описания всех навалившихся проблем или попыток разобраться в вопросе «Кто виноват?». Цель данной статьи — поразмышлять, что можно сделать для минимизации возможных потерь и рисков и как обеспечить бесперебойную работу IT-инфраструктуры предприятия.

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

Почему именно ERP? Все достаточно прозаично:

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

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

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

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

• выявить критически важные компоненты инфраструктуры;.

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

Почему данные главные?

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

Итак, почему данные? Любая информационная система, каковой несомненно является и ERP, служит для получения информации. Можно манипулировать загадочными аббревиатурами, например BI, AI, ML и другими страшными словами, но под всем этим скрывается процесс добычи информации. А извлекается она из данных. Другими словами, мы можем получить информацию, только если:

• данные в наличии;

• данные отражают текущее положение дел;

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

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

Стартовая позиция

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

• SAP;

• Microsoft;

• Oracle.

Данное решение может быть:

• реализующим классическую клиент-серверную архитектуру (или по-модному On-Premise);

• облачным SaaS-решением (как правило, полученным в результате миграции с «устаревшей» платформы, упомянутой в предыдущем пункте).

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

1. Обеспечить сохранность и бесперебойный доступ к текущей конфигурации данных.

2. Обеспечить непрерывность текущего рабочего процесса.

3. Выбрать новую платформу для развертывания информационной инфраструктуры.

4. Организовать миграцию информационной экосистемы предприятия на выбранную платформу.

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

Обеспечение сохранности и бесперебойности доступа к текущей конфигурации данных

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

Жизнь предприятия усложняется в случае использования передовых облачных сервисов, особенно в случае развертывания инфраструктуры в так называемом Public Cloud — одного из глобальных провайдеров облачных услуг. Все не так драматично, когда критически важная инфраструктура ERP-системы развернута в Private или Hybrid Clouds на базе собственного дата-центра или в центре обработки данных одного из отечественных провайдеров (далее по тексту — ЦОД). Этот случай немногим отличается от описанного в предыдущем параграфе для On-Premise решений. Как минимум проблема сохранности данных решена.

Что касается случая Public Clouds, то остается открытым вопрос о применимости данного метода развертывания в корпоративном секторе. Скорее это касается предприятий меньшего масштаба. Однако используемый в этом случае подход как минимум должен быть упомянут. А набор необходимых в данной ситуации технических шагов выходит за рамки данной статьи. Такими шагами могут быть:

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

• развертывание новой инфраструктуры в дата-центре локального поставщика облачных решений (когда это технически возможно, например SAP S4/Hana допускает возможность развертывания на сторонних ресурсах IaaS).

Стратегия выбора новой платформы для миграции информационной инфраструктуры

Тенденции глобального рынка

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

• SAP S4/Hana Cloud;

• Microsoft Dynamics 365;

• Oracle Cloud ERP.

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

• облачное хранение данных как в базах данных сервисов, так и в хранилищах неструктурированных и частично структурированных данных;

• обеспечение доступа к внешним источникам данных;

• интеграцию данных всех указанных выше источников;

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

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

В качестве ярких примеров данного архитектурного элемента можно привести Common Data Service от Microsoft и Business Technology Platform от SAP.

Идеальная платформа для миграции

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

1. Получить надежную платформу для хранения и консолидации данных (в том числе и географически распределенных).

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

   1. приложений, реализующих полную функциональность отраслевого ERP-решения;

   2. доступных BI-платформ, позволяющих максимально расширить возможность получения сложной аналитики, в том числе с применением инструментов на базе ML и AI.

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

4. Обеспечить высокую доступность решения для различных классов пользователей. Конечный пользователь должен иметь возможность работать с ресурсами системы удаленно посредством веб-интерфейса и мобильных устройств.

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

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

Возможности реального мира

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

1. Развертывание гибридной инфраструктуры на базе текущего решения и облачных сервисов одного из отечественных поставщиков ЦОД (центр обработки данных).

2. Миграция на отечественную ERP-систему.

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

Развертывание гибридной инфраструктуры на базе текущего решения и облачных сервисов одного из отечественных поставщиков ЦОД

Основные идеи данного подхода:

1. Предприятие продолжает использовать текущее ERP-решение в полном объеме.

2. Выбор поставщика ЦОД-решений на основании соответствия предоставляемых сервисов требованиям, предъявляемым к новой инфраструктуре.

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

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

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

Данный подход имеет несомненные преимущества:

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

• решение является наиболее гибким и расширяемым;

• независимость развития и поддержки системы от конкретного интегратора;

• техническая сторона вопроса может быть отдана на аутсорс.

Недостатки:

• По сути речь идет о разработке индивидуального решения со всеми вытекающими накладными расходами.

• Высокая гибкость порождает дополнительную сложность в настройке и поддержке существующей архитектуры.

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

Миграция на отечественную ERP-систему

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

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

• из возможных альтернатив выбрать вариант, наиболее близко соответствующий критериям раздела «Идеальная платформа для миграции»;

• стартовать проект на миграцию платформы.

Здесь нет конкретных рекомендаций по выбору. Определенную аналитику вы можете найти в материалах доступных специализированных медиаресурсов, например CNews.

Преимущества данного подхода также лежат на поверхности. Следует выделить следующие:

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

• Большинство предоставляет отраслевые решения «из коробки».

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

Очевидно, данный подход тоже не лишен недостатков. Перечислим основные:

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

• Поставляемые решения не всегда являются «гибкими», обладая достаточными возможностями расширения функционала и интеграции с данными внешнего ПО.

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

Выводы 

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