Измерение и мониторинг — это деятельность по изучению процессов системы менеджмента качества организации, которая образует один из этапов внедрения процессного подхода.
Действия в процессах измерения и мониторинга
Согласно действующим стандартам в области менеджмента качества, организация должна по возможности применять подходящие методы измерения и мониторинга процессов системы менеджмента качества. В результате они должны подтвердить или опровергнуть наличие у данных процессов способности достигать запланированных результатов.
Осуществление измерения и мониторинга процессов системы менеджмента качества приводит к необходимости выполнения следующих действий:
- определить объекты и цели измерения и мониторинга;
- определить систему показателей оценки;
- выбрать методы измерения и мониторинга процессов;
- собрать и проанализировать информацию, которая относится к характеристикам и тенденциям процессов.
Сдай на права пока
Построение мониторинга роботизированных бизнес-процессов
учишься в ВУЗе
Вся теория в удобном приложении. Выбери инструктора и начни заниматься!
В качестве объекта измерения и мониторинга выступают входы, выходы и ход процесса. Рассматриваемые виды деятельности нацелены на то, чтобы подтвердить соответствие входов и выходов процессов установленным требованиям и стабильность их протекания, а также выявить, с одной стороны, возможности оптимизации требований к входам и выходам процесса, с другой стороны, сферы для улучшения самого процесса.
Система показателей оценки формируется исходя из объектов и целей измерения и мониторинга. При этом в данном случае необходимо учитывать затраты на сбор и обработку данных, периодичность проведения измерения и мониторинга, стратегические и тактические цели деятельности организации, возможность интеграции в систему планирования бизнеса. В то же время необходимо обеспечить адекватность, полноту и объективность данных, а также понятность для заинтересованных сторон.
Измерение и мониторинг процессов системы менеджмента направлены на то, чтобы дать им характеристику по следующим параметрам: результативность, эффективность, адаптивность, производительность, длительность, стоимость процесса. По мнению ряда специалистов, при построении системы показателей измерения и мониторинга бизнес-процесса необходимо выделить несколько приоритетных направлений: обслуживание, технология, финансы, персонал, инфраструктура.
«Процессы измерения и мониторинга»
Готовые курсовые работы и рефераты
Решение учебных вопросов в 2 клика
Помощь в написании учебной работы
Методы процессов измерения и мониторинга
Выбор того или иного метода измерения и мониторинга процессов системы менеджмента качества определяется средой их проведения, поставленными целями, выбранными критериями оценки, желаемой формой представления полученных результатов. Наиболее распространенная классификация методов измерения и мониторинга сформирована в зависимости от источника получения информации:
Организация мониторинга бизнес-процессов (с нуля до автоматизации)
- Технологические методы — используются для подтверждения стабильности процесса и поиска направлений улучшения продукции и процесса (диаграммы сродства, разброса, причин и результатов, Парето, процесса осуществления программы, древовидная, матричная, стрелочная, контрольные листок и карта, гистограмма, стратификация, матрица приоритетов, функционально-стоимостной анализ, QFD-анализ, FMEA).
- Социально-психологические методы — используются для оценки степени удовлетворенности поставщиков и потребителей процесса (анкетирование, интервьюирование, опрос).
- Экспертные методы — используются для выявления сильных и слабых сторон процесса, подтверждения его соответствия установленным требованиям, оценки уровня зрелости процесса, поиска областей для улучшения (SWOT-анализ, самооценка по выбранной модели, бенчмаркинг, внутренний и внешний аудиты).
Как правило, перечисленные выше методы и инструменты используются комплексно, в различных комбинациях, что определяется спецификой задач, решаемых в рамках измерения и мониторинга.
Содержание процессов измерения и мониторинга
Как правило, в начале в организации следует мониторинг процессов системы менеджмента качества. Он в основном заключается в наблюдении за ходом процесса, результаты которого подлежат регистрации в соответствующих документированных записях и дальнейшему хранению.
Затем решается вопрос о необходимости измерения процесса или о необходимости таковой. Если измерение требуется, то нужно выбрать алгоритм расчета значений показателей, характеризующих процессы. В соответствии с выбранным алгоритмом подбираются соответствующие данные. На этой основе выполняются непосредственные расчеты, результаты которых также регистрируются, а затем передаются на хранение.
Выход измерения процессов системы менеджмента качества соответствует входу в процесс анализа, т. е. оценки результативности рассматриваемой системы.
Преобразование результатов измерения и мониторинга процессов системы менеджмента качества в конкретные управленческие решения и мероприятия по их оптимизации и совершенствованию считается самым сложным этапом в реализации процессного подхода в деятельности организации. При этом негативно могут сказаться формальный подход к осуществлению указанных процессов, нечеткое определение ответственности, выбор и использование неэффективных методов и инструментов, нехватка ресурсов, субъективный и неточный анализ информации.
Для того чтобы не допустить указанные ошибки, процессы измерения и мониторинга должны активно поддерживаться высшим руководством организации, персонал организации должен быть обучен методам измерения и мониторинга, обязанности и полномочия по выполнению данного вида работ должны быть четко распределены, полученные результаты необходимо широко обсуждать в коллективе и т. д.
Таким образом, составной частью процессного подхода в организации являются процессы измерения и мониторинга, объектами которых являются входы, выходы и ход процессов системы менеджмента качества. Они дают результаты, полезные с точки зрения дальнейшего улучшения данной системы.
Источник: spravochnick.ru
Зачем нужен комплексный мониторинг ИТ и бизнесу и КАК его внедрять?
На «Хабре» есть статьи о том, как внедрять мониторинг. В них описано, как надо и не надо организовывать систему мониторинга. Все эти статьи мы прочитали и поняли, что чего-то не хватает. Здесь не будет информации о важности разработки ресурсно-сервисной модели и о том, как уменьшить число ложно-позитивных сообщений о проблеме.
Мы поделимся лайфаками в работе команды, которые помогают реализовывать подобные проекты. Дальше будут такие рекомендации, которых в других статьях нет. Советы собраны на основе нашего опыта.
Комплексный мониторинг позволяет компаниям понять, где они теряют деньги
В компаниях всегда есть бизнес-подразделения. Они смотрят, где компания может больше зарабатывать и меньше тратить. Часто они обращают внимание на внутренние ИТ-системы. Если в ИТ-системах возникают инциденты, компания будет терять деньги. Например, рухнула платёжная система.
Или регистрация стала сложнее, потому что её модифицировали. Или процесс оплаты неудобен для пользователей – в нем 10 кликов вместо 2.
Чем сложнее архитектура бизнес-приложения, тем больше людей необходимо для ее обслуживания: мониторить системы, анализировать и диагностировать инциденты, вникать, как эти инциденты влияют на клиентов. Итог – потрачены часы на выяснение причин сбоя, кто виноват и что делать. Пока это делается, клиенты страдают, деньги компании тратятся, а время устранения инцидентов растёт. Компании приходится смотреть на шлейф всех этих проблем, а не в светлое будущее. Дальше разберёмся, почему так происходит.
Есть кое-что, что мешает быстро обнаруживать источник проблем. Это разрозненность средств мониторинга. Все вместе они не дают единой картины для всех ИТ-компонентов, которые влияют на работу бизнес-приложения. Бывает так, что задачи похожи или даже одинаковые, но повторно их решают другие люди другими инструментами. Нередко приходится сверять друг с другом показатели одних и тех же метрик.
Что будет, если вот это все заставить работать вместе? О плюсах комплексного мониторинга – далее.
Преимущества комплексного мониторинга
Внедрение единого комплексного мониторинга для бизнес-процессов и ИТ-систем – логичное решение. Вот, что сможет делать компания, которая внедрила комплексный мониторинг:
- Оперативно обнаруживать и решать проблемы в работе приложений до того, как они повлияют на пользователей;
- Оценивать качество работы приложений на основе объективного мониторинга работы пользователей с приложением, а не обращаться в службу поддержки;
- Анализировать клиентский опыт на протяжении всего процесса взаимодействия пользователя с системой;
- Оценивать работу подрядчиков. Сравнивать их по количеству пользователей, которые выбирают данную платформу;
- Получить единую точку доступа к общей картине состояния ИТ, возможность исследования «вглубь» – до сырых данных, а также анализировать корреляции.
Какие правила при внедрении комплексного мониторинга мы выработали
Совет №1: Выделите отдельную целостную команду разработки системы комплексного мониторинга.
Вот, кто должен быть в команде:
- Бизнес-аналитик
- Системные аналитик
- Разработчики
- Администраторы
- Архитектор
- Инженер данных
- Инженер DevOps
- Специалист по Data Science
Бизнес- и системные аналитики должны быть вовлечены в проект на 100% и играть роль Product Owner’а. Они общаются с командой разработки основного продукта компании: от администраторов до руководителей. Бизнес- и системные аналитики пишут требования к системе мониторинга, планируют релизы и проводят UAT. Они обучают конечных пользователей системы мониторинга.
ИТ-роли в команде можно совмещать: разработчик системы мониторинга и инженер данных, администратор и DevOps инженер.
Совет №2: Заведите мониторинг препродуктивной среды. Потом синхронизируйте релизные циклы команды разработки основного продукта и команды разработки системы мониторинга
Бизнес ставит задачу разработчикам оптимизировать процесс взаимодействия пользователей с платформой. Например, процесс регистрации, оформления покупки, оплаты или возврата средств. Это влечет за собой изменение логов и логики построения KPI. Чтобы это сделать, нужно строить синхронные процессы изменения логики бизнес-процессов сайта и их KPI. Это важно, чтобы одним утром после релиза не обнаружить, что мониторинг не работает.
Совет №3: Начинайте с мониторинга простых метрик, релизьте чаще, усложняйте метрики постепенно
Мониторинг не универсален. Он много от чего зависит. Например, от архитектуры систем и взаимодействия между ними, от пользователей мониторинга и их видения.
Начинать мониторинг лучше с планирования простых метрик. Можно и не с простых, а вообще со всех. Ещё можно сразу зацепить планирование KPI, все источники данных, все дашборды и только потом начинать внедрять. В результате всех этих «можно» — передать пользователям готовую систему через несколько месяцев работы. Так можно, но не нужно.
В проектах разработки и внедрения системы комплексного мониторинга лучше использовать спринты и Agile-подход. Процесс разработки в нашей команде упрощенно выглядит так:
- Определяем один показатель или один бизнес-процесс для мониторинга
- Делаем небольшие выгрузки данных, достаточные для построения KPI. Чем больше выгрузок, тем лучше. Изучаем данные и определяем минимально достаточные источники для построения KPI.
- Реализуем KPI на основе выгрузок и демонстрации пользователя мониторинга.
- Дорабатываем источники данных и их подключения.
- Разрабатываем KPI на основе живых данных.
- Дальше релиз и получение обратной связи.
- Потом планируем доработки на основе отзывов. Усложняем KPI путём подключения новых источников. Повторяем цикл.
Совет №4: Не планируйте ресурсные затраты на разработку мониторинга на основе объема систем, покрываемых мониторингом, или по количеству метрик и KPI, запланированных в разработку – вы все равно промахнетесь
Этот пункт вытекает из предыдущего. Наша команда начала разрабатывать мониторинг с зафиксированным объемом и количеством KPI. Сначала мы реализовали несколько дашбордов. Потом перешли на спринты и запланировали только набор бизнес процессов, которые будут мониториться. В результате (а может в процессе) перехода выработался процесс разработки KPI.
Тот, что описан выше.
Совет №5: Дайте пользователям системы мониторинга больше свободы
Пускай у пользователей будет возможность исследовать данные, на основе которых вычисляется KPI. Ещё хорошо, если они смогут реализовывать простейшие вычисления и разрабатывать собственные метрики.
Продуктовая команда знает о своем продукте всё. При общении с системными аналитиками они могут упустить некоторые детали в работе или архитектуре систем. Если дать им доступ к изучению сырых данных, вы повышаете интерес конечных пользователей к мониторингу. Может так получиться, что продуктовая команда заметит отклонение показателей.
Тогда она начнёт исследовать причины отклонений. Для этого команда сформирует новые метрики – так в будущем обнаруживать подобные проблемы будет проще. Команде мониторинга останется только формализовать метрику и запустить в работу.
Совет №6: Предусмотрите возможность отображения показателей на дашбордах в разрезе разных отрезков времени
Рассмотрим пример: мы разрабатываем бизнес KPI «Процент успешно завершенных регистраций пользователей на сайте». Для разработки KPI необходимо выбрать промежуток времени, в рамках которого мы будем наблюдать за показателем, а также на основе исторических данных определить уровни критичности.
Уровень критичности, или важность проблем, определяет какой процент успешно завершенных регистраций считается обычным поведением (обычно обозначается зеленым цветом), или, когда процент успешно завершенных регистраций очень мал, сигнализирует о серьезных проблемах и обозначается красным цветом. В зависимости от промежутка времени, за который мы рассчитываем «Процент успешно завершенных регистраций», уровень критичности может быть разным. Процесс регистрации, как правило состоит из двух основных шагов: заполнение формы на сайте и подтверждение почты путем перехода по ссылке из письма. Некоторые пользователи выполняют регистрацию за пару минут, а другим – требуется вспомнить или восстановить забытый пароль от своей почты, что может занять более 5 минут. Если мы будем вычислять Процент успешных регистраций в рамках 5 минут, то мы «потеряем» пользователей, которые завершат регистрацию за 7-8 минут, что может значительно повлиять на Процент успешных регистраций, и система будет сигнализировать о проблеме.
Поэтому, разрабатывая KPI, мы ориентируемся и выбираем промежуток согласно оценке от бизнес аналитика, но обязательно добавляем другие промежутки времени в интерфейс, чтобы иметь возможность анализировать реальное поведение пользователей.
Совет №7: Настраивайте self-мониторинг, чтобы сохранить доверие к системе мониторинга
Self-мониторинг должен покрыть как можно больше функциональности: все подключения к источникам данных, успешность загрузки данных и выполнения расчетов KPI, доступность самой системы и т.д. Если система мониторинга будет отклоняться от нормального функционирования — скрывайте показатели на дашбордах, на которые это могло повлиять. Сразу после этого вывешивайте предупреждение: «Метрика недоступна. Причина: недоступность источника данных или отсутствие новых данных».
Совет №8: Используйте стандартный функционал продвинутой аналитики «из коробки». Например, «Автоматический ML»
Когда мы подключаем новый источник, мы уже знаем, какие поля и значения мы будем использовать. Ещё мы знаем, как будем строить KPI. По возможности, подгружаем в систему мониторинга исторические данные.
Однако, мы всегда прогоняем их через встроенные аналитические инструменты. Полученные показатели и графики оставляем «пожить» в течение какого-то времени и «пережить» инциденты. В половине случаев обнаруживаем новые зависимости от других показателей и интересные аномалии. На основе этого рождаются новые KPI.
Совет №9: Не спешите передавать дашборды и направлять оповещения группе поддержки второй и третьей линии
Есть показатели, разрабатываемые в рамках комплексного мониторинга, а есть – в рамках инфраструктурного. Они сильно различны по своей природе и имеют совершенно разные понятия «нормы» и отклонения от нее.
«Комплексные» KPI строятся на основе корреляции разнородных бизнес и ИТ-показателей. Как правило, этим показателям присваивают веса, которые определяют влияние на «комплексный» KPI. Поэтому сразу определить понятие «нормы» и построить грамотный алертинг бывает очень сложно.
Команда разработки мониторинга должна брать на себя роль поддержки на какое-то время при релизе каждого нового дашборда или KPI. Это позволит получать обратную связь без посредников и дорабатывать «на ходу». Оповещений не должно быть много.
Есть специалист поддержки, который отвечает за решение проблемы или поиск её причин. Действия этого специалиста должны быть максимально понятными и простыми. Написано множество статей про лечение событийной усталости и о том, как грамотно настраивать алертинг.
Совет №10: Ведите историю инцидентов
Если есть возможность — проводите оценку, как мониторинг уменьшил потери. Посмотрите, насколько быстрее он обнаружил проблему по сравнению с подобными проблемами, которые возникали до внедрения мониторинга или на более ранних его стадиях. Заведите привычку рассылать результаты анализа бизнесу, если они вас сами не попросят.
ИТОГ: Выгоды от внедрения системы мониторинга
Как устроен мониторинг ИТ-инфраструктуры. Практика ITGLOBAL.COM
Чем бы не занималась компания, в современных реалиях ИТ-инфраструктура — важная часть бизнеса. Ведь на ней завязано много критических для компании процессов. Благодаря мониторингу можно узнавать о приближающихся инцидентах до того, как они возникли, оперативно их устранять и не терять деньги на незапланированных простоях. Рассказываем, как организован мониторинг клиентской ИТ-инфраструктуры в ITGLOBAL.COM.
Что такое мониторинг
К мониторингу ITGLOBAL.COM подключены ИТ-инфрастурктура и сервисы более 100 компаний. Мониторинг организован так, чтобы можно было контролировать все до единого процессы в информационных системах. Мониторить можно бесконечное количество параметров, но ITGLOBAL.COM фокусируется на ключевых характеристиках, критичных для конкретного бизнеса. Все сделано не ради отчетов, а ради эффективности и соблюдения SLA.
Мониторинг ITGLOBAL.COM
Компания накопила большой опыт, и для всех ключевых сервисов существуют базовые наборы правил — «модели здоровья». Наши специалисты настраивают мониторинг так, что система посылает только нужные уведомления и только тогда, когда надо. То есть у нас полностью исключена ситуация, при которой генерируются тысячи бессмысленных уведомлений.
На каком программном решении организован мониторинг
Используется надежная и проверенная система с открытым исходным кодом Icinga, форк известного продукта Nagios. Служа поддержки ITGLOBAL.COM выбрала Icinga по многим причинам. Вот основные:
- Это одно из лучших решений для организации системы мониторинга на большом количестве точек.
- У Icinga высокая отказоустойчивость, при условии размещения в нескольких географических точках.
- Решение поддерживает формат баз данных InfluxDB — один из самых удобных вариантов для организации службы мониторинга.
Как устроены «модели здоровья»
Устройство каждой конкретной модели зависит от типа сервиса, который контролируется. Существуют базовые метрики: состояние CPU, RAM, свободного места на дисках, аптайм и сетевая доступность (пинг с разных точек).
Дополнительные метрики зависят от роли сервера. Например, для статичного сайта добавляется уведомление об экспирации доменного имени и сертификатов безопасности. Для веб-сервера — количество порождаемых дочерних процессов. Кроме того, клиент, как правило, сообщает метрики, которые важны именно ему. Таким образом, с каждым новым клиентом, модели здоровья компании постоянно улучшаются.
Какие проблемы способен выявить мониторинг
Он дает около 80% необходимой информации для понимания источника проблемы. При покрытии всех процессов и настроенных моделей здоровья, мониторинг дает полный контроль и возможность увидеть всю «картинку» целиком и далее уже планировать изменения. Вот несколько примеров, что именно учитывает мониторинг ITGLOBAL.COM.
- Работу HTTP, SMTP, NNTP, POP3, NNTP, Ping и других сетевых служб.
- Использование жестких дисков, загрузку процессоров, использование RAM и другую работу ресурсов хоста.
- Работоспособность хостов.
- Работу маршрутизаторов, коммутаторов, датчиков (температуры, влажности и других), серверов и другого оборудования ЦОД.их компонентов в серверных.
Какие параметры мониторинга важны
Базовые метрики сразу выявляют 80% всех проблем. Таким образом можно заранее предотвратить возможные убытки. Кроме того, ITGLOBAL.COM делает фокус на метрики, которые важны для конкретного бизнеса. К примеру, это может быть RPS, количество обрабатываемых запросов в секунду.
Метрика, критичная для ритейла и многих других отраслей — количество транзакций в единицу времени и стабильность потока данных. Ведь каждая транзакция — это прибыль для клиента.
Что происходит после того, как система обнаруживает проблему
Если модель здоровья сгенерировала предупреждение, в системе поддержки автоматически заводится инцидент-тикет. Служба поддержки ITGLOBAL.COM работает круглосуточно и в течение 15 минут реагирует на инцидент.
В первую очередь выясняется степень критичности инцидента и его влияние на работу ИТ-сервиса. В службе поддержки разработаны инструкции, как действовать при самых распространенных проблемах. Если проблема существенная, то к процессу подключаются специалисты второй линии.
Можно ли обойтись без мониторинга
Да, но это будет означать полное отсутствие контроля. Вы будете не предотвращать проблемы, а узнавать о них от клиентов. На вашей репутации и доходах это скажется самым негативным образом. Плюс важно учитывать, что на решение проблем вы будете тратить в 5-10 раз больше времени, чем команда профессиональных специалистов, «вооруженная» мониторингом.
Кому и когда следует обратиться за услугой мониторинга
Мониторинг как услуга освобождает вас от множества трудоемких задач:
- Вам не нужно устанавливать на свою инфраструктуру программное обеспечение и следить за его обновлением.
- Не нужно беспокоиться о полном покрытии мониторингом своих информационных систем.
- Не нужно придумывать и настраивать модели здоровья. Модели здоровья ITGLOBAL.COM успешно протестированы на сотнях клиентов.
- Не надо заниматься оперативной работой — добавлением, удалением, перенастройкой новых узлов инфраструктуры.
При подключении сервиса с клиентом согласовываются модели здоровья и условия получения уведомлений. Например, ИТ-службы могут получать их в круглосуточном режиме, а бизнес-подразделения можно информировать только о критичных случаях. Это сэкономит время и человеческие ресурсы.
Источник: itglobal.com
