Бизнес процессы банка

Содержание

Описание бизнес-процессов: стремление к простоте

Владимир Репин

Генеральный директор ООО «Владимир Репин Менеджмент»

Член ABPMP Russia

Доцент

Консультант по управлению

Бизнес-тренер

Кандидат технических наук

В статье рассмотрены вопросы выбора нотации для описания процессов с целью последующей регламентации. Сравниваются между собой часто используемые нотации Work Flow, такие как: «Простая блок-схема» в MS Visio, «Процедура» Business Studio, нотация ARIS eEPC и другие. При сравнении нотаций основное внимание уделяется вопросам создания простых и понятных сотрудникам организации схем процессов.

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

Введение

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

Сравнение нотаций

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

  1. «Простая блок-схема» (с отображением движения документов, с использованием блока «Решение»);
  2. «Простая блока-схема» (без отображения движения документов, без использования блоков «Решение»);
  3. «Процедура» системы Business Studio (один из возможных вариантов представления);
  4. ARIS eEPC.

В качестве тестового примера был выбран простой и интуитивно понятный процесс. Результаты описания этого процесса представлены на Рис. 1–4.

Рис. 1. Схема процесса в нотации «Простая блок-схема» в MS Visio (с движением документов, с использованием блока «Решение»)

На схеме, представленной на Рис. 1, последовательность выполнения операций процесса во времени показана при помощи жирных стрелок, а движение документов — при помощи тонких пунктирных стрелок. Блоки «Решение» использованы классическим образом. Они отображают информацию (вопросы), от которых «зависит» последующий ход процесса. Такой подход к использованию «ромбиков» является весьма распространенным. Но фактически, вся логика принятия решений и формирования тех или иных выходов (документов) должна заключаться внутри операций процесса. Если задуматься, то ценность (смысл) рисования этих «ромбиков» не является очевидным. Что это за объекты: операции процесса, события? Вроде бы, ни то, и ни другое. Это скорее операторы принятия решения по какому-либо условию. Но ведь мы разрабатываем схему процесса для людей, а не пишем компьютерную программу на специальном языке. В компьютерной программе «ромбик» был бы полноценной операцией сравнения условий и т. п. Но на схеме процесса нужно показывать реальные объекты — процессы, выполняемые людьми, документы, информационные системы и т. п. Задумайтесь, корректно ли показывать «ромбики» отдельно от операции процесса на схеме? Вместо этого можно:

  • Описать логику принятия решения в виде последовательность операций на схеме рассматриваемого процесса;
  • Описать логику в виде схемы шагов соответствующего подпроцесса, переходя на уровень ниже;
  • Описать логику текстом (в текстовых атрибутах операции) и в последующем вывести в регламент выполнения процесса.

Сформулируем «плюсы» и «минусы» рассмотренного выше (Рис. 1) способа использования «ромбиков».

«Простая блок-схема» в MS Visio (с движением документов, с использованием блока «Решение»)

«Плюсы» «Минусы»
  1. Наглядное отображение «логики» выбора тех или иных выходов процесса;
  2. Акцентирование внимания исполнителя на точку принятия решения/ветвление процесса в зависимости от условий.
  1. Вынос логики принятия решения «наружу» операции процесса (некорректно с точки зрения формальной декомпозиции процессов);
  2. Неудобно документировать процесс (приходится дублировать «ромбики» текстом при формировании текстового описания операции);
  3. Схема процесса становится информационной перегруженной;
  4. «Ромбики» часто используются слишком формально, без реальной необходимости.

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

На Рис. 2 показан пример того же самого процесса, только описанного без использования блоков «Решение» и документов. Легко проверить, что на этой схеме на 24 графических элемента меньше, чем на схеме Рис. 1. Схема Рис. 2 выглядит гораздо проще. От графических элементов не рябит в глазах, а с точки зрения информативности эта схема вполне понятна и доступна конечному пользователю. Если для каждой операции процесса описать требования к ее выполнению текстом, то комбинируя табличную и графическую формы представления, можно вполне адекватно описать порядок исполнения процесса для сотрудников компании.

Рис. 2. Схема процесса в нотации «Простая блок-схема» в MS Visio (без движения документов, без использования блока «Решение»)

«Плюсы» и «минусы» графического представления процесса в форме, представленной на Рис. 2, показаны ниже.

«Простая блок-схема» в MS Visio (без движения документов, без использования блока «Решение»)

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

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

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

Второй особенностью схемы процесса, представленной на Рис. 3, является применение стрелок. Для отображения последовательности операций можно использовать стрелку с одним наконечником — стрелку «предшествования». Для отображения движения документов можно использовать стрелку с двумя наконечниками. Однако в Business Studio можно обойтись использованием только одного типа стрелок — стрелками «предшествования». При этом к именованным стрелкам можно привязывать необходимое количество документов, которые определены в справочнике объектов деятельности.

Такой подход дает возможность:

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

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

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

Рис. 3. «Процедура» системы Business Studio (вариант с нетрадиционным использованием блоков «Решение»)

«Плюсы» и «минусы» графического представления процесса в форме, представленной на Рис. 3, показаны ниже.

«Процедура» системы Business Studio (вариант с нетрадиционным использованием блоков «Решение»)

«Плюсы» «Минусы»
  1. Простота представления;
  2. Акцентирование внимания исполнителя на операцию, связанную с принятием решения/ветвлением процесса;
  3. На листе А4 может быть представлено большое количество информации.
  1. Блок «Решение» не декомпозируется;
  2. Неоднозначность в именовании стрелок (возможны разночтения).

В случае применения Business Studio, нотация «Процедура» может быть использована несколько по-разному. Автор статьи склоняется к подходу, представленному на Рис. 3.

На Рис. 4 представлена схема рассматриваемого процесса, разработанная в нотации ARIS eEPC. Заметим, что на схему не поместились некоторые операции процесса. Эта неполная схема простейшего процесса, выполненная в нотации ARIS eEPC, содержит четыре оператора логики и восемь событий! Сотрудник, читающий схему, должен уметь правильно интерпретировать все эти логические операторы. Без специального обучения и наличия некоторых навыков чтения подобных схем, рядовой сотрудник вряд ли сможет понять логику рассматриваемого процесса без подробного текстового описания или помощи квалифицированного бизнес-аналитика.

Заметим, что схема процесса в нотации ARIS eEPC занимает существенно больше места, чем схемы, представленные на Рис. 1–3. Трудоемкость формирования такой схемы также существенно выше.

Рис. 4. Схема процесса в нотации ARIS eEPC (построена в Business Studio)

Схема процесса в нотации ARIS eEPC (построена в Business Studio)

«Плюсы» «Минусы»
  1. При формировании схемы выдерживается строгая, формальная логика процесса;
  2. Четко определены все события, возникающие по ходу процесса.
  1. Сложность восприятия;
  2. Значительная трудоемкость формирования схемы;
  3. У сотрудников должны быть специальные навыки и опыт интерпретации подобных схем;
  4. Информационная избыточность;
  5. Занимает слишком много места, что неудобно для документирования.

В целом, если Вы не собираетесь покупать SAP R/3, то выбор и использование нотации ARIS eEPC не является, с точки зрения автора статьи, оптимальным решением. Стоит обратить внимание на более наглядные и интуитивно понятные исполнителям нотации описания процессов. Впрочем, кому-то нотация ARIS eEPC может показаться более наглядной и понятной. До определенной степени, это вопрос вкуса.

Описание процесса для целей последующей автоматизации

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

Своим мнением об использовании BPMN 2.0. делится А. А. Белайчук — Генеральный директор компании «Бизнес-консоль»:

«На Рис. 5 изображен тот же процесс в нотации BPMN. Как мы видим, этот рисунок похож на Рис. 1: в нотации BPMN задачи изображаются прямоугольниками, развилки — ромбами, данные — пиктограммой, похожей на документ. Потоки управления — сплошные линии, потоки данных — пунктирные.

Надо учитывать, что на этой диаграмме задействована только малая часть нотации BPMN: только один вид развилок из 5 имеющихся в палитре, один вид задач из 8. Помимо более широкой палитры, эту нотацию отличает возможность моделировать не только изолированный поток работ, но также несколько процессов, взаимодействующих друг с другом через сообщения или данные. Кроме того, эта нотация более строгая: в ней определены не только значки, но и правила, по которым они могут сочетаться друг с другом. Необходимость таких правил диктуется тем, что нотация BPMN ориентирована не только на то, что ее будут читать люди, но и на непосредственное исполнение специальным программным обеспечением — „движком“ BPM-системы.

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

Рис. 5. Схема процесса в нотации BPMN 2.0

Практика жизни

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

Рис. 6. Примеры схемы процесса одной из компаний

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

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

Выводы

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

Использование сложных, формализованных нотаций при описании процессов приводит к:

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

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

http://finexpert.ru/ — среда общения профессионалов http://bpm3.ru/ — процессы, проекты, эффективность

Поделиться:

Рекомендуемые материалы по тематике

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

Business Studio 4.1. Обзор новых возможностей программы

Снижение среднегодовой стоимости обслуживания клиентов на примере проекта НПФ «Будущее»

Техническая поддержка — ПИТ-стоп в вашем бизнесе

Что такое бизнес-процесс и описание бизнес процесса

И, тем не менее, ум человеческий тщетно пытался постигнуть ее в течение более чем 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-анализа для выявления и согласования задач по проекту

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

Основные причины осуществления реструктуризации

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

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

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

К внутренним причинам, тормозящим развитие компании, относятся:

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

Но чаще решение о реструктуризации принимается из-за внешних факторов (изменение конъюнктуры рынка, появление новых научных и технических разработок).

Цели реструктуризации

В числе целей процедуры выделяют:

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

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

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

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

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

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

Виды реструктуризации

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

Классификации видов реструктуризации разделяются по разным критериям, в том числе по:

  1. Стадии развития предприятия:
    • оперативная (при необходимости выхода организации из кризисной ситуации);
    • стратегическая (для поддержания функционирования организации).
  2. Инициатору:
    • пассивная, связанная с внешними обстоятельствами, при которых предприятие заинтересовано в структурных преобразованиях;
    • активная, когда инициатором является сама компания.
  3. По степени взаимодействия с внешним окружением:
    • внешняя, нацеленная на изменение взаимоотношений с внешней средой;
    • внутренняя, направленная на внутренние корректировки и прямо не касающаяся изменения внешней среды.
  4. Охвату видов деятельности организации:
    • комплексная (для всех сторон деятельности);
    • поэлементная (для отдельных элементов — производства, финансов, управленческой системы);
    • многоэлементная (для комплекса ряда элементов системы).
  5. По времени проведения:
    • краткосрочная;
    • среднесрочная;
    • долгосрочная.
  6. По степени подотчетности и привлекаемым средствам:
    • централизованная, проводимая в компании по решению и под контролем государственных (муниципальных) структур за счет привлеченных средств;
    • децентрализованная, осуществляется предприятием самостоятельно (собственными средствами);
    • смешанная при использовании собственного и привлеченного финансирования.
  7. По количеству проводимых операций (этапов):
    • одноэтапная;
    • многоэтапная.
  8. По темпам проведения процедуры:
    • последовательная;
    • скачкообразная.

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

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

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

При проведении процедуры выделяются несколько основных этапов:

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

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

Этап 3. Подготовка стратегии и программы. По данным диагностических мероприятий составляются альтернативные варианты развития, вычисляются прогнозные показатели и потенциальные риски, объемы необходимых ресурсов. С учетом различных критериев руководством компании осуществляется выбор варианта, на основе которого вырабатывается программа реструктуризации с уточненными стратегическими направлениями, детализацией параметров (качественных, количественных), достижение которых планируется. Основным документом при осуществлении изменений принимается программа проведения корректировок. У каждого предприятия программа носит индивидуальный характер.

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

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

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

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

Возможные риски

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

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

Переструктуризация функционального зонирования помещений для оптимальной эксплуатации Текст научной статьи по специальности «Строительство. Архитектура»

дсрг _ ¿—н.о.и

О (гср

о.и о

о

ср.г п.и

О (гсрг

п.и п

гсрг) + О (гсрг — гсрг)

гр о. и о гр

О (г срг

еср.г _ п.и У п

н.п.и

-гсГ)

п.и н.п.и

2(гН + гК) — г.и 4″ + гК + гН + го) — ггри ^Н + гК) — г..и

Значения среднегодовых тепловых потерь по нормам для испытанных участков данной тепловой сети определяются по формулам:

iНе можете найти то, что вам нужно? Попробуйте сервис подбора литературы.

ОСрг =Хв* Чп * ь ОР =Хв* Чн.п * Ь ОТ: чн.о * Ь

Соотношения фактических и определенных по нормам тепловых потерь

ОСр,

К _ ^п.и

ОСр,

К _ ^ Н.п.и

ОСр,

К _ ^ н.о.и

ур.г

^н.о

определяются по формулам: срг п срг о

О-Н.п ОН

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

Гришина Анна Николаевна

студентка 5 курса 4 группы факультета ИСТАС Гаряев Николай Алексеевич профессор, к.т.н.

iНе можете найти то, что вам нужно? Попробуйте сервис подбора литературы.

МГСУ, ИЭУИС, кафедра «САПР в строительстве»

ПЕРЕСТРУКТУРИЗАЦИЯ ФУНКЦИОНАЛЬНОГО ЗОНИРОВАНИЯ ПОМЕЩЕНИЙ ДЛЯ ОПТИМАЛЬНОЙ ЭКСПЛУАТАЦИИ

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

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

Спецвыпуск 1/2009

Рассмотрим конкретный пример. Нам представлен план 1-ого нежилого этажа среднеэтажного многоквартирного дома. На 1-ом этаже расположен магазин одежды. Конструктивная схема — с неполным каркасом (рис 1).

Рис 1.

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

В данном планировочном решении можно выделить ряд существенных недостатков: слишком большие площади комнаты персонала (20 м2) и холла 36.5 м2), а также проходных витрин (25 м и 21,5 м при площади торгового зала 175 м , при учете расхода этой площади на кассы и примерочные). Количество примерочных (5шт) и их планировочное расположение мы также не находим оптимальным относительно площади торгового зала. Таким образом мы получаем слишком большие площади административно-бытового блока и проходных витрин при недостаточном объеме площадей посетительской зоны.

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

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

Спа! /ой/т//-!/■ 1/9АПС)

Рис 2.

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

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

iНе можете найти то, что вам нужно? Попробуйте сервис подбора литературы.

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

Описание бизнес процессов. Использовать осторожно

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

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

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

Как создается описание бизнес процесса

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

Немного о терминах используемых в данной статье

Прежде чем продолжить необходимо внести ясность в картину происходящего и роли того человека или группы людей в работе по оптимизации.
Сотрудник — сущность представляющая человека или группу людей которые являются источником информации. Сотрудник компетентен в бизнес процессе, не имеет права принятия решения и обыкновенно не компетентен в моделировании.
Бизнес аналитик — сущность представляющая человека или людей которые моделируют бизнес процесс и могут в отдельных случаях предоставлять рекомендации по улучшению бизнес процесса.В большинстве случаев изначально не компетентен в процессе и не имеют права принятия решения.
Руководитель — сущность представляющая человека или группу людей которые ответственны за принятие решения. Руководитель компетентен в принятии решения, и обыкновенно некомпетентен в бизнес процессе и моделировании.
Нотация/бизнес нотация — язык описания бизнес процессов.
Кто нибудь может меня поправить что один человек может быть как хорошим сотрудник так и хорошим бизнес аналитиком. Я сразу скажу что таких людей не видел, да и сложно представить себе человека который был бы одинаково хорош в двух таких друг от друга дисциплинах как бизнес анализ и все деятельность компании.
Для наглядности я предоставляю вам таблицу (последовательность колонок и строк не имеет значения):

Таблица соотвествия сущностей и компетенций
Сущность/Компетенция Знание процесса Бизнес моделирование Принятие решения
Сотрудник *
Бизнес аналитик *
Руководитель *

Зачем нужен приглашенный бизнес-аналитик?

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

  1. Знание бизнес-анализа и умение работать с нотациями.
  2. Информация о работе определенного процесса.
  3. Требования по оптимизации: к какому результату стремится руководство компании.

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

Пример 1. Автоматизация интернет-магазина

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

  • Операторы, которые вручную переносили заказы, полученные с сайта, в систему учета.
  • Складской работник, занимавшийся непосредственно отгрузкой заказов.

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

Пример 2. Автоматизация такси

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

  1. Заказ такси – автоматически, через сайт или приложение без участия диспетчера.
  2. Доставка клиента до места назначения
  3. Оплата – автоматически, с банковской карты или интернет-денег после поездки на основе GPS-данных.

Конечно, при этом в самой службе такси все равно работают люди (операторы техподдержки, специалисты по обслуживанию программного обеспечения и техники, модераторы отзывов и т.д.). Но в описанном выше бизнес-процессе в случае отказа от водителей они перестают принимать участие вообще.
С одной стороны, все получается удобно и выгодно. Нет людей – нет случайных ошибок, затрат на создание рабочих мест и заработную плату.
С другой, если из цепочки полностью исключаются люди, то возникает множество рисков. Что будет, если программа водителя-автомата даст сбой, и человека отвезут не туда? А как робот будет реагировать в случае аварии, особенно, если по причине ДТП повредится какой-то аппаратный узел? А если преступники или террористы решат захватить и использовать робота-такси в своих целях?
Как видите, при всей внешней выгоде исключение из цепочки человека ведет к непредсказуемым последствиям и требует внедрения каких-то защитных механизмов, в результате внедрения которых (или даже не внедрения) компания несет дополнительные расходы, т.е. результат противоположен тому, который планировался.

Основные причины ошибок и проблем

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

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

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

Простое решение проблемы: цените людей

Самый простой и очевидный выход – берегите сотрудников и относитесь к ним гуманно. Определите адекватные нормы работы, не исключайте полностью людей из бизнес-процесса, сократите им число функций, например, пусть они контролируют, проверяют и распечатывают документы или выполняют другие вспомогательные виды работы. Сократите им рабочий день, например, сделайте смены по 6 часов. Люди не будут переутомляться, будут успевать все делать вовремя, процесс будет под контролем.
Конечно, так экономия средств будет меньшей в сравнении с полным отказом от участия в определенных процессах сотрудников. Зато вы гарантированно избежите многих проблем.
При этом снижение нагрузки на сотрудников с высокой вероятностью само по себе принесет вам прибыль. Человек, который не перегружается и успевает хорошо отдыхать, намного лучше работает. Он результативнее, реже совершает ошибки, готов творчески подходить к работе, делать больше и лучше.
Впрочем, это вам подтвердит любой опытный руководитель. Если вынудить человека работать 8 часов подряд без перерывов, то работоспособность его значительно падает. Вынуждать сотрудников работать «на износ» не только негуманно, но и, в большинстве случаев, не выгодно. Люди будут увольняться либо, в определенных случаях, вы будете вынуждены их увольнять, так как они начинают выполнять работу очень плохо, как говорят о таких сотрудниках, «выгорают». Придется тратить время и силы на поиск нового человека, его обучение, и так из раза в раз. Постоянные лояльные компании сотрудники принесут много больше пользы и стоить будут меньше, чем регулярно меняющиеся кадры.

Бизнес моделирование и IT-сфера

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

Бизнес процессы банка

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

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