WWW.DISSERS.RU

БЕСПЛАТНАЯ ЭЛЕКТРОННАЯ БИБЛИОТЕКА

   Добро пожаловать!

Pages:     | 1 |   ...   | 7 | 8 || 10 |

Управление проектами по внедрению КИС Концептуальная модель является отраслевой моделью и, как правило, разрабатывается для предприятия внешним консультантом (обычно на основе эталонных моделей, предлагаемых поставщиками ERP-систем). В ней определяются основные направления развития предприятия через графическое представление передовой мировой практики (заключенной в стандарты ISO и ERP) и через определение несоответствий деятельности предприятия данной практике (на основе проведения сопоставительного анализа — benchmarking).

Концептуальная модель подразумевает унификацию основных процессов предприятия в соответствии со стандартами ISO 9001:Эталонная модель с использованием ISO 9000 переводится в IDEF0-модель.

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

• декомпозиция процессов предприятия — верхний уровень иерархии процессов соответствует элементам и подэлементам стандарта ISO 9001:2000, а нижние уровни раскрываются с высокой точностью • проектирование графического «скелета» документации СМК предприятия;

• определение ключевых пользователей процессов и бизнес-функций;

• определение на базе ERP-системы основных модулей информационной системы предприятия, обеспечивающих выполнение процессов;

• определение связей процессов по входам/выходам.

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

Логическая модель описывает деятельность предприятия посредством объектно-ориентированного проектирования (опираясь на методологию бизнесмоделирования RUP9 и нотации UML10).

Цель логического моделирования — построить интегрированную модель деятельности предприятия, являющейся связующим звеном между бизнесметодиками и ERP-системой. Логическая модель позволяет спланировать, как нужно реорганизовать текущие способы выполнения процессов предприятия в желаемые — вплоть до каждого рабочего места.

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

• кто и где исполняет бизнес-функции (организационный аспект деятельности);

• что перемещается в материальных и в связанных с ними информационных потоках (элементный аспект деятельности предприятия);

• как предприятие выполняет бизнес-функции (функциональный аспект);

• когда предприятие осуществляет бизнес-функции (динамический аспект);

• какая информационная платформа (какие инструменты) необходима для поддержания бизнес-функций на предприятии.

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

Иными словами, бизнес-модель является отображением предприятия и его информационно-управляющей системы. Без бизнес модели Невозможно построить действительно интегрированную и «всеобъемлющую» КИС. Именно при создании бизнес-модели формируется «язык общения» консультантов, разработчиков, пользователей и руководителей предприятия, позволяющий выработать единое представление о том, ЧТО и КАК должна делать система управления предприятия.

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

С особой тщательностью следует подходить к формату представления бизнесмодели. Популярная методология SADT (Structured Analysis and Design Technique) или рожденная на ее основе IDEF0 действительно хороши там, где практически отсутствуют описания функций и бизнес процессов, а также в тех случаях, когда построением модели занимается не единая, слаженная команда, а, например, группа, состоящая из внешних консультантов, экспертов поставщика КИС и сотрудников самого предприятия. В таком случае можно гарантировать, что большинство членов «сборной» команды знакомы с общепринятым стандартом IDEF0 (в настоящее время его преподают во многих вузах), следовательно, можно сравнительно быстро приступить к работе над моделью, «поделив» между собой бизнес функции предприятия. Создаваемые диаграммы будут совместимы друг с другом и смогут впоследствии составить единую модель. Однако характерная для стандарта IDEF0 бедность изобразительных средств делает невозможным, например, описание сквозных бизнес процессов, охватывающих весь цикл обработки заказа — от размещения до исполнения. Для подобных задач более подходящим инструментом могут служить такие известные системы проектирования, как ARIS («архитектор интегрированных информационных систем») или BAAN DEM («динамический моделировщик предприятий»). В общем, любой способ изображения модели хорош, если он нагляден и понятен руководству предприятия.

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

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

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

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

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

Проект архитектуры информационных систем должен быть:

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

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

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

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

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

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

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

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

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

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

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

Тестирование Тестирование представляет собой набор процедур и действий, предназначенных для демонстрации корректной работы КИС в заданных режимах и внешних условиях. Цель тестирования — выявить наличие ошибок или убедительно продемонстрировать их отсутствие, что возможно лишь в отдельных тривиальных случаях. Важно различать тестирование и сопутствующее понятие «отладка». Отладка — это набор процедур и действий, начинающихся с выявления, самого факта наличия ошибки и заканчивающихся установлением точного места, характера этой ошибки и способов ее устранения.

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

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

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

Pages:     | 1 |   ...   | 7 | 8 || 10 |



© 2011 www.dissers.ru - «Бесплатная электронная библиотека»

Материалы этого сайта размещены для ознакомления, все права принадлежат их авторам.
Если Вы не согласны с тем, что Ваш материал размещён на этом сайте, пожалуйста, напишите нам, мы в течении 1-2 рабочих дней удалим его.