Коллектив авторов - Свод знаний по управлению бизнес-процессами: BPM CBOK 3.0
После этого проектная команда должна разработать схему верхнего уровня «как будет»[138]. При этом все подвергается сомнению и поощряются инновационные и нешаблонные идеи. Поиск решения не должен быть ограничен ничем, кроме юридических, финансовых и других рамок, заданных высшим руководством.
На этом уровне схема содержит очень мало подробностей реальных операций. Однако с точки зрения будущей схемы этот уровень наиболее важен, потому что именно здесь должны быть заложены фундаментальные изменения. Это отправная точка для детального проектирования. Если проектная команда не будет достаточно смелой при создании модели верхнего уровня, то недостаток креативности отразится и на дальнейшей детализации, и в результате масштаб изменений окажется невелик.
Модель верхнего уровня задает систему координат для детальной схемы процесса «как будет». С помощью имитационного моделирования проектная команда может проверить соответствие модели требованиям верхнего уровня и целям трансформации. Чтобы убедиться, что трансформация даст желаемые результаты, проектная команда должна просмотреть результаты имитационного моделирования схемы верхнего уровня вместе с высшим руководством. Полученные комментарии и замечания учитываются в ходе доработки, и затем проводится окончательное имитационное моделирование.
С приемкой модели верхнего уровня начинается основная работа по трансформации.
Проектная команда перебирает возможные решения в поисках оптимальной схемы, создавая таким образом серию детальных моделей «как будет» на основе утвержденной модели верхнего уровня.
В соответствии с процессным подходом в этот момент следует рассмотреть соответствие между процессом и организационной структурой.
Примечание: если для трансформации выбран организационный подход, то проект не будет охватывать кросс-функциональный процесс целиком, и в этом случае потребуется оценить воздействие изменений на часть процесса ниже по потоку, не охватываемую проектом. Такая оценка позволит установить, какие изменения допустимы в новой схеме. В этом проявляется ограниченность организационного подхода.
После того как новая схема «как будет» одобрена, можно приступать к проектированию нового процесса. Рекомендуется разделить модель верхнего уровня на несколько частей, чтобы запустить серию связанных, но отдельных проектов аналогично тому, как готовое изделие собирается из нескольких узлов, разрабатываемых отдельно.
Схема каждой части прорабатывается в деталях, при этом применяется тот же подход: все подвергается сомнению, инновационность всячески поощряется. Как и схема верхнего уровня, детальные схемы разрабатываются итерационно с использованием имитационного моделирования. Но при этом проектирование каждой части, являясь отдельным проектом трансформации, также часть общего проекта трансформации. Рассматривается как схема каждой части по отдельности, так и ее совместимость со схемой верхнего уровня. Каждая часть что-то получает на входе от других компонент, выполняет какие-то действия и на выходе передает данные и продукцию последующим компонентам в соответствии со схемой верхнего уровня. Это позволяет руководству контролировать усовершенствования и на уровне компонент, и на уровне проекта в целом.
По мере того как компоненты проектируются, тестируются и утверждаются, служба IТ получает требования верхнего уровня, а также детальные спецификации программных интерфейсов, модулей Java, веб-сервисов, структуры баз данных и прочие. Имитационное моделирование привязывается по срокам к готовности изменений в IТ-инфраструктуре, необходимых интерфейсов и т. п. Эта готовность определяет также расписание «окончательного» имитационного моделирования и общий график трансформации.
После того как «окончательное» имитационное моделирование завершено, новая схема должна шаг за шагом быть просмотрена каждым участником нового процесса. Их собственный опыт может потребовать дополнительных итераций, но в результате удастся достичь оптимума. В случае использования BPMS из новой схемы (включающей бизнес-модель, правила, данные, экранные формы) автоматически генерируются компьютерные приложения, исполняемые в среде BPMS. Интеграция этих приложений cо вспомогательными модулями, разработанными IТ-подразделением, дает на выходе итоговое решение.
7.5.1. В выигрыше должны быть все
Прежде всего в выигрыше должна быть компания. Но не должно получиться так, что компания будет единственным выгодоприобретателем, в выигрыше также должны быть менеджеры всех уровней и персонал. Если это становится основной целью проекта, то выработанное решение имеет хорошие шансы на одобрение, а риск будет сведен к минимуму.
Но понятие выигрыша неоднозначно. Выигрыш, когда кого-то оценили выше, чем можно было ожидать. Выигрыш, если снизилась нагрузка. Или изменилась культура, так что с людьми стали обращаться лучше и они не боятся быть уволенными в результате сокращения. Чтобы найти взаимовыгодное решение, надо разговаривать с людьми и выяснять, что они надеются получить в результате проекта. Здесь свою роль должен сыграть отдел управления персоналом.
Может показаться, что это просто, но если в организации действует профсоюз, то уже нет. И вообще в современном мире бизнеса, сильно регулируемом, со специфическим местным трудовым законодательством и отчетностью, решение любых проблем, связанных с персоналом, никак нельзя отнести к числу простых. Поэтому поиск взаимовыгодного решения обязательно должен вестись с участием отдела персонала.
Даже если это нелегко, проект трансформации обязан учитывать фундаментальные изменения в работе и все, что связанно с людьми. Ведь, в конце концов, любая компания и любой процесс – это социальное взаимодействие. Люди вместе работают, они взаимодействуют друг с другом, играют в политические игры и приводят бизнес в движение, ежедневно решая возникающие проблемы. Вот почему для успеха так важны люди и культурная составляющая трансформации.
7.5.2. Роль унаследованных технологий: помощь или ограничение
IТ может быть как помощником, так и ограничивающим фактором. Даже если все до одного работники IТ, включая IТ-директора, горят желанием помочь с трансформацией, во многих компаниях сокращение издержек привело к тому, что IТ мало что может. Унаследованные информационные системы и IТ-архитектура ограничивают диапазон возможных решений. Если рассматриваемое изменение невозможно реализовать без крупных инвестиций в IТ, его могут исключить из рассмотрения.
Как мы постоянно подчеркиваем, трансформация подразумевает переосмысление и радикально новые подходы. В противном случае вы просто будете делать то же самое, что не давало вам добиться успеха, но только быстрее. С одной стороны, это проблема, а с другой – реальность. У одних компаний проблемы с финансированием, у других – с IТ, у третьих – с профсоюзами и т. д. Эти реалии приходится принимать во внимание при выработке решения. Так что, хотя креативность и приветствуется, она должна оставаться в границах реальности.
Вести поиск решений за рамками определенных ограничений проектная команда может только после обсуждения с высшим руководством: это позволяет рассмотреть цели на более дальнюю перспективу. Ограничения и допущения, закладываемые в модель трансформации, со временем меняются. Так, например, конечная схема может проектироваться в расчете на устранение или смягчение финансовых ограничений. Затем проектная команда отступает назад, добавляя финансовые ограничения, заданные для определенных временных интервалов. Поскольку проект трансформации рассчитан на несколько лет, он может предусматривать изменение ограничений во времени и разработку решения, меняющегося во времени при смене одного ограничения другим, менее жестким. Это особенно актуально там, где ограничением является IТ-архитектура или инфраструктура: оно будет меняться с добавлением нового оборудования, программного обеспечения или коммуникаций.
В этом случае проектная команда должна работать совместно с IТ-директором и спланировать серию согласованных по времени расширений возможностей IТ. Это позволит достигать результатов поэтапно путем реализации все более гибких и мощных решений.
7.5.3. BPMS и трансформация компании
Сегодня многие считают, что настоящая трансформация невозможна без BPMS. Аргументируется это тем, что, хотя схему можно разработать с помощью простейших средств, даже просто на бумаге, она не будет такой точной, как могла бы. Проще говоря, данные, накапливаемые в ходе трансформации, невозможно поддерживать в актуальном состоянии из-за проходящих почти ежедневно изменений.
