Классические ERP-системы, в отличие от так называемого «коробочного» программного обеспечения, относятся к категории «тяжёлых» программных продуктов, требующих достаточно длительной настройки, для того чтобы начать ими пользоваться. Выбор ERP-системы, приобретение и внедрение, как правило, требуют тщательного планирования в рамках длительного проекта с участием партнёрской компании — поставщика или консультанта. Поскольку ERP-системы строятся по модульному принципу, заказчик часто (по крайней мере, на ранней стадии таких проектов) приобретает не полный спектр модулей, а ограниченный их комплект. В ходе внедрения проектная команда, как правило, в течение нескольких месяцев осуществляет настройку поставляемых модулей. [2].
Важным подходом к внедрению является использование — с самого начала проекта — работающего прототипа системы. Вместо того, чтобы формализовать бизнес-процессы и требования к ним «на бумаге», целессобразно сразу настраивать прототип системы в соответствии с бизнес-требованиями. Это позволяет пропустить трудоемкую фазу формализации требований на бумаге, быстрее получить не промежуточные, а значимые для бизнеса результаты; избежать искажений в понимании бизнес-требований в процессе их «теоретической» формализации (бизнес-эксперт имеет в виду одно, говорит другое, консультант записывает третье и т.д.); эффективнее использовать экспертизу представителей бизнеса, поскольку наглядная демонстрация гораздо понятнее, чем «бумажная» формализация.
Еще одной ключевой особенностью нового подхода к внедрению бизнес-приложений является отказ от фазы описания бизнеса «как есть» и перенос акцента на моделирование бизнес-процессов «как будет». В самом деле, какая польза от тщательной проработки картины существующего бизнеса, если после внедрения бизнес-процессы и, возможно, бизнес-структура существенно изменятся? Вместо того чтобы детально анализировать существующие бизнес-процессы, рекомендует как можно быстрее перейти к моделированию новой картины бизнеса. Закономерен вопрос: каким образом эксперты предприятия смогут моделировать новые бизнес-процессы в той их форме, которая подразумевает интенсивное задействование приложения, не зная ни его возможностей, ни практики построения бизнеса с использованием бизнес-систем? Разрешить это противоречие помогает акцент на использование работающего прототипа системы. Действительно, в приложения обычно «зашиты» лучшие практики построения бизнес-процессов, а в случае с отраслевыми решениями учтена и специфика данной конкретной отрасли, поэтому эксперты предприятия, с помощью консультантов наглядно знакомясь с работающим прототипом, освобождаются от необходимости придумывать будущие бизнес-процессы «с чистого листа». [2].
Таким образом, используя «вшитую» в приложение экспертизу построения «правильных» автоматизированных бизнес-процессов, участники проекта получают возможность быстрее продвинуться к получению главного результата — работающей, подстроенной под бизнес системы. Однако, случается и так, что нужного отраслевого решения, а весьма «продвинутые» приложения могут не реализовывать все требования специфического бизнеса, поскольку разработка (а особенно поддержка) таких узкоспециализированных приложений чрезвычайно ресурсоемка для производителя, и, следовательно, такое приложение будет иметь очень высокую стоимость. Для реализации специфических требований бизнеса, не реализуемых стандартными возможностями приложения, предусмотрен ряд задач, в ходе выполнения которых происходит формализация бизнес-требований и доработка приложения. Этот процесс включает в себя следущие задачи:
Даже из этого описания ясно, что доработка функциональности приложения — трудоемкий процесс, требующий существенных ресурсов. Поэтому рекомендуют рассмотрение способов реализации нестандартных требований в порядке от менее ресурсоемких решений к более ресурсоемким, а именно:
Формализация бизнес-требований необходима как первый шаг в разработке новой функциональности, но если бизнес-требование можно реализовать стандартными возможностями приложения или отраслевого прототипа, то исчезает смысл тратить силы и время на тщательную формализацию требования. Еще раз хотелось бы акцентировать внимание на том, ч рекомендуют формализацию бизнес-требований только в случае, если приложение не реализует важных специфических требований бизнеса. В подавляющем большинстве случаев предполагают, что требования бизнеса аккумулируются в рабочем прототипе системы, а точнее, в процессе моделирования и настройки прототипа от чернового варианта к виду, готовому для рабочего использования.
У специалистов по внедрению ERP-систем есть прфессиональный термин: Conference Room Pilot (CRP) — сессия целевых совещаний-демонстраций, в ходе которых работающий прототип системы «прогоняется», т.е. тестируется, рабочей группой проекта по заранее определенным сценариям с целью тщательной «подгонки» системы под требования бизнеса. В ходе проекта проводится три сессии CRP, в первой, второй и третьей фазе проекта. [3].
Рассмотрим теперь, каким образом предлагается строить проект внедрения, акцентируя внимание на задачи «притирки» приложения к бизнесу и бизнеса к приложению (см. Рис 3 в ПРИЛОЖЕНИИ А.).
1. С первой фазы внедрения проектная группа начинает активно тестировать преднастроенный работающий прототип системы (сессия CRP1). Подразумевается, что в тестовую среду системы введены данные, позволяющие демонстрировать все возможности приложения.
2. В ходе CRP1 возможности приложения демонстрируются по заранее проработанным сценариям показа (какие действия, с какими данными, кому выполнять). Сессию проводят консультанты - специалисты по приложению. Зрителями и активными участниками CRP1 являются участники проектной группы от предприятия - бизнес-эксперты и ключевые пользователи.
3. Цель CRP1 двоякая. Во-первых, происходит обучение "людей от бизнеса" базовым навыкам работы в приложении и, что еще более важно, ознакомление бизнес-экспертов предприятия с вариантами использования приложения. Во-вторых, выявляются особенности бизнес-процессов предприятия, и собирается оргструктурная информация о предприятии (план счетов, склады, финансовая отчетность и т.д.).
4. На втором этапе проекта прототип системы настраивается на все процессные и структурные особенности бизнеса, которые могут быть реализованы путем настройки. Корректируются сценарии использования системы в привязке к особенностям бизнеса.
5. Система, максимально настроенная на особенности бизнеса, "прокручивается" по сценариям, теперь уже максимально приближенным к реалиям бизнеса (сессия CRP2). Главной целью CRP2 является убедить представителей бизнеса, что использование заложенных в приложение бизнес-процессов эффективно для практики предприятия.
6. В ходе CRP1 и CRP2 выявляются и документируются все особенности бизнеса, которые не могут быть удовлетворены настройкой приложения и требуют его доработки (если таковые в данном конкретном случае есть). Одновременно разрабатываются новые сценарии, позволяющие продемонстрировать или протестировать работу системы в "доработанном" варианте.
7. На второй и третьей фазе выполняются задачи по доработке приложения.
8. На третьей фазе проекта прототип системы, настроенный и доработанный под все особенности бизнеса, опять "гоняется" проектной группой уже на полностью реальных сценариях (сессия CRP3). Устраняются все замечания и недоработки системы. Цель CRP3 - убедиться в полной работоспособности бизнес-процессов, построенных на использовании системы.
9. На четвертой фазе проекта все настройки и доработки системы переносятся со среды тестового прототипа в среду промышленной эксплуатации системы. Происходит ввод начальных данных в систему, обучение всех пользователей.
10. На пятой фазе система запускается в эксплуатацию. Проводится интенсивная "работа над ошибками" в течение первого периода эксплуатации системы. [3].
От сессии к сессии (CRP1 — CRP2 — CRP3) прототип системы эволюционирует: в первой сессии применяется предварительно настроенный прототип системы, мало привязанный к бизнесу, во второй — прототип, максимально настроенный под специфику бизнеса, в третьей — прототип, настроенный и доработанный под специфику бизнеса.
В рамках каждой сессии CRP выполняется столько «прогонов», сколько необходимо для удовлетворения целей каждой сессии. Целью CRP1 является обучение участников проектной группы от предприятия и выявление информации, необходимой для перехода к прототипу № 2. Целью CRP2 является убедить экспертов предприятия в эффективности бизнес-процессов, поддерживаемых системой и выявить информацию, необходимую для перехода к прототипу № 3. Целью CRP3 является тестирование прототипа системы на предмет полной готовности к использованию в деятельности предприятия.
Важнейшим приемом в новой методике является построение проекта вокруг трех сессий CRP. Для эффективного проведения CRP необходим прототип системы, соответствующий специфике бизнеса, — работающее преднастроенное приложение с тестовыми данными, а также проработанные сценарии, раскрывающие при их «прогоне» все возможности системы. Чем больше прототип соответствует специфике бизнеса, тем быстрее и проще переход от CRP1 к CRP2 и далее к CRP3. Так, квалифицированно разработанный отраслевой прототип позволяет уменьшить число «прогонов» в каждой сессии CRP и минимизировать усилия по настройке и доработке приложения.
Дата добавления: 2015-09-12; просмотров: 23 | Поможем написать вашу работу | Нарушение авторских прав |