Новый подход к внедрению бизнес-приложений

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

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

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

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

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

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

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

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

1) попытаться реализовать требования бизнеса с помощью комбинации существующих возможностей приложения в сочетании с «ручными» операциями;

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

3) только если первое и второе невозможно, проектировать новую функциональность приложения.

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

Рис. 1. Пять фаз проекта

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

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

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

Рис. 2. Процесс внедрения бизнес-приложений

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 до начала проекта.

Новые подходы к внедрению бизнес-приложений, заложенные в AIM for BF, позволяют вовлечь в проект самих «людей бизнеса», облегчить проектирование новых автоматизированных бизнес-процессов предприятия и отказаться от выполнения некоторых «промежуточных» задач проекта внедрения. Это приводит к снижению рисков и уменьшению сроков проекта, что делает новую методику более привлекательной для управления проектами внедрения, чем предыдущие версии AIM. Конечно же, получение выгод от применения AIM for BF возникает не только за счет методологических новинок самих по себе, а базируется на обыгрывании всех возможностей, предоставляемых работающим прототипом системы.

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

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

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