Business Studio. Основные объекты программы (продолжение)

Первая часть обзора - Business Studio. Основные объекты программы (Часть 1)

2.3. Строим модель

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

Главное что нужно помнить при построении модели процесса – в результате модель должна давать ответ на некий вопрос. Модель должна быть полезна.

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

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

Рис. 2.12. Последовательность использования стандартов моделирования бизнес-процессов

Создавать диаграммы бизнес-процессов в стандарте IDEF0 мы рекомендуем такой последовательности:

1. определение перечня подпроцессов;
2. определение их доминирования (последовательности);
3. определение исполнителей и владельцев;
4. определение основных результатов подпроцессов (документов);
5. связывание подпроцессов по выходам-входам;
6. отображение прочих документов на диаграмме;
7. указать информационные потоки между подпроцессами (при необходимости).

Создание диаграмм бизнес-процессов в стандарте «процедура» рекомендуется проводить в такой последовательности:

1. указать начальное и конечное событие процесса;
2. обозначить точки принятия решений (объект – «проверка условия»);
3. указать перечень подпроцессов;
4. обозначить временную последовательность подпроцессов;
5. указать документальные потоки между подпроцессами;
6. указать информационные потоки между подпроцессами (при необходимости).

Примеры диаграмм бизнес-процесса кредитования в стандарте IDEF0 и «процедура» приведены на рисунках 2.13 и 2.14 соответственно.

Рис. 2.13. Пример диаграммы в стандарте IDEF0

Рис. 2.13. Пример диаграммы в стандарте IDEF0

Рис. 2.14. Пример диаграммы в стандарте «Процедура»

Рис. 2.14. Пример диаграммы в стандарте «Процедура»

Как вы могли заметить, диаграмма IDEF0 в «Бизнес-Студии» имеет необычный вид. Она лишилась верхнего колонтитула. См. рис. 2.15.

Рис. 2.15. Сравнение колонтитулов в «Бизнес-Студии» и BPwin-е

Рис. 2.15. Сравнение колонтитулов в «Бизнес-Студии» и BPwin-е

Почему так произошло? Немного изучив программу Visio можно найти ответ. В самой программе именно таков шаблон диаграммы IDEF0. Почему выбран такой шаблон, несмотря на другие рекомендации стандарта [6] – сказать не берусь.

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

Рис. 2.16. Традиционный колонтитул IDEF0

Рис. 2.16. Традиционный колонтитул IDEF0

Хотим подробнее остановиться на вопросе отражения сотрудников в модели процессов.

Как мы отметили ранее, мы считаем, что для работы вполне достаточно описать два типа участия субъекта в процессе: владелец и исполнитель. Программа «Бизнес-Студия» предлагает нам 4 типа субъекта: должность, подразделение, роль и внешний субъект. В результате мы получаем следующие возможные сочетания «процесс – субъект», см. рис. 2.17.

Рис. 2.17. Варианты участия субъектов в бизнес-процессах

Рис. 2.17. Варианты участия субъектов в бизнес-процессах

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

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

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

Рис. 2.18 Различные типы субъектов для разных задач

Рис. 2.18 Различные типы субъектов для разных задач

Еще одной особенностью программы «Бизнес-Студия» является необходимость в стандарте IDEF0 отражать участников процесса и в виде стрелок и в свойствах самих процессах. Об этом недостатке мы говорили в первой статье цикла. Если вы укажите участников процесса только в виде стрелок – вы не сможете полноценно формировать регламентирующие документы. См. рис. 2.19.

Рис. 2.19. Участников процесса необходимо указывать два раза

Рис. 2.19. Участников процесса необходимо указывать два раза

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

Рис. 2.20. Перед формирование отчета сохраняйте изменения на диаграммах

Рис. 2.20. Перед формирование отчета сохраняйте изменения на диаграммах

Не могу не отметить потерю очень удобного и полюбившегося многим инструмента декомпозиции – автоматического создания нужного количества блоков на диаграмме декомпозиции. Коллеги, которые активно занимались созданием диаграмм IDEF 0, надеюсь со мной согласятся, что данный инструмент в IDEF0 значительно упрощал работу. При создании же декомпозиции в «Бизнес-Студии» мы получаем сиротливый прямоугольник на пустом экране. См. рис. 2.21.

Рис. 2.21. Программа не умеет автоматически наполнять диаграмму

Рис. 2.21. Программа не умеет автоматически наполнять диаграмму

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

Рис. 2.22. Нарушение принципа доминирования на диаграмме

Рис. 2.22. Нарушение принципа доминирования на диаграмме

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

Рис. 2.23. Копирование процессов следует применять осторожно

Рис. 2.23. Копирование процессов следует применять осторожно

2.4. Проверка модели

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

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

Рис. 2.24. Инструменты проверки модели

Рис. 2.24. Инструменты проверки модели

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

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

Нам понадобятся отчеты двух видов: матрица ответственности и матрица документооборота.

Матрица ответственности показывает связь между процессами и субъектами модели. На пересечении строк и столбцов указывается тип связи. Как мы уже говорили – мы рекомендуем использовать только два типа связи: владелец и исполнитель.

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

Схематически матрицы ответственности и документооборота показаны на рисунке 2.25.

Рис. 2.25. Матрицы для проверки модели

Рис. 2.25. Матрицы для проверки модели

По поводу матриц ответственности и документооборота у нас есть две новости: хорошая и плохая:

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

Как быстро обойти все «подводные камни» программы и построить эти два отчета мы опишем ниже. Первое, что нам бросилось в глаза – в навигаторе программы мы не нашли отчетов. См. рис. 2.26.

Рис. 2.26. Где программа хранит отчеты

Рис. 2.26. Где программа хранит отчеты

Искать отчеты нужно в меню «Отчеты». Зачем разработчики допустили такую путаницу – для нас осталось загадкой.

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

Рис. 2.27. Матрицы удобно вызывать из контекстного меню

Рис. 2.27. Матрицы удобно вызывать из контекстного меню

Первая неприятность, которая вас подстерегает с отчетами: они корректно могут формироваться только в MS Excel. Несмотря на то, что программа предложит вам выбрать также формат MS Word – не верьте этому! Матричные отчеты в версии «Бизнес-Студии» 3.5 включительно формироваться не могут.

Рис. 2.28. Матрицы в Word не выгружаются :(

Рис. 2.28. Матрицы в Word не выгружаются :(

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

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

Рис. 2.29. Место для хранения отчетов

Рис. 2.29. Место для хранения отчетов

Аналогично следует поступать при выборе места хранения фильтров, используемых при работе ответа. См. рис. 2.30.

Рис. 2.30. Место для хранения фильтров

Рис. 2.30. Место для хранения фильтров

Другая особенность формирования матриц – не следует сразу выбирать формат «шахматка». Выберите сначала формат «таблица», а затем в свойствах отчета сменить тип. У нас ни разу не получилось построить отчет изначально выбрав его тип «шахматка». См. рис. 2.31.

Рис. 2.31. Не используйте изначально формат отчета «шахматка»

Рис. 2.31. Не используйте изначально формат отчета «шахматка»

Давайте рассмотрим поочередно алгоритм создания отчета «Матрица ответственности» и «Матрица документооборота».

Для формирования матрицы ответственности нам необходим перечень подпроцессов, начиная с процесса, от которого мы вызываем отчет, а также заполненная таблица «Субъекты» подпроцесса. В таблице должен быть указан и владелец и исполнитель (исполнители) процесса. См. рис. 2.32.

Рис. 2.32. Для формирования матрицы ответственности необходимы данные об участниках процесса

Рис. 2.32. Для формирования матрицы ответственности необходимы данные об участниках процесса

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

Алгоритм создания отчета «Матрица ответственности» следующий:

1. создаем новый отчет в формате «список»;
2. выбираем привязку «Упорядоченный список процессов с корнем»;
3. внутри привязки выбираем первое свойство «Название процесса»;
4. вторым свойством выбираем вложенную привязку «Процесс.Субъекты»;
5. внутри вложенной привязки выбираем свойства «Субъект» и «Тип связи. Сокращение»;
6. меняем тип отчета на «Шахматка» (в свойствах отчета).

Пример построенного отчета приведен на рисунке 2.33.

Рис. 2.33. Фрагмент матрицы ответственности

Рис. 2.33. Фрагмент матрицы ответственности

Для формирования матрицы документооборота необходимыми исходными данными являются стрелки, связанные с процессом, у которых в свойствах «Объекты» указаны документы (бумажные или электронные).

Рис. 2.34. Объекты стрелок – основа построения матрицы документооборота

Рис. 2.34. Объекты стрелок – основа построения матрицы документооборота

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

Алгоритм построения матрицы документооборота:

1. создаем новый отчет в формате «список»;
2. выбираем привязку «Упорядоченный список процессов с корнем»;
3. в первый столбец выносим свойство процесса «Название»;
4. выбираем привязку «Связи процесса по объектам» и настраиваем фильтр «Объект = Документ»;
5. во второй столбец таблицы выносим свойство привязки «Стрелка SADT»;
6. в третью колонку выносим свойство привязки «Тип стрелки»;
7. меняем тип отчета на «Шахматка» (в свойствах отчета).

Пример построенного отчета приведен на рисунке 2.35.

Рис. 2.35. Фрагмент матрицы документооборота

Рис. 2.35. Фрагмент матрицы документооборота

Примеры отчётов

2.5. Информационные источники

  1. 1. Д. Марка, К. МакГоуэн Методология структурного анализа и проектирования SADT. М. «Серебряные нити». 1999.
  2. 2. В.В.Репин, В.Г.Елиферов Процессный подход к управлению. Моделирование бизнес- процессов. 2004.
  3. 3. В.В. Репин Комплексная система поддержки процессного управления. www.businessstudio.ru/procedures/business/complex_bpm/
  4. 4. Создание пользовательских отчетов. Методика. Группа компаний «Современные технологии управления». www.businessstudio.ru
  5. 5. Руководство пользователя Business Studio. Группа компаний «Современные технологии управления». www.businessstudio.ru
  6. 6. Методология функционального моделирования IDEF0. Руководящий документ. Госстандарт России ИПК Издательство стандартов, 2000, 92 с.
  7. 7. ГОСТ 19.701-90. Схемы алгоритмов, программ, данных и систем. Условные обозначения и правила выполнения.

По материалам сайта Finexpert.ru

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

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Можно использовать следующие HTML-теги и атрибуты: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>