В предыдущем номере «ДО» мы отметили актуальность и значение бизнес-процессов в компании. Теперь определим, по каким принципам проводить их анализ, как правильно использовать полученную информацию и выявить проблемы.
Что описываем?
При процессном подходе ведения бизнеса, когда основной упор делается на правильное выполнение последовательности действий, главным объектом изучения как раз и являются текущие процессы.
Прежде чем оптимизировать, необходимо их тщательно изучить. Основной метод исследований — это описание процесса на основе непосредственного общения с его участниками. В первую очередь, определите, кто является хозяином процесса (это руководитель того подразделения, где сосредоточен основной функционал деятельности).
Для любой торговой организации характерна приемка товара от поставщика и его оприходование. Например, в нашей компании в этом принимают участие сотрудники сразу двух подразделений: отдела закупок и отдела логистики. Организационно они подчиняются разным руководителям, и определить хозяина процесса зачастую бывает затруднительно.
В этом случае перераспределением ответственности должен заняться тот, кому подчиняются оба начальника участвующих в процессе структурных подразделений. В нашем случае это руководитель управления запасных частей. А чтобы избежать разного понимания сути процесса и размывания границ ответственности, обсуждение деталей процесса лучше вести в присутствии этих менеджеров среднего и высшего звеньев.
Сбор информации
- функции, которые они выполняют;
- принципы их взаимодействия между собой;
- данные, передаваемые ими друг другу.
Какой формат выбрать?
Полная информация от всех участников бизнес-процесса позволяет приступить непосредственно к моделированию его схемы. В настоящее время существует множество форматов для описания таких моделей. Каждый из них имеет свою специфику и наилучшим образом подходит для описания конкретного вида бизнес-процесса.
При выборе формата нужно иметь в виду одно обстоятельство: результатом описания должна стать модель процесса, понятная как любому из его участников, так и начальнику подразделения и руководству компании. На начальном этапе следует выбрать тот формат, который позволит описать существующее положение дел в привязке к имеющейся в компании организационной структуре. Такой подход объясняется тем, что на практике понять процесс абстрактно, в отрыве от оргструктуры, бывает затруднительно.
В определенной степени оптимальным считается формат WFD (Work Flow Diagram — Диаграмма потоков работ), когда выполняемые работы привязываются к конкретным сотрудникам, встроенным в организационную структуру компании на описываемом этапе. Можно использовать и различные специализированные программные продукты.
Однако такие специальные оболочки, как правило, дорого стоят, и для работы с ними потребуются определенные знания и опыт. Более простой вариант — применение стандартной графической программы. Например, в нашей компании используется Microsoft Office Visio, которая насчитывает значительное число стандартных шаблонов по самым различным разделам: бизнес, расписания, блок-схемы и т.п. При помощи имеющихся в программе инструментов можно описать практически любую схему.
В привязке к существующей оргструктуре удобнее всего использовать так называемую функциональную блок-схему, в которой показываются потоки работ, выполняемых конкретными исполнителями. В ней по горизонтали или по вертикали располагаются столб-цы, соответствующие конкретным должностям, а в теле таблицы при помощи условных обозначений показаны работы, выполняемые ими. Под условными обозначениями понимаются стандартные фигуры, имеющиеся в программе для описания простой блок-схемы: процесс, решение, данные и т.д. WFD позволяет описать бизнес-процесс как совокупность всех составляющих его работ.
Максим Бородаенко
директор по коммерческому развитию компании «Авторай»
Андрей Храмов
помощник директора по коммерческому развитию компании «Авторай»
Источник: uldelo.ru
Описание бизнес-процессов «Как есть» (AS IS) и «Как должно быть» (TO BE)
Когда я сам изучал моделирование бизнес-процессов при реинжиниринге, то во всех учебниках встречал два понятия — AS IS и TO BE. И все авторы писали, что сначала необходимо составить нотацию AS IS (буквальный перевод — «как есть»), т.е. как система работает в настоящее время, и только потом приступать к процессу модернизации, т.е. создавать нотацию TO BE (Как должно быть).
Проще говоря, сначала следует изучить, как работает предприятие или отдел сейчас, сделать описание бизнес процесса, и только потом, на основе нотации AS IS, начинать оптимизацию. Но все эти теории хороши, когда есть что описывать по схеме «Как есть». В реальности ситуация чаще всего иная.
Описывать нечего
Если в компании не проводилась ранее оптимизация бизнес-процессов, а это обычная ситуация, нет каких-то четких инструкций, то каждый из сотрудников будет работать по-своему.
Здесь нет ничего необычного. Каждый человек мыслит немного по-своему, у каждого за плечами — собственный опыт. В результате даже самые простые задачи мы все склонны выполнять по-разному.
Например, процесс согласования счета даже в одной организации может выполняться очень по-разному. Кто-то сначала пойдет к начальнику отдела, а кто-то направится сразу в бухгалтерию подписывать счет.
Еще ярче, в тех же продажах, заметна разница между действиями при работе с лидами:
- Один менеджер отправит прайс-лист или коммерческое предложение и успокоится на этом.
- Другой сначала позвонит, все уточнит.
- Третий будет добиваться личной встречи даже там, где без нее можно прекрасно обойтись.
Перед ними стоит задача — обработать лиды и сделать план продаж. Возможно, есть даже перечень рекомендаций, как это лучше делать. Но единой системы нет. И люди начинают нарушать последовательность действий, поступать на свое усмотрение и т. д.
Даже при наличии должностных инструкций в реальности они чаще всего пылятся всеми забытые, а сотрудники работают «кто как привык». В итоге, мы видим, что системы AS IS, т.е. «как есть», не существует. Нет какой-то единой системы, по которой на самом деле люди работают. И описывать, на самом деле, нечего.
Вы, конечно, можете, попытаться составить модель AS IS на основе инструкций. Но она не будет отражать реальность, ведь их массово нарушают. Можете опросить сотрудников, но любая из моделей будет отражать работу только части людей либо что-то «усредненное», что вообще не будет иметь отношения к реальности, т.к. все работают похоже, но — не так.
Описывать незачем
Еще один важный аспект, с которым я столкнулся на практике. О том, что в компании что-то делают неправильно, все и так давно догадываются. Иначе бы вас, как специалиста, не пригласили. И от вас не ждут описания существующих проблем, они часто и так понятны. От вас ждут решения — как надо работать.
Чаще всего клиенты ожидают, что бизнес-консультант придет, осмотрится, опросит людей, после чего выдаст рекомендации, как надо делать, чтобы решить существующие проблемы. Т.е. людям не нужны нотации «Как есть». Им сразу хочется увидеть «Как должно быть».
Зачем создают нотации AS IS?
Создавать нотации AS IS для себя вы можете, это даже может быть удобно и полезно. В конце концов, графика помогает упорядочить мысли, разобраться точнее лично для себя, что и как происходит. Но в рекомендованной последовательности действий указывается обязательный этап предоставления этой нотации клиенту.
Бизнес-консультанту такой подход выгоден с финансовой точки зрения. Большой объем работы повышает ее стоимость. Но нужно ли это заказчику? Он и сам знает, что компания как-то работает, потому что бизнес приносит прибыль и т. д. Вас он нанимает не для того, чтобы за их деньги вы им поясняли, какую схему работы они сами организовали. Им хочется увидеть от эксперта результат, т.е. схему, которая будет работать лучше.
Возникает резонный вопрос. А как без описания того, что есть, вы сможете выдать рекомендации, что нужно изменить? Но ведь вы — специалист, эксперт в своей сфере деятельности, вас потому и позвали, что верят, вы разберетесь и сумеете выдать правильный результат.
Конечно, вы будете вести свои записи. Вполне возможно, что вы даже оформите их в виде нотации, как это и описывают в учебниках. Вы можете использовать эти записи для уточнения каких-то моментов в работе компании. Но этот этап нужен вам, а не заказчику.
Потому не имеет смысла тратить силы и время на составление полноценной нотации AS IS с сопроводительной документацией, включать этот этап в план работ и т. д. Если ваш клиент не ждет от вас этого этапа в обязательном порядке, что иногда случается в крупном бизнесе или в случаях, когда заказчики тоже читали те самые учебники, предоставляйте сразу решение — TO BE. Вы должны быть на стороне клиента, и давать ему то, что реально нужно. Это подход продуктивности.
Пример использования нотации AS IS и TO BE
Я сотрудничал с хлебокомбинатом, который имеет цех выпечки, склад и подразделение охраны. При составлении нотации AS IS стало очевидно, что участие охраны в процессе выпечки хлеба абсолютно не нужно.
Как выглядит процесс:
- Сотрудники принимают материалы в цех. Операция выполняется вручную, момент принятия каких-либо документов здесь не отражается.
- Пекут хлеб. Этот этап также не отражается в IT-системе. Хлеб они пекут вручную на оборудовании, которое не подключено к системе.
- Составляют пакет документов “Выпуск хлеба”. Как именно выглядят эти документы, в данном случае не имеет значения.
- Выполняют выпуск хлеба.
- Далее они должны сдавать полученную партию и документы охране.
- Охрана проверяет партию и дает разрешение. Причем, разрешение дается всегда, так как что может охрана? Убедиться, что в партии есть хлеб. Максимум – подсчитать его количество
- Охрана выдает разрешение.
- Цех выпечки передает партию товара на склад.
- Склад принимает товар.
На самом деле, этапы, связанные с действия охраны, не имеют особого смысла, так как охранники не проходили никакие специализированные курсы, в хлебе они вообще не разбираются. Потому и проверить охрана не может ничего, кроме количества. Но количество проверяется еще раз позже при приеме на склад.
Очевидно, что для оптимизации нужно убрать участие охраны в процессе, а контроль выполнять другими методами. Охрана при этом работать на предприятии будет, выполнять контроль периметра, входной контроль и т.д. Но в этом процессе она не нужна.
Процесс TO BE будет таким:
- Сотрудники принимают материалы в цех. Операция выполняется вручную, момент принятия каких-либо документов здесь не отражается.
- Пекут хлеб. Этот этап также не отражается в IT-системе. Хлеб они пекут вручную на оборудовании, которое не подключено к системе.
- Составляют пакет документов “Выпуск хлеба”. Как именно выглядят эти документы, в данном случае не имеет значения.
- Выполняют выпуск хлеба.
- Цех выпечки передает партию товара на склад.
- Склад принимает товар.
Источник: Блог компании Системный интегратор Тринион
Источник: biconsult.ru
XV Международная студенческая научная конференция Студенческий научный форум — 2023
Разработка диаграмм «как есть» и «как будет» бизнес-процессов получения и исполнения заказа
Манжосов М.С. 1
Работа в формате PDF
Текст работы размещён без изображений и формул.
Полная версия работы доступна во вкладке «Файлы работы» в формате PDF
Моделирование бизнес-процессов (Business Process Modeling) — один из методов повышения эффективности и прозрачности работы организации. В его основе лежит процессный подход к управлению: процессы описываются через присущие им элементы — действия, данные, события, материалы. Полученное описание позволяет глубоко разобраться в бизнес-процессах, увидеть потенциал их улучшения и эффективно организовать взаимодействие всех участников.
Отсутствие формализованных бизнес-процессов может привести к тому, что внутреннее развитие компании не успевает за ростом бизнеса и рыночными изменениями, возникают «болезни роста», процессы становятся все более хаотичными. Если же показатели деятельности перестают устраивать руководителей, нет возможности выявить проблемные точки и наиболее перспективные направления улучшений [1] .
Для моделирования бизнес процессов можно использовать такие программы как: ARIS Express, Intalio BPMS, Bizagi Process Modeler, Camunda, ELMA и Fox Manager Бизнес Процессы.
Одной из самых популярных программ для моделирования бизнес процессов является ARIS Express — это предоставляемый бесплатно инструмент бизнес-моделирования, позволяющий решать базовые задачи создания моделей бизнес-процессов, инфологических моделей, организационных диаграмм и схем ИТ-инфраструктуры [2].
Программный продукт ARIS Express от разработчика Software AG предназначен для создания основных бизнес-моделей и является хорошим инструментом для решения разовых задач моделирования, а также для новичков в управлении бизнес-процессами. Вместе с инструментом компанией-разработчиком предлагаются обширные материалы для обучения моделированию на базе сообщества ARIS Community.
ARIS Express удовлетворяет следующим потребностям [3]:
Организационная структура. Программное обеспечение предлагает нотацию и соответствующие сущности (организационная единица, роль и личность) для отражения связей между отдельными организационными единицами, такими как отделы или сотрудники.
Бизнес-процессы. Программа позволяет создать модели бизнес-процессов и рабочих процедур с применением нотаций семейства ARIS, а также нотации BPMN. Также инструмент позволяет создавать ландшафты (карты) процессов.
Инфологические модели и модели данных. Применяя нотацию сущность-связь для моделирования, пользователь может создать в системе модели данных различной степени детальности. Например, для определения структуры базы данных.
Системные модели. ARIS Express позволяет разработать системную модель, раскрывающую структуру ИТ-систем и технологические свойства (операционные системы, пользовательские интерфейсы или системы управления базами данных), на которых основаны ИТ-системы.
ИТ-инфраструктура. Возможно создание схем ИТ-инфраструктуры, используемые для моделирования технической коммуникационной инфраструктуры компании. ИТ-системы и принадлежащие им аппаратные системы на схеме могут быть соединены сетями с использованием различных сетевых устройств.
Объектом моделирования данной работы является процесс поступления заказа в базу компании и риски его перехвата конкурирующими компаниями.
В условиях конкуренции часто компании стараются перехватить друг у друга заказы. Решить данную проблему может помочь автоматизация процесса получения заказов путём ограничения доступа к данным заказов и путём совершенствования ИТ части бизнеса.
Задачей работы было показать то, как было и как будет протекать усовершенствованный процесс.
Практическая ситуация. Руководители компании подозревали, что ее информационная система, обеспечивающая дистрибуцию товаров через посредников конечным покупателям с помощью центрального федерального телефонного номера и единого Web-сайта, допускала утечки информации — конкуренты перехватывали заказы.
Аудит системы выявил, что причиной этого является человеческий фактор: операторы контакт-центра не заносили поступавшие заказы в системы, а «сливали» знакомым в конкурирующие фирмы. По итогам аудита было решено дополнить бизнес-процессы функциями мониторинга путем журналирования всех этапов работы с информационной системой и более жесткого разграничения доступа к данным и к возможности удалять информацию. Были введены процедуры контрольных обратных звонков, позволяющих удостовериться, что клиент подтверждает факт доставки оборудования и его успешного монтажа. Аудит информационной системы помог выявить недостатки и найти возможности для совершенствования на уровне ИТ и бизнес-процессов заказчика.
На рисунке 1 представлена EPC диаграмма бизнес – процесса получения и исполнения заказа как есть.
На рисунке 2 представлена EPC диаграмма бизнес – процесса получения и исполнения заказа как будет.
Рисунок 1 – eEPC диаграмма бизнес – процесса поступления и исполнения заказа «КАК есть»
Рисунок 2 – eEPC диаграмма бизнес – процесс поступления и исполнения заказа «КАК будет»
Список используемых источников
Источник: scienceforum.ru
