Полное описание процесса для физических лиц

Сегодня мы предлагаем статью на тему: "Полное описание процесса для физических лиц". Наши специалисты постарались полностью раскрыть тему доступным языком. Вопросы вы можете задать нашему дежурному юристу.

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

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

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

Итеративность связана с тем, что меняются требования клиентов, меняется

рынок, выходят новые нормативные документы Банка России и т.п. Такого рода изменения требуют постоянного контроля и необходимости актуализации бизнес-процессов.

Негативные последствия неформализованности бизнес-процессов банка

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

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

Причины (состав проблемы)

1. Не распределена четко ответственность между сотрудниками, отделами.

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

Рис. 1. Следствия неформализованности бизнес-процессов банка

Нажмите, чтобы увеличить рисунок

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

3. Слабая автоматизированность бизнес-процессов и несоответствие инфраструктуре.

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

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

Следствия неформализованности бизнес-процессов банка

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

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

3. Снижение удовлетворенности клиентов.

4. Ошибки в работе сотрудников и некачественное оказание услуг. Любого рода ошибки влекут за собой дополнительное время и издержки на их устранение.

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

Выгоды для банка описания бизнес-процессов

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

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

2. Снижение времени и издержек, повышение качества и эффективности бизнес-процессов.

3. Возможность тиражировать бизнес банка (создавать дополнительные отделения и офисы).

4. Шаг к комплексному развитию банка. Описание бизнес-процессов является этапом комплексного проекта по развитию деятельности банка. На основе описанных бизнес-процессов можно:

— проводить их дальнейшую оптимизацию;

— проектировать новые бизнес-процессы;

— оптимизировать оргструктуру;

— совершенствовать системы управления банка (информационную систему, систему управления финансами, систему стратегического управления и т.п.).

5. Уменьшение зависимости от персонала, правильный подбор персонала, повышение эффективности работы персонала и руководителей.

6. Повышение лояльности и удовлетворенности клиентов как следствие репутации банка.

Кто должен заниматься в банке описанием бизнес-процессов

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

Плюсы:

— меньшие сроки выполнения проекта по сравнению с выполнением проекта «своими силами»;

— получение экспертного опыта и квалифицированного исполнения работ.

Минусы:

— высокая стоимость проекта;

— необходимость в дальнейшей поддержке результатов проекта без участия консультантов;

— в консалтинговых проектах не всегда детально учитываются специфика предметной области и все «тонкости» деятельности банка.

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

во-первых, найти квалифицированных специалистов (либо обучить имеющихся специалистов);

во-вторых, приобрести специализированное программное обеспечение;

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

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

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

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

В малых банках обычно для этой цели выделяют нескольких специалистов.

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

Начальник (заместитель начальника) отдела. Его функции: руководство проектом описания бизнес-процессов, координация работ и представление результатов топ-менеджерам банка; организация взаимодействия с подразделениями и отделами банка.

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

Методики и подходы к описанию бизнес-процессов Существуют два типа методик.

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

Методики графического описания бизнес-процессов. Данные методики содержат набор графических объектов и правил их использования при разработке диаграмм бизнес-процессов.

Рассмотрим методики организации проекта по описанию бизнес-процессов.

1. Через дерево бизнес-процессов.

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

2. Через отделы.

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

Перечислим самые распространенные методики, с помощью которых можно описывать бизнес-процессы: IDEF0, IDEF3, DFD, ARIS, UML. Подробно останавливаться на описаниях методик не стоит, поскольку данной информации достаточно в открытых источниках.

Инструменты для описания бизнес-процессов

На сегодняшний день на рынке существуют следующие профессиональные программные продукты, предназначенные для автоматизации описания бизнес-процессов: ARIS, Бизнес-Студио, AllFusion Process Modeler, MS Visio, QPR и др. Они отличаются функционалом, схемами ценообразования.

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

— автоматизированное формирование регламентирующей документации на основе диаграмм бизнес-процессов;

— аналитические функции (ФСА-анализ и др.);

— сетевая работа;

— защита информации и распределение доступа;

— публикация бизнес-моделей в WEB.

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

Методика описания (структуризации) бизнес-процессов банка

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

Рис.2. Методика описания банковских бизнес-процессов

Нажмите, чтобы увеличить рисунок

1. Определение целей и задач описания бизнес-процессов, основных требований

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

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

2. Создание рабочей группы по описанию бизнес-процессов

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

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

3. Разработка соглашения по бизнес-моделированию, выбор и приобретение программного продукта бизнес-моделирования

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

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

Соглашение по бизнес-моделированию — это документ, в котором фиксируются следующие положения:

— общие положения;

— глоссарий проекта;

— архитектура разрабатываемых бизнес-моделей в рамках проекта и их взаимосвязи, структура базы данных (моделей) проекта;

— выбранная методика описания бизнес-процессов с детальными пояснениями к ее объектам, методам, правилам и т.п. Как правило, методика привязывается к конкретному программному продукту бизнес-моделирования. Примеры соглашений можно найти в открытом доступе в сети Интернет либо в соответствующих приложениях к программным продуктам;

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

— другие правила, опыт и инструкции по описанию бизнес-процессов.

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

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

Рис.3. Дерево бизнес-процессов банка

Нажмите, чтобы увеличить рисунок

4. Определение владельцев процессов и дерева процессов

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

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

Читайте так же:  Как устанавливают дорожные знаки??

Приведем пример формирования дерева бизнес-процессов банка на примере «МТИ-Банка».

На верхнем уровне обычно выделяют группы бизнес-процессов (рис. 3).

Основные бизнес-процессы — это те, которые приносят банку прибыль:

1. Обслуживание физических лиц.

2. Обслуживание юридических лиц.

3. Работа на финансовых и межбанковских рынках.

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

4. Административно-хозяйственное обеспечение.

5. Обеспечение безопасности.

6. Юридическое обеспечение.

7. ИТ-обеспечение и связь.

8. Внутренний контроль.

9. Бухгалтерский учет и отчетность.

10. Другие (более 10).

Бизнес-процессы управления — вспомогательные процессы, с помощью которых осуществляется управление деятельностью банка и основными объектами:

11. Стратегическое управление.

12. Управление маркетингом.

13. Управление рисками.

14. Управление персоналом.

15. Управление бизнес-процессами и развитием.

16. Региональное управление.

17. Другие (более 10).

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

В данном дереве (рис. 3) нас интересует группа бизнес-процессов «А2 Обслуживание юридических лиц». В данной группе выделяются бизнес-процессы, которые реализуют услуги и продукты банка для юридических лиц. Это все бизнес-процессы 1-го уровня.

2. Обслуживание юридических лиц.

2.1. Расчетно-кассовое обслуживание.

2.2. Банковские карты.

2.3. Кредитование.

2.4. Привлечение депозитов.

2.5. Внешнеэкономическая деятельность.

2.6. Инкассация.

2.7. Удаленное управление счетом.

2.8. Другие (более 20).

Важное замечание: следует разделять понятия «группа бизнес-процессов» и «уровень бизнес-процесса». Когда мы группируем несколько бизнес-процессов по определенному признаку, мы не создаем новый уровень для бизнес-процесса. Групп бизнес-процессов может быть сколько угодно (они делаются для удобства аналитиков и сотрудников банка), а уровней бизнес-процессов желательно делать не более 3–5. Возникает вопрос: как определить уровень бизнес-процесса? МТИ-Банк применяет следующий подход для разбиения бизнес-процессов по уровням.

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

Пример

Бизнес-процесс «2.3. Кредитование» — это бизнес-процесс 1-го уровня, который также представляет собой дерево.

2-й уровень. Подпроцессы, которые являются ключевыми составляющими бизнес-процесса 1-го уровня. Кодовое название элемента уровня: подпроцесс.

Пример

2.3. Кредитование.

2.3.1. Кредит.

2.3.1.1. Оформление и выдача кредита.

2.3.1.2. Погашение кредита.

2.3.2. Возобновляемая кредитная линия.

2.3.3. Невозобновляемая кредитная линия.

3-й уровень. Процедуры — последовательность процедур с промежуточным результатом.

Кодовое название элемента уровня: процедура.

2.3.1.1. Оформление и выдача кредита

2.3.1.1.1. Получение и обработка заявки

2.3.1.1.2. Проверка заемщика

2.3.1.1.3. Выдача кредита

2.3.1.1.4. Формирование резерва.

4-й уровень. Действия — узкоспециализированные функции нижнего уровня, из которых состоят процедуры.

2.3.1.1.1. Получение и обработка заявки

2.3.1.1.1.1. Провести интервью с клиентом

2.3.1.1.1.2. Получить минимальный комплект документов от клиента

2.3.1.1.1.3. Оказать содействие клиенту в оформлении заявки

2.3.1.1.1.4. Провести предварительную проверку документов

2.3.1.1.1.5. И т.д.

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

5. Разработка плана проекта по описанию бизнес-процессов

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

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

Результат этапа: план проекта по описанию бизнес-процессов.

6. Детальное описание бизнес-процесса

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

Выделим подэтапы данного этапа.

6.1. Выбрать бизнес-процесс 1-го уровня для детального описания

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

Результат подэтапа: выбранный бизнес-процесс.

6.2. Составить окружение бизнес-процесса

Следует заранее запросить у владельца бизнес-процесса следующую информацию:

— участники процесса;

— нормативные и регламентирующие документы;

— все формы документов, входы-выходы бизнес-процесса;

— что и как автоматизировано в бизнес-процессе.

Для сбора информации возможно анкетирование владельца и исполнителей бизнес-процесса.

Пример

Для выбранного бизнес-процесса имеем следующую информацию:

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

— нормативные и регламентирующие документы: положение о кредитных рисках, методика финансово-экономического анализа, положение о кредитном комитете, Положение Банка России № 54-П «О порядке предоставления (размещения) кредитными организациями денежных средств и их возврата (погашения)» и т.д.;

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

Результат этапа: документ с зафиксированным окружением бизнес-процесса.

6.3. Составить рабочую группу по описанию бизнес-процесса

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

При создании рабочей группы назначаются ответственные, устанавливаются сроки описания бизнес-процесса, делаются соответствующие приказы. [1]

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

6.4. Провести интервью владельца бизнес-процесса и сделать детальное описание бизнес-процесса

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

Второе, что нужно изучить перед проведением интервью, — это методика проведения интервью.

  • Основные правила ведения интервью, которых рекомендует придерживаться автор при описании бизнес-процессов:

— старайтесь выстраивать и фиксировать мысли собеседника в строго логичном и последовательном порядке;

— внимательно слушайте, задавайте наводящие вопросы, чтобы узнать все «тонкости», но не командуйте;

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

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

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

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

Также довольно часто возникает ситуация, когда требуется разработать новые формы документов для бизнес-процесса и отредактировать существующие. Этому тоже следует уделять внимание. [2]

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

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

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

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

6.5. Доработать и согласовать описание бизнес-процесса с другими участниками

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

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

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

6.6. Согласовать итоговое детальное описание бизнес-процесса с контролирующими подразделениями

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

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

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

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

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

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

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

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

6.8. Опубликовать регламенты бизнес-процессов, Положение, формы документов

Итак, к данному подэтапу мы имеем регламенты бизнес-процессов и формы документов, сведенные в единое Положение.

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

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

— коллективный доступ с разграничением прав — с Положением должно работать большое количество сотрудников банка и «видеть» только необходимую им часть;

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

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

Существуют несколько способов решения данной задачи.

Во-первых, с помощью программного продукта бизнес-моделирования. Некоторые программные продукты могут генерировать так называемые HTML-навигаторы (web-сайты), в которые включается вся информация из бизнес-процессов. Данные сайты размещаются на корпоративном web-портале банка. Например, МТИ-Банк формирует HTML-НАВИГАТОР на базе программного продукта Business Studio и актуализирует его несколько раз в месяц (по ходу описания новых бизнес-процессов либо внесения изменений в существующие регламенты и формы документов).

Читайте так же:  Правила поведения при землетрясении в доме

Во-вторых, с помощью систем электронного документооборота и баз знаний. Одна из наиболее известных и успешно применяемых в банках систем — Microsoft Share Point Services.

Оптимизация бизнес-процессов в рамках проекта их описания и структуризации

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

1. Перестройка бизнес-логики процесса. Добавление, удаление, переструктуризация процедур и действий внутри бизнес-процесса.

2. Переработка форм документов, входов-выходов бизнес-процесса, нормативных документов.

3. Перераспределение ответственности и исполнителей в рамках бизнес-процессов.

Заключение

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

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

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

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

Р.А. Исаев, «МТИ-Банк» (ЗАО), отдел разработки банковских продуктов и технологий, ведущий специалист

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

Карл Маркс. Капитал. Том 1. Предисловие к первому изданию.

О бизнес-процессах говорят много и часто преимущественно в связи с автоматизацией бизнеса. Использую этот термин и я, в том числе, в своих статьях, посвященных CRM-системам, ERP, работе с BPMN-нотациями, IDEF0 и других инструментов, которые могут понадобиться в работе бизнес-консультанта и внедрении систем автоматизации. При этом в Рунете понятное и развернутое определение термина «бизнес-процесс» я не нашел.

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

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

Определение бизнес-процесса

Итак, в чем же разница между бизнес-процессом и функций или даже просто обычным процессом? В чем разница между этими терминами? Я пришел к следующему выводу:

Бизнес-процесс – это логическая последовательность действий человека (или нескольких человек) в коллективе. Цель описания бизнес-процесса – анализ и регламентация тех или иных действий в коллективе.

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

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

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

Описание бизнес процесса

Также важно дать определение описанию бизнес процесса:

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

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

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

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

Лично я сравниваю создание нового бизнес-процесса с балансированием на тонкой нити гармоничного сочетания творчества, искусства и строгой математики.

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

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

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

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

Технологический процесс и бизнес-процесс

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

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

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

  1. Берем заготовку A;
  2. Соединяем ее с заготовкой B;
  3. Обрабатываем под параметры C;
  4. Получаем деталь.

Все однозначно и никаких условных «вилок» не предусматривается.

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

  1. Получаем вводные данные A:
    • Если данные соответствуют условию B, переходим на последовательность действий C;
    • Если данные соответствуют условию D, выполняем действия E.
  2. Полученный результат передается на выход.
Видео удалено.
Видео (кликните для воспроизведения).

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

История появления термина

Я не единожды читал информацию о том, что нотации бизнес-процессов IDEF0 появилось чуть ли ни в середине XIX века. Более реалистичные авторы пишут о периоде Второй Мировой войны. Но и они ошибаются.

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

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

На самом деле описание бизнес-процессов и нотации BPMN появились в 70-е годы XX века, когда повсеместно начали использоваться информационные системы. И сам термин, и нотации понадобились изначально именно для разработки информационный систем.

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

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

Первые методологически проработанные нотации бизнес-процессов (а я буду говорить именно о методологически проработанных нотациях, например, IDEF3***) появились у военных в США. Причина очевидна – уже тогда военные в США пользовались автоматизацией с использованием удаленных соединений, т.е. той самой системой, которая позже стала Интернетом. И при таком уровне применения информационных систем потребность в нотациях бизнес-процессов была особенно актуальной.

***По теме методологически проработанных нотаций хочу также сказать пару слов. Почему я привел в качестве примера IDEF3: я еще не видел более проработанной методологически системы описания бизнес-процессов. Даже BPMN 2.0 все еще развивается и дорабатывается. А если вы почитаете англоязычное описание IDEF3 (перевода на русский я пока не видел), то также сумеете оценить по достоинству глубину его проработки.

Очень быстро методология и нотации завоевали огромную популярность в бизнес-среде.

Читайте так же:  Как проверить штрафы ГИБДД по номеру машины?

Нотации позволили получить инструмент описания взаимодействия людей и цифровых информационных систем.

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

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

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

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

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

Зачем моделировать (описывать) бизнес-процессы

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

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

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

И сочетание изучения истории появления термина с моим личным опытом дает следующее определение:

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

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

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

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

Как описывать бизнес-процессы

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

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

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

Рекомендуемая последовательность действий:

  1. Собираем участников процесса (сотрудников);
  2. Собираем входящую информацию, необходимую и достаточную для запуска процесса;
  3. Собираем используемые системы. Это может быть учетная система,CRM, электронная почта, таблицы Excel и т.д. Все, что реально используется в работе, необходимо зафиксировать.
  4. Определяем ожидаемый результат – что будет в конце процесса.
  5. Собираем последовательность действий, которые выполняет человек.
  6. Вычленяем условия. В зависимости от разных входящих данных и промежуточных результатов действия могут быть разными.
  7. Описываем всю собранную информацию в графическом виде в удобной нотации (IDEF3, BPMN 2.0 и т.д.).

Правила описания бизнес-процесса

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

  • Законченность. Бизнес-процесс должен четко отвечать на вопрос, стоящий перед ним. Если мы говорим о процессе продажи определенного товара или услуги, то бизнес-процесс должен полностью описывать действия, необходимые для получения указанного результата, и завершающегося именно таким результатом (с определенными допущениями, о которых я говорил выше).
  • Лаконичность. Бизнес-процесс должен сочетать в себе достаточность, т.е. описывать все необходимые этапы и действия, при этом быть максимально лаконичным для простоты восприятия. Лично я вывел для себя «правило 15 минут» — если за этот период времени я могу объяснить руководству компании представленный бизнес-процесс, значит, его можно показывать заказчику. Получается быстрее – прекрасно, требует больше времени и слов – надо подумать, что можно сократить и упростить.
    Я когда-то лично видел графическое описание бизнес-процесса, выполненное на листе 2 метров длиной (и соответствующей шириной). Его даже просто рассмотреть и понять, куда ведет какая стрелка крайне сложно. А как его пояснять заказчику, я лично не представляю.
    Помните, что человек воспринимает зрительно определенный объем информации, ограниченный, в том числе, определенным размером листа или экрана (это связано с особенностями зрения), а также числом элементов (возможности мозга также ограничены). Простой и лаконичный бизнес-процесс заказчик поймет, просто «охватив» схему взглядом. Сложный и перенасыщенный деталями придется изучать не один час просто для того, чтобы понять, что там отображено. Скорей всего, руководитель компании, который не является экспертом в работе отдельных подразделений, а также ограничен по количеству свободного времени, просто не будет изучать столь сложную конструкцию и не поймет сути даже самых выгодных предложений.
  • Использование общепризнанных нотаций. Не стоит изобретать собственные обозначения и правила. Используйте нотации, которыми пользуются во всем мире. Я видел в книгах некоторых отечественных авторов попытки создания собственной системы обозначений. И, честно говоря, так и не понял, зачем они усложняют жизнь и себе, и своим читателям. Здесь как с языком – вы можете придумать свой особый язык, но понимать его никто, кроме вас, не будет. А если он окажется похож на существующие, то может еще и путаница появиться. Либо вас сочтут безграмотным, так как вы не по правилам известных языков используете пунктуацию, склоняете слова и т.д. Так и с нотациями – есть уже устоявшиеся, известные людям и, что также немаловажно, интуитивно понятные нотации. Они потому и стали популярны, что в процессе их создания и доработок постоянно тестировались на простоту, однозначность и удобство. Если вы будете использовать готовые нотации, вас будут понимать, воспринимать, как эксперта, да и сами правила нотаций уберегут вас от логических ошибок. Я лично рекомендую IDEF3 и BPMN 2.0.
  • Все участники бизнес-процесса должны быть учтены и прямо указаны. И делать это необходимо без использования сносок с нумерациями, комментариях в объектах Swimm line (специальные сноски) и т.д. Этим нередко «грешат» любители создавать собственные конструкции вместо использования готовых нотаций. Где-то у них названия не помещаются, где-то им кажется, что длинное название в теле бизнес-процесса будет неудобным. В результате либо приходится искать в сносках, о ком именно идет речь, либо создатели таких бизнес-процессов просто забывают указать кого-то из участников.
  • Понятное потребителю описание. Самое главное – ваш потребитель, тот, кто будет читать эту нотацию, должен быстро и, в идеале, даже без ваших пояснений понимать описание бизнес-процесс.

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

Распространенные мифы и заблуждения

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

Я не рекомендую так поступать. Во-первых, при использовании готовых инструментов вам не потребуется изобретать свои обозначения и стандарты. Все давно придумано до вас. При этом стандартные нотации действительно понятны интуитивно, читаются однозначно, известны многим людям. Во-вторых, в готовых системах (IDEF3, BPMN 2.0 и пр.) имеется проработанная методология и строгие ограничения. Их можно воспринимать как язык программирования и среду для работы с этим языком. Здесь вы просто не сумеете совершить многих ошибок, от этого вас уберегут стандарты синтаксиса и сама среда (ограничения в редакторе, автоматические проверки).

Читайте так же:  Сколько времени делается кипрская виза

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

Распространенная ошибка: Бизнес-процесс обязательно приносит ценность (прибыль). О том, что бизнес-процессы должны приносить прибыль, я слышал даже от известных спикеров. Более того, видел даже “разбор ошибок” при создании бизнес-процесса, в котором очень много внимания уделяется тому, что 70% действий не несут никакой ценности.

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

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

Возможно ли создать идеальный бизнес-процесс — когда следует остановиться? Нет. Бизнес—процесс должен быть простым, понятным, удобным, читабельным. Но идеальным он не будет никогда.

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

На самом деле, исходя из всего выше описанного, моделирование бизнес-процесса — это некоторое допущение, процесс творческий. С другой стороны, я в свое время не знал даже что ответить на просьбы описать еще “это” и “вон то”. Но со временем я понял, что бизнес-моделирование — это не просто творчество, но некий диалектический процесс. И уже само создание бизнес-процесса всегда будет нести в себе собственное отрицание. Здесь действительно стоит подходить к вопросу с философской точки зрения. И создавая бизнес-процесс, нужно помнить, что мы не можем охватить все и сразу, а потому он всегда будет несовершенен. Но при этом мы уже закладываем в него то, что будем совершенствовать в будущем. Стоит к этому подходить просто как к факту.

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

Для лучшего понимания тематики рекомендую статьи:

  • Разбираемся с понятием BPM. Что такое управление бизнес процессами
  • Моделирование бизнеса. Основные подходы
  • Знакомство с нотацией IDEF0 и пример использования
  • Краткое описание BPMN с примером
  • Что такое BPMS
  • Использование GAP-анализа для выявления и согласования задач по проекту

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

Полное описание процесса для физических лиц 100

В первой части мы рассмотрели основные понятия бизнес-процессов. В данной части мы рассмотрим моделирование бизнес-процессов и приведем пример моделирования.

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

Для моделирования рекомендуется использовать следующие методы сбора информации:

  • интервьюирование;
  • работа с законодательством, документами организации;
  • методы мозгового штурма и т.д.

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

Ниже мы рассмотрим пример алгоритма моделирования бизнес-процессов. Итак, для моделирования бизнес-процесса необходимо:

  1. Определить результат и владельца  бизнес-процесса.
  2. Определить набор и порядок действий, составляющих бизнес-процесс.
  3. Определить исполнителей бизнес-процесса: на данном шаге необходимо произвести разделение зон ответственности, выделить какие сотрудники каких подразделений несут ответственность за выполнение действий процесса,  привязать исполнителей к действиям.
  4. Определить события бизнес-процесса. Определить типы событий: начальное, конечное, промежуточное. Привязать промежуточные события к действиям.
  5. Определить ресурсы: документы, информацию, и др. потребляемые действиями бизнес-процессов. Привязать ресурсы к действиям.

Схема, иллюстрирующая алгоритм моделирования показана на рисунке ниже:

Полное описание процесса для физических лиц 156

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

  • дополнить существующую модель ответвлениями;
  • предусмотреть отдельно действия «альтернативного» процесса.

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

Не рекомендуется анализировать все возможные и невозможные случаи процесса. Ситуациями, не предусмотренными процессом, как правило, занимается функциональный руководитель подразделения (в зоне ответственности которого возникла ситуация).

Для фиксации бизнес-процессов в графическом виде используется система условных обозначений элементов (нотация). Наиболее известные нотации: SADT/IDEF0, IDEF3, DFD, BPMN, ARIS, UML. Рассмотрение и сравнительный анализ нотации не входит в предмет обсуждения данной статьи; интересующимся в интернете можно найти массу статей на темы сравнения нотаций, например «IDEF vs ARIS».

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

Приведем пример описания бизнес-процесса. В качестве примера возьмем процесс предоставления неоплаченного отпуска. Рассмотрим порядок и документооборот, возникающий при указанном выше процессе. Метод сбора информации: законодательство РФ как предварительный материал перед интервью с экспертами предметной области и Владельцем процесса. Нотация описания: ARIS eEPC.

1. Сбор исходного материала.

1.1 Предоставление отпуска регламентируется Трудовым Кодексом (при сборе материала необходимо опираться на последнюю редакцию, на момент написания статьи – с изменениями от 30 декабря 2015 г. № 434-ФЗ), статьей 128 Отпуск без сохранения заработной платы

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

Работодатель обязан на основании письменного заявления работника предоставить отпуск без сохранения заработной платы:

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

 

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

1.2. Документооборот при оформлении отпуска регламентируется постановлением Госкомстата РФ от 05.01.2004 N 1 «Об утверждении унифицированных форм первичной учетной документации по учету труда и его оплаты», раздел «Приказ (распоряжение) о предоставлении отпуска работнику».

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

Составляются работником кадровой службы или уполномоченным им на это лицом, подписываются руководителем организации или уполномоченным им на это лицом, объявляются работнику под расписку. На основании приказа (распоряжения) о предоставлении отпуска делаются отметки в личной карточке (форма N Т-2 или N Т-2ГС(МС)), лицевом счете (форма N Т-54 или N Т-54а) и производится расчет заработной платы, причитающейся за отпуск, по форме N T-60 »Записка-расчет о предоставлении отпуска работнику».

Приводим данные, необходимые для моделирования бизнес-процесса (действуем согласно описанной ранее схеме): 

1. Результат бизнес-процесса — оформленные согласно законодательству РФ и стандартам организации документы. 

2. Владелец бизнес-процесса: руководитель кадровой службы. Как определить владельца? Владелец – это сотрудник, обладающий ресурсами для осуществления бизнес-процесса (в данном случае ресурсы – сотрудники кадровой службы) и несущий ответственность за результат бизнес-процесса.

3. Набор и порядок действий:

написание заявления -> составление приказа -> подписание приказа у руководителя инициатора -> подписание приказа у инициатора –> оформление кадровых документов.

В последовательности действий отсутствует расчет заработной платы, т.к. статья Трудового Кодекса, согласно которой оформляется отпуск, – Отпуск без сохранения заработной платы.

4. Исполнители бизнес-процесса.. Для более наглядного предоставления информации приведем последовательность шагов и исполнителей в таблице:

№ действия

Наименование действия

Исполнитель

№ след. действия

1

Написание заявления

Инициатор

2

2

Составление приказа

Сотрудник кадровой службы

3

3

Подписание приказа у руководителя инициатора

Сотрудник кадровой службы

4

4

Подписание приказа у инициатора

Сотрудник кадровой службы

5

5

Оформление кадровых документов

Сотрудник кадровой службы

(конец)

5. События. Дополним вышеуказанную таблицу информацией о событиях:

№ действия

Входящее событие

Наименование действия

Исполнитель

Исходящее событие

№ след. действия

1

Инициатору необходим отпуск за свой счет

Написание заявления

Инициатор

Составлено заявление на отпуск за свой счет

2

2

Составлено заявление на отпуск за свой счет

Составление приказа

Сотрудник кадровой службы

Составлен приказ об отпуске

3

3

Составлен приказ об отпуске

Подписание приказа у руководителя инициатора

Сотрудник кадровой службы

Приказ об отпуске подписан руководителем инициатора

4

4

Приказ об отпуске подписан руководителем инициатора

Подписание приказа у инициатора

Сотрудник кадровой службы

Приказ об отпуске подписан инициатором

5

5

Приказ об отпуске подписан инициатором

Оформление кадровых документов

Сотрудник кадровой службы

Оформлены кадровые документы на отпуск

(конец)

6.  Ресурсы, документы и информация. В данном примере мы не учитываем такие ресурсы, как время исполнителей, материалы и оборудование, т.к. нам важны документы, оформленные согласно законодательству РФ и стандартам организации (см. результата процесса). Нам надо проанализировать, какие документы принимают участие в процессе. Дополним существующую таблицу информацией:

№ действия

Входящее событие

Наименование действия

Документ, информация

Исполнитель

Исходящее событие

№ след. действия

1

Инициатору необходим отпуск за свой счет

Написание заявления

Заявление на отпуск за свой счет

Инициатор

Составлено заявление на отпуск за свой счет

2

2

Составлено заявление на отпуск за свой счет

Составление приказа

Приказ на отпуск

Сотрудник кадровой службы

Составлен приказ об отпуске

3

3

Составлен приказ об отпуске

Подписание приказа у руководителя инициатора

Приказ на отпуск

Сотрудник кадровой службы

Приказ об отпуске подписан руководителем инициатора

4

4

Приказ об отпуске подписан руководителем инициатора

Подписание приказа у инициатора

Приказ на отпуск

Сотрудник кадровой службы

Приказ об отпуске подписан инициатором

5

5

Приказ об отпуске подписан инициатором

Оформление кадровых документов

Т-2, Т-54а

Сотрудник кадровой службы

Оформлены кадровые документы на отпуск

(конец)

Читайте так же:  Обжалование штрафа ГИБДД, образцы жалоб

7. Проведем анализ «что если».

  • Что если заявление будет содержать ошибки (начиная от грамматических, заканчивая неправильным указанием реквизитов)? Инициатор заявления не обязан иметь достаточную квалификацию для безошибочного заполнения заявления (а обязан уметь грамотно выполнять свои непосредственные обязанности). Для устранения случая неправильного заполнения заявления добавим действие проверки заявления в основной процесс, т.к. нам важно предотвратить наличие ошибочного документа в процессе.
  • Что если приказ на отпуск будет неправильно составлен? Т.к. в обязанности специалиста кадровой службы входит составление кадровых документов, то мы предполагаем, что в большом количестве случаев приказ составляется правильно. Это не отменяет проверку квалификации специалиста кадровой службы (процессы приема на работу и аттестации) и проведение периодической проверки документов (процесс аудита кадровых документов).
  • Что если руководитель не подпишет приказ и инициатор:
    • имеет право на отпуск, согласно 128 статье Трудового кодекса. Данный вопрос запишем в открытые вопросы по данному процессу и зададим его Владельцу процесса при согласовании процесса. Всю ответственность за исполнение процесса несет Владелец процесса, именно он определяет правила выполнения работы во вверенном ему подразделении;
    • не имеет право на отпуск, согласно 128 статье Трудового кодекса. Данный вопрос также запишем в открытые вопросы.
  • Что если инициатор откажется подписывать приказ (например, у него изменились обстоятельства, согласно которым он брал отпуск)? Мы прекращаем процесс.
  • Что если внесение отметок в кадровые документы Т-2 и Т-54а будет некорректным? Данный вопрос аналогичен вопросу, рассматриваемому в п. 3.2.
Дополним существующую таблицу полученной информацией. Фактически мы получили предварительное описание процесса в табличном виде:

Полное описание процесса для физических лиц 57

Открытые вопросы

  • Что если руководитель инициатора отказался подписать приказ на отпуск и инициатор имеет право на отпуск, согласно 128 статье Трудового кодекса
  • Что если руководитель инициатора отказался подписать приказ на отпуск и инициатор не имеет право на отпуск, согласно 128 статье Трудового кодекса

Краткое обозначение элементов нотации ARIS eEPC приведено в таблице ниже (описаны не все элементы нотации, а используемые. Графическое обозначение элементов взято из пакета MS Visio):

Полное описание процесса для физических лиц 175

Схема, отображающая взаимодействие элементов показана ниже:

Полное описание процесса для физических лиц 157

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

Полное описание процесса для физических лиц 104

 

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

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

— Не сомневаюсь, ты написал интересную статью. Но к чему такие сложности? Зачем нужны бизнес-процессы, неужели без них нельзя?

— Смотри, бизнес-процессы снижают вариабельность результатов за счет стандартизации операций. Вариабельность означает снижение разброса допустимых вариантов результатов процесса. Я описал простой пример, бизнес-процессы применимы не только к кадровому делу, но и к деятельности организации. Представь себе, что организация, специализирующая на поставке запчастей, будет производить детали с разным уровнем качества (мы помним, что качество – это соблюдение характеристик изделия). Далее автозапчасти будут ставиться на автомобили, и мы получим… продукцию АвтоВАЗа. Продукция АвтоВАЗа находит своего покупателя, но мы в последнее время предпочитаем автомобили качественной сборки.

— Я думаю, все дело в исполнителях. Достаточно найти грамотных исполнителей и мы получим хороший результат. Как в твоем примере – надо найти грамотного кадровика, только и всего.

— Хорошие исполнители, уже обеспечены работой, их труд стоит дорого. Ты не думаешь об оптимизации расходов организации, найма толковых специалистов, и обеспечения специалистов методической поддержкой. Еще один фактор – масштабирование работы. Представим, что в нашей организации работает 2 000 сотрудников. В данном случае у нас будет несколько специалистов кадровой службы и у них будет разный опыт. Наша задача в данном случае – предоставить инструмент обучения, осуществления операций и контроля операций со стороны руководителя подразделения.

— Даже если 2 000 человек и даже если специалисты будут ошибаться. Какова цена ошибки – всего-лишь неправильно оформленные кадровые документы, эти бумажки.

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

Спасибо читателям, что дошли до этого места. Можно было бы многое сказать дополнительно: рассказать про инструменты, используемые при описании бизнес-процессов, подробнее коснуться нотаций… Но это всё продолжение введения в бизнес-процессы.

Автор

Евгений Пономарёв

[email protected]

Процессы могут быть описаны (в частности, это может быть сделано в Руководстве по качеству) различными способами:

1) текстом;

2) в виде таблицы;

3) в виде блок-схемы;

4) в виде SADT-диаграмм, позволяющих создать структурированную модель процессов, указать взаимосвязи процессов, потоки данных, применяемое управление, ресурсы и механизмы — создать графическое и наиболее полное описание процессов;

5) иными способами, например, с использованием таких программных средств как FlowChart, ARIS и т.д.

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

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

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

В качестве примера приведено описание Паспорта процесса, который содержит следующие элементы.

Наименование процесса должно отражать его содержание и быть кратким (например, «Производство», «Управление персоналом»).

Определение процесса должно в краткой форме детализировать его наименование и отвечать на вопрос: «Из каких основных видов деятельности состоит процесс?».

Код процесса состоит из трех знаков: один знак — класс вида деятельности («М» — менеджмент, «Б» — бизнес-процесс, «Р» — менеджмент ресурсов), два знака — порядковый номер процесса данного типа.

Цель процесса определяет необходимый результат процесса. Цель процесса отвечает на вопрос: «Что должно быть достигнуто при надлежащем выполнении данного процесса?»

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

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

— улучшение своего процесса и выполнение связанных с ним деятельности и задач;

— обеспечение связи с исполнительной властью организации по ее усовершенствованию;

— разработка требований для всех работников, вовлеченных в функционирование и улучшение процесса;

— управление применением внешних требований и выполнением норм;

— обеспечение гарантий устранения всех горизонтальных барьеров процесса.

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

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

П р и м е ч а н и я

1 Виды деятельности могут быть описаны как процессы или как процедуры СМК организации.

2 Под «организациями» в данном случае понимаются внешние организации (например, предприятия поставщики).

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

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

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

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

Показатели выходов процесса — показатели, позволяющие оценить соответствие выходов процесса требованиям.

Методы измерения выходов процесса. Как правило, методы измерения установлены в документах. Следует указать соответствующие документы или кратко описать метод.

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

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

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

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

Показатели результативности процесса — характеризуют степень достижения запланированных результатов. Следует указать формулу расчета показателей результативности процесса.

П р и м е ч а н и я

1 Результативность процесса оценивается как соотношение фактического и нормативного значений показателей выходов процесса.

2 Следует использовать показатели выходов процесса и показатели результативности при оценивании удовлетворенности потребителей.

Затраты на процесс. Следует оценить затраты на процесс, складывающиеся из следующих элементов:

— затраты на труд;

— затраты на средства труда (например, на организационную и технологическую оснастку);

— затраты на материалы;

— затраты на создание условий труда.

П р и м е ч а н и е — Информация о затратах необходима для оценивания эффективности процесса.

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

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

Видео удалено.
Видео (кликните для воспроизведения).

Источники:

  1. Родионова, В.М.; Вавилова, Ю.Я.; Гончаренко, Л.И. и др. Финансы; М.: Финансы и статистика — , 2011. — 432 c.
  2. А.Л., и др. история министерства финансов 1903-2002г.г. / ред. А.Л Кудрин, А.Л. и. — М.: ИНФРА-М, 2016. — 631 c.
Полное описание процесса для физических лиц
Оценка 5 проголосовавших: 1

ОСТАВЬТЕ ОТВЕТ

Please enter your comment!
Please enter your name here