Авторитет ИТ-руководителя и его департамента базируется в первую очередь на успешности выполнения поставленных бизнесом задач. О том, как организовано взаимодействие с бизнес-подразделениями в банке «Ренессанс Кредит», рассказывает Андрей Эзрохи, CIO банка.
Intelligent Enterprise: Каким образом организовано взаимодействие с бизнесом в вашем банке?
Андрей Эзрохи: Взаимодействие с бизнес-заказчиком, с одной стороны, формализовано и закреплено соответствующими процедурами, а с другой — построено по принципу взаимного партнерства и полной взаимной вовлеченности.
Внутри ИТ-департамента существует подразделение, которое мы называем IT Governance. На нём лежат всевозможные управляющие, координирующие и вспомогательные функции основного ИТ-процесса. Например, бюджеты, расчеты и договоры — всё это готовится здесь, контроль за выполнением SLA и метрик KPI — тоже одна из задач. Но самый важный по смыслу в этом подразделении — офис управления ИТ-задачами и проектами.
В рамках данного офиса существуют так называемые роли аккаунт-менеджеров, отвечающих за те или иные направления бизнес-заказчиков. Кто-то отвечает за блок дистрибуции, кто-то за департамент рисков, кто-то за финансовый блок и т.д. Этот аккаунт-менеджер, или менеджер бизнес-направления, служит единой точкой контакта для заказчиков соответствующей бизнес-службы, а также своеобразным проектным менеджером для всех задач данного подразделения.
Таких задач в зависимости от их масштаба у каждого менеджера может быть сразу много, а может быть всего одна или две.
Например, изменение поля в анкете, внедрение нового банковского продукта или системы — это типичные задачи менеджеров бизнес-направлений, они, конечно, различаются по масштабу и трудоемкости, но выполняются по единому процессу управления изменениями.
Весь этот процесс начинается с единой точки входа. В ИТ-департамент поступает формализованный запрос, авторизованный соответствующим членом правления, который курирует бизнес-подразделение, приславшее запрос. Все запросы объединяются в общий пул, менеджеры бизнес-направлений разбирают из него свои задачи и дальше ведут их как небольшие проекты. Проводят оценку трудозатрат, собирают проектную команду и занимаются проектом вплоть до получения бизнес-результата, выхода изменения в продуктив, после чего передают его заказчику и службе ИТ-сопровождения.
Всё взаимодействие по задаче — и с внутренней ИТ-службой, и с внешними подрядчиками, если они привлекаются, — бизнес-подразделение ведет только через менеджера своего направления. Равно как и в обратную сторону: исполнители общаются с заказчиком только через этого специалиста. В обход его никакие коммуникации с бизнес-пользователями не идут.
Изменения во все свои системы мы вносим в строго регламентированной форме — в виде релизов. Релиз, то есть обновление, по всем ключевым системам выходит примерно раз в три месяца, и все необходимые изменения собираются в нем — ото всех менеджеров бизнес-направлений.
Скорее всего так было не всегда и раньше вы практиковали другие схемы взаимодействия?
Полноценно на такую систему мы перешли полтора года назад. Раньше ИТ-департамент управлял изменениями, задачами не по направлениям бизнеса, а по ИТ-импликациям. Менеджеров направлений не было. Некоторые ключевые системные аналитики имели роли «технических владельцев систем», той или иной AБС — например, те, кто консолидировал и курировал все задачи, связанные с изменениями в этой системе.
Но изменение бизнес-процесса, как правило, затрагивает не одну систему. И проблема была в том, что все технические владельцы одновременно занимались всеми изменениями, по сути дублируя управленческие функции. Кроме того, было размыто представление о том, кто же все-таки является ответственным за конкретное изменение.
Расстановка приоритетов оказывалась невозможной, сотрудники не очень понимали, за что хвататься в данный момент и кто заказчик конкретных изменений. При этом общение с бизнесом превращалось в постоянное противодействие при естественном желании снизить нагрузку и «отменить или отклонить» какие-то запросы.
Я не говорю уже о том, что информацию о той или иной задаче трудно было не только получить, но и вообще собрать, не было унифицированной системы взаимодействия. Бизнес-пользователи, заказчики непосредственно контактировали с исполнителями своих задач, и кроме этих исполнителей никто о задаче ничего не знал. Равно как и не учитывал взаимное влияние тех или иных изменений друг на друга.
Удалось ли решить эти проблемы с переходом на новую систему взаимодействия? Как прошел переход?
Обе проблемы — прозрачности статуса задач и эффективных коммуникаций — мы решили, перейдя на новую схему управления и введя роли менеджеров бизнес-направлений. Теперь ни у кого не возникает вопросов, к кому идти за информацией, куда бежать с проблемой при реализации задачи внутри ИТ-подразделения и т.д. Сложилась четкая и понятная система управления реализацией конкретной бизнес-заявки.
Для начала мы выбрали один из департаментов заказчиков — департамент управления рисками — и на нем «пропилотировали» этот подход: у них первых появился свой выделенный аккаунт-менеджер, который сфокусировал на себе все взаимные коммуникации. Мы предложили «попробовать работать по-новому» и уже через неделю услышали позитивные отклики. Наконец-то внутренние процессы ИТ-департамента и статусы работ стали для заказчиков прозрачными и понятными.
Через месяц-два мы убедились, что не только бизнес-пользователи видят в новом подходе главным образом плюсы, но и наша работа стала более структурированной и системной, наладилась коммуникация, повысилась эффективность процессов взаимодействия с бизнесом. Подход стал применяться ко всем подразделениям банка.
Конечно, некоторая напряженность в первое время была, но через полгода она полностью исчезла, а новый подход прижился и стал привычным настолько, что теперь уже и непонятно, как мы раньше без этого жили, — пожалуй, повторить прежние упражнения «планирования» сейчас уже и не смогли бы.
И что очень важно, мы перешли от противодействия к реальному и эффективному взаимодействию со своими бизнес-заказчиками.
Появление заявок и расстановка приоритетов — как это происходит в вашем банке?
Любой сотрудник может прислать заявку на изменение или реализацию нового функционала в ИТ-департаменте, заполнив определенную электронную форму. Однако все заявки в обязательном порядке согласовываются членами правления банка, курирующими подразделения, от которых они поступили, — без такого согласования заявки в работу не принимаются. Когда формируется заявка на изменение, в ней указывается желаемый срок, обусловленный бизнес-причинами. Все заявки собираются в единый пул и проходят первый этап приоритизации по срокам исполнения.
Каждая заявка оценивается с точки зрения трудозатрат. Так как мы вносим изменения в ИТ-системы на основе ежеквартальных релизов, а в релиз может войти определенное количество трудозатрат различных специалистов — аналитиков, разработчиков и тестировщиков, — начинается второй этап приоритизации по доступным ресурсам.
На третьем этапе мы согласуем состав релиза с курирующими топ-менеджерами, учитывая необходимость очередности выполнения заявок и прочие внешние факторы — например, реализация требований регуляторов всегда имеет приоритет.
Еще хочу сказать, что в конце каждого года мы проводим серию встреч с руководителями бизнес-направлений и в ходе их прорабатываем список тем, которыми будем заниматься в будущем году. На основании этого планируется бюджет и выстраивается операционный план с приоритетами. Это приоритизация более стратегического уровня.
Статус ИТ-руководителя и общение с высшим руководством: как упрочить свои позиции?
В банковском бизнесе роль ИТ ясна и каких-то особых доказательств их важности не требуется: без ИТ-систем и инфраструктуры продолжение бизнеса невозможно, что несколько упрощает задачу ИТ-директора по защите своего статуса.
В зрелых и успешных компаниях, как правило, высшее руководство воспринимает ИТ как инструмент реализации своей стратегии. Поэтому ему важно знать и понимать, что ИТ-процессы эффективны, а оборудование и системы применяются правильные. В этом должны помогать открытые коммуникации с руководителем и прозрачность внутренних процессов и решений.
