Задумка написать данный текст появилась в марте 2004 при попытке упорядочить обучение начинающих консультантов команды «Найтов-БИС». В марте же, когда была готова первая часть текста, стало понятно, что текст может быть использован нетолько для внутрифирменного обучения, но и будет интересен «посторонним» читателям:

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

Текст может помочь не только освоить методику внедрения готовых приложений Oracle Application Implementation Method (AIM), но и понять базовые принципы внедрения любого сложногобизнес-приложения.

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

Об AIM

AIM – Application Implementation Method – методика внедрения готовых приложений, разработана компанией Оракл для внедрения пакета готовых приложений Oracle E-Business Suite. Методика AIM практически не использует специфических особенностей Oracle E-Business Suite, поэтому она с одинаковым успехом может быть применена при внедрениилюбой ERP-системы и, вообще говоря, любого готового приложения, ориентированного на «автоматизацию» бизнес-процессов. Основную суть методики составляет адаптация бизнес-процессов к применению информационных технологий и,одновременно, адаптации этих самых информационных технологий к конкретным бизнес-процессам.

На настоящий момент не существует отечественных методик и/или стандартов (ГОСТов) в области внедрения готовых приложений. Учитывая современную мировую интеграцию в области стандартизации, а также ненаверстываемое в ближайшем будущемотставание отечественной индустрии сложных программных разработок, теперь уже нет никакого смысла в разработке отечественных методик.

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

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

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

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

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

Когда по тексту будет важно понимать, идет ли речь о «стандартном» AIM или модифицированной методике, для модифицированной будет применяться термин AIM-M (как дляКалашникова :)

Существует детальная фирменная документация на Oracle AIM версии 3 и версии 2.5 (на английском языке). В данном тексте используется структура задач по версии 2.5, поскольку эта версия кажется менее перегруженнойнеосновными задачами, а в целом методика обоих версий одинакова. Читатель при необходимости легко сможет перевести задачи AIM 2.5 в задачи AIM 3, пользуясь главой «Task Cross-Reference» в документации по3-й версии.

Основные понятия AIM

Общеизвестные понятия

При внедрении готовых приложений пакета Oracle E-Business Suite используется ноу-хау методика, выработанная и апробированная компанией Oracle в ходе внедрения пакета собственным подразделением консалтинга. Данная методика - AIM(Applications Implementation Method, Метод внедрения приложений) - представляет собой детальное описание задач, выполняемых в ходе проекта, с указанием последовательности выполнения и ответственных ролей проектной группы.

Задача в терминах методики AIM представляет собой элементарный (неделимый) объем работ, который обязательно заканчивается формально фиксируемым результатом.

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

Все задачи сгруппированы в процессы по принципу общности результата. Выделяются следующие процессы внедрения:

Определение бизнес-требований- результатом выполнения задач, входящих в данный процесс, является описание требований заказчика к развертываемой системе. В ходе этого процесса выявляются детальные алгоритмы, по которым происходит выполнениехозяйственной деятельности (бизнес-процессов) заказчика в области, затрагиваемой развертыванием автоматизированной системы. Затем разрабатываются детальные модели хозяйственной деятельности (бизнес-процессов) заказчика после развертывания системы,которые затем детализируются до уровня конкретных функций, выполняемых системой для каждого элементарного шага бизнес-процесса.
Отображение бизнес-требований- в ходе выполнения задач, входящих в данный процесс, проводится анализ того, какая функциональность Oracle E-Business Suite и каким образом может использоваться для реализации функциональных возможностей, необходимыхзаказчику. В этом процессе окончательно определяется, каким образом будут осуществляться хозяйственные процессы (бизнес-процессы) заказчика после развертывания системы, какая информация будет храниться в системе и какие доработки необходимо сделать, атакже значения параметров настройки Oracle E-Business Suite.
Функциональная и техническая архитектура – в ходе этого процесса происходит построение технической архитектуры, необходимой для работы системы, а также определяются значения ключевых параметров настройки Oracle E-Business Suite, касающихся архитектуры.
Разработка дополнительной функциональности – в рамках этого процесса разрабатывается программное обеспечение, необходимое для реализации функциональности, отсутствующей в Oracle E-Business Suit.
Конвертация данных – процесс охватывает задачи, связанные с переносом данных из существующих систем (возможно в бумажном виде) во внедряемую систему. Выявляются объекты, содержащие необходимые данные, определяются методы загрузки этихданных в систему. Разрабатываются и выполняются программы переноса.
Документирование – вэтом процессе создается документация на систему.
Тестирование системы - на основе требований к функциональности системы, собранных и детализированных в ходе процессов определения и отображения бизнес-требований, разрабатываются сценарии тестирования и производится проверка системы нареализуемость требований.
Тестирование на производительность- в ходе этого процесса выполняются задачи, связанные с тестированием системы на «узкие» места по производительности.
Обучение - этотпроцесс разбивается на две части - обучение проектной группы, с которого начинается проект по внедрению, и обучение конечных пользователей, которым проект заканчивается.
Ввод в эксплуатацию- в ходе этого процесса рассматриваются все вопросы, связанные с вводом в эксплуатацию системы и ее последующим сопровождением.

Все работы по проекту разбиваются на временные фазы. Выделяются следующие фазы:

Определение - поокончании данной фазы определяются совокупные бизнес-требования заказчика. Впоследствии они могут уточняться и видоизменяться в ходе отображения на функциональность Oracle E-Business Suite, но появления новых бизнес-требований не происходит.
Анализ операций - поокончании данной фазы будущие бизнес-процессы зафиксированы и определено, как они будут реализованы с помощью Oracle E-Business Suite. Так же точно определено, какие бизнес-требования не могут быть удовлетворены с помощью стандартной функциональностии какая дополнительная разработка необходима.
Проектирование решения - в ходе данной фазы в частности производится создание детальных спецификаций для дополнительной разработки (функциональный и технический дизайн) и разработка сценариев тестирования.
Разработка - поокончании данной фазы все дополнительные разработки завершены, приемочные тесты проведены, пользовательская документация разработана.
Переход к эксплуатации - в ходе этой фазы завершается обучение конечных пользователей, производится конвертация данных и система вводится в эксплуатацию.
Эксплуатация системы – это начало фазы поддержки системы. В это время выявляются и исправляются все недочеты по работе системы.

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

Комментарии к термину «фаза внедрения»

В ходе проекта все фазы внедрения накладываются одна на другую и, более того, итеративно повторяются. Это, в частности, происходит из-за того, что:

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

Нормальна ситуация, когда, например, внедрение бизнес-процесса Х1 находится в фазе 3 (Проектирование решения), а внедрение бизнес-процесса Х2 - в фазе 1 (Определение бизнес-требований).

В дальнейшем по тексту будет детально показано, при выполнении каких задач и почему происходит «фазовое смещение». Сейчас важно понять, что понятие «фаза» выполняет только одну роль - является качественной оценкой прогресса внедрения,но не всего проекта, а отдельных его объектов. Например, использование понятия «фаза» позволяет показать, что: если в ходе проекта выполняется задача Х, «декларируемая» AIM как задача 4-й фазы, то ход внедрения по этой задаче Химеет прогресс больший, чем для другой задачи Y, реально выполняемой одновременно с Х, но «приписанной» AIM ко 2-й фазе.

Результат задачи

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

Обязательно ведется электронная и бумажная библиотека проекта. Бумажная необходима для помещения в нее подписанных актов и, возможно, твердых подписанных копий электронных документов-результатов. Важно понять, что порядок приемарезультатов задач внедрения должен быть формализован и сам по себе утвержден до получения первых результатов. Порядок согласования и утверждения (приема) результатов проекта и порядок работы с библиотекой проекта определяется методикой OraclePJM, и сам по себе задокументирован в документе CM.10 (процедуры управления конфигурацией проекта).

Шаблоны документов-результатов всех задач AIM входят в состав стандартной поставки AIM. Если формат реального документа-результата отличается от предусмотренного AIM (как это имеет место быть в AIM-M), то этот новый формат должен быть описан (чтобы исполнители последующих задач могли его использовать). PJM предусматривает документCM.10 для такого описания (либо разъясняющие комментарии должны содержаться в самом документе).

Документирование результатов выполнения всех задач используется в двух целях:

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

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

Исполнители задачи

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

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

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

Руководитель проекта по качеству. Ответственен за правильное управление проектом и решение всех спорных вопросов.

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

В описании каждой задачи AIM (в фирменной документации) указывается, какая роль участвует в исполнении задачи и приводится процент её участия. В случаях, когда определенная роль задействована существенно более50% в исполнении задачи, понятно, что человек, исполняющий эту роль, с точки зрения управления проектом является ответ.исполнителем, т.е. исполнителем, ответственным за успешное выполнение всей задачи; при этом участники выполнения задачи,исполняющие другие роли, помогают ему. В случаях, когда такую лидирующую роль выделить невозможно (например, указаны две роли с одинаковым процентом участия), возникает проблема единой ответственности за выполнение задачи. В этих случаях, чтобыуменьшить проблему координации работы нескольких участников при выполнении задачи, рекомендуется:

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

Последняя рекомендация самая универсальная, но и самая трудоемкая.

Идентификация задач по процессам и фазам,
Порядок выполнения задач

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

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

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

Задачи в AIM обозначаются двумя буквами (обозначение процесса) и двумя-тремя цифрами (порядковый номер задачи *10) через точку, типа RD.10, TA 120. Вообще говоря,порядковый номер задачи внутри процесса ничего не говорит о последовательности её выполнения в проекте, поскольку реальная последовательность выполнения задач (взаимосвязь задач по переходящим результатам) включает задачи из разных процессов.

Понимание взаимосвязи задач очень важно, поскольку это есть понимание

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

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

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

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

Полезно посмотреть в документации по AIM графическое изображение взаимосвязи задач (внутри одной фазы), приводимое в начале каждой главы про фазы проекта. Пользы в этой картинке мало, но наглядно. Взаимосвязьвсех задач проекта приводится в формате MS Project и является «скелетом» типового плана внедрения (файл в составе типовой поставки AIM). Пользы и в этой картинке мало, но опять же наглядно (почему малопользы – станет ясно потом).

Разделение задач по фазам реального значения не имеет (это тоже станет потом ясно).

Идеология AIM

Как это будет продемонстрировано в пособии, основная идея AIM состоит в следующем подходе:

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

Изучение и моделирование бизнеса

Сама суть проекта внедрения готового приложения заключается в адаптации

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

AIM подразумевает, что при создании начальной модели бизнеса применяется метод Oracle OBM. OBM – это модификация метода data-flow диаграмм.Вместо data-flow в OBM используется понятие information-flow, где под потоком между шагами обработки понимается не только данные, но илюбая структурированная и неструктурированная информация, в том числе управляющие события. Интересующиеся могут посмотреть фирменную документацию по OBM; методика становится ясной с первого прочтения.

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

Для AIM-M был выработан свой подход к моделированию бизнеса, позволяющий в одном формате не только моделировать бизнес, но и выполнять основные задачи внедрения. При этом графические моделибизнеса применяются как вспомогательные. Основным инструментом моделирования в AIM-Mявляется описание бизнеса в виде процедур формата Oracle Tutor (описано ниже).

Термины, применяющиеся при моделировании бизнеса в AIM и OBM

Бизнес-процесс нижнего уровня (LBP – lower-level business process) – это последовательность шагов (steps), выполняемых бизнесом в ответ на возникшее событие.
Роль (role) – типовая роль в бизнесе, специализирующаяся на выполнении в бизнесе определенных функций. Каждый шаг LBP выполняет определенная роль. Одна роль может выполнять один или несколько последовательных шагов, прежде чем действия перейдут к другой роли.
Шаг бизнес-процесса нижнего уровня (LBP step) является элементарной бизнес-функцией (EBF- elementary business function). Элементарной её называют, поскольку она выполняется как единый элемент определенным исполнителем (ролью) и её выполнение не должно прерываться: либо EBF выполняется и дает бизнес-результат, либо нет; частично выполнение EBF бизнес-результата не дает. Роль полностью определяется множеством EBF, которые она выполняет в бизнесе.
Событие понимается как нечто произошедшее вне бизнес-процесса. События бывают:
Внешнее событие – случающееся вне сферы моделируемого бизнеса. Могут инициироваться или полностью вовне бизнеса (приход инвойса от внешнего поставщика), или в бизнесе, но вне автоматизируемой области.
Внутреннее событие – когда какая-то роль после исполнения своей EBF передает действие другой роли. Вообще говоря, внутреннее событие не является настоящим событием, а используется для удобства, чтобы разбить последовательность шагов, выполняющихся бизнесом в ответ на внешнее событие, на несколько бизнес-процессов.
Событие по расписанию – происходит по заранее известному расписанию (например, каждое 1-е число месяца). Может быть внешнее или внутреннее.
Один и тот же LBP может запускаться разными событиями.
Шаг LBP, он же EBF, может быть трех видов с точки зрения задействования приложения: 1) выполняемый ролью (человеком) с использованием приложения (system assisted step), 2) выполняемый без участия приложения (manual step), 3) выполняемый приложением без участия человека (automated step). Надо понимать, что для выполнения EBF роль (приложение) может выполнить множество действий.
Бизнес-процесс (б/п) не нижнего уровня – множество LBP, связанных между собой «передачей управления». Обычно LBP группируются по видам деятельности предприятия: снабжение, сбыт, маркетинг, проектирование, производство и т.п. Б/п-ы могут группироваться иерархично, по уровням. В OBM уровнем LBP считается пятый уровень, множество LBP 5-го уровня объединяются в б/п 4-го уровня, множество б/п-ов 4-го уровня объединяются в б/п 3-го уровня, и так до 1-го уровня. Б/п 1-го уровня – это предприятие в целом, включая все его б/п.
Бизнес-функция (б/ф). При взгляде на бизнес с точки зрения выполнения последовательности шагов в ответ на внешнее событие говорят о бизнес-процессе. При взгляде на бизнес с точки зрения получаемого результата в ответ на внешнее событие говорят о бизнес-функции. Снабжение – это с одной стороны бизнес-процесс, с другой – бизнес-функция. Заметим: EBF = шаг LPB, LBP = одноименная б/ф.

При «точечном» внедрении ERP систем автоматизируемая область бизнеса представляет из себя один или несколько (не много) бизнес-процессов 2-го или 3-го уровня. Если внедрение охватывает «много» бизнес-процессов2-го уровня, то говорят о всеобъемлющем внедрении.

При описании (моделировании) LBP в AIM (OBM) и AIM-M применяются следующие изобразительные средства:

Запускающее событие. Всегда должно быть указано. Может быть несколько.
Шаг LBP, он же EBF. Обычно от 2-х до 9 шагов в LBP. Выделяют первый шаг, который выполняется первым по возникновении события.
Последовательный переход от шага к шагу. Указывает, на какой шаг перейти после выполнения текущего.
Ветвление по условию на уровне LBP. Применяется, когда после выполнения шага (EBF) или сразу после возникновения события (шаги еще не выполнялись) возможен переход либо к одному шагу (EBF), либо к другому в зависимости от условия, проверяемого перед переходом.
Ветвление по условию внутри EBF. Применяется, когда при выполнении EBF после выполнения действия нужно перейти либо к одному действию внутри EBF, либо к другому в зависимости от условия, проверяемого перед переходом.
Безусловный переход к выполнению другого LBP. После перехода остальные шаги исходного LBP не выполняются. Понятно, что исходный LBP должен породить внутреннее событие, запускающее другой LBP (входное для него).
Переход к выполнению другого LBP с продолжением. После окончания выполнения «вызванного» LBP, выполняются остальные шаги исходного LBP.
Окончание. Подчеркивает, что на этом месте LBP заканчивается.
Роль, выполняющая EBF. Должна быть указана для каждого EBF.

Всегда актуален вопрос: каким образом множество шагов, выполняемых бизнесом в ответ на внешнее событие, разбивать на разные LBP? Рекомендуется выделять в отдельный LBP шаги, выполняемые безразрыва во времени. Если переход от одного шага к другому подразумевает асинхронность, да еще если при этом управление процессом передается другой роли, то этот переход – хороший кандидат на границу LBP.

Моделирование бизнес-процессов в формате бизнес-процедур Oracle Tutor

Читателю необходимо ознакомиться с применением языка описания процедур Oracle Tutor в «Procedure Style Guide.pdf» (из стандартной поставки Tutor-а). Язык прост и становится ясным с первого прочтенияинструкции.

В AIM-M язык описания процедур Tutor применяется для описании (моделировании) LBP, а расширение этого языка – для документирования результатовмножества задач проекта внедрения. Далее, в тексте комментариев к задачам, будет разъяснено, как при их выполнении используется расширения языка описания процедур Tutor (вместо формата, предусмотренного AIM).

Цели моделирования бизнеса в проекте внедрения готового приложения

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

каким образом должно быть настроено приложение,

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

Поэтому:

моделируются процессы только в автоматизируемой области,
детально моделируются только процессы, имеющие автоматизируемые шаги (system assisted и/или automated),
детально моделируются только шаги типа system assisted и/или automated,
manual шаги детально моделируются только если результат их выполнения влияет на какие-то шаги system assisted и/или automated,
процессы, содержащие только manual шаги, моделируются только если результат их выполнения влияет на какие-то system assisted и/или automated процессы,
некоторые внешние события выпадают из рассмотрения, если процессы, которые они запускают, выпали из рассмотрения,
приобретают важность для моделирования внутренние события, передающие управление от чисто manual процессов к процессам system assisted и/или automated.

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

Сертификация на ISO 9000,
Полноценный реинжиниринг по JIT, TOC и т.п.,
Документирование бизнес-структуры, должностных инструкций.

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

Задачи проекта внедрения

Основные зависимости между задачами

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

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

RD.020 – RD.030 – RD.070 – BR.020 – BR.080 – MD.020 – MD.060 – DO.070 – TE.110 – PM.050 – CV.140 – PM.080, где

RD.020 – изучение существующих бизнес-процессов
RD.030 – моделирование будущих бизнес-процессов
RD.070 – выявление детальных требований к будущим бизнес-процессам
BR.020 – отображение бизнес-процессов в функциональность приложения
BR.080 – тестирование принятых решений
MD.020 – оценка решений по доработке функциональности приложения
MD.060 – дизайн расширений функциональности приложения
DO.070 – разработка инструкций пользователя
TE.110 – тестирование приложения
PM.050 – установка приложения на систему периода эксплуатации
CV.140 – ввод начальных данных
PM.080 – запуск новой системы

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

при «нехватке» возможностей приложения, касающихся функциональности

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

Эту зависимость можно изобразить следующим образом:

по доработке основного функционала исполняется такая цепочка задач

BR.020 – BR.080 – MD.020

- BR.020 – выявление «дыр» функциональности приложения, предварительное формулирование решения, как можно устранить «дыры»
- BR.080 – первоначальная оценка предложенного предварительного решения
- MD.020 – окончательное формулирование решения, как можно устранить «дыры», оценка трудозатрат
по доработке отчетов

RD.100 – TA.080 – BR.070 – MD.020

- RD.100 – выявление детальных требований к будущим отчетам
- TA.080 – отображение требований в технологические средства, поддерживающие генерацию отчетов
- BR.070 – отображение требований в стандартные возможности приложения, выявление «дыр» в стандартных отчетах, предварительное формулирование решения, как можно устранить «дыры»
- MD.020 – окончательное формулирование решения, как можно устранить «дыры», оценка трудозатрат
по доработке доступа к данным

BR.030 – BR.060 – TA.120 – MD.020

- BR.030 – отображение бизнес-объектов в объекты приложения
- BR.060 – выявление детальных требований к организации доступа к данным
- TA.120 – отображение требований доступа к данным в стандартные возможности приложения, выявление «дыр» в стандартных возможностях доступа к данным, предварительное формулирование решения, как можно устранить «дыры»
- MD.020 – окончательное формулирование решения, как можно устранить «дыры», оценка трудозатрат
по разработке программ конвертации

BR.030 – CV.050 – CV.070

BR.030 – отображение бизнес-объектов в объекты приложения
CV.050 – выявление какие данные и каким образом будут конвертироваться
CV.070 – дизайн программ конвертации

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

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

MD.020 – МD.060 – DO.070

- MD.020 – окончательное формулирование решения, какая нужна разработка
- МD.060 – функциональный дизайн новой разработки
- DO.070 – составление инструкции пользователя
внедрение дизайна расширений БД

MD.050 – MD.100 – MD.120

- MD.050 – дизайн расширения базы данных
- MD.100 – внедрения дизайна в БД
- MD.120 – создание инсталляционного пакета
разработка и тестирование нового кода

MD.060 – MD.070 – TE.030 – MD.110 (TE.20, TE.70) – TE.080 – MD.120

MD.060 – функциональный дизайн новой разработки
MD.070 – функциональный дизайн новой разработки
TE.030 – создание тестов на предмет, как новый функционал будет использоваться вместе со стандартным
MD.110 – создание новой функциональности (включая создание тестов нового кода TE.20 и само тестирование TE.80)
TE.080 – тестирование новых возможностей приложения на предмет использования вместе со стандартными возможностями
MD.120 – создание инсталляционного пакета

После окончания разработки новых возможностей приложения (ряд задач MD, заканчивающийся MD.120) и определения настройки стандартных возможностей (ряд задач RD,BR, заканчивающийся BR.80), приступают к тестированию системы (TE.110). Для проведения тестирования необходимо разработать тесты (TE.40).

Эту зависимость можно изобразить следующим образом:

выработка стандартных настроек приложения определяет инструкции пользователя

BR.080 – DO.070

- BR.080 – тестирование принятых решений
- DO.070 – разработка инструкций пользователя
дизайн новых возможностей приложения определяет инструкции пользователя

МD.060 – DO.070

- MD.060 – функциональный дизайн новых возможностей приложения
- DO.070 – разработка инструкций пользователя
окончание разработки новых возможностей в виде создания инсталляционного пакета позволяет приступить к тестированию

MD.120 – TE.110

- MD.120 – создание инсталляционного пакета
- TE.110 – тестирование (System Test)
разработка инструкций пользователя позволяет приступить к разработке и исполнению тестов

DO.070 – TE.040 – TE.110

DO.070 – разработка инструкций пользователя
TE.040 – создание комплексных тестов (System Test)
TE.110 – тестирование (System Testing)

После тестирования системы (TE.110) систему можно запускать в промышленную эксплуатацию (PM.80). Для этого необходимо:

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

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

Запуск системы можно изобразить следующим образом:

перед запуском систему надо установить и настроить

PM.040 – PM.050 – PM.080

- PM.040 – установка системных компонент периода эксплуатации
- PM.050 – настройка приложения периода эксплуатации (в том числе «заведение» пользователей)
- PM.080 – запуск новой системы
перед запуском надо наполнить систему данными

PM.050 – CV.140 – PM.080

- PM.050 – настройка приложения периода эксплуатации
- CV.140 – конвертация «начальных» данных
- PM.080 – запуск новой системы
перед запуском надо завести пользователей системы

PM.050 – BR.120 – PM.080

- PM.050 – настройка приложения периода эксплуатации
- BR.120 – конвертация «начальных» данных
- PM.080 – запуск новой системы
перед запуском надо построить техническую инфраструктуру

ряд задач процесса TA (начинающиеся с TA.040-2) – выполнение подпроектов построения инфраструктуры – PM.040

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

Если проект с ранних стадий развивается «правильно», то задачи RD.10, RD.20, RD.30, RD.60, RD.70, RD.100, TA.40, TA.50, BR.20 выполняются в «облегченном» виде на предпроектном этапе: от изучения бизнеса и требований к будущей автоматизации к оценке эффективности внедренияприложения.

RD.10

Начинают внедрение две задачи по изучению существующего бизнеса - RD.10 и RD.20, выполняющиеся параллельно.

На этапе RD.10 происходит выявление всех «крупномасштабных» структурных единиц в автоматизируемой области. Что является структурной единицей - зависит от специфики охваченного автоматизацией бизнеса.

Для любого процесса актуальны такие орг.единицы, как 1) субъекты процесса, группирующие роли, участвующие в процессе (организации, подразделения, отделы) и 2) их иерархия (причем может быть несколько разных иерархий по разнымпризнакам). Субъекты должны быть выявлены для каждого бизнес-процесса 2-го уровня (для производства – одни субъекты, для маркетинга – другие).

Если бизнес-процесс охватывает финансовые отношения, то необходимо выявить финансовые орг.единицы:

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

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

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

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

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

RD.20

Параллельно с RD.10 происходит изучение существующих бизнес-процессов (задача RD.20 по AIM).

Направление выполнению RD.10 и 20 придают люди, исполняющие роль бизнес-аналитиков (чаще всего сторонние для предприятия консультанты). Обязательно, чтобы руководители направлений бизнеса (автоматизируемыхобластей) выделяли фиксированное время для проекта. Руководитель проекта от заказчика ответственен за это. Эти люди:

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

Обычно это зам.директора и начальники или зам.начальники подразделений (отделов). В терминах AIM такие люди называются business line manager.

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

Изучение бизнеса в рамках RD.10 и RD.20 происходит на основе интервьюирования бизнес-аналитиками руководителей бизнеса и дополнительно привлекаемых ими людей, а также изучения внутреннихнормативных документов. Чрезвычайно желательно непосредственное наблюдение практики основных бизнес-процессов (работа с реальными исполнителями по несколько дней в каждом «отделе»).

С самого начала проекта важно полноценное участие в проекте так называемых ключевых пользователей (key users по AIM). Это специалисты предприятия, 100% времени выделенные на проект, хорошознающие специфику бизнеса. На каждую бизнес-область должно быть выделено по два человека (на случай, если один заболеет или его придется поменять). От этих людей ожидается, что в ходе проекта они будут:

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

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

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

В ходе выполнения задачи RD.20, как минимум, необходимо выявить

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

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

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

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

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

Формат библиотеки документов и процедуры работы с ней должны быть описаны в отдельном документе (PJM предусматривает CM.10 для этих целей), и доведены до участников проекта. Должен бытьназначен отдельный человек, ответственный за работу с библиотекой (прием документов, помещение в библиотеку в нужном формате, выдачу бумажных копий участникам проекта). Обычно электронную библиотеку документов помещают в подкаталог (с именем типа«Documents Lib») электронной библиотеки проекта.

Для каждого LBPжелательно указать ссылку на нормативные документы и формы документов, «участвующие» в LBP. Для каждой выявленной формы документа желательно выявить его документооборот (гдеи как появляется, кем и как используется).

Насколько детально изучается существующий бизнес (в частности, детализируется ли и документируется ли «внутренность» LBP) – зависит от того, 1) насколько сильно он будет меняться при автоматизации, и 2) насколькоточно видит заказчик, как будет устроен новый автоматизированный бизнес. Чем меньше будет меняться бизнес – тем больше смысла его подробно изучать. Чем лучше видит заказчик устройство нового автоматизированного бизнеса – тем меньше смысла изучатьсуществующий. Понятно, что чем детальнее изучается существующий бизнес – тем легче дальше будет внедрять, но и тем больше будет на это потрачено усилий (времени, ресурсов, денег). Поэтому важно найти золотую середину; ответственный за это –руководитель проекта от консультанта.

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

Бизнес-области (бизнес-процессы высокого уровня),
События,
LBP.

В AIM-M используется специфический шаблон для документирования этого результата (описан в PJM.CM.10).

Вторым результатом задачи RD.20 является сформированная библиотека нормативных документов и форм документов.

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

RD.30

Начиная с задачи RD.30 начинается адаптация бизнеса к использованию приложения и адаптация приложения к использованию в бизнесе.

Ответственные за выполнение задачи - те же бизнес-аналитики, которые выполняли RD.10 и RD.20. Подразумевается, что эти люди также являются специалистами по приложению (по крайней мере, побизнес-возможностям приложения).

Основным приемом, используемым для выполнения RD.30 является

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

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

Новые LBP буду отличаться от старых по двум причинам:

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

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

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

При конструировании новых LBP используется:

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

Поскольку очень вероятно, что документирование подробностей существующих LBP при выполнении RD.20 не проводилось, единственная возможность при конструировании новых LBP учесть особенности существующих LBP – выполнять RD.30 тем же людям, что и выполняли RD.10 и 20. Вообще-то, все эти три задачи уже частично (скорее всего - поверхностно)выполнялись на этапе предпроектного обследования. Поэтому:

надо максимально использовать наработки предпроектных документов,
поскольку 1) достаточно часто предпроектное обследование проводится одними людьми, а проект выполняется – другими, и 2) предпроектное обследование документируется достаточно формально, в целях – продать/купить, а не в целях – внедрить; то именно поэтому приходится выполнять эти задачи как бы повторно.

Желательно конструировать LBP с учетом максимального соответствия:

возможностям приложения,
сложившейся мировой практике в этой отрасли бизнеса.

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

Для каждого шага нового LBP надо понять «участие» системы при выполнении EBF, пока приблизительно:

system assisted step
manual step
automated step

В AIM-M LBP документируются в формате процедур Tutor, один файл процедуры на один LBP. Детализация процедуры LBP проводится до уровня Primary Tasks (Task 1), причем Task 1 = шагу LBP = EBF. Более подробное расписывание шагов обычно не производится.

Для указания участия приложения в выполнении EBF (system assisted step, automated step), в тексте процедуры используются специальные обозначения (расширениестандартного языка процедур Tutor).

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

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

В AIM-M результаты задачи документируются:

LBP в виде множества файлов процедур (по файлу на LBP),
xls файл «Список LBP» со списком LBP и проставленными ссылками на файлы процедур,
графическое изображение бизнес-областей (например в Visio)

AIM предусматривает утверждение результатов RD.30

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

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

RD.60

В рамках задачи RD.60, параллельно с выполнением RD.30, выясняются показатели объема и важности операций в бизнесе.

Для каждого шага LBPвыясняется, каков объем операций (в единицу времени), выполняемых на этом шаге, какова трудоемкость этих операций, как операции распределены по времени. Единица объема, трудоемкости и временизависят от специфики шага (EBF). Как минимум, должно быть выяснено:

как часто возникают события, запускающие LBP; отдельно по каждому событию (пример: несколько раз в год, обычно ближе к концу года),
как часто роль выполняет EBF, не важно по какому событию (пять раз в день); сколько времени уходит на выполнение EBF (один час); сколько людей выполняет подобную EBF (пять человек и трое помогают при заторах), как распределяются EBF по времени (в конце месяца обычно наплыв),
сколько и какого типа документов и их составляющих обрабатывается при выполнении EBF (сто инвойсов вида Х ежемесячно), как объемны документы (редко бывают инвойсы вида Х больше чем на десять строк), сколько времени уходит на обработку документа (1-3 минуты) и т.п.

Одновременно с выяснением объема операций, «вспоминается» важность внедрения каждого нового LBP (или даже EBF) для повышения эффективности бизнеса. Подразумевается, что оценка эффективностивнедрения была определена до проекта внедрения приложения. Эффективность могла быть оценена разными способами:

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

Сбор показателей объема и важности операций помогает в дальнейшем (на задаче BR.20, MD.20) оценить важность оптимизации каждой конкретной операции, EBF, LBPв ходе проекта. Чем больше объем операций, чем более трудоемка операция, чем больше вероятность перегрузки - тем больше положительных результатов для бизнеса даст оптимизация именно этой операции. Чем более важна операция для бизнеса –тем больше усилий в проекте должно быть потрачено на оптимизацию именно этой операции.

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

В AIM-M cобираемые показатели по каждому LBP документируется в файле его процедуры. Для записи используется расширение стандартного языка. Показатели записываютсявнутри записей о событиях и внутри записей шагов специальным стилем.

RD.70

RD.30 и RD.60 – это первая итерация по конструированию новых бизнес-процессов и адаптации готового приложения к бизнесу. Вторая итерация – RD.70 – исследование детальных бизнес-требований кбудущему бизнесу.

Ответственные за качество выполнения задачи - те же бизнес-аналитики – специалисты по приложению, которые выполняли RD.30. На этапе выполнения этой задачи, необходимо окончательно определиться с ключевымипользователями – заменить тех, которые продемонстрировали низкую заинтересованность в участии в проекте или плохо справляются с выполнением порученных им задач.

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

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

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

AIM предлагает пользоваться следующим утверждением:

Каждое требование предопределяет выполнение конкретных шагов конкретных LBP.
И наоборот: каждый шаг определяется конкретными требованиями.

Из этого следует:

Если какое-нибудь требование не может быть отнесено хотя бы к одному шагу LBP - значит или это требование излишнее или не хватает какого-то шага LPB (или целого LBP).
Если к шагу LBP не выявлено никаких требований – значит или этот шаг является не нужным или требование должно быть дополнительно выработано.

RD.70 выполняется следующим образом:

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

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

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

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

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

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

Если на этапе RD.70 уже понятно (хотя бы предварительно) как расписать какую-нибудь EBF до уровня Secondary Tasks (Task 2), то этот шаг процедуры LBP расписывается до уровня Task 2, и бизнес-требования «приписываются» не к шагу, а к Task 2.

Параллельно с выявлением требований на этапе RD.70 для каждого LBP:

В раздел «Бизнес-правила» процедуры LBP заносится информация о всех особенностях, обусловленностях бизнеса, связанных с данным LBP в целом.
В раздел «Activity Preface» процедуры LBP заноситься информация о всех особенностях, обусловленностях, механизмах событий, запускающих LBP. Например, для события «поступление сч/ф» такая доп.информация: сч/ф может поступить вместе с грузом, а может придти по почте, а может поступить по каналам электронного B2B.

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

к ограничению доступа
к доступности системы
к отчетности.

Эти требования могут быть задокументированы на этапе выполнения задачи RD.70 как и остальные требования.

Смысл выполнения RD.70 - выявления требований - состоит в следующем:

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

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

AIM предусматривает утверждение результатов RD.70

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

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

Для справки: AIM использует термин Business Requirements Scenario (BRS) – сценарий бизнес требований – чтобы разделить один LBP нанесколько BRS - принципиально отличающихся «версий» LBP. Считается, что в зависимости от запускающего события или условий, проверяемых в середине LBP, выполнение LBP может идти по разным «веткам» - сценариям. Чтобы подчеркнуть, что в одном LBP заложены несколько сценариев его выполнения, причем к шагам разных сценариев имеются собственные требования, именно для этого вводитсяпонятие BRS.

Например: LBP – обработка сч/ф. BRS1 – обработка сч/ф при наличии предоплаты, BRS2 – обработка сч/ф при оплате по факту.

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

В AIM предусматривается, что каждый BRS документируется отдельно (даже BRS одного LBP) и при этом указывается ссылка на «свой» LBP. Такое разделение имеет смысл, поскольку дальнейший ход внедрения оперирует объектом BRS. Однако отдельное документирование всех BRS одного LBP имеет и существенныенедостатки:

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

Придя в результате опыта к осознанию указанных недостатков, в AIM-M описание LBP не разделяется на описания BRS. Для удобства оперирования сразными BRS одного LBP, в описании процедуры LBP указывается 1) какие BRS содержит LBP и 2) в чем состоят их особенности. Этогооказывается достаточным, чтобы одновременно использовать все преимущества описания одноLBPшных BRS в одном месте и, при необходимости, оперировать разными BRS как отдельнымиобъектами.

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

Группа событий может запускать как бы единый LBP. В зависимости от конкретики события развитие процессаможет идти по разному. В этом случае возможно либо 1) разделение одного LBP на несколько, по одному на каждую принципиально разную реакцию бизнеса, либо 2) выделение в одном LBP нескольких BRS. Например, LBP «оплата поставщику» может быть разделен на два объекта (два LBP или два BRS одного LBP): «оплата аккредитивом» и «оплата с расчетногосчета». Или например: обработка документов по запросу и обработка тех же документов в конце периода может рассматриваться как один LBP с двумя BRS, а может – как два LBP.
В ответ на возникшее событие бизнес осуществляет множество шагов. Окончание реакции бизнеса на событие иногда не может бытьопределено точно (в бизнесе всё со всем связано). Отсюда: соответствующий событию LBP может быть «длиннее» (один) или «короче» (два).
Повторяющиеся действия (одинаковые шаги) в разных процессах могут рассматриваться как отдельные служебные процессы (иоформляться как отдельные служебные LBP, «вызываемые» из основных LBP), а могут и рассматриваться просто как шаги этих процессов.

Из-за наличия этих проблем моделирования, «нарезание» бизнеса на бизнес-процессы (выделение части шагов в отдельные LBP, а также слияние нескольких BRS внутри одного LBP), вообще говоря, произвольное. Однако, проблема «нарезания» в проекте внедрения готового приложения не является принципиальной; «нарезание» принципиально влияет собственно только на одну непринципиальную вещь – оглавление инструкций пользователя(это будет видно дальше).

RD.100

Параллельно RD.70 выполняется задача сбора требований по отчетам (RD.100 по AIM). Эта задача выполняется под координацией тех же консультантов, которыекурируют RD.70.

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

Выделение задачи выявления требований по отчетам отдельно от «общей» задачи выявления требований (RD.70), обусловлено тем, что:

Часто отчеты используются для выполнения каких-то шагов LBP из автоматизируемой области. В этом случае требования к отчету выясняются в рамках RD.70. Однако нередки случаи, когда необходимость существования отчета определяется требованиями вне автоматизируемой области. Например, налоговым законодательством требуется наличие определенного вида отчетов, и если бы не требования законодательства, бизнес спокойно бы обошелся без этих отчетов. Исследуя только бизнес-процессы в автоматизируемой области, очень легко «пропустить» необходимость в таких отчетах.
Такой вид бизнес-деятельности, как анализ статистики бизнеса, является 1) прерогативой руководства, 2) плохо формализуем. Поэтому требования к аналитическим отчетам не удается выяснить, только исследуя бизнес-процессы предприятия.

На этапе RD.100 собираются следующие требования к каждому отчету:

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

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

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

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

AIM предлагает документировать требования к отчетам в отдельном документе Master Report Tracking List(AIM рекомендует шаблон). AIM-M предполагает иную методику документирования результатов RD.70 и последующих задач, связанных с отчетами. В AIM-M все отчеты рассматриваются как объекты, обязательно используемыев каких-то LBP. Если отчет используется вне автоматизируемой области (и LBP, использующего отчет, не задокументирован), то создается «фиктивный» LBP, только в целях документированиярезультатов внедрения по этому отчету.

Такой подход более эффективен, так как:

часто отчет используется для выполнения шага LBP, следовательно, требования к отчету составляют неотъемлемую часть требований к этому шагу, и естественно задокументировать эти требования в процедуре LBP,
следующий шаг по внедрению отчетов – отображение требований к отчетам на функциональность приложения (BR.70 по AIM), аналогичен задаче отображения бизнес-процессов (BR.20), и в AIM-M выполняется как подзадача BR.20.
последующие шаги по внедрению отчетов проходят в рамках тех же шагов, что и внедрение бизнес-функциональности,

Все требования к отчетам документируются в файлах описаний процедур LBP.

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

BR.20

BR.20 – отображение бизнес-процессов в функциональность приложения – это третья итерация по конструированию бизнес-процессов и адаптации готового приложения к бизнесу. На этапе BR.20 происходит 1) созданиедействующей модели программной системы и 2) выявление, чего приложение не умеет делать, а бизнес требует.

Задачу выполняют те же бизнес-аналитики – специалисты по приложению, которые были ответственны за RD.70. На этапе выполнения BR.20 от них в полной мере потребуются глубокие знания спецификиприложения. Напоминание: каждый такой человек закреплен за определенной бизнес-областью.

Для создания действующей модели приложения «специалист по приложению»:

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

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

Если было выявлено, что приложение не обладает требуемой функциональностью, то специалист по приложению инициирует новую ветвь развития проекта – доработку приложения. Для этого он составляет документ, называемый в AIM «Business Requirement Mapping Form» (BRMF, произносится Бэрэмээф). Данный документ будет базой для разработки новой функциональности приложения.

На каждый шаг LBP (EBF), для которого не нашлось готовой функциональности, составляется отдельный BRMF. Если предполагается использование новой функциональности вразных LBP (например, в одном LBP информация об объекте вводится, в другом – корректируется), то для шагов этих LBP составляется один BRMF.

AIM предоставляет шаблон для составления BRMF. Необходимая информация, которая должна быть помещена в BRMF:

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

Возможна неглубокая (схематичная) проработка вопросов по пп. 3 и 4, поскольку в дальнейшем ходе проекта для детальной проработки предусмотрена отдельная задача (MD.20).

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

Результат выполнения задачи BR.20 документируется:

изменением файлов процедур LBP для «найденной» функциональности,
написанием BRMF для каждой дырки в приложении.

В каждом файле процедуры для каждого шага system assisted или automated:

Если для выполнения шага используется существующий функционал приложения (форма, отчет, пакетная программа), то
- в описании шага указывается ссылка на этот функционал (навигация до формы, отчета, пакетной программы или их название) и ссылка на документацию по этому функционалу (для этого используется стандартный язык процедур Tutor),
- если шаг system assisted, то
- - шаг детализируется до уровня Secondary Tasks (Task 2),
  - указывается, как каждый Task 2 должен выполняться с использованием функционала (в поле Х введите дату или нажмите на кнопку Y и т.п.).
Если необходимый для выполнения шага функционал отсутствует, то
- для этого шага разрабатывается BRMF,
- в описании шага, вместо ссылки на функционал, указывается ссылка на эту BRMF,
- в документ «Список BRMF» помещается информация о BRMF, в частности, ссылка на описание BRMF.

Возможна ситуация, когда в приложении имеется функциональность для выполнения шага LBP с учетом большинства бизнес-требований, но остаются требования, не покрытые функционалом. В этом случае, при документированииможно: 1) либо считать, что функционала нет и инициировать доработку приложения через BRMF (этот вариант лучше применять, если много чего не хватает), либо 2) расписывать функционал как существующий и уже на уровне Task2 указать ссылку на BRMF (считая, что только этот Task 2 соответствует непокрытым бизнес-требованиям).

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

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

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

Заметьте: если на этапе BR.20 появляется «слишком много» BRMF, то это наверняка указывает, что реально происходит не внедрение готового приложения, а разработка нового. Это может произойтив трех случаях: 1) приложение «слабое», и в нем нет продвинутых возможностей, 2) приложение «хорошее», но выбрано неадекватно бизнесу, 3) бизнес «кривой», не соответствует сложившихся стандартам в этой отрасли, и требует сильного реинжиниринга.

Обратите внимание: основным объектом, вбирающим (документирующим) результаты проекта в ходе задач RD.30 – BR.20, является файл процедур LBP.

Обратите внимание: ход внедрения часто бывает таким, что по одной бизнес-области (или даже LBP) уже выполнена задача BR.20, а по другим еще не закончена RD.70. Вчастности поэтому понятие «фаза проекта» очень условно; скорее понятие «фаза» может быть отнесено не ко всему проекту в целом, а к прогрессу проекта по отдельным объектам (например, LBP). Например: внедрение по LBP #X находится на фазе выявления требований.

BR.30

Параллельно с BR.20 выполняется задача отображения бизнес-данных (объектов бизнеса) в структуру данных приложения (объектов приложения) и наоборот – структуры данных приложения в бизнес-данные (задачаBR.30 по AIM).

При выполнении задачи применяются понятия

Объект
Сущность (entity)
Атрибут

в стандартной их интерпретации.

Напомним на примере, что понимается под этими понятиями:

Объект – Поставщик, Контракт
Сущность (entity) – Отделение Поставщика, Заголовок контракта
Атрибут – Название отделения, Номер контракта

Задачу выполняют те же специалисты по приложению, что и в BR.20, каждый – по «своим» объектам. Существует проблема распределения объектов по бизнес-областям, т.к. один объект может использоваться в несколькихпроцессах из разных областей. В этом случае, каждый выполняет обработку объекта по «своим» атрибутам объекта.

Основная цель задачи - определить соответствие между всеми атрибутами бизнес-объектов и объектов приложения.

Идентификация объектов происходит следующим образом:

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

Если на предприятии эксплуатируются какие-то приложения, имеющие отношение к автоматизируемой области, то часть бизнес-объектов существуют в виде объектов этих приложений. «Старый» набор приложений называется в AIM «Legacy system». При наличии Legacy system задача по формализации бизнес-объектов существенно упрощается, так как объекты Legacy system уже отображают бизнес-данные.

Чтобы не путаться, о каком приложении идет речь, существующем или внедряемом, AIM называет внедряемое приложение «Target system».

При отображении соответствия бизнес-объектов объектам приложения используются следующие приемы:

Некоторые поля объектов Target system являются обязательными для работы приложения. Соответствующие им атрибуты должны быть «найдены» в бизнес-объектах прежде всего.
Некоторые атрибуты бизнес-объектов являются очевидно обязательными для функционирования бизнеса. Эти атрибуты должны быть отображены в поля Target system прежде всего.
Состав атрибутов бизнес-объекта определяется бизнес-требованиями. Именно поэтому задача BR.30 выполняется одновременно с BR.20 (и является как бы её подзадачей).
Некоторые атрибуты бизнес-объектов Legacy system могут не иметь бизнес-смысл в Target system, по двум причинам: 1) это служебные поля «старого» приложения, имеющие смысл только для этого приложения, 2) бизнес перестраивается, и некоторые старые данные теряют смысл.

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

Результаты задачи документируются в файле «BDMF» (Business Data Mapping Form) в виде таблицы: левая часть таблицы перечисляет бизнес-объекты (с их атрибутами), правая – объекты приложения(с указанием форм и полей форм). Соответствие левой и правой части по строкам показывает соответствие бизнес-данных данным приложения:

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

При отображении бизнес-данных в ходе задачи BR.30, так же как и для отображения бизнес-процессов в ходе задачи BR.20, возможно выявление «дырок»:

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

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

3. Для обязательного поля объекта приложения в существующем бизнесе не находится соответствия. В этом случае, «придумывается» значение по умолчанию. Этозначение указывается в BDMF.

После выполнения BR.30 ход проекта раздваивается:

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

BR.70

AIM предусматривает отдельную задачу BR.70 для отображения собранных на этапе RD.100 требований к отчетам в функциональность приложения. AIM-M предполагает, что отображение требований к отчетности на функциональность приложения происходит на этапе BR.20, аналогично отображению бизнес-процессов. Т.е. в AIM-M задача BR.70 является частью BR.20.

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

Определение технологии получения отчетов выполняется на задаче TA.80. Заметьте TA.80 должна быть выполнена между RD.100 и BR.70.

Задачу BR.70 выполняют те же консультанты, что и BR.20, распределяя отчеты по «своим» LBP. Возможно, понадобиться участие экспертов по выбранным на TA.80 технологическим средствам (если консультант не обладает достаточной квалификацией по выбранному средству).

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

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

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

BR.80

BR.80 – тестирование решений – это четвертая итерация по конструированию бизнес-процессов и адаптации приложения к бизнесу. На этапе BR.20 происходит формальная проверка выработанных на BR.20 решений по настройке и доработке приложения.

После BR.20 уже существует 1) работающий прототип приложения и 2) решения, что необходимо доделать в приложении.

На этапе BR.80 происходит формальное тестирование принятых на BR.20 решений, призванное проверить: 1) соответствуют ли продемонстрированные возможности прототипа приложения требованиямбизнеса, 2) будут ли соответствовать возможности приложения всем бизнес-требованиям после доработки приложения. Важно понять, что на данном этапе не выполняется анализа соответствия «стоимости решений» «достигаемым возможностям», а только проверяетсясоответствие решений требованиям.

После положительного ответа о правильности принятых решений продолжается дальнейшее развитие проекта, иначе ход внедрения частично (по какому-то LBP или группе связанных LBP) возвращаетсяназад вплоть до RD.30.

Для тестирования всех решений тестируется каждый LBP; для тестирования LBP тестируется каждый его BRS. Процесс тестирования состоит из двух подзадач: подготовки ктестированию и выполнению тестирования. Будем называть эти подзадачи BR.80-1. и BR.80-2.

Протестировать BRS – означает:

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

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

Определение: Тестовый сценарий – это BRS с конкретными данными. Данные, используемые при выполнении тестового сценария – тестовые данные.

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

Тестовые данные должны быть подготовлены для каждого «потребляющего» данные Task 2. Выделяют данные двух видов использования:

вводимые в приложение или другую систему (например, вписываемые от руки на бланк) во время выполнения Task 2; такие данные в AIM называются User Input,
заранее введенные в приложение и используемые при выполнении Task 2; такие данные в AIM называются Preexisting Data.

AIM предусматривает, что Preexisting Data могут быть введены в приложение не действиями пользователя, а через процедуры автоматической конвертации. AIM-Mрекомендует все данные вводить вприложение действиями пользователей. При этом важна последовательность выполнения сценариев: сценарии, потребляющие Preexisting Data, должны быть выполнены после сценариев, помещающих эти данные в приложение.

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

Заметьте, в AIM-M тестовый сценарий выполняется в двух целях:

протестировать решение по соответствующему ему BRS,
внести в приложение данные, используемые как Preexisting Data в другом сценарии.

Часто (но не всегда) выполнение сценария «убивает двух зайцев», однако нередки случаи, когда BRS уже протестирован, но необходимо выполнить аналогичный сценарий только для того, чтобы породить Preexisting Dataдля выполнения другого сценария.

Для подготовки к тестированию (как выполняется BR.80-1):

Для каждого BRS, в текст процедуры LBP вписываются конкретные тестовые данные на уровне Task 2 (если на уровне Task 2 было «в поле Х введите дату», то надо написать «в поле Х введите 01.04.2003»). Таким образом, текст процедуры превращается в текст тестового сценария.
Определяется последовательность выполнения тестовых сценариев в цепочке, исходя из 1) разделов Activity Preface (Prior Activity information) процедур LBP, 2) требуемых Preexisting Data.
В отдельном документе документируется последовательность выполнения тестовых сценариев в каждой цепочке. В одной цепочке часто оказываются тестовые сценарии одного LBP (например, при тестировании цепочки необходимо дважды разместить заказ по одному контракту).

Подбор тестовых данных (и построение цепочек) является непростым делом:

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

Подготовку данных для тестирования и выполнение тестирования выполняют ключевые пользователи. Координацию всего процесса тестирования должен выполнять человек, хорошо понимающий методику и цели тестирования. Имеет смысл назначить наэту роль ведущего ключевого пользователя. Предварительный «погружение в предмет» этого человека должен провести руководитель проекта со стороны консультанта, и кто-то из консультантов (руководитель проекта или консультант, который участвовал вRD.30-BR.20) должен курировать этот процесс (возможно, первое время).

Результатом BR.80-1 является:

набор файлов тестовых сценариев,
документ, содержащий информацию о всех тестовых цепочках, а также последовательности выполнения тестовых сценариев в каждой цепочке (в AIM-M он называется «Последовательность тестов» или «Testing Scenario Chain List»).

В документе «Последовательность тестов» должно быть три раздела, каждый «работающий» в своих целях:

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

Желательно файлам с текстом тестовых сценариев давать такие имена, чтобы было видно по какому BRS он создан, и является ли он «дублем» (т.е. создан не для тестирования, а для создания Preexisting Data).

Подразумевается, что к началу этапа BR.80-2 ключевые пользователи имеют поверхностные знания, достаточные, чтобы пользоваться приложением – выполнять тестовые сценарии. Как правило, эти знания должны им передатьконсультанты, вместе с которыми они выполняли задачи RD.30-BR.20. Оптимально происходит обучение ключевых пользователей на этапе выполнения задачи BR.20:

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

На этапе тестирования (BR.80-2):

Тестовые цепочки распределяются для выполнения между ключевыми пользователями (по сферам специализации, бизнес-областям). Назначения фиксируются в документе «Последовательность тестов» в разделе, предназначенном для отслеживания прогресса тестирования.
Ключевые пользователи последовательно выполняют свои цепочки сценарий за сценарием. При возникновении проблем с выполнением тестов, пользователи совместно со «своим» консультантом пытаются разобраться в проблеме.
Обнаружив при тестировании проблему, неустранимую в оперативном порядке, пользователь описывает её прямо в тексте тестового сценария (используется расширение стандартного языка Tutor). Одновременно, пользователь отмечает факт обнаружения проблемы в документе «Последовательность тестов» в разделе результатов.

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

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

Когда тестирование закончено (возможно – частично) консультант, выполнявший RD.30-RD.20, должен проанализировать все обнаруженные проблемы по «своим» тестам. В зависимости от серьезностипроблемы, ход внедрения по «проблемному» бизнес-процессу возвращается

на этап RD.30, если требуется реинжиниринг процесса,
на этап RD.70, если необходимо скорректировать бизнес-требования (вспомнили забытые, решили от каких-то отказаться),
на этап BR.20, если выявилось, что решение не удовлетворяет требованиям бизнеса.

При обнаружении серьезных проблем в решениях по одному бизнес-процессу, могут произойти изменения и в других связанных процессах (напомним, «нарезание» бизнеса на процессы – условное).

После проработки проблем (RD.30, RD.70, BR.20), ход внедрения по «проблемным» процессам опять возвращается к этапу BR.80. И так до тех пор,пока решения по бизнес-процессу не будут удовлетворять требованиям бизнеса. Более того, и в дальнейшем ходе проекта (как это станет ясно ниже по тексту) нормальным является возврат хода проекта к начальным задачам моделирования.

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

Заметьте, именно на этапе первого тестирования происходит мощное смешивание фаз проекта: по одним бизнес-процессам ход проекта уже перешел за BR.80, а по другим – вернулся к RD.30.

Отслеживание прогресса тестирования происходит по документу «Последовательность тестов», отслеживание прогресса проекта по задачам RD.30-BR.80 (а также некоторым последующим) происходит подокументу «Список LBP».

MD.20

Все задачи в процессе MD– Module Design – посвящены разработке нового функционала.

Задача MD.20 – оценка решений по дополнению функциональности приложения – это новая ветвь проекта, инициированная на этапе BR.20 обнаружением недостатков функциональности приложения. Можносчитать, что по бизнес-процессам, требующим расширения функциональности, MD.20 – это пятая итерация по конструированию бизнес-процессов и адаптации готового приложения к бизнесу (RD.30 – первая,RD.70 – вторая, BR.20 – третья, BR.80 – четвертая).

На этапе MD.20 происходит

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

При выполнении MD.20, для каждого BRMF должен быть сначала проведен дополнительный анализ изложенных в BRMF вопросов. Вспомните, что на этапе BR.20 в BRMF было помещено описание следующих вопросов:

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

Возможно, что уже на этапе BR.20 были детально проработаны вопросы пп. 3 и 4. Если нет, то необходимо их проработать. Проработку п.3 должен выполнять тот же консультант, что выполнял BR.20.А вот для проработки п.4 у него может не хватить квалификации. В этом случае, подзадача по п.4 выполняется совместно с человеком, обладающим квалификацией дизайнера по новым приложениям и, одновременно, являющимся специалистом по приложению.

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

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

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

После того, как готовы

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

после этого руководителем проекта и спонсором проекта принимается решение, будет ли разрабатываться новая функциональность. Если будет, то ход проекта по LBP, связанным с BRMF, продолжаетсяпо ветке MD. Если нет, то происходит пересмотр бизнес-требований в сторону ослабления и возврат к задаче RD.70, а то и RD.30.

Решение по разработке («добро» или «пересмотр требований») документируется в файле «Список BRMF». В дальнейшем ходе проекта этот документ будет использован для отслеживания процесса разработки новойфункциональности в разрезе каждой BRMF.

Обратите внимание: единицей, по которой отслеживаться ход проекта в процессе разработки, является каждый отдельный BRMF. Отслеживание прогресса разработки новой функциональности в рамках задач BR.20-BR.80, задач MD и задач тестирования (TE.20, TE.30) происходит по документу «Список BRMF».

Подумайте: каждый раз при возврате хода проекта к более ранним стадиям (что является нормальным!) увеличивается объем работ и длительность проекта. Это порождает две проблемы:

Именно из-за итеративности внедрения практически ни один проект не укладывается в сроки и бюджет (спланированные без запаса). Если цель – уложиться всроки и/или бюджет – является первоочередной, то необходимо мириться либо 1) с «подгонкой» бизнеса под приложение (перекраивать бизнес под приложение, отказываться от части бизнес-требований), либо 2) с ограниченным, неудобным использованиемприложения в бизнесе (реализовывать walkaround-ы).
Из-за невозможности или нежелания расширить бюджет проекта, внедрение останавливается на середине.

MD.50, MD.60, MD.70

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

MD.50, MD.60, MD.70 – задачи по разработке дизайна нового приложения. Основным документом (входом) для выполнения этих задач является BRMF. Дизайн и дальнейшая разработка новой функциональности ведется длякаждого BRMF в отдельности.

На этапе MD.50 дизайнер разрабатывает модель данных, необходимую для реализации нового функционала, и разрабатывает дизайн базы данных под эту модель.

На этапе MD.60 дизайнер разрабатывает функциональный дизайн нового приложения. Функциональный дизайн будущего приложения можно рассматривать как прототип Инструкции по использованию функций этого приложения (UserReference Manual).

Для реализации решения по одному BRMF может использоваться несколько «функционалов». Например, одновременно три: 1) доработка существующего «окна»-формы, с которой работает пользователь, 2) разработка новойформы, 3) доработка существующего отчета. В функциональном дизайне документируется User Reference Manual по каждому «функционалу» в отдельности.

На этапе MD.70 дизайнер разрабатывает технический дизайн нового приложения.

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

Во многих случаях, когда новая функциональность не сложная, задачу MD.60 может выполнить тот же специалист по приложению, что и писал на этапе BR.20 BRMF под этуфункциональность.

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

Существуют случаи, когда дополнительную функциональность приложения можно реализовать без написания нового кода, используя встроенные возможности приложения по расширению функциональности (например, в Oracle ProfessionalApplications это Flexfield). В этом случае задачи MD.60 и MD.70 не выполняются.

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

В процессе дизайна, окончание каждой задачи по каждому BRMF отмечается в файле «Список BRMF» и таким образом отслеживается прогресс процесса разработки.

После готовности дизайна приложения ход проекта по процессу разработки раздваивается:

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

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

Заметьте: из-за процесса разработки/доработки функциональности в очередной раз происходит мощное смешивание фаз проекта: по одним BRMF разработка уже закончена и интегрирована в приложение (т.е. законченафаза Build), а по другим – процесс разработки еще не начинался (т.е. проект по этим BRMF находится в стадии Solution Design).

MD.100, MD.110, MD.120

После выполнения дизайна новой функциональности приложения в рамках MD.50, MD.60, MD.70 начинается разработка функциональности:

MD.100 – создание/модификация структур данных,
MD.110 – создание/модификация программ (отчетов, форм, …)
MD.120 – создание инсталляционных пакетов.

После окончания задач MD (в том числе тестирования в рамках Unit Test) переходят к тестированию приложения в рамках System Test (TE.80).

DO.70

На этапе выполнения этой задачи происходит уточнение описания процедур LBP.

Идентификация этой задачи как DO.70 не совсем соответствует пониманию AIM, поскольку в AIM используется отличная от AIM-M методика документирования результатов задач процесса моделирования (RD и BR) и процесса документирования (DO). AIM предусматривает, что документ-результаткаждой задачи процесса RD, BR и DO, составляется «с нуля». Для переноса наработок предыдущих задач в последующие, текст предыдущих документов может частично копироваться, а может ипереписываться в новом тексте. Это относиться и к задаче DO.70 - написанию User Guide.

Как вы помните, в AIM-M используется модифицированная методика, позволяющая постепенно перейти от описания бизнес-процесса к готовности инструкций пользователя, причем в одном документе(описании процедуры LBP в формате Tutor).

Задача DO.70 выполняется непосредственно по готовности функционального дизайна какой-нибудь BRMF. Задача выполняется консультантом, который курировал выполнение RD.30-BR.20 по LBP, имеющим ссылку на эту BRMF.

При выполнении DO.70:

по каждой BRMF, изучается функциональный дизайн (фактически – User Reference Guide) новой функциональности приложения,
определяется, c какими LBP связана BRMF,
для тех шагов процедуры LBP, где стоит ссылка на BRMF, процедура детализируется так же, как это было сделано на BR.20 для стандартной функциональности:
- шаг детализируется до уровня Secondary Tasks (Task 2),
- указывается, как каждый Task 2 должен выполняться («в поле Х введите дату» или «нажмите на кнопку Y» и т.п.),
в документах «Список BRMF» и «Список LBP» отмечается, что модификация процедуры LBP по новой функциональности проведена (для отслеживания прогресса проекта).

Задачи тестирования TE.20-TE.70, TE.30-TE.80, TE.40-TE.110

AIM предусматривает несколько видов тестирования:

Unit Test – тестирование нового (разработанного в рамках проекта) функционала приложения:

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

Link Test – тестирование нового (разработанного в рамках проекта) функционала приложения в целях проверить его работу как части приложения.
System Test – тестирование приложения на использовании в бизнесе.
Regression Test – тестирование приложения на работоспособность после установки патчей.

Разработка (TE.20) и выполнение (TE.70) unit test по большей части осуществляется программистами в процессе разработки нового функционала. Вообще говоря, все ошибки разработки должны быть обнаружены приunit тестировании.

Одновременно с разработкой функционального дизайна новых возможностей приложения (MD.60) дизайнер разрабатывает link test для тестирования новой функциональности приложения (задачаTE.30 по AIM). На каждый документ функционального дизайна разрабатывается отдельный link test. Можно сказать, что дизайн приложения – это теоретический взгляд на то, как должно работатьприложение, а link test – это подборка примеров, демонстрирующая, как приложение должно работать.

Link test на разрабатываемую функциональность включает тестирование тех LBP, шаги которых используют эту функциональность. Разработка link теста аналогична задаче BR.80-1 с двумя допущениями:

тестовые сценарии составляются только на те LBP, которые используют разрабатываемую функциональность,
тесты составляются так, как будто новая функциональность уже существует в приложении.

Выполнение link теста (задача TE.80) аналогична задаче BR.80-2 с учетом тех же допущений.

Задача TE.40 – подготовка тестов системы (для System Test).

Задача TE.110 – исполнение тестов системы.

Задачи TE.40, TE.110 выполняются аналогично BR.80-1, BR.80-2 со следующими дополнениями:

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

За организацию процесса тестирования

бизнес-решений в задачах BR.80-1 – BR.80-2
Link Test в задачах TE.30 – TE.80,
System Test в задачах TE.40 – TE.110

должен отвечать человек, хорошо понимающий методику и цели тестирования. Имеет смысл назначить на эту роль ведущего ключевого пользователя. Предварительный «погружение в предмет» этого человека должен провести руководитель проекта состороны консультанта, и кто-то из консультантов (руководитель проекта или консультант, который участвовал в RD.30-BR.20) должен курировать этот процесс (возможно, первое время). Подготовку данных длятестирования и выполнение тестирования выполняют ключевые пользователи.

Все задачи тестирования выполняются итерационно, до тех пор, пока не будут устранены все замечания. После выполнения последнего успешного тестирования переходят к установке Production system в рамкахзадачи PM.50.

BR.110

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

В реальном проекте затруднительно определить момент окончания настройки, потому что

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

Вспомните, что в процессе адаптации «приложение <–> бизнес» настраивается действующая модель приложения. В ней и аккумулируются все настройки приложения в процессе всего внедрения. Если тестирование системы происходит наотдельном экземпляре приложения, в Test environment (описание Project environment см. TA.40-1), то тогда наиболее корректные настройки накапливаются именно в этом экземпляреприложения.

AIM-M предусматривает, что настройки приложения формально не документируются до тех пор, пока не начинается задача PM.50 – настройка Production system (экземпляраприложения, предназначенного для «боевой» эксплуатации). Настройка Production system происходит путем переноса настроек, выверенных на рабочей модели приложения, в среду Production environment. В ходепереноса все настройки документируются.

Для документирования настроек одновременно используются несколько изобразительных средств:

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

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

BR.120

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

В ходе BR.120 происходит планирование аккаунтов пользователей системы.

Задача выполняется следующим образом:

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

Результат задачи документируется в файле Application Security Architecture в разделе User Access в виде таблицы: слева - Организация, ФИО, должность, …, справа – системныенастройки.

В AIM-М задача BR.120 выполняется непосредственно перед выполнением PM.50. Задачу выполняют те же специалисты по приложению, что и TA.120.Принимают участие ключевые пользователи и администратор системы.

Результат задачи TA.120 используется при настройке Production system в ходе задачи PM.50. Необходимо понимать, что в ходе эксплуатации системы пользователи приложениябудут изменяться. Поэтому таблица User Accessдолжна тщательно поддерживаться администратором системы периода эксплуатации.

Связанные задачи процесса TA

AIM предусматривает задачу TA.40 для выполнения множества разноплановых действий, связанных к технической архитектурой и архитектурой приложения.

В частности, на этапе TA.40 выполняется задача планирования Project environment. Эта подзадача в AIM-M условно называется TA.40-1.

AIM использует понятие Application Environment для обозначения среды эксплуатации приложения:

Environment – это техническая инфраструктура, т.е. среда для эксплуатации приложения. Environment и Application Environment – синонимы.
System – система периода эксплуатации, т.е. приложение (Application), установленное в специальной технической среде (Environment).

Словом Production в словосочетаниях

Production environment
Production system

обозначают «используемое в бизнесе», «периода эксплуатации».

Словом Project в словосочетаниях

Project environment
Project system

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

В процессе внедрения подготавливается Production environment для пуска Production system. Для внутренних целей внедрения используется Project environment. В процессевнедрения для разных целей необходимо использование нескольких экземпляров (instance) приложения:

Development environment – среда, позволяющая разрабатывать новую функциональность и тестировать её. В том числе в этой же среде создаются и тестируются программы конвертации.
Demo environment – среда, позволяющая демонстрировать возможности приложения, создавать действующую модель приложения.
Test environment – среда для тестирования на уровне TE.80.

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

В качестве Demo environment имеет смысл использование преднастроенной (производителем) версии приложения, позволяющей быстро продемонстрировать базовые возможности приложения. Для Oracle EBS такая преднастроенная версия называется Vision.

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

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

Конкретная конфигурация Project environment зависит от специфики проекта и должна курироваться опытным руководителем проекта (как правило, со стороны консультанта), чтобы, с одной стороны, учесть все потребностипроекта, с другой – не разорить заказчика :)

Задача TA.40-1 выполняется условно независимо от других задач проекта как можно раньше, так как на построение Project environment может понадобиться существенное время, а безготового Project environment и, в частности, Demo environment, невозможно приступить к построению модели приложения.

Сервера периода внедрения после окончания проекта могут быть использованы:

как резервные сервера к основному серверу Production environment,
как среда развития приложения, отработки нестандартных ситуаций, разработки новых отчетов.
для тестирования обновлений кода приложения и/или системных компонент, перед установкой их на Production environment (Regression testing).

Решения по Project environment должны быть задокументированы, желательно с рисунками, изображающими каждый вид Project environment. AIM предоставляет шаблон такогодокумента (TA.40 по AIM.2.5).

Вторая часть задачи TA.40 посвящена планированию концептуальной архитектуры. В AIM-M эта подзадача условно называется TA.40-2.

Под планированием концептуальной архитектуры подразумевается определение:

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

AIM применяет понятие Data Center чтобы назвать:

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

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

Выполнение TA.40-2 начинается с выяснения, какие компоненты концептуальной архитектуры планируются с точки зрения использования приложений:

какие модули приложения будут использоваться для Production system,
какие внешние (другие) бизнес-приложения будут использоваться совместно с модулями приложения,
где будут установлены модули приложения (в каких Data Center),
как будет обеспечиваться взаимодействие модулей приложения, установленных в разных Data Center,
как будет обеспечиваться доступ к приложению с рабочих мест пользователей,
как будет обеспечиваться взаимодействие модулей приложения и внешних бизнес-приложений.

Определение того, какие модули приложения будут использоваться в Production system, реально является задачей маппинга (BR.20). Однако, если проводилось предварительное обследованиесопоставимости приложения бизнес-требованиям, то приблизительно известно, какие модули приложения будут использоваться для решения каких задач. AIM рекомендует уже на начальной стадии проекта хотя бы вчерне определиться какиемодули в каких Data Center будут установлены. Это необходимо, чтобы как можно раньше запустить процессы построения Production environment (может понадобиться приобретение или построение каких-то новыхкомпонент).

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

В случае с несколькими Data Center необходимо спланировать решение следующих вопросов:

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

Если приложение будет взаимодействовать с другими приложениями (АСУТП, электронные платежи, электронныq прием заказов и т.д.), то необходимо спланировать, какие для этого понадобятся интерфейсы (программные иаппаратные компоненты).

Параллельно с планированием концептуальной архитектуры с точки зрения используемых приложений, планируется, какими техническими системами будет обеспечено функционирование приложений. Эти части задачи связаны друг с другом, т.к.ограничения технических средств влияют на использование приложений. Например: 1) отсутствие адекватных каналов связи между территориально распределенными подразделениями обуславливает организацию Data Center на каждойтерритории, 2) нежелание руководства возиться с организацией нескольких Data Center, из-за сложности их эксплуатации, вынуждает строить корпоративную магистраль, чтобы все подразделения могли работать с одним DataCenter.

На ранних стадиях проекта возможны разные варианты построения концептуальной архитектуры. Все они должны быть конспективно описаны с анализом особенностей каждого. AIM предоставляет шаблон такого документа(TA.40 по AIM.2.5).

Третья часть задачи TA.40 посвящена бизнес-архитектуре приложения. В AIM-M эта подзадача условно называется TA.40-3.

Под определением бизнес-архитектуры приложения понимается планирование использования специализированных параметров (настроек) приложения, предназначенных для отображения организационных элементов бизнеса, тех самых структурных единиц,выявление которых началось на этапе RD.10.

В Oracle EBS существуют специализированные параметры бизнес-архитектуры:

Set of Books
Balancing Entity
Inventory Organization
HR Business Groups and Organizations
Legal Entity
Operating Unit

На этапе TA.40-3 должны быть приняты предварительные решения по использованию параметров бизнес-архитектуры приложения. Уточнение использования этих параметров происходит при выполнении задачи TA.120 – отображении требования доступа на возможности приложения.

Предварительные решения по бизнес-архитектуре приложения должны быть задокументированы. AIM предоставляет шаблон такого документа (TA.40 по AIM.3).

До тех пор, пока не будут ясны все вопросы

какие модули приложения и как будут использоваться, что определяется в задаче отображения бизнес-процессов в функциональность приложения (BR.20),
по разработке дизайна интерфейсов с внешними приложениями (MD.60),
по разработке технологии системы отчетов (TA.80),
по отображению требования доступа на возможности приложения (TA.120),

задача определения концептуальной архитектуры (TA.40-2) и бизнес-архитектуры (TA.40-3) не может быть окончательно закончена.

AIM-M предполагает, что первая итерация TA.40-2 и TA.40-3 выполняется параллельно задаче BR.20. Затем результаты задачи итеративно (возможнонесколько раз) пересматриваются в ходе проекта по мере продвижения проекта по задачам BR.20, MD.60, TA.80, TA.120. Необходимо понимать, что, если результатыпоследних задач пересматривается (а это нормально, особенно для BR.20), то результаты TA.40-2 и TA.40-3, возможно, тоже потребуют пересмотра.

По мере готовности результатов задачи TA.40-2 (параллельно этой задаче) приступают к задаче TA.70 – определению плана развертывания Production system. AIMназывает этот план - Deployment Plan.

Под Deployment Plan понимается:

порядок запуска Data Center (не обязательно развертывание Production system по всем Data Center должно проходить параллельно, важно быстрее запустить те Data Center, которые дадут больший эффект),
порядок запуска модулей приложения (не обязательно внедрение по всем модулям должно проходить параллельно, важно быстрее внедрить те модули, которые дадут больший эффект).

Результаты и обоснования выработанного плана должны быть задокументированы в виде план-графика. AIM предоставляет для этого шаблон в виде word файла, но возможно и использовать свойформат.

Очевидно, что разработка Deployment Plan не может быть окончательно закончена, пока не закончена задача TA.40-2. Однако ранняя разработка Deployment Plan (пусть даже предварительной версии) помогает осознатьакценты в управлении проектом.

По мере готовности результатов задачи TA.40-2 (параллельно этой задаче) приступают к задаче TA.100 – планирование архитектурных подсистем (TA.100) и TA.110 – планирование архитектурных подпроектов (TA.110). Эти две задачи так взаимосвязаны, что выполняются как одно целое.

На этапе TA.100 для каждого отдельного компонента технической инфраструктуры (называемого в AIM подсистемами) выявляются детальные требования, которым он должен соответствовать. Преждевсего, эти требования определяются требованиями Production system, однако принимается во внимание, что подсистемы могут использоваться не только для поддержки эксплуатации Production system, но и дляэксплуатации других бизнес-приложений (например, по корпоративной сети будут не только передаваться данные приложения, но и электронной почты и IP-телефонии).

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

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

Для каждого подпроекта должны быть, как минимум, описаны

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

AIM предоставляет шаблоны для документирования результатов задач TA.100 и TA.110. Однако эти документы могут быть составлены и в принятом в организации виде (на территории СНГ болеераспространен шаблон ТЗ).

После того, как подпроекты спланированы (в рамках TA.110), они передаются на исполнение (обычно, в IT-службы и/или отдельным субподрядчикам). Важно, чтобы исполнение подпроектов управлялосьсинхронизировано с управлением основного проекта, т.к. проблемы в подпроектах могут оказать влияние на основной проект.

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

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

По мере готовности результатов задачи TA.40-2 приступают к ряду задач процесса TA по планированию архитектуры серверной платформы и сети передачи данных.

AIM разделяет это планирование на ряд задач TA.150, TA.160, TA.170, TA.180. Однако решаемые каждой задачей вопросы так сильно взаимосвязаны, что реально они все выполняются как одна задача.

На этапе TA.150-180 необходимо определить:

конфигурацию системных компонент приложения (для Oracle EBS это: сервер приложений и сервер БД),
конфигурацию серверов (hardware),
конфигурацию локальной сети и интерфейса с интернет/интранет.

Любое готовое приложение предусматривает определенную конфигурацию своих системных компонент. Эта конфигурация может меняться в определенных пределах. Ключевые параметры, от которых принципиально зависит работа приложения, должны бытьспланированы до начала инсталляции системных компонент. Остальные параметры могут быть задокументированы уже после установки Production system.

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

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

Задачи TA.150-180 реально связаны с задачей TA.40-2 в части планирования технической инфраструктуры. Не определив конфигурацию hardware-серверов и интерфейса с интернет/интранет, невозможнозапустить подпроекты по приобретению серверных платформ и построению/аренде телеком.сети.

После окончания задач TA.150-180 запускается процесс приобретения серверов и построению/аренде интернет/интранет. Можно рассматривать это как переход к задачам TA.100, TA.110 поподпроектам hardware-серверов и интерфейса с интернет/интранет.

Заметьте: Структура задач процесса TA в AIM v.3 существенно отличается от приведенной в AIM v.2.5 и является более простой и продуманной. В AIM-Mприменяется еще более простой подход к выполнению задач процесса TA: все вышеупомянутые задачи представляют собой как бы одну задачу, результат которой постоянно уточняется на протяжении всегопроекта. AIM-M выделяет только четыре «самостоятельные» задачи из процесса TA:

TA.50 – ревизия используемых бизнес-систем.
TA.40-1 – планирование Project Environment.
TA.80 – определения технологии получения отчетов.
TA.120 – отображение требований доступа в возможности приложения.

TA.80

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

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

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

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

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

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

Формы IAS,
отчеты Oracle Portal,
Oracle Discoverer.

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

Data Warehouse,
OLAP.

Пока не выполнена задача TA.80, невозможно приступить к задаче BR.20 (в части BR.70). В самом деле, реализация отчетов не может быть начата, пока не определенытехнологические средства их получения, поскольку технологии влияют на идеологию получения и использования отчетов, их внешний вид. Например, дизайн статичных отчетов, получаемых средствами Oracle Reports, достаточнопринципиально отличается от дизайна отчетов Oracle Portal.

CV.50

Процесс CV содержит задачи, нацеленные на перенос существующих в бизнесе данных (в бумажной или электронной Legacy system) во внедряемое приложение (Target system).Перенос должен быть выполнен до запуска приложения в эксплуатацию на фазе Transition.

Основной цепочкой задач по переносу данных является:

BR.30 - CV.50 – CV.70 – CV.90 – CV.140

Непосредственно сам перенос данных происходит на задаче CV.140. Остальные задачи посвящены подготовке к переносу.

В данном тексте перенос данных называется «conversion» (как в AIM). В жизни также применяются термины: конвертация данных, загрузка данных, начальная загрузка, начальный ввод данных и ихсочетание.

AIM-М различает разные категории данных (объектов), поскольку для каждой категории существует свой подход к conversion:

Setup данные. Могут быть введены в приложение только служебными операциями настройки приложения. Яркий пример setup данных: валюта, бухгалтерские счета, типы номенклатурных позиций. Особенностью setup данных является «восприятие» их приложением: для всех setup объектов, приложение предусматривает настройку предопределенных реакций на каждый экземпляр объекта. Например: по иностранной валюте приложение будет автоматически производить пересчет в нац.валюту, причем с учетом вида валюты. Другой пример: по номенклатурной позиции типа «expenses» приложение будет автоматически списывать товары при приходе, а по типу «goods» - класть на склад.
Пополняемые данные. Вводятся в приложение операциями пользователей. Приложение «не различает» экземпляры пополняемых данных между собой. Пример: номенклатурные позиции, поставщики.
История изменения объектов (транзакции).

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

В зависимости от бизнес-требований, conversion может выполняться с разной степенью детализации транзакций по объекту:

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

Conversion транзакций – трудоемкий процесс, однако

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

AIM различает два способа проведения conversion с точки зрения применения автоматизированных средств:

manual – ввод данных в приложение «ручками» через предназначенные для этого формы ввода.
programmatic - ввод данных в приложение с использование специальных программ.

Основной плюс manual conversion перед programmatic - не требует разработки дополнительных программ. Основной минус – требует существенно больше времени. Всегда, когда возможно (еслипозволяет время), пользуются методом manual conversion.

AIM-М различает два способа проведения conversion по отношению к моменту пуска приложения в эксплуатацию:

before Transition – ввод данных в приложение осуществляется до фазы Transition и не требует остановки бизнеса. В это время Target system еще не используется бизнес-пользователями. Способ before Transition применяется, чтобы «разгрузить» конечную стадию проекта – запуск приложения в эксплуатацию. Однако, он имеет существенный минус: как только данные введены в приложение, необходимо осуществлять постоянную актуализацию данных (в то время как «нормальные» процедуры Target system еще не работают). Поэтому таким способом можно вводить только медленно меняющиеся объекты.
during Transition - ввод данных в приложение во время фазы Transition. Это обычно означает, что бизнес останавливается (чтобы не обрабатывать новых данных), и за это время выполняется conversion.

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

Задача CV.50 состоит из нескольких последовательно выполняемых частей:

Первым делом выясняется, данные каких объектов должны быть введены в приложение до момента его запуска в эксплуатацию. Возможно, данные некоторых объектов не будут переноситься из Legacy system, а будут заводиться в приложении уже во время эксплуатации по мере необходимости.
Затем выясняется, какие из этих объектов будут вводиться через setup, а какие - через conversion.
Затем выясняется, какие из conversion объектов будут вводиться через manual conversion, а какие – через programmatic.
Для каждого conversion объекта определяется формат, в котором подготавливаются данные объекта из Legacy system для загрузки в Target system.

По сравнению с AIM в AIM-M из задачи CV.50 вынесена часть работ (в задачу CV.70), требующая знаний структуры храненияданных в приложении. Это сделано для того, чтобы задачу могли выполнять те же специалисты по приложению, что и BR.30, каждый – по «своим» объектам.

Для выяснения, какие данные (каких объектов) должны быть перенесены из Legacy system, придерживаются следующего:

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

Для выяснения, какие объекты будут вводиться через setup, а какие - через conversion, придерживаются следующего:

только setup объекты, имеющие очень большое число экземпляров, могут рассматриваться как подлежащие conversion.

Для каждого conversionобъекта принимается решение, каким способом (manual или programmatic) будет проводиться conversion этого объекта:

Выявляются бизнес-требования по необходимости наличия истории транзакций объекта в Target system.
Выявляется зависимость объекта от других объектов. Их данные должны быть введены в приложение до ввода самого объекта.
Принимается решение, все ли экземпляры объекта будут переноситься в Target system или только отвечающие определенному критерию.
Оценивается объем данных по этому объекту (число экземпляров объекта) в Legacy system с учетом критериев отбора.
Если объем данных (с учетом требований по истории транзакций) мал, то способ conversion - manual (не важно before или during Transition), если нет, то
Замеривается скорость ввода одного экземпляра объекта в приложение через предназначенные для этого формы ввода (с учетом требований по истории транзакций).
Вычисляется время ввода всех имеющихся в Target system экземпляров объекта (в человеко-часах) при использовании manual conversion по формуле: скорость ввода одного экземпляра умножить на число экземпляров. Определяется, сколько человек может быть выделено для manual ввода объекта. Вычисляется общее время T, необходимое для ввода всех данных по объекту всеми выделенными людьми.
Оценивается процент мусора в данных по объекту. Оценивается время очистки всего объема данных по объекту от мусора. Время T корректируется на время, необходимое для очистки данных от мусора.
Оценивается изменчивость данных по объекту как отношение числа экземпляров объекта, создаваемых/изменяемых за время T, к общему числу экземпляров объекта. Большая изменчивость делает невозможным conversion before Transition.
Принимается решение, каким способом (manual или programmatic) проводить ввод данных этого объекта. При этом руководствуются следующим:
- если изменчивость «достаточно» мала, то - manual before Transition,
- если изменчивость «достаточно» большая, и время T приемлемо для остановки бизнеса, то - manual during Transition,
- остальные данные требуют ввода методом programmatic.

По ходу выполнения задачи, все полученные оценки и решения по мере выявления документируются в BDMF(в BDMF каждый объект «ведется» по «своим» строкам, каждое решение отражается в «своем»столбце).

Очень важно выявить, будут ли средства programmatic conversion использоваться

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

Для этого необходимо просмотреть все LBP и выявить шаги, при выполнении которых в приложение вводятся данные (чаще всего – массово), поступившие извне бизнеса в электронном виде. Например: обновление прайс-листоввнешних поставщиков; обработка счетов, поступивших по каналам B2B; обработка банковских выписок, поступивших по системе банк-клиент. Для таких бизнес-объектов имеет смысл проводить programmatic conversion теми же средствами приложения (если они есть), что и будут использоваться при эксплуатации приложения. Если же таких средств в приложении нет, то для такихбизнес-объектов имеет смысл при эксплуатации приложения пользоваться теми же средствами, что были разработаны для programmatic conversion.

После того, как определено, какие бизнес-объекты будут загружаться в Target system через conversion, для каждого такого объекта определяется формат, в котором подготавливаются данныеобъекта для загрузки. Подразумевается, что все данные, в каком бы виде они не существовали в бизнесе, для целей conversion будут перенесены в так называемый Extract file (по одному файлу предопределеннойструктуры на каждый объект):

Если данные существуют в Legacy system в электронном виде, то эти данные выгружаются в Extract file средствами существующих приложений.
Если данные существуют только в бумажном виде, то Extract file подготавливается «ручками».

Extract file может быть: tab-delimited text, excel, dbf, - это зависит от используемых в проекте технологических средств. Важно, чтобы

формат Extract file был задокументирован в BDMF по каждому объекту,
был задокументирован способ доступа к файлу: тип файловой системы, путь к файлу, акаунт доступа.

По окончании задачи CV.50 в документе BDMF:

определено, какие бизнес-объекты будут загружаться через conversion, каким способом (manual или programmatic), и каков порядок их загрузки,
по каждому бизнес-объекту определено, какая часть его данных будет загружаться (критерий отбора данных + история транзакций),
для каждого бизнес объекта определен формат его данных в Legacy system (формат Extract file),
каждому атрибуту бизнес-объекта поставлено в соответствие поле формы приложения (еще на этапе BR.30). Если в приложении соответствующее поле отсутствует, то задание на разработку поля сформулировано в BRMF.

С такими результатами происходит переход:

к дизайну программ programmatic conversion (CV.70),
к выработке плана manual conversion (CV.60).

BR.60

После завершения BR.30 начинает выполняться задача BR.60 – выявление детальных требований по доступу к объектам приложения. Под этим понимается определение требований

по предоставлению доступа,
по ограничению доступа

разных ролей в разных организациях к данным приложения.

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

В задаче BR.60 понятие «роль» получает дополнительный аспект своего значения – список организаций, в которых роль «действует».

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

System assisted EBF выполняются одним их трех способов:

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

Пользователь приложения манипулирует данными приложения только тремя приведенными способами. Или, иными словами: Пользователь приложения получает доступ к бизнес-объектам приложения только тремя приведенными способами.

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

критерий Х			критерий Y		критерий Z
Орг X1	орг X2	Орг X3	Орг Y1	орг Y2	орг Z1

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

Часть EBF являются system assisted, именно они рассматриваются при определении модели доступа к данным. Это может быть проиллюстрировано следующим образом:

	EBF 1	EBF 2	EBF 3	EBF 4	EBF 5	EBF 6	EBF 7	EBF 8	EBF 9
Роль 1	орг X1, орг X2	Орг X1				орг Z1
Роль 2	Орг X3
Роль 3				Орг Y1			Орг Z1		орг Z1
Роль 4								орг Z1
Роль 5					Все Y

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

AIM определяет задачу BR.60 как Develop Information Access Model – разработка модели доступа к информации (данным) приложения. В AIM-M подразработкой модели доступа понимается ряд задач:

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

Построение модели доступа в AIM-M происходит следующим образом:

Определение используемых функционалом объектов происходит при разработке приложения: для стандартного функционала объекты уже определены, для дорабатываемого – определяются на задаче BR.20-MD.20-MD50,
Определение используемого EBF функционала происходит на задаче BR.20.
Определение выполняемых ролью EBF происходит на задаче RD.30 и, в дальнейшем, уточняется на задачах RD.70, BR.20.
Определение внутри роли по каждой EBF списка организаций, в которых роль имеет право выполнять EBF, происходит на задаче BR.60 (разъясняется ниже).
Определение для пользователя выполняемых им ролей происходит на задаче BR.120.

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

Просматривая все процедуры LBP, составляется список задействованных там ролей.
Для каждой роли просматриваются все выполняемые ею EBF. Для каждой EBF внутри роли анализируется доступ корганизациям.
Заполняется таблица Information Access Model Table по вышеприведенной форме (роли по строкам, EBF постолбцам, на пересечении – список организаций). Таблица документируется в документе - файле Application Security Architecture.
Если выявляются специфические требования по ограничению доступа, не формализуемые в Information Access Model Table, то онидокументируются в процедуре LBP, аналогично документированию «обычных» требований на BR.20. Эти же требования документируются в файле Application Security Architecture для дальнейшего использования назадаче TA.120 (при отображении этих требований в возможности приложения).

Задача выполняется теми же специалистами по приложению, что выполняли BR.30; каждый – по «своим» EBF.

Результат задачи BR.60, предусмотренный AIM-M, используется для проектирования архитектуры безопасности приложения на задаче TA.120 и дляопределения настроек доступа пользователей на задаче BR.120.

Имейте в виду: AIM предполагает выполнение BR.60 в отличном от описанного виде. Согласно AIM, определение ограничений доступа к данным происходит только на уровнеорганизаций, без детализации по ролям.

TA.120

После завершения BR.60 выполняется задача TA.120 – отображение требований доступа, выявленных на BR.60, в возможности приложения.

Заметьте, вся идеология AIM построена на следующей схеме:

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

Задача выполняется теми же специалистами по приложению, что выполняли BR.60; каждый – по «своим» требованиям.

Для выполнения задачи:

Просматриваются все требования по доступу, задокументированные в файле Application Security Architecture в разделеInformation Access Model Table и разделе специфических требований. Возможно, некоторые требования по доступу задокументированы в тексте процедур LBP. Приложение настраивается, чтобы реализовать требования подоступу. Используется та же действующая модель приложения, которая была создана на BR.20.
Принятые решения по настройке приложения документируются в файле Application Security Architecture. Должно быть видно, какиетребования какими настройками реализованы.
Если в приложении нет стандартных возможностей по реализации требований доступа, то составляется BRMF, аналогично тому, какBRMF составляется для дырок в функционале на этапе BR.20. Возможна реализация требований доступа не возможностями приложения (стандартными или новыми, доработанными), а организационными методами,аналогично wolkaround-ам на BR.20. Такая реализация тоже документируется в BRMF.
По каждой BRMF запускается процесс разработки, аналогично доработке функциональности приложения (MD.20-MD.50-…)

Вспомните, на этапе BR.80 происходит тестирование решений по реализации требований. Вообще говоря, правильно на BR.80 проводить проверку решений не только по функционалу, но и по отчетам ипо доступу. В реальности, для тестирования решений по доступу уже после «основного» BR.80 проводят отдельный раунд тестирования, посвященный вопросам доступа, либо тестируют реализацию требований по доступу в рамкахкакого-нибудь раунда system test (TE.40, TE.110).

Специфичным для Oracle EBS является наличие таких стандартных возможностей по реализации требований доступа, как параметры:

Set of Books
Balancing Entity
Inventory Organization
HR Business Groups and Organizations
Legal Entity
Operating Unit

AIM v.3 предусматривает специальную задачу TA.040 - Define Application Architecture – для планирования вышеприведенных параметров. В AIM-M начальное определение этих параметров выполняется в начале проекта в задаче TA.40-3, а затем уточняется внутри задачи TA.120.

После окончания TA.120 переходят к выполнению задачи BR.120 - определению настроек доступа пользователей. Одновременно процесс внедрения распараллеливается для разработки нестандартныхвозможностей доступа по каждой BRMF.

Заметьте: Появление большого числа BRMF для реализации требований доступа, так же, как и большое число «дырок» в функциональности, демонстрирует актуальность одного из следующих утверждений: 1) приложение«слабое», и в нем нет продвинутых возможностей по предоставлению/ограничению доступа, 2) приложение «хорошее», но выбрано неадекватно бизнесу (бизнес слишком секретный :), 3) бизнес «кривой», требования по безопасности не соответствуют сложившихсястандартам, и требует сильного реинжиниринга.

Версия для печати