Формулюємо вимоги. Як створити оптимальну 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 р.