Методика внедрения ERP-систем

модули автоматизации ранее неохваченных областей, совершенствуются возможности существующих, а на основе уже имеющихся бизнес-приложений создаются прототипы отраслевых решений. Однако новые модули и отраслевые прототипы часто требуют иных подходов к процессу их внедрения. Методики внедрения бизнес-приложений корпорации Oracle оформлены в Application Implementation Method for Business Flows.

Результаты работы корпорации Oracle в сфере методик внедрения бизнес-приложений оформились недавно в новую версию методики Application Implementation Method — AIM for Business Flows (AIM for BF), на примере которой мы рассмотрим вопросы изменения процедур внедрения бизнес-приложений, вызванные, в первую очередь, ростом бизнес-ориентированности комплекса приложений Oracle E-Business Suite.

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

Еще одной ключевой особенностью нового подхода к внедрению бизнес-приложений является отказ от фазы описания бизнеса «как есть» и перенос акцента на моделирование бизнес-процессов «как будет». В самом деле, какая польза от тщательной проработки картины существующего бизнеса, если после внедрения бизнес-процессы и, возможно, бизнес-структура существенно изменятся? Вместо того чтобы детально анализировать существующие бизнес-процессы, AIM for BF рекомендует как можно быстрее перейти к моделированию новой картины бизнеса. Закономерен вопрос: каким образом эксперты предприятия смогут моделировать новые бизнес-процессы в той их форме, которая подразумевает интенсивное задействование приложения, не зная ни его возможностей, ни практики построения бизнеса с использованием бизнес-систем? Разрешить это противоречие помогает акцент AIM for BF на использование работающего прототипа системы. Действительно, в приложения обычно «зашиты» лучшие практики построения бизнес-процессов, а в случае с отраслевыми решениями учтена и специфика данной конкретной отрасли, поэтому эксперты предприятия, с помощью консультантов наглядно знакомясь с работающим прототипом, освобождаются от необходимости придумывать будущие бизнес-процессы «с чистого листа».

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

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

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

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

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

Новая версия AIM предусматривает разбиение проекта не на шесть фаз, как более ранние версии AIM, а на пять. Две «старые» фазы «Анализ операций» (Operations Analysis) и «Дизайн решений» (Solution Design) объединены в одну — «Уточнение» (Elaboration), что отражает ускорение процесса внедрения за счет использования новых подходов. Другим методологическим изменением является группировка всех задач, относящихся к бизнес-анализу и настройке приложения, в один комплексный процесс — «Отображение бизнес процессов» («Business Process Mapping», BF), что соответствует тесному сближению процессов выявления бизнес-требований, проектирования будущих бизнес-процессов и отображения бизнес-процессов на функциональность приложения.

В глоссарий AIM for BF введено новое понятие — Conference Room Pilot (CRP) — сессия целевых совещаний-демонстраций, в ходе которых работающий прототип системы «прогоняется», т.е. тестируется, рабочей группой проекта по заранее определенным сценариям с целью тщательной «подгонки» системы под требования бизнеса. В ходе проекта проводится три сессии CRP, в первой, второй и третьей фазе проекта.

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

1. С первой фазы внедрения проектная группа начинает активно тестировать преднастроенный работающий прототип системы (сессия CRP1). Подразумевается, что в тестовую среду системы введены данные, позволяющие демонстрировать все возможности приложения.
2. В ходе CRP1 возможности приложения демонстрируются по заранее проработанным сценариям показа (какие действия, с какими данными, кому выполнять). Сессию проводят консультанты - специалисты по приложению. Зрителями и активными участниками CRP1 являются участники проектной группы от предприятия - бизнес-эксперты и ключевые пользователи.
3. Цель CRP1 двоякая. Во-первых, происходит обучение "людей от бизнеса" базовым навыкам работы в приложении и, что еще более важно, ознакомление бизнес-экспертов предприятия с вариантами использования приложения. Во-вторых, выявляются особенности бизнес-процессов предприятия, и собирается оргструктурная информация о предприятии (план счетов, склады, финансовая отчетность и т.д.).
4. На втором этапе проекта прототип системы настраивается на все процессные и структурные особенности бизнеса, которые могут быть реализованы путем настройки. Корректируются сценарии использования системы в привязке к особенностям бизнеса.
5. Система, максимально настроенная на особенности бизнеса, "прокручивается" по сценариям, теперь уже максимально приближенным к реалиям бизнеса (сессия CRP2). Главной целью CRP2 является убедить представителей бизнеса, что использование заложенных в приложение бизнес-процессов эффективно для практики предприятия.
6. В ходе CRP1 и CRP2 выявляются и документируются все особенности бизнеса, которые не могут быть удовлетворены настройкой приложения и требуют его доработки (если таковые в данном конкретном случае есть). Одновременно разрабатываются новые сценарии, позволяющие продемонстрировать или протестировать работу системы в "доработанном" варианте.
7. На второй и третьей фазе выполняются задачи по доработке приложения.
8. На третьей фазе проекта прототип системы, настроенный и доработанный под все особенности бизнеса, опять "гоняется" проектной группой уже на полностью реальных сценариях (сессия CRP3). Устраняются все замечания и недоработки системы. Цель CRP3 - убедиться в полной работоспособности бизнес-процессов, построенных на использовании системы.
9. На четвертой фазе проекта все настройки и доработки системы переносятся со среды тестового прототипа в среду промышленной эксплуатации системы. Происходит ввод начальных данных в систему, обучение всех пользователей.
10. На пятой фазе система запускается в эксплуатацию. Проводится интенсивная "работа над ошибками" в течение первого периода эксплуатации системы.

От сессии к сессии (CRP1 — CRP2 — CRP3) прототип системы эволюционирует: в первой сессии применяется предварительно настроенный прототип системы, мало привязанный к бизнесу, во второй — прототип, максимально настроенный под специфику бизнеса, в третьей — прототип, настроенный и доработанный под специфику бизнеса.

В рамках каждой сессии CRP выполняется столько «прогонов», сколько необходимо для удовлетворения целей каждой сессии. Целью CRP1 является обучение участников проектной группы от предприятия и выявление информации, необходимой для перехода к прототипу № 2. Целью CRP2 является убедить экспертов предприятия в эффективности бизнес-процессов, поддерживаемых системой и выявить информацию, необходимую для перехода к прототипу № 3. Целью CRP3 является тестирование прототипа системы на предмет полной готовности к использованию в деятельности предприятия.

Важнейшим приемом в новой методике является построение проекта вокруг трех сессий CRP. Для эффективного проведения CRP необходим прототип системы, соответствующий специфике бизнеса, — работающее преднастроенное приложение с тестовыми данными, а также проработанные сценарии, раскрывающие при их «прогоне» все возможности системы. Чем больше прототип соответствует специфике бизнеса, тем быстрее и проще переход от CRP1 к CRP2 и далее к CRP3. Так, квалифицированно разработанный отраслевой прототип позволяет уменьшить число «прогонов» в каждой сессии CRP и минимизировать усилия по настройке и доработке приложения.

Откуда же к началу сессии CRP1 возникает преднастроенный работающий прототип системы? Существует несколько вариантов создания первого прототипа. Вариант первый — использование тестовой демосистемы Oracle E-Business Suite — Vision. Совместно с этой системой предоставляется описание данных и настроек системы, а также сценарии, «прогон» которых позволяет продемонстрировать ключевые возможности приложения. В Oracle предусматривают два варианта получения доступа к Vision. Можно установить демосистему во время инсталляции Oracle E-Business Suite со стандартных инсталляционных дисков либо обратиться к ресурсу Advanced Demo System в Сети, где установлена работающая Vision.

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

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

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

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

1. Устанавливается "пустая" система, либо Vision.
2. На основе данных, полученных в ходе предпроектной подготовки, система настраивается так, чтобы максимально соответствовать специфике предприятия.
3. Сценарии "прогона" разрабатываются на основе ранее применявшихся на других проектах, либо на основе стандартных сценариев из состава Advanced Demo System.

Такой вариант имеет смысл применять в случае, когда отраслевой прототип недоступен, а предприятие не устраивает «стандартный» прототип Vision. При этом надо быть готовым к тому, что потребуется задействовать существенные ресурсы для подготовки прототипа, фактически, к проведению CRP0 и выходу на CRP1 до начала проекта.