Каскадные процессы и agile — столкновение культур
— Мне кажется, что под определением «банковские ИТ» объединены разные понятия. В рамках одного департамента живут как будто две разные культуры. Одни — охранители, другие — инноваторы. Как это возможно?
— Согласен. За последние пять лет в банковском ИТ появился новый тип процессов, который стал использоваться для разработки продуктов, внедрения изменений, управления проектами и который существенно отличается от того, что существовало раньше.
Я дам небольшое пояснение упомянутых в вопросе двух видов процессов. Первый тип — это то, что существовало «всегда». К нему относятся каскадные (waterfall) методологии, которые сконцентрированы на «безопасности и точности». Чаще всего такие методологии применяются в проектах на АБС и других банковских системах, которые критически важны, где надежность и предсказуемость результата превалирует над гибкостью и скоростью.
Второй тип — процессы agile, где все «очень гибко» и «очень быстро». Вопросы определения финального целевого состояния, выполнения этапов в строгой последовательности, формальных согласований и т. д. отходят на второй план. Для agile характерны быстрые итерации, быстрые решения, быстрые первые результаты. Этот подход изначально применялся в банкинге не очень широко, он пришел из других отраслей, где часто ниже цена ошибки, ниже уровень регулирования. А в банковской отрасли воспринимался как «что-то не очень качественное».
Со временем второй тип процессов стал не только быстрым, его использование позволило создавать масштабные и надежные решения. Нельзя сказать сейчас, что Google или Amazon, которые используют в разработке гибкие методологии, делают ненадежные решения. У них время доступности сервиса такое, что все могут позавидовать. В том числе, за счет облачной инфраструктуры — выход из строя одного элемента не приводит к падению сервиса.
Возвращаясь к вопросу появления в банках agile-процессов. Основная причина появления этих процессов в банках — это необходимость высокой скорости реакции на изменения на рынке и управление быстро меняющимися приоритетами. «Классические» методы могут обеспечить необходимую скорость не всегда. Со временем два типа процессов стали сосуществовать в рамках одной организации. Важно понимать, что нельзя абстрактно сказать, что один из этих подходов лучше, а другой хуже. Подход — это инструмент, который надо правильно подбирать под конкретную задачу.
Основная сложность возникает, когда появляется необходимость интеграции двух противоположных подходов друг с другом. В том числе появляется необходимость в совместной работе отдельных команд, использующих разные подходы в рамках одной организации.
Допустим, приложение создается agile-методом, но при этом оно взаимодействует с АБС. И здесь может возникнуть столкновение двух культур, двух процессов. Люди, работающие с АБС, хотят получать детальные формально согласованные документы, к которым они привыкли. Им кажется, что люди, которые занимаются внешними приложениями, занимаются какими-то «несерьезными делами». И, с другой стороны, те, кто работает в рамках agile-процессов, привыкли, что у них все делается быстро, без бюрократии. И когда возникает необходимость интеграции с основными системами, у них появляется ощущение, что там сидят какие-то «староверы», которые медленно работают. Это и можно назвать «столкновением культур».
Конкретно у нас в банке широко используется первый тип процессов для работ по основным системам, и при этом есть несколько инновационных направлений, где применяется agile.
— В первую очередь речь идет об интернет-банкинге?
— Нет, наш интернет-банкинг — это аутсорсинговое решение «Фактура», и можно сказать, наверное, что ЦФТ применяет при развитии системы именно методологии второго типа. Я говорил в первую очередь о собственных разработках, где мы активно используем agile-процессы (например, для нашей «не розничной» части бизнеса).
— У вас свои проектные группы или вы работаете с внешними командами?
— Мы много сервисов приобретаем. Иногда создаются комбинированные команды, когда часть сотрудников — это наши банковские сотрудники, часть сотрудников — на аутстафе, еще — это сотрудники сторонних ИТ-компаний.
— И как вы решаете проблему столкновения двух культур?
— Первое, что нужно делать,— это систематически доносить до представителей каждой из «культур», что они по факту не «оппоненты», а люди, работающие для достижения общебанковских целей. Важно показывать положительный эффект от использования той или иной методологии, демонстрировать, что баланс в использовании разных инструментов и командная работа позволили достичь необходимого результата.
Помимо чисто «образовательного» способа есть другие. Например, технологический. Как вариант, снизить «градус» во взаимодействии команд помогает использование сервисно ориентированной архитектуры. Например, АБС, которая должна быть «очень надежной и неприкосновенной», начинает вовне отдавать какие-то сервисы. Например, сервис ответа на вопрос, есть ли в банке клиент и какие у него остатки по счетам. Другой сервис может инициировать платеж и т. д. На стороне АБС создается набор сервисов, при этом минимизируется возможность влияния какого-то внешнего приложения за счет того, что набор регламентирован и практически изолирован. Ты точно ничего не сломаешь, потому что можешь только запросить из АБС какие-то конкретные данные и эти данные получить.
Естественно, на 100% риск убрать нельзя (как минимум остаются вопросы нагрузки на систему), но, когда у команды, обслуживающей АБС, уходит ощущение, что люди «из agile» могут «всё» сломать, их совместная работа идет гораздо более продуктивно. И наоборот, когда команда, отвечающая за разработку приложения методами agile на вход, получает понятное и простое описание сервисов взаимодействия, она может продолжать работать «как привыкла», минимально адаптируясь под процессы коллег, обслуживающих АБС.
— Кто выступает арбитром между двумя командами?
— Это может быть либо сильный проектный менеджер, либо, в большинстве ситуаций, это все-таки человек, который имеет влияние на обе команды и правильно оценивает эффективность с рисками при выборе подходов. В нашем банке эту роль выполняю я, как CIO. Мне приходится, можно сказать, мирить эти два мира.
Проектный офис в банке
— Как должен быть устроен проектный офис в банке? Кто должен им руководить? Как у вас это устроено?
— Единственно правильного ответа на вопрос, где и каким должен быть проектный офис, нет. Все зависит не только от специфики деятельности конкретного банка или другой организации, но и от компетенций отдельных руководителей, «исторических» факторов и т. д. До прихода в Совкомбанк я работал руководителем проектного офиса GE Money Bank. Одно из преимуществ работы в интернациональной команде заключается в том, что есть возможность изучить процессы во всех бизнесах GE Money Bank в мире. Я знал лично руководителей проектных офисов разных стран и мог изучать, как выстроены процессы в других банках, что работает эффективно, а что можно было бы упростить или изменить.
Давайте рассмотрим проектный офис с разных сторон. Первый вопрос: где должен находиться проектный офис? Есть разные практики. Есть ситуации, когда проектный офис находится в операционном департаменте, под управлением менеджера, который отвечает за операционную деятельность компании. Есть примеры, когда он находится в IT. Иногда создается отдельная структура, подчиняющаяся CEO, есть даже примеры, когда проектный офис находится в «финансах». Второй вопрос: есть ли у проектного офиса свои ресурсы? Есть два подхода: централизованный и децентрализованный. Централизованный — это когда проектные менеджеры находятся непосредственно в проектном офисе. В этом случае проектный офис не только отвечает за методологию и контроль, но фактически внедряет проекты. Другой вариант — когда функция проектного офиса чисто методологическая. Когда проектный офис определяет шаблоны проектных документов, определяет, как будут консолидироваться данные по портфелю проектов, какой процесс принятия решения использовать и т. д. Соответственно, отвечая на эти два вопроса, можно получить все многообразие вариантов существования проектного офиса.
Местоположение и тип проектного офиса можно изменять во времени. Если говорить про начальный этап, этап становления проектной культуры, то я считаю, что очень сложно прививать новую культуру и «просить» людей что-то делать по-другому, если у тебя ограниченные возможности влиять на них. Ситуация, когда ты являешься владельцем каких-то ресурсов, одновременно будучи руководителем проектного офиса, выигрышна, потому что в этом случае ты тот, с кем надо договариваться, кто может вводить какие-то новые правила. Кроме этого, наличие внутри проектного офиса хотя бы нескольких сильных проектных менеджеров позволяет продемонстрировать эффективность самого института «проектного менеджмента».
Для нашей организации на текущем этапе я считаю оптимальным, когда проектный офис находится в IT. Уровень автоматизации процессов в банке высок, сложно реализовать масштабный проект, который не приведет к необходимости изменений в системах. Поэтому логично проектный офис начинать выстраивать вокруг изменений в IT-системах.
То есть существует процесс внедрения изменений. IT — владелец ресурсов, которые эти изменения внедряют. На базе текущих процессов органично получается внедрять процессы приоритезации, отслеживания статусов и т. д., затем расширять границы проектов от внедрения изменений в конкретной системе до запуска бизнес-процесса (с учетом тренингов, коммуникаций, отслеживания результатов и т. д.). А уже следующим шагом, если это целесообразно, распространять участие проектного офиса и на другие бизнес-проекты.
— С другой стороны, заказчиком изменений выступает бизнес. Если проектный офис находится в IT, не получится ли здесь некая IT-центричность?
— Нет. Руководитель проектного офиса, на мой взгляд, отвечает за две вещи. Первое — это оптимальность набора выполняемых проектов и их приоритетов. Под «оптимальностью» понимается максимизация бизнес-показателей по результатам запуска портфеля проектов. Факторами являются ресурсы, бюджет и т. д.
И речь идет не о «локальном» оптимуме для какого-либо проекта или заказчика, а оптимальности для организации. Вторая функция — обеспечить успешное выполнение этих проектов и аллокацию ресурсов во всем банке в соответствии с приоритетами. Под успешностью в первую очередь я понимаю достижение бизнес-результата в запланированном объеме, а не просто выполнение проекта «в срок, в рамках бюджета, с нужным качеством»
— Как решается первая задача? Есть много разных бизнес-заказчиков, у них у всех свои задачи, которые они считают самыми важными. Проектный офис отвечает за приоритезацию?
— Да, ответственность проектного офиса — подготовить достаточную информацию для принятия руководством решения о составе портфеля проектов и приоритетах внутри этого портфеля. Учитывая, что у разных заказчиков могут быть свои приоритеты и интересы, задача проектного офиса сделать так, чтобы при принятии решения все проекты были сравнимы. Звучит просто, но в реальности это очень сложно сделать.
В западных компаниях часто бывает так, что пока ты все не просчитаешь «до последней запятой», ты не получишь согласования на проект. И даже если получил локальное одобрение, тебе надо идти на уровень материнской компании. Сам процесс принятия решения требует огромного объема работы. В Совкомбанке ситуация другая. Здесь владельцы непосредственно участвуют в принятии решений, им не надо самим себе доказывать очевидные вещи. И в этом плане бессмысленно было бы пытаться перенести сюда западный опыт без изменений. Второе отличие — требования по количеству артефактов (документов), которые должны быть созданы в рамках проектов. Такой объем документов, который необходимо было готовить в GE Money Bank в соответствии с требованиями материнской компании, объективно нужен не во всех ситуациях.
— Можно сказать, что в российских проектах больше гибкости?
— Вопрос скорее не в том, какая организация — западная или российская, а в том, как выстроены процессы. Являясь частью международной корпорации, ты часто вынужден делать вещи, которые не несут большой пользы локальному бизнесу, но при этом важны (и часто полезны) на уровне штаб-квартиры. В Совкомбанке гибкости точно больше.
Если ты веришь или можешь объяснить полезность некоего инструмента, ты его применяешь. Если не считаешь инструмент полезным в конкретной ситуации, не применяешь. Это прагматичный подход, который позволяет убрать все лишнее и сделать проектное управление легким, гибким инструментом, что повышает количество успешных проектов. Проектные техники, методологии, инструменты всегда нужно адаптировать под размер и специфику решаемых задач. Одна из главных ошибок — это попытка для небольшой задачи использовать громоздкий инструментарий.
— Что называется, «из пушки по воробьям»?
— Да. Есть, например, небольшая задача, которую можно выполнить за неделю: два человека сядут рядом — один заказчик, другой разработчик, и они ее решат. Если при этом требовать подготовить план управления проектом, план управления рисками, план управления стоимостью и т. д., то это отличный способ «все завалить». Поэтому мы используем те инструменты, которые нужны для проектов конкретного размера (специфики). Когда шла интеграция банков, мы использовали одни инструменты; сейчас, когда внедряем различные инициативы, используем другие инструменты.
Интеграция систем: скорость и порядок
— Вам удалось довольно быстро интегрироваться. Что помогло этому? Какой основной урок вы для себя вынесли из этой интеграции?
— Я бы назвал несколько факторов успеха. На первом месте, несомненно, уровень профессионализма команды. На втором — скорость принятия решений, способность правильно оценивать риски и четкое понимание целевого состояния. Скорость была определяющим фактором. Она была важна не только с точки зрения задвоенности систем, задвоенности команд и т. д. Был риск, что часть людей из команд может просто уйти. Не было гарантии, что через три месяца все останутся работать, то есть была опасность остаться с системой, которую даже поддерживать не можем. Важно было быстро принимать решения. Важна была готовность брать на себя ответственность и определенный риск. Ну и конечно, доступность лиц, принимающих решения. Был создан проектный интеграционный комитет, в который входило всего четыре человека, которые могли принимать все решения в рамках интеграции. Мы встречались каждую неделю, и все вопросы, которые возникали у меня, как у менеджера портфеля интеграционных проектов, мы тут же решали. Третий фактор — это структура, которую мы привнесли в этот процесс, четкое понимание набора проектов, которые надо было реализовать для того, чтобы выполнить интеграцию, четкое понимание границ этих проектов, сроков, последовательности реализации, статуса, ответственных и т. д.
На самом деле для интеграции часто не хватает решимости. Даже после приобретения небольшого банка часто не решаются провести слияние АБС, перенос данных из одной АБС в другую. И это заканчивается огромной неэффективностью, увеличением операционных IT-затрат, необходимостью вносить изменения в несколько систем и т. д.
— Потребовались какие-то принципиально новые решения с точки зрения программного обеспечения?
— Прежде чем я отвечу на этот вопрос, позвольте дать небольшую «матчасть», понимание которой важно для правильного понимания ответа. Существует несколько типов интеграции. Первый тип — это поглощение, когда процессы, методологии, зрелость одной организации очевидно превалирует над другой, тогда происходит поглощение, при котором целевыми процессами и целевыми системами считаются целевые процессы одного из участников сделки. Второй тип — это ситуация, когда как таковой интеграции не происходит. Остаются две организации, у которых есть какие-то общие задачи, общие цели, но при этом они могут ориентироваться на разные сегменты рынка и у них разные процессы, разные системы. Остаются отдельные компании, просто имеющие одних владельцев. Третий тип — это «выбор лучшего». Это ситуация, когда уровень зрелости по каким-то процессам и системам выше у одной организации, а по каким-то — у другой. И в каждой ситуации происходит выбор, какую технологию, какой бизнес-процесс мы считаем целевым. При интеграции Совкомбанка и GE Money Bank мы использовали именно третий тип. Честно сказать, он был сложным, особенно по системам и процессам, на которых работают фронты, массовые сотрудники. Приходится делать выбор — переучивать либо 1000 сотрудников, либо 5000 сотрудников. Разница в размерах, наверное, не везде позволила провести такой выбор, но по многим направлениям нам это удалось. С точки зрения АБС и процессинга у нас особо не было вариантов. АБС не принадлежала локальному бизнесу GE Money, она была глобальной, и мы были обязаны в течение 18 месяцев с нее уйти. С карточным процессингом похожая ситуация, поскольку он был интегрирован с этой АБС. Поэтому мы перешли на единую АБС и единый процессинг, которые были в Совкомбанке (оба решения от компании ЦФТ). Замена систем не потребовалась. Был сделан плановый апгрейд оборудования.
— Затраты объединенных банков на ИТ выросли?
— Нет. Понятно, что был период, пока мы проводили интеграцию, когда у нас существовало фактически два банка, две инфраструктуры, два набора систем, два набора специалистов. Это было неэффективно. Первое, что было сделано: мы быстро перешли к целевому состоянию с единой инфраструктурой — одна АБС, одна команда. После этого мы продолжили оптимизацию ИТ-расходов. Сейчас наши расходы ниже на 20–30%, чем до объединения.
Оптимизация расходов
— Кто у вас управляет сокращением расходов: какое-то специальное подразделение или вы сами как ИТ-департамент?
— Мы сами. Мне делегировано управление IT-бюджетом. Я являюсь фактически главным заказчиком процесса оптимизации затрат и координирую его большую часть. На активной фазе оптимизации у нас было отдельное направление, которое занималось взаимодействием с ключевыми партнерами.
— Иначе говоря, давило на вендоров, чтобы они снизили цены?
— Простым давлением добиться можно немногого, и эффект не будет долгосрочным. Если вы не выстроили партнерских отношений с вендорами, то сегодня вы их продавите, а завтра их позиция будет сильнее, и они вас продавят. Например, вы получили хороший «входной билет», но через два года на вас так отыграются, что вы сами рады не будете.
Несомненно, мы вели переговоры по тарифам, но основную экономию приносят более «сложные» действия. У команды уже был опыт, поскольку мы постоянно занимались снижением расходов в GE Money Bank. Со стороны штаб-квартиры для всех бизнесов было установлено четкое правило: снижение текущих операционных IT-расходов минимум на 10%. Для российского рынка, к сожалению, обычным является другой подход: есть инфляция, значит, мы должны каждый год и бюджет увеличивать минимум на размер инфляции.
Подход западных компаний: забудьте про инфляцию, вы должны повышать операционную эффективность своих процессов, вы должны делать это так, чтобы экономия, которой вы достигаете, покрывала инфляцию и еще позволяла экономить дополнительно, т. е. чтобы мы каждый год тратили меньше, чем в предыдущем.
Интернет-банк для пенсионеров
— Сейчас банки все больше уходят в цифровые дистанционные каналы. Насколько это актуально для вас? Вашей целевой аудитории являются пожилые люди, пенсионеры. Наверное, для них более важны отделения.
— Естественно, есть специфика сегмента, в котором мы работаем, которая не позволяет нам делать ровно то, что делают другие. Но в области удаленного обслуживания у нас есть ряд инициатив по разработке сервиса, который будет понятен и востребован нашей аудиторией.
— Вы имеете в виду какое-то специальное мобильное приложение для пенсионеров?
— И мобильные приложения, и новые возможности обслуживания в устройствах самообслуживания, и т. д. Мы провели фокус-группы, сделали пилотный проект, сейчас начинаем тиражировать часть идей. Мы помогаем нашим клиентам повысить уровень грамотности в этом направлении и получить инструмент, в котором они разберутся, которого они не будут бояться, где выполнение операции будет сводиться к нажатию нескольких кнопок.
— Кто инициировал разработку таких сервисов? Бизнес?
— В банке есть группа сотрудников, которая занимается такими перспективными проектами. Мы как IT их поддерживаем, даем технологии, и те гибкие подходы, о которых мы с вами говорили. Когда мы выводим на рынок продукт, которого еще не было и который надо много итеративно развивать, самое плохое, что можно сделать,— попытаться изначально все «высечь в камне».
Комбинированный подход к аутсорсингу
— Какие IT-компетенции банк должен иметь внутри, а что он может отдать вовне — на аутсорсинг?
— Внутри IT имеет смысл накапливать экспертизу по бизнес-процессам, информационной безопасности, управлению инфраструктурой, сопровождению ключевых приложений, проектному управлению и частично разработке. При этом мы открыты к использованию аутсорсинга, если это качественно, управляемо и выгодно с точки зрения расходов (например, дата-центры, обслуживание банкоматов, интернет-банк, карточный процессинг и т. д.). Я сторонник комбинированного подхода. На российском банковском рынке есть примеры на 90% аутсорсингового IT. Я не берусь судить, насколько это экономически целесообразно, в том или ином случае. Иногда это позволяет серьезно выигрывать в скорости.
— Для большого банка полный аутсорсинг нецелесообразен?
— Аутсорсинг должен быть не самоцелью, а инструментом достижения других целей или решения задач. Для большого банка стопроцентный аутсорсинг, на мой взгляд, нецелесообразен. Но все иметь внутри — тоже невыгодно и может навредить бизнесу. Мы постоянно прорабатываем и просчитываем разные направления ИТ-сервисов с точки зрения возможности и целесообразности использования аутсорсинга. Сейчас, например, мы пилотируем несколько проектов по получению сервисов по модели SaaS (software as a service) и PaaS (platform as a service), в том числе для критичных систем.
Аутсорсинг также востребован там, где необходима какая-то сложная или специфичная разработка. Часто сложно привлечь в банк разработчиков определенного профиля. По сравнению с компаниями—разработчиками ПО в банке другая культура, другие процессы и, в том числе, требуются другие компетенции, чтобы эффективно управлять высококвалифицированными сотрудниками, которые являются экспертами в узкоспециализированных областях и часто необходимы банку на определенный срок для решения задач определенного уровня.
1 октября Альберт Борис будет выступать с докладом по теме «Организация работы проектного офиса в Совкомбанке» на конференции Банкир.ру.
Подробнее о конференции и участии в ней.
