Аннотация: Принципы создания информационной системы. Реинжиниринг бизнес-процессов. Отображение и моделирование процессов. Обеспечение процесса анализа и проектирования ИС возможностями CASE-технологий. Внедрение информационных систем.

4. Разработка и внедрение информационной системы

4.1. Принципы создания информационной системы

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

Развитие систем и средств вычислительной техники, расширенное их внедрение во все сферы науки, техники, сферы обслуживания и быта привели к необходимости объединения конкретных вычислительных устройств и реализованных на их основе информационных систем в единые информационно-вычислительные системы (ИВС) и среды. При этом разработчики ИВС столкнулись с рядом проблем.

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

Принцип "открытости" информационной системы

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

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

Это определение, сформулированное специалистами института IEEE (Institute of Electrical and Electronic Engineers), унифицирует содержание среды, которую предоставляет открытая система для широкого использования. В настоящее время общепризнанным координационным центром по разработке и согласованию стандартов открытых систем является OASIS (Organization for the Advancement of Structured Information Standards).

Общие свойства открытых информационных систем можно сформулировать следующим образом:

• расширяемость/масштабируемость: обеспечение возможности добавления новых функций ИС или изменения некоторых уже имеющихся при неизменных остальных функциональных частях ИС;
• мобильность/переносимость: обеспечение возможности переноса программ, данных при модернизации или замене аппаратных платформ ИС и возможности работы с ними специалистов, пользующихся ИТ, без их переподготовки при изменениях ИС;
• взаимодействие: способность к взаимодействию с другими ИС (технические средства, на которых реализована информационная система, объединяются сетью или сетями различного уровня: от локальной до глобальной);
• стандартизуемость: ИС проектируются и разрабатываются на основе согласованных международных стандартов и предложений, реализация открытости осуществляется на базе функциональных стандартов (профилей) в области информационных технологий;
• дружественность к пользователю: развитые унифицированные интерфейсы в процессах взаимодействия в системе "человек-машина", позволяющие работать пользователю, не имеющему специальной "компьютерной" подготовки.

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

Структура среды информационной системы

Обобщенная структура любой ИС может быть представлена двумя взаимодействующими частями:

• функциональной части, включающей прикладные программы, которые реализуют функции прикладной области;
• среды или системной части, обеспечивающей исполнение прикладных программ.

С этим разделением тесно связаны две группы вопросов стандартизации:

• стандарты интерфейсов взаимодействия прикладных программ со средой ИС, прикладной программный интерфейс (Application Program Interface - API);
• стандарты интерфейсов взаимодействия самой ИС с внешней для нее средой (External Environment Interface - EEI).

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

Спецификации внешних интерфейсов среды ИС и, как будет видно далее, спецификации интерфейсов взаимодействия между компонентами самой среды, - это точные описания всех необходимых функций, служб и форматов определенного интерфейса. Совокупность таких описаний составляет эталонную модель открытых систем (Reference Open System Model).

Эта модель используется более 20 лет и определяется системной сетевой архитектурой (SNA), предложенной IBM в 1974 году. Она основана на разбиении вычислительной среды на семь уровней, взаимодействие между которыми описывается соответствующими стандартами, и обеспечивает связь уровней вне зависимости от построения уровня в каждой конкретной реализации (рис. 4.1). Основным достоинством этой модели является детальное описание связей в среде с точки зрения технических устройств и коммуникационных взаимодействий. Вместе с тем она не принимает в расчет взаимосвязь с учетом мобильности прикладного программного обеспечения.

Рис. 4.1.

Эталонная модель среды открытых систем (OSE/RM) определяет разделение любой информационной системы на приложения (прикладные программы и программные комплексы) и среду, в которой эти приложения функционируют. Между приложениями и средой определяются стандартизованные интерфейсы (API), которые являются необходимой частью профилей любой открытой системы. Кроме того, в профилях ИС могут быть определены унифицированные интерфейсы взаимодействия функциональных частей друг с другом и интерфейсы взаимодействия между компонентами среды ИС.

Более подробно о применении технологии и моделей открытых систем будет рассказано в "лекции 18" .

Модель создания информационной системы

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

Компания является сложной онтологической (понятийной) структурой, состоящий из определенной совокупности сущностей и взаимосвязей (рис. 4.2).

Рис. 4.2.

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

При создании модели формируется "язык общения" руководителей предприятия, консультантов, разработчиков и будущих пользователей, позволяющий выработать единое представление о том, ЧТО и КАК должна делать система управления предприятием (корпоративная система управления). Такая бизнес-модель - осязаемый результат, с помощью которого можно максимально конкретизировать цели внедрения ИС и определиться со следующими параметрами проекта:

• основные цели бизнеса, которые можно достичь посредством автоматизации процессов;
• перечень участков и последовательность внедрения модулей ИС;
• фактическая потребность в объемах закупаемого программного и аппаратного обеспечения;
• реальные оценки сроков развертывания и запуска ИСУ;
• ключевых пользователей ИС и уточненный список членов команды внедрения;
• степень соответствия выбранного вами прикладного программного обеспечения специфике бизнеса вашей компании.

В основе модели всегда лежат бизнес-цели предприятия, полностью определяющие состав всех базовых компонентов модели:

• бизнес-функции, описывающие ЧТО делает бизнес;
• основные, вспомогательные и управленческие процессы, описывающие КАК предприятие выполняет свои бизнес-функции;
• организационно-функциональную структуру, определяющую ГДЕ исполняются бизнес-функции и бизнес-процессы;
• фазы, определяющие КОГДА (в какой последовательности) должны быть внедрены те или иные бизнес-функции;
• роли, определяющие КТО исполняет бизнес-функции и КТО является "хозяином" бизнес-процессов;
• правила, определяющие связь и взаимодействие между всеми ЧТО, КАК, ГДЕ, КОГДА и КТО.

После построения бизнес-модели (или параллельно с этим) можно приступать к формированию модели проектирования, реализации и внедрения самой ИС (рис. 4.3).

Рис. 4.3.

Опыт создания и использования "заказных" ИС позволяет условно выделить следующие основные этапы их жизненного цикла:

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

Определение требований к системе и анализ является первым этапом создания ИС, на котором требования заказчика уточняются, согласуются, формализуются и документируются. Фактически на этом этапе дается ответ на вопрос: "Для чего предназначена и что должна делать информационная система?". Именно здесь лежит ключ к успеху всего проекта.

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

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

Разработка перечисленных выше спецификаций при создании ИС, предназначенной для автоматизации управленческих процессов, в общем случае проходит четыре стадии.

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

По результатам обследования аналитик на первой стадии строит обобщенную логическую модель исходной предметной области, отображающую ее функциональную структуру, особенности основной деятельности и информационное пространство, в котором эта деятельность осуществляется (рис. 4.4). На этом материале аналитик строит функциональную модель "Как есть" (As Is).

Вторая стадия работы, к которой обязательно привлекаются заинтересованные представители заказчика, а при необходимости и независимые эксперты, состоит в анализе модели "Как есть", выявлении ее недостатков и узких мест, определение путей совершенствования системы управления на основе выделенных критериев качества.

Третья стадия анализа, содержащая элементы проектирования, - создание усовершенствованной обобщенной логической модели, отображающей реорганизованную предметную область или ее часть, которая подлежит автоматизации - модель "Как должно быть" (As To Be).

Заканчивается процесс (четвертая стадия) разработкой "Карты автоматизации", представляющей собой модель реорганизованной предметной области, на которой обязательно обозначены "границы автоматизации".

В большинстве случаев модель "Как есть" улучшается системным аналитиком за счет устранения очевидных несоответствий и узких мест, а полученный таким образом вариант модели рассматривается в дальнейшем в качестве предварительной модели "Как должно быть", которая впоследствии дополняется в соответствии со стратегией развития предприятия (рис.4.5).

Рис. 4.5.

На стадии анализа требований к проектируемой системе и вводятся:

• классы пользователей и соответствующие диаграммы бизнес-транзакций;
• модели (диаграммы) процессов прикладной деятельности и соответствующие перечни функциональных задач ИС;
• классы объектов предметной области и соответствующие диаграммы "сущность-связь", отражающие информационную модель этой предметной области;
• топология расположения подразделений и пользователей, обслуживаемых данной ИС;
• параметры защиты данных, информации и самой системы.

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

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

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

Производительность и надёжность являются главными факторами, определяющими эффективность системы. Хорошее проектное решение служит основой высокопроизводительной системы.

Проектирование информационных систем охватывает три основные области:

• проектирование структур данных, которые будут реализованы в базе данных;
• проектирование программ, экранных форм, отчетов, которые будут обеспечивать выполнение запросов к данным;
• проектирование конкретной среды или технологии, а именно: топологии сети, конфигурации аппаратных средств, используемой архитектуры, параллельной обработки, распределенной обработки данных и т. п.

На основе результатов системного анализа на стадии предварительного проекта разрабатываются:

• проект программно-аппаратной реализации, проект пользовательских интерфейсов и технологии работы пользователей в системе;
• архитектура распределенной системы и спецификации телекоммуникационной сети;
• модели (диаграммы) потоков данных;
• функциональные блок-схемы прикладного и системного программного обеспечения (последние - в соответствии с принятыми моделями среды ИС и профилями стандартов).

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

На стадии детального проектирования разрабатываются:

• комплексы функциональных программ ИС и проект реализации среды ИС;
• структуры данных, средства ведения баз данных;
• сетевые адреса, протоколы телекоммуникаций и другие компоненты среды обмена информацией, включаемые в состав проектируемой ИС;
• правила разграничения доступа пользователей и средства их реализации.

Стадия реализации ИС предусматривает разработку и тестирование компонентов и комплексное тестирование системы.

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

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

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

4.2. Реинжиниринг бизнес-процессов

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

Следование требованиям стандартов при разработке ИС автоматически приводит к тому, чтобы само предприятие - внешняя среда для ИС - также отвечало необходимым требованиям: определение и стандартизация классов пользователей и объектов, топология потоков данных и работ, архитектура наследуемых и разрабатываемых подсистем, состояние бизнес-процессов и т. д.

Бизнес-процесс представляет собой систему последовательных, целенаправленных и регламентированных видов деятельности, в которой посредством управляющего воздействия и с помощью определенных ресурсов за определенное время входы процесса преобразуются в выходы - в результаты, представляющие ценность для потребителя и приносящие прибыль изготовителю.

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

Рис. 4.6.

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

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

Реинжиниринг бизнес-процессов - это совокупность методов и действий, служащих для перепроектирования процессов в соответствии с изменившимися условиями внешней и внутренней среды и/или целями бизнеса.

Существует несколько базовых правил, которых следует придерживаться в процессе проведения реинжиниринга:

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

Реинжиниринг деловых процессов и функций начинается с пересмотра целей предприятия, его структуры, анализа потребностей внутренних пользователей и рынка, производимых продуктов и услуг (рис. 4.7).

Рис. 4.7.

Перепланирование целей и задач предполагает пересмотр политики предприятия и ответа на следующие вопросы:

• Какие новые вызовы предъявляют нам изменившиеся условия бизнеса?
• Что представляет предприятие сейчас, и что мы хотим от него в будущем?
• Каких именно потребителей мы обслуживаем, насколько мы удовлетворяем их требования и ожидания, и что нужно сделать для привлечения новых?
• Какие именно показатели определяют эффективность деятельности предприятия, производительность труда и качество продукта, является ли это определение полным и адекватным?
• Какие именно информационные технологии и средства помогут нам в этом?

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

Рис. 4.8.

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

Результатом такого описания является:

• уточненная карта сети процессов;
• матрица взаимосвязей процессов и подразделений, вовлеченных в эти процессы;
• информация о том, какие системы автоматизации существуют, при выполнении каких операций используются, где и какие данные используются, какие системы автоматизации и информатизации необходимо разработать;
• функциональные схемы потоков данных (Data Flow), работ (Work Flow), финансовых потоков (Cash Flow), потоков управленческих воздействий (Control Flow) и документооборота (Doc Flow).

Функциональная модель поможет составить точные спецификации всех операций, процедур и взаимосвязей между ними. Такая модель, если она построена правильно, обеспечивает исчерпывающее описание о функционирующем процессе и обо всех имеющихся в нем потоках информации. Эта модель описывает состояние "Как есть" (As Is). По результатам анализа возможных путей улучшения от реальной модели нужно перейти к модели, характеризующей улучшения - модель "Как будет" (As To Be), вариант - "Как должно быть" (рис. 4.9).

Рис. 4.9.

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

Реинжиниринг бизнес-процессов является сложным и многоаспектным проектом, требующим тщательного планирования и проработки деталей. В таблице 4.1 показаны основные этапы реинжиниринга.

Таблица 4.1. Основные этапы реинжиниринга

Этап	Мероприятия
Планирование и начало работ	Выявление главных причин проведения реформы на предприятии и оценка последствий отказа от такой реформы
	Выявление важнейших процессов, требующих реинжиниринга
	Выявление единомышленников среди руководства и создание рабочей группы из представителей администрации
	Обеспечение поддержки проекта руководством
	Подготовка плана проекта: определение объема, обозначение измеримых целей, выбор методологии, составление подробного графика
	Согласование целей и объемов проекта с руководством
	Формирование группы реинжиниринга
	Выбор консультантов или внешних экспертов
	Проведение вводного совещания
	Доведение целей проекта до руководителей низшего звена; начальное информирование всей организации
	Обучение группы реинжиниринга
	Подготовка плана и начало работ
Исследования	Аналитическое исследование опыта компаний с подобными процессами
	Опрос клиентов и контрольных групп для выявления существующих и будущих требований
	Опрос служащих и руководителей для выявления вопросов; мозговой штурм
	Поиск в литературе и прессе данных о тенденциях в отрасли и о чужом опыте
	Оформление подробных документов на исходные процессы и сбор рабочих данных; выявление недоработок
	Обзор изменений и вариантов технологий
	Опрос владельцев и представителей руководства
	Посещение кружков и семинаров
	Сбор данных от внешних экспертов и консультантов
Проектирование	Мозговой штурм и выработка новаторских идей; упражнения по творческому мышлению, чтобы "снять шоры"
	Проработка сценариев "а что, если?" и применение "шаблонов успеха" других компаний
	Создание при помощи специалистов 3-5 моделей; разработка комплексных моделей, в которых собрано лучшее от каждой из предыдущих
	Создание картины идеального процесса
	Определение моделей нового процесса и их графическое представление
	Разработка организационной модели в сочетании с новым процессом
	Определение технологических требований; выбор платформы для новых процессов
	Выделение краткосрочных и долгосрочных мер
Утверждение	Анализ затрат и преимуществ; расчет прибыли на капитал
	Оценка влияния на клиентов и служащих; оценка влияния на конкурентоспособность
	Подготовка официального документа для высшего руководства
	Проведение обзорных совещаний для ознакомления и утверждения деталей проекта оргкомитетом и высшим руководством
Внедрение	Завершение подробной разработки процессов и организационных моделей; определение новых рабочих обязанностей
	Разработка систем поддержки
	Реализация предварительных вариантов и первичные испытания
	Ознакомление работников с новым вариантом; разработка и осуществление плана реформы
	Разработка поэтапного плана; внедрение как таковое
	Разработка плана обучения; обучение работников новым процессам и системам
Последующие мероприятия	Разработка мероприятий по периодической оценке; определение итогов нового процесса; внедрение программы непрерывного совершенствования нового процесса
	Предоставление окончательного отчета оргкомитету и администрации

4.3. Отображение и моделирование процессов

На сегодняшний день получили распространение три основные методологии функционального моделирования (и сопутствующий им инструментарий): IDEF (Integrated DEFinition), UML (Unified Modeling Language) и ARIS (Architecture of Integrated Information Systems). Для каждой из них существуют определенные программные продукты, которые помимо разработки позволяют проводить преобразования и операции для последующей работы с полученными моделями. Наибольшее распространение сегодня получили методологии IDEF и программный продукт BPWin, содержащий методологии IDEF0, IDEF3, DFD (Data Flow Diagrams) и ERWin (IDEF1x) от компании Computer Associates.

История методологии IDEF начинается с 70-х годов ХХ века с методологии SADT (Structured Analysis and Design Technique), разработанной Дугласом Россом (Softtech INC). Изначально SADT применялось Министерством Обороны США для практического моделирования процессов в рамках программы ICAM (Integrated Computer Aided Manufacturing). Принципиальным требованием при разработке рассматриваемого семейства методологий была возможность эффективного обмена информацией между всеми специалистами - участниками программы ICAM (Icam DEFinition). В последующем эта методология была трансформирована в стандарт IDEF0 (Function Modeling, FIPS № 183). Семейство IDEF включает уже упомянутые IDEF3 (Process Description Capture) и IDEF1x (Data Modeling, FIPS № 184).

После опубликования стандартов они были успешно применены в самых различных областях бизнеса, показав себя эффективным средством анализа, конструирования и отображения бизнес-процессов (к слову сказать, он активно применяется и в отечественных госструктурах, например в Государственной налоговой инспекции). Более того, собственно с широким применением IDEF (и предшествующей методологии SADT) и связано возникновение основных идей популярного ныне понятия "реинжиниринг бизнес-процессов" (Business Process Reengineering - BPR).

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

Работа с использованием метода IDEF начинается с постановки цели моделирования. Мировой опыт свидетельствует, что ошибки при постановке цели приводят в среднем к 50 % неудач в процессе моделирования. Формулирование цели изначально направляет работу в заданном направлении, а значит, ограничивает круг вопросов для анализа. Практическая работа начинается с определения контекста (Context, Context Diagram), то есть верхнего уровня системы, в нашем случае - предприятия. После формулировки цели необходимо очертить область моделирования (Scope), которая в последующем будет определять общие направления движения и глубину детализации (Decomposition). Собственно, сама методология IDEF определяет стандартизированные объекты для работы и отображения. Например, к таковым относятся функция (Activity), интерфейсная дуга (Arrow), заметка (Note) а также способ их расположения и трактования (Semantics).

В последнее время на российском рынке появился программный продукт Business Studio, который специально создан для работы с методами IDEF и обладает интуитивным и дружественным интерфейсом (User-friendly Interface).

Рис. 4.10.

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

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

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

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

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

Пример функциональной модели процесса отгрузки и доставки продукции показан на рис. 4.11 .

Степень формализации описания бизнес-процессов может быть различной в зависимости от решаемых при этом задач. Для описания информационных процессов разработан специализированный язык BPEL (Business Process Execution Language). BPEL создан на основе XML для формального описания бизнес-процессов и протоколов их взаимодействия между собой. BPEL расширяет модель взаимодействия Web-служб и включает в эту модель поддержку транзакций.

В настоящее время активно развивается методология BPMS (Business Process Management System) - класс программного обеспечения для управления бизнес-процессами и административными регламентами. (Употребляются также термины BPM-система и просто BPM). Использование BPMS позволяет организовать эффективное взаимодействие между управленцами и ИТ-специалистами, лучше использовать существующие подсистемы и ускорить разработку новых.

Основные функции BPMS - моделирование, исполнение и мониторинг бизнес-процессов. Основываясь на данных мониторинга, предприятия выявляют узкие места и усовершенствуют свои бизнес-процессы. Цикл управления замыкается, когда при помощи BPMS измененные бизнес-процессы оперативно внедряются в эксплуатацию.

Современные методы разработки и развития программного обеспечения ИС в полной мере стараются ориентироваться на возможности автоматизированного оперативного внесения изменений. Наиболее сложным оказался процесс стандартизации языка BPEL для унификации использования одних и тех же конструкций программным обеспечением разных производителей. Фирмы IBM и Microsoft определили два довольно-таки схожих языка: WSFL (Web Services Flow Language) и Xlang, соответственно.

Рост популярности BPML и открытое движение BPMS к пользователям привело корпорации Intalio Inc., IBM и Microsoft к решению объединить эти языки в новый язык BPEL4WS. В апреле 2003 года корпорации BEA Systems, IBM, Microsoft, SAP и Siebel Systems передали BPEL4WS версии 1.1 в OASIS для стандартизирования в Web Services BPEL Technical Committee. Хотя BPEL4WS появился в версиях 1.0 и 1.1, технический комитет WS-BPEL OASIS проголосовал 14 сентября 2004 за то, чтобы назвать спецификацию WS-BPEL 2.0. Это изменение было сделано, чтобы согласовать BPEL с другими стандартами Web-сервисов, которые на основании "Соглашения об именовании" начинаются сочетаниями букв "WS-".

Корпорации Active Endpoints, Adobe, BEA, IBM, Oracle и SAP опубликовали согласованные спецификации BPEL4 People и WS-HumanTask, в которых описывалось, как может быть реализовано в системе и нотациях BPEL взаимодействие процессов с людьми. Предполагается добавление в BPEL семантики в форме WS-HumanTask и других разнообразных дополнений.

4.4. Обеспечение процесса анализа и проектирования ИС возможностями CASE-технологий

Термин CASE (Computer Aided Software/System Engineering) используется в настоящее время в весьма широком смысле. Первоначальное значение термина CASE, ограниченное вопросами автоматизации разработки только лишь программного обеспечения (ПО), в настоящее время приобрело новый смысл, охватывающий процесс разработки сложных ИС в целом.

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

Появлению CASE-технологии и CASE-средств предшествовали исследования в области методологии программирования. Программирование обрело черты системного подхода с разработкой и внедрением языков высокого уровня, методов структурного и модульного программирования, средств визуального моделирования и проектирования на базе языка UML (Unified Modeling Language), средств их поддержки, формальных и неформальных языков описаний системных требований и спецификаций и т. д. Кроме того, появлению CASE-технологии способствовали и такие факторы, как:

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

CASE-технология представляет собой методологию проектирования ИС, а также набор инструментальных средств, позволяющих в наглядной форме моделировать предметную область, анализировать эту модель на всех этапах разработки и сопровождения ИС и разрабатывать приложения в соответствии с информационными потребностями пользователей. Большинство существующих CASE-средств основано на методологиях структурного (в основном) или объектно-ориентированного анализа и проектирования, использующих спецификации в виде диаграмм или текстов для описания внешних требований, связей между моделями системы, динамики поведения системы и архитектуры программных средств [Вендров А. М. ,www.citforum. ru/database/case/index.shtml ].

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

Большинство CASE-средств основано на парадигме "методология/метод/нотация/структура/средство".

Методология задает руководящие указания для оценки и выбора проекта разработки ПО, этапы и последовательность работ, правила применения тех или иных методов.

Метод - систематическая процедура или технология генерации описаний компонент ПО (например, описание потоков и структур данных).

Нотации предназначены для описания системы в целом, ее элементов: графы, диаграммы, таблица, блок схемы, алгоритмы, формальные языки и языки программирования.

Структуры являются средством для реализации структурного анализа и построения структуры конкретной системы.

Средства - технологические и программные инструменты для поддержки и усиления методов.

CASE-технологии обладают следующими основными достоинствами, которые позволяют широко использовать их при разработке информационных систем:

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

Следует отметить, что, несмотря на все потенциальные возможности CASE-средств, существует достаточно много примеров их неудачного внедрения, в результате которых CASE-средства становятся "полочным" ПО (Shelfware).

В связи с этим необходимо учитывать следующее:

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

Можно также перечислить следующие факторы, усложняющие определение возможного эффекта от использования CASE-средств:

• широкое разнообразие качества и возможностей CASE-средств;
• относительно небольшое время использования CASE-средств в различных организациях и недостаток опыта их применения;
• широкое разнообразие в практике внедрения различных организаций;
• отсутствие детальных метрик и данных для уже выполненных и текущих проектов;
• широкий диапазон предметных областей проектов;
• различная степень интеграции CASE-средств в различных проектах.

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

Ниже перечислены основные виды и последовательность работ, рекомендуемые при построении логических моделей предметной области в рамках CASE-технологии анализа системы управления предприятием.

1. Проведение функционального и информационного обследования системы управления (административно-управленческой деятельности) предприятия (рис. 4.2):
   • определение организационно-штатной структуры предприятия;
   • определение функциональной структуры предприятия;
   • определение перечня целевых функций структурных элементов (подразделений и должностных лиц);
   • определение круга и очередности обследования структурных элементов системы управления согласно сформулированным целевым функциям;
   • обследование деятельности выделенных структурных элементов;
   • построение FD-диаграммы системы управления с указанием структурных элементов и функций, реализация которых будет моделироваться на DFD-уровне.
2. Разработка моделей деятельности структурных элементов и системы управления в целом:
   • выделение множества внешних объектов, оказывающих существенное влияние на деятельность структурного элемента;
   • спецификация входных и выходных информационных потоков;
   • выявление основных процессов, определяющих деятельность структурного элемента и обеспечивающих реализацию его целевых функций;
   • спецификация информационных потоков между основными процессами деятельности, уточнение связей между процессами и внешними объектами;
   • оценка объемов, интенсивности и других необходимых характеристик информационных потоков;
   • разработка иерархии диаграмм потоков данных, образующих функциональную модель деятельности структурного элемента;
   • объединение DFD-моделей структурных элементов в единую модель системы управления предприятием.
3. Разработка информационных моделей структурных элементов и модели информационного пространства системы управления:
   • определение сущностей модели и их атрибутов;
   • проведение атрибутного анализа и оптимизация сущностей;
   • идентификация отношений между сущностями и определение типов отношений;
   • анализ и оптимизация информационной модели;
   • объединение информационных моделей в единую модель информационного пространства.
4. Разработка предложений по автоматизации системы управления предприятия:
   • определение границ автоматизации - составление перечня автоматизируемых структурных элементов, разбиение процессов основной деятельности на автоматические, автоматизированные и ручные;
   • составление перечня подсистем и логических АРМов (автоматизированных рабочих мест), определение способов их взаимодействия;
   • разработка предложений по очередности проектирования и реализации подсистем и отдельных логических АРМов, входящих в состав ИС;
   • разработка требований к средствам базового технического обеспечения ИС;
   • разработка требований к средствам базового программного обеспечения ИС.

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

Развитие логической модели предметной области, ее последовательное превращение в модель целевой ИС, позволит интегрировать перспективные предложения руководства и ведущих сотрудников предприятия, экспертов и системных аналитиков, сформировать видение новой, реорганизованной и автоматизированной деятельности предприятия (рис. 4.12).

Рис. 4.12.

Построенная модель является законченным результатом по следующим причинам.

1. Она включает в себя модель существующей неавтоматизированной технологии, принятой на предприятии. Формальный анализ этой модели позволяет выявить узкие места в управлении предприятием и сформулировать рекомендации по его улучшению (независимо от того, предполагается ли дальнейшая разработка автоматизированной системы или нет).
2. Она независима и отделяема от конкретных разработчиков, не требует сопровождения и может быть безболезненно передана другим лицам. Более того, если по каким-либо причинам предприятие не готово к реализации проекта в данный момент времени, модель может быть "положена на полку" до тех пор, пока в ней не возникнет необходимость.
3. Она позволяет осуществлять эффективное обучение новых работников конкретным направлениям деятельности предприятия, так как соответствующие технологии содержатся в модели.
4. С ее помощью можно осуществлять предварительное моделирование перспективных направлений деятельности предприятия с целью выявления новых потоков данных, взаимодействующих процессов и структурных элементов.
5. Она обеспечивает распространение накопленного опыта на других предприятиях, дает возможность унифицировать административно-управленческую и финансовую деятельность этих предприятий.

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

Paradigm Plus - моделирование приложений и генерация объектного кода;

Rational Rose - моделирование бизнес-процессов и компонентов приложений

Rational Suite AnalystStudio - пакет для аналитиков данных;

Oracle Designer (входит в Oracle9i Developer Suite) - высоко функциональное средство проектирования программных систем и баз данных, реализующее технологию CASE и собственную методологию Oracle - CDM. Позволяет команде разработчиков полностью провести проект, начиная от анализа бизнес-процессов через моделирование к генерации кода и получению прототипа, а в дальнейшем и окончательного продукта. Сложное CASE-средство, имеет смысл использовать при ориентации на линейку продуктов Oracle.

Самым мощным из указанных программных пакетов является пакет Rational Rose (RR) компании IBM-Rational, с помощью которого можно спроектировать и сопровождать весь жизненный цикл разработки программного продукта (рис. 4.15 Рис. 4.16. Сопровождение ЖЦ программного продукта с RR

4.5. Внедрение информационных систем

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

Внедрение информационной системы, как правило, значительно облегчает управление деятельностью предприятия, оптимизирует внутренние и внешние потоки информации, ликвидирует узкие места в управлении. Однако после того как система успешно установлена, "обкатана" в работе и показала свою эффективность, у части сотрудников выявляется нежелание использовать ИС в работе. В результате проведённого реинжиниринга становится ясно, что некоторые сотрудники в большой степени дублирует работу других или вовсе не нужна. Кроме того, внедрение КИС сопровождается обязательным обучением, но, как показывает российский опыт, желающих переучиваться не так много. Ломка старых навыков и прививание новых - долгий и трудный процесс!

Надо четко понимать, что корпоративная ИС призвана упростить управление организацией, улучшить процессы, усилить контроль и обеспечить этим конкурентные выгоды. Только с такой точки зрения можно оценивать пользу от её внедрения.

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

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

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

К настоящему времени сложился стандартный набор приемов внедрения ИС. Основное правило: выполнять обязательные фазы последовательно и не пропускать ни одной из них.

Критически важными для внедрения являются следующие факторы:

• наличие четко сформулированных целей проекта и требований к ИС;
• наличие стратегии внедрения и использования ИС;
• проведение предпроектного обследования предприятия и построения моделей "Как есть" и "Как будет";
• планирование работ, ресурсов и контроль выполнения плана внедрения;
• участие высшего руководства во внедрении системы;
• проведение работ по внедрению ИС специалистами по интегрированию систем совместно со специалистами предприятия;
• регулярный мониторинг качества выполняемых работ;
• быстрое получение положительных результатов хотя бы в части внедренных модулей ИС или в процессе её опытной эксплуатации.

Перед началом разработки проекта внедрения необходимо:

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

Необходимо также определить функциональные сферы внедрения модулей информационной системы:

• организационное управление;
• организационно-административное обеспечение;
• управление бизнес-процессами;
• управленческий, планово-финансовый и бухгалтерский учет;
• управление персоналом;
• управление документацией;
• управление материально-техническим обеспечением;
• управление связями с клиентами и внешней средой.

Кроме того, что перечислено выше, надо задать технологические требования к внедрению ИС:

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

Основные фазы внедрения информационной системы

Фаза "Предварительные работы по подготовке проекта внедрения ИС". В ходе предпроектного обследования предприятия (рис. 4.1.4) собирается подробная информация о структурном построении организации, функциональных связях, системе управления, об основных бизнес-процессах, о потоках внутри предприятия (Control Flow, Doc Flow, Data Flow, Work Flow, Cash Flow), необходимая для построения соответствующих моделей и выбора объектов для автоматизации. Оцениваются сроки, ресурсы, виды и объемы работ, номенклатура и стоимость программно-аппаратных и телекоммуникационных средств, стоимость обучения персонала и т. д.

Фаза "Подготовка проекта". После завершения первой фазы осуществляется предварительное планирование и формирование процедур запуска проекта:

• формирование проектной и экспертной групп;
• распределение полномочий и ответственности;
• определение организационно-технических требований к процессу внедрения;
• уточнение спецификаций и ожиданий заказчика;
• обучение группы внедрения, состоящей из специалистов предприятия-заказчика.

Последний очень важный момент почему-то часто пропускается при составлении плана внедрения. А ведь от него в огромной степени зависит успех всего проекта! После начала финансирования проект считается запущенным к исполнению.

Фаза "Концептуальная проработка проекта". В течение этой фазы:

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

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

Фаза "Реализация проекта". Во время проведения основных работ по внедрению создается, устанавливается и конфигурируется системная среда, определяются процедуры системного администрирования, устанавливаются основные программно-аппаратные комплексы и приложения. В системе настраиваются организационно-штатные и организационно-функциональные структуры предприятия с использованием таких организационных единиц, как филиал, департамент, отдел, рабочая группа и т. д.

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

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

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

Для улучшения деятельности организации, в проекте необходимо доходить до уровня исполнителей и их действий (уровни детализации бизнес-процессов отражены на рисунке 1.1).

Рис. 1.1

Под операцией понимается минимальная для анализа часть деятельности каждого работника, которая выполняется им "автоматически", без проведения осознанного контроля.

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

Под процедурой понимается несколько последовательно исполняемых действий, которые осуществляются определенным исполнителем. Для процедуры необходим результат: документ, продукт или недокументированные сведения (устное сообщение, факс, электронное письмо и пр.).

Под бизнес-процессом базового уровня понимается последовательность взаимосвязанных процедур, которые выполняются разными исполнителями и приводят к законченному и значимому результату для организации. К примеру, заключенный договор, акт сдачи-приемки Ильин В.В. , Реинжиниринг бизнес-процессов с использованием ARIS, - М.: - Вильямс, 2009. - С. 120.

Под направлением деятельности понимается укрупненная доля деятельности организации, которая состоит из одной или нескольких групп бизнес-процессов базового уровня.

Управлением бизнес-процессами называется концепция процессного управления организацией, которая рассматривает бизнес-процессы как особые ресурсы организации, которые непрерывно адаптируются к постоянным изменениям и полагаются на следующие принципы:

Понятность и видимость бизнес-процессов в организации за счет моделирования бизнес-процессов с использованием формальных нотаций, использования программного обеспечения моделирования, симуляции, мониторинга и анализа бизнес-процессов;

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

Основной задачей управления бизнес-процессами является адекватное и быстрое перестроение взаимосвязанных процессов в зависимости от изменяющихся параметров внешней и внутренней среды, будь то поставки, расчеты с контрагентами или расширение рынка Практическое руководство по реинжинирингу бизнес-процессов, Майк Ротер, Джон Шук. - HE LEAN ENTERPRISE INSTITUTE, США, 2009. - С. 42.

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

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

Этап 1. Становление организации и освоение рынка.

Разработка четко сформулированной стратегии развития предприятия с указанием конкретных целей и мотивов развития;

Определение обязанностей и области ответственности как отдельных работников, так и отделов и рабочих групп;

Формирование алгоритма обучения и передачи навыков, знаний и умений новым сотрудникам на различных уровнях сложности выполняемой работы;

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

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

Этап 2. Рост организации.

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

Основные задачи при организации управления:

Организация делегирования полномочий руководителя;

Сохранение пропорций между ростом численности персонала и ростом выручки;

Поиск резервов снижения себестоимости из-за повышения конкуренции;

Координация действий функциональных подразделений на среднем уровне менеджмента.

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

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

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

На основании того, что около 80-85% операций бизнес-процессов являются типично повторяющимися, для них формируется подробный регламент действий.

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

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

1) в связи с тем, что структура управления опирается на структуру существующих на предприятии бизнес-процессов (для среднего предприятия не более 5-7), уменьшается количество уровней управления и подчинения;

2) возрастает эффективность управления за счет увеличения норм управляемости (в среднем в 2-3 раза), так как управляющее воздействие в данном случае направлено на координацию персонала и включается в процесс только при каких-либо нарушениях и отклонениях от обычной деятельности.

Для организации системы управления, которая базируется на процессном подходе, следует пройти ряд этапов (рисунок 1.2).

Рис.1.2

Этап 3. Развитие сетевой структуры, открытие новых представительств, филиалов.

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

Основные задачи при организации управления:

Разработка формализованной технологии открытия новых подразделений;

Организация контроля всех аспектов деятельности филиалов Рыбаков М. Как навести порядок в своем бизнесе. Как построить надежную систему из ненадежных элементов. Практикум. - М: "Издательство ИКАР", 2011. - С. 217.

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

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

Зачастую при этом в комплексе используются следующие инструменты:

Модель управления подразделениями, которая основана на процессном подходе и определяет меру самостоятельности филиалов;

Адаптивная и отвечающая требованиям внешней среды оптимальная структура;

Спроектированные в центре нормативные документы и инструкции, которые регулируют деятельность подразделений сети.

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

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

Я собрал наиболее распространенные мифы по вопросам управления бизнес процессами и разбил на 4 категории:
1. Мифы управления бизнес процессами
2. Мифы применения управления бизнес процессами
3. Мифы внедрения процессного подхода
4. Не дайте себя обмануть
Разрушайте мифы, которые могут привести к реальным последствиям.

Мифы управления бизнес процессами

Создание моделей и есть управления бизнес процессами

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

Управление бизнес процессами отвечает за следующие виды деятельности в компании:
– Анализ бизнес процессов
– Проектирование процессов
– Моделирование процессов
– Описание бизнес процессов
– Изменение и трансформация бизнес процессов
– Внедрение
– Мониторинг и контроль
– Увеличение эффективности
– А иногда, еще и за организацию

Составляющие управления бизнес процессами

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

Таким образом – модель, это инструмент, который облегчает управление бизнес процессами. И все.

Именно поэтому во многих компаниях, специалисты по управлению по бизнес процессам, занимаются только моделирование и описанием.

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

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

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

Суть управления бизнес процессами это написание регламентов и других документов

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

Ряд представителей фанатично убеждены, что большой объем документации является показателем реального управления бизнес процессами. Что, собственно, управление бизнес процессами должно только этим и заниматься – развивать бумажную промышленность. Причем именно бумажную, потому что электронная документация не приемлема. Она же не позволяет завалить рабочий стол и создать видимость работы)))

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

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

Документация помогает доносить и использовать информацию, но никак не является сутью управления бизнес процессами.

Цель управления бизнес процессами – сделать из людей роботов в жесткой системе

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

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

Развеять этот миф очень просто с помощью 4х аргументов:

1. Во всех бизнес процессах, кроме полностью автоматизированных, участвуют люди. Если не учитывать особенности, связанные с ними, то изменения, а управление бизнес процессами всегда связано с изменениями, не будут успешными. Все профессионалы по управлению бизнес процессами и изменениями, однозначно согласны с тем, что при планировании и реализации управления, необходимо учитывать:
   – Культуру организации
   – Негласные правила
   – Поведенческие особенности
   – Идеи и замыслы
   – Коммуникации и правила, принятые в компании
2. Управление бизнес процессами ориентируется на процессов, а не на их стандартизацию. Кто сказал, что увеличение эффективности возможно только с помощью стандартизации? Ах да, Генри Форд. Хороший был дядька. Сделал целую промышленную революцию. Но стандартизация изделий не идентична стандартизации процессов. Далеко не всегда, стандартизация, как единственно верный способ выполнения процесса, будет полезен. Необходимо выполнять процессы таким образом, чтобы они были эффективны, а не стандартны.
3. Правильно спроектированный и внедренный процесс, предусматривает множество сценариев развития и возможность создания нового! Без потери заданной эффективности. Это высший пилотаж управления бизнес процессами. Вероятно стоит посвятить данному вопросу отдельную статью.
4. Использование уровней управления, принципов и правил, позволяет обеспечить эффективность при весьма большой свободе действий. Нет необходимости пытаться описать процесс написания картины художником. Однако процесс создания картины описать можно. Более того, это может повысить эффективность процесса написания, за счет устранения отвлекающих факторов – например подготовки мольберта, красок и т.д.

Поймали мысль?

Создание человеческих роботов, не является целью управления бизнес процессами. Цель – обеспечить эффективность и развитие процессов. А использование творческой и человеческой составляющих, скорее усиливает, чем вредит процессу.

Автоматизация операций это управление бизнес процессами

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

На самом деле, автоматизация, это инструмент. Один из инструментов управления и повышения эффективности. Один из многих инструментов.

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

Иногда можно даже встретить такие сообщения:

«Кстати, мы тут бота запили. Диагностику бизнеса проводит и аудит сайта…»

Занавес. Недоуменное молчание. Кто то нервно идет в курилку, а кто то в буфет.

Эти «специалисты» упускают из вида две вещи:
1. То, что они делают, очень далеко от автоматизации бизнес процессов, их настройки и, тем более, от управления бизнес процессами. Максимум, что они делают, это автоматизируют операции и некоторые процедуры. Например они могут наладить запись клиентских заявок с сайта в вашу систему CRM. Это как то очень далеко от оптимизации бизнес процессов, вы не находите?

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

Оптимизация бизнес процессов и автоматизация процедур, это разные вещи. Автоматизация процедур это частичка не только в управлении бизнес процессами, но и в нормальной автоматизации.

Мифы применения управления бизнес процессами

В нашей компании / отрасли управление бизнес процессами не сработает

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

Управление бизнес процессами работает в любой отрасли, и вот почему:

1. Универсальность принципов. Базовые принципы управления одинаково применяются во всех организациях. Специальные принципы тоже применяются повсеместно, но, как правило, видоизменяются под действием особенностей компании. В управлении бизнес процессами, тоже существуют принципы, которые применимы для любой компании. Вне зависимости сферы деятельности, вы будете определять границы бизнес процессов исходя из одних и тех же принципов. Не важно что вы производите – элементы космически спутников, или создаете интернет страницы, вы будете одинаково определять промежуточные продукты процессов. Принципы работают везде.
2. Адаптивность подходов. Существует множество подходов к управлению бизнес процессами. Прелесть в том, что опираясь на принципы управления бизнес процессами, вы будете адаптировать подходы, под свои конкретные нужды. Более того, правильное внедрение и использование подходов, будет заключать в себе механизмы адаптации. Каждый, правильно спроектированный процесс, заключает в себе такой механизм.
3. Комбинации методологий. Многие методологии оптимизации бизнес процессов, хорошими по себе. Но управление, предполагает поиск и внедрение такой комбинации методов, которая позволит показать наибольшую эффективность в конкретных условиях. Эта комбинация будет работать наилучшим образом только для вас. Кстати именно поэтому, слепое копирование подходов и методов других компаний не сработает в вашей компании.
4. Простота реализации. Для того чтобы получить преимущества управления бизнес процессами, не нужно высокоточных приборов и передовых информационных технологий. Да, технологии помогают, но это не главное. Управление бизнес процессами очень просто в реализации т.к. интуитивно понятным людям. Процессный подход основывается на логике и взаимосвязанности. А для их использования не нужны дорогостоящие инструменты.

Процессный подход всегда основывается на действительности вашей компании.

Мы пробовали управлять процессами – это не работает

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

Для них это не сработало. Почему? Потому что реализация.
Реализация хромает. У нас ведь это часто бывает – идея вроде хороша, но исполнение все губит.
А губит потому, что недооценили и не продумали. Не вникли в суть. Ведь дело, как я уже говорил выше, не в описании процессов, а в том, что вы делаете с этим дальше.

Когда человек говорит, что он пробовал пробежать марафон, но у него не получилось и «вообще это не мое», стоит выяснить – а что было для этого сделано и сколько он пробежал. А то часто получается, что пробежал он от булочной до подъезда 500 метров, устал, запыхался и решил бросить эту затею. Но он ведь пытался. Целых 500 метров пробежал. Из 42 километров. Понимаете мою мысль?

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

Использование управления бизнес процессами очень сложно и работает только в крупных компаниях

Ну да, ну да. А бег доступен только профессиональным атлетам.
Если у вас две ноги и две руки (и то необязательно), то вы можете бегать.

Если вы уже занимаетесь управлением, вы можете использовать управление бизнес процессами.

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

Надеюсь я вас обрадую – все это не так.
Не нужно супер оборудование, программное обеспечение класса ERP и специалисты мирового уровня.
Все что необходимо – это освоить методологию и подумать как реализовать ее имеющимися ресурсами.
Дорогое ПО, можно заменить доступными аналогами. Специалисты есть не только дорогие и раскрученные, но и очень даже доступные и человечные. А все оборудование может быть заменено на ноутбук, блокнот, ручку и телефон. Хотите узнать как? Спросите)))

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

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

Нет смысла заниматься процессами в небольших компаниях

Самая малочисленная компания, с которой я имел дело, не насчитывала и пяти человек.

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

Даже ваши личные процессы можно оптимизировать и эффективно управлять.

Более того, если компания не очень большая, она как правило очень стеснена в ресурсах, поэтому вопрос максимально эффективного их использования – это вопрос выживания.

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

Нельзя управлять “творческими процессами”

Творческими процессами управлять можно и нужно, но несколько иначе.
Я не говорю о том, что нужно управлять, например, самими процессом написания новеллы. Когда даже сам писатель не в состоянии объяснить как такой процесс происходит. Но необходимо сконцентрироваться на вспомогательных процессах, т.е. Тех процессах, которые создадут наилучше условия для выполнения основного.

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

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

Управление творческими процессами осуществляется через вспомогательные.

И кстати, если вас интересует прямое управление творческими процессами, обратитесь к трудам Эдварда де Боно. Он предлагает ряд крайне интересных механизмов.

Мифы применения процессного подхода

Чтобы заниматься управлением бизнес процессами, нужно разбираться в тонкостях работы

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

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

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

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

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

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

Хороший управленец, всегда будет управлять эффективнее самого высококлассного специалиста.

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

Мы справимся своими силами

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

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

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

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

Опять же, чаще всего, сотрудники просто игнорируют работу по изменениям по причине высокой загрузки. Здесь ведь нужно не только делать работу, но и прикладывать серьезные умственные усилия. А высокая текучка к этому не располагает.

Это еще одна причина, почему привлечение стороннего специалиста будет крайне полезно, а порой просто необходимо.

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

У нас не хватит ресурсов на внедрение

Для того чтобы оценить хватит у вас ресурсов или нет, нужно понимать, какие ресурсы нужны и в каком количестве.

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

Стадия определения границ бизнес процессов
– Топ менеджмент – 4-5 часа в неделю.
– Средний менеджмент – 5-6 часов в неделю.
– Функциональные руководители – 2-3 часов в неделю.
– Специалисты – 1-2 часа в неделю.

Стадия описания бизнес процессов


– Функциональные руководители – 4-5 часов в неделю.
– Специалисты – 6-8 часов в неделю.

Стадия планирования изменений
– Топ менеджмент – 4-5 часов в неделю.
– Средний менеджмент – 7-8 часов в неделю.
– Функциональные руководители – 7-8 часов в неделю.
– Специалисты – 4-5 часов в неделю.

Стадия внедрения изменений
– Топ менеджмент – 1 час в неделю.
– Средний менеджмент – 2-3 часов в неделю.
– Функциональные руководители – 8-12 часов в неделю.
– Специалисты – 8-10 часа в неделю.

В общем, на внедрение изменений необходимо выделять 20 – 30% рабочего времени задействованных сотрудников. Помните – изменения не внедряются одновременно, но волнообразно, так что фактически, вы выделяете совсем немного времени, относительно всех ресурсов компании.

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

Если вы готовы выделить 20% рабочего времени ответственных сотрудников, вы справитесь с изменениями.

Наемные специалисты все сделают за вас

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

Подход «Мы платим, пусть они все делают», здесь не сработает. Вам придется помогать им. А они будут помогать вам. Это полностью взаимовыгодное сотрудничество.

Разделение ролей здесь очень простое. Специалисты владеют навыками и технологиями управления. Вы лучше всего знаете свой бизнес и свою отрасль.
Специалисты знают что и как делать в управлении. Вы знаете как и что делать в технологиях.

Специалисты не сделают все за вас. Только совместная работа приносит результат.

Сложно оценить эффект от управления бизнес процессами

Есть много способов оценки эффекта от внедрения управления бизнес процессами.
Самый простой – функционально стоимостной анализ.

Суть в следующем.
Когда известны все составляющие бизнес процесса, можно подсчитать стоимость его выполнения. Для расчета стоимости процесса учитывается:
– Затраты выполнение операций сотрудниками. Исходя из длительности операций и стоимости человека часа сотрудников.
– Затраты сырья и материалов
– Затраты на использование инструментов исходя из их срока эксплуатации
– Затраты на использование инфраструктуры. Если необходимо.
– Прочие производственные затраты. Например электроэнергия, вода и т.д.

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

Оценка стоимости выполнения процесса производится до изменений и спустя определенное время. Как правило, когда мы считаем, что изменения стали явными.

Разница в стоимости выполнения процесса и есть тот эффект, который вы получили.

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

Методы оценки эффективности использования управления бизнес процессами разнообразны, но при этом просты для применения.

Мы увидим результаты уже «завтра»

На самом деле – нет.
Любые изменения требуют времени. Сначала на организацию изменений. Затем на их реализацию, т.е. Непосредственно изменение процесса. Затем необходимо время, пока изменения полностью приживутся (или нет), а сотрудники начнут выполнять работу в соответствии с новым процессом.

Внедрение изменений всегда встречает сопротивление. И на его преодоление тоже требуется время.
Если вы пошли учиться плавать, это не значит, что завтра вы сможете спокойно проплыть несколько километров.

Разные изменения требуют разного времени. Некоторые внедрить очень просто – буквально за пару недель. Другие требуют годы. Соответственно эффект от изменений тоже будет виден на разных временных горизонтах.

Мы делим изменения на «быстрые» и «планомерные». Эффект от быстрых изменений виден не более чем через 2 месяца с момента внедрения. Все остальное – планомерные улучшения.

Миф о скорости изменений часто вредит компаниям. Когда до точки невозврата остается совсем чуть чуть, компания может сдаться. Важно уметь трезво оценивать возможную скорость изменений и получение эффекта.

Изменения не происходят быстро. Ни в жизни, ни в компаниях.

Не дайте себя обмануть, или Быстрый сыр, как правило, дурно пахнет

Любого специалиста, посвятившего себя Делу, возмущает шарлатанство. Я не исключение.
Управление бизнес процессами – это моя профессия, которой я посвятил основную часть трудовой деятельности. На этом пути были и выдающиеся успехи, и грандиозные провалы. И будет их еще больше. Это закономерное развитие профессионала. Знать всего невозможно, но 3 вещи я знаю наверняка:
1. Желающий получить все и дешево, получает ничего и дорого.
2. Методичность, последовательность и терпение всегда приносит свои плоды.
3. Только плохое происходит сразу. Все хорошее требует времени.

Поэтому:
– Трехдневные тренинги, гарантирующие увеличение продаж на 30% – шарлатанство
– Автоматизация бизнес процессов за неделю – обман
– Автоматизация процессов маркетинга – опасна, потому что автоматизируются только расчеты по грубым шаблонам.
– Двадцатипятилетний эксперт по оптимизации бизнес процессов – наглый авантюрист
– Если в одном предложении встречайте «управление бизнес процессами» и «CRM» – это про общедоступную CRM и больше ни про что.
– Если специалист по управлению бизнес процессами говорит вам что бизнес процесс это, «устойчивая целенаправленная совокупность взаимосвязанных видов деятельности, которые по определенной технологии преобразует входы в выходы, представляющие ценность для потребителя» – бегите от него!
– Анализ вашего бизнеса по сайту – все равно что лечить зубы по фотографии

Опасайтесь мифов и шарлатанов. Все модное становится предметом спекуляции.

Владимир Мальзам Бизнес-аналитик

Роль методов анализа в управлении процессами

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

Управление процессами впервые было упомянуто Анри Файолем в книге "Общее и промышленное управление", изданной в 1916 году. В ней были систематизированы решения, позволившие превратить горно-металлургическую компанию в лидера отрасли, находившуюся, на момент его прихода в компанию, на грани банкротства. Были в тот период и исследователи, узко специализировавшиеся на операционном менеджменте, статистическом подходе и других аспектах управления.

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

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

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

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

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

Функциональный анализ процессов

Цель: оценка того, насколько рационально организованы действующие процессы, поиск более эффективных способов их реализации.
Источник данных: графические модели бизнес-процессов.

При бумажной регламентации, модели теряют актуальность через 3-6 месяцев, и проведение анализа обычно требует повторного описания процессов с отрывом от работы исполнителей на интервьюирование. Системы BPMS, в силу логики своей работы, обеспечивает актуальность моделей процессов в любой момент времени.

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

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

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

В зависимости от набора услуг, для каждой сделки готовилось до 22 документов. В существующей информационной системе для этого требовалось 350 кликов мышью и 25 минут рабочего времени. Разработка модуля информационной системы, позволяющего формировать весь пакет, снизила трудозатраты на эту операцию в 8 раз.

В исходном виде процесса, подготовку части документов менеджерам приходилось откладывать на конец рабочего дня, нередко задерживаясь на работе до 20:00. Далее, курьер доставлял документы клиенту на подпись и оплату. Документы, подготовленные до 17:00 текущего дня, доставлялись клиенту на следующий день. Документы, подготовленные позже, доставлялись "через день". При такой организации, от устного согласования сделки до ее подтверждения подписью клиента и оплатой проходило 2-3 дня.

Доработка информационной системы, помимо снижения себестоимости процесса, легла в основу ряда мер, снизивших в 24 раза время от звонка до фиксации сделки подписью клиента. С 2-3 дней до 2-3 часов. Такая организация снизила риск отказа клиента от устного соглашения и косвенно увеличила объем продаж.

План-факторный анализ показателей

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

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

Пример: предприятие ЖКХ столкнулось с проблемой собираемости платежей.

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

Автоматизация начисления платежей позволила исключить ошибки в расчетах. При общении с клиентом, бухгалтер мог за 8 секунд отследить и объяснить историю формирования любой цифры. Прозрачность начисления принесла в работу ряд положительных следствий. Конфликты исчезли, но собираемость увеличилась лишь на 3-5%.

Далее, фокус внимания был перенесен с оптимизации существующих процессов, дающих 80% собираемости, на выявление факторов, обуславливающих отказ от оплаты оставшихся 20%. План-факторный анализ выявил причины отказа от погашения задолженности и позволил найти решения по устранению или сглаживанию их негативного влияния:

Фактор №1 - плательщик имеет низкий доход и не может выплачивать полную сумму самостоятельно. По закону, плательщик имеет право платить за услуги ЖКХ сумму, не превышающую 20% дохода семьи. Разница субсидируется государством. Для реализации права на субсидию, плательщик должен ежеквартально предоставлять утвержденный пакет документов. Плательщик часто не знает о своем праве на субсидию, либо не знает, как его реализовать.
Решение: сделать все, чтобы плательщик, имеющий право на субсидию, ее получал. Консультировать по порядку оформления, обеспечить необходимыми справками со своей стороны. Далее, требовать самостоятельной оплаты оставшихся двадцати процентов.

Фактор №2 - льготы и субсидии предоставляется на сумму, начисленную за площадь "в пределах социальной нормы". Это ставит под удар пенсионеров, имеющих квартиры с большим метражом. Для снижения коммунальных платежей, обычно они стараются минимизировать в своей квартире количество "прописанных" родственников, но получают обратный эффект - попадают, по логике закона, в статус "живущих в роскоши", лишают себя права на субсидию, некоторые льготы и получают услуги по повышенному на 20% тарифу. В результате этих действий, сумма платежа вырастает до несовместимого с жизнью уровня, клиенты физически не способны ее оплатить.
Решение: сделать выборку информации о клиентах, имеющих "лишнюю" жилплощадь. Проконсультировать их о принципах начисления услуг и расчету оптимального числа прописанных в квартире родственников, для минимизации суммы начисленных платежей и получения права на субсидию.

Фактор №3 - руководитель одного из подразделений, ответственный за внутридомовые коммуникации, отказывается выполнять большую часть заявок жильцов. При этом он имеет настолько развитый "эмоциональный интеллект", что клиенты просто уходят, не жалуясь выше. В знак протеста, они отказываются от оплаты всех услуг, как предоставленных так и не предоставленных.
Решение: организовать прием заявок через подразделение, ответственное за собираемость платежей. Оно должно передавать заявки в подразделение-исполнитель и вести статистику по удовлетворенности плательщиков.

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

1. Невозможно повысить результативность, анализируя процесс

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

2. Между негативными факторами взаимосвязей не существует

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

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

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

Структурный анализ процессов

Цель: выявление границ процессов, корректная идентификация входов и выходов.
Источник данных: графические модели бизнес-процессов, описанные при функциональном анализе.

Структурный анализ выявляет два типа ошибок:

1. Ошибки целеполагания;
2. Несоответствия между полномочиями и ответственностью;

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

Вне зависимости от причин возникновения, эти ошибки ведут к некорректному выбору KPI. Мотивация на достижение некорректного KPI несет ряд крайне негативных последствий:

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

О технологии анализа

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

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

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

Пример №1

На одном из проектов была поставлена задача - повысить показатели отдела продаж. Изначально этому отделу был назначен KPI "объем продаж", что на первый взгляд логично. На объем продаж была ориентирована и жесткая система мотивации - полностью отсутствовала окладная часть зарплаты, только процент с продаж.

Исходный KPI "объем продаж", диктовал нечеткий способ достижения - "больше и лучше работать". К такой цели невозможно было применить план-факторный анализ. Замена KPI на "процент обращений, завершенных сделками" открыл план-факторной разрез - "что повлияло на отказ клиентов от сделки". Далее, план-факторный анализ выявил 12 факторов (!), повышающих риск отказа клиента от сделки. Были внесены изменения в процесс, исключающие саму возможность проявления многих факторов и существенно сглаживающие негативные эффекты от оставшихся.

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

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

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

Пример №2

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

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

Если бы показателем эффективности было выбрано "время простоя терминалов в неисправном состоянии", техники мотивировались на минимизацию этого показателя, и жесткость системы мотивации была разумной - стоимость обслуживания сети снизилась бы в 5 раз, при пятикратном же повышении качества ее работы (уменьшении времени простоя в ремонте).

Декомпозиция стратегии на целевые показатели

Суть управления организацией состоит в увязке содержания деятельности с меняющимися внешними условиями:

• интересами собственников;
• финансовым рынком;
• потребностями клиентов;
• конкурентной средой;
• законодательством;
• актуальными технологиями и т.п.

Суть управления процессами состоит в их перенастройке на достижение KPI, реализующих стратегические цели и интересы организации. Управление процессами может подразумевать, как достижение показателей по существующим KPI, так и переориентацию содержания процессов на другие KPI. Целевые ориентиры, для управления процессами, формируются путем декомпозиции стратегических целей.

Источник данных: стратегические цели организации и типы показателей эффективности, выявленные при структурном анализе процессов.

Цель декомпозиции: сфокусировать внимание менеджеров и исполнителей на показателях, реализующих стратегические цели организации, и организовать систему их контроля.

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

Декомпозиция стратегии - компетенция менеджмента, роль аналитика здесь вспомогательная.

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

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

Обзор классических инструментов управления и систем BI

Влияние качества инструментов управления на эффективность методов анализа

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

• Машиностроительные компании выработали концепцию "Lean", глубоко проработав принципы функционального анализа. Ее цель - устранение, в сверхдлинных производственных цепочках, непроизводительных затрат и избыточного замораживания оборотных средств в незавершенном производстве (межоперационных заделах).
• Производители электроники выработали концепцию "Six Sigma", основанную на подвиде план-факторного анализа - статистическом. Ее цель - снижение доли брака за счет комплексного подбора параметров технологического процесса.
• Компании, специализирующиеся на продаже услуг, как правило, используют бюджетирование в качестве базовой системы управления.

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

Чем обусловлена такая ситуация

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

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

Какие риски она привносит

Слабый контроль вспомогательных процессов открывает простор для злоупотреблений. Подразделения, не имеющие корректных и измеряемых целей, остаются, предоставлены сами себе. Часть из них ориентируется на отсутствие жалоб от смежников. Некоторые используют неподконтрольность, как базу для выстраивания скрытой системы злоупотреблений. В результате, эффективность такого подразделения снижается на сотни и тысячи процентов. И на 30-60% снижается эффективность смежных с ними подразделений.

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

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

Регламентация

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

Работа юридических инструментов основывается на следующей логике:

1. С работником заключается трудовой договор, в котором он добровольно принимает на себя обязательства, исполнять распоряжения непосредственного руководителя и подчиняться правилам компании;
2. Распоряжения руководителя (акты управления) оформляются в формате, имеющем юридическую силу;
3. Работник знакомится с распоряжениями и исполняет их;
4. Руководитель контролирует исполнение;
5. Если распоряжение не было выполнено в том виде, как это предписывалось актом управления, значит, работник нарушил свои обязательства по договору. В этой ситуации Трудовой кодекс РФ дает право работодателю применить дисциплинарное наказание, вплоть до увольнения;

Для наделения актов управления юридической силой, обычно достаточно дополнить содержательную часть наименованием "Приказ", датой и подписью руководителя. Содержательная часть может быть вынесена в приложение к приказу, без потери юридической силы.

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

Система управления формируется в виде набора регламентов и инструкций - нормативно-распорядительной документации (НРД). НРД представляет собой "внутреннее законодательство" организации, детализирующее требования к работникам, прописанные в трудовых договорах. Ее назначение – дать руководителям инструмент системного управления. Сменить подход к управлению, с выработки ситуационных распоряжений, на совершенствование системы принципов реализации функций, за которые менеджер отвечает.

Недостатки регламентации делятся на две категории: "типичные" - поддающиеся устранению, и "системные", устранить которые невозможно, в рамках юридических принципов управления.

Типичные недостатки регламентации

1. Требования к компетенциям Применение юридических инструментов требует понимания принципов их работы всеми сторонами, включая исполнителей. В ВУЗах преподают такие знания студентам, обучающимся по специальности "Менеджмент организации". На управленческих же должностях, как правило, лучше себя проявляют не выпускники кафедр абстрактного менеджмента, а руководители с профильным образованием в той области, которой они руководят. Это провоцирует отношение к регламентации как к самоцели, использование НРД часто вырождается из системного проектирования в бесцельную ритуальную рутину.
   Если подготовкой регламента занимается не руководитель, а выделенный специалист, даже понимающий суть своей деятельности, он все равно опасается негативной оценки вышестоящим руководством степени псевдонаучности своей работы. Такие опасения могут быть мнимыми или обоснованными, результат будет одинаков - документ осознанно будет подготовлен в нечитаемом, канцелярском стиле, с целью не обеспечить эффективность процесса, а получить подпись директора.
2. Некритичность к ошибкам Юридический инструмент некритичен к ошибкам, у исполнителя всегда есть возможность проигнорировать некорректное требование и выполнить задачу "по ситуации". Это еще один фактор, который не мотивирует разработчика к качественной проработке регламентов. Дефекты проработки могут сколь угодно снижать эффективность деятельности, об этом никто никогда не узнает. Выявлены будут лишь те ошибки, которые провоцируют серьезные конфликты между участниками процесса.
3. Отсутствие обратной связи с исполнителями Легкость обхода требований регламента и формальный риск наказания, мотивируют исполнителя замалчивать информацию о потере регламентом актуальности. В итоге "инструмент управления" превращается в "инструмент догоняющего документирования" - он не решает никаких задач и поддерживается из принципа "так принято, все так делают". С потерей актуальности, система НРД превращается либо в библиотеку ни к чему не обязывающей макулатуры, либо в фактор, вызывающий деструктивное психологическое давление на ответственных и эффективных исполнителей, из-за потенциальной ответственности за вынужденные нарушения.

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

Системный недостаток регламентации

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

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

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

Автоматизация

Нередко ряд действий процесса можно вывести из зоны ответственности работника. В сфере услуг для этих целей хорошо себя зарекомендовала автоматизация. Автоматизированные фрагменты исполняются мгновенно, дешево и не нуждаются в системе контроля.

Автоматизация имеет два недостатка:

1. Жесткие ограничения на состав операций - возможна только обработка, передача и хранение оцифрованной информации. В подавляющем большинстве случаев, автоматизировать удается лишь отдельные фрагменты процесса. Оставшиеся операции исполняются работниками, согласно регламентам и инструкциям. Фрагментарная автоматизация позволяет существенно повысить производительность труда, но не способна обеспечить сквозного управления и контроля.
2. Высокая стоимость разработки, а также длительность, неприемлемая для задач управления процессами. Классические языки программирования, ориентированные на разработку тиражируемого программного обеспечения, целесообразно использовать только для фрагментов процессов, логика работы которых, не меняется годами. Это еще больше сужает область применения классических информационных систем.

Информационные системы класса BPMS предназначены для совмещения автоматизации, электронной регламентации и сквозного контроля исполнения процессов.

Системы BI (отступление)

Прежде чем описать третий тип инструментов (BPMS), раскрою термин BI, поскольку в дальнейшем придется его использовать.

Аббревиатура BI расшифровывается как "бизнес-интеллект". В период зарождения термина, предполагалось, что главным преимуществом этого инструмента станет "data mining" – алгоритмы "искусственного интеллекта", способные находить в данных компании неочевидные закономерности, полезные для управления бизнесом. Впоследствии, производители BI-систем не смогли выработать действительно полезных алгоритмов и "бизнес-интеллект" стал маркетинговым ярлыком, за которым стоит очередное поколение OLAP-систем.

BI-система представляет собой связку из:

• Отдельной базы данных;
• Инструментов анализа многомерного массива данных и наглядного отображения результатов;
• Инструментов интеграции, для загрузки исходных данных из внешних систем;

Предварительное копирование информации в отдельную базу позволяет:

• Не перегружать поисковыми запросами исходные информационные системы (ИС);
• Одновременно использовать, для анализа, данные, загруженные из функционально разных ИС;
• Консолидировать данные из одинаковых систем, использующих для работы отдельные экземпляры баз данных. К примеру, данные региональных филиалов.

Как правило, система допускает использование нескольких языков запросов (SQL, MDX и т.п.) Эти языки разрабатывались, как доступные для освоения бизнес-пользователями и не требующие профильного ИТ-образования. Обычно составлением запросов занимается специалист, прошедший краткосрочный курс обучения. Привлечение программистов требуется только для организации выгрузки данных в аналитическую базу, с заданной периодичностью. Иногда для этого приходится дорабатывать ПО, из которого производится выгрузка.

BI-системы позволяют без привлечения ИТ-специалистов:

• Выполнять произвольные поисковые запросы и анализировать результаты в различных срезах;
• Создавать периодические отчеты и автоматизировать их рассылку заданным пользователям;
• Выводить результаты запросов в виде панелей индикаторов и назначать пользователям (менеджерам) права доступа к ним;
• Предоставлять доступ к отчетам и панелям индикаторов через смартфоны и планшеты;

Примеры управленческих панелей индикаторов:

Свои преимущества BI-системы раскрывают на узком круге задач, который актуален далеко не для любой организации. Обычно это управление запасами и логистикой крупных торговых сетей – аптечных, продуктовых, книжных. Их ассортимент может насчитывать десятки тысяч позиций. Если товары имеют ограниченный срок годности и анализ требует учета географии мест хранения, аналитикам приходится оперировать сотнями тысяч партий. Для таких задач, BI-системы - незаменимый инструмент.

К управлению процессами BI-инструментарий, выделенный в самостоятельную BI-систему, не имеет никакого отношения. Технически его можно использовать для контроля показателей, но необходимость привлечения ИТ-специалистов, при каждой корректировке процессов, резко повышает издержки и делает управления процессами нецелесообразным.

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

BPMS. Принципы работы, преимущества и ограничения

Информационные системы класса BPMS созданы для замещения большей части регламентов, классических информационных систем (ИС) и сбора управленческой аналитики. Расшифровывается BPMS, как "Business Process Management Suite" и в переводе означает "набор инструментов управления бизнес-процессами".

BPMS представляет собой сплав классической информационной системы и "Workflow engine" - "движка" рассылки пользовательских задач. "Workflow engine" имеет много общего с электронной почтой, но есть и отличия:

Workflow и E-mail - отличие №1

Вместо электронных писем, между работниками пересылаются поручения сделать что-либо - "Пользовательские Задачи".

Скриншот 1 - Рабочее место Исполнителя

Workflow и E-mail - отличие №2

От работника скрыты поля "Кому" и "От кого", он должен выполнить Задачу, внести в интерфейс результат и подтвердить его. Логика взаимодействия фиксируется на этапе разработки, в виде исполняемой модели процесса. Работник - инициатор процесса, запускает его вручную, далее рассылка задач производится согласно модели.

Скриншот 2 - Интерфейс Разработчика процессов

Исполняемая модель процесса создается в несколько шагов:

1. В окно модели, для каждого исполнителя, мышью переносятся "области ответственности". На скриншоте №2 они отображены в виде вертикальных полей с наименованиями:
   • "Администратор продающего подразделения";
   • "Работник операционной поддержки";
   • "Андеррайтер";
2. В областях ответственности размещаются "Задачи";
3. Порядок исполнения Задач задается "стрелками";
4. В "шлюзах" настраивается логика ветвления;

Шлюз на скриншоте №2, реализует следующую логику:

• Если группа риска профессии страхователя пятая или выше - сформировать для андеррайтера Задачу "Рассчитать и утвердить андеррайтерский коэффициент";
• Иначе, если группа риска ниже пятой, исполнить Задачу-скрипт "Рассчитать страховую премию и сформировать маску полиса";

Workflow и E-mail - отличие №3

В электронной почте есть одно основное поле, в которое помещается вся информация, в неструктурированном виде.

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

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

В workflow-модуле работнику приходит Задача, с интерфейсом, настроенным только под ее решение. Нет лишних элементов. Потребность в обучении отсутствует, риск ошибки снижается на порядки.

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

Обычно интерфейс содержит:

• поля с исходными условиями Задачи;
• инструкции по исполнению Задачи, при необходимости;
• поля ввода результата исполнения.

Интерфейс Задачи создается в два этапа

Первый этап: в табличной форме готовится "список данных", которыми придется оперировать в процессе;

Скриншот 3 - Табличная регистрация типов данных процесса

Второй этап: разработчик открывает свойства каждой Задачи и переносит мышью необходимые поля из "списка данных" на макет пользовательского интерфейса.

Скриншот 4 - Перенос полей из списка данных в макет интерфейса Задачи

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

Прочие компоненты BPMS

Кроме workflow-модуля, BPMS включает стандартные возможности классической информационной системы:

1. Автоматизацию математических и логических вычислений;
2. Формирование отчетов и управленческих панелей индикаторов;
3. Подготовку форм для печати на принтере;
4. Некоторые BPMS содержат модули интеграции с внешними системами: IP-телефонией, 1С-бухгалтерией, корпоративным сайтом, сервисами SMS-информирования и т.п.

Для автоматизации вычислений, в модель процесса помещается Задача типа "скрипт", в ее свойства вписывается алгоритм обработки. На скриншоте №2 вы можете увидеть такую Задачу с наименованием "Рассчитать страховую премию и сформировать маску полиса". В системах разных производителей используют разные языки программирования скриптов – C# (СиШарп), Java или JavaScript.

Для формирования отчетов и управленческих панелей индикаторов, в систему встроен BI-инструментарий. От самостоятельных BI-систем он отличается отсутствием отдельной аналитической базы данных. Такое решение позволяет отказаться от привлечения ИТ-специалистов, при корректировке процессов и системы их контроля.

В итоге, разработка исполняемых процессов содержит шесть этапов:

1. Создать модель процесса;
2. Создать список данных;
3. Создать индивидуальный пользовательский интерфейс для каждой Задачи;
4. Настроить логику шлюзов;
5. Прописать скрипты автоматизации;
6. При необходимости, обеспечить интеграцию с внешними системами (если нет готового модуля интеграции, потребуется привлечение ИТ-специалиста);
7. Увязать пользовательские учетные записи с ролями в процессе;

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

Преимущества BPMS

Внедрение BPMS позволяет решить следующие задачи:

1. Снизить стоимость и длительность разработки программного обеспечения в 10-30 раз Разработка процессного приложения занимает 5-30 дней, корректировка (акт управления процессом) - от 10 минут до 4 дней. 90% трудозатрат реализуется подготовленным бизнес-пользователем, без привлечения ИТ-специалистов.
   Разработка организована по принципу переноса мышью объектов и заполнения таблиц. Бизнес-пользователь может создать более качественный продукт, сосредоточившись на решении задач организации, вместо "борьбы с техническими трудностями", обусловленными избыточной сложностью классических языков программирования;
2. Сократить до нескольких минут длительность внедрения актуальных версий процесса Глубокие изменения в компании, путем регламентации, занимают 1-2 месяца, с множеством непреднамеренных ошибок работников и их исправлением, в период адаптации. Внесенные в регламенты несущественные изменения, нередко игнорируется работниками.
   Процесс в BPMS, "публикуется на сервер" в горячем режиме и не требует приостановки работы исполнителей. Сразу после "публикации" все филиалы начинают работать по новой версии.
3. В разы снизить временные затраты на переобучение работников Система позволяет отказаться от заучивания большой части документации. При внесении изменений в процесс, в большинстве случаев, исполнителей не потребуется об этом даже уведомлять. Логика взаимодействия администрируется без их участия. А содержание Задачи, при необходимости, прописывается в ее интерфейсе. Работнику остается делать то, что от него требует логика и описание интерфейса;
4. Свести к нулю затраты на поддержку в актуальном состоянии моделей процессов и перенесенных в систему регламентов Модели процессов пригодны для функционального и структурного анализа в любой момент времени. Исключается необходимость начинать каждую итерацию анализа с проекта по повторному описанию (актуализации) процессов.
   Электронные регламенты (процессные приложения) также актуальны в любой момент времени. Обойти большинство требований электронных регламентов нет технической возможности. Если работник обнаружил необходимость в актуализации, ему придется эскалировать эту проблему руководству. В течение 1-4 дней процесс будет доработан и исполнитель сможет решить возникшую проблему.
5. В разы снизить стоимость контроля показателей процессов При бумажной регламентации, учет многих показателей не ведется, поскольку стоимость его реализации неоправданно высока. Это отражается в качестве управленческих решений. В системах BPMS временные затраты на исполнение Задач не требуют организации учета - эта функция вшита в систему. Сбор статистики по отклонениям от оптимального хода процесса - тоже базовая функция.
   Интегрированный BI-инструментарий позволяет, без привлечения ИТ-специалистов, организовать контроль любых показателей процесса. Выигрыш, по сравнению с внешними BI-системами, в том что, при корректировке процесса, часто требуется корректировка и системы его контроля. Встроенный BI-инструментарий требует на настройку несколько десятков минут, вместо нескольких дней/недель, характерных для перенастройки интеграции с внешними BI-системами.

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

Ограничения BPMS

В наибольшей степени BPMS проявляют свои преимущества, если характер деятельности укладывается в некоторые ограничения:

1. Исполнитель имеет на рабочем месте компьютер, планшет или смартфон с подключенным интернетом или локальной сетью организации. С распространением смартфонов и планшетов это ограничение становится все менее актуальным.
2. Требуется координация работы нескольких исполнителей;
3. Характер процесса подразумевает, что его корректное исполнение гарантирует получение требуемого результата;

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

Примером "неподходящей" деятельности, в некоторых случаях, может служить взаимодействие с клиентами. Каждый экземпляр процесса по подбору и продаже жилья, к примеру, сопровождается одним агентом и не использует возможности Workflow-движка по координации работы разных сотрудников.

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

Может ли BPMS полностью заменить ИТ-системы?

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

Может ли BPMS полностью заменить распорядительную документацию?

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

Выгоды от BPMS пропорциональны:

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

Этим объясняется востребованность систем BPMS в страховой, банковской и некоторых других сферах услуг.

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

Заключение

В итоге, набор инструментов управления процессами будет выглядеть так:

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

1. Специализированные ИС

В этом блоке останутся:

• Сервисы, предоставляемые другими организациями: интернет-эквайринг, sms-информирование, ip-телефония, расчет маршрутов в яндекс-картах и т.п.
• Частично, функционал уже используемых в организации информационных систем. Та часть, которую проще интегрировать с BPMS, чем переносить в формат скриптов.

1. Скрипты процессов - алгоритмы обработки информации, которых нет в старых информационных системах или которые дешевле прописать заново, чем реализовывать путем интеграции. В дальнейшем, в рамках управления процессами, их будет проще и быстрее корректировать, чем связку из функций старой системы и функций интеграции с ней;
2. Электронные регламенты (Workflow)

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

1. Юридические регламенты

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

Сегодня в отечественном бизнесе набирает популярность новый вид программного обеспечения для управления бизнес-процессами, а именно, BPMS-системы. И, естественно, их появление вызвало много вопросов. Зачем они нужны? Как они работают? В чем их принципиальное отличие от других вариантов автоматизации бизнеса?

Когда я впервые столкнулся с BPMS, у меня также возникли все перечисленные выше вопросы. Я далеко не сразу понял, зачем нужен новый инструмент, почему нельзя реализовать все необходимые для успешной работы бизнес-процессы в уже имеющихся системах учета или CRM, и в чем принципиальное отличие BPMS от других вариантов автоматизации бизнес-процессов.

В этой статье я хочу рассказать о том, что такое BPMS-системы, зачем они нужны и чем процессный подход отличается от традиционных методов работы. Я не буду говорить о технических аспектах BPMS (о моделировании и разработке бизнес-процессов), этому будет посвящена следующая статья. Сейчас я постараюсь раскрыть сущность и смысл BPMS максимально простым и понятным языком:

Что такое BPMS?

BPMS - еще одна аббревиатура из разряда ERP, CRM, которая не имеет четкого определения. Хотя определений достаточно много: и зарубежных, и российских. Кроме того, компании, которые выпускают собственные BPM-системы, также дают свои, особые определения, что вносит дополнительную путаницу. К тому же нередко BPMS объединяют с другими системами (например, BPMS+CRM, BPMS+ERP) и тогда разработчики дают определение BPM-системы, исходя уже из этого контекста.

Но для того, чтобы разобраться, что такое на самом деле BPMS, и в чем заключаются их особенности, необходимо сначала разобраться, что такое BPM.

BPM (англ. Business Process Management, управление бизнес-процессами) - концепция процессного управления организацией, рассматривающая бизнес-процессы как особые ресурсы предприятия, непрерывно адаптируемые к постоянным изменениям, и полагающаяся на такие принципы, как понятность и видимость бизнес-процессов в организации за счёт моделирования бизнес-процессов с использованием формальных нотаций, использования программного обеспечения моделирования, симуляции, мониторинга и анализа бизнес-процессов, возможность динамического перестроения моделей бизнес-процессов силами участников и средствами программных систем.

Википедия.

BPMS (англ. Business Process Management System) - это в первую очередь программное обеспечение для поддержки концепции BPM в компании. BPMS-системы нужны для того, чтобы реализовывать в программной среде концепцию BPM.

BPMS рассматривает работу компании как набор процессов, а не как набор функций. Объектом BPM-системы является не работа отдела продаж или закупок, а процесс продажи, процесс поддержки клиентов, процесс управления снабжением и т.д. И уже исходя из этого понимания, строится работа по реинжинирингу бизнес-процессов в BPMS.
BPM-cистема направлена, главным образом, на совершенствование работы компании, на более прибыльную деятельность предприятия путем оптимизации и контроля бизнес-процессов.

Работа пользователей в BPMS и других системах

Для лучшего понимания сути BPMS, нужно понять, как обыкновенные системы (ERP-системы, CRM) подходят к работе пользователей. Например, пользователю необходимо составить заказ клиента. Каковы его действия?

Пользователь может заполнять документ произвольно, если не запрограммирована последовательность его работы:

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

Одним словом, в действиях пользователя есть вариативность, т.е. сотрудник, исходя из ситуации, может выбирать собственные варианты действия.

BPM-система рассматривает пользователя как еще один кирпичик в системе. Человек должен четко знать, в каком процессе он работает и что он должен делать.

Сотрудники в BPM-системе рассматриваются не с точки зрения результата процесса, а с точки зрения выполнения действия. Вариативность действия пользователя здесь исключается. Сотрудник делает только то, что запрограммировано в системе, ни больше, ни меньше.

Способы реализации бизнес-процессов

BPMS - это один из способов реализации бизнес-процесса. Рассмотрим, какие способы представлены в реалиях российского бизнеса для понимания, зачем же нужна BPM-система.

Выделим три подхода:

1. “Бумажный” подход;
2. Автоматизированный подход (с применением других систем);
3. Процессный подход в системе BPMS.

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

Потому что у них в компании не было процедуры согласования счета. Узнали мы с директором компании об этом совершенно случайно. Я узнал, что в их компании на этапе согласования счета происходят периодические сбои, а директор с удивлением обнаружил, что он оплатил не 50% счета, как планировал, а сразу 100%.

Почему так случилось? Все просто. Сработал, так называемый, “испорченный телефон”. Специалист принес с бухгалтерию счет к оплате с фразой “Надо оплатить 50% от суммы”. Бухгалтер уточнила у руководителя, оплачивать этот счет или нет. Руководитель, будучи уверенным, что речь идет о 50% суммы, подтвердил оплату. А бухгалтер, в свою очередь, забыла о том, что вслух было сказано о половине суммы, и поняла руководителя так, что надо оплатить весь счет. Что и было сделано.

На примере этой компании и этого бизнес-процесса мы и рассмотрим все три подхода.

“Бумажный” (не автоматизированный) подход

Как раньше происходило согласование счета в этой компании?

• Сотрудник получает счет, передает его в бухгалтерию;
• Бухгалтерия вписывает счет в платежную ведомость, согласовывает ее с руководителем;
• Если руководитель одобряет и подписывает запрос, бухгалтерия оплачивает счет.

Чем плох этот подход? Здесь размыты границы перехода зон ответственности между этапами. В случае недоразумения и не своевременной оплаты или неоплаты счета сотрудники перекладывают вину друг на друга, и невозможно в итоге найти ответственных.

Автоматизированный подход

Как правило, компании стараются контролировать тот или иной бизнес-процесс в учетной системе, в которой они уже работают. Но это также неправильно. Рассмотрим, какие минусы есть при таком варианте.

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

Как это выглядело:

• В системе назначаются ответственные лица за согласование расходов;
• На основании какого-либо документа (заказа поставщику, поступления товаров или другого документа) создается документ Заявка на расходование денежных средств в статусе Не согласовано;
• Если ответственный согласовал заявку и поменял статус на Согласовано, то счет направлялся в бухгалтерию;
• Если ставился статус Отклонено, значит, заявка уходила обратно к лицу, инициировавшему процесс.

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

• создать доступ в систему;
• обучить работе с необходимыми документами;
• настроить интерфейс для удобства использования;
• настроить права доступа.

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

Для принятия решения в данном случае интересны только 3 момента:

1. деньги (сколько мы должны выплатить);
2. получатель (кому мы должны выплатить);
3. назначение (за что выплачиваем).

А, значит, заполняя лишнюю информацию, сотрудник теряет время, и процесс согласования затягивается.

К тому же, такая реализации согласования в учетной системе достаточно примитивна и не предполагает вариативности (например, разделение зон ответственности в зависимости от суммы документа или статьи расходов).

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

Итак, основные отличия ведения бизнес-процессов в BPMS от учетной системы:

1. В BPMS важно именно то, что делается. Здесь важна не учетная информация, не отчетность, а необходимость быстро принять решение, чтобы бизнес-процесс продвинулся дальше. С учетной системой так не получится, здесь мы должны указывать, какие документы за счет каких создаются и т.п. - это неудобно. Здесь нет четкого контекста.
2. Простота логики и разработки. Если мы ведем бизнес-процесс в учетной системе, то должны учитывать большое количество логических связей: как проводятся документы, транзакции, на что это влияет, какие дополнительные лицензии надо покупать и т.п. - хотя, казалось бы, ответственному за согласование лицу это не нужно. Но в учетной системе мы обязательно должны привязываться к объектам конфигурации либо дорабатывать их, что не очень правильно.

Вот как раз для этого и были созданы BPM-системы, в которых вся логика направлена не на расчеты, не на хранение данных, а на быстрое исполнение процесса и его контроль.

Теперь перейдем к третьему подходу и рассмотрим, как же должен быть решен этот бизнес-процесс в системе BPMS.

Процессный подход в BPMS

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

В нашем примере их будет три:

1. Создание заявки на согласование счета;
2. Проверка заявки;
3. Результат заявки:
   • если одобрено - распечатка заявки,
   • если не одобрено - сообщить об этом поставщику

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

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

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

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

Если другие системы направлены на то, чтобы операция была выполнена, то в BPMS мы сконцентрированы на действиях.

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

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

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

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

Вернемся к примеру с согласованием счета, и рассмотрим, какие возможности есть при процессном подходе:

• Разделение зон ответственности;
• Концентрация работы сотрудников на конкретных действиях;
• Оповещение пользователей об изменениях в процессах (или о необходимости внести изменения), в которых они участвуют.

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

BPMN 2.0 - это общепризнанный стандарт описания бизнес-процесса и люди, знакомые с этой нотацией, сразу поймут модель бизнес-процесса, написанную в этом формате.

Заключение

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

Еще статьи по данной теме.