Цифровая трансформация

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

Какие ключевые задачи в области информационной безопасности стоят перед ДИТ и с какими основными проблемами приходится сталкиваться при их решении?

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

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

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

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

Основная организационная задача – доведение информации до наших сотрудников, подрядчиков, инженеров. Последние вирусные эпидемии нас почти не затронули, так как мы знали о них заранее и проводили профилактические мероприятия, информируя органы власти Москвы и пользователей, что нужно делать, а чего, наоборот, стоит избегать. Аналогичная работа идет постоянно, так как подобные угрозы возникают очень часто. Блок ИБ взаимодействует с федеральными структурами – регуляторами отрасли (ФСТЭК, ФСБ и ФСО) и видит все тенденции данной сферы. Более того, мы постоянно сотрудничаем с государственными центрами мониторинга: FinCERT – Центром мониторинга и реагирования на компьютерные атаки в кредитно-финансовой сфере Центробанка, ГосСОПКА – Государственной системой обнаружения, предупреждения и ликвидации последствий компьютерных атак, – потому что нам важно иметь больше источников информации о происходящем в мире в области ИБ.

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

Человеческий фактор – вторая по распространенности причина происшествий в области ИБ после вредоносных программ. Что делает ДИТ для повышения грамотности пользователей с точки зрения кибербезопасности?

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

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

Для самообразования работниками ДИТ используются электронная библиотека, телеграм-канал «ЭруДИТ», база знаний на портале in.mos.ru. Проходят мероприятия по обмену опытом «ДИТ говорит» и кросс-продуктовые проекты. На постоянной основе по корпоративной электронной почте осуществляется информационная рассылка по вопросам обеспечения ИБ – например, о защите от актуального в настоящее время вредоносного ПО.

Как организована защита городских инфоресурсов?

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

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

Какие современные сложные задачи есть в вашей работе?

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

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

Вы к этому готовы?

Мы обязательно будем готовы. Пока этого еще нет, есть только тенденции, и мы их знаем.

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

Да, однозначно. Каждые 30 секунд кто-то пытается проникнуть в городские системы. Хорошо, что в 95% случаев это просто интерес обычных горожан, прочитавших инструкцию об использовании «дырок» в операционных системах. Сейчас несложно стать «бытовым хакером» – в Интернете огромное множество инструментов, которые позволяют это сделать. Но 5% – это серьезные атаки, от них приходится защищаться, в том числе прибегать к внешним компаниям и просить помощи у регулятора.

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

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

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

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

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

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

А есть необходимость раскрывать «зонтик» над теми подрядчиками, где уровень ИБ ниже?

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

Но ведь современные архитектуры устаревают?

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

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

На программу «Информационный город» в 2016 году было потрачено около 40 млрд руб., на ИБ – 500 млн руб. Это обычная пропорция в стоимости защиты и защищаемых объектов. Но в «умном» городе, где речь идет в том числе о физической безопасности жителей, об экологии, разве расходы на ИБ не должны быть выше?

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

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

Что из опыта столицы в области кибербезопасности может быть полезным для защиты корпоративных инфоресурсов?

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

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

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

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

Данных не хватает даже в Mail.Ru

Что такое цифровизация HR? Это не просто ситуация, когда появляется много данных. Самое главное – появляются способы их обработки. Следовательно, меняются процессы и способы принятия решений на основе этих данных.

Ольга Филатова, вице-президент по персоналу Mail.Ru Group: «Методика подбора персонала с помощью искусственного интеллекта уже доказала свою эффективность: в четыре раза снижается стоимость подбора, вдвое – время закрытия вакансии»

«У нас нет отдельного ИТ-департамента, практически все сотрудники так или иначе связаны с ИТ. Было бы странно, если бы мы не экспериментировали с технологиями в области управления персоналом», – говорит Ольга Филатова, вице-президент по персоналу Mail.Ru Group. В компании много математиков, работающих с искусственным интеллектом и обрабатывающих персональные данные. Некоторые клиенты обращаются к этим специалистам и просят сделать продукты для HR – например, прогнозную аналитику по уходу сотрудников, по соответствию сотрудников корпоративной культуре, просчитать вероятность прохождения ими испытательного срока. Все такие модели сначала испытываются «на себе», и это позволяет HR-службе быть на передовой технологий.

Уже зарекомендовала себя методика подбора персонала с помощью искусственного интеллекта, в Mail.Ru ею активно пользуются. Этот подход уже доказал свою эффективность: в четыре раза снижается стоимость подбора, вдвое – время закрытия вакансии.

Тем не менее пока не хватает данных для оценки кандидата без участия рекрутера. Недавно производитель товаров питания и продуктов для дома Unilever объявил о внедрении решения для анализа видеорезюме HireVue применительно к одной из массовых вакансий. Все данные о кандидате анализирует система, рекрутер-человек включается только на стадии финального интервью. В ходе этого проекта показаны неплохие результаты. Российские компании – Skillaz и VisionLabs – пытаются строить аналогичные модели на российском рынке. Технологии отработаны, не хватает лишь данных: нужны данные о сотнях тысяч людей, которые уже успешно прошли собеседование по этой вакансии (и, наоборот, провалили его).

«Уже есть технологии, методы и первые проекты. Но пока качество моделей не слишком хорошее из-за того, что данных либо не хватает, либо они непригодны для анализа. А значит, надо всерьез заниматься сбором данных и следить за их качеством», – считает Филатова.

Цифровой след сотрудника

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

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

Что касается роботизации, то во многом ее актуальность в HR определяется стоимостью ресурсов. Стоимость административного персонала у нас пока несравнима со стоимостью на Западе. Мотивация роботизировать бизнес-процессы усиленными темпами невелика, особенно на фоне огромной организационной трансформации. Тем не менее исследование кадровых процессов, проведенное в НЛМК аналитиками Ernst &Young, выявило участки, уже готовые к роботизации, и даже посчитан экономический эффект. На ближайшие два года руководство компании оставило три направления, в которых будет вестись работа: персональная рассылка извещений о транзакциях; уход от бумаги – обработка отсканированных документов и их индексация; роботизация контакт-центра – автоматическая подготовка как письменных, так и устных ответов.

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

Сервисы вместо HR-специалистов

Вера Соломатина, директор по персоналу SAP CНГ: «Мы фокусируемся на упрощении HR-организации, и одним из столпов является стандартизация процессов»

«Мы фокусируемся на упрощении HR-организации, и одним из столпов является стандартизация процессов», – говорит Вера Соломатина, директор по персоналу SAP CНГ. До того как руководство затеяло трансформацию кадровой функции, в каждом представительстве компании были внедрены свои решения, и локальный HR-отдел занимался и подбором, и развитием персонала, и кадровым делопроизводством.

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

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

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

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

Приложение Resume Matching позволяет, введя в систему неформализованное описание вакансии, найти в базе резюме наиболее подходящих кандидатов; Job Standardization дает возможность ввести в систему описание вакансии и после этого категоризировать ее, то есть определить, что это на самом деле уже существующая вакансия с определенным названием, должностной инструкцией, зарплатой и правилами найма; Employee Flight Risk Prediction прогнозирует риск оттока наиболее ценных сотрудников; Conversational AI Platform является основой для чатботов и прочих автоматизированных помощников по всем линиям бизнеса; Bias Language Checker приводит вакансии к нейтральному виду, чтобы удалить из их описания параметры, которые могут быть отнесены к дискриминации по какому-либо признаку. Последнее из перечисленных приложений для России пока неактуально, но есть страны, где оно активно используется.

Борьба за таланты

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

«Все активнее идет борьба за таланты. Если раньше мы думали, к кому из конкурентов уйдут сотрудники – Microsoft, SAP или Oracle, то теперь новыми работодателями вполне могут стать, например, Сбербанк или любая крупная производственная компания», – признает Ксения Шумакова, директор по работе с персоналом IBM в России и СНГ. Кросс-индустриальность обострила ситуацию. Приходится держать ухо востро и искать те конкурентные преимущества, которые позволяют работодателю быть интересным сотрудникам.

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

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

В IBM выделяют «пять П» – направлений для создания «лучшего опыта» сотрудника.

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

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

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

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

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

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

«Маленькие удобства» для сотрудников

Полина Хабарова, HR-директор «Крок»: «Самые интересные примеры цифровизации HR в последнее время связаны с роботизацией функций – например, использование чат-ботов»

По мнению Полины Хабаровой, HR-директора компании «Крок», HR-департамент должен сам влиять на процессы цифровой трансформации. И внутри компании, и вовне можно подметить тенденции, которые влияют на развитие функции HR и процессы цифровизации в целом.

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

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

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

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

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

***

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

Выступление Антона Исанина, руководителя центра качества «Альфа-Банка», набрало максимальное число позитивных отзывов участников конференции «Agile, DevOps и ITIL – инструменты цифровизации», проведенной издательством «Открытые системы». Сокращение вывода новых продуктов на рынок до пяти дней с помощью подходов DevOps – результат, заслуживающий уважения.

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

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

Успеть за возможностями

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

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

Антон Исанин, руководитель центра качества «Альфа-Банка»: «DevOps позволяет быть ближе к клиенту, а если мы понимаем клиента, то понимаем, как заработать деньги, и это уже половина успеха. Вторая половина успеха – максимально быстро удовлетворить эти потребности»

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

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

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

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

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

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

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

«Мы минимизируем путь к удовлетворению клиента, меняемся быстро – за дни. В случае agile-команд время создания продукта сокращается до 20 дней. Подход DevOps сокращает цикл разработки до 5 дней», – подчеркивает Исанин. Когда все необходимые действия зависят от единой команды, заинтересованной в результате, удается избежать потери времени на самых разных этапах проекта.

Необходимо создать цельные независимые продуктовые команды с полноценным сопровождением. Это важный вопрос: DevOps подразумевает не только совместную работу различных администраторов в agile-командах; вместе со специалистом в команду «переезжает» и ответственность, а за стабильность продукта отвечает его владелец. Кроме того, в команду уходят второй и третий уровни поддержки.

Мельче, но быстрее

«Чтобы быстро выпустить продукт на рынок, задачу надо раздробить. Есть простая связь: чем лучше удается дробить ценность, доставляемую клиенту, тем ощутимее эффект. И чем мельче получаются кусочки, тем лучше работает автоматизация», – уверен Исанин. DevOps превращается в непрерывный поток маленьких кусочков продуктов, которые едут по автоматическому конвейеру.

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

В «Альфа-Банке» автоматизация процессов разработки была начата с процессов тестирования.

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

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

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

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

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

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

1. Переход в облако при отсутствии стратегии руководства и планирования

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

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

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

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

2. Вера в то, что в облако можно перенести любые системы

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

Определитесь, чего вы хотите добиться переносом тех или иных систем в облако, и оцените, реально ли это.

3. Отношение к облаку как к своему центру обработки данных

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

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

4. Уверенность в том, что весь груз ответственности лежит на провайдере

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

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

5. Уверенность, что любые приложения можно перенести в облако без изменений

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

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

6. Отказ от мониторинга производительности сервисов

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

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

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

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

Незнание особенностей облака может легко привести к катастрофе с точки зрения безопасности.

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

8. Слепое доверие скриптам автоматизации

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

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

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

9. Вера в то, что безопасность – больше не ваша проблема

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

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

10. Пренебрежение планированием обеспечения непрерывности бизнеса и аварийного восстановления

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

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

***

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

– John Edwards. 10 cloud mistakes that can sink your business. CIO. NOV 14, 2017

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

Значительному числу организаций не удается провести преобразования правильно из-за фундаментального непонимания того, что на самом деле представляет собой цифровая трансформация.

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

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

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

1. Цифровая трансформация – это на самом деле трансформация человека

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

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

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

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

Этот сдвиг мышления помог компании совершить рывок вперед. «За прошедшие 10 лет мы сделали 80 приобретений, смогли укрепить связи, сформировать новые взаимоотношения и добиться того, чтобы сотрудники получше узнали друг друга», – отметил Фейруэзер.

2. Придерживайтесь ориентированного на клиентов подхода

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

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

Прежде всего они ориентируются на клиентское восприятие.

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

3. Формируйте новые команды

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

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

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

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

Аналогичного подхода придерживаются и в компании – поставщике сельскохозяйственного оборудования John Deere, где руководство составило план реализации перспективного проекта умного подключенного предприятия. На одной из фабрик компании было организовано пространство Foundry площадью 650 квадратных метров с более низкими, чем обычно, столами, с тем чтобы людям удобнее было общаться. Там предполагалось собирать новые команды и изучать agile-методологии при содействии экспертов, которые проводили бы сотрудников через полный цикл разработки.

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

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

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

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

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

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

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

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

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

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

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

«Конечно, у нас были скептики, – заметила вице-президент GE Commercial и подключенной цифровой экосистемы digitalTHREAD Кейт Гутовски. – Но, если мы нацелились провести какие-то преобразования, равняться на таких людей не стоит».

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

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

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

6. Вырабатывайте менталитет стартапа

В 2014 году к купленному AT&T оператору добавилась вновь приобретенная компания Cricket Wireless. Две конкурировавшие друг с другом организации требовалось преобразовать в единого крупного игрока национального масштаба.

Подобно John Deere и CarMax, Cricket Wireless взяла на вооружение модель Agile. Все силы были приложены к тому, чтобы действовать быстро и добросовестно.

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

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

7. Добивайтесь от руководства дополнительных полномочий

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

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

После этого Джаярам пошел к руководству и представил план интеллектуального подключения и agile-методологии.

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

– Esther Shein. 7 habits of highly effective digital transformations. CIO. November 6, 2017

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

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

Что представляет собой DevOps?

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

Путь к DevOps

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

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

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

1. Подготовка к культурным переменам

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

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

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

2. Формирование процесса непрерывной интеграции, платформы непрерывного предоставления

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

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

Вот как это работает:

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

3. Создание среды непрерывного тестирования

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

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

К непрерывному тестированию применимы следующие рекомендации:

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

4. Внедрение системы непрерывного развертывания

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

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

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

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

5. Использование нового и старого развертывания

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

6. Непрерывный мониторинг производительности

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

1. Циклы разработки. Чтобы иметь представление о функционировании конвейера автоматического развертывания, следите за тем, как часто в код вносятся изменения, сколько новых функций реализовано, какое количество ошибок обнаружено и исправлено и т. д.
2. Развертывание. Если процедура автоматического развертывания завершается неудачей, нужен инструмент, который предупредит об этом соответствующих специалистов. Большинство серверов непрерывной интеграции автоматически пересылают сообщения на серверы чатов в случае сбоя процедур развертывания или сборки.
3. Уязвимости. После передачи кода в производство управление уязвимостями следует осуществлять автоматически. Неважно, идет ли речь об известных уязвимостях (присутствующих в National Vulnerability Database) или неизвестных (возникших в результате небезопасных действий), в любом случае система обязана их обнаруживать и минимизировать последствия.
4. Состояние серверов. Мониторинг серверов имеет важное значение практически для любого типа инфраструктуры, не только при использовании DevOps. Производительность и соглашения об уровне обслуживания (service-level agreements, SLA) системы зависят от состояния сервера. Есть несколько инструментов, помогающих решать эту задачу. Следует также осуществлять мониторинг инфраструктуры.
5. Производительность приложений. Для определения ключевых моментов производительности и регресса приложений необходимо следить за их функционированием и своевременно принимать необходимые решения. Поможет вам в этом целый ряд инструментов, в том числе AppDynamics и New Relic. Инструменты мониторинга производительности приложений (application performance monitoring, APM) предоставляют дополнительную информацию о характере использования приложений и их производительности.

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

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

Ключевые инструменты DevOps

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

• репозиторий исходного кода (Git, CloudForce, TFS, Subversion);
• сервер сборки (SonarQube, Jenkins, Artifactory);
• управление конфигурацией (Puppet, Ansible, Salt, Chef);
• автоматизация тестирования (Selenium, Water);
• виртуальная инфраструктура (Amazon Web Services, Microsoft Azure, VMware vCloud).

***

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

– Adam Bertram. 6 steps to devops success. CIO. OCT 18, 2017

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

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

Зачем «Росэнергоатому» понадобились изменения?

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

Сергей Мигалин Послужной список: 2015 – настоящее время  Заместитель генерального директора, директор по экономике и финансам АО «Концерн “Росэнергоатом”» 2014 – 2015 Финансовый директор ОАО «Атомредметзолото» 2013 Первый заместитель генерального директора ФГУП «Федеральный центр ядерной и радиационной безопасности» 2008 – 2013 Работа в ТВЭЛ, должности от заместителя главного бухгалтера до вице-президента по экономике и финансам Образование: 1994 – Московский государственный технический университет им. Н.Э. Баумана, специальность «радиоэлектронные устройства и системы» 2001 – Финансовая академия при Правительстве Российской Федерации, специальность «бухгалтерский учет и аудит» Фото: «Росэнергоатом»

Почему вы говорите именно о цифровой трансформации, что подразумеваете под ней?

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

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

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

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

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

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

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

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

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

«В “Росэнергоатоме” простой только одного крупного энергоблока последнего поколения обходится более чем в 1 млн долл. в сутки. Цена вопроса – критическая»

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

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

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

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

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

В чем роль SAP? Это просто платформа или нечто большее?

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

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

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

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

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

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

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

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

Сергей Мигалин, заместитель генерального директора, директор по экономике и финансам АО «Концерн “Росэнергоатом”»: «Культурная трансформация коллектива, его взглядов на то, что такое электронное управление бизнесом, зачем это надо и что в результате будет получено, – самая большая сложность» Фото: «Росэнергоатом»

Что оказалось самым сложным?

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

Чего проект уже позволил добиться и какие эффекты ожидаются в будущем?

Многие, внедряя ERP, говорят вполне понятные и очевидные вещи – например, касающиеся сокращения запасов и повышения их оборачиваемости. У нас это тоже было так.

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

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

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

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

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

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

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

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

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

Вы смирились с тем, что пока не получается?

Разумеется, мы планируем все доделать на следующих этапах. Чтобы не остановиться на уровне ERP, а довести нашу историю до уровня Индустрии 4.0, надо трансформироваться, обучать людей, вовлекать их в проект, а при необходимости – менять.

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

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

В каком направлении будет развиваться проект?

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

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

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

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

Голосовая биометрия на сегодняшний день самая спорная и сложная биометрическая технология. Она также исследуется в «Почта Банке» в рамках пилотных проектов для автоматического обслуживания клиентов.

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

«Распознавание лиц – хороший мотор, но сам по себе он никуда не поедет, – подчеркивает Гурин. – Ему нужно шасси для приложения своих усилий и “топливо”, которое будет подаваться на вход. Важно понимать, где эта технология применима, и уметь встроить ее в операционные процессы». Систему распознавания лиц начали внедрять еще во времена «Лето Банка», после вхождения которого в структуры «Почты России» проект стал самым большим среди подобных в мире.

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

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

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

Дисциплинирующий эффект

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

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

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

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

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

«На пилотном этапе, в первое время после запуска процедуры распознавания, было очень много случаев, когда обнаруживались похожие лица у разных клиентов, – говорит Гурин. – Когда банк официально объявил о наличии системы биометрической идентификации, инцидентов стало намного меньше, и сейчас можно сказать, что число пойманных за руку людей относительно невелико». За 2016 год система обнаружила 4,5 тыс. повторно используемых фотографий, и выдача по ним новых кредитов не была допущена. Было отловлено 9,2 тыс. явно мошеннических заявок, когда за кредитом приходил неизвестный банку человек и предъявлял паспорт, уже имевшийся в банковской базе. Предотвращено сомнительных операций на общую сумму 1,5 млрд руб. Хотя справедливости ради следует отметить, что наверняка не все из них в итоге закончились бы потерей денег.

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

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

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

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

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

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

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

Куда уходит время?

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

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

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

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

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

«Если вас недопоняли — значит, вы плохо объясняли», — говорит Иншаков. Пожалуй, наиболее известной и эффективной методикой постановки целей является S.M.A.R.T. Она подразумевает, что цели должны быть конкретными (Specific), измеримыми (Measurable), достижимыми (Achivable), реалистичными (Realistiс) и определенными во времени (Timebound).

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

Коварная почта

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

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

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

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

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

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

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

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

Задачи и слоны

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

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

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

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

В своей книге «Тайм-драйв. Как успевать жить и работать» (Издательство «Манн, Иванов и Фербер», 2005) гуру тайм-менеджмента Глеб Архангельский сравнивает реализацию сложной задачи с поеданием слона. Слон велик, и если вы захотите его съесть сразу, у вас ничего не получится. Слона нужно есть по кусочкам, то есть проект следует разбить на маленькие этапы и каждый день реализовывать хотя бы по одному из них.

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

Совещание или митинг?

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

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

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

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

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

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

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

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

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

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

Культура календарей

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

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

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

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

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

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

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

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

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

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

В этой статье мы коротко обрисуем наиболее популярные методологии управления проектами (project management methodologies, PMM) и покажем, как оценить, какая из них лучше подходит для вашего проекта и организации. Разработанный один раз процесс оценки и выбора правильной методологии управления проектами можно задокументировать и затем применять его много раз, экономя тем самым время на структуризацию проектов и управление ими. Освободившиеся же ресурсы имеет смысл ориентировать на успешную реализацию самого проекта.

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

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

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

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

Метод критического пути. Метод критического пути (critical path method, CPM) – это пошаговая методология, используемая при реализации взаимозависимых проектов. Составляется перечень работ, определяются структура их декомпозиции, временная шкала, зависимости, реперные точки и результаты. Критические и некритические работы выделяются путем расчета наибольшего (на критическом пути) и наименьшего (плавающего) времени выполнения различных задач. После этого определяется, какие задачи являются критическими, а какие – нет.

Метод критической цепи. Метод критической цепи (critical chain project management, CCPM) отличается от метода критического пути тем, что он ориентирован на использование ресурсов проекта, а не проектных работ. Для решения потенциальных проблем с ресурсами формируются буферы, гарантирующие своевременную реализацию проектов с соблюдением всех необходимых мер безопасности.

Шесть сигм (six sigma). Концепция «шесть сигм» была разработана компанией Motorola для исключения лишних потерь, улучшения процессов и повышения прибыли. Методология, построенная на основе анализа данных, включает три ключевых компонента: DMAIC (define, measure, analyze, improve and control) – определение, измерение, анализ, улучшение и контроль; DMADV (define, measure, analyze, design and verify) – определение, измерение, анализ, проектирование и проверка; DFSS (Design for Six Sigma) – проектирование для шести сигм. DFSS может включать как предыдущие, так и другие варианты: например, IDOV (identify, design, optimize and verify) – идентификация, проектирование, оптимизация и проверка. Концепцию шести сигм иногда называют методологией.

Scrum. Термин scrum – «схватка» – пришел из регби, где он означает коллективную боевую стойку игроков над мячом. Методология реализации agile-разработки предполагает использование интерактивного подхода. «Скрам-сессии», или «30-дневные спринты», используются для определения приоритетных задач. Роль менеджера проекта для упрощения передается скрам-мастеру. Для независимого решения конкретных задач формируются небольшие команды. В ходе встреч со скрам-мастером оцениваются достигнутые результаты, после чего определяется приоритетность невыполненных задач.

Другие методологии управления проектами.

Помимо перечисленных, существуют и другие методологии управления проектами: методология цепочки событий (event chain methodology, ECM), Crystal, функционально-ориентированная разработка (feature driven development, FDD), разработка динамических систем (dynamic systems development, DSDM), адаптивная разработка программного обеспечения, Rational Unified Process (RUP), бережливая разработка (lean development, LD), Prince2 и пр.

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

Как эффективно оценить методологии управления проектами

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

Организация Project Management Institute (PMI) разработала всемирно признанный стандарт Organizational Project Management Maturity Model (OPM3) – модель зрелости организационного управления проектами. Он помогает организациям выявлять, измерять и улучшать свои возможности в части управления проектами и стандартизации процессов, способствует закреплению результатов успешных проектов, определению наилучших практик и усилению связей между стратегическим планированием и исполнением. OPM3 ориентирован на стратегическую эффективность организации в целом и описывает управление проектами, программами и портфелями.

В опубликованном PMI документе «Implementing Organizational Project Management: A Practice Guide» («Реализация организационного управления проектами: практическое руководство») описываются высокоуровневые процессы адаптации методологий управления проектами. Перед тем как выбрать методологии, подходящие для того или иного проекта, следует внимательно изучить этот документ и использовать в дальнейшем содержащиеся в нем сведения.

Преимущества организационного управления проектами

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

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

Ключевые моменты при выборе методологии управления проектами

При оценке методологий следует обратить внимание на следующие моменты:

• стратегические цели и базовые ценности организации;

• ключевые бизнес-факторы;

• ограничения;

• заинтересованные лица;

• риски;

• сложность;

• масштаб и стоимость проекта;

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

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

1) определение движущих сил проекта путем выявления и ранжирования основных его целей и приоритетов;

2) после определения движущих сил проекта, требований и целей – описание условий, влияющих на методологию;

3) выявление всех доступных/возможных методологий, которые в наибольшей степени подходят для проекта;

4) сравнение методологий применительно к конкретному проекту;

5) определение методологии, сулящей наилучшие результаты и наименьший риск;

6) налаживание обратной связи;

7) документирование и обоснование методологии;

8) реализация методологии;

9) мониторинг и внесение изменений по мере необходимости.

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

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

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

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

− Moira Alexander. How to pick the best project management methodology for success. CIO. JUL 20, 2017