События

Нестандарт по стандарту

31 января 2014, 10:31
Тема «стандартов» и «нестандартов» в ИТ-системах и, в частности, в решениях, предлагаемых SAP, стала основным вопросом конференции «Стандарт SAP: мифы и реальность». На конференции обсуждали текущее состояние по использованию стандарта систем SAP в разрезе внутреннего и внешнего использования, а также поиск возможностей для расширения объема использования стандартной функциональности систем SAP. 
 
Основных вопросов у заказчиков к вендору можно выделить два. Первый – это отсутствие ряла очевидных отраслевых модулей, причем модули не попадают в стандарт и после того, как решение уже разработано на базе предприятия совместно с консультантами или разработчиками SAP. А второе, что отметили представители бизнеса: очень хотелось бы, чтобы процесс разработки и появления стандартов у вендора был прозрачным. Сейчас абсолютно невозможно предсказать, какой стандарт и когда будет реализован. Это очень сильно затрудняет планирование разработок у заказчика.
 
По словам Алексея Лекомцева (Башнефть), без доработок при внедрении решений обойтись не удастся никогда, и решения SAP – не исключение. Но нужно различать те доработки, которые вызваны индивидуальной особенностью деятельности предприятия или желанием «влиятельных пользователей системы» от доработок вынужденных, вызванных тем, что  вендор не учел общие принципы деятельности всех предприятий сектора или же не прописал что-то в явном виде в имеющихся стандартах. По мнению Лекомцева, именно в последних вариантах доработок вендор и может черпать идеи для разработки новых стандартов, повышая тем самым лояльность заказчиков и улучшая качество продукта.
 
Речь не идет о том, чтобы получить ИТ-систему, которая будет работать без доделок прямо из коробки. Но, по всей видимости, вендору стоит внимательнее относится к общим проблемам каждой отрасли, что позволит предлагать более кастомизированные решения.
 
Впрочем, как отмечает Сергей Дьяченко,  генеральный директор «Маркет-Визио», стандарты– это палка о двух концах. С одной стороны, чем больше в решении стандартов, тем проще кастомизация, но с другой, - чем выше уровень кастомизации, тем дороже решение.
 
Еще более странная – и весьма неудобная для заказчиков - ситуация возникает, когда партнерство заказчика и вендора (в данном случае - SAP) возникает как ко-инновация, как совместная работа над еще только возникающим продуктом. Начиная работать над технологией вместе, заказчик и вендор через некоторое время совершенно «расходятся»: первый продолжает работать над системой у себя, как правило, силами собственных разработчиков, а второй постепенно выпускает релизы, включающие все большее количество стандартных модулей.
 
Нестандарт по стандартуТакая ситуация возникла и в «Сургутнефтегаз», когда было принято о внедрении на предприятии решения SAP HANA. По словам Рината Гимранова, начальника управления ИТ компании «Сургутнефтегаз», внедрение этого решения на предприятии началось в 2010 году – тогда, когда в самой SAP еще даже не было названия для продукта и тем более не было никакого опыта внедрения решения. То есть в данном случае была в чистом виде ко-инновационная деятельность.
 
Как рассказал Александр Юношев, ведущий инженер-программист отдела инновационных продуктов управления ИТ компании «Сургутнефтегаз», в «Сургутнефтегазе» на настоящий момент  базе HANA работают 18 проектов (все находятся в опытной эксплуатации, во всех – реальные пользователи и реальные задачи), которые подразделяются на шесть групп. Это анализ материалов, логистический анализ, автотранспорт, сбыт нефтепродуктов, анализ кредитной задолженности и энергоэффективность котельных. У каждого из проектов есть своя особенность. Так, анализ материалов был самым первым «опытным» образцом; в случае модуля логистического анализа решался вопрос обработки архивных данных (за последние 2 года) наряду с данными актуальными; модель по работе автотранспорта интересен тем, что в нем обрабатываются данные из различных источников (не только данные, собираемые в базу SAP, но и данные из баз Oracle и MS SQL). Проект по сбыту нефтепродуктов требовал крайне сложной семантической структуры, анализ кредитной задолженности интересен тем, что в нем используется обработка метаданных, а в последнем проекте обрабатываются данные SCADA.
 
Таким образом, реализуя различные проекты в рамках платформы HANA, «Сургутнефтегаз» путем проб и ошибок в разрабатываемых приложениях смог решить ряд универсальных, по большому счету, задач, которые стоят если не перед всеми, то по крайней мере, перед большинством компаний нефтегазового сектора. То есть как минимум ряд этих модулей можно было бы включить в стандарты, входящие в модификации SAP HANA для компаний «нефтянки». Однако, до сих пор ни одно существенного «ко-инновационного» модуля в рамках стандарта не появилось. Это, если так можно назвать, отраслевое неудобство. Для самой же компании «Сургутнефтегаз» ситуация осложняется тем, что стандарты на базе совместных разработок, даже когда они появятся в HANA, уже не смогут быть установлены в «Сургутнефтегазе» без существенного отката назад, без потери времени, между тем как для бизнес-критичных приложений, несущих реальную нагрузку, это просто неприемлемо. Получается, что через некоторое время после старта у заказчика буквально не остается возможности получить стандарты по решению, которое разрабатывалось и им тоже.
 
По большому счету, проблемы начинаются тогда, когда разработанное и обкатанное решение должно бы перейти в категорию стандарта. Но стандарт появляется позже, инновации уходят вперед… Есть ли пути выхода из такой ситуации? По мнению Рината Гимранова, есть. В случае инновационной деятельности они заключаются в объединении двух этапов – ко-инноваций и внедрения, которые вендор и заказчик должны проводить полностью совместно. А это, в свою очередь, будет приводить к появлению стандарта на базе инфраструктуры заказчика.
 
Надо отметить, что никаких сомнений в правильности выбора HANA как технологии будущего для всей инфраструктуры «Сургутнефтегаза» у Рината Гимранова нет. Это решение, по его собственному выражению, он «выжидал», и совершенно уверен в правильности выбора. Цель, которая стояла при выборе платформы – в разы увеличить скорость вычислений – уже достигнута. Запросы, на обработку которых ранее в SAP ERP требовалось около трех часов, при поддержке SAP HANA выполняются менее чем за 16 секунд. При этом нагрузка на сервер SAP HANA весьма далека от предельной.  «Мы сейчас используем SAP HANA только на 2% от ее возможностей», - уверен Гимранов. А в будущем он надеется все базы данных, существующие в «Сургутнефтегазе», свести в одну in-memory базу, работающую на базе HANA. И, быть может, со временем это решение станет отраслевым стандартом.

Источник