Материал: Предметно-ориентированные информационные системы_Фомина_конспект

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

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

Методология OneMethodology разработана компанией PeopleSoft (теперь входящей в состав Oracle) для внедрения информационных систем линейки J.D. Edwards. Состав этапов проекта внедрения существенно отличается от рассмотренных методологий Методика компании Oracle внедрения готовых приложений па-

кета Oracle E-Business Suite, называемая Application Implementation Method (AIM), является составной частью мето-

дического комплекса Oracle Method, который охватывает различные аспекты развития ИТ-инфраструктуры компании. Методология Oracle AIM представляет собой детальное описание задач, выполняемых в ходе проекта, с указанием последовательности их выполнения и ответственных ролей проектной группы.

AIM (Application Implementation Method) разбивается на фазы.

Эти фазы обеспечивают контрольные точки для координации проектных действий, которые имеют общую цель (общей и обязательной составляющей всех фаз и этапов работ является разработка и оформление соответствующей проектной документации):

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

анализ операций (анализ соответствия детальных бизнестребований стандартной функциональности Oracle E-Business Suite. По результатам анализа подготавливаются предложения для выполнения бизнес-операций на основе имеющейся архитектуры бизнес-приложений);

проектирование решений (разработка детальных спецификаций, соответствующих будущим бизнес-процессам. При согласованной необходимости новых разработок и дополнений к стандартной функциональности проводятся работы по настройке Oracle E-Business Suite, анализ интеграции с третьими продуктами и при согласованной необходимости формализация заданий на разработку интерфейсов);

реализация (настройка и наладка стандартных модулей, программирование и тестирование дополнительных отчетных форм, модификаций и новых разработок, включая согласованные расширения стандартной функциональности Oracle E-Business Suite, разработанных интерфейсов и процедур конвертации данных);

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

промышленная эксплуатация (переход на работу в новой системе, проверка функционирования и измерение/анализ показателей эффективности работы Oracle E-Business Suite).

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

Методологии представляются различными документами, есть методологии представленные в виде такого компактного документа где описывается все, это методология OnTarget, методология PeopleSoft, а есть методологии, которые разделены на

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

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

Методология Oracle делится на несколько другие элементы, делится на дисциплины, которые определяют каким образом, разрабатывать программный продукт, каким образом внедрять программный продукт, как управлять проектом разработки или создания программного продукта.

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

Рассмотрим содержание отечественного ГОСТа 34.601-90 «Автоматизированные системы. Стадии создания» (дата введения 01.01.1990 г.). Стандарт распространяется на автоматизированные системы (АС) для различных видов деятельности (ис-

это последовательное построение все более точных проектных решений по всем видам обеспечения информационной системы. Допускается исключать стадию «Эскизный проект» и отдельные

этапы работ на всех стадиях, объединять стадии «Технический проект» и «Рабочая документация» в «Технорабочий проект», параллельно выполнять различные этапы и работы, включать дополнительные.

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

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

Формирование требований и разработку концепции можно отнести к предпроектному обследованию. В первом случае процессы предприятия описываются «как есть», во втором – «как будет». В комментариях к пункту «Обследование и оценка необходимости» перечислены требования, определяемые заказчиком: «ограничения допустимых затрат на разработку, ввод в действие и эксплуатацию, эффект, ожидаемый от системы, условия создания и функционирования системы». Ограничения затрат и эффект от системы стоит, наверное, отнести к разделам «Технико-Экономическое Обоснование» (ТЭО) и «Выработка целей». Определить их корректно на первом этапе все равно не удастся. На последней стадии разработки концепции стандарт предлагает в общем случае создавать альтернативные варианты и планы их реализации; оценивать преимущества и недостатки этих вариантов, а также объем необходимых средств. Но не совсем понятно, о каких концепциях идет речь и по какому критерию эффективности их надо сравнивать.

Таким образом, в первых трех пунктах ГОСТа, относительно четко описаны только две стадии: Предпроектное обследование и Техническое задание. Следующие пункты относятся непосредственно к процессу внедрения.

В последовательности, представленной в ГОСТе, можно обнаружить элементы управления данными. Предусмотрены классификация и кодирование информации («Разработка проектных решений по системе и ее частям»), внедрение классификаторов («Ввод в действие»), загрузка информации в базу данных и проверка ведения этой базы («Пусконаладочные работы»).

В этот довольно ограниченный список действий не входят: определение точности данных, контроль, общая классификация и т. д. А На подготовку персонала выделен всего один пункт, чего в реальности недостаточно.

К недостаткам стандарта можно отнести:

ГОСТ 34.601-90 не ориентирован на конкретный вид программного продукта. В нем не учтены особенности внедрения комплексных систем автоматизации предприятия (особенно - в области обучения персонала и управления данными). Многие понятия определяются слишком широко.

некоторые положения устарели. Нулевой этап внедрения плохо проработан. Отсутствует этап предварительной переподготовки. Неубедительно и непоследовательно сформулированы процессы выработка целей и ТЭО.

Стандарт имеет и ряд достоинств. В частности, хорошо проработана технологическая цепочка: Обследование - Техническое задание - Технический проект и Опытный Пример - Получение результата - Анализ текущего состояния. Это универсальные элементы внедрения, необходимые для автоматизации во всех областях деятельности.

ГОСТ - открытый, публично доступный стандарт внедрения. Несмотря на все недостатки, он превосходит по качеству многие «корпоративные» методики.

8.6. Модель комплексного взаимодействия с клиентами банка с помощью системы Terrasoft ХRM

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