Статьи

Опубликован атлас

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

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

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

Россия, следуя мировым технологическим тенденциям, принимает передовые зарубежные практики, положенные в основу международных стандартов (в частности, ISO), формализуя их в виде стандартов ГОСТ. Тут случаются коллизии. Если мы посмотрим на англоязычный термин «business continuity», с которого собственно и начинается данное направление, то в стандарте ГОСТ 22300 «Безопасность в чрезвычайных ситуациях. Термины и определения» он переведен как «непрерывность деятельности». А в стандарте ГОСТ 22301 «Системы менеджмента непрерывности бизнеса. Общие требования» термин переводится как «непрерывность бизнеса». И это, к сожалению, не единственное подобное расхождение.

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

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

Специалист широкого профиля

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

Для понимания того, какие же именно области включает в себя непрерывность бизнеса, можно поискать стандарты по номеру серии ISO 223xx или по термину «business continuity» – и увидеть большой список нормативов. Кроме указанных выше глоссария и общих требований, здесь будут документы по построению системы управления непрерывностью бизнеса, обеспечению устойчивости организации, по непрерывности цепочки поставок, анализу влияния на бизнес, массовой эвакуации, использованию добровольцев, структуре обмена информацией, по проведению тренировок, установлению партнерства, реагированию на инциденты, оповещению общества. А если поискать дополнительные источники, то можно найти еще и руководства по обеспечению управления людьми в критических ситуациях, общему кризисному управлению, обеспечению устойчивости ИТ-систем и многое другое.

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

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

Источники знаний

Куда же обратиться тем, кто хочет развить свою компетенцию в сфере обеспечения непрерывности бизнеса, если упомянутых курсов недостаточно? Хорошо, если человек владеет английским языком на уровне чтения литературы – он может использовать и многообразие перечисленных выше стандартов, и множество литературы от опытных профессионалов, и услуги целых учреждений, работающих в данной области и представленных в Интернете. Среди последних наиболее авторитетными и предоставляющими для изучения большое количество профессиональной информации являются Институт непрерывности бизнеса (Business Continuity Institute, thebci.org) и Международный институт восстановления после катастроф (Disaster Recovery Institute International, drii.org). Эти институты выпустили свои подробные методики построения систем управления непрерывностью бизнеса, они публикуют дополнительные предметные руководства, а также статьи по отдельным вопросам непрерывности бизнеса.

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

В тематических и отраслевых журналах встречается некоторое количество более или менее подробных статей по вопросам непрерывности бизнеса, в том числе и в «Директоре информационной службы» (http://www.osp.ru/os/2012/01/13012922). Но нужно понимать, что, читая статью или даже серию статей, невозможно погрузиться в тему настолько, чтобы стать специалистом хотя бы начального уровня. Для сравнения, методики Института непрерывности бизнеса или Международного института восстановления после катастроф, подробно поясняющие все аспекты процессов управления непрерывностью бизнеса, – это книги объемом более 100 страниц текста.

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

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

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

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

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

* * *

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

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

Старайтесь избегать сетей Wi-Fi с открытым доступом

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

Защитите домашнюю сеть

Незащищенная домашняя беспроводная сеть также уязвима. Пользователи должны как минимум защитить свои беспроводные сети паролями и включить шифрование (желательно WPA2). А лучше – разработать для удаленных сотрудников набор правил, регламентирующих настройку их систем.

Подключайте все мобильные устройства через VPN

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

Подберите подходящее приложение VPN, попросите сотрудников установить его на свои устройства и объясните, как им пользоваться.

Не путайте свои персональные данные с деловыми

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

Не распространяйтесь в социальных сетях о работе

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

Смените, наконец, пароли, установленные по умолчанию!

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

Обновляйте программы регулярно

Киберпреступники активно эксплуатируют также и известные уязвимости в ПО и плагинах – например, в Adobe Flash, Acrobat Reader и Java. Плагины и программное обеспечение – в том числе мобильную операционную систему и доверенные приложения – необходимо регулярно обновлять на всех используемых устройствах.

Путешествуйте с умом

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

Берегитесь подслушивающих и подглядывающих!

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

Держите компьютер «на замке»

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

– Ryan Francis. 10 ways to make sure your remote workers are being safe. CSO. November 1, 2016

Черные пятницы и киберпонедельники – источники радости для покупателей и периоды наибольшей занятости для многих продавцов. В компании Hudson’s Bay Company (HBC), которой принадлежат торговые марки Lord & Taylor, Saks 5th Avenue и ряд других, прошлогодняя предпраздничная лихорадка стала самым подходящим поводом для испытания новых функций веб-сайтов.

HBC использует типичный сервер приложений Oracle WebLogic и платформу электронной коммерции Blue Martini, предлагаемую разработчиками RedPrairie. Общий ее стек создавался и совершенствовался на протяжении многих лет. «Она работала, но были проблемы с ее развертыванием, сложно было вносить изменения и обновления», – указал Мэтью Пик, управляющий в HBC командой инженеров по инфраструктуре.

Инженеры HBC стали выяснять, как можно решить эти вопросы. Для решения проблемы были предложены микросервисы и контейнеры.

Для начала реализации своего проекта по смене платформы Пик выбрал Product Detail Page (PDP). PDP представляет собой часть приложения электронной коммерции, в котором содержатся описания и фотографии товаров. Вместо того чтобы встраивать PDP в приложение, разработчики из HBC разбили его на 12 отдельных микросервисов, размещавшихся в контейнерах приложения (один из них загружал изображения, другой обслуживал текстовую часть и т. д.).

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

Запуская PDP в прошлогодние черную пятницу и киберпонедельник, HBC решила подстраховаться и направила на микросервисы PDP лишь часть трафика. В случае возникновения нештатных ситуаций их можно было бы отключить и вернуть весь трафик в традиционное русло. «Мы не стали рисковать всем сайтом, – вспоминал Пик, следивший за ситуацией на протяжении всего запуска новых технологий, с пятницы и до понедельника. – Но рано или поздно настает момент, когда нужно просто сказать: “Давайте попробуем”».

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

Что такое микросервисы?

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

Звучит знакомо? Несложно предположить, что микросервисы восходят к модному термину прошлых лет – сервисно ориентированной архитектуре (SOA), воплощавшей идею создания независимых отдельных компонентов приложения.

«Заинтересованность предприятий в микросервисах объясняется поиском нового подхода к построению сервисно ориентированной архитектуры, а также к использованию микросервисов с контейнерами», – пояснил старший вице-президент консультационной компании Cloud Technology Partners Дэвид Линтикум.

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

Преимущества

Микросервисный подход дает следующие преимущества:

Гибкость. Благодаря разбиению приложения на компоненты каждая отдельная его часть разрабатывается независимо. «Вам больше не нужно беспокоиться о синхронизации действий разработчиков», – заметил Сид Сиджбрандидж, генеральный директор стартапа GitLab, предлагающего репозитарий кода, который составляет конкуренцию GitHub. Вместо того чтобы собирать команду из 100 человек, которые будут работать над одним приложением, вы формируете 10 команд по 10 человек, проектирующих отдельные компоненты и внедряющих новые функции по мере их готовности. Не нужно составлять расписание обновлений и собирать приложение полностью – новые функции появляются сразу, как только они будут готовы.

Частичные нарушения. Если какой-то компонент приложения перестает работать, нет опасности того, что откажет все приложение полностью. «Цель заключается в том, чтобы сузить круг неисправностей и минимизировать их последствия», – пояснил аналитик 451 Research Донни Беркхольц. Например, если банковский сайт создан с использованием микросервисного подхода, при отказе функции перевода денег возможность проверить свой баланс у клиентов все равно остается.

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

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

Задачи

По мнению Беркхольца, у команд, исповедующих agile-проектирование или концепцию DevOps, больше шансов преуспеть в создании микросервисов. DevOps – это объединение функций разработчиков и операционных функций, повсеместное или в каких-то отдельно взятых командных проектах.

В таких средах код пишется, тестируется и внедряется быстрее. Многие предприятия, придерживающиеся концепции DevOps, имеют автоматизированную инфраструктуру с самообслуживанием – например, виртуализированные или облачные среды для тестирования и разработки или для поставки уже готовых приложений. Исследования, проведенные 451 Research, показывают, что две трети организаций применяют при разработке приложений методологию agile-проектирования, а около 40% – концепцию DevOps. Именно в таких организациях вероятность успешного внедрения микросервисов наиболее высока. У компаний, не придерживающихся тенденции разработки следующего поколения, процесс перехода к микросервисам будет протекать сложнее.

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

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

«Разработчики, выстраивающие микросервисы, не идут в ИТ-службу оформлять заявку на новую виртуальную машину, – пояснил он. – При agile-проектировании разработчики вправе ожидать, что инфраструктурные ресурсы будут автоматически выделяться им по требованию через API и эластичное масштабирование».

Для поддержки инфраструктурной среды такого рода существует множество различных инструментов. Строить внутреннее облако можно при помощи программного обеспечения для частных облаков, предлагаемого VMware или OpenStack. Если ИТ-служба не хочет заниматься построением инфраструктуры самостоятельно, она может обратиться к платформам публичных облаков Amazon, Microsoft, Google и других поставщиков. Автоматизировать управление инфраструктурой можно при помощи платформ PaaS Cloud Foundry или Red Hat. Для приложений, управляемых событиями (например, для сценариев Интернета вещей), идеально подходят так называемые бессерверные вычислительные платформы. Каждая такая платформа меняет роль ИТ-службы – теперь перед ней могут ставиться разные задачи, начиная от поставок инфраструктуры и заканчивая построением среды, где разработчики самостоятельно будут развертывать микросервисы.

Для чего микросервисы подходят лучше всего

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

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

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

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

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

– Brandon Butler. What you need to know about microservices. Network World. November 9, 2016

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

Недавно сеть модных магазинов «Мэлон Фэшн Груп» завершила внедрение кассового решения на базе Microsoft Dynamics AX POS. Главной целью проекта была именно реализация концепции омниканальности. Подробностями проекта делится Алексей Морозов, ИТ-директор «Мэлон Фэшн Груп».

- Каковы корни проекта? Почему было принято решение о его реализации?

Ландшафт наших информационных систем сейчас эволюционирует: от стратегии Suite, то есть от монопольно представленной платформы «1С», мы постепенно переходим к стратегии Best of Breed, подразумевающей интеграцию лучших нишевых решений. Эта стратегия сложна в реализации и требует больше времени и компетенций, особенно в области качественной интеграции процессов и потоков данных. Однако комбинация лучших средств для решения каждой конкретной бизнес-задачи более выигрышна – не приходится идти на компромиссы: бизнес получает полную автоматизацию процессов каждого направления. В рамках реализации данной стратегии мы рассматривали и выбор лучшего решения для автоматизации точек продаж (Point Of Sale, POS).

Прежде в наших магазинах работала система на базе «1C:Предприятие 7.7». Это были автономные рабочие места, ими не могли централизованно управлять как бизнес-подразделения (скидки и акции), так и сервисные службы (обновления, контроль работы, сбор статистики). Загрузка справочных данных и выгрузка результатов были полностью в руках сотрудника конкретного магазина.

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

- Какую роль играет новое решение в развитии омниканальности?

Microsoft Dynamics мы рассматриваем как ядро для автоматизации всех процессов коммуникаций с розничными клиентами. Сейчас у нас реализованы не только стандартные POS-операции, но и процессы возврата в любом магазине, возвраты в обычном магазине покупок из интернет-магазина, есть поддержка акций и скидок, внутренние «фишки» (например, лимитные карты для своих сотрудников). Кроме того, разработана программа балльной лояльности, она постепенно запускается на первых двух брендах (BeFree и Zarina). Также начат ее запуск в Love Republic. Вся система работает как с классическим интерфейсом, так и в тач-реализации.

Каждый бренд самостоятельно разрабатывает требования к омниканальности, и базой для реализации этого служит именно новая платформа. Так, BeFree сейчас отказался от пластиковых карт лояльности – с клиентами теперь взаимодействуют через мобильное приложение, интегрированное с системой. С ней также интегрированы три автономные интернет-площадки, SMS- и почтовые сервисы. В ноябре передаем в эксплуатацию подсистему работы с остатками, потом запланированы процессы Click&Collect. На следующий, 2017 год в плане стоят проекты по самообслуживанию, а также сервисы, связанные с вводом в действие Федерального закона № 54-ФЗ «О применении контрольно-кассовой техники».

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

- Почему была выбрана именно платформа Dynamics AX, какие рассматривались альтернативы?

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

Выбор был богатый. Мы просмотрели более 10 систем: решения компаний «Пилот», «Сервис Плюс», Cegid, продукты GK/Retail, TP.Net, Set Retail. Везде были свои плюсы и минусы, но по совокупности победило выбранное нами решение. Изначально оно проигрывало в двух составляющих: требования к инфраструктуре и стоимость владения. Однако необходимость в глобальном апгрейде оборудования стояла уже давно, кроме того, переход на решения Microsoft позволил сократить требования к инженерной службе и в итоге решить вопросы централизованного управления.

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

- Какие проблемы – ожидаемые и не очень – проявились в ходе реализации проекта? Как их решали?

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

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

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

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

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

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

Затраты на тиражирование оказались минимальными благодаря отказу от тиражирования силами интегратора и совмещению работ по нескольким проектам.

- За счет чего ожидаете возврат инвестиций, и какой? На какие эффекты рассчитываете?

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

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

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

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

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

К сказанному нужно добавить, что есть и дефицит специалистов по безопасности.

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

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

Необходимые навыки

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

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

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

– Безопасность. Специалисты по информационной безопасности станут еще более востребованными в мире, где из-за наплыва новых IP-устройств неизбежно вырастет число уязвимостей. DDoS-атаки, уже сегодня организуемые с применением «вещей», – это только «первые ласточки».

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

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

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

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

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

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

В компании Foote Partners в числе наиболее востребованных называют навыки работы с Apache Hadoop, базами NoSQL и NewSQL, а также с Apache Spark.

В компании GE Aviation после реализации проекта цифровой трансформации и внедрения технологий Интернета вещей появились две новые должности – директор по данным и главный инженер по новым методологиям производства. Для проектов разработки ПО компании требуются профессионалы с широкими познаниями в сфере Больших Данных, говорит ИТ-директор GE Aviation Джуд Шрамм: «Нам нужны люди, разбирающиеся в широком круге технологий, таких как Hadoop, Cassandra, Greenplum. Мы вкладываем деньги, чтобы нанимать новых специалистов и обучать имеющихся. Мы стремимся максимально расширить их компетенцию и приучить к адаптивности. Нам не нужны те, кто хорошо разбирается только в одной области, – мы ищем специалистов по Большим Данным, имеющим познания по всем технологиям».

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

Примерно в 60% компаний, ставших участниками опроса LNS Research, признались, что им не хватает собственных специалистов, чтобы начать проект в области Интернета вещей или аналитики. Мэтью Литлфилд, президент LNS, говорит, что остальные 40% – те, кто утверждают, что располагают нужными навыками, – «просто не осознают реальных масштабов проблемы».

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

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

– Облачные вычисления. С ростом объема данных в рамках проектов Интернета вещей предпочтительной инфраструктурой для них станет облачная.

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

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

– Деловые качества. С ростом применения Интернета вещей техническим специалистам понадобятся знания в области бизнеса.

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

Работник новой эпохи

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

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

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

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

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

Курс на инновацию

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

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

«Нужно приучаться распознавать закономерности, это основа ассоциативного мышления, одного из главных навыков аналитика», – уверен Фут.

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

– Stacy Collett. Is your IT staff ready for IoT? Computerworld. Oct 31, 2016

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

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

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

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

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

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

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

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

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

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

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

– Пол Уимпенни, директор по цифровой стратегии в ИТ-подразделении Продовольственной и сельскохозяйственной организации при ООН

– Paul Whimpenny, Senior Officer for Digital Strategy in the IT Division of the Food and Agriculture Organization of the United Nations. What happens when IT is guilty of Shadow IT? Network World. October 5, 2016

Почему вопросам безопасности перед слиянием или поглощением (Mergers and Acquisitions, M&A) уделяется так много внимания? Эксперты привели сразу несколько примеров кошмарных сценариев, когда компания с хорошим уровнем кибербезопасности приобретала организацию, у которой уже имелись серьезные бреши. Был случай проникновения к покупателю вредоносного кода из приобретаемой компании. Об этом никто не знал почти год, выяснилось же все только при подсчете нанесенного ущерба. Исходный код был украден, продукт скомпрометирован, репутация пострадала.

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

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

Раннее планирование

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

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

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

Целью хакеров может оказаться сама информация о слиянии

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

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

Задавайте конкретные вопросы

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

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

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

Добейтесь максимальной прозрачности

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

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

Больше компаний – больше проблем

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

Трудности приобретаемой компании

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

Документируйте все тщательно и заблаговременно

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

Автоматизируйте свои процессы

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

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

Кто за что отвечает

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

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

Следите за людьми, которые пытаются делать все по-старому

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

Держите системы под замком, даже если планируете от них отказаться

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

Временные меры могут оказаться необходимыми

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

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

Не забывайте о человеческом факторе

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

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

Следите за утечкой мозгов

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

Жизнь вносит коррективы, и их следует учитывать

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

– Josh Fruhlinger. How to keep IT security at the forefront during a merger. CSO. Sep 19, 2016

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

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

Исследователи Грегорио Роблес и Хесус Гонсалес-Барахона из испанского Университета короля Хуана Карлоса определяют «ответвление» (forking) следующим образом: «Ответвление возникает, когда часть сообщества разработчиков (или независимая сторона, вовлеченная в проект) начинает проводить полностью независимую дальнейшую модернизацию имеющегося исходного кода. Для того чтобы считаться ответвлением, проект должен иметь: новое название; иное направление развития; параллельную инфраструктуру (веб-сайт, систему управления версиями, список подписчиков и т. д.); новое сообщество разработчиков (не связанное с оригинальным проектом).

Следует помнить, что ответвление не является повсеместным явлением. Несмотря на то что в последние годы оно встречается чаще, доля таких проектов в общей массе проектов свободного ПО не увеличивается.

Оценка ответвления с обеих сторон

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

«С одной стороны, возможность ответвления — одно из основополагающих прав разработчиков свободного программного обеспечения, — заметил президент Open Source Initiative Эллисон Рандал. — И мы понимаем, что свобода ответвления очень важна. Это отличный способ оживить умирающий проект».

В качестве примера Рандал привел пакет LibreOffice. До появления этой ветви проект OpenOffice.org страдал от «человеческого фактора», который не позволял развивать код дальше. Ветвь LibreOffice оказалась весьма успешной и сегодня уже затмила собой OpenOffice.org.

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

Но можно предпринять меры, которые помогут вам остаться на правильной стороне.

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

Опасности реальной жизни

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

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

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

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

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

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

В своем исследовании Роблес и Гонсалес-Барахона проанализировали «все сколько-нибудь значимые ответвления». В августе 2011 года ими было выявлено 220 подобных проектов. Прекращение реализации как первоначального проекта, так и всех его ветвей наблюдалось в 9% случаев. При появлении ветвей, обусловленных прекращением реализации оригинального проекта (возможным или фактическим), доля действительно прекращенных оригинальных проектов составила 10%. Дальнейшее развитие ответвлений обрывалось чуть чаще — в 14% случаев.

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

– Paul Rubens What CIOs need to know about open source forking. CIO. October 4, 2016

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

– Paul Whimpenny, Senior Officer for Digital Strategy in the IT Division of the Food and Agriculture Organization of the United Nations. A pragmatic approach to Enterprise Architecture. Network World. October 4, 2016

На конференции Gartner Data Center, Infrastructure & Operations Management Events, которая пройдет 28-29 ноября в Лондоне и 5-8 декабря в Лас-Вегасе, аналитики обсудят тенденции развития ЦОД.

Появление новых технологических тенденций всегда сопровождается распространением определенных допущений и посулов, которые могут повлиять на поведение покупателей и привести к принятию неверных решений. На рынке гиперконвергентных интегрированных систем (Hyperconverged Integrated Systems, HCIS) компания Gartner выделяет семь наиболее общих деструктивных предположений такого рода.

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

Миф 1. Во всех реализациях HCIS фигурируют стандартные и открытые архитектуры

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

Миф 2. HCIS проваливают тесты на масштабируемость и устойчивость

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

Миф 3. Стоимость HCIS соответствует максимально экономичной модели развертывания

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

Миф 4. Важнейший сценарий использования HCIS связан с VDI

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

Миф 5. HCIS подразумевают отход от традиционных массивов хранения

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

Миф 6. HCIS не обеспечивают интероперабельности

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

Миф 7. Традиционные предпочтения при выборе вендоров останутся прежними

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

• В какой степени затрагивает вендора новая волна HCIS?
• Всерьез ли он намерен отказаться от обычных решений?
• Есть ли у него проработанный план инноваций?
• Способен ли он оставаться в авангарде в условиях растущей конкуренции, в том числе и с новыми игроками, и постоянно повышать эффективность и экономичность своих решений?

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

- Gartner Reveals Seven Myths for Hyperconverged Integrated Systems. Analysts to Discuss Data Center Trends at the Gartner Data Center, Infrastructure & Operations Management Events