Мэри Пратт

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

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

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

Что такое NoOps?

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

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

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

NoOps не является и платформой, которую можно купить.

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

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

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

Эволюция NoOps

В своем докладе Tech Trends 2019 аналитики Deloitte отнесли NoOps к «бессерверному миру». На следующем этапе эволюции облачных вычислений ключевые задачи будут автоматизированы, что позволит ИТ-специалистам сосредоточиться не на операциях, а на конечных результатах.

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

Да, идея NoOps не нова, как и споры о том, является ли это достижимым состоянием, громким призывом или несбыточной мечтой. Публичные споры об этом понятии между руководителями технических направлений Etsy и Netflix разгорелись еще в 2012 году.

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

ИТ-службы отреагировали на это переходом на новые технологии (например, облачные вычисления) и внедрением новых методологий (Agile и DevOps).

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

Континуум NoOps

Глава Deloitte Consulting и технический директор облачного направления компании Кен Корлесс называет NoOps «вершиной горы DevOps».

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

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

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

Однако эксперты предупреждают, что ИТ-службы пока далеки от создания истинной среды NoOps.

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

Неприятие концепции

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

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

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

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

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

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

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

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

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

Рене Хед также признает ограниченный характер NoOps.

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

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

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

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

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

С представителями бизнеса на борту

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

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

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

Проблемы формирования культуры agile

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

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

Но вовлечение бизнес-подразделений в процесс agile-разработки сопряжено и с определенными трудностями.

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

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

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

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

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

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

Продвижение концепции agile. Преимущества и ограничения

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

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

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

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

«Я не говорю, что все мы станем гибкими и будем счастливы, не использую терминологию agile, — признался Гуле. — Я просто говорю, что надо сделать конкретно то-то и то-то, и объясняю, какие выгоды это принесет».

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

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

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

Баланс между ИТ-службой и бизнес-подразделениями

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

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

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

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

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

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

«Я стараюсь донести до всех, что более активное участие в процессе увеличивает шансы получить правильное решение уже с первой попытки», — подчеркнул Тонер.

— Mary K. Pratt. Moving agile beyond IT: The secret to successful software delivery. Contributing Writer, CIO. AUG 21, 2018

Бизнес-аналитика (Business Intelligence, BI) важна для роста и приобретения конкурентных преимуществ, но, чтобы пользоваться возможностями BI, недостаточно только внедрить соответствующие технологии.

В сущности, такое внедрение – самая простая часть любой инициативы BI, уверен Борис Эвельсон, главный аналитик Forrester Research. Гораздо более сложными являются этапы, связанные с подготовкой персонала и процессов.

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

Эксперты перечисляют семь основных элементов успешной стратегии в области BI.

1. Сделайте бизнес владельцем BI

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

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

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

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

2. Следите за использованием BI и вносите корректировки по необходимости

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

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

3. Проверяйте и еще раз проверяйте

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

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

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

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

4. Фокусируйтесь сначала на бизнес-задачах, затем – на данных

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

Более оптимальным будет подход «сверху вниз», ориентированный на бизнес-результаты: начинать надо не с данных, а с решения бизнес-задачи.

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

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

5. Назначайте приоритеты и реализуйте процессы совершенствования

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

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

6. Расширяйте навыки «гражданских» исследователей данных

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

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

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

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

7. Обучайте персонал «рассказывать истории» с помощью данных

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

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

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

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

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

– Mary K. Pratt. 7 keys to a successful business intelligence strategy. CIO Magazine. Sep. 26, 2017

Продолжает ли еще существовать такое понятие, как провал ИТ-проекта, в эпоху Agile-разработки, DevOps и новых методов управления? Увы, да.

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

Но сегодня провалы ИТ-инициатив отличаются от провалов прежних времен, так как Agile-методы, DevOps, непрерывная доставка и принцип мгновенной регистрации сбоя (fail-fast) изменили способы осуществления проектов. Современные итеративные методики управления призваны свести к минимуму шансы масштабных провалов, однако провалы по-прежнему происходят, причем по-новому и иногда даже с еще более неприятными последствиями.

Вот что думают эксперты о современном положении дел с провалами ИТ-инициатив.

История-предостережение

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

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

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

Этот провал – далеко не единственный. Согласно отчету Project Management Institute от 2017 года, подготовленному по результатам опроса 3 тыс. специалистов по управлению проектами, 28% стратегических инициатив, которыми они руководили, оказались абсолютно провальными. Примерно 37% опрошенных причинами провала назвали отсутствие четко определенных и достижимых вех и задач, используемых в качестве оценки степени завершения проекта. Далее в ряду причин шли нехватка информационного обмена (19%), отсутствие откликов от высшего руководства (18%), сопротивление сотрудников (14%) и недостаточное финансирование (9%).

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

Факторы, ведущие к провалу

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

В рамках исследования Global Digital IQ Survey, проведенного компанией PwC в 2017 году, были опрошены более 2 тыс. бизнес- и ИТ-руководителей, вопросы касались факторов, сдерживающих цифровую трансформацию. Около 64% опрошенных указали на отсутствие взаимодействия между службой ИТ и бизнесом, 58% – на негибкость и медлительность процессов, 41% – на отсутствие интеграции между новыми и существующими технологиями, 38% – на устаревшие технологии, а 37% – на недостаточную квалификацию проектных команд.

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

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

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

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

Спасение – в Agile и автоматизации?

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

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

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

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

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

Польза от неудач

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

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

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

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

Риск провала сохраняется

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

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

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

Как подчеркивают в PwC, в последнее время затраты бизнес-подразделений на ИТ растут быстрее, чем в самих отделах ИТ. Согласно исследованию PwC Global Digital IQ за 2015 год, 68% расходов на ИТ поступают не из бюджета ИТ-служб.

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

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

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

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

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

– Mary K. Pratt. Why IT projects still fail. CIO. August 1, 2017