Cтруктурный подход в оценке приложения
Одно из наиболее важных решений, принимаемых отделом ИТ, связано с выбором максимально эффективного приложения для решения конкретной задачи, стоящей перед организацией. В большинстве случаев подходящий продукт можно выбрать из представленных на рынке коммерческих прикладных программ. Если только бизнес-задача не является новой или специфической, для ее решения подойдут многие существующие приложения. Какой же вариант выбрать? От правильного ответа на этот вопрос может зависеть успех или неудача в карьере специалиста по ИТ. Если учесть стоимость приобретения приложения и затраты на его настройку и развертывание, правильный вариант ответа может оказаться единственным.
Ровняем игровую площадку
Процесс выбора нового приложения взамен действующей программы или для развертывания в качестве нового программного обеспечения почти всегда протекает в духе напряженной дискуссии. Бизнес-подразделения, деятельность которых зависит от функционирования данного приложения, так же заинтересованы в оптимальном выборе, как и отдел ИТ. Обе группы в процессе принятия решения должны тесно сотрудничать. По сравнению с использованием специальных методов оценки, анализ всех приложений на основе единых стандартов более эффективен, так как позволяет специалистам, принимающим решения по коммерческим и техническим вопросам, сравнивать варианты на более реалистичной основе. Использование единых стандартов в оценке также позволяет объяснить руководству, почему выбранное в результате сравнения приложение является оптимальным. Используемые стандарты должны заключать в себе как минимум перечисленные ниже 10 категорий.
Стоимость. Увы, стоимость часто оказывается самым трудным аспектом в оценке приложения, так как цифра, указанная на ценнике, нередко является лишь вершиной айсберга затрат. Помимо авансовой цены приложения, реальная его стоимость в расчете на одно рабочее место складывается из таких статей, как стоимость лицензии на одного пользователя, затраты на модернизацию, скидки при оптовом приобретении, годовые выплаты, предполагаемая стоимость поддержки, оплата заказной настройки, а также затраты на обучение персонала и развертывание. В ходе оценки необходимо учитывать как можно больше таких оцениваемых единиц, чтобы получить реальное представление о полной стоимости владения приложением в расчете на одно рабочее место. Часто бывает, что приложение, предлагаемое по минимальной авансовой цене, обходится значительно дороже с точки зрения полной стоимости владения, чем приложения, на которые установлена более высокая цена.
Требования бизнеса. Чтобы определить, насколько данное приложение соответствует основным требованиям бизнеса, надо предложить подразделениям, которые будут работать с этой программой, построить схему процесса их деловой активности с указанием предполагаемого режима применения приложения. Поскольку в описании процесса деловой активности легко упустить отдельные этапы, визуальное представление, например в виде блок-схемы, позволяет быстро проверить точность описания последовательности выполняемых действий. Необходимо зафиксировать эти общие сценарии и попросить представителей подразделений указать желаемые функциональные возможности нового приложения на основе знания деловой сферы. Затем следует соотнести эту информацию с возможностями оцениваемого приложения.
Обязательства производителя. Никто не станет приобретать и развертывать продукт, для которого в ближайшем будущем планируется прекращение выпуска или радикальное изменение. Также никто не захочет приобретать продукт компании, которая может уйти из бизнеса через три года. Важно знать, какие обязательства берет на себя производитель в отношении данного продукта. Не менее важно выяснить, планируется ли выпуск следующих версий или обновлений приложения. Если да, то каков график выпуска? Предусматривает ли производитель порядок прекращения поддержки, если в будущем это приложение не будет выпускаться? Что можно сказать о прочности финансового положения производителя?
Архитектура. Разобравшись в архитектуре рассматриваемых приложений, вы сможете лучше оценить характер их взаимодействия с имеющейся сетью и приложениями и будете готовы к потенциальным проблемам, связанным с безопасностью и надежностью. Важно знать, как работает приложение и какова глубина его интеграции с действующей платформой в отношении средств обеспечения безопасности, надежности и зависимости от других служб. Изучите критерии проектирования архитектуры применительно к общим сценариям, таким как географическая удаленность пользователей. Оцените возможности масштабирования приложения. Узнайте, использует ли приложение стандартные протоколы. Наконец, необходимо выяснить, обеспечивает ли приложение соответствие юридическим требованиям, принятым в организации.
Способность к взаимодействию. Стоимость приложения может существенно возрасти, если оно не способно напрямую либо с минимальной настройкой взаимодействовать с имеющейся или предполагаемой платформой либо с другими приложениями. Кроме того, плохо взаимодействующие приложения в большей степени подвержены негативному воздействию изменений в используемой платформе или приложениях. Следует выяснить, насколько хорошо данное приложение будет функционировать на платформе, используемой в организации, либо на платформе, на которую предполагается перейти. Необходимо оценить способность приложения напрямую взаимодействовать с другими приложениями, применяемыми в организации, и узнать, какое промежуточное программное обеспечение может потребоваться для других форм взаимодействия. Использует ли приложение общепринятые стандарты либо лицензионные протоколы (для связи, хранения данных или интерфейсов управления)? Лицензионные протоколы могут затруднить взаимодействие с другими бизнес-системами и потребовать использования промежуточных программ, что может увеличить стоимость данного решения.
Безопасность. Чтобы гарантировать необходимую защиту информации, которую будет использовать рассматриваемое приложение, необходимо ответить на ряд важных вопросов. В частности, предусматривает ли производитель использование процесса, реализующего конкретные меры по защите приложения от атак? Как должна обеспечиваться защита приложения и располагает ли организация необходимыми для этого ресурсами? Каковы механизмы идентификации пользователей и компьютеров и авторизации доступа к данным? Работают ли эти механизмы на действующей платформе? Какие службы проверки предусматривает данное приложение? Как оценить безопасность развернутой системы? Как производитель реагирует на сообщения о выявляемых в процессе эксплуатации дефектах?
Надежность. Часто гарантия эксплуатационной готовности составляет единственный важный аспект, определяющий сферу ответственности отдела ИТ в области организационного управления приложением. Поэтому необходимо убедиться, что надежность рассматриваемого приложения, а также функциональные средства обеспечения надежности, которыми оно располагает, внушают доверие. Заблаговременно изучите, какие аппаратные и программные механизмы обеспечения надежности, такие как кластеризация и балансировка нагрузки, можно будет использовать для гарантии эксплуатационной готовности приложения в соответствии с потребностями бизнеса. Следует выяснить, каким образом приложение извещает администратора о сбоях в работе и как проходит его послеаварийное восстановление. Поинтересуйтесь у производителя, какие методы тестирования надежности применены к данному приложению. Узнайте, как измерить период работоспособного состояния приложения.
Удобство эксплуатации. Стоимость приложений, с которыми пользователям трудно работать, повышается из-за потерь производительного времени и необходимости профессиональной подготовки. Кроме того, существует риск конфликта с бизнес-подразделением, использующим данное приложение, если оно вызовет негативную реакцию пользователей. Оценивая продукт, нужно провести тесты на удобство эксплуатации в группах пользователей. Выясните, какие формы обучения предлагает производитель или его партнеры. Возможна ли заказная настройка или персонализация интерфейса и предусмотрена ли для данного приложения языковая среда для всех языков, на которых общаются пользователи?
Управляемость. Для приложений, сложных в управлении либо не управляемых с использованием средств, которыми располагает ваш отдел ИТ, возможно увеличение полной стоимости владения либо снижение предполагаемого уровня безопасности и надежности. Проводя оценку приложения, нужно определить, располагают ли администраторы необходимыми профессиональными навыками управления. Если нет, возможна ли соответствующая профессиональная подготовка? Определите, какие инструменты управления поддерживает данное приложение. Изучите возможные варианты управления приложением в локальном или удаленном режиме, а также поддерживаемые варианты автоматизации управления. Следует узнать, как проводится контроль операций, выполняемых в рамках управления, и возможна ли передача функций управления приложением сотрудникам, не являющимся администраторами. Наконец, необходимо выяснить, каким образом приложение оповещает о своей работоспособности.
Поддержка. Способность быстро и эффективно решать проблемы поддержки выбранного приложения имеет большое значение с точки зрения обеспечения эксплуатационной готовности и прогнозирования затрат. Поинтересуйтесь у производителей, какие предусмотрены варианты бесплатной поддержки приложений. Убедитесь в своей способности различать бесплатные и платные варианты поддержки. Оцените, насколько удобна документация пользователя, и выясните, проводятся ли конференции пользователей с целью предоставления активной поддержки. Рассмотрите и оцените собственные диагностические программные средства приложения. Наконец, выясните, насколько важна поддержка данного приложения в вашей организации.
Подсчет баллов
Для оценки достоинств каждого оцениваемого приложения следует применять унифицированный критерий. Хороший эффект может дать рейтинговая оценка приложений по отдельным категориям с использованием пятибалльной шкалы Ликерта. Использование этого метода состоит в присуждении каждому приложению баллов от 1 до 5 по каждой категории по следующей шкале:
1 - очень плохо; 2 - плохо; 3 - ни хорошо, ни плохо (удовлетворительно); 4 - Хорошо; 5 — Отлично.
После проведения оценки всех рассматриваемых приложений подсчитайте общее число баллов для каждого из кандидатов. Обычно можно с легкостью отказаться от варианта, имеющего средний балл 3 или ниже. Для вариантов, набравших средний балл выше 3, можно провести дополнительный углубленный анализ. Например, можно сделать расчет «стоимости, отнесенной к рейтингу», если предполагаемую стоимость приложения в расчете на одно рабочее место разделить на средний балл этого приложения. Вариант, давший самый низкий результат, способен обеспечить наибольшую эффективность за свою цену. Для простоты сравнения полезно также составить краткий список «за и против» для каждого приложения по каждой категории.
Используя структурный подход в оценке приложений, намеченных к приобретению, путем их всестороннего сравнения можно прийти к принятию более объективного решения. Такой подход также послужит хорошей основой для представления результатов проведенного исследования руководству и другим лицам, принимающим решения. А службе ИТ останется лишь выполнить развертывание приложения.
Бен Смит - Специалист по безопасности в компании Microsoft. bensmi@microsoft.com