Справочник Бухгалтера

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

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

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

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

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

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

В каких ситуациях нужен проект?

Ситуация 1

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

Ситуация 2

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

Ситуация 3

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

Ситуация 4

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

Ситуация 5

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

Ситуация 6

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

Ситуация 7

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

Какие задачи решает проект?

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

Какие результаты будут достигнуты?

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

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

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

Мы привели в пример самый безобидный кейс, но принцип понятен. Чтобы вы не остались у разбитого корыта после автоматизации, мы составили пошаговый план и правила моделирования бизнес-процессов – так, как их видит команда Forward Telecom.

ВИДЫ МОДЕЛИРОВАНИЯ

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

• Функциональное. Модель бизнес-процесса состоит из диаграмм, текста и глоссария. Каждый элемент может ссылаться на другой. Основа модели – диаграммы, которые отображают последовательность функций, связанных общими объектами. Плюсы функционального моделирования в графической простоте, потому что оно базируется на двух элементах – функциональном блоке и интерфейсной дуге, которая связывает блоки между собой.
• Процессное. Ключевой принцип – отображение последовательности. Определяется цепочка совокупности бизнес-процессов, которые увеличивают конечную стоимость услуг или товаров. Процессное моделирование лежит в основе популярных нотаций IDEF3, DFD и ARIS, о которых мы поговорим позже.
• Ментальное. . Этим типом моделирования владеет каждый из нас. Под ним подразумеваются графические наброски схем в свободной форме, которые помогают структурировать и упорядочить спутанные представления о бизнес-процессах и делаются в основном «для себя».

ЭТАПЫ МОДЕЛИРОВАНИЯ

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

1. Определите роли сотрудников и зоны ответственности.
2. Определите бизнес-функции, которые выполняют сотрудники в рамках своей деятельности.
3. Соотнесите роли и бизнес-функции работников.
4. Определите порядок исполнения бизнес-функций.
5. Добавьте действия, которые проводят сотрудники в рамках бизнес-функций.
6. Добавление документы и ресурсы, используемые в процессе выполнения бизнес-функций.

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

1. Финансовый директор принимает окончательное решение об оплате счета и несет за это решение ответственность.
2. Финансовый директор должен проверить счет на наличие ошибок, определить назначение платежа и инициатора.
3. Действия, производимые финансовым директором, являются последними в цепочке перед оплатой счета.
4. Сотрудник должен получить счет, проверить его, проинформировать инициатора о принятом решении, передать счет на оплату или вернуть его для корректировки.
5. Проверка счета, взаимодействие с инициатором, взаимодействие с другими сотрудниками финансовой службы.
6. Счет на оплату в электронном или бумажном виде, электронная почта и/или информационная база для информирования инициатора и сотрудников, ответственных за оплату.

В результате моделирование бизнес-процессов должно наполнить полученные модели следующей информацией:

• Набор бизнес-функций;
• Порядок выполнения;
• Принципы контроля и управления в рамках бизнес-процесса;
• Исполнители
• Входящие и исходящие документы;
• Ресурсы;
• Документация или условия, регламентирующие выполнение бизнес-функции;
• Общая характеристика процесса.

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

НОТАЦИИ

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

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

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

2. IDEF3. Нотация из одного «семейства» с предыдущей, но с акцентом на очередность выполнения бизнес-процессов и ориентацией на нижние уровни моделирования. То самое процессное моделирование бизнес-процессов, которое легло в основу многих популярных нотаций.
3. BPMN. Отличительный признак нотации – наличие «дорожки», которая обозначает совокупность действий ответственного в рамках бизнес-процесса. Если в нем участвует несколько человек, на графике отражается взаимодействие «дорожек». С помощью нотации BPMN удобно искать «слабые места» бизнес-процессов, которые в большинстве случаев находятся на стыке работ разных исполнителей.



4. Basic Flowchart. Нотация класса workflow используется для составления алгоритма выполнения процесса. Составляющие элементы графика: событие, процесс, решение, стрелки входящей информации и стрелки «Поток объектов». Basic Flowchart больше всех похожа на блок-схему.



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

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

РЕЗУЛЬТАТЫ

На выходе вы должны получить:

1. Процессную карту бизнес-процессов компании с их взаимосвязью;
2. Диаграмму ролей сотрудников;
3. Модель «как есть» каждого бизнес-процесса.

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

Общие принципы моделирования

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

1. Принцип осуществимости. Создаваемая модель прежде всего должна обеспечивать достижение поставленных целей. Таким образом, прежде чем приступить к сбору информации об объекте, нужно четко определить границы области моделирования, цели и количественные показатели их достижения; «моделирование ради моделирования» обычно создает негативное отношение к проекту в компании, снижает лояльность руководства.

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

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

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

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

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

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

Данный текст является ознакомительным фрагментом.
Читать книгу целиком
Поделитесь на страничке

Алексей Важнов, Елена Монахова

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

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

Для модели, поясняет ученый, в общем случае характерны четыре свойства:

— уменьшенный масштаб (размер модели, точнее, ее сложность, всегда меньше, чем у оригинала. Мы сознательно вводим упрощения);

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

— работоспособность — возможность в принципе работать, как оригинал (во всяком случае, похожим образом);

— соответствие действительным свойствам оригинала (степень достоверности).

Итак, модель нужна для того, чтобы узнать что-то о моделируемой вещи.

Самое лаконичное определение звучит так: А является моделью В, если А позволяет отвечать на вопросы по поводу В.

Зачем они нужны?

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

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

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

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

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

Виды моделей

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

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

— модель финансового управления (взгляд на бизнес с точки зрения движения финансовых средств);

— маркетинговая модель (оценка влияния внешней среды — рынка — на рассматриваемый бизнес);

— модель управления производством;

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

В эти категории можно отнести и ряд других моделей. Для их построения применимы популярные на Западе концепции управления — MRP (Manufacturing Resource Planning), DRP (Distribution Resource Planning), ERP (Enterprise Resource Planning), CSRP (Customer Synchronized Resource Planning).

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

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

Кому они нужны?

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

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

Использование моделей в управлении бизнесом

Для удобства изложения материала еще раз приведем схему управления бизнесом, опубликованную в PC Week/RE, № 5/98, на c. 56, несколько детализировав ее (рис. 1).

рис.1. Место моделей и информационной системы в структуре управления фирмой

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

Кроме того, сведения об объекте поступают из одновременно применяемого набора, состоящего из трех моделей:

— стратегической (например, годовой или трехлетний финансовый план в рамках генерального плана развития);

— среднесрочной (месячное бюджетирование);

— оперативной (текущий цикл измерения, контроля и фиксации параметров бизнеса).

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

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

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

Кроме того, ИС должна помогать решению задачи прогнозирования по схеме «что, если…” в рамках оперативной модели. Сформированные по заранее определенному алгоритму наборы текущих и ожидаемых показателей системы сравниваются, после чего вырабатывается управляющее воздействие на объект (рис. 2).

рис.2. Внутренние связи в блоке управления

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

В следующей части (в № 16/98 PC Week/RE) мы поговорим о том, кто и с использованием каких инструментальных средств должен создавать модели систем управления бизнесом, в какой момент и как часто эти модели изменяются.

К Алексею Важнову, исполнительному директору компании ICS, можно обратиться по адресу: vazhnov@postman.ru., к Елене Монаховой, заместителю главного редактора PC Week/RE, — по адресу: monah@pcweek.ru.

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

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

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

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

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

Для моделирования бизнес-процессов можно использовать различные методы . Метод, или методология, моделирования включает в себя последовательность действий, которые необходимо выполнить для построения модели, т. е. процедуру моделирования, и применяемую нотацию (язык). Наиболее популярной методологией бизнес-моделирования является ARIS, но также известны Catalyst компании CSC, BusinessGenetics, SCOR (Supply \ ChainOperationsReference), POEM (ProcessOrientedEnterpriseModeling) и др. Язык моделирования имеет свой синтаксис (условные обозначения различных элементов и правила их сочетания) и семантику (правила толкования моделей и их элементов).В теории и на практике существуют различные подходы к построению и отображению моделей бизнес-процессов.

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

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

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

В период «первой волны» для моделирования бизнес-процессов используются блок-схемы, ориентированные графы, сети Петри, методологии SADT, IDEF, DFD. Блок-схемы на основе определенной в ГОСТ 19.701-90 нотации схем алгоритмов, программ, данных и систем (в англ. литературе — ANSI flowcharts) остаются и сегодня простейшим, но практически важным формальным графическим языком моделирования бизнес-процессов.

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

Таблица 1

Начало второго этапа ознаменовал выход книги М. Хаммера и Д. Чампи»Реинжиниринг корпорации: манифест революции в бизнесе», которая возродила в управленческой среде интерес к описанию и анализу бизнес-процессов с целью их радикальной перестройки — реинжиниринга. Реинжиниринг бизнес-процессов предполагает построение двух моделей бизнес-процесса: «как есть» (англ. АSIS) и «как должно быть» (англ. TOBE), а затем внедрение последней на предприятии.

Как следующий шаг в автоматизации бизнес-процессов в 1990-х гг. появляются системы управления потоками работ WfMS (WorkflowManagementSystem) второго поколения, предназначенные для маршрутизации потоков работ любого типа в рамках бизнес-процессов компании. Эти системы снабжены средой разработчика, которая теоретически может использоваться для моделирования различных нестандартных бизнес-процессов, однако на практике в большинстве случаев внедрение нового или изменение имеющегося процесса требовало привлечения труда программистов. Еще более
ограниченные возможности по настройке и изменению процессов предоставляли поддерживающие управление потоками работ системы планирования ресурсов предприятия ERP (EnterpriseResourcePlanning). Внесение любых существенных изменений в бизнес- процесс превращалось в весьма дорогостоящий и долгосрочный проект по проектированию и разработке программного обеспечения, а модели бизнес-процессов, построенные аналитиками, использовались для более четкой формулировки требований, которые затем передавались программистам. В качестве примера методологии и средства автоматизации бизнес-процессов второго поколения можно назвать соответственно ARIS и распространенную ERP-систему SAP R/3.

Негибкость моделей и средств автоматизации, их неспособность обеспечить оперативное реагирование на постоянные изменения в бизнес-среде стали основными недостатками систем «второй волны», стимулировавшими разработку в начале 2000-х гг. методологий следующего — третьего — поколения. Манифестом «третьей волны» в моделировании бизнес-процессов можно по праву назвать книгу Г. Смита и П. Фингара «Управление бизнес-процессами: третья волна». На смену радикальному реинжинирингу приходит системное и «плавное» управление. Изменчивость бизнес-процессов, возможность их корректировки в ответ на изменения в бизнесе становятся главным критерием использования информационных технологий как средства, позволяющего получить преимущества на рынке.

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

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

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

— OASIS (OrganizationfortheAdvancementofStructuredInformationStandards, основанав 1993 г.) выпускаетспецификацииebXMLиBPEL, атакжеразличныестандартыдляэлектронногобизнесанабазеXMLивеб-сервисов;

— OMG (ObjectManagementGroup, осн. в 1989 г.) выпускаетстандартыBPMNиUML, атакжеMDAиCORBA;

— WfMC (WorkflowManagementCoalition, осн. в 1993 г.) выпускает стандарты Wf-XML и XPDL.

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

Развитие сети Интернет послужило толчком к созданию новых методов и технологий в области электронного обмена данными. Одним из наиболее удачных методов электронного обмена является появившаяся в 1998 г. методология консорциума RosettaNet. Данная технология описывает открытую платформу электронного взаимодействия, основанного на стандарте XML, и позволяет сторонам, участвующим во взаимодействии, обмениваться бизнес-информацией через Интернет. Первоначально стандарт был разработан для индустрии высоких технологий (информационные технологии и электроника), однако предложенный подход послужил основой механизмов взаимодействия предприятий и других отраслей. В рамках методологии RosettaNet разработаны стандарты более сотни процессов бизнес-взаимодействия между различными компаниями или подразделениями внутри одного предприятия. Эти стандартизованные процессы получили название процессов интерфейса взаимодействия с партнером (PartnerInterfaceProcess, PIP) и специфицируют транзакции между двумя бизнес-системами в форме диалога на основе стандарта XML.

Еще одной современной технологией автоматизации межкорпоративного взаимодействия является ebXML (ElectronicBusinessusingextensibleMarkupLanguage,ИСО 15000). Работа над технологией ebXML началась в 1999 г. по инициативе СЕФАКТ ООН (Центр ООН по поддержке процедур и практики управления, коммерции и транспорта) и консорциума OASIS, накопившего большой опыт в сфере организации ведения бизнеса в Интернете на базе XML. Целью данного проекта является разработка инфраструктуры электронного бизнеса — полного набора спецификаций, позволяющего осуществлять бизнес-взаимодействия через единообразную XML-среду. С появлением ebXML компании получили стандартизованный де-факто метод обмена данными и бизнес-сообщениями, а также единые условия информационной поддержки торговых отношений.

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

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

— Определение результата бизнес-процесса и оценка его значения для бизнеса .

— Определение набора действий, составляющих бизнес-процесс.

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

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

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

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

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

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

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

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

— Описание деятельности предприятия в целом.

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

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

Список литературы

3. Гусарова О.М. Информационно-аналитические технологии моделирования деятельности организаций Смоленского региона. — Смоленск: Свиток, 2013. — 100 с.

5. Гусарова О.М. Моделирование в принятии управленческих решений // Наука и образование: проблемы и перспективы развития: сборник научных трудов по материалам Международной научно-практической конференции. — Тамбов: Юком, 2014. — С. 41-42.

6. Гусарова О.М. Проблемы интеграции теории и практики моделирования результатов бизнеса // Экономика и образование: Вызовы и поиск решений: сборник научных трудов по материалам II Всероссийской (заочной) научно-практической конференции (Ярославль, 15 апреля 2014 г.) — Ярославль: Канцлер, 2014. — С.78-82.

8. Гусарова О.М. Методы и модели прогнозирования деятельности корпоративных систем // Теоретические и прикладные вопросы образования и науки: сборник научных трудов по материалам Международной научно-практической конференции. — Тамбов: Юком, 2014. — С. 48-49.
9. Гусарова О.М. Компьютерные технологии моделирования социально-экономических процессов // Экономический рост и конкурентоспособность России: тенденции, проблемы и стратегические приоритеты: сборник научных статей по материалам Международной научно-практической конференции. — М.: Юнити-Дана, 2012. — С. 102-104.
10. Репин В.В. Бизнес-процессы. Моделирование, внедрение, управление. — М.: Манн, Иванов и Фербер, 2013. — 512 с.