Джон Джестон - Управление бизнес-процессами. Практическое руководство по успешной реализации проектов Страница 69
- Категория: Бизнес / Управление, подбор персонала
- Автор: Джон Джестон
- Год выпуска: 2012
- ISBN: 978-5-9614-3755-3
- Издательство: Литагент «Альпина»
- Страниц: 134
- Добавлено: 2018-07-25 15:58:59
Джон Джестон - Управление бизнес-процессами. Практическое руководство по успешной реализации проектов краткое содержание
Прочтите описание перед тем, как прочитать онлайн книгу «Джон Джестон - Управление бизнес-процессами. Практическое руководство по успешной реализации проектов» бесплатно полную версию:В предлагаемой книге подробно излагаются основополагающие принципы управления бизнес-процессами, их преимущества и выгоды для организаций, а также приводятся примеры осуществления такого управления. В ней рассматривается общая схема, комплекс инструментов и методов ВРМ, а также выбор одного из четырех вероятных сценариев его реализации.
Книга содержит более пятидесяти конкретных примеров, иллюстрирующих различные ее положения, а также этапы проекта ВРМ и основные атрибуты, которые являются важными факторами обеспечения успеха проекта. Вы сможете заглянуть внутрь механизма, при помощи которого можно определить готовность организации или структурного подразделения к ВРМ, поймете что, зачем и как делается при реальном усовершенствовании процессов.
Книга может служить справочником для организаций, осуществляющих проекты управления бизнес-процессами, поскольку материал, изложенный в ней, дает в руки группы проекта практический инструментарий, пояснения и помощь в успешной реализации проекта ВРМ.
Джон Джестон - Управление бизнес-процессами. Практическое руководство по успешной реализации проектов читать онлайн бесплатно
• тест приемки пользователями (UAT) выполняется пользователями системы. В «теневых» эксплуатационных условиях автоматизированное решение BPM будет испытано на предмет соответствия требованиям бизнеса. Это включено в этап реализации;
• регрессионный тест предназначен показать, что все части системы по-прежнему функционируют правильно после внедрения или модификации автоматизированного решения BPM. Регрессия – это явление, показывающее, что качество системы как целого не ухудшается в результате отдельных модификаций.
Разумеется, нужно следовать обычному процессу тестирования:
1. Определите показатели теста. Тестирование всегда предполагает баланс между выгодами от тестирования и связанными с ним затратами. 100-процентное тестирование – практически нереальное и чрезвычайно дорогостоящее мероприятие. TMap® – прагматичный подход, описанный в {57}.
2. Определите и опишите стратегию тестирования, которая должна включать тест блоков, приемки пользователями (UAT), интеграции, регрессионный тест и т. д. Необходимо обдумать используемую инфраструктуру. Замечание: обязательно сделайте все возможное в рамках проекта, чтобы на стадии тестирования использовалась точная копия действующей среды инфраструктуры. Многие проекты развалились, если данное условие не было выполнено. Также помните, что не все тесты относятся к системам приложений. В процессной среде бо льшая часть тестирования вращается вокруг «пробных прогонов» процессов в бизнес-подразделении и определения его пригодности для заданной цели.
3. Составьте план тестов. Организация принимает решение о количестве и типах тестовых конфигураций. Не забудьте привлечь все соответствующие заинтересованные стороны и другие подгруппы проекта.
4. Опишите различные конфигурации тестов. Объем их будет зависеть от размера и сложности проекта. Самое важное – охватить все вероятные сценарии.
5. Выполните тестирование. Завершите конфигурации и программы тестов.
6. Проанализируйте результаты и решите, как двигаться дальше. Варианты: продолжать реализацию, приостановить внедрение, пока не устранены ошибки, продолжить внедрение и обеспечить внесение изменений по ходу или же скомбинировать три этих варианта.
Не все тесты фактически выполняются на данном этапе, но их нужно обязательно предусмотреть. Например, примененные тесты пользователей подготавливаются и осуществляются как часть шагов 3 и 5 этапа реализации.
Реализация ценности
Чтобы добиться согласия, необходимо тщательно определить выигрыши как часть данного этапа. Подробности описаны в главе 21, шаг 5, в связи с реализацией ценности в проекте.
Результаты этапа разработки
* * *Этап разработки дает значимый вклад в другие этапы общей схемы (рис. 19.7), вот лишь несколько примеров:
• решение может налагать требования на людей, которые будут работать с системой;
• этап разработки дает информацию для обучения на этапе реализации-внедрения;
• предложенная система может обеспечивать функциональность, которая дает бизнесу дополнительные возможности, или же не обеспечить все функции, предусмотренные на этапе инноваций, и в этом случае должны быть привлечены люди, готовившие спецификации после этапа инноваций;
• этап разработки должен обеспечить устойчивое функционирование;
• разработка ПО может повлиять на изменения в архитектуре процессов (особенно соответствующей информации и технологий).
Риски этапа разработки
На данном этапе присутствуют некоторые риски, так что нужно предусмотреть и реализовать стратегии их исключения (или хотя бы снижения). Некоторые риски перечислены в табл. 18.2 (см. выше).
В табл. 19.1 указаны риски и стратегии снижения, которые должны быть рассмотрены на этапе разработки.
Таблица 19.1. Риски и стратегии их снижения на этапе разработки
Глава 20
Этап реализации
Назначение
На этапе реализации (рис. 20.1) все спроектированные и разработанные усовершенствования процессов осуществляются в реальности. Здесь также сходятся вместе многие действия по управлению изменениями персонала. Хотя это одна из последних частей всей общей схемы и цикла проекта, ее следует рассмотреть в самом начале каждого проекта, с этапом стартовой площадки, поскольку именно в начале проекта нужно принять решение относительно его внедрения в бизнес (подробности см. в главе 15). Решение о реализации окажет влияние на такие грани проекта, как проектирование или перестройка процессов, выполнение разработки и тестирования и т. п. К этому решению постоянно возвращаются по ходу проекта, понимая, что метод реализации может измениться.
Кейс: запоздалая реализация в малом масштабе
Нас пригласили проанализировать неудачный BPM-проект. Его спонсор был поражен, что проект не удался: все метрики были определены, технология работала, основные заинтересованные лица получали сведения еженедельно, а пользователи готовились по проекту через масштабную кампанию расклейки постеров, рассылок по электронной почте и по программе интенсивного обучения.
Мы побеседовали с пользователями, и они сообщили, что с ними не посоветовались о предлагаемых изменениях, которые строились на неверных предположениях, и на практике не сработали бы. Когда мы поинтересовались у спонсора проекта, на какой стадии проекта советовались с пользователями и сообщали им об изменениях, оказалось, что это было осуществлено лишь после создания перестроенных процессов с помощью внешнего аналитика и своих менеджеров.
Вывод. Пользователи должны привлекаться в проект на самых ранних стадиях, как, впрочем, и все заинтересованные стороны.
Результаты
Если этап реализации завершен успешно, то организация может надеяться получить:
• обученный и мотивированный персонал;
• усовершенствованные или новые процессы, которые работают удовлетворительно, согласно требованиям и нуждам определенных заинтересованных сторон и бизнес-обоснованию.
Кейс: тест у кофейного автомата
Об участии заинтересованных сторон и пользователей часто говорят, но редко его добиваются. Нам кажется, что можно легко проверить (простым и ненаучным способом), привлечены ли пользователи.
Подойдите к кофейному автомату в любой фирме и спросите у сотрудников о предлагаемых улучшениях процессов. Если ответы будут вроде: «Понятия не имею, чем они там занимаются», «Они провели увлекательные беседы, но я ничего не слышал в подробностях» или «Нам они все равно ничего не говорят», знайте, что налицо явные признаки невовлеченности пользователей и недостаточного общения.
Жалоба
Напишите нам, и мы в срочном порядке примем меры.