Роль CTO во внутрикорпоративных ИТ

Так сложилось, что последнее время, в разном контексте, мне пришлось обсуждать роль CTO с несколькими CIO/Директорами по ИТ. Участвуя в проекте модернизации одной ИКТ-стратегии, предполагавшей реорганизацию блока ИТ в холдинге, возникла интересная дискуссия о фактическом дублировании обязанностей CTO и руководителя отдела архитектуры и стандартов. В другом случае, Директор по ИТ ожидал от CTO ответа на вопросы о выборе платформы, сайзинге ERP и затратах на необходимое оборудование. В третьем, CIO (именно так — Cio, являющийся членом Совета директоров компании) не был уверен в необходимости наличия CTO в организации, сам постоянно «зашиваясь» со временем и пытаясь погрузиться в детали технических решений, предлагаемых разными вендорами и интеграторами.

В двух словах, мое определение роли CTO (кстати, включенное в своей содержательной части в должностную инструкцию в одной компании ;) звучит так:

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

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

Я заметил, что зачастую, руководители блока ИТ смешивают роль CTO и руководителя отдела инфраструктуры, что по моему мнению не очень корректно. Такой проблемы не возникает у тех руководителей, которые понимают значимость выделенной (есть замечательное и очень ёмкое слово на английском — dedicated) архитектурной деятельности. Но, даже в этом случае, не так часто можно увидеть явного CTO (с т.з. его полномочий, кратко описанных во втором абзаце моего определения). При таком подходе соответствующая деятельность и ответственность в области определения технической политики размазывается между руководителями архитектурного отдела и других отделов. При этом, основная болезнь — сужение области ответственности и нехватка полномочий, позволяющих в одних случаях блокировать неоднозначные решения, предлагаемые к примеру отделом инфраструктуры, а в других, требовать рассмотрения, возможно, более приемлемых альтернатив. Если CIO добивается прозрачности деятельности и обоснованности выносимых на его уровень решений, CTO является той важной ролью, которая обеспечивает баланс интересов руководителей других отделов, входящих в блок ИТ (и, кстати, позволяет снизить коррупционные риски).

Ну а что касается компетенций CTO — по большому счету, это enterprise architect (т.е. отвечает в большей степени на вопрос «что», а не на вопрос «как», в отличие от архитектора решений), умеющий общаться с заинтересованными лицами со стороны бизнеса, обладающий полномочиями принятия определенных решений, а значит, понимающий что есть риск менеджмент, что есть принцип «good enough» (достаточно хорошо, но не более ;) для баланса затрат и ожидаемого эффекта, и, разумеется, имеющий опыт проектной деятельности, помещающий руководителя в железный треугольник содержания, сроков и ресурсов (и «покрашенный’ в цвет заданного, а если быть более точным — приемлемого уровня качества). Должен ли CTO знать все технологии и решения — от железа до ERP? это невозможно (мы не в конце 80-х/начале 90-х, когда прикладной разработчик пересобирал комп под себя, автоматизировал бизнес-процессы и при этом разбирался в прерываниях DOS). Но понимать тренды, что происходит в ИТ бизнесе (включая бизнес-модели оказания услуг — того же аутсоурсинга во всех своих проявлениях) — для CTO это must. Иначе, какой из него decision maker? а если он не принимает решений — он уже не CTO ;)