Есть две прекрасно работающие модели:
- Цикл качества PDCA (Plan-Do-Check-Act), который применятся в IT-процессах;
- И модель BSS/OSS, которая используется для управления процессами телекома.
За последние несколько лет IT и телекоммуникации настолько слились, что различия в методологиях становится тормозом при реализации реальных технических проектов. Возможно ли совместить взгляды ИТ и технических специалистов в один? Мой ответ – да!
Попытки совместить эти два взгляда до сих пор сводятся к простому отображению одних понятий в другие, что не приближает к пониманию, а лишь подтверждает, что обе методологии по-разному описывают по сути одну и ту же деятельность. Возникает большое желание совместить эти два взгляда в один, уйдя от ярлыков «подход ИТ» и «подход телекоммуникаций» и фокусировавшись на сути. Суть же проста – предоставление сервисов.
Мы всё время находимся между двумя полюсами: определённостью и неопределённостью, развитием и операционной деятельностью. Пробегая PDCA, мы получаем опыт, расширяем свои знания и возможности. Но при этом цикл не даёт ответа на вопрос, где именно лежит граница между развитием и операционной деятельностью. Это важно, поскольку управление развитием и типовыми операциями сильно отличаются. Вторая проблема PDCA – это отсутствие фокуса на клиенте. Каждый раз мы смотрим в этом процессе на проблему изнутри компании: нам важны отлаженные процессы, эффективная инфраструктура, выполняемые показатели SLA. Но клиент при этом всё равно может оставаться недовольным.
Но прежде чем переходить ко второй модели, давайте посмотрим внимательнее на область Check. Она может быть разделена на две важных части:
- Операционную – «выявление ошибок» (багов) и работу по ним с целью быстрого восстановления качества предоставляемых услуг.
- Развитие – «выявление состояния системы» (проблемы), c целью проанализировать данные о работе системы и предложить решения проблем, предотвратить ошибки и найти способы улучшения системы в целом.
В области планирования деятельности ситуация аналогичная. Мы можем планировать укладку стены после инцидента разрушения части стены (работа по устранению ошибок) или проект строительства великой стены (развитие системы)? Должен ли
укладчик кирпичей, которому выписан наряд на работы, задумываться об этом? И какой квалификацией и уровнем сознания должен обладать такой человек?
Таким образом, и область Plan может быть разделена на две подобласти:
- Операционную – «управление ордерами на типовые работы» (ordering);
- Развитие – «планирование изменений» (change).
Вот что у нас получается с циклом PDCA:
Обратите внимание на переходы от Check к Plan минуя этап Act, который оказывается не нужен, если речь идет о стандартных ошибках и стандартной реакции на неё.
Это даёт однозначные ответы на несколько частых вопросов:
— Можно ли не регистрировать инцидент?
Да, если ошибку обнаружила система мониторинга, ошибка незначительна, ее можно исправить автоматически или минимальными действиями (переход 1 на рисунке выше). Событие регистрируется на более низком уровне воронки событий – в журнале мониторинга, но до регистрации инцидента дело не доходит.
— Можно ли выполнять работы на инфраструктуре без согласования RfC?
Да, если это делает сама система мониторинга/управления инфраструктурой или если работа является типовой, стандартной (переходы 1 и 2 на рисунке). Необходимо лишь понимать влияние работы на прерывание сервиса и согласовать при необходимости временные окна этого прерывания. Изменение же всегда уникально, поэтому стандартных RfC не существует!
— Требуется ли классическое управление релизом для выполнения типовых работ или внедрения средств мониторинга?
Нет. Более эффективно работают упрощенные формы управления (переход 2 на рисунке).
Автоуправление
Переход 1 показывает как работает автоуправение. При отклонении в системе логика автоматики или типовые инструкции людей позволяют быстро устранить проблему в короткий срок. Это похоже на опрос прерываний и действия по ним. Например, автоуправление – это автопилот самолёта. Или открытие клапана парового котла, если давление доходит до критической точки. При этом человек, открывающий клапан, может и не иметь квалификации достаточной для понимания своих действий. Стрелка в красной зоне – выполнил инструкцию.
Мониторинг ошибок и планирование типовых работ
Это переход 2. Если возникают ошибки, которые система не может откорректировать сама, вы подключаете более квалифицированных людей. Люди из центра мониторинга достаточно быстро устраняют проблему, используя свой стандартный сценарий. Например, если пилот самолёта видит, что автопилот отказал – он берёт ручное управление.
Мониторинг состояния системы и планирование изменений
На переходе 3 идёт более медленный анализ, не имеющий типовых инструкций. Анализируются ошибки с невыясненной причиной, ситуация в целом и так далее. Основной показатель – качество анализа и качество варианта решения. Важно, что третий уровень не должен отнимать слишком много ресурсов – поэтому решение принимается в шаге Act в модели, то есть данные о состоянии системы передаются дальше. При этом при среднем влиянии на бизнес требуется компромисс между скоростью принятия решения и качеством анализа, а при сильном влиянии на бизнес – качество анализа, позволяющее принять оптимальное управленческое решение.
На области Act мы переходим из пассивного наблюдения за системой к активному её изменению. При этом мониторинг может выводить нас за Act для изменения системы с целью рутинной коррекции ошибки (операционная деятельность), либо для развития (существенного творческого – то есть нетипового изменения). При этом чем больше нетиповых опорных данных использовалось при переходе через Act – тем важнее будет решение, и тем точнее должна быть корреляция событий. Разделение между мониторингом и планированием позволяет представить BSS/OSS вот так:
Теперь посмотрим снова на PDCA
Есть две проблемы применения чисто этой модели:
- Процессы работы с клиентами и работы с инфраструктурой совмещены.
- Точка принятия решений находится вверху, а не в центре (как подсказывает здравый смысл).
Но у нас ведь уже есть BSS/OSS, расписанная по PDCA. Теперь мы просто объединяем эти две модели.
Объединение моделей
Процессов теперь ровно по два для каждого полюса. Почему? Здесь можно привести аналогию из области строительства. Мы привыкли рассуждать, что абсолютно весь бизнес управляется клиентским спросом. Тогда при строительстве дома логично было бы сперва найти на рынке первого клиента, согласного купить квартиру, заключить с ним сделку и построить ему угловую квартиру на первом этаже будущего дома. Так, клиент за клиентом, довести этажность дома до многоэтажки. Только ведь только никто так не делает. Строительство дома, и продажа квартир движутся параллельно, взаимозависимы и неотделимы друг от друга.
Прямой вывод, следующий из этой модели – важность соблюдения баланса между бизнесом и инфраструктурой, между проектами и мониторингом состояния. Вот та же модель от операций к развитию:
Workflow в такой модели – это два встречных потока событий, порождаемых клиентами и инфраструктурой. Модель клиентоориентирована, и ее содержание сильно зависит от вида клиента, с которым взаимодействует система. Такую модель лучше строить отдельно для клиента, поставщика, внутреннего сотрудника и т.д.
Вот пример:
Ключевые выводы
- Де-факто границы между ИТ и телекоммуникациями уже не существует.
- Фокус ИТ — клиент компании. Внутренние сотрудники – лишь частный случай клиентов.
- BSS/OSS – мощный инструмент, который пора использовать в управлении любыми сервисами. Полученные выше «Сервисные оси координат» позволяют держать в фокусе одновременно процессный и архитектурный взгляды на клиента, а также видеть проблемы, возникающие на стыках доменов.4. Сам внутренние процессы компании должны быть сбалансированы по вертикали – между клиентами и инфраструктурой, и по горизонтали – между мониторингом и проектами. Перекосы приводят к проблемам. Полученная модель открыто заявляет бизнесу: нельзя ударяться в чисто проектную деятельность, равно как нельзя останавливаться, просто поддерживая достигнутый уровень качества. Нельзя упирать на заключение контрактов с клиентами, не подкрепив их инфраструктурными возможностями.
- Должен быть баланс по обеим осям. Какой баланс – это зависит от текущих целей бизнеса. В двух крайних случаях это застывание и постепенный рост в имеющейся архитектуре, либо скачок к инновациям и трансформации архитектуры.
- Все функциональные и системные элементы архитектуры организации могут быть уложены в полученных семи слоях. Если где-то возникает пустота, это намек, что либо вы забыли что-то автоматизировать, либо ваш бизнес действительно несбалансирован. В качестве примера приведу домен Customer Experienсe. Он абсолютно симметричен домену Technical Performance, а следовательно, при его строительстве возникают совершенно прогнозируемые заранее информационные потоки.
Автор: AntonSavvin
