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

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

Вступление

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

Некоторые вводные

• Мы говорим, в основном, о компаниях, бизнесом которых не является предоставление ИТ услуг
• Да, мы все знаем про процессный подход, взаимные “косты” подразделений, инсорсинг и аутсорсинг, но на практике у ИТ директора не хватает политического веса для внедрения этого на всём предприятии, а ИТ решения нужны уже сейчас.
• Правление/Генеральный директор действительно заинтересованы в устойчивом росте скорости генерации дохода компании. (иначе это и не бизнес совсем)
• ИТ директор замотивирован на успех бизнеса, а не на сохранение тёплого местечка.

Теоретическая часть

Крайне полезно прочитать книгу: Синдром стога сена

Для тех, кому лень читать: существуют три показателя от которых может отталкиваться любой руководитель при принятии инвестиционных и управленческих решений: скорость генерации дохода, связанный капитал и операционные расходы. Рост первого при сохранении или уменьшении 2х других — наша постоянная цель. Причём — рост СГД приоритетнее, чем уменьшение СК или ОР.

Так же важно понять, что такие критерии как прозрачность информации и эффективность работы НЕ ЯВЛЯЮТСЯ хорошими показателями при принятии решений. Как вы уже давно заметили вашему “Гендиру” всё-равно насколько быстро и легко человек проверяет почту, а вот если вдруг начав проверять почту удалённо, вечером сотрудник зарабатывает дополнительные деньги — это уже важно.

И ещё: ваши руководители, хоть и кажутся полными идиотами просящими “сделай нам корпоративный-портал” или не понимающими зачем вам виртуализация с терминальными сервисами, в большинстве своём абсолютно правы «зарезая» бюджеты. Т.к. не видят, как скажутся эти инвестиции на 3х показателях, или как же они приобретут конкурентное преимущество.

Стратегические советы(Подготовка почвы)

1. Внедрите у себя процессный подход, хотя бы внутри подразделения, внедрите самое полезное из ITIL, посчитайте часы/трудозатраты на типовые задачи/запросы, привяжите премии к процессным KPI.
2. Почитайте про TQM и другие методологии управления/улучшения качества.
3. Станьте евангелистом процессного подхода — в итоге он позволит вам заработать больше и обосновать больше инвестиций.
4. Не бойтесь предлагать увольнять сотрудников других департаментов, особенно сервисных. Если, конечно предложили решение заменяющее их.
5. Не бойтесь показывать и проводить аналитику показателей в информационных системах — это даст вам пищу для размышлений, а случайно обнаруженный милионный откат на уровне среднего менеджмента ещё и чреват премией.
6. Не думайте, что вы разбираетесь в логистике лучше директора по логистике — общайтесь с профильными подразделениями, выясняйте именно их мнение, а не руководствуйтесь своими домыслами.
7. Составьте хотя бы “на коленке” карту рисков или хотя бы табличку вида(цветом выделен пример):

Номер	Описание	Вероятность наступления(%)	Скорость восстановления(% от рассчётного периода)	Показатель на который влияет риск	Стоимость риска в год
1	Остановка почтового сервера в связи со сбоем — провоцирует остановку деятельности центрального офиса	0.01%	0.02%	(годовая прибыль, если её генерирует офис)	Вероятность наступления *  Показатель * Скорость восстановления

• В описании вы указываете подсистему/сервис в которой происходит сбой, а так же процесс который останавливается/ухудшается в случае, если риск реализуется
• Вероятность наступления каждый раз считаете по разному — зачастую она складывается из SLA провайдера + Наработку на отказ железа * статистику устойчивости программной части.
• Скорость восстановления — время, которое сервис будет недоступен в случае сбоя. Удобнее для расчётов проставлять её как процент от рассчётного периода(обычно я считаю год или объявленный период для рассчёта ROI)
• Показатель на который влияет риск — в колонку вписываете сумму реальных объективных финансовых потерь, которые точно произойдут. Не стоит фантазировать. “Если в магазине отключат свет — он не сможет продать товар — прибыль магазина входит в сумму” — это объективно, “Не будет работать корпоративный мессенджер, менеджеры не договоряться” — это притянуто за уши. Зачастую очень хочется вписать в потери фонд оплаты труда и т.п. Этого делать не нужно. Как мы платили фиксированную часть, так и будем платить, сбой на это никак не повлияет, а сдельную оплату мы при неработе не потеряем.
• Стоимость риска в год — это произведение предыдущих трёх колонок

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

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

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

KPI? Как вас оценивать

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

Очень хорошо выглядят KPI на проценты доступности сервисов, скорости обработки заявок на изменение(для этого хорошо бы иметь единую точку входа HelpDesk), скорости восстановления после сбоев — остальное оставьте на откуп проектам.

ФОТ, сотрудники, внутренние расходы

Забудьте, если ещё пользуетесь, про слова — “ну мне нужен этот человек, мы ну никак не справимся”

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

Или: “Найм этого специалиста в штат под следующие проекты позволит снизить стоимость услуг аутсорсеров на стольно(сумма)”

А лучше всего привязывайте найм сотрудников к запросам других подразделений. В остальном — всё на ваше усмотрение, но помните, всегда лучше раздать премию/повысить зп в половину зарплаты нового сотрудника уже нанятым.

Обоснование инвестиций, самая “вкусная” часть

Заметка: Смиритесь, вам придётся хотя бы первое время быть бизнес-консультантом. Если, конечно, вы хотите делать хорошо.

Эта часть самая сложная, потому что если вы выберете путь: “я тут нашёл такую классную систему автоматизации, она нам так нужна” — вы останетесь в компании максимум до конца внедрения, а-то и меньше. Т.к. такие внедрения ничем кроме финансовых потерь и проблем обычно не заканчиваются.

Этап аналитики:

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

1. Как вообще они работают? — желательно ещё и описывать это какой-то простой процессной нотацией.
2. К какому виду относится их деятельность? — проект, процесс, функция.
3. Создают ли они добавочную стоимость или являются обслуживающим подразделением? — это не значит, что надо забывать про сервисные подразделения, просто нужно думать — как уволить оттуда половину сотрудников 🙂
4. Какие проблемы они испытывают в информационном обмене, взаимодействии с другими подразделениями?
5. Как снизить риски невыполнения ими поставленных задач, целевых показателей?
6. Сколько это стоит? — всё конвертируем в деньги.
7. Чем они пользовались в других компаниях, к чему привыкли из ИТ решений?

Из всей этой информации вашей задачей является формализовать требования и запросы и проранжировать их по приоритетам, влиянию на показатели(помните начало статьи)

Заметка: В нормальной ситуации владелец процесса сам должен приходить к вам с запросом/проблемой, но мы сами кузнецы своего счастья и если так не происходит — мы должны брать процесс в свои руки.

Этап подготовки решения и ТЭО(Технико экономического обоснования):

Заметка: Де факто у вас должно быть исключительно экономическое обоснование, а техника мало кого волнует, кроме вас, но смотрите по ситуации и по тому, насколько акционеры/ГД любят технические новинки и т.п.

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

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

Здесь же закладывайте в ТЭО проектные премии всем участникам. (ДЕНЬГИ!!!) Мы же не хотим зарабатывать на откатах….

Этап поиск поддержки:

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

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

Этап привлечения инвестиций:

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

Этап реализации проекта:

Обязательно прочитайте: Критическая цепь Э. Голдратт

А лучше отучитесь на курсе проектного управления.

Но из основного:

1. Законы Мёрфи — это не шутки, а то, что произойдёт завтра, если уже не произошло.
2. Люди не любят изменений, т.е. либо вы снимите с них большую боль, либо прибавите денег, либо сильно накажете за непослушание. (Думайте про мотивацию подверженных изменениям сотрудников, помогайте их руководителям)
3. В самом начале обговорите все финансовые условия и премии за этапы как для себя, так и для сотрудников, даже не ваших.
4. Опишите миссию, критерии успеха и ограничения проекта.
5. Документируйте все.
6. Выспитесь перед началом, повидайтесь с семьёй.

Этап завершения, оценки:

Опишите все проблемы возникшие в проекте, сложности, недоработки, сравните “что хотели” и “что получилось”, посчитайте реальное влияние проекта на финансовые результаты(если хорошее — обязательно всем про это расскажите)

Подводя итоги

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

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

Если есть вопросы/комментарии — всегда рад ответить. А нажатие кнопки Like и Share — лёгкий способ меня порадовать.