Для чего в основном служат данные мониторинга
Мониторинг и прогнозирование чрезвычайных ситуаций
В общей системе мер противодействия чрезвычайным ситуациям первенство отдается комплексу мероприятий, направленных на снижение риска возникновения чрезвычайных ситуаций и смягчение их последствий. Это можно обеспечить, если будет действовать определенная система наблюдения за состоянием и развитием различных природных, техногенных процессов и явлений а также опережающее предвидение либо определение вероятности возникновения чрезвычайной ситуации природного или техногенного характера.
Такая система, направленная на наблюдение и предвидение, составляет общее понятие «мониторинг и прогнозирование чрезвычайных ситуаций».
Под мониторингом понимается система постоянного наблюдения за явлениями, процессами, происходящими в природе и техносфере, для предвидения нарастающих угроз для человека и среды его обитания.
Общей целью мониторинга опасных явлений и процессов в природе и техносфере является повышение точности и достоверности прогноза чрезвычайных ситуаций на основе объединения интеллектуальных, информационных и технологических возможностей различных ведомств и организаций, занимающихся вопросами мониторинга отдельных видов опасностей.
Данные мониторинга служат основой для прогнозирования. В общем случае прогнозирование — это творческий исследовательский интерес, в результате которого получают данные о будущем состоянии какого-либо объекта явления, процесса.
Прогнозирование чрезвычайных ситуаций — это опережающее отражение вероятности возникновения и развития чрезвычайной ситуации на основе анализа причин ее возникновения, ее источника в прошлом и настоящем.
Прогнозирование включает в себя ряд элементов. Один из них — информация об объекте прогнозирования (природном явлении), раскрывающая его поведение в прошлом и настоящем, а также закономерности этого поведения.
В основе всех методов, способов и методик прогнозирования лежит эвристический или математический подход.
Суть эвристического подхода состоит в оценке мнений специалистов-экспертов. Он находит применение для прогнозирования процессов, формализовать которые нельзя.
Математический подход заключается в использовании имеющихся данных о некоторых характеристиках прогнозируемого объекта, их обработке математическими методами, получении зависимости, связывающей указанные характеристики со временем, и вычислении с помощью найденной зависимости характеристик объекта (техногенного процесса) в данный момент времени.
Прогнозирование в большинстве случаев является основой предупреждения чрезвычайных ситуаций природного и техногенного характера.
В режиме повседневной деятельности прогнозируется вероятность возникновения чрезвычайных ситуаций — факт возникновения чрезвычайного события, его место, время и интенсивность, возможные масштабы и другие характеристики предстоящего происшествия.
При возникновении чрезвычайной ситуации прогнозируется ход развития обстановки, эффективность тех или иных намеченных мер по ликвидации чрезвычайной ситуации, необходимый состав сил и средств. Наиболее важным из всех этих прогнозов является прогноз вероятности возникновения чрезвычайных ситуаций. Его результаты могут быть в основном эффективно использованы для предотвращения чрезвычайных ситуаций (особенно в техногенной сфере, а также для защиты от некоторых природных бедствий), заблаговременного снижения возможных потерь и ущерба, обеспечения готовности к ним, определения оптимальных превентивных мер.
Что такое мониторинг и его уровни
Поговорим о том, какие уровни мониторинга бывают и что стоит измерять и анализировать в IT-проектах.
Зачем нужен мониторинг и что это такое
Случается, что серверы падают и программы ломаются. Это неизбежно. Случайный баг, скачок напряжения в сети, сбои в подаче электричества — всё это может вызывать поломки.
Кроме того, помимо очевидных проблем, могут быть и куда менее очевидные. Например, менеджеры по продукту приняли плохое решение, реализовали плохую фичу и из-за нового релиза упала выручка. Технически код хорошо работает, серверы в порядке — но бизнес несет убытки.
Начнем снизу: мониторинг оборудования
Что бы вы ни запускали — у вас всё равно будут серверы в дата-центре, а у них есть определенные параметры производительности. Эти показатели надо мониторить на каждом сервере, обслуживающем ваших клиентов:
Список параметров вполне очевиден. Мониторинг этих значений позволяет диагностировать большую пачку неприятных ситуаций, которые могут привести к полному или частичному коллапсу инфраструктуры.
Для анализа поведения серверов в самом простом виде можно использовать штатные средства контроля по типу htop. Более гибкое и масштабируемое решение — Zabbix — он уже умеет анализировать основные параметры целого кластера серверов и собирать их в одной панели. Такое решение требует настройки со стороны квалифицированного администратора.
Поднимаемся выше: мониторинг состояния приложений
Допустим, мониторинг серверов у нас есть и они выглядят адекватно. Памяти много, нагрузка на процессор — незначительная. Наверное, всё хорошо организовано, клиентов немного, всё работает как часы? Может быть. Или всё упало, программы не запущены, клиенты не могут попасть на сервер и выполнить запросы? Тоже может быть.
Какой из вариантов правильный — подскажут метрики приложений.
У любого приложения должны быть параметры, по которым разработчики и администраторы понимают, что программа работает и в ней что-то делается. У каждой программы эти параметры свои, но вот несколько примеров, которые позволят понять, какие метрики нужно придумать для приложения:
У вас в системе 100 активных пользователей, они генерируют 1 000 запросов в минуту и у них случается 1 ошибка в час? Допустим, что всё хорошо. У вас в системе 3 активных пользователя, они генерируют 10 000 запросов в минуту и ловят 5 000 ошибок? Наверное, стоит начать беспокоиться. Даже если метрики нагрузки на процессор и диски в порядке.
Для мониторинга на этом уровне подойдет специализированная СУБД — Prometheus, Graphite, InfluxDB. С установкой самой базы данных проблем не будет, а вот посчитать и пробросить нужные метрики в базу — для этого понадобятся усилия программистов.
Для удобства анализа ко всем этим базам лучше всего подключить Grafana — графический инструмент для отображения статистики и метрик.
Есть еще специфические системы отлова ошибок в коде — они могут вовремя оповестить программистов о сбойной ситуации. Иногда этого вполне достаточно для базовой диагностики проблем. Хороший пример такой системы — Sentry.
Третий уровень: мониторинг бизнес-метрик
Конечная цель любой программы — решать чьи-то проблемы и получать за это деньги. Это значит, что для управленцев нужны метрики, которые расскажут:
Список метрик, которые нужны бизнесу, велик и зависит от конкретного проекта и индустрии. Лучше всего вам помогут разобраться с правильными параметрами менеджеры продукта.
Минимально здесь можно обойтись Google Analytics — базовые конверсии и переходы можно смотреть в готовых системах анализа пользовательского поведения. Более глубокое понимание ситуации потребует четкой и слаженной работы администраторов, программистов и ребят из отдела аналитики — они смогут правильно реализовать и посчитать тонкие поведенческие аспекты. Например, зависимость выручки от A/B-тестов на бэкенде.
Зачем нужен комплексный мониторинг ИТ и бизнесу и КАК его внедрять?
На «Хабре» есть статьи о том, как внедрять мониторинг. В них описано, как надо и не надо организовывать систему мониторинга. Все эти статьи мы прочитали и поняли, что чего-то не хватает. Здесь не будет информации о важности разработки ресурсно-сервисной модели и о том, как уменьшить число ложно-позитивных сообщений о проблеме. Мы поделимся лайфхаками в работе команды, которые помогают реализовывать подобные проекты. Дальше будут такие рекомендации, которых в других статьях нет. Советы собраны на основе нашего опыта.
Комплексный мониторинг позволяет компаниям понять, где они теряют деньги
В компаниях всегда есть бизнес-подразделения. Они смотрят, где компания может больше зарабатывать и меньше тратить. Часто они обращают внимание на внутренние ИТ-системы. Если в ИТ-системах возникают инциденты, компания будет терять деньги. Например, рухнула платёжная система. Или регистрация стала сложнее, потому что её модифицировали. Или процесс оплаты неудобен для пользователей – в нем 10 кликов вместо 2.
Чем сложнее архитектура бизнес-приложения, тем больше людей необходимо для ее обслуживания: мониторить системы, анализировать и диагностировать инциденты, вникать, как эти инциденты влияют на клиентов. Итог – потрачены часы на выяснение причин сбоя, кто виноват и что делать. Пока это делается, клиенты страдают, деньги компании тратятся, а время устранения инцидентов растёт. Компании приходится смотреть на шлейф всех этих проблем, а не в светлое будущее. Дальше разберёмся, почему так происходит.
Есть кое-что, что мешает быстро обнаруживать источник проблем. Это разрозненность средств мониторинга. Все вместе они не дают единой картины для всех ИТ-компонентов, которые влияют на работу бизнес-приложения. Бывает так, что задачи похожи или даже одинаковые, но повторно их решают другие люди другими инструментами. Нередко приходится сверять друг с другом показатели одних и тех же метрик.
Что будет, если вот это все заставить работать вместе? О плюсах комплексного мониторинга – далее.
Преимущества комплексного мониторинга
Внедрение единого комплексного мониторинга для бизнес-процессов и ИТ-систем – логичное решение. Вот, что сможет делать компания, которая внедрила комплексный мониторинг:
Оперативно обнаруживать и решать проблемы в работе приложений до того, как они повлияют на пользователей;
Оценивать качество работы приложений на основе объективного мониторинга работы пользователей с приложением, а не обращаться в службу поддержки;
Анализировать клиентский опыт на протяжении всего процесса взаимодействия пользователя с системой;
Оценивать работу подрядчиков. Сравнивать их по количеству пользователей, которые выбирают данную платформу;
Получить единую точку доступа к общей картине состояния ИТ, возможность исследования «вглубь» – до сырых данных, а также анализировать корреляции.
Какие правила при внедрении комплексного мониторинга мы выработали
Совет №1: Выделите отдельную целостную команду разработки системы комплексного мониторинга.
Вот, кто должен быть в команде:
Специалист по Data Science
Бизнес- и системные аналитики должны быть вовлечены в проект на 100% и играть роль Product Owner’а. Они общаются с командой разработки основного продукта компании: от администраторов до руководителей. Бизнес- и системные аналитики пишут требования к системе мониторинга, планируют релизы и проводят UAT. Они обучают конечных пользователей системы мониторинга.
ИТ-роли в команде можно совмещать: разработчик системы мониторинга и инженер данных, администратор и DevOps инженер.
Совет №2: Заведите мониторинг препродуктивной среды. Потом синхронизируйте релизные циклы команды разработки основного продукта и команды разработки системы мониторинга
Бизнес ставит задачу разработчикам оптимизировать процесс взаимодействия пользователей с платформой. Например, процесс регистрации, оформления покупки, оплаты или возврата средств. Это влечет за собой изменение логов и логики построения KPI. Чтобы это сделать, нужно строить синхронные процессы изменения логики бизнес-процессов сайта и их KPI. Это важно, чтобы одним утром после релиза не обнаружить, что мониторинг не работает.
Совет №3: Начинайте с мониторинга простых метрик, релизьте чаще, усложняйте метрики постепенно
Мониторинг не универсален. Он много от чего зависит. Например, от архитектуры систем и взаимодействия между ними, от пользователей мониторинга и их видения.
В проектах разработки и внедрения системы комплексного мониторинга лучше использовать спринты и Agile-подход. Процесс разработки в нашей команде упрощенно выглядит так:
Определяем один показатель или один бизнес-процесс для мониторинга
Делаем небольшие выгрузки данных, достаточные для построения KPI. Чем больше выгрузок, тем лучше. Изучаем данные и определяем минимально достаточные источники для построения KPI.
Реализуем KPI на основе выгрузок и демонстрации пользователя мониторинга.
Дорабатываем источники данных и их подключения.
Разрабатываем KPI на основе живых данных.
Дальше релиз и получение обратной связи.
Потом планируем доработки на основе отзывов. Усложняем KPI путём подключения новых источников. Повторяем цикл.
Совет №4: Не планируйте ресурсные затраты на разработку мониторинга на основе объема систем, покрываемых мониторингом, или по количеству метрик и KPI, запланированных в разработку – вы все равно промахнетесь
Этот пункт вытекает из предыдущего. Наша команда начала разрабатывать мониторинг с зафиксированным объемом и количеством KPI. Сначала мы реализовали несколько дашбордов. Потом перешли на спринты и запланировали только набор бизнес процессов, которые будут мониториться. В результате (а может в процессе) перехода выработался процесс разработки KPI. Тот, что описан выше.
Совет №5: Дайте пользователям системы мониторинга больше свободы
Пускай у пользователей будет возможность исследовать данные, на основе которых вычисляется KPI. Ещё хорошо, если они смогут реализовывать простейшие вычисления и разрабатывать собственные метрики.
Продуктовая команда знает о своем продукте всё. При общении с системными аналитиками они могут упустить некоторые детали в работе или архитектуре систем. Если дать им доступ к изучению сырых данных, вы повышаете интерес конечных пользователей к мониторингу. Может так получиться, что продуктовая команда заметит отклонение показателей. Тогда она начнёт исследовать причины отклонений. Для этого команда сформирует новые метрики – так в будущем обнаруживать подобные проблемы будет проще. Команде мониторинга останется только формализовать метрику и запустить в работу.
Совет №6: Предусмотрите возможность отображения показателей на дашбордах в разрезе разных отрезков времени
Рассмотрим пример: мы разрабатываем бизнес KPI «Процент успешно завершенных регистраций пользователей на сайте». Для разработки KPI необходимо выбрать промежуток времени, в рамках которого мы будем наблюдать за показателем, а также на основе исторических данных определить уровни критичности. Уровень критичности, или важность проблем, определяет какой процент успешно завершенных регистраций считается обычным поведением (обычно обозначается зеленым цветом), или, когда процент успешно завершенных регистраций очень мал, сигнализирует о серьезных проблемах и обозначается красным цветом. В зависимости от промежутка времени, за который мы рассчитываем «Процент успешно завершенных регистраций», уровень критичности может быть разным. Процесс регистрации, как правило состоит из двух основных шагов: заполнение формы на сайте и подтверждение почты путем перехода по ссылке из письма. Некоторые пользователи выполняют регистрацию за пару минут, а другим – требуется вспомнить или восстановить забытый пароль от своей почты, что может занять более 5 минут. Если мы будем вычислять Процент успешных регистраций в рамках 5 минут, то мы «потеряем» пользователей, которые завершат регистрацию за 7-8 минут, что может значительно повлиять на Процент успешных регистраций, и система будет сигнализировать о проблеме.
Поэтому, разрабатывая KPI, мы ориентируемся и выбираем промежуток согласно оценке от бизнес аналитика, но обязательно добавляем другие промежутки времени в интерфейс, чтобы иметь возможность анализировать реальное поведение пользователей.
Совет №7: Настраивайте self-мониторинг, чтобы сохранить доверие к системе мониторинга
Совет №8: Используйте стандартный функционал продвинутой аналитики «из коробки». Например, «Автоматический ML»
Когда мы подключаем новый источник, мы уже знаем, какие поля и значения мы будем использовать. Ещё мы знаем, как будем строить KPI. По возможности, подгружаем в систему мониторинга исторические данные.
Однако, мы всегда прогоняем их через встроенные аналитические инструменты. Полученные показатели и графики оставляем «пожить» в течение какого-то времени и «пережить» инциденты. В половине случаев обнаруживаем новые зависимости от других показателей и интересные аномалии. На основе этого рождаются новые KPI.
Совет №9: Не спешите передавать дашборды и направлять оповещения группе поддержки второй и третьей линии
Есть показатели, разрабатываемые в рамках комплексного мониторинга, а есть – в рамках инфраструктурного. Они сильно различны по своей природе и имеют совершенно разные понятия «нормы» и отклонения от нее.
«Комплексные» KPI строятся на основе корреляции разнородных бизнес и ИТ-показателей. Как правило, этим показателям присваивают веса, которые определяют влияние на «комплексный» KPI. Поэтому сразу определить понятие «нормы» и построить грамотный алертинг бывает очень сложно.
Команда разработки мониторинга должна брать на себя роль поддержки на какое-то время при релизе каждого нового дашборда или KPI. Это позволит получать обратную связь без посредников и дорабатывать «на ходу». Оповещений не должно быть много.
Есть специалист поддержки, который отвечает за решение проблемы или поиск её причин. Действия этого специалиста должны быть максимально понятными и простыми. Написано множество статей про лечение событийной усталости и о том, как грамотно настраивать алертинг.
Совет №10: Ведите историю инцидентов
ИТОГ: Выгоды от внедрения системы мониторинга
Мы собрали их пять. Вот они:
Система комплексного мониторинга является зонтичным решением для существующих систем мониторинга. Она объединяет агрегированные данные из других узкоспециализированных систем.
Комплексное решение закрывает все «слепые зоны», не покрытые существующими в компании системами мониторингами – сбор сырых данных из систем источников в комплексный мониторинг.
Появляется единая точка для анализа данных и расследования причин инцидентов.
Бизнес-аналитики, маркетологи, администраторы и руководители подразделений смотрят на одни и те же данные.
Все события имеют корреляцию по времени.
Ещё раз все наши рекомендации кратко:
Комплексный мониторинг внедряет отдельная команда, а не участники продуктовой команды;
Не упускайте мониторинг препродуктивной среды;
Начинайте с мониторинга простых метрик, релизьте чаще, усложняйте метрики постепенно;
Для внедрения комплексного мониторинга больше подходит Agile методология и отсутствие жестко зафиксированного скоупа;
При планировании закладывайте ресурсы продуктовой команды на доработку и изменение источников данных;
Пользователи системы мониторинга должны иметь возможность «покрутить» данные и метрики;
Дашборды должны иметь фильтры для настройки отображения метрик в разрезе 5 минут и 1 часа;
Разрабатывайте мониторинг для системы мониторинга. Особое внимание стоит уделить точкам взаимодействия системы мониторинга с источниками данных;
Аналитический функционал системы мониторинга, поставляемый «из-коробки», может быть полезен;
Не спешите передавать дашборды и направлять оповещения группе поддержки второй и третьей линии. Пусть команда разработки мониторинга поживет с ними сама, чтобы понаблюдать за количеством оповещений и по возможности сократить их количество;
Ведите историю инцидентов.
Статью подготовил консультант компании Accenture Анастасия Астафьева
Мониторинг и инженерная защита населения от ЧС
Список вопросов теста
Вопрос 1
Чему в общей системе мер противодействия чрезвычайным ситуациям отдается первенство?
Варианты ответов
комплексу мероприятий, направленных на снижение риска возникновения
чрезвычайных ситуаций и смягчение их последствий
Увеличению численности сил и средств МЧС
созданию и совершенствованию средств защиты населения от ЧС
Вопрос 2
Какой из перечисленных терминов подходит под определение: «Опережающее отражение вероятности возникновения и развития чрезвычайной ситуации на основе анализа причин ее возникновения, ее источника в прошлом и настоящем»?
Варианты ответов
Прогнозирование чрезвычайных ситуаций
Статификация чрезвычайных ситуаций
Мониторинг чрезвычайных ситуаций
Статистика чрезвычайных ситуаций
Вопрос 3
Для чего в основном служат данные мониторинга?
Варианты ответов
Для контроля поведения населения
Для выявления опасных мест
Для выявления опасных явлений
Вопрос 4
Где организуется мониторинг для прогнозирования возникновения техногенной ЧС?
Варианты ответов
На конкретном объекте экономики
В едином центре МЧС
В органах местного управления
На космических спутниках.
Вопрос 5
Для чего была развернута территориально распределенная система приема и анализа авиационно-космической информации?
Варианты ответов
Для отслеживания космического мусора, который угрожает Земле
Для оперативного выявления природных и техногенных чрезвычайных ситуаций
Для контроля потенциальных опасносте, геополитических угроз как в атомосфере, так и геологических недрах
Вопрос 6
Чем является строительство и использование защитных сооружений различного назначения?
Варианты ответов
Одним из направлений эффективного уменьшения масштабов чрезвычайных ситуаций
Методом контроля природы, уменьшения опасности появления ЧС
Улучшением обороноспособности страны, уменьшением потерь от авиационных и артиллерийских налетов
Вопрос 7
Что является эффективной мерой по защите населения от чрезвычайных ситуаций?
Варианты ответов
Рациональное размещение объектов экономики и населенных пунктов по территории страны
Уменьшение количества объектов экономики повышенной опасности
Строительство бомбоубежищ на опасных объектах экономики
Вопрос 8
Где должны размещаться объекты экономики?
Варианты ответов
Как можно дальше от жилых зон и друг от друга.
В хорошо охраняемой государством зоне
В местах, где имеются ресурсы природные и человеческие
В зонах с низкой природной и техногенной опасностью
В зонах высокой природной и техногенной опасности
Вопрос 9
Где должны размещаться склады АХОВ?
Варианты ответов
В зонах высокой природной и техногенной опасности
С подветренной стороны по отношению к цехам, в которых работает наибольшее количество производственного персонала
В подземных помещениях, без вентиляции и с плотно прилегающими дверями
Рядом с водоемами для быстрого тушения возгорания
В загородной зоне, за пределами территории объекта
Вопрос 10
Как должны размещаться биологически опасные объекты и их элементы?
Варианты ответов
В загородной зоне, за пределами территории объекта
С учетом розы ветров в данной местности
В гористой местности
Вопрос 11
Что создается вокруг радиационно, химически и биологически опасных объектов?
ДЛЯ ЧЕГО НУЖЕН МОНИТОРИНГ?
ДЛЯ ЧЕГО НУЖЕН МОНИТОРИНГ?
Если с оценкой проекта все более-менее ясно (должны же мы как-то оценить результат своей работы и отчитаться за использованные ресурсы!), то о целесообразности мониторинга и о том, как использовать полученные данные, хочется сказать несколько слов дополнительно.
Казалось бы, почему так много внимания уделяется планированию показателей мониторинга? Просто надо описать, чего и когда надо достигнуть – пиши отчет о достигнутых показателях! Однако в действительности не все так просто.
Главная функция мониторинга – обеспечить выполнение поставленной задачи независимо от событий, происходящих в ходе реализации проекта и изменяющихся факторов. А изменений может произойти множество: изменятся внутренние факторы (например, смена персонала проекта или организации), внешние факторы, в процессе планирования могло быть что-то упущено… Несмотря на возможные «подводные камни», поставленные цели должны быть достигнуты.
Предположим, в ходе реализации проекта последовательно происходят какие- то изменения, которые можно описать с помощью некоторого показателя. Планируемое изменение этого показателя за период работы над проектом показано на Рисунке 20. «Показатели осуществления проекта» в виде графика зеленого цвета.
Однако в ходе работы над проектом реальное изменение показателя может несколько отличаться от планируемого (на рисунке – графики синего и оранжевого цвета). При этом он может сохранять ожидаемую тенденцию (то есть мы ожидали, что показатель будет все время расти приблизительно с такой-то скоростью – в общем, он примерно так и растет, как на графике синего цвета «Реальное (1) изменение показателя»). Но, вопреки ожиданиям, показатель может сильно отклониться от ожидаемого поведения (то есть мы ожидали, что показатель будет расти, а он в какой-то момент начал падать, как на графике оранжевого цвета «Реальное (2) изменение показателя»).
При этом, проводя мониторинг величины показателя в моменты времени, обозначенные как Веха 1, Веха 2, Веха 3, Окончание проекта, мы можем контролировать изменение этой величины. Если поведение не очень сильно отличается от ожидаемого (а что значит сильно – это надо оговорить в момент разработки системы мониторинга на этапе планирования), то мы спокойно работаем дальше. Если же различие между реальным и планируемым показателями становится опасно большим, требуется более подробный анализ ситуации и внесение изменений в стратегию проекта.
Так, в случае повышения температуры пациента медсестра не ждет момента, когда, предположительно, пациента должны выписать из больницы, а незамедлительно докладывает об этом врачу, чтобы не «запустить» ситуацию.
Ведь в момент окончания работы мы можем только констатировать факт, что «проект не удался» – планируемый показатель не достигнут. А в промежуточный момент работы мы можем изменить программу своих действий, адаптировавшись к создавшейся ситуации, и «спасти» проект.
Рисунок 20. Показатели осуществления проекта
Глядя на приведенный рисунок, легко ответить на вопрос «Как часто проводить мониторинг?» Настолько часто, чтобы можно было отследить достаточно серьезные отклонения от плана и успеть на них отреагировать. В частности, по итогам анализа данных оранжевого графика на Вехе 1 было бы разумно предположить, что изменения происходят слишком быстро, и мониторинг нужно проводить чаще. Тогда в промежутке времени, прошедшем между Вехами 2 и 3, мы могли бы среагировать на негативную тенденцию раньше и, возможно, не допустить столь серьезного отклонения от плана по итогам проекта.
Также упомянем о такой важной функции мониторинга, как обеспечение обратной связи с целевой группой, на которую направлена работа по проекту. Ведь без контроля за реакцией целевой группы на производимое вмешательство можно попросту «провалить» проект.
В качестве примера приведем старый анекдот.
Подходит маленький сын к отцу и спрашивает:
– Папа, а почему когда я надкусываю яблоко, оно темнеет?
– Видишь ли, сынок, в яблоке содержится много железа. При соединени с кислородом происходит процесс окисления железа, и при этом оно темнеет…
– Папа, а с кем ты сейчас разговариваешь?
Образовательный проект папы, направленный на собственного сына, очевидно, закончился провалом. Реакция сына является первичной обратной связью от целевой группы. Фактически одним предложением он указывает папе на ошибки планирования – неверную оценку потенциала целевой группы и выбор некорректного и неэффективного способа вмешательства.
Итак, основные функции мониторинга – это внесение корректив, получение обратной связи, облегчение управления проектом и документирование деятельности, как следствие – обеспечение гарантии достижения запланированных результатов независимо от изменений внутренних и внешних факторов в процессе реализации проекта.
Читайте также
Мониторинг рынка
Мониторинг рынка Кроме информации о собственном счете, которая, безусловно, является очень важной, современному интернет-спекулянту необходима не менее важная информация об объекте его работы – о рынке. Причем представление этой информации должно быть удобным для
2.1. Для чего нужен личный финансовый план
2.1. Для чего нужен личный финансовый план Планирование. Некоторым это слово уже набило оскомину: «Сколько книжек ни читал, везде только и пишут: нужен план того, нужен план этого. А я не знаю, нужен мне какой-нибудь план или не нужен. Я и так проживу».Безусловно, есть люди,
1.2.1.4. Мониторинг зданий, сооружений и земельных участков. Мониторинг зданий и сооружений
1.2.1.4. Мониторинг зданий, сооружений и земельных участков. Мониторинг зданий и сооружений Мониторинг зданий и сооружений может проводиться в документарной форме (табл. 1.7), на основе анализа выписок из ЕГРП[17] либо посредством физических проверок (табл. 1.8). Набор
Для чего нужен бюджет?
Для чего нужен ЦСиМИ?
Для чего нужен ЦСиМИ? I.Совершенно очевидно, современное наукоёмкое производство, — помимо прочего требующее огромных капитальных вложений, — которое должно окупить очередные капитальные вложения за два-три года, получить прибыль и быстро произвести новую
Для чего нужен call-центр?
Для чего нужен call-центр? Работа с телефоном важная часть деятельности агента.Но важно понимать, что по телефону недвижимость нельзя продать или купить. Договор с собственником тоже не возможно заключить после звонка.Напомним, что агент в конечном итоге «продает»
Для чего нужен секретарь?
Для чего нужен секретарь? На первый взгляд может показаться, что работа секретаря не требует особых усилий. Сиди себе в приемной, отвечай на звонки, набирай и распечатывай разные документы, готовь для начальника чай. Но обязанности секретаря отнюдь не ограничиваются
3.1.1. Уставной капитал– что это и для чего он нужен
3.1.1. Уставной капитал– что это и для чего он нужен Главное отличие ИП от ООО – в наличии уставного капитала и ответственности по долгам. Фирма в виде ООО – это, по сути, предприятие, в уставной капитал которого один или несколько человек (предпринимателей или юридических
3.2. Для чего вам нужен блог
3.2. Для чего вам нужен блог Итак, зачем же вам вообще нужен блог. Вот список основных функций, которые выполняют блоги, выберете среди них те, которые будут подходить вам и удовлетворять вашим желаниям.1. Блоги – средства коммуникации. Конечно же, именно эта их функция чаще
Для чего нужен бизнес в стиле шоу
Для чего нужен бизнес в стиле шоу Авторы многих книг по маркетингу утверждают, что изменение современного бизнеса обусловлено тремя тенденциями: уменьшением влияния традиционной рекламы, ростом информированности и независимости потребителя, появлением культуры
Шаг 12. Мониторинг и отладка
Шаг 12. Мониторинг и отладка При распространении изменений значительные усилия следует посвятить мониторингу процесса распространения изменений и продвижения к достижению бизнес-результатов.Важно задать показатели для мониторинга продвижения. Вот некоторые
2.4.2.3. Мониторинг субподряда
2.4.2.3. Мониторинг субподряда Необходимо понимать, каким образом осуществляется мониторинг работы субподрядчиков в условиях подписания рамочного контракта или соглашения. Возможны два варианта: либо исполнение контракта субподрядчиками контролирует центральный
Для чего нужен коучинг
Для чего нужен коучинг Для результатов клиентов? У наших клиентов есть результаты. А самим себе не нужно доказывать, что этих результатов можно добиться. У нас сегодня в базе есть порядка четырех тысяч положительных отзывов.Кто-то нас просит взять его в коучинг: «Мне нечем
Урок 57 Лучше владеть 1 процентом чего-либо, чем управлять 100 процентами чего угодно
Урок 57 Лучше владеть 1 процентом чего-либо, чем управлять 100 процентами чего угодно Должен признаться: если бы я писал эту книгу лет десять назад, этот заголовок был бы прямо противоположным, чем-нибудь вроде «ПРЕЖДЕ ЧЕМ приглашать себе кого-то в партнеры, ИЗУЧИТЕ ВСЮ
Мониторинг и оценка
Мониторинг и оценка После начала реализации программы или кампании проведение маркетинговых исследований позволит сравнивать достигнутые результаты с поставленными целями. Когда это исследование проводится в период осуществления кампании, оно обычно называется
Глава 5 Для чего нужен менеджмент
Глава 5 Для чего нужен менеджмент Британская империя, если не полностью, то в значительной степени существовала за счет эксплуатации ресурсов своих колоний. Так, самым лучшим способом получить прибыль от Мумбаи – города в Индии, который до 1995 года назывался Бомбеем, –