ИТ-инфраструктура

Вычислительные мощности есть у всех дата-центров, и во всех в той или иной мере присутствует охлаждение. Конечно, доступные вычислительные мощности могут отличаться, но большинство ЦОД вполне способно удовлетворить потребности большей части клиентов. На недавней конференции Finance and Investment Forum, прошедшей в Лондоне, от клиентов и инвесторов исходил четкий посыл: «Нас не заботят ваши пустые заявления. Нам интересны лишь безопасность ЦОД и получаемый уровень обслуживания».

Между тем большинство владельцев ЦОД, похоже, больше беспокоит то, что они думают о себе сами. (Возможно, мы просто преувеличиваем степень их зрелости?) «Мой ЦОД отвечает стандарту Tier 3, а мой – Tier 3*, у моего показатель PUE, характеризующий эффективность энергопотребления, составляет 1,2, а у меня – 1,1» – слышим мы то и дело.

Но: a) на самом деле это не так; б) такие уровни по большей части недостижимы; в) практически всегда это не более чем похвальба; г) клиентов все это совершенно не интересует.

Клиенты справедливо ждут, что ЦОД будет находиться в состоянии постоянной готовности. Источник: Leonardo Rizzi — CC BY-SA 3.0

Громкие заявления довольно редко действительно имеют под собой основания. Да, клиентам важно, чтобы ЦОД был доступен тогда, когда им это понадобится. Возможно, клиентов интересует даже эффективность ЦОД, хотя для многих плата не зависит от величины PUE, поэтому и экономия проходит мимо них.

Клиенты справедливо ждут, что ЦОД будет находиться в состоянии постоянной готовности. Они рассчитывают также, что мощности его обладают достаточным уровнем резервирования, и, если один элемент выйдет из строя, его тут же заменит другой без какого-либо прерывания обслуживания. Клиенты надеются, что ЦОД работает максимально эффективно. В конце концов, на протяжении многих лет нам постоянно твердят об этом. Редко когда можно встретить владельца коммерческого ЦОД, который не упомянул бы о «Tier 3» (очень часто это является саморекламой) или не утверждал, что у него показатель PUE меньше, чем у кого бы то ни было (еще одно голословное заявление). А вот о чем многие предпочитают не упоминать, так это о безопасности и реальном качестве обслуживания,  ведь это отнюдь не является их сильной стороной.

Клиентов же безопасность и качество обслуживания интересуют в гораздо большей степени, нежели какие-то совершенно абстрактные для них Tier и PUE. На практике их совершенно не заботит, каким должен быть показатель PUE и почему. Клиенты хотят знать, будут ли их программы и данные в безопасности. И на какой уровень обслуживания они могут рассчитывать. И если среди ночи они позвонят в службу поддержки, потому что связь с их сервером, похоже, оборвалась, какой будет реакция. И каким приоритетом будут обладать их сервисы в случае аварии или сбоя в ЦОД.

Почти каждую неделю мы слышим очередную историю о брешах в системе ИТ-безопасности.

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

Встречаются ЦОД, проникать в которые можно часами, даже если вашего появления там ждут. Полчаса уйдет на то, чтобы пройти через входную дверь, если же вы хотите попасть внутрь, проще подойти сзади и воспользоваться грузовым дебаркадером. Здесь нет никого, и вы легко сможете пройти в любое место здания. Между тем все процессы должны быть надежны и эффективны с точки зрения защиты клиентских данных и оборудования, но просты и прозрачны в части получения авторизованного доступа. Большинство организаций превыше всего ценит безопасность своих данных, но многие ЦОД отделываются здесь лишь пустыми словами, предпочитая акцентировать внимание на том, какой у них Tier и насколько низким является показатель PUE: проверить это все равно невозможно и рассуждать об этом гораздо проще!

Позиция облачных провайдеров по вопросу надежности предоставляемых сервисов

Как показал опрос, проведенный в начале 2015 года Аналитической группой OSP Data, главным препятствием на пути использования облачных сервисов компании по-прежнему считают проблемы информационной безопасности. Опасения пользователей также вызывает надежность предлагаемых провайдерами сервисов. Между тем подавляющее большинство провайдеров предусматривают заключение соглашения SLA, чаще всего обязательное.

Источник: OSP Data, 2015

Качество же обслуживания по большей части оставляет желать лучшего. Во многих ЦОД полагают, что после подписания контракта клиент становится привязан к ним на долгие годы. И даже когда срок договора подойдет к концу, уйти в другое место окажется слишком сложно и дорого. Возможно, когда-то это было действительно так, но сегодня все изменилось. Многие провайдеры ЦОД поспешили запрыгнуть в «облачный» поезд, но лишь очень небольшая часть из них представляет себе, что на самом деле должно скрываться за «облачными сервисами». Они не понимают также, что пока необходимость предоставления хорошего сервиса не станет им очевидна, облако будет оставаться для них проклятием.

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

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

Оптимальный вариант размещения ИТ-систем

На VI форуме «МИР ЦОД – 2015» аналитическая группа OSP Data провела блицопрос относительно оптимального варианта размещения ИТ-систем.

Традиционно большинство заказчиков в России предпочитают размещать ИТ-системы в собственных ЦОД. Немало специалистов высказалось в пользу гибридного варианта. Другие исследования OSP Data также показывают стремительный рост популярности этого варианта.

Источник: OSP Data, 2015

 

В федеральной сети автосервисов «Белый сервис» инициатором полного вывода инфраструктуры в облака стало руководство компании, оно отстояло проект, несмотря на серьезное сопротивление ИТ-специалистов.

Перенос решений на платформе «1С» в облако был начат в 2009 году. Тогда в рамках проекта стояла задача по одновременному использованию информационной базы многочисленными розничными подразделениями, которые открывались по всей стране. В рамках этой задачи надо было быстро подключать и отключать пользователей, предоставлять им тестовый доступ. А потому и обратили внимание на облачные технологии. Впоследствии на принятие решения повлияло и то, что бизнес, начатый в рамках группы «Рольф», был выделен в отдельную компанию. Стало понятно, что собственную инфраструктуру развивать бессмысленно, лучше ее развертывать сразу в облаке, чтобы, имея прозрачные расходы, видеть показатели компании.

В экономию поверили не сразу

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

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

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

«Мало кто верил, что облачная инфраструктура реально поможет сэкономить. В итоге, если говорить не только про оборудование, но и о людях, необходимых для его поддержки, мы сэкономили, причем значительно — затраты сократились на 15–17%», — отмечает Никишин. Тем не менее главным эффектом следует считать быстрое подключение и скорость запуска новых сервисов для партнеров. Это стало ключевым преимуществом перед конкурентами.

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

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

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

Разумеется, перевести бизнес-потребности в характеристики приобретаемой инфраструктуры далеко не просто, как и наоборот — перевести технические термины в язык, понятный «простым смертным».

«Специалисты “Первого БИТа” сумели сделать сложное простым для нас. Опыт внедрения “1С” у них уже тогда был большой, и команде специалистов удалось с максимальной точностью определить технические требования к инфраструктуре», — говорит Никишин. На этапе разработки системы начинали с минимального объема виртуальной среды, необходимого для разработчиков. По мере необходимости расширяли его в соответствии с растущими задачами.

«Сейчас мы точно можем сказать, что услуги, которыми мы пользуемся, весьма надежны. И надежность — это ключевой параметр, который следует рассматривать при переходе в облако», Олег Никишин, коммерческий директор компании «Белый сервис»

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

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

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

Гибкость как преимущество

«Белый сервис» предоставляет единые услуги для всей сети партнеров, поэтому так важны надежность и стабильность.

«Когда кто-то из партнеров говорит, что у них не запускаются какие-то службы и из-за этого они не могут обслужить клиентов, для нас это губительно. Партнер, само собой, долго терпеть не будет и спустя какое-то время начнет “смотреть на сторону”. Именно поэтому важна непрерывность ИТ-услуг, и в нашем случае облако реально помогло», — говорит Никишин.

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

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

Быстрота и гибкость компании — критически важные качества на нынешнем рынке.

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

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

Надежность с минимальными затратами

Типичным примером осторожной облачной стратегии является перенос в облако отдельных частей ИТ-инфраструктуры. В банке «ДельтаКредит» задумались об этом лишь недавно. Первой из перенесенных систем стала инфраструктура сайта, достаточно критичная к стабильности работы.

«Оборудование, поддерживающее работу корпоративного сайта, было довольно старым, для его обновления требовались значительные ресурсы. До сих пор мы не использовали виртуализацию систем и взвешивали, как поступить — приобрести новые серверы или перевести сайт в облако», — рассказывает Андрей Столяров, руководитель группы системного администрирования банка «ДельтаКредит».

«Помимо значительного увеличения надежности, других бизнес-требований как таковых не было. В результате было принято решение в пользу более современной облачной технологии», Андрей Столяров, руководитель группы системного администрирования банка «ДельтаКредит»

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

«Мы проанализировали предложения облачных провайдеров и сравнили их со стоимостью услуг размещения собственных серверов в коммерческих ЦОД. В результате было принято решение в пользу более современной облачной технологии», — говорит Столяров. Вычислительные мощности были развернуты в облаке Softline. А поскольку стоимость облачных решений в России стала почти приемлемой, проект окупился довольно быстро — за полгода.

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

Как и во многих финансовых организациях, одна из основных проблем работы в облаках — обработка и передача персональных данных клиентов. Однако на сайте банка «ДельтаКредит» подобная информация не хранится.

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

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

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

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

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

Таким образом, вполне логично пойти дальше — подключить к аналитической системе внешние данные. Их сейчас очень много, и главными являются социальные сети. Что, если добавить в число источников неструктурированные данные, существующие внутри банка, — например, поведение клиента на сайте или логи приложений? Дав возможность анализировать все это, компания приходит к концепции «озера данных».

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

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

Стоимость имеет значение

Что такое «озеро данных» и почему оно позволяет решить поставленные аналитические задачи?

«Идея очень простая: мы все данные грузим в кластер на платформе Hadoop, и все приложения используют эти данные, — объясняет Сотниченко. — Можно использовать и другие платформы, но Hadoop, на наш взгляд, имеет много плюсов, в том числе экономических».

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

Что еще немаловажно, Hadoop реально, а не на словах поддерживается сообществом разработчиков — любую возникшую проблему можно довольно оперативно решить.

«Как ни странно, в проприетарных системах это может стать непростой задачей — у нас есть опыт, когда бизнес-критичная проблема в коммерческом аналитическом решении “живет” уже три года, и мы ничего не можем с ней сделать, несмотря на обращение к руководству вендора. Надеемся, что open source позволит избежать таких ситуаций», — говорит Сотниченко.

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

Не превратить озеро в болото

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

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

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

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

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

Хранилища еще пригодятся

Естественным становится вопрос о том, каково место в построенной архитектуре реализованных ранее традиционных хранилищ, базирующихся на дорогостоящих высокопроизводительных системах. «Надо ли выбросить Greenplum и оставить Hadoop? Нет, так делать не стоит. Каким бы хорошим ни был Hadoop, он имеет преимущество лишь при работе с неструктурированными данными. Классические задачи аналитики — например, построение отчетности — эффективнее решаются на четкой реляционной модели», — уверен Сотниченко. Так что поставщики хранилищ данных могут не беспокоиться — их продукты еще долго останутся востребованными.

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

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

Потоки данных внутри Hadoop напоминают потоки в классическом хранилище. Вопрос их реализации является одним из ключевых. Изначально в ТКС эту задачу пытались решать на платформе Java, однако попытки были не очень удачными — получился хаос. «Наводить порядок» пришлось с помощью решений Informatica — вся обработка и трансформация данных внутри Hadoop теперь доверены им.

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

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

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

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

Качество имеет значение

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

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

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

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

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

Ломка стереотипов

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

«Эффективность инфраструктурных проектов всегда трудно оценить точно, но то, что качество услуг влияет на лояльность абонентов и привлекает к нам новых, — бесспорно», Раиль Фатхуллин, директор по информатизации и новым технологиям «Таттелекома»

«Несмотря на стремительное развитие технологий, мы не сторонники революций. Все решения, которые планируются к эксплуатации, проходят тщательное тестирование», — подчеркивает Фатхуллин. Среди множества продуктов по контролю качества услуг (а их действительно множество) решение HP было расценено как наиболее комплексное, способное охватить все звенья технологической цепочки, в том числе и процессы, не относящиеся напрямую к ИТ. Еще одно важное достоинство предложенного решения — это возможность охвата оборудования любого производителя. Кроме того, именно специалисты HP показали, как можно контролировать не только оборудование, но и услугу в целом.

«Предложенные подходы зачастую ломали все сложившиеся стереотипы, привычки, отработанные регламенты», — признает Фатхуллин.

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

Работы были поделены на два больших этапа: мониторинг оборудования и управление технологическими процессами. Последовательность объясняется просто. Мониторинг — это то, что в компании всегда умели делать. Управление же технологическими процессами, анализ KPI, применение рекомендаций ITIL — все это требует уже работающей инфраструктуры. Поэтому этапы осуществлялись именно последовательно.

Проект стартовал с развертывания HP Network Node Manager Advanced для мониторинга магистральных республиканских MPLS-сетей и HP Operations Manager для мониторинга критичных серверов. Оценив функциональность продуктов, компания приняла решение расширить покрытие системой мониторинга всего активного сетевого оборудования крупнейшего из своих филиалов. Также в систему мониторинга было включено серверное оборудование, задействованное в сопровождении телекоммуникационных услуг.

Однако главной задачей был качественный скачок от мониторинга оборудования к мониторингу услуг в целом. Для этого в проект были введены система корреляции событий, универсальная база данных управления конфигурациями, а также флагманский продукт HP — Service Manager.

Быстро поднятое упавшим не считается

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

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

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

«При обрыве нашего кабеля или отказе оборудования мы сразу можем определить, какие абоненты пострадали и какие у них сервисы не работают, — объясняет Фатхуллин. — И можем сообщить абонентам, когда все будет восстановлено, поскольку на все аварийные случаи имеется регламентное время восстановления».

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

«Наверняка Татарстан и в будущем будет принимать крупные соревнования. Если вновь придется строить систему контроля качества инфраструктуры, мы знаем, как и из чего ее собрать», — говорит Фатхуллин.

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

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

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

Главное — заинтересовать

«Самое сложное в реализации подобных проектов — заинтересовать собственных специалистов. Да, интегратор может все настроить, но он никогда не сможет сделать систему работоспособной, пока не включится инженерный состав», — говорит Фатхуллин. Именно поэтому значительное продвижение проекта началось лишь тогда, когда были инсталлированы и интегрированы все элементы. После этого специалисты смогли оценить реальные возможности, которые несет система.

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

Следующим серьезным этапом в рамках развития проекта должно стать подключение к системе управления качеством новой дочерней сотовой компании. Это весьма трудоемкая задача.

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

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

Новое поколение струдников предъявляет иные требования к технологиям, отмечает Шелдон Смит, директор SaskPower по техническим инновациям. Молодым, тем, кто рассчитывает получить на новом месте iPad с зарядником, чтобы сразу приступить к работе, не нравится проходить двухнедельный курс обучения работе с системой. «Поэтому мы поняли, что пора меняться», — добавляет он.

Рассчитывая обеспечить единство внешнего вида приложений SAP на различных устройствах, в SaskPower обратились к SAP Fiori, инструментарию построения мобильных интерфейсов для SAP HANA и Business Suite. По словам Смита, важная особенность Fiori — соответствие концепции адаптивного дизайна: приложения распознают тип устройства и автоматически меняют внешний вид. Так, некоторые поля, отображаемые на ПК, на мобильных устройствах не видны, поскольку их экраны слишком маленькие.

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

К примеру, руководство SaskPower жаловалось на трудности использования SAP при выполнении простой задачи — просмотра количества доступных дней отпуска. В ИТ-отделе с помощью Fiori создали приложение My Quotas, и теперь с мобильных устройств можно легко обратиться к кадровой системе, чтобы просмотреть имеющиеся дни отгулов и отпусков.

«Это очень простое приложение, которое уже “знает” вас и показывает самую свежую информацию о ваших отпусках, — объясняет Смит. — My Quotas, наверное, самое популярное из наших приложений».

В эпоху, когда официальная политика BYOD становится для предприятий скорее правилом, чем исключением, служащие стали рассчитывать на возможность работать с помощью мобильных устройств. Поэтому все больше компаний становятся «мобильноцентричными», предоставляя доступ к корпоративным приложениям на мобильных устройствах, отмечает Билл Ром, управляющий партнер консалтинговой компании 151 Advisors: «По мере появления у служащих потребности в доступе к разным типам данных, в компаниях создают мобильные расширения имеющихся приложений или их групп». Специалисты отмечают, что мобильные приложения нередко повышают продуктивность работы сотрудников.

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

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

Проблема размера экрана

Но инструменты вроде Fiori, Oracle JD Edwards EnterpriseOne Mobile Framework и другие нередко генерируют интерфейсы, непохожие на те, что отображаются на настольном компьютере, поскольку оригинальные версии систем были рассчитаны на экраны большей площади, чем у планшетов и смартфонов. Тем не менее, после соответствующих изменений, приложения отображаются на мобильном устройстве в удобочитаемом виде, предоставляя доступ к нужным функциям, отмечает Ром.

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

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

Бейкер общался с сотрудниками многих корпоративных отделов разработки, которые получали задание перенести на смартфоны имеющиеся приложения — например, системы управления расходами. Мобильные версии подобных инструментов могут быть удобными, но, как считает аналитик, перенос приложения сам по себе не сделает работника более продуктивным: «Доступ к системе становится более удобным или простым, но других преимуществ не ждите. Продуктивность повысится, если грамотно спроектировать мобильное приложение с нуля».

Сейчас, по оценкам Gartner, лишь менее четверти предприятий самостоятельно разрабатывают мобильные приложения, 17–18% решают эту задачу путем аутсорсинга, а остальные пользуются обоими способами.

С нуля создается мало мобильных приложений, да и вообще волна их разработки только начинается, считает Бейкер. Подавляющее большинство предприятий разрабатывают до десяти приложений, а 25–35% еще не создали ни одного. «Думаю, в этом году дело пойдет активнее, — отмечает аналитик. — На предприятиях очень настойчиво требуют мобильных приложений — отделы ИТ перегружены запросами и не успевают реагировать. В результате бизнес-подразделения идут в обход своих ИТ-служб, обращаясь к третьим сторонам».

Расширение систем ERP

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

Компания Allied Specialty Vehicles производит пожарные машины, школьные автобусы, жилые автофургоны и другие транспортные средства специального назначения. Когда в ней решили предоставить складским рабочим возможность получать оперативные данные о запасах, в ИТ-отделе остановили выбор на платформе разработки мобильных приложений Catavolt.

Когда рабочие набирают запчасти по списку необходимых для транспортного средства, они сканируют штрихкоды, сгенерированные ERP-системой Mapics. Теперь сканер связывается по Bluetooth с iPad и складская транзакция происходит мгновенно, благодаря чему запасы всегда пополняются вовремя, отмечает Джошуа Брэдбери, директор по ИТ-проектам и сисадмин компании Allied Specialty Vehicles. При любом обращении к системе рабочие также сразу видят текущий уровень запасов.

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

По его словам, создавать мобильные приложения с ее помощью несложно и длительное тестирование им не требуется. При создании нового объекта данных в Catavolt отображается список объектов из Mapics, после чего надо выбрать нужный — к примеру, заказ товара; затем задается способ его отображения на мобильном устройстве. «На внедрение очередного приложения уходит один-два дня, — отмечает Брэдбери. — После соединения с Mapics приходится еще немного повозиться с кодом XML».

Сотрудникам ASV приложения понравились, продолжает он: «Пользователи говорят, что теперь работать стало быстрее и удобнее. Когда им нужна информация, не приходится идти через весь склад к компьютеру». Приложение также позволяет запрашивать сведения по номеру детали: система сразу показывает, есть ли таковая на складе и где именно, а кроме того, отображает заказы на покупку и производство. На ПК, чтобы получить ту же информацию, приходилось открывать четыре окна.

В Catavolt также были разработаны приложения, позволяющие запрашивать со смартфонов и планшетов разрешение на отгул.

Мобильные инструменты оказались весьма полезными, так как они экономят время. За 2014 год только с одного завода были отправлены запросы на 317 тыс. деталей со склада. Регистрация одной детали в системе обычным способом занимает 20 секунд, а в приложении Catavolt — всего две. Благодаря этому, как отмечают в ASV, общая экономия времени на вводе данных составила около 73 суток, или 176 десятичасовых рабочих дней.

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

Тестирование

Видя общий рост популярности мобильных приложений, в компании Stewart & Stevenson решили обеспечить мобильный доступ к корпоративной ERP-системе Oracle JD Edwards. В Stewart & Stevenson занимаются проектированием, производством и продажей специализированного оборудования для нефтегазовой и других отраслей.

Сейчас бизнес-аналитики, менеджеры и пользователи других специальностей тестируют мобильные приложения для работы с 23 модулями JD Edwards, отвечающими за продажи, цепочку поставок, обслуживание и кредитование, сообщил Пол Крюгер, ИТ-директор компании. Приложения разработали с помощью платформы EnterpriseOne Mobile Framework, позволяющей создавать адаптивные мобильные интерфейсы для инструментов JD Edwards.

«Постоянно менять масштаб изображения на экране движениями пальцев было бы очень неудобно», — отмечает Крюгер. У JD Edwards есть больше 70 готовых мобильных приложений, доступных в App Store, которые позволяют перенести функциональность существующей ERP-системы на мобильные устройства.

После завершения тестирования в Stewart & Stevenson собираются заняться разработкой мобильных версий имеющихся приложений для техников сервисной службы. По словам Крюгера, для этого планируют воспользоваться EnterpriseOne или другим инструментарием, не от Oracle, в зависимости от того, что позволит быстрее провести разработку.

Создать мобильные расширения имеющихся приложений было решено после оценки потенциальных денежных и временных затрат. «Разработка и сопровождение пользовательских интерфейсов, а также обеспечение интероперабельности всегда сопряжены с издержками, — поясняет Крюгер. — Для мобильных приложений мы предпочли бы воспользоваться средствами поставщика нашего ПО, чтобы при модернизации системы ERP без особых усилий обновлялись и мобильные приложения. Всегда, когда есть возможность задействовать ресурсы, предлагаемые нашими стратегическими партнерами, мы используем ERP».

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

По оценкам Крюгера, новое приложение для сервисного обслуживания на местах позволит на 25–30% сократить время, проходящее с момента получения вызова от клиента до выставления счета за проделанные работы. С помощью мобильного приложения техники смогут передавать сведения, еще находясь у клиента, а не только по возвращении в офис.

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

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

- Esther Shein. Modernizing enterprise apps for the mobile world. Computerworld. Mar 30, 2015

Интернет-компании, онлайн-ретейлеры и мобильные операторы уже давно строят на Больших Данных свой бизнес. Банки же в силу традиционной консервативности входят в «клуб Больших Данных» относительно поздно — только сейчас. Сбербанк, имея больше по сравнению с другими возможностей, ступил на эту стезю раньше многих: подразделение, занимающееся внедрением инновационных решений, у него появилось еще в 2011 году. По проработанности подхода его можно отнести к лидерам, а накопленный опыт позволяет избегать многих ловушек, принимая взвешенные решения в области развития используемых платформ.

Аналитики Gartner относят зрелость технологий Больших Данных к этапу скатывания по «желобу разочарований», когда несоответствие между ожиданиями от технологий и их возможностями порождает заметный скепсис. Когда же встретятся ожидания и возможности Больших Данных?

«Аналитики оценивают эти показатели в комплексе, с точки зрения всех секторов экономики. Однако в некоторых из них Большие Данные не только достигли ожиданий, но и превысили их», — полагает Анджей Аршавский, директор центра компетенции супермассивов данных «Сбертеха». Эти технологии появились в поисковых системах, когда Google и Yahoo, будучи еще стартапами, пытались «перемолоть» Интернет. Для них задача стояла достаточно просто: на дешевых серверах было необходимо обрабатывать гигантские массивы данных, и эта задача была решена. Затем технологии Big Data перешли в сегмент интернет-торговли, где тоже прекрасно себя зарекомендовали — например, магазины-гиганты стали использовать их в рекомендательных системах. Во многом именно Большие Данные позволили этому бизнесу процветать. Не так давно мы стали наблюдать проникновение Больших Данных и в деятельность мобильных операторов.

Банки входят в «клуб Больших Данных» только сейчас, относительно поздно. Это происходит не потому, что Большие Данные до сих пор им не были нужны, а в силу традиционной консервативности. Тем не менее такой процесс неизбежен.

Инновации — разрушающие и созидающие

Бретт Кинг, автор книги «Банк 3.0», привел последовательность инноваций, вызывающих разрушение традиционной банковской системы. Оно началось с приходом Интернета и социальных сетей, давших возможность выбирать банк не по месту жительства, а более осознанно. Приход смартфонов позволил взаимодействовать с банком из любого места; попутно возникли мобильные кошельки, дав возможность обходиться без карточек и наличных. Сейчас уже ставится под вопрос необходимость наличия банковского счета: например, Facebook анонсировал возможность переводов денежных средств между участниками сети.

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

«Таким образом, от использования Больших Данных напрямую зависит прибыль банка. Поэтому вопрос необходимости их использования уже не стоит», — констатирует Аршавский.

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

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

Последние три стадии относятся к категории Больших Данных.

BI и Big Data — в чем разница?

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

Во-первых, системы класса Big Data изначально ориентированы на работу с разнородными данными. Во-вторых, они закрывают потребность компании во внешних источниках данных, в то время как бизнес-аналитика базируется на существующих в компании внутренних источниках. Кроме того, систему Больших Данных можно построить на стандартном оборудовании, тогда как BI-системы требуют гораздо более дорогих аппаратных решений.

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

Анджей Аршавский, директор центра компетенции супермассивов данных «Сбертеха»

Мощь данных недооценивается

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

Известна оценка Gartner, согласно которой 70% усилий в работе с данными приходится на их первоначальную обработку, очистку, загрузку и подготовку. Чтобы стать пригодными для эффективного анализа, данные нуждаются в реинжиниринге и переформатировании. Только 30% относится непосредственно к анализу и построению моделей. Это становится большой проблемой, частично порождающей разочарование в технологиях Больших Данных.

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

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

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

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

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

Big Data: как важно быть наглядным

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

В условиях, когда отношение к Большим Данным, по мнению аналитиков, сменилось с восторженного на настороженное, «пробивать» соответствующие проекты стало более затруднительно. Как полагает Андрей Скворцов, директор группы компаний «Меркатор», специализирующейся в области инфографики, помочь в этом может наглядная визуализация данных. На форуме Big Data 2015, организованном издательством «Открытые системы», он предложил три простых правила представления данных в наглядном виде. Визуализированные данные должны вызывать удивление, показывать контрасты; кроме того, необходимо представлять все данные — иначе они будут не столь убедительны.

Первым «визуализатором» стал французский математик и астроном Урбен Леверье, наиболее известный своим открытием Нептуна «на кончике пера». После того как шторм в ноябре 1854 года изрядно потрепал англо-французский флот под Севастополем, французский император Наполеон III обратился к ученому с вопросом относительно предсказуемости такого рода явлений. Леверье изучил и изобразил траекторию урагана, попутно предложив основать сеть метеорологических станций для заблаговременного отслеживания природных катаклизмов. Император, удивленный невиданными доселе картинками движения атмосферных фронтов, дал добро.

Качественная иллюстрация лучше тысячи слов расскажет о том, в каких странах энергетики «ставят» на ветер и воду, а в каких — на уголь и мирный атом Источник: «Меркатор»

С этих карт Леверье, считает Скворцов, и началась визуализация данных. Она позволяет сделать данные более наглядными — например, отобразить ход застройки центра Москвы по годам, представить транзакции Сбербанка в реальном времени или показать, в каких странах Европы предпочитают маленькие ветровые электростанции, в каких — большие атомные и тепловые. А порой она дает возможность вскрыть некоторые прчинно-следственные связи, особенно при работе с малоформализуемой информацией. Так, графически ото­бразив взаимоотношения в коллективе, можно найти в нем отчетливые группы друзей. Или понять, как в реальности повлиял на динамику продаж приход нового руководителя.

Самый поучительный пример формально касался степени совпадения динамики бюджета США с прогнозами относительно этой динамики. Прогнозы, как отметил Скворцов, были двух типов: «Все хорошо» и «Сейчас не очень, но скоро все будет хорошо». Реальность несколько отличалась, и, по словам директора «Меркатора», такая ситуация характерна для госучреждений отнюдь не только нашего заокеанского партнера.

- Дмитрий Гапотченко, заместитель главного редактора Computerworld

 

Для экспертов, и не только

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

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

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

Таким образом, в результате планируется создать две зоны работы с платформой Больших Данных: зону анализа ad hoc (лат. Ad hoc — «по месту») для прямой работы исследователей с данными и зону приложений, которые будут интегрироваться в бизнес-системы. В результате платформой смогут пользоваться не только аналитики, но и маркетологи, служба безопасности, специалисты продаж.

Много компаний в предыдущие годы вложили значительные средства в создание мощной ИТ-инфраструктуры. Реализация проектов Больших Данных — возможность наконец заставить ее отрабатывать инвестиции.

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

«Бизнес-аналитики в нашей компании работают с Большими Данными с 2005 года, задолго до того как получил распространение термин Big Data», — подчеркивает Виктор Булгаков, руководитель департамента управленческой информации «ВымпелКома». По его словам, большинство потоков данных больше 100 Гбайт в день можно относить к категории Больших Данных: они требуют определенной культуры работы, специфических процессов. Компании удалось создать эту культуру. Свидетельство тому — постоянный рост числа пользователей средств бизнес-аналитики, увеличение объема хранимых и обрабатываемых данных. В условиях повышения требований к качеству и оперативности информации это становится особенно востребовано бизнесом. Технологии ориентированы на повышение уровня клиентского сервиса, а также улучшение качества корпоративного управления.

«Бесцельно собирать все данные подряд — это путь в никуда. Данные без экспертов — балласт, тормозящий развитие бизнеса», Виктор Булгаков, руководитель департамента управленческой информации компании «ВымпелКом»

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

«У нас действительно много данных — больше, чем у нефтяников, а в части информации о конкретном абоненте они даже шире, чем у Google. Поисковики “знают” все, с чем пришел к нему пользователь, а мы знаем, куда он ходил, кроме Google» — констатирует Алексей Мартынов, директор департамента развития и сопровождения ИТ-систем ОАО «МГТС». Кроме того, люди все чаще выходят в Интернет с мобильных устройств, что дает массу дополнительных знаний. Известно, где человек находится в данный момент, что смотрит, какую рекламу ему показывают, определен его круг общения. Способов организовать взаимодействие с человеком также гораздо больше: мобильный телефон у многих никогда не выключается.

«Появление технологий Больших Данных никак не сказалось на количестве новых продуктов, их качестве, скорости их вывода на рынок. Скорее, оно отразилось на понимании того, кому и какие услуги следует продавать — на таргетировании наших предложений», — считает Мартынов. Для любого телеком-оператора важно четко понимать, кому и какой продукт можно продать и с какой вероятностью предложение будет принято.

Объять ли необъятное?

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

«При определении потенциальной ценности данных следует действовать через исследовательские проекты», — рекомендует Мартынов.

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

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

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

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

«Выделенные люди, освобожденные от рутины, могут быть более эффективны в творческих задачах», — согласен Булгаков. Однако оторванность от практических задач сужает круг возможностей, и здесь нужен разумный баланс креативности и технологий.

Инструмент не для всех

«Часто поставщики ИТ-решений, говоря о Больших Данных, подразумевают некий бренд, который хорошо продается. В бизнес-среде такая технология воспринимается как элитная», — констатирует Булгаков. Но, несмотря на новые особенности обработки данных, ее суть осталось прежней. При этом в компаниях однозначно вырос уровень аналитической культуры. Многие перешли от Excel к работе с профессиональными статистическими пакетами, курс обучения работе с которыми занимает считанные дни.

Как полагает Булгаков, освоение технологий Больших Данных можно ускорить, эта технология — буквально шаговой доступности. Конечно, мечта стать за несколько дней полноценным исследователем данных (data scientist) слишком оптимистична, но такая мечта необходима.

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

В 2013 году «ВымпелКом» удивил ИТ-сообщество оригинальным стартом проекта Big Data. При нулевых начальных инвестициях за несколько недель удалось силами энтузиастов создать из подручных рабочих станций кластер Hadoop. Это позволило проверить несколько идей и выйти к бизнесу с новыми инициативами.

«Только что получивший автомобильные права человек на болиде “Формулы-1” уедет не дальше первого поворота», — иронизирует Мартынов. Он уверен, что Большие Данные — действительно не для всех: без выстраивания в компании «традиционной» системы бизнес-аналитики обойтись нельзя.

«Я выделяю три уровня аналитики: отчетность, data discovery и Большие Данные», — говорит Мартынов. Отчетность построить проще всего, ее задача — отвечать на вопрос, как разделяются покупатели, скажем, синих машин по возрасту, полу, доходам. Следующий уровень — аналитика, отвечающая на более абстрактные вопросы, например: что общего между покупателями синих машин и чем они отличаются от покупателей красных машин? Таким образом изучаются склонности клиентов. Третий уровень — Большие Данные, когда на базе огромного массива разнородных данных о покупателях компания пытается найти совершенно неочевидные взаимосвязи между покупкой синей машины и склонностью к потреблению Интернета.

«Не пройдя первые два этапа, невозможно применять на практике результаты, получаемые на третьем», — уверен Мартынов.

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

Как уверен Мартынов, технологии Больших Данных, подобно инструментам data discovery (исследования данных), будут становиться все более простыми, ориентированными на конечного пользователя. Если раньше инструменты анализа даже относительно небольшого объема данных были инструментом ИТ-специалистов и требовали серьезных вычислительных мощностей, то несколько лет назад технологии исследования данных в десятки терабайт уже стали доступны бизнес-пользователям без специализированного образования.

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

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

Потенциал данных

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

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

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

Основные проблемы Больших Данных Источник: Accenture, 2014

Валюта впечатлений

«Не следует давать клиентам скидки, бонусы и подарки. Наша задача — платить за лояльность валютой впечатлений, и именно тут аналитика Больших Данных должна сказать свое веское слово», — уверен Максим Мозговой, директор по CRM «Промсвязьбанка».

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

Почему важно использовать все доступные данные о поведении клиента для предсказания его действий? Чем больше данных компания накопит, тем с большей точностью может быть предсказана вероятность снижения лояльности или приобретения того или иного продукта. Алгоритмы Больших Данных и машинного обучения позволяют с высокой степенью точности предсказывать тот или иной вариант развития событий. Однако все технологии упираются в бизнес-инициативы — идеи, которые должны быть подтверждены реальными изменениями в бизнесе. Сейчас большая проблема не в том, чтобы внедрить какую-либо систему, а в том, чтобы понять, какую ценность она будет приносить бизнесу.

«Что скажет владелец, если со склада вдруг исчезнет 10% товаров? Вероятно, такое событие стало бы поводом как минимум для служебного расследования. А что происходит, когда мы теряем 10% клиентов? Ничего, компания продолжает работать», — удивляется Мозговой. Это говорит о том, что бизнес не понимает ценности клиентов. Компания уподобляется дырявому ведру — наполняется новыми продажами, но и заметно теряет. И никто не знает, насколько ведро дыряво.

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

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

Большие Данные уйдут в облака

Более половины крупных предприятий планируют использовать публичные облака для работы с Большими Данными.

Не секрет, что многие ИТ-менеджеры крупных компаний не слишком доверяют публичным облакам: они не уверены в их надежности и безопасности. Однако это мнение может измениться — по крайней мере, в отношении обработки Больших Данных.

Исследование, проведенное Gigaom Research, обнаружило, что 53% крупных компаний либо уже используют возможности облаков для аналитики Больших Данных, либо планируют делать это. Лишь 13% заявили, что для решения аналитических задач будут использовать исключительно собственные ЦОД.

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

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

Использование облачных технологий для работы с Большими Данными Источник: Gigaom Research, 2015

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

Можно привести простой пример того, как учет одного фактора позволяет коренным образом изменить взгляд на эффективность маркетинговых кампаний. Рассмотрим стандартную ситуацию: у компании есть база с данными 1 млн клиентов, и маркетинговая кампания в виде «ковровой бомбардировки» генерирует 1% отклика — при этом получается 10 тыс. откликов. Допустим, каждый отклик генерирует 125 руб. увеличения ценности клиента. Получаем общий эффект 1,25 млн руб. Обычно маркетологи на этом останавливаются и считают свою задачу выполненной. Но на самом деле это не так: клиенты, не ответившие из-за нерелевантного предложения, снижают вероятность отклика при последующих обращениях. Если вероятность отклика снижается хотя бы на 0,5%, организация в результате небрежно проведенной кампании теряет гораздо больше, чем получает: ценность клиентской базы разрушается быстрее, чем создается.

«Задайте себе вопрос: как быстро вы разрушаете ценность своей клиентской базы? Скорее всего, на такой вопрос никто ответить не сможет», — уверен Мозговой. В компании отсутствует не просто понимание ситуации, но и сама бизнес-функция. Это дает право ИТ-специалистам, осознавшим положение дел, выйти с предложением о ее создании.

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

Непростые времена вполне могут стать катализатором для развития инфраструктурных проектов, считает Эллиот Гойхман, директор ИТ-департамента МДМ Банка. За последние несколько лет в банке был реализован целый ряд проектов по модернизации ИТ-инфраструктуры, в ходе которых кардинальному обновлению подверглись ее ключевые элементы — серверы и системы хранения данных, обслуживающие критически важные для бизнеса аспекты. Гойхман уверен, что проекты модернизации не должны возникать на пустом месте — у бизнеса появляются потребности, и нередко для их удовлетворения приходится «подтягивать» имеющуюся инфраструктуру. В любом случае бизнес должен быть союзником в проведении модернизации — это необходимое условие успеха инфраструктурных проектов.

Стоит ли начинать крупные инфраструктурные проекты в сложных экономических условиях?

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

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

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

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

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

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

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

Должны ли при этом топ-менеджеры понимать сильные и слабые стороны корпоративных систем своих организаций?

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

Бизнес-руководство редко инициирует проекты в области ИТ-инфраструктуры. В каких случаях это происходит?

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

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

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

Еще один распространенный фактор — экономическая эффективность. Если лицензирование программного обеспечения напрямую зависит от количества процессорных ядер (подобные схемы можно встретить, например, у СУБД Oracle и Microsoft SQL Server), то переход на оборудование с более производительными ядрами позволит сэкономить на лицензиях. В подобных случаях модернизация ИТ-инфраструктуры может быть чисто ИТ-проектом, приносящим организации конкретный экономический эффект.

Как в понятных для бизнеса терминах донести до него выгоду инфраструктурных проектов? И как убедить руководство в том, что улучшения ИТ-инфраструктуры смогут благоприятно отразиться на показателях бизнеса?

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

В банке мы оцениваем проекты посредством расчета чистой приведенной стоимости (Net Present Value, NPV): на горизонте трех лет вычисляем разницу между потоком доходов и расходов от данного проекта, приведенных к текущему моменту времени. Бизнес строит свои прогнозы относительно ожидаемых денежных потоков, ИТ-департамент прогнозирует расходную составляющую. Эти оценки перепроверяются, и с учетом текущей ставки дисконтирования вычисляется чистая приведенная стоимость. Такая оценка позволяет спрогнозировать стоимость, добавляемую любым проектом. Чем выше чистый дисконтированный доход проекта, тем выше его инвестиционная привлекательность.

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

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

Да, вполне. Как я уже сказал, обосновать пользу модернизации серверного оборудования совсем несложно: есть стоимость оборудования с гарантийной поддержкой, есть расходы на постгарантийное обслуживание, есть информация о производительности новых серверов, числе ядер на них, политике лицензирования ПО ваших вендоров. Если речь идет о системах хранения, то можно рассмотреть время ожидания в качестве одного из показателей производительности, которые, в свою очередь, обеспечивают более эффективное использование потенциала компьютерного оборудования, требуя, соответственно, меньшего числа процессоров, сокращая требуемые лицензии СУБД. На основе этой информации строим оценку чистой приведенной стоимости. Опираясь на эти оценки, мы, в частности, готовили обоснование для инфраструктурных проектов по замене серверов IBM и систем хранения Hitachi Data Systems, чтобы сократить совокупную стоимость владения инфраструктурой для бизнеса

Можно ли аргументировать наличие взаимосвязи между повышением производительности обновляемых инфраструктурных компонентов (например, систем хранения) и появлением новых возможностей для роста отдельных бизнес-направлений? Какие доказательства работают в этом случае?

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

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

Приведу пример. Два года назад у нас были две системы цифровой телефонии — Cisco и Avaya, а в 15% дополнительных офисов еще работали аналоговые АТС Panasonic. Сквозной нумерации не было, не все имена звонивших отображались, отсутствовал единый каталог абонентов, прямой набор номеров был неполным, поскольку не везде была цифровая телефония. Персонал тратил свое рабочее время на поиск и набор телефонных номеров сотрудников, к тому же часть звонков из одного офиса в другой шла через платные каналы по городской и междугородной связи. Реализовав единую систему цифровой телефонии, мы существенно снизили расходы на телефонную связь благодаря тому, что звонок маршрутизируется по сети в ту точку присутствия банка, откуда связь с вызываемым абонентом обойдется дешевле всего.

Может ли инфраструктурный проект повлиять на конкурентоспособность организации, например, в результате модернизации специализированной телефонии для голосового трейдинга и внедрения платформы Orange Open Trade компании Orange Business Services? И как можно увязать новые возможности инфраструктурного компонента с таким многогранным фактором, как конкурентоспособность?

Одно из направлений финансовой деятельности МДМ Банка — инвестиционный бизнес, и в биржевых торгах скорость выполнения клиентских ордеров имеет колоссальное значение — чей сводящий механизм (matching engine) отработает быстрее, чьи серверы и чей программный код быстрее пересчитают модели в алгоритмическом трейдинге, чья транзакция пройдет быстрее за счет колокации серверного оборудования с биржей. И это только малая часть примеров влияния инфраструктуры на конкурентоспособность организации.

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

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

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

Как уловить момент, когда бизнес будет готов начать модернизацию инфраструктуры? Какие признаки могут на это указывать?

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

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

Есть ли смысл пытаться формировать спрос со стороны бизнеса на проекты инфраструктурной модернизации?

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

Может быть и так: ИТ исправно работают и вроде бы устраивают бизнес, но есть возможность удовлетворить потребности бизнеса более эффективно, например, с помощью более производительного оборудования, которое позволит снизить число лицензий СУБД, занимает меньше места в ЦОД и к тому же потребляет меньше электроэнергии. В этом случае можно предложить бизнесу такое более эффективное решение.

Допустим, проект модернизации ИТ-инфраструктуры реализован. Как доказать бизнесу, что он в результате точно получит те выгоды, которые ожидал получить?

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

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

Как следует себя вести ИТ-руководителю в отношении инициатив инфраструктурной модернизации — предлагать, настаивать, искать союзников? Или просто ждать, когда бизнес «созреет», не предпринимая активных действий?

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

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

Какую роль ИТ-руководителю следует отвести в модернизации ИТ-инфраструктуры?

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

Опыт цифровой трансформации постепенно накапливается в самых разных отраслях, и в каждой можно найти нечто ценное для других. Острота проблем, связанных со сбором, хранением, обработкой и обеспечением безопасности данных, нарастает и в ретейле, и в транспортной отрасли, и в финансовом секторе. А в медицинской диагностике эти проблемы видны как на ладони, так как эта область требует особой ответственности от всех участников процессов — от разработчиков до пользователей. Стандартизация, необходимая для организации совместной работы, анализ неструктурированных данных, жесткие требования регулятора, осторожное знакомство с Большими Данными и облаками — все рассматривается через призму этой ответственности, которая ложится в том числе и на ИТ-руководителя.

Диагностический кластер

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

Как автоматизировать архивирование диагностических снимков, их привязку к истории болезни и передачу направлений на исследования, организовать виртуальные консилиумы, предоставить лечащему врачу и пациенту доступ к изображениям? «Похоже, удалось наконец сформулировать реальные потребности и понимание, какие задачи, кроме чисто технических, будут решены теми или иными средствами», — говорит Дмитрий Дроздов, эксперт по медицинским вопросам компании «Альтомедика».

Наряду с медицинской информационной системой (МИС) вторым базовым компонентом ИТ-инфраструктуры современной клиники стала cистема архивирования и передачи медицинских изображений (Picture Archiving and Communication System, PACS). По мере освоения новых возможностей и понимания новых потребностей, клиники добавляют к PACS радиологические информационные системы (Radiology Information System, RIS), компьютерные системы диагностики (Сomputer Aided Diagnostic, CAD) и другие решения, формируя новый кластер ИТ-инфраструктуры.

«Руководители отрасли здравоохранения осознали наличие проблемы сбора и хранения медицинских диагностических изображений и необходимость заниматься ею не для галочки, а с целью обеспечить решение широкого круга задач, обозначенных в региональных и федеральных программах развития здравоохранения», — заметил Евгений Крючков, руководитель направления PACS компании «Базис-Мед».

Одни из доминирующих тенденций в этой области — стандартизация и унификация. «Практически во всех присутствующих на рынке решениях такие тенденции приоритетны, причем как на уровне стыковки используемого оборудования по профилям IHE, так и на уровне универсальных программных протоколов обмена информацией, способных объединить решения данной области с госпитальными и аналитическими системами», — отмечает Игорь Пятница, независимый эксперт, до недавнего времени выполнявший обязанности начальника отдела ИТ и комплексной безопасности Федерального научно-клинического центра детской гематологии, онкологии и иммунологии им. Д. Рогачева. С обеспечением защиты данных PACS, RIS и других решений данного кластера, по его словам, ситуация похуже из-за отсутствия четкой нормативной базы в отрасли или нежелания иностранных разработчиков медоборудования и ПО следовать российским требованиям в области информационной безопасности.

«На сегодняшний день практически у всех медучреждений отсутствует интеграция PACS с МИС, которая могла бы сильно упростить работу врачей и существенно сократить информационный разрыв в диагностике для пациентов», Сергей Гилев, ИТ-директор компании «Медскан»

Проблемы в головах

Пласт проблем, возникающих при работе с медицинскими изображениями, маленьким не назовешь. В большинстве медицинских организаций снимки и результаты PACS/CAD хранятся на DVD, что существенно затрудняет поиск, обмен и передачу результатов обследований, сообщил Олег Симаков, генеральный директор компании «Технологии Моделирования Здоровья». Внесение корректировок в хранимые файлы (заштриховка ФИО пациентов или их замена на идентификаторы) ведет к существенному снижению доверия к документам исследований и резкому увеличению трудоемкости.

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

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

Медицинские изображения — объемные файлы, которые требуют систем хранения соответствующей емкости и качества. ИТ-служба или обслуживающая компания должна постоянно контролировать каждый из трех уровней хранения таких данных. На первом уровне результаты проведенных исследований до их описания специалистами (а в ряде случаев и после этого) хранятся на мощностях просмотровых станций и только по команде врача, описывающего исследование, отправляются в централизованную базу PACS с прикрепленным описанием. Второй уровень образует база PACS, откуда доступ к результатам исследований и их описаниям получают клиницисты медучреждения и удаленные консультанты. И третий уровень — долговременное хранилище, где содержатся снимки выписанных пациентов, а также резервные копии системы и базы данных. Последние два уровня, как правило, отличаются только используемыми средствами хранения c разной скоростью доступа к ним. «На практике за каждый уровень хранения зачастую отвечают разные подразделения лечебного учреждения и разные обслуживающие организации, — говорит Пятница. — Отсутствие согласованного взаимодействия между ними порой приводит к довольно плачевным результатам — частичной, а иногда и полной потере медицинских изображений».

Надежные системы хранения данных не только сложны, но и дороги. Между тем ИТ в лечебных учреждениях обычно финансируются недостаточно, и нередко — по остаточному принципу. Типовые решения практически отсутствуют, и стандартизация далека от совершенства. «Сообщество специалистов пока не достигло консенсуса по целому ряду вопросов стандартизации, описаний API, в результате каждый внедряющий сложную МИС сталкивается с одними и теми же проблемами, в том числе частично уже решенными, но недостаточно документированными», — указал Дроздов.

Сегодня клиники уже включают в технические требования к приобретаемому медицинскому оборудованию поддержку отраслевого стандарта обмена медицинскими изображениями DICOM (Digital Imaging and Communications in Medicine). Однако, по словам Крючкова, довольно часто из соображений экономии или по незнанию DICOM-сервисы не включаются в состав закупки, а это приводит к тому, что новое современное оборудование не может использоваться в нужном объеме.

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

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

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

Адекватное предложение

Решений для автоматизации сбора, хранения, обработки медицинских изображений на рынке немало, но насколько они отвечают потребностям врачей?

Пятница считает, что практически все решения ведущих мировых производителей, таких как GE, Fuji, Agfa, EMC, Siemens, отвечают требованиям, которые предъявляются к ним врачами-диагностами в части инструментария. Все больше врачей-клиницистов начинают использовать так называемые веб-просмотрщики и другие инструменты, прежде им недоступные, а узкие специалисты в хирургии и онкологии активно применяют функционал для 3D-реконструкции органов (тканей) человека.

В наибольшей степени отвечают потребностям врачей PACS, базовые функции лабораторных информационных систем и другие специализированые системы, где большая часть данных генерируется медицинским оборудованием, а не вводится персоналом, отмечает Дмитрий Фадин, руководитель отдела корпоративного взаимодействия компании «ОМБ».

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

Решения для работы с медицинскими изображениями различаются не только по цене, функциональности, лицензионной политике и требованиям к инфраструктуре, но и по качеству. И к их выбору надо подходить серьезно. «Крайне важно, чтобы в процессе выбора принимали участие врачи, и последнее слово должно оставаться за ними, — подчеркнул Налетов. — Если врач имел возможность ознакомиться с системой, поработать с демонстрационной версией, он сам решит, насколько она ему подходит».

Вотум доверия

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

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

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

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

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

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

«Ни один западный врач близко не подойдет к несертифицированной PACS, а у нас любой программист может написать и успешно продавать собственную «PACS»», Евгений Крючков, руководитель направления PACS компании «Базис-Мед»

К новым высотам

Самой важной тенденцией в сфере обработки медицинских данных Фадин назвал появление таких систем для анализа медицинских данных, как IBM Watson, осуществляющих обработку неструктурированной информации на естественном языке. «Широкое применение подобных систем может привести к глубокому изменению роли врача и системы медицинского обслуживания», — уверен он.

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

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

Гилев полагает, что качественных изменений можно добиться интеграцией с МИС и предоставлением доступа к данным «извне», со стороны пациента.

По мнению Фадина, самыми актуальными расширениями функциональности существующих МИС станут системы поддержки принятия решений, основанные на клинических рекомендациях. Анализ Больших Данных и другие системы анализа данных, на его взгляд, найдут применение в первую очередь в научных организациях.

«Система поддержки принятия решений врача может основываться на технологиях Big Data и анализа неструктурированных данных, дополняющих друг друга», — говорит Симаков.

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

«Было бы полезно включить в инструментарий систем данного кластера речевые технологии», — считает Пятница. По его сведениям, первые шаги в этом направлении в нашей стране уже делаются. Инструменты анализа неструктурированных данных и системы поддержки принятия решения должны находиться на уровне хранения данных медучреждения в целом. Big Data также целесообразнее и проще реализовать в масштабе всей организации, так как руководству интересно и полезно объединить медицинские данные и экономические показатели для максимально полной оценки качества работы учреждения и тенденций его развития.

«Было бы полезно включить в инструментарий систем данного кластера речевые технологии», Игорь Пятница, независимый эксперт, экс-начальник отдела ИТ и комплексной безопасности ФНКЦ детской гематологии, онкологии и иммунологии им. Д. Рогачева

Облачно-мобильные перспективы

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

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

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

«Практика получения «второго мнения» и предоставления доступа к медицинским данным в нашей стране не развита из-за отсутствия единой базы медицинских карт пациентов и драйвера продвижения подобного рода сервисов среди населения», — заметил Гилев. Еще один подводный камень активно развивающейся в мире мобильности — безопасность данных. «Как руководитель ИТ-службы, я должен предоставлять качественные, а главное, безопасные услуги по хранению и обработке данных не только для наших пациентов, но и для врачей», — подчеркнул он.

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

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

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

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

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

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

ИТ-директор: оптимизатор, интегратор, консультант

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

«Мои главные задачи — снизить затраты на ИТ-инфраструктуру хранения, обработки и обеспечения безопасности данных, сфокусировать внимание на непрерывности бизнес-процессов и рентабельности ИТ. Все это взаимосвязано», — говорит Гилев.

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

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

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

Интернет вещей стремительно распространяется. Датчики, сетевые чипы и другие технологии, требуемые для объединения самых разных интернет-устройств, начиная от светильников и умных часов и заканчивая промышленным оборудованием, стоят сегодня совсем недорого.

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

Большинство аналитиков согласны с тем, что масштабы Интернета вещей в перспективе станут огромными. По оценкам группы Acquity Group (входящей в состав компании Accenture), к 2019 году оснастить свои дома подключенными технологиями планируют две трети потребителей; почти половина намерена приобретать носимые устройства. Как прогнозируют в Gartner, к 2020 году общее число подключенных потребительских, деловых и промышленных «вещей» достигнет 26 миллиардов. Это в 30 раз больше, чем в 2009 году, когда их насчитывалось около 900 миллионов. (По мнению Gartner, реклама Интернета вещей сегодня достигла своего пика.)

«Для практического применения “вещи”, выполняющие сбор и передачу данных, должны быть подключены к системам автоматизации, — указал аналитик Forrester Джеффри Хэммонд. — Эти программные системы осуществляют интеллектуальное управление “вещами” и сетями, которые те используют, и отвечают за упорядочение и хранение больших объемов собранных данных, а также за их обработку перед выдачей окончательного представления, помогающего решать какие-то полезные задачи».

Проектирование приложений для Интернета вещей

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

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

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

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

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

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

Сегодня стартапы, например Xively, Mnubo, Bug Labs и ThingWorx, предлагают уже много таких платформ, оснащенных средствами взаимодействия с широким спектром «вещей», выпускаемых большим количеством производителей.

Платформы для Интернета вещей выпускают и крупные производители. Компания Microsoft предлагает решение Intelligent Systems Service, а SAP — Internet of Things Solutions.

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

Стоит ли создавать платформу с нуля?

Компания OnFarm использует облачную платформу ThingWorx для разработки собственного веб-приложения. Использование ThingWorx помогло OnFarm существенно сократить объемы программирования и в короткие сроки создать веб-панели, подключаемые к источникам данных через API ThingWorx.

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

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

Поначалу генеральный директор OnFarm Ланс Донни подумывал о создании платформы для Интернета вещей с нуля, но такая идея была быстро отвергнута из-за большой конкуренции на рынке. Тогда компания наняла программиста, он написал на JavaScript интерфейс, позволяющий новым датчикам поддерживать взаимодействие с платформой ThingWorx способом, предусмотренным их производителями. Код этот находится непосредственно в ThingWorx. «К нам начали обращаться клиенты, желающие использовать в нашем решении какой-то конкретный датчик, — отметил Донни. — Выполняя их просьбу, мы связались с поставщиком, получили у него API и разработали интерфейс для связи ThingWorx с новыми датчиками».

Компания привлекла также четырех разработчиков, которые занимались созданием пользовательского интерфейса веб-приложения средствами Bootstrap, AngularJS и JavaScript. Интерфейс этот взаимодействует с ThingWorx через API RESTful. «Весь процесс был организован очень рационально, благодаря чему нам удалось сосредоточить основные усилия на вопросах производительности и гибкости при обращении к данным, их использовании и отображении на экране», — подчеркнул Донни.

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

- Paul Rubens. How to Develop Applications for the Internet of Things. CIO.  Nov 5, 2014