Наконец проектирование завершено.
• Вся не добавляющая ценность работа исключена.
• Все проблемы рассмотрены.
• Все возможности усовершенствования бизнеса рассмотрены.
• Правила обоснованы и нормализованы.
• Ручная, неавтоматизированная работа устранена.
• Бизнес-сценарии упорядочены.
• Проанализировано возможное влияние изменений на всех уровнях процессной иерархии.
• Определены все источники данных, интерфейсы с унаследованными приложениями, преобразование и использование данных.
• Специфицированы потребности в автоматизации.
• Произведена оценка показателей новой модели по сравнению с исходной «как есть».
• Спроектирована система контроля для новой бизнес-модели и для проекта внедрения.
• Спроектирована система контроля эффективности, предупреждения о проблемах и другой отчетности.
Как обычно при проектировании и при составлении требований, глубина детализации модели зависит от сложности предстоящих изменений и от масштаба затрагиваемых проектом бизнес-операций, а также от того, будет ли использоваться BPMS и генерация приложений или традиционная IТ-разработка на основе бизнес-требований и технических спецификаций.
В любом случае уровень детализации, диктуемый действующими стандартами, достигнут. В зависимости от выбранной стратегии можно приступать к внедрению либо конкретного разового изменения, либо (если выбран путь эволюционных изменений) к первой фазе изменений бизнес-операций.
5.6.2.4. Бизнес-правила – непрерывный поиск возможностей усовершенствования
Данные – это кровь в жилах бизнеса. Они протекают сквозь операции и поддерживают в них жизнь. Следуя этой аналогии, бизнес-правила – это мозг бизнеса. Правилами определяется, что будет делаться, когда, где, кем и как все это будет управляться и контролироваться. Значение качества правил, которыми управляется бизнес, невозможно переоценить. Неэффективные правила приводят к неэффективному бизнесу, в котором качество страдает, а затраты растут.
Реальность многих компаний такова, что большинство писаных правил устарели и противоречат друг другу. Зачастую правила вводятся посредством служебных записок или электронных писем, которые могут сохраниться, а могут и нет или (в лучшем случае) добавляются к пачке существующих регламентов. Этой проблеме редко уделяется внимание, и правила, которым следуют операции, зачастую не соответствуют текущей политике и даже законодательству.
Поэтому любой проект BPM должен уделять внимание поиску, каталогизации, описанию и нормализации бизнес-правил, а также их применению. Если используется BPMS или машина бизнес-правил, необходимо также следить за тем, как правила «закодированы» в программном обеспечении.
Многие организации тяготеют к усложнению бизнес-правил. Отчасти это связано со стремлением сократить их число – многие стремятся представить все дерево принятия решения в виде одного правила, вместо того чтобы разбить его на отдельные решения и затем объединить их в набор правил. Помимо того что переусложненные правила труднее тестировать и использовать, они усложняют процесс. А чем сложнее процесс, тем выше вероятность сбоя. Вот почему важно ориентироваться на наборы правил и вырабатывать такие стандарты, которые позволят сохранять правила настолько простыми, насколько возможно.
Каждое правило должно быть протестировано по отдельности – и его описание, и реализация в машине бизнес-правил. Затем должны быть протестированы наборы. Юридический и финансовый отделы должны проконтролировать результаты тестирования на предмет соответствия требованиям закона и финансовой дисциплины. Также следует протестировать эффективность правил: неудачно закодированные правила могут замедлить информационную систему, а следовательно, бизнес.
В итоге команда должна выявить все правила, удостовериться в их применимости и качестве и в том, что они максимально эффективно закодированы.
Поскольку правила постоянно меняются и (предположительно) более изменчивы, чем любая другая составляющая бизнес-операций, минимум каждые полгода следует проверять их актуальность. Такая проверка должна выявить изменения, новые правила и появившиеся в связи с правилами лишние действия. Хотя это можно отнести к постоянной деятельности, она жизненно важна в контексте устойчивого поддержания оптимальности бизнес-операций.
5.7. Управление изменениями
Множество отличных проектов провалилось из-за того, что команда не уделяла достаточного внимания управлению изменениями и созданию благожелательного отношения со стороны бизнес-пользователей. Все просто: если люди, выполняющие бизнес-задачи, работающие с информационной системой, измеряющие эффективность и т. д., будут чувствовать себя в новой среде некомфортно, то они не примут изменения и будут им сопротивляться.
О корпоративной культуре и управлении изменениями написана масса книг. Некоторые компании решают проблему одобрения изменений персоналом через создание формальных групп управления изменениями и выработку стандартов внедрения изменений в бизнесе и в IТ. Другие требуют, чтобы проект включал в себя человеческую составляющую и чтобы в нем уделялось внимание донесению до персонала причин изменений, намерений и планов.
К изменениям можно подходить одним из двух способов: либо вы делаете что-то вместе с людьми, либо над ними. Очевидно, стремиться надо к первому. Прежний подход, в котором ставка делалась на выделенного эксперта предметной области, который решал, что и как будет делаться, применительно к BPM доказал свою неэффективность. Просто если целью является новый способ ведения бизнеса, то изменения оказываются слишком глубокими. Старый способ годился тогда, когда речь шла о новом средстве (новой информационной системе), который накладывался на существующие бизнес-операции. BPM предполагает большую вовлеченность со стороны бизнеса, а технологии BPM – более тесное взаимодействие между бизнесом и IТ при проектировании.
Персонал либо воспримет изменения, либо найдет способ продемонстрировать их провал. Если большинство почувствует в изменениях угрозу, оно найдет способ их провалить. Такова реальность. В данном разделе мы лишь хотели сказать, что BPM предполагает новый уровень управления изменениями и поэтому проектирование процессов должно предусматривать методы, способствующие установлению доверия и вовлечению персонала. Более подробно об управлении изменениями см. раздел 7.3.
5.8. Анализ и проектирование IТ-инфраструктуры
Новая модель бизнес-операций может потребовать изменений в IТ-приложениях и поменять то, как операции распределяются по офису и по производственным помещениям компании. Это, в свою очередь, повлияет на требования к IТ-инфраструктуре и коммуникациям.
Новая модель может также вызвать изменение требований к интерфейсам унаследованных приложений и к интерфейсам доступа к данным, которые, в свою очередь, могут повлиять на IТ-стратегию и инфраструктуру, включая хранение и использование данных и документов.
Если выбран путь эволюционных изменений, то необходимо проанализировать IТ-инфраструктуру и привязать ее изменения к фазам эволюции бизнес-операций. Это позволит учесть планируемые изменения бизнеса в планах и бюджете IТ-отдела. Это также даст возможность группе архитектуры предприятия в составе IТ заранее начать присматриваться к новым технологиям и к новым приложениям, чтобы в момент, предусмотренный планом эволюционных изменений, выбрать оптимальное решение.
Вот некоторые вопросы, которые встанут перед IТ.
• Какое программное обеспечение максимально соответствует требованиям процесса?
• Накладывает ли текущая инфраструктура ограничения на возможную модель бизнеса?
• Возможно ли быстро внедрить новую модель бизнеса?
• Как изменения в IТ влияют на организацию?
• Можно ли прибегнуть к поэтапному подходу?
• Каковы затраты на внедрение новой модели (включая обучение, программное обеспечение и т. д.)?
• Могут ли поставщики программного обеспечения помочь с внедрением?
Архитекторы BPM, корпоративные и бизнес-архитекторы должны рассмотреть эти вопросы совместно, чтобы согласовать требования бизнеса с возможностями IТ. Архитектор BPM сможет понять с какими ограничениями сталкивается IТ и какие ограничения IТ-инфраструктура накладывает и будет накладывать в будущем, с учетом ее эволюции.
5.9. Имитационное моделирование
