Концепция управления бизнес процессами 3 Процесс и его компоненты 4 Состав типовых бизнес-процессов в деятельности компании

Вид материалаРегламент

Содержание


Пример процессов SCOR-модели
Бенчмаркинг (Benchmarking) процессов
Сравнительный анализ
Основные процессы
Вспомогательные процессы
Процессы управления и развития
Типовые процессы небольшой организации
Основные процессы
Процессы развития
Процессы верхнего уровня
3. Сущность моделирования бизнеса
Фрагмент модели «Офисный процесс», выполненной в среде ARIS
Если описание требует больших затрат и ресурсов
Если компания собирается делать это не из реальных потребностей
Если невозможно получить реальную информацию
3.1 Понятие о моделирования и подходы к моделированию
Последовательность описания бизнес-процессов
Схема описания процессов в методологии ARIS
Function Allocation Diagram (FAD)
Метод моделирования включает язык и процесс моделирования. Процесс
...
Полное содержание
Подобный материал:
1   2   3   4   5   6   7   8   9   10

Пример процессов SCOR-модели


В области предоставления телекоммуникационных услуг получили широкую известность модели, разработанные компаниями SAP, HP, a также ассоциацией TeleManagement Forum. Референтная модель Telecom Operations Model (ТОМ) — общеотраслевая модель процессов телекоммуникационной отрасли. ТОМ предлагает универсальную (в смысле независимости от конкретной организации, технологии или содержания услуг) классификацию процессов, с одной стороны, по уровням управления, а с другой — по определенным областям деятельности, которые правильнее всего определить как функциональные.

В качестве «сквозных» процессов модель ТОМ рассматривает:
  • исполнение услуги (правильно и вовремя доставить то, что заказано);
  • обеспечение услуги (своевременное и оперативное разрешение проблем, обнаруженных в сети или клиентами, отслеживание, отчетность, управление и улучшение всех аспектов услуги, которые составляют понятие «качество обслуживания» и т. п.);
  • биллинг (своевременная и точная выписка счетов, компетентный и внимательный ответ на запросы по поводу оплаты, включая своевременную корректировку счетов и сбор платы).

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

Для торгово-промышленных компаний Международная бенчмаркинговая палата Американского Центра производительности и качества (American Productivity & Quality Center) разработала перечень типовых бизнес-процессов предприятия в виде структуры классификации процессов (Process Classification Framework), в которую входит 13 процессов, что дало название эталонной модели как «13-процессная эталонная модель».

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

Сравнительный анализ - сравнение некоторых наборов показателей схожих элементов.
Все процессы разделены но основные и вспомогательные, каждый из которых иерархически детализирован на 2-3 уровня. Соответственно, имея инструментарий моделирования, это описание процессов можно взять за основу при создании графической модели. Тринадцатипроцессная модель не показывает логику выполнения процессов, в ней присутствует только структура, которая распределяет процессы по тринадцати основным направлениям:
  1. Изучение рынка и потребителей;
  2. Разработка видения и стратегии;
  3. Разработка продукции и услуг;
  4. Маркетинг и продажи;
  5. Производство и поставка продуктов и услуг (сервисные компании);
  6. Производство и поставка продуктов и услуг (производственные компании);
  7. Выставление потребителям платежных требований и сервис- услуги;
  8. Развитие и управление кадрами (профессиональное и карьерное);
  9. Управление ИТ - ресурсами и технологиями;
  10. Управление финансовыми и материальными ресурсами;
  11. Реализация программы управления охраной внешней средой;
  12. Управление внешними связями;
  13. Управление улучшениями и изменениями.


2.5 Пример описания бизнес процессов


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

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

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

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

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

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

Процессы управления и развития существуют, соответственно, для управления и развития основных процессов. Обычно принимают следующий принцип моделирования, который состоит в том, что основных процессов не должно быть более 7±2, а вспомогательных, процессов управления, развития — не более 4±2 каждого типа. Такое ограничение связано с тем, что человек не может эффективно воспринимать, а значит и руководить более чем 7-9 объектами управления одновременно. Общее число выбранных бизнес-процессов не должно превышать 15-20, максимум 25.

Типовые процессы небольшой организации


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

Управление финансами
Стратегическое планирование

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

Снабжение (закупки продукции)
Складирование и хранение
Сбыт продукции (продажа)
Обработка заказа клиента
Транспортировка

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

Маркетинг

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

Управление персоналом
Управление информационными технологиями


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


Процессы верхнего уровня


Ниже приводим детализацию некоторых процессов.


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

 



3. Сущность моделирования бизнеса


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

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

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

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

Моделирование имеет богатую историю во всех инженерных дисциплинах. Длительный опыт его использования позволил сформулировать четыре основных принципа.
  1. Выбор модели оказывает определяющее влияние на подход к решению проблемы и на то, как будет выглядеть это решение. Иначе говоря, подходите к выбору модели вдумчиво. Правильно выбранная модель высветит самые коварные проблемы разработки и позволит проникнуть в самую суть задачи, что при ином подходе было бы попросту невозможно. Неправильная модель заведет вас в тупик, поскольку внимание будет заостряться на несущественных вопросах.
  2. Каждая модель может быть воплощена с разной степенью абстракции. Для аналитика или конечного пользователя наибольший интерес представляет вопрос "что", а для разработчика - вопрос "как". В обоих случаях необходима возможность рассматривать систему на разных уровнях детализации в разное время.
  3. Лучшие модели - те, что ближе к реальности, т.к. «ахиллесова пята» структурного анализа - несоответствие принятой в нем модели и модели системного проекта. Если этот разрыв не будет устранен, то поведение созданной системы с течением времени начнет все больше отличаться от задуманного. При объектно-ориентированном подходе можно объединить все почти независимые представления системы в единое семантическое целое[4].
  4. Нельзя ограничиваться созданием только одной модели. Наилучший подход при разработке любой нетривиальной системы - использовать совокупность нескольких моделей, почти независимых друг от друга.

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

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

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

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

Термин “моделирование” применяется в двух смыслах: как процесс построения модели системы и как процесс исследования модели ее функционирования. Также выделяют “имитационное моделирование”, которое поддерживается некоторыми инструментальными средствами (например, ARIS): скажем, можно запустить имитационную модель событийной цепочки процесса (еЕРС) для анализа его особенностей: затрат времени на выполнение каждой функции, стоимостных характеристик, занятости исполнителей и т.п.[6]

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

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

В моделировании бизнеса этот способ также применяется: например, инструментарий ARIS и VISIO дает возможность представлять одни и те же объекты в виде символического и пиктографического (ассоциативного) изображения (образа): сравните рисунки.


Фрагмент модели «Офисный процесс», выполненной в среде ARIS



Фрагмент модели «Событийная цепочка процесса (еЕРС),
выполненной в среде ARIS



В каких случаях нет необходимости в описании бизнес-процессов?

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

 



3.1 Понятие о моделирования и подходы к моделированию


При детальном описании бизнес-процессов нужно получить ответы на следующие основные вопросы:
  • Каковы «вход» и «выход» процесса?
  • Из каких процедур состоит процесс?
  • Кто выполняет каждую процедуру?
  • Каков результат выполнения процедур?
  • Кто получатель результата?
  • Что происходит после получения результата?

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

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

Последовательность описания бизнес-процессов такова: вначале описываются процессы верхнего уровня, т.е. наиболее широкое обобщение. Как правило, для этого в разных инструментариях используется модель типа VAD – Value Added Diagram – Цепочка добавленной стоимости (иногда ее называют Value Added Chain Diagram). На рисунке показана схема описания бизнес-процессов.


Схема описания процессов в методологии ARIS


После описания верхнего уровня можно перейти к следующему уровню детализации: сценариев процессов. Что такое сценарии? Возьмем один процесс: приема сотрудников на работу. Сотрудники могут быть двух типов: штатные (сценарий 1) и внештатные (работающие по договору, сценарий 2). Соответственно, сам процесс будет идти по-разному в зависимости от этих сценариев. Специальная модель выбора процесса при нескольких сценариях - Process Selection Diagram – Диаграмма выбора процесса.

Однако, эти уровни описания не дают представления о логике выполнения тех или иных процедур, не показывают элементы оргструктуры, ресурсы и т.п. Для этих случаев предусмотрена модель еЕРС – Расширенная событийная цепочка процесса, extended Event Process Chain, которая может описать процесс уровня рабочего места на уровне событий-функций. В этой модели предусмотрено множество объектов для точного отображения всех аспектов процесса.

И наконец, самой последней по степени детализации является модель окружения функции Function Allocation Diagram (FAD) , которая позволяет подробно рассмотреть одну функцию из модели еЕРС на предмет ресурсов, местоположения, документов, информационных систем, оборудования, цели выполнения и прочее.

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

Часто описание предприятия начинается с рассмотрения ее структуры. Это наиболее привычный метод анализа, однако, если мы говорим о процессном подходе, то более адекватно сначала подходить к описанию процессов. «Структура отражает наиболее существенные, устойчивые связи между объектами системы и их группами, которые обеспечивают основные свойства системы. Иначе говоря, структура – это форма организации системы, скелет, костяк существования системы. Вместе с тем структура системы может претерпевать определенные изменения в зависимости от различных факторов (причин)» [2].

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

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

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

Для моделирования можно использовать различные методы. Метод моделирования включает язык и процесс моделирования. Процесс моделирования – это последовательность действий (операций, функций), которые необходимо выполнить для построения модели. Язык моделирования – это графическая нотация, используемая методом для построения модели. Нотация отражает синтаксис языка моделирования, т. е. содержит множество графических объектов, используемых при построении моделей (например, синтаксис русского языка образуют 33 буквы и различные знаки препинания). Модель – это построенный образ (заместитель) оригинала. Различают двухмерные (схемы) и трехмерные (макеты) модели [6].

 


3.2 Программы и инструментальные системы для моделирования бизнеса

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