клиентов, начиная с бизнеса по ипотечному кредитованию.
Созданная Мэтисоном для достижения этой цели команда руководителей приступила к работе. Ее члены сначала использовали методы, известные как проектирование разработки ориентированного на клиента видения North Star. Это принцип, позволяющий понять какой опыт и какие выгоды, приобретенные у поставщиков финансовых услуг, клиенты ценят больше всего, чтобы соответственно направлять инновационную деятельность. В интервью представители компании так описали два элемента North Star: «Я рассматриваю банк как шлюз, который соединяет меня с нужными мне экспертами и инструментами» и «Банк облегчает мне поиск, покупку и управление моим домом в цифровом формате, при необходимости оказывая помощь».[1]
Затем группа разработала структуру, которая включала в себя опыт всех главных клиентов и бизнес-цели каждого из них. Одним из примеров была заявка на ипотечный кредит. Целью стало сокращение времени и усилий, необходимых клиенту для заполнения заявки и ее одобрения банком. Затем, исходя из этого опыта, руководство начало формировать специализированные кросс-функциональные Agile-команды. Они также задействовали множество инструментов, необходимых для быстрого внедрения инноваций. Например, использовался принцип коллокации членов групп, а их финансирование было привязано к бизнес-результатам, а не к характеристикам продукта. «В основе нашей новой модели лежит организация “пути клиентов”, – рассказал Мэтисон. – Эта конструкция обеспечивает кросс-функциональной команде редкую возможность принимать точку зрения клиента при каждом его взаимодействии с банком. Как бы мы ни старались, мы никогда не смогли бы достичь этого с нашей старой функциональной организацией, ориентированной на финансовый продукт».[2]
Agile-команда лидеров, возглавляемая Франсом Уолдерсом, директором по цифровым технологиям розничного банка, знала, что ей необходимо добиться впечатляющих побед, чтобы создать импульс для Agile-перехода. Было решено сначала сосредоточиться только на одной или двух самых больших целях, которые, как были уверены бизнес-единицы и инновационные альянсы, они могли бы реализовать. Разработкой алгоритма подачи заявок на ипотеку должна была заняться одна из самых первых постоянных групп «пути клиента». Согласно новой концепции, заявление можно было заполнить менее чем за час, пользуясь смартфоном или компьютером. Последующее обсуждение (по требованию регулятора) должно было проходить по телефону, а не в ходе личной встречи, и банк сообщал свое решение в течение нескольких дней, а не недель.
Под руководством разработчиков члены команды провели исследование клиентов, чтобы получить обратную связь. Затем группа, уже имея опыт работы и обслуживания клиентов, разработала новые цифровые процессы, чтобы создать решение, желательное для клиентов. Инженеры-программисты совместно с инженерами по обработке данных и аналитиков написали код, чтобы ввести в эксплуатацию эти новую процедуру. Группа выполнила все предписанные шаги в рамках двухнедельных спринтов, получая обратную связь от потребителей в конце каждого из них. Первоначально клиентам был представлен частичный прототип. Затем наступила очередь полноценных прототипов и законченных систем, готовых к эксплуатации. Члены Agile-команды из операционного подразделения руководили обучением небольшой группы консультантов по кредитным заявкам, когда новое приложение было выпущено в ограниченном доступе, а затем с всеми консультантами перед официальным выходом. «То, что представители бизнеса и технологий работают как одна команда, имеет важное значение для успеха, – сказал нам Уолдерс. – Если бы группы работали отдельно, даже при максимальных усилиях по согласованию это не было бы даже приблизительно похоже по скорости реализации и качеству продукции на то, что нам требуется. Начав с покупки жилья и владения им, теперь мы используем новые способы работы во всех сферах обслуживания клиентов».[3]
Чтобы команда по заявкам на ипотечные кредиты и другие команды, занимавшиеся изучением «пути клиента», могли достичь такого быстрого успеха, RBS начала использовать несколько других Agile-инструментов. Были проведены изменения в бюджетировании, финансировании и управлении, которые мы обсудили в Главе 5. Ввелись командные показатели эффективности. Были использованы методы выбора из Scaled Agile Framework, одного из фреймворков масштабирования, описанных в Главе 2, для управления взаимозависимостями между основными механизмами и многочисленными командами «пути клиентов», обслуживаемыми системами.
По мере того как росли возможности организации в области применения Agile, улучшались и результаты. Внедрение Agile позволило бизнесу банка, занимающимся покупкой жилья и владением им для физических лиц, существенно увеличить темпы инноваций. Банк первым в Соединенном Королевстве стал использовать электронную заявку на ипотечный кредит; в настоящее время 90 % всех заявлений электронные. RBS увеличил переброску ипотечных сумм по цифровым каналам с 34 % в первой половине 2017 года до примерно 60 % годом позже. Это сократило среднее время с подачи заявки до предложения с двадцати трех дней до одиннадцати. Перечисленные инновации помогли банку достичь лидирующих на рынке показателей лояльности клиентов (NPS), получающих новую ипотеку. Когда мы писали книгу, команда по подаче заявок на ипотечный кредит продолжала работать и совершенствовать этот процесс. Цель состоит в том, чтобы еще больше сократить объем действий клиентов и время согласования и опередить всех активных конкурентов. Между тем, успех в бизнесе покупки и владения жильем помог укрепить в организации приверженность к гибким методам, что привело к внедрению Agile в обслуживание физических лиц по всему банку.
Проблемы процессов и технологий
Если вы дочитали до этого момента, вы должны уже достаточно хорошо представлять, как Agile может помочь компаниям разрабатывать отличные решения для клиентов, то есть продукты и услуги, обеспечивающие потребителям или бизнес-покупателям нужную им ценность. Но все они зависят от процессов, шагов и процедур, с помощью которых организации создают и поставляют эти продукты. Процессы почти всегда опираются на технологии, в первую очередь на программное обеспечение.
Однако в большинстве компаний существующие процедуры и технологии являются барьерами, а не стимулирующими факторами на пути к удовлетворению потребностей клиентов. Подумайте об отправной точке RBS: громоздкие процессы и системы мешали оказывать качественные услуги. Это обычная ситуация. Например, региональные офисы или бизнес-единицы компании могут действовать совершенно по-разному, что затрудняет или делает невозможным интеграцию и обучение. Никто не делает это намеренно; это просто результат тысячи мелких решений, принятых за годы разными людьми. Или организация приобрела ряд других компаний и никогда их эффективно не интегрировала, сохранив множество различных и неоптимальных систем. И конечно, процессы и технологии, с которыми приходится иметь дело сотрудникам, могут порождать разочарование и неэффективность.
К сожалению, программное обеспечение, которое разрабатывает IT, печально известно тем, что создает эти трудности. Общая проблема для компаний – тратить миллионы на специальное ПО, хотя стандартные готовые решения отвечают их запросам. Они разрабатывают свое программное обеспечение с помощью традиционной каскадной модели, с заранее прописанными требованиями, поэтому оно неизбежно содержит функции, которые никто не использует. Таким образом создается уровень сложности, с которым простым людям справиться нелегко. Многие IT-отделы настолько завалены запросами на изменение или создание новых продуктов, что возникает своего рода теневые IT-ресурсы. Руководители, которым надоело ждать, создают собственные мини IT-группы или ищут внешних поставщиков. Это только усугубляет сложность, создавая неоправданно разнообразные процессы, системы и технические стандарты.
Бюрократия обычно придерживается имеющихся процессов и технологий настолько долго, насколько это возможно, что означает достаточно длительный временной промежуток. В конце концов, менять их дорого. Изменения будут мешать повседневному бизнесу. И результаты в любом случае будут ненамного лучше, как считают бюрократы. Конечно, когда все станет слишком плохо или дорого, команда руководства наконец решит, что настало время перемен.
Управляющие собираются за закрытыми дверями, готовят спецификации и бюджет для новых процессов и систем, а затем приказывают своим подчиненным во всем разобраться. Такие организации хронически несбалансированны и быстро переходят от застоя к периодическим попыткам неэффективных изменений.
Как мы видели на примере RBS, компании, которые хотят идти по пути к Agile, поступают по-другому. Они понимают, что решения, значимые для клиентов, должны основываться на потребностях самих покупателей. Такие задачи должны формировать процессы, а технологии их должны поддерживать и автоматизировать (Рис. 7–1). Agile-специалисты также считают, что по мере изменения потребностей клиентов следует постоянно перестраиваться. Они считают, что Agile-команды – это инструменты, лучше всего подходящие для разработки инновационных решений. То, что нужно сделать и как это нужно сделать, выглядит расплывчато и непредсказуемо – типичная ситуация в работе с потребителями. Специалисты полагают, что группы операционные и занимающиеся инновациями должны тесно сотрудничать, а в некоторых случаях даже объединяться.
В этой главе мы рассмотрим нововведения в процессах и технологиях и постараемся понять, как они способствуют созданию передовых решений для клиентов. Здесь в основном будут рассмотрены этапы и системы, лежащие в основе удовлетворения потребностей клиентов, а не физические продукты. Но это также касается и множества услуг, которые те поддерживают.
Работа, исходя из решений для клиентов
Командам, ищущим решения для внедрения инноваций в процессы и технологии, следует сосредоточиться на покупателях, как и любым другим Agile-командам. Иногда это внутренние клиенты. Но даже в этом случае важно рассматривать потребности внешних потребителей, которых ваши внутренние клиенты обслуживают. Слишком часто такие отделы, как IT и финансы, по-прежнему рефлексивно фокусируются на внутренних запросах – и это одна из причин плохой репутации многих IT-департаментов. Новшества в таких случаях отражают видение проблемы инженеров-программистов или финансовых специалистов, но никак не ценности клиента. Agile-команды, напротив, рассматривают решения для клиентов, процессы и технологические инновации как Agile-продукты. Они работают, исходя из потребностей потребителя, стремясь, чтобы все инновации были простыми и эффективными.