формулюємо вимоги. Як створити оптимальну OSS/BSS

М.С. САМСОНОВ, заступник генерального директора ВАТ «Петер-Сервіс»

У прагненні до ідеалу

Запуск нових послуг майже завжди пов'язаний з переглядом стратегії бізнесу, зміною організаційної та інформаційної структури компанії, впровадженням нових бізнес-процесів і розробкою відповідних програм. Тому, з точки зору «внутрішніх» користувачів інформаційних систем, найбільш значний зміна останніх років пов'язано з істотним зменшенням часу життя бізнес-процесів операторів зв'язку.

Разом з тим ядро інформаційної системи підприємства повинно залишатися незмінним, оскільки на нього «зав'язані» інші компоненти управління телекомунікаційним підприємством - модулі управління мережним устаткуванням і серверами послуг, бухгалтерія і облік, бізнес-аналітика і маркетинг, взаємини із замовниками і партнерами-постачальниками. Вибір компонентів OSS/BSS, їх інтеграція і експлуатація зазвичай пов'язані зі складними економічними і технічними аспектами, високими витратами і необхідністю взаємодії великого числа людей, що знаходяться на різних рівнях управління компанією. Треба враховувати, що інформаційні системи безпосередньо впливають на прибутковість за все підприємства. Правильне використання OSS/BSS не тільки приносить економічні вигоди і дозволяє підвищити якість обслуговування абонентів, але і служить інструментом залучення нових абонентів, пропонуючи нові види послуг, що дозволяє збільшувати доходи на існуючій технічній базі. Тому в більшості операторських компаній найважливішою характеристикою технічних підрозділів є їхня готовність до реалізації нових вимог і швидкому зміни бізнес-процесів. Відповідно, конфігуровані OSS/BSS - головне вимога при виборі постачальника і впровадження рішення.

конфігуровані ПЗ можна умовно розділити на чотири рівні:

конфігуровані на основі визначеного набору параметрів (predefined configurability). Багатьом організаціям достатньо, якщо інформаційні системи підтримують тільки набір базових бізнес-процесів, що мають загальний характер. Це досягається впровадженням «псевдокоробочного» рішення.

Обмеженою модифікації вбудованих процесів можна досягти шляхом зміни значень параметрів з визначеного набору.

Наприклад, модуль тарифікації білінгової системи може підтримувати зумовлений набір послуг. З кожною послугою пов'язана параметрезованих ставка вартості одиниці споживання.

конфігуровані на основі визначеного набору базових об'єктів (framework constrained configurability) підходить для організацій, бізнес-процеси яких можуть мінятися, залишаючись в заздалегідь відомих межах. У цьому випадку комплект поставки інформаційної системи включає в себе визначений набір процесів, сутностей і службових процедур, які можуть компонуватися довільним чином, так, щоб забезпечити підтримку різних бізнес-процесів. При цьому для кожної конфігурації буде існувати власний набір параметрів, що дозволяє «підлаштовувати» реалізовані бізнес-процеси. Наприклад, модуль тарифікації білінгової системи може підтримувати визначення нових послуг, кожній з яких приписуються атрибути із заздалегідь визначеного, нерозширювана набору. З кожною послугою пов'язана параметрезованих ставка вартості одиниці споживання.

конфігуровані шляхом реалізації нових базових об'єктів (basis reimplementation). Іноді бізнес-процеси організації можуть змінюватися так сильно, що інформаційна система підприємства повинна буде підтримувати суті, не передбачені в первісної поставці. У цьому випадку можливості налаштування системи повинні забезпечувати розширення набору процесів і сутностей. Наприклад, білінгова система спочатку може не підтримувати Quality of Service, однак можливості системи дозволять визначити в ній цю сутність, правила її використання в процесі тарифікації та обслуговування абонентів і інтерфейси для редагування відповідних параметрів. Не у всіх операторів потреби в наявності різних компонентів OSS однакові навіть на початковій фазі функціонування. Вимоги до складу системи операційного забезпечення з'являються на стадії позиціонування компанії, при формуванні бізнес-планів і ростуть разом з розвитком компанії.

конфігуровані шляхом реалізації нової системи (system reimplementation). У деяких випадках підприємство може кардинально змінити область своєї діяльності. Наприклад, оператор зв'язку перетвориться в торгово-закупівельну компанію. У такій ситуації ні один з існуючих бізнес-процесів не зберігається, і інформаційні системи повинні встановлюватися і налаштовуватися з нуля.

Звідси висновок - з універсальною системою не пов'язано динамічне вимога універсальної конфігуруються. Мова йде тільки про статичної можливості підтримувати бізнес-процеси конкретного оператора. У той же час універсальна OSS, яка повинна бути адаптується, в стандартному постачанні може не підтримувати всі бізнес-процеси конкретного оператора.

Навколо білінгу

В той час як компоненти OSS/BSS набувають все більш універсальний характер, кожен окремо взятий оператор зв'язку будує для себе повнофункціональну систему забезпечення бізнесу. Ми вважаємо, що білінгова система є центральним сполучною ланкою між засобами надання послуг, засобами управління бізнесом підприємства зв'язку і зовнішніми організаціями, які беруть участь у процесі надання послуг абонентам (див. малюнок).

Про конвергенції

Терміном «Конвергенція», спочатку означав підтримку роботи мереж декількох стандартів, сьогодні все частіше називають обслуговування контрактних та prepaid-абонентів в інтегрованому рішенні. Таким чином, всі пропоновані продукти в якомусь сенсі конвергентних. Конвергентної - одна з вимог конфігуруються. Через відмінності між стандартно підтримуваними послугами і можливістю настройки при виборі OSS/BSS вимоги до конвергентної залежать від того, яка перспектива враховується при їх формуванні (таблиця).

Набір вимог внутрішніх замовників (маркетинг, відділ обслуговування абонентів, фінансовий відділ, технічна служба та ін) при підготовці до впровадження рішення або його заміну звичайно заснований на знаннях про існуючому або плановане наборі послуг і бізнес-процесів. Тому при виборі вимог найчастіше присутні підтримка фіксованого набору об'єктів і настроюваність на основі зумовленого набору параметрів. У результаті впроваджені рішення швидко застарівають і росте впевненість операторів зі складним або нестандартним набором послуг у тому, що їх специфічні потреби не задовольняє ні один тиражована система. При цьому причина невдоволення оператора - застарілий підхід до розробки продуктів, який зустрічається і до цього дня: тривала і дорога розробка, негарантований результат, відсутність гнучкості кінцевого продукту. У підсумку розробка та розгортання системи можуть тривати рік і більше.

Оскільки прийнятним терміном з моменту формулювання вимог до впровадження продукту вважається термін близько трьох місяців, відслідковування залежностей між бажаним рівнем конфігуруються та формулюванням вимог принципово важливо і дозволяє забезпечити розвиток бізнесу в заданих рамках, у міру розвитку оператора зв'язку.

Для прикладу можна порівняти різні вимоги до системи.

1. Система повинна підтримувати розрахунки за послугу передачі даних з тарифікацією по об'ємом.

Таке вимога неявно передбачає настроюваність на основі зумовленого набору параметрів і створить проблему при впровадженні, наприклад послуги з VoD фіксованою вартістю кожного фільму.

2.1. Система повинна підтримувати модифікується набір послуг.

2.2. Система повинна підтримувати модифікується набір заходів споживання послуг (час, штуки, об'єм).

2.3. Система повинна підтримувати призначення кожної послуги однієї або декількох заходів споживання.

2.4. Алгоритм для тарифікації послуги повинен визначатися призначеними їй заходами споживання.

Другий набір вимог має на увазі можливість розширення і зміни базових об'єктів системи. Система, яка задовольняє цим вимогам, з високим ступенем ймовірності підійде навіть для послуг, що не існують (не визначених) під час вибору.

Природно, така переробка вимог заснована на прийнятті відповідального бізнес-рішення. Вибираючи систему, потрібно враховувати, що чим вищий рівень настроюваності, тим вона дорожча. Тому коробковий продукт - дешева система на невеликий термін. По-справжньому універсальна система може не мати властивостей, необхідних оператору на момент прийняття рішення про впровадження, проте в майбутньому забезпечувати засоби їх реалізації. При цьому система та її впровадження обійдуться дорожче, але служити вона буде довше і ефективніше.

Крім технічних вимог до продукту та технічного супроводу, помітно підвищилася увага з боку замовників до самої компанії-постачальника - її надійності, позиції на ринку, досвіду реалізації складних проектів, системі управління якістю, участі в асоціаціях зв'язку і т.д. Звичайно, в першу чергу це пов'язано з величезними змінами у масштабах і якості бізнесу операторів зв'язку. Клієнтами «Петер-Сервісу» сьогодні є лідери ринку, спільними проектами з кожним з них ми можемо пишатися. У їх числі «Дельта Телеком» (мережа «Скай Линк»), «ПетерСтар», «Ростелеком», «Мегафон», «КиївСтар», філія JITC ВАТ «Північно-Західний Телеком» - наш найбільший клієнт в галузі фіксованого зв'язку.

Реалізація OSS/BSS може здійснюватися трьома способами. Перший підхід - оператор зв'язку розробляє інформаційні системи самостійно. Безперечною перевагою цього підходу є змогу домогтися повної відповідності своїм потребам та глибокої інтеграції з технічними засобами мережі. На жаль, світова практика показує, що витрати на подібне рішення (з урахуванням подальшого супроводу і модифікації) у 2,5-5 разів перевищують витрати на покупку і впровадження тиражованою рішення.

Другий підхід припускає закупівлі інтегрованої системи операційного забезпечення бізнесу в одного постачальника. На жаль, і в цьому випадку існують певні проблеми.

Компанія стає заручником «головного» постачальника інформаційної системи: розвиваючись, вона не має можливості використовувати найкращі у своєму класі рішення. У разі локальних проблем доведеться змінювати всю інформаційну систему. Крім того, як показують результати дослідження та аналізу, проведених компанією Logan Orvis International, навіть найбільш оптимальна білліпговая система зможе у кращому випадку задовольняти не більше 70% запитів і потреб оператора, її вибрав.

Третій підхід полягає у використанні методу бізнес-компонентів для побудови системи операційного забезпечення підприємства. Під бізнес-компонентом розуміється програмний модуль, який має добре визначені застосування і мережні інтерфейси і дозволяє взаємодіяти з розподіленими інформаційними системами. Бізнес-компоненти орієнтовані на вирішення певних завдань в масштабі підприємства (ізоморфно відповідають бізнес-категоріями) і володіють необхідними властивостями, пов'язаними з паралельною виконання, контролем доступу та управлінням транзакціями. Слід зазначити, що подібний підхід широко поширений при впровадженні складних інформаційних систем за рахунок трьох важливих переваг:

збірка на замовлення. Процес впровадження системи заснований на складанні окремих підсистем для одержання рішення, що відповідає специфічним вимогам конкретного оператора;

використання ринку компонентів третіх фірм. У сучасних умовах існує великий вибір компонентів, побудованих відповідно до добре певними специфікаціями і стандартами;

обслуговування шляхом заміни компонентів. У разі виявлення помилки якої потреби зміни функціональності виробник замінює окрему підсистему, стикуються з іншими модулями через добре визначені інтерфейси.

Такий метод, на наш погляд, дозволяє оптимально поєднати і невисоку вартість тиражованих систем, і можливість задовольнити унікальні потреби окремих операторів зв'язку за рахунок замовних компонентів.

Список літератури

Журнал ІнформКУРЬЕРсвязь № 9, 2005 р.