Почему «Бизнес-Студия»? Особенности программы (Александр Климчук)

Александр Климчук
к.т.н., доцент, начальник отдела бизнес-администрирования банка «Кредит-Днепр» (Украина)
mail@klimchuk.info

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

Моделирование бизнес-процессов в банке

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

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

Недавно я познакомился с оригинальной концепцией, предложенной А.Лебедевым (промышленный дизайн). Концепция называется «Метод прогрессивного джипега».

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

Рассуждая о бизнес-процессах и процессном управлении нельзя не упомянуть таких почтенных авторов, как П.Друкер и М.Хаммер. Десяток и более лет назад в своих трудах они готовили нас к мысли, что скоро закончиться пора «правильных решений» для бизнеса. Наступит пора «правильных систем» в бизнесе, которые способны генерировать эти правильные решения по мере поступления информации (или при ее отсутствии). Как раз бизнес-процессы – это инструмент построения таких «правильных систем».

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

0. «Нулевой» (процессы управления не применяются)
1. «Начальный»(процессы специализированы и не организованны)
2. «Повторяемый» (процессы повторяются на регулярном основании)
3. «Определенный» (процессы документированы взаимосвязаны)
4. «Управляемый» (процессы наблюдаются и измеряются)
5. «Оптимизированный» (процессы соответствуют «лучшей практике» и автоматизированы)

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

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

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

Не последнюю роль при выборе программы «Бизнес-Студия» для нас сыграла серия статей Р.Исаева о типовой модели бизнес-процессов для коммерческого банка. Тем не менее, мы решили не применять предлагаемую универсальную модель и сконцентрировать усилия на разработке собственного решения.

До прихода в банк наша команда имела многолетний опыт работ с бизнес-процессами в различных отраслях. Чем отличается банк от других отраслей с т.з. формализации бизнес- процессов? Тем, что в условиях банка процессное управление приживается более органично в силу природы банковского бизнеса. Банк не терпит хаоса и неконтролируемого творчества. Банк имеет жёсткие ограничения со стороны национальных и международных институтов. В банке значительное влияние имеет служба безопасности, для которой обычным делом является установление правил и процедур. Но, тем не менее, формализация и регламентация бизнес- процессов – это не лекарство от неэффективных процессов в банке. Более того – это тонкая система, которая сможет выжить лишь в достаточно высокой культуре менеджмента.

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

Рис. 1. Область применения программ моделирования бизнес-процессов (на примере банковского продукта)

Рис. 1. Область применения программ моделирования бизнес-процессов (на примере банковского продукта)

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

Из рисунка 1 также видно перечень основных задач, которые должен решать инструмент моделирования бизнес-процессов, например «Бизнес-Студия».

Чтобы показать особенности, преимущества и недостатки «Бизнес-Студии» нам необходимо с чем-то сравнить данный продукт. Мы предлагаем следующих конкурентов:

  • карандаш и бумага;
  • MS Word и MS Excel;
  • BPwin;
  • MS Visio.

Инструменты, не представленные в списке, были дисквалифицированы по причине неудобства работы, высокой стоимости, не поддержки необходимых стандартов моделирования или низкой популярности. В результате сравнения «Бизнес-Студии» с перечисленными конкурентами мы выделили три слова: «много», «медленно» и «не интуитивно» (см. рис. 2).

Рис. 2. Что такое «Бизнес-Студия»

Рис. 2. Что такое «Бизнес-Студия»

Далее приведены обоснования этим трем характеристикам программы.

Характеристика. Много

Чего же много в программе? Мы выделяем 5 значений слова «много» для программы «Бизнес- Студия»:

  1. много меню;
  2. много стандартов;
  3. много справочников;
  4. много отчетов;
  5. много дополнительных модулей.

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

Рис. 3. У программы два основных меню

Рис. 3. У программы два основных меню

Много стандартов. «Бизнес-Студии» конечно далеко до “ARIS”, но выбор тоже широк. См. рис. 4.

Рис. 4. Стандарты моделирования бизнес-процессов программы

Рис. 4. Стандарты моделирования бизнес-процессов программы

Давайте рассмотрим предлагаемый программой набор стандартов.

IDEF0. Тут комментарии излишни. Этот стандарт был, есть и будет «рабочей лошадкой» для системного анализа бизнеса.

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

Стандарт EPC. В нашей практике данный стандарт не прижился. Чтобы не повторяться – причины этого достаточно аргументированно изложены также В.Репиным.

Если рассматривать перечень предлагаемых стандартов – нам кажется что не хватает стандарта VAD (Value Added Diagram – диаграммы создания ценности). Этот стандарт очень хорош для концептуальной прорисовки бизнеса, для определения групп бизнес-процессов: основных, управляющих и вспомогательных. За счет минимизации объектов и стрелок между ними очень удобно сконцентрировать внимание на главные аспекты бизнеса.

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

Хорошо это или плохо? Ответить сложно. С одной стороны – это структурирует мысли и позволяет постепенно «навешивать» на модель необходимые объекты. Но с другой стороны – это может быть ограничением. Например, мы около недели настраивали справочник «термины» для того, чтобы можно было связать бизнес-процесс со специфическими терминами из справочника и автоматически формировать раздел «термины» в регламенте процесса. Причина – изначально данный справочник предназначался для отражения различных статусов документов в системе СМК. Кто бы мог подумать? 🙂

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

Рис. 5. Ключевые справочники программы

Рис. 5. Ключевые справочники программы

Много отчетов. Только что установленная программа содержит в себе довольно внушительный набор стандартных отчетов. Они сгруппированы по разным категориям. Довольно тяжело сориентироваться, что и зачем может понадобиться. См. рис. 6.

Рис. 6. Стандартные отчеты программы

Рис. 6. Стандартные отчеты программы

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

Поэтому совет: пользуйтесь стандартными отчетами только чтобы освоить искусство их настройки. Потом сделайте необходимые себе отчеты, а про стандартные отчеты — забудьте. Для «изготовления» своих отчетов программа предлагает мощный редактор.

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

  • СМК (система менеджмента качества);
  • ССП (система сбалансированных показателей);
  • ФСА (функционально-стоимостной анализ).

Насколько эти модули полезны – вопрос спорный. Автор не знаком с примерами их эффективного использования. Но с точки зрения маркетинга – это бесспорно добавляет баллов программе.

Характеристика. Медленно

Я считаю неправильным, когда программа думает дольше, чем человек (особенно, если от программы требуется простое очевидное действие, например – нарисовать стрелку или передвинуть блок). Так вот, «Бизнес-студия» думает медленнее человека и медленнее его движений мышкой. С эти придется мириться. BPwin работает рамного быстрее. Рисовать карандашом на бумаге намного быстрее. MS Visio будет откликаться намного быстрее.

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

Медлительность программы объясняется выбранными разработчиками технологиями:

  • графический «движок» от MS Visio – программы даже самой по себе не очень проворной, а тут еще сверху на нее нагрузили логический блок бизнес-конструктора;
  • хранение данных на SQL сервере; технология несомненно современная и полезная, но оправдывает она себя в полной мере только при групповой работе; часто встречается ситуация, когда серьезно моделированием бизнес-процессов занимается много и одновременно сотрудников? Я таких ситуаций не встречал.

Характеристика. Не интуитивно.

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

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

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

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

Рис. 8. Куда делись сотрудники?

Рис. 8. Куда делись сотрудники?

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

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

Модель храниться не в файле. Поработав какое-то время с программой, вы неизбежно захотите сохранить результаты своего труда. Тут вас ожидает сюрприз. В привычном меню «Файл» нет строки «Сохранить». См. рис. 9.

Рис. 9. Как сохранить модель?

Рис. 9. Как сохранить модель?

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

Отчеты можно вызывать интерактивно. Это приятная неожиданность. Можно щелчком правой кнопки по интересующему объекту вызвать отчет именно об этом объекте. Для бизнес-процесса это может быть его регламент или матрица ответственности. Для сотрудника – должностная инструкция или список процессов, где он задействован. Для документа – траектория его движения по процессам или по сотрудникам и т.д.

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

Единственная недоработка – контекстное меню нельзя вызвать на диаграмме. Можно вызвать только из навигатора. См. рис. 10.

Рис. 10. Отчеты можно вызывать отдельно для объектов

Рис. 10. Отчеты можно вызывать отдельно для объектов

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

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

Объяснение было очень простым. В каждом отчете есть динамическая составляющая (что показывать) и статичная составляющая (как и где показывать). Вторую составляющую тоже придется настраивать. Настройка выполняется в шаблоне MS Excel или MS Word (в зависимости – что вы выберете). См. рис. 11.

Рис. 11. Отдельно настраиваем содержание и отдельно – форму отчета

Рис. 11. Отдельно настраиваем содержание и отдельно – форму отчета

Не обошлось без досадных недоработок. Например, вы не сможете в регламенте бизнес-процесса (который естественно вы захотите видеть в MS Word) размесить матрицу ответственности. Матрицы программа «Бизнес-студия» имеет без ошибок формировать только в MS Excel. Данный факт подтвердили разработчики и пообещали в будущем устранить.

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

Выводы

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

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

Если вы делаете только первые шаги в области описания и управления бизнес-процессами – используйте более простые и понятные программы. Я бы советовал начать даже просто с карандаша и бумаги. Когда вы достигнете первых успехов и признания у собственников (высшего руководства) бизнеса – переходите на MS Visio и BPwin. И только когда ваш бизнес осознает необходимость построения системы управления с ориентацией на бизнес-процессы – задумайтесь о приобретении «Бизнес-Студии».

Business Studio. Основные объекты программы

Разноцветные панели инструментов и большие распахивающиеся меню: как из этого сделать полезную модель? Что использовать сразу, а что – потом? От чего стоит отказаться? Какой алгоритм разработки модели лучше?

2.1. Перед тем, как сесть за компьютер

Перед тем как начать строить модель бизнес-процессов банка задайте себе вопрос ЗАЧЕМ?

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

Главное правило: от того что мы просто нарисует бизнес-процесс ничего не измениться. Более того, после того, что мы нарисуем улучшенную модель бизнес-процесса – тоже ничего не измениться. Модель процесса – это всего лишь инструмент.

Как ни банально бы звучали рекомендации методики SADT4 [1], тем не менее – за все время существования процессного менеджмента не было предложено ничего лучшего. Эта методика предлагает перед началом моделирования определиться со следующим:

  • Зачем создается модель бизнес-процесса (цель)?
  • С какой позиции мы описываем бизнес-процесс (точка зрения)?
  • Где начинается и где заканчивается моделируемый бизнес-процесс (охват)?

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

Рис. 2.1. Три слагаемых хорошей модели бизнес-процесса

Рис. 2.1. Три слагаемых хорошей модели бизнес-процесса

В банковской практике набор целей довольно предсказуем и мы из своей практики может предложить следующий «топ 5» таких целей:

1. определение зон ответственности (например, кто из подразделений в банке ответственный за работу с проблемными кредитами: только юристы и безопасность или бизнес-подразделения также должны принимать участие в «обработке» клиента);

2. сокращение времени принятия решения по кредитной заявке;

3. автоматизация создания и обновления регламентирующих документов;

4. формирование технического задания на автоматизацию бизнес-процессов;

5. разработка системы стимулирования сотрудников, основанная на их вкладе в прибыльность деятельности банка.

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

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

Заручившись поддержкой руководства банка можно приступать к моделированию бизнес- процесса.

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

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

У каждого варианты есть «+» и «-», о них много уже было написано (например — [2]), поэтому останавливаться на данном вопросе не буду. Хочу лишь предостеречь от распространенной ошибки, когда моделирование поручают неким «smart – специалистам» параллельно с их повседневным функционалом. Из этого нечего хорошего не выйдет! Как минимум из-за того, что у этих сотрудников не будет достаточных полномочий для проведения работ и повседневная «текучка» рано или поздно заставит их отложить моделирование в долгий ящик.

Если в банке уже принято решение моделировать процессы, и решено делать это собственными силами – выделите для этого отдельных сотрудников, которое не будут выполнять другие функции. Для банка средних размеров (2000-3000 тыс. сотрудников) достаточно 3-4 таких специалиста. Более того, при наличии специализированного подразделения для моделирования бизнес-процессов целесообразно создавать временные проектные группы из участников моделируемого процесса. Это обеспечит поддержку работ ресурсами и упростит доступ к информации о выполнении процесса.

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

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

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

Но ландшафт должен быть простым. Тут мы полностью согласны с мнением В.Репина [3] по поводу увеличения сложности модели по мере углубления декомпозиции. Критерию простоты соответствует стандарт моделирования VAD. Но, к сожалению, данный стандарт не присутствует в программе «Бизнес-Студия». Компенсировать данный недостаток мы предлагаем за счет использования структуры процессов в навигаторе программы.

2.2. Исследуем строительные материалы

Давайте ответим на вопрос: что должна содержать в себе хорошая модель бизнес-процесса банка? Первый раз, начав заниматься моделированием бизнес-процессов в банке (около 5 лет назад), я для себя отметил приятную новость: в банке не нужно моделировать материальные потоки!

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

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

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

Что же нам предлагает «Бизнес-Студия» в качестве строительных материалов для создания модели процессов? Все строительные «кубики» можно свести по назначению в четыре группы (см. рис. 2.2):

  • Что делаем? (перечень процессов);
  • Кто делает? (перечень участников процессов);
  • Где отражаются результаты работы? (перечень документов);
  • При помощи чего делаем работу? (программные продукты);
  • Описание терминов – слов, которые неоднозначно могут быть поняты читателями диаграмм.
Рис. 2.2. «Строительные кирпичи» модели бизнес-процесса банка

Рис. 2.2. «Строительные кирпичи» модели бизнес-процесса банка

Все необходимые элементы для построения модели находятся в левой части окна программы. См. рис. 2.3.

Рис. 2.3. «Кирпичи» для построения модели бизнес-процесса

Рис. 2.3. «Кирпичи» для построения модели бизнес-процесса

Прочие элементы, предлагаемые «Бизнес-Студией», не следует использовать на первых стадиях построения модели. Давайте, к примеру, рассмотрим такой элемент, как информация. Что такое информация в банке? Это устный разговор, это мысли сотрудника, это слухи о личной жизни руководителя? Если информация представляет интерес для бизнеса банка – она должна быть зафиксирована в документе. Если этого не сделано – значит это не важно. См. рис. 2.4.

Рис. 2.4. Избегайте использование «информации»

Рис. 2.4. Избегайте использование «информации»

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

Стандарты моделирования бизнес-процессов, которые предлагает «Бизнес-Студия» делятся на две группы: структурные и временные. См. рис. 2.5.

Рис. 2.5. Стандарты моделирования бизнес-процессов в «Бизнес-Студии»

Рис. 2.5. Стандарты моделирования бизнес-процессов в «Бизнес-Студии»

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

Из перечисленных стандартов мы рекомендуем использовать два: IDEF0 и «Процедура». IDEF0 хорошо справляется для моделирования бизнес-процессов на верхнем уровне [6]. Процедура является вариантом хорошо всем известной блок-схемы, дополненной вертикальными или горизонтальными полосами, отражающими исполнителей процессов. Этот стандарт хорош для моделирования бизнес-процессов на нижних уровнях [7].

Мы уже затрагивали вопрос: как быть с ландшафтом бизнес-процессов? Мы предлагаем реализовать ландшафт в виде структуры папок процессов в «Бизнес-Студии». Делается это так. Сначала создадим папку, где будет храниться вся наша модель. См. рис. 2.6.

Рис. 2.6. Создание папки для хранения модели бизнес-процесса

Рис. 2.6. Создание папки для хранения модели бизнес-процесса

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

Рис. 2.7. Три группы процессов

Рис. 2.7. Три группы процессов

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

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

Рис. 2.8. Типы субъектов

Рис. 2.8. Типы субъектов

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

Рис. 2.9. Типы участия сотрудника в бизнес-процессе

Рис. 2.9. Типы участия сотрудника в бизнес-процессе

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

  • выполняет бизнес-процесс;
  • является владельцем бизнес-процесса.

Следующий элемент модели – это документы. Тут я хочу отметить две важные особенности. Первая заключается в том, что программа «Бизнес-Студия» предлагает нам разделить все документы на две группы: электронные и бумажные. Вторая особенность заключается в возможности связать наименование документа в программе с его электронным аналогом. Это удобная возможность, например если необходимо утвердить шаблон оформления того или иного документа. Рассмотрим подробнее эти две особенности использования документов.

По поводу необходимости классифицировать документы на электронные и бумажные. Какой документ электронный в организации, а какой — бумажный? Я однозначного ответа дать не могу.

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

Рис. 2.10. Классификация документов

Рис. 2.10. Классификация документов

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

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

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

Рис. 2.11. Название и содержание стрелки могут отличаться

Рис. 2.11. Название и содержание стрелки могут отличаться

Сложностей не возникает, если мы перетаскиваем стрелку из справочника документов. В этом случае и наименование стрелки и наименование объекта совпадают.

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. Фрагмент матрицы документооборота

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

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

  1. П. Друкер. Задачи менеджмента в XXI веке. М. «Вильямс». 2007.
  2. М. Хаммер. Бизнес в ХХI веке: повестка дня. М. «Добрая книга». 2005.
  3. Стандарт качества организации работы по описанию и оптимизации бизнес-процессов в кредитных организациях. Ассоциация российских банков. www.arb.ru/site/action/list_anons.php?id=3381
  4. Р.А. Исаев. Референтные (типовые) модели банковской деятельности. www.businessstudio.ru/procedures/business/typebank/
  5. Р.А. Исаев. Комплексная бизнес-модель коммерческого банка. www.businessstudio.ru/procedures/business/bank_complex
  6. А.В. Шеер Моделирование бизнес-процессов. М. «Серебряные нити». 1999.
  7. В.В. Репин. Описание процессов при помощи Work Flow. www.finexpert.ru
  8. В.В. Репин. Описание бизнес-процессов: стремление к простоте. www.businessstudio.ru/procedures/business/simple_descr/
  9. Д. Марка, К. МакГоуэн Методология структурного анализа и проектирования SADT. М. «Серебряные нити». 1999.

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

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

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

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>