Комментарии

В нашей компании большой онлайн-магазина, с высокими нагрузками, мы долго искал подходящую CMS и остановились на DST Store. Первое, что привлекло – это открытый код, который позволил настроить все под мои специфические требования. Система написана на PHP с MySQL, что обеспечивает хорошую производительность и масштабируемость.

За полтора года работы у нас не было проблем или сбоев в работе. Панель управления действительно содержит только необходимые функции, без лишнего мусора, что очень удобно. Отдельно хочу отметить интеграцию с платежными системами и системой доставки – все работает как часы, без лишних заморочек и сложностей.

В нашей компании большой онлайн-магазина, с высокими нагрузками, мы долго искал подходящую CMS и остановились на DST Store. Первое, что привлекло – это открытый код, который позволил настроить все под мои специфические требования. Система написана на PHP с MySQL, что обеспечивает хорошую производительность и масштабируемость.

За полтора года работы у нас не было проблем или сбоев в работе. Панель управления действительно содержит только необходимые функции, без лишнего мусора, что очень удобно. Отдельно хочу отметить интеграцию с платежными системами и системой доставки – все работает как часы, без лишних заморочек и сложностей.

Не согласен, мы запустили оптовый ИМ на DST Store, функционала намного больше чем в Битриксе и в Могуте и работает быстрее, можете сравнить открыв демо. Сейчас не мало CMS систем которые намного более функциональны чем старые Битрикс или OpenCart, правда DST Store значительно дороже, ну в принципе как и все профессиональные решения

Не согласен, мы запустили оптовый ИМ на DST Store, функционала намного больше чем в Битриксе и в Могуте и работает быстрее, можете сравнить открыв демо. Сейчас не мало CMS систем которые намного более функциональны чем старые Битрикс или OpenCart, правда DST Store значительно дороже, ну в принципе как и все профессиональные решения

Для интернет-магазина сейчас фактически 2 специализированных платформы со всеми необходимыми интеграциями по оплатам, логистике, маркетингу и т.д.: это 1C-Битрикс и MogutaCMS. Остальные или вообще пустые в плане функционала, или тормозят/работают с ошибками.

Для интернет-магазина сейчас фактически 2 специализированных платформы со всеми необходимыми интеграциями по оплатам, логистике, маркетингу и т.д.: это 1C-Битрикс и MogutaCMS. Остальные или вообще пустые в плане функционала, или тормозят/работают с ошибками.

Читаешь и кажется все просто) А на самом деле много гемора. Да и пока магазин выйдет в ноль или начнет приносить прибыль нужно как то барахтаться на поверхности. Что интернет магазин, что фактический, на все требуется время. У меня магазин находится в проходном месте и то сначала было так себе. Это сейчас уже раскрученный, даже эквайринг подключил в компании Некст пос, так как доход вырос, а до этого так себе перебивался.

Читаешь и кажется все просто) А на самом деле много гемора. Да и пока магазин выйдет в ноль или начнет приносить прибыль нужно как то барахтаться на поверхности. Что интернет магазин, что фактический, на все требуется время. У меня магазин находится в проходном месте и то сначала было так себе. Это сейчас уже раскрученный, даже эквайринг подключил в компании Некст пос, так как доход вырос, а до этого так себе перебивался.

Давно занимаюсь b2b ecommerce сектором, и к сожалению пока что на рынке не существует ни одного грамотного решения «из коробки», кроме DST Store, так что выбор остановил на нем.

Советы грамотные, если собираетесь разрабатывать свой b2b портал, обязательно надо иметь ввиду.

Мы выстраиваем подобный подход у наших клиентов. Рекламации, дебиторку, просроченные задолженности также автоматизируем в b2b-системе.

У меня грузовые СТО. В марте месяце закупил запчастей на 7.5млн рублей(входящая), из них 6,8млн приходится на те самые b2b онлайн магазины.

С поставщиками у которых нет возможности онлайн заказа — попросту не работаю, за редким исключением.

Взаимодействие с поставщиком сведено до минимума.
Заходишь на сайт, забиваешь номера деталей, проставляешь количество, набираешь корзину.
Нажал отправить и все, никаких созвонов, список и тд.
Через день(два, три, в зависимости от локации склада поставщика. Основной поставщик делает две доставки в день) приезжает курьер с грузом и документами. Склад принял, подписал и все.
В живую (телефон мессенджер почта) общаемся только по возвратам или каким то другим подобным вещам типа просрочки и тд.

Расскажу наш опыт которые чаще всего допускают при запуске инструментов оптовой торговли в онлайне, исходя из собственных ошибок нашей компании.

Ошибка №1. Считать, что компания ещё слишком мала для оптового интернет-магазина

Существует ошибочное мнение, что оптовый интернет-магазин стоит запускать после того, как оборот компании превысит 100 млн рублей в год.

Допустим, что сегодня вам достаточно офлайн-продаж. Но согласитесь, глупо отказываться от возможностей, которые предоставляет онлайн. Ведь на деле оптовый интернет-магазин — инструмент для автоматизации оптовых продаж, и он решает множество бизнес-задач: упрощает документооборот по сделкам, увеличивает эффективность отдела продаж, повышает лояльность клиентов за счёт удобства работы и создаёт с ними оперативную связь.

Мы опросили наших клиентов — торговые и производственные компании b2b-сегмента — и выяснили, как обычно распределяют своё рабочее время менеджеры по продажам в их компаниях. Вот что мы узнали.

40% времени они тратят на согласование условий поставок с покупателями по телефону и электронной почте, 20% времени уходит на подтверждение наличия товара на складах, 15% — на обмен документами с контрагентами, ещё 15% — на оформление бухгалтерских документов и 10% времени остается на другие задачи.

При этом руководители компаний хотели бы, чтобы их менеджеры по продажам 40% рабочего времени тратили только на поиск новых клиентов и столько же на улучшение отношений с ними. По их мнению, сейлзы должны проводить не более 10% времени в работе с бухгалтерской документацией, а освободившееся время проводить в изучении ассортимента, рынков, конкурентов и новых методик продаж.

Ещё один опрос мы провели среди тех компаний, которые пользовались собственным b2b-интернет-магазином не менее трёх месяцев. Оказалось, что после запуска торговой площадки количество ошибок в документах уменьшилось на 80%, на 25% выросло количество заказов в нерабочее время, на 80% сократилось время обработки заявок и выставления счета, и на 10% выросла средняя стоимость одного заказа. В результате запуска интернет-магазина операционные затраты компаний сократились на 70%, а количество новых клиентов увеличилось на 20%.

Ошибка №2. Думать, что b2b-интернет-магазин — то же самое, что и розничный интернет-магазин

Конечно, это не так. Основное отличие здесь в уникальности бизнес-процессов оптовой компании. Делая свой проект по лекалам розничных интернет-магазинов, вы рискуете получить неработающий инструмент.

Здесь мы приводим лишь несколько пунктов, по которым оптовый интернет-магазин отличается от розничного:

— ценообразование производится по сложным алгоритмам;
— необходимость в информации о наличии товара по всем складам и филиалам;

— формирование полного пакета документов по сделке (счёта-фактуры, ТТН);
— управление менеджерами в личном кабинете (зачастую один клиент работает от нескольких юрлиц, для которых могут существовать разные условия);
— необходимость настройки единиц измерения, удобной для оптовиков;
— загрузка прайс-листа с проставленным количеством товара;
— быстрое добавление товара через ввод артикулов;

— возможность видеть платежный баланс по договорам в личном кабинете.

Ошибка №3. Выбирать CMS до описания функциональности

Выбор CMS — один из ключевых этапов в разработке оптового интернет-магазина. И вернуться к нему, сделав неправильный выбор, будет весьма затратно. Поэтому для начала нужно выяснить требования к функциональности интернет-магазина, чтобы предотвратить ошибки. Совет здесь такой: подбирайте CMS или CMF под ваши требования и необходимую функциональность, но никак не наоборот.

Многие клиенты спрашивают нас, ведём ли мы разработку оптовых порталов на «DST Platform». Да, ведём. Но будет ли он оптимальным выбором для ваших процессов? Далеко не всегда.

Коробочное решение (шаблонная комплектация интернет-магазина) дешевле в два-три раза и внедряется в разы быстрее, если сравнивать с индивидуальной разработкой. Минус в том, что ваши бизнес-процессы придётся подстраивать под «коробку» хотя и решения на DST Platform надо сказать очень гибкие и сама платформа ну прям очень функиональна. Поэтому мы рекомендуем выбирать коробочное решение, только если его функциональность совпадает с нужной вам на 70%, а оставшиеся 30% подрядчик готов доделать за приемлемую для вас цену. Если «коробка» вас устраивает, незачем переплачивать за индивидуальное решение.

Также будет полезно знать, что «облачные» решения имеют существенные ограничения, поскольку находятся на хостинге разработчика. Поэтому код разработки будет полностью для вас закрыт. И если возникнет необходимость переноса проекта на другой хостинг или вам понадобится доступ к исходному коду, разработчики либо откажут, либо захотят получить за это деньги, иногда сравнимые со стоимостью разработки индивидуального решения.

Ошибка №4. Желание запуститься с максимальной функциональностью с первого раза

Многие заказчики мечтают выйти на рынок с крутым продуктом, который сразу «убьет» всех конкурентов. В большинстве случаев это утопия. Надо понимать, что чем сложнее функциональность интернет-магазина, тем дольше разработка и больше вероятность возникновения багов. Ожидая отладки своего «космического корабля», вы рискуете потерять время. Лучше действовать по принципу MVP (минимально жизнеспособного продукта): начать с необходимых для запуска базовых бизнес-процессов функций и выпустить первую версию. И уже после поэтапно дорабатывать и внедрять дополнительные инструменты.

Разделите функциональность на основную и второстепенную. Например, в первой итерации позвольте своим дилерам видеть номенклатуру, наличие и совершать заказ по своим ценам. А остальное: сложные конструкторы, обработчики заказов, цепочки оповещений и прочее, — докручивайте к уже работающему проекту.

При разработке проекта компании «Фомлайн» по оптовой продаже пенополиуретана с нескольких заводских площадок мы с заказчиками разделили проект на уровни. Для пилотной версии мы сделали функции авторизации, подключения трех из десяти заводов, интеграцию номенклатуры, контрагентов и заказов.

Так за три месяца мы запустили рабочий проект, в котором контрагенты смогли делать свои заказы. Пока шла разработка MVP-версии, параллельно дописывалось общее техзадание, в которое были включены все последующие итерации разработки. Так в сжатые сроки мы получили работающую платформу и объемное техзадание, на базе которого продолжили дальнейшее развитие проекта.

Ошибка №5. Ставить задачу разработчику в духе «сделайте как у конкурента»

Довольно часто заказчики высказывают подобные пожелания. Безусловно, анализ конкурентов — неотъемлемая часть предпроектного исследования, в ходе которого можно обнаружить полезные решения и для своего проекта. Но нельзя ориентироваться только на удачный стиль сайта конкурентов. За видимой частью интерфейсов находятся длинные алгоритмы бизнес-процессов.

В одном из наших проектов мы столкнулись со следующей ситуацией: главной задачей для заказчика было привлечение на интернет-площадку прорабов, которые привыкли делать заказы с мобильных устройств, находясь непосредственно на строительных объектах. Прямой конкурент же ориентировался на работающих за десктопами менеджеров по закупкам. Разумеется в таком случае простое копирование интерфейсов, как того хотел заказчик, не дало бы нужных результатов.

Ошибка №6. Использование неупорядоченных баз данных учетно-складских систем

Интеграция данных учетно-складских систем обеспечивает актуальной информацией по ценам и наличию товара. Если данные некорректны, ваш сайт будет обманывать покупателей. Минимально необходимая информация для интернет-магазина, без которой невозможна автоматизация — артикулы, наличие товара и цены. Чем больше и сложнее компания, тем больше данных появляется в базе. Поэтому поддержание их полноты и актуальности — один из важных моментов в работе оптового интернет-магазина.

Когда мы начали работу с торгово-производственной компанией спортивного оборудования, то обнаружили, что характеристики товаров в базе 1С свалены в одну кучу. Выделив каждую из них в отдельное поле, мы смогли автоматически группировать товар удобным для покупателя образом, что за неделю дало рост продаж на 6%.

Был случай, когда мы не стали брать проект компании по производству искусственных ёлок в работу, поскольку весь складской учет велся в разнородных офисных программах, а 1С использовалась только для бухгалтерской отчетности.

Ошибка №7. Данные по филиалам не централизованы

Открывая филиалы и представительства в регионах, важно наладить централизацию данных по договорам, заказам и остаткам. Для этого существует много разных подходов, но идея одна — важные для торговли данные должны агрегироваться в центральной базе на центральном сервере. Если централизация отсутствует, налаживать связь сайта с каждым из филиалов будет слишком трудозатратно.

Ошибка №8. Разрабатывать b2b-интернет-магазин внутренними силами компании

Желание сэкономить понятно. Но если вы считаете, что раз в компании работает дизайнер, программист и системный администратор, то они легко разработают b2b-площадку без привлечения подрядчика — вы ошибаетесь. Специалисты, работающие в компании, часто не видят систему глазами клиента: они уже давно «варятся» в своем котле и не замечают недостатки. Если в компании хаос — они будут автоматизировать хаос. Кроме того, содержать профессиональную команду банально дорого.

В команду разработчика должны входить как минимум бизнес-аналитик, дизайнер, верстальщик и веб-программист. Координацией и распределением задач между ними должен заниматься опытный руководитель проекта. Подумайте, сможете ли вы собрать схожий набор компетенций внутри своей компании.

Ошибка №9. Несерьезное отношение к предпроектному этапу

Обычно предпроектное исследование подразумевает знакомство и интервью со всеми участниками проекта и выяснение нюансов о выстроенной работе в компании. Также оно предполагает тщательный анализ конкурентов.

Итогом этого этапа, как правило, являются четыре документа. Они позволяют начать проектирование с четким пониманием, что, как и для чего планируется делать.

Документ №1. «Инициация проекта». В нем определяются зоны ответственности и состав команды проекта.

Документ №2. «Требования рынка и бизнеса». В этом документе описываются цели проекта, его KPI, описывается, зачем бизнесу и рынку нужна эта система и прогнозируются перспективы развития проекта.

Документ №3. «Функциональные требования проекта». На этих требованиях и будет строиться техзадание для проекта.

Зачастую требования к функциональности оптового интернет-магазина прописывает директор компании с позиции «мне с бугра виднее». Это ошибка. Руководитель, как правило, понимает бизнес-процессы компании верхнеуровнево. Поэтому будьте готовы предоставить разработчикам контактные данные людей, которым предстоит работать с оптовым интернет-магазином, и выделите время на их опрос. Нелишним будет собрать пожелания контрагентов — потенциальных пользователей системы.

Документ №4. «Техзадание». Полностью регламентирует работу над проектом.

В разработке ТЗ должны принимать участие обе стороны — только так можно создать эффективный документ.

Основные разделы технического задания на разработку оптового интернет-магазина:

— описание сайта (основные цели сайта, ожидаемая аудитория, задачи и возможности сайта);
— требования к интернет-магазину и программному обеспечению;
— требования к визуальной составляющей;
— структура интернет-магазина;
— прототипы страниц сайта и описание интерфейса;
— описание функциональности интернет-магазина (общие функциональности подсистем и модулей, перечисление функций модулей с описанием логики их работы);
— интеграции (описание логики интеграции и описание форматов выгружаемых и загружаемых файлов);
— план синхронизаций при обмене данными;
— описание типов пользователей и делегируемых им прав;
— перечень требований к разработке сайта.

Ошибка №10. Не продумать цели и KPI для оценки работы проекта

Разработка оптового интернет-магазина подразумевает серьезные инвестиции в проект. А любой инвестпроект подразумевает оценку перспективы его окупаемости. Для этого сначала необходимо определить цели внедрения портала, и уже под эти цели рассчитывать KPI.

Целями запуска оптового интернет-магазина могут быть:

— Оптимизация взаимодействия с торговыми партнерами.
— Увеличение продаж за счет предоставления клиентам удобного и функционального сервиса оформления заказов на товар.

Задачи оптового интернет-магазина обычно следующие:

— Предоставление клиентам полной информации о товаре.
— Оперативное информирование клиентов о новинках, скидках и маркетинговых акциях.
— Повышение эффективности взаимодействия между менеджерами компании и сетями клиентов.
— Обеспечение возможности формирования онлайн-заказов для сетей клиентов и торговых представителей компании.

Примеры KPI по проектам наших клиентов:

— процент клиентов, которые будут пользоваться системой;
— количество менеджеров, обрабатывающих заказы;
— объем продаж;
— количество новых клиентов;
— сокращение расходов на персонал;
— время выполнения заказа;
— удовлетворенность покупателей качеством и комплектностью заказов;
— средняя стоимость одного заказа.

Ошибка №11. Уделять слишком много внимания дизайну

Не стоит в разработке оптового интернет-магазина делать упор на дизайн и длительное обсуждение разных визуальных «примочек». Все-таки здесь приоритетом является функциональность b2b-площадки, которая помогает решать задачи бизнеса.

Мы делаем оптовые проекты на базе фреймворков — готовых наборов функциональных элементов с выпадающими списками, чекбоксами, таблицами, вкладками. За счет этого клиенты экономят на дизайне и верстке до 200-300 тысяч рублей, и срок разработки сокращается до нескольких месяцев.

Ошибка №12. Непрозрачная ценовая политика

Идеальная ситуация — когда к моменту разработки оптового интернет-магазина в компании установлена прозрачная ценовая политика. Но так бывает не всегда. В некоторых случаях цены вбиваются вручную «на глаз». Таким компаниям необходимо будет выбрать подходящую модель ценообразования.

Это может быть примитивная колоночная система РРЦ ОПТ1 ОПТ2 с некоторым шагом в процентах. Или модель, в которой используются уровни клиентов. Розница, ОПТ1 ОПТ2 VIP1. Уровни в данном случае работают более гибко, ведь их может быть сколько угодно, а сделать и поддерживать 10–20 ценовых колонок довольно проблематично.

В компаниях со сложным ценообразованием лучше всего применять матрицы, где на конечную цену влияет ряд факторов, например, договор, юридическое лицо, регион, склад, марка, отсрочка платежа. В таких случаях описываются все факторы и составляется таблица, из которой рассчитывается конечная цена.

Ошибка №13. Несформированная рабочая группа со стороны заказчика

Лучше собрать команду до старта разработки, чтобы в процессе реализации проекта не возникало проблем. Для этого нужно знать, какие задачи решает команда заказчика в процессе разработки оптового интернет-магазина. В основном она:

— предоставляет информацию об особенностях ассортимента;
— дает описание существующих бизнес-процессов и схем работы;
— дает понимание ценовой политики и условий работы с контрагентами;
— формирует собственные и клиентские ожидания от работы b2b-платформы;
— делает выгрузки из учетной системы и их доработку при необходимости.

Команда проекта со стороны заказчика обычно состоит из следующих сотрудников:

— руководитель проекта;
— 1С-специалист;
— технический директор;
— руководитель отдела продаж;
— маркетолог.

Отдельным пунктом можно выделить требования к руководителю проекта:

— ​Он должен понимать бизнес-процессы компании.
— Обладать компетенциями в ИТ-сфере и иметь базовое понимание принципов работы учётных систем и проектов электронной коммерции.
— Зона влияния и зона ответственности руководителя проекта должны совпадать, поскольку ему придется постоянно взаимодействовать с другими отделами и запрашивать внутреннюю информацию.

По опыту можем сказать, что не всегда стоит выбирать в качестве руководителя проекта узкоспециализированного ИТ-специалиста (например, системного администратора). Как правило, такие люди излишнее значение придают техническим вопросам, в которых уверенно разбираются. Остальное, в том числе ключевые бизнес-процессы компании, отодвигается на второй план. В итоге мы получаем жаркие дискуссии на тему выбора хостинга или формата обмена данными, а бизнес-задачи так и остаются нерешенными.

Самый лучший вариант в нашей практике — это когда бывший сотрудник-технарь переходит на руководящую должность. Технический склад мышления дополняется пониманием бизнес-процессов.

Ошибка №14. Разводить бюрократию

Бывают компании, в которых даже самый незначительный вопрос выносится на планерку. Казалось бы, нетрудно собрать всех задействованных лиц на 10-15 минут. Но в итоге теряются даже не дни, а целые месяцы.

Работая с одной крупной компанией, занимающейся тепловым оборудованием, мы писали техзадание на типовую функциональность более полугода, при том что обычно это занимает месяц. А всё потому, что вопросы, которые мы задавали заказчику, решались в компании коллегиально.

Ошибка №15. Перевод всех клиентов на новую онлайн-площадку в день запуска

Желание запустить оптовый интернет-магазин сразу на всю мощь понятно, но не всегда верно. Было бы разумнее сначала проверить новую площадку на пилотных клиентах, а потом планомерно подключать остальных. О тестовом запуске лучше договариваться с лояльными клиентами — от них гораздо проще получить обратную связь. Затем можно внедрять программу мотивации для других клиентов, которая даст им стимул к переходу в онлайн.

Большая часть наших клиентов так и поступала. Например, ГК «Деан», «Фабрика Дриада», ГК «Фомлайн» — все они на первом этапе привлекли три-пять пилотных компаний-партнеров, менеджеры которых полностью перешли на работу в онлайне. В результате недоработки, на которые указали пилотные клиенты, были устранены, и началось постепенное подключение остальных контрагентов.

Ошибка №16. Не собирать обратную связь от пользователей

Очевидно, что главную оценку оптовому интернет-магазину должны давать его пользователи. Назначьте ответственного за сбор отзывов и развитие проекта в целом. Пусть он получает информацию о том, удобно ли работать в интернет-магазине пользователям, хватает ли функций или наоборот, есть ненужные элементы. Лучше получить негативные отзывы, чем уходящих с площадки клиентов. После запуска, особенно в первые недели, важно уделять повышенное внимание опросам пользователей.

При выборе инструмента управления API учитывайте масштабируемость, функции безопасности, простоту использования, возможности интеграции и цену.

Спасибо за ответ! Какие факторы следует учитывать при выборе инструмента управления API?

Apigee и IBM API Connect идеально подходят для крупных предприятий благодаря своим надежным функциям и масштабируемости.

Какой инструмент управления API лучше всего подходит крупным предприятиям?

Как разработчик, могу сказать, что управление версиями API через такие системы — это просто революция в разработке! Больше не нужно вручную обновлять каждую конечную точку при изменениях, интеграция с популярными платформами разработки значительно упрощает рабочий процесс. А аналитика использования помогает быстро находить узкие места в производительности. Очень полезное решение для современных IT-команд.

Очень впечатлён возможностями современных систем управления API! Особенно радует комплексный подход к безопасности — от базовой аутентификации до продвинутого шифрования. А функция монетизации API открывает новые бизнес-перспективы для компаний. Это действительно мощный инструмент, который позволяет не только защитить свои сервисы, но и превратить их в источник дохода.

Мой список API Management платформ:

Gravitee

Описание системы производит хорошее впечатление, не хватило разве что примеров передовых идей в области интеграции или API. Наличие opensource-версии платформы – это плюс, но нужно учитывать, что она немного порезанная. В принципе, в России есть компании, которые обеспечивают поддержку Gravitee и способны дописать, что нужно, поэтому санкционная стойкость — 50%.

По стоимости: за ПО предусмотрена ежегодная плата, не слишком большая, техподдержка – примерно 20% от стоимости ПО. По обоим параметрам система почти в топе.

По нефункциональным требованиям оценка была снижена по показателю «Поддержка», компания не готова была выезжать на территорию заказчика, нас упорно убеждали, что все проблемы можно будет решить удаленно.

По функциональным требованиям оценка снижена за отсутствие поддержки спецификации WADL, отсутствие кеширования для управления states. В API-портале не хватило функционала группировки разных версий API в один объект с выпадающим списком версий. Ну и в модуле безопасности не досчитались поддержки ГОСТ TLS (что для иностранного ПО не удивительно).
WSO2 API Manager

По репутационным критериям у решения практически 100%. Все хорошо расписано. Имеется opensource-версия с базовым функционалом.

По стоимости платформа оказалась в 4 раза дешевле самой дорогой, причем техподдержка входила в эту цену. Но это строго без необходимости доработок.

По нефункциональным требованиям оценка снижена за неумение работать в автономном режиме и падение производительности платформы при росте числа параллельных вызовов.

По функциональным требованиям минусы за: отсутствие поддержки WADL, кеширования для управления states, отсутствие поддержки балансировки API-запросов, отсутствие предоставления разных TLS сертификатов для разных host name. Отсутствует возможность интеграции с системами класса Service Discovery, в частности с Eureka. В API портале не хватило возможности версионирования артефактов и создания шаблонов описания API. Да и в целом не хватает автогенерации документации.
Tyk

Платформа описана на сайте подробно, есть примеры внедрений и чувствуется, что она развивается. Tyk – opensource-решение, и это несомненный плюс.

По стоимости, если брать коммерческую версию с техподдержкой, ПО окажется совсем не бесплатным, примерно в половину цены самого дорогого решения.

По нефункциональным требованиям все на 100%, а вот по функциональным нашлись минусы. Это отсутствие поддержки спецификации AsyncAPI для возможности публикации асинхронных API и спецификации WADL. Отсутствует возможность отправки событий по SNMP, например Qradar. В модуле безопасности не поддерживаются авторизационные механизмы Kerberos, отсутствует механизм обнаружения ботов и идентификации устройств, отсутствует keystore. Также в Tyk как таковой отсутствует API маркетплейс.
Red Hat OpenShift API Management

Репутационные критерии на высоте. По сайту видно, что решение впитало в себя современные подходы и хорошо интегрировано с другими продуктами Red Hat. Это opensource-решение, что позволяет его использовать даже при заявленном уходе Red Hat из России.

По экономическим параметрам это самый доступный продукт, но вот техподдержку нужного уровня заполучить нам не удалось, поэтому за нее 0%.

По нефункциональным требованиям снизили оценку за влияние нагрузки на производительность системы. По функциональным всего 3 замечания. Это отсутствие поддержки спецификации WADL, интеграции с системами класса Service Discovery (в первую очередь с Eureka и Consul.io), а также поддержка из языков программирования только Lua для создания кастомной логики.
Google Apigee API Management

Несомненно, это одна из передовых платформ от передовой компании. Снижение репутационных критериев только за счет невысокой санкционной стойкости.

В России есть компании, которые готовы продать и внедрить Apigee, но только по заоблачным ценам, практически на уровне самого дорогого. Стоимость техподдержки тоже высокая, примерно 15% от цены ПО.

По нефункциональным требованиям замечаний почти нет, разве что отсутствует особый режим техподдержки 24/7 в случае серьезных сбоев.

По функциональным требованиям отметим отсутствие поддержки спецификации WADL, отсутствие нужных нам механизмов контроля открытых соединений, в частности rate limit, а также невозможность интеграции с нужными нам системами Service Discovery (есть только с Istio).
Tibco Cloud API Management

В описании решения мы не увидели четкого плана развития системы и следования современным методологиям. Продукт существует уже довольно давно, на рынке есть специалисты, знакомые с этой системой. Это коммерческий продукт западной компании, поэтому о санкционной стойкости говорить не приходится.

По стоимости эта платформа оказалась весьма привлекательной – в 10 раз ниже, чем самое дорогое решение. А если учесть, что техподдержка включена в цену, то суммарно почти в 20 раз дешевле.

По нефункциональным критериям есть небольшое замечание к архитектуре, она оказалась чувствительна к величине полезной нагрузки. И к поддержке. Как оказалось, компания готова оказывать техническую поддержку в виде обновлений и оперативного закрытия дыр безопасности, но на этом все.

По функциональным критериям выявились следующие моменты: платформа не поддерживает спецификации AsyncAPI, GraphQL и WADL, набор механизмов reverse-proxy неполон, нет возможности интеграции с системами Service Discovery. Ограничены возможности по группировке и поиску API по атрибутам и тегам. В модуле безопасности отсутствует динамическая регистрация новых пользователей, ограничен механизм управления сессиями, нет Keystore.
Axway Amplify

Продукт получил хорошую оценку по первому набору критериев. Не хватило разве что понимания, как платформа будет развиваться дальше. Это полностью коммерческий продукт, поэтому санкционная стойкость 0%.

Стоимость решения примерно в два раза ниже самой дорогой API платформы, подходящего уровня техподдержки получить не удалось.

По нефункциональным требованиям минус за отсутствие возможности автономной работы.

По функциональным требованиям – за отсутствие интеграции с системами Service Discovery, а также непорядок с механизмами квотирования и хранилищем конфигураций.
Microsoft Azure API Management

Впечатления от описания системы двойственные. Не совсем понятна стратегия компании в отношении управления и интеграции API, в отношении поддержки Agile. Продукт полностью коммерческий, так что с уходом Microsoft из России его использование – это дополнительные риски.

По экономическим критериям эта платформа – самая дорогая как по стоимости ПО, так и по техподдержке. Переплата за бренд?

По нефункциональным требованиям все на 100%.

По функциональным требованиям есть пара минусов. Это отсутствие нормальных механизмов квотирования и отсутствие хранилища конфигураций. Во всем остальном – полный набор поддерживаемых инструментов и спецификаций.
IBM API Connect

По репутационным критериям основным минусом стала проприетарность продукта. IBM приостановила деятельность в России, так что этот продукт временно недоступен.

По стоимости эта платформа на уровне Apigee, а вот техническая поддержка с нужными нам условиями оказалась очень дорогой, поэтому 0%.

Снижение оценки по нефункциональным требованиям возникло за счет зависимости производительности платформы от нагрузки и очень негибких условий техподдержки.

По функциональным требованиям нашлись минусы: отсутствие поддержки спецификаций AsyncAPI и WADL, ограниченный набор механизмов кеширования и reverse-proxy, отсутствие поддержки нескриптовых языков программирования при создании бизнес-логики, отсутствие удобных инструментов документирования API, отсутствие поддержки механизмов идентификации устройств.
Mulesoft Anypoint Platform

В целом впечатления от описания платформы неплохие, видно, что разработчики занимаются его развитием. Санкционная стойкость низкая, так как в свободном доступе opensource-версии продукта не нашлось.

По экономическим критериям это решение не особо привлекательно. Совокупно за лицензии и интеграцию нам предложили цену в 2 раза превышающую стоимость решения Microsoft.

По нефункциональным требованиям основной минус – это отсутствие поддержки мультитенантности.

По функциональным требованиям довольно много замечаний. Отметим основные. Это отсутствие поддержки спецификаций WADL и WSDL, неполный набор механизмов кеширования, возможность динамической регистрации и саморегистрации пользователей, а также полное отсутствие функционала, необходимого для монетизации API.

В результате мы выбрали для себя Gravitee, активно используем его сами и в проектах, но, как видите, разрыв с тройкой лидеров был небольшим. Надеемся, этот анализ поможет и вам выбрать свою API Management платформу.

Очень интересно наблюдать, как мобильная коммерция развивается по всему миру! В Азии и Скандинавии она уже на высоте, а в Европе пока есть заметные различия между странами. Особенно впечатляет, что всё зависит не только от технологий, но и от стоимости интернета. Получается, что в странах, где связь дорогая, люди меньше пользуются мобильными платежами. Это точно отражает поведение потребителей — мы всегда выбираем наиболее выгодные варианты!