В настоящем списке упомянуты только вопросы, ответы на которые нельзя найти в руководствах или интернете. Из множества запросов, поступавших на протяжении нескольких лет, были выделены самые волнующие и на них даны краткие ответы.
1. Как быстро может окупиться система мониторинга?
Система мониторинга направлена на автоматизацию и не имеет своей прямой целью увеличение оборота бизнеса. Автоматизация помогает повысить эффективность и сократить расходы. Бывают сценарии, когда системы мониторинга внедряются для повышения капитализации компании или для следования требованиям регулирующих органов. Но в таких случаях подобные вопросы задаются редко.
Усредненные цифры по отрасли от крупнейших аналитических агентств никак не помогут в подсчете вашей прибыли (экономии). Можно автоматизировать рабочие места пользователей вплоть до постоянного следования новым веяниям, но это может совершенно не сказаться на реальной производительности пользователей с точки зрения бизнеса. Просто у сотрудников куда больше времени будет на перекуры и общение друг с другом. С другой стороны, повышение рентабельности на 7% в среднем с возможным отклонением от -10% до +24% (что, конечно же, умалчивается) не оставляют ни единого шанса для точной оценки возможных последствий проекта именно в Вашем случае.
Для правильной оценки ROI необходимо обратиться по каждой статье расхода (дохода) к существующей у Вас статистики (если таковая имеется, а это отдельный вопрос). В зависимости от типа автоматизации необходимо пройтись по всей таблице статей и оценить, будет ли влиять предлагаемая автоматизация на характеристики статьи. Может у Вас в компании именно такая ситуация, что предлагаемый продукт никак не поможет. Например, регламенты есть, но их никто не соблюдает.
Теория про положительный эффект от повышения производительности и сокращения персонала, так часто фигурирующая в западных методиках вычисления ROI, совершенно неприменима к российским реалиям. У нас не то чтобы переизбыток грамотных специалистов, но и повсеместный «кадровый голод».
Чтобы правильно автоматизировать, необходимо иметь информацию по степени доступности каждого элемента и обращать внимание именно на самые слабые звенья. Что толку предлагать ставить CRM (с технико-экономической позиции) и показывать топ-менеджерам презентации с фантастическими данными по ROI, если администратор БД является безответственным типом и у него постоянно все ломается?
2. А почему так дорого стоит?
Пример типичного заблуждения в стоимости объектов нематериального мира. Несмотря на то, что программный продукт является специфической совокупностью «0» и «1», он позволяет решать конкретные задачи, для которых и был создан. Стоимость продукта имеет 2 аспекта: стоимость с точки зрения производителя и стоимость с точки зрения покупателя. С точки зрения производителя, чем качественнее программный продукт, тем большее количество людей и материальных ресурсов было вовлечено в процесс создания и тем дороже он будет. Архитекторы, программисты, технические писатели, инженеры по качеству, руководители проектов, аналитики, дизайнеры, маркетологи и многие другие специалисты участвовали в создании продукта. Продукт — это не просто код, это код, окруженный большим количеством атрибутов: требования, тесты, руководства, скрипты миграции, библиотеки устройств, шаблоны отчетов. Дополнительно, код воплощает весь накопленный опыт за время существования продукта.
С точки зрения пользователя стоимость продукта определяется теми возможностями, которые становятся доступными при внедрении этого продукта. В одних случаях ПО может повысить эффективность уже существующих процессов, в других же, позволяет сделать качественный скачок и перейти на новый уровень, недоступный ранее. В разных случаях стоимость тех плюсов, которые приносит ПО, может существенно различаться. А как оценить интеллектуальную составляющую ПО? Как оценить стоимость знаний об ошибочных путях и правильных решениях, стоимость опыта, накопленных в продукте во время его эволюционирования и использования другими компаниями? Знание об ошибках конкурентов часто позволяет вовремя скорректировать стратегию и миновать определенные опасности. И чем больше пользователей у продукта, тем меньше удельная стоимость всех нововведений и исправленных ошибок. Таким образом, ПО не является дорогим или дешевым априори, реальная ценность продукта для каждого пользователя будет сильно различаться.
3. А чем решение X лучше решения Y?
Вопрос слишком общий, чтобы на него можно было дать ответ. В целом, можно ответить: «Ничем, все одинаково (полезно или бесполезно)». Правильный ответ можно дать только преломляя возможности систем через призму потребностей Заказчика. А это означает, что четкое и однозначное формулирование требований к системе мониторинга является основой правильного выбора. Однако, при формулировании требований очень важно не совершить иную ошибку, часто совершаемую техническими специалистами: формирование огромного списка сложных технических требований, которые достаточно дороги в реализации, требуют привлечения высококвалифицированных специалистов, но которые, к сожалению, не приносят основному бизнесу ничего кроме расходов. Очень важно найти разумный компромисс между желанием технического перфекционизма и реальными требованиями бизнеса.
4. Необходимо, чтобы решение осуществляло мониторинг приложения X. Ваше умеет?
Когда речь идет о мониторинге приложений, сразу возникает несколько десятков альтернатив. Что значит, осуществлять мониторинг? Следить за лог-файлами? Следить за состоянием процессов? Получать сообщения? Осуществлять проактивный мониторинг с помощью тестовых функций? Проверять выполнение бизнес-логики? Отслеживать утечки памяти? А что понимать под мониторингом распределенных и\или многозвенных приложений? У Microsoft Exchange, например, существуют более 1500 метрик (KPI); какие из этих метрик являются важными именно в Вашей конфигурации Exchange? Или может важным являются агрегатные метрики (KQI)? При этом немаловажно учесть особенности работы человеческого мозга, а именно, возможность одновременного удержания в сфере сознательного 7±2 объектов. С учетом этой особенности, 0 метрик и 100 метрик имеют равнозначно информативную составляющую, а именно, нулевую. Правильным ответом на поставленный вопрос будет анализ бизнес-процессов, выделение функций, выполняемых бизнес-критичными приложениями и формирование рекомендаций по агрегатным метрикам. Только после этого можно переходить к вопросам технической реализации мониторинга этих метрик. Для большинства приложений можно предложить несколько альтернативных технических решений по мониторингу, выбор упирается в соотношение цена\качество, аспекты безопасности, возможность изменения кода в случае ПО самостоятельной разработки и многое другое.
5. Нам необходима гибкая система отчетности. Насколько гибкую систему Вы предлагаете?
Требование о гибкости системы выглядит логичным и правильным. Вдруг по истечении некоторого времени потребуется разработать какой-либо нестандартный отчет? Однако, чем гибче система, тем она сложнее и дороже. Предельным случаем гибкой системы может служить среда разработки, например, Microsoft Visual Studio, Вряд ли этот предельный случай устроит кого-либо. А обслуживание технически сложной системы требует наличия квалифицированных специалистов, что удорожает эксплуатационные расходы. А вдруг при этом потребность в нестандартном отчете так и не возникнет? Окажется, что было выбрано дорогое, технически сложное решение, затратное в обслуживании, но выгоды от этого выбора получить не удалось. Так что, очень важно найти компромисс между гибкостью и реальными потребностями. Перейти от требований «в целом» к конкретным отчетам: проанализировать возможность создания отчетов, уже используемых в организации, какие отчеты потребуются от этой системы, какие есть нормативы на форматы отчетов, в частности от регламентирующих органов, что входит в пакет готовых отчетов, поставляемых вместе с системой, действительно ли необходимы дополнительные отчеты. Дополнительным вариантом может быть выгрузка данных и последующее использование уже существующей в компании системы генерации отчетов для решения задач генерации сложных, кроссдоменных отчетов в устоявшемся формате.
6. Система должна интегрироваться с продуктами X, Y и Z. Перечислите существующие средства интеграции.
Если рисовать высокоуровневую картину «5 прямоугольников и потоки данных», то кажется, что это все очень просто. Конечно же, требование интеграции выглядит очень правильным. Построение единой информационной системы, в которой все модули интегрированы, создана единая система отчетности в разрезах, необходимых каждому подразделению, крайне привлекательно для бизнеса. При этом, на уровне «прямоугольников» опускаются многочисленные технические аспекты, которые впоследствии не позволят эту картину воплотить в жизнь.
Средства интеграции достаточно стандартны: ODBC, CLI, Web-services, SNMP, SMTP. Но их перечисление опять же не даст никакого ответа на реальную возможность интегрировать указанные продукты. Ситуация достаточно проста: если оба продукта, которые необходимо интегрировать, не изменяются с течением времени, то интегрировать можно любым, даже самым трудоемким и неэффективным способом. Главное оттестировать эту интеграцию и устранить ошибки. И будет потом эта интеграция служить верой и правдой долгие годы. К сожалению, в реальном мире все по-другому. Каждый из интегрируемых продуктов живет своей жизнью, меняется код, меняется логика, меняются интерфейсы, меняются технологии. Поэтому, после каждого изменения продукта, входящего в интегрированный комплекс, необходимо проверять корректность работы существующего механизма интеграции. В случае сложных систем и неудачных методов интеграции эта задача может оказаться неподъемной. Таким образом, главным требованием должен быть выбор таких средств интеграции, которые позволят обеспечить максимальную инвариантность механизма интеграции по отношению к изменениям, происходящим в интегрируемых компонентах.
7. Можно систему посмотреть?
Как правило, это требование подразумевает два сценария развития. Посмотреть продукт на демо-стенде или провести триал в своей инфраструктуре. С первым случаем все просто — сценарий удаленной демонстрации отработан, его длительность составляет примерно 2-3 часа, после демонстрации пользователь получает представление обо всех основных возможностях продукта, особенностях работы и интерфейсе. Этого, как правило, вполне достаточно, чтобы позволить провести оценку для применимости системы в своем окружении и принять управленческое решение.
Второй вариант, проведение триала, требует очень тщательной подготовки со стороны пользователей, проработки методики испытаний. При ее отсутствии сложно рассчитывать на объективность оценки результатов триала.
8. Система может хранить все аварийные сообщения в течение года? А двух?
Каждая информация стоит ресурсов, которые, так или иначе, могут быть выражены в денежном эквиваленте. Изначально система регистрации неисправностей, являющаяся основой системы мониторинга, рассчитана на оперативную работу и на быструю реакцию на действия оператора. Любое увеличение данных, которые должны храниться в оперативном доступе, требует соответствующего увеличения аппаратных мощностей. Но действительно ли существуют такие объективные требования к хранениям «сырых» (raw) данных? Чем может помочь отдельное аварийное сообщение 6-ти месячной давности? А годовой? Ресурсов для изучения и анализа этого непрерывно увеличивающегося количества информации, как правило, нет и не предвидится. Ляжет это все мертвым грузом, ежедневно потребляя ресурсы на свое обслуживание. При таких сроках давности имеет смысл анализировать тенденции, периодические колебания, средние значения и статистику по сбоям. Архитектурно, это уже прерогатива систем аналитической отчетности, а не систем мониторинга. Поэтому оптимальным вариантом является разделение задач между различными системами, а не обрушение всего потока требований на одну систему.
9. Почему так мало вопросов?
В силу того, что CA Spectrum является успешным коммерческим продуктом с 15-ти летней историей, за кадром остались вопросы такие, как управление правами пользователей, самодиагностика, масштабирование, надежность, список заказчиков, и многие другие. Они не упоминаются вследствие того, что на каждый этот вопрос идет прямая цитата из документации.
Комментариев нет:
Отправить комментарий