Презентация на тему: » ЭВОЛЮЦИЯ БИЗНЕС-МОДЕЛЕЙ В ТЕЛЕКОММУНИКАЦИЯХ: откуда и куда мы движемся 10-й Российский Интернет-Форум 22 марта 2006 г. Алексей Рокотян Старший вице-президент.» — Транскрипт:
1 ЭВОЛЮЦИЯ БИЗНЕС-МОДЕЛЕЙ В ТЕЛЕКОММУНИКАЦИЯХ: откуда и куда мы движемся 10-й Российский Интернет-Форум 22 марта 2006 г. Алексей Рокотян Старший вице-президент ЗАО «Компания ТрансТелеКом»
2 2 Немного истории… Первый этап развития телекоммуникаций малая пропускная способность линий связи плохие параметры каналов жесткое (аппаратное) управление коммутационными устройствами дефицит услуг Как результат: специализированные сети для каждого вида передаваемой информации монопольные компании, строящие сети и оказывающие услуги (1)
3 3 Немного истории… Телефония… Телеграфия… Вещание… (2) Передача данных…
4 4 Особенности первого периода телекоммуникаций Несколько специализированных сетей, оптимизированных для передачи различных видов информации Логика услуги связи реализуется на базовом сетевом оборудовании (коммутаторах) Услуга связи сама по себе представляет ценность для клиента Цель отрасли — ликвидация дефицита услуг. Для этого прежде всего нужно концентрировать ресурсы и развивать инфраструктуру Оператор — как правило и владелец сети, и продавец услуг Правда, услуги больше «покупают», чем «продают»… Конкуренция (там, где она есть) — прежде всего конкуренция инфраструктур (качественнее, доступнее, дешевле…)
БИЗНЕС-МОДЕЛЬ CANVAS ( Модель Остервальдера )
5 5 Начало революции в телекоммуникациях Технологическая революция развитие волоконной оптики — много дешевых и качественных каналов микропроцессорная техника — колоссальный рост и удешевление вычислительных ресурсов коммутаторов развитие мобильной связи Рост широкополосности сетей. Появление новых возможностей, включая конвергенцию сетей / услуг На развитых рынках закончился период телефонизации — период экстенсивного развития Появляются примеры отделения услуг от сетевого обрудования концепция интеллектуальных сетей Интернет
6 6 Модель инфокоммуникационного сервиса Услуга связи Инфокомму- никационная услуга
7 7 От чего « поехала парадигма » Сетевые ресурсы стали качественны и дешевы отпала необходимость оптимизировать сеть под конкретный вид передаваемой информации — реальная мультсервисность избыточность позволяет оптимизировать сети под задачу обеспечения гибкости и удобства пользования — изменение сетевых архитектур Все большую ценность в глазах пользователя приобретает не услуга связи как таковая (как процесс передачи информации), а сервис, доступ к которому становится возможен через потребление услуги связи. Именно на этом построен Интернет
8 8 Участники цепочки создания ценности Традиционно Тенденция в современных условиях Магистральный оператор Региональный оператор Локальный оператор / оператор, работающий на целевом сегменте Клиент Магистральный оператор Региональный оператор Оператор сети доступа Сервис- провайдер Телеком Инфоком Телеком
9 9 Эволюция бизнес-моделей Локальный оператор Оператор вида сетей / услуг Национальный оператор Национальный оператор Локальный оператор Специализи- рованный оператор Магистральный оператор Локальный оператор Специализи- рованный оператор Контент- провайдер Инфраструктурный магистральный оператор Инфраструктурный оператор сети доступа Сервис- провайдер Оператор — интегратор Конец XIX — начало ХХ в.Большая часть ХХ в.1990-е годы Начало ХХI в.~ 2008…2010 гг. и далее
Бизнес-модели интернет-проектов
10 10 Цепочка создания ценности и основные бизнес-модели Сеть Транспорт VAS ( услуги связи ) Основное обслужи- вание и биллинг Основные услуги ( связь ) Доступ Устройства Контент и несвязн ы е услуги CRM (в широком смысле) Магистральный оператор Локальный оператор Системный интегратор Контент- провайдер Перспективная бизнес-модель инфра- структурного оператора Перспективная бизнес-модель сервисного оператора
11 11 Отличия бизнес-модели «классического» телекома и инфокоммуникационных услуг ТелекомИнфоком Основная потребность клиентов Передача информации Доступ к информации, услугам и службам Роль услуги связи Передача информации — непосредственно потребляемый продукт 1. Средство доступа к услугам и службам (растущая часть) 2. Непосредственно потребляемый продукт (сокращающаяся часть) «Место», где обеспечивается логика услуги В составе оборудования сети связи — принадлежность оператора связи «Над сетью» связи — может принадлежать как оператору связи, так и, скорее, другой компании Роль телекоммуника- ционного оператора 1. Создание инфраструктуры 2. Обеспечение услуг связи 3. Продажи и работа с клиентом Розничный рынок Обеспечение телекоммуникационной инфраструктуры для сервисов Оптовый рынок Роль сервис- провайдера Один из клиентов оператора связи, самостоятельно (как правило) продающий свои услуги Поставщик инфокоммуникационных сервисов, включая услуги связи Розничный рынок
12 12 Сопоставление бизнес-ролей Бизнес Показатель Магистральная инфраструктура Инфраструктура доступа Сервис для гос. органов и крупн.корп-ций Сервис на массовом рынке Ориентация компании Технологическая Маркетинговая Тип рынкаОптовый В перспективе — оптовый, исторически — розничный Розничный Инвестиции в сеть Очень существенные СущественныеСредниеНезначительные Физические объемы закупок по одному контракту ЗначительныеСредние Небольшие Прибыльность бизнеса (в целом) В мире — низкая В РФ — средняя Сейчас — высокая В перспективе — низкая / средняя СредняяВысокая / средняя Стандартизован- ность продукта Очень высокаяВысокаяНизкая Разнообразие продуктов МинимальноеНебольшоеСреднееОчень высокое Индивидуализа- ция продукта НизкаяСредняяВысокаяСредняя Рыночные рискиСредниеНизкиеВысокие Конкуренция В мире – очень острая, В России — ограниченная В мире – средняя В России — низкая Высокие/ очень острая Высокие Преобладающие стратегии Лидерство по издержкам Дифференциация Сегментирование Дифференциация Сегментирование
13 13 Конвергенция телекоммуникационных сетей: сегодня Телеком
14 14 Конвергенция телекоммуникационных сетей: завтра Телеком
15 15 Конвергенция телекоммуникационных сетей: послезавтра Телеком
16 16 Организация работы с клиентом: сегодня Оплата услуг связи Оплата информации Оплата услуг Оплата информации Клиент Оператор связи Сервис Оператор связи Схема, чаще всего действующая в Интернете и других сервисах Схема, реализованная пока только для мобильного контента Клиент
17 17 Кошмар договорных отношений Договорные отношения, вытекающие из сегодняшнего законодательства И это без учета мобильной связи и конвергентных сервисов! Интернет- провайдер Поставщик VPN Оператор дальней телефонии Оператор зоновой телефонии Оператор местной телефонии Клиент Договор Сервис
18 18 А клиенту удобно так… Интернет- провайдер Поставщик VPN Оператор дальней телефонии Оператор зоновой телефонии Оператор местной телефонии Клиент Договор Единый клиентский договор Сервис Сервис- провайдер Договор
19 19 Фундаментальные тенденции в телекоммуникациях Кардинальное изменение сетевых архитектур, отказ от жесткой иерархии сетей, характерной для «классических» телефонии и телеграфии Функциональное разделение уровней транспортной коммутируемой сети и уровня формирования услуг Обострение конкуренции в наиболее динамичных секторах рынка (мобильная связь, Интернет, услуги для корпоративных пользователей). Рост рыночной власти пользователей Объективная необходимость перепродажи услуг связи, обеспечивающая работу через «одно операционное окно» Услуга связи как таковая перестает быть существенной ценностью для пользователя. Телекоммуникации ( как минимум, на массовом рынке ) все больше приближаются к модели коммунальных услуг ( обязательный инфраструктурный сервис ) В жилищах и офисах появляется «розетка со связью» Телекоммуникации неизбежно начинают расслаиваться на 2 части: инфраструктурную сервисную Идея «Killer application» устарела
20 20 Выводы Переход «от телекома к инфокому» связан с радикальными изменениями во всем телекоммуникационном бизнесе, IT, смежных отраслях (paradigm shift) Приоритет в будущем сервиса ( в широком смысле ) над инфраструктурой практически очевиден Будущие бизнес-модели должны обеспечивать: эффективную продажу (и, соответственно, производство, доставку, … ) потребителям всевозможных сервисов и контента минимальную зависимость сервиса от инфраструктуры эффективное развитие этой инфраструктуры Изменения не могут быть только «автоматическими». Потребуется: спокойное осознание происходящих изменений кардинальное изменение нормативной базы умение искать решения, взаимоприемлемые для всех участников процесса: пользователей телекоммуникационных компаний контент-провайдеров регулятора В интересное время живем, коллеги!
21 21 Спасибо за внимание! Контактная информация: Алексей Рокотян Старший Вице-президент ЗАО «Компания ТрансТелеКом»
Источник: www.myshared.ru
Информационный обмен или как реализовать транспорт данных?
Вопросу хранения, обработки и передачи данных посвящено огромное множество статей. Данные – это три кита, на которых держится любой бизнес, и от того, насколько грамотно эти данные обращаются в системах, зависят рост и успех компании.
За все время существования информационных систем архитектурный ландшафт менялся, и в каждой парадигме был свой способ хранения данных. От особенностей хранения данных, в свою очередь, зависели технологии интеграции. В данной статье мы рассмотрим основные технологии обмена данными, пережившие эволюцию и доказавшие свою состоятельность в бизнесе.
Необходимость перекачивать данные из одного хранилища в другое в бизнесе возникает на каждом шагу.
Рассмотрим простой кейс:
- Клиент оставил заявку на сайте банка – включилась передача данных с веб-формы в базу данных на бэк;
- Он запросил большой кредит: надо передать его персональные данные в сервис скоринга и получить решение;
- Банк готов сотрудничать с этим клиентом – необходимо передать статус по заявке для отображения личном кабинете;
- Кредит выдан, теперь его надо включить в отчетность, значит, он попадет в регулярные обновления данных в DWH.
В этом тривиальном кейсе мы видим 4 факта передачи данных, и для каждого из них используется свой интеграционный механизм.
Этот пример можно усложнить авторизацией и аутентификацией, использованием кэша для загрузки ранее заполненной формы, обогащением профиля клиента в личном кабинете данными из разных источников, предложением клиенту индивидуальных маркетинговых кампаний, логированием его поведения на фронте и передачей данных в аналитическую систему, и т.д.
Каждую секунду данные перемещаются из одного контейнера в другой по различным транспортным каналам. Итак, с помощью каких технологий может быть организован транспорт данных?
Прежде всего, разделим интеграции на две категории:
- онлайн-интеграции;
- интеграции с задержкой во времени.
Разные бизнес-задачи допускают разную степень актуальности данных. Например, когда клиент совершает онлайн-платеж, его данные моментально передаются в банк-эквайер, оттуда в платежную систему, и затем а банк-эмитент на проведение платежа. Все происходит моментально, и уж через какие-то полминуты сделка купли-продажи совершена.
А вот когда тот же клиент совершает покупку на борту самолёта, моментального обмена данными быть не может, поскольку отсутствует подключение к сети. Все операции накапливаются в POS-терминале, а по приземлении самолёта происходит процессинг всех оффлайновых операций. В данном случае это интеграция с задержкой во времени. Как правило, передача данных с лагом во времени допускается при невозможности получить моментальный ответ от смежной системы, или при передаче больших объемов данных (например, в DWH и BI-системы).
Онлайн-интеграции
Самый распространенный способ моментального обмена данными – через API (Application Programming Interface).
API – это интерфейс, спроектированный поставщиком ресурса для получения запросов на сервер по заданному контракту. Иначе говоря, это то, что обеспечивает эффективный процесс коммуникаций между программами, использующими функции и ресурсы друг друга. Идея обмена данными с помощью API лежит в основе сервис-ориентированной и микросервисной архитектур.
В таких архитектурах существуют системы, которые готовы выполнять некоторый набор функций по запросу. Набор таких функций называется сервисом, а выполняющая логику сторона – поставщиком сервиса. Системы, запускающие сервисы других систем, называются потребителями сервиса и чаще всего отправляют запросы поставщику сервиса и принимают от них ответы через промежуточное звено – брокера. В роли брокера выступает промежуточное ПО.
Наиболее популярными на сегодняшний день являются – SOAP API и REST API. Оба вида сервисов широко используются в различных платформах и имеют свои преимущества и недостатки, поэтому при проектировании интеграции зачастую возникает вопрос, какую технологию использовать.
К преимуществам SOAP относится использование XML для кодирования запросов и ответов, а также строгую типизацию данных, гарантирующую их целостность при передаче между клиентом и сервером. В свою очередь, в модели REST отсутствуют встроенные требования к типизации данных, поэтому пакеты запросов и ответов в REST имеют намного меньшие размеры, чем SOAP. Благодаря скорости обмена данными именно REST API предоставляется такими соцсетями, как VK, Facebook, Twitter.
Обмен данными с задержкой
В ряде случаев данные могут попадать в систему-потребитель актуальными на момент времени в прошлом. Например, система-потребитель может разом забрать данные, накопленные в системе-источнике за определенный период. Схема обмена данными выглядит так: «оставьте мне данные в таком-то месте, я заберу их, когда мне будет удобно». Такая схема обмена удобна, когда изменения в системе-источнике происходят слишком часто и в больших количествах, и моментальный обмен невозможен из-за большой нагрузки на базы данных и транспортное ПО. Поэтому система-источник накапливает изменения данных и затем передает эту дельту всем заинтересованным сторонам.
Существует несколько подходов к такому обмену данными.
Пожалуй, самый простой и быстрый способ – это выгрузка данных в нужном срезе напрямую из базы и запись их в .csv-файл. Далее этот файл может быть отправлен на эндпойнт или просто почтовый ящик потребителя, или может быть сохранен в определенной директории в сети, к которой у потребителя есть доступ.
К сожалению, данный способ вызывает частые ошибки, например, когда меняется набор полей .csv файла или в нем просто меняется разделитель. Более продвинутый способ – настройка на стороне поставщика данных специальных витрин, где данные хранятся в нужных срезах, и доступом к ним управляет поставщик. В сравнении с файловым обменом это исключает некоторые риски, такие как вероятность сбоя кодировки, сбой на стороне сервиса email-рассылки, попадания данных третьим лицам. Для того, чтобы избежать предоставления прямого доступа к витринам, удобным решением является предоставление сервисов, которые по запросу отдают потребителю массив данных.
Концептуально это отличается от онлайн-интеграции тем, что изменение данных в источнике система-потребитель может получить через какое-то время после их изменения, по собственному запросу.
Еще один из способов «оставить» где-то данные для потребителя – сложить их в очередь (наиболее популярны на рынке сейчас kafka и rabbitmq). На самом деле, очереди могут быть использованы как для моментальной передачи (можно передавать сообщения в очереди с высокой пропускной способностью, где они быстро будут вычитаны подписчиком), так и для передачи больших пакетов данных, которые подписчик вычитывает не в моменте, а по определенному таймингу.
Что же выбрать?
В выборе самого оптимального механизма интеграции нет волшебной пилюли. Посоветовать однозначно ту или иную технологию невозможно, потому что выбор зависит от множества разных факторов, которые делают каждый кейс уникальным. Все зависит от уже используемого стека технологий, от требований и ограничений интегрируемых систем, возможностей программного обеспечения, требований бизнеса к актуальности данных и скорости обмена, от политик безопасности в компании.
Именно поэтому многие компании опираются на опыт своих предшественников и best practices при выборе интеграции. Мы же надеемся, что данная статья помогла вам вкратце познакомиться с основными механизмами интеграции, которые стоит рассмотреть в первую очередь при выборе инструмента обмена данными.
Валерия Новицкая
Магистр бизнес-информатики Высшей школы экономики (направление моделирования и оптимизации бизнес-процессов). Ведущий системный аналитик, эксперт по системным интеграциям.
- Что такое системный рефакторинг? — 23.12.2020
- Информационный обмен или как реализовать транспорт данных? — 27.02.2020
- Кто такой системный аналитик? — 18.12.2019
Источник: thisisdata.ru
Бизнес-модель платежного шлюза — полное руководство по 2022 году 5 мин для чтения
Добавить в избранное
Главное меню » Бизнес-модель платежного шлюза — полное руководство по 2022 году
17 августа 2022
Н и для кого не секрет, что бизнес электронной коммерции в наши дни растет безумно быстро. Согласно расчетной величине глобальных розничных продаж начиная с 2021 года, ожидается, что к 2025 году объем розничных продаж электронной коммерции в глобальном масштабе достигнет 8,5 трлн долларов США. Такой огромный рост рынка подразумевает спрос на программную инфраструктуру, которая позволит принимать платежи на их веб-сайтах.
Платежный шлюз для high risk проектов или агрегатор платежей — это часть жизненно важной инфраструктуры в процессе платежей, которая обеспечивает передачу конфиденциальных данных от клиента и банка-эквайера. Шлюз подключен к API внутри электронной коммерции или компании, принимающей платежи. Агрегатор взимает учетную ставку продавца (MDR) за каждую транзакцию, которая проходит через него. В этой статье мы представляем полное руководство по инфраструктуре платежного шлюза и его бизнес-модели.
Платежный шлюз: основы
Агрегатор платежей — это инфраструктурная компания, предоставляющая программное обеспечение по модели распространения SaaS (программное обеспечение как услуга). Проще говоря, агрегатор — это мост между клиентом и продавцом. Его роль заключается в передаче данных между основными участниками, участвующими в обработке транзакций: клиентом, продавцом, банком-эквайером, банком-эмитентом и сетью карт.
Еще одним важным моментом является то, что передача такой конфиденциальной информации должна быть безупречной и безопасной. Обеспечение высокой скорости и безопасности передачи данных является одной из основных задач платежного агрегатора. После проверки информации о карте на предмет безопасности шлюз разрешает платеж.
Принцип работы платежного агрегатора заключается в следующем: человек размещает заказ и вводит свои платежные данные либо непосредственно на веб-сайте продавца, если он сертифицирован по стандарту PCI DSS, либо на странице платежного агрегатора. Затем агрегатор получает их, шифрует конфиденциальные данные и передает их банку-эквайеру. После этого информация поступает эмитенту карты, за которым следует банк-эмитент, который одобряет или отклоняет транзакцию, а затем сообщение с одобрением или отклонением возвращается на сайт.
Как платежные шлюзы зарабатывают деньги
Проще говоря, платежный шлюз получает доход от каждой транзакции, взимая процент и/или фиксированную комиссию, которая называется учетной ставкой продавца (MDR). Однако это гораздо сложнее. Чтобы выяснить, что именно представляет собой MDR, вам необходимо понять бизнес-модель карточных сетей, поскольку она является основным игроком в онлайн-платежах.
Читать Краткая история успеха операционной системы Windows
Обычно, когда мы говорим о сетях кредитных карт или эмитентах карт, мы имеем в виду Visa или Mastercard. Вы когда-нибудь задумывались, как они зарабатывают на своих транзакциях? Большинство кредитных и дебетовых карт по всему миру выпущены банками-участниками сети Visa или Mastercard. Чтобы воспользоваться преимуществами, скажем, Visa, банк должен оплатить плату за участие в сети, которая является фиксированной и выплачивается только один раз. Банк также выплачивает карточной сети комиссию за каждую совершенную транзакцию.
Платежные агрегаторы зарабатывают деньги аналогичным образом. Давайте посмотрим на пример. Чтобы принимать платежи онлайн, продавцу электронной коммерции нужны поставщики платежей. Услугами, которые позволяют это, являются банк-эквайер и банк-эмитент, сеть карт, платежный процессор и платежный шлюз.
Все они имеют фиксированную комиссию, выплачиваемую за транзакцию в размере 1 доллара США. Общая сумма этих сборов называется MDR.
Расчет ставки дисконтирования транзакции
В среднем с продавца взимается 1-3% от MDR за обработку каждой транзакции. MDR — это общая сумма сборов, которую продавец платит за обработку транзакций. Предполагая, что общая сумма MDR, которую должен заплатить продавец, составляет 1,0%, как мы ее разделяем? Это выглядит так:
- Комиссия в размере 0,35% для карточной сети;
- Комиссия банку-эквайеру составляет 0,35%.
- 0,20% комиссия поставщику услуг платежного шлюза;
- Комиссия в размере 0,10% для платформы организации платежей;
Например, клиент совершает покупку в интернет-магазине на сумму 1000 долларов США с помощью кредитной карты Visa. С этой суммы продавец заплатит 3,50 доллара США карточной сети, 2 доллара США платежному шлюзу, 1 доллар США платформе организации платежей и 3,50 доллара банку-эквайеру. Таким образом, продавец получит 990 долларов из 1000 долларов, уплаченных клиентом.
Бизнес-модель платежного шлюза
Платежные шлюзы получают большую часть своего дохода от MDR, но размер комиссии варьируется в зависимости от способа транзакции. На этапе оплаты клиент выбирает предпочтительный способ оплаты покупки. В зависимости от того, выбирает ли клиент кредитную или дебетовую карту, электронный кошелек, интернет-банкинг или кошелек с предоплатой, плата за MDR будет отличаться.
Существует также разница между бизнес-моделями, которые выбирает агрегатор. Для предприятий, которые совершают большие объемы транзакций, платежный шлюз может взимать фиксированную комиссию в месяц в дополнение к MDR (хотя MDR в этом случае будет ниже). Если у платежного агрегатора бизнес-модель без фиксированной комиссии, сумма сбора MDR выше.
Читать 7 Основных инструментов для Frontend веб-разработки сайтов в 2023 году
Кроме того, за международные транзакции с использованием нескольких валют взимается дополнительная плата. Если продавец принимает платеж от клиента в той же валюте, которую он получает, дополнительная плата не взимается. Но в случае, если валюта, в которой клиент платит, отличается от той, которую получает продавец, будет взиматься дополнительная комиссия за конвертацию. Как правило, дополнительная плата составляет около 1%.
Кроме того, плата определяется страной, в которой находится банк-эквайер, и страной клиента. Если клиент и банк находятся в одной стране, комиссия ниже. Если их страны разные, но они расположены в одном регионе (например, в Европе), плата будет выше. И, если клиент и покупатель находятся на разных континентах, плата будет намного выше.
Плата за настройку является еще одним источником дохода для платежного шлюза. Это плата, которую продавец платит только один раз за создание торгового счета. Все расходы, связанные с настройкой торгового счета, включены в комиссию. Однако не все платежные шлюзы взимают с продавцов плату за настройку, некоторые агрегаторы отказываются от нее.
Еще одна услуга, за которую платит продавец, — это обслуживание и поддержка шлюза. Агрегатор взимает ежегодную плату для покрытия операционных расходов и затрат, необходимых для поддержки программного обеспечения, безопасности и технологии платежей, хотя взимать плату за обслуживание должны поставщики платежных шлюзов.
Наконец, может взиматься дополнительная плата за InstaPay или оплату в один клик. Выбирая его в качестве предпочтительного способа оплаты, клиент получает ссылку для оплаты по электронной почте или номеру телефона в режиме реального времени. Перейдя по ссылке или отсканировав QR-код, клиент оплачивает покупку, не вводя свои платежные данные.
Заключение
В настоящее время продавец не может принимать платежи на веб-сайте без платежных шлюзов. Бизнес-модель платежного шлюза основана на процентах и/или фиксированной комиссии, которую продавец выплачивает с каждой транзакции. Размер комиссии зависит от режима транзакции. Таким образом, предприятия, которые имеют постоянный поток транзакций, получают постоянную прибыль для платежного шлюза. Кроме того, поставщики платежных шлюзов получают прибыль от сборов за настройку и обслуживание, а также дополнительных сборов за международные транзакции и транзакции InstaPay/One-click.
Если вы нашли ошибку, пожалуйста, выделите фрагмент текста и нажмите Ctrl+Enter.
Источник: andreyex.ru
