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

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

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

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

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

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

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

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

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

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

Каждая часть BGERP имеет своего владельца-разработчика, которому консультант переадресует все ваши претензии и пожелания. Эта инновация позволила нам решить частую беду с безответственностью в открытых проектах. Хозяева плагинов кровно заинтересованы в продаже подписок, поскольку получают полностью свою долю за них.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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