Читать онлайн «Хватит платить за все! Снижение издержек в компании». Страница 13

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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