вівторок, 30 грудня 2008 р.

Вітання для шановних читачів, колег та всіх людей доброї волі :)

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

З повагою,
/Олег Гринчук

субота, 27 грудня 2008 р.

Анонс ТелеМенеджмент Форумом нової версії (ver. 8.0) карти eTOM

На початку грудня 2008 р. ТелеМенеджмент Форумом було офіційно анонсовано нову версію карти eTOM бізнес-процесів. Тобто eTOM version 8.0.
На перший погляд (я ще детально не дивився) найсуттєвіші доповнення там (порівняно з версією 7.5) - це:
  • опис вертикалі "Billing" групи процесів "Operations". Бо до цієї версії процеси вертикалі "Billing" були, що називається, terra incognita. Все руки в TMF до них не доходили... А можливо й сама робота була досить об'ємною та скрупульозною (особисто я схиляюся до останнього варіанту відповіді);
  • дуже суттєве розширення взаємнооднозначного відображення та опису міжпроцесної взаємодії власне eTOM- та ITIL-процесів. Включаючи те, що певні процесні групи області Enterprise Management (EM), наприклад, Enterprise Risk Management, були в явному вигляді доповнені процесами з бібліотеки ITIL.

пʼятниця, 26 грудня 2008 р.

Xohm. Знаєте що це таке? ;-)

Сабдж?
Вельми цікава ініціатива Sprint Nextel'a та ClearWire. Brand (з подачі Sprint Nextel'a) мобільного броадбенду на основі технологій 4G (WiMax). А от цікаво, наші ПіплНети та Інтертелекоми по послугам подібні до Xohm, чи ні? Думаю, що принаймі в цінах на смугу вони сильно відрізняються не в кращу сторону. Та й позиціонуються трохи не так...
Як видно з англ. вікіпедії, перша фаза проекту Xohm закінчилася (умовно) лише в кінці вересня ц.р. організацією покриття в Балтіморі. На черзі інші великі міста США.
Раджу почитати FAQ на офіційному Xohm-сайті ось тут. Досить цікаво.
І зверніть увагу на простоту, зручність та гнучкість тарифних планів! Жаль, що це лише в Штатах :-/

Думка практика-маркетолога відносно операторських VAS-послуг на основі базових телко-сервісів

В статті "Can operators generate more revenue from Voice?" мужчина-практик із зовнішністю вишуканого та інтелігентного Castilian та з нехілим бекграундом сейлза та маркетолога (остання спеціалізація - Product Marketing / Product Management professional) з Бостону висловлює свою думку відносно того, що найближчим часом мобільним операторам з фінансової точки зору навряд чи доцільно розвивати офігенно "навернуті" та екстравагантно-вишукані VAS-сервіси. А цілком досить на основі базових послуг Voice та SMS, котрі не залежать від типу юзерівських дивайсів (sic!), приділити увагу розробці та імплементації відносно простих (з точки зору споживача, звичайно) комбінованих послуг на зразок всяких гібридів Visual Voice Mail (заснована на доставці MMS та SMS), Voice SMS та/чи Voice to Text (не плутати з Voice Mail!). Причому автор дає вже існуючі приклади із життя.
Звертаємо увагу на дві принципові речі, на котрі робить наголос Рауль (Raul Castanon):
  • такі послуги за своєю природою надаватимуться не called-стороні, а протилежній - calling-стороні;
  • такі послуги націлені виключно на масовий (retail) ринок.
Бог його знає... Може й так. Я от приміряв цінність таких послуг на себе і подумав, що навряд чи користувався б ними. Але, як то кажуть, кому як. Може комусь це й цікаво. Може хтось без них і жити не може. А ще коли б і ціна була відповідна...
А в нас в Україні вже є такі послуги? Бо я не слідкую скрупульозно за цим.

середа, 24 грудня 2008 р.

Fraud Management & Revenue Assurance Management in eTOM Context (частина-2)

Це є друга частина документу. Перша була опублікована кілька днів тому тут. В даній частині документу розглядаються наступні питання:

5.3. Процессы Manage Revenue Assurance Operations
5.3.1. Процессы Monitor Revenue Assurance Controls
5.3.2. Процессы Create Revenue Assurance Trouble Report
5.3.3. Процессы Assess Revenue Assurance Trouble
5.3.4. Процессы Resolve Revenue Assurance Trouble
5.3.5. Процессы Track & Manage Revenue Assurance Trouble Resolution
5.3.6. Процессы Report Revenue Assurance
5.3.7. Процессы Close Revenue Assurance Trouble Report
6. Дополнительные информационные источники

----------------

Процессы Manage Revenue Assurance Operations
Группа процессов Manage Revenue Assurance Operations (см. рис. 5) измеряет и сопоставляет фактические характеристики [системы] сохранности доходов ожидаемым (причем обязательно в четко определенных контрольных точках), выдает отчеты об аномалиях и управляет их разрешением.


Рисунок 5. Группа процессов Manage Revenue Assurance Operations

Эти процессы охватывают управление, отслеживание, мониторинг, анализ и выдачу отчетов о характеристиках [системы] сохранности доходов в четко определенных контрольных точках RA-области и в соответствии с предписаниями системой KPI-метрик. Если в ходе анализа значений RA KPI обнаруживаются какие-либо отклонения, то это считается возникновением факта «нарушения периметра RA», что в свою очередь может приводить к вызову процедур генерации соответствующего рапорта (группа процессов Revenue Assurance Trouble Report).
Далее соответствующие процессы Manage Revenue Assurance Operations управляют решением возникшей проблемы, продолжая отслеживать Revenue Assurance Trouble Report аж до момента когда необходимые характеристики системы RA вернулись к требуемому диапазону соответствующих KPI-метрик.

Процессы Monitor Revenue Assurance Controls
Основной целью группы процессов Monitor Revenue Assurance Controls является мониторинг ранее определенных контрольных RA-точек и немедленное обнаружение любых аномалий, или деградации значений KPI, связанных с этими контрольными точками.
Зона ответственности группы процессов Monitor Revenue Assurance Controls охватывает (но не ограничивается!) следующими сферами:
  • это «первый рубеж» в плане обнаружения аномалий, заключающийся в мониторинге ранее определенных контрольных точек области сохранности доходов
  • здесь происходит сравнение полученных из этих контрольных точек специфичных данных, связанных с RA, с KPIs, соответствующих этим контрольным точкам
  • оценка и регистрация специфичных данных, связанных с RA, полученных из контрольных точек, которые (данные) находятся в допустимых KPI-пределах, соответствующих тим контрольным точкам
  • приоритезация обнаруженных RA KPI аномалий согласно критерия «большая-меньшая критичность в плане влияния на целостность данных и RA-перспективу»
  • регистрация результатов непрерывного мониторинга для последующей выдачи отчетов группой процессов Report Revenue Assurance
  • обнаружение нарушений пороговых RA-значений, представляющих собой специфичные ошибки из-за неправильных действий
  • обнаружение деградации KPI-параметров, соответствующих специфичным контрольным точкам области RA, с целью раннего обнаружения потенциальных проблем
  • создание и отсылка сообщений об обнаруженных событиях, характеризирующих деградацию и различные аномалии, на вход группе процессов Create Revenue Assurance Trouble Report
  • запись в лог-файл подробной информации об обнаруженных событиях, характеризирующих деградацию и различные аномалии, с целью предоставления (при необходимости) всей истории другим группам процессов.
Отметим, что группа процессов Monitor Revenue Assurance Controls носит перекрестный характер, поскольку она расширяет мониторинговые возможности иных процессов, входящих в структуру всей карты эталонных бизнес-процессов eTOM.

Процессы Create Revenue Assurance Trouble Report
Основной задачей группы процессов Create Revenue Assurance Trouble Report является создание новых отчетов о проблемах, связанных с областью сохранности доходов и, в зависимости от запросов, поступающих от других процессов, либо создание и отправка запросов на модификацию существующих отчетов о RA-проблемах, либо создание и отправка запросов на отмену существующих отчетов о RA-проблемах.
Новый отчет о проблемах, связанных с областью сохранности доходов может создаваться вследствие сообщений о событиях, полученных от группы процессов Monitor Revenue Assurance Controls, или в результате запросов, полученных от других процессов, обнаруживших проблемы, или аномалии в производительности, могущие повлиять на сохранность доходов.
В случае наличия отчета о RA-проблемах, группа процессов Create Revenue Assurance Trouble Report ответственна за его приведение в соответствующий формат, удобный для иных RA-процессов и, если надо, для формирования запроса на получение другой дополнительной информации. Каждое сообщение о проблемах должно содержать информацию об их источнике, уровне серьезности проблемы, ее типе, любые сопутствующие данные, важные для RA-области, данные о возможных последствиях проблемы и ожидаемое время их наступления.

Процессы Assess Revenue Assurance Trouble
Целью группы процессов Assess Revenue Assurance Trouble является анализ информации, полученную для определения природы и первопричины (root cause) нарушений и деградации параметров RA-области.
Зона ответственности группы процессов Assess Revenue Assurance Trouble охватывает (но не ограничивается!) следующими сферами:
  • осуществление анализа в ответ на получение специфичной информации о нарушениях и деградации параметров RA-области
  • проведение специального подробного анализа по обнаружению первопричины нарушений и деградации параметров RA-области
  • сравнение текущих (оперативных) и исторических данных, включая данные, относящиеся к открытым, или прежним (закрытым) RA-trouble tickets
  • инициация, модификация и прекращение сбора RA-данных соответственно требованиям последующего анализа фактов деградации и нарушений в RA-области
  • определение первопричин нарушений и деградаций в RA-области
  • регистрация/запись [текущих] результатов анализа и промежуточные обновления прежних результатов для возможного их использования в случае запроса этой информации иными процессами
  • обновление в RA-отчетах результатов анализа вместе с рекомендациями относительно дальнейших действий.
Процессы Resolve Revenue Assurance Trouble
Цель группы процессов Resolve Revenue Assurance Trouble состоит в осуществлении действий, направленных на решение обнаруженных проблем и деградаций в области сохранности операторских доходов. Эти действия осуществляются в пределах организационных возможностей предприятия, относящихся к области сохранности доходов. Вероятнее всего действия процессов Resolve Revenue Assurance Trouble будут приводить к процедурным и/или процессным изменениям для поддержания соответствия изменяемых процедур/процессов текущим нуждам предприятия сервис-провайдера. Когда анализ показывает, что решение RA-проблемы требует изменений в конфигурации специфичных ресурсов или сервисов, то последующие действия по ее устранению управляются соответственными процессами, определяемые этими ресурсами или сервисами. Они (эти «соответствующие процессы») лежат за пределами группы процессов Resolve Revenue Assurance Trouble.

Процессы Track & Manage Revenue Assurance Trouble Resolution
Цель группы процессов Track & Manage Revenue Assurance Trouble Resolution состоит в эффективном назначении, координации и отслеживании анализа RA-проблем, их решении, управлении (функциональном, или иерархическом) эскалацией, одним словом, все, как предписано открытым отчетом о проблеме, связанной с областью сохранности доходов. Для более качественных действий управление опасностями/рисками связывается с открытыми (текущими) отчетами о RA-проблемах, а процессы Track & Manage Revenue Assurance Trouble Resolution отвечают за обнаружение и эскалацию условий опасности.
Зона ответственности группы процессов Track & Manage Revenue Assurance Trouble Resolution охватывает (но не ограничивается!) следующими сферами:
  • планирование, назначение и координирование анализа с определенными действиями по разрешению RA-проблем, включая последующие анализ/обзоры для более полной гарантированности успеха предпринимаемых действий
  • модификация статуса RA-отчетов
  • выражение значимости RA-проблемы в денежном эквиваленте для лучшего понимания ее влияния и уровня серьезности
  • отмена отчета о RA-проблеме, когда выяснилось, что он был создан ошибочно
  • мониторинг статуса активного отчета о RA-проблеме и эскалация (функционально, или по иерархии) иных отчетов о RA-проблемах по мере необходимости.
Следует отметить, что некоторые продукты и/или сервисы (или их компоненты) оператора могут пребывать под управлением третьих сторон/партнеров. В таких случаях группа процессов Track & Manage Revenue Assurance Trouble Resolution отвечают за инициирование запросов (через соответственные S/P Performance Management процедуры – см. карту eTOM 3-го уровня декомпозиции) к этим сторонам/партнерам на предмет осуществления ими необходимых действий в зоне их ответственности по устранению угроз сохранности доходов оператора.
Эти процессы должны координировать все действия, необходимые для гарантирования того, что все задачи выполнены в срок и в должной последовательности. Группа процессов Track & Manage Revenue Assurance Trouble Resolution также информирует процессы Close Revenue Assurance Trouble Report о разрешении существующих проблем, связанных с угрозой утечки доходов, путем модификации статуса отчета о RA-проблеме (выставляет статус «cleared»).

Процессы Report Revenue Assurance
Цель группы процессов Report Revenue Assurance состоит в мониторинге и выдаче отчетов о:
  • статусе непрерывно мониторящихся характеристик контрольных точек RA-области
  • статусе открытых отчетов об аномалиях
для обеспечения как уведомлений о любых изменениях, так и управленческих отчетов.
Эти процессы несут ответственность за непрерывно мониторящийся статус отчетов об аномалиях и управление нотификациями, отсылаемыми в ответ на запросы других процессов и частей инфраструктуры (которые состоят в списке разрешенных к получению этих нотификций) для нужд их функционирования. Нотификационные списки администрируються и управляются группой процессов Support Revenue Assurance Operations.
Процессы Report Revenue Assurance также регистрируют, производят анализ и оценку изменения статуса отчетов об RA-аномалиях для создания управленческих и различного вида сводных отчетов об эффективности и качестве всех процессов группы Manage Revenue Assurance Operations. Эти сводные отчеты могут представлять собой специфичные отчеты в ответ на специфичные требования различных пользовательских аудиторий.

Процессы Close Revenue Assurance Trouble Report
Цель группы процессов Close Revenue Assurance Trouble Report состоит в закрытии активных рапортов (отчетов) об различных аномалиях RA-области когда эти аномалии успешно разрешены (устранены).
Процессы Close Revenue Assurance Trouble Report мониторят статус всех открытых извещений об RA-аномалиях и распознают ситуации, когда отчет может быть закрыт. Это происходит тогда, когда статус активного отчета изменяется на «cleared».

Дополнительные информационные источники
  1. GB921_Release_7-5_V7-3 «Business Process Framework (eTOM)»
  2. GB921_D_Release_6-3 «Business Process Framework (eTOM). Addendum D: Process Decompositions and Descriptions»
  3. «Гарантії отримання доходів (Revenue Assurance) телко-оператора»
  4. «Fraud Management в контексте Revenue Assurance»

неділя, 21 грудня 2008 р.

Fraud Management & Revenue Assurance Management in eTOM Context (преамбула та частина-1)

Давненько вже нічого не постив сюди цікавого. Абсолютно не було часу. Виправляюсь :). І хочу продовжити тему операторських Fraud Management та Revenue Assurance (RA), котру вже зачіпав в двох попередніх дописах:
На цей раз хочу розглянути ці теми з точки зору карти еталонної моделі eTOM останньої версіїї (ver. 7.5), запропонованої ТелеМенеджмент Форумом. Здається, що в цій версії (можу помилятися, але версію 6.0 я не вивчав детально) одним із цілого ряду суттєвих доповнень було введення групи процесів RA в область Enterprise Management (EM).
Структура даного документу матиме наступний вигляд:

1. Введение
2. Процессы Enterprise Management (EM)
3. Процессы Enterprise Risk Management
4. Процессы Fraud Management
5. Процессы Revenue Assurance Management
5.1. Процессы управления структурой RA-политик (Manage Revenue Assurance Policy Framework)
5.2. Процессы Support Revenue Assurance Operations
5.3. Процессы Manage Revenue Assurance Operations
5.3.1. Процессы Monitor Revenue Assurance Controls
5.3.2. Процессы Create Revenue Assurance Trouble Report
5.3.3. Процессы Assess Revenue Assurance Trouble
5.3.4. Процессы Resolve Revenue Assurance Trouble
5.3.5. Процессы Track & Manage Revenue Assurance Trouble Resolution
5.3.6. Процессы Report Revenue Assurance
5.3.7. Процессы Close Revenue Assurance Trouble Report
6. Дополнительные информационные источники

З цих всіх розділів в першій (даній) частині будуть розглянуті лише пп.1 - 5.2.. Пп.5.3. - 5.3.х та п.6 я приведу в другій частині документу, бо якраз працюю над ними. Отже,
------------------------

Fraud Management & Revenue Assurance Management in eTOM Context


Введение
Данный документ представляет собой анализ обновлений и дополнений, вошедших в новую версию (ver. 7.5) расширенной карты бизнес-процессов TMF eTOM и относящихся к предметным областям Fraud Management и Revenue Assurance Management. Источниками информации для настоящего документа послужили два следующих документа TMF:
  • GB921_Release_7-5_V7-3 «Business Process Framework (eTOM)»
  • GB921_D_Release_6-3 «Business Process Framework (eTOM). Addendum D: Process Decompositions and Descriptions»
В основном эти дополнения сосредоточены в области процессов 2-го уровня, на которые декомпозируются процессы Enterprise Risk Management карты eTOM (см. рис. 1 и рис. 2), но отдельные моменты, имеющие отношение к Fraud Management и Revenue Assurance Management, также наличиствуют и («размазаны» по) в других областях (например, в области операционных процессов "Operations" провайдера применимо к процессам, связанным с оценкой рисков со стороны пользователей услуг). В данном документе все внимание будет сосредоточено на Fraud Management и Revenue Assurance Management именно области Enterprise Risk Management.


Рисунок 1. Карта eTOM процессов 1-го уровня детализации


Рисунок 2. Процессы Enterprise Risk Management 2-го уровня детализации

Процессы Enterprise Management (EM)
К процессам EM (рассматриваем сейчас EM как группу из 7-ми процессов 1-го уровня – см. рис. 3) относятся процессы, которые управляют всеми аспектами и нуждами организации «в целом», либо имплементированы в виде приложений, реализующих процессы, которые имеют отношение ко всей организации провайдера услуг.


Рисунок 3. Область процессов EM 1-го уровня декомпозиции

Процессы EM охватывают все бизнес-процессы предприятия, которые:
  • необходимы для поддержания жизнедеятельности всего предприятия, включая процессы управления финансовой деятельностью, управления юридической поддержкой, взаимоотношений с регуляторами, управления затратами, качеством, и т.д.;
  • ответственны за внедрение корпоративных политик, стратегий, направлений, обеспечение рекомендаций и целей для всего бизнеса, включая разработку стратегии и планирование для областей (например, таких как Архитектура Предприятия), которые являются неотъемлемой частью выработки направлений развития всего бизнеса;
  • «размазаны» по всему предприятию, включая процессы управления проектами, оценок производительности, затрат и т.д.
Процессы Enterprise Risk Management
Группа процессов Enterprise Risk Management (см. рис. 2) отвечает за контроль над тем, что риски и угрозы для деятельности компании (или для ее репутации) идентифицированы, и им поставлены в соответствие необходимые механизмы управления и контроля для минимизации (или устранения) возможных негативных последствий. Идентифицированные риски и угрозы могут носить как физический, так и логический (виртуальный) характер. Успешное управление риском гарантирует, что предприятие способно поддерживать свои критичные для бизнеса операции, процессы, приложения, связь перед лицом различных серьезных инцидентов, угроз/нарушений безопасности и попыток мошенничества.

Группа процессов Enterprise Risk Management имеет дело (осуществляет управление) с вопросами обеспечения непрерывности ведения бизнеса (business continuity), безопасности и мошенничества. Всюду на предприятии, где только возможно (и уместно) такое управление, - оно осуществляется. Однако существуют риски, управление которыми (их минимизация) находится за пределами возможностей предприятия провайдера услуг. В таких случаях хороший эффект может дать внешнее страхование. Т.о., группа процессов «Insurance Management» является одним из ключевых аспектов Enterprise Risk Management’a.

Ключевым аспектом риск-менеджмента является также независимая оценка общего состояния того, что применяемые средства управления рисками являются адекватными и функционируют эффективно. За такую независимую оценку отвечает группа процессов «Audit Management».

У многих провайдеров в группу процессов Enterprise Risk Management включены также рабочие процессы, отвечающие за управление кредитной политикой. Но по мнению ТелеМенеджмент Форума вопросы кредитования и оценки кредитоспособности в операторской и провайдерской деятельности очень тесно переплетаются с процессами идентификации и управленией клиентскими отношениями. Посему их отнесли к операционным процессам (горизонталь CRM). Здесь же (в данном документе) этот момент просто фиксируется, но не рассматривается (см. «Введение»).

Процессы Fraud Management
Процессы Fraud Management определяют корпоративные политики борьбы с хищениями, инструкции, лучшие практики и процедуры управления, направленные на минимизацию потерь доходов предприятия сервис-провайдера. Эти процессы имеют дело с рисками и угрозами потерь доходов, или репутации сервис-провайдера вследствие мошенничества и покрывают сферы финансов, соблюдения авторских и интеллектуальных прав, воровство идентификационных данных и проч..

Процессы проактивного Fraud Management’a описывают области рисков, связанных с мошенничеством в пределах всего предприятия (включая внутренние и внешние источники риска), мониторят тренды индустрии телекоммуникаций и отслеживают best practices для сохранения гарантий того, что предприятие остается на передовых позициях в области минимизации ущерба, наносимого мошенничеством. Процессы проактивного Fraud Management’a отвечают также за поддержку классификации и установление приоритетов областей риска мошенничества. Эти процессы определяют политики, инструкции, методы и процедуры, которым должно следовать предприятие, и обеспечивают помощь процессам области «Operations» в разворачивании своих внутренних соответствующие процедур и мониторинговых процессов.

Процессы реактивного Fraud Management’a имеют дело с определением инструментария и типов наборов данных для накопления детальной информации об операционной активности предприятия, анализа этих данных для обнаружения возможных угроз, связанных с мошенничеством и судебных исследований, направленных на доказательство фактов мошенничества и определения виновных. Эти процессы тесно взаимодействуют с процессами «Security Management», имеют общие элементы (в плане workflows и process flows), информационные сервисы и специфичные коммуникационные элементы.
Процессы Fraud Management’a имплементированы на многих уровнях как предприятия сервис-провайдера, так и на уровне пользователей, систем/сетей, и т.д.. Отметим, что фактический мониторинг случаев мошенничества и управляющие процедуры встроены в эксплуатационные процессы, которые определены в пределах области «Operations» карты eTOM.

Буквально одна фраза о взаимосвязи процессов Fraud Management’a и Audit Management’a: задачей последних в т.ч. является обеспечение гарантий существования и должного функционирования необходимых управляющих структур, оценка соответствия действий предприятия принятым процедурам и эффективности этих процедур.

Процессы Revenue Assurance Management
Основной задачей группы процессов Revenue Assurance Management (см. рис. 4) является имплементация целостной структуры по контролю за сохранностью доходов (revenue assurance) на всех уровнях предприятия сервис-провайдера и создание соответствующих возможностей для решения в процессе операционной деятельности предприятия любых проблем, связанных с утечкой доходов.


Рисунок 4. Группа процессов Revenue Assurance Management

Группа процессов Revenue Assurance Management идентифицирует (в пределах всего предприятия) области рисков, связанных с утечкой доходов, мониторит тренды отрасли и подходы, основанные на best practices. Этим самым данная группа обеспечивает гарантии того, что предприятие сервис-провайдера находится на передовых позициях в плане деятельности, направленной на минимизацию утечки доходов. Эти процессы также классифицируют и установливают приоритеты рисковых областей возможной утечки дохода. Для достижения данной цели эти процессы:
  • определяют политики, руководящие принципы, методы и процедуры, которым надо следовать
  • обеспечивают помощь процессам из области «Operations» карты eTOM в деле разворачивания последними соответствующих процедур и мониторинговых процессов.
Процессы Revenue Assurance Management имеют дело с выбором инструментария и типов наборов данных для накопления детальной информации об операционной активности предприятия, анализа этих данных для обнаружения и устранения возможных источников утечки доходов. Эти процессы взаимодействуют с процессами области «Operations» и другими для оказания последним помощи во всем, что может быть связано с управлением утечкой доходов. Процессы Revenue Assurance Management, где уместно, расширяют возможности (дополняют характерными для RA) иных групп процессов для получения более полной картины деятельности предприятия сервис-провайдера.

К задачам Revenue Assurance Management относятся (но не ограничиваются только ими!) следующие:
  • установление и управление структурой RA-политик (Manage Revenue Assurance Policy Framework), включая идентификацию средств управления и систему BSC/KPI
  • установление и управление возможностями операционных процессов в части их способности к обнаружению и решению проблем, связанных с утечкой доходов
  • установление и управление динамичным развитием структуры RA-политики (Revenue Assurance Policy Framework) для гарантированности того, что эта структура отвечает современным требованиям и интересам предприятия сервис-провайдера.
Процессы управления структурой RA-политик (Manage Revenue Assurance Policy Framework)
Основной целью данной группы процессов является организация и управление структурой политик и измеряемых показателей, используемых для управления рисками, связанными с утечкой доходов оператора. В частности выбор оптимального баланса между этими рисками.

К задачам группы процессов Manage Revenue Assurance Policy Framework относятся (но не ограничиваются только ими!) следующие:
  • установление и управление структурой RA-политик, ориентированной на глобальные цели и задачи предприятия
  • разработка структуры управления и KPI, направленной на достижение четко идентифицированных целей и задач по сохранности дохода оператора
  • изучение основных обязательств предприятия и его структуры
  • регулярный пересмотр и обновление (при необходимости) структуры RA-политик для ее соответствия текущим целям и задачам предприятия сервис-провайдера.
Процессы управления структурой RA-политик имеют специфичную особенность – они отвечают за определение и развитие метрик управления и иных KPI, имеющих отношение к сохранности доходов, вместе с операционными (процессы «Operations») и иными процессами в масштабах всего предприятия сервис-провайдера. То есть, процессы управления структурой RA-политик помогают этим другим процессам поднастроиться (путем внедрения дополнительных, или модификации существующих KPI) для учитывания внутри себя еще и аспектов RA. То есть, все эти действия должны приводить к получению более полной картины деятельности всего предприятия.

Исходя из определения KPI, процессы управления структурой RA-политик определяют цели, используемые для идентификации минимально необходимого уровня производительности, требуемой соответствующей точкой контроля или процессом с точки зрения RA-перспективы, и для реализации этой задачи взаимодействуют с другими элементами процессов предприятия.

Исходя из развития структуры управления процессами RA, процессы управления структурой RA-политик применяют (накладывают) правила, основанные на разработанных RA-политиках, представляющие собой логическое определение сравнений объектов (например, счетов на оплату и CDR’ов). Результаты таких сравнений затем используются совместно с RA KPI для анализа и идентификации несоответствий с точки зрения RA-перспективы.

Процессы Support Revenue Assurance Operations
Цели группы процессов поддержки RA-операций носят двойной характер:
  • поддержка процессов управления RA-операциями путем управления требованиями к инфраструктуре для поддержки операционных процессов
  • мониторинг, управления и отчеты, основанные на возможностях процессов управления RA-операциями.
Зона ответственности группы процессов поддержки RA-операций охватывает (но не ограничивается!) следующими сферами:
  • Развитие и поддержка репозитория RA KPI для поддержки процессов управления RA-операций
  • Мониторинг и анализ отчетов, предоставляемых операционными процессами предприятия, для идентификаци потенциальных проблем, связанных с утечкой доходов, могущих возникать внутри всей области «Operations»
  • Разработка и управление графиками сбора RA-данных, включая управление необходимой информацией, взятой из области «Resource Data Collection & Distribution» (см. область «Operations» карты eTOM. Конкретно 3-й уровень декомпозиции), для поддержки проактивного мониторинга и анализа активности и запросов от процессов управления RA-операциями насчет предоставления дополнительных данных с целью оценки и анализа производительности всей RA-системы
  • Мониторинг процессов управления RA-операциями и затрат на их функционирование (включая даже те области инфраструктуры, которые внедрены и поддерживаются третьими сторонами/партнерами) и отчеты о возможностях процессов управления RA-операциями
  • Установление и управление средствами системы уведомлений о производительности ресурсов для поддержки процессов выдачи нотификаций и отчетов, поступающих из группы процессов управления RA-операциями
  • Создание, развертывание, модификация и/или апгрейд инструментария, предназначенного для развертывания новых (или модификации существующих) частей RA-инфраструктуры и RA-процессов
  • Создание, рассмотрение (анализ) и одобрение операционных процедур, разработанных группой процессов «Resource Development & Management» еще до внедрения этих процедур в ресурсную (т.е. только ресурсы. Сервисы здесь не трогаем) инфраструктуру
  • Тестирование и приемка нового, или модифицированного инструментария поддержки RA-инфраструктуры как одной из составляющих процедуры передачи от группы процессов «Resource Development & Management»
  • Обнаружение операционных ограничений или различного рода несовместимостей RA-инфраструктуры и их трансляция в требования к процессам «Resource Development & Management».

(продолжение следует)

неділя, 7 грудня 2008 р.

Управління канторою під час кризи. В т.ч. vision, mission & strategy.

Із задоволенням прочитав три дописи на блозі Міхаїла Завілєйского. Особливо другий (в минулому місяці) - "Кризис и стратегические атрибуты компании". Я вже якось піднімав в списку розсилки [Lean-Operators] (тут і тут) питання vision, mission and strategy в діяльності компаній-провайдерів. То в цьому другому дописі Міхаїл чудово їх розвинув, "обсмоктав" з різних точок зору і інтегрував поміж собою. Ознайомтесь, не пожалкуєте.

Марк Твен і я. Ггггггггггггггггггггг.

Давно для себе усвідомив одне з найбільш важливих життєвих правил. Але, виявляється, задовго до мене, буква в букву, це правило сформулював, та ще й зробив публічно доступним кльовий чуваг Марк Твен. Ну але я не злюсь на нього. Навпаки, аж загордився. Ну, дійсно, встати в один ряд з Марком Твеном - це ж неабияка честь! :)))
Єдине, що мене трохи засмутило - як сталося, що я пропустив цю його фразу. То ж, здається, перечитав чи не всю його творчу спадщину (правда, в оригіналі мало що), опубліковану в укр. та рос. перекладі! Мабуть все-таки більшість матеріалів з його творчості (публіцистика, колонки редактора, критичні відгуки, листи etc) так ніколи й не були трансльовані укр., чи рос. мовами...
Але менше з тим... Ось, власне, це життєве правило:

"Менше бреши - і тоді менше доведеться запам'ятовувати"
/(С)/ Марк Твен/

субота, 6 грудня 2008 р.

10 заповідей аналітиків

Відверто стягнув цитату з LJ юзера wanderer :). Але сподобалась мені сильно. Imho, квінтесенція професійності аналітєгів. Ну, може, слід було би ще явно вказати про необхідність відстежувати впливи "зовнішніх факторів" (сюди й різного роду "політика" та "зовнішні інтриги" можуть відноситись), але так само можна вважати, що це просто часткові випадки ("розмазані по пунктах) нижчевказаних пунктів 2, 4 і 8.

10 заповедей аналитиков
  1. Изучи бизнес и его базовые теоретические основы;
  2. Формализуй бизнес и создай модель бизнеса, поддерживай ее в актуальном виде;
  3. Определи и оцени "точки улучшения" бизнеса, учитывая тенденции и направления его развития;
  4. Следи за развитием технологий и стандартов, следи за тенденциями бизнеса и его окружения;
  5. Изучи технологии, которые намереваешся применить, создай базу знаний и поддерживай ее в актуальном состоянии;
  6. Определи конечную цель, четко сформулируй задачи и определи маршрут движения к конечной цели;
  7. Знай текущее состояние бизнеса и технологий, применяемых в текущей модели бизнеса, оцени возможность их использования в новой модели;
  8. Научись общаться, задавать правильные вопросы, научись правильно слушать;
  9. Научись работать в команде, передавать свои знания;
  10. Доводи начатое до конца.

Fraud Management в контексті Revenue Assurance

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

-----------
Fraud Management в контексте Revenue Assurance

Содержание

1. Введение
2. Мошенничество в среде провайдеров телекоммуникаций
2.1. Незаметность мошенничества
2.2. Типы мошенничества
3. Утечка доходов. Различие в подходах fraud management и revenue assurance management
3.1. Случай-1
3.2. Случай-2
3.3. Случай-3
3.4. Случай-4
4. Взаимосвязь между мошенничеством и гарантированностью доходов (revenue assurance)
5. Коллаборативный подход для отслеживания комплексной (многосторонней - multi-dimension) утечки доходов
5.1. Рекомендации по использованию коллаборативного подхода
5.2. Компоненты коллаборативного подхода
5.2.1. Коллаборация на уровне команд (персонала)
5.2.1.1. Ключевые преимущества коллаборации на уровне команд
5.2.1.2. Возможные проблемы коллаборации на уровне команд
5.2.2. Коллаборация на уровне процессов
5.2.2.1. Преимущества коллаборации на уровне процессов
5.2.2.2. Возможные проблемы коллаборации на уровне процессов
5.2.3. Коллаборация на уровне инструментариев
5.2.3.1. Преимущества коллаборации на уровне инструментариев
5.2.3.2. Возможные проблемы коллаборации на уровне инструментариев
5.3. Ключевые преимущества коллаборативного подхода
6. Дополнительные источники информации


Введение
Данный документ основан преимущественно на информации из соответствующих документов ТелеМенеджмент Форума и представляет собой попытку более или менее систематизировать «высокоуровневую» информацию о борьбе операторов с хищениями (fraud management) в общем контексте управления сохранением доходов (revenue assurance management).
Несколько слов по данному вопросу было сказано в документе «Гарантії отримання доходів (Revenue Assurance) телко-оператора» (крайне желательно с ним ознакомиться).
Там же были даны определения этих двух терминов с точки зрения ТелеМенеджмент Форума.
В телко-отрасли исторически сложилось так, что борьба с хищениями начиналась как отдельное направление и развивалась практически независимо от более широкого контекста управления сохранением доходов. Более того, в отличие от fraud management’a управление сохранностью доходов до сих пор является молодым и довольно «сырым» (незрелым) видом деятельности и большинством сервис-провайдеров по-прежнему развивается практически отдельно, в отрыве от области fraud management'a.
Однако, исходя из характера утечек доходов, подходов и механизмов их устранения, современные тенденции развития операторов требуют рассмотрения этих двух направлений в общем контексте.
Далее в документе будут рассмотрены вопросы взаимосвязи управления мошенничеством и сохранением доходов, а также даны некоторые рекомендации операторам по эффективному решению вопросов, характерных для этих двух предметных областей.

Мошенничество в среде провайдеров телекоммуникаций
Мошенничество в операторских сетях давно представляло собой проблему. Жажда легких денег делает жуликов из многих людей. Существует много различных способов обмана операторов и злоупотребления телекоммуникационными сетями – как наземной, так и беспроводной связи. Операторы имеют длинную историю борьбы с мошенничеством, но разнообразие приемов и методов, используемых мошенниками, вынуждают к перманентному усовершенствованию средств и механизмов этой борьбы.

Незаметность мошенничества
Несмотря на большие потери вследствие мошенничества многие операторы все еще не уделяют достаточно внимания вопросам борьбы с хищениями. Зачастую они даже считают, что по отношению к ним никакого мошенничества не существует. И ошибаются. Потери от мошенничества часто списывают как безнадежный долг. A недавние исследования показали, что часть дохода, теряемого из-за мошенничества, может достигать 40%-50% от всего безнадежного долга! Еще одной причиной игнорирования всей серьезности вопроса хищений является безосновательная вера операторов в то, что их сети, основанные на цифровых технологиях, якобы являются безопасными. Прежние сети, основанные на аналоговых технологиях, содержали некоторое количество принципиальных технических уязвимостей, используемых жуликами для зарабатывания денег. Наступление эры цифровых технологий, подобных GSM, напрочь устранило эти технические уязвимости. Возможно поэтому GSM-операторы почувствовали себя в безопасности. Но мошенникам в скором времени удалось отыскать простые нетехнические методы жульничества даже в среде продвинутых цифровых сетей. Мошенничество, при котором жулики официально подписываются на телеком-услуги, но не оплачивают никаких счетов, является опасным и действенным примером из их арсенала. При этом операторы не могут вычислить мошенников из огромного количества вполне лояльных пользователей услуг. Сама природа мошенничества с подпиской на услуги вынуждает операторов рассматривать его как обычный безнадежный долг. Опасность здесь состоит в том, что мошенничество, которое требует к себе крайне сосредоточенного внимания, происходит незамеченно, и оставаясь таким на протяжении длительного времени, приводит к существенной потере операторских доходов.

Типы мошенничества
Как уже было сказано ранее, существует много различных методов мошенничества, используемых жуликами для обмана операторов. И такие методы, используемые в аналоговых сетях, стали непригодны в условиях сетей цифровых. Поскольку сейчас операторы развивают исключительно цифровые сети, то это вызвало эволюцию нетехнических приемов мошенничества.
В частности гигантские размеры жульничество приобрело в области роаминга ввиду неизбежных задержек с доступом к CDR и, соответственно, с довольно неоперативным последующим обнаружения случаев мошенничества. Можно объяснить интерес злоумышленников в этом плане тем, что роуминг – это главная особенность, предлагаемая GSM-операторами, и приносит им значительный доход. Мошенничество с подпиской на услуги (subscription fraud) применительно к области роуминга часто называется roaming subscription fraud (RSF).

Мошенничество с подпиской на услуги (subscription fraud) является самым разрушительным среди всех методов и приемов нетехнического жульничества. Ее методология довольно проста. Жулье обычным образом оформляет подписку на какие-либо операторские услуги, используя нормальную, принятую в телекоммуникационной компании процедуру. Но мошенники изначально даже не намереваются платить по будущим счетам и в течении короткого промежутка времени пользуются предоставленными услугами на огромные суммы. Операторы узнают о таких фактах обычно слишком поздно, когда отследить жуликов бывает уже невозможно. И т.о. приходится списывать эти деньги на безнадежные долги.

Одним из вариантов мошенничества с подпиской является т.н. мошенничество по продаже телефонных вызовов (Call-Sell Fraud) при котором жулики используют стандартную функцию форвардинга звонков в свою пользу и предлагают «своим» клиентам возможность звонить на другие операторские сети по ценам, ниже официальных операторских. Разумеется, они могут себе позволить такие «скидки», потому как совершенно не намеревались оплачивать счета своего провайдера. Часто случалось, что пока оператор поймет что происходит и начнет выяснять ситуацию, то жулики за это время создавали целые компании и кооперативы по продаже таких «ворованных» услуг и зарабатывали целые состояния.

Еще одним любопытным вариантом мошенничества является т.н. мошенничество с услугами премиум-качества (PRS fraud, Premium Rate Services Fraud). Обычно эти PRS-услуги представляют собой номера 8-900 дозвона на всякие службы типа «секс по телефону» и проч.. Особенность этих услуг такова, что контент-провайдер получает свой доход непосредственно от оператора, предоставившего номерную емкость этому контент-провайдеру. А оператор для этого предварительно выставляет счет и снимает оплату у клиентов, воспользовавшихся этими PRS-услугами. Злоумышленник т.о. может «наговорить» на кучу денег, даже не планируя их когда-либо заплатить. А оператор все-равно будет вынужден отдать необходимую часть денег контент-провайдеру. Финансовые последствия двух последних типов мошенничества составляют до половины потерь от всех типов мошенничества.

В проводных сетях распространение получили также иные типы мошенничества. В частности мошенничество путем взлома PBX (PBX Hacking) и путем нелегального подсоединения к линии (Clip-on Fraud). Первый из них возможен в случае поддержки офисным PBX т.н. функционала прямой автоматической коммутации входного клиентского соединения (DISA, Direct Inward System Access). В этом случае внутренние пользователи офиса имеют возможность входа в PBX и, введя свой авторизационный PIN-код, получают доступ к внешним линиям и могут совершать междугородние и международные телефонные звонки. Хакеры точно так же входят в PBX, взламывают PIN-код реальных пользователей и получают доступ к внешним телефонным каналам. Чем и пользуются (а платит за это компания-собственник PBX). О характере второго упомянутого типа мошенничества можно судить с его названия. Это один из самых древних видов жульничества, заключающийся в нелегальном подсоединении (например, с помощью зажимов-«крокодильчиков») к телефонным линиям связи. Оба типа мошенничества подразумевают нелегальное использование операторского продукта или услуги.

Первоначальные системы, основанные на предварительной оплате (pre-paid systems), обладали рядом врожденных уязвимостей типа «игнорирование (или отбрасывание) последнего звонка» (last call exposure) и подвергались атакам хакеров, направленным на взлом платформ. Производители pre-paid систем понимали всю серьезность этих проблем и постоянно развивали технологии, на которых организованы такие платформы, с целью повышения их безопасности. В какой-то момент это вселило в операторов ложную уверенность в том, что pre-paid системы развились настолько, что в них полностью устранена возможность мошенничества. Надо сказать, что это абсолютно не отвечает действительности, и мошенничество с pre-paid платформами приводит к огромным потерям в доходах операторов. Жулики нашли возможным обмануть pre-paid платформы путем злоупотреблений с секретными кодами, а также используя методы «призраков-невидимок» для того, чтобы совершенно запутать как последствия своих действий, так и, собственно, свою идентификацию (подделываясь, например, под внутреннее мошенничество и т.д.).

В дополнение к вышесказанному известной есть также проблема внутреннего мошенничества (internal fraud), при которой персонал оператора или его партнеров помогает внешним злоумышленникам в их преступных действиях. Ведь внутренний персонал имеет доступ ко всем частям операторской сети и достаточно хорошо осведомлен, чтобы знать, где и как можно смошенничать. Известны случаи, когда недобросовестный персонал оператора использовал очень сложные инструменты (которые были фактически предназначены для поиска неисправностей в сети) для получения конфиденциальной информации и делал целый бизнес на использовании этой информации. То есть, внутреннее мошенничество чрезвычайно опасно и может приводить к большим потерям в доходах операторов.

Мошенничество с интерконнектом (interconnect fraud) – это еще одна важная область угроз. Часто партнеры оператора пытаются пропихнуть через его шлюзы на интерконнект-линках трафик, не подпадающий под условия контракта по интерконнекту (в надежде «авось не заметит»). Это позволяет таким горе-партнерам пробрасывать через таких операторов большие объемы неоплачиваемого трафика. Другим примером мошенничества с интерконнектом является подмена параметров вызова для подмены категории звонков и попадание в более выгодные тарифные группы. Подмена, например, параметра вызовов A-numbers в дальнейшем позволит жуликам подменить идентификацию международных телефонных вызовов локальными, а следовательно совершать международные звонки по ценам локальных. Ну и последний тип жульничества с интерконнектом предполагает нелегальный проброс трафика через дешевые неавторизируемые сети, в то время как регуляторное законодательство большинства стран разрешает проброс трафика телефонных сетей общего пользования исключительно и только через авторизируемые сети.

Утечка доходов. Различие в подходах fraud management и revenue assurance management
Собственно, утечка доходов (revenue leakage) в любом бизнес-процессе деятельности оператора подразделяется на три основные категории:
  • мошенничество (fraud). К данной категории относятся утечки доходов, вызванные злонамеренным умыслом, направленным на то, чтобы избежать оплаты использованных по факту услуг;
  • проблема гарантированности доходов (revenue assurance) ввиду операционной неэффективности (operational inefficiency). К данной категории относятся утечки доходов, вызванные неэффективностью операций в существующих системах и процессах;
  • безнадежный долг (bad debt). К данной категории относятся как преднамеренные так и непреднамеренные потери доходов.
Для наглядной иллюстрации этих категорий рассмотрим пример выпуска оператором на рынок нового продукта (см. рис. ниже).

Рисунок. Категории утечки доходов.

Как видно из рисунка, утечка доходов оператора от продаж этого нового продукта может быть вызвана противозаконным использованием предоставляемых продуктом услуг и самой сети, а также злостными неплатежами пользователей. Эти виды утечки доходов принадлежат к категории мошенничества (fraud). Неправильные данные биллинговой системы (т.е. в конечном итоге счета на оплату, содержащие разного рода ошибки в цифрах) и неотработка пользовательских заявок на приобретение данного продукта относятся к категории проблем гарантированности доходов (revenue assurance) ввиду операционной неэффективности (operational inefficiency). Невозможность (по разным причинам) пользователей уплатить по счетам за использованные ими услуги, приведшие к «безнадежной» дебиторской задолженности, относится к категории безнадежного долга (bad debt).
Иногда довольно тяжело, или даже невозможно, четко и однозначно произвести сегментацию утечки операторских доходов и выделить упомянутые категории. Это может происходить по следующим причинам:
  • Грань в дифференцировании факторов утечки доходов может быть очень тонкой. Этими факторами выступают умысел и корневая причина (root cause). А корневые причины мошенничества и проблем гарантированности доходов (revenue assurance) ввиду операционной неэффективности могут быть одними и теми же. Подача услуги на коммутатор без одновременного проведения надлежащих изменений в биллинговой системе приводит к утечке доходов у оператора, поскольку поданный сервис не сможет биллиться надлежащим образом. Так вот, первопричиной такой ситуации может быть как, например, банальная нехватка ресурсов для процесса подачи услуги (provisioning’a), так и преднамеренный злой умысел. В первом случае имеем проблему гарантированности доходов (revenue assurance) ввиду операционной неэффективности, во втором – внутреннее мошенничество.
  • Анализ большинства существующих проблем производится на основе одних и тех же данных, которые дублируются и отображаются во многих инструментах и системах. И данная тенденция вероятнее всего сохранится и в будущем. И более того – даже усугубится при анализе событий, происходящих в IP-сетях (такие события унифицированы в гораздо большей мере, чем, скажем, в сетях на основе SS7-сигнализации).
Случай-1
Услуга, которой пользуется клиент, не заведена в биллинговой системе. Хотя в сетевом элементе, предоставляющем доступ к услуге, этот клиент зарегистрирован должным образом. Такая ситуация может быть интерпретирована следующим образом:
  • Клиент был зарегистрирован в сетевом элементе нелегально.
  • Клиент ни в чем не виноват. Просто из-за ошибки в процессе, или в системе provisioning’a регистрация клиента была произведена только в сетевом элементе (а в биллинговой системе – нет).
Случай-2
Внезапное увеличение количества сгенерированных для пользователя CDR’ов может быть описано тремя возможными причинами-сценариями:
• Расширение шаблона вызова (call pattern), что может трактоваться существующей (если, разумеется, таковая есть в наличии) системой fraud management’a как потенциальное мошенничество.
• Неисправность в станции коммутации.
• Реальное повышение активности работы пользователя, способствующая увеличению доходов оператора (дай-то Бог :).

Случай-3
Внезапное увеличение трафика от интерконнект-оператора на транке, сконфигурированном для национальных вызовов. Ситуацию можно интерпретировать следующими способами:
  • Неправильная конфигурация транка инициировала через него маршрутизацию иных видов трафика (например, международного).
  • Сторонняя компания нелегально маршрутизирует свои вызовы через данный транк, используя устройства типа gateway SIMs (здесь приведен пример таких устройств).
  • Все вызвано естественными причинами. Так и должно быть. Возможно, оператору следует пересмотреть условия своих договоров и тарифных политик.
Случай-4
В рамках своей программы разработки и тестирования новых продуктов и услуг оператор выпустил на рынок мобильные телефоны с преинсталлированным новым типом сервисов для тестирования в «полевых» условиях. Это тестирование должно было подвергнуть проверке возможности по обеспечению QoS и покрытие самой сети.
  • После окончания периода тестирования большинство телефонов оператору возвращено не было. Причем из-за ошибки в рабочем процессе на этих телефонах остался активирован новый тип услуг, который собственно и тестировался.
  • После официального объявления оператором о выходе на рынок нового типа сервиса разное жулье (fraudsters :)) получило доступ к этим невозвращенным телефонам и начали нелегально торговать возможностью совершать с них исходящие звонки, нанося оператору значительные убытки.
Взаимосвязь между мошенничеством и гарантированностью доходов (revenue assurance)
Взаимосвязь между этими двумя доменами иллюстрируется ниже.

Вопросы гарантированности доходов, могущие способствовать мошенничеству
Случаи мошенничества (особенно внутреннего) могут быть вызваны тем, что жулики используют различные дырки в политиках целостности данных, или дырки в операторских, либо системных процессах. Новые системы, сервисы и оборудование – это все потенциально уязвимые области, могущие быть использованы разным жульем. Тестовые телефоны и SIM-карты также могут оказаться заманчивой целью для их использования не по прямому назначению. Наиболее общеизвестными источниками мошенничества выступают следующие области:
  • Разработка новых продуктов
  • Системные конфигурации
  • Тестовые конфигурации и тестовое оборудование
Сценарии мошенничества, способные привести к утечке доходов
Некоторые сценарии мошенничества приводят к потере доходов для подписчиков, не связанных с мошенничеством. Эти потери обычно являются следствием проблем с целостностью данных, вызванных фактом мошенничества. Идентификация таких проблем важна для возобновления получения дохода от подписчиков, никак не связанных с мошенничеством. Примером такого случая является внутреннее мошенничество, произведенное путем несанкционированного конфигурирования системы с целью подавления выдачи отчетов, касающихся жуликов, и порождающее утечку дохода для других пользователей (грубо говоря, жулик свою сумму, которую должен был заплатить оператору, делит между ничего не подозревающими пользователями, а информацию о себе вообще убирает из соответствующей системы).

Утечки доходов, которые можно выявить fraud-анализом, и наоборот
Исходя из самой природы мошенничества и вопросов из области гарантированности доходов становится возможным выделить признаки утечки доходов практически на любой системе. Этот факт приобретает большую значимость в новых случаях мошенничества в новых же системах. Использование информации такого рода является критичным фактором в деле максимально оперативного решения возникающих вопросов с целью минимизации негативных последствий. Примером такого анализа может быть определение системой управления гарантированностью доходов случаев мошенничества в подсистеме интерконнекта, которые характеризовались изменением некоторых конфигурационных параметров, в связи с чем подменялись реальные параметры инициаторов телефонных вызовов и, соответственно, биллинговой системой использовались иные, более дешевые, тарифные сетки .
Возможность fraud management system работы в режиме реального времени, нацеленной на обнаружение проблем в целостности данных, значительно уменьшает время реакции, необходимое команде, занимающейся вопросами revenue assurance, для разрешения инцидентов, связанных с мошенничеством и утечкой доходов.

Коллаборативный подход для отслеживания комплексной (многосторонней - multi-dimension) утечки доходов
Рассматривая все вышеприведенные случаи мошенничества и утечки доходов, становится ясно, что необходимо каждый такой случай рассматривать с точки зрения различных перспектив.
  • Обычно обнаружить утечку доходов и идентифицировать проблемную область является возможным. Однако довольно трудно узнать первопричину (root cause). Был ли это злой умысел, или мы имеем дело с простой ошибкой в процессах. Ответить на этот вопрос, не имея целостного взгляда на проблему, крайне сложно;
  • Вернемся к случаю-4. Описанная в этом случае проблема из области гарантированности доходов легко может привести к мошенничеству на всей операторской сети. Если эту проблему не рассмотреть в комплексе, с учетом всех взаимосвязей и их влияния, то имеющиеся лазейки могут позволить разному жулью атаковать всю операторскую сеть. То есть, еще раз: идентификация взаимосвязей обнаруженной проблемы и их воздействия крайне важна для выбора правильного решения и методологии предотвращения таких проблем.
  • Случаи внутреннего мошенничества, вероятно, будут обнаружены revenue assurance system изначально. Однако если точная причина и влияние проблемы не идентифицированы, то возможной будет ее возникновение вновь и вновь. Если рассматривать эту проблему только с точки зрения гарантированности доходов, то весьма вероятно, что это даст возможность жуликам воспользоваться имеющимися лазейками и дырами. Посему данную проблему следует анализировать как при помощи revenue assurance system, так и с помощью fraud management system.
  • Время, отведенное для решения проблем, является весьма критичным. Для более быстрого решения определенных проблем, обнаруженных одной из функций соответствующих систем управления (мошенничеством, или гарантированностью доходов), может оказаться необходимо, чтобы выявленная информация была передана другой соответствующей функции при первой же возможности. Такой совместный подход облегчает как передачу информации, так и ранние реактивные действия в ответ на возникшие проблемы.
Рекомендации по использованию коллаборативного подхода
Для комплексного анализа проблем и принятия решений, связанных с утечкой доходов, рекомендуется применять коллаборативный подход, основанный на возможностях обеих систем:
  • fraud management system
  • revenue assurance system
Такой коллаборативный подход следует осуществлять на трех уровнях:
  • Уровень персонала (RA-team и fraud-team)
  • Уровень процессов
  • Уровень инструментария
Во многих случаях, следствием такого сотрудничества является качественный анализ и принятие комплексного решения, направленного на устранение причин утечки доходов, отдельные формы которого могли были быть пропущены (если бы не применялся такой коллаборативный подход).
Рекомендации в последующих разделах документа касаются только взаимодействия между RA-team и fraud-team и не предполагают обязательное наличие выделенных сотрудников, которые работают в тесном контакте с обоими подразделениями. Если быть кратким, то суть этих рекомендаций заключается в использовании инструментов и процессов для revenue assurance и fraud’a, которые позволяют совместное использование данных, KPI, case management’a, зонтичных подсистем и отчетов. Причем совершенно не является необходимым использование именно одних и тех же процессов и инструментов для RA- и fraud management’a.

Компоненты коллаборативного подхода

Коллаборация на уровне команд (персонала)
Сотрудничество между RA- и fraud management teams приводит к гораздо более эффективному распространению и передаче информации, что позволяет более быстрое решение возникших проблем. Ниже перечислены некоторые варианты коллаборации на уровне команд:
  • Расположение в одном помещении, или офисе;
  • Общие для обеих команд сотрудники и менеджеры с четкими ролями и обязанностями, для поддержания тесных рабочих связей между этими двумя командами;
  • Общие сотрудники, которые анализируют и случаи мошенничества, и проблемы, связанные с гарантированностью доходов.
Ключевые преимущества коллаборации на уровне команд
Приведем только некоторые ключевые преимущества коллаборации на уровне команд.
  • Перекрестное снабжение информацией;
  • Более быстрая информированность по поводу проблем и обнаруженных несоответствий;
  • Более быстрый передача контроля и полномочий в решении проблем между командами;
  • Более быстрая идентификация ключевых вопросов и информации.
Возможные проблемы коллаборации на уровне команд
Наряду с преимуществами коллаборации на уровне RA- и Fraud-management команд возможны также и проблемы (см. ниже).
  • Во многих сервис-провайдеров и/или операторов команды RA- и Fraud-management’a существуют в виде различных отделов, и могут даже подчиняться разноплановым руководителям (например, коммерческому и техническому директору). Может оказаться необходимым провести изменение существующих организационных структур, или определить новые структуры, которые позволили бы эффективный обмен информацией между этими командами.
  • Приоритезация проблем - мошенничеству обычно присваивают высший приоритет, так как оно считается внешней атакой. Но для предприятия сервис-провайдера/оператора может оказаться необходимым определить какие-то другие приоритеты.
  • Примесь различных «политических» факторов в роли, обязанности, и полномочия членов команд (сюда также относятся разного рода интриги).
  • Проблемные вопросы из области безопасности. Доступ к информации, относящейся к сфере вопросов fraud management team, в некоторых сервис-провайдеров может быть ограничен ввиду требований локальных регуляторных актов. То есть следует иметь ввиду и помнить о таких моментах.
  • Различия в миссии обеих команд. Отдел, который занимается вопросами хищений как правило пытается устранить случаи мошенничества, не делясь при этом информацией с целой организацией (чтобы воспрепятствовать повторению подобного мошенничества). С другой стороны миссия команды, которая занимается вопросами гарантированности доходов, состоит в том, чтобы обнародовать всю информацию, полученную от всех подразделений целой организации (чтобы помочь предотвратить подобные проблемы с гарантированностью доходов в будущем, и убедить всех в продолжении сотрудничества с собой).
  • Опыт и навыки. Некоторые участники команды, возможно, должны приобрести дополнительный опыт и навыки, чтобы свободно обращаться с вопросами, имеющими отношение к обеим предметным областям (fraud и revenue assurance).
Коллаборация на уровне процессов
Интеграция процессов управления мошенничеством и процессов revenue assurance (гарантированности доходов) способствует более оптимальному движению информации и повышает общее качество решения проблем. Интеграция процессов охватывает общие цели и KPI, интегрированные методологии и процедуры принятия решений, передачу информации и событий, коммуникацию между подразделениями и другие связанные области.
В зависимости от природы бизнеса, размеров предметной области и способности произведения (при необходимости) изменений в существующей структуре, интеграция может быть произведена во всех процессах или специфических областях. Например, интеграция может быть проведена только касательно проактивных действий по предотвращению проблем, а не для оперативных действий по их устранению.

Преимущества коллаборации на уровне процессов
Ниже приведены примеры преимуществ коллаборации на уровне процессов.
  • Оптимизация действий, облегчающих и убыстряющих решение проблем, особенно в случае кросс-функциональных проблем;
  • Уменьшение количества избыточных процессов.
Возможные проблемы коллаборации на уровне процессов
  • Риск повышения сложности;
  • У большинства операторов уже установлены рабочие процессы и процедуры для борьбы с мошенничеством и эксплуатационной неэффективностью. И для их изменения может потребоваться преодолевать определенное сопротивление;
  • «Политические» соображения при рассмотрении процессов в обеих областях.
Коллаборация на уровне инструментариев
Интеграция инструментариев fraud management’a и revenue assurance management’a может быть произведена на двух уровнях:
  • уровне управления данными (data management layer)
  • бизнес-уровне (business layer)
На уровне управления данными системы используют одну и ту же обработку данных и хранение для интерфейсов, которые обычно используются обоими системами. Интеграция инструментариев способна обеспечить существенную экономию эксплуатационных расходов на поддержку инфраструктуры.
На бизнес-уровне интеграция включает общие сообщения о инцидентах (alarms), общие технологические процессы, отчеты и представления. Это позволяет пользователям систем обмениваться информацией и эффективно сотрудничать. Автоматизация содействует более быстрой коммуникации и быстрому решению проблемы, обеспечивая наличие и корректность соответствующих процессов наряду с правильным описанием проблем.

Преимущества коллаборации на уровне инструментариев
  • Целостный взгляд на проблемы fraud management’a и RA-management’a;
  • Легкость impact-анализа (анализ последствий) широкого круга проблем на управленческом уровне предприятия;
  • Целостность в решении проблем и взглядов на технологические процессы.
Возможные проблемы коллаборации на уровне инструментариев
  • Интегрированные платформы, способные работать с вопросами обеих предметных областей (fraud и RA);
  • Режимы работы инструментариев из области fraud- и RA-management’a обычно отличаются. Исходя из характера проблемы, ее воздействия на бизнес и экономику, инструментарий из сферы fraud management’a обычно является real-time’овой системой. Напротив, RA-инструментарий обычно функционирует в режиме пакетной обработки процессов.
  • Стандартные интерфейсы для инструментов коллаборации.
Ключевые преимущества коллаборативного подхода
  • Более быстрое решение проблемы. Коллаборативный подход облегчает передачу информации от одной системы и персонала другой системе и персоналу. Это приводит к более быстрому решению проблем.
  • Увеличение производительности путем устранения дублирующих процессов. Коллаборативный подход упрощает запутанные и сложные процессы, являющиеся общими для различных действий. Это позволяет устранить избыточные процессы и упростить сами действия.
  • Оптимизация ресурсов через предоставление общего доступа к имеющейся инфраструктуре. Устраняет разобщенность отдельных систем для получения лучших результатов в области fraud и RA-менеджмента. Общая коллаборативная платформа может способствовать упрощению инфраструктуры.
Дополнительные источники информации
  • Очень информативная статья «Fraud Management Systems in Telecommunications: a practical approach», в которой дается более подробная классификация мошенничества в операторских сетях и описываются основные принципы систем управления мошенничеством.
  • Просто список URL источников о борьбе с мошенничеством. Не все линки работающие, но есть просто замечательные.

четвер, 4 грудня 2008 р.

Експертне заключення спеціаліста :)))

Недавно мало живіт не надірвав від сміху :).

В одному підрозділі, котрий займається проектною діяльністю, його начальник, проектант з великим досвідом роботи, влаштував коротку нараду, щоби публічно проаналізувати один проект, котрий був доручений молодому та недосвідченому інженеру-проектанту, на предмет дотримання стандартів проектування (ГОСТів, ДБНів, ISO etc).
Але вийшовши до дошки та пролиставши цей проект він зміг видавити з себе лише одну фразу. Зате яку!!!! :)))

- Мда... Лучше всего данная работа подпадает под определение "релаксация молодого организма".

вівторок, 2 грудня 2008 р.

Доповнення до статті "Service delivery: трансляція потреб користувачів в сервіси мережі. Best practices"

Згадав, що варто було би доповнити раніше опубліковану статтю "Service delivery: трансляція потреб користувачів в сервіси мережі. Best practices" ще кількома штрихами.
  1. Ну, по-перше, варто було би одночасно мати наувазі моменти, про які я вже писав в списку розсилки [Lean_Operators] і на цьому ж блозі в статті "OSS procurement process".
  2. Величезне значення та вплив на кінцевий успіх будь-якого операторського інфраструктурного проекту мають також:
    а) однакова культура (підхід, стандарти) замовника та підрядника до проектної діяльності в цілому. Дане питання вирішується в ході переговорів та узгоджень ще до початку проектних робіт.
    б) усунення мовних бар'єрів (якщо замовник та підрядник належать до різних мовних культур). Не скупіться на піднайм перекладача, котрий орієнтується в професійній тематиці, принаймі для проведення знакових переговорів та консультацій. Бо дуже часто представники різних мовних культур, виходячи зі свого досвіду, розуміють одні й ті ж терміни та поняття по-різному.

понеділок, 1 грудня 2008 р.

Навстречу кризису :))))

Колеги колись прислали.
На 100% відображає відношення народу до влади.
---
Навстречу кризису

Однажды в телевизоре появился бледный как смерть Министр Финансов и заявил:
- Финансовый кризис нас не затронет! Потому что. Я вам точно говорю.
Население, знающее толк в заявлениях официальных лиц, выматерилось негромко и отправилось закупать соль,спички и сахар.

На следующий день в телевизоре появился смущенный донельзя Министр Торговли и сказал:
- Запасы хлеба и товаров первой необходимости позволяют нам с гордостью утверждать, что голод и товарный дефицит нам не грозит. Вот вам цифры.
- Ох! – сказало население и докупило еще муку и крупы.

Министр Сельского Хозяйства для убедительности сплясал на трибуне и сказал радостно:
- Невиданный урожай! Надежды на экспорт! Возрождаемся! Закрома трещат!
- Во даже как! – ужаснулось население и побежало конвертировать сбережения в иностранную валюту.

- Цены на недвижимость упадут! Каждому студенту по пентхаузу! В ближайшем будущем! – не поморщившись выпалил Министр Строительства.
- Да что ж такое, а?! – взвыло население и побежало покупать керосин, керосиновые лампы, дрова и уголь.

- Современная армия на контрактной основе. Уже завтра. И гранаты новой системы. В мире таких еще нет. – солидно сказал Министр Обороны. – Ну а чего нам? Денег же – тьма тьмущая. Резервы, запасы и вообще профицит.
- Мама!...- пискнуло население и начало копать землянки.

- Все о-фи-ген-но! Вы понимаете?! О-ФИ-ГЕН-НО!!! – внушал Президент. – Мы уже сегодня могли бы построить коммунизм. Единственное что нас останавливает – нам всем станет нефиг делать. Потому можете спать спокойно! Стабильнее не бывает! Пенсионеры покупают икру ведрами! Предвижу качественный скачок, рывок и прыжок. А количественный – вообще бег! Семимильными шагами к достатку и процветанию. Карибы становятся ближе. Отсель грозить мы будем миру. По сто тридцать центнеров роз с каждой клумбы. Надои будем вообще сокращать. Коровы не могут таскать вымя. Население возмущено дешевизной. Южная Америка просится в состав нас на правах совхоза. Ура!

- Да что ж вы там такое готовите, звери?! – закричало население и на всякий случай переоделось во все чистое.

неділя, 30 листопада 2008 р.

Супер історія створення картини "Таємна Вечеря" Лернардо Да Вінчі

Чудова історія з колосальним змістом. Майже в дусі дзен-буддизму. І абсолютно не суть важливо - легенда це, чи насправді так було...
--------
Создавая свой гениальный шедевр "Тайная вечеря", Леонардо да Винчи очень скурпулезно искал модели для фрески. Леонардо много раз прерывал работу, отправляясь на поиски натурщиков. Однажды, слушая церковный хор, он увидел в одном из молодых певчих совершенный образ Иисуса и, пригласив его в свою мастерскую, сделал с него несколько набросков и этюдов.
Прошло три года. "Тайная вечеря" была почти завершена, однако Леонардо так и не нашел подходящего натурщика для Иуды. Кардинал, отвечавший за роспись собора, торопил художника, требуя, чтобы фреска была закончена как можно скорее.
И вот после долгих поисков художник увидел валявшегося в сточной канаве человека - молодого, но преждевременно одряхлевшего, грязного, пьяного и оборванного. Времени на этюды уже не было, и Леонардо приказал своим помощникам доставить его прямо в собор. С большим трудом его притащили туда и поставили на ноги. Человек толком не понимал, что происходит, и где он находится, а Леонардо писал на холсте лицо человека, погрязшего в грехах...
Когда он окончил работу, нищий, который к этому времени уже немного пришел в себя, подошел к полотну и воскликнул:
- Я уже видел эту картину раньше!
- Как? - удивился Леонардо.
- Три года назад, ещё до того, как я всё потерял. В ту пору, когда я пел в хоре, и жизнь моя была полна мечтаний, один художник написал с меня Иисуса.

пʼятниця, 28 листопада 2008 р.

Service delivery: трансляція потреб користувачів в сервіси мережі. Best practices

Прийшла недавно мені одна стаття по забугорному списку розсилки. І спонукала мене накидати документ, котрий в якійсь мірі зводить воєдино досвід як мого спілкування з забугорними спецами по OSS/BSS інтеграції, так і власних помилок.
І ось що вийшло.
-----------------

Содержание

1 Введение
2 Опросник, предназначенный для определения бизнес-требований пользователей
2.1 Бизнес-требования
2.2 Технологии и технические требования
2.3 Требования по интеграции
3 Обеспечение гибкости плана проекта
4 Основные приемы оптимального выполнения плана имплементации сетевых сервисов
4.1 Надежная архитектура
4.2 Стандартизированные конфигурации и детализированный проект
4.3 Приобретение и поставка
4.4 Готовность участка внедрения
4.5 Планирование и снабжение
4.6 Управление изменениями
4.7 Предварительный запуск участка
4.8 Тестирование участка
4.9 Передача участка в эксплуатацию


1 Введение
Что это за документ
Настоящий документ является некой аналитической интеграцией идей и мыслей, вызванных изучением:
  • документов ТелеМенеджмент Форума (в основном касающихся структуры NGOSS – TMF GB927, карты бизнес-процессов eTOM – TMF GB921, «Service Delvery Framework» - TMF TR139 и TMF TR141),
  • функционала отдельных модулей OSS-систем (в основном «SDP, Service Delivery Platform» by Telcordia),
  • ряда открытых публикаций в специализированных Интернет-изданиях,
  • идей Telco 2.0 Инициативы (особенно касательно network neutrality)
  • и практики проведения консалтинговых работ по проекту внедрения модулей и частей OSS.
Для кого предназначен
Документ может быть полезным как операторам так и предприятиям-собственникам корпоративных сетей, перед которыми стоит задача внедрения или модификации сетевых сервисов для решения высокоуровневых задач бизнеса.

Рассматриваемые вопросы
Трансляция потребностей пользователей в сетевые сервисы отчасти является искусством, отчасти наукой. Лучшие мировые практики в этом вопросе предполагают проведение работ по идентификации нужд пользователей путем составления и заполнения специальных анкет-опросников, предназначенных для определения бизнес-требований, затем трансляции этих бизнес-требований в технические требования и технологические решения (см. рис.1 - структуру NGOSS: Business View (eTOM), System View (SID, Share Information and Data), Implementation View (TNA, Technology Neutral Architecture), Deployment View (TAM, Telecom Application Map)).
После этого составляется план проектных работ для практического воплощения такого последовательного отображения. Самое сложное в данном вопросе, как показала практика – это понимание ключевых шагов выполнения проекта для соблюдения его бюджета и временных рамок. Далее рассмотрим все перечисленные выше вопросы по порядку.

Рисунок 1. Структура NGOSS

2 Опросник, предназначенный для определения бизнес-требований пользователей
Сетевые сервисы могут быть определены различными путями. Их примеры содержат разворачивание на операторской сети сервисов VoIP, Video-over-IP, бизнес-приложений SAP, CRM, Citrix и др., работоспособность которых зависит от функционала собственно самой сети.
В настоящее время большинство предприятий (особенно крупных) в значительной мере зависит от сети и способности сетевых сервисов поддерживать бизнес-приложения этих предприятиий. И как правило существуют различные варианты технологий (или их модификации), позволяющие имплементировать эти сетевые сервисы таким образом, чтобы достигалась оптимальность выполнения бизнес-приложений.
Бизнес-требования выступают являются движущей силой развития технологий (а не наоборот). Поэтому понимание самых важных бизнес-требований клиента и их трансляция в технические требования и технологические решения являются наиболее критичными аспектами в деле успешного внедрения сетевых услуг.
Сбор бизнес-требований – суть довольно интенсивный процесс. Общепринято этот процесс рассматривать с точки зрения трех ключевых областей:
  1. Бизнес-требования
  2. Технологии и технические требования
  3. Требования по интеграции
2.1 Бизнес-требования
Бизнес-требования фокусируются на четком понимании того, куда пользователь двигается с точки зрения его будущей экспансии на новые рынки, внедрения новых возможностей по сервисам, финансирования и видения развития операционной деятельности. В большинстве случаев, как уже отмечалось выше, все это (то есть принятые бизнес-решения) является определяющим фактором для последующих ИТ-инициатив. А уже ИТ-отделы, или службы отвечают собственно за разворачивание сети, обеспечение ее бесперебойной работы и производительности, поддержку критичных бизнес-приложений. Естественно, что ИТ-отдел во многих случаях для решения каких-либо оперативных вопросов вынужден контактировать с бизнес-единицами, но в общем и целом работа ИТ-отдела является реактивной, по факту (то есть, они безусловно принимают к исполнению решения бизнес-руководства, являясь обеспечивающим подразделением).
Лучшие мировые практики рекомендуют рассмотрение и формализацию бизнес-требований в трехлетней перспективе с целью определения на их основе того какие сетевые сервисы будут необходимы для поддержки бизнеса предприятия.

2.2 Технологии и технические требования
Необходимые технологии и технические требования определяются после бизнес-требований и фактически являются производными от последних.
Технологические требования содержат определения стыков вендорских решений и требований стандартизации. Технические требования представляют собой детализацию проектов решений, предполагающихся к внедрению для поддержки бизнес-требований, которые предсталяются в виде высокоуровневых сетевых приложений. Исходя из вышесказанного технические требования содержат следующие компоненты:
  1. Архитектурные требования. Данный вид требований обеспечивает входные данные для выбора основных сетевых технологий: LAN, WAN, центры обработки и консолидация данных, выбор между централизованными, либо распределенными ИТ-операциями.
  2. Требования по полосе пропускания и масштабированию. Данный вид требований определяет кто и где именно (место в сети) будет использовать сервисы высокоуровневых приложений, и какая полоса пропускания для этого требуется. Исходя из этого принимаются решения об архитектуре WAN-сети, решений по удаленному доступу и общем размере сетевой инфраструктуры.
  3. Требования по интеграции. Эти требования определяют выбор технологических решений таких как, например, функционал вендорских решений и их совместимость с текущей сетевой инфраструктурой.
  4. Требования по управлению. Данный вид требований определяет как сеть будет управляться с точки зрения сетевых проблем и аварий, конфигурации и производительности.
  5. Требования по безопасности. Эти требования определяют каким образом будет обеспечиваться безопасность сервисов, предоставляемых приложениями. Данный вид требований является необходимым особенно с точки зрения требований локального законодательства. То есть, они дают ответ на вопросы как осуществляется контроль за ограничением доступа к сети, аутентификацией и авторизацией пользователей, криптованием передаваемых данных и т.п..
2.3 Требования по интеграции
Данный вид требований определяет процесс развертывания, временной график плана работ, задачи и распределение ресурсов, необходимых для реализации проекта по внедрению сетевых сервисов.
Ключевыми вопросами требований по интеграции являются следующие:
  1. Требуется ли заказчиком формальное управление проектом внедрения сетевых сервисов?
  2. Составлен ли заказчиком четкий перечень всех задач, подлежащих решению для внедрения сетевых сервисов?
  3. Составлен ли заказчиком временной график внедрения сетевых сервисов?
  4. Владеет ли заказчик всеми необходимыми внутренними ресурсами для внедрения сетевых сервисов?
  5. Разработан ли детальный план проекта внедрения сетевых сервисов?
Крайне необходимо перед началом работ иметь ответы на все эти вопросы. Более того, эти ответы должны быть кристально четкие и понятные, потому как они являются залогом правильных решений и действий по имплементации проекта внедрения сетевых сервисов. Добавим, что процесс нахождения ответов на поставленные вопросы может оказаться довольно длительным. Это нормально. Экономить на времени здесь крайне нецелесообразно исходя из цены ошибки на данном этапе.

3 Обеспечение гибкости плана проекта
План проекта представляет собой испытанное и верное средство для достижения успеха в деле имплементации сетевых сервисов и сопутствующей ей сложного процесса интеграции многих составных частей. Для отслеживания статуса работ по проекту существует много инструментариев и средств. В данном документе они не рассматриваются. Вместе этого приводятся общие подходы по созданию плана проекта, основанные на лучших мировых практиках и повышающих вероятность успешного завершения работ по внедрению сетевых сервисов.
По самой своей природе проектные планы во многих случаях являются достаточно негибкими. Они представляют собой запланированную последовательность событий, (могущих происходить либо параллельно, либо последовательно по отношению одно к другому), взаимосвязей между ними и их предшественниками (тоже событиями). И все это «размазано» по всему проектному плану. Хорошим примером типичного проектного плана является организация и разворачивание сети, зависящее от процессов организации тендера, выбора поставщиков, заказа и доставки оборудования. Без решения этих вопросов разворачивание сети невозможно. Но реальность такова, что проект редко продвигается согласно плану. Посему в плане проекта должна быть предусмотрена определенная степень гибкости, предоставляющая возможность маневра и коррекции.
Хороший план проекта начинается с составления перечня всех контактов участников (или групп участников), задействованных в проекте, или имеющих к нему отношение. Типичный проект по внедрению сетевых сервисов, состоящий из работ по инсталляции новых механизмов, или реконфигурации существующих, должен содержать контакты на следующие группы людей:
  • Контакты группы по архитектурным и инженерным решениям
  • Контакты места проведения работ
  • Контакты на группу, обеспечивающую готовность к проведению соответствующих видов работ
  • Контакты на группу обеспечения (в т.ч. ресурсами)
  • Контакты на группы, отвечающие за отдельные участки проведения работ
  • Контакты на группу, отвечающие за интеграцию проектных работ
  • Контакты на группу тестирования
  • Контакты на группу сетевых операций (типа NOC)
  • Контакты на группу, отвечающую за корпоративные коммуникации
  • Контакты на группу по управлению проектом
Каждая из этих групп представляет различные сферы деятельности организации, и информация от всех этих групп необходима для создания общего плана проекта. Согласно лучших мировых практик представители от каждой из этих групп должны принимать активное участие в процессе планирования. Проведение общих собраний этих представителей в одной комнате с определением целей, временных графиков каждого из них позволяет всем группам четко знать свои обязанности и зоны ответственности. После этого следует обсудить и определить взаимодействия групп и ограничения, накладываемые характером этих взаимодействий. Все это позволит группам максимально предусмотреть различные неожиданности, возникающие (или могущие возникнуть) в ходе реализации проекта.
Коммуникация между этими группами важна с точки зрения обеспечения гибкости плана проекта. Если все группы действительно понимают свои роли, обязанности, ограничения и взаимозависимости, то может быть составлен план реакции на непредвиденные обстоятельства, который будет учитывать определенную степень гибкости в возможном перемещении проектных вех (milestones) вверх, или вниз в пределах временного графика проекта. Такая гибкость, основанная на планировании непредвиденных обстоятельств, является критическим компонентом для успешного выполнения проекта.
Прекрасным примером этого может выступать план реакции на непредвиденные обстоятельства в проекте миграции к MPLS WAN. В таком проекте существуют сотни тысяч компонентов и их взаимосвязей, потому планирование всех задач, временных графиков и ресурсов является основной его (проекта) проблемой. В большинстве подобных миграционных проектов обязательно возникают различные непредвиденные задержки, в связи с чем совершенно необходимо предусматривать определенную степень гибкости в планировании графика миграции участков сети. Общепринятый подход к решению данной проблемы состоит в категоризации частей проекта на высокорисковые, среднерисковые и низкорисковые. Низкорисковые части вводятся в план проекта с пониманием того, что эти части имеют большую степень свободы в плане продвижения вверх или вниз в пределах временной оси для обеспечения оптимальности порядка выполнения работ в случае задержек. Это обеспечивает высокий уровень гибкости для проекта и минимизирует риск критичных нарушений графика проекта.
Резюмируя, еще раз повторим, что гибкость проектного плана достигается посредством:
  • надлежащего планирования,
  • высоким уровнем коммуникации между группами
  • и хорошо продуманным планом реакции на непредвиденные обстоятельства.
4 Основные приемы оптимального выполнения плана имплементации сетевых сервисов
Оптимальная имплементация сетевых сервисов начинается с надлежащего общего планирования. Независимо от того, насколько полезными (в финансовом плане) будут новые сетевые сервисы, проблемы в их внедрении могут свести на нет всю их выгоду, посеять сомнения в их выгоде, и, более того, могут даже привести к ощутимым финансовым потерям. Внедрение сетевых сервисов как правило требует инсталляции и конфигурации нового оборудования. Без соответствующего планирования это может представлять собой большую опасность как с точки зрения срывов графика внедрения так и с точки зрения перспективы интеграции. Следует за всякую цену избегать временных задержек и неблагоприятного влияния любых действий на функционирующую сеть.
Планирование процесса внедрения должно сосредотачиваться на следующих областях:
  1. Надежная (robust) архитектура
  2. Стандартизированные конфигурации и детализированный проект
  3. Приобретение и поставка
  4. Готовность участка внедрения
  5. Планирование и снабжение
  6. Управление изменениями
  7. Запуск участка
  8. Тестирование участка
  9. Передача участка в эксплуатацию
Каждая из этих областей подвержена внесению оплошностей и ошибок в общий процесс внедрения проекта, поэтому четкое понимание их ключевых вопросов является крайне важным.

4.1 Надежная архитектура
Надежная (robust) архитектура – это такая архитектура, которая определяет все архитектурные аспекты, включая требуемый функционал, возможности, интеграцию в существующую сеть и наблюдаемость с точки зрения управления. Если новые сетевые сервисы вводятся путем внедрения новой технологии, с которой у организации нет предшествующего опыта работ, крайне рекомендуется, чтобы тестовая лаборатория провела Proof-of-Concept (PoC), или испытать технологию на пилотном проекте еще до развертывания реального проекта.

4.2 Стандартизированные конфигурации и детализированный проект
Если возможно, для элементов сети, предоставляющих сетевые услуги, должны быть созданы шаблоны стандартных конфигураций. Много усилий по инсталляции идут прахом именно из-за несогласованностей в конфигурационных механизмах во время развертывания проекта и трудностей в поиске неисправностей в условиях нестандартного окружения.
Должен быть разработан детализированный проект, который подчеркивает специфические особенности конфигурации для каждого участка внедрения. Это должно быть сделано еще до развертывания проекта так, чтобы определенная для оборудования или определенная для участка информация могла быть привязана непосредственно к деталям проекта, касающихся каждого отдельного участка, включая отображение портов (port mapping), имена интерфейсов, имена хостов, IP-адресация, VLAN-адресация, номерные планы и другие многочисленные параметры конфигурации, специфичные для участка. Во всех случаях наличие детальной информации о специфических деталях, характерных для конфигурации отдельных участков и стандартных шаблонов конфигурации для иных участков сильно сокращает общее количество ошибок во время развертывания проекта.

4.3 Приобретение и поставка
Процесс приобретения и поставки (procurement process) должен предусматривать непредвиденные обстоятельства для всех нижеперечисленных (и подобных им) причин и всех использующихся каналов коммуникации:
  • Невозможность инсталляции по причине неприбытия в срок необходимого оборудования
  • Получение не того оборудования, которое было заказано
  • Оборудование, испорченное в процессе доставки
Это делается для того, чтобы предусмотреть и немедленно учесть все задержки еще до собственно этапа внедрения проекта.

4.4 Готовность участка внедрения
Независимо от того, насколько качественно была определена и разработана архитектура и насколько скрупулезно прописаны детали конфигураций, но если участок сети, на котором должны быть произведены изменения, не готов к работам, то весь проект не способен даже сдвинуться с места. Готовность участка к произведению изменений должна как минимум рассматриваться с точки зрения готовности свободного места, электропитания и требований HVAC (Heating, Ventilating and Air Conditioning, - иногда говорят «климат контроль»), наличие и доступности портов и разграничения всех возможных расширений. Нет ничего более раздражающего, чем невозможность произведения работ только потому, что никто не удосужился банально посмотреть есть ли свободное место в серверной для размеения нового оборудования.

4.5 Планирование и снабжение
Контроль за тем, что правильные ресурсы, установленные в правильное место, в нужное время решают правильные (соответственные) задачи, является необходимым для любого успешного проекта внедрения. Внедрение зависит от ресурсов и в отрыве от них (само по себе) не происходит. Ненадлежащее (плохое) планирование в этой области практически однозачно приводит к неуспеху внедренческого проекта.

4.6 Управление изменениями
Большинство организаций требует наличие хоть какой-нибудь разновидности процесса управления изменениями, чтобы рассмотреть, спланировать и отрапортовать об изменениях в пределах инфраструктурного окружения. Управление изменениями может быть довольно интенсивным процессом и в некоторых случаях ограниченным определенными временными рамками. Однако игнорирование данного процесса может привести к катастрофическим последствиям в деле внедрения общего проекта.

4.7 Предварительный запуск участка
Для предварительного запуска участка требуется, собственно, само наличие ресурсов для инсталляции и конфигурации элементов сети, предоставляющих новые сетевые услуги. Наличие хорошо задокументироанного инсталляционного и конфигурационного скрипта (списка задач) является существенным для управления требуемыми ресурсами через их инсталляцию в предопределенный способ. Обратная связь от различных усовершенствований и нюансов, изученных с помощью предварительного запуска, обеспечивает механизм определения оптимальной последовательности задач.

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

4.9 Передача участка в эксплуатацию
Для передачи модернизированной сети операционным подразделениям должен быть разработан стандартизированный процесс. Это позволяет в течение одного-двух дней собрать (и отреагировать на) замечания не только от группы по внедрению, но и от операционных подразделений, которым и предстоит эксплуатировать сеть дальше. Также в рамках процесса передачи необходимо предусмотреть обучение операционных подразделений основам и навыкам практической работы с внедряемыми технологиями еще до их развертывания.

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