Портфель ИТ-инициатив во многих компаниях живет в режиме «срочно и еще вчера», где приоритеты прыгают, проекты зависают в «вечном пилоте», а стоимость владения растет незаметно просто потому, что решения принимаются по отдельным задачам, а не по эффекту и рискам. На виртуальном круглом столе, организованном журналом IT Manager и клубом «ИТ-Диалог», ИТ-директора российских компаний говорили о том, как ИТ выйти из роли исполнителя и стать партнером, который разделяет ответственность за результат. Логика партнерства здесь упирается не в скорость поставки функций. Важнее договориться о правилах: кто формулирует инициативы и как их «приземляют» до измеримого эффекта, кто принимает решения по приоритетам, где проходит граница между «надо сделать» и «имеет смысл делать сейчас» и как заранее считать цену изменений — в деньгах, устойчивости процессов и управляемости рисков.
Право на партнерство
У темы бизнес-партнерства длинная история, но вопросы остаются прежними — что именно стоит за словом «партнер» и чем ИТ должно быть внутри компании, чтобы на это претендовать.
В понимании Ольги Щепуновой (клуб 4CIO) бизнес-партнерство начинается с равной позиции и правильного формата запроса. Она обращает внимание на типичную ситуацию, когда бизнес приносит в ИТ детальные задания «низкого уровня», вроде просьбы «сделать кнопку», но не объясняет, какая проблема и какая цель за этим стоят. В такой модели ИТ неизбежно остается подразделением, которое просто выполняет поручения, тогда как партнерский формат предполагает, что бизнес приходит с идеей и потребностью, а ИТ помогает упаковать ее в решение, если это в его зоне влияния. Вторая сторона партнерства — способность ИТ предлагать неочевидные бизнесу варианты и приносить свой опыт как добавленную ценность. Тему различий между отраслями эксперт описывает через контекст: в рознице, финтехе и телекоме зависимость от ИТ давно стала базовой и без ИТ-систем компания просто не работает. При этом в сфере онлайн-образования, по ее наблюдениям, встречается другой перекос — там бизнес может иногда недооценивать возможности ИТ и тем самым ограничивать свою траекторию развития.
Алексей Максимачев (EMS Family clinic) считает решающим фактором не рынок, а конкретную компанию и ее управленческую культуру. В любой сфере, по его словам, встречаются и закрытые структуры с жесткой вертикалью, где не слышат не только ИТ, но и другие функции. А потому шанс на партнерство появляется там, где руководитель ИТ готов не ограничиваться ролью исполнителя, а участвовать в принятии решений и аргументировать инициативы языком бизнес-эффекта — что это даст компании или чего она лишится при отсутствии решения. К тому же он намеренно разделяет уровни: партнерство, как он его понимает, складывается на верхнем управленческом уровне, тогда как само ИТ-подразделение в повседневности все равно во многом остается исполнительской структурой.
Жизненный цикл ИТ-ресурсов как управляемый процесс
При этом участники фиксируют, что даже если «отрасль не решает», контекст все равно влияет на то, какими именно компетенциями ИТ доказывает свою партнерскую роль. По мнению Андрея Ложечникова (Каппа Рус), промышленность именно такой пример, где акценты смещаются. Он связывает партнерство с тремя функциями — глубоким знанием предметной области и бизнес-процессов, умением анализировать возможности и с коммерческой составляющей, то есть способностью оформить решение так, чтобы оно было понятно бизнесу и получало поддержку не только у непосредственного заказчика, но и у смежных подразделений. В таком случае ИТ-команда постепенно уходит от чисто технической роли к роли предложения: сначала формируется «макет» решения, затем он обсуждается с заказчиком и уже это обсуждение помогает убедиться, что задача понята правильно и реализуется экономически оправданно. В самой идее бизнес-партнерства ключевое слово — «партнер», и эта конструкция не может работать в одну сторону, добавляет Евгений Богорад (клуб «ИТ-Диалог»). В его понимании не только ИТ должно выстраивать партнерскую модель, но и бизнесу нужна готовность к ней — к совместной работе и ответственности, а не только к передаче задач на исполнение.
Шкала влияния и точка опоры
Во многих компаниях роль ИТ различается не по названию департамента, а по степени влияния технологий на бизнес-результат. В одном случае ИТ в основном облегчает труд и поддерживает учетные функции, в другом — обеспечивает ключевые процессы, а в третьем становится встроенной частью продукта или самим продуктом. От этой позиции на шкале зависит и реалистичность ожиданий от «бизнес-партнерства»: чем ближе ИТ к продукту и критичным процессам, тем важнее совместная ответственность за эффект, риски и стоимость владения, а не только за поставку функций.
Если развитие и изменения проходят через внешних поставщиков решений, значение имеют не столько формальные роли «интегратор/вендор», сколько то, что именно привносится в компанию: только инструменты или вместе с ними практики управления и единая информационная культура. По словам Ивана Хрулева («Группа Астра»), здесь большую роль играет коммерческий контур клиента, так как именно он помогает понять отраслевые нюансы, будь то регуляторика, отношение к legacy или темпы инноваций, и за счет этого точнее настроить внедрение под реальные ограничения и приоритеты. В разных организациях запрос к ИТ может выглядеть по-разному. Где-то на первом плане оптимизация процессов, где-то — повышение прозрачности через аналитику и мониторинг, вплоть до измеримых оценок эффективности не только ИТ-процессов, но и смежных участков. При этом партнерство часто буксует из-за отсутствия единого стандарта управления. Некоторые инженеры и департаменты работают каждый по-своему, а руководству непонятно, что именно делается и насколько это эффективно. В таких условиях единый стандарт автоматизации становится практическим способом выровнять подходы и сделать управление наблюдаемым на разных уровнях — независимо от отрасли.
Еще один принципиальный вопрос бизнес-партнерства — для кого именно внутри компании ИТ становится партнером. Ориентиром может быть первое лицо, руководители доходных направлений, владельцы процессов или широкая пользовательская аудитория. Пока эта точка не определена, инициативы легко превращаются в конкурирующий набор задач, где эффект измеряется разными линейками, а ответственность размывается между «заказали» и «сделали». Партнерство в этой теме описывается не как «хорошие отношения», а как взаимная выгода и приведение к единому уровню понимания задачи партнерами. По словам Андрея Ложечникова, сама идея предполагает стратегию, где выигрывают оба, а значит, если одна сторона не дотягивает по компетенциям или пониманию контекста, вторая заинтересована помочь «подтянуться», иначе сотрудничество не будет равноправным. В этой логике роль тех, кто внедряет решения, — не просто поставить инструмент, а сделать так, чтобы стороны одинаково понимали, что и зачем меняется, и могли обсуждать результат на одном языке, без перевода «с бизнесового на технический» и обратно.
Практический вопрос «кто заказчик внутри компании?» в такой модели тоже перестает быть формальностью. В понимании эксперта, опорная точка — руководители бизнес-подразделений, потому что именно они отвечают за бизнес-ценность. Но потребность не всегда рождается «сверху»: внутри подразделений часто есть активные сотрудники, которые первыми чувствуют проблему, умеют ее сформулировать и донести так, чтобы идея была услышана на уровне руководителя. Схожую мысль про «двустороннее движение» высказала и Ольга Щепунова: ИТ приходится одновременно подниматься до уровня бизнес-обсуждения и в моменты, когда ИТ выступает лидером, подтягивать бизнес к более «взрослой» постановке запросов. Ее опыт показывает, что в сложившейся организации партнерство не возникает автоматически из должности — приходится искать те подразделения и тех руководителей, с кем можно двигаться вперед, чаще всего на уровне топ-2 и ниже. И здесь точкой опоры может стать вовсе не стратегический комитет, а «низовой» источник решения проблем — техподдержка и поддержка программных продуктов, где концентрируются повторяющиеся проблемы пользователей и процессы, которые можно улучшать.
Она описывает это как постепенное завоевание доверия через устранение конкретных сбоев и приведение процессов в порядок, например, когда становится понятно, что данные не должны вноситься «в десятки мест», если можно выстроить единый контур. «Техподдержка — хороший источник именно болей, которые мы можем снять», — добавляет Ольга.
В этой логике особую ценность получает не сама линия поддержки, а данные, которые она собирает. При хорошо выстроенной системе техподдержки именно аналитика обращений становится опорой для управленческих решений ИТ-директора — от выявления повторяющихся болей до планирования ресурсов и денег на следующий год.
Ответственность как инструмент управления
Есть еще один вопрос бизнес-партнерства — как распределять роли и ответственность между бизнесом и ИТ, чтобы «драйвер цифровизации» не оставался лозунгом. Пока не определены границы «кто отвечает за результат» и «кто отвечает за способ», инициативы легко превращаются в набор ожиданий, когда бизнес приносит запрос, ИТ делает решение, а на выходе спорят, что считать успехом и кто должен был об этом заранее договориться.
Что делать, если запросов на изменения много, а готовности владеть сервисом или процессом заметно меньше? По наблюдениям модератора дискуссии Сергея Горшенина (Кузница Управленческого Бэкграунда), бизнес-заказчики нередко хотят более получить качественный продукт или сервис, но не спешат становиться владельцами результата — и это уже вопрос не регламента, а информационной культуры как части корпоративной культуры. В этой точке партнерство перестает быть декларацией, поскольку без человека со стороны бизнеса, который принимает ответственность за бизнес-процесс, обсуждать эффект и измерять успех становится просто не с кем.
Действительно, здесь не работает административный нажим. «Насильно мил не будешь и насильно вытащить бизнес-заказчика, если он не готов стать бизнес-партнером, — это утопия. Надо искать тех, кто готов, или тех, кто хотя бы хочет и попробовать», — говорит Ольга Щепунова. Поэтому ставку нужно делать на поиск руководителей и команд, готовых стать владельцами процессов или продуктов, и на выстраивание с ними модели win-win — иначе ИТ снова остается исполнителем чужих задач. При этом внутри связки должен быть человек, который удерживает соответствие решения бизнес-потребности.
Даже когда владелец результата найден, остается еще одна типовая слабая точка — как описывать инициативу так, чтобы ее можно было запускать в работу и потом спрашивать за результат. Здесь, как считает Алексей Максимачев, в компаниях встречаются очень разные практики: далеко не всегда есть «зарегулированный» формат, а инициатива часто начинается с наблюдений на совещаниях, цифр, проблем «в поле» и предложений со стороны ИТ. Но независимо от формы фиксация все равно необходима хотя бы потому, что без нее размываются ожидания и непонятно, что именно приносит бизнесу предлагаемое изменение. И здесь критичен не шаблон документа, а то, что в нем должно быть: зачем это нужно бизнесу, какой эффект ожидается и почему это важно именно сейчас — с учетом того, что даже сильная идея может быть отложена, если для компании «не время» и приоритеты в другом месте.
Архитектор, сценарий, локомотив
Один из практических способов не превращать инициативы в вечную очередь — заранее договориться, где заканчивается мелкая доработка и начинается проект со своими правилами отбора и ответственности. По словам Евгения Богорада, на практике это можно развести довольно просто: небольшие изменения уходят в обычную заявку через сервис-деск, а более серьезные инициативы переводятся в проектный контур. Там уже появляется формальная рамка — регламент по проекту, рассмотрение в проектном офисе и сравнение по ожидаемым бенефитам, чтобы приоритизировать не по громкости запроса, а по выгоде для бизнеса.
Даже при отсутствии «единого правильного документа» вопрос упирается не столько в форму, сколько в роли, которые удерживают инициативу на всем пути — от идеи до запуска. Критично, чтобы в процессе были задействованы разные компетенции, считает Андрей Ложечников. Первая — это автор идеи, тот человек, который приносит первоначальную ценность и формулирует, ради чего вообще стоит начинать. При этом эксперт отмечает типичную проблему жизненного цикла: авторы часто «перегорают» ближе к середине и теряют интерес, когда начинается рутинная работа по доведению до результата, поэтому на одном энтузиазме проект не удержать. Вторая — архитектор идеи, чаще со стороны ИТ. Это аналитик или специалист — он вместе с ключевыми участниками собирает детали и переводит намерение в понятную конструкцию требований, из которой дальше может сложиться техническое задание и план работ. Третья связана с описанием сценария будущего — визуализацией того, как должно выглядеть целевое состояние после внедрения, иногда в нескольких вариантах, чтобы участники одинаково понимали, к чему идут и что именно меняется в процессе. И наконец, нужна отдельная «тяговая» — локомотив, способный довести проект до запуска: финальные согласования, организационную рутину и задачи, без которых решение не становится работающим сервисом.
Приоритизация в масштабе компании
Когда бизнес становится слишком проактивным, партнерская модель проверяется на прочность, запросов и хотелок больше, чем ИТ способно переварить, а выбор «берем это — откладываем то» легко превращается в соревнование голосов. В такой ситуации важно не только разложить входящий поток по приоритетам, но и удержать отношения с теми подразделениями, чьи инициативы не попали в работу, иначе вместо партнерства получается очередь обиженных.
В понимании Ивана Хрулева опорой для такого отбора становятся измеримые критерии — эффект, риски и ресурсная цена изменений, включая совокупную стоимость владения. Он описывает подход как прикладную проверку нескольких запросов по одной логике: что дает компании результат, какие риски несет и во сколько обойдется по людям и времени. «Здесь все упирается в бизнес-эффективность, риски и совокупную стоимость. Во что это обойдется компании в деньгах и ресурсах. Когда такие оценки есть по нескольким запросам, становится понятно, что брать в работу в первую очередь и как аргументировать отказ по остальным», — комментирует Иван. Эта рамка нужна не для того, чтобы отфутболить неудобные просьбы, а чтобы отказ можно было обосновать и сделать его управленческим решением, а не эмоциональной реакцией на очередной запрос.
Отдельная сложность — кто внутри компании должен сводить «чаши весов»: сколько стоит изменение и что оно даст бизнесу. По словам спикера, эту роль логично закреплять за владельцем продукта, так как именно он выступает переводчиком между ИТ и бизнесом, знает, что требуется сделать, может собрать верхнеуровневую оценку затрат и эффекта, а затем представить ее стейкхолдерам и топ-менеджменту. Внутреннюю сторону цены он связывает не только с бюджетом подрядчиков или инфраструктуры, но и с ресурсами самой компании — временем инженеров и вовлеченностью внутренних команд, которые тоже «платят» своим рабочим временем за внедрение.
При этом риск приоритизации не исчерпывается сравнением двух-трех инициатив «на входе». В управленческой практике иногда видно, что один проект дает очевидный выигрыш конкретному подразделению, но при более глубоком разборе оказывается, что другие направления начинают терять — и в масштабе компании итоговый эффект может стать отрицательным. Поэтому всегда приходится проверять, не пострадают ли остальные, и такой контроль рисков нужен на постоянной основе.
Даже когда приоритизация опирается на эффект, риски и стоимость ресурсов, остается принципиальный вопрос — кто принимает решение и на чьей стороне ответственность за выбор. Если арбитром становится само ИТ, партнерство легко скатывается во внутреннюю политику: одним сделали, другим отказали, а спор уходит в плоскость «кто громче». В понимании Алексея Максимачева это именно то место, где приоритеты должен определять не ИТ-директор в одиночку, а бизнес вместе с ИТ, на уровне компании, а не отдельных функций. Критичны прозрачность ограничений и общая площадка, где инициаторы защищают свои предложения перед другими руководителями бизнеса, а не «доказывают айтишникам», почему их запрос важнее.
В этой же рамке укрепляется позиция ИТ как партнера. В компаниях, где ИТ не является конечным продуктом, технологии остаются инструментом для эффективности и устойчивости процессов. Отсюда неизбежно возникает вопрос о цене владения. Закупка или внедрение — лишь первая часть решения, дальше начинается обслуживание, поддержка и последствия для операционного бюджета.
Как отмечает Евгений Богорад, на практике подразделения часто тянут одеяло на себя — всем нужно разное, «все и сразу», при ограниченных ресурсах. Поэтому одной площадки для обсуждения недостаточно, нужна финансовая модель, которая считает выгоду не локально для одного отдела, а для компании в целом, и уже на основании общей картины принимаются решения, что делать в первую, вторую, третью очередь. Отдельной «жесткой» категорией он называет требования регулятора: такие задачи вытесняют остальной портфель и неизбежно меняют приоритеты, как бы они ни были согласованы заранее.
Как ИТ набирает авторитет
Когда приоритеты и правила отбора хоть как-то выстроены, следующая опора партнерства — статус ИТ внутри компании. Без него любые комитеты и модели быстро превращаются в формальность — договоренности есть, но вес ИТ в принятии решений остается «служебным», и портфель снова начинает жить по инерции.
В понимании Ольги Щепуновой позиция ИТ-руководителя держится на двух вещах — на знании бизнеса и на доверии, подтвержденном действиями. Речь не про «табличку» в оргструктуре, а про включенность в обсуждение бизнес-результатов и способность говорить с руководителями функций на равных. «Его должны туда звать не столько потому, что у него должность называется «директор», а потому что другие подразделения видят его заинтересованность в бизнес-результатах», — говорит она. При этом доверие должно быть привязано к предсказуемости — к выполнению обязательств в согласованные сроки и к тому, что тот же подход становится нормой для команды, а не личным стилем одного руководителя.
Со стороны ИТ-подразделения Андрей Ложечников описывает похожую логику через состав команды и качество «слушания» бизнеса. Он отмечает, что особенно полезны люди с бизнес-опытом, потому что они помогают снять ИТ-категоричность и обсуждать инициативы не только через риски и расходы: «Это, как правило, самые ценные сотрудники с точки зрения партнерства и бизнеса. Потому что они умеют слушать бизнес, они позволяют преодолеть стереотипы типичной ИТ-модели представлений и посмотреть на проблемы совершенно иными глазами: не с точки зрения рисков, не с точки зрения трат, а с точки зрения тех выгод, которые может решение принести», — говорит эксперт.
То, что помогает ИТ удерживать партнерскую позицию, часто начинается не с регламентов, а со смены инфраструктуры внутри самой функции. По наблюдениям Сергея Горшенина, для многих ИТ-руководителей это отдельная «управленческая ломка»: в ИТ часто приходят «по любви» и продолжают мыслить категориями автоматизации и оптимизации, даже став руководителями. Люди с бизнес-опытом внутри ИТ, по его словам, ускоряют этот переход и помогают выйти из привычной парадигмы. Это же проявляется и в техподдержке, как в точке, где партнерство проверяется на практике, через коммуникацию и понимание проблемы пользователя. В его примере сильная первая линия нередко держится не на технарях, а на тех, кто умеет разговаривать и разбирать ситуацию: «Самые классные специалисты в техподдержке — это люди с гуманитарным образованием, которые в первую очередь умеют хорошо коммуницировать, их проще научить каким-то азам ИТ, нежели технарей научить хорошо разговаривать».
Отказ как управленческое решение
Может ли поставщик сказать «нет», когда инициатива исходит от топ-менеджера заказчика? В понимании Ивана Хрулева отказ — не жест ради принципа, а управленческая защита продукта и репутации: идеи, которые уводят решение в сторону «костылей» и кастомизаций, оцениваются через данные и последствия для базовой логики продукта, для рынка и для имиджа. При этом он подчеркивает, что цена «да» иногда оказывается выше, чем цена «нет». Так одно неудачное кастомное решение может «аукнуться» позже и стоить дороже, чем потеря конкретной сделки.
Сильнее всего эта позиция работает в долгой связке, когда поставщик думает не разовой выгодой, а отношением на перспективу. Здесь партнерство измеряется не готовностью «все сделать», а готовностью удерживать рамку — что действительно дает ценность, а что создает долг.
При этом в связке «бизнес — внутреннее ИТ — внешнее ИТ» критично не обходить внутреннего партнера. Спикер подчеркивает, что технические команды начинают работу с архитекторами и ИТ-руководителями заказчика, а не напрямую с коммерческим топ-менеджментом; общение с ЛПР по деньгам обычно возникает на финальных стадиях крупных внедрений. Это важный нюанс для партнерства: если внешний поставщик разговаривает только с «верхом» и минует ИТ-руководителя, у компании ломается тройственная конструкция ответственности и внутреннему ИТ становится сложнее удерживать роль переводчика, владельца решения и защитника общей управляемости.
В партнерской модели право на «нет» становится частью управляемости. Без него ИТ не может защищать ни ресурсы, ни устойчивость решений, ни стоимость владения. При этом «нет» работает только тогда, когда его воспринимают не как отказ «по настроению», а как позицию функции, которая отвечает за результат вместе с бизнесом.
Когда ИТ-директор говорит «нет»? По мнению Алексея Максимачева такое право не появляется автоматически из должности. Оно держится на весе в компании и на том, насколько мнение ИТ принято — от пользователей до собственника. Основание у этого веса приземленное: опыт, компетенции и привычка разбирать неудачи так, чтобы коллеги видели, что ошибки превращаются в изменения, а не заметаются под ковер. «Наверное, открытостью, прозрачностью, опытом, компетенциями», — так он перечисляет то, что помогает ИТ-руководителю быть услышанным, даже когда ответ неудобный.
При этом отказ не может быть только «обоснованным» с точки зрения ИТ — важнее понимать, зачем инициатива нужна другой стороне. Спикер отдельно подчеркивает, что перед «нет» важно услышать мотив и потребность оппонента: «Здесь очень важно услышать, почему это нужно твоему оппоненту». Бизнес может осознанно принимать риски, которые ИТ считает чрезмерными, и тогда спор идет не про «правильно/неправильно», а про выбор в системе координат компании и про то, кто берет на себя последствия этого выбора.
Из этой же логики вырастает самая болезненная часть отказа — когда речь не о старте, а о пересборке или остановке инициативы на середине пути. Здесь «нет» становится не жестом, а управленческим решением с политическими последствиями: как остановить проект без ощущения, что подразделение «бросили», и как объяснить это так, чтобы осталась возможность работать дальше — уже в рамках общих правил и общей ответственности.
Право на «нет» в партнерской модели держится не на аргументах как таковых, а на доверии и авторитете — иначе отказ остается звуком. Можно сколько угодно говорить «нет», но «толку от этого не будет», если у ИТ-руководителя нет признанного веса и кредита доверия. При этом доверие работает как ускоритель: «Иногда, когда человеку уже доверяют, он действительно может сказать нет. И особого обоснования не потребуется, потому что ему доверяют», — добавляет Ольга Щепунова.
Когда речь идет не о «нет» на входе, а об остановке проекта на середине, ставка на доверие становится еще выше, потому что политические потери почти неизбежны. По ее словам, универсального рецепта «как выйти без потерь» нет, но есть набор практик, которые снижают ущерб. Во-первых, нужна честность, но с мерой — «иногда честность бывает излишней», поэтому важно не навредить себе и команде формой подачи. Во-вторых, важно заранее продумать минимизацию рисков — от недополученной прибыли до последствий для смежных процессов — и вынести это в обсуждение не тогда, когда проект уже фактически провалился, а в тот момент, когда его еще можно остановить или пересобрать с минимальными потерями для бизнеса и отношений между командами.
Тема «права на нет» упирается не столько в формулировки, сколько в личный и институциональный вес ИТ, но здесь важно различать внешнюю оболочку и реальную опору. По словам Сергея Горшенина, статус легко спутать с авторитетом, хотя это разные вещи: статус — про должность и «внешнюю обертку», позиция — про принципы и лояльность интересам компании, а авторитет — про то, как человека воспринимают люди. Отдельно он связывает управляемость с доверием, причем не в общем смысле, а как с рабочим ресурсом, который экономит время и снижает трение. В качестве примера он приводит собственный опыт бюджетирования: сначала защита бюджета занимала месяцы, а позже свелась к короткому циклу вопросов и утверждения: «Через 15 минут я получил подписанный бюджет». Для него это и есть практическое проявление доверия, когда руководителю верят не потому, что он убедительно говорит, а потому что он системно действует в интересах бизнеса и предсказуем в последствиях своих решений.
Согласования как часть маршрута
Та же тема доверия выводит на «неудобных партнеров» внутри компании — безопасность, юристов, закупки и договорные подразделения, которые ИТ часто воспринимает как тормоз. В этом месте напряжение возникает не из-за чьей-то «вредности», а из-за разницы в целях и метриках: ИТ хочет скорости, контролирующие функции отвечают за ограничения и последствия. По словам Евгения Богорада, это ощущение понятно, но одностороннее: «Понятно, что, когда нет ограничений, действовать можно быстрее. Но мы живем в мире ограничений, и лучше немного замедлиться и сохранить бизнес, чем поспешить и врезаться в стену». В его понимании проблема чаще не в самих функциях контроля, а в том, что компании не умеют учитывать их как часть нормального производственного цикла. Если процессы выстроены и заранее заложено «логистическое плечо» на закупку и согласования, то конфликт «вы нам мешаете» становится управляемым: сроки предсказуемы, ответственность распределена, а требования перестают выглядеть как внезапные стоп-сигналы.
Ощущение, что безопасность, юристы и закупки «тормозят», чаще связано не с их ролью, а с тем, когда их подключают. Контролирующие функции действительно становятся охлаждающим фактором, если появляются слишком поздно, когда решение уже придумано и его хочется просто «быстро протащить», – считает Иван Хрулев. Но при встраивании ИБ и юристов в начало потока согласования они, наоборот, начинают ускорять работу, получается меньше возвратов, меньше переделок, меньше сюрпризов на финише.
Вопрос партнерства упирается в привычку смотреть на инициативы не как на поле борьбы ИТ и бизнеса, а как на площадку, где можно собрать управляемое решение с учетом выгод и рисков. По словам Ивана, это про процесс, который помогает развиваться обеим сторонам, и ИТ-команде, и бизнес-команде, если в нем заранее зафиксированы ограничения и ожидаемый результат.
***
Основной вывод дискуссии – партнерство держится на управляемости. Бизнесу важно, чтобы решения по инициативам принимались предсказуемо, с понятным владельцем результата, прозрачной приоритизацией и расчетом цены изменений, включая дальнейшую поддержку. ИТ сохраняет роль партнера там, где умеет держать рамку, спокойно объяснять ограничения, отказывать без конфликта и вовремя останавливать проекты, пока они не начали тянуть деньги и людей без отдачи.