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

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

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

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

Майбутня концептуальна архітектура бізнес-моделі телко

Недавно написав своє high-level vision про про майбутнє телко-операторів. І сьогодні знайшов в архівах малюнок, котрий колись передер десь в надрах блогу Telco 2.0 Ініціативи і який гарно ілюструє одну із частин цього мого бачення. Тобто high-level logical сабдж. де пов'язані і операторські активи ("традиційні", та ті дані про користувачів, котрі оператор продавати до цього часу не навчився), і типи продуктів, які оператор потенційно здатен пропонувати ринку. Його і пропоную увазі читачів (див. малюнок внизу).

Моє тезисне бачення майбутнього оператора, чи сервіс-провайдера

Дякуючи нашій переписці з Володею Литовкою мені вдалося піймати та зафіксувати сабдж :). Щиро йому вдячний.
Я прямо кусок з мого останнього листа йому приведу. Може потім стилістично відредагую. Отже,

-----------------
Вот прямо в черновом (пока без стилистических правок, я просто зафиксировать хочу) и очень концентрированном виде (каждый пункт у меня бы целую лекцию занял :)) скидываю мысль, которую удалось поймать и зафиксировать.

Главный мой месидж:

В современном мире (и в перспективе) операторы могут зарабатывать (и, разумеется, кое на чем уже зарабатывают) на:

1. своих "личных" сервисах (о которых все знают. Но абсолютно не хотят понять, что основное бабло лежит далеко не в них):

• базовые "классические": транспорт данных, голоса, видео, Интернет, hosting;
• "продвинутые" расширенные: гарантированные QoS-полосы, Triple Play, другие BI/NGN-прибамбасы;
• "свои" VAS

2. своих уникальных данных о пользователях (еще и кот не валялся. Бо даже не знают как их консолидировать, не говоря о пригодных к продаже форматах)

3. сервисах, созданных совместно с партнерами (начало есть. Даже неплохое. Но, как всегда, не у нас)

4. исключительно нетипичных (бо никто раньше не задумывался, что так можно) партнерских сервисах, направленных на вертикальные рынки (отраслевые). Влезая в них, например, в качестве канала продаж (а я бы даже лучше сказал, что этот класс "нетипичных" продуктов суть функция от предыдущих трех типов)

Основных пять вопросов выживания операторов:

1. Что и как создавать (в первую очередь это должно будет реализоваться операторскими SDP "нового типа" с открытыми API для доступа всех желающих партнеров)
2. Правильное позиционирование (чтобы было интересно для определенных групп конечных потребителей. Некогда будет проводить маркетинговые исследования по каждому планируемому продукту. И дорого. Дешевле и быстрее будет выпустить в месяц 1000 продуктов-миксов, оценить какие из них начнут пользоваться спросом, оставить через 1-2 месяца только 2, остальные 998 нафиг вывести из продаж. Повторять все в цикле :))
3. Методы и каналы продаж (фишка! См. "двусторонние операторские модели продаж" насчет правильного использования и пропорций ритейловых и wholesale-продаж)
4. Модель (система) взаиморасчетов (не просто биллинговая система, даже самая продвинутая и крутая, а целый дилинговый центр!) всех участвующих партнерских сторон, включая конечных пользователей, которые во многих случаях могут/будут рассматриваться как равноправные партнеры
5. Невероятно быстрая реакция на любые рыночные и внутренние изменения

А теперь главная на мой взгляд фишка (требования будущности):
Оператору надо уметь миксить и "держать в голове" все вышесказанное (все 9 пунктов) в необходимых рынку пропорциях!
А следовательно для этого необходимы соответствующие инструменты. Бо "вручную", или с помощью устаревших инструментов и систем, с таким огромным количеством комбинаций не справиться ну никак. Посему нужны новые инструментарии. И они будут. Еще их нет, но будут обязательно, бо много отдельных звеньев и моделей таких систем уже есть.

Интересно, что по отдельности многие пункты современным телко-манагерам понятны. А вот вместе - ну никак. И уж микса всего описанного они совершенно не представляют.

Операторы, которые это уяснят (именно для этого им надо кардинально ломать сознание) - в будущем выживут и будут "на коне". Остальные тупые ахтунги отомрут, и туда им и дорога :)

Анонс цікавої конференції по BSS/OSS системах в Москві

Сабдж.
http://www.exposystems.ru/boss/2008/
Це щорічна конференція. Колись (в 2006-му році) приймав участь в ній. Дуже інформативна та цікава. Якщо хто матиме змогу відвідати - настирливо раджу. Особливо, на мій погляд, корисно прийняти участь в пленарних дискусіях та взагалі поспілкуватися "по кутках". Але і теми докладів з самими докладчиками вкрай цікаві.
А ще уважно читаємо Agenda'у і звертаємо увагу на месиджі :).

KPI для сервіс-провайдерів (update)

Як і обіцяв, приводжу опис ще 17-ти бізнес-метрик.
---------------------------------------

TMF GB935 Up-to-Date (Release 3.0, Ver. 4.2. May 2008)


Содержание

1 Введение
2 Общие бизнес-метрики (G, «General»)
3 Бизнес-метрики по работе с клиентами (CM, «Customer Management»)
4 Бизнес-метрики по предоставлению/активации сервисов клиентам (F, «Fulfillment»)
5 Бизнес-метрики по обеспечению функционирования сервисов, используемых клиентами (A, «Assurance»)
6 Billing бизнес-метрики (B, «Billing»)


1 Введение
В данном документе описываются изменения и дополнения к документу TMF GB935 «Business Benchmarking Metrics Framework» Release 2.0 Ver. 2.2, формирующие следующий релиз данного документа - Release 3.0, Ver. 4.2.
Известно (уже приводилось в этом документе), что KPI, описанные в документе GB935 Release 2.0 Ver. 2.2 распределялись по доменам следующим образом (см. таблицу на рис.1):

Рис. 1. Структура KPI согласно GB935 «Business Benchmarking Metrics Framework» Release 2.0 Ver. 2.2

В следующей версии документа (Release 3.0, Ver. 4.2) рабочей группой Телеменеджмент Форума было добавлено 17 новых KPI, и их распределение по доменах приобрело следующий вид (см. таблицу на рис.2):

Рис. 2. Структура KPI согласно GB935 «Business Benchmarking Metrics Framework» Release 3.0 Ver. 4.2

Сравнивая обе приведенные таблицы видим, что в новом релизе исходного документа TMF GB935 «Business Benchmarking Metrics Framework» добавились следующие KPI:

• Область «Доход и рентабельность» (RM, «Revenue and Margin») – 12 KPI класса «Общие» (G, «General»)
• Область «Уровень обслуживания пользователей» (CE, «Customer Experience») – 1 KPI класса «Обеспечение» (A, «Assurance»)
• Область «Операционная эффективность» (OE, «Operational Efficiency») – 1 KPI класса «Взаимодействие с клиентами» (CM, «Customer Management»), 2 KPI класса «Исполнение» (F, «Fulfillment») и 1 KPI класса «Обеспечение» (A, «Assurance»)

То есть общее количество добавившихся KPI составляет 17. В оставшейся части настоящего документа приведем их описание (подоменно).

2 Общие бизнес-метрики (G, «General»)

G-RM-1b: Показатель средней месячной доходности предлагаемых сервисов из расчета на одного пользователя (иными словами – это хорошо известный показатель ARPU, Average Revenue per User).
Вычисляется по формуле:
«Суммарный месячный доход от всех пользователей / Количество пользователей»
Этот показатель характеризует усредненное количество денег, которые пользователь тратит в месяц на услуги, предлагаемые сервис-провайдером.

G-RM-RA-RLb: Показатель удельного веса дохода от отдельной услуги, поступившего мимо биллинговой системы (как доход, вообще не прошедший через биллинговую систему, так и «неполный» доход, то есть «по разным причинам в кассу поступило меньше, чем было насчитано»), по сравнению ко всему доходу от этой услуги за отчетный период.
Вычисляется по формуле:
«Сумма месячного дохода, расходящегося с данными биллинговой системы / Весь месячный доход (все, что поступило оператору)»
Этот показатель характеризует одно из возможных мест утечки доходов (гибкость и степень формализации как пре-биллинговых и биллинговых процессов, так и возможностей/функционала самой биллинговой системы).

G-RM-RA-RLg: Квартальный показатель (вычисляется на основе данных за 3 месяца), характеризующий [внутреннюю] эффективность услуги.
Вычисляется по формуле:
«(Стоимость неиспользуемых активов / Общая стоимость всех активов) * 100%»
Этот показатель характеризует эффективность механизмов извлечения доходов от отдельной услуги. А именно одно из возможных мест утечки доходов –«напрасно потраченные деньги». «Неиспользуемые активы», упомянутые в формуле расчета, - это активы, которые никаким образом не задействованы (ни прямо, ни косвенно) в формировании этой услуги (неликвиды и просто неиспользуемые ресурсы и/или «элементарные» сервисы). Т.е., «лежащие мертвым грузом».

G-RM-RA-RLh: Квартальный показатель (вычисляется на основе данных за 3 месяца), характеризующий эффективность отдельной услуги.
Вычисляется по формуле:
«(Количество утвержденных расчетных актов 3-х сторон / Общее количество всех утвержденных расчетных актов) * 100%»
Этот показатель характеризует эффективность финансовой дисциплины во взаимоотношениях с третьими сторонами, принимающими участие в формировании отдельной услуги, предоставляемой оператором. А именно - одно из возможных мест утечки доходов – уровень «бардака» в финансовых расчетах с третьими сторонами (например, высокий уровень дебиторской задолженности и т.п.).

G-RM-RA-PEa: Квартальный показатель (вычисляется на основе данных за 3 месяца), характеризующий эффективность отдельной услуги.
Вычисляется по формуле:
«(Доход от услуги, все таки полученный оператором (имеется ввиду ошибки при первоначальных расчетах, или из «безнадежных» денег) / Общий операционный доход от данной услуги) * 100%»
Этот показатель характеризует целеустремленность и напористость действий оператора (без применения специальных механизмов revenue assurance!) в деле работы с первоначальными ошибками в финансовых расчетах, «безнадежными» долгами и проч..

RA-PEa: Месячный показатель, характеризующий эффективность применения специальных механизмов управления и контроля за гарантированием доходов (revenue assurance).
Вычисляется по формуле:
«(Доход, полученный оператором в результате применения специальных механизмов revenue assurance / Общий операционный доход) * 100%»
Здесь доход и в первом и во втором случае считается по всем услугам.

RA-PEc: Месячный показатель, характеризующий эффективность применения специальных механизмов управления и контроля за гарантированием доходов (revenue assurance).
Вычисляется по формуле:
«(Сумма обнаруженных недочетов в доходе, которые еще реально можно вернуть / Общий операционный доход) * 100%»
Здесь недочеты и операционный доход считаются по всем услугам.

RA-PEf: (Внимание! Наименование данного параметра совпадает со следующим параметром! Наверняка это ошибка в оригинальном документе) Месячный показатель, характеризующий эффективность применения специальных механизмов управления и контроля за гарантированием доходов (revenue assurance).
Вычисляется по формуле:
«(Количество восстановленных (в процессе recycling’a) и переданных на вход биллинговой системе xDR / Общее количество xDR) * 100%»
Здесь оба типа xDR считаются по всем услугам.

RA-PEf: (Внимание! Наименование данного параметра совпадает с предыдущим параметром! Наверняка это ошибка в оригинальном документе) Месячный показатель, характеризующий эффективность применения специальных механизмов управления и контроля за гарантированием доходов (revenue assurance).
Вычисляется по формуле:
«((Сумма обнаруженных недочетов в доходе, которые еще реально можно вернуть + Сумма уже оприходованных (поступивших в кассу) недочетов) / Общий операционный доход) * 100%»
Здесь все недочеты и операционный доход считаются по всем услугам.

RA-DQa: Месячный показатель, характеризующий качество (целостность, достоверность, своевременность) любых данных, поступающих на вход специальным механизмам контроля за гарантированием доходов (revenue assurance).
Вычисляется по формуле:
«(Количество проверенных (проконтролированных) записей данных / Общее количество всех записей данных) * 100%»

RA-DQb: Месячный показатель, характеризующий качество (целостность, достоверность, своевременность) данных, согласованных с пользователями и поступающих на вход специальным механизмам контроля за гарантированием доходов (revenue assurance).
Вычисляется по формуле:
«(Количество пользователей, согласных со статистикой их работы / Общее количество всех пользователей) * 100%»
Внимание! Здесь данные могут быть и неточны, но если пользователь с ними согласен (согласен оплачивать счет на их основе) – то и ладно, оператору только лучше :).

RA-RLb: Показатель удельного веса дохода от всех услуг, поступившего мимо биллинговой системы (как доход, вообще не прошедший через биллинговую систему, так и «неполный» доход, то есть «по разным причинам в кассу поступило меньше, чем было насчитано» - например, поторговались и «полюбовно» договорились с пользователем), по сравнению ко всему операционному доходу за месяц.
Вычисляется по формуле:
«Сумма месячного дохода, расходящегося с данными биллинговой системы / Весь месячный операционный доход (все, что поступило оператору)»
Этот показатель характеризует уровень влияния одного из критичных мест утечки доходов (гибкость и степень формализации как пре-биллинговых и биллинговых процессов, так и возможностей/функционала самой биллинговой системы).

3 Бизнес-метрики по работе с клиентами (CM, «Customer Management»)

CM-OE-1b: Показатель удельного веса затрат на клиентскую поддержку конкретной услуги относительно общих операционных затрат на функционирование этой услуги за отчетный период (обычно месяц).
Вычисляется по формуле:
«Затраты на helpdesk по конкретной услуге / Общие операционные затраты на поддержку функционирования этой услуги»
Характеризует (в денежном выражении!) сложность конкретной услуги с точки зрения ее пользователей.

CM-OE-1f: Показатель эффективности затрат на клиентскую поддержку конкретной услуги из расчета на единицу количественного измерения услуги за отчетный период (обычно месяц). Эта метрика вычисляется на основе общей суммы затрат на пользовательскую поддержку конкретной услуги как функция от количества пользовательских транзакций по данной услуге. В роли пользовательских транзакций могут выступать как реальные транзакции (где услуга таки подразумевает их), так и повремянка (стоимость часа работы), стоимость мегабайта информации, месячный flat rate тариф и т.п..

4 Бизнес-метрики по предоставлению/активации сервисов клиентам (F, «Fulfillment»)

F-OE-1f: Показатель средней эффективности затрат на поддержку всего процесса подачи и активации отдельной услуги (от момента регистрации заявки на подачу этой услуги) на одну инсталляцию (за отчетный период. Например, месяц).
Вычисляется по формуле:
«Общие затраты на поддержку всех процессов подачи конкретной услуги / Количество инсталляций этой услуги»

F-OE-3c: Показатель операционной эффективности процессов подачи услуги (fulfillment) за отчетный период. Характеризует степень потенциальных возможностей для экономии, устранения ненужных затрат и т.д.
Вычисляется по формуле:
«(Количество заявок на активацию услуги, по которым требуется переделка выполненных работ / Общее количество заявок на активацию услуги) * 100%»

5 Бизнес-метрики по обеспечению функционирования сервисов, используемых клиентами (A, «Assurance»)

A-CE-2а: Среднее время разрешения инцидентов (за отчетный период)
Измеряется от момента наступления инцидента до момента подтверждения пользователем того факта, что инцидент был успешно разрешен и клиентский сервис возобновил свое нормальное функционирование.
Вычисляется по формуле:
«Общее время, которое потребовалось для разрешения всех решенных инцидентов / Количество решенных инцидентов»
Характеризует «расторопность» соответственных служб сервис-провайдера в разрешении инцидентов, имеющих влияние на предоставляемые пользователям услуги. Как усредненное значение может считаться по разным группам (географическим, клиентским, типам сервисов и проч.). Влияет на лояльность клиентов. Требует внедрения системы регистрации инцидентов.

A-CE-2b: Среднее время разрешения инцидентов, о которых сообщил пользователь (за отчетный период)
Измеряется от момента сообщения пользователем насчет проблемы до момента рапорта пользователю о том, что инцидент был успешно разрешен.
Вычисляется по формуле:
«Общее время разрешения инцидентов, о которых сообщили пользователи / Количество таких инцидентов»
Сильно влияет на лояльность клиентов. Требует внедрения системы регистрации инцидентов.

A-CE-2c: Удельный вес инцидентов, решенных к обещанной дате (за отчетный период).
Вычисляется по формуле:
«(Количество инцидентов, решенных к обещанной дате / Общее количество инцидентов) * 100%»
Сильно влияет на лояльность клиентов. Требует внедрения системы регистрации инцидентов.

A-CE-4c: метрика убрана из новой редакции документа.

A-OE-1f: Показатель усредненной стоимости затрат для устранения одного инцидента. Характеризует эффективность затратной части по организации процессов assurance (за отчетный период).
Вычисляется по формуле:
«Общая сумма затрат на поддержку процессов assurance / Количество устраненных инцидентов»

6 Billing бизнес-метрики (B, «Billing»)

B-CE-4d: Среднее количество исправленных счетов на оплату услуг за отчетный период.
Вычисляется по формуле (пример за квартал):
«(Количество исправленных счетов в 1-м месяце + Количество исправленных счетов в 2-м месяце + Количество исправленных счетов в 3-м месяце) / 3»
Метрика характеризует аккуратность биллинговых счетов с точки зрения пользователей сервис-провайдера. Влияет на лояльность клиентов.

B-OE-1d: метрика убрана из новой редакции документа.

B-OE-1f: Показатель эффективности затрат на обеспечение биллингового процесса за отчетный период.
Вычисляется по формуле:
«Общая стоимость производства счетов на оплату потребленных услуг / Суммарное количество счетов»
Характеризует усредненную себестоимость производства одного счета на оплату услуг.

B-OE-2c: Метрика предоставляет сведения о производительности биллинговой системы и биллинговых процессов. Характеризует среднее количество времени, необходимое для обработки биллинговой системой одного события.
Вычисляется по формуле:
«Общее время доступности первичных биллинговых данных для обработки / Количество событий, которые необходимо пробиллить»
Фактически под «общим временем доступности первичных биллинговых данных для обработки» понимается сумма временных промежутков между наступлением событий и началом обработки соответствующих xDR (точнее, не началом обработки, а возможностью начала обработки - разлочиванием соответственных данных).

Дуже коротко на тему "довгих хвостів" (long tails)

Не знаю як кому, а мені тема long tails дуже цікава.
Але тут дам просто три imho цікаві посилання (знайти при бажанні більше інформації труднощів не складе - welcome to Google).

1. Перше - презентаха Андрія Ярошенка, котра "в загальному" дає поняття про тему (рос.).
2. Друге - початок статті в Harvard Business Review (на жаль за всю статтю треба заплатити бабла) "Чи вигідно інвестувати бізнес-моделі, засновані на "довгих хвостах"?" (англ.). Тут авторка (professor of business administration) говорить про високий рівень ризиків, котрі не дозволяють однозначно заявити, що інвестиції в long tails бізнес-моделі продаж таки вигідні.
3. Третє - обговорення попередньої статті, включаючи участь її авторки (англ.). Не менш цікаве, ніж сама стаття. З солідними аргументами та цікавими точками зору.
   

KPI для сервіс-провайдерів (коротке доповнення)

Оце щойно подивився на відповідні документи ТелеМенеджмент Форуму і побачив, що ніщо не стоїть на місці, все розвивається. Тобто, число рекомендованих KPI вже виросло до 79 (а я в попередньому документі приводив лише 62 - за станом на кінець 2007 року).

Ось як зараз вони розподіляються по доменах (див. мал. внизу).

Коли буде час, то приведу характеристики нових KPI. Але не зараз, бо маю багато інших клопотів.