Бизнес процессы

Содержание

Бизнес-процессы. Часть 2: Вспомогательные процессы

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

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

Я пишу цикл статей о бизнес-процессах и записал сразу два видео-курса: 1) экспресс-курс «Процессный подход к управлению» и 2) методический курс из 4 частей «Как создать систему на основе бизнес-процессов». Вы можете бесплатно подписаться на методический курс с условием выполнения всех практических кейсов курса.

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

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

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

Рекомендую посмотреть видео «Функциональная модель бизнеса». В нем я провожу явную границу между вспомогательным процессом продаж и основным процессом выполнения заказа клиента.

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

  1. Процессы маркетинга
  2. Процессы продаж
  3. Процессы работы с сотрудниками
  4. Процессы учета (бухгалтерского, налогового, управленческого)
  5. Процессы закупки
  6. Производственные процессы
  7. Складские процессы
  8. Логистические процессы
  9. Процессы IT-сопровождения
  10. Административно-хозяйственные процессы

Список может быть еще больше, но какие мысли он вызывает у вас? Попробую угадать. В мыслях у руководителя сразу же возникают отдельные подразделения и должности. Такие связки:

  1. Процессы маркетинга – Отдел маркетинга или маркетолог
  2. Процессы продаж – Отдел продаж, розничная точка или продавец
  3. Процессы работы с сотрудниками – Отдел персонала или HR(эйч-ар как должность)
  4. Процессы учета (бухгалтерского, налогового, управленческого) – Бухгалтерия или бухгалтер
  5. Процессы закупки – Отдел закупки или закупщик
  6. и т.д. по списку

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

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

Если у вас проблема с продажами, что будете делать? Здесь практически, без вариантов. Найдете руководителя отдела продаж или коммерческого директора. Он будет решать эту проблему.

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

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

Это и есть бег по кругу. Берем специалиста с опытом решения наших проблем. Он создает активную «движуху». Он напрягает других людей в коллективе. Вызывает различные формы сопротивления у коллег. Если он ответственный человек, пытается все решить сам в одиночку. Обламывается. Ищет причины и оправдания. Если безответственный, сразу ищет оправдания. Принимаем трудное решение – расстаться! Делаем выводы. Теперь мы точно знаем, какой человек нам… не нужен! Со следующим мы уж точно не ошибемся. И заходим на следующий круг.

Среди наших клиентов, участников бизнес-лагерей, есть предприниматели, которые до работы с нами только за один год умудрились сменить трех-четырех РОПов. Какую пользу компании принес такой путь проб и ошибок? Думаю, всем очевиден убыток равный 12 месяцев х зарплата РОПа. Сколько это будет в цифрах? Для областных центров, по скромному: 12 х 30.000-40.000 рублей = 360-480 тыс. рублей в год, не считая прочих расходов и потерь, которые в разы больше этой суммы. Российские предприниматели еще не научились оцифровывать косвенные потери и упущенные возможности. Конечно, есть исключения. Но именно в таких компаниях-исключениях все считают, не экономят на организации своей деятельности и, как следствие, далеко отрываются от конкурентов. Инвестируешь в бизнес-процессы – экономишь на потерях денег, времени и возможностей.

Инвестируешь в бизнес-процессы – экономишь на потерях денег, времени и возможностей

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

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

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

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

Подходы для определения процесса по сути:

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

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

  • исследование внешней среды;
  • создание нового продукта;
  • продвижение компании и ее продуктов.

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

  • обработка входящих обращений клиентов;
  • ведение (аккаунт) постоянных клиентов;
  • поиск и привлечение новых клиентов.

При работе с персоналом также есть типовые вспомогательные процессы:

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

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

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

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

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

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

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

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

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

Подписаться на рассылку

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

Подпишитесь на получение новых публикаций и видео-материалов!

С уважением, Виктор Лучков
Бизнес-консультант, член Гильдии маркетологов России
Эксперт по созданию систем управления на основе процессного подхода

Источник: http://victorluchkov.ru/articles/biznes-proczessyi.-chast-2/

Определение процессов, бизнес-процессов и их характеристика

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

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

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

 сквозные: проходящие через несколько подразделений (межфункциональные);

 процессы подразделений: деятельность ограничена рамками одного подразделения.

Примеры: процесс производства, процесс продаж, процесс поставок и т.д.

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

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

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

Каждый бизнес-процесс характеризуется:

— эффективностью (доходностью, стоимостью, временем, качеством);

— входом(информация, материалы);

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

— процессом (последовательность операций);

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

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

Рис. 2.8. Упрощенная схема бизнес-процесса.

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

Рис. 2.9. Декомпозиция Процесса в сеть бизнес-процессов.

Если бизнес-процесс представить цепочкой создания добавленной стоимости, то все они делятся на:

-основные бизнес-процессы;

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

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

Рис. 2.10. Жизненный цикл продукции.

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

-бухгалтерские и финансовые процессы, включающие управление наличными средствами, учет дебиторов и кредиторов и прочие операции;

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

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

Пример выделения Основных и Вспомогательных Процессов для крупной организации приведен на Рис. 2.11.

Рис. 2.11. Пример выделения сети процессов для крупной организации.

Источник: https://studopedia.ru/7_29975_opredelenie-protsessov-biznes-protsessov-i-ih-harakteristika.html

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

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

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

Источник: https://habr.com/post/342448/

Процессы: ключевые или сквозные?

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

Определимся с терминами

Традиционно под сквозными бизнес-процессами по­ни­мают такие процессы, которые протекают бо­лее чем через одно структурное подразделение компании.

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

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

Недостатки сквозных процессов

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

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

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

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

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

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

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

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

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

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

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

Как избавиться от сквозных ключевых процессов

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

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

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

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

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

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

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

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

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

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

Например, функция подбора персонала. Как правило, ее считают инфраструктурной. Если HR-подразделение одно на всю компанию, тогда его место — в «горизонтальном» слое. А если функ­ция подбора персонала критична для какого-то ключевого процесса, то логично поместить ее в соответствующее бизнес-подразделение.

Автоматизируй это

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

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

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

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

Источник: https://www.iemag.ru/analitics/detail.php?ID=27478

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

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

Группы бизнес-процессов

Выделяют основные, вспомогательные и процессы управления – это главные группы БП. Как выполняемый единожды уникальный процесс отдельно выделяется БП развития. Направленность БП основной группы:

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

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

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

Процессы управления координируют всю совокупность БП (основные, поддерживающие, БП развития).

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

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

Описание основных БП для производственно-торговой компании (пример):

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

Поддерживающие БП:

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

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

БП развития – совершенствование деятельности, своего рода бизнес-инжиниринг.

Описание и анализ БП

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

Визуализация модели.

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

Как реализуется описание БП

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

1. Текстовое описание.

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

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

2. Табличная форма. Подходит для описания последовательных процессов. Может применяться в качестве переходной к графической реализации в качестве базы данных.

3. Графическое описание в виде моделей и диаграмм.

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

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

Технологии, которые используются для описания БП:

1. IDEF — принята за стандарт практически повсеместно. Integration Definition for Function Modeling –технология моделирования функционала. Поддерживается следующим программным обеспечением – BPWIN, MS Visio и пр. Это совокупность методов моделирования позволяет детализировать БП всех уровней, представляя их как в одном блоке, так и в отдельных схемах.

2. Технологии моделирования используют унифицированный язык моделирования (UML). Он позволяет описывать БП непосредственно на языке понятном компьютерным программам, является средством автоматизации. Поддерживается ведущими разработчиками ПО, основным инструментом для реализации является программное средство Rational Rose от IBM.

3. Диаграммы еЕРС (extended Event-Process Chain). Благодаря им, есть возможность отобразить последовательность операций, участников, используемые ресурсы, отображая состояние на текущий момент времени.

4. Технология ARIS (Architecture of Integrated Information Systems) используется как встроенный инструмент в одну из крупнейших систем автоматизации – SAP R/3.

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

Алгоритм действий при моделировании:

1. Определение целей для описания БП. Подготовка к моделированию, выбор модели. Так как модель составляется для непосредственно практического использования, то цели такого описания должны согласовываться с будущими перспективами. Описанию подлежат все бизнес-процессы – основные, вспомогательные (поддерживающие), управленческие, развития.

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

3. Описание функционального содержания БП. Подразумевает описание всех зон ответственности для каждого из подразделений или должности в организации.

4. Описание БП потоков и их структуры. Определяется целями, которое оно преследует. Если необходимо улучшить информационную систему, тогда описываются потоки информации, документооборот и т.п., если цель распределить правильно финансы – тогда финансовый поток и БП в них.

5. Построение, в зависимости от предпочтений и целей, текстовой, графической модели либо диаграммы.

6. Составление последовательности действий в БП. Определение последовательности исполняемых функций, условий исполнения, а также параметров, которые определяют именно такой алгоритм.

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

Источник: https://hr-portal.ru/blog/opisyvaem-biznes-processy-organizacii

Вспомогательные бизнес-процессы

⇐ Предыдущая12345

БП 7. Поддержание инфраструктуры компании

o Планирование и финансирование деятельности

o Учет и администрирование деятельности

o Информационное и юридическое обеспечение

БП 8. Управление человеческими ресурсами

o Подбор и найм персонала

o Обучение персонала

o Мотивация и оплата труда

БП 9. Развитие технологий

o Проведение рыночных исследований

o Проектирование и разработка новых продуктов

o Совершенствование внутренних технологий/процессов

На рисунке приведено дерево бизнес-процессов модели цепочки добавления ценности.

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

Тринадцати процессная модель разработана Американским центром производительности и качества (American Productivity&Quality Center). Эта модель включает процессы, приведенные на рисунке 1.

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

Тринадцатипроцессная модель примечательна тем, что выделяется всего 13

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

Эти 13 процессов общие для всех компаний.

Основные процессы

БП 1. Изучение рынков и потребителей
БП 2. Разработка видения и стратегии
БП 3. Разработка продуктов и услуг
БП 4. Маркетинг и продажи
БП 5. Производство и поставка продуктов и услуг (производственные компании)
БП 6. Производство и поставка продуктов и услуг (сервисные компании)
БП 7. Выставление потребителям платежных требований и сервис

Вспомогательные процессы

БП 8. Профессиональное и карьерное развитие кадров и управление кадрами

БП 9. Управление информационными ресурсами и технологиями

БП 10. Управление финансовыми и материальными ресурсами

БП 11. Исполнение программы управления охраной внешней среды

БП 12. Управление внешними связями

БП 13. Управление улучшениями и изменениями 2. Ключевые бизнес-процессы в цепи поставок

Существует 8 ключевых бизнес-процессов в цепи поставок:

1. управления взаимоотношениями с потребителями:

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

2. обслуживания потребителей:

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

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

3. управления спросом:

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

4. управления выполнением заказов:

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

5.управление производством/операциями.

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

6. управления снабжением:

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

⇐ Предыдущая12345

Дата добавления: 2017-02-25; просмотров: 642 | Нарушение авторских прав

Рекомендуемый контект:

Похожая информация:

Поиск на сайте:

Источник: https://lektsii.org/15-19957.html

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

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

Рис. 8.1. Анализ бизнес-процессов как составная часть работ

по их улучшению

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

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

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

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

Таблица 8.2

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

Вид анализа

Характеристика

Качественный анализ

Анализ непрерывности процесса

Анализ операций процесса и их последовательности

Анализ ресурсного обеспечения процесса

Анализ руководителей и исполнителей процесса, входящей и исходящей информации, материальных, технических и ИТ-ресурсов

Анализ соблюдения требований к реализации процесса

Анализ соответствия всех действий и используемых ресурсов нормативным правовым и иным регламентирующим документам

SWOT-анализ

Анализ сильных и слабых мест в бизнес-процессе

Количественный анализ

Анализ результатов мониторинга выполнения процесса

Анализ показателей эффективности

Анализ результатов имитационного моделирования

Анализ динамики выполнения процесса, результатов расчета стоимостных характеристик процесса

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

Рис. 8.2. Процесс обработки входящего документа

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

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

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

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

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

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

В рамках анализа входов и выходов изучаются два основных аспекта: 1) потребность во входах и выходах; 2) выявление неиспользуемых выходов .

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

Рис. 8.3. Выдержка из процесса «Совершенствование продукта»

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

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

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

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

Такой последовательный анализ входов/выходов процессов позволяет также выявить неиспользуемые входящие и исходящие ресурсы. Например, в вышеописанном примере процесса обработки входящих документов (см. рис. 8.2) рассматривались операции копирования входящего документа. Как известно, копии создаются для того, чтобы в случае утери подлинника можно было восстановить ход работы по обработке и выполнению документов. В результате анализа выходов данного процесса возникает вопрос: «Кто является потребителем документов “Копия входящего документа” и “Копия входящего документа с резолюцией”?» Очевидно, что потребитель в данном случае один и ему достаточно одной последней копии. А их две. Значит, один из этих двух документов в качестве выхода/входа не будет использоваться в других процессах, т.е. он — лишний. На данном примере показана ситуация, которая часто встречается в разных компаниях, где создается много документов, которые не используются или используются только потому, что по регламенту их нужно принять и «подкрепить» в дело, однако никакой реальной потребности в них нет.

Для поиска неиспользуемых выходов В. В. Репин и В. Г. Елиферов рекомендуют использовать таблицу, приведенную ниже (табл. 8.3).

Таблица 8.3

Поиск неиспользуемых выходов процесса

Название процесса (операции)

Название исходящего документа

Документ 1

Документ 2

Процесс 1. Операция 1.1

Операция 3.1

Не используется

Процесс 2. Операция 2.5

Операция 10.4

Операция 4.2

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

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

Анализ соблюдения требований к реализации процесса осуществляется в целях выявления соответствия реальному выполнению бизнес-процесса требованиям и нормам, предъявляемым к нему. Любая деятельность компании в той или иной степени регулируется различными законодательными, нормативно-правовыми и организационно-распорядительными актами. Как правило, во внутренних нормативно-правовых и организационно-распорядительных актах, стандартах, регламентах и инструкциях учитываются требования законодательства РФ.

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

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

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

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

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

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

Таблица 8.4

SWOT-анализ процесса

Сильные стороны

Слабые стороны

Наличие квалифицированного персонала

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

Качественные инструменты и расходные материалы, косметика

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

Возможности

Угрозы

Повышение уровня удовлетворенности клиентов за счет введения системы скидок

Потеря клиентов в связи с изменением используемых косметических средств

Снижение накладных расходов за счет изменения поставщиков косметики

Потеря клиентов в связи с увольнением ключевых работников

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

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

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

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

• показатели качества:

критические показатели — устанавливают соответствие продукции требованиям безопасности и действующему законодательству;

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

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

производительность — показатель объема производства на единицу положенных ресурсов;

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

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

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

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

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

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

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

Таблица 8.5

Примеры количественных показателей процесса

Катего

рия

Абсолютные показатели

Относительные показатели

Время

І Іродолжительность выполнения процесса; длительность простоев; время выполнения каждой операции процесса

Показатели план/факт (плановое/фактическое время выполнения процесса); показатели сравнения (среднее время выполнения процесса/среднее время выполнения процесса в компании конкурента); удельные показатели (время выполнения процесса/количество исполнителей процесса)

Техноло

гия

Количество используемых ПК; количество участников процесса; число обращений к базе данных за один цикл реализации процесса

Показатели план/факт (плановое/фактичeское количество транзакций); показатели сравнения (количество участников процесса/количество участников процесса в компании конкурента); удельные показатели (офисная площадь на одного работника)

Стои

мость

Стоимость реализации процесса; расходы на: оплату’ труда, материалы, амортизацию используемого оборудования; стоимость продукта/услуги

Показатели план/факт (плановая/фактическая стоимость реализации процесса); показатели сравнения (расходы на оплату труда/расходы на оплату труда в компании конкурента); удельные показатели (рентабельность = прибыль от реализации процeсса/стоимость реализации процесса)

Качество

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

Показатели план/факт (плановое/фактическое количество жалоб клиентов); показатели сравнения (количество дефектных продуктов/количество дефектных продуктов в компании конкурента); удельные показатели (количество жалоб/общее количество клиентов)

Примечание. Таблица подготовлена по материалам В. В. Репина, В. Г. Елиферова.

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

  • • анализ результатов моделирования временных характеристик процесса и параметров ресурсов (анализ динамики выполнения процесса);
  • • анализ результатов расчета стоимостных характеристик процесса (ABC-анализ, пооперационный расчет стоимости).

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

Для справки

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

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

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

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

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

Таким образом, с помощью анализа, в частности, определяют следующие показатели:

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

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

  • ГОСТ ISO 9000—2011. Межгосударственный стандарт. Системы менеджмента качества. Основные положения и словарь.
  • Репин В. В.. Елиферов В. Г. Процессный подход к управлению. Моделирование бизнес- процессов.
  • ГОСТ ISO 9000—2011. Межгосударственный стандарт. Системы менеджмента качества. Основные положения и словарь.
  • Баландин Е. С., Юдаева В. Г. Международные стандарты ИСО серии 9000—2000: Методические рекомендации по применению. Ульяновск, 2003.
  • Снетков Н. Н. Имитационное моделирование экономических процессов : учебно-практическое пособие. М.: Издательский центр ЕАОИ, 2008.

Источник: https://studme.org/87206/ekonomika/metody_analiza_biznes-protsessov