От Excel до блокчейна – Собственный биллинг в ServiceNow. Часть 2

excel servicenow 1.jpg

ServiceNow предоставляет возможность не только пользоваться своими коробочными решениями, такими как ITSM (IT Service Management), ITOM (IT Operations Management), ITBM (IT Business Management) и многими другими, но и создавать уникальные пользовательские приложения на базе собственной платформы. Одним из примеров такой разработки является биллинговая система.

Биллинговая система – программный комплекс, осуществляющий учет объема потребляемых клиентами услуг, выставление счетов в соответствии с тарифами компании.

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

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

Задачи проекта

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

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

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

Схема системы

Исходя из задач и запросов бизнеса, можно представить систему в виде схем.

sсheme system.jpg

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

Услуги могут быть разными (например, Виртуальная инфраструктура как сервис, Резервное копирование виртуальных машин, Облако ФЗ-152, PCI DSS хостинг, Co-location, Терминальный сервер 1С, VDI, ИТ Аутсорсинг и др.), надо обеспечить доставку ядру системы в единообразном виде информации о том, какой тип услуги, какой клиент, в каком объеме и в какое время потребил.

Рассмотрим некоторые составляющие системы биллинга подробнее:

1. Справочник ценовых позиций (Price Position)

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

2. Биллингируемые объекты (Billing Object)

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

3. Биллингируемые атрибуты (Billing Attribute)

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

4. Правила определения цен (Price Rules)

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

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

5. Модуль разграничения доступа – по сути является простым набором правил безопасности (ACL), что в результате открывает или закрывает доступ определенному клиенту.

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

Перспективы развития биллинга

Модуль «Бухгалтерия» – в планах интеграция биллинга в общую бухгалтерию организации, например в 1С или другую альтернативную систему, используемую для этих целей.

Заключение

При планировании собственного биллинга учтите тот факт, что у одного абонента может быть несколько разных счетов (на разные услуги) и он должен иметь возможность либо объединять, либо изолировать их. Еще довольно часто встречается ситуация, когда несколько разных пользователей работают с одним счетом. Нами были продуманы и проработаны множество таких нюансов, поэтому система получилась настолько универсальной, что ее можно применить практически к любому виду деятельности, если в организации уже внедрен ServiceNow.

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

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

О том, каким именно образом нам удалось ее применить в разрабатываемом биллинге на платформе ServiceNow, вы узнаете уже в следующей статье этой серии.

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

Подписывайтесь на блог компании «ИТ Гильдия» – официального сертифицированного партнера ServiceNow, чтобы следить за новыми статьями, которые позволят вам достигнуть успеха, внедряя платформу.

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