воскресенье, 5 июля 2015 г.

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

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

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

В свою бытность руководителем компании, которая занимается ИТ аутсорсингом, я общался с руководителем и владельцем достаточно крупной организации, и на мое предложение повысить эффективность работы его сотрудников за счет внедрения новой технологии он ответил мне примерно следующее: "Женя, сейчас мои люди примерно половину рабочего времени бездельничают. Ты предлагаешь мне потратить деньги и повысить производительность их труда, чтобы они бездельничали 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. Переход на "тонкие клиенты", которые значительно дешевле и надежнее компьютеров.
Если интересны конкретные цифры - пишите, покажу/расскажу.



пятница, 3 июля 2015 г.

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


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

Введение


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

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

Мы будем рассматривать жизненный цикл проекта как последовательность фаз проекта (Инициация, Планирование, Выполнение работ, Завершение), разделенных между собой Точками принятия решений (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 июля 2015 г.

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

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

  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. 
  1. Prioritize IT investment initiatives and deliver final approvals and recommendations on proceeding with proposed IT projects. 
  1. 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].