Cсылка на источник : http://www.cfin.ru/itm/standards/manual_oracleaim.shtml?printversion
Часть текста по состоянию на 14 мая 2004 (с чисто литературными добавлениями от 14.01.2005) находится у Вас перед глазами. По мере готовности следующих частей, текст будет обновляться и публиковаться (в январе-феврале 2005 авторпланирует дописать главы по PJM, прежде всего по организации части проектной группы со стороны заказчика). Замечания по тексту можно направлять на мейл автора; адекватное отношение гарантировано.
На настоящий момент не существует отечественных методик и/или стандартов (ГОСТов) в области внедрения готовых приложений. Учитывая современную мировую интеграцию в области стандартизации, а также ненаверстываемое в ближайшем будущемотставание отечественной индустрии сложных программных разработок, теперь уже нет никакого смысла в разработке отечественных методик.
При внедрении готовых приложений в бизнес-областях, обусловленных специфическим регламентом, или наоборот, четко не регламентированных, применение AIM не имеет смысла. В самом деле:
Опыт применения AIM на реальных проектах позволил оптимизировать некоторые положения методики; информация об оптимизации приводится по тексту. Оптимизация касается следующего:
Существует детальная фирменная документация на Oracle AIM версии 3 и версии 2.5 (на английском языке). В данном тексте используется структура задач по версии 2.5, поскольку эта версия кажется менее перегруженнойнеосновными задачами, а в целом методика обоих версий одинакова. Читатель при необходимости легко сможет перевести задачи AIM 2.5 в задачи AIM 3, пользуясь главой «Task Cross-Reference» в документации по3-й версии.
Задача в терминах методики AIM представляет собой элементарный (неделимый) объем работ, который обязательно заканчивается формально фиксируемым результатом.
Схема ниже иллюстрирует разбиение задач по процессам и фазам внедрения. По горизонтали указаны процессы, разбиение по вертикали – фазы.
Все задачи сгруппированы в процессы по принципу общности результата. Выделяются следующие процессы внедрения:
В дальнейшем по тексту будет детально показано, при выполнении каких задач и почему происходит «фазовое смещение». Сейчас важно понять, что понятие «фаза» выполняет только одну роль - является качественной оценкой прогресса внедрения,но не всего проекта, а отдельных его объектов. Например, использование понятия «фаза» позволяет показать, что: если в ходе проекта выполняется задача Х, «декларируемая» AIM как задача 4-й фазы, то ход внедрения по этой задаче Химеет прогресс больший, чем для другой задачи Y, реально выполняемой одновременно с Х, но «приписанной» AIM ко 2-й фазе.
Обязательно ведется электронная и бумажная библиотека проекта. Бумажная необходима для помещения в нее подписанных актов и, возможно, твердых подписанных копий электронных документов-результатов. Важно понять, что порядок приемарезультатов задач внедрения должен быть формализован и сам по себе утвержден до получения первых результатов. Порядок согласования и утверждения (приема) результатов проекта и порядок работы с библиотекой проекта определяется методикой OraclePJM, и сам по себе задокументирован в документе CM.10 (процедуры управления конфигурацией проекта).
Шаблоны документов-результатов всех задач AIM входят в состав стандартной поставки AIM. Если формат реального документа-результата отличается от предусмотренного AIM (как это имеет место быть в AIM-M), то этот новый формат должен быть описан (чтобы исполнители последующих задач могли его использовать). PJM предусматривает документCM.10 для такого описания (либо разъясняющие комментарии должны содержаться в самом документе).
Документирование результатов выполнения всех задач используется в двух целях:
Возможны различные сочетания ролей в одном человеке в зависимости от его профессионального опыта. Одно из сочетаний является классическим, это выполнение одним человеком роли бизнес-аналитика и роли специалиста по приложению вспецифической бизнес-области. Этого человека, разбирающегося как в бизнесе, так и в настройке приложения, обычно и называют консультантом по внедрению (что, конечно, не совсем корректно). Таких людей в проекте - несколько, как правило, по одному набизнес-область. Обычно, таких людей привлекают «со стороны», из компаний, специализирующихся на внедрении конкретных приложений.
Другие абсолютно необходимые роли, обычно выполняемые сторонними консультантами:
Идентификация задач по процессам и фазам,
В фирменной документации по AIM указывается порядок выполнения задач. Важно понять:
Задачи в AIM обозначаются двумя буквами (обозначение процесса) и двумя-тремя цифрами (порядковый номер задачи *10) через точку, типа RD.10, TA 120. Вообще говоря,порядковый номер задачи внутри процесса ничего не говорит о последовательности её выполнения в проекте, поскольку реальная последовательность выполнения задач (взаимосвязь задач по переходящим результатам) включает задачи из разных процессов.
Понимание взаимосвязи задач очень важно, поскольку это есть понимание
Полезно посмотреть в документации по AIM графическое изображение взаимосвязи задач (внутри одной фазы), приводимое в начале каждой главы про фазы проекта. Пользы в этой картинке мало, но наглядно. Взаимосвязьвсех задач проекта приводится в формате MS Project и является «скелетом» типового плана внедрения (файл в составе типовой поставки AIM). Пользы и в этой картинке мало, но опять же наглядно (почему малопользы – станет ясно потом).
Разделение задач по фазам реального значения не имеет (это тоже станет потом ясно).
бизнес-процессов в автоматизируемой области к применению информационных технологий. В ходе проекта осуществляется разработка модели будущих бизнес-процессов (процессов в условиях автоматизации) в целях адаптация приложения кбизнес-процессам и бизнес-процессов к приложению.
AIM подразумевает, что при создании начальной модели бизнеса применяется метод Oracle OBM. OBM – это модификация метода data-flow диаграмм.Вместо data-flow в OBM используется понятие information-flow, где под потоком между шагами обработки понимается не только данные, но илюбая структурированная и неструктурированная информация, в том числе управляющие события. Интересующиеся могут посмотреть фирменную документацию по OBM; методика становится ясной с первого прочтения.
Использование графического изображения бизнеса очень наглядно, но трудоемко для выполнения проекта, учитывая, что картинки многократно по ходу проекта меняются. Кроме того, поскольку обойтись без текстовых описаний бизнеса невозможно,необходимо параллельно вести графическое и текстовое описание.
Для AIM-M был выработан свой подход к моделированию бизнеса, позволяющий в одном формате не только моделировать бизнес, но и выполнять основные задачи внедрения. При этом графические моделибизнеса применяются как вспомогательные. Основным инструментом моделирования в AIM-Mявляется описание бизнеса в виде процедур формата Oracle Tutor (описано ниже).
При описании (моделировании) LBP в AIM (OBM) и AIM-M применяются следующие изобразительные средства:
В AIM-M язык описания процедур Tutor применяется для описании (моделировании) LBP, а расширение этого языка – для документирования результатовмножества задач проекта внедрения. Далее, в тексте комментариев к задачам, будет разъяснено, как при их выполнении используется расширения языка описания процедур Tutor (вместо формата, предусмотренного AIM).
Основной линией развития проекта внедрения готового приложения является последовательность задач, нацеленная непосредственно на адаптацию приложения к использованию в бизнесе (с одновременной адаптацией бизнеса к использованиюприложения). Такой ключевой последовательностью условно можно считать:
RD.020 – RD.030 – RD.070 – BR.020 – BR.080 – MD.020 – MD.060 – DO.070 – TE.110 – PM.050 – CV.140 – PM.080, где
Процесс доработки/разработки новых возможностей приложения можно изобразить следующим образом:
После окончания разработки новых возможностей приложения (ряд задач
MD, заканчивающийся MD.120) и определения настройки стандартных
возможностей (ряд задач RD,BR, заканчивающийся BR.80), приступают к
тестированию системы (TE.110). Для проведения тестирования необходимо
разработать тесты (TE.40).
Эту зависимость можно изобразить следующим образом:
После тестирования системы (TE.110) систему можно запускать в промышленную эксплуатацию (PM.80). Для этого необходимо:
Запуск системы можно изобразить следующим образом:
Остальные зависимости будут показаны в следующей версии пособия.
Если проект с ранних стадий развивается «правильно», то задачи RD.10, RD.20, RD.30, RD.60, RD.70, RD.100, TA.40, TA.50, BR.20 выполняются в «облегченном» виде на предпроектном этапе: от изучения бизнеса и требований к будущей автоматизации к оценке эффективности внедренияприложения.
На этапе RD.10 происходит выявление всех «крупномасштабных» структурных единиц в автоматизируемой области. Что является структурной единицей - зависит от специфики охваченного автоматизацией бизнеса.
Для любого процесса актуальны такие орг.единицы, как 1) субъекты процесса, группирующие роли, участвующие в процессе (организации, подразделения, отделы) и 2) их иерархия (причем может быть несколько разных иерархий по разнымпризнакам). Субъекты должны быть выявлены для каждого бизнес-процесса 2-го уровня (для производства – одни субъекты, для маркетинга – другие).
Если бизнес-процесс охватывает финансовые отношения, то необходимо выявить финансовые орг.единицы:
AIM предоставляет шаблон для документирования результатов этой задачи. Вообще говоря, формат документирования результатов зависит от специфики автоматизируемой области. Главное, чего надо добиться при документировании – любойконсультант, не участвующий в выполнении задачи, по документу-результату RD.10 должен понять существующие структурные особенности автоматизируемого бизнеса.
Направление выполнению RD.10 и 20 придают люди, исполняющие роль бизнес-аналитиков (чаще всего сторонние для предприятия консультанты). Обязательно, чтобы руководители направлений бизнеса (автоматизируемыхобластей) выделяли фиксированное время для проекта. Руководитель проекта от заказчика ответственен за это. Эти люди:
Один бизнес-аналитик должен быть закреплен за одной бизнес-областью (за группой связанных бизнес-процессов, за бизнес-процессом высокого уровня) как основной ответственный за её изучение и дальнейший реинжиниринг области в ходепроекта. Это назначение должно быть зафиксировано и категорически-рекомендовано не меняться до конца проекта.
Изучение бизнеса в рамках RD.10 и RD.20 происходит на основе интервьюирования бизнес-аналитиками руководителей бизнеса и дополнительно привлекаемых ими людей, а также изучения внутреннихнормативных документов. Чрезвычайно желательно непосредственное наблюдение практики основных бизнес-процессов (работа с реальными исполнителями по несколько дней в каждом «отделе»).
С самого начала проекта важно полноценное участие в проекте так называемых ключевых пользователей (key users по AIM). Это специалисты предприятия, 100% времени выделенные на проект, хорошознающие специфику бизнеса. На каждую бизнес-область должно быть выделено по два человека (на случай, если один заболеет или его придется поменять). От этих людей ожидается, что в ходе проекта они будут:
Крайне желательно, чтобы среди ключевых пользователей был один человек из высшего руководства предприятия. Он же одновременно может быть руководителем проекта.
В ходе выполнения задачи RD.20, как минимум, необходимо выявить
Желательно для каждого события составить список LBP, которые запускаются данным событием и роли, принимающие участие в LBP.
По ходу изучения существующего бизнеса должна формироваться библиотека нормативных документов и образцов форм документов. Любой документ, управляющий каким-либо аспектом автоматизируемой области, считается нормативным документом. Любойдокумент, порождаемый или изменяемый в бизнес-процессах, считается формой документа.
В электронную библиотеку документов необходимо поместить ссылку на нормативный документ (если он общераспространенный, типа законодательных актов) или его копию (отсканированную или электронную), если документ – внутриорганизационный.Если бумажный документ объемный, то можно его твердую копию поместить «на полку», в «бумажную» библиотеку, а ссылку на него – в электронную библиотеку.
Формат библиотеки документов и процедуры работы с ней должны быть описаны в отдельном документе (PJM предусматривает CM.10 для этих целей), и доведены до участников проекта. Должен бытьназначен отдельный человек, ответственный за работу с библиотекой (прием документов, помещение в библиотеку в нужном формате, выдачу бумажных копий участникам проекта). Обычно электронную библиотеку документов помещают в подкаталог (с именем типа«Documents Lib») электронной библиотеки проекта.
Для каждого LBPжелательно указать ссылку на нормативные документы и формы документов, «участвующие» в LBP. Для каждой выявленной формы документа желательно выявить его документооборот (гдеи как появляется, кем и как используется).
Насколько детально изучается существующий бизнес (в частности, детализируется ли и документируется ли «внутренность» LBP) – зависит от того, 1) насколько сильно он будет меняться при автоматизации, и 2) насколькоточно видит заказчик, как будет устроен новый автоматизированный бизнес. Чем меньше будет меняться бизнес – тем больше смысла его подробно изучать. Чем лучше видит заказчик устройство нового автоматизированного бизнеса – тем меньше смысла изучатьсуществующий. Понятно, что чем детальнее изучается существующий бизнес – тем легче дальше будет внедрять, но и тем больше будет на это потрачено усилий (времени, ресурсов, денег). Поэтому важно найти золотую середину; ответственный за это –руководитель проекта от консультанта.
По ходу выполнения задачи, результат изучения документируется. Документ-результат содержит информацию:
Вторым результатом задачи RD.20 является сформированная библиотека нормативных документов и форм документов.
Третий результат не документируется, - у консультантов должно сложиться понимание 1) специфики существующего бизнеса (в автоматизируемой области) и 2) что заказчик хочет изменить в бизнесе при внедрении автоматизированнойсистемы.
Ответственные за выполнение задачи - те же бизнес-аналитики, которые выполняли RD.10 и RD.20. Подразумевается, что эти люди также являются специалистами по приложению (по крайней мере, побизнес-возможностям приложения).
Основным приемом, используемым для выполнения RD.30 является
Новые LBP буду отличаться от старых по двум причинам:
Для каждого шага необходимо указать роль, ответственную за его выполнение. Если бизнес-процесс изменяется так, что аналогичная EBF (и соответственно роль) в существующем бизнесе отсутствует, можно определить рольабстрактно, типа «Исполнитель функции EBF». При дальнейшем реинжиниринг выполнение новых EBF будет назначено либо новой роли, либо какой-нибудь из существующих в старом бизнесе.
При конструировании новых LBP используется:
Для каждого шага нового LBP надо понять «участие» системы при выполнении EBF, пока приблизительно:
Для указания участия приложения в выполнении EBF (system assisted step, automated step), в тексте процедуры используются специальные обозначения (расширениестандартного языка процедур Tutor).
Важно на задаче RD.30 начать формировать раздел «Бизнес-правила» каждой процедуры. В этот раздел (для каждого LBP) заносится информация о всех особенностях, обусловленностях бизнеса,связанных с данным LBP в целом.
Все LBP группируются в бизнес-области (те самые, которые были выявлены в RD.20). Желательно графически изобразить все бизнес-области с входящими в них LBP так, чтобывсё изображение поместилось на одном листе (в дальнейшем ходе проекта необходимо вносить изменения в это изображение) и повесить его на стену. На этом изображении можно отмечать, кто над LBP работает, в каком состоянии процессвнедрения каждого LBP, где есть проблемы.
В AIM-M результаты задачи документируются:
Для каждого шага LBPвыясняется, каков объем операций (в единицу времени), выполняемых на этом шаге, какова трудоемкость этих операций, как операции распределены по времени. Единица объема, трудоемкости и временизависят от специфики шага (EBF). Как минимум, должно быть выяснено:
Надо понимать, что: в проекте внедрения готового приложения, оптимизация бизнеса в основном происходит за счет переложения как можно большей работы по выполнению операций на приложение (компьютерную систему).
В AIM-M cобираемые показатели по каждому LBP документируется в файле его процедуры. Для записи используется расширение стандартного языка. Показатели записываютсявнутри записей о событиях и внутри записей шагов специальным стилем.
Ответственные за качество выполнения задачи - те же бизнес-аналитики – специалисты по приложению, которые выполняли RD.30. На этапе выполнения этой задачи, необходимо окончательно определиться с ключевымипользователями – заменить тех, которые продемонстрировали низкую заинтересованность в участии в проекте или плохо справляются с выполнением порученных им задач.
Бизнес-требование (requirement) – ключевой термин AIM. Это понятие включает в себя любое уточнение любого аспекта бизнеса со стороны теории и практики бизнеса, в том числе со сторонысобственных бизнес-специалистов, со стороны ведущих экспертов бизнеса, со стороны требований нормативных документов. Термин «бизнес-требование» можно воспринимать как уточнение, обязательное для выполнения в бизнесе. Вот примерыбизнес-требований:
AIM предлагает пользоваться следующим утверждением:
Вообще говоря, если руководство бизнеса не может сформулировать осмысленные бизнес-требования к автоматизированному бизнесу, то проект внедрения не может быть выполнен. Желательно выявить этот факт на этапе предпроектного обследования,и 1) либо предпринять меры по привлечению в бизнес прогрессивных руководителей (например, изложив факты хозяину бизнеса), либо 2) отложить проект. Именно на этапе RD.70 большинство проектов, тесно связанных с реинжинирингом,стопорится; это говорит о том, что бизнес - в лице лучших своих представителей – не понимает, каким образом в его конкретном случае информационные технологии могут повысить эффективность бизнеса.
В AIM-M процесс выявления требований документируется в файлах процедур LBP: внутри записи каждого шага требования записываются специальным стилем. Требование можетбыть записано в LBP в виде текста или в виде ссылки на нормативный документ и место в нем, содержащее текст требования. Рекомендуется для требований из нормативных документов копировать их текст в файл процедуры, если текстнебольшой. Это облегчит дальнейшую работу с описанием процедуры (не надо будет лезть в нормативный документ, чтобы посмотреть требование).
Требования, описание которых составляет объемный текст, и не изложенные в виде нормативных документов, скорее всего должны быть оформлены как новый нормативный документ.
Как правило, к одному шагу может быть несколько требований. Как исключение, одно требование может относиться к разным шагам. Если одно требование относится к многим шагам, а то и LBP, то скорее всего это нетребование, а или положение бизнес-политики («к началу процесса все операции с … должны быть закончены») или стратегическая установка («сотрудник предприятия должен поддерживать высокое качество выполняемых им операций»). Обязательный атрибуттребования – конкретность, выполнимость.
Если на этапе RD.70 уже понятно (хотя бы предварительно) как расписать какую-нибудь EBF до уровня Secondary Tasks (Task 2), то этот шаг процедуры LBP расписывается до уровня Task 2, и бизнес-требования «приписываются» не к шагу, а к Task 2.
Параллельно с выявлением требований на этапе RD.70 для каждого LBP:
Смысл выполнения RD.70 - выявления требований - состоит в следующем:
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 имеет и существенныенедостатки:
Кстати, задача выделения бизнес-процесса и сценария бизнес-требований как единого целого не является такой простой, как кажется на первый взгляд. Существуют три проблемы:
Из-за наличия этих проблем моделирования, «нарезание» бизнеса на бизнес-процессы (выделение части шагов в отдельные LBP, а также слияние нескольких BRS внутри одного LBP), вообще говоря, произвольное. Однако, проблема «нарезания» в проекте внедрения готового приложения не является принципиальной; «нарезание» принципиально влияет собственно только на одну непринципиальную вещь – оглавление инструкций пользователя(это будет видно дальше).
Под отчетом понимается возможность просмотра данных, порожденных в приложении при выполнении бизнес-процессов и сохраненных в базе данных приложения, в определенном пользователем виде. Обычно, подразумевается возможность вывода этихданных на твердый носитель, но это необязательно.
Выделение задачи выявления требований по отчетам отдельно от «общей» задачи выявления требований (RD.70), обусловлено тем, что:
AIM предлагает документировать требования к отчетам в отдельном документе Master Report Tracking List(AIM рекомендует шаблон). AIM-M предполагает иную методику документирования результатов RD.70 и последующих задач, связанных с отчетами. В AIM-M все отчеты рассматриваются как объекты, обязательно используемыев каких-то LBP. Если отчет используется вне автоматизируемой области (и LBP, использующего отчет, не задокументирован), то создается «фиктивный» LBP, только в целях документированиярезультатов внедрения по этому отчету.
Такой подход более эффективен, так как:
Задача RD.60 должна быть выполнена параллельно RD.100 для сбора статистики использования отчетов, аналогично тому, как она выполняется для сбора статистики по шагам бизнес-процессов.
Задачу выполняют те же бизнес-аналитики – специалисты по приложению, которые были ответственны за RD.70. На этапе выполнения BR.20 от них в полной мере потребуются глубокие знания спецификиприложения. Напоминание: каждый такой человек закреплен за определенной бизнес-областью.
Для создания действующей модели приложения «специалист по приложению»:
Если было выявлено, что приложение не обладает требуемой функциональностью, то специалист по приложению инициирует новую ветвь развития проекта – доработку приложения. Для этого он составляет документ, называемый в AIM «Business Requirement Mapping Form» (BRMF, произносится Бэрэмээф). Данный документ будет базой для разработки новой функциональности приложения.
На каждый шаг LBP (EBF), для которого не нашлось готовой функциональности, составляется отдельный BRMF. Если предполагается использование новой функциональности вразных LBP (например, в одном LBP информация об объекте вводится, в другом – корректируется), то для шагов этих LBP составляется один BRMF.
AIM предоставляет шаблон для составления BRMF. Необходимая информация, которая должна быть помещена в BRMF:
Определение: AIM использует термин gap-analysis для процесса, в ходе которого выявляется, какие бизнес-требования приложение не может удовлетворить существующейфункциональностью.
Результат выполнения задачи BR.20 документируется:
Важное понять, что в дальнейшем ходе проекта (после того, как будет разработана недостающая функциональность), все 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 находится на фазе выявления требований.
При выполнении задачи применяются понятия
Напомним на примере, что понимается под этими понятиями:
Основная цель задачи - определить соответствие между всеми атрибутами бизнес-объектов и объектов приложения.
Идентификация объектов происходит следующим образом:
Чтобы не путаться, о каком приложении идет речь, существующем или внедряемом, AIM называет внедряемое приложение «Target system».
При отображении соответствия бизнес-объектов объектам приложения используются следующие приемы:
Результаты задачи документируются в файле «BDMF» (Business Data Mapping Form) в виде таблицы: левая часть таблицы перечисляет бизнес-объекты (с их атрибутами), правая – объекты приложения(с указанием форм и полей форм). Соответствие левой и правой части по строкам показывает соответствие бизнес-данных данным приложения:
1. Для отображения атрибута бизнес-объекта в приложении нет соответствующего атрибута (поля). В этом случае, так же как и для «дырки» в функциональности,составляется BRMF, чтобы запустить процесс доработки приложения. Необходимо понимать, что при отсутствии в приложении нужного поля, в приложении отсутствует и функционал для манипулирования с данными этого поля. Для «дырки»в BDMF вместо соответствующего поля указывается ссылка на BRMF.
2. Для отображения бизнес-объекта в приложении нет соответствующего объекта. Так же, как и большое число «дырок» в функциональности, это демонстрируетактуальность одного из следующих утверждений: 1) приложение «слабое», и в нем нет продвинутых возможностей, 2) приложение «хорошее», но выбрано неадекватно бизнесу, 3) бизнес «кривой», не соответствует сложившихся стандартам в этой отрасли, и требуетсильного реинжиниринга. В этом случае, так же как и для «дырки» в функциональности, составляется BRMF, чтобы запустить процесс доработки приложения. В BDMF вместо соответствующего объекта приложенияуказывается ссылка на BRMF.
3. Для обязательного поля объекта приложения в существующем бизнесе не находится соответствия. В этом случае, «придумывается» значение по умолчанию. Этозначение указывается в BDMF.
После выполнения BR.30 ход проекта раздваивается:
Перед тем как «подгонять» приложение под требования к отчетам, необходимо выяснить какое приложение будет использоваться для формирования отчетов. Дело в том, для формирования отчетов возможно использования разных технологий. Взависимости от применяемой технологии, требования будут реализовываться разными способами, специфичными для выбранной технологии.
Определение технологии получения отчетов выполняется на задаче TA.80. Заметьте TA.80 должна быть выполнена между RD.100 и BR.70.
Задачу BR.70 выполняют те же консультанты, что и BR.20, распределяя отчеты по «своим» LBP. Возможно, понадобиться участие экспертов по выбранным на TA.80 технологическим средствам (если консультант не обладает достаточной квалификацией по выбранному средству).
Отображение требований к отчетам в функциональность приложения происходит аналогично отображению «обычных» бизнес-требований (по методике, описанной в 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, так как одни и те же шаги BRS могут выполняться в тестовом сценарии несколько раз из-за наличия циклав BRS, при этом каждый раз - с разными экземплярами данных.
Тестовые данные должны быть подготовлены для каждого «потребляющего» данные Task 2. Выделяют данные двух видов использования:
Последовательность тестовых сценариев, зависящих друг от друга по Preexisting Data, в AIM-M называется цепочкой тестовых сценариев. Сценарии в цепочке должны быть выполнены строгопоследовательно. Разные цепочки могут выполняться как последовательно, так и параллельно.
Заметьте, в AIM-M тестовый сценарий выполняется в двух целях:
Для подготовки к тестированию (как выполняется BR.80-1):
Результатом BR.80-1 является:
Желательно файлам с текстом тестовых сценариев давать такие имена,
чтобы было видно по какому BRS он создан, и является ли он «дублем»
(т.е. создан не для тестирования, а для создания Preexisting Data).
Подразумевается, что к началу этапа BR.80-2 ключевые пользователи имеют поверхностные знания, достаточные, чтобы пользоваться приложением – выполнять тестовые сценарии. Как правило, эти знания должны им передатьконсультанты, вместе с которыми они выполняли задачи RD.30-BR.20. Оптимально происходит обучение ключевых пользователей на этапе выполнения задачи BR.20:
Поскольку тестирование по разным цепочкам происходит асинхронно, тестирование может быть частично закончено по одним сценариям, и продолжаться по другим.
Когда тестирование закончено (возможно – частично) консультант, выполнявший RD.30-RD.20, должен проанализировать все обнаруженные проблемы по «своим» тестам. В зависимости от серьезностипроблемы, ход внедрения по «проблемному» бизнес-процессу возвращается
После проработки проблем (RD.30, RD.70, BR.20), ход внедрения по «проблемным» процессам опять возвращается к этапу BR.80. И так до тех пор,пока решения по бизнес-процессу не будут удовлетворять требованиям бизнеса. Более того, и в дальнейшем ходе проекта (как это станет ясно ниже по тексту) нормальным является возврат хода проекта к начальным задачам моделирования.
При перетестировании необходимо выполнить подготовку новых тестовых данных. Например, если весь груз по контракту был принят в первом раунде тестирования, то для перетестирования приемки груза необходимо придумать новый контракт.Возможно, часть данных можно использовать из предыдущих раундов тестирования (например, если поставщик заведен на первом раунде тестирования, то его можно использовать во всех раундах). Чтобы не смешивать документы, используемые в разных раундахтестирования, имеет смысл все документы каждого отдельного раунда (набор файлов тестовых сценариев для раунда, файл «Последовательность тестов» для раунда) держать в разных подкаталогах электронной библиотеки проекта.
Заметьте, именно на этапе первого тестирования происходит мощное смешивание фаз проекта: по одним бизнес-процессам ход проекта уже перешел за BR.80, а по другим – вернулся к RD.30.
Отслеживание прогресса тестирования происходит по документу «Последовательность тестов», отслеживание прогресса проекта по задачам RD.30-BR.80 (а также некоторым последующим) происходит подокументу «Список LBP».
Задача MD.20 – оценка решений по дополнению функциональности приложения – это новая ветвь проекта, инициированная на этапе BR.20 обнаружением недостатков функциональности приложения. Можносчитать, что по бизнес-процессам, требующим расширения функциональности, MD.20 – это пятая итерация по конструированию бизнес-процессов и адаптации готового приложения к бизнесу (RD.30 – первая,RD.70 – вторая, BR.20 – третья, BR.80 – четвертая).
На этапе MD.20 происходит
Оценка преимуществ, получаемых бизнесом при использовании новой функциональности, описывается, по возможности, не только качественно, но и количественно. Для этого используются задокументированные на этапе RD.60статистические показатели LBP, вплоть до оценки прибавочной стоимости, генерируемой именно этим LBP.
AIM предлагает методику оценки трудоемкости разработки новой функциональности и доработки существующей (описана в стандартной документации). Данная методика, путем эвристической оценки, позволяет определить число человеко-дней разныхспециалистов (дизайнера, разработчика, тестировщика, тех.писателя), необходимых для разработки/доработки разнотипных приложений.
С помощью этой методики для каждого BRMF, используя описание из п.4, оценивается число специалисто-часов, необходимых для реализации каждого варианта новой функциональности приложения.
После того, как готовы
Решение по разработке («добро» или «пересмотр требований») документируется в файле «Список BRMF». В дальнейшем ходе проекта этот документ будет использован для отслеживания процесса разработки новойфункциональности в разрезе каждой BRMF.
Обратите внимание: единицей, по которой отслеживаться ход проекта в процессе разработки, является каждый отдельный BRMF. Отслеживание прогресса разработки новой функциональности в рамках задач BR.20-BR.80, задач MD и задач тестирования (TE.20, TE.30) происходит по документу «Список BRMF».
Подумайте: каждый раз при возврате хода проекта к более ранним стадиям (что является нормальным!) увеличивается объем работ и длительность проекта. Это порождает две проблемы:
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» и таким образом отслеживается прогресс процесса разработки.
После готовности дизайна приложения ход проекта по процессу разработки раздваивается:
Заметьте: из-за процесса разработки/доработки функциональности в очередной раз происходит мощное смешивание фаз проекта: по одним BRMF разработка уже закончена и интегрирована в приложение (т.е. законченафаза Build), а по другим – процесс разработки еще не начинался (т.е. проект по этим BRMF находится в стадии Solution Design).
Идентификация этой задачи как 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:
Одновременно с разработкой функционального дизайна новых возможностей приложения (MD.60) дизайнер разрабатывает link test для тестирования новой функциональности приложения (задачаTE.30 по AIM). На каждый документ функционального дизайна разрабатывается отдельный link test. Можно сказать, что дизайн приложения – это теоретический взгляд на то, как должно работатьприложение, а link test – это подборка примеров, демонстрирующая, как приложение должно работать.
Link test на разрабатываемую функциональность включает тестирование тех LBP, шаги которых используют эту функциональность. Разработка link теста аналогична задаче BR.80-1 с двумя допущениями:
Задача TE.40 – подготовка тестов системы (для System Test).
Задача TE.110 – исполнение тестов системы.
Задачи TE.40, TE.110 выполняются аналогично BR.80-1, BR.80-2 со следующими дополнениями:
Все задачи тестирования выполняются итерационно, до тех пор, пока не будут устранены все замечания. После выполнения последнего успешного тестирования переходят к установке Production system в рамкахзадачи PM.50.
В реальном проекте затруднительно определить момент окончания настройки, потому что
AIM-M предусматривает, что настройки приложения формально не документируются до тех пор, пока не начинается задача PM.50 – настройка Production system (экземпляраприложения, предназначенного для «боевой» эксплуатации). Настройка Production system происходит путем переноса настроек, выверенных на рабочей модели приложения, в среду Production environment. В ходепереноса все настройки документируются.
Для документирования настроек одновременно используются несколько изобразительных средств:
В ходе BR.120 происходит планирование аккаунтов пользователей системы.
Задача выполняется следующим образом:
В AIM-М задача BR.120 выполняется непосредственно перед выполнением PM.50. Задачу выполняют те же специалисты по приложению, что и TA.120.Принимают участие ключевые пользователи и администратор системы.
Результат задачи TA.120 используется при настройке Production system в ходе задачи PM.50. Необходимо понимать, что в ходе эксплуатации системы пользователи приложениябудут изменяться. Поэтому таблица User Accessдолжна тщательно поддерживаться администратором системы периода эксплуатации.
В частности, на этапе TA.40 выполняется задача планирования Project environment. Эта подзадача в AIM-M условно называется TA.40-1.
AIM использует понятие Application Environment для обозначения среды эксплуатации приложения:
Словом Project в словосочетаниях
В процессе внедрения подготавливается Production environment для пуска Production system. Для внутренних целей внедрения используется Project environment. В процессевнедрения для разных целей необходимо использование нескольких экземпляров (instance) приложения:
В качестве Demo environment имеет смысл использование преднастроенной (производителем) версии приложения, позволяющей быстро продемонстрировать базовые возможности приложения. Для Oracle EBS такая преднастроенная версия называется Vision.
При эксплуатации нескольких сред остро стоит задача синхронизации их настроек. Как правило, настройки определяются в Demo environment (поскольку именно там идет основной процесс настройки) и должны быть аккуратноперенесены в остальные среды.
Наличие нескольких систем периода внедрения определяет требования к аппаратному обеспечению на время внедрения – сервера должны предусматривать одновременную эксплуатацию всех систем. Должно быть либо несколько серверов, либо мощныйсервер, предусматривающий одновременную эксплуатацию нескольких систем.
Конкретная конфигурация Project environment зависит от специфики проекта и должна курироваться опытным руководителем проекта (как правило, со стороны консультанта), чтобы, с одной стороны, учесть все потребностипроекта, с другой – не разорить заказчика :)
Задача TA.40-1 выполняется условно независимо от других задач проекта как можно раньше, так как на построение Project environment может понадобиться существенное время, а безготового Project environment и, в частности, Demo environment, невозможно приступить к построению модели приложения.
Сервера периода внедрения после окончания проекта могут быть использованы:
Вторая часть задачи TA.40 посвящена планированию концептуальной архитектуры. В AIM-M эта подзадача условно называется TA.40-2.
Под планированием концептуальной архитектуры подразумевается определение:
Выполнение TA.40-2 начинается с выяснения, какие компоненты концептуальной архитектуры планируются с точки зрения использования приложений:
Самый замечательный вариант, если возможно установить все модули для обслуживания всех организаций в одном Data Center и предоставить доступ пользователям к приложению через корпоративную сеть или интернет.Однако, в случае большой территориальной распределенности, чисто технические (или финансовые) ограничения не позволяют это сделать. Тогда возникает несколько Data Center, распределенных по территориальному признаку (например, покомбинатам или по странам).
В случае с несколькими Data Center необходимо спланировать решение следующих вопросов:
Параллельно с планированием концептуальной архитектуры с точки зрения используемых приложений, планируется, какими техническими системами будет обеспечено функционирование приложений. Эти части задачи связаны друг с другом, т.к.ограничения технических средств влияют на использование приложений. Например: 1) отсутствие адекватных каналов связи между территориально распределенными подразделениями обуславливает организацию Data Center на каждойтерритории, 2) нежелание руководства возиться с организацией нескольких Data Center, из-за сложности их эксплуатации, вынуждает строить корпоративную магистраль, чтобы все подразделения могли работать с одним DataCenter.
На ранних стадиях проекта возможны разные варианты построения концептуальной архитектуры. Все они должны быть конспективно описаны с анализом особенностей каждого. AIM предоставляет шаблон такого документа(TA.40 по AIM.2.5).
Третья часть задачи TA.40 посвящена бизнес-архитектуре приложения. В AIM-M эта подзадача условно называется TA.40-3.
Под определением бизнес-архитектуры приложения понимается планирование использования специализированных параметров (настроек) приложения, предназначенных для отображения организационных элементов бизнеса, тех самых структурных единиц,выявление которых началось на этапе RD.10.
В Oracle EBS существуют специализированные параметры бизнес-архитектуры:
Предварительные решения по бизнес-архитектуре приложения должны быть задокументированы. AIM предоставляет шаблон такого документа (TA.40 по AIM.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 понимается:
Очевидно, что разработка 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 – определение отдельных подпроектов, в рамках которых будут реализовываться разные подсистемы. Подсистемы, реализация которых тесно связанас настройкой приложения (например, разработка интерфейсов к внешним системам) могут быть реализованы в рамках основного проекта внедрения приложения. Остальные подсистемы передаются на реализацию в рамках внешних подпроектов.
Для каждого подпроекта должны быть, как минимум, описаны
После того, как подпроекты спланированы (в рамках TA.110), они передаются на исполнение (обычно, в IT-службы и/или отдельным субподрядчикам). Важно, чтобы исполнение подпроектов управлялосьсинхронизировано с управлением основного проекта, т.к. проблемы в подпроектах могут оказать влияние на основной проект.
Очевидно, что разработка подсистем и подпроектов не может быть окончательно закончена, пока не закончена задача TA.40-2. Однако, во многих случаях возможно выделение некоторых подпроектов на ранней стадиипроекта, что позволяет «запустить» эти подпроекты на выполнение уже на этой стадии.
Заметьте, одной из целей управления проектом является запуск на выполнение всех возможных задач на как можно более ранней стадии проекта.
По мере готовности результатов задачи TA.40-2 приступают к ряду задач процесса TA по планированию архитектуры серверной платформы и сети передачи данных.
AIM разделяет это планирование на ряд задач TA.150, TA.160, TA.170, TA.180. Однако решаемые каждой задачей вопросы так сильно взаимосвязаны, что реально они все выполняются как одна задача.
На этапе TA.150-180 необходимо определить:
Болезненным вопросом является необходимая для функционирования приложения конфигурация 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:
Задачу выполняют эксперты по технологическим средствам генерации отчетов. Одновременно, необходимо участие консультанта, курировавшего выполнение RD.100.
Самым «дубовым» способом получения аналитической информации является выдача статичной распечатки требуемых данных в требуемом виде на бумаге или мониторе. Этого достаточно для удовлетворения требований нормативной отчетности ибольшинства требований внутренних аналитиков предприятия. Тем более это верно для предприятий, впервые вне
дряющих приложение типа ERP, - у них еще не оформилось понимание самих бизнес-процессов, что уж говорить об аналитике.
Для удовлетворения требованиям к технологии «статичного» получения отчетов, обычно достаточно возможностей, предусмотренных в стандартной поставке приложении. В этом случае, объем работ по TA.80 вырождается донуля (просто где-то должно быть зафиксировано, что принято решение использовать стандартные средства), и участие эксперта при выполнении задачи не требуется.
Современный технологический инструментарий позволяет получать динамичную, кросс-связанную информацию прямо из базы данных, содержащей основные данные приложения (транзакционной базы, OLTP). Для OracleApplications это:
Основной цепочкой задач по переносу данных является:
BR.30 - CV.50 – CV.70 – CV.90 – CV.140
Непосредственно сам перенос данных происходит на задаче CV.140. Остальные задачи посвящены подготовке к переносу.
В данном тексте перенос данных называется «conversion» (как в AIM). В жизни также применяются термины: конвертация данных, загрузка данных, начальная загрузка, начальный ввод данных и ихсочетание.
AIM-М различает разные категории данных (объектов), поскольку для каждой категории существует свой подход к conversion:
В зависимости от бизнес-требований, conversion может выполняться с разной степенью детализации транзакций по объекту:
AIM-М различает два способа проведения conversion по отношению к моменту пуска приложения в эксплуатацию:
Задача CV.50 состоит из нескольких последовательно выполняемых частей:
Для выяснения, какие данные (каких объектов) должны быть перенесены из Legacy system, придерживаются следующего:
Очень важно выявить, будут ли средства programmatic conversion использоваться
После того, как определено, какие бизнес-объекты будут загружаться в Target system через conversion, для каждого такого объекта определяется формат, в котором подготавливаются данныеобъекта для загрузки. Подразумевается, что все данные, в каком бы виде они не существовали в бизнесе, для целей conversion будут перенесены в так называемый Extract file (по одному файлу предопределеннойструктуры на каждый объект):
Вспомните, что роль полностью определяется списком выполняемых ею EBF. Роль – это всего лишь удобный способ обозначить группу функций (EBF), выполняемых в бизнесе определенным видомработников (должностью). Надо понимать, что группировка EBF в роли, вообще говоря, произвольна.
В задаче BR.60 понятие «роль» получает дополнительный аспект своего значения – список организаций, в которых роль «действует».
При определении требований доступа пользуются следующими утверждениями:
Пользователь приложения манипулирует данными приложения только тремя
приведенными способами. Или, иными словами: Пользователь приложения
получает доступ к бизнес-объектам приложения только тремя приведенными
способами.
Часть EBF являются system assisted, именно они рассматриваются при определении модели доступа к данным. Это может быть проиллюстрировано следующим образом:
Результат задачи BR.60, предусмотренный AIM-M, используется для проектирования архитектуры безопасности приложения на задаче TA.120 и дляопределения настроек доступа пользователей на задаче BR.120.
Имейте в виду: AIM предполагает выполнение BR.60 в отличном от описанного виде. Согласно AIM, определение ограничений доступа к данным происходит только на уровнеорганизаций, без детализации по ролям.
Заметьте, вся идеология AIM построена на следующей схеме:
Для выполнения задачи:
Специфичным для Oracle EBS является наличие таких стандартных возможностей по реализации требований доступа, как параметры:
AIM v.3 предусматривает специальную задачу TA.040 - Define
Application Architecture – для планирования вышеприведенных параметров. В
AIM-M начальное определение этих параметров выполняется в начале
проекта в задаче TA.40-3, а затем уточняется внутри задачи TA.120.
После окончания TA.120 переходят к выполнению задачи BR.120 - определению настроек доступа пользователей. Одновременно процесс внедрения распараллеливается для разработки нестандартныхвозможностей доступа по каждой BRMF.
Заметьте: Появление большого числа BRMF для реализации требований доступа, так же, как и большое число «дырок» в функциональности, демонстрирует актуальность одного из следующих утверждений: 1) приложение«слабое», и в нем нет продвинутых возможностей по предоставлению/ограничению доступа, 2) приложение «хорошее», но выбрано неадекватно бизнесу (бизнес слишком секретный :), 3) бизнес «кривой», требования по безопасности не соответствуют сложившихсястандартам, и требует сильного реинжиниринга.
Предисловие
Задумка написать данный текст появилась в марте 2004 при попытке упорядочить обучение начинающих консультантов команды «Найтов-БИС». В марте же, когда была готова первая часть текста, стало понятно, что текст может быть использован нетолько для внутрифирменного обучения, но и будет интересен «посторонним» читателям:- начинающим консультантам, осваивающим методику внедрения готовых приложений,
- руководителям со стороны заказчика, ответственным за управление проектом внедрения,
- специалистам по внедрению, переходящим от внедрения узкоспециализированных приложений к внедрению приложений, ориентированных на бизнес-процессы.
Часть текста по состоянию на 14 мая 2004 (с чисто литературными добавлениями от 14.01.2005) находится у Вас перед глазами. По мере готовности следующих частей, текст будет обновляться и публиковаться (в январе-феврале 2005 авторпланирует дописать главы по PJM, прежде всего по организации части проектной группы со стороны заказчика). Замечания по тексту можно направлять на мейл автора; адекватное отношение гарантировано.
Об AIM
AIM – Application Implementation Method – методика внедрения готовых приложений, разработана компанией Оракл для внедрения пакета готовых приложений Oracle E-Business Suite. Методика AIM практически не использует специфических особенностей Oracle E-Business Suite, поэтому она с одинаковым успехом может быть применена при внедрениилюбой ERP-системы и, вообще говоря, любого готового приложения, ориентированного на «автоматизацию» бизнес-процессов. Основную суть методики составляет адаптация бизнес-процессов к применению информационных технологий и,одновременно, адаптации этих самых информационных технологий к конкретным бизнес-процессам.На настоящий момент не существует отечественных методик и/или стандартов (ГОСТов) в области внедрения готовых приложений. Учитывая современную мировую интеграцию в области стандартизации, а также ненаверстываемое в ближайшем будущемотставание отечественной индустрии сложных программных разработок, теперь уже нет никакого смысла в разработке отечественных методик.
При внедрении готовых приложений в бизнес-областях, обусловленных специфическим регламентом, или наоборот, четко не регламентированных, применение AIM не имеет смысла. В самом деле:
- в узкоспециализированной деятельности бизнес-процессы обычно не поддаются изменению, а потому само приложение должно быть написано точно под бизнес (и не нужно методики, чтобы его внедрять),
- в нерегламентированном бизнесе, по определению, бизнес-процессы четко не определены, поэтому подгонять приложение не подо что.
Опыт применения AIM на реальных проектах позволил оптимизировать некоторые положения методики; информация об оптимизации приводится по тексту. Оптимизация касается следующего:
- идеология, концепции, термины, идентификация задач оставлены без изменения,
- «неважные» задачи - т.е. задачи, результаты которых могут быть легко получены при выполнении других, «основных» задач - не выделяются как отдельныезадачи,
- технология получения результатов части задач изменена таким образом, чтобы результат одной задачи максимально (вплоть до текста) использовался привыполнении последующих задач.
Существует детальная фирменная документация на 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. Так же точно определено, какие бизнес-требования не могут быть удовлетворены с помощью стандартной функциональностии какая дополнительная разработка необходима.
- Проектирование решения - в ходе данной фазы в частности производится создание детальных спецификаций для дополнительной разработки (функциональный и технический дизайн) и разработка сценариев тестирования.
- Разработка - поокончании данной фазы все дополнительные разработки завершены, приемочные тесты проведены, пользовательская документация разработана.
- Переход к эксплуатации - в ходе этой фазы завершается обучение конечных пользователей, производится конвертация данных и система вводится в эксплуатацию.
- Эксплуатация системы – это начало фазы поддержки системы. В это время выявляются и исправляются все недочеты по работе системы.
Комментарии к термину «фаза внедрения»
В ходе проекта все фазы внедрения накладываются одна на другую и, более того, итеративно повторяются. Это, в частности, происходит из-за того, что:- внедрение по разным бизнес-областям и даже бизнес-процессам из одной области происходит параллельно, причем внедрение одного бизнес-процесса может произвольно опередить внедрение другого;
- в процессе внедрения реализуется принцип итеративной проработки затронутых проектом проблем, когда уточнение требований влияет на реализацию, а реализация влияет на уточнение требований, при этом постоянно происходит возврат от более поздних задач к более ранним.
В дальнейшем по тексту будет детально показано, при выполнении каких задач и почему происходит «фазовое смещение». Сейчас важно понять, что понятие «фаза» выполняет только одну роль - является качественной оценкой прогресса внедрения,но не всего проекта, а отдельных его объектов. Например, использование понятия «фаза» позволяет показать, что: если в ходе проекта выполняется задача Х, «декларируемая» AIM как задача 4-й фазы, то ход внедрения по этой задаче Химеет прогресс больший, чем для другой задачи Y, реально выполняемой одновременно с Х, но «приписанной» AIM ко 2-й фазе.
Результат задачи
В ходе выполнения каждой задачи появляется один или несколько результатов (термин Deliverables в AIM). Результат всегда документируется. Если результат естественным образом в ходевыполнения задачи «записан» (обычно в электронной форме), то этот «записанный» документ должен быть соответствующим образом оформлен, согласован и утвержден (обычно в бумажной форме). Если результатом задачи является заранее спланированная выполненнаяработа, то результат задачи документируется как акт выполнения определенных работ (например, проведения определенного вида учебных курсов с определенной аудиторией).Обязательно ведется электронная и бумажная библиотека проекта. Бумажная необходима для помещения в нее подписанных актов и, возможно, твердых подписанных копий электронных документов-результатов. Важно понять, что порядок приемарезультатов задач внедрения должен быть формализован и сам по себе утвержден до получения первых результатов. Порядок согласования и утверждения (приема) результатов проекта и порядок работы с библиотекой проекта определяется методикой OraclePJM, и сам по себе задокументирован в документе CM.10 (процедуры управления конфигурацией проекта).
Шаблоны документов-результатов всех задач AIM входят в состав стандартной поставки AIM. Если формат реального документа-результата отличается от предусмотренного AIM (как это имеет место быть в AIM-M), то этот новый формат должен быть описан (чтобы исполнители последующих задач могли его использовать). PJM предусматривает документCM.10 для такого описания (либо разъясняющие комментарии должны содержаться в самом документе).
Документирование результатов выполнения всех задач используется в двух целях:
- зафиксировать выполнение объема работ в целях учета затраченных ресурсов и отслеживания хода проекта;
- использовать задокументированный результат выполнения одной задачи при выполнении следующей.
Исполнители задачи
В фирменной документации по AIM приводится описание типовых ролей, выполняемых участниками проекта в ходе проекта и при эксплуатации. На практике каждый реальный участник проекта должен выполнять несколько ролей.Это необходимо, т.к. при выполнении некоторых разных ролей разными людьми требуются такие существенные усилия по координации действий исполнителей, что никакой нормальный бюджет это не потянет (для координации двух человек, работающих по однойзадаче, нужен третий, а для координации одного – никого).Возможны различные сочетания ролей в одном человеке в зависимости от его профессионального опыта. Одно из сочетаний является классическим, это выполнение одним человеком роли бизнес-аналитика и роли специалиста по приложению вспецифической бизнес-области. Этого человека, разбирающегося как в бизнесе, так и в настройке приложения, обычно и называют консультантом по внедрению (что, конечно, не совсем корректно). Таких людей в проекте - несколько, как правило, по одному набизнес-область. Обычно, таких людей привлекают «со стороны», из компаний, специализирующихся на внедрении конкретных приложений.
Другие абсолютно необходимые роли, обычно выполняемые сторонними консультантами:
- Руководитель проекта по качеству. Ответственен за правильное управление проектом и решение всех спорных вопросов.
- Дизайнер расширений функциональности приложения. Этот человек прорабатывает создание функциональности, отсутствующей в стандартном приложении. Иногда эта роль совмещается с ролью специалиста по приложению, иногда – с ролью программиста.
- Администратор системных компонент. Ответственен за начальную установку системы и решение системных проблем периода внедрения. Одновременно может быть экспертом по разным системным вопросам.
- Эксперт по информационным технологиям, применяемым при внедрении и эксплуатации приложения. Обычно один человек специализируется в одной или нескольких узких областях, поэтому требуется привлечение разных экспертов на время решения проблемы.
- Назначать на выполнение задачи людей, способных выполнять роли, общий процент участия которых существенно больше 50%. Если это не получается, то
- Назначать на выполнение ключевых ролей задачи людей, хорошо сработавшихся друг с другом в прошлом. Они сами разберутся, что является чьей ответственностью. Если и это не получается, то
- Четко определить ответственность каждого участника и протокол взаимодействия между ними при выполнении задачи.
Идентификация задач по процессам и фазам,
Порядок выполнения задач
В фирменной документации по 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 = одноименная б/ф.
При описании (моделировании) 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.
Моделирование бизнес-процессов в формате бизнес-процедур 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 – запуск новой системы
- при «нехватке» возможностей приложения, касающихся функциональности
- при «нехватке» возможностей приложения, касающихся отчетов
- при «нехватке» возможностей приложения по предоставлению/ограничению доступа к функциям и данным,
- при разработке программ автоматической конвертации (программ переноса бизнес-данных в новое приложение).
- по доработке основного функционала исполняется такая цепочка задач
-
- BR.020 – выявление «дыр» функциональности приложения, предварительное формулирование решения, как можно устранить «дыры»
- BR.080 – первоначальная оценка предложенного предварительного решения
- MD.020 – окончательное формулирование решения, как можно устранить «дыры», оценка трудозатрат
- по доработке отчетов
-
- RD.100 – выявление детальных требований к будущим отчетам
- TA.080 – отображение требований в технологические средства, поддерживающие генерацию отчетов
- BR.070 – отображение требований в стандартные возможности приложения, выявление «дыр» в стандартных отчетах, предварительное формулирование решения, как можно устранить «дыры»
- MD.020 – окончательное формулирование решения, как можно устранить «дыры», оценка трудозатрат
- по доработке доступа к данным
-
- BR.030 – отображение бизнес-объектов в объекты приложения
- BR.060 – выявление детальных требований к организации доступа к данным
- TA.120 – отображение требований доступа к данным в стандартные возможности приложения, выявление «дыр» в стандартных возможностях доступа к данным, предварительное формулирование решения, как можно устранить «дыры»
- MD.020 – окончательное формулирование решения, как можно устранить «дыры», оценка трудозатрат
- по разработке программ конвертации
- BR.030 – отображение бизнес-объектов в объекты приложения
- CV.050 – выявление какие данные и каким образом будут конвертироваться
- CV.070 – дизайн программ конвертации
- дизайн новых возможностей приложения определяет инструкции пользователя
-
- MD.020 – окончательное формулирование решения, какая нужна разработка
- МD.060 – функциональный дизайн новой разработки
- DO.070 – составление инструкции пользователя
- внедрение дизайна расширений БД
-
- MD.050 – дизайн расширения базы данных
- MD.100 – внедрения дизайна в БД
- MD.120 – создание инсталляционного пакета
- разработка и тестирование нового кода
- MD.060 – функциональный дизайн новой разработки
- MD.070 – функциональный дизайн новой разработки
- TE.030 – создание тестов на предмет, как новый функционал будет использоваться вместе со стандартным
- MD.110 – создание новой функциональности (включая создание тестов нового кода TE.20 и само тестирование TE.80)
- TE.080 – тестирование новых возможностей приложения на предмет использования вместе со стандартными возможностями
- MD.120 – создание инсталляционного пакета
Эту зависимость можно изобразить следующим образом:
- выработка стандартных настроек приложения определяет инструкции пользователя
-
- BR.080 – тестирование принятых решений
- DO.070 – разработка инструкций пользователя
- дизайн новых возможностей приложения определяет инструкции пользователя
-
- MD.060 – функциональный дизайн новых возможностей приложения
- DO.070 – разработка инструкций пользователя
- окончание разработки новых возможностей в виде создания инсталляционного пакета позволяет приступить к тестированию
-
- MD.120 – создание инсталляционного пакета
- TE.110 – тестирование (System Test)
- разработка инструкций пользователя позволяет приступить к разработке и исполнению тестов
- DO.070 – разработка инструкций пользователя
- TE.040 – создание комплексных тестов (System Test)
- TE.110 – тестирование (System Testing)
- подготовить документацию для эксплуатации системы,
- обучить пользователей,
- создать группу поддержки системы,
- запустить систему.
Запуск системы можно изобразить следующим образом:
- перед запуском систему надо установить и настроить
-
- PM.040 – установка системных компонент периода эксплуатации
- PM.050 – настройка приложения периода эксплуатации (в том числе «заведение» пользователей)
- PM.080 – запуск новой системы
- перед запуском надо наполнить систему данными
-
- PM.050 – настройка приложения периода эксплуатации
- CV.140 – конвертация «начальных» данных
- PM.080 – запуск новой системы
- перед запуском надо завести пользователей системы
-
- PM.050 – настройка приложения периода эксплуатации
- BR.120 – конвертация «начальных» данных
- PM.080 – запуск новой системы
- перед запуском надо построить техническую инфраструктуру
Остальные зависимости будут показаны в следующей версии пособия.
Если проект с ранних стадий развивается «правильно», то задачи 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 придают люди, исполняющие роль бизнес-аналитиков (чаще всего сторонние для предприятия консультанты). Обязательно, чтобы руководители направлений бизнеса (автоматизируемыхобластей) выделяли фиксированное время для проекта. Руководитель проекта от заказчика ответственен за это. Эти люди:
- участвуют в проектировании и внедрении в бизнес-практику всех изменений, связанных с проектом,
- привлекают к выполнению задач проекта своих подчиненных,
- своим авторитетом способствуют продвижению проекта.
Один бизнес-аналитик должен быть закреплен за одной бизнес-областью (за группой связанных бизнес-процессов, за бизнес-процессом высокого уровня) как основной ответственный за её изучение и дальнейший реинжиниринг области в ходепроекта. Это назначение должно быть зафиксировано и категорически-рекомендовано не меняться до конца проекта.
Изучение бизнеса в рамках 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.
Вторым результатом задачи RD.20 является сформированная библиотека нормативных документов и форм документов.
Третий результат не документируется, - у консультантов должно сложиться понимание 1) специфики существующего бизнеса (в автоматизируемой области) и 2) что заказчик хочет изменить в бизнесе при внедрении автоматизированнойсистемы.
RD.30
Начиная с задачи RD.30 начинается адаптация бизнеса к использованию приложения и адаптация приложения к использованию в бизнесе.Ответственные за выполнение задачи - те же бизнес-аналитики, которые выполняли RD.10 и RD.20. Подразумевается, что эти люди также являются специалистами по приложению (по крайней мере, побизнес-возможностям приложения).
Основным приемом, используемым для выполнения RD.30 является
- просмотр всех событий, выявленных в RD.20,
- для каждого события необходимо сконструировать бизнес-процесс (LBP), отрабатывающий это событие и порождающийбизнес-результат.
Новые LBP буду отличаться от старых по двум причинам:
- Одни старые LBP изменяются, поскольку часть их действий берет на себя система, другие – вынуждено, т.к. изменились первые. Это, так сказать, «реинжиниринг из-за автоматизации» (обязательный при внедрении информационных технологий).
- В процессе внедрения происходит реструктуризация бизнеса не только из-за автоматизации, но и просто потому, что серьезные люди наконец взялись пристально анализировать бизнес. Это, так сказать, «бизнес-реинжиниринг» (дополнительный, условно-бесплатный - но возможно очень существенный - плод проекта внедрения). При этом бизнес-процессы могут измениться как угодно сильно, единственным условием является выполнение бизнесом (автоматизированной областью бизнеса) своих основных стратегических задач.
Для каждого шага необходимо указать роль, ответственную за его выполнение. Если бизнес-процесс изменяется так, что аналогичная EBF (и соответственно роль) в существующем бизнесе отсутствует, можно определить рольабстрактно, типа «Исполнитель функции EBF». При дальнейшем реинжиниринг выполнение новых EBF будет назначено либо новой роли, либо какой-нибудь из существующих в старом бизнесе.
При конструировании новых LBP используется:
- выявленные в RD.20 особенности существующих LBP,
- знание бизнес-функциональности приложения, знание заложенных в приложение бизнес-возможностей (ожидается от представителей консультанта),
- понимание практики применения в аналогичном бизнесе аналогичных приложений (ожидается от представителей консультанта и бизнеса).
- ожидания руководства бизнеса, сформулированные в виде пожеланий как должен функционировать автоматизированный бизнес.
- надо максимально использовать наработки предпроектных документов,
- поскольку 1) достаточно часто предпроектное обследование проводится одними людьми, а проект выполняется – другими, и 2) предпроектное обследование документируется достаточно формально, в целях – продать/купить, а не в целях – внедрить; то именно поэтому приходится выполнять эти задачи как бы повторно.
- возможностям приложения,
- сложившейся мировой практике в этой отрасли бизнеса.
Для каждого шага нового LBP надо понять «участие» системы при выполнении EBF, пока приблизительно:
- system assisted step
- manual step
- automated step
Для указания участия приложения в выполнении 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)
- чтобы все участники ответственно относились к получению качественных результатов данной задачи,
- чтобы в дальнейшем, если будут сделаны изменения в схему б/п, все понимали, что обработка этих новых изменений – это новая работа.
RD.60
В рамках задачи RD.60, параллельно с выполнением RD.30, выясняются показатели объема и важности операций в бизнесе.Для каждого шага LBPвыясняется, каков объем операций (в единицу времени), выполняемых на этом шаге, какова трудоемкость этих операций, как операции распределены по времени. Единица объема, трудоемкости и временизависят от специфики шага (EBF). Как минимум, должно быть выяснено:
- как часто возникают события, запускающие LBP; отдельно по каждому событию (пример: несколько раз в год, обычно ближе к концу года),
- как часто роль выполняет EBF, не важно по какому событию (пять раз в день); сколько времени уходит на выполнение EBF (один час); сколько людей выполняет подобную EBF (пять человек и трое помогают при заторах), как распределяются EBF по времени (в конце месяца обычно наплыв),
- сколько и какого типа документов и их составляющих обрабатывается при выполнении EBF (сто инвойсов вида Х ежемесячно), как объемны документы (редко бывают инвойсы вида Х больше чем на десять строк), сколько времени уходит на обработку документа (1-3 минуты) и т.п.
- как размер упускаемой прибыли из-за недочетов в бизнесе, которые возможно устранить внедрением приложения,
- как увеличение «боевого духа» персонала в связи с получаемыми возможностями от использования приложения,
- как упрочение бизнес-стратегии руководства, получаемое при внедрении.
Надо понимать, что: в проекте внедрения готового приложения, оптимизация бизнеса в основном происходит за счет переложения как можно большей работы по выполнению операций на приложение (компьютерную систему).
В AIM-M cобираемые показатели по каждому LBP документируется в файле его процедуры. Для записи используется расширение стандартного языка. Показатели записываютсявнутри записей о событиях и внутри записей шагов специальным стилем.
RD.70
RD.30 и RD.60 – это первая итерация по конструированию новых бизнес-процессов и адаптации готового приложения к бизнесу. Вторая итерация – RD.70 – исследование детальных бизнес-требований кбудущему бизнесу.Ответственные за качество выполнения задачи - те же бизнес-аналитики – специалисты по приложению, которые выполняли RD.30. На этапе выполнения этой задачи, необходимо окончательно определиться с ключевымипользователями – заменить тех, которые продемонстрировали низкую заинтересованность в участии в проекте или плохо справляются с выполнением порученных им задач.
Бизнес-требование (requirement) – ключевой термин AIM. Это понятие включает в себя любое уточнение любого аспекта бизнеса со стороны теории и практики бизнеса, в том числе со сторонысобственных бизнес-специалистов, со стороны ведущих экспертов бизнеса, со стороны требований нормативных документов. Термин «бизнес-требование» можно воспринимать как уточнение, обязательное для выполнения в бизнесе. Вот примерыбизнес-требований:
- это действие должно выполняться не более 5 секунд,
- для каждого поставщика надо хранить его атрибуты, такие как ИНН, р/счета, …
- данная проводка должна формироваться так-то согласно нормативному документу такому-то,
- никогда нельзя останавливаться в этом месте, в случае остановки будет то-то,
- в этой операции должен быть задействован один человек и не более,
- коррекция должна рассчитываться по алгоритму такому-то
- и т.п.
AIM предлагает пользоваться следующим утверждением:
- Каждое требование предопределяет выполнение конкретных шагов конкретных LBP.
- И наоборот: каждый шаг определяется конкретными требованиями.
- Если какое-нибудь требование не может быть отнесено хотя бы к одному шагу LBP - значит или это требование излишнее или не хватает какого-то шага LPB (или целого LBP).
- Если к шагу LBP не выявлено никаких требований – значит или этот шаг является не нужным или требование должно быть дополнительно выработано.
- С одной стороны, каждое имеющееся требование должно быть проанализировано на предмет актуальности для будущего бизнеса и отнесено к соответствующим ему шагам 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.
- к ограничению доступа
- к доступности системы
- к отчетности.
Смысл выполнения RD.70 - выявления требований - состоит в следующем:
- задокументированные требования в дальнейшем помогут правильно настроить систему (или выявить, что необходимо систему «доделывать», поскольку система встандартном варианте не может удовлетворить требованиям) и
- выработать правильные инструкции для исполнителей бизнес-процессов (ролей, исполняющих EBF).
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 в один общий документ.
Кстати, задача выделения бизнес-процесса и сценария бизнес-требований как единого целого не является такой простой, как кажется на первый взгляд. Существуют три проблемы:
- Группа событий может запускать как бы единый 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) плохо формализуем. Поэтому требования к аналитическим отчетам не удается выяснить, только исследуя бизнес-процессы предприятия.
- какие данные присутствуют в отчете,
- в каком виде необходимо (для определенных нормативными документами случаев) или желательно (для внутреннего использования) представить данные.
- существующими в бизнесе отчетами,
- видением будущих бизнес-процессов (тех шагов, для выполнения которых требуются отчеты).
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.
- последующие шаги по внедрению отчетов проходят в рамках тех же шагов, что и внедрение бизнес-функциональности,
Задача 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, шаги, для выполнения которых нужна новая функциональность,
- описание бизнес-требований, вызвавших необходимость разработки новой функциональности,
- описание и оценка преимуществ, которые получит бизнес, если будет использоваться новая функциональность,
- предлагаемая реализация новой функциональности приложения, варианты.
Определение: AIM использует термин gap-analysis для процесса, в ходе которого выявляется, какие бизнес-требования приложение не может удовлетворить существующейфункциональностью.
Результат выполнения задачи BR.20 документируется:
- изменением файлов процедур LBP для «найденной» функциональности,
- написанием BRMF для каждой дырки в приложении.
- Если для выполнения шага используется существующий функционал приложения (форма, отчет, пакетная программа), то
-
- в описании шага указывается ссылка на этот функционал (навигация до формы, отчета, пакетной программы или их название) и ссылка на документацию по этому функционалу (для этого используется стандартный язык процедур Tutor),
- если шаг system assisted, то
- шаг детализируется до уровня Secondary Tasks (Task 2),
- указывается, как каждый Task 2 должен выполняться с использованием функционала (в поле Х введите дату или нажмите на кнопку Y и т.п.).
- Если необходимый для выполнения шага функционал отсутствует, то
-
- для этого шага разрабатывается BRMF,
- в описании шага, вместо ссылки на функционал, указывается ссылка на эту BRMF,
- в документ «Список BRMF» помещается информация о BRMF, в частности, ссылка на описание BRMF.
Важное понять, что в дальнейшем ходе проекта (после того, как будет разработана недостающая функциональность), все 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) – Отделение Поставщика, Заголовок контракта
- Атрибут – Название отделения, Номер контракта
Основная цель задачи - определить соответствие между всеми атрибутами бизнес-объектов и объектов приложения.
Идентификация объектов происходит следующим образом:
- Бизнес-объект и его атрибут идентифицируются их короткими названиями.
- Объект приложения идентифицируется названием (или навигацией) формы приложения, через которую происходит создание экземпляров объекта. Например: форма ввода поставщика, форма создания контракта.
- Атрибуты объектов приложения идентифицируются полями форм приложения, через которые происходит манипуляция с атрибутами. Основной формой для идентификации является форма, в которой впервые создаются экземпляры объекта. Возможно использование полей других форм или полей отчетов.
Чтобы не путаться, о каком приложении идет речь, существующем или внедряемом, AIM называет внедряемое приложение «Target system».
При отображении соответствия бизнес-объектов объектам приложения используются следующие приемы:
- Некоторые поля объектов Target system являются обязательными для работы приложения. Соответствующие им атрибуты должны быть «найдены» в бизнес-объектах прежде всего.
- Некоторые атрибуты бизнес-объектов являются очевидно обязательными для функционирования бизнеса. Эти атрибуты должны быть отображены в поля Target system прежде всего.
- Состав атрибутов бизнес-объекта определяется бизнес-требованиями. Именно поэтому задача BR.30 выполняется одновременно с BR.20 (и является как бы её подзадачей).
- Некоторые атрибуты бизнес-объектов Legacy system могут не иметь бизнес-смысл в Target system, по двум причинам: 1) это служебные поля «старого» приложения, имеющие смысл только для этого приложения, 2) бизнес перестраивается, и некоторые старые данные теряют смысл.
Результаты задачи документируются в файле «BDMF» (Business Data Mapping Form) в виде таблицы: левая часть таблицы перечисляет бизнес-объекты (с их атрибутами), правая – объекты приложения(с указанием форм и полей форм). Соответствие левой и правой части по строкам показывает соответствие бизнес-данных данным приложения:
- название бизнес-объекта должно находиться на той же строке, что и название формы создания объекта приложения,
- атрибут бизнес-объекта должен находиться на той же строке, что и название (навигация) поле формы, через которое «идентифицируется» атрибут объекта приложения.
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.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, при этом каждый раз - с разными экземплярами данных.
Тестовые данные должны быть подготовлены для каждого «потребляющего» данные Task 2. Выделяют данные двух видов использования:
- вводимые в приложение или другую систему (например, вписываемые от руки на бланк) во время выполнения Task 2; такие данные в AIM называются User Input,
- заранее введенные в приложение и используемые при выполнении Task 2; такие данные в AIM называются Preexisting Data.
Последовательность тестовых сценариев, зависящих друг от друга по Preexisting Data, в AIM-M называется цепочкой тестовых сценариев. Сценарии в цепочке должны быть выполнены строгопоследовательно. Разные цепочки могут выполняться как последовательно, так и параллельно.
Заметьте, в AIM-M тестовый сценарий выполняется в двух целях:
- протестировать решение по соответствующему ему 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.
Результатом BR.80-1 является:
- набор файлов тестовых сценариев,
- документ, содержащий информацию о всех тестовых цепочках, а также последовательности выполнения тестовых сценариев в каждой цепочке (в AIM-M он называется «Последовательность тестов» или «Testing Scenario Chain List»).
- собственно последовательность сценариев с указанием цепочек,
- список сценариев, в котором для каждого сценария отражается по какому BRS он создан (для тестирования какого BRS создан),
- раздел, предназначенный для отслеживания выполнения тестов, где указывается прогресс и результаты тестирования.
Подразумевается, что к началу этапа BR.80-2 ключевые пользователи имеют поверхностные знания, достаточные, чтобы пользоваться приложением – выполнять тестовые сценарии. Как правило, эти знания должны им передатьконсультанты, вместе с которыми они выполняли задачи RD.30-BR.20. Оптимально происходит обучение ключевых пользователей на этапе выполнения задачи BR.20:
- Перед началом BR.20, консультант дает «своим» (прикрепленным к «его» бизнес-области) ключевым пользователям очень короткий теоретический обзор приложения.
- На практике консультант показывает общие приемы работы с приложением (как запускать, заходить, навигация, печать и т.п.).
- В ходе создания консультантом прототипа приложения и демонстрации его ключевым пользователям, происходит практическое обучение ключевых пользователей работе в приложении (типа: ну-ка а теперь сам попробуй).
- Тестовые цепочки распределяются для выполнения между ключевыми пользователями (по сферам специализации, бизнес-областям). Назначения фиксируются в документе «Последовательность тестов» в разделе, предназначенном для отслеживания прогресса тестирования.
- Ключевые пользователи последовательно выполняют свои цепочки сценарий за сценарием. При возникновении проблем с выполнением тестов, пользователи совместно со «своим» консультантом пытаются разобраться в проблеме.
- Обнаружив при тестировании проблему, неустранимую в оперативном порядке, пользователь описывает её прямо в тексте тестового сценария (используется расширение стандартного языка Tutor). Одновременно, пользователь отмечает факт обнаружения проблемы в документе «Последовательность тестов» в разделе результатов.
Поскольку тестирование по разным цепочкам происходит асинхронно, тестирование может быть частично закончено по одним сценариям, и продолжаться по другим.
Когда тестирование закончено (возможно – частично) консультант, выполнявший 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 происходит
- формальная оценка преимуществ, получаемых бизнесом от разработки новой функциональности (доработки существующей),
- формальная оценка трудоемкости разработки новой функциональности,
- принятие решения о соответствии «стоимости создания новой функциональности» «приобретаемым бизнесом преимуществам».
- ссылка на LBP, шаги, для выполнения которых нужна новая функциональность,
- описание бизнес-требований, вызвавших необходимость разработки новой функциональности,
- описание и оценка преимуществ, которые получит бизнес, если будет использоваться новая функциональность,
- предлагаемая реализация новой функциональности приложения, варианты.
Оценка преимуществ, получаемых бизнесом при использовании новой функциональности, описывается, по возможности, не только качественно, но и количественно. Для этого используются задокументированные на этапе RD.60статистические показатели LBP, вплоть до оценки прибавочной стоимости, генерируемой именно этим LBP.
AIM предлагает методику оценки трудоемкости разработки новой функциональности и доработки существующей (описана в стандартной документации). Данная методика, путем эвристической оценки, позволяет определить число человеко-дней разныхспециалистов (дизайнера, разработчика, тестировщика, тех.писателя), необходимых для разработки/доработки разнотипных приложений.
С помощью этой методики для каждого BRMF, используя описание из п.4, оценивается число специалисто-часов, необходимых для реализации каждого варианта новой функциональности приложения.
После того, как готовы
- с одной стороны, - оценка преимуществ, получаемых бизнесом от разработки новой функциональности,
- с другой стороны, - оценка трудоемкости (т.е. стоимости) разработки этой функциональности,
Решение по разработке («добро» или «пересмотр требований») документируется в файле «Список 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 – создание инсталляционных пакетов.
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 – тестирование приложения на работоспособность после установки патчей.
Одновременно с разработкой функционального дизайна новых возможностей приложения (MD.60) дизайнер разрабатывает link test для тестирования новой функциональности приложения (задачаTE.30 по AIM). На каждый документ функционального дизайна разрабатывается отдельный link test. Можно сказать, что дизайн приложения – это теоретический взгляд на то, как должно работатьприложение, а link test – это подборка примеров, демонстрирующая, как приложение должно работать.
Link test на разрабатываемую функциональность включает тестирование тех LBP, шаги которых используют эту функциональность. Разработка link теста аналогична задаче BR.80-1 с двумя допущениями:
- тестовые сценарии составляются только на те LBP, которые используют разрабатываемую функциональность,
- тесты составляются так, как будто новая функциональность уже существует в приложении.
Задача 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
Все задачи тестирования выполняются итерационно, до тех пор, пока не будут устранены все замечания. После выполнения последнего успешного тестирования переходят к установке Production system в рамкахзадачи PM.50.
BR.110
После того как закончены все задачи процесса BR, влияющие на настройку приложения, AIM рекомендует формально задокументировать все настройки. Для этого предусмотрена задача BR.110.В реальном проекте затруднительно определить момент окончания настройки, потому что
- настройка приложения по разным бизнес-процессам не синхронизирована,
- настройка по каждому процессу происходит итеративно,
- настройки могут меняться после каждого тестирования при обнаружении несоответствия бизнес-требованиям или нестыковок интеграции разных процессов между собой.
AIM-M предусматривает, что настройки приложения формально не документируются до тех пор, пока не начинается задача PM.50 – настройка Production system (экземпляраприложения, предназначенного для «боевой» эксплуатации). Настройка Production system происходит путем переноса настроек, выверенных на рабочей модели приложения, в среду Production environment. В ходепереноса все настройки документируются.
Для документирования настроек одновременно используются несколько изобразительных средств:
- пошаговая инструкция, с ссылками на стандартные или разработанные гайды по настройке,
- скрин-шоты с экранов, отображающих окна настройки,
- файлы с конфигурационными данными, определяющими настройки.
BR.120
В рамках задачи TA.120 были определены настройки доступа для типовых ролей бизнеса.В ходе BR.120 происходит планирование аккаунтов пользователей системы.
Задача выполняется следующим образом:
- Составляется список реальных сотрудников, для которых запланировано, что они будут использовать приложение.
- Для каждого сотрудника определяются системные права доступа к функциям и данным приложения.
В 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 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).
Вторая часть задачи TA.40 посвящена планированию концептуальной архитектуры. В AIM-M эта подзадача условно называется TA.40-2.
Под планированием концептуальной архитектуры подразумевается определение:
- какие модули приложения будут использоваться,
- как они будут распределены территориально (по Data Center),
- какими компонентами технической инфраструктуры будет поддерживаться их функционирование.
- определенное место,
- установленное в этом месте серверное и коммуникационное оборудование,
- установленные на этих серверах модули приложения.
Выполнение TA.40-2 начинается с выяснения, какие компоненты концептуальной архитектуры планируются с точки зрения использования приложений:
- какие модули приложения будут использоваться для Production system,
- какие внешние (другие) бизнес-приложения будут использоваться совместно с модулями приложения,
- где будут установлены модули приложения (в каких Data Center),
- как будет обеспечиваться взаимодействие модулей приложения, установленных в разных Data Center,
- как будет обеспечиваться доступ к приложению с рабочих мест пользователей,
- как будет обеспечиваться взаимодействие модулей приложения и внешних бизнес-приложений.
Самый замечательный вариант, если возможно установить все модули для обслуживания всех организаций в одном Data Center и предоставить доступ пользователям к приложению через корпоративную сеть или интернет.Однако, в случае большой территориальной распределенности, чисто технические (или финансовые) ограничения не позволяют это сделать. Тогда возникает несколько Data Center, распределенных по территориальному признаку (например, покомбинатам или по странам).
В случае с несколькими Data Center необходимо спланировать решение следующих вопросов:
- синхронизация информации между экземплярами приложения, установленными в разных Data Center (например, синхронизация справочников),
- централизованной сбор информации из разных Data Center для аналитических целей,
- доступ пользователей одного Data Center к информации другого Data Center.
Параллельно с планированием концептуальной архитектуры с точки зрения используемых приложений, планируется, какими техническими системами будет обеспечено функционирование приложений. Эти части задачи связаны друг с другом, т.к.ограничения технических средств влияют на использование приложений. Например: 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
Предварительные решения по бизнес-архитектуре приложения должны быть задокументированы. AIM предоставляет шаблон такого документа (TA.40 по AIM.3).
До тех пор, пока не будут ясны все вопросы
- какие модули приложения и как будут использоваться, что определяется в задаче отображения бизнес-процессов в функциональность приложения (BR.20),
- по разработке дизайна интерфейсов с внешними приложениями (MD.60),
- по разработке технологии системы отчетов (TA.80),
- по отображению требования доступа на возможности приложения (TA.120),
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, которые дадут больший эффект),
- порядок запуска модулей приложения (не обязательно внедрение по всем модулям должно проходить параллельно, важно быстрее внедрить те модули, которые дадут больший эффект).
Очевидно, что разработка 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 – определение отдельных подпроектов, в рамках которых будут реализовываться разные подсистемы. Подсистемы, реализация которых тесно связанас настройкой приложения (например, разработка интерфейсов к внешним системам) могут быть реализованы в рамках основного проекта внедрения приложения. Остальные подсистемы передаются на реализацию в рамках внешних подпроектов.
Для каждого подпроекта должны быть, как минимум, описаны
- цель,
- область охвата,
- требования к подсистеме,
- методика управления,
- связь с основным проектом.
После того, как подпроекты спланированы (в рамках 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),
- конфигурацию локальной сети и интерфейса с интернет/интранет.
Болезненным вопросом является необходимая для функционирования приложения конфигурация 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.
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» - класть на склад.
- Пополняемые данные. Вводятся в приложение операциями пользователей. Приложение «не различает» экземпляры пополняемых данных между собой. Пример: номенклатурные позиции, поставщики.
- История изменения объектов (транзакции).
В зависимости от бизнес-требований, conversion может выполняться с разной степенью детализации транзакций по объекту:
- Conversion текущего состояния объекта. В
приложение вводится только текущее состояние каждого экземпляра объекта.
Вводятся только «открытые», «актуальные» экземпляры объекта, которые
еще участвуют в бизнес-процессах.
Пример: conversion только неоплаченных частей открытых счет-фактур. - Conversion транзакций «открытых» экземпляров объекта. В
приложение, кроме текущего состояния экземпляра, вводится история его
изменений с момента его создания. Вводится история только по «открытым»
экземпляры.
Пример: conversion всех открытых счет-фактур и историй оплат по ним. - Conversion транзакций всех экземпляров объекта за период. В
приложение вводится история всех экземпляров объекта, начиная с
определенной даты, не важно «открытый» это экземпляр или «закрытый».
Пример: conversion всех счет-фактур за последние 3 года и историй оплат по ним.
- наличие в приложении исторических данных по «открытым» экземплярам объекта позволяет «правильней» обрабатывать (закрыть) объект,
- наличие в приложении исторических данных по всем экземплярам объекта за период позволяет проводить средствами приложения анализ той части бизнеса, которая связана с этим бизнес-объектом.
- manual – ввод данных в приложение «ручками» через предназначенные для этого формы ввода.
- programmatic - ввод данных в приложение с использование специальных программ.
AIM-М различает два способа проведения conversion по отношению к моменту пуска приложения в эксплуатацию:
- before Transition – ввод данных в приложение осуществляется до фазы Transition и не требует остановки бизнеса. В это время Target system еще не используется бизнес-пользователями. Способ before Transition применяется, чтобы «разгрузить» конечную стадию проекта – запуск приложения в эксплуатацию. Однако, он имеет существенный минус: как только данные введены в приложение, необходимо осуществлять постоянную актуализацию данных (в то время как «нормальные» процедуры Target system еще не работают). Поэтому таким способом можно вводить только медленно меняющиеся объекты.
- during Transition - ввод данных в приложение во время фазы Transition. Это обычно означает, что бизнес останавливается (чтобы не обрабатывать новых данных), и за это время выполняется conversion.
Задача CV.50 состоит из нескольких последовательно выполняемых частей:
- Первым делом выясняется, данные каких объектов должны быть введены в приложение до момента его запуска в эксплуатацию. Возможно, данные некоторых объектов не будут переноситься из Legacy system, а будут заводиться в приложении уже во время эксплуатации по мере необходимости.
- Затем выясняется, какие из этих объектов будут вводиться через setup, а какие - через conversion.
- Затем выясняется, какие из conversion объектов будут вводиться через manual conversion, а какие – через programmatic.
- Для каждого conversion объекта определяется формат, в котором подготавливаются данные объекта из Legacy system для загрузки в Target system.
Для выяснения, какие данные (каких объектов) должны быть перенесены из Legacy system, придерживаются следующего:
- setup данные однозначно должны быть введены до запуска приложения,
- объекты, данные которых изменяются быстро, не имеет смысл вводить до запуска приложения (они мгновенно устаревают),
- чем больше объектов будет перенесено до запуска приложения в эксплуатацию, тем удобнее будет пользователям при эксплуатации приложения (не надо будет заводить данные «по новой»), и тем сложнее будет процесс переноса,
- переносимые данные должны быть очищены от мусора, иногда это очень трудоемкая операция; при больших массивах информации проблема мусора в данных может повлиять на решение отказаться от переноса данных,
- данные, существующие только в бумажном виде, переносить более трудоемко, чем существующие в электронном виде; это особенно актуально для «объемных» данных.
- только setup объекты, имеющие очень большое число экземпляров, могут рассматриваться как подлежащие 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.
Очень важно выявить, будут ли средства programmatic conversion использоваться
- только на стадии внедрения приложения или
- есть необходимость их использования при эксплуатации приложения.
После того, как определено, какие бизнес-объекты будут загружаться в Target system через conversion, для каждого такого объекта определяется формат, в котором подготавливаются данныеобъекта для загрузки. Подразумевается, что все данные, в каком бы виде они не существовали в бизнесе, для целей conversion будут перенесены в так называемый Extract file (по одному файлу предопределеннойструктуры на каждый объект):
- Если данные существуют в Legacy system в электронном виде, то эти данные выгружаются в Extract file средствами существующих приложений.
- Если данные существуют только в бумажном виде, то Extract file подготавливается «ручками».
- формат Extract file был задокументирован в 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 по организациям определяются ограничение доступа пользователя к данным.
- на уровне пользователя: определение выполняемых пользователя ролей,
- на уровне роли: определение выполняемых ролью EBF, с определением для каждой EBF списка организаций, вкоторых роль имеет право их выполнять.
- на уровне EBF: определение используемого EBF функционала (наприм.формы),
- на уровне функционала: определение используемых функционалом (наприм.отчетом) объектов.
- Определение используемых функционалом объектов происходит при разработке приложения: для стандартного функционала объекты уже определены, для дорабатываемого – определяются на задаче BR.20-MD.20-MD50,
- Определение используемого EBF функционала происходит на задаче BR.20.
- Определение выполняемых ролью EBF происходит на задаче RD.30 и, в дальнейшем, уточняется на задачах RD.70, BR.20.
- Определение внутри роли по каждой EBF списка организаций, в которых роль имеет право выполнять EBF, происходит на задаче BR.60 (разъясняется ниже).
- Определение для пользователя выполняемых им ролей происходит на задаче BR.120.
- Просматривая все процедуры LBP, составляется список задействованных там ролей.
- Для каждой роли просматриваются все выполняемые ею EBF. Для каждой EBF внутри роли анализируется доступ корганизациям.
- Заполняется таблица Information Access Model Table по вышеприведенной форме (роли по строкам, EBF постолбцам, на пересечении – список организаций). Таблица документируется в документе - файле Application Security Architecture.
- Если выявляются специфические требования по ограничению доступа, не формализуемые в Information Access Model Table, то онидокументируются в процедуре LBP, аналогично документированию «обычных» требований на BR.20. Эти же требования документируются в файле Application Security Architecture для дальнейшего использования назадаче TA.120 (при отображении этих требований в возможности приложения).
Результат задачи BR.60, предусмотренный AIM-M, используется для проектирования архитектуры безопасности приложения на задаче TA.120 и дляопределения настроек доступа пользователей на задаче BR.120.
Имейте в виду: AIM предполагает выполнение BR.60 в отличном от описанного виде. Согласно AIM, определение ограничений доступа к данным происходит только на уровнеорганизаций, без детализации по ролям.
TA.120
После завершения BR.60 выполняется задача TA.120 – отображение требований доступа, выявленных на BR.60, в возможности приложения.Заметьте, вся идеология AIM построена на следующей схеме:
- строится грубая модель явления,
- выявляются детальные требования к разным аспектам явления,
- модель и детальные требования отображаются в приложение (приложение настраивается и демонстрируется),
- если какие-то аспекты модели или требований не реализуются приложением, то формируется подход, как их реализовать,
- стоимость реализации новых возможностей приложения оценивается, и, если она «слишком» велика, то происходит возврат к перестройке модели илипереформулированию требований;
- если стоимость реализации новых возможностей оправдана, то новые компоненты приложения разрабатываются (и интегрируются в приложение),
- составляются инструкции по использованию приложения, объединяющие стандартные и новые возможности приложения, и базирующиеся на модели явления и надетальных требованиях к нему,
- новая модель внедряется в жизнь.
Для выполнения задачи:
- Просматриваются все требования по доступу, задокументированные в файле 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-…)
Специфичным для Oracle EBS является наличие таких стандартных возможностей по реализации требований доступа, как параметры:
- Set of Books
- Balancing Entity
- Inventory Organization
- HR Business Groups and Organizations
- Legal Entity
- Operating Unit
После окончания TA.120 переходят к выполнению задачи BR.120 - определению настроек доступа пользователей. Одновременно процесс внедрения распараллеливается для разработки нестандартныхвозможностей доступа по каждой BRMF.
Заметьте: Появление большого числа BRMF для реализации требований доступа, так же, как и большое число «дырок» в функциональности, демонстрирует актуальность одного из следующих утверждений: 1) приложение«слабое», и в нем нет продвинутых возможностей по предоставлению/ограничению доступа, 2) приложение «хорошее», но выбрано неадекватно бизнесу (бизнес слишком секретный :), 3) бизнес «кривой», требования по безопасности не соответствуют сложившихсястандартам, и требует сильного реинжиниринга.
Этот комментарий был удален автором.
ОтветитьУдалить