Есть много аспектов в бизнесе и отраслях, которые влияют на маркетинговый ландшафт. Специалисты по маркетингу, которые понимают эту ситуацию, могут использовать свои знания, чтобы получить преимущества в продажах и прибыльности своих компаний. Узнав больше о маркетинговом ландшафте, вы сможете более эффективно прогнозировать и понимать маркетинговые ситуации. В этой статье мы рассмотрим, что такое маркетинговый ландшафт, объясним, почему он важен, и резюмируем, как маркетинговые тенденции влияют на этот ландшафт.
Что такое маркетинговый ландшафт?
Маркетинговый ландшафт — это структура, в которой компании или специалисты по маркетингу определяют свои наиболее важные рынки или конкурентов и отслеживают их сильные стороны, стратегии и характеристики. Это способ, с помощью которого специалисты по продажам могут определить, какие инструменты работают для разных аудиторий с течением времени. Они могут предсказать состояние рынка, внимательно отслеживая маркетинговый ландшафт и отслеживая, какие элементы или стратегии нравятся и не нравятся разным демографическим группам. Маркетинговый ландшафт включает в себя как реакцию клиента на продукт, так и все инструменты, которые компания использует для мониторинга и создания этого продукта.
Backyard Landscape Design App Free
Чтобы создать маркетинговый ландшафт, бизнес-лидеры исследуют программы конкурентов и свои собственные, коммуникационные схемы, работу с населением, системы обмена сообщениями и услуги. Оценка того, как клиенты взаимодействуют с этими элементами и покупают продукты, дает им представление об их маркетинговом ландшафте и о том, как они сравниваются с конкурентами. Мониторинг ландшафта с течением времени может дать руководителям надежные данные, которые они могут использовать для прогнозирования рынка, и они могут использовать эти данные для определения маркетинговых тенденций в системе. Реагирование на маркетинговые тенденции или активное участие в них может помочь улучшить продажи и еще больше развить маркетинговую среду.
Программы для Windows, мобильные приложения, игры — ВСЁ БЕСПЛАТНО, в нашем закрытом телеграмм канале — Подписывайтесь:)
Что такое маркетинговые тренды?
Маркетинговые тренды — это предпочтения клиентов на рынке с течением времени. Маркетинговая тенденция означает, что клиенты чаще покупают определенный товар. Например, пузырчатые куртки могут стать популярными в стране, потому что их носит знаменитость. Спустя много лет популярность пузырчатых курток продолжает расти, пока они не станут маркетинговой тенденцией. Из-за этой тенденции многие компании, производящие зимнюю одежду, вкладывают средства в производство пузырчатых курток и увеличивают свою прибыль.
Маркетинговые тренды могут ассоциироваться с чем угодно в жизни клиента, например, с сезонами, людьми или обычными обстоятельствами. Важным аспектом маркетинговых тенденций является то, что они являются общим опытом. Если у многих людей достаточно опыта или предпочтения, это может стать тенденцией в маркетинге. По мере того, как маркетинговые тенденции продолжают появляться и исчезать, бизнес-лидеры используют эти данные и элементы своего маркетингового ландшафта для более предсказуемого увеличения продаж.
How To Start A Landscape Business: Industry & Consumer Analysis
Почему маркетинговые тренды важны?
Маркетинговые тенденции важны, потому что они влияют на текущие и будущие продажи. Эти тенденции позволяют предприятиям использовать преимущества для улучшения каждого элемента компании, от прибыли до того, как лидеры управляют своей компанией. Тенденции позволяют предприятиям экспериментировать и получать прибыль от временной ситуации. На протяжении всего тренда руководители отдела маркетинга могут полагаться на популярность, чтобы получать стандартный доход, пока сотрудники работают над новыми идеями. Если какие-либо новые идеи окажутся успешными во время тренда, лидеры могут продолжать использовать их для получения прибыли даже после окончания тренда.
Маркетинговые тенденции помогают постоянно улучшать бренд, поощряя новые идеи. Поскольку новые идеи постоянно получают отзывы от клиентов, бизнес может оставаться актуальным и улучшать свои продукты, чтобы соответствовать текущим тенденциям. Во время маркетинговой тенденции бизнес-лидеры также могут использовать отзывы от увеличившегося количества клиентов, чтобы выявить лучшие ценности бизнеса. Прямая обратная связь может помочь руководителям увидеть лучшие моменты в бизнесе и улучшить их для повышения эффективности работы с клиентами.
5 важных тенденций маркетингового ландшафта
Есть несколько общих тенденций, влияющих на маркетинговые ландшафты, в том числе:
1. Искусственный интеллект
Искусственный интеллект (ИИ) — это маркетинговая тенденция, которая помогает повысить эффективность покупок клиентов за счет автоматизированных процессов на веб-сайтах, в интернет-магазинах и посредством телефонных звонков. Популярность технологии искусственного интеллекта частично помогла изменить ландшафт онлайн-бизнеса. Предприятия могут использовать технологию ИИ для улучшения многих аспектов обслуживания клиентов, включая оформление заказа, обслуживание клиентов, информационную помощь и узнаваемость бренда.
2. Экспериментальный маркетинг
Экспериментальные кампании и маркетинговые тактики помогают привлечь клиентов через реальные события или взаимодействия. Это может включать в себя найм актеров или знаменитостей для продвижения бизнес-бренда в прямом эфире для потенциальной аудитории. Например, маркетологи могут отправиться в тур с музыкантом, используя платформу знаменитостей для продвижения бренда с помощью известных отзывов о продукте. Лидеры маркетинга также могут использовать средства массовой информации, такие как социальные сети, для распространения информации о бренде о продукте через знаменитость в Интернете.
3. Автоматизированный маркетинг
Некоторые маркетинговые тенденции помогают предприятиям сократить расходы. Автоматизированный маркетинг позволяет предприятиям более эффективно осуществлять маркетинг при меньших затратах. Для клиентов автоматизированный маркетинг популярен из-за его скорости и точности для рекомендаций, соображений и процессов оформления заказа, связанных с интернет-магазинами компании. Чем эффективнее процесс благодаря автоматизированному маркетингу, тем более удобными для покупателей могут быть покупки.
4. Представительский брендинг
Брендинг руководителей — это когда лидер бизнеса, например, узнаваемый генеральный директор или представитель компании, помогает рекламировать бренд, занимаясь маркетингом. Этот вид брендинга включает в себя присутствие в социальных сетях и публичное присутствие, взаимодействие с вашими клиентами, чтобы увеличить потенциальный оборот потенциальных клиентов. Лидеры также могут использовать управленческий брендинг, используя мотивационные речи и благотворительные акции.
Брендинг руководителей — это тренд по той же причине, по которой знаменитости — тренды. Возможно, клиентов не нужно убеждать следить за жизнью и событиями кого-то известного, даже если этот человек является генеральным директором компании. Это заставляет клиентов прислушиваться к тому, что продает генеральный директор, даже если они не входят в демографическую группу для этих продуктов.
5. Онлайн-единство
Онлайн-единство — это когда компания поддерживает постоянное присутствие в социальных сетях на нескольких платформах. С ростом числа онлайн-взаимодействий между клиентами и компаниями онлайн-единство между учетными записями становится тенденцией, которая помогает клиентам лучше узнавать бренд компании. Это также может помочь клиентам легче находить компанию во всех социальных сетях, которые они используют.
Источник: buom.ru
Управление ИТ-инфраструктурой компаний
Сегодня ИТ-специалистам приходится работать по новым правилам, ориентируясь не на технологии как таковые, а на продвижение самих бизнес-целей. Становится все больше компаний выбирающих решения, которые позволяют делать ИТ-инфраструктуру гибче и проще, но при этом надежнее.
Именно поэтому имеет смысл говорить не о наборе отдельных приложений, а об ИТ-ландшафте, где развернут постоянно растущий пакет сервисов.
Концепция ИТ-ландшафта
Концепция ИТ-ландшафта описывает совокупность элементов архитектуры и их отношения в структуре предприятия (это архитектура приложений, бизнес-архитектура, архитектура информации, техническая архитектура и архитектура развёртывания) . Эти архитектуры являются способом объединения функциональных и бизнес-потребностей организаций с возможностями информационных технологий в условиях их экспоненциальной сложности.
Выгоды от внедрения информационного ландшафта
Выгоды от внедрения эффективного и полезного для организации информационного ресурса определяются такими факторами как ускорение сбора и обработки информации, повышение эффективности обмена информацией с внешними контрагентами, снижение рисков операционной деятельности и др.
Зарубежная статистика (по данным GartnerGroup) свидетельствует, что от 50 до 80% внедрений информационных систем являются эффективными и становятся отправной точкой для успешной деятельности организации. По различным оценкам и в России примерно 40–60% проектов внедрения информационного ландшафта можно считать успешными.
Делать инфраструктуру ради неё самой, конечно, нет смысла. Главное — это понимание, что грамотную инфраструктуру предприятия нужно строить в комплексе, иначе невозможно предугадать взаимные требования систем и обеспечить необходимый запас расширения. Спрос на построение правильной инфраструктуры огромный — эти вопросы важны как для начинающих компаний, разрабатывающих бизнес с нуля, так и для тех, кто стремится расширить или модернизировать свои системы.
С чего стоит начинать?
Внедрение IT решений в деятельность организации должно начинаться с дизайна ландшафта. И самым важным в этом является определение концепции видения компании, а предпосылкой к этому служат современные тенденции развития бизнеса, обусловленные рядом требований к ИТ-инфраструктуре независимо от специфики их деятельности. Это:
- необходимость предоставлять массовые услуги в полном объеме и одинакового качества во всех точках обслуживания централизованного управления распределенной ИТ-системой;
- хранение, обработка и защита огромных объемов информации требуется при переходе к персональной работе с каждым клиентом;
- необходимость быстро принимать решения и реагировать на изменения в стремительно развивающейся тенденции развития мобильных и интернет-технологий.
Такие требования и приводят к тому, что мониторинг и визуализация IT-ландшафта необходима.
Что даст мониторинг и визуализация ландшафтного дизайна ИТ?
- бесперебойную работу (работа в режиме 24×7);
- масштабируемость (проактивный мониторинг);
- безопасность (система защиты информации);
- скорость изменений (постоянное повышение уровня сервиса);
- прозрачность и управляемость (простое управление, легкая настройка)
Как построить IT-ландшафт
Построение правильных элементов архитектуры позволит осуществить значительный прорыв в развитии самих технологий и возможностях их применения в бизнесе.
Построение IT-landscape необходимо для компаний разного масштаба, отличие лишь в подходе построения инфраструктуры. Особенности ландшафта определяются архитектурой внедряемой системы управления. Важную роль играет количество пользователей, которые будут работать с системой, требования по отказоустойчивости, доступности данных, сервисов. Конкретная специфика определяется не отраслью, в которой работает компания, а требованиями бизнеса.
К примеру, для крупных торговых предприятий критически важна возможность быстро наращивать розничную сеть: открывать новые магазины и склады и оперативно интегрировать их в общую ИТ-систему. В связи с этим для ИТ-инфраструктуры торговых сетей характерна масштабность и большая территориальная распределенность. В
банковском секторе приоритеты традиционно смещены в сторону безопасности: огромное значение придается защите финансовой и персональной информации. В банках всегда использовалась практика резервирования ЦОДов на удаленной площадке и глубоко эшелонированная система доступа к данным.
Фактически, концепция построения — это представление о будущем системы, определение дальнейшего пути организации, методов и планов ее развития, позволяющие оценить необходимые ресурсы. Само же проектирование происходит с учетом четырех фаз внедрения — разработки, тестирования и стабилизации, введения в эксплуатацию и дальнейшей поддержки. И все эти четыре этапа невозможны без грамотной системы мониторинга.
Мониторинг и визуализация ИТ ландшафта
Полноценный мониторинг развитого ИТ ландшафта требует универсальной системы — с одной стороны необходимо обеспечить контроль работоспособности всех элементов инфраструктуры и уведомления о сбоях, а с другой стороны — требуется представить каждый из этих элементов наиболее наглядным образом и показать взаимосвязь с остальными компонентами ландшафта.
Такая система должна иметь следующие возможности:
- мониторинг работы компьютеров, серверов, принтеров
- контроль сетевого оборудования
- мониторинг промышленного оборудования
- мониторинг доступности каналов связи
- проверка работоспособности программного обеспечения
- уведомления о сбоях через различные каналы: e-mail, sms, мессенджеры, телефонным звонком
- эскалация сообщений до момента разрешения проблемы
- готовность к работе с большими объемами данных — как хранением, так и обработкой
С точки зрения визуализации:
- графическое представление элементов всей инфраструктуры
- отображение взаимосвязи объектов и их характеристик
- отображение элементов на схемах, планах и географических картах
- различные представления: живая схема, графики, таблицы
Платформа мониторинга SAYMON отвечает перечисленным выше критериям, при этом постоянно развивается и дополняется новыми возможностями. Наиболее ожидаемые в ближайшее время — аналитика и автоматическое обнаружение новых элементов инфраструктуры появятся в одном из ближайших релизов.
Это слайд-шоу требует JavaScript.
Поделиться ссылкой:
- Нажмите, чтобы поделиться на Twitter (Открывается в новом окне)
- Поделиться на Facebook (Открывается в новом окне)
- Нажмите, чтобы поделиться в Google+ (Открывается в новом окне)
- Нажмите, чтобы поделиться на LinkedIn (Открывается в новом окне)
Источник: saymon.info
На что похож ИТ-ландшафт обычного банка в России
Речь про обычный розничный банк, как вы понимаете
ИТ-ландшафт чаще всего повторяет оргструктуру и отражает исторические процессы. Например, мы запускали банк в 2002 году, когда вообще все банки в России, пожалуй, кроме Сбера, были ориентированы на юрлиц. Возможно, сейчас это будет уже немного тяжело вспоминать, но банковского пластика почти не было, было много кеша. Соответственно, архитектура банка тех лет была заточена под юрлиц, то есть большие разовые транзакции, которые можно обрабатывать чуть ли не руками.
Ядро любого банка — АБС. Это движок, который, например, ведёт главную книгу счетов банка, выполняет бухгалтерские операции и формирует бухгалтерскую отчётность. У нас эта АБС от компании Кворум. Учитывая давний год рождения, первичная задача АБС тогда была вести учёт и формировать отчётность, которую жёстко требовал ЦБ, и делать, собственно, расчёты.
Без этих двух вещей банк работать не может. Чуть позже мы стали заниматься картами, а у Кворума тогда не было карточного модуля, поэтому мы завели ещё и вторую АБС TranzWare. Обычно в банковском ландшафте это выглядит так: либо поверх старого «движка» вешается более новый карточный модуль, либо же сразу «из коробки» используется АБС с картами.
В нашем случае мы интегрировали две АБС, поделив их по продуктам. Сама необходимость отдельной АБС для карт обуславливалась тем, что тогдашняя архитектура не была готова к большому количеству транзакций, по которым нужно было отвечать чуть ли не в реальном времени. Из железа у нас в этот период были x64-машины IBM, причём чуть позже с ростом нагрузки появилась одна, вообще индивидуально собранная под нас.
Интегрировались они тогда напрямую без всяких промежуточных шин и брокеров. Ну, знаете, вот это «мои файлы — твои файлы, мой дом — твой дом».
С тех пор кое-что поменялось, конечно.
Ядро банка
АБС для юрлиц, АБС для физлиц (или одна АБС со всей бухгалтерией, проводками и отчётами, что случается чаще) + два дата-центра (один боевой, один для горячего резерва) плюс операторы — это минимальный набор для работы банка. Второй ЦОД и вообще жёсткие требования по Disaster Recovery обусловлены ещё тем, что ЦБ требует очень высокий уровень доступности сервисов ядра. Упрощая, если у какого-то крупного банка не будет в конце банковского дня рассчитан клиринг, то это проблема. На второй день это уже катастрофа федерального масштаба для экономики практически независимо от страны, поэтому центробанки по всему миру предъявляют очень жёсткие требования к тому, насколько качественный должен быть код (точнее, как должны быть устроены процессы разработки и деплоя) и насколько быстро банк должен восстанавливаться после разных аварий.
Тем не менее только на АБС работать практически невозможно, потому что не будет же никто каждую проводку вбивать в консоль. Хотя и такой период в банкинге был, когда клиент звонил по телефону или приходил в офис, а операторы работали чуть ли не напрямую с базой. К счастью, в 2002 году всё было уже куда и куда лучше.
Второй уровень: продукты и шина
Сама АБС очень редко хранит продуктовую логику. Условно, АБС — это движок, который обеспечивает взаимодействие с законами физики. Только вместо физики у нас ЦБ и финансовая система. По сути, язык API АБС представляет собой некий ассемблер банковских операций: зачислить на такой-то счёт, снять с такого-то счёта и т.п. Часто туда входит какая-то минимальная логика для очень стандартных продуктов вроде депозитов, но всё, что сложнее, реализуется в системах выше уровнем.
Наша первичная система уровнем выше уже была самописная. Это Homer, который изначально разрабатывался в Чехии для всей Группы Хоум Кредит, но в какой-то момент мы здесь поняли, что банкинг и ИТ в России растут неимоверно быстро и пора забирать разработку к себе. В итоге мы забрали у штаб-квартиры весь исходный код, переделали всё под реалии РФ и получили собственный сервис, который дальше развивали. Поскольку исторически мы сразу начали заниматься потребительскими кредитами, Homer очень быстро оброс функционалом расчёта кредитных продуктов наличными, кредитных карт и так далее.
Для работы с картами нужен ещё один отдельный сервис с отдельной логикой. Карточный продукт сам по себе намного более технологичная вещь, чем кредитный продукт. Например, потому что система завязана на много устройств, разные платёжные системы, интеграцию с ними. И карта очень специфический инструмент (особенно для тех лет) — нужен реалтаймовый процессинг, быстрые операции и т.п.
Вы только вставили карту в терминал — а банк уже должен дать ответ, а не рассматривать заявление 10 минут. Запросы из POS-терминалов и банкоматов идут в карточный процессинг, который подтверждает возможность совершения операций. Соответственно, все карты и банкоматы Банка Хоум Кредит мы обслуживаем сами — процессинговый центр от Compass Рlus, на платформе TranzWare.
Третий уровень: каналы взаимодействия
Ядро делает сами банковские операции, продуктовый слой отвечает за логику, но ко всему этому ещё нужны фронты. Основных фронтов у нас (как и у большинства других банков) два. Первый — софт для офлайн-обслуживания, по сути — рабочее место оператора отделения, которое также используется для контакт-центра. Второй — онлайн-банкинг, дистанционное обслуживание.
Там поверх одной и той же логики взаимодействий лежит фронт в виде web-версии, iOS-приложения и Android-приложения. Вполне возможно, что к этим фронтам присоединится со временем и чат-бот, но пока он выступает, скорее, ассистентом оператора в контакт-центре.
Фронты — это, по сути, интерфейсы к продуктовым системам, соединяются они с ними через шину.
Естественно, в 2002 году про онлайн-банкинг никто не думал, а сейчас это фокусный продукт. Клиентам очень важно иметь приложение, банк в кармане. Причём это реальная точка конкуренции: если вдруг клиенты не могут разобраться или получить какую-то услугу, то очень быстро меняют банк.
Россия — одна из самых требовательных стран по юзабилити и уровню сервиса в приложениях. Тот уровень, который есть у нас, сильно выше привычного европейского. Причём у нас люди не медлят менять банк при неудобствах: сначала человек пробует приложение, если удовлетворяет базовую потребность — начинает разбираться дальше и дальше. Мы много сил тратим на то, чтобы наше приложение было максимально близко к текущим потребностям наших клиентов и отраслевым бенчмаркам, плюс сейчас я могу сказать, что в некоторых продуктах и сервисах мы лидируем на рынке.
Также фронтами можно назвать интеграции со внешними партнёрами: тем же торговым сетям, которые выдают кредиты на покупку товаров, также предоставляются рабочие места операторов для оформления заявок на кредит. Часто — в их собственных торговых приложениях, то есть каждая сеть или каждое приложение — это своя отдельная интеграция. Их фронты работают по API с продуктами второго слоя, формируя заявки и передавая ответы.
Ещё один относительно новый канал — это доставка. Раньше была одна модель, когда клиент приходил к нам за чем-то физическим, например, за деньгами, документами или картой. Сейчас всё чаще и чаще мы доставляем что-то клиентам домой или на работу. Для такого обслуживания у нас есть отдельная система. Выездной сотрудник получает что-то вроде ограниченного по функционалу рабочего места оператора с возможностью построения маршрутов.
Работа с данными
Как я уже говорил, ИТ-ландшафт крупных банков в России, в принципе, практически одинаковый. Разница в кластеризации (структура ИТ стремится к структуре организации) и в более новых-старых решениях. У каждого крупного банка есть своя разработка, и каждый самостоятельно поддерживает свои решения. В современных финансовых организациях ИТ не живёт отдельно от бизнеса почти никогда, потому что это важный фактор бизнес-эффективности, то есть в конечном счёте конкуренции.
Конкуренция, связанная с ИТ, идёт сейчас в двух основных направлениях: практической применимости анализа данных и удобстве (речь как для юзабилити клиентов, так и для партнёров, а в случае партнёров ещё и удобстве интеграции). В первую очередь анализ данных — это умение работать с рисками.
Финансовые организации ярко отличаются от всех остальных игроков ИТ-рынка как раз тем, что отлично понимают, какой риск сколько стоит. Это буквально ядро банковского бизнеса. Например, та же выдача кредита должна сопровождаться скорингом клиента по внешним источникам, по известным платёжным и банковским событиям, по look-alike и другим моделям — чтобы за несколько секунд принять решение о том, какую сумму и с какой вероятностью он сможет выплатить. Если кредит одобряется — значит, риск для нас приемлемый. Очень легко навыдавать безнадёжных кредитов и прогореть, с одной стороны, — и очень легко отдать кредитные сделки банкам-конкурентам с другой.
Также нужен постоянный анализ клиентских потребностей. Данные нужны для создания новых банковских продуктов и сервисов, поиска эффективных способов коммуникации с клиентом и так далее. Маркетинг не может без данных, розница не может без данных, никто не может без данных.
В случае конкретного анализа этих самых данных у нас тоже два поколения систем. Во-первых, традиционная CRM (есть системы для онлайн-принятия решений и офлайн-принятия), анализа маркетинговых компаний и т.п. Данные для этих систем берутся, естественно, не с прода, а с крупного хранилища, содержащего практически полные списки всех банковских событий с момента запуска банка. Данные этого хранилища мы почти не используем в операционных процессах, обновляем его итерациями с некоторым запозданием: для каких-то таблиц это минуты, для каких-то — дни.
Параллельно работает near-realtime-система на Hadoop для анализа больших данных. Она уже может поддерживать операционные процессы, в частности, матчинг, оперативный профиль, может использоваться для работы антифрода и т.п. Данные в неё попадают асинхронно проду, но почти с той же скоростью.
В этом месте вы можете спросить меня про антифрод и другие детали ИБ, но, увы, тут я не могу особо много рассказывать. Общая тенденция — от имплементированных в каждую продуктовую систему решений переходить к централизованному решению, работающему в режиме реалтайм. В ИБ ещё очень важно соответствовать и требованиям ЦБ, и требованиям платёжных систем, что означает определённые требования к архитектуре и процессам разработки и достаточно частые и подробные аудиты.
Текущие изменения
Можно с некоторым допущением сказать, что любой современный банк — это ИТ-компания с банковской лицензией.
Тренд текущей ситуации — замещение коммерческих продуктов, которые сейчас уходят с рынка. Если, например, замена системы бекапа — это просто проект с понятными сроками и понятной ценой, то вот матмодели, которые лежали в некоторых продуктах, заменить куда сложнее. Банкам сейчас придётся с нуля разрабатывать то, что раньше можно было просто купить.
В этом плане нам достаточно повезло, что мы всегда делали акцент на собственную разработку. С уходом Визы и Мастеркарда ещё добавилось разработки для карточных продуктов — нужны новые платёжные сервисы и цифровые услуги. Замена всего этого требует капитала: в кризис выживает тот, кто крупнее. Стартапы-финтехи имеют все шансы умереть или продаться, потому что сейчас будет большой период разработки с отложенной выгодой, замены части систем и интеграций, но это и определённая возможность обновления архитектуры. Для банков с большой историей, как мы, это достаточно хороший шанс.
Тренды года те же самые, что и в прошлый, и позапрошлый год: большие данные и клиентская аналитика. Очень большое влияние оказывают переход бизнеса в онлайн и высокие требования к юзабилити клиентских приложений.
Управление разработкой
От гибкости архитектуры зависит скорость разработки, поэтому тенденции в развитии архитектуры тоже более-менее одинаковые: монолиты ядра разных лет, сервисный слой основных продуктов и современные микросервисы поверх. Вся новая разработка максимально ведётся в микросервисах из-за скорости разработки и внедрения и простоты поддержки. Как и всегда, есть потребность выпускать новые вещи быстро. И если в прошлые годы это было конкурентным преимуществом, то сейчас это уже жизненно важная потребность.
Крупные системы создают очень много зависимостей. В нашем случае это системы ядра и продукты: в ядре — монолиты, в продуктах — большие сервисы. Как я уже говорил, всё новое мы делаем на микросервисах, и это связано, в частности, с управленческими процессами и возможностью быстро вносить правки любой команде в то, что у неё в зоне ответственности.
Стратегии разбора монолитов вроде «мы всё перепишем за 10 лет» у нас нет. Скорее, мы рассматриваем их как некий операционный ассемблер, а разработку сосредотачиваем не на изменении их функциональности, а на создании сервисов, которые эту функциональность реализуют через атомарные операции, обращаясь к ядру. Поэтому продуктовая логика на фронтах может меняться очень быстро.
В классической архитектуре современного банка у каждого подразделения есть своя крупная ИТ-система. Она чаще всего обособлена, то есть взаимодействует с другими системами на уровне, например, той же шины. Интеграционные проблемы внутри подразделения, естественно, куда меньше, чем снаружи. Именно поэтому нужны микросервисы — разработка двигается в сторону всё более и более тесной интеграции продуктов.
В нашем случае у нас организованы стримы, состоящие из ИТ-специалистов разных компетенций и людей, отвечающих за развитие бизнеса, каждый из которых отвечает за ценность, владеет чем-то крупным в части бизнеса, ИТ-системами или их компонентами и пакетами микросервисов. Команды стримов развивают архитектуру, сами решают, когда и как делать реинжиниринг или рефакторинг.
Но, что важно, исходят они не из функциональных потребностей, а из потребности целого стрима. Внутри стримов самый главный вопрос — насколько быстро и безболезненно для основного бизнеса можно выпустить новую фичу или продукт. Некоторые банки продолжают жить редкими крупными релизами уровня «революция каждые полгода». Когда-то и у нас было 4 релиза в год, сейчас 2 релиза всего ландшафта в месяц + минорные патчи.
Естественно, процесс релиза в любом банке — это не то же самое, что поправить код на проде. Любой код, попадающий на прод, проверяется со всех сторон и не один раз.
Причём требования ЦБ и вообще индустрии таковы, что проверять нужно не только возможные баги, но и злонамеренное изменение кода изнутри, поэтому тестирование и ревью делают как внутри команд, так и независимый отдел качества. Ещё одна важная вещь на фронтах — проверка интерфейсов, на том же Android сотни моделей телефонов, и если какая-то форма поедет на одной из них, мы потеряем клиентов. Разумеется, пропущенные баги в финансовой логике — это сразу и репутационные потери, и некислые штрафы или другие проблемы от регуляторов или платёжных систем. Кошмарный сон — остановить процессинг на несколько часов из-за ошибки в логике. Кроме нескольких итераций тестов и отладки в командах и потом ещё одной в отделе качества, есть два цикла регресса и нагрузочные тесты.
Релизы фронтов самообслуживания ещё требуют тщательного АБ-тестирования. Нельзя просто так взять и аналитически спрогнозировать поведение людей, нужны именно практические тесты, причём параллельные. Какие шаги в каком порядке, как называть элементы формы, какие данные запрашивать и когда — всё это влияет на продукт и требует поддержания большого количества разных динамических элементов. Для этого тоже нужны отдельные подходы к разработке и тестированию, а не сравнение релизов.
Интеграции с партнёрами — отдельная история. По сути, мы поучаствовали в строительстве отдельной компании-брокера, которая занимается максимально быстрой интеграцией бизнеса с нами и другими банками, чтобы бизнес мог предлагать услуги банка чуть ли не как свои. Крупных партнёров мы можем интегрировать напрямую, но обычно идёт точная работа с партнёрами в POS-бизнесе.
Эта компания получает комиссию с заявок, то есть заинтересована в сервисе для них и в поддержании особенных интеграций для каждого по потребностям. Часто они «дружат» нас с сервисами и других банков тоже, что очень удобно для клиента. С точки зрения ландшафта это означает, что у нас есть шлюзы под каждый дружественный банк и партнёров. Понятно, что, если у вас околомонопольное положение на рынке, вы можете просто опубликовать API и сказать, чтобы на него равнялись, но банки из-за конкуренции должны быть гибкими для партнёров. В частности, нужно иметь в архитектуре кучу различных методов интеграций и держать их изолированными друг от друга.
Для управления стримами мы используем фреймворк SAFe, который часто противопоставляют классическому проектному управлению. Это подходы Agile и LEAN, которые не ставят цель проекта, а задают ценность стрима. Упрощённо, набираются компетенции, роли и строятся потоки поставки ценности.
Процесс достаточно быстро реагирует на потребности рынка и позволяет оперативно направлять стримы на самую важную ценность для клиента. Классический проектный офис у нас, конечно, остался и адаптировался для сверхкрупных или срочных проектов: это, например, большие требования законодательства, системные вещи для банка.
Проектный офис синхронизирует стримы и достаёт все нужные ресурсы. Внутри стримов есть бизнес-владелец, архитектор, ИТ-лидер, Agile-лидер и команды разработки. Эти команды кросс-функциональные настолько, чтобы полностью поддерживать свой продукт.
Например, есть стрим карт, есть стрим наличных, есть кредитный стрим — каждая из команд может патчить или дополнять фичами свои части ИТ-ландшафта так, чтобы не зависеть от других команд. Внутри команды разработки обычно есть три базовых роли: аналитик, разработчик, тестировщик. Где-то добавляются девопсы, где-то юзабелисты и так далее по потребностям. Есть отдельные команды платформенных сервисов.