 | |
Paul Hollingsworth Director of Product Management, Celona |
Проблемой стандартной стратегии выбора наилучших пакетов программного обеспечения, или разработки пользовательских решений, является то, что сегодня версии программ для обеспечения услуг, реализуются с применением десятков баз данных и сотен интеграционных программ. Этот программный разнобой приводит к множеству проблем, среди которых можно отметить следующие.При создании новых продуктов и поддержке уже имеющихся персонал сети должен отслеживать и обновлять множество разнородных систем, что требует обширных знаний. Сохранить при этом содержание программ в точном и неизменном виде достаточно сложно, особенно с учетом многочисленных исправлений, внесенных в ПО в разное время и разными программистами. Даже автоматизированные процессы в таких системах нередко дают сбои. Кроме того, из-за различных форм представления крайне тяжело увязать разные продукты в единый пакет и весьма проблематично использовать механизмы их создания для разработки новых продуктов. В результате наборы этих механизмов постоянно множатся.
Особенности продукта, касающиеся, например, его взаимосвязи с другими продуктами или несовместимости с ними, требований к сети или методов экспорта из одной формы представления в другую, часто требуют интерфейсного ПО для интеграции продукта в имеющуюся систему, а также высококвалифицированных специалистов для ее поддержки.
Новые продукты, создаваемые в такой среде, требуют скрупулезного тестирования, причем, порядок некоторых процедур, касающихся продукта, просто фиксируется на бумаге или хранится в голове разработчика. Это может, например, относиться к процедурам учета заказов на услугу или ее ресурсному обеспечению.
Часто эксплуатация убыточных продуктов продолжается просто потому, что стоимость их изъятия слишком высока, а необходимые для этого квалифицированные специалисты немногочисленны и заняты выполнением более приоритетных задач. Запуск и остановка каждого продукта становится дорогостоящей процедурой, причем, уже сам расчет стоимости затрат на эту работу оказывается достаточно трудоемким. В результате, внедрение услуг и их модернизация оказывается не только дорогостоящей, но и весьма продолжительной процедурой, что приводит к запаздыванию предложения на рынке.
Таким образом, телекоммуникационные операторы оказываются не в состоянии сформировать пакет продуктов, динамично адаптируемый с новыми требованиями рынка, упуская существенные возможности получения прибыли.
Для преодоления этих проблем многие операторы рассматривают варианты замены традиционных программных решений более новыми и гибкими, меняя, например, решения для биллинга или учета заказов. Эти новые решения могут несколько сократить некоторые задержки, но их собственное внедрение тоже может растянуться более чем на год, и, главное, оно не решает основной проблемы, связанной с отсутствием единой базы для программной реализации услуг. Ниже перечислены три этапа, позволяющие превратить сеть в структуру, готовую к быстрой и безболезненной модернизации.
Первый этап. Выбор единообразной структуры для разработки и администрирования продуктов. Такая структура быть реализована в рамках двух архитектур – централизованной и федеративной. В федеративной архитектуре данные обрабатываются не в центральной базе, а прямо в приложениях, входящих в динамически меняющийся пакет. Проблема с централизованным подходом заключается в том, что, несмотря на кажущуюся простоту, его практически невозможно реализовать, так как при этом нельзя будет вносить изменения в текущие приложения, а все данные надо будет пропускать через центр. Для большинства телекоммуникационных систем кроме самых простых такой подход оказывается чрезвычайно громоздким. Выбрав единую форму представления, оператор может начать постепенную модификацию продуктов, не меняя остальные.
Второй этап. Создание условий, препятствующих введению в систему несовместимых по форме данных. Если такие данные поступают, то они должны либо автоматически интерпретироваться в нужный формат, либо должно формироваться сообщение о факте их поступления. Кроме того, следует минимизировать влияние бизнес-схем применения приложения на его программную реализацию. Это сократит количество инструментов, необходимых для создания приложений и одновременно сделает их пригодными для разработки новых приложений. Если правила, по которым создается приложение, удастся интерпретировать в простой набор программных инструментов, то разработка и администрирование приложений резко упростятся и к этой работе можно будет привлечь более широкий круг специалистов. С этого момента оператор сможет создавать новые продукты значительно быстрее и с меньшими затратами, и, соответственно, существенно повысить прибыльность услуг. Следует отметить разницу между таким подходом и планами внедрения новой биллинговой системы или, например, централизованного каталога продуктов.
Третий этап. Обеспечение доступа через веб-интерфейс к продуктам и услугам, представленным в унифицированной форме, выбранной на первом этапе. Это дополнительно упростит процедуру обновления продуктов и контроль за их работой и повысит коммерческую эффективность их применения. На этом этапе оператор начинает сознавать силу предлагаемого подхода. Процедуры введения или исключения программных продуктов будут требовать небольших денежных расходов, минимального анализа задачи, незначительных изменений в системе и несложного тестирования. Это позволит оператору внедрять новые продукты наиболее оперативно и с минимальными затратами.
Построение такой системы не так трудоемко, как может показаться. Перечисленные несложные шаги позволят существенно повысить адаптационные возможности имеющейся системы.
Автор Пол Холингсворс – директор Отдела товарного маркетинга компании Celona Technologies, производящей программные продукты для задач администрирования.
Решения Celona интегрируются c традиционными телекоммуникационными системами с использованием имеющейся инфраструктуры www.celona.com .
