Литература:

• Статьи
• Обзоры
• Форумы
• Стандарты
• Книги
• Авторы

Автор: Роб Дэвис (Rob Davis) – главный консультант ARIS BPM в Software AG, международно признанный эксперт в области управления бизнес-процессами (BPM) и практическом использовании платформы ARIS Design. Специалист в области моделирования, дизайна, архитектуры, структуры, управления и интеграции процессов и ИТ-дизайна, автор книг по практическому использованию платформы ARIS Design для BPM.
Оригинал статьи: www.bptrends.com/publicationfiles/01-08-2013-COL-ProcinPractice%20-%20Process%20for%20the%20People%20or%20Just%20for%20Experts-Davis.pdf

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

Учитывая подобный взгляд на процесс, сложно сделать так, чтобы разработка и анализ процесса стали необходимыми дисциплинами, предпринимаемыми опытными и квалифицированными людьми, использующими профессиональные инструменты. Вместо этого организации предпочитают поручать работу по «рисованию» процессов неквалифицированному персоналу, используя Microsoft Visio или подобные ему рисовалки. Общая точка зрения, что процессы – это для бизнеса и для людей, поэтому они должны делаться бизнесом и людьми. Это имеет смысл, но значит ли это, что процессы должны проектироваться кем попало или это все же требует специальных навыков?

Профессионализация ИТ

Чтобы пролить свет на этот вопрос, интересно провести сравнение с развитием отрасли ИТ. В 1980-х корпоративная компьютеризация осуществлялась при помощи мейнфремов, которые заботливо контролировались и охранялись департаментами обработки данных. Доступ к этим компьютерам был сильно ограничен, и время получения новой функциональности в софтверном облаке составляло месяцы или даже годы. В начале 90-х все изменилось.  Настольные компьютеры стали более надежными и мощными, и на сцену вышли приложения типа Microsoft Access, Microsoft Excel или Microsoft Visual Basic. Внезапно люди бизнеса смогли купить себе свои собственные компьютеры, и создавать свои собственные бизнес-приложения, независимо от департаментов обработки данных. Конечно, эти новые приложения все еще нуждались в информации из мейнфреймов, что породило целое поколение так называемых «screen scraping» приложений, извлекающих данные и вводящих данные, имитируя ввод с клавиатуры или чтение с экрана.

Эта эра свободных компьютеров 90-х продемонстрировала быстрый прогресс в использовании компьютеров для поддержки всех аспектов бизнеса, но закончилось это плачевно. Компьютерная инфраструктура, заботливо контролируемая департаментами обработки данных, была теперь распределена между сотнями и тысячами маленьких приложений, разбросанными по всему бизнесу. Эти приложения часто создавались программистами-любителями; на самом деле любым, кто интересовался новыми технологиями. Что еще хуже, корпоративные данные были теперь окончательно фрагментированы, и было невозможно получить интегрированное представление данных.  Управлять изменениями стало практически невозможным, и было сложно оценить стоимость, не говоря уже о том, чтобы её контролировать. Даже сегодня многие организации до сих пор страдают от фрагментации, созданной в 90-х.

Выходя из этой ситуации, большинство организаций создали централизованные ИТ департаменты под руководством CIO. Они начали использовать подходы Enterprise Architecture, чтобы создать связанную архитектуру и «дорожную карту» ИТ преобразований. Они ввели управления требованиями, чтобы контролировать стоимость разработки, и они начали работу по созданию большой вычислительной системы, чтобы избавиться от тысяч маленьких приложений. Важнее всего то, что они ввели тренинги и программы сертификации, чтобы быть уверенными, что они используют подготовленных специалистов для разработки программного обеспечения. Они купили профессиональные инструменты для разработки и начали инвестировать в повторное использование и такие технологии, как SOA. Как результат, ИТ и департаменты разработки сегодня гораздо более эффективны с точки зрения затрат, лучше контролируемы и «профессиональны».

Разработка процессов сегодня

Итак, что общего это имеет с процессом? Ну, во многих случаях разработка процесса сегодня в том же состоянии, как это было в конце 90-х. Есть большое количество профессиональных инструментов для разработки процессов, но все еще преобладает точка зрения, что они сложны, трудны в использовании и не могут дать достаточной гибкости для бизнеса. Вместо этого процессы часто пытаются «разрабатывать», используя инструменты типа PowerPoint и Visio. Как результат, корпоративные знания о процессе распределены между сотнями, если не тысячами, рисовальщиков. Нет центрального репозитория, нет возможности анализа нарисованного. Это означает, что лишь немногие организации имеют современное сквозное представление своих ключевых процессов. Кроме того, это означает, что большинство организаций не могут:

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

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

Почему процессы должны быть профессиональными

Прежде всего, давайте подумаем, что должен учитывать создатель процессов. Создание процесса описывает:

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

Но прежде, чем начать моделировать эти элементы, должны быть заданы некоторые даже более важные основные вопросы:

• Цели моделирования процессов – зачем вообще это затевать?
• Кто будет «заказчиком» создания процесса – кто будет его использовать?
• Какая информация и как много деталей необходимы – что они будут с этим делать?

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

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

Социальный BPM

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

Для поддержки этого подхода, среда совместной разработки (например, ARIS Connect, рис.2) , как правило, должна обеспечивать следующие возможности:

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

Процессы, сделанные экспертами, но для людей

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

Комментарии