Текст книги "Управление бизнес-процессами. Практическое руководство по успешной реализации проектов"

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

Лучше получить эту информацию на практическом совещании, типовая повестка и подход которого приводятся в Приложении Е.

При разработке этих моделей очень полезно уловить различные метрики, связанные с бизнес-подразделением организации и процессами, – например, определить число работников, занятых в каждом процессе или группе процессов, соответствующий объем продаж и обслуживающих транзакций и т. п. Это поможет сориентировать группу процессов в выборе процессов или участков бизнеса для начала таких последующих этапов схемы, как понимание и инновации.

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

• моделей данных, их опорных принципов и логики;

• основных приложений и соответствующих интерфейсов, их опорных принципов и логики;

• основного промежуточного ПО, его опорных принципов и логики;

• основных платформ, их опорных принципов и логики;

• основных сетей, их опорных принципов и логики.

Наш опыт подсказывает, что самая крупная проблема встраивания архитектуры ИТ в архитектуру предприятия – наличие в подразделении ИТ большинства организаций огромного числа инструментов и приложений. Поэтому нужно суметь сосредоточиться на принципах и основных вариантах выбора.

Кейс: «неправильная» архитектура

Подразделение ИТ одной организации решило внедрить архитектуру предприятия и выдало ее в виде более чем семидесятистраничного технического описания. Когда им задали вопрос о следующих шагах, они сказали, что хотят, чтобы высшее руководство утвердило и в приказном порядке ввело эту «архитектуру». Однако им пришлось признать, что руководство вряд ли разберется в таком документе, не говоря уже о его утверждении. Они осознали, что нужно разработать архитектуру принципиально иным способом: скорее продвигаемую бизнесом, чем наоборот. Разработчики поставили бизнес во главу угла, что привело к созданию полноценной и принятой организацией архитектуры.

Вывод. Крупная проблема архитектуры процессов состоит не в ее формулировании, а в том, чтобы добиться убежденности людей, которые сами захотят использовать такую архитектуру.

Более того, существенно, что ИТ поддерживают цели, стратегию и бизнес, и именно поэтому целесообразно уже иметь архитектуру процессов и бизнеса до выстраивания архитектуры ИТ. Но если разработка архитектуры началась с архитектуры ИТ, нужно внимательно следить за сохранением поддерживающей роли ИТ для требований бизнеса.

На этом шаге вся информация консолидируется и сверяется. Часто данный шаг оказывается наиболее проблемным, потому что именно здесь сходятся все противоречивые приоритеты и требования, и именно здесь все они должны быть разрешены. Например, бизнесу может быть нужна гибкость, а подразделению ИТ – стандарты и единообразие.

Один из способов консолидации накопленной информации – сопоставить различные архитектурные модели друг с другом. Например, сочетание организационно-структурных схем и процессов дает карту-схему организационных взаимосвязей (рис. 14.9).

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

Пример нестыковки процесса также приведен на рис. 14.9. Центр обработки вызовов реализует и вырабатывает руководящие инструкции по кредитованию для организации, отдел взыскания занимается сбором неоплаченных в срок сумм. На этом рисунке нет обратной связи между опытом отдела по взыскиванию сумм относительно эффективности методических инструкций и центром обработки вызовов, чтобы при необходимости подправлять правила кредитования. Если инструкции по кредитованию неудачны, центр обработки вызовов не получит обратной связи.

Лучший способ выработать такую схему – провести практическое совещание со всеми заинтересованными сторонами, при этом:

• используя цели и стратегию организации в качестве отправной точки;

• внося все разнообразные требования и взгляды заинтересованных сторон;

• выявляя взаимосвязи и противоречия между этими требованиями;

• обсуждая противоречия и находя пути их разрешения; здесь проблема – снова выйти из замкнутого пространства мышления и набраться смелости, чтобы принимать решения с мыслью о будущем, вместо того чтобы застрять в настоящем;

• ранжируя требования;

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

• подготавливая планы мероприятий для устранения нестыковок и противоречий (включая пути эскалирования);

• предоставляя окончательные выводы соответствующим руководителям, четко обозначив связь со стратегией и целями организации и указывая, как сформулированная архитектура будет содействовать их осуществлению;

• добиваясь окончательного утверждения.

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

• расклеивая постеры с моделями архитектуры во всей организации;

• обеспечивая применение архитектуры всеми структурными подразделениями при определении объемов и принятии решений;

• обеспечивая запуск всех проектов с архитектуры как со стартовой позиции.

Любая организация, желающая использовать архитектуру процессов, должна наладить необходимую дисциплину. Это означает, что все соответствующие проекты должны учитывать архитектуру и выявлять, где они отклоняются от согласованных принципов.

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

В DYA® (DYnamic Architecture. Вагтер и др., {77} – динамичная архитектура) преследуется весьма практичный подход к таким ситуациям: признается тот факт, что бывают случаи, когда срочные нужды бизнеса превалируют над архитектурными вопросами. Но вместо борьбы с этим, руководству следует сосредоточиться на ограничение воздействия таких отклонений. Тем не менее, любое отклонение от согласованной архитектуры должно отвечать следующим условиям:

• должны быть определены краткосрочные и длительные последствия отклонений (например, дополнительные расходы на обслуживание);

• в предложении должно быть указано, каким образом решение будет соответствовать согласованной архитектуре – либо оно будет постепенно выводиться из применения (что, как правило, делается в случае разового проекта или проблемы), либо же двинется в сторону согласованной архитектуры (как в случае новой версии приложения, которая решает требуемые архитектурные вопросы);

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

Данный подход можно сравнить с механизмом клапана скороварки (выпускание пара защитным клапаном): когда давление становится слишком высоким, лучше контролируемо снижать его (рис. 14.11), чем сопротивляться ему и получить в итоге взрыв (см. рис. 14.10).

Полезный способ вживления архитектуры процессов в организацию – сформировать комитет по архитектуре бизнес-процессов.

Данный комитет должен располагать полномочиями по поддержанию общего вида процессов всей организации и архитектуры процессов. Комитет должен установить и поддерживать связи между стратегическими целями организации и задачами процессов. Ему также должно быть известно, в какой степени каждый процесс поддерживает определенную стратегическую цель. (Вариант: проект работает по архитектуре процессов и вносится в хранилище данных архитектуры процессов).

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

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

Комитет по архитектуре бизнес-процессов работает на постоянной основе, а не формируется под конкретный проект.

Чтобы проект применял архитектуру процессов, организации следует выработать структуру запуска проекта (СЗП – PSA) на основе DYA® {77}. СЗП обеспечивает резкий старт проекта, поскольку дает группе проекта необходимые компоненты, не перегружая его чрезмерно полной архитектурой процессов, если в этом нет нужды, т. е. СЗП – подмножество архитектуры процессов организации. В нее включаются такие модели, как структурно-организационная схема, портфель продуктов, модели процессов и приложений, а также соответствующие методические руководства, относящиеся к ним. Преимущество СЗП в том, что она обеспечивает механизм, позволяющий не тратить недели на сбор всей необходимой информации для более подробной архитектуры проекта.

Архитектуру процессов нельзя завершить – ее можно только улучшить.

Архитектура процессов всегда должна поддерживаться в актуальном состоянии, а для работы с изменениями необходимо определить механизм управления ими. Это существенно, поскольку любое изменение в архитектуре может повлиять на процессы, которые были разработаны с использованием старых ее версий. Чтобы управление изменениями имело место, необходимо четко определить, кто хозяин – владелец архитектуры.

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

• в ширину – включать больше элементов (например, вопросы ИТ);

• в глубину – включать больше подробностей (например, более детальные модели процессов);

• по объему – включать больше процессов (например, создание моделей дополнительных процессов бизнес-подразделения).

И, наконец, не последний по важности момент: необходимо обеспечить, чтобы архитектуру использовали все больше и больше людей, например аудиторы, аналитики ИТ и бизнеса.

Реальные выгоды архитектуры процессов со временем становятся очевидны: когда наступают новые события и новые вызовы, меняется стратегия, или внедряется новая система, архитектура процессов задает направление для оценки эффекта этих воздействий.

Шаг 7 должен обеспечить регулярную оценку архитектуры, чтобы она была полезна и подходила для организации.

Здесь нужно описать механизм управления извлечением выгод и преимуществ как части данного этапа. Подробности см. в главе 21, шаг 1, где это описано в связи с реализацией ценности в рамках проекта.

Этап архитектуры процессов дает ценный вклад в другие этапы общей схемы внедрения (рис. 14.12). Приведем лишь несколько примеров:

• модели бизнес-процессов, создаваемые на этапах понимания и инноваций, используют архитектуру, созданную или уточненную на данном этапе;

• архитектура процессов дает общие методические указания по формированию объема проекта и его организационной структуры на этапе стартовой площадки;

• по обратной связи данный этап подпитывает этап стратегии организации в плане целесообразности и пригодности, а также способности организации реализовать стратегию в рамках существующих процессов.

В табл. 14.1 приведены самые распространенные риски разработки архитектуры процессов.

Таблица 14.1. Риски этапа архитектуры процессов и стратегии их снижения

Типовой образец этапа архитектуры процессов приведен в Приложении B.

Глава 15
Этап стартовой площадки

Часто организации бывает очень трудно определить, где начинать проект BPM. Могут быть известны проблемы и неэффективность работы конкретного подразделения предприятия, однако весьма трудно решить, как и где начинать проект.

Кейс: с чего начать

Руководитель дает указания менеджеру процессов: «Найди мне существенные усовершенствования процессов, где можно добиться значительной экономии в организации». Менеджер процессов был лишь недавно назначен на должность, и не знает, с чего начинать. Он организовывает несколько групп проекта, чтобы процессно моделировать различные участки бизнеса в их текущем состоянии. Перед этим не проводится общего анализа для выявления вероятных областей экономии и нацеленных действий, поддержка проектов со стороны высшего руководства незначительна или отсутствует вовсе, менеджеру процессов не оказывается кураторской поддержки BPM. Проект, в основном, не оправдывает ожиданий заинтересованных сторон, и большей частью свертывается уже через год.

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

Этап стартовой площадки (рис. 15.1) – это платформа, на которой масштабируются, организуются и запускаются проекты BPM (рис. 15.2).

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

Этот этап – просто способ начать проект, здесь выполняются шаги, необходимые для организации проекта ради его успеха, включая объем проекта, выбор и структуру группы проекта, ожидания заинтересованных сторон, организационное оформление и распределение обязанностей, определение первоначальных задач проекта и использование стартовой архитектуры процессов для быстрого запуска проекта с архитектурной точки зрения. Каждый последующий проект, запускаемый с данной стартовой площадки, получит возможность перенимать опыт предыдущих проектов BPM, а не начинать с нуля, всякий раз изобретая колесо. Чтобы организация продвигалась вперед, чрезвычайно важно систематическое и структурированное внедрение в выбранный подход осмысленного и освоенного опыта, накопленного ранее.

Среди предполагаемых результатов этапа стартовой площадки перечислим:

1. Определение заинтересованных сторон, привлекаемых к проекту или связанных с ним.

2. Привлечение и «заточенность» на проект заинтересованных сторон; документированные и согласованные ожидания.

3. Матрицу выбора процесса.

4. Перечень выделенных бизнес-процессов и исходные метрики.

5. Перечень согласованных задач процессов.

6. Перечень в порядке приоритета процессов, выбранных для этапа понимания.

7. Первоначальная стратегия реализации.

8. Управление проектом:

• положение о проекте;

• описание объема проекта;

• первоначальную схему календарного плана проекта (этап понимания выполняется детально);

• разработка и описание начальной стратегии распространения и доведения информации;

• исходный анализ рисков.

9. Разработку исходного варианта экономического обоснования.

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

По-прежнему следует выполнять все шаги, но глубина некоторых из них будет определяться методом выбора проекта и сценарием. Конкретно это будет указано при описании каждого шага.

До начала этого этапа необходимо донести до персонала информацию о проекте, его задачах, исходном или вероятном объеме и ориентировочных сроках. В некоторых организациях проекты BPM отмечены «проклятьем» со времен BPR – BPR в них равнозначно сокращению персонала, поэтому люди сначала затаятся. Эту проблему нужно снять с самого начала путем эффективного информирования и общения, объясняя людям, почему BPM – совсем другая «штука».

Распространение информации и сообщение ее людям должно продолжиться на всем этапе и в проекте целиком, по мере уточнения его объемов и планов. Сообщаемая информация должна включать постоянное обновление знаний о следующих действиях:

• как проект повлияет на персонал;

• какого поведения персонал может ожидать от руководства;

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

Старайтесь предвосхищать вопросы и возражения и заранее быть готовым отвечать на них. Анализируйте работу целевых групп и специально формулируйте сообщения для них, выдерживая последовательность и согласованность.

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

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

В результате собеседований:

• устанавливается контакт и связи с заинтересованными сторонами (как часть работы с заинтересованными сторонами);

• формируется общее понимание проблем с точки зрения заинтересованных сторон;

• определяются быстрые выигрыши, которых страстно желают заинтересованные стороны.

Этот шаг нельзя путать с шагом 4, где определяются все заинтересованные стороны и лица проекта, что служит входными данными для стратегии управления отношениями с заинтересованными сторонами, описанной в главе 24.