OSS-BSS Внутренний и Внешнй голос Бизнес-системы (мастер-класс)

Как строим ? (Know How)
Зачем строим ? (Know Why)
Во что верим ? «Здравый смысл». Не заиграться в методологию и стандарты.
Где остановиться в детализации?
Целостная картинка. Детализация отдаляет от понимания.
К той ли стене приставлена пожарная лестница ?
Ценности и цели важнее, чем методы и парадигмы.
Know Why – держим фокус на человеке, а не на ИТ системе!

Базовые принципы
Базовые принципы
О сервисах
Парадигма OSS-BSS
Мониторинг
Ресурсы
Пример процесса - Управление ошибками

Система субъективна
Система – это то, что мы держим в фокусе внимания в данный момент.
Нет субъекта, нет системы.
Принципы – объективные законы.
Правила – субъективные законы.
Суждения, проводящие границу между системой и внешним миром.
Нет правил – нет системы.

Каким мы видим мир ?
Невозможно создать одну правильную модель.
Первый шаг к системе – фокусировка на вопросах:
Мое субъективное отношение к системе?
Из чего состоит система?
Как она работает?

*
От материального – в тонкий мир информации
Модель «матрешка» и модель «7 чакр» – это об одном и том же.
Нематериальное и информация – это об одном и том же.
Контраст имеет значение – «проявленное»-»непроявленное».

*
Нравственный баланс
Можно ли быть одновременно богатым и счастливым ???
Если все будут богатыми и счастливыми, где будет центр квадранта ???
По отношению к кому ???

*
Любой процесс –
бесконечно вложенный цикл

*
Любой процесс – 2-х фазный цикл
Модель
6x4
Каким бы электронным ни был бизнес, в центре находится человек…

*
Пример – проектный цикл

*
Понижая энтропию,
наводим порядок
В общем случае, система может находиться всего в 3-х возможных состояниях:
созидание – движение от хаоса к порядку, от целей к будущим событиям;
сохранение – поддержание существующего порядка вещей;
разрушение - движение от порядка к хаосу, от внешних событий к будущим целям.

*
Есть всего лишь 5 базовых процессов…

*
Любой процесс –
воронка важности событий
Срочность - Лежит в области инстинкта, операций и времени реакции на произошедшие события
Является свойством стандартного процесса или инцидента
Важность - Лежит в области интуиции, развития и проактивного свободного выбора. Является свойством цели, изменения, проблемы

О сервисах
Базовые принципы
О сервисах
Парадигма OSS-BSS
Мониторинг
Ресурсы
Пример процесса - Управление ошибками

*
Сервис – деятельность, приносящая Value
Сервис – законченное элементарное действие в интересах заинтересованных лиц (клиентов/программных компонентов/других сервисов), выполняемое в соответствии с контрактом, определяющим критерии соответствия результата ожиданиям.
Все усвоили слово «Ценность»,
но забывают слово «Деятельность»

*
Снежный ком понимания смысла сервиса

*
Продукт-сервис

*
Примеры сервисов и продуктов

*
Два взгляда на деятельность
Взгляд со стороны клиента
Фокус – цель потребителя
Участник – игрок в команде
Ключевая диаграмма - Use Cases
Путь – соответствие степени зрелости
Проблема – угадать последовательность
Взгляд со стороны строителя
Фокус – сквозной перечень шагов
Участник – «укладчик кирпичей»
Ключевая диаграммы - IDEF…
Путь - реинжиниринг
Проблема – адаптация к изменениям

текст0 + лого
*
Типовые ошибки
строительства процессов в ИТ
Фокус на внутреннем клиенте
Инкапсуляция процедур в процессы
Вера в «разовое» строительство
Непонимание ролевого механизма

*
Дерево должно расти
Проявление сервисов-рецепт построения процессов
1. Выделить в крупную клетку «известные функции»
и назначить персональные зоны ответственности
2. Сверить дерево функций с картой (Best Practice)
3. Выделить точки контакта с внешним клиентом и ключевые приоритетные функции, требующие объединения в цепочки.
4. Для каждой ключевой функции:
Проверить признаки сервиса…;
Согласовать между участниками сценарии процедуры;
Оркестровать процедуру с другими процедурами и ИТ архитектурой;
Провести пилотное внедрение процедуры;
Стартовать Rollout процедуры;
Договориться о KPI и SLA.
5. На основании полученного опыта:
предложить пути улучшения смежных сервисов,
пополнить ролевую матрицу,
перерисовать сквозной процесс.
1. Снова уточнить список выявленных в крупную клетку известных «функций» и ответственных.
Делать так в цикле, пока процессы не созреют…

Парадигма OSS-BSS
Базовые принципы
О сервисах
Парадигма OSS-BSS
Мониторинг
Ресурсы
Пример процесса - Управление ошибками

*
Парадигма BSS-OSS
(стюардессы и пилоты)
Парадигма BSS-OSS не зависит от предметной области.
Это взгляд на архитектуру любого бизнеса.
Статический взгляд требует процессного понимания
Почему же закрыта дверь ?
Фокус –
пассажир доволен !
Фокус –
Полет нормальный !

*
Две наиболее удачные модели
Цикл качества PDCA
Парадигма BSS/OSS
Фокус на процессах
Фокус на функциях и архитектуре
Попробуем совместить эти два взгляда в один

*
Разворачиваем в привычный Workflow
(5 ключевых процессов)

*
Растягиваем к полюсам BSS/OSS
Кто перетянет
на себя
дверь ?

*
Процессная граница между BSS и OSS
Fulfilment цельный!
Разделение и особенности возникают в мониторинге и управлении изменениями,
Где встречаются 2 потока информации.

*
Воронки событий

*
Направление автоматизации процессов –
«эффект застегивания молнии»
От организации бизнеса к единому управлению изменениями
От встречного движения BSS-OSS к сквозному процессу

Мониторинг
Базовые принципы
О сервисах
Парадигма OSS-BSS
Мониторинг
Ресурсы
Пример процесса - Управление ошибками

*
Мониторинг – наблюдение и оценка
Metric (KPI,KQI…) – measured or calculated parameter of monitored object
Threshold – value crossing which leads change of metric status (green/yellow/red).

Отчеты по техническим показателям качества
Сравнение технических показателей качества
Технический аудит сети
Отчеты по качеству продуктов
Сравнение показателей качества продуктов
Мониторинг уровня жалоб и SLA
Проактивное оповещение клиентов
Решение проблем клиентов
Мониторинг KPI & аварий
Устранение проблем в инфраструктуре
Мониторинг
(Функции и системы)
Мониторинг On-Line
Мониторинг Off-Line
Customer Care
Marketing & Sales
IT
Quality Dep.

Пассивный и активный мониторинг

*
Зонтичный мониторинг

*
OSS&BSS – внутренний и внешний голоса бизнес-системы

Ресурсы
Базовые принципы
О сервисах
Парадигма OSS-BSS
Мониторинг
Ресурсы
Пример процесса - Управление ошибками

*
Что ? Где ? В результате чего ?
Зачем ?
Многие путают эти понятия
Многие не могут ответить на вопросы:
Зачем им нужна информация Inventory ?
Зачем им нужна детальная информация Inventory ?

*
Ресурсы глазами разных участников
Хорошо бы иметь сквозной список ресурсов…
Типы объектов – это линейный список
Классификаторы – это иерархичные справочники
Может существовать несколько кодировок и классификаций

*
Плохая новость – единый взгляд невозможен
Не существует:
единого взгляда на детализацию ресурса
единого кода ресурса
единой системы учета ресурсов

*
Что же делать ? – Договориться об уровне детализации.
Федеративная Inventory.
Общий уровень содержит информацию, достаточную для назначения инцидентов и проведения Impact analisys
Детальные данные могут быть извлечены из систем с более подробным уровнем детализации

Как 12 музыкантов превратить
в группу U2 ?
*

Пример процесса - Управление ошибками
Базовые принципы
О сервисах
Парадигма OSS-BSS
Мониторинг
Ресурсы
Пример процесса - Управление ошибками

*
Местоположение Trouble Ticketing
Требуют согласования
2 потока инцидентов:
от клиента
от технич. мониторинга

*
Главный приоритет – прибыль ?
Как измерить потери On-Line ?
Единый приоритет – это требуемое время восстановления сервиса глазами руководства, но в интерпретации взглядов со стороны клиента и технического мониторинга.
Это то, как должно быть.
Хорошая новость: TT – самый изученный процесс.
Мы знаем как бежать.
Плохая новость: методологии не отвечают на вопрос «Почему TT имеет высокий или низкий приоритет»

*
Как клиенты и технический мониторинг
влияют на интерпретацию приоритета
Шкала должна быть единой, даже если интерпретация не совпадает с денежным эквивалентом возможных потерь

*
Разрыв между желаемым и действительным
Отношение к приоритету изменять нельзя, можно изменить отношение к результату
(исполнитель может сделать только то, что позволяют возможности / ресурсы)

*
Пока вы не договорились, единого приоритета нет.
Единая шкала - способ оценки качества процесса, а не качества людей.
Единая шкала – лишь способ зафиксировать общие ценности
Единый приоритет – цель корпорации, время реакции – возможности людей.
Нельзя манипулировать приоритетом. Надо договориться о времени реакции.
Нельзя манипулировать временем. Надо правильно интерпретировать отчеты.
SLA должен быть разным и зависеть от возможностей,
иначе, люди начинают «бороться с KPI», забывая о ценностях
Вопросы, требующие решения:
Клиент : Все ли клиенты одинаково важны ?
Сотрудник : Все ли согласны со шкалой приоритетов ?
: Добавить ресурс или ослабить SLA ?
Поставщик : Мой 3-й приоритет для тебя является 1-м !
Резюме 1: Приоритет субъективен

*
Резюме 1: Строим «многополярный IT», адаптированный к бизнесу
Методология – лишь способ сверить часы
Главный фокус ИТ - «внешний клиент»
Итеративно проявляем процедуры, Процессы должны созревать.
Вовремя останавливаемся в детализации

*
Резюме 2: Руководствуемся здравым смыслом
Акцент на ключевых сервисах, ключевых объектах, ключевых KPI и единых приоритетах.
Есть всего 5 процессов Inventory, Fulfilment, Fault, Performance, Change
Сквозной процесс можно построить быстрее, сконцентрировав внимание на 5 узловых направлениях:
Единый Ordering
Единый Trouble Ticketing
Единый Service Quality Mgt.
Единый Release Mgt.
Federated Inventory
Know Why (ценности и цели) важнее,
чем Know How (методы и парадигмы).