Определение целей предприятия с помощью CobiT

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

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

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

Чтобы не "изобретать велосипед", заглянем в CobiT, который предлагает нам 17 общих бизнес-целей, уже заботливо разложенных по BSC (Системе сбалансированных показателей):

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

Чтобы как-то прояснить бизнес-цели, в CobiT приводятся примеры метрик для каждой бизнес-цели. Они там на английском языке (оригинал я привел в конце статьи), здесь приведу в собственном переводе:

1. Отдача от инвестиций для заинтересованных сторон
• Процент инвестиций, где отдача соответствовала ожиданием заинтересованных сторон;
• Процент продуктов и/или сервисов, где были получены ожидаемые выгоды
• Процент инвестиций, где заявленные выгоды соответствовали или превысили ожидания
2. Портфель конкурентоспособных товаров и услуг
• Процент продуктов и услуг, которые соответствуют или превосходят целевой доход и/или долю рынка
• Распределение продуктов и услуг по этапам их жизненных циклов
• Процент продукции или услуг, которые соответствуют или превосходят ожидания заказчиков
• Доля продукции и услуг, которые обеспечивают конкурентное преимущество
3. Управляемые бизнес-риски (защита активов)
• Процент критически важных бизнес-задач и услуг, охватываемых оценкой рисков
• Соотношение значительных инцидентов, которые не были выявлены при оценке риска к общему количеству инцидентов
• Частота обновления профиля риска
4. Соответствие внешним законам и регулирующим нормам
• Стоимость, во сколько обошлось несоблюдение регулирующих норм, в том числе досудебные соглашения и штрафы
• Количество инцидентов несоблюдения нормативных актов, вызвавших общественное обсуждение или ухудшение репутации
• Количество вопросов несоблюдения нормативных актов, относящиеся к договорам с деловыми партнерами
5. Финансовая прозрачность
• Процент инвестиционных бизнес-кейсов с четко определенными и утвержденными ожидаемыми затратами и преимуществами
• Доля продукции и услуг с четко определенными и утвержденными эксплуатационными затратами и ожидаемыми выгодами
• Опрос удовлетворенности ключевых заинтересованных сторон в отношении прозрачности, понимания и точности корпоративной финансовой информации
• Процент затрат от услуг, которые могут быть разнесены по пользователям
6. Клиентоориентированная сервисная культура
• Количество сбоев в обслуживании клиентов, связанных с ИТ-инцидентами (надежность)
• Процент представителей заинтересованных сторон согласных с тем, что сервис для клиентов соответствует согласованному уровню
• Количество жалоб заказчиков
• Текущий тренд результатов опроса удовлетворенности заказчиков
7. Непрерывность и доступность бизнес-услуг
• Количество перерывов в обслуживании клиентов, вызванных значительными инцидентами
• Бизнес-стоимость инцидентов
• Количество человеко-часов, потерянных в результате незапланированных перерывов сервиса
• Процент сбоев в общем количестве запросов
8. Гибкая реакция на изменяющиеся условия ведения бизнеса
• Уровень удовлетворенности высшего руководства относительно реагирования предприятия на новые требования
• Количество критичных продуктов и услуг, поддерживаемых современными бизнес-процессами
• Среднее время обращения стратегических целей предприятия в согласованные и утвержденные проекты
9. Принятие стратегических решений на основе информации
• Степень удовлетворенности высшего руководства и менеджмента системой принятия решений
• Количество инцидентов, обусловленных неправильными бизнес-решениями, принятыми на основе неточной информации
• Время предоставления справочной информации для обеспечения принятия бизнес-решений.
10. Оптимизация затрат на предоставление услуг
• Частота проводимых мероприятий по оценке оптимизированности стоимости предоставления услуг
• Тенденция соотношения роста затрат и уровня предоставляемых услуг
• Уровень удовлетворенности правления и менеджмента расходами на предоставление услуг
11. Оптимизация функциональности бизнес-процессов
• Частота оценки уровня зрелости бизнес-процессов
• Тенденция результатов оценки
• Уровень удовлетворенности правления и руководителей возможностями бизнес-процессов
12. Оптимизация затрат бизнес-процессов
• Частота проводимых мероприятий по оценке оптимизированности бизнес-процессов
• Тенденция соотношения роста затрат и уровня предоставляемых услуг
• Уровень удовлетворенности правления и руководителей расходами на осуществление бизнес-процессов
13. Управление программами бизнес-изменений
• Количество программ, которые уложились во время и в бюджет
• Процент представителей заинтересованных сторон удовлетворенных выполнением программ
• Уровень осведомленности об изменениях в бизнесе, вызванных проектами с высоким уровнем ИТ составляющей
14. Операционная производительность персонала
• Количество программ/проектов, которые уложились во время и бюджет
• Расходы на персонал и уровень персонала относительно среднего по отрасли
15. Соблюдение внутренних политик
• Количество инцидентов, связанных с несоблюдением политик
• Процент представителей заинтересованных сторон, которые понимают внутренние политики
• Процент политик, поддерживаемых действующими стандартными и практиками
16. Квалифицированный и мотивированный персонал
• Уровень удовлетворенности заинтересованных сторон опытом и навыками персонала
• Процент сотрудников, чьи навыки недостаточны для квалификации, необходимой для их роли
• Процент удовлетворенности персонала
17. Культура долгосрочных инноваций продуктов и бизнеса
• Уровень осведомленности и понимания бизнес-инновационных возможностей
• Удовлетворенность заинтересованных сторон уровнем продукта, инновационной экспертизой и идеями
• Количество утвержденных продуктов и сервисов, полученных в результате инновационных идей

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

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

Приложение: оригинал из CobiT относительно метрик бизнес-целей:

Написание ИТ стратегии - пример определения важнейших ИТ процессов

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

02. Портфель конкурентоспособных товаров и услуг.
10. Оптимизация затрат на предоставление услуг.
12. Оптимизация затрат бизнес-процессов.

Определим набор соответствующих ИТ целей с помощью таблицы:

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

Итак, в результате мы имеем три ИТ цели (05, 06 и 11) с весом два и 6 ИТ целей (01, 04, 07, 09, 12 и 17) с весом в 1.

Перейдем к таблице соответствующих ИТ целям процессов:

Справа выписано количество соответствующих пересечений с учетом веса той или иной ИТ цели.

Итак, у нас определились три явных фаворита - ИТ процесса:

EDM02 Обеспечение получения выгоды - 7 баллов

APO04 Управление инновациями - 6 баллов

APO01 Управление подходом к управлению ИТ - 5 баллов

Дальше 8 процессов набрали по 4 балла, понятно, что так распылять свои усилия мы уже не сможем. (Интересно, кстати, посмотреть на процессы - аутсайдеры, который набрали по одному баллу, это именно то, на что нам следует обращать внимание в последнюю очередь).

Посмотрим на эти процессы более подробно.

EDM02 - это процесс из области руководства

EDM02 Ensure Benefits Delivery

Process Description:

Optimise the value contribution to the business from the business processes, IT services and IT assets resulting from investments made by IT at acceptable costs.

Process Purpose Statement

Secure optimal value from IT-enabled initiatives, services and assets; cost-efficient delivery of solutions and services; and a reliable and accurate picture of costs and likely benefits so that business needs are supported effectively and efficiently.

Следующие два - уже из области управления:

APO04 Manage Innovation

Process Description

Maintain an awareness of information technology and related service trends, identify innovation opportunities, and plan how to benefit from innovation in relation to business needs. Analyse what opportunities for business innovation or improvement can be created by emerging technologies, services or IT-enabled business innovation, as well as through existing established technologies and by business and IT process innovation. Influence strategic planning and enterprise architecture decisions.

Process Purpose Statement

Achieve competitive advantage, business innovation, and improved operational effectiveness and efficiency by exploiting information technology developments.

APO01 Manage the IT Management Framework

Process Description:

Clarify and maintain the governance of enterprise IT mission and vision. Implement and maintain mechanisms and authorities to manage information and the use of IT in the enterprise in support of governance objectives in line with guiding principles and policies.

Process Purpose Statement

Provide a consistent management approach to enable the enterprise governance requirements to be met, covering management processes, organisational structures, roles and responsibilities, reliable and repeatable activities, and skills and competencies.

Вывод:

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

PS

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

1. Understand stakeholder requirements; strategic IT issues, such as dependence on IT; and technology insights and capabilities regarding the actual and potential significance of IT for the enterprise’s strategy.

2. Understand the key elements of governance required for the reliable, secure and cost-effective delivery of optimal value from the use of existing and new IT services, assets and resources.

3. Understand and regularly discuss the opportunities that could arise from enterprise change enabled by current, new or emerging technologies, and optimise the value created from those opportunities.

4. Understand what constitutes value for the enterprise, and consider how well it is communicated, understood and applied throughout the enterprise’s processes.

5. Evaluate how effectively the enterprise and IT strategies have been integrated and aligned within the enterprise and with enterprise goals for delivering value.

6. Understand and consider how effective current roles, responsibilities, accountabilities and decision-making bodies are in ensuring value creation from IT-enabled investments, services and assets.

7. Consider how well the management of IT-enabled investments, services and assets aligns with enterprise value management and financial management practices.

8. Evaluate the portfolio of investments, services and assets for alignment with the enterprise’s strategic objectives; enterprise worth, both financial and non-financial; risk, both delivery risk and benefits risk; business process alignment; effectiveness in terms of usability, availability and responsiveness; and efficiency in terms of cost, redundancy and technical health.

1. Define and communicate portfolio and investment types, categories, criteria and relative weightings to the criteria to allow for overall relative value scores.

2. Define requirements for stage-gates and other reviews for significance of the investment to the enterprise and associated risk, programme schedules, funding plans, and the delivery of key capabilities and benefits and ongoing contribution to value.

3. Direct management to consider potential innovative uses of IT that enable the enterprise to respond to new opportunities or challenges, undertake new business, increase competitiveness, or improve processes.

4. Direct any required changes in assignment of accountabilities and responsibilities for executing the investment portfolio and delivering value from business processes and services.

5. Define and communicate enterprise-level value delivery goals and outcome measures to enable effective monitoring.

6. Direct any required changes to the portfolio of investments and services to realign with current and expected enterprise objectives and/or constraints.

7. Recommend consideration of potential innovations, organisational changes or operational improvements that could drive increased value for the enterprise from IT-enabled initiatives

1. Define a balanced set of performance objectives, metrics, targets and benchmarks. Metrics should cover activity and outcome measures, including lead and lag indicators for outcomes, as well as an appropriate balance of financial and non-financial measures. Review and agree on them with the 

IT and other business functions, and other relevant stakeholders.

2. Collect relevant, timely, complete, credible and accurate data to report on progress in delivering value against targets. Obtain a succinct, high-level, all-around view of portfolio, programme and IT (technical and operational capabilities) performance that supports decision making, and ensure that 

expected results are being achieved.

3. Obtain regular and relevant portfolio, programme and IT (technological and functional) performance reports. Review the enterprise’s progress towards identified goals and the extent to which planned objectives have been achieved, deliverables obtained, performance targets met and 

risk mitigated.

4. Upon review of reports, take appropriate management action as required to ensure that value is optimised.

5. Upon review of reports, ensure that appropriate management corrective action is initiated and controlled.

Как написать толковую ИТ стратегию

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

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

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

Говоря проще, получать выгоды, сильно не рискуя и при этом, и, желательно, используя минимум ресурсов. (Здесь и далее все рисунки нарезаны из COBIT 5 Russian, который настоятельно рекомендую к прочтению всем, кого интересует тема ИТ стратегии).

Не вдаваясь в детали, приведу всю цепочку:

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

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

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

Для помощи в определении наиболее актуальных бизнес-целей можно использовать в помощь нижеприведенную таблицу с вопросами:

Определившись с приоритетными бизнес-целями мы уже можем выбрать приоритетные на текущий момент ИТ цели из списка:

Для определения соответствия ИТ целей бизнес-целям тоже есть соответствующая таблица:

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

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

Как я сдавал экзамен по корпоративному управлению в ИТ (CGEIT)

Для начала несколько слов о том, зачем вообще сдавать экзамены и получать сертификаты. Каждый делает это, имея собственную мотивацию. Лично для меня - наличие сертификата снимает необходимость кому-либо что-либо объяснять и доказывать, достаточно просто сказать "Мне кажется следует делать так-то и так-то". И, при наличии сертификата, если специалисту что-то кажется, то с высокой долей вероятности так оно и есть :).

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

Одна из немногих доступных на эту тему сертификаций - это сертификация Certified in the Governance of Enterprise IT (CGEIT), которую проводит организация ISACA.
Весьма подробно тема "Нужен ли ИТ-руководителю сертификат CGEIT?" раскрыта в статье по соответствующей ссылке, здесь же я остановлюсь лишь на практических аспектах сдачи данного экзамена.

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

Вначале я изучил официальные рекомендации от организации ISACA, которая и проводит соответствующий экзамен. Там, чтобы сдать экзамен, рекомендуется изучить соответствующую литературу и убедиться, что у вас есть знания и опыт в соответствующих областях.
Заказав, оплатив и получив по почте соответствующие три книги - CGEIT Review Manual 2015, CGEIT Review Questions, Answers & Explanations Manual 2015 и CGEIT Review Questions, Answers & Explanations Manual 2015 Supplement, мне стало понятно, что их не получиться просто "прочитать", даже, если не обращать внимания на то, что они на английском языке.

Review Manual - это книга на 200 страниц мелкого текста, которая описывает термины и понятия, которые кандидат должен знать. Причем, весьма кратко и справочно, на одной странице могут быть перечислены штук пять понятий уровня Balanced Scorecard, детальное описание которых мне пришлось искать в интернете (кстати, рекомендую сайт 12manage.com, очень много толковых описаний, в том числе и на русском языке).
Предполагаю, что это индивидуально, но мне оказалось гораздо проще читать про новые для меня понятия сначала на русском языке, а уже потом - на английском. Кстати, для некоторых понятий, например accountability, в русском языке вообще аналогов нет.

CGEIT Review Questions, Answers & Explanations содержит примерные вопросы к экзамену, с правильными ответами, но самое главное - с объяснениями, почему один ответ правильный - а остальные - не очень.

Вообще, экзамен построен в виде "угадайки" - описывается ситуация, задается вопрос и приводится 4 варианта ответа, из которых требуется выбрать правильный. Основная сложность состоит в том, что, как правило, все 4 ответа приводят к желаемому результату, нужно определить именно ЛУЧШИЙ вариант.

Для подготовки я использовал механистическую схему: до экзамена у меня оставалось 10 недель, я пересчитал количество страниц в трех книжках, которые мне предстояло прочитать (314 всего), прикинул, что для полного счастья лучше бы это все прочитать как минимум 2 раза, вышло, что в день мне нужно изучать где-то 11 страниц текста (один день в неделю я оставил себе, как выходной/запасной).
Сразу скажу, что 10 недель в таком темпе - это нелегко, напоминаю, что нужно не просто прочитать за вечер 11 страниц на английском языке но и разобрать все те понятия, что там встречаются.

Всего в курсе 5 основных разделов - Framework for the Governance of Enterprise IT, Strategic Management, Benefits Realization, Risk Optimization, Resource Optimization. Поэтому я сначала изучал соответствующий раздел, потом разбирал вопросы из этого раздела, потом переходил к следующему разделу.
По результатам я заполнял таблицу, чтобы отслеживать свой прогресс и понимать, насколько все мои планы реальны

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

Для сдачи экзамена пришлось ехать в Москву (экзамены принимают 2 раза в год), там все оказалось очень сурово, телефоны сдаешь на входе, если во время экзамена зазвонит телефон - то это серьезный инцидент и о нем записывают с специальный журнал, выносить ничего нельзя, в туалет только по одному, перед этим под подпись все материалы сдаешь и проверяют чтобы сдал все, записывать все можно только на тетради которую тоже дают а потом забирают, за малейшие отклонения, понятно, сразу дисквалификация.
Результат тебе сообщают только через 8 недель. Сдавать, в принципе, можно сколько хочешь раз, 2 раза в год, если есть возможность каждый раз по $500 за каждую попытку отстегивать :)

По моему объективному ощущению, без опыта работы в корпоративной среде в крупной (желательно международной) компании на этот экзамен лучше не ходить, так как ОЧЕНЬ много вопросов, которые не закрываются никакой теорией, нужно просто знать, что делает тот или иной комитет, за принятие каких решений в компании обычно кто отвечает и так далее.

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

Dear Evgeniy Tishin, CGEIT,

RE: CGEIT certification number: 1506642

Congratulations! ISACA’s CGEIT Certification Working Group is pleased to inform you that on  22 September 2015 you have been granted certification as Certified in the Governance of Enterprise IT (CGEIT).

Типа, они pleased to inform. А уж как я pleased, так это и словами не передать! :)

Как снизить ИТ расходы в расчете на пользователя в два раза

Статья основана на личном опыте работы ИТ директором. Так получилось, что за первый же год своей работы я снизил расходы на ИТ (в расчете на одного пользователя) ровно в два раза.
Чтобы не ограничиваться банальным "Выведите все на аутсорсинг и будет вам счастье", оговорюсь сразу, что на аутсорсинг следует выводить не все. Заодно найдем здесь ответ на вопрос "За счет ЧЕГО снижаются расходы"?

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

В свою бытность руководителем компании, которая занимается ИТ аутсорсингом, я общался с руководителем и владельцем достаточно крупной организации, и на мое предложение повысить эффективность работы его сотрудников за счет внедрения новой технологии он ответил мне примерно следующее: "Женя, сейчас мои люди примерно половину рабочего времени бездельничают. Ты предлагаешь мне потратить деньги и повысить производительность их труда, чтобы они бездельничали 3/4 своего времени?" :).

Персонал

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

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

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

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

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

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

1. Аутсорсер заинтересован в повышении надежности инфраструктуры (меньше запросов - меньше работы) и прикладывает все усилия, чтобы все работало хорошо и не ломалось.
2. Надежная инфраструктура снижает процент сбоев, работу с которыми труднее планировать и это требует нескольких человек одновременно (ведь сломаться что-то может одновременно в разных офисах). Сейчас у нас в компании процент сбоев составляет примерно 20%, т.е. из 100 запросов 80 можно спокойно планировать, равномерно загружая инженеров.
3. Инженеры загружены практически на 100%, выполняя один запрос за другим. В каждый момент времени инженер выполняет какой-то запрос, и так весь свой рабочий день.

Снижение процента сбоев в общем количестве запросов.

Оборудование

Странно, что при том, что все имеют представление о том, что ИТ оборудование со временем устаревает, многие искренне не понимают, что, например, если вы покупаете сервер за $7000 и срок его службы 7 лет, то через семь лет вам придется отдать еще $7000, причем сервер-то у вас останется только один. Аналогично с компьютерами, принтерами, всякими сетевыми коммутаторами и прочее.

То есть, если у вас ИТ оборудования, скажем, на $1 000 000, и при этом семилетний цикл обновления техники (то есть за семь лет вы все это оборудование должны обновить) то ваши расходы в год на обновление составят 1/7 от стоимости, или примерно 15%, то есть $150 000 в год вы будете платить, просто поддерживая парк техники в том же состоянии.

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

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

Компьютеры при этом, по мере их выхода из строя, заменяются на "Тонкие клиенты", которые реже ломаются, не требуют настройки и потребляют в 10 раз меньше электричества, что особенно привело в восторг наш отдел эксплуатации :)

Когда, в конце 2014 года курс доллара поднялся в два раза, и многие были в шоке, то на наш ИТ бюджет это никак не повлияло, т.к. мы больше не закупаем оборудование, а аутсорсеры работают за рубли и там только услуги, а не "железо".

На чем же здесь происходит снижение затрат?:

1. Отказ от владения дорогостоящим "железом", которое при этом не загружено на 100%, но требует обслуживания и обновления.
2. Переход на "тонкие клиенты", которые значительно дешевле и надежнее компьютеров.

Если интересны конкретные цифры - пишите, покажу/расскажу.

Про то, как при этом работать ИТ директору можно почитать здесь :)

Краткий курс проектного управления

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

Введение

Определение проекта

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

Мы будем рассматривать жизненный цикл проекта как последовательность фаз проекта (Инициация, Планирование, Выполнение работ, Завершение), разделенных между собой Точками принятия решений (Gates, G1-G4, точки пересмотра выделения ресурсов). Как правило, «Gate» представляет из себя совещание, на котором принимается соответствующее решение.

Идея проекта

Идея проекта  может быть озвучена любым сотрудником компании в виде Предложения (заявки) о проекте и вынесена на рассмотрение Комитета по управлению портфелем.

Портфельный комитет

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

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

Gate 0 (Точка принятия решения G0) – решение о начале предпроектных исследований

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

Фаза «Инициация»

На этом этапе Портфельный комитет назначает/определяет Спонсора проекта (Project Owner)

Спонсор проекта

Спонсор (Заказчик, Project Owner, project customer ) – это лицо, которое предоставляют финансовые ресурсы (деньгами или в любом другом виде) для проекта. Сюда входит выступление в роли представителя перед руководством более высокого уровня, чтобы заручиться поддержкой по всей организации и содействовать получению выгод, которые принесет проект. Спонсор сопровождает проект на протяжении процесса вхождения в контакт и отбора до получения официального одобрения и играет важную роль в разработке первоначального содержания и Устава.

В частности, Спонсор проекта отвечает за следующее:

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

Цель фазы Инициация – проработка Предложения о проекте и создание Устава проекта.

Устав проекта

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

Устав проекта должен включать в себя:

• Цель проекта
• Измеряемые критерии успешности проекта
• Краткое изложение общих требований
• Краткое изложение описания сути проекта – преимущества для бизнеса (business benefits)
• Краткое изложение характеристик продукта проекта
• Требования к системе утверждения результатов проекта и кто решает, что проект успешно завершен
• Поименный перечень лиц с указанием их ответственности за проект
• Менеджер проекта, его полномочия и ответственность
• Ключевые вехи по срокам проекта
• Ориентировочный бюджет

Шаблон Устава:

1. Предыстория проекта и его связь со стратегией компании
2. Преимущества (выгоды) для бизнеса
3. Бизнес-цели, достижение которых поддерживает проект
4. Приоритеты (бюджет, сроки, качество/объем работ)
5. Результат (продукт) проекта
6. Заинтересованные стороны (stakeholders)
7. Полномочия и ответственность менеджера проекта
8. Описание фаз проекта, точек принятия решений и основных вех проекта
9. Стоимость и необходимые ресурсы
10. Высокоуровневая оценка бюджета включая финансирование всего проекта
11. Необходимые ресурсы для фазы «Планирование» (G1-G2)
12. Основные риски проекта
13. Ограничения и связи с другими проектами
14. Зависимости

Вехи проекта

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

Менеджер проекта

Менеджер проекта (Project Manager, PM)  - лицо, назначенное исполняющей организацией для достижения целей проекта.

Обычно Менеджера проекта назначает Спонсор проекта или Команда управления проектом
Основные задачи и зоны ответственности Менеджера проекта:

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

Обычно Спонсор привлекает Менеджера проекта на этапе разработки Устава проекта – его пишет Менеджер, но отвечает за содержание Спонсор.

Gate 1 (Точка принятия решений G1) – решение о начале планирования

Портфельный комитет утверждает Устав проекта

Фаза «Планирование»

Календарно-ресурсный план

Основной целью фазы Планирование является создание Календарно-ресурсного плана (КРП, Project Plan), который в свою очередь состоит из распределения ресурсов по Иерархической структуре работ (ИСР, Work Breakdown Structure, WBS)

Иерархическая структура работ

Иерархическая структура работ (ИСР, Work Breakdown Structure, WBS) это ориентированная на результаты (предметы поставки) иерархическая декомпозиция работ, выполняемых командой проекта для достижения целей проекта и получения необходимых результатов. С ее помощью структурируется и определяется все содержание проекта.

Создание иерархической структуры работ (ИСР) – это процесс разделения результатов проекта и работ по проекту на более мелкие элементы, которыми легче управлять, на каждом более низком уровне ИСР представляет все более детальное описание работ по проекту

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

Декомпозиция – это разделение результатов проекта на более мелкие и легко управляемые элементы; декомпозиция выполняется до тех пор, пока работы и результаты не будут определены на уровне пакетов работ. Уровень пакетов работ является низшим и представляет собой точку, в которой стоимость и длительности операций работ поддаются достоверной оценке и управлению. Обычно пакет работ длиться не более 2х недель (10 рабочих дней)

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

В начале фазы Планирование Спонсор проекта собирает Команду управления проектом (Steering Group)

Команда управления проектом

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

Команда управления проектом играет две важных роли в проекте:

1. Обеспечивает ценность проекта для бизнеса
• Это наиболее важная роль Команды управления проектом
• Некоторые члены Команды управления проектом могут являться Заказчиками
• Руководитель команды управления проектом обычно представляет собой наиболее заинтересованное лицо от бизнеса в проекте
• Руководитель Команды управления проектом и Менеджер проекта должны представлять собой эффективную команду.
2. Обеспечение проекта ресурсами
• Участники Команды управления проектом используют свое влияние, чтобы на проект выделялись необходимые ресурсы – это важно, в частности, с точки зрения Менеджера проекта
• Обеспечение того, чтобы ресурсы, выделяемые на проект были действительно доступны. Если ключевые ресурсы заняты на проекте полный рабочий день, эта роль не актуальна.

Состав команды управления проектом:

• Каждый участник Команды управления проектом должен играть чёткую роль и вносить свой вклад в руководство проектом
• Минимально возможная Команда управления проектом состоит из Спонсора и Менеджера проекта
• Участники команды могут иметь и другие роли, за исключением следующих:
• Специалисты – они должны работать в Команде проекта или как консультанты под руководством Менеджера проекта
• Сотрудники, которым нужна информация – коммуникации в проекте должны обеспечиваться другим путем

Основные задачи и область принятия решений Команды управления проектами и Спонсора:

• Принимает решения на этапах выполнения проекта
• Удостоверяется в том, что проект имеет необходимые условия для успешного выполнения/завершения
• Утверждает календарно-ресурсный план (КРП, Project Plan)
• Утверждает отклонения в проекте, которые требуют изменения согласованного графика, бюджета или объема работ
• Отвечает за управление рисками проекта. Отслеживает изменения ситуации, которые могут повлиять на цели проекта
• Контролирует доступность необходимых для проекта ресурсов
• Распространяет принятые решения и контролирует их выполнение
• Постоянно оценивает ход реализации проекта и гарантирует целесообразность продолжения проекта
• Оказывает поддержку менеджеру проекта
• Разъясняет суть проекта и его преимущества для бизнеса внутри компании
• Утверждает достигнутые результаты и  отчет об окончании проекта
• Принимает решение о закрытии проекта

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

Gate 2 (Точка принятия решений G2) – решение о начале выполнения работ

Спонсор и Команда управления проектом утверждают Календарно-ресурсный план (КРП, Project Plan). Это наиболее важная точка принятия решений во всем проекте. Именно здесь утверждается окончательный бюджет, организация проекта и формы отчетности.

Фаза «Выполнение работ»

Утвержденный Спонсором, Командой управления проектом (и, возможно, Проектным комитетом) Календарно-ресурсный план ознаменует собой начало фазы Выполнение работ.
Основная цель фазы Выполнения работ – выполнить все пакеты работ согласно КРП, таким образом, достигнув целей проекта
Все работы выполняет Команда проекта согласно утвержденному Календарно-ресурсному плану.

Команда проекта

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

• Вносит персональный вклад в выполнение пакетов работ, а также принимает участие в детальном планировании работ
• Документирует свою часть работ
• Информирует Менеджера проекта обо всех отклонениях по срокам или объему работ от согласованных ранее или вновь появившихся рисках
• Отвечает за качество выполненной работы в соответствии с требованиями

Gate 3 (Точка принятия решений G3) – решение о завершении проекта

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

Фаза «Завершение проекта»

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

Gate 4 (Точка принятия решений G4) – решение об утверждении отчетности

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

Отчетность

Отчеты по проекту готовит Менеджер проекта. Существует несколько видов отчетности:

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

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

1. Открытие совещания (Спонсор)
2. Утверждение протокола предыдущего совещания
3. Обзор решений, принятых на прошлом совещании, краткий отчет ответственных по каждому пункту выполнено/не выполнено.(Обычно ведет Спонсор, может поручить вести совещание любому из присутствующих)
4. Краткий отчет по проекту (отклонения от графика и/или бюджета) (Менеджер проекта, PM)
5. Перечисление результатов, достигнутых за отчетный период (PM)
6. Мероприятия проекта, намеченные на следующий отчетный период (PM)
7. Обзор проблем/сложностей/возникших рисков, обязательно уже с вариантами их решения. Наличие вопросов без предложенных вариантов решений свидетельствует о некомпетентности менеджера проекта. (PM)
8. Определение даты следующего совещания (PM и Спонсор)
9. (В процессе совещания) заполнение таблицы поручений и ответственных. Ответственными назначаются лица ТОЛЬКО из присутствующих на совещании. (PM)

Менеджер проекта рассылает протокол на согласование всем участникам в течение 2-3 дней после совещания, менеджер учитывает комментарии к протоколу и утверждает протокол на следующем совещании.

Отчет о текущем состоянии проекта (Status Report)

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

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

Чек-лист управления проектом

• Создан документ «Предложение о проекте» (ссылка на документ)
• Сформирован «Портфельный комитет» (список участников)
• Портфельный комитет утвердил данное «Предложение о проекте» (протокол заседания)
• Портфельный комитет назначил Спонсора (Куратора) этого проекта (протокол заседания)
• Спонсор (Куратор) подготовил Устав проекта (ссылка на документ)
• Портфельный Комитет утвердил Устав (протокол заседания)
• Спонсор (Куратор) назначил Менеджера проекта (ФИО)
• Спонсор (Куратор) собрал Команду Управления проектом (протокол заседания)
• Менеджер проекта подготовил Календарно-ресурсный план (КРП) (ссылка на документ)
• Команда управления проектом утвердила КРП (протокол заседания)
• Менеджер проекта собрал Команду проекта, сделали всю работу (протоколы собраний)
• Менеджер проекта подготовил отчет о завершении проекта (ссылка на документ)
• Команда управления проектом утвердила Отчет о завершении проекта (протокол заседания)
• Менеджер проекта подготовил Финальный отчет по проекту (ссылка на документ)
• Команда управления проектом утвердила финальный отчет (протокол заседания)

Типичные бизнес-цели предприятия:

Как эффективно проводить закупки товаров или услуг

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

1. Определитесь с тем, что вы хотите купить. Это описание называется Запрос предложения (Request for Proposal, RFP).
• писать его самим долго и утомительно, поэтому просто попросите это сделать любого вашего потенциального поставщика, естественно без обещаний при этом каких-либо преференций при закупке. Это ваимовыгодное взаимодействие. Вы экономите время и силы, а поставщик узнает о предложении первым, что дает ему некоторую фору относительно других.
2. Внимательно изучите это RFP и выбросите из него все "закладки", которые туда включил ваш потенциальный поставщик, чтобы "заточить" его под себя и заранее отрезать конкурентов. Поиск подобных закладок - очень увлекательный процесс и он вам обязательно понравится.
3. Создайте специальный почтовый ящик типа zakupki@kompaniya.ru и настройте его так, чтобы доступ к нему был у ограниченного количества лиц, а главное - чтобы письма из этого ящика было невозможно удалять. Это несложно сделать технически, а пользы в дальнешем принесет очень много, так как исключит соблазн у недобросовестных закупщиков "фильтровать" поступающие предложения.
4. Разместите ваше RFP на сайте вашей компании в разделе "закупки", чтобы оно "провисело" на нем не менее двух недель, чтобы все желающие смогли отправить свои коммерческие предложения на вышеуказанный адрес.
• оптимально сделать на сайте возможность подписаться на обновления и новые закупки, чтобы подрядчикам не нужно было постоянно заглядывать в этот раздел, а они бы уведомлялись по электронной почте, если появляется что-то новое.
• если опасаетесь, что "набежит" слишком много потенциальных подрядчиков, то поставьте сразу какое-нибудь условие, чтобы отсеять фирмы-однодневки, например, оплата только по факту поставки, или фирма должна существовать не менее года, или что-нибудь еще в этом же духе.
5. Далее отдел закупок или те, кто будет потом отвечать за контракт собирают заявителей на телефонную конференцию и проводят так называемые "конкурентные переговоры", где участникам предлагается снижать цену, как на аукционе и каждый останавливается на какой-то цене.
• избегайте при всем этом терминов "аукцион", "тендер", "конкурс", так как они будут налагать на вас некоторые обязательства, в частности потом вы будете вынуждены объяснять почему вы выбрали того или иного подрядчика 
• зафиксируйте цену, на которой остановился каждый участник и предложите им выслать вам уже новое  коммерческое предложение с указанной новой ценой.
• на этом "конкурентные переговоры" завершаются, никаких решений по выбору подрядчика на этом этапе не происходит
6. Заранее учредите так называемый Центральный закупочный комитет (ЦЗК), в который будут входить руководители высшего звена, который будет собираться примерно раз в месяц для принятия решений по выбору подрядчика/поставщика.
7. На очередном заседании ЦЗК представитель подразделения, которое осуществляет закупку выступает с небольшой презентацией, где представляет список потенциальных поставщиков, которые заявились на конкурентные переговоры, цену, на которой остановился каждый, а также какого из этих поставщиков агрументированно предлагается в результате выбрать (причем не обязательно того, у кого самая низкая цена).
8. Выслушав докладчика, ЦЗК принимает решение, у которого поставщика компания будет приобретать товар/услугу. Естественно, это будет не обязательно тот поставщик, которого рекомендует докладчик от профильного подразделения.
• заранее известите всех поставщиков что вы не обязаны им сообщать кто и почему в результате будет выбран, так как это не тендер и не конкурс.
9. Далее подразделение уже заключает договор с этим поставщиком и происходит сама закупка товара/услуги.

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

Положение об Управляющем (стратегическом) комитете по ИТ

Что такое Стратегический комитет по ИТ? Заглянем в CobiT, чтобы найти там определение:

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

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

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

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

Примерный шаблон Устава на английском языке можно взять, например, на сайте www.infotech.com.

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

Полный текст на английском языке (для сведения) я привел в самом конце статьи, а далее здесь идет перевод:

Положение об Управляющем комитете по ИТ

Назначение

Управляющий комитет по ИТ (далее - Комитет, IT Steering Committee, ITSC) осуществляет надзор за инвестиционными приоритетами в ИТ для [название компании]. Члены Комитета назначаются [должность того, кто назначает]. Комитет:

1. Обеспечивает стратегическое лидерство для ИТ через приведение в соответствие стратегических целей ИТ со стратегическими целями и процессами предприятия в целом.
2. Расставляет приоритеты инвестиционных предложений в ИТ, дает рекомендации и проводит итоговое утверждение предлагаемых ИТ проектов.
3. Обеспечивает открытое общение между ИТ подразделением и другими функциональными и бизнес-подразделениями [название компании] чтобы поощрять совместное планирование.

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

Повестка

Типичная повестка дня собрания (заседания) комитета включает в себя:

1. Обзор основных текущих проектов и обсуждение проблем (текущее положение дел и вопросы).
2. Обзор и принятие решений по новым проектным предложениям (т.е. принять, отклонить или отложить).
3. Обзор любых изменений в производительности бизнеса или ИТ.
4. Пересмотр и необходимая корректировка приоритетов проектов.

Состав

В Комитет входят:

• [Ген. директор] - председатель
• [Директор по ИТ] - зам. председателя
• [Финансовый директор]
• [Директор по маркетингу]
• [Директор по персоналу]
• [Дополнительно, руководители бизнес-подразделений]
• Специальные участники, по необходимости, эксперты в конкретных бизнес процессах и/или технологиях

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

Если какой-либо участник не смог присутствовать на большинство встреч Комитета, то Председатель комитета назначает ему замену. Если Председатель не в состоянии присутствовать на большинстве встреч Комитета, то сам Комитет будет назначить замену.

Полномочия

• Комитет проводит заседания на ежемесячной основе. Встречи собирает Председатель или его представитель.
• Все предложения должны быть выполнены в виде бизнес-кейсов, включая в себя описания конкретных преимуществ для бизнеса, анализ затрат/выгод и расчет возврата инвестиций (ROI).
• Предложения от соответствующих бизнес-подразделений следует направлять Председателю комитета как минимум за [число] дней до заседания комитета
• Предложения, которые будут приняты к рассмотрению Председатель рассылает как минимум за [число] дней до заседания.
• Комитет рассматривает только предложения, соответствующии следующим критериям:
• Капитальные затраты более чем [число]
• [другие критерии]

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

• Все предложения должны быть представлены лично представителем того бизнес-подразделения, которое выступает бизнес-спонсором данного предложения на протяжении его полного жизненного цикла.
• Все предложения должны быть отсмотрены и одобрены ИТ подразделением как технически осуществимые.
• Утверждение предложениий проводиться простым большинством голосов при голосовании, которое проводит Председатель. Каждый член комитета имеет один голос, за исключением [вставьте исключения].
• Комитет имеет право отклонить любое предложение, если он посчитает, что бизнес-кейс не достаточно подготовлен, или, если предложение не в достаточной степени поддерживает стратегические цели компании [название компании].
• На каждом заседании Комитет получает отчеты о состоянии всех ранее одобреных предложений. Комитет может рекомендовать остановку и завершение любого проекта, который более не соответствует заявленным целям.
• Каждый [год/квартал] Комитет предоставляет [Генеральному директору, Совету директоров] отчет с обзором проектов за предыдущий [год/квартал] и список проектов и их приоритетами на следующий [год/квартал].

--------------------------------------------------------

IT Steering Committee Charter

Introduction: How to Use This Tool
An IT steering committee is an excellent tool for making the business accountable for desired IT investment decisions. A charter is an essential document for defining the scope and purpose of the committee. Without a charter to control and set clear objectives for this committee, the IT department could find the rest of the enterprise overly involved in day-to-day IT operations.

To use this template, simply customize any text below in dark grey to fit the needs of your enterprise. Be sure to remove all introductory text in dark grey and convert the remaining text to black prior to distribution.

Purpose 
The IT Steering Committee (ITSC) oversees the information technology investment priorities for [insert company name]. Members of the ITSC are appointed by [insert role] and are accountable to the senior executive. The committee will:

1. Provide strategic leadership for IT through the alignment of IT strategic objectives and activities with enterprise strategic objectives and processes. 

2. Prioritize IT investment initiatives and deliver final approvals and recommendations on proceeding with proposed IT projects. 

3. Ensure open communication between the IT department and the other functional units of [insert      company name] so as to promote collaborative planning.

The ITSC is not responsible in any way for the IT department operating budget, IT department staff, or any other aspect of day-to-day IT operations.

Agenda
The agenda of a typical ITSC meeting will include the following items:

1. Review major projects in flight and discuss concerns (i.e. status and issues).
2. Review and set disposition for new project proposals (i.e. approve, decline, or defer).
3. Review any changes in IT/business capacity.
4. Review the project priority list to consider adjustments.

Membership
Members of the ITSC include:

• [CEO/President] – Chair
• [The head of IT] – Vice-Chair
• [The head of Finance]
• [The head of Marketing]
• [The head of Human Resources]
•  [Additional heads of business units]
• Ad hoc members, as required, who are experts of particular business processes or technologies.

All permanent members of the ITSC should be very familiar with the IT department’s policies, procedures and practices. As well, all permanent members should have the authority to make decisions and take actions on behalf of the business unit they represent.

If any member is unable to attend the majority of ITSC meetings, then the committee chair will designate a replacement. If the ITSC chair is unable to attend the majority of ITSC meetings, then the committee itself will designate a replacement. 

Mandate

• The ITSC shall meet on a monthly basis. These meetings will be scheduled by the ITSC chair or designated proxy.
• The ITSC will be chaired by [insert role].
• All proposals must follow a specific business case methodology as mandated by the ITSC. This methodology includes clear definitions of business measures and benchmarks of progress, namely a cost/benefit analysis and clear calculation of Return on Investment (ROI).
• Electronic copies of all proposals must be submitted to the ITSC chair by the sponsoring business unit at least [insert number] business days in advance of the ITSC meeting.
• Copies of all project proposals to be reviewed by the ITSC will be sent by the committee chair to the rest of the committee members at least [insert number] business days in advance of the meeting.
• The committee shall review all proposals for IT investment meeting the following criteria:
• With projected capital costs over [insert monetary amount].
• [Insert other threshold criteria].
• [Insert other threshold criteria].

This includes proposals from within the IT department as well as proposals from other departments that have a significant IT component.

• All proposals must be formally presented in person to the ITSC by the business unit which will act as the sponsor for the proposed project throughout its lifecycle.
• All proposals must be reviewed and approved for technological merit by the IT department.
• Approval for all projects will be reached through a consensus vote of the ITSC. The vote will be administered by the ITSC chair. Each member of the committee shall be entitled to one vote, excepting [insert exceptions].
• ITSC has the authority to reject any proposal which it deems not to have made a sufficient business case or which does not significantly contribute to the strategic goals of [insert company name].
• At each meeting, the committee will receive progress reports on all previously approved proposals. The ITSC can recommend the termination of any project which is not meeting its projected goals.
• Each [year/quarter], the ITSC will provide [CEO, Board of Directors] with a report that reviews project progress for the previous fiscal {year/quarter} and set a priority list of projects for the coming fiscal [year/quarter].