бизнес процесс история возникновения
Что такое бизнес-процессы предприятия
Бизнес-процесс (сокращенно БП) — комплекс процедур и задач по конструированию, производству и реализации материальных ценностей или услуг для определенной целевой аудитории потребителей или одного заказчика. Понятие заключает в себе алгоритм действий, что начинается с поступления запроса в компанию и заканчивается продажей готовых продуктов.
История понятия бизнес-процесса
Самое раннее упоминание встречается в рукописях экономиста Адама Смита, вышедших в печать в 1776 году. Специалист описал случай распределения сложной процедуры создания штифтов на контактном заводе. С разделением задач между сотрудниками производительность увеличилась на 24 000%. Смит отстаивал пользу разумного упрощения сложных процедур. Уровень распределения получен экспериментально, через проектирование БП. Идея Смита получила широкое признание.
В XX веке американским инженером Фредериком Тейлором разработаны научные методики управления предприятиями, что способствовали стандартизации распределения задач в целях оптимизации деятельности организации. К концу XX века известный гуру менеджмента Питер Друкер провел работу по упрощению и децентрализации производства. Появилась популярная концепция аутсорсинга.
Виды бизнес-процессов
Простая схема БП
Запрос клиента > оператор call-центра (фиксация заявки)> менеджер (обработка > логист (движение, доставка, перевозка материалов) > бухгалтер (анализ расходов, формирование счета) > п роизводство > ОТК (проверка качества) > реализация.
Классификация БП выглядит так:
Алгоритм конструирования бизнес-процессов
Алгоритм может выглядеть сложнее. Для крупных производственных комплексов при определении, что такое бизнес-процесс, как будут регулироваться его процедуры, используют стандарт-модели, что проектируются и корректируются на специально разработанном программном обеспечении.
Помощь в оптимизации бизнес-процессов, интеграции с существующими системами, IT-решения и многое другое для развития и продвижение бизнеса сможете найти в компании Polytell.
Разрыв в процессе – потерянные деньги
Частая причина снижения деятельности – отсутствие слаженных действий всех звеньев промышленной цепи. Здесь могут быть трудности с логистикой, недобросовестное отношение к обязанностям сотрудников ОТК. Работники и крупные отделы должны действовать слаженно и эффективно. Для оценки проводятся тестирования, опросы, прочие исследования, анализ, корректировки.
Управление БП с помощью компьютерных технологий
Достижения последних десятилетий в сфере IT скорректировали привычные процессы. В середине XIX века программное обеспечение имело ограниченные ресурсы для администрирования деятельности предприятий. Сегодня это мощные системы, что дают серьезные перспективы для максимально эффективной автоматизации БП: SAP, Oracle, PeopleSoft. Разработаны протоколы и веб-язык, модели коммерческой мотивации для конструирования, коррекции и управления бизнесом или графические изображения для визуального отображения блок-схем, диаграмм.
Анализ и автоматизация активных рабочих моделей
На деятельность компаний оказывают значительное влияние инновации в сфере облачных технологий, запросы социальных медиа, мобильные приложения. Они позволяют участникам рынка приобретать, продавать ресурсы, организовывать коммуникацию независимо от расположения. Новые каналы связи, соцсети, сайты, электронные СМИ дают возможность привлечения потенциальных потребителей, удобно анализировать спрос и предложение, молниеносно взаимодействовать с целевой аудиторией через инструменты e-mail маркетинга.
Важна роль отчетов для организации эффективной деятельности предприятий. Периодический системный анализ (мониторинг) отклонений, что появляются по мере реализации процессов в различных подразделениях (цехах, бухгалтерии), помогает вовремя среагировать на снижение производительности и предпринять корректирующие шаги. Статистические данные позволяют легко оценивать ситуацию и делать выводы. Оптимизация и анализ рабочих процедур максимально эффективны при автоматизации предприятий.
Корректировка бизнес-процессов
Дающий большие перспективы в плане эффективной оптимизации коммерческой деятельности системный метод появился в 1991 году. Технология описывается в книге г. Джеймса Харрингтона. Суть метода в реорганизации и реинжиниринге БП. Они направлены на поиск отклонений, анализ, улучшение коммерческой деятельности в рамках новых задач и целей, увеличение рентабельности и производительности, сокращение расходов.
Алгоритм методики складывается из трех задач:
Оптимизация БП:
Цель оптимизации по Джеймсу Харрингтону по-своему радикальна. Она заключается в кардинальной перестройке, а не серии постепенных реструктуризаций. Такая модель описана в книге Майкла Хаммера и Джеймса Чампи «Реинжиниринг корпорации: манифест бизнес-революции», выпущенной в 1993 году. Многие предприятия решаются применить систему, какие-то отказываются от радикальной методики. Но те и другие считают оптимизацию БП ценным инструментом для увеличения эффективности.
Автор: Андрей Серов Бизнес-консультант, главный редактор Ктовделе.
Работал юристом, руководил отделением Сбербанка, инвестировал в строительный и ритейл бизнес.
Краткая история управления бизнес-процессами
Краткая история управления бизнес-процессами
Путь к управлению бизнес-процессами (BPM) был труден, на нем вбирался опыт разнообразных удачных и неудачных попыток добиться эффективности организации за счет опоры на процессы.
Возможно, стоит посвятить несколько строк очень краткой новейшей истории управленческой ориентированности на бизнес-процессы.
В 80-х годах прошлого века значительное внимание привлекало полное управление качеством (TQM – Total Quality Management), за которым в начале 90-х годов последовал реинжиниринг бизнес-процессов (BPR – Business Process Reengineering), пропагандировавшийся М. Хаммером (Hammer) и Дж. Чампи (Champy). Довольно пестрая история концепции реинжиниринга знает примеры блистательных успехов и сокрушительных провалов.
Следующей громкой концепцией, пришедшей на смену реинжинирингу в середине – конце 90-х годов, стало планирование ресурсов предприятия (ERP – Enterprise Resource Planning). Предполагалось, что системы ERP обеспечат усовершенствованные способы управления функционированием организаций, и многие поставщики утверждали, что такие системы «решат все ваши проблемы». Разумеется, системы ERP не решали проблем процессов, как не обеспечивали возможной эффективности и производительности процессов. В конце 90-х годов и в начале нового века получили распространение различные системы управления взаимоотношениями с клиентами (CRM – Customer Relationship Management), в которых главный упор делался на профиль клиента, его «послужной список» и опыт. Хотя здесь центр внимания смещался на службы, непосредственно работающие с клиентами (фронт-офис), процессы служб обеспечения (бэк-офиса) при этом не улучшались. Совсем недавно стала получать признание и распространение концепция «Шесть сигм».
По словам М. Хаммера <24>, «выдвинуть идею просто, трудно добиться результата. Реформы вязнут и погибают в окопах». А кто сидит в «окопах»? Вы, я и все остальные люди. Реформы, навязываемые «людям в окопах», не преуспеют, если они оторваны от эволюционного или революционного процесса:
Волевое лидерство имеет свои пределы. Переход от бюрократии машинного века к гибким, самоуправляемым группам требует психологической подготовки огромных масс обычных менеджеров и рядовых сотрудников.
Данный текст является ознакомительным фрагментом.
Продолжение на ЛитРес
Читайте также
Краткая история произошедшего
Краткая история произошедшего Даже теперь, когда новые вызовы, с которыми мы столкнулись, стали понятны, остается открытым вопрос: почему это случилось? Ведь считалось, что рыночная экономика не должна работать подобным образом. Но что-то пошло не так, причем совсем не
Глава 6. Органы управления бизнес‑процессами и организация работы специалистов
Глава 6. Органы управления бизнес?процессами и организация работы специалистов Поддержание процесса в рабочем состоянии Наступает этап, когда вы, возможно, решите, что для запуска преобразований на основе процессов все готово. Вам посчастливилось заполучить как
Политика управления бизнес‑процессами
Политика управления бизнес?процессами Буквально каждая компания провозглашает важность командной работы и беспристрастное отношение ко всем ее участникам. При этом ничего не делается ни для того, ни для другого. Одна из главных функций органов управления
Что можно и чего нельзя делать при построении органов управления бизнес‑процессами и организации работы специалистов
Что можно и чего нельзя делать при построении органов управления бизнес?процессами и организации работы специалистов • В состав органов управления бизнес?процессами должны входить все руководители процессов. Тогда они будут понимать, как изменения влияют на
Глава 12 Краткая история IBM
Глава 12 Краткая история IBM Прежде чем мы поговорим о том, как создавалась новая IBM, думаю, будет полезно понять в общих чертах, как IBM стала великой компанией, которую большинство из нас почитало до начала 1990-х гг., и что обусловило, по крайней мере на мой взгляд, ее
КРАТКАЯ ИСТОРИЯ ОРГАНИЗАЦИОННОГО РАЗВИТИЯ
КРАТКАЯ ИСТОРИЯ ОРГАНИЗАЦИОННОГО РАЗВИТИЯ Истоки ОР Истоки организационного развития можно найти в работе Курта Левина, который разрабатывал понятие динамики группы (термин впервые употреблен в 1939 г.). Это понятие связано с тем, каким образом группа развивается и как
Краткая история BPM
Краткая история BPM Вряд ли нова мысль о том, что на работу можно посмотреть как на процесс и затем совершенствовать его. Она зародилась еще на пороге прошлого столетия у Фредерика Тейлора (Frederick Taylor), а скорее всего, еще раньше. Ф. Тейлор с соратниками разработали
Глава 1 Как развенчать миф о загадочности управления бизнес-процессами
Глава 1 Как развенчать миф о загадочности управления бизнес-процессами Краткая история управления бизнес-процессами Путь к управлению бизнес-процессами (BPM) был труден, на нем вбирался опыт разнообразных удачных и неудачных попыток добиться эффективности организации
Управление бизнес-процессами как составная часть «управления»
Управление бизнес-процессами как составная часть «управления» Данный тип управления должен обеспечить реализацию целей бизнеса и стратегии организации. Такое управление осуществляется линейным руководством (или хозяевами бизнес-процессов), и его нельзя поручить
Глава 6 Почему стратегия организации и архитектура процессов важны для управления бизнес-процессами
Глава 6 Почему стратегия организации и архитектура процессов важны для управления бизнес-процессами Первый вопрос, который предприятие должно поставить в начале любого проекта BPM, – это вопрос о целях и задачах процессов. Ответ часто бывает уклончивым – да, пока эти
Глава 7 Как убедить организацию принять технологию управления бизнес-процессами Фритц Буссемейкер (Frits Bussemaker)
Глава 7 Как убедить организацию принять технологию управления бизнес-процессами Фритц Буссемейкер (Frits Bussemaker) Хотя многие практики BPM внутри организации открыли для предприятия существенные преимущества в использовании решений автоматизации бизнес-процессов, этим
Кому нужна технология управления бизнес-процессами
Кому нужна технология управления бизнес-процессами Выше уже отмечалось, что в принятие технологии вовлечены как бизнес-подразделения, так и ИТ организации. Поскольку процессы присутствуют везде, это также подразумевает, что любой бизнес-менеджер может увлечься
Кто продвигает технологию управления бизнес-процессами
Кто продвигает технологию управления бизнес-процессами Можно назвать следующие три силы, продвигающие решение автоматизации управления бизнес-процессами:1. Силы внутри предприятия.2. Поставщик программного обеспечения.3. Системный интегратор и/или консультант.Во
Зрелость управления бизнес-процессами
Зрелость управления бизнес-процессами Управление бизнес-процессами – это сложная практика, которая во многих организациях оказалась трудной для внедрения и доведения до высоких стадий зрелости. Это подтверждается исследованиями, показывающими, что 97 % опрошенных
Сверочный список выбора инструментального средства моделирования и управления бизнес-процессами
Сверочный список выбора инструментального средства моделирования и управления бизнес-процессами Опасности при выборе инструментария и управления процессами Подходящее для организации средство моделирования и управления процессами нельзя выбирать исключительно по
Краткая история денег
Краткая история денег Развитие денег и обретение ими разнообразных форм важны потому, что одна из причин царящего ныне беспорядка заключается в том, что слово «деньги» превратилось во всеобъемлющее название ошеломляющего количества кредитных инструментов и валют.
История бизнес-моделирования
Виктор Волонтей
Управляющий партнер и руководитель компании «Правила бизнеса»
В статье рассмотрены основные понятия и краткий обзор истории как подхода к управлению организацией.
Основные необходимые понятия
— процесс описания той или иной сферы деятельности организации с использованием четкого формализованного подхода (методологии), поддерживаемый специализированным программным продуктом.
Организация — группа людей и средств с распределением ответственности, полномочий и взаимоотношений. Пример: компания, корпорация, фирма, предприятие, учреждение, благотворительная организация, предприятие розничной торговли, ассоциация, или же их части, или комбинации из них (ISO 9000:2005).
Модель — модель М моделирует объект, А, если модель М отвечает на вопросы относительно объекта А. Пример: карта города является его моделью, выполненной в определенном масштабе с использованием условных обозначений.
История
1 этап: годы XX века
В годы прошлого века начались реализация сложных крупномасштабных проектов совместно специалистами различных предметных областей (системы вооружения, полеты в космос, атомные электростанции, транспортные сети ), произошло достаточно серьезное изменение условий функционирования как коммерческих так производственных компаний. Анализ проблем возникающих в деятельности организаций, привел к тому, что они стали рассматриваться как системы, включающие:
Это в свою очередь вызвало необходимость в разработке адекватных способов этих элементов в структурированном связном виде. Минимальные требования, которым должно было отвечать описание организации, следующие:
Одной из самых известных методологий описания организаций как систем, стала методология структурного анализа и проектирования систем SADT (Structured Analysis and Design Technique). Она была разработана американцем Дугласом Россом (D. Ross) в 1973 г. Особенно широкое применение получило одно из подмножеств SADT методология функционального моделирования IDEF0 (Integration Definition For Function Modeling). Инициатором ее разработки и дальнейшей стандартизации было Министерство обороны США. Методология IDEF0 успешно применялась в военных, коммерческих организациях для решения широкого спектра задач (от разработки программного обеспечения для оборонных систем до разработки систем снабжения и управления финансами). Наличие возможностей и опыт применения IDEF0 в различных предметных сферах, наряду с растущей компьютерной поддержкой сделало ее еще более доступной в использовании. Это в свою очередь, также привело к широкому использованию IDEF0 как методологии для описания организаций.
Во многом популярность методологии функционального моделирования IDEF0 обусловлена простотой нотации, основными элементами которой является функциональный блок и стрелка.
Каждая из четырех сторон блока имеет строго определенное значение:
Исходя из смыслового значения сторон блока, процесс в общем виде можно определить как деятельность (последовательность работ), которая преобразует Входы в Выходы по правилам и требованиям, уставленным Управлением, с помощью определенных Механизмов (ресурсов).
2 этап: годы XX века
Мощнейший импульс дальнейшему развитию методов описания деятельности организаций придало широкое внедрение персональных компьютеров, а также разработка информационных систем (или систем автоматизации) компаний различных предметных областей. Потребность в автоматизации в свою очередь вызвала необходимость их описания и формализации (читай моделирования) на принципиально другом уровне.
В зависимости от целей, стоящих перед специалистами по автоматизации, было разработано достаточно большое число методологий для описания деятельности организаций, самые известные из которых:
Каждая из методологий (нотаций) в силу имеющих место ограничений оптимально решала ту или иную задачу, стоящую перед специалистами по автоматизации.
Бурное развитие информационных технологий в 80 г.г., рост объемов разработки наряду со все более острой необходимостью проектирования «правильного» программного обеспечения «с первого раза», привело к созданию целого отдельного направления программотехники ( Software/System Engineering).
3 этап: годы XX века
В начале годов на Западном рынке появились первые программные продукты, предназначенные для решения задач, связанных с организационными вопросами управления организациями. Этому способствовало:
, построенная с помощью программ класса «BMS», как правило, включает:
4 этап: 2000 г.г. XXI века, и до настоящего времени
Существующая динамика изменений внешней выдвигает новые требования к проведению соответствующих им внутренних изменений. Скорость проведения изменений, улучшений во многом определяется возможностями анализа того или иного аспекта деятельности организации, или организационная структура. Наличие навыков проведения внутренних изменений, их системное применение являются необходимым условием выживаемости и успешности компании. Моделирование является тем инструментом, который позволяет облегчить проведение внутренних изменений, улучшений на уровне соответствующем сложности этой задачи.
Список источников
Что такое бизнес-процесс и описание бизнес процесса
И, тем не менее, ум человеческий тщетно пытался постигнуть ее в течение более чем 2 000 лет, между тем как, с другой стороны, ему удался, но крайней мере приблизительно, анализ гораздо более содержательных и сложных форм. Почему так? Потому что развитое тело легче изучать, чем клеточку тела. К тому же при анализе экономических форм нельзя пользоваться ни микроскопом, ни химическими реактивами. То и другое должна заменить сила абстракции.
Карл Маркс. Капитал. Том 1. Предисловие к первому изданию.
О бизнес-процессах говорят много и часто преимущественно в связи с автоматизацией бизнеса. Использую этот термин и я, в том числе, в своих статьях, посвященных CRM-системам, ERP, работе с BPMN-нотациями, IDEF0 и других инструментов, которые могут понадобиться в работе бизнес-консультанта и внедрении систем автоматизации. При этом в Рунете понятное и развернутое определение термина «бизнес-процесс» я не нашел.
Многие авторы используют его «по умолчанию», как термин «интуитивно понятный» без расшифровки, либо вообще вносят дополнительную путаницу использованием альтернативной терминологии, например, пишут вместо бизнес-процесса «бизнес сущность» и т.д.
В этой статье я решил поговорить о том, что такое бизнес-процесс, рассказать об истории появления этого понятия и о том, где его можно и нужно применять. Также я планирую посвятить теме бизнес-процессов следующую статью, в которой расскажу, как правильно использовать бизнес-процессы.
Определение бизнес-процесса
Итак, в чем же разница между бизнес-процессом и функций или даже просто обычным процессом? В чем разница между этими терминами? Я пришел к следующему выводу:
Бизнес-процесс – это логическая последовательность действий человека (или нескольких человек) в коллективе. Цель описания бизнес-процесса – анализ и регламентация тех или иных действий в коллективе.
Почему я делаю особый упор на людях и коллективе:
Описание бизнес процесса
Также важно дать определение описанию бизнес процесса:
Описание бизнес-процесса – это описание последовательности действий сотрудников при выполнении определенных действий в графическом и текстовом виде с целью регламентации действий в коллективе, анализа и оптимизации их последовательности.
И здесь необходимо понимать, что бизнес-процесс без описания не существует. Только в процессе описания появляется бизнес-процесс, т.е. невозможно реализовать одно без другого.
При этом все действия, которые описываются в бизнес-процессе, должны быть логичными, их последовательность должна приводить к определенной поставленной ранее цели.
Описание бизнес-процессов – работа творческая. Даже если вы описываете «то, что есть», все равно допускаются некоторые неточности, «сглаживаются» углы, какие-то действия упускаются для простоты восприятия. А если описывается «то, что должно быть», то здесь на основе существующего создается нечто новое. При этом бизнес-аналитик все же ограничен строгими рамками – правил, синтаксиса, логических ограничений.
Лично я сравниваю создание нового бизнес-процесса с балансированием на тонкой нити гармоничного сочетания творчества, искусства и строгой математики.
При этом нужно понимать, что ни один бизнес-процесс не может быть совершенным и на 100% соответствовать реальности. Всегда есть место каким-то упрощениям и допущениям, где-то при реализации даже самого строгого регламента свои коррективы вносит человеческий фактор.
Кроме того, как известно, в любой новой сущности всегда заложена возможность дальнейшего совершенствования. И создание бизнес-процессов также подтверждает этот философский тезис. Как бы вы ни старались описать бизнес-процесс идеально, все равно в нем найдется что-то такое, что также можно улучшить либо сейчас, либо – в будущем.
И здесь очень важно с одной стороны, вовремя остановиться самому, ведь обновленные бизнес-процессы будут реализовывать реальные люди, которые привыкли работать «по старинке», и нужно учитывать их косность мышления и степень обучаемости. Также и автоматизация, которая обычно входит в модернизацию бизнес-процессов, требует определенных вложений. И здесь нужно исходить из реальных возможностей заказчика.
Все это бизнес-консультант должен четко понимать сам, знать, где и на каком уровне допущений он упростил описание бизнес-процесса, а где решил отложить на будущее какие-то решения по объективным причинам (финансы, человеческий фактор). И все это нужно уметь просто и понятно объяснить руководителю бизнеса.
Технологический процесс и бизнес-процесс
Главное отличие бизнес-процесса от технологического заключается в том, что в технологическом процессе на выходе предполагается один вполне определенный результат. Например, если речь идет о производстве, то на выходе должна получиться продукция с определенными параметрами.
Конечно, даже в технологическом процессе существует вероятность получения брака, но не один из закономерных вариантов, а последствия нарушения технологического процесса. В то время как в бизнес-процессе результат «на выходе» может отличаться в зависимости от выполнения тех или иных условий в «теле» бизнес-процесса, который выполнялся без нарушений и сбоев.
Для наглядности описание технологического процесса может выглядеть таким образом:
В бизнес-процессе вполне нормальной считается следующая ситуация:
История появления термина
Я не единожды читал информацию о том, что нотации бизнес-процессов IDEF0 появилось чуть ли ни в середине XIX века. Более реалистичные авторы пишут о периоде Второй Мировой войны. Но и они ошибаются.
Например, когда я написал статью об IDEF0, некоторые читатели в качестве примеров нотаций приводили примеры каких-то инструкций из министерств и ведомств времен Первой Мировой или даже раньше, а в качестве графического отображения обсуждались схемы и наглядные изображения военных действий. Но все это не является описанием бизнес-процесса. Все вышеперечисленное можно назвать методиками, наглядной демонстрацией, инструкциями, но нельзя назвать нотациями.
Нотации – понятие современное, причем, нотациями называется нечто устоявшееся, стандартизированное, т.е. набор команд и обозначений, которыми пользуется много людей, а не одна или две организации. Можно придумать свой особый язык для описания бизнес-процессов или, например, программирования. Но пока он не получит «обкатку» в массовом использовании, не будут выявлены и устранены противоречия, неоднозначные трактовки, другие недочеты, пока он не стает устоявшимся и привычным для людей стандартом, называть его нотацией нельзя. Подробнее о нотациях я планирую написать позже. А сейчас вернемся к вопросу появления термина «бизнес-процесс».
На самом деле описание бизнес-процессов и нотации BPMN появились в 70-е годы XX века, когда повсеместно начали использоваться информационные системы. И сам термин, и нотации понадобились изначально именно для разработки информационный систем.
Дело в том, что после начала применения информационных систем сложность организации работы людей в организациях увеличилась во много раз. Кроме того, машины не понимают абстракции, им требуется строгий алгоритм и определенный порядок введения и обработки информации. Если до начала автоматизации, когда информация переходила непосредственно от человека к человеку, проблема взаимопонимания находилась на уровне человеческих коммуникаций, то теперь появилась необходимость ее строго регламентировать.
В результате понадобилось создавать описания работы не только людей в организации, но также их взаимодействия с информационными системами. И здесь стало недостаточно текстовых нотаций (инструкций), где все описания были в свободной текстовой форме, они оказались не актуальны и неудобны. Появилась потребность в стандартизации, по сути, в создании особого языка команд и однозначной последовательности действий. Причем, в отличие от машинных языков, эти нотации должны были стать одинаково удобными для перевода в машинный код, и для восприятия человека.
Первые методологически проработанные нотации бизнес-процессов (а я буду говорить именно о методологически проработанных нотациях, например, IDEF3***) появились у военных в США. Причина очевидна – уже тогда военные в США пользовались автоматизацией с использованием удаленных соединений, т.е. той самой системой, которая позже стала Интернетом. И при таком уровне применения информационных систем потребность в нотациях бизнес-процессов была особенно актуальной.
***По теме методологически проработанных нотаций хочу также сказать пару слов. Почему я привел в качестве примера IDEF3: я еще не видел более проработанной методологически системы описания бизнес-процессов. Даже BPMN 2.0 все еще развивается и дорабатывается. А если вы почитаете англоязычное описание IDEF3 (перевода на русский я пока не видел), то также сумеете оценить по достоинству глубину его проработки.
Очень быстро методология и нотации завоевали огромную популярность в бизнес-среде.
Нотации позволили получить инструмент описания взаимодействия людей и цифровых информационных систем.
С их помощью оказалось возможным оптимизировать бизнес, т.е. получить более высокую производительность при тех же затратах.
Особенно заинтересовала бизнес возможность оптимизации. Как известно, чтобы что-то улучшить, нужно четко понимать, что вы имеете, и что из этого вы желаете изменить. И графические нотации наглядно показывали обе ситуации – отправная точка и желаемый результат, а также наиболее проблемные области. На основе этих данных выбрать оптимальный путь решения и смоделировать оптимальный вариант модернизации оказалось намного проще, чем без столь удобных инструментов.
Именно тогда появились понятия бизнес-процессов и нотаций бизнес-процессов, два неразрывно связанных понятия.
Очень важно понимать, что не существует, например, отдельного «бизнес-процесса продажи». Есть процесс продажи, который станет бизнес-процессом, если его описать при помощи нотации. Т.е. без описания в нотации бизнес-процесса вы занимаетесь продажами, это никто не оспаривает. Но пока нет определенного незыблемого и однозначного описания ваши продажи – явление, в чем-то, стихийное. А бизнес-процессом они станут только после их описания в рамках нотации и реализации этого описания на практике.
Продажи – это самый простой и наглядный пример. Каждый из нас в роли покупателя, а многие, и в роли продавца знакомы с этим процессом. И все мы знаем, что даже один и тот же человек в разных ситуациях (для разных товаров, разных покупателей, в разную погоду и вообще, в зависимости от настроения) будет продавать несколько по-разному. Но если описать и четко регламентировать определенный бизнес-процесс, то независимо от того, «с какой ноги встал утром продавец», процесс продажи будет определенным образом стандартизирован, ограничен определенными рамками, и, в результате, более стабилен.
Зачем моделировать (описывать) бизнес-процессы
Как я уже не единожды писал, я работаю преимущественно с малым и средним бизнесом, где предоставляю широкий комплекс услуг – от выявления проблем и «узких мест» в работе компании до внедрения предложенных мною решений на уровне программных продуктов и систем автоматизации.
Моделирование бизнес-процессов помогает решить сразу две задачи:
Бизнес-процессы необходимы, чтобы представить сложную информацию в простой для восприятия форме для изучения и принятия решения.
Представьте себе обычную компанию, состоящую из разных подразделений: бухгалтерия, кадры, отдел продаж, склад, доставка, производство и т.д. Над всем этим стоит один человек – руководитель бизнеса. Он физически не может на экспертном уровне понимать все виды процессов в бизнесе. Именно потому и нанимают различных специалистов. Но ему необходимо эффективно всем этим управлять, а в определенных случаях – модернизировать.
И здесь на помощь приходят бизнес-процессы. При этом определенные виды человеческой деятельности в рамках компании описываются графическими нотациями и представляются в том виде, который помогает руководству понять, как именно происходит работа на каждом из этапов, и что здесь можно улучшить. При этом руководителю компании не обязательно обладать высокой квалификацией специалиста того или иного профиля.
Конечно, на этом уровне не обойтись без некоторых информационных потерь. Невозможно описать графической нотацией все нюансы и подробности работы каждого сотрудника. Но эти информационные потери оказываются несущественными для понимания процессов в общем и принятия решения.
Как описывать бизнес-процессы
Для того чтобы получить описание реально действующих бизнес-процессов, достаточно просто внимательно изучить последовательность действий каждого сотрудника. Т.е. необходимо получить информацию о входящих данных для запуска определенного процесса, исходящих – т.е. результата действий сотрудника, а также пошагово зафиксировать действия, которые потребовались.
После того, как вся информация собрана, ее нужно перевести в графическую нотацию. Здесь стоит понимать, что именно графические нотации считаются «хорошим тоном» при составлении описаний бизнес-процессов. Для себя вы можете составлять нотацию как вам удобнее, текстовые варианты описаний также существуют и применяются, например, некоторыми разработчиками программного обеспечения. Но если вы составляете нотацию, которую будут читать другие люди, не важно, разработчик программы или руководитель компании, выбирайте графику.
Причина такого решения проста: в графическом виде информация лучше воспринимается. Если вы предложите человеку «стену текста», ему потребуется много времени и сил, чтобы разобраться, о чем вы вообще говорите. А охватить задачу целиком в этом случае – почти не реально. Другое дело графические схемы – здесь можно изучать бизнес-процессы на разных уровнях детализации, да и быстро «охватить взглядом в общем» графическую схему сможет любой человек.
Рекомендуемая последовательность действий:
Правила описания бизнес-процесса
Выше я много сказал о творческом подходе, о возможностях включения условий и вариантов действий в описании бизнес-процессов. В результате может показаться, что любое описание действий человека «на работе» можно посчитать описанием бизнес-процесса. На самом деле, существуют строгие рамки и правила, которые определяют, можно ли назвать перечень действий описанием бизнес-процесса (в графической или текстовой форме) или нет:
Распространенные мифы и заблуждения
Не «изобретайте велосипед»! Не нужно придумывать свои нотации.
Нередко люди вместо того, чтобы изучить особенности существующих нотаций, рисуют графики в произвольной форме в различных графических программах.
Я не рекомендую так поступать. Во-первых, при использовании готовых инструментов вам не потребуется изобретать свои обозначения и стандарты. Все давно придумано до вас. При этом стандартные нотации действительно понятны интуитивно, читаются однозначно, известны многим людям. Во-вторых, в готовых системах (IDEF3, BPMN 2.0 и пр.) имеется проработанная методология и строгие ограничения. Их можно воспринимать как язык программирования и среду для работы с этим языком. Здесь вы просто не сумеете совершить многих ошибок, от этого вас уберегут стандарты синтаксиса и сама среда (ограничения в редакторе, автоматические проверки).
Не путайте описания бизнес-процессы компании и бизнес-процессы IT систем.
Во многих автоматизированных системах, например, 1С или Zoho CRM, существуют собственные сущности с названием «бизнес-процессы». Но к описываемым в этой статье бизнес-процессах эти сущности не имеют никакого отношения. Считайте их «омонимами», т.е. термины вроде звучат одинаково, но в нашем случае это – описание работы компании, а в IT системах – название группы функций и отчетов.
Распространенная ошибка: Бизнес-процесс обязательно приносит ценность (прибыль).
О том, что бизнес-процессы должны приносить прибыль, я слышал даже от известных спикеров. Более того, видел даже “разбор ошибок” при создании бизнес-процесса, в котором очень много внимания уделяется тому, что 70% действий не несут никакой ценности.
На самом деле, бизнес-процессы бывают разными. Результатом каких-то будет и правда получение прибыли, например, прямые продажи. В других случаях о приобретении ценности и вообще об оценке действий с этой точки зрения говорить сложно. Например, как можно оценить, какую ценность приносит бизнес-процесс отгрузки товара или формирования и отправки налоговой отчетности?
Я считаю, что бизнес-процесс совсем не обязательно приносит какую-то ценность, если понимать ее как непосредственную прибыль компании. Внедрение процессно-ориентированного подхода и реализация бизнес-процессов направлены больше на другое — на сохранность ценности, т.е. получению большей результативности при тех же затратах.
Возможно ли создать идеальный бизнес-процесс — когда следует остановиться?
Нет. Бизнес—процесс должен быть простым, понятным, удобным, читабельным. Но идеальным он не будет никогда.
Когда я начинал работать, мне и самому все время казалось, что я что-то недорабатываю, где-то можно было бы сделать лучше. А нередко и клиенты меня просили детализировать и описать подробнее тот или иной процесс. И я это также считал своим недочетом.
На самом деле, исходя из всего выше описанного, моделирование бизнес-процесса — это некоторое допущение, процесс творческий. С другой стороны, я в свое время не знал даже что ответить на просьбы описать еще “это” и “вон то”. Но со временем я понял, что бизнес-моделирование — это не просто творчество, но некий диалектический процесс. И уже само создание бизнес-процесса всегда будет нести в себе собственное отрицание. Здесь действительно стоит подходить к вопросу с философской точки зрения. И создавая бизнес-процесс, нужно помнить, что мы не можем охватить все и сразу, а потому он всегда будет несовершенен. Но при этом мы уже закладываем в него то, что будем совершенствовать в будущем. Стоит к этому подходить просто как к факту.
Ваш бизнес-процесс должен решать поставленную задачу, отвечать на тот вопрос, который рассматривается в рамках проекта. Все остальное — вопрос будущего возможного сотрудничества. Именно так и стоит пояснять заказчикам, почему вы не детализируете какие-то процессы или не рисуете еще какой-то бизнес-процесс, связанный с обсуждаемым.
Для лучшего понимания тематики рекомендую статьи: