Взаимодействие ИТ-департамента и бизнес-подразделений, переход к сервисной модели, участие в оптимизации бизнес-процессов  — задачи актуальные для большинства крупных и средних российских компаний. О том, как их решают в группе «Русфинанс», рассказывает её CIO Олег Подкопаев.

Родился в 1969 году в Москве, в 1992-м закончил Московский институт радиотехники, электроники и автоматики по специальности «Электронные вычислительные машины».
В 2004-м успешно сдал экзамен на звание Certified Information System Auditor.
В сфере информационных технологий работает более 15 лет, восемь из которых занимался созданием и внедрением западных банковских систем в России, Словакии, Венгрии, Бельгии и Англии, пройдя путь от разработчика до руководителя проектов.
В 2001—2003 годах работал в Управлении банковских технологий Банка Москвы.
В 2003—2004-м возглавлял Управление информационных технологий, а затем Департамент информационных и банковских технологий КМБ-Банка.
С 2004-го по настоящее время является CIO группы «Русфинанс».
Лауреат национальной ежегодной премии IT Лидер 2007 «За выдающийся вклад в развитие информационных технологий в России».

Intelligent Enterprise: Каким образом вы планируете развитие ИТ-систем, на что опираетесь при разработке ИТ-стратегии?

Олег Подкопаев: Наша ИТ-стратегия состоит из трех основных блоков. Первый — базовый уровень. Тут мы определяем, что необходимо для поддержания бизнеса в его нынешнем состоянии. С точки зрения бюджета это не инвестиции, а затраты, причем те, поступаться которыми крайне нежелательно. Второй — поддержка планов бизнеса по развитию. Здесь мы говорим о том, каким образом можно поддержать намерения бизнес-подразделений и их проекты, т. е. бизнес-стратегию. Сюда относятся новые продуктовые линейки, новые продукты и модификации существующих. Основой для планирования являются соответствующие планы бизнес-подразделений с цифрами и списками продуктов, а также планы по персоналу и точкам присутствия. Этот раздел стратегии в свою очередь состоит из двух частей — объемной и проектной. Объемная часть в основном направлена на прямую поддержку увеличения объемов продаж, количест­ва точек и персонала, и расчет здесь довольно простой, арифметический. Зная стандартные конфигурации и нормативы, мы соотносим их с объемом бизнеса и определяем, что надо сделать и сколько это будет стоить. С проектами сложнее, поскольку здесь продуктовые параметры нужно перевести в функционал бизнес-систем, в необходимые изменения прикладной и системной архитектур, в модификации инфраструктуры и все это скомпоновать в проекты, логичные с точки зрения передовых ИТ.

Наконец третий блок — «экстра». Это суперпроекты, экстраразвитие — нечто такое, что на наш взгляд позволит бизнесу развиваться быстрее, или повысит его эффективность, или даст какие-то дополнительные преиму­щества.

Эти три блока формируют стратегию, которую мы затем защищаем. Бизнес должен понять, что и почему мы собираемся делать, и расставить приоритеты. Дискуссии бывают весьма бурными, поскольку ви’дение проблем и решений у ИТ-департамента и у бизнес-подразделений зачастую заметно различается. И тут свою роль играет деление на три упомянутых блока. В отношении первого блока мы готовы спорить и отстаивать свою точку зрения очень жестко, так как по нашему мнению в него входит то, что совершенно необходимо и без чего обойтись нельзя, и урезанию он практически не подлежит. Второму блоку мы уделяем самое пристальное внимание, поскольку должны показать и доказать бизнесу, что если он хочет заниматься тем, что намечено с точки зрения развития, то предлагаемое нами ИТ-обеспечение совершенно необходимо. Тут бизнес-менеджерам нужно хорошо разобраться и понять эту связь, и наша задача — правильно всё объяснить. Третий блок обычно представляется совместно с конкретными бизнес-заказчиками, но, к сожалению, это не всегда помогает, поскольку речь здесь всегда идет о чем-то очень «продвинутом» и зачастую дорогом, и, как правило, именно эта часть и подвергается урезанию.

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

Как вы этого добиваетесь?

Мы стараемся работать на основе сервисно-ориентированной модели, выступая как некий «поставщик», предоставляющий сервисы своему «заказчику» — бизнесу. Соответственно чтобы успешно работать с заказчиком, необходимо выстроить коммуникации с ним, и для этой цели у нас внедрен институт эккаунт-менеджеров (account manager). Это сотрудники ИТ-департамента, постоянно работающие с определенными бизнес-направлениями. Они опеспечивают связь ИТ-службы с заказчиком — скажем, с департаментом автокредитования или каким-то другим отделом. Именно эккаунт-менеджеры согласуют состав и уровень сервисов, которые мы предоставляем бизнесу, контролируют исполнение проектов, представляют заказчику всю необходимую информацию. Очень важно, что эти люди говорят на языке бизнеса. Например, совершенно бессмысленно говорить бизнесу о «доступности каналов связи до офиса продаж в течение 99,9% времени» — в любом случае там поймут это по-своему. Но фраза типа «вы сможете в этой точке выдавать кредиты по схеме 24×7 с одним часом простоя в две недели в среднем» для функциональных заказчиков вполне ясна и приемлема. Все вопросы о работоспособности приложений мы проговариваем и объясняем в таком же ключе, и это позволяет достичь ясности и однозначного понимания.

Когда мы стали внедрять понятие сервисов, конечно же мы начали с ИТ-сервисов, говорили о доступности линий, приложений и проч. Это вводный этап, когда бизнес приучается к понятиям сервисов, SLA (service level agreement) и учится взаимодействовать с ИТ, а ИТ, в свою очередь, — с бизнесом. С бизнес-подразделениями организуются регулярные встречи, где представляются численные параметры (KPI) качества ИТ-сервисов, обсуждаются отклонения от желаемых значений, планируются корректирующие действия, устанавливаются целевые показатели.

Этот технический язык в принципе работает, для бизнеса понятна техническая нотация (т. е. ее можно объяснить), термины ИТ вполне доступны, но далеко не комфортны. Поэтому сейчас мы переходим на трехуровневую модель сервисов. Самый верхний уровень — бизнес-сервисы. Они показывают бизнесу, что’ он будет иметь от ИТ и сколько это может стоить. Например, сервис выдачи кредитов. У него есть характеристики: время выдачи, режим работы (24×7, 8×5), непрерывность, срок восстановления после сбоя и другие KPI. Такую систему KPI мы уже внедрили для департамента автокредитования, этот подход у нас активно развивается и в других сферах деятельности и новостью ни для кого в компании не является.

Нижележащий уровень — собственно ИТ-сервисы. Сейчас мы перешли к этапу, на котором на этом языке эккаунт-менеджеры, договорившись с бизнесом, разговаривают уже внутри ИТ-службы. Согласовав уровни сервиса с бизнесом, эккаунт-менеджер транслирует их на этот уровень. Скажем, чтобы выдавать кредиты, должно быть доступно определенное приложение, нужно, чтобы функционировала телефония и были рабочие места. Это минимальный набор, с которым действуют менеджеры приложений (application manager), отвечающие за работоспособность определенного ПО. Здесь возникают ограничения. Например, менеджер приложений говорит: «Я не могу обеспечить доступность 24×7, поскольку мне ежедневно нужно часовое технологическое окно, чтобы сделать бэкап». Если же тем не менее нужно 24×7, то на время этих технологических перерывов мы должны предусмотреть онлайновую син­хронизацию.

На следующем уровне — менеджеры по инфраструктуре (infrastructure manager), которые отвечают непосредственно за работоспособность серверов, сетей и телефонии. С ними доступность сервисов также согласовывается, и на уровень бизнеса вновь отправляются согласованные предложения ИТ-службы о реальном уровне доступности сервисов и о мерах, необходимых для их обеспечения. Принципиально важно, что при этом для бизнеса есть один контакт, одна точка входа — его эккаунт-менеджер. Он строит дерево сервисов и их показателей как сверху вниз, так и в обратном направлении — вначале согласовав с бизнесом KPI, дальше транслирует их на уровни приложений и инфраструктуры. Затем мы измеряем реальные уровни сервиса и говорим: KPI на данном уровне такие-то. Для расчёта у нас есть экспертные оценки, цифры сторонних провайдеров и наши собственные системы мониторинга. Эккаунт-менеджер передаёт собранные сведения бизнесу и сообщает, какие реальные значения KPI возможны. Ну а дальше начинаются переговоры. Если требуются существенные улучшения по сравнению с текущим положением, обсуждаются соответст­вующие изменения бюджета.

Бюджетирование ведется тоже с опорой на сервисы?

При нашем подходе практически реализуется схема «заказчик — подрядчик — субпорядчики». Этим можно было бы ограничиться, если бы речь шла о полном аутсорсинге, полном разделении компании и ее ИТ-службы. Но обычно этого не бывает. Руководству недостаточно знать, что на обеспечение таких-то сервисов будет потрачено столько-то денег. Они хотят точных данных, на что конкретно будут потрачены средства. Поэтому возникает вторая задача: не ограничиваясь сервисным подходом, обосновать необходимость ИТ-проектов и тех затрат, которые они повлекут. Например, мы должны сказать четко: мы собираемся провести проект по внедрению такой-то системы, поскольку она необходима для таких-то бизнес-целей, и нужно определить бюджет и сроки. Так что ограничиться сервисным подходом на данном этапе невозможно, а говорить лишь о проектах тоже нельзя. Поэтому при обсуждении стратегии и вытекающего из нее бюджета необходимо соблюдать своеобразный дуализм, опираться и на сервисный, и на проект­ный подход. Бюджет тоже рассматривается в двух направлениях. Во-первых, по конкретному проекту. Во-вторых, он проецируется на бизнес-направление, и мы видим, сколько мы тратим на поддержку этого направления. Таким образом, у нас есть как минимум два взгляда на общую картину.

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

А дальше мы видим: чтобы такая новая система нормально работала, нужны подходящие серверы, она должна быть интегрирована в сущест­вующую структуру, все это следует расположить в приемлемом датацент­ре с резервным копированием и так далее — так и выстраивается цепочка. Мы открыто кладем карты на стол и объясняем руководству и бизнесу (нашим спонсорам и заказчикам), зачем в этой цепочке нужен каждый элемент. И так по всем пунктам, по всем планам бизнес-подразделений.

В частности, поэтому мы ушли от исключительно постатейного бюджета на оборудование, ПО, зарплату и т. д. и включили компоновку бюджета с привязкой к отдельным проектам. Только в первом блоке бюджетирование постатейное, поскольку каждая статья показывает конкретное направление деятельности — скажем, не просто телефонные линии, а линии подключения к определенному офису. А все остальное финансирование идет по проектам. После защиты бюджета мы, конечно, разделяем его по статьям, удобным для бухгалтерии, но это уже чисто техническая процедура. Но защищаем мы бюджет и потом отчитываемся на проектной основе.

Сложно ли объяснить функциональным заказчикам преимущества сервисного подхода к ИТ? С какими проблемами вы сталкиваетесь, переводя взаимодействие на сервисную модель?

Объяснить бизнесу, зачем нужен сервисный подход в области ИТ, по моему опыту проще, чем объяснить это сотрудникам ИТ-службы. Казалось бы, должно быть наоборот, айтишники должны иметь представление об ITIL и связанных с этим подходах, но это не вполне так.

Несмотря на свое несколько потребительское отношение к ИТ бизнес все же тянется к общению. Его представителям нравится, когда есть менеджер, который постоянно в курсе их проблем и заботится о них. Есть кто-то, кому можно позвонить и он решит вопросы, а если надо, объяснит, что к чему и как лучше сделать. Это напоминает обычные и привычные взаимоотношения в деловой среде между заказчиками и подрядчиками. С другой стороны, KPI, SLA упрощают контроль, делают его более прозрачным. Контроль на понятийном уровне, качественные оценки «хорошо — плохо» не дают такого эффекта, скорее приводят к шантажу со стороны бизнеса. При сервисном подходе мы сами приходим и предлагаем параметры, по которым нас можно контролировать. Важно, что эккаунт-менеджеры — это сотрудники, выделенные исключительно для общения с бизнесом. Никаких других обязанностей, совмещения функций внутри ИТ-службы у них нет. Их и подбирали специально для этого.

А вот ИТ-сотрудники переходят на сервисную модель совсем иначе. От человека, который блестяще знает свое любимое «железо» или софт и полностью погружен в собственные «колдовские» действия с ними, требуют каких-то показателей, по сути просят описать, что он делает, причем не на понятийном уровне, а на уровне численных параметров. Это воспринимается как тяжелая дополнительная сверхобязанность, фискальный контроль за своими действиями.

Какими могут быть аргументы «за»?

Прежде всего профессиональный рост. Людей, действительно умеющих управлять ИТ-сервисами, на российском рынке пока немного. Хотя мы уже очень давно говорим про ITIL, до сих пор всё остается в основном на уровне деклараций, красивых слов. Те компании, которые заявляют, что способны провести аудит по CoBIT, на самом деле хотя бы приблизительно не умеют этого делать. И опыт, компетенции, накопленные при работе в сервисной среде, — это весомый плюс.

Второе. Сервисный подход дает реальный инструмент для измерения производительности труда. Ведь обычно каждый сотрудник все же сильно зависит от личного к себе отношения непосредственного начальника, как бы даже тот ни старался этого избежать. Есть симпатия, понимание — идут премии и бонусы, нет — даже если он хороший работник, сладкой жизни ему не видать. Но и в том случае, если премии выплачиваются объективно, объяс­нить обиженному сотруднику, что он работал хуже коллег, невозможно. У него есть собственное мнение на этот счет. Поэтому крайне желательно иметь объективные и измеримые параметры. Когда они согласованы с персоналом и всем понятны — любые вопросы снимаются.

Третий момент — взаимопонимание, коммуникации. Часто люди работают на смежных направлениях, влияющих друг на друга. И совершенно не понимают, что происходит вокруг. Каждый пытается справиться с проблемой изолированно, тратит массу усилий, но ничего не получается. Если бы они по­пробовали решать задачу сообща, дело пошло бы совсем иначе и продвигалось бы быстрей. При сервисном подходе любой сотрудник видит своих смежников, понимает, «на кого он работает», кто и как пользуется его услугами. Мы регулярно, обычно раз в неделю, проводим встречи на каждом уровне сервиса. Их проводят эккаунт-менеджеры. Согласовав какие-то новые требования с бизнесом, расставив приоритеты, они обсуждают изменения и текущее положение дел с инженерами, специалистами, ответственными за инфраструктуру и приложения (infrastructure manager и application manager). Люди начинают общаться, рассказывать о своей работе, и в результате они лучше понимают, что происходит. Такого целостного ви’дения в компаниях обычно нет, и привнести его сложно. А при регулярном общении люди уясняют себе, что в организации кроме них еще кто-то работает и даже делает что-то по­лезное.

Так что в сервисном подходе есть как минимум три плюса: квалификация, объективная оценка, коммуникации. Эти три вещи каждый айтишник должен понять, и они должны стимулировать работу с ИТ-сервисами.

Как вы оцениваете качество ИТ-сервисов? Ведется ли у вас непрерывный мониторинг их предоставления?

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

Теперь наша цель — интеграция этих сведений в единую картину. Мы планируем на базе HP OpenView создать единую CMDB (Configuration Management Data Base), где будет учитываться состояние любого подключенного к сети устройства, приложения, сервиса. Затем на её основе можно сконструировать единое дерево сервисов. Под каждый сервис расписываются определенные приложения, серверы и пр., и все они имеют агентов, отслеживающих их состояние. Тогда в любой момент можно поднять дерево и выяснить, с чем связана недоступность того или иного глобального сервиса. Это мы планируем сделать в нынешнем году.

Но просто так, на ровном месте, заниматься этим нет никакого смысла. Прежде чем что-то автоматизировать, нужно отладить методологию, и это принципиальный вопрос. Когда айтишники общаются с бизнесом, они всегда стараются использовать этот тезис: «Нельзя автоматизировать хаос». Вначале нужно формализовать бизнес-требования, а потом уж автоматизировать. Но почему-то относительно себя они тем же принципам не спешат следовать, и первое, что автоматизируют, — собственную деятельность вне зависимости от ее упорядоченности. По моему же глубокому убеждению, сначала должны устояться процессы, их нужно отладить, и лишь после этого можно что-то автоматизировать.

Вы говорили о значении проектного взгляда на ИТ-затраты. Как у вас организовано проектное управление?

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

Вообще-то существует два подхода к организации и внедрению проектной деятельности в компании. Первый — сверху вниз, когда разрабатываются некие общие документы, которые спускаются от начальства к подчинённым, их официально делают обязательными для всеобщего исполнения, затем разрабатываются процедуры более низкого уровня и т. д., и вся организация вдруг начинает работать на основе проектного подхода. Я в успех этой схемы не верю и считаю, что так действовать нельзя. Здесь, как правило, вся проектная документация и все действия, необходимые для управления, выглядят и действительно оказываются лишь дополнительной нагрузкой, лишней работой. Люди заполняют какие-то бумажки, проводят совещания, но всё делается формально.

Отвертеться они не могут: руководство захотело, значит придется, ничего не попишешь. Но чтобы давать результат, проект­ный подход должен быть реально поддержан на всех уровнях. Люди должны созреть профессионально и ментально быть готовыми к принципиальному изменению в подходах к их ежедневной деятельности. Поэтому я исповедую другой подход — снизу вверх: сотрудники должны почувствовать, зачем нужны какие-то действия, убедиться на практике, что это и вправду помогает. Мы так и делаем, вводим какие-то практики де-факто. Например, начинаем нормально планировать. У проекта есть план, при этом регулярно проводятся встречи. И люди видят: да, план выполняется, проект продвигается, у нас получается! Пишем отчеты. Зачем? Чтобы понять, что было в каждый момент времени, что произошло и что нам мешало двигаться дальше. Наконец доходит до итогов. И тут самое время сказать: а вот если бы у нас был паспорт проекта, то сейчас гораздо лучше было бы видно, добились мы того, чего хотели, или нет. Когда всё это вводится, возникает и необходимая структура.

Мне нужно лишь подталкивать людей, вовремя предлагать им небольшие готовые документы и еще что-то в этом же духе. У меня на компьютере множество шаблонов проектных документов, но без особой необходимости я никому их не даю, не заставляю применять их. Но постепенно сотрудники проходят обучение — то одни, то другие. Идет нарастание опыта и привыкание к проектной методологии. Проходит какое-то время, и они уже не мыслят работы по-другому: «Зачем, мы всегда так делали, и получаются приличные результаты». И выходит, что к формальным документам люди относятся не формально, а как к инструменту: да, тут описано то, чем мы на самом деле занимаемся. Проводятся разные встречи, организуются проектные комитеты, презентации становятся качественно другими; начинают заниматься управлением изменениями. При этом весь процесс идёт довольно быстро, поскольку в ИТ много проектов.

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

Кто на ваш взгляд должен выполнять функции по описанию бизнес-процессов. Существуют разные мнения на этот счет, в том числе и такое, что этим должен заниматься ИТ-департамент. Как это организовано у вас в компании?

Работа с бизнес-процессами очень логично связана с ИТ. ИТ-отдел — это подразделение, которое наиболее органично, по сути своей деятельности умеет формализовать процессы. Профессиональный айтишник де-факто обладает аналитическим складом ума. Для него любое действие связано с последовательностью каких-то шагов и условий, с алгоритмами. В отличие от многих других специальностей нас этому учат. Блок-схемы нигде больше не рисуют, алгоритмы не разрабатывают. А это ведь фактически и есть бизнес-процессы, и чтобы грамотно описать работу какой-то системы, сначала нужно их описать.

Впервые я этим занялся в Банке Москвы, в отделе банковских технологий. Все технические задания у нас сопровождались описанием бизнес-процессов в графическом виде. Текстовые описания воспринимаются с трудом, графические — намного легче. В «Русфинансе» мы стали это делать практически сразу в рамках ИТ-департамента. У нас в ИТ-департаменте есть особое подразделение, которое этим занимается, — управление перспективных технологий, где работают эккаунт-менеджеры, проджект-менеджеры и бизнес-аналитики. И вот эти люди снабжают любые проекты описанием бизнес-процессов и следят за ними.

Но тут важна зрелость. Бизнес-процесс должен устояться, затем его следует описать и только потом автоматизировать, и никак иначе. Кроме того, не надо забывать, что описать бизнес-процесс «навсегда» невозможно. Вы делаете снимок — описываете бизнес-процесс на момент времени. Самая сложная задача — поддерживать его описание в динамике. Именно поэтому многие проекты, связанные с автоматизацией процессов, оканчиваются неудачей: мы приглашаем кого-то, описываем процесс, автоматизируем. А за прошедшее время полученная картина уже не соответствует практике.

И второй важный момент: прежде чем приступать к описанию, нужно создать инфраструктуру поддержи и управления бизнес-процессами. Должна быть команда людей и разработанные процедуры, как им контролировать бизнес-процесс. Иначе сколько бы вы ни рисовали схем, вы все равно не поймете, что происходит. А чтобы сформировать правила, люди должны понимать, что они делают. Поэтому, между прочим, когда приглашают внеш­нюю компанию и просят описать, как мы должны действовать, то это не работает.

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

На мой взгляд, продвижение идет снизу вверх, эволюционный процесс — самый продуктивный способ развития. Из всех способов руководства наставничество и делегирование, которые мы и практикуем, оказываются самыми эффективными. До любых методологий люди должны дорасти, иначе они будут навязаны и неработоспособны. Главная задача руководителя — задать направление и потом следить, как оно выдерживается. Стратегия развития — некий направляющий туннель, в рамках которого должна вестись вся деятельность. Как только появляются заметные отклонения — на них должен реагировать ИТ-директор. Но основная задача — создать этот «туннель», это направление и следить, чтобы деятельность за его рамки не выходила.