Литература:

• Статьи
• Обзоры:    0    0    17    16    15    14    13    12    11    10    9    8    7    6    5    4    3    2    1  
• Форумы
• Стандарты
• Книги
• Авторы

«Creating a BPM and Workflow Automation Vendor Checklist». Jim Sinur, David W. McCoy, Toby Bell

«Creating a BPM and Workflow Automation Vendor Checklist». Jim Sinur, David W. McCoy, Toby Bell, Gartner Group, 2003 г.

Список вопросов к поставщикам при выборе BPM/Workflow системы.

Прежде всего, аналитики Гартнер советуют принять как данность, что пока что ни одному продукту или поставщику не под силу закрыть все 5 классов задач, относимых к BPM (см. «A BPM Taxonomy: Creating Clarity in a Confusing Market»). Поэтому критически важно осознать стоящие перед предприятием задачи и не пытаться применять инструмент для задач, к которым он слабо приспособлен.

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

На что надо следует внимание при выборе BPM/Workflow системы:

1. Поддержка «человеческих» (human-to-human-related) задач, в противовес задач взаимодействия автоматизированных систем. Некоторые стандартные требования: поддержка организационной структуры, ролевых групп, переназначения заданий, обработка исключительных ситуаций и ad-hoc изменений схемы процесса конечным пользователем.
2. Простота использования и администрирования. Ключевой фактор успеха проекта BPM — запуск бизнес-процесса в эксплуатацию минуя продолжительный этап разработки. Обязательное требование — графические средства разработки схемы бизнес-процесса.
3. Поддерживаемые архитектуры, стандарты и платформы. Способность «играть на одном поле» с другими системами — также критичный для успеха проекта фактор.
4. Производительность и масштабируемость. Способность обслуживать многочисленные, сложные, продолжительные и распределенные процессы.
5. Управляемость. Как можно меньшее участие ИТ-персонала в эксплуатации и администрировании, выполнение административных функциям конечными пользователями через веб-интерфейс, включая управление пользователями и группами, изменение бизнес-правил, отчетность.
6. Мониторинг (BAM — Business Activity Monitoring). Включает такие функции, как извещение о бизнес-событиях, информирование в реальном времени об интегральных показателях выполнения бизнес-процессов.
7. Системы исполнения бизнес-правил (BRE — Business Rule Engine) и симуляторы бизнес-процессов. Эти средства обеспечивают «быстроту реакции» — способность BPM-системы в кратчайшие сроки перестраиваться под изменяющиеся требования.
8. Среда разработки. Помимо разработки схемы бизнес-процесса, назначения ролей и ведения бизнес-правил, система должна быть пригодна на роль центра в архитектуре корпоративных приложений. Обязательное требование — поддержка сервис-ориентированной архитектуры (SOA — Service Oriented Architecture) и разработки (SODA — Service Oriented Development of Applications).
9. Наличие готовых шаблонов бизнес-процессов для вертикальных и горизонтальных применений. Готовые шаблоны бизнес-процессов для определенных отраслей (например, финансов, здравоохранения или машиностроения) и/или определенных управленческих методологий, используемые в качестве начального приближения, способны значительно ускорить разработку собственного BPM-решения.
10. Цены и ценообразование. На что следует обращать внимание: умеренная цена начального пакета, наличие обучения и других сопутствующих услуг, цена годовой техподдержки в обычных для отрасли пределах.

    — АБ

>> Комментарии (всего 0)

«A BPM Taxonomy: Creating Clarity in a Confusing Market». Jim Sinur, Toby Bell

«A BPM Taxonomy: Creating Clarity in a Confusing Market». Jim Sinur, Toby Bell, Gartner Group, 2003 г.

Классификация BPM-систем по версии Gartner.

В 2003 г. Гартнер (www.gartner.com) решил навести порядок в BPM/Workflow терминологии и предложил классификацию BPM-систем. По мнению аналитиков Гартнер, термин Workflow исторически означает последовательность задач, в совокупности образующих процесс; причем под задачами обычно понимается нечто выполяемое человеком. BPM — это расширение Workflow, в котором автоматизируется не только поток работ, выполняемых людьми, но и задачи, выполняемые автоматизированными системами. Но это в теории, на практике существующие BPM-системы тяготеют либо к автоматизации «человеческой» деятельности, либо к интеграции автоматизированных систем.

Всего же Гартнер аналитики выделяет пять классов BPM-систем:

1. Канцелярские системы, отслеживающие выполнения поручений (Administrative and Task Support), которые могут рассматриваться как легковесные средства автоматизации бизнес-процессов.
2. Средства поддержания коллективной работы (Collaborative BPM) с основным упором на маршрутизации и согласовании документов — к этой категории относится, например, IBM/Lotus Notes Domino.
3. Прикладные BPM-компоненты (Application-Specific or Preconfigured BPM): ERP и CRM-системы зачастую содержат встроенный BPM Engine и готовые шаблоны бизнес-процессов
4. Системы, нацеленные на интеграцию автоматизированных систем (Integration-Focused BPM) — к ним относятся, в частности, BPEL-совместимые BPM-системы. Движение в направлении поддержки работ, выполняемых человеком, идет, но достаточно медленно.
5. Не привязанные к приложениям «чистые» BPM-системы (Pure-Play BPM), решающие задачи от автоматизации единичного выполняемого вручную процесса (например, прием и отслеживание заказа) до реорганизацию бизнес-направлений или предприятия в целом на принципах процессного управления. Как правило, такие системы логически располагаются поверх автоматизированных систем и серверов и координируют процессы верхнего уровня.

Отчет заканчивается предсказанием универсальные средства для решения всех относящихся к области BPM задач не появятся по крайней мере до 2005 г. и, следовательно, заказчикам следует рассматривать продукты из разных категорий, которые дополняли бы друг друга.

Как мы видим сегодня, этот прогноз вполне оправдался. Для систем, нацеленных на интеграцию, сегодня стандартом стал язык BPEL, и эти системы мало пригодны для автоматизации процессов, включающих выполняемые человеком работы.

    — АБ

>> Комментарии (всего 0)

«Who Has the Next Big Idea?». Daniel H. Pink

«Who Has the Next Big Idea?». Daniel H. Pink

Критические стрелы в адрес Майкла Хаммера.

Статья начинается с напоминания о том, кто такой Майкл Хаммер — человек, который (в соавторстве с Джеймсом Чемпи) в свое время ввел в обращение термин «реинжиниринг». С 10-летней дистанции видно, что не все из тех, кто вдохновился идеями Хамера, преуспели, а многие вообще разглагольствовали о реинжиниринге, плохо понимая что же это, собственно, такое.

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

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

После этого, довольно критического вступления, автор разбирает книгу Хаммера The Agenda: What Every Business Must Do to Dominate the Decade, общая тональность — опасливо-уважительная: «Книга — настоящий кладезь идей. Среди них есть как многообещающие, так и те, которые чреваты непредвиденными последствиями.»

Русский перевод: Еще одна притча о реинжиниринге или новое учение доктора Хаммера.

— WJ

>> Комментарии (всего 0)

«Reengineering Work: Don't Automate, Obliterate!». Michael Hammer

«Reengineering Work: Don't Automate, Obliterate!». Michael Hammer, 1990 г.

Классическая статья по реинжинирингу бизнес-процессов от одного из авторов этой концепции.

Содержание статьи в основном сводится к разбору нескольких успешных проектов реорганизации бизнес-процессов (в частности Ford и Hewlett-Packard) и попытке выделить из них общие правила. Основной тезис, вокруг которого было сломано столько копий впоследствии: «Реинжиниринг нельзя спланировать детально и выполнить мелкими и осторожными шагами. Это предложение вида "все или ничего" с неопределенным результатом.»

Статья, опубликованная Майклом Хаммером в 1990 г. в академическом издании «Harvard Business Review», вместе с последовавашими за ней книгами, в свое время вызвали большой резонанс. Это тот случай, когда идея носилась в воздухе, и стоило только произнести слово, как оно было подхвачено многими. Результатом стало повальное увлечение реинжинирингом в 1990-х. На практике реинжиниринг (по крайней мере в Америке) часто становился синонимом сокращения штатов («downsizing»), за что Хаммеру впоследствии приходилось даже оправдываться.

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

Русский перевод: Реинжиниринг: не автоматизируйте — уничтожайте.

— WJ

>> Комментарии (всего 0)