Тема 8. Характеристика работ продуктового ИТ-консалтинга

Работы по проведению обследования организации с целью оценки существующей информационной системы на функциональную полноту и соответствие требованиям бизнеса

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

Разработка требований к функциональности информационной системы

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

Разрабатываемые требования к функциональности делятся на две большие группы: общие и требования к функциям.

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

Требования к функциям содержат детальные функциональные требования к информационной системе по процедурам/функциям бизнес-процессов. Для окончательной формализации и подтверждения требований относительно тех или иных бизнес-процессов продуктовые ИТ-консультанты проводят дополнительные собеседования и собрания, выполняют работы по формализации, документированию и согласованию требований. Результаты работы оформляются в виде раздела отчета, в котором по каждому бизнес-процессу представлена следующая информация:

1. Функциональная модель бизнес-процесса.

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

3. Перечень и описание функций/процедур бизнес-процесса

4. Описание требований к функциональности ИС по всем функциям/процедурам бизнес-процессов.

5. Список входных и выходных документов.

На основе выявленных требований в дальнейшем разрабатывается техническое задание.

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

Работы при выборе и обосновании продуктового решения

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

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

Основными недостатками заказной разработки являются следующие положения:

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

· Тиражируемое решение внедряется поэтапно и частично может быть доступно в рабочем режиме гораздо быстрее, чем заказная разработка.

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

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

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

Для создания информационной системы организации применяются различные классы типовых тиражируемых программных продуктов:

· системы управления ресурсами предприятия (Enterprise Resource Planning, ERP - планирование ресурсов предприятия / Manufacturing Requirement Planning, MRP II - планирование производственных ресурсов/ Material Requirements Planning, MRP -- планирование материальных ресурсов);

· системы управления активами и фондами (Enterprise Asset Management, EAM);

· системы управления взаимоотношениями с клиентами (Customer Relationship Management, CRM);

· системы управления цепочками поставок (Supply Chain Management, SCM);

· системы управления персоналом (Human Resources Management, HRM);

· системы документационного обеспечения управленческой деятельности;

· системы управления эффективностью бизнеса (Business Performance Management, BPM);

· системы интеллектуального бизнес-анализа (Вusiness Intelligence BI);

· системы управления данными об изделии (Product Data Management, PDM).

Назначение основных классов программных продуктов, их функциональные возможности, и особенности рассмотрены в п.6.8.

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

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

Российские программные продукты более полно учитывают национальные особенности, российскую учетную специфику.

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

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

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

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

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

В состав документа "Запрос предложения", как правило, включают следующую информацию:

1. Общие сведения об организации.

2. Цели организации, задачи, стратегический план (необходимые выдержки).

3. ИТ-стратегию или тактический план (необходимые выдержки).

4. Ожидаемые результаты проекта.

5. Требования к программному продукту, включая требования к функциональности.

6. Требования к поставщику решения.

7. Требования по оформления и документарному составу предложения. Стандартные формы.

8. Критерии и методику оценки предложений.

9. Модель ценообразования.

10. Основные договорные требования / проект договора.

11. Контакты.

12. Сроки и место представления предложений.

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

Предварительно разрабатывают следующие группы критериев выбора, используемых при сравнительном анализе:

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

2. Квалификационные и другие критерии, предъявляемые к поставщику решения.

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

По результатам исследования, проведенного компаниями SAP и Market-Visio Consulting/ Gartner, организации при выборе поставщика ИТ-решений, в первую очередь, обращают внимание на качество предлагаемых продуктов и услуг. Вторым важным фактором является наличие истории успешных внедрений в организациях данной или схожей отрасли. Третий фактор - квалификация сотрудников ИТ- интеграторов.

При выборе поставщика комплексных программных решений ведущая аналитическая компания Gartner рекомендует использовать следующие критерии оценки:

3. Функциональные возможности.

4. Архитектура: техническая инфраструктура, необходимая для поддержки решения.

5. Устойчивость продукта: оценка в трех измерениях - финансы, структура и рынок.

6. Цена: средняя стоимость приобретения, инсталляции, обновления версий и технической поддержки программного продукта.

7. Сервис и поддержка: уровень технической поддержки, который обеспечивают поставщик и его партнеры.

8. Концепция и видение: прогнозы поставщика относительно тенденций развития отрасли; действия поставщика в плане функциональности и стратегии развития продукта в свете этих прогнозов.

Поставщик оценивается в двух аспектах - стабильность и полнота концепции.

В настоящее время компанией Gartner Inc. запатентована методика "Magic Quadrant" (Магический Квадрант), которая заключается в подготовке отчета с графическим представлением определенного рынка продукции за некоторый период времени. Этот отчет сравнивает компании по набору критериев, разработанных для данного рынка, и отражает мнение исследовательской компании. В "Магическом квадранте" компании оцениваются по полноте видения рынка (completeness of vision) и по способности к практической реализации этого видения (ability to execute). В соответствии с этими критериями системы различных производителей располагаются в четырех квадрантах: "лидеры" (leaders), "провидцы" (visionaries), "бросающие вызов" (challengers) и "нишевые игроки" (Niche Players). К сектору лидеров компания Gartner Inc. относит поставщиков, которые успешно ведут свою деятельность, имеют четкую концепцию работы на рынке и активно совершенствуют свои возможности для реализации этой концепции и удержания своих лидирующих позиций,

Исследования компании Gartner Inc. предоставляют один из источников информации для проведения сравнительного анализа и не являются окончательной рекомендацией выбирать только того производителя, который оценен как "Лидер".

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

· функциональная полнота и возможность поддержки информационной модели организации;

· отраслевая специфика;

· наличие инструментов разработки, позволяющих дополнить отсутствующие функции;

· масштабируемость;

· гибкость;

· стандартизация и открытость;

· сложность сопровождения и администрирования;

· архитектура и техническая платформа;

· стоимость;

· перспективы развития;

· информационная безопасность;

· профессиональные знания и квалификация поставщика;

· опыт и репутация поставщика;

· надежность поставщика.

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

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

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

Для крупных проектов выбор программных продуктов из альтернативных вариантов целесообразно проводить на конкурсной основе.

Стандартное аппаратное и программное обеспечение, информационные системы имеют свои особенности как предмет конкурса.

Выделяют следующие особенности стандартного аппаратного и программного обеспечения как предмета конкурса:

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

· диапазон оборудования, которое соответствует понятию стандартного аппаратного обеспечения, очень широк;

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

· необходимо учитывать особенности лицензионной политики разработчиков стандартного программного обеспечения (корпоративные лицензии, скидки для отдельных категорий пользователей);

· в конкурсную документацию должны быть внесены требования:

o обеспечивающие возможность модернизации аппаратного и программного обеспечения;

o по обеспечению расходными материалами;

· необходимо учитывать общую стоимость владения;

· требования должны быть сформулированы в соответствии с положениями нормативных документов.

Особенности информационной системы как предмета конкурса определяются следующими положениями:

· необходимостью подготовки специальных требований:

o к аппаратному и программному обеспечению;

o по проведению тестирования, приемо-сдаточных испытаний, пуско-наладочных работ;

o по интеграции с уже имеющимися информационными системами;

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

· необходимостью учета в условиях контракта вопросов, связанных с причинением ущерба в ходе выполнения различных работ.

Эти особенности обуславливают необходимость и целесообразность привлечения продуктовых ИТ-консультантов для участия в работах при подготовке и проведении конкурса.

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

Формально предварительное обследование не относится к процедуре открытого конкурса, однако его качественное проведение оказывает существенное влияние на проведение конкурса.

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