Введение в реинжиниринг бизнес-процессов

1.

Введение

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

1.1 Бизнес-процесс

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

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

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

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

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

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

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

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

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

Итак, с внешними и внутренними потребителями результатов бизнес-процессов разобрались. А как можно классифицировать бизнес-процессы?

Бизнес-процессы разделяются на следующие классы:

· Основные процессы;

· Сопутствующие процессы;

· Вспомогательные процессы;

· Обеспечивающие процессы;

· Процессы управления;

· Процессы развития.

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

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

Вспомогательные бизнес-процессы — процессы, предназначенные для обеспечения выполнения основных БП и поддержания их специфических черт. Так, для ТЭЦ или ГЭС вспомогательным бизнес-процессом является процесс ремонта производственного оборудования.

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

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

Бизнес-процессы развития — это процессы совершенствования производимого товара или услуги, технологий, модификации оборудования. Например, это проведение НИОКР в машиностроении, процесс технического перевооружения в электроэнергетике и т. п.

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

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

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

1.2 Реинжиниринг и усовершенствование бизнес-процессов

Реинжиниринг бизнес-процессов — методология, разработанная для проведения усовершенствования бизнес-процессов организации, а также сам процесс проведения такого усовершенствования.

Формально термин «реинжиниринг» определен Хаммером, Давенпортом и Шортом в двух статьях в 1990 году. Термин получил широкую известность в 1993 году после публикации книги Хаммера и Чампи «Реинжиниринг корпораций — манифест революции в бизнесе».

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

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

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

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

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

· внедрение новой корпоративной информационной системы;

· слияние, разделение, либо иное преобразование организаций;

· необходимость сертификации в системе качества по стандартам ИСО серии 9000;

· необходимость подготовки к финансовому аудиту;

· необходимость реагирования на требования, предъявляемые потребителями и государством;

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

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

1.3 Общая процедура проведения реорганизации бизнес-процессов

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

· Постановка целей и задач реинжиниринга бизнес-процессов, а также критериев оценки БП;

· Аудит текущего состояния бизнес-процессов;

o проведение обследования бизнес-процессов;

o описание и моделирование бизнес-процессов;

o выявление «узких мест» ;

· Формирование предложений по изменению бизнес-процессов (ряд альтернативных путей);

· Выбор альтернатив изменения бизнес-процессов (по ранее выбранному критерию);

· Внедрение новых бизнес-процессов;

· Дальнейшее совершенствование бизнес-процессов.

1.4 Некоторые определения системного анализа

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

Необходимо напомнить некоторые определения из этой области знаний.

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

Иерархическая система — система, элементы которой являются системами (системы низшего ранга).

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

Цель — желаемое состояние системы или желаемый результат ее поведения. Цель может быть сформулирована только с точки зрения вышестоящей системы.

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

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

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

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

Синтез — логический прием, с помощью которого отдельные элементы соединяются в целое

Разнообразие системы — количество возможных её состояний.

Сложная система — система, разнообразие которой велико, но ещё позволяет описать её детерминированной моделью.

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

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

2. Определение целей, задач и критериев для реорганизации бизнес-процессов

2.1 Техническое задание на реорганизацию бизнес-процессов

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

Поэтому прежде всего необходимо однозначно и четко сформулировать цели и задачи проекта проведения реорганизации бизнес-процессов предприятия или организации. Как это сделать? Надо лишь четко ответить на ряд вопросов, а именно:

· Для решения какой проблемы (каких проблем) мы хотим реорганизовать наши бизнес-процессы?

· Можем ли мы решить данные проблемы, не прибегая к реорганизации бизнес-процессов? Какие есть альтернативы решению наших проблем?

· Какие именно бизнес-процессы необходимо реорганизовать?

· Что мы хотим добиться в результате проведения проекта реорганизации? Какое должно быть целевое состояние нашей системы? Какие ожидаются результаты?

· Какие основные задачи стоят перед нами при выполнении данного проекта?

· Какие ресурсы будут привлечены для выполнения проекта? Достаточны ли они?

· Сколько времени отводится на выполнение проекта?

· Кто отвечает за выполнение проекта?

· Есть ли какие либо ограничения либо дополнительные условия, связанные с реорганизацией?

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

Документ в сжатой форме содержит все ключевые моменты проекта реорганизации:

· Предпосылки к проведению проекта;

· Целевое состояние организации;

· Задачи (как декомпозицию цели проекта);

· Ресурсы;

· Сроки;

· Ответственные лица.

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

2.2 Критерии

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

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

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

3. Проведение обследования бизнес-процессов предприятия

3.1 Цели и задачи проведения обследования

бизнес реинжиниринг обследование

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

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

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

Реализация обследования предполагает наличие методики проведения обследования, которая включает в себя:

· программу проведения обследования;

· объекты и единицы анализа;

· степень детализации анализа;

· методы анализа и сбора данных;

· правила обработки и характер использования результатов.

3.2 Методы проведения обследования

Методы обследования, то есть способ получения необходимых данных, определяется целями и задачами изучения бизнес-процессов и системы управления предприятием. В зависимости от объекта исследования выделяют следующие методы обследования:

· Процедурно-ориентированный метод — объектом исследования являются процедуры обработки информации.

· Предметно-ориентированный метод изучает элементы информации на предприятии.

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

· Метод анализа выходов изучает зависимость управленческих решений от начальных условий.

· Метод реакций на воздействие изучает реакцию системы на какие-либо воздействия.

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

3.3 Методы сбора данных при обследовании

Основными методами сбора данных при обследовании являются:

· Анкетирование;

· Интервьюирование;

· Сбор документов;

· Наблюдение.

Анкетирование.

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

Анкета должна быть составлена таким образом, чтобы ее заполнение заняло не более 1 часа у анкетируемого лица, в противном случае внимание рассеивается и человек отвечает на вопросы анкеты по принципу «лишь бы отписаться», либо вообще игнорирует многие вопросы. Вопросы анкеты должны быть таковы, чтобы:

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

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

· Предполагаемый ответ на вопрос был кратким по объему, но достаточно полным по содержанию;

· По возможности, в зависимости от специфики вопроса, следует предлагать выбрать один или несколько заранее подготовленных вариантов ответа.

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

Интервьюирование

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

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

Типичными ошибками являются:

· Переход беседы на темы, не относящиеся к цели опроса;

· Навязывание собственных вариантов ответа собеседнику;

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

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

Сбор документов

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

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

Наблюдение

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

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

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

3.4 Организация проведения обследования

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

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

Таким образом, в ходе экспресс-обследования выясняются и уточняются следующие сведения о предприятии:

· Наименование и организационно форма предприятия;

· Наименование и организационно-правовая форма предприятий, входящих в тот же холдинг, и характер взаимодействия с ними (разумеется, если предприятие входит в тот или иной холдинг);

· Основные виды продукции, работ и услуг предприятия, а также примерную долю, которую они вносят в общую выручку предприятия (в процентах);

· Организационная структура и, если это необходимо, штатное расписание предприятия;

· Формулировка и степень важности проблем, которые стоят перед предприятием, и которые необходимо решить в ходе реинжиниринга.

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

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

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

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

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

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

4. Описание и моделирование бизнес-процессов

4.1 Способы представления информации о БП

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

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

Основные способы описания бизнес-процессов следующие:

· текстовый (естественный язык);

· текстовый (формальное описание);

· графический (свободная нотация);

· графический (формальная нотация);

· комбинированный.

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

Текстовое описание формализованным языком — это описание БП с помощью заранее определенных словесных конструкций и оборотов, подобно словесному описанию алгоритма программы (ЕСЛИ … ТО… ИНАЧЕ… и т. п.). Кроме того, при описании формализованным языком уже существует определенный глоссарий терминов предметной области, что немаловажно для правильного понимания процесса. Недостатки данного способа представления информации — сравнительно большой объем, что может затруднить понимание процесса.

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

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

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

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

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

4.2 Стандарты графического описания БП

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

· Семейство стандартов IDEF (в частности, IDEF0, DFD, IDEF3);

· Семейство стандартов ARIS (в частности, нотация eEPC);

· Семейство стандартов UML (Usecase diagram, activity diagram).

Каждое из этих семейств стандартов представляет собой определенную методологию, и реализовано рядом программных продуктов (CASE-средств). Наиболее популярное ПО, реализующее ту или иную методологию, представлено в таблице ниже.

Таблица 1

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

Кроме этого, на практике часто встречаются модели БП, подготовленные с использованием шаблона Audit diagram в программе MS Visio.

Семейство стандартов IDEF

Стандарт моделирования бизнес-процессов IDEF0 был принят в качестве такового в 1981 году. Исторически он возник из стандарта SADT (Structured Analysis and Design Teqnique), активно применявшегося с конца 60-х годов, в частности, Министерством обороны США. IDEF является аббревиатурой от ICAM DEFinition. ICAM — Integrated Computer Aided Manufacturing.

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

· IDEF0 — стандарт описания бизнес-процессов;

· DFD — диаграмма потока данных (DataFlow Diagram);

· IDEF3 — стандарт моделирования потока работ (workflow).

Семейство стандартов ARIS

ARIS расшифровывается как Arhitecture of Integrated Information Systems (архитектура интегрированных информационных систем). В методологию ARIS входит пять типов представлений моделей:

· Организационные модели, описывающие иерархическую структуру системы: иерархию организационных подразделений, должностей, полномочий конкретных лиц и т. д.;

· Функциональные модели, описывающие функции (процессы, операции), выполняемые в организации;

· Информационные модели (модели данных), отражающие структуру информации, необходимой для реализации всей совокупности функций системы;

· Модели процессов/управления, представляющие комплексный взгляд на реализацию деловых процессов в рамках системы и объединяющие вместе другие модели;

· Модели входов и выходов, описывающие потоки материальных и нематериальных входов и выходов процедур, включая, в частности, потоки денежных средств.

В каждом из этих типов моделей есть ряд нотаций, отличающихся методами моделирования, и число этих нотаций довольно велико. В частности, ARIS Toolset поддерживает ряд нотаций языка моделирования UML (Unified Modeling Language).

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

Нотация ARIS eEPC расшифровывается следующим образом: Extended Event Driven Process Chain — расширенная нотация описания цепочки процесса, управляемого событиями. Нотация разработана специалистами компании IDS Scheer AG (Германия), в частности профессором Шеером. В таблице ниже приводятся основные используемые в рамках нотации графические объекты.

Таблица 2

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

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

На рисунке видно, что связи между объектами имеют определенный смысл и отражают последовательность выполнения функций в рамках процесса. Стрелка, соединяющая Событие 1 и Функцию 1 «активирует» или инициирует выполнение Функции 1. Функция 1 «создает» Событие 2, за которым следует символ логического «И», «запускающий» выполнение Функций 2 и 3. Нотация eEPC построена на определенных семантических правилах описания:

· Каждая функция должна быть инициирована событием и должна завершаться событием;

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

Кроме этих правил, существуют и другие важные правила формирования моделей в ARIS. Эти правила можно изучить при помощи методического материала «Методы ARIS», который устанавливается на компьютер одновременно с демо-версией продукта.

На рисунке ниже показано применение различных объектов ARIS при создании модели бизнес-процесса.

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

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

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

Семейство стандартов UML

Аббревиатура UML расшифровывается как Unified Modeling Language (унифицированный язык моделирования).

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

Язык UML был создан в компании Rational одним из ведущих идеологов объектно — ориентированного подхода к программированию Гради Бучем (Grady Booch), совместно с Джимом Рамбо (Jim Rumbaugh) и Иваром Джекобсоном (lvar Jacobson) в 1994 году.

UML включает в себя ряд типов диаграмм, некоторые из которых могут быть использованы для моделирования бизнес-процессов. В частности, это диаграмма прецедентов (Use-case diagram) и диаграмма действий (Activity Diagram).

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

Диаграмма прецедентов состоит из прецедентов (use-case) — типичных взаимодействий между пользователем и компьютерной системой — и субъектов (actor) — ролей, которые пользователи играют относительно системы. Также на ней могут быть указаны отношения между прецедентами: связь расширения (extends) и связь использования (uses).

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

К вопросу о выборе нотации моделирования

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

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

4.3 Основы IDEF0

В основе методологии IDEF0 лежат три основных понятия:

· Функциональный блок (Activity Box);

· Интерфейсная дуга (Arrow);

· Декомпозиция (Decomposition);

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

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

· Верхняя сторона имеет значение «Управление» (Control);

· Левая сторона имеет значение «Вход» (Input);

· Правая сторона имеет значение «Выход» (Output);

· Нижняя сторона имеет значение «Механизм» (Mechanism).

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

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

Графическим отображением интерфейсной дуги является однонаправленная стрелка. Каждая интерфейсная дуга должна иметь свое уникальное наименование (Arrow Label). По требованию стандарта, наименование должно быть оборотом существительного.

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

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

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

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

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

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

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

Обязательное наличие управляющих интерфейсных дуг является одним из главных отличий стандарта IDEF0 от других методологий классов DFD (Data Flow Diagram) и WFD (Work Flow Diagram).

Часто бывают случаи, когда отдельные интерфейсные дуги не имеет смысла продолжать рассматривать в дочерних диаграммах ниже какого-то определенного уровня в иерархии, или наоборот — отдельные дуги не имеют практического смысла выше какого-то уровня. Например, интерфейсную дугу, изображающую «деталь» на входе в функциональный блок «Обработать на токарном станке» не имеет смысла отражать на диаграммах более высоких уровней — это будет только перегружать диаграммы и делать их сложными для восприятия. С другой стороны, случается необходимость избавиться от отдельных «концептуальных» интерфейсных дуг и не детализировать их глубже некоторого уровня. Для решения подобных задач в стандарте IDEF0 предусмотрено понятие туннелирования. Обозначение «туннеля» (Arrow Tunnel) в виде двух круглых скобок вокруг начала интерфейсной дуги обозначает, что эта дуга не была унаследована от функционального родительского блока и появилась (из «туннеля») только на этой диаграмме. В свою очередь, такое же обозначение вокруг конца (стрелки) интерфейсной дуги в непосредственной близи от блока — приёмника означает тот факт, что в дочерней по отношению к этому блоку диаграмме эта дуга отображаться и рассматриваться не будет. Чаще всего бывает, что отдельные объекты и соответствующие им интерфейсные дуги не рассматриваются на некоторых промежуточных уровнях иерархии — в таком случае, они сначала «погружаются в туннель», а затем, при необходимости «возвращаются из туннеля».

Третьим основным понятием стандарта IDEF0 является декомпозиция (Decomposition). Принцип декомпозиции применяется при разбиении сложного процесса на составляющие его функции. При этом уровень детализации процесса определяется непосредственно разработчиком модели.

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

Модель IDEF0 всегда начинается с представления системы как единого целого — одного функционального блока с интерфейсными дугами, простирающимися за пределы рассматриваемой области. Такая диаграмма с одним функциональным блоком называется контекстной диаграммой, и обозначается идентификатором «А-0».

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

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

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

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

Очень важно при построении модели четко обозначить цель (purpose) и точку зрения (viewpoint) модели.

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