У оператора, который собирается внедрить биллинговую систему, есть выбор: купить все сразу вплоть до последней "гайки" (это может оказаться чересчур дорого) или приобрести наращиваемое решение с необходимой в данный момент функциональностью, а затем платить по частям за расширение возможностей системы. Хотя в долгосрочной перспективе затраты могут оказаться сопоставимыми, выгоднее все же платить именно тогда, когда возникает необходимость; но крайней мере есть шанс, что необходимость покупки станет осознанной. Обычно мощная функциональность на нервом этапе не так уж и нужна. Кроме того, приобретения легче делать по мере развития бизнеса, а не в самом начале пути. Однако, если оператору, работающему по подобному сценарию, потребуется срочно ввести новую функцию, есть риск, что он может достаточно долго (до полугода) ожидать ее внедрения. Оператор действительно попадает в зависимость от поставщика. Здесь важна расторопность разработчика решения и, вообще, главными оказываются уже свойства не самой системы, а ее разработчика.
Подчеркнем еще раз: тот набор характеристик системы, на который ориентируется оператор при выборе решения, важен для него в начальный момент эксплуатации. Готовое решение, удовлетворяющее этому набору характеристик, может быть найдено, однако при дальнейшем развитии оператора иногда возникают требования, предвидеть которые в момент выбора системы просто невозможно. Эволюция системы начинает зависеть не только от того, какие принципы были заложены в ее основу, но и от того, насколько разработчик сумеет осознать новые требования оператора и быстро их реализовать. Качество биллинговой системы начинает определяться качеством ее сопровождения.
Обратимся к некоторым опубликованным данным. Компания Сhoг1еуwood consulting в течение ряда лет проводила исследование, изучая, насколько операторы связи удовлетворены продуктами ведущих поставщиков биллинговых систем.
Оценка производилась, в частности, по таким показателям, как функциональность, работа службы поддержки, соответствие стоимости проекта предварительно оговоренному бюджету и т.д. Отметим, что для покупателей биллинговых систем наиболее важными являются вопросы стоимости и качество сопровождения программныхпродуктов.
Эти результаты соотносятся с итогами опроса, проведенного исследователями из Philips Group. Операторам связи был задан следующий вопрос: "Что является наиболее важным в деятельности фирмы-разработчика биллинговой системы?". Наиболее частый ответ - поддержка и сопровождение программного продукта (так ответили 34% опрошенных). Вывод из сказанного напрашивается простой: работа с биллинговой системой - это не однообразный рутинный процесс, это непрерывная модернизация, в ходе которой постепенно возникает понимание того, каким должен быть следующий шаг.
Думается, что в действительности ни один разработчик не заинтересован 15 том, чтобы поставить оператора "на колени" и вместо пего заняться несвойственным и крайне хлопотным делом - обслуживанием абонентов. Если вслед за авторами процитированной выше статьи продолжить музыкальные аналогии, то можно вспомнить, что Страдивари не только был великим мастером по созданию смычковых инструментов, но и неплохо музицировал, однако он отнюдь не выступал с гастролями. Задача разработчика не в том, чтобы играть на инструменте вместо оператора, а в том, чтобы инструмент был правильно настроен и не фальшивил. Поскольку биллинг никогда не был и не будет решением plug and plау, желательно, чтобы инструмент был прост в постройке и оператор мог осуществлять ее самостоятельно. Для этого необходимо, чтобы поставщик развивался вместе с оператором и знал особенности его бизнеса.
Унифицированные системы имеют свои преимущества. Покупая "чужие", не просто выполненные по индивидуальному заказу, а тиражируемые решения, оператор получает уже проверенное ПО, устанавливаемое поставщиком, имеющим опыт подобных инсталляций, а также обновленные версии систем, уже функционирующих у других операторов. Серийное решение отличается от самостоятельной разработки самого оператора тем, что в нем аккумулирован опыт работы десятков телекоммуникационных компаний.
Желание любого покупателя, который платит деньги, вполне понятно: за эти деньги (раз уж приходится их тратить) он хочет купить как можно больше. Поэтому рассуждения о биллинге заходят иногда в какие-то "высшие сферы" и в биллинговых системах начинают видеть основу OSS или вообще основу единой информационной системы оператора. Некоторые полагают, что функциональность биллинга может быть неограниченной.
Насколько же универсальным должно быть то решение, которое приобретает оператор для поддержки своего бизнеса? Должно ли оно ограничиваться выполнением только относительно узкого круга задач (расчеты, платежи, обслуживание, управление услугами, взаиморасчеты и ряд других) или же нужно, чтобы оно было шире и включало в себя, например, элементы технического управления сетью или элементы складского и бухгалтерского учета.
Однозначно ответить на такой вопрос сложно. С одной стороны, для части покупателей приобретение универсального продукта весьма привлекательно (особенно для небольших компаний): можно и инфраструктуру развернуть оперативно, и работать начать быстрее, и ресурсы сэкономить. С другой стороны, в такое "глубоко интегрированное решение" неизбежно встроена определенная технология работы (иначе говорить об интегрированности бессмысленно). Возможно, это самая передовая на текущий момент технология, по проблема состоит именно в том, что она встроена. Купив решение вместе с этой технологией, оператор вынужден ей следовать. Он лишает себя возможности маневрировать и в какой-то степени на самом деле становится заложником поставщика, поскольку все купленное оказалось в одной корзине. Чем объемнее подобное интегрированное решение, тем труднее в нем что-то оперативно поменять, а ресурсы, сэкономленные при покупке, расходуются (часто с избытком) на периодическое обновление системы, которая, как мы помним, куплена у одного поставщика, ставшего в данном случае монополистом. Получается, что "на колени" оператора ставит не само но себе покупное решение, а жесткая интегрированность разных решений.
Существует и иной подход. Разработчик может заниматься тем, что относится именно к поддержке операторского бизнеса, отшлифовывая функции, связанные с обслуживанием абонента, с расчетами стоимости услуг и управлением ими, с выпуском счетов и т.д. У оператора остается возможность выбрать, например, складскую систему любого поставщика или любую бухгалтерскую систему, которая наиболее полно отвечает его требованиям, а затем объединить эти системы. Сделав систему открытой (а именно об этом оператор и мечтает ), можно снабдить ее гибкими инерфейсами. Как правило, на стадии внедрения происходит интеграция со всеми смежными системами, и в этом оператору должна быть оказана вся необходимая помощь. Можно поставить перед разработчиком задачу тщательно проработать механизмы бил-линга, а во всем остальном предоставить оператору возможность самому выбрать лучший в топ или иной области продукт. В итоге оператор получает и более качественное IТ-решение, и большую свободу действий.