Замість передмови

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

Ця стаття - про програмне забезпечення, яке дозволяє використовувати АТС не тільки для комутації, але й реалізовувати додаткові функції, проводити аналіз даних телекомунікаційної мережі і її аудит.

Нині на телекомунікаційному ринку України пропонуються найрізноманітніші станції. Підшукати АТС можна собі на будь-який смак і найвибагливіші технічні умови - від міні"панаслоніка" Panasonic 6х16(маркування: [вхідні лінії від оператора]х[внутрішні номери офісу]) до операторських АТС Si2000, що, до речі виробляються прямо в Україні, або рішень від AVAYA. Зупинятись тут не буду, проте, якщо стисло, ринок не просто заповнений - він переповнений, та, не зважаючи на це, кожний постачальник визначає для себе бюджетні і бізнес-рішення під приблизно однаковий функціонал, різниця в ціні між якими часто коливається в межах порядку.

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

1. Незалежно від марки АТС і її виробника, всі сучасні станції здатні надавати CDR(сall details record) або SMDR(station message detail recording) інформацію, яка містить достатньо даних для забезпечення процедури тарифікації, альтернативної обчисленням оператора зв`язку. Хоча, нажаль, про це не всі власники АТС здогадуються.

2. Для АТС, як комутатора, існує дві області (множини) абонентів, між якими вона виступає т.н. транзитом: внутрішні абоненти і зовнішні абоненти, які підключені до АТС, відповідно, через внутрішні і зовнішні порти. При цьому портами тут можуть виступати як звичайні аналогові FXS/FXO(в хаті у вас такий), так і BRI(2 канали), PRI/2(15+1службовий), PRI(30+2 службових) - цифрові канали.
Для білінгової системи ці абоненти так само розподіляються на окремі сутності - внутрішній номер і зовнішній.

Сучасні білінгові системи

Спільне – всі сучасні білінгові системи мають одну єдину спільну рису - вони збирають CDR/SMDR інформацію з джерела даних (найчастіше це корпоративна АТС, проте може виступати і інший комутатор) для її подальшої обробки, все інше - технічні деталі, себто функціональні можливості білінгової системи і методи їх реалізації (зауважте - нгавіть тарифікація проводиться не завжди - іноді достатньо і просто реєстрації виклику). Функціонал такої системи в свою чергу прямо залежить від постановки задачі, отже, класу задач, які вона покликана вирішувати:
- Готельний білінг
- Білінг оператора зв`язку
- Білінг переговорного пункту
- Корпоративний білінг
- Облаштування інтерактивних голосувань
- etc

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

Хотілося б навести приклади використання білінгових систем в різних царинах підприємницької діяльності і спеціальні вимоги до них:

Готельний білінг має наступні особливості:
1. Необхідність підтримки особистого балансу абонента системи.
Наявність такого балансу по-перше значно спрощує отримання даних про його заборгованість (альтернативою може слугувати лише вибірка дзвінків для зазначеного абонента в зазначений час і окремий зовнішній для системи довідник сплати за дзвінки, але таке рішення значно ускладнює роботу працівників рецепції)
2. Для готелів білінг мусить підтримувати одночасну тарифікацію якнайменше по 2 тарифним планам. Ця вимога зумовлюється комерційною необхідністю виставлення рахунків клієнтам готелю за тарифами, вищими за операторські з метою отримання прибутку.
Тобто в системі відбувається одночасно дві тарифікації - для розрахунку з оператором і для виставляння рахунків клієнтам. Іноді одночасну тарифікацію можна замінити відсотковим нарахуванням при виставленні рахунку, проте:
- сума дзвінків в деталізації не співпаде із виставленою в рахунку, оскільки нарахування відбудеться при виписці рахунку
- ведення балансу абонента значно ускладнюється
Тут залишимо без розгляду юридичне питання надання послуг зв`язку готелями, яке в нашій країні зовсім непросте.
3. Для готелів, що використовують сучасні системи підтримки готельного бізнесу, білінгова система має підтримувати експорт даних по протоколу Homisco, стандартного для цих систем. В цьому випадку білінгова система виступає лишень тарифікатором.

Білінг переговорного пункту має функції у всьому подібні до готельного за одним винятком:
Білінгова програма мусить проводити процедуру пре-тарифікації і повідомляти оператору АТС про вичерпаний баланс абонента, це мінімум. А на практиці - просто відмикати абонента. Ця функція може бути реалізована лише на станціях які:
- видають т.зв. pre-CDR тобто інформацію про початок розмови абонентом з означеним зовнішнім номером
- підтримують функцію припинення розмови оператором абонента з від`ємним або означеним балансом, яка може бути задіяна білінговою системою через емуляцію команди програматора АТС або системного телефону.
Чому випливає така вимога зрозуміло - на відміну від готелю, переговорний пункт кредитні рахунки відкривати не може.

Білінг оператора зв`язку це окрема тема.
Скажу відразу - великі оператори, такі як Укртелеком, Голдентелеком, тощо, білінг або замовляють на тендері або пишуть власний. Їх не чіпаємо, бо організація білінгу для подібних трафіків - комерційна таємниця кожної окремої реалізації.
Невеличкі ж оператори, наприклад, відомчі або навчальні заклади, тощо, виставляють наступні вимоги:
1. Наявність бухгалтерії або SDK для експорту/імпорту даних в бухгалтерські програми
2. Розширені можливості друку рахунків (реклама на іншому боці рахунку, вставка стану рахунку, адреси, краще - наявність редактора рахунків)
3. Прийнятна швидкість тарифікації і формування рахунків, що стає критичним на великих обсягах даних.
4. Підтримка додаткових послуг (дебетні рахунки по карткам, оплата тонового набору, тарифікація Інтернету по dial-up, тощо)
Також варто враховувати особливості обробки великих масивів даних в довідниках системи (список з 20000 абонентів просто не повинен сортуватися бульбашкою, а вибірка з 1000000 дзвінків прямо переноситись в операційну пам`ять робочої станції).
Також важливим і дуже актуальним лишається питання прав проведення фінансових транзакцій - оператори (тобто працівники) Kyivstar і Life, наприклад, мають доступ до таких транзакцій, чим постійно користуються, збільшуючи собі і своїм знайомим баланс за рахунок абонентів з великою активністю і це не може не позначатись на ставленні до оператора зв’язку.

Корпоративний білінг - мабуть, найширша ніша для білінгових програм, проте чи не найскладніше тут задовольнити користувача.
Особливості перерахувати важко, бо потреби бувають аж зовсім несподівані. Комусь потрібні телефонні списки щоб заносити небажані номери; комусь налаштування безпеки доступу до інформації, щоб керівники департаментів мали доступ лише до інформації, що стосується їх самих і їх підлеглих; комусь потрібна безпека, інтегрована в Active Directory; комусь - автоматична періодична звітність; комусь - функціонал для співставлення тарифікаційної інформації з деталізаціями провайдерів. Список невичерпний і добре, коли замовник сам знає чого хоче. Із власного досвіду реалізацій можна пригадати такі корисні випадки:
-ЦВК України свого часу виявила, без перебільшення, шпигуна саме завдячуючи білінговій системі, яка вчасно повідомила адміністратору на якому апараті щойно було набрано певний номер.
-Дуже розповсюджений приклад співоренди цифрових потоків кількома фірмами із подальшим розподілом витрат на зв`язок. Така реалізація телекомунікаційної мережі дозволяє зекономити на АТС, яка встановлюється одна на всі ці фірми і обслуговується, відповідно, одним адміністратором.
-За допомоги білінгової системи деякі фірми проводять дослідження з ефективності реклами. Рішення дуже цікаве і, водночас, надзвичайно просте.
-Крупні корпорації, а особливо банки, полюбляють за допомоги білінгових систем проводити організаторські заходи з метою мінімізації використання службових телефонів в приватних цілях. Тут і справді є де розгулятися фантазії якщо система дозволяє хоча б генерувати фільтровані вибірки даних а краще ще й підтримує телефонні списки.
Насправді прикладів ціла купа, кількість інсталяцій білінгових систем в Україні обраховується 5-6 значноми числами і досвід цей розробниками широко використовується з метою покращення і вдосконалення нових версій систем.

Зазначене вище - лише певні аспекти особливостей білінгових систем в різних профільних реалізаціях. Без сумніву, окремо розроблена система під якусь область діяльності здатна задовольнити більше потреб своїх користувачів аніж універсальний тарифікатор. Проте існує і інший підхід до розроблення білінгових систем - це створення універсальної гнучкої базової білінгової платформи, яка в тій чи іншій мірі може бути допрацьована для застосування її в різних царинах. Реалізація і підлаштування такої системи під кожного замовника має певні особливості. Однак, за виконання наведених нижче умов, така платформа разом із про інстальованими додатковими модулями зі специфічним функціоналом в змозі конкурувати із профільними рішеннями завдяки своїй універсальності і, таким чином, наданню можливо і не завжди потрібних, проте зручних для користувачів додаткових функцій.
До такої універсальної системи, отже, висуватимуться свої вимоги:

1. Компоновка Клієнт-сервер, а краще і надання можливості Web-client. Така компоновка дозволить не тільки рознести обчислення в разі необхідності, оптимізувати швидкість передачі даних і доступу до них, але й задовольнити найвибагливішого споживача у питаннях безпеки і доступу, оскільки реалізувати політику безпеки на єдиному сервері для групи клієнтів на порядок простіше ніж для файл-серверних реалізацій.

2. Кросплатформеність що до сховища даних або використання такої СУБД, яка по кишені відносно незаможному споживачеві і, водночас, може задовольнити оператора зв`язку.

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

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

5. Реалізація безпеки доступу до даних за кількома критеріями:
- до функціональних модулів
- до інформації по групам абонентів/по окремому абоненту
- до стовпчиків у вибірках даних
- до операцій створення/видалення/виправлення
Така безпека також здатна задовольнити переважну частину споживачів

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

7. Універсальна платформа обробки інформації на етапі збору CDR.
Досі не розроблений і ніколи, мабуть, не буде розроблено єдиного протоколу CDR. Тому розробники універсальних білінгових систем мусять підлаштовувати модулі збирання інформації з тим, щоб приводити зібрані дані до єдиного формату. Ця проблема дуже непроста, оскільки АТС різняться не лише за кількістю рядків в CDR записі, але й позиціями та форматом полів даних, непостійністю кількості рядків для одного дзвінка (особливо для переведених або конференцій та за використання кодів авторизації), не завжди стандартною ознакою закінчення рядка, іноді замість часу початку розмови видається час її закінчення, тощо.
Дослідження нинішнього ринку показує, що налаштування більшості білінгових систем під кожну окрему модель АТС вимагає втручання розробника білінгової системи, а часто і перекомпіляції коду. Ця сама більшість систем використовує для збирання даних методи збирання "по масці", де для кожного поля даних для кожного типу дзвінка визначається чітка позиція і всі протоколи, що не можуть бути описані таким чином, вимагають додаткового втручання програміста. Лише одна з систем, присутніх на українському ринку дозволяє адміністратору системи запрограмувати обробку CDR інформації за допомогою мови програмування, яка складається зі стандартних функцій оброблення символьних масивів і приведення типів. Функціонал системи DialAudit дозволяє без доробки програмного коду описати дзвінок, що розбитий станцією на кілька рядків, із альтернативним символом нового рядка, із механічним обривом рядка (такі проблеми станції теж часто трапляються). В найгіршому випадку, це виконується віддалено працівниками технічної підтримки розробника (в цьому випадку скрипт обробки пересилається), в кращому - адміністратором системи.

Автору статті доводилось підлаштовувати обробку протоколу станції Meridian, яка використовувала PRI-потік, за допомоги білінгової системи DialAudit. Після 8 годин підлаштувань похибка між даними системи і рахунком оператора склала 0,08%
Хочеться зазначити що подібної точності для станції Meridian годі сподіватись досягти в принципі з іншими білінговими системами, які не дозволяють програмувати процедуру обробки CDR. Тим більше, якщо абоненти станції активно використовують конференції, на інших тарифікаторах розбіжність в кращому випадку обчислюється у відсотках, в гірших - у десятках відсотків.

8. Спроможність системи отримувати інформацію з різних джерел даних. Якщо колись CDR-записи передавались винятково через послідовний порт, то нинішні реалізації АТС передають дані і в TCP/IP і в FTP. Перелік постійно розширюється. Часто неспроможність системи отримати дані з джерела зумовлює відмову від неї, не зважаючи на всі переваги.

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

10. Можливість створення тарифікаційної моделі будь-якої складності. В тому числі:
- безболісний перехід між різними тарифними планами (як у Укртелекомі, скажімо 21/09/2003),
- враховуючи святкові дні,
- враховуючи зональність кодів оператора,
- враховуючи нарахування на кшталт абонентської платні і ПДВ,
- враховуючи похибки на аналогових лініях зв`язку,
- враховуючи безкоштовні секунди,
- враховуючи змінний курсу валют,
- враховуючи, враховуючи, враховуючи...
Моделювання тарифікації оператора зв`язку часто дуже складна процедура.

11. Ведення журналу змін. Ця функція дуже актуальна для систем, що адмініструються кількома операторами. Головна мета - пошук винного у некоректних даних.

12. Наявність функціоналу для співставлення тарифікаційної інформації з деталізаціями провайдерів.

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

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

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

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