Подписаться
Рубрикатор
Полный список
Развитие организации
Управление процессами
Моделирование процессов
Регламентация процессов
Автоматизация процессов
Бережливое производство
Менеджмент качества
Управление проектами
Дайджесты по Business Studio

Облако терминов
12-процессная модель 4PL ACM Activity diagram AQPC ARIS ARIS 9 ARIS eEPC Balanced Scorecard Big Data & Analytic BMPN BPA BPEL BPM BPM accelerator BPM CBOK BPM-система BPM-системы BPMN BPMS BPR BPWin BS Portal BSC Business Intelligence Business Performance Management Business Performance Management (BPM) Business Process Management Business Process Management Systems Business Process Manager Business Rules Business Studio Business Studio 3.6 Business Studio 4 Business Studio 4.0 Business Studio Portal CA ERwin Data Modeler Case Management Casewise Casewise Corporate Modeler CFFC Corporate Modeler CPM CRM Decision Management DFD Digital Directum

Опрос

Вы используете

Библиотека

09.01.2012 16:51
  от автора
  Репин

Как создать архитектуру бизнес-процессов компании? Часть 1

Оценки за материал: 4.50 (4)

В статье В.В. Репина рассматриваются различные подходы к разработке архитектуры (системы) бизнес-процессов компании. Приводится оценка «плюсов» и «минусов». Раскрываются важные практические аспекты построения системы процессов организации. Статья написана на основе опыта выполнения проектов для российских компаний (в 2010-2011 годах В.В. Репин принял участие в 8 проектах по разработке системы процессов).

Часть 1.
Цели построения архитектуры бизнес-процессов компании

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

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

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

Пример 2. В одной из крупных частных компаний (производитель снеков) был реализован проект по созданию архитектуры бизнес-процессов. Частично был выполнен так называемый «маппинг» с APQC – сравнение между собой двух моделей процессов за счет наложения одной на другую. Цели разработки системы процессов, согласованные руководством компании, включали следующие пункты:
• разработать уникальную процессную модель «ХХХ», которая бы за счет наличия четких связей с моделями APQC, CBM, SAP, DocsVision, СМК и реестром нормативных документов компании обеспечивала бы возможность:
- осуществлять расширение бизнеса (как в России, так в странах СНГ) за счет передачи знаний о процессах, используемых средствах автоматизации и соответствующих регламентирующих документах;
- системным образом осуществлять описание и регламентацию бизнес-процессов компании с использованием системы Business Studio 3.6.;
- создавать систему управления знаниями о деятельности компании.
Одна из неформальных целей разработки системы процессов заключалась в снижении зависимости от конкретных личностей – их субъективного видения состава и границ процессов, которые целесообразно выполнять для поддержания стабильного состояния и развития бизнеса.


Пример 3. Компания средняя по оборотам, но небольшая по численности. Разработка системы процессов потребовалась руководству для обеспечения «прозрачности» деятельности при условии активного роста бизнеса. Комплексная процессная модель (система процессов) позволила руководству по-новому взглянуть на модель бизнеса организации, усилить и реорганизовать ключевые направления деятельности компании.

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

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

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


Определение системы процессов компании

Что же представляет собой (система) процессов компании? Как правило, это иерархический справочник процессов следующего вида:

1. Процессная категория (1-й уровень).
1.1. Процессная группа (2-й уровень).
1.1.1. Процесс (3-й уровень).
1.1.1.1. Операционный процесс (4-й уровень).
1.1.1.1.1.Операция (5-й уровень).
1.1.1.1.1.1.Транзакция (6-й уровень).

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

После того, как система процессов в виде иерархического справочника построена, при необходимости могут быть созданы модели деятельности в виде графических схем. На уровне 1-3 целесообразно использовать структурные типы моделей (например, IDEF0). С уровня 4 (для небольших компаний – с уровня 3), как правило, описание выполняют при помощи схем в формате Work Flow. Удобным способом их визуального представления являются кросс-функциональные схемы, содержащие дорожки. На каждой дорожке указываются операции, выполняемые подразделениями/сотрудниками/бизнес-ролями. Пример: «Начальник отдела продаж» - сотрудник, «Инициатор договора» - бизнес-роль.

Заметим, что построение системы процессов компании и «тотальное» описание всех процессов – не одно и тоже. Система процессов – это иерархический справочник процессов со связями на операционном уровне (входы/выходы) и указанием ответственности. Для компании среднего размера можно разработать систему процессов за 2-3 месяца, в то время как описание ВСЕХ процессов на операционном уровне может занять несколько лет (в зависимости от количества выделенных ресурсов), что практически нецелесообразно.

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

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

Таблица 1. Определения систем процессов.


Технически, для описания системы процессов компании можно использовать MS Excel (автору известны примеры крупных компаний, которые поддерживают репозиторий процессов в этой программе). Удобно показывать процессные категории на отдельных листах. Примером рассматриваемого представления является модель APQC. Модель процессов в MS Excel в дальнейшем переводится (импортируется) в соответствующий программный инструмент, например, в среду моделирования бизнес-процессов. Хотя «автоматизированный репозиторий бизнес-процессов» компании может быть реализован и другими программными средствами.

В качестве примера приведем фрагмент системы процессов некоторой небольшой организации:

Таб. 2. Фрагмент системы процессов.

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

  1. структурный подход;
  2. продуктовый подход;
  3. «блюдо» спагетти;
  4. CBM IBM (Component Business Model компании IBM);
  5. методика построения системы процессов на основе анализа модели цепочек создания ценности (ЦСЦ);
  6. смешанные подходы.
Рассмотрим каждый из указанных подходов более подробно.

Структурный подход к построению системы процессов компании

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

Важно отметить, однако, что 40-90% операционных процессов (в зависимости от степени «проектной» ориентированности организации) не являются «сквозными». Другими словами, их нецелесообразно определять в качестве «сквозных», т.к. они на 100% выполняются внутри соответствующих подразделений.

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

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

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

Таб.3. Фрагмент системы процессов из категории «Инженерно-техническое обеспечение»


Показанные в таб. 3. процессы практически все выполняются в Отделе главного механика. Только несколько процессов связаны с межфункциональным взаимодействием, например это процесс «8.2.7. Закупка ЗИП и инструмента для ремонта механического оборудования». В таб. 4. «сквозные» процессы выделены курсивом. В данном случае, «межфункциональность» процессов явно видна из состава его участников (Начальник производства, Начальник склада, технолог не подчиняются Главному механику).

В таб. 4. Показан фрагмент системы процессов другой компании. Все процессы, за исключением 6.4.5. не могут быт названы «сквозными». Они практически полностью выполняются силами сотрудников лаборатории. Между процессами 6.4.1. – 6.4.4. существует взаимодействие, но все они выполняются в одном подразделении. Поэтому в данном случае структурный метод построения системы процессов «работает» вполне нормально.

Таб.4. Фрагмент системы процессов из категории «Управление технологией и контроль качества»


Может возникнуть вопрос, по каким принципам выделяются процессы внутри структурного подразделения? Как правило, принимают во внимание на следующие моменты:

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

      
Продуктовый подход к построению системы процессов

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

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

1. Основные процессы.
1.1. Обслуживание физических лиц.
1.1.1. Расчетно-кассовое обслуживание физических лиц.
1.1.1.1. Текущие счета физических лиц.
1.1.1.1.1. Открытие текущего счета для физического лица.
1.1.1.1.2. Прием взносов на счет.
1.1.1.1.3. Проведение выплат со счета.
1.1.1.1.4. Взимание комиссии со счета.
1.1.1.1.5. Оформление доверенности на распоряжение счетом.
1.1.1.1.6. Оформление доверенности на распоряжение счетом.
1.1.1.2. Расчетное обслуживание.
1.1.1.3. Кассовое обслуживание.
1.1.1.4. Валютный контроль и валютные операции.
1.1.1.5. Денежные переводы по системам.
1.1.2. Вклады.
1.1.3. Кредитование физических лиц.
1.1.4. Банковские карты для физических лиц.
1.1.5. Индивидуальные банковские ячейки (сейфы) для физических лиц.
1.1.6. …
1.2. Обслуживание юридических лиц.
1.3. Работа на финансовых и межбанковских рынках.
2. Вспомогательные процессы.


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

  • большое количество уровней иерархии справочника процессов («реальные» операции процессов появляются только на 6 уровне иерархии!);
  • не выделяются «сквозные» процессы;
  • в модели не прослеживаются цепочки создания ценности, на которых «держится» весь бизнес (вместо этого представлена «мозаика» элементарных услуг);
  • возможное дублирование (например, процесс «взимание комиссии» может быть типовым и запускаться с разными параметрами при оказании различных услуг.
    При рассматриваемом подходе он будет показан несколько раз в разных частях системы процессов);
  • при внедрении новых продуктов/услуг придется «перекраивать» всю систему процессов.


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

Приведем еще один фрагмент из рассматриваемой модели банка:

3. Управленческие процессы
3.1. Управление финансами.
3.2. Управление персоналом.
3.3. Управление маркетингом
3.3.1. …
3.3.2. …
3.3.3. …
3.3.4. Управление продуктами.
3.3.4.1. Разработка и внедрение продуктов и услуг.
3.3.4.1.1.      …

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

3.Разработка новых и изменение текущих продуктов.      
      3.1. Управление разработкой новых и изменением текущих продуктов.      
      3.2. Поиск и отбор идей по новым продуктам.
      3.3. Управление портфелем проектов по новым продуктам/изменениям текущих продуктов.      
      3.4. Управление проектом по разработке нового продукта/изменению текущего продукта.      
      3.5. Выполнение исследований по новому продукту/изменениям текущего продукта.      
      3.6. Проработка идеи нового продукта/изменения текущего продукта.      
      3.7. Разработка нового продукта/измененного текущего продукта.      
      3.8. Подготовка производства продукта.      
      3.9. Запуск производства продукта.      
      3.10. Вывод продукта на рынок.      
      3.11. Управление нормативно-технологической документацией.      

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

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

Продолжение следует в Части 2 настоящей статьи.
      
В.В. Репин, к.т.н., доцент, Исполнительный директор и партнер ООО «BPM Консалтинг Групп».

Январь 2012 г.

www.finexpert.ru - всё о процессном управлении!

Прочитать Часть 2

Комментарии

Оценки: /
12.01.2012 14:41
  от автора
  Богиня
Владимир,спасибо за интересный материал. Всё разложено по "полочкам", очень кстати примеры компаний.Немного смутил термин "транзакция",насколько он здесь уместен,вроде как термин,относящийся к финансовой/банковской деятельности?
Оценки: /
12.01.2012 15:17
  от автора
  Дмитрий Пинаев
Вопрос затронут сложный, но настолько же и полезный, и актуальный.

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

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

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

Мое текущее видение правильной архитектуры процессов опирается на то, что система управления компании 2х уровневая.
Начну издалека и приведу пример:
Допустим у нас есть ракета, цель которой - долететь до цели (прощу прощения за каламбур Полетом ракеты управляет система управления, допустим находящаяся на самой ракете. Ракеты текущей конструкции поражают цель с каким-то фактически установленным процентом попаданий. Так может продолжаться бесконечно долго, пока кого-то не возмутит, что процент попаданий маловат. Здесь мы приходим к пониманию, что существует надсистема управления, которая занимается отслеживанием эффективности работы системы управления ракеты и может вносить изменения в систему управления ракеты и в саму ракету тоже. Будем далее называть систему управления ракеты – системой управления 2-го уровня, а надсистему управления – систему управления 1-го уровня.
Возвращаясь к бизнес-системам, в них также можно выделить 2 системы управления:
Система управления 2го уровня: служит для управления рядом Объектов управления, которыми компания «вынуждена управлять»: клиенты, оборудование, ресурсы, персонал, финансы и т.д. Управление в данном случае понимается классически: приведение объекта управления в целевое состояние: клиенты – довольные, оборудование – работающие, ресурсы – в наличии, персонал-работоспособный, финансы – достаточные для осуществления деятельности.
Т.е. грубо говоря, это управление операционной «текущей» деятельностью компании. Если текущая эффективность работы компании всех устраивает, внешние условия стабильны, то… получаем устойчивую систему управления. Больше в ней ничего не нужно.
Но в реальности так не бывает. И в дело вмешиваются «высшие» силы, которые могут захотеть поменять систему управления 2го уровня. Появляется система управления 1го уровня, объектом управления которой является… система управления 2го уровня. Цель – привести систему управления 2го уровня в состояние «эффективная». Физически 1ая система осуществляет изменение бизнес-процессов и основных средств компании на основе разрабатываемой стратегии. Т.е. 1ая система ставит цель для 2ой системы и собственно проектирует ее.
Проектировать в виде бизнес-процессов такую двухуровневую систему управления целесообразно с помощью двух моделей:
1. Модель системы управления 1 уровня – «Системы управления развитием бизнеса»
2. Модель системы управления 2 уровня – «Операционная система управления»
Первая модель порождает цели, регламенты бизнес-процессов, основные средства. В рамках второй модели описывается операционная деятельность: т.е. как с помощью данных основных средств осуществлять текущую деятельность.
К сожалению, в виде отдельного труда пока такое видение не изложено.
Оценки: /
12.01.2012 15:43
  от автора
  Репин
"...Если «нарезать» деятельность на блоки, не думая о результате, то с вероятностью 100%, при создании графических схем нарезка процессов поменяется, ибо попытки добавить результат приведут к пониманию, что деятельность должна быть сгруппирована по-другому..."

Теоретически Дмитрий прав на 100%. Да, такое может быть. Но на практике, в компании с устоявшейся орг. структурой ситуация проще. Там можно после анализа ЦСЦ (можно их не рисовать, если опыта хватает) сразу предложить состав категорий и групп процессов. Есть много типовых моделей для отраслей. Так что на уровне категорий и групп сделать значительные ошибки при наличии опыта сложно. А конкретные входы/выходы потом можно уточнять. Это работает нормально. (Другое дело, если начальник департамента вместо того, чтобы четко и конкретно рассказать, что именно и как делается, начинает гнать пургу про свой "трудовой подвиг" и умняк на счет западных референтных моделей!).

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


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

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

Что касается примера с ракетой, то в свое время учился и сдавал экзамен по система наведения баллистических ракет Над системой управления, которая ставит цель совершенствования системы автоматического управления ракетой, стоит система Министерства обороны, над ней президент, над ним... и т.д. и т.п. Уровней много. Так же и в компании....
Оценки: /
12.01.2012 16:07
  от автора
  Дмитрий Пинаев
>>Да, Дмитрий, подход "на основе объектов" не указан. Во второй части статьи будут мысли на эту тему. Насчет "структурного подхода". Здесь речь просто идет о том, что бывает удобно не выдумывать чего-то экзотичного, а просто определять операционные процессы в рамках существующих структурных подразделений, "отлавливая" при этом сквозные.

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

>>Ага! Дмитрий тонко почувствовал необходимость описания процессов управления! Во второй части статьи (она уже написана - ждет своего часа) есть мысли (надеюсь, интересные) о подходах к определению процессов управления.

Не процессов управления! а целых систем! процессы управления - они везде, в т.ч. на операционном уровне!

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

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

Надеюсь вернуться к вопросу системы и процессов управления после публикации второй части статьи.
Оценки: /
12.01.2012 16:12
  от автора
  Дмитрий Пинаев
>>5.методика построения системы процессов на основе анализа модели цепочек создания ценности (ЦСЦ);
Что касается этого подхода:
это подход в первую очередь для анализа деятельности, а не для построения модели процессов.
Поясню: получив длинную цепочку ЦСЦ по принципу ""что вижу, то и рисую", далее начинается ее свертка. Одинаковые куски вырезаются и становятся бизнес-процессами, описанными в модели один! раз.

Оценки: /
12.01.2012 16:13
  от автора
  Дмитрий Пинаев
>>Насчет двух уровней управления - есть еще собственники бизнеса, инвесторы, гос. органы. Все они ставят свои цели и ограничения. Вероятно, на основе теории ограничений тоже можно какую-то систему процессов построить

Здесь большой вопрос - зачем и нужно ли моделировать деятельность собственника? у модели должны быть границы.
Я отталкиваюсь от принципа бритвы Оккамы - модель должна содержать необходимые и достаточные элементы!
Оценки: /
12.01.2012 16:17
  от автора
  Репин
Мы схемы ЦСЦ используем в качестве рабочих, эскизных моделей. Т.е. с аналитическими целями. После построения системы процессов они могут не использоваться.
Оценки: /
12.01.2012 16:18
  от автора
  Дмитрий Пинаев
Ок, значит правильно помню.
Оценки: /
12.01.2012 16:22
  от автора
  Репин
Конечно, модель должна иметь границы. Вопрос описания процессов управления в рамках общей системы процессов - нетривиальный! Об этом в части 2
Оценки: /
13.01.2012 09:42
  от автора
  Богиня
Интересная получилась дискуссия двух гуру (если можно так назвать). Сложилось впечатление, уж не слишком-ли "атомизируются" процессы. В какой-то момент потерялась....



Я отталкиваюсь от принципа бритвы Оккамы - модель должна содержать необходимые и достаточные элементы!
- этим всё сказано!
Оценки: /
13.01.2012 10:36
  от автора
  Репин
Странно, что тема не обсуждается. Она актуальна для многих компаний.
Вероятно, причина в том, что народ еще догуливает праздники
Оценки: /
19.01.2012 10:55
  от автора
  Елена Дмитриевна
Добрый день. Интересная статья.
Тоже выскажусь по поводу положения «Если речь идет о построении системы процессов для действующей организации, то с точки зрения автора, целесообразно разрабатывать систему процессов сразу в виде справочника, не формируя графическую модель верхнего уровня»
Не буду со 100% утверждать, что не согласна с этим. Но не вижу ничего плохого и нецелесообразного в разработке графической схемы. Во-первых, разработкой системы процессов, как правило, занимается специалист в этой области. Результат своих трудов ему необходимо предоставлять Заказчику – директору, руководителю … Многим людям проще воспринимать графическое представление информации. Или совмещать графическое представление с краткой описательной частью. Во-вторых, если для описания процессов используется система бизнес моделирования, то на основании созданной графической схемы можно выгрузить отчет в виде иерархического справочника, что займет не больше 5 минут. И в-третьих, согласна с аргументацией Дмитрия – в некоторых случаях графическое представление помогает избежать ошибок.
Таким образом, думаю, что создавая графическую модель мы:
Получаем:
- еще один вид представления системы процессов;
- возможность избежать ошибок , выявляемых при создании графической схемы.
Теряем:
- собственно, ничего мы не теряем (при наличии системы моделирования, иначе потеряем время на копирование название процессов из схемы в список)
Оценки: 1/
19.01.2012 11:29
  от автора
  Репин
Привет, Елена!
Прошу понять меня правильно - я не против графических моделей верхнего уровня.
Но дело в том, что:
1. организация уже и так работает без подобного рода модели. У людей бизнеса все "модели" и так в голове;
2. разработка модели верхнего уровня предполагает, что будут определены укрупненные потоки информации/материальных ресурсов. Агрегированные (укрупненные) потоков (как и деятельность) в модели остается "на совести" бизнес-аналитика. "Стыковка" процессных категорий и групп при помощи таких агрегированных потоков весьма неоднозначная задача. Кроме того, руководителям верхнего уровня бывает сложно объяснить, "почему на этой схеме нет такого-то документа" и т.п.
3. создание модели верхнего уровня со всеми связями намного (в разы) более трудоемкая задача, чем создание справочника процессов;
4. использовать модели верхнего уровня для регламентации нельзя именно вследствие агрегирования - получается неконкретно, невозможно четко обозначить ответственность. Это не означает, что не нужно регламентировать зоны ответственности топ-менеджеров. Нужно обязательно! Но вот только модель верхнего уровня для этой задачи не особо помогает;
5. Жизнь сложнее чем любая методика. Если у меня в системе процессов 14 категорий, то как я это покажу на схеме? Это будет чрезмерно сложная, нечитаемая схема. Так за что тогда мы боролись?
Оценки: /
19.01.2012 16:19
  от автора
  xtlan
Владимир, в ссылке для печати на вторую часть указана первая часть. Поправьте ссылочку, пожалуйста!
Оценки: 1/
19.01.2012 17:00
  от автора
  Репин
Спасибо - поправил
Оценки: 2/
22.01.2012 22:00
  от автора
  Петров Дмитрий
Абсолютно согласен с Владимиром по поводу процессов верхнего уровня. Такие модели не позволяют отобразить толком ни последовательность работ, ни потоки информации, можно лишь условно показать логические связи между элементами. Кроме того, на схеме IDEF0 много объектов не уместишь, приходится сознательно многое упрощать (или излишне декомпозировать, плодя лишние уровни). При этом связи, обозначенные на схемах верхнего уровня, могут абсолютно не отражать реальных взаимодействий в процессах нижнего уровня (по крайней мере, я не видел систем, которые могли бы анализировать и находить подобные несоответствия). Поэтому предпочитаю подобные схемы не строить. Да и кому они в итоге могут быть полезны кроме самого бизнес-аналитика, который их рисует? А регламентировать ответственность топ-менеджеров можно и без этих схем.

Добавить комментарий

Комментировать материалы могут только зарегистрированные пользователи. Вы можете зарегистрироваться здесь.
©  2010-2014 В.В. Репин. Сайт основан 3 февраля 2001 г.

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

Регистрация
О Портале
Правила
Контакты
Новости
Библиотека
Энциклопедия
Литература и сайты
Группы
Мои страницы
Тесты
Форум
Доска объявлений