1. Направления ИТ-аутсорсинга
Классифицировать основные направления ИТ-аутсорсингаможно по степени полноты процессов, передаваемых на исполнение другой компании.
Аутсорсинг отдельных ИТ-систем - классический вид аутсорсинга ИТ-услуг. В этом случае все работы по внедрению и поддержке отдельных систем (ERP, CRM и др.) выполняются внешним подрядчиком. При этом ИТ-услуги, относящиеся к другим системам, осуществляются собственными силами ИТ-подразделения компании. Этот вид аутсорсинга применяется в большинстве крупных и средних компаний, использующих типовое ПО корпоративного уровня (системы ERP, CRM, системы документооборота). В случае хорошо развитого ИТ-отдела данный вариант может являться переходным ко второму.
üЧастичный аутсорсинг ИТ-систем
Данный вариант напоминает предыдущий, но на аутсорсинг передаются не все ИТ-процессы, связанные с информационной системой, а только некоторые из них. Например, внедрение системы производится силами внешнего подрядчика, а ее сопровождение - собственными силами. Другой пример: поддержка системы осуществляется собственными силами, а ее развитие - силами внешнего подрядчика. Этот вариант применяется, если имеется хорошо развитый ИТ-отдел, выполняющий поддержку ПО собственной разработки и берущий на себя функции по поддержке покупных систем.
üАутсорсинг аппаратного обеспечения
Используется аппаратное обеспечение внешнего подрядчика и осуществляется аутсорсинг процесса поддержки этого оборудования. Этот вид аутсорсинга пока слабо распространен в России. Применяется, в частности, в некоторых компаниях, основанных западным капиталом.
üАутсорсинг отдельных процессов в рамках всей ИТ-инфраструктуры
От предыдущего вида отличается тем, что внешние подрядчики выполняют полный цикл отдельных процессов для всей ИТ-инфраструктуры компании. Например, "Сетевая печать", "Доступ в Интернет", "Средства коллективной работы". Применяется в некоторых малых и средних компаниях, где ИТ-стратегия не предусматривает расширения ИТ-отдела и фактор безопасности не является ключевым.
üПолный аутсорсинг (нет собственных ИТ-специалистов в компании)
Максимально полный вариант предыдущего типа: собственного ИТ-отдела в компании нет, и все ИТ-функции выполняются внешними подрядчиками. Применяется в средних и небольших компаниях, где фактор безопасности не является ключевым.
-
Процедура проведения тендера на внедрение ИС
Процесс проведения тендера состоит из нескольких основных этапов:
6. Оформление результатов;
7. Заключение соглашения с победителем тендера.
1. Инициация проекта
Проект по проведению тендера начинается с определения и обоснования потребностей в новой информационной системе (системах) и определения рамок проекта. На предварительном этапе инициации проекта решаются организационные задачи назначения руководящей тендерной комиссии, участники которого должны будут управлять процессом проведения тендера; происходит мобилизация команды, производящей выбор победителя тендера; подготавливается и утверждается поэтапный план работ по проекту с разбивкой на сроки; готовится регламент проведения тендера.
2. Формирование «длинного списка» поставщиков (long list)
На этапе формирования «длинного списка» поставщиков рассматривается максимально широкий список решений, представленных на рынке. Предварительный отбор систем производится при минимизации затрат на получение дополнительной информации о решении. Т.е. при составлении «длинного списка» используют открытые источники информации, а также личный опыт участников проектной команды и рекомендации коллег, пользующихся доверием. Как правило, это веб-сайты вендоров, содержащие описание основных характеристик систем; обзоры в профессиональной прессе, презентации и демонстрационные ролики, руководства пользователей и т.д. Отбраковка решений из полного списка происходит на основании небольшого числа критичных критериев. Соответствие этим обязательным требованиям является основанием для внесения системы в «длинный список». При оформлении результатов этапа (самого Long List) полезно указывать не только системы, вошедшие в «длинный список», но и все рассматриваемые системы. Например, можно вынести перечень отбракованных решений в отдельный раздел документа. Важно не только перечислить их, но и указать причину исключения системы из рассмотрения — это позволяет вынести обоснованное решение и предупредит возможные вопросы со стороны руководства.
3. Формирование «короткого списка» поставщиков (short list)
Формирование «короткого списка» поставщиков производится из «длинного списка» на основании расширенного состава критериев выбора решения. На данном этапе требования к решению уточняются и систематизируются. Рекомендуется отдельно рассматривать требования к системе, поставщику и проекту.
Требования к системе подразделяют на:
ü Функциональные — перечень функций, которые должна поддерживать система;
ü Нефункциональные — требования к быстродействию, надежности, эксплуатации и обслуживанию системы, к эргономике, защите информации и т.д.;
Требования к поставщику подразделяют на две группы:
ü Общие показатели деятельности — например, требования к численности персонала компании-поставщика решения; время нахождения на рынке, финансовые показатели деятельности компании за отчетный период, отсутствие задолженности перед налоговыми органами;
ü Прочие требования — например, наличие сертифицированных специалистов, заключенные партнерские договора с вендорами, возможность предоставления определенного уровня поддержки, подход к ценообразованию.
Требования к проекту могут быть следующими:
ü Принципы организации проекта и управления проектом;
ü Требования к ресурсам, выделяемым на проект;
ü Сроки начала и завершения отдельных этапов проекта и проекта в целом;
ü Зависимость от критичных для бизнеса дат (дата сдачи отчетности);
ü Зависимость от других проектов;
После того, как требования к решению определены, следует разработать методику формирования «короткого списка» из «длинного» и отбраковать системы, не соответствующие требованиям в соответствии с разработанной методикой. В качестве примера возможных методик сравнения можно привести следующие:
ü Попарное сравнение систем;
ü Балльная оценка систем в с учетом веса каждого критерия выбора системы;
ü Приведенная стоимостная оценка решений, включающая финансовую оценку рисков;
ü Качественное сравнение решений на основе анализа реализации ключевых сценариев (key use cases);
ü TCO (Total Cost of Ownership);
Решения, не вошедшие в «короткий список», следует так же, как и на предыдущем этапе формирования «длинного списка», вынести в отдельный раздел, указав причину их «отбраковки».
4. Рассылка и обработка запросов на предоставление предложений
После того, как все требования к решению сформулированы и состав «короткого списка» определен, потенциальным участникам тендера (поставщикам, перечисленным в short list), высылается запрос на предоставление предложения. Разрабатывать его обычно начинают в самом начале проекта, а при получении из длинного списка короткого списка поставщиков, он может быть расширен дополнительной информацией.
Запрос может состоять из следующих основных блоков:
ü Выдержки из Регламента проведения тендера (основные сроки, правила и процедуры, контактные данные заказчика);
ü Требования к информации в предложении могут включать:
ü Правила заполнения предложения, которые указываются для удобства обработке предложений. Ответы потенциальных участников тендера должны описываться в единой форме для того, чтобы при обработки предложений построить единую таблицу сравнения ответов поставщиков;
ü Требования к участнику — требования, которым должен соответствовать поставщик решения, свидетельствующие о его «успешности», надежности, соответствии проекту;
ü Требования к системе — функциональные, нефункциональные требования, требования к информации о сроках, стоимости решения, истории и опыта ее внедрения;
ü Требования к прочим услугам, оказываемым в ходе проекта: требования к составу работ по проекту (внедрение системы, обучение сотрудников работе с системой, сопровождение).
5. Получение дополнительной информации в ходе презентаций, референс-визитов, консультаций
В ответ на запрос, поставщики высылают свои предложения, таким образом, становясь участниками тендера, и фактически с этого момента начинается собственно проведение тендера. Присланные предложения тщательно анализируются и после приведения их к единообразной форме сопоставляются, ответы поставщиков уточняются. Иногда после обработки предложений «короткий список» поставщиков удается сократить до 2–3 решений. Для оставшихся решений организуются презентации и тестовые демонстрации на территории поставщика или заказчика.
Целей у демонстраций и референс-визитов несколько:
ü Наглядно подтвердить свойства решений, которые заявлены в тендерных предложениях;
ü Подтвердить опыт конкретных проектов, также указанный в тендерных предложениях;
ü Продемонстрировать свойства решений, которые не могут быть оценены на основе предложений (например, юзабилити);
ü Оценить способность команды участника тендера к взаимодействию с заказчиком;
ü Оценить экспертизу команды участника тендера.
Для эффективного проведения презентаций рекомендуется разработать и предоставить участникам тендера единый план или несколько сценариев. Это позволит, во-первых, заставить их показывать то, что действительно интересно компании (а не только сильные стороны системы и поставщика), и, во-вторых, упростит сравнение результатов презентаций различных участников тендера.
6. Оформление результатов
После уточнения всех важных свойств решения, проведения сравнительного анализа систем и выбора победителя оформляется отчет о результатах тендера. В отчете могут быть отражены следующие виды анализа систем:
ü Качественная оценка решений предполагает сравнение систем с точки зрения их функциональности. По сути, качественная оценка является отчетом о проведенных демонстрациях систем;
ü Анализ рисков, сопряженных с выбором каждого решения. При оценке рисков должны учитываться вероятность наступления рисковой ситуации и стоимость расходов при наступлении или предупреждении риска;
ü Финансовая оценка всех затрат, связанных с выбором каждого решения. В качестве одного из подходов можно предложить включать в финансовую оценку наряду с TCO оценку рисков, связанных с выбором конкретного решения.
При принятии решения важно соблюсти принцип коллегиальности и участия всех заинтересованных лиц, иначе могут возникнуть как политические, так и организационные препятствия — причем уже при внедрении системы.
Если окончательный выбор сделать не удается, то следует задаться вопросом: «Какая дополнительная информация позволит склонить чашу весов в ту или иную сторону?» После этого участникам направляются дополнительные запросы и проводятся новые встречи.
В отчете о результатах тендера должно даваться краткое заключение по каждой из рассматриваемых систем. Рекомендуется определять не только единоличного победителя тендера, но и второго «финалиста» — на тот случай, если по каким-либо причинам не удастся заключить договор поставки с победителем.
7. Заключение соглашения с победителем тендера
После того, как победитель определен, с ним заключат соглашение на поставку информационной системы. Предварительно может быть подписан договор о неразглашении. После согласования с поставщиком всех условий поставки договор подписывается, что является точкой в процессе проведения тендера и началом проекта внедрения новой системы. Материалы, использованные в процессе проведения тендера, могут стать хорошей основой для написания технического задания на доработку системы.
Вне зависимости от того, будет ли компания обращаться к помощи консультантов или примет решение все работы проводить самостоятельно, принципы проведения тендера едины:
ü Организация тендера как самостоятельного проекта со своими целями, ресурсами, сроками;
ü Выделение ключевых требований бизнеса как критериев для выбора;
ü Поэтапное уточнение критериев — от «длинного списка» до окончательного выбора победителя;
ü Поэтапное сокращение числа и детализация описания сравниваемых решений.
-
Состояние рынка ИТ-аутсорсинга
Глобальный финансовый кризис выводит тему ИТ-аутсорсинга на повестку дня руководителей предприятий, стремящихся активно и гибко противодействовать негативным явлениям. Согласно исследованиям, 43% крупнейших европейских и североамериканских компаний уже сократили свои ИТ-бюджеты. Большинство из них считают аутсорсинг инструментом для уменьшения ИТ-издержек: так, увеличить долю аутсорсинга приложений планируют 45%, долю аутсорсинга инфраструктуры - 43%, долю технического консалтинга - 38%. Среди ИТ-процессов, которые российские компании намереваются передать на аутсорсинг в течение этого года выделяются услуги дата-центра (10%), управление рабочими станциями (10%), поддержка пользователей и приложений, а также ИТ-консалтинг (по 8%).
Сегодня на первый план среди преимуществ ИТ-аутсорсинга выходит возможность получения компанией большей гибкости в управлении и обслуживании своей ИТ-инфраструктуры. Неоспоримым в текущей ситуации преимуществом аутсорсинга является также возможность оперативного наращивания или сокращения услуг. То, что может быстро обеспечить грамотный подрядчик, не дадут ни набор или сокращение персонала, ни увеличение или уменьшение расходов.
В последние годы внутренние затраты на ИТ российских предприятий и организаций росли существенно (почти в два раза) быстрее, чем внешние. По сути, имел место процесс, обратный аутсорсингу, что способствовало развитию натурального хозяйства. Сейчас для значительного числа компаний это становится непосильной ношей. Наблюдаемое в настоящее время нарастание конкуренции во всех отраслях экономики, резкое сужение горизонтов планирования и, как следствие, необходимость получения информации о деятельности компании в режиме реального времени требуют очень высокого уровня надежности ИТ-систем и качества информации в них.
-
Пример внедрения ИТ-аутсорсинга
Рассмотрим пример ИТ-аутсорсинга на примере внедрения ITIL (IT Infrastructure Library) - библиотеки, описывающей лучшие из применяемых на практике способов организации работы подразделений или компаний
Кратко о Проекте
ü Техническая реализация проекта: на базе Ilient SysAid.
ü Сервер баз данных MS SQL.
ü Время реализации Проекта: 9 месяцев.
Основные результаты
ü Сервисный отдел работает в режиме самоокупаемости; дополнительный доход подразделения около $470K в год;
ü повышение эффективности сервисного отдела на 42% (см. таблица 1);
ü централизованная приемка и обработка заявок;
ü контроль эффективности инвестиций;
ü улучшение эффективности коммуникаций внутри отдела;
ü эффективное управление ресурсами отдела;
ü эффективное распределение зон ответственности;
ü компания может гарантировать выполнение своих договорных обязательств;
ü эффективное управление рисками;
ü повышение лояльности заказчиков;
Проект заложил надежный фундамент преобразований фундамент для дальнейшего развития компании «СП»
Цель данного обзора – на примере из практики продемонстрировать экономический эффект от внедрения процессов ITIL. Для рассмотрения выбран сервисный ИТ-отдел крупной отечественной компании «СП», в которой силами специалистов BENEFFY Consulting был реализовано внедрение ряда процессов ITIL. Согласно с договором о конфиденциальности название компании, в которой был реализован проект, было изменено.
О компании «СП»
Компания «СП» специализируется на построении корпоративных информационных систем, телекоммуникационной инфраструктуры, торговле вычислительной техникой.
Сервисный отдел «СП» отвечает за выполнение гарантийных обязательств компании перед заказчиками, осуществляет поддержку пользователей. Кроме этого, в небольшом объеме, отдел предоставляет услуги по ИТ-аутсорсингу: обслуживание ИТ-инфраструктуры Заказчика, расширенная поддержка пользователей.
Территориально компания расположена в Украине, имеет 5 филиалов.
Штат сервисного отдела компании 12 человек. Из них 6 человек в центральном офисе и 6 в филиалах компании.
Толчком к проведению реформирования сервисного отдела в Компании было решение руководства взять на ИТ-аутсорсинг несколько крупных компаний финансового сектора, обладающих распределенной филиальной сетью.
Потребность в изменениях
Руководство «СП» провело анализ деятельности сервисного отдела компании за последний год. В результате анализа эффективность отдела получила негативную оценку.
Данный вывод базировался на следующих фактах.
ü Превышение сроков ремонта гарантийной техники в 2-3 раза стало для компании обычным явлением, более того, участились случаи превышения сроков ремонта в 10 раз.
ü Компания «СП» не в состоянии гарантировать выполнение собственных договорных обязательств касательно гарантийного обслуживания.
ü Качество ремонта неприемлемо низко, в 10% случаев возникает необходимость в повторных ремонтах.
ü Количество жалоб на работу сервисного отдела «СП», за истекший год увеличилось вдвое.
ü По данным опроса, проведенного среди заказчиков «СП», имидж компании заметно ухудшался.
ü Уменьшение заказов постоянных клиентов достигло 20% по сравнению с предыдущим годом.
ü Издержки на содержание сервисного подразделения стали неоправданно большими.
ü Увольнения в сервисном отделе составили 4 человека за год (33% штата).
ü Руководство «СП» ощущало нехватку информации. В результате управленческие решения принимаются на основании субъективных оценок.
ü Существующая структура сервисного отдела не позволяет на его основе развивать направление ИТ-аутсорсинга.
Эффект от внедрения Проекта преобразований
После реализации Проекта удалось достичь следующих результатов:
ü Сервисный отдел начал работать в режиме самоокупаемости за счет нового направления ИТ-аутсорсинга.
ü Сервисный отдел получил возможность дополнительного дохода $470K в год (см. раздел Финансовые результаты).
ü На 40% снижены непродуктивные издержки сервисного подразделения.
ü Количество единиц техники на обслуживании увеличено с 75 до 4150.
ü Количество административных единиц (отделений, офисов) взятых на аутсорсинг увеличено с 5 до 58.
ü Число жалоб на работу сервисного подразделения «СП», снизилось на 90%.
ü Нарушения сроков гарантийного ремонта сведены к минимуму (не более 5% случаев).
ü Число повторных ремонтов сведено к 0.5%, благодаря введенной процедуре контроля качества ремонта.
ü Компания может гарантировать выполнение своих договорных обязательств.
ü Введена процедура сбора отзывов заказчиков о качестве и сроках решения инцидентов.
ü Введены механизмы контроля загрузки персонала (минимизировано количество простоя).
ü Расширен спектр предоставляемых сервисным отделом услуг.
ü Принятие управленческих решений опирается на достоверные количественные данные.
Описание преобразований
Проект был разбит на 2 этапа;
ü Первый этап – создание службы Service Desk, внедрение процесса управления инцидентами. Основная цель – достижение 100% регистрации инцидентов, накопление и анализ информации, детальное планирование преобразований.
ü Второй этап – внедрение процессов управления конфигурациями и изменениями. Цель – оптимизация бизнес-процессов отдела в целом, открытие направления аутсорсинга ИТ-услуг.
Этап 1. Создание службы Service Desk и внедрение процесса управления инцидентами Первый этап включал стандартизацию процессов приемки, регистрации, обработки заявок, поступающих через унифицированные средства коммуникаций (единый электронный почтовый ящик, выделенная телефонная линия). Для автоматизации этих задач была задействована базовая версия программного обеспечения Ilient SysAid.
За 3 месяца были достигнуты результаты:
ü регистрация инцидентов достигла 95%;
ü документирование действий по решению инцидентов достигло 80%;
ü решения инцидентов «по первому звонку» связанных с ПО составили 10%, с аппаратным обеспечением -2%.
Сроки реализации первого этапа Проекта обусловлены невозможностью резкого перехода от одной модели службы поддержки к другой (как со стороны Заказчика так и со стороны исполнителя). Накопление статистики позволило подготовить сотрудников и заказчиков «СП» к следующему этапу Проекта. Кроме того стало возможным провести количественный анализ бизнес-процессов ИТ-отдела компании, составить план следующего этапа реорганизации отдела.
По результатам первого этапа стало очевидно, что инженеры в регионах, при неизменном качестве и сроках решения инцидентов, загружены около 50% рабочего времени. Это позволяет в 75% случаев отказаться от услуг субподрядчиков. Инженер по серверным системам в центральном офисе имеет загрузку менее 50%.
Этап 2. Внедрение процессов управления конфигурациями и изменениями
Реализация второго этапа Проекта преобразований длилась 6 месяцев. Такой срок был связан с необходимостью подбора дополнительного персонала. Кроме этого, сроки реализации первого этапа недостаточны для получения полной и достоверной исходной информации. Поэтому, уточнение нюансов проводили в рамках реализации второго этапа. Одновременно с реализацией второго этапа была активизирована деятельность по продаже услуг ИТ-аутсорсинга.
В результате завершения второго этапа было достигнуто:
ü Необходимость развития направления ИТ-аутсорсинга требовала увеличения числа обрабатываемых Service Desk инцидентов. Исходя из резервов рабочего времени персонала, Служба поддержки должна обрабатывать минимум 1000 инцидентов в месяц. Это требует увеличения штата отдела на 2 диспетчера и 1 инженера в центральный офис.
ü Система регистрации инцидентов позволила более равномерно распределять нагрузку на сотрудников Service Desk. Это позволило распределить зоны ответственности, снизить простои персонала, в среднем, на 5%.
ü Внедрение процессов управления конфигурациями и изменениями сделало возможным предоставление более широкого спектра услуг.
ü Создана база знаний, содержащая решения часто встречающихся инцидентов. С сотрудниками сервисного отдела проведены тренинги по быстрому решению инцидентов с использованием базы знаний. В результате, количество инцидентов, решаемых «по первому звонку» возросло связанных с ПО до 40%, с техникой – до 10%.
ü Появилась возможность проводить анализ затрат на решение инцидентов. Проводится сбор статистики по инцидентам, привязанным к технике Заказчика. Это позволило более точно, на основании количественных данных, разрабатывать политику ценообразования и формирование каталога услуг.
ü В среднем эффективность сервисного подразделения выросла на 42%. Этого удалось добиться за счет устранения простоев персонала, распределения ролей и ответственности, наличия четких инструкций. Также была внедрена информационная система.
Анализ финансовых результатов
Расчет финансовых показателей сервисного подразделения анализировались в следующих допущениях.
ü Доходы от работ, связанных с гарантийным обслуживанием проданной техники и доходы от ИТ-аутсорсинга оцениваются по одинаковому принципу.
ü Дополнительными услугами, которые составляют небольшую долю в доходах отдела, пренебрегаем для упрощения расчетов.
Стоимость человеко-часа
Средняя себестоимость часа сотрудника сервисного отдела $1200 в месяц (с учетом лишь прямых издержек), $1500 в месяц с учетом непрямых издержек (маркетинг, PR, Sales и т. д.).
Структура доходов ИТ-отдела компании «СП»
Доходы отдела можно структурировать следующим образом:
ü Гарантийное обслуживание проданной компанией продукции;
ü Продажа услуг по ИТ-аутсорсингу, поддержке ИТ-инфраструктуры Заказчика; Ремонт вычислительной техники, периферийных устройств, восстановление работоспособности системного ПО.
ü Дополнительные услуги по сверхбыстрому восстановлению техники и/или сервисов Заказчика.
Коэффициент ROI проекта рассчитан как частное от деления средств, полученных компанией дополнительно благодаря более высокой ее эффективности, и средств, затраченных на реализацию проекта преобразований.
Величина коэффициента ROI составляет около 200%
Выводы
Проект преобразований, реализованный в сервисном отделе компании «СП», существенно отразился на его экономической эффективности. Доходность инвестиций, выделенных руководством компании на реализацию Проекта преобразований, обеспечивается благодаря увеличению производительности труда сотрудников, снижению непродуктивных издержек и улучшенной организации рабочего времени. Задача приведения структуры сервисного отдела в соответствие планам развития направления ИТ-аутсорсинга была успешно выполнена.
5. Роль финансового директора.
Согласно выводам автора, роль финансового директора на текущий момент сводится к выполнению функций учета и контроля. Финансовый директор практически не участвует в разработке перспективных проектов, а ограничивается лишь оценкой.
По всей видимости, это справедливо только для предприятий крупного бизнеса, где финансовый директор сталкивается с множеством организационных проблем связанных с унификацией и координацией работы множества отдельных подразделений. В данном случае у него практически не остается ресурсов для более тесного общения с производственными и маркетинговыми подразделениями, которые являются основными генераторами бизнес-идей.
На предприятиях малого и среднего бизнеса ситуация несколько отличается. Как правило на таких предприятиях функции планирования и контроля объединяются в одном подразделении. Таким образом финансовый директор оказывается гораздо больше вовлечен непосредственно в процесс производства, что позволяет ему расширять свои знания в этой области.
Несомненно роль финансового директора не должна ограничиваться только учетом и контролем. Так как зачастую финансовый директор является наиболее информированным лицом в компании относительно стоимости отдельных бизнес-процессов, их способности генерировать прибыль и рост стоимости компании, он должен активно участвовать в работе бизнес-команды и помогать производственным подразделениям двигаться именно в направлении дальнейшего увеличения доходов компании.
6. Настоящее и будущее ИТ-департаментов.
В современных условиях, когда информационные технологии бурно развиваются, а их роль в достижении конкурентных преимуществ для бизнеса становится неоспоримой встает вопрос о роли ИТ-руковолителя в команде компании.
Сейчас уже очевидно, что руководитель ИТ-подразделения – это не просто технический исполнитель, поддерживающий текущую инфраструктуру, а одна из ключевых фигур процессов совершенствования бизнеса, реализация компетенций которой должна являться неотъемлемой частью стратегии предприятия.
В данном случае вопрос, следует ли ИТ-руководителю выступать в роли менеджера бизнес-проекта можно рассматривать в двух плоскостях. Для успешной реализации проекта кроме проработки чисто технической, процессной стороны категорически важен доступ к ресурсам, как материальным, так и административным. Несомненно, что бизнес-руководитель может привлечь в проект, все необходимые ресурсы, однако он не сможет уделять должное внимание проекту, таким образом, возникает дополнительное промежуточное звено между непосредственно проектной командой и источником ресурсов.
Необходимость наличия этого звена напрямую зависит от степени развития понимания структурообразующей роли информационных технологий в современном бизнесе руководством компании. Если начальник ИТ-подразделения является полноправным членом бизнес-команды, то назначение его менеджером бизнес-проекта будет способствовать созданию компактной и динамичной структуры, способной оперативно реагировать на изменения внешней и внутренней среды, стремясь к поставленной цели, не теряя динамики развития на промежуточные согласования и дублирование механизмов управления.