Инна Сенчугова: «Если решение не сокращает издержки и не снижает риски — зачем оно бизнесу?»
Инна, с прошлого интервью прошло несколько лет. Какие изменения в работе ИТ-директора вы почувствовали особенно сильно — в задачах, подходах, ожиданиях?
Для меня изменилось очень многое. В первую очередь — сфера деятельности. Раньше я была ИТ-директором производственных предприятий, в том числе в машиностроении, а сейчас работаю в сфере культуры и искусства. Вместе с этим поменялся и контекст. Если прежде это были корпорации и холдинги, то теперь — бюджетные учреждения.
За это же время заметно ускорились технологии. Быстрее появляются новые решения, быстрее их пытаются внедрять, и параллельно меняется запрос со стороны бизнеса. Если раньше часто искали универсальные варианты «на все случаи», то сегодня ожидания становятся гораздо более точечными. Все чаще требуется глубокая специализация и понимание отраслевой специфики.
Поэтому, чтобы быть эффективным, важно разбираться в ключевых бизнес-процессах, учитывать регуляторные требования и трезво оценивать риски, включая киберриски. Их вес за последние годы явно вырос. Условно говоря, раньше «поставили антивирус» — и казалось, что на этом вопрос закрыт. Сейчас так уже не работает. Нужна стратегия, нужны приоритеты и ясное понимание, что и зачем внедрять в первую очередь.
Изменились ли ожидания бизнеса? Есть ли разница по сравнению с тем, что было два-три года назад? Многие ИТ-директора говорят, что бизнес стал лучше разбираться в цифре.
Это действительно так. Сегодня бизнес ожидает не просто внедрения или автоматизации отдельного процесса. Ему важно получить устойчивое и безопасное решение, которое будет напрямую влиять на ключевые показатели. Речь про сокращение издержек, рост прибыли, снижение рисков.
Поэтому, когда обсуждается та или иная технология, смотрят на измеримый эффект и уже по этим «цифрам» принимают решение. Раньше, как мне кажется, было проще. Условно «автоматизируйте бухгалтерию» — и этого хватало. Сейчас же нужно четко понимать, зачем проект делается, какую задачу закрывает, какую стратегическую цель позволяет достигнуть и какими показателями это будет подтверждаться.
Я слышала от ваших коллег ИТ-директоров, что если раньше бизнес часто говорил «давайте попробуем», то сейчас такой возможности из-за бюджетных ограничений почти нет. Это так?
Совершенно верно. Если речь о пилоте, то чаще всего он теперь делается бесплатно — когда поставщик или внедренец заинтересован в продвижении продукта либо это уже хорошо продуманное решение с техническим заданием, с которым можно выходить на большой проект. Формат «что-то попробуем» сейчас встречается все реже. Все понимают, что это время, деньги и ресурсы.
Как вы расставляете приоритеты между «сделать новое» и «починить фундамент»?
Решение вопроса напрямую зависит от постановки задачи и анализа потенциальных последствий.
Нужно понять, что будет дороже, что дешевле, а также хватает ли ресурсов и времени. Фундамент, конечно, выходит на первый план, когда есть риски по безопасности — и для данных, и для пользователей. То же самое происходит, когда начинаются сложности в операционной работе. Если что-то регулярно ломается и останавливает бизнес-процесс, значит, приходится возвращаться к основе и приводить ее в порядок.
Еще один критерий — возможность развития. Если на текущем основании продукт невозможно развивать и добавлять новые функции, то попытка «строить сверху» будет упираться в ограничения, заложенные изначально.
Приведу пример из практики. Есть продукт, над которым мы работали пять лет. Он стабильно функционирует, устраивает бизнес-заказчиков, его поддерживают программисты. Но в какой-то момент мы решили выйти на новый уровень и добавить юзабилити, BI-аналитику и веб-версию, чтобы иметь возможность удобной удаленной работы с продуктом. И в процессе выяснилось, что фундамент, заложенный в продукт ранее, не дает нам развиваться дальше.
В итоге мы выбрали другой сценарий. Текущий продукт не развиваем, продолжаем на нем стабильно работать, но параллельно создаем версию 2.0. Берем новый технологический стек и уже в него закладываем нужные функции, чтобы дальнейшее развитие было полноценным.
Вы участвовали в «ИТ-Диалоге», где обсуждали свою разработку и готовое ПО. Многие ИТ-директора после опыта собственной разработки говорят «never again» и стараются покупать. Вы с этим согласны?
Если есть готовое решение, его чаще разумнее взять, чем писать с нуля и создавать новый продукт. У готовых решений обычно есть поддержка и обновления, а также уже учтены многие требования по информационной безопасности. Это понятная модель.
Когда мы делаем сами, рисков больше. Во-первых, в ходе работы можно допустить ошибки, что-то не учесть или неправильно заложить на старте. Во-вторых, это почти всегда финансово затратнее, чем выбрать готовый продукт. Поэтому если бы то, что мы сейчас реализуем, существовало на рынке в виде зрелого решения, мы бы, конечно, пошли по этому пути. Но подходящего варианта просто нет. У нас есть ранее созданный продукт, и сейчас мы будем брать его за основу. Где-то переносить отдельные фрагменты кода, где-то дорабатывать, но с нуля начинать не будем.
У готового решения есть риск зависимости от вендора, особенно если продукт уникальный. На что вы смотрите при выборе поставщика и решения, чтобы не попасть в ловушку? Какие критерии для вас ключевые?
Для меня принципиально важно, чтобы у нас была возможность сопровождать и развивать решение. В идеале это означает доступный код и возможность вносить изменения своими ресурсами. Либо с помощью текущего поставщика, либо с привлечением другой команды.
Если код закрыт, мы рискуем попасть в ловушку. Возникает зависимость от того, будет ли поставщик работать, сколько он продержится на рынке и на каких условиях продолжит поддержку. И кстати, этот же принцип важен и тогда, когда мы идем в разработку вместе с подрядчиком. Нужно заранее обеспечить, чтобы после завершения проекта у нас оставалась полноценная возможность дальше сопровождать продукт самостоятельно.
Тогда еще про типичную ситуацию. Что вы делаете, когда бизнес просит сделать что-то очень быстро, а вы понимаете, что это принесет риски или технический долг? Как вы аргументируете свою позицию?
Сначала я стараюсь понять, почему именно «быстро» и чем это обусловлено. Какой бизнес-эффект хотят получить и к какой дате он нужен. Дальше я формулирую риски и последствия. Что именно может случиться, если мы поторопимся, где потеряем в качестве, безопасности или устойчивости.
При этом я никогда не отвечаю в стиле «это невозможно» или «мы так делать не будем». Бизнес такие ответы не принимает. Вместо этого предлагаю варианты. Можно сделать быстро, но с понятным уровнем риска и с объяснением, что мы сэкономим и что можем потерять. Можно сделать сбалансированно, оптимально по срокам и качеству. А можно надежно, но дольше. То есть, по сути, предложить несколько сценариев, показать компромиссы и уже вместе с заказчиком выбрать путь, который подходит именно для этой задачи.
Бывало ли, что поставщик пытался «обойти» ИТ и продать решение напрямую бизнесу или первому лицу, чтобы у ИТ-директора не было шанса «зарубить»?
К счастью, у меня такое случалось очень редко. В бизнесе обычно работает простая логика. Руководитель доверяет твоему экспертному мнению, поэтому даже если к нему приходит продавец с красивой презентацией и обещанием «через неделю все будет работать», то дальше все равно спрашивают оценку у ИТ.
Да, в практике бывали ситуации, когда «заходили» через руководителя, показывали, как решение может всем помочь. Но дальше презентация попадала ко мне, я глубже погружалась в детали и уже объясняла руководителю, что решение может быть хорошим и рабочим, но у него есть нюансы, которые важно учитывать.
Какая, на ваш взгляд, самая дорогая ошибка ИТ-руководителя? Без деталей и без названий.
Недооценка рисков информационной безопасности. Такие риски могут привести и к потере данных, и к остановке процессов, и к репутационным последствиям, и к штрафам. Сейчас особенно строго с защитой персональных данных.
Недавно в рамках аудита мы оценивали, во сколько может обойтись ошибка, связанная с утечкой данных в одной из систем с большим объемом персональной информации. По расчетам получилась сумма штрафа больше 10 миллионов рублей плюс правовая ответственность руководства. Поэтому ИТ-руководитель обязан воспринимать информационную безопасность как фундамент для любых решений, будь то инфраструктура, внедрение продукта или запуск новой технологии.
Многие безопасники говорят о киберграмотности и киберкультуре как о постоянной работе с пользователями. Вы согласны с таким подходом?
Абсолютно согласна и поддерживаю. Мы недавно проводили аудит по информационной безопасности, и один из его пунктов был про оценку практических привычек сотрудников. Мы собрали фокус-группу из десяти человек из разных подразделений. Аудитор задавал им вопросы из повседневных сценариев. Где вы храните пароли? Как отреагируете на письмо с определенными признаками? Что сделаете в конкретной ситуации? И так далее.
Важно, что это делалось не для того, чтобы потом кого-то «наказывать», а чтобы собрать и консолидировать ответы. И по итогам выяснилось, что примерно 30 процентов сотрудников разбираются в теме глубже, а остальные, несмотря на регламенты, инструкции и подписи под ними, не знают даже ключевых правил. Так мы увидели серьезный пробел.
Зато это помогло сформировать план обучения и развития культуры безопасности. Тренинги, материалы, рассылки с понятными примерами и визуальными подсказками, чтобы действительно привлекать внимание. Для отдельных групп, возможно, будут и более углубленные курсы. И отдельно я слежу за обучением ИТ-сотрудников, потому что при наличии привилегированных прав они тоже становятся заметной целью для атак.
Какие еще уязвимые места вы видите в информационной безопасности?
Для меня одна из самых заметных проблем — текучка. Особенно среди специалистов техподдержки. Приходят, полгода поработают и уходят. Часто это молодые ребята. Кому-то становится скучно, кто-то находит что-то интереснее — и люди быстро меняются.
При этом техподдержка — это как раз те, кто «компьютер настрой, программу установи», но у них обычно есть привилегированные права. То есть доступ к ресурсам у них шире, чем у большинства пользователей. И здесь риск выше.
Поэтому сейчас, пока мы настраиваем DLP, я в первую очередь беру такие роли на мониторинг и контроль действий в корпоративной сети. Плюс у них отключены флешки. Потому что сценарии бывают разные. Один человек просто пришел, ему не понравилось — и он ушел. А другой может прийти целенаправленно, чтобы что-то получить. Скопировать данные, выгрузить файлы и исчезнуть.
Сейчас мы вместе со специалистом по ИБ разрабатываем план именно под новых сотрудников. Какие должности нужно отслеживать особенно внимательно с первого дня, когда человек только пришел. Понятно, что и «старые» могут повести себя по-разному, но к новичкам внимания больше.
Какие темы по кибербезопасности вы считаете обязательными для ИТ-директора, даже если в компании есть отдельная функция или служба ИБ?
Во-первых, ИТ-директору важно разбираться в нормативной базе. Например, в требованиях 152-ФЗ, понимать базовые принципы и регламенты, а также ориентироваться в регуляторных требованиях и стандартах, которые применимы к компании. И, что не менее важно, постоянно отслеживать изменения в законодательстве.
Во-вторых, аудит информационной безопасности должен быть регулярной практикой. У нас в компаниях аудит проводили уже дважды, и сейчас мы делаем это ежегодно. Причем берем разных исполнителей. В первый год одна компания проводит проверку, фиксирует находки и дает перечень мероприятий. В следующий раз мы сверяемся. Что закрыли, что отработали, что осталось, что проявилось снова. Так шаг за шагом можно закрывать уязвимости, которые вообще удается обнаружить.
Еще один обязательный блок — понимание того, как изменения в ИТ-ландшафте влияют на безопасность. Внедрение новых систем, обновления ПО, обновление сетевых устройств. Сначала нужно оценить последствия для безопасности, а потом уже внедрять.
Отдельное внимание — резервному копированию, чтобы обеспечивать сохранность данных. И конечно, обучение пользователей и собственного персонала культуре безопасности.
Плюс ИТ-директор должен понимать и техническую сторону. Какие средства защиты существуют, какие задачи они закрывают, как их можно применить в компании. Я сама постоянно учусь, смотрю, какие продукты появляются, что нового на рынке. У нас есть план внедрения корпоративных средств защиты, и по нему мы движемся последовательно, шаг за шагом.
Перед интервью вы сказали, что записались на обучение по искусственному интеллекту. Зачем и какой результат хотите получить на выходе?
Да, сейчас я прохожу курс «Искусственный интеллект для ИТ-директоров». Мне важно разобраться, как внедрять ИИ в своей области и в реальных задачах. Тема активно развивается, много обсуждается, и хочется быть в тренде, но не на уровне заголовков. Я хочу понимать, какие классы задач решаются какими системами и что действительно имеет смысл применять.
Причем запрос на ИИ идет не только сверху. Даже от пользователей, которые не очень сильны в технологиях, уже появляются вопросы вроде «а можно это решить с помощью ИИ?» или «а можно поставить систему, которая поможет оптимально закрыть задачу?». Поэтому мне важно ориентироваться, где ИИ уместен, а где нет, и как встроить эту технологию в стратегию развития.
Есть и конкретные прикладные сценарии. Например, у нас есть система мониторинга сетевого и серверного оборудования, там много логов. ИИ может анализировать эти логи и подсвечивать аномалии и отклонения параметров. Это помогает быстрее реагировать и, по сути, предотвращать проблемы, которые иначе могли бы перерасти в инцидент или аварию.
Еще ИИ может серьезно помочь с аналитикой. Если дать системе контекст, например, как должно быть или доступ к нужным материалам, она может не только анализировать, но и предлагать рекомендации. Мы как раз думаем о следующем шаге. Хотим, чтобы система не просто подсвечивала отклонения, но и подсказывала варианты действий в конкретной ситуации.
Какие два-три сценария использования ИИ вы считаете безопасными и полезными «здесь и сейчас» для большинства организаций? И где, наоборот, начинаются риски?
Из того, что легче всего применить, я бы назвала автоматизацию рутинных задач и работу с контентом. ИИ может заметно ускорять повторяющиеся операции и помогать с информированием.
Например, если говорить про поддержку и обращения пользователей, ИИ может помочь зарегистрировать заявку, определить категорию, занести ее в систему и даже предложить ответ из базы знаний или рекомендации, что пользователю сделать, чтобы устранить ошибку. То есть это вполне рабочий сценарий для сервис-деска.
С контентом я тоже использую ИИ. Например, когда нужно быстро подготовить официальный текст, письмо, инструкцию или регламент. Он помогает сформулировать черновик, а дальше я уже вношу правки и привожу текст к нужному виду.
Плюс есть сценарии с аналитикой и отчетностью. Иногда полезно «пробежаться» по тексту договора, найти нестыковки или потенциально спорные места, особенно когда заключаем договор с поставщиком или обсуждаем услуги и работы.
Если говорить о рисках, то я бы не доверяла ИИ задачи, где цена ошибки слишком высока и где важен человеческий контекст. На бытовом уровне это видно на примере медицинских рекомендаций, когда люди пытаются получить «диагноз» по анализам. Система не знает всего контекста и может причинить вред.
В корпоративной реальности главный риск — конфиденциальность. Если загружать в ИИ документы с персональными данными или другой чувствительной информацией, непонятно, куда эти данные уйдут дальше. У нас были случаи, когда сотрудники делали это неосознанно. Мы объясняли, почему так нельзя. Люди часто просто не замечают, что в документе есть персональные данные, а последствия могут быть серьезными.
И наконец, про планы на этот год. Какие цели вы ставите себе как ИТ-руководитель?
В первую очередь — обеспечить технологическую устойчивость и при этом сохранить динамику развития. Для меня это, конечно, включает активную работу по кибербезопасности, а также внедрение новых полезных технологических решений. Таких, которые дают понятную ценность и тем, кто с нами взаимодействует, и нашим сотрудникам, потому что упрощают работу и снимают лишнюю нагрузку.
Опубликовано 30.01.2026
