Статьи

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

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

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

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

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

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

Какие задачи можно решать эффективнее, если выстроена постоянная обратная связь с пользователями? Какие задачи удается таким образом решать в «Сибуре»?

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

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

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

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

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

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

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

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

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

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

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

Следует ли вести диалог по подразделениям или группам бизнес-пользователей? Нужна ли ИТ-службе сегментация бизнес-клиентов?

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

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

На каком языке должен вестись диалог ИТ-подразделения с его бизнес-заказчиками и пользователями? Как складывался язык общения в «Сибуре» и какой язык в итоге выбран?

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

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

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

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

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

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

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

Проект централизации ИТ полностью еще не завершен. Мы собрали воедино ИТ-службу, выстроив ее как одну из функциональных вертикалей: она нацелена на единые цели, работает по единым стандартам, и труд ее сотрудников оценивается по унифицированным принципам с декомпозицией целей и KPI службы на каждого ее сотрудника. Также мы централизовали ИТ-инфраструктуру, сейчас идет централизация бизнес-приложений: внедрено централизованное решение на платформе «БОСС-Кадровик», внедряются SAP ERP, модуль HR, корпоративная система документооборота на базе EMC Documentum (она заменит прежние локальные СЭД). Кстати, тиражирование новых бизнес-приложений на управленческие площадки дает огромный экономический эффект, поскольку вместе с внедрением систем идет развертывание стандартных бизнес-процессов.

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

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

Если постоянный широкий диалог между ИТ и бизнесом выстроен, можно ли рассчитывать на то, что в компании перестанут развиваться «теневые» ИТ (создание и приобретение ИТ в обход ИТ-службы), а те, которые уже есть, выйдут из «тени»?

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

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

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

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

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

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

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

В компании 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

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

Одно из таких исследований — отчет компании Rightscale о состоянии облака в 2015 году (State of the Cloud Report, 2015), в котором говорилось о росте облака Azure, превратившегося в главного конкурента лидирующей на этом рынке платформы Amazon Web Services (AWS).

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

Отвечает ли на самом деле ИТ-служба за облако компании?

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

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

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

А вот в других областях единодушие исчезает и мнения расходятся. На вопрос, кто выбирает публичные облака, 59% сотрудников ИТ-служб ответили, что это относится к их зоне ответственности. В бизнес-подразделениях с этим согласны лишь 35% опрошенных. Еще удивительнее, пожалуй, то, что аналогичный ответ на вопрос о частных облаках дали 57% сотрудников ИТ-служб и лишь 35% сотрудников бизнес-под­разделений.

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

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

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

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

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

На диаграмме, отражающей используемые в частном облаке технологии, видно, что 43% респондентов говорят об управлении частными облаками при помощи vSphere или System Center. Другими словами, они используют продукты виртуализации и называют их облаками. С тем же успехом минивэн можно назвать гоночным болидом, ведь оба автомобиля обладают схожими чертами — под капотом у них находится двигатель. И возникает уверенность, что практически все из озвученных тысяч виртуальных машин в облаке на самом деле являются стандартными объединениями виртуальных машин, а вовсе не облачными средами.

Еще одним свидетельством медленных темпов продвижения компаний к частному облаку стал доклад «В корпоративных планах доминируют проекты — предвестники облака», опубликованный недавно аналитиками 451 Group.

55% респондентов (всего в опросе принимал участие 191 человек) говорили о стандартизации и консолидации — другими словами, о базовой виртуализации. И только 6% упомянули об автоматизации, характеризующей облачные вычисления, хотя о создании частного облака сообщили 14% опрошенных. Последняя цифра, вероятно, свидетельствует о том, что участники этого опроса под частным облаком понимали примерно то же самое, что и участники опроса Rightscale, то есть внедрение vSphere или System Center они называли переходом к частному облаку.

С учетом результатов этого исследования неудивительно, что из 140 участников конференции Gartner, посвященной ЦОД, 95% сообщили о провале инициатив по внедрению частного облака.

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

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

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

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

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

Почему теневые ИТ живут и процветают

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

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

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

- Bernard Golden. Why the Enterprise Cloud Needs Shadow IT to Succeed. CIO. Mar 4, 2015

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

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

Технологии Больших Данных уже перевалили через «пик завышенных ожиданий» на кривой Gartner (Hype Cycle) и начали спуск по «желобу разочарований», тем не менее об их зрелости говорить преждевременно. Такое мнение высказал Александр Аникин, руководитель аналитического отдела Wikimart, на форуме Big Data 2015, организованном издательством «Открытые системы». По его словам, практика показывает, что, несмотря на очевидный прогресс за последние годы, Hadoop все еще остается сырой технологией, инструменты Apache не выдерживают критики, а система управления данными неудобна.

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

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

Матрица рекомендует

Wikimart — крупный торговый онлайн-центр, где на одной площадке представлены свыше 2 млн товаров от более чем 1,5 тыс. интернет-магазинов. Онлайн-ретейлеры загружают информацию о своих товарах на сайт гипермаркета и обрабатывают поступающие через него заказы. Выставленные на продажу товары автоматически попадают в общий каталог и становятся доступными покупателям. По сути, Wikimart — это сервисная компания, упрощающая процесс онлайн-торговли для ретейлеров, которые платят агрегатору разовую сумму за активацию своего партнерского счета, абонентскую плату в зависимости от размера выручки на площадке и комиссию 1–15% от каждого созданного заказа.

Благодаря ресурсам, вкладываемым в привлечение трафика, поисковую оптимизацию и контекстную рекламу, на сайт гипермаркета заходят более 300 тыс. посетителей в день. Компания регулярно анализирует поведение пользователей на сайте и оптимизирует дизайн, интерфейс и функционал площадки, чтобы повысить так называемую конверсию — долю посетителей, ставших покупателями. При этом в построении аналитической инфраструктуры Wikimart очень экономна и инвестирует в нее лишь тогда, когда это действительно необходимо. Аналитическая платформа Wikimart основана на классическом стеке Microsoft Business Intelligence и отдельно стоящем Hadoop-кластере на десять серверов, который работает на решении Cloudera. Из множества источников, в числе которых сайт, веб-счетчик, учетная система «1С», комплекс Asterisk-решений, данные пользователей, MySQL, а также сервисы контекстной рекламы «Яндекс.Директ» и Google AdWords, данные стекаются в классическое хранилище.

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

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

Реализованный в конце 2011 — начале 2012 года проект создания собственной системы внутренних рекомендаций для улучшения показателей конверсии и совершенствования взаимодействия пользователей с сайтом изначально был исследовательским. Для 2 млн товаров на сайте необходимо было построить матрицу попарных корреляций векторов просмотров этих товаров. Особенность этой задачи такова, что на входе данных не очень много, на выходе — еще меньше, но в процессе обработки возникают большие промежуточные вычисления, моментально забивающие винчестеры объемом по 10 Тбайт.

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

В результате внедрения Hadoop создан инструмент, генерирующий существенную долю продаж сайта Wikimart.

Аникин считает проект эффективным: при более чем скромных инвестициях получен заметный для бизнеса результат, и его можно реплицировать в других компаниях: «К примеру, мой коллега Роман Зыков, главный идейный вдохновитель проекта внедрения Hadoop, стал одним из основателей проекта RetailRocket.ru, который предлагает сервис рекомендаций для интернет-магазинов в формате облачного решения».

В аналитическом подразделении Wikimart сейчас ведется два крупных технологических проекта: построение внутренней системы планирования и бюджетирования на базе Microsoft OLAP Writeback, а также перенос в Hadoop части задач классического хранилища данных и усложнение логики преобразований, которую в рамках обычной базы данных нельзя было реализовать из-за ограничений по производительности. В первую очередь речь идет об анализе ассортимента, мониторинге загрузки товаров магазинов на площадку и других подобных задачах. Но все, что можно сделать с помощью обычной базы данных за разумное время, с ней и делается, подчеркнул Аникин.

Отдел синергии

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

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

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

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

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

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

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

Проблемы же с точностью и востребованностью данных решает наука о данных — Data Science, которая сейчас взбирается по кривой зрелости технологий, выстроенной аналитиками Gartner, на «пик ожиданий», в то время как Большие Данные уже начали с него сваливаться. Впрочем, учитывая отставание российского рынка от западного, Большим Данным еще только предстоит покорить вершину ожиданий. Но если срок созревания Больших Данных оценивается в 5–10 лет, то для Data Science этот период составляет от двух до пяти лет, а значит, барьеры недостаточной точности и востребованности данных могут быть преодолены гораздо быстрее. Функцию работы с данными следует выделить в специальный отдел, а в штате должна появиться должность директора по данным. Необходимость организационно обособить функции Data Science постепенно начинает осознаваться и в России, заметил Аникин. По его мнению, именно в отделе по работе с данными должна решаться проблема синергии бизнеса и ИТ. Кроме того, при наличии выделенной структуры будет заметно легче продвинуться в работе с данными на уровне топ-менеджмента.

«Хочется надеяться, что проблемы эффективной работы с данными решит Data Science, но время покажет», — заключил Аникин.

Интернет-компании, онлайн-ретейлеры и мобильные операторы уже давно строят на Больших Данных свой бизнес. Банки же в силу традиционной консервативности входят в «клуб Больших Данных» относительно поздно — только сейчас. Сбербанк, имея больше по сравнению с другими возможностей, ступил на эту стезю раньше многих: подразделение, занимающееся внедрением инновационных решений, у него появилось еще в 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 — «по месту») для прямой работы исследователей с данными и зону приложений, которые будут интегрироваться в бизнес-системы. В результате платформой смогут пользоваться не только аналитики, но и маркетологи, служба безопасности, специалисты продаж.

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

Единое сервисное окно

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

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

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

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

«Мы сравнительно быстро реализовали новые услуги в системе, которая поддерживала работу Service Desk. Теперь любой сотрудник, набрав ее новое название — HelpMe — в браузере, автоматически переводится на портал, через который может получить практически любые услуги, которые предоставляют сервисные подразделения банка», — объяснил Мартиросов.

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

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

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

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

Оптимизации ради

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

«В ИТ-департаменте российского ЕССО мы реализовали прозрачную систему предоставления ИТ-сервисов. В качестве инструментария мы использовали систему OmniTracker, она давала возможность планировать ИТ-ресурсы, контролировать качество работы и обеспечивала соблюдение SLA», — вспоминает Сергей Прохоров, эксперт совета ИТ-директоров журнала «Директор информационной службы» (CIO.ru), возглавлявший в тот момент ИТ-департамент компании «Экко-Рос».

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

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

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

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

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

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

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

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

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

Один ответ — ITSM

В агропромышленном холдинге «Мираторг», который является одним из ведущих производителей и поставщиков мяса на российском рынке, идея использовать принципы ITSM в бизнесе реализуется и развивается с 2013 года. «Наши сотрудники постоянно спрашивали: если есть проблема, вопрос или просьба (неважно, какая), то куда обращаться? И как отследить факт выполнения этих обращений? Как планировать ресурсы, используемые при обработке обращений и как оценивать качество выполнения работ по обращениям? — вспоминает Дмитрий Мельников, ведущий технолог Service Desk компании “Мираторг”. — Проанализировав опыт работы ИТ-подразделения, я попытался использовать идеи ITSM для ответов на эти вопросы — естественно, с адаптацией к нашим реалиям и, что особенно важно, с учетом отечественного менталитета».

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

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

Подобные проекты охватили под­разделения инженерного обслуживания магазинов в рознице, АХО в офисах, службы качества и АСУТП на производстве, бухгалтерию, отдел управления персоналом, а также различные технические службы и соответствующие сервисы.

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

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

Устранение болевых точек

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

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

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

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

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

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

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

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

Улучшение бэк-офиса

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

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

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

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

Подводные камни

В ходе реализации проектов в области сервис-менеджмента определенные трудности неизбежны. По наблюдениям Ильи Масленкина, директора компании Axios Systems в России и СНГ, самое важное и сложное — договориться, кто, как и когда управляет процессом (регламентирует, задает и контролирует метрики качества) и кто обеспечивает методологическую и технологическую базу и экспертизу: «Смежные подразделения, как правило, требуют поступательного развития процессов управления, поэтому при внедрении ITSM-подходов важно “не спугнуть”, не усложнить, не создать лишней бюрократии и избежать ситуации, когда пользователи борются против системы автоматизации, работают ей вопреки».

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

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

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

Чтобы избежать серьезных трудностей при внедрении сервис-менеджмента, Дмитрий Рубин, руководитель по развитию направления Service Desk компании Naumen, рекомендует в первую очередь объяснить сотрудникам, что они являются ценными для компании внутренними поставщиками сервисов и что от их труда напрямую зависит конечный результат деятельности всей компании, ее эффективность и бизнес-показатели, поэтому работа сотрудников должна быть формализована и максимально оптимизирована. Потребитель или заказчик услуг любого сервисного подраз­деления, в свою очередь, должен четко понимать, какой именно результат он получит (это будет описано в каталоге услуг конкретного сервисного подразделения), в какие сроки и с каким качеством (это будет зафиксировано в SLA).

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

***

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

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

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

«Бизнес-аналитики в нашей компании работают с Большими Данными с 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% печати на двухстороннюю, то после завершения проекта можно просчитать, как реально изменились расходы на тонер и бумагу.

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

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

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

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

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