Управление рисками в проекте SAP
Управление рисками в проекте SAP
Так как проект SAP — это внедрение стандартного пакета программного обеспечения, связанные с проектом риски отличаются от рисков, традиционно ассоциируемых с внедрением программного обеспечения. Перечень основных рисков, связанных с внедрением традиционного ПО:
• Недостаток ресурсов
• Недостаток ясности, полноты и уверенности в отношении рамок проекта и желаемой функциональности
• Определение и анализ требований
• Эффективный, результативный, но в тоже время достаточно гибкий для будущих изменений системный проект
• Разработка системы на основе этого проекта и ее тестирование для справочных целей
• Обучение различных групп пользователей работе с новой системой
• Взаимодействие с другими приложениями и системами в режиме реального времени
• Загрузка всех необходимых данных в новую систему
• Параллельная работа старой и новой систем
• Переход на другую систему
• Превышение крайних сроков
• Споры относительно обязанностей, ответственности и критериев определения характеристик работы
• Несогласие пользователей, их нежелание принимать участие в проекте
• Сбои в инфраструктуре или программном обеспечении.
В дополнение к вышеперечисленным рискам, проект SAP может столкнуться со следующими факторами риска:
• Определение и анализ требований компании
• Понимание того, что может обеспечить система SAP
• Обнаружение пробелов в функциональности и заострение на них внимания
• Правильная конфигурация системы SAP и корректное осуществление настроек
• Тестирование интеграции системы SAP
• Почти одновременное обучение всех групп пользователей
• Загрузка всех необходимых данных в новую систему
• Быстрое переключение на новую систему без периода параллельной работы.
Риски, связанные с начальным определением и анализом требований к системе, мало чем отличаются от рисков в традиционных проектах. Для предприятий нового тысячелетия особенно важно сокращать сроки внедрения.
Компания, внедряющая SAP, может взять на вооружение несколько стратегий для минимизации присущих проекту рисков. Самая важная стратегия заключается в отказе от анализа требований с одновременным внедрением функциональности, которая представляла бы оптимальные практики и процессы, играющие самую важную роль в деятельности компании. Добиться этого легче всего с помощью внедрения на предприятии лучших в своем классе процессов и практик, поставляемых вместе с системой SAP.
Отбор основных жизненно важных процессов
Компания должна оценить и отобрать те процессы, которые имеют жизненно важное значение для ее деловой активности, а также сосредоточиться на эффективном внедрении этих процессов с целью придания процессу оптимизации максимальной значимости.
Внедрение лучших в своем классе практик и процессов
В системе SAP предусмотрена библиотека, состоящая из 800 лучших в своем классе практик и процессов, основанных на опыте компаний из разных стран. Успех SAP в предоставлении всеобъемлющей функциональности за значительно меньшие по сравнению с традиционными проектами сроки основывается на стратегии усиления общих черт, объединяющих бизнес-процессы различных компаний в одной отрасли.
В области традиционной разработки программного обеспечения концепция многократного использования оказалась мощным средством наращивания производительности и качества поставляемых программных продуктов. Компания SAP делает особый акцент на использовании этой концепции в проектировании жизненно важных для предприятия систем и упорядочивает общие черты функциональности для быстрого и эффективного внедрения.
Однако, прежде чем добавлять принцип повторного использования в библиотеку лучших в своем классе процессов, компания должна задокументировать, рационализировать и стандартизировать отобранную группу внедряемых процессов, используя SAP.
Документирование процессов
Документирование различных бизнес-процессов обеспечивает реальное понимание характерной структуры и динамики среды деловой активности компании. Это подразумевает запись подробной информации о процессах — в том числе название, назначение, ответственная функция, описание процесса с указанием предпосылок и результата, а также подпроцессов. Также требуется указать интерфейсы взаимодействия с другими функциями и системами, исключительные условия, возможности улучшения, анализ эффекта от внесения изменений и т. д.
Рационализация процессов
На многие предусмотренные в традиционных системах программы и процедуры оказывала воздействие архитектура общей системы. Например, традиционные программные продукты создавались с расчетом на то, что ими будут пользоваться сотрудники с высокой степенью компьютерной грамотности, а техподдержка станет единой централизованной
В таких охватывающих все предприятие системах, как SAP, множество этих устройств и возможностей могут работать автоматически благодаря архитектуре системы. Поэтому, такие действия можно полностью исключить из бизнес-процессов.
Стандартизация процессов
Каждый офис или участок производства компании имеет свой характер и культуру, и это является частью стратегии компаний в том или ином регионе. Обычно такие локальные практики весьма популярны и служат источником укрепления лояльности сотрудников и гордости за свою работу. Этот фактор зачастую становится препятствием на пути полномасштабного, многорегионального внедрения такой сравнительно стандартизованной системы, как SAP. Руководитель проектного офиса (СРО) должен предпринять все возможное, чтобы обеспечить принятие стандартизированной системы во всех офисах и на всех участках производства. Меры, направленные на достижение этого могут быть следующими:
• Быстрое внедрение на пилотном участке.
• Быстрое разворачивание SAP на остальных участках производства и офисах.
• Делегирование ключевых работников всех подразделений компании для участия во внедрении на пилотном участке, даже если есть риск чрезмерной комплектации команды проекта.
• Взвешенный, обдуманный отбор и документирование функциональностей для внедрения на пилотном участке.
• Демократичный, прозрачный процесс стандартизации на основе заранее заданных критериев повышения эффективности, качества, оперативности, снижения затрат, ориентации на потребителя и т. д.
• Конфигурация и настройка максимально возможной функциональности на пилотном участке с оглядкой на практики и процессы, принятые на остальных участках деятельности компании.
Централизованная справочная база конфигурации
Компания может в полной мере получить все преимущества и выгоды от установки такой ERP-системы, как SAP, только если система внедряется во всех офисах и участках производства. В традиционных компьютерных системах внедрение стандартизированных процессов в масштабе всей компании значительно труднее. Так как проект SAP подразумевает и стандартизированные, и лучшие в своем классе процессы, такой проект приводит к реализации стандартизированных решений на всех участках деятельности компании.
На пилотном участке компания должна запланировать внедрение максимально всеобъемлющей функциональности, которая представляет собой централизованную справочную базу конфигурации (Centralized Base Reference Configuration, CBRC). В дальнейшем эту базу можно просто «пересаживать» на остальных участках. Такой подход значительно ускоряет процесс осуществления необходимых настроек, проведения обучения, тестирования на интеграцию и конечный запуск системы.
Методология AcceleratedSAP (ASAP)
Методология внедрения AcceleratedSAP (ASAP) — это новейший инструмент, представленный компанией SAP для быстрого внедрения системы. Методология ASAP — это структурный подход к внедрению, который значительно ускоряет продвижение проекта и обеспечивает эффективное обучение пользователей, исчерпывающую документацию и ясно составленные сетевые графики на всех стадиях проекта. Основные этапы методологии ASAP приведены ниже:
1. Подготовка проекта
2. Концептуальное проектирование
3. Реализация
4. Конечная подготовка
5. Запуск и поддержка.
Предоставляя лучшие в своем классе процессы и практики, SAP исключает необходимость трудоемких и утомительных этапов составления и анализа требований к системе, о котором говорилось выше.
Популярность, надежность и эффективность этого подхода берут начало от похожей методологии, применявшейся с огромным успехом при установке традиционных информационных систем в 80-е годы. Созданная Гейном и Сарсоном методология Structured Systems Analysis and Design (SSAD) пропускала общепринятую в то время практику анализа существующей системы, и сразу переходила к стадии анализа будущей системы. Поэтому, проект системы представлял собой абсолютно новую интерпретацию будущих требований организации, не подверженную влиянию таких затормаживающих факторов, как ограничения, практики и недостатки прошлых систем и процедур, принятых в компании.
Однако системы SAP пошли еще дальше, оптимизируя традиционные стадии проектирования и разработки с помощью библиотеки лучших в своем классе практик и заранее внедренных процессов, характерных для той или иной отрасли. Подробно эти стадии ASAP будут обсуждаться в IV части книги.