Geum.ru

А. З. Моделирование отношений между разными типами представлений (модель управления) 88

Вид материалаДокументы
Б. 1.3. Quickstep for R/3: описание фаз реализации SAP
Подобный материал:
1   ...   8   9   10   11   12   13   14   15   16

Б. 1.3. Quickstep for R/3: описание фаз реализации SAP


Предложение / Заказ

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

Описание ситуации «как есть» предполагает предварительное создание общего эскиза процессов с крайне незначительной степенью детализации (один-два уровня). На семинарах по выработке требований с ориентацией на процессы выясняются требования заказчика к реализации R/3. Это делается при помощи контрольных списков. В результате составляется официальное предложение для заказчика. В зависимости от стратегии реализации Quickstep for R/3 предоставляет также ориентированные на процессы расчетные модели, план структуры проекта, списки действий (задач) и календарные графики. Эти способы контроля значительно повышают эффективность и качество планирования проекта.

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

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

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

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

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

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

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

Концептуальный проект прототипа

В начале этого этапа на основании календарных графиков и списков действий (задач), включенных в Quickstep for R/3, определяются временные рамки проекта и план действий по его реализации. Следует проинформировать сотрудников о ходе и целях проекта и установить необходимое оборудование и программное обеспечение.

Еще одной из мер по подготовке к реализации программного обеспечения является определение организационной модели R/3. На уровне предприятия необходимо описать клиентов, коды компании, корпоративные отделения и правила учета стоимости. Следует также определить организационные структуры для материально-технического обеспечения (логистики), продаж и закупок.

Организационная структура хранится в ARIS Toolset в виде иерархической диаграммы наряду с текстовой документацией, где приводится обоснование для описания различных структур.

Масштабы прототипа определяются путем описания актуальных бизнес-процессов, которые должны быть отображены в R/3. Необходимые модули R/3 определяются исходя из бизнес-процессов.

Взяв в качестве отправной точки цепочку добавленного качества, проектируют варианты процессов, отражающие различные опции в R/3. Это делается для следующих бизнес-процессов:

• инжиниринг/мастер-данные,

• обработка предложений/заказов,

• закупки,

• производство,

• послепродажное обслуживание.

Скажем, для обработки предложений/ заказов существует ряд вариантов, например, обработка стандартных продуктов, обработка сложных продуктов заданной конфигурации с помощью специальных конфигураторов или обработка сложных продуктов с помощью проектных инструментов. Эти варианты моделируются в ARIS Toolset как процессы. Для того чтобы сократить объем работ по проектированию и эффективно использовать возрастающие функциональные возможности R/3, проектирование вариантов процессов опирается на модель-прототип R/3 и модели вертикального рынка IDS. Модели вертикального рынка документально описывают процессы для приложений R/3, предварительно сконфигурированных IDS.

Настройка этих моделей должна выполняться децентрализованно будущими пользователями, работающими в соответствующих отделах. Для этого требуются инструменты, удобные для пользователя, например, ARIS Easy Design.

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

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

Иерархия моделей представлена на рис. 165.



Рис. 165. Иерархия моделей


Реализация

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

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

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

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

Непрерывное совершенствование

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