[ERP-системы, Управление проектами] Управление требованиями и сроками в методологии Oracle AIM BF
Автор
Сообщение
news_bot ®
Стаж: 6 лет 9 месяцев
Сообщений: 27286
При внедрении ERP компания Oracle использует методологию (AIM for BF — Application Implementation Method for Business Flow в прошлом, а ныне OUM — Oracle Unified Method), в которой применяется итеративный подход ко внедрению системы. Этот подход включает в себя несколько ключевых положений:
- Внедрение начинается с прототипа, в котором уже реализованы цепочки бизнес-процессов, которые могут быть приняты заказчиком в качестве целевых. При этом могут быть и отличия, которые в ходе проекта необходимо устранить.
- Для работы по проекту создается единая команда состоящая из консультантов, представителей заказчик от бизнеса и ИТ службы. Представители заказчика обучаются в ходе проекта и совместно с консультантами тестируют прототипы системы, формулируют требования к системе и принимают их реализацию. ИТ служба принимает активное участие, реализует часть требований, и по окончанию проекта берет систему на поддержку.
- В ходе проекта настраиваются еще несколько прототипов, которые с каждой итерацией становятся ближе к требованиям заказчика. В ходе проекта требования несколько раз уточняются и изменяются.
Фактически, в большом проекте по внедрению ERP применяются принципы agile – люди и взаимодействие важнее процессов, работающий продукт важнее документации, сотрудничество с заказчиком важнее контракта, готовность к изменениям важнее следования первоначальному плану.
Однако в условиях подписанного договора с фиксированной ценой, работы с большой единой системой эти принципы нуждаются в приземлении. Без дополнительных условий и ограничений проект с большой вероятностью не будет закончен, и уж точно выйдет за пределы бюджета.
Во-первых, это не разработка системы, которую можно запустить по частям, как это часто бывает в agile-проектах, когда каждая итерация должна заканчиваться разработкой законченного функционального блока, готового к использованию. ERP систему можно запустить только целиком, и никак не по частям.
Во-вторых, если не ограничить требования, то их уточнение и изменение будет бесконечным, проект растянется, потребует дополнительного финансирования.
Итак, первая проблемы – ERP система состоит из частей, которые тесно взаимосвязаны, пронизаны сквозными процессами. Поэтому нам нужна целостная система во всем своем объеме на каждой итерации. Задача облегчается тем, что система не создается с нуля, это уже готовый продукт. Часто есть отраслевое решение или преднастроенная система со стандартными процессами, которую можно использовать в качестве первого рабочего прототипа.
Для того, чтобы подготовить следующий прототип необходимо время. Система большая, сложная, участников проекта много, поэтому для подготовки прототипа, его тестирования и формирования замечаний к нему требуется не менее двух месяцев. Итерации в нашем случае – не две недели, как в типовом agile, а 2-5 месяцев.
На каждой итерации мы делаем полную систему, но между ними есть различия. На первой итерации – это типовая система со стандартными или отраслевыми процессами. Стандартные процессы могут быть довольно далеки от того, что заказчик ожидает увидеть в конечном итоге. Процессы на верхнем уровне – те же самые, но детали будут совсем другими. Говоря «заказчик» я подразумеваю людей, которые будут использовать систему – независимо какие отношения связывают его с исполнителем – контрактные, или это внутренний проект компании, где исполнителем может выступать ИТ подразделение.
После сбора требований по результатам тестирования первого прототипа мы настраиваем второй прототип, в котором все требования, которые можно реализовать настройками, реализованы, загружены тестовые данные заказчика, проработаны все вопросы, которые всплыли на тестировании первого прототипа. Заказчик проходит по бизнес-процессам в системе, проверяет, насколько текущая реализация устраивает, насколько система работоспособна и отвечает его требованиям.
На второй итерации будущие пользователи системы видят ее уже не первый раз, чувствуют себя более комфортно, выдвигают новые требования, уже более осмысленные и детальные. В идеале, в этот период должны быть решены все ключевые вопросы, потому что изменения становятся тем дороже, чем меньше времени остается до запуска.
На третьей итерации мы уже можем позволить себе приступить к разработке расширений или, как у нас называют на жаргоне, «кастомизаций» системы. Это могут быть отчеты, процедуры, формы, которые в стандартной системе отсутствуют, но они очень нужны, потому что подстроить бизнес-процессы под стандарт системы не всегда возможно. Решение о разработке расширений принимаются после рассмотрения всех других возможностей, т.к. их разработка и поддержка – удовольствие довольно дорогое, и это дополнительные деньги.
Третий прототип мы готовим несколько месяцев, с тем чтобы он стал полноценной системой, близкой к целевой. Обычно система полностью настроена, туда загружен существенный объем данных, установлены все критически важные расширения. Ее тестируют очень тщательно, с привлечением большого количества пользователей. Длится это тестирование обычно около месяца.
После тестирования третьего прототипа остаются замечания и вопросы, по которым мы составляем план их отработки. И к запуску все критичные замечания должны быть устранены.
Темп проекта к этому времени становится очень интенсивным, время сжимается, как во время схватки. Необходимо подготовить инструкции, обучить пользователей, конвертировать данные, провести оргизменения. Всплывают не решенные ранее вопросы, кто-то вспоминает, что забыл заявить о каком-то важном обстоятельстве… Перед запуском проводят еще одно, приемочное тестирование – и вперед, старт новой системы.
Это, естественно, весьма поверхностное описание итерационного подхода к внедрению ERP системы. В методологии детально описаны все процессы, включая документирование, обучение проектной команды и пользователей, конвертации данных, проведения организационных изменений и т.д., которые по сути не отличаются от любых других подходов ведения проекта.
Резонно возникает вопрос, каким образом организовать процесс таким образом, чтобы не уйти на четвертую, а потом на пятую или шестую итерации? Каким образом избежать риска неконтролируемого изменения и уточнения требований, что складывается естественно по мере погружения в детали, а иногда из-за изменения бизнеса?
Безусловно риск такой есть, и он весьма существенный. На входе в проект требования зафиксированы в договоре, но как правило они сформулированы в общем виде, а дьявол кроется в деталях.
При «водопадном подходе» в начале проекта фиксируются требования, подписывается ТЗ, которое становится формальным основанием позже отказать в изменении требований или попросить за изменение дополнительные деньги. В итерационном подходе такая уловка не применима.
Мы понимаем, что требования могут меняться и будут меняться обязательно. Мы закладываем на это время и деньги. Вопрос в объеме этих изменений. Мы можем сильно ошибиться, и получить вал новых замечаний в конце, особенно, если заказчик вначале относится к участию в проекте «спустя рукава», выделяет для участия не тех людей, не формулирует внятно требования, надеется на то, что «все будет хорошо», полагается на консультантов – тогда в конце мы имеем серьезные проблемы.
Поэтому самая главная составляющая снижения риска разрастания требований в конце проекта – это участие заказчика. Та самая реализация принципа разработки agile, согласно которой команда работает вместе – заказчик и разработчик, в тесном контакте с самого начала проекта. Это приводит к нескольким важным последствиям. Во-первых — раннее выявление реальных потребностей и несоответствия этим потребностям системы. Во-вторых, вовлекаясь в процесс подготовки системы, заказчика становится ее владельцем не в момент передачи ее в законченном виде, а постепенно, в ходе всего проекта. Она становится результатом его труда, и к концу проекта предъявлять претензии типа «ваша система не работает» становится невозможным, потому что это его система.
Хорошая практика, это когда в проект выделяются наиболее квалифицированные, способные принимать решение люди на 100% времени. На нашей практик это были владельцы бизнес-процессов, их заместители, либо сотрудники, пользующиеся полным доверием руководителей служб. Да, это сложно, да – лишних людей нет, да – сложно отдать самых лучших. Но только так можно сделать проект быстро и получить качественную систему. Участники проекта получают огромный скачок в понимании того, как работает предприятие, приобретают новые знания, учатся работать по-новому, и как правило для них это создает новые карьерные возможности. Можно рассматривать проект внедрения ERP, как чрезвычайно мощного мероприятия по развитию персонала, как создание нового кадрового резерва управленцев.
Второе, на что необходимо обратить внимание, это жесткие ограничения времени проекта. График проекта должен быть агрессивным, и дата запуска не должна меняться. Если проект растягивается, то вероятность изменения требований бизнеса увеличивается. Если дата проекта смещается, появляются новые требования, и ситуация повторяется: опять система не готова, давайте отложим запуск. Совершенства систем не достигнет даже при очень больших сроках проекта, и никогда все требования не буду выявлены полностью до запуска. Только реальная эксплуатация показывает все узкие места и что на самом деле важно. Поэтому после запуска идет период стабилизации не менее трех месяцев, в течение которых проектная команда помогает и доучивает пользователей, исправляет ошибки, получает новые требования и делает необходимые доработки.
Для того, чтобы побороть соблазн сдвинуть сроки и расширить требования, у всех должен быть сильный стимул эти сроки выдержать. У исполнителя, понятно, это контрактные обязательства и бюджет. У заказчика же мотивация обычно формируется сверху, от руководства или акционеров компании. Например, генеральный директор, принимающий решение о готовности к запуску, может быть скован обязательством перед акционерами. Руководитель проекта и проектная команда может быть мотивирована премией по окончанию проекта при условии соблюдения сроков. Руководители подразделений будут поставлены перед необходимостью запуститься приказом по предприятию.
Очень редко бывает, когда есть искренне желание скорее запустить систему из-за приятных ожиданий новых возможностей, которые она дает. Новая система – это прежде всего стресс и необходимость перехода от привычного к неудобному поначалу интерфейсу, к большему контролю, к необходимости вводить больше информации. Практически никогда конечные пользователи не приветствуют новую систему. Требуется время, чтобы они смирились и нашли преимущества в ней. И если изначально не встроить в проект внутреннюю мотивацию запуститься вовремя, запуск будет отложен, ибо систем никогда не будет готова к запуску на 100%.
При условии жестких сроков запуска становится невозможным расширять и уточнять бесконечно требования. Проектная команда, которая включает в себя представителей заказчика, перестает их выдвигать и начинает задумываться о приоритетах, о возможностях что-то отложить, перед лицом неизбежно надвигающегося дедлайна. Задача руководителя проекта – с самого начала проекта сформировать это чувство скорого запуска, дефицита времени. Слишком спокойная атмосфера в первой половине проекта означает, что вторая половина будет крайне стрессовой из-за гонки, которая неизбежно наступит. Для этого должны быть поставлены промежуточные цели, а график проекта сформирован таким образом, чтобы первые фазы проекта были сжаты во времени, а за счет этого сформирован резерв на последние фазы перед запуском. В забеге на длинные дистанции есть разные стратегии, но здесь стратегия должна быть одна – быстро бежать надо со старта, на ускорение в конце сил может не хватить.
Резюме всему вышесказанному:
- Итерационный подход дает гораздо лучший результат в смысле близости системы к заявленным и подразумеваемым требованиям заказчика.
- Для реализации этого подхода абсолютно необходимо полная вовлеченность заказчика в проект.
- Чтобы избежать разрастания и бесконечного уточнения требований, сроки проекта должны быть жестко ограничены, и у участников проекта должна быть мотивация их соблюсти.
Безусловно, это только основные принципы, есть еще много тонкостей, которые зависят от конкретных условий, особенностей компании и личности участников. В каждом конкретном случае все решается индивидуально.
===========
Источник:
habr.com
===========
Похожие новости:
- [Информационная безопасность, Софт] «Росатом» переходит на российское ПО
- [Oracle, Биллинговые системы] От Oracle до Tarantool и Hazelcast – современный BSS/OSS для телекома
- [ERP-системы, Машинное обучение, Финансы в IT] Новое в SAP PaPM: интерфейс, построение прогнозов с помощью ML и scale out
- [Облачные вычисления, История IT, Исследования и прогнозы в IT] Бархатная перчатка Microsoft
- [Управление проектами] Ещё одна статья «Как я сдавал PMP». Online. Лайфхаки
- [Atlassian, GTD, Управление проектами] Trello — начало работы и скрытые фишки
- [Карьера в IT-индустрии, Управление персоналом, Управление проектами] Старый новый VUCA-мир: как ответить на его вызовы
- [Конференции, Управление персоналом, Управление проектами, Управление разработкой] Почему онлайн-конференция по управлению знаниями — это не скучно
- [Управление проектами, Управление разработкой] Три истории и один вопрос
- [CRM-системы, ERP-системы, Open source, PHP, Развитие стартапа] Totum — open source конструктор CRM/ERP и произвольных учетных систем (PHP + PgSQL)
Теги для поиска: #_erpsistemy (ERP-системы), #_upravlenie_proektami (Управление проектами), #_erp, #_aim, #_oum, #_oracle, #_erpsistemy (
ERP-системы
), #_upravlenie_proektami (
Управление проектами
)
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 22-Ноя 17:12
Часовой пояс: UTC + 5
| Автор | Сообщение |
|---|---|
|
news_bot ®
Стаж: 6 лет 9 месяцев |
|
|
При внедрении ERP компания Oracle использует методологию (AIM for BF — Application Implementation Method for Business Flow в прошлом, а ныне OUM — Oracle Unified Method), в которой применяется итеративный подход ко внедрению системы. Этот подход включает в себя несколько ключевых положений:
Фактически, в большом проекте по внедрению ERP применяются принципы agile – люди и взаимодействие важнее процессов, работающий продукт важнее документации, сотрудничество с заказчиком важнее контракта, готовность к изменениям важнее следования первоначальному плану. Однако в условиях подписанного договора с фиксированной ценой, работы с большой единой системой эти принципы нуждаются в приземлении. Без дополнительных условий и ограничений проект с большой вероятностью не будет закончен, и уж точно выйдет за пределы бюджета. Во-первых, это не разработка системы, которую можно запустить по частям, как это часто бывает в agile-проектах, когда каждая итерация должна заканчиваться разработкой законченного функционального блока, готового к использованию. ERP систему можно запустить только целиком, и никак не по частям. Во-вторых, если не ограничить требования, то их уточнение и изменение будет бесконечным, проект растянется, потребует дополнительного финансирования. Итак, первая проблемы – ERP система состоит из частей, которые тесно взаимосвязаны, пронизаны сквозными процессами. Поэтому нам нужна целостная система во всем своем объеме на каждой итерации. Задача облегчается тем, что система не создается с нуля, это уже готовый продукт. Часто есть отраслевое решение или преднастроенная система со стандартными процессами, которую можно использовать в качестве первого рабочего прототипа. Для того, чтобы подготовить следующий прототип необходимо время. Система большая, сложная, участников проекта много, поэтому для подготовки прототипа, его тестирования и формирования замечаний к нему требуется не менее двух месяцев. Итерации в нашем случае – не две недели, как в типовом agile, а 2-5 месяцев. На каждой итерации мы делаем полную систему, но между ними есть различия. На первой итерации – это типовая система со стандартными или отраслевыми процессами. Стандартные процессы могут быть довольно далеки от того, что заказчик ожидает увидеть в конечном итоге. Процессы на верхнем уровне – те же самые, но детали будут совсем другими. Говоря «заказчик» я подразумеваю людей, которые будут использовать систему – независимо какие отношения связывают его с исполнителем – контрактные, или это внутренний проект компании, где исполнителем может выступать ИТ подразделение. После сбора требований по результатам тестирования первого прототипа мы настраиваем второй прототип, в котором все требования, которые можно реализовать настройками, реализованы, загружены тестовые данные заказчика, проработаны все вопросы, которые всплыли на тестировании первого прототипа. Заказчик проходит по бизнес-процессам в системе, проверяет, насколько текущая реализация устраивает, насколько система работоспособна и отвечает его требованиям. На второй итерации будущие пользователи системы видят ее уже не первый раз, чувствуют себя более комфортно, выдвигают новые требования, уже более осмысленные и детальные. В идеале, в этот период должны быть решены все ключевые вопросы, потому что изменения становятся тем дороже, чем меньше времени остается до запуска. На третьей итерации мы уже можем позволить себе приступить к разработке расширений или, как у нас называют на жаргоне, «кастомизаций» системы. Это могут быть отчеты, процедуры, формы, которые в стандартной системе отсутствуют, но они очень нужны, потому что подстроить бизнес-процессы под стандарт системы не всегда возможно. Решение о разработке расширений принимаются после рассмотрения всех других возможностей, т.к. их разработка и поддержка – удовольствие довольно дорогое, и это дополнительные деньги. Третий прототип мы готовим несколько месяцев, с тем чтобы он стал полноценной системой, близкой к целевой. Обычно система полностью настроена, туда загружен существенный объем данных, установлены все критически важные расширения. Ее тестируют очень тщательно, с привлечением большого количества пользователей. Длится это тестирование обычно около месяца. После тестирования третьего прототипа остаются замечания и вопросы, по которым мы составляем план их отработки. И к запуску все критичные замечания должны быть устранены. Темп проекта к этому времени становится очень интенсивным, время сжимается, как во время схватки. Необходимо подготовить инструкции, обучить пользователей, конвертировать данные, провести оргизменения. Всплывают не решенные ранее вопросы, кто-то вспоминает, что забыл заявить о каком-то важном обстоятельстве… Перед запуском проводят еще одно, приемочное тестирование – и вперед, старт новой системы. Это, естественно, весьма поверхностное описание итерационного подхода к внедрению ERP системы. В методологии детально описаны все процессы, включая документирование, обучение проектной команды и пользователей, конвертации данных, проведения организационных изменений и т.д., которые по сути не отличаются от любых других подходов ведения проекта. Резонно возникает вопрос, каким образом организовать процесс таким образом, чтобы не уйти на четвертую, а потом на пятую или шестую итерации? Каким образом избежать риска неконтролируемого изменения и уточнения требований, что складывается естественно по мере погружения в детали, а иногда из-за изменения бизнеса? Безусловно риск такой есть, и он весьма существенный. На входе в проект требования зафиксированы в договоре, но как правило они сформулированы в общем виде, а дьявол кроется в деталях. При «водопадном подходе» в начале проекта фиксируются требования, подписывается ТЗ, которое становится формальным основанием позже отказать в изменении требований или попросить за изменение дополнительные деньги. В итерационном подходе такая уловка не применима. Мы понимаем, что требования могут меняться и будут меняться обязательно. Мы закладываем на это время и деньги. Вопрос в объеме этих изменений. Мы можем сильно ошибиться, и получить вал новых замечаний в конце, особенно, если заказчик вначале относится к участию в проекте «спустя рукава», выделяет для участия не тех людей, не формулирует внятно требования, надеется на то, что «все будет хорошо», полагается на консультантов – тогда в конце мы имеем серьезные проблемы. Поэтому самая главная составляющая снижения риска разрастания требований в конце проекта – это участие заказчика. Та самая реализация принципа разработки agile, согласно которой команда работает вместе – заказчик и разработчик, в тесном контакте с самого начала проекта. Это приводит к нескольким важным последствиям. Во-первых — раннее выявление реальных потребностей и несоответствия этим потребностям системы. Во-вторых, вовлекаясь в процесс подготовки системы, заказчика становится ее владельцем не в момент передачи ее в законченном виде, а постепенно, в ходе всего проекта. Она становится результатом его труда, и к концу проекта предъявлять претензии типа «ваша система не работает» становится невозможным, потому что это его система. Хорошая практика, это когда в проект выделяются наиболее квалифицированные, способные принимать решение люди на 100% времени. На нашей практик это были владельцы бизнес-процессов, их заместители, либо сотрудники, пользующиеся полным доверием руководителей служб. Да, это сложно, да – лишних людей нет, да – сложно отдать самых лучших. Но только так можно сделать проект быстро и получить качественную систему. Участники проекта получают огромный скачок в понимании того, как работает предприятие, приобретают новые знания, учатся работать по-новому, и как правило для них это создает новые карьерные возможности. Можно рассматривать проект внедрения ERP, как чрезвычайно мощного мероприятия по развитию персонала, как создание нового кадрового резерва управленцев. Второе, на что необходимо обратить внимание, это жесткие ограничения времени проекта. График проекта должен быть агрессивным, и дата запуска не должна меняться. Если проект растягивается, то вероятность изменения требований бизнеса увеличивается. Если дата проекта смещается, появляются новые требования, и ситуация повторяется: опять система не готова, давайте отложим запуск. Совершенства систем не достигнет даже при очень больших сроках проекта, и никогда все требования не буду выявлены полностью до запуска. Только реальная эксплуатация показывает все узкие места и что на самом деле важно. Поэтому после запуска идет период стабилизации не менее трех месяцев, в течение которых проектная команда помогает и доучивает пользователей, исправляет ошибки, получает новые требования и делает необходимые доработки. Для того, чтобы побороть соблазн сдвинуть сроки и расширить требования, у всех должен быть сильный стимул эти сроки выдержать. У исполнителя, понятно, это контрактные обязательства и бюджет. У заказчика же мотивация обычно формируется сверху, от руководства или акционеров компании. Например, генеральный директор, принимающий решение о готовности к запуску, может быть скован обязательством перед акционерами. Руководитель проекта и проектная команда может быть мотивирована премией по окончанию проекта при условии соблюдения сроков. Руководители подразделений будут поставлены перед необходимостью запуститься приказом по предприятию. Очень редко бывает, когда есть искренне желание скорее запустить систему из-за приятных ожиданий новых возможностей, которые она дает. Новая система – это прежде всего стресс и необходимость перехода от привычного к неудобному поначалу интерфейсу, к большему контролю, к необходимости вводить больше информации. Практически никогда конечные пользователи не приветствуют новую систему. Требуется время, чтобы они смирились и нашли преимущества в ней. И если изначально не встроить в проект внутреннюю мотивацию запуститься вовремя, запуск будет отложен, ибо систем никогда не будет готова к запуску на 100%. При условии жестких сроков запуска становится невозможным расширять и уточнять бесконечно требования. Проектная команда, которая включает в себя представителей заказчика, перестает их выдвигать и начинает задумываться о приоритетах, о возможностях что-то отложить, перед лицом неизбежно надвигающегося дедлайна. Задача руководителя проекта – с самого начала проекта сформировать это чувство скорого запуска, дефицита времени. Слишком спокойная атмосфера в первой половине проекта означает, что вторая половина будет крайне стрессовой из-за гонки, которая неизбежно наступит. Для этого должны быть поставлены промежуточные цели, а график проекта сформирован таким образом, чтобы первые фазы проекта были сжаты во времени, а за счет этого сформирован резерв на последние фазы перед запуском. В забеге на длинные дистанции есть разные стратегии, но здесь стратегия должна быть одна – быстро бежать надо со старта, на ускорение в конце сил может не хватить. Резюме всему вышесказанному:
Безусловно, это только основные принципы, есть еще много тонкостей, которые зависят от конкретных условий, особенностей компании и личности участников. В каждом конкретном случае все решается индивидуально. =========== Источник: habr.com =========== Похожие новости:
ERP-системы ), #_upravlenie_proektami ( Управление проектами ) |
|
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 22-Ноя 17:12
Часовой пояс: UTC + 5