Rambler's Top100
Статьи ИКС № 1 2009
Лилия ПАВЛОВА  29 января 2009

OSS – новый предмет в школе экономии

Проекты OSS средней стоимостью в миллион долларов до недавнего времени для российских операторов связи были нормой. В новых экономических реалиях ребром встал вопрос: как экономить, в том числе на внедрении ПО? Ответы искали участники прошедшего в конце 2008 г. форума Billing and OSS Telecom Forum'2008.

Эпоха мыльных пузырей закончилась

Экспертиза-2008: как сэкономить на OSS?Как заметил «человек из зала» на одной из пленарных дискуссий, посвященных проблемам выбора комплексного OSS/BSS-решения, сегодня лопаются мыльные пузыри, которые надувались в последние годы на многих рынках. Такими «пузырями» нередко становились системы OSS/BSS, когда затраты компаний на их внедрение обусловливались не столько стремлением автоматизировать операционные и бизнес-процессы и тем самым повысить свою конкурентоспособность, сколько желанием пустить пыль в глаза инвесторам, повысить рыночную капитализацию. Сегодня вряд ли кто позволит себе роскошь неуспешных проектов OSS/BSS с бюджетом в сотню (а то и не одну) миллионов долларов. Но как избежать ошибок?

Множество ошибочных сценариев рассматриваются при обучении менеджеров проектов, однако практика показала, что на деле типичных ошибок немного. Л. Бельский (IBM EE/A) привел пример из жизни (не называя заказчика), когда ошибка увеличила стоимость проекта в полтора раза, до $200 млн. Состояла она в том, что исполнитель пошел на поводу заказчика. Была выбрана модель, в которой новые разрабатываемые системы пытались полностью воспроизвести существующие бизнес-процессы – отчеты, подходы к работе, к технологическим циклам. В результате в системы пришлось внести колоссальное количество (3–4 тыс.) изменений, причем за очень короткое время. Соответственно, стоимость проекта возросла в полтора раза. «Здесь необходим определенный компромисс, – считает Л. Бельский. – Насколько нужно подстраивать систему под желания заказчика? Насколько возможно внедрение с минимальным объемом кастомизации? Решаются эти вопросы каждый раз индивидуально, и от того, как они решены, зависит, станет проект ошибкой либо успехом».

 Made in Russia в конкурентной среде

Насколько конкурентоспособны российские OSS/BSS-разработки на зарубежных и отечественном рынках? Как заметил Д. Пангин (CBOSS), из российских компаний успехов на международном уровне добились единицы. И дело не только в качестве продуктов, но и в том, что у разработчиков нет хороших связей со странами, где эти продукты должны использоваться. Для самого CBOSS, широко шагающего по зарубежным рынкам, главные конкуренты – китайские компании. По словам Д. Пангина, CBOSS успешно конкурирует с крупными мировыми вендорами (Amdocs, Comverce), но китайские разработчики предлагают более низкие цены (что важно для стартапов) и все более высокое качество и широкую функциональность.

На российской же территории сферы влияния разделились. Ю. Годына («Мастертел», блоггер портала iksmedia.ru) отметил, что для «большой тройки» сотовиков, полностью перенявших западную модель бизнеса, более привлекательны зарубежные разработки. А для средних и небольших региональных операторов больше подходят отечественные системы, учитывающие специфику их бизнеса. Однако, по мнению А. Кархова (Effortel), для отечественных разработок, которые, как правило, молоды и изобилуют «белыми пятнами» (в продуктах «с историей» они прикрыты) проблемой является отсутствие концепции. Чтобы успешно продавать свои решения даже на собственной территории, российским компаниям придется уделить внимание составлению «некоего осмысленного roadmap'а», дающего гарантии развития продукта.
Требования как источник экономии

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

Что значит «правильно составленные требования»? Взгляды на этот предмет диаметрально противоположны. Так, М. Ковалев (NetCracker Technology) отмечает, что требования к системе, составленные самим заказчиком или консультантами, иногда бывают слишком детальными, с подробным описанием функциональности старой системы (какого цвета кнопка, какое окошко появляется при ее нажатии и т.п.), что проекту помогает мало. По мнению М. Ковалева, в первую очередь требования должны отвечать на вопросы: зачем нужна система? где она экономит деньги? где зарабатывает? Если требования, изложенные даже всего на двух листках бумаги, на эти вопросы отвечают – можно запускать проект, а их потом детализировать по функциональным компонентам. Если не отвечают, то какими бы требования ни были объемными, проекту они по ходу дела только помешают. Конкретные пожелания конкретных людей бывают иногда полезны, но, как правило, размывают единое понимание бизнес-целей проекта в команде заказчика – и впоследствии компания будет тратить огромные усилия на обсуждение их нужности. Цена проекта будет расти соответственно.

С ним согласен О. Гавриков («Оранж Систем»): задачи – первичны. А персонал заказчика, который собирает, по его выражению, разные «хотелки» предприятия, должен быть способен эти задачи сформулировать. Если этого не происходит, то исполнителю приходится додумывать самому, отчего возникают коллизии, в том числе относительно расходов на проект.

Другой точки зрения придерживается У. Ярко (Comptel), который считает, что список требований должен быть максимально полным и точным. Его поддержал А. Михайлов («Инлайн Телеком Солюшнс»). Зафиксировать следует все до мелочей. Особенно важно, по его словам, четко фиксировать текущую ситуацию и задачи компании в проектах со сроком реализации около года (например, внедрение системы Inventory), на которые выделяются «небольшие» бюджеты (меньше $1 млн), – впоследствии возможности доработать систему может просто не оказаться. «По истечении года ситуация может измениться и задачи, очевидные на момент заключения контракта, с трансформацией бизнеса могут перестать быть таковыми. Сдавать такой проект будет крайне сложно», – предостерег А. Михайлов.

Подводя черту обсуждению, модератор дискуссии А. Брыков («ТехноСерв») заметил, что неточно сформулированные требования в проекте приводят к появлению запросов на изменения, которые могут быть сделаны за счет рискового бюджета. «Но у нас кризис, – напомнил А. Брыков. – Поэтому рисковые бюджеты будут урезаны. А это означает, что в случае появления большого количества изменений проект может остаться нереализованным. Итак, проектное управление во время кризиса должно обеспечить максимально точный сбор требований заказчика и использование опыта интегратора и вендора, накопленного в предыдущих проектах. Вот единственный способ уменьшить бюджет, выделяемый обычно на риск».

Ставка на совместную работу

В идеале привлечение ресурсов заказчика как при формировании требований, так и на этапах реализации проекта также приведет к его удешевлению. По мнению В. Потаповича («Мобифон-2000»), во многом успех проекта определяется отношением сотрудников заказчика к внедрению: система будет работать более эффективно, если будущие пользователи принимают активное участие в ее внедрении. В частности, необходимо совместно разрабатывать техническое задание на OSS, а также описывать требования к составу пользователей системы и выполняемым ими действиям. В некоторых случаях просто невозможно обойтись без привлечения ресурсов заказчика. «Не секрет, что при отсутствии у оператора нормальной информационной системы часть данных для ввода в нее может храниться на бумажных носителях, из которых невозможно осуществить автоматическую миграцию данных», – считает В. Потапович.

У NetCracker и вовсе сложилась своя методология привлечения ресурсов заказчика. По словам М. Ковалева, суть ее в очень тесном взаимодействии, фактически объединении высококвалифицированных кадров клиента и поставщика на этапах реализации проекта, каждый из которых является ступенькой к окончательному результату. По признанию М. Ковалева, такой подход позволяет устранить значительную часть накладных расходов на написание детальной документации, на «перетягивание каната» – но он работает только в том случае, когда обе стороны доверяют друг другу, когда клиент готов серьезно вложиться в дело и подключить серьезные ресурсы. «В таком проекте жизненно важно понимание того, к чему мы хотим прийти и какую ценность для компании это имеет, – подчеркнул М. Ковалев. – В результате проект оказывается дешевле на 30%».

Эксперты признают, что привлечение заказчика к проекту порождает определенные сложности, поскольку «комбинированной» проектной командой управлять труднее. Тем не менее Л. Бельский отметил как дополнительный плюс тот факт, что при совместной работе большее число представителей заказчика оказывается вовлечено в проект еще на ранней стадии – и передача знаний и последующая поддержка систем становятся проще и, соответственно, дешевле. Получается двойная экономия – на стадии внедрения и на стадии поддержки и развития системы.

«ИКС» об OSS/BSS: 2008:№ 6, с. 34. 2007: № 2, с. 21, 64. 2006: № 9, с. 58. 2005: № 1, с. 75; № 9, с. 22
Заметили неточность или опечатку в тексте? Выделите её мышкой и нажмите: Ctrl + Enter. Спасибо!