Аудит и консалтинг Развитие бизнес-систем
 |  Вторник, 30 апреля
Новости
Компания
Консалтинг
Право
Информационные технологии
Аудит
 

CNews.ru// "Дорожная карта": меняем модель взаимодействия бизнеса и ИТ

 
Дата: 06/10/2010
Версия для печати

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


29/06/2021
РБС аккредитовано Министерством юстиции Российской Федерации в качестве независимого эксперта
еще новости
Дата: 29/02/2016
Источник:
еще публикации
Фиксированные цены не изменяются в ходе исполнения контракта, либо изменяются только в оговоренных контрактом случаях. Применяются по контрактам, уровень обоснованных издержек по которым достаточно точно предсказуем, поставляемые услуги имеют в основном традиционный характер. Фиксированная цена включает планируемые издержки и планируемую прибыль. Норма прибыли по контракту согласуется заказчиком и поставщиком.
Автор: Кочковой О. В.
Источник: Финансового Директор No 5 (май) 2007
еще публикации
<  Апрель 2024 >
ПнВтСрЧтПтСбВс
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
 


w w w . r b s y s . r u
Новости  |  Компания  |  Услуги  |  Клиенты  |  Пресс-центр    Карьера
Акционерное общество «Аудиторско-консультационная группа «Развитие бизнес-систем».
Телефон: +7 495 967 6838 / e-mail:
© АО "АКГ "РБС". Все права защищены, 2001-2022.