Влад Кучинский, solution-архитектор Bercut, рассказывает про трудности, с которыми сталкиваются аналитики в работе со сложными бизнес-процессами заказчика. Как делегировать задачи и избавится от стереотипа, что основной фактор результативности – исполнение «желаний» клиента. Возможно ли объединить клиентоориентированный подход с развитием собственного продукта.
Bercut уже 25 лет является партнером для развития бизнеса операторов связи и сервис-провайдеров, предоставляя качественные BSS (Business Support System) и VAS –решения (Value Added Services – услуги, приносящие дополнительный доход).
Business Rules Engine — платформа принятия решений, на основании логических правил и параметров событий, позволяющая управлять бизнес-сценариями работы с пользователями. На базе BRE реализовано несколько других продуктов компании, например, Welcome SMS и FakeCall. Платформа входит в периметр BSS-системы Bercut IN@Voice.
Телеком – весьма специфичная отрасль, в которой нам приходится учитывать определенные требования и факторы:
· Жесткий SLA, надежность 99.98%
· Highload 10K+tps
· Множество технологий и вендоров
· Высокая конкуренция на рынке мобильной связи
Рассмотрим на примере развития продукта BRE несколько мифов о роли аналитика в решении сложных бизнес-задач мобильных операторов.
Миф 1. «Наши рамки – требования заказчика, смотреть за их пределы – ТАБУ!»
Однажды, долгосрочный партнер Bercut обратился к нам с запросом по расширению функционала предустановленного продукта Welcome SMS (системы информирования абонентов, находящихся в зоне роуминга). Когда абонент покидает домашний регион, именно система WSMS высылает ему уведомление о месте пребывания и стоимости услуг связи в гостевом регионе. Развитие сервиса заключалось в создании возможностей для рассылки таргетированной рекламы с точностью до абонента. Желанием партнера было формировать и доставлять предложения по подключению дополнительных услуг клиентам, что позволило бы сделать их пребывание в зоне роуминга более комфортным.
Как это работает: Происходит событие - регистрация абонента в роуминге. WSMS получает основные параметры абонента из прочих систем мобильного оператора и, основываясь на них, формирует коммуникацию для клиента. Реакция системы происходит в реальном времени и обрабатывает от 200-500 запросов в секунду.
Стандартное устройство бизнес-процессов операторов связи по внесению изменений в ИТ-продукт:
1. Бизнес-заказчику требовалось создать заявку в простой системе типа Service Desk.
2. Преобразование заявки аналитиком на технологический язык
3. Внутреннее согласование заявки
4. Внесение настроек в продукт разработчиками
5. Проверка на соответствие внесенных изменений
6. Введение в коммерческую эксплуатацию
Time-to-Market в среднем 2-3 недели
Типовое решение задачи: реализовать систему с использованием CMS (Content Management System, cистема управления контентом), через которую технический специалист будет вносить изменения из excel-файла. Бизнес-процесс в данном случае не изменится.
Вместо «типового решения» мы предложили клиенту альтернативный вариант, создать платформу Business Rules Engine. Решение способное не просто удовлетворить конкретным потребностям клиента в рассылке, но и оптимизировать бизнес-процессы по внесению изменений в продукты. Тем самым сократить Time-to-Market.
Платформа позволила бизнес-заказчику вносить изменения в настройки самостоятельно, без привлечения дополнительных ресурсов, проводить тестирование внесенных изменений на тестовом окружении. Таким образом, роль технического специалиста была сведена исключительно к контролю за корректностью работы самого комплекса.
Цикл внесения изменений от 2-3 недель, сократился до 2-3 дней (от потребности, до выхода в продуктив).
Погружайтесь в бизнес-процессы заказчика, смотрите шире на задачу и проявляйте инициативу.
Миф 2. «Хорошо все, за что платит заказчик!»
Пример №1: Интеграция BRE, когда платформу BRE требуется интегрировать с одной из внутренних систем заказчика.
Типовая последовательность действий при решении подобной задачи:
1. Возникновение идеи интеграции
2. Бизнес-заказчик ставит задачу своим аналитикам
3. Оформление аналитиками заказчика описания и отправка технического задания в Bercut
4. Прояснение тонкостей реализации аналитиками команд вендора и заказчика
5. Подключение project manager в части согласования: сроков, ресурсов, стоимостей и других условий
6. Постановка в очередь на разработку
7. Разработка
8. Тестирование
9. Выпуск в продуктив
Time-to-Market в среднем 2-3 месяца
Пример №2:
Платформа BRE представляет из себя конструктор, каждый элемент которого может быть повторно использован в разных сервисах заказчика. К примеру, мы добавляем критерий «тип абонента» (b2b/b2c) для получения информации из биллинговой системы. Данный критерий становится универсальным и, в последующем, может быть использован в прочих продуктах. Если заказчик захочет «отправлять факс» только абонентам B2B, Business Rules Engine сегментирует этих абонентов. У заказчика уже есть этот критерий и он сможет легко его выгрузить.
На первый взгляд, кажется, что выгоднее оставаться в парадигме, когда любая фича для систем заказчика производится вендором. По опыту, это часто приводит к введению в компаниях политик жестко регламентирующих наличие обновлений. В некоторых случаях стоит от чего-то отказаться, занять открытую позицию, получая взамен большее.
Отказывайтесь от стандартных, рутинных, пусть и прибыльных задач, мы получаем больше новых креативных и значимых проектов.
МИФ 3: «Любой каприз за ваши деньги!» или «как не скатиться в заказную разработку, когда мы работаем с одним крупным или несколькими заказчиками?»
Bercut заблаговременно разрабатывает в RoadMap дальнейшего структурированного развития продуктов, так же было и с BRE. Принципиальное отличие подхода Bercut заключается в синхронизации его плана развития решений с планами развития продуктов партнеров и клиентов.
Именно общее информационное пространство помогает аргументировано общаться с клиентом, обсуждать рядовые запросы. RoadMap, составленный с учетом планов и пожеланий клиентов, дает понимание по срокам реализации проектов и, как задача, ложится в целевую архитектуру.»
Пример:
Заказчик решил использовать нестандартный Date Picker (интерфейс календаря для выбора даты) со способностью модифицировать конкретный параметр даты. Команда Bercut позитивно оценила идею. Логичным шагом было возвращение к RoadMap, что позволило отметить наличие в планах развития функционала «формул и выражений». Реализация планов, входивших в RoadMap с использованием математических формул и выражений для корректировки параметров, позволила получить желаемый заказчиком результат. Благодаря запланированному функционалу заказчик смог не только гибко модифицировать любой параметр типа «дата», но и получил возможности работы с арифметическими выражениями. Таким образом, ожидания клиента были предвосхищены, а решение получило целевое развитие.
Согласованный Share RoadMap позволяет оптимизировать процессы развития продукта и сократить количество доработок.
ВЫВОДЫ:
1. Стоить выходить за пределы требований бизнес-заказчика, чтоб улучшить конечный продукт.
2. Простые и рутинные задачи лучше передать, это оптимизирует процессы и бюджет, принесет более интересное и крупные проекты.
3. Составленный совместно с клиентами Share RoadMap позволит сократить количество лишних итераций, сделает развитие продукта целевым.