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