Как ни странно это может прозвучать, оператор не только что-то покупает при подписании контракта на поставку биллинговой системы, но одновременно в какой-то степени и продает... себя в рабство. Уместно привести цитату: "Биллинговая программа должна быть полноценным инструментом, дающим возможность оператору самому "играть" на нем, а не приглашать сторонних "музыкантов", , которые могут с ним совладать, ведь многие разработчики буквально ставят оператора "на колени", практически лишая возможности вести самостоятельную политику в области биллинга". Автор, как представитель "вражеского" клана разработчиков, хотел бы прокомментировать это высказывание.
Не будем оспаривать очевидное: никто не знает бизнес оператора лучше, чем сам оператор. Вероятно, если бы IT-команда оператора взялась за разработку биллинговой системы, она действительно смогла бы создать наиболее подходящий для данной компании продукт. Но, как отмечается в той же процитированной статье, "на собственную разработку и наладку уйдет длительное время, плюс систему необходимо сертифицировать... при этом оператор развивается..." . А о том, что для начинающего оператора максимальное сокращение времени выхода на рынок является важнейшей задачей, мы уже говорили.
Решив идти своим путем, оператор постоянно находится перед дилеммой. С одной стороны, свое ПО "роднее", с ним легче работать и проще решать проблемы, с другой - существует риск, что сотрудники, в обязанности которых входит модернизация этого ПО, не будут успевать за всеми техническими, технологическими, юридическими и прочими нововведениями. Ведь, как правило, если биллипговую систему создают специалисты оператора, они же ее и эксплуатируют, а это требует затрат времени и сил, причем немалых.
Приверженцев "самописных" решений подстерегает еще одна проблема, о которой, правда, открыто предпочитают не говорить. За купленную систему отвечает поставляющая ее организация, и отношения с ней закрепляются контрактом, в котором оговаривается мера ответственности поставщика за качество продукта. В случае "самописных" решений таких юридических документов, как правило, не существует и очень многое зависит от "хороших отношений" администрации оператора и своих собственных разработчиков. Осознавая это, свои же разработчики как раз и ставят администрацию "на колени" или просто уходят, бросая свое детище на произвол судьбы. Последствия такой акции для оператора представить нетрудно.
Следует также учитывать, что тенденции и динамика развития современных рыночных отношений заставляют разработчиков создавать приложения, обеспечивающие возможность прямого обращения абонентов к некоторым компонентам биллипговой системы, для того чтобы клиенты оператора могли самостоятельно получать информацию о состоянии своего счета, управлять и следить за состоянием своих услуг. Создание подобных приложений невозможно (или весьма затруднительно) вне рамок промышленных технологий разработки программных продуктов, так как требует интегрированного подхода с применением полного спектра различных способов передачи информации (таких как: компьютерная телефония, использование доступа в Интернет, передача SМS-сообщений).
В то же время после покупки готового решения часто оказывается, что Шиллингом занимается не оператор, а разработчик. Это не позволяет персоналу оператора действовать гибко и проявлять самостоятельность в вопросах, связанных с биллингом. Конечно, ни один разработчик не может заранее предугадать все маркетинговые ходы операторов связи. Последние могут быть заинтересованы в инструментах, которые у разработчика в данный момент отсутствуют. Поэтому весьма важной является способность разработчика как можно скорее отреагировать на требования оператора, то есть способность не только продать продукт, по и качественно поддерживать его работу. И здесь па первый план выходит еще один аспект выбора биллинговой системы - отношения между оператором и поставщиком решения.