Информационное общество. Определение, основные черты

Вид материала

Документы

Содержание Тема 10. Взаимодействие с производителями и поставщиками аппаратного и программного обеспечения Детальный анализ вендоров

Подобный материал:

• Информационное общество Информационное общество, 118.42kb.
• 1. Определение и основные характеристики информационного общества, 575.54kb.
• История и современность, №2, сентябрь 2009, 398.1kb.
• Лекция: Информационное обеспечение ис: Информационное обеспечение ис. Внемашинное информационное, 314.22kb.
• Распоряжение от 20 октября 2010 г. N 1815-р о государственной программе российской, 2080.19kb.
• Распоряжение от 20 октября 2010 г. N 1815-р о государственной программе российской, 2442.12kb.
• Вопросы к экзамену по Отечественной истории, 34.96kb.
• Обществознание интенсивный курс Авторы: Александрова И. Ю., Андреева В. В., Глазунова, 1095.61kb.
• Экономический факультет рудн, 147.41kb.
• Информатизация образования и модернизация школы, 313.71kb.

Тема 10.
Взаимодействие с производителями и поставщиками аппаратного и программного обеспечения

Детальный анализ вендоров

В большинстве проектов создания информационных систем задействованы три стороны: заказчик, производитель оборудования или программного обеспечения, а также посредник между ними в лице интегратора. Заказчик общается с интегратором, интегратор — с производителем, и эти два круга общения оказываются изолированы друг от друга. Так обстоит дело при внедрении простых информационных систем, однако если речь идет о сложных проектах, цена которых начинается с десятков тысяч долларов, заказчик может вступить в непосредственное взаимодействие с производителем¹.

Для прямой работы с вендором (производителем и поставщиком) есть две основные причины: «Во-первых, общение заказчика с поставщиком является способом воздействия на посредника — дистрибьютора или интегратора, а во-вторых, это способ воздействия на самого поставщика. Вендор обычно гораздо внимательнее слушает конечного потребителя, нежели интегратора, если тот ему рассказывает о своих нуждах: почему, например, нужно ускорить поставку и сделать ее не за двенадцать, а за восемь недель. Решать такие вопросы напрямую бывает эффективнее, нежели задавать их через цепочку посредников».

Кроме того, как правило, интеграторы хорошо справляются лишь с задачами, похожими на те, что они уже решали ранее. В случае же принципиально новых задач непосредственное взаимодействие заказчика и производителя может стать единственным способом преодоления временной некомпетентности местного интегратора и в конечном итоге пойдет ему же на пользу, позволив приобрести новый опыт. И тогда наличие регионального представительства у вендора может стать важным конкурентным преимуществом.

Взаимодействие с производителем оборудования необходимо, потому что качество комплектующих и цены на рынке сильно варьируются. С поставщиком можно договориться, например, о плановой поставке техники, определить границы цен, бюджет и т. п.

Взаимодействие с вендором имеет смысл лишь в том случае, если в компании существует продуманная ИТ-стратегия. Основным условием ее построения, в свою очередь, является бизнес-стратегия, в которую органично включены вопросы централизованного финансирования ИТ. Однако последнее условие в 90% случаев не выполняется: «Либо у руководства компании существуют смутные представления об ИТ-стратегии, либо у разных управляющих отсутствует согласие по поводу целей развития. А от этого согласия зависит развитие взаимоотношений с поставщиками, будь то консультанты, поставщики программного обеспечения или вычислительной техники. Если ресурс, выделяемый на развитие информационных технологий, недостаточно специфицирован и за него отвечают различные подразделения, то могут возникать самые разные сценарии, в том числе и сценарий «дикого рынка», когда заказчик становится ареной неупорядоченной конкурентной борьбы нескольких поставщиков (иногда, впрочем, он специально устраивает такую борьбу с целью добиться снижения цены или получения иных выгодных условий).


С учетом вышеизложенного выбор вендора является важной задачей информационного менеджмента.

Детальный анализ вендоров представляет собой важный этап работы с вендорами². Главная задача этого шага — тщательнейшая проработка соответствия вендорского продукта функциональным запросам компании, проработка технических моментов вендорского решения, а также планомерная работа с бывшими заказчиками данного вендора с целью понять, насколько качественно вендор решил проблемы других компаний.

Прорабатывая данные, предоставленные вендорами, необходимо рассмотреть различиях между вендорами, так как именно эти различия и повлияют на окончательный выбор. Обычно на конечном этапе рассматриваются два (иногда три) вендора. Эти два вендора должны быть подвергнуты детальному анализу. Детальный анализ состоит из двух основных частей:

• функциональность продукта, в ходе которого выясняют, насколько точно продукт, предлагаемый вендором, соответствует функциональным запросам компании;
  
• технические решения.
  

Функциональная часть детального анализа должна проводиться достаточно детально. Как наиболее важная, она требует особенных аналитических усилий. Необходимо упомянуть, что ошибки именно в этой части, как правило, являются основным источником неприятных сюрпризов в фазе внедрения решения. Поэтому понимание бизнес-процессов, которые надо перевести в информационные системы, должно быть очень глубоким. Серьезные требования предъявляются и к уровню детализации системы вендора. При выборе вендора необходимо задавать вопросы до тех пор, пока не будет получен удовлетворительный ответ. Если в результате этой работы от вендора начнут поступать недовольные замечания по поводу детальности вопросов, можете принять это как комплимент хорошей работе. Жалобы подобного рода можно использовать как индикатор правильности направления движения. Важно понять и обратное: если вендор не жалуется, то до желаемого уровня детализации еще далеко и процесс выбора определяется самим вендором, а не заказчиком.

Основа функциональной части детального анализа — демонстрация решения. Эффективнее всего будет организовать для каждого вендора по две разные демонстрации. На первой из них, открытой, вендор демонстрирует продукт так, как считает нужным. Вторая демонстрация четко планируется менеджерами, ответственными за выбор вендора, и дает ответы на вопросы, являющиеся высокоприоритетными функциональными моментами компании-заказчика. Демонстрации надо организовывать именно в порядке, указанном выше: сначала свободная презентация вендоров, потом, спустя некоторое время, — презентация по плану, продуманному менеджерами заказчика.

Все вендоры знают наилучший способ презентовать свою продукцию. Открытая ничем не лимитированная возможность показать продукт так, как вендоры считают нужным, является важным шагом в работе с ними. Зная, что им были даны все шансы, они будут удовлетворены ходом дела. Вы получаете все козыри в руки. Вы дали вендорам сделать то, что они хотели, теперь их черед сделать то, что вам нужно. Вендоры и не будут подозревать, что вторая демонстрация для менеджеров по выбору вендора намного более важна.

Содержание второй демонстрации критично. Менеджеры по выбору вендора должны представить вендору обширный список требуемых функций, а также пробные сценарии и данные для тестовой работы системы. В результате этой демонстрации менеджеры по выбору вендора должны понять не только то, как в данной системе выполняются ключевые функциональные требования, но и как та или иная функция сконфигурирована в системе и какой уровень конфигурации требуется, чтобы заставить ее работать согласно функциональным требованиям. Менеджеры по выбору вендора ни на минуту не должны забывать, что многоступенчатые конфигурации и настройки системы повышают стоимость внедрения. Нужно вести учет примерного уровня настроек, требуемого для функциональности. Вендора надо просить дать столько демонстраций, сколько нужно, чтобы менеджеры по выбору вендора поняли в деталях, как каждая из функций будет выполняться.

В дополнение к демонстрации основных функциональных требований менеджеры по выбору вендора должны запросить демонстрации вспомогательных функций системы, если относительно них остаются какие-либо вопросы после первой демонстрации. В эту часть обычно включаются дополнительная функциональность, инструменты конфигурации, языки настройки, интеграционные средства, API, инструменты извлечения данных, возможности создания отчетов и другие.

Как правило, на каждую демонстрацию отводится целый день. Вторая демонстрация назначается на одну из последующих недель. Одна-две недели после первой демонстрации должны быть посвящены анализу откликов других заказчиков на эту же систему и дополнительные исследования по данному вендору. Менеджеры по выбору вендора должны иметь достаточно времени между демонстрациями, чтобы собрать воедино все, что удалось найти. Но демонстрации надо назначать достаточно близко по времени друг к другу, чтобы быть уверенным, что сравнение вендоров сделано качественно. Хорошим интервалом считается один день между демонстрациями.

Добиться наилучшего порядка работы данного этапа можно, выполняя следующие правила:

1. Вендоры должны четко представлять, чего вы ожидаете от первой и второй демонстраций.
   
2. Необходимо обеспечить присутствие на демонстрации каждого члена команды менеджеров по выбору вендора и отсутствие каких-либо других дел в этот день.
   
3. Членам команды менеджеров по выбору вендора следует проявлять активность во время сессии вопросов и ответов.
   
4. Демонстрации должны проходить там, где это удобно вендору, чтобы он мог показать товар в его лучшем проявлении и не имел никаких претензий в связи с нехваткой чего бы то ни было или техническими неувязками.
   

Вторая часть детального анализа — технический детальный анализ. Он необходим для выяснения полного набора технических компонентов для всех вендорских приложений и планируемой технической архитектуры. Технический детальный анализ, как правило, проходит при участии технического представителя (одного или более) от вендора, членов команды менеджеров по выбору вендора и технического специалиста из ИТ-отдела компании. Данная часть работы предполагает, что будут определены все необходимые технические детали будущего решения. Эта часть состоит из трех подчастей:

• предпочтительная техническая архитектура решения;
  
• способность поддерживать пиковые объемы нагрузки;
  
• подход к разработке.
  

Прежде всего менеджеры по выбору вендора должны определить рекомендуемые стандарты и вероятные требования для всех требуемых компонентов планируемой системы. Дело в том, что показать в благоприятном свете свое решение вендорам часто удобнее на конфигурации, минимально соответствующей требованиям. Но реальный интерес представляет не минимальная, а наиболее вероятная конфигурация, и оценивать решения надо относительно нее. Очевидно, что наиболее вероятная конфигурация определяет и цену.

Менеджеры по выбору вендора могут проанализировать различные аспекты технического анализа. Результатом работы на этом этапе должно быть четкое понимание вероятной стоимости проекта с технической точки зрения, чтобы менеджеры могли создавать бюджет проекта начиная с конца описываемого здесь этапа выбора вендора. Потенциальные вопросы должны быть распределены таким образом, чтобы было понятно, какие технологические вопросы повлияют на процесс принятия решения в целом и какие — на общую стоимость проекта.

Список рассматриваемых вопросов может быть следующим:

1. Предпочтительная техническая архитектура решения: ОС, серверы, клиенты, сеть, базы данных.
   
2. Количество и тип требуемых серверов и систем хранения.
   
3. Инструменты интеграции: middleware, API и т. д.
   
4. Приложения от третьих компаний, необходимые для работы решения (middleware, приложения создания отчетов, базы данных и др.).
   
5. Минимальные требования к клиенту.
   
6. Требования к сети и пропускной способности между сервером и клиентом
   
7. Возможности балансировки нагрузки и кластеризации.
   
8. Подходы к созданию резервных копий данных. Управление восстановлением данных.
   
9. Процедуры старта и завершения работы системы
   
10. Защита и аудит системы. Пользовательские и администраторские настройки.
    

Вторая часть технического анализа состоит в том, чтобы оценить способность системы поддерживать пиковые объемы транзакций и адаптироваться к будущему изменению бизнеса. Здесь важно четко проанализировать возможности масштабируемости системы. Для этого необходимо оценить текущий объем пользователей и пиковую нагрузку на систему. Это трехступенчатый процесс. Сначала надо определить день и время пиковой активности существующей в компании системы. После чего взять реальный объем транзакций и количество пользователей. Должны быть определены пики нагрузки, сезонные и месячные факторы (отчеты конца месяца или финансовые обработки) и недельные влияния. Эти пиковые изменения зависят в значительной степени от индустрии, типа компании, концентрации пользователей, сезонности бизнеса и ряда других показателей.

После того как пики определены, техническая команда должна построить календарь работы системы, описать, какие процессы в какие часы работают. Данная таблица может выглядеть примерно так, как показано на рис. 1.




Менеджеры по выбору вендора могутт оценить количество пользователей и объемы транзакций для пиковых и общих периодов. Затем эта информация должна быть просуммирована, как показано на рис. 2.





После этого менеджеры могут сравнить эти данные с данными рассматриваемой системы. Вендоры обычно представляют два различных типа показателей мощностей системы. Один является результатом лабораторного стресс-теста, который показывает максимальные возможности системы при определенных различных технических условиях. Второй — результат практического внедрения системы у реального пользователя. Во втором случае менеджеры по выбору вендора должны связаться с компанией, у которой уже работает эта система, и проверить данные и способность системы управляться с пиковыми объемами.

В целом все эти сборы данных и оценки должны стремиться ответить на два вопроса.

1. Будет ли у онлайнового пользователя нормальная возможность взаимодействовать с системой во время пиковых часов работы системы (будет ли время ответа системы находиться в приемлемых пределах для пользователей, или ответ будет слишком медленным)?
   
2. Будет ли система способна обработать всю требуемую информацию в какое-то разумное время?
   

Наконец, последняя составляющая технического детального анализа — оценка методологии разработки и технологий, использованных вендором для создания данной системы или продукта. Эти два фактора влияют на стоимость системы. Вендоры, которые сделали инвестиции в специальные технологии и методики создания приложений, такие как SDLC, CMM, или вендоры с сертификатами качества ISO имеют важные преимущества. Чем более распространена технология, использованная при создании, тем выше доступность рабочей силы и тем, как правило, ниже стоимость продукта. Можно оценить уровень адаптации сертификации и методологий через контакт с компанией, которая выдала сертификат. Можно также, например, попросить вендора показать руководство по стандартам разработки.


В области технического детального анализа один вендор редко отличается от другого. Большинство вендоров поддерживают все технологии, присутствующие на рынке, используют одинаковые среды разработки, обеспечивают похожие интерфейсы и поддерживают объемы передачи данных, превышающие ожидаемые пики. Поэтому технический детальный анализ должен быть сосредоточен на понимании потенциальной стоимости внедрения данной системы с точки зрения аппаратной и инфраструктуры. Следует предусмотреть и страховку от любых сюрпризов, в особенности связанных с поддержкой платформ и масштабируемостью решения анализа.

Тем не менее фаза технического детального анализа необходима. Важно понять: при таком подходе, а также при проведении двух функциональных презентаций команда по выбору вендора держит контроль над ситуацией в своих руках, что и требуется делать явно или скрыто на протяжении всего периода выбора.