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

Данная проблема стара как мир IT и последние годы всё чаще разрешается с помощью концепции Программа Как Услуга (Software as a Service - SaaS). Суть её заключается в замене больших единоразовых выплат существенно меньшими периодическими. Размер выплат зависит от используемых сервисов, состав которых может гибко изменяться. Это принципиально иной способ взаимодействия потребителя с поставщиком, рассчитанный на честное, долгое и взаимовыгодное сотрудничество.

Преимущества для клиента SaaS решения заключаются в следующем:

• Отсутствует огромный первоначальный взнос за "покупку" программного продукта, который помимо непосредственного финансового обременения создаёт привязанность к единожды выбранному поставщику.
• Каждый месяц объём подписки может быть изменён, сообразно потребностям бизнеса.
• Всегда доступный консультант по всем вопросам, несущий персональную ответственность.
• Обновления предоставляются только с новым функционалом, либо исправлениями безопасности, версии не выпускаются ради ещё одной продажи.
• Не происходит двойной оплаты: сначала заказанной доработки, а после лицензии на ПО с ним. Клиент оплачивает только подписку.

Подобная схема удобнее и для серьёзных разработчиков:

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

Для разработки BGERP используется модель Continuous Delivery (CD), позволяющая достигнуть оптимального баланса между стабильностью и продукта и скоростью доставки модификаций для клиентов. Основная версия продукта меняется крайне редко, только при нарушении обратной совместимости, текущая имеет номер 3.0 Пример выпуска релизов нашего продукта изображен на схеме ниже.

Выпускаются трижды в год: в январе, мае и сентябре, включают все принятые на момент выхода в Мастер релиз Изменения. На схеме примерами Стабильных релизов являются 3.0.2509 и 3.0.2601, их номера содержат год и месяц. Только два Изменения между Стабильными релизами в примере взяты исключительно для упрощения. Перед выпуском каждый Стабильный релиз тщательно тестируется, что обеспечивает гарантии надёжности в дополнение к нашей методике разработки, учитывающей поддержку обратной совместимости конфигураций, API и структуры БД.

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

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

Изменениями называются модификации кода, которые могут содержать как "фикс", так и "фичу" и идентифицируемые уникальными числами, на схеме это 23456 и 23422. В отличие от номеров Стабильных релизов, номера Изменений не обязательно последовательны, так как их приёмка может происходить в любом порядке. При каждой модификации кода в Изменении для него автоматически публикуется релиз, на схеме: 3.0.2509.23456, 3.0.2509.23422. Физически сборки с Изменениями и документацией к ним выкладываются в каталог.

Обновление на Изменение позволяет максимально быстро получить новую функциональность в нём содержащуюся и может быть выполнено через оснастку интерфейса Администрирование / Приложение / Статус приложения и далее Обновление на изменение. Получателями таких обновлений выступают заказчики Изменений.

Изолированно протестированные и документированные Изменения принимаются в продукт, попадая в Мастер релиз. Этот релиз используется для:

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

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

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

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

В последние входят не только переобучение разработчиков, корректировка кода и документации, но и, что куда более существенно, обновление существующих инсталляций и переподготовка персонала клиентов. Оцениваются риски при обновлении установок и конвертации БД. Всегда продумываются "пути возможного отхода": резервные копии программы и данных.

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

Поэтому BGERP - это платформа, а не только продукт. Изначальная гибкость модели, множество настроек конфигурации, JEXL скрипты, Custom код, открытый HTTP API. И, наконец, самостоятельная разработка плагинов через открытый процесс разработки образуют идеальный компромисс между коробочным решением и "самописным" проектом. В любых изменениях вас поддержит исчерпывающая и актуальная документация.

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

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

По мере развития продукта BGBilling и роста компаний-клиентов появилась потребность в системе, позволяющей организовывать массовые бизнес-процессы, такие как:

• Подключение и отключение абонентов.
• Техподдержка.
• Работа с должниками.

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

• «Тяжелый» интерфейс через клиентское приложение, которое необходимо устанавливать на каждой машине, ситуация усугубляется тем, что доступ к CRM системе необходимо предоставлять большему числу пользователей, чем к биллингу.
• Ограниченная гибкость, для каждого типа процесса требуются разные свойства.
• Избыточность и специфичность интерфейса биллинговой системы для большинства задач CRM.
• Невозможность сведения в одном интерфейсе нескольких баз биллинга.

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

• Ориентация на малое число процессов, преимущественно на крупные продажи, с соответствующей спецификой интерфейса: нет постраничного деления, данные, такие как адреса, вводятся без валидации.
• Необходима установка клиентского приложения, часто функционирующего только на ОС Windows; мы изначально ориентировались на веб-интерфейс.
• Отсутствие необходимой гибкости, в т.ч. для интеграции с BGBilling.