Коллектив авторов - Свод знаний по управлению бизнес-процессами: BPM CBOK 3.0

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

С приемкой модели верхнего уровня начинается основная работа по трансформации.

Проектная команда перебирает возможные решения в поисках оптимальной схемы, создавая таким образом серию детальных моделей «как будет» на основе утвержденной модели верхнего уровня.

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

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

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

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

По мере того как компоненты проектируются, тестируются и утверждаются, служба IТ получает требования верхнего уровня, а также детальные спецификации программных интерфейсов, модулей Java, веб-сервисов, структуры баз данных и прочие. Имитационное моделирование привязывается по срокам к готовности изменений в IТ-инфраструктуре, необходимых интерфейсов и т. п. Эта готовность определяет также расписание «окончательного» имитационного моделирования и общий график трансформации.

После того как «окончательное» имитационное моделирование завершено, новая схема должна шаг за шагом быть просмотрена каждым участником нового процесса. Их собственный опыт может потребовать дополнительных итераций, но в результате удастся достичь оптимума. В случае использования BPMS из новой схемы (включающей бизнес-модель, правила, данные, экранные формы) автоматически генерируются компьютерные приложения, исполняемые в среде BPMS. Интеграция этих приложений cо вспомогательными модулями, разработанными IТ-подразделением, дает на выходе итоговое решение.

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

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

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

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

IТ может быть как помощником, так и ограничивающим фактором. Даже если все до одного работники IТ, включая IТ-директора, горят желанием помочь с трансформацией, во многих компаниях сокращение издержек привело к тому, что IТ мало что может. Унаследованные информационные системы и IТ-архитектура ограничивают диапазон возможных решений. Если рассматриваемое изменение невозможно реализовать без крупных инвестиций в IТ, его могут исключить из рассмотрения.

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

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