Контакты

«Дорожная карта»: меняем модель взаимодействия бизнеса и ИТ

CNews - 4 октября 2010 - Артак Оганесян, EPAM

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

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

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

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

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

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

Формализация процессов и распределение ролей

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

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

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

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

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

Улучшение коммуникаций между ИТ и бизнесом

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

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

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

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

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

Мониторинг качества и оценка эффективности работы

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

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

Примеры метрик для оценки эффективности работы ИТ-службы

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

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

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

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

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

«Подводные камни» практической реализации

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

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

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

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

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

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

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

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

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

Оригинал публикации