Разработка нового процесса обычно ведется командой реинжиниринга. В этот период команда рассматривает несколько вариантов процесса, собирает необходимую информацию и вносит исправления, если это необходимо.
Даже после того, как новый процесс был согласован, задача разработки ключевых положений процесса может означать, что команде придется вносить дальнейшие изменения в новый процесс. Занимаясь реинжинирингом процесса, команда должна вернуться к предварительно проведенной работе по выявлению требований клиентов процесса, установлению планки и созданию видения процесса, а также к ее пониманию мотивации сотрудников и технологическим аспектам.
Команда должна обратиться также к большому количеству принципов и рекомендаций, которые помогут ей в деле создания нового процесса. Некоторые из этих принципов происходят из школы научного управления и были разработаны, чтобы помочь людям выполнять работу максимально производительно. Другие принципы являются совершенно новыми и отражают радикальность, отличающую РБП от других более ранних подходов к оптимизации бизнеса. Применяя принципы на практике, команда реинжиниринга должна пытаться творчески использовать их.
Практическое задание
Построение модели бизнес-процесса выполнения заказа в компании, производящей корм для животных, который покупают фермеры.
 |
Процесс представлен просто в виде круга, и это называется схемой внешней среды процесса.(рис 8.1) Эта схема показывает также основных клиентов и поставщиков процесса, изображенных в виде прямоугольников, а также входы и выходы процесса, изображенные с помощью стрелок.
Карта процесса, позволяющая взглянуть на процесс более детально. Это схема информационных потоков первого уровня, и на ней показаны основные составляющие процесс субпроцессы. Каждый субпроцесс изображается в виде кружка, с идущими к нему и от него входами и выходами в виде стрелок.
Здесь не требуется включать в схему клиентов и поставщиков, как это было на схеме внешней среды процесса, только входы и выходы от них и к ним. Таким образом, можно избежать переусложнения схемы процесса и показать только информацию, являющуюся новой по сравнению с предыдущей схемой. Для процесса, показанного на рис.8.1, схема информационных потоков первого уровня будет выглядеть так, как показано на рис. 8.3. Основные этапы процесса, изображенные на рисунке следующие:
• Этап 1. Отдел по обслуживанию покупателей получает заказ от покупателя, записывает его и посылает в отдел продаж и производства, а копию — в отдел технической поддержки.
• Этап 2. На основе информации о заказе покупателя отдел технической поддержки разрабатывает техническую спецификацию на тип пищевой смеси, которая требуется покупателю, и посылает ее в отдел продаж и производства.
• Этап 3. Используя информацию о заказе покупателя и техническую спецификацию, отдел продаж и производства оформляет заказ на поставку, а также информацию о текущем уровне запасов. Этот заказ и информация передаются в планово-производственный отдел.
• Этап 4. Разрабатывается план производства для отдела по планированию расходов сырья и материалов. Это делается на основе информации о продажах и запасах.
• Этап 5. Отдел по планированию сырья и материалов использует производственный план, номер контракта и информацию о наличии транспорта и запасов сырья и материалов для разработки требований к перевозке и плана потребности в материальных ресурсах.
• Этап 6. Отдел планирования перевозок выписывает заказ на транспортное средство, используя требования к перевозке и текущую информацию от третьей стороны (перевозчика). Информация о задержках скапливается в отделе по обслуживанию покупателей.
 |
После выполнения этих шагов цех помола производит требуемое количество корма, готового к погрузке на транспорт перевозчика. Перевозчик забирает продукцию и доставляет ее к покупателю.
Эта схема информационных потоков показывает основные субпроцессы данного процесса и их взаимодействие между собой для производства первичного выхода процесса, которым в данном случае является животный корм, доставленный фермеру. Эта схема позволяет увидеть процесс как бы сверху, хотя при этом нет возможности рассмотреть детали основных субпроцессов. Довольно редкий случай в нашей практике, когда было создано полное изображение процесса, который увидели все члены команды. Каждый член команды персонально принимал участие в создании карты, поясняя свою роль в процессе, но скорее всего до этого момента ни у кого не было четкого представления о роли других в этом процессе.
Серьезный реинжиниринг процесса возможен уже на этом уровне, он может включать в себя удаление субпроцессов или сведение нескольких субпроцессов в один
Но для того чтобы действительно принимать такие решения, следует иметь больше информации, что реально происходит в каждом субпроцессе. Следовательно, требуется и более детальная схема, которую можно получить с помощью построения схем информационных потоков второго уровня.
 |
Схемы информационных потоков второго уровня получаются, если взять каждый кружок из схемы информационных потоков первого уровня и расписать его основные элементы. В результате получается набор схем, число которых равно числу схем на графике первого уровня. Каждая схема представляет основные элементы субпроцесса, который она детализирует, и также рисуется в виде схемы информационных потоков
Задания для самостоятельной разработки модели бизнес-процесса выполнения заказа в компании, производящей корм для животных, который покупают фермеры.
Часть 1
1) построить контекстную диаграмму модели ”as-is”; используя методологию IDEF0
2) построить диаграммы верхнего уровня;
3) произвести функциональную декомпозицию каждого процесса с помощью детализирующих диаграмм;
Часть2
Применить один из принципов реинжиниринга и.создать модель процесса “to-be ” для которой:
4) построить контекстную диаграмму модели
5) построить диаграммы верхнего уровня;
6) произвести функциональную декомпозицию каждого процесса с помощью детализирующих диаграмм;
Разработать модель бизнес-процесса выполнения заказа в компании, производящей корм для животных, который покупают фермеры, получившегося после реинжиниринга, если удалось применить один из принципов реинжиниринга:
Вариант 1. (№№1,5,9,13,17)
Источник: poisk-ru.ru
TO-BE модель
TO BE (SHOULD-BE, AS-TO-BE) — модель «как должно быть».
Как правило, данная модель создается на основе AS IS, с устранением недостатков в существующей организации бизнес-процессов, а так же с их совершенствованием и оптимизацией. Это достигается за счет устранения выявленных на базе анализа AS IS узких мест.
В традиционном реинжиниринге именно на основе модели TO BE рекомендуется производить автоматизацию бизнес-процессов и проектировать КИС. Подразумевается, что это позволяет существенно снизить риск проявления автоматизации как исключительно источника затрат из-за автоматизации несовершенных процессов. Однако в настоящее время, в связи с возрастающей популярностью «эволюционного» реинжиниринга (см. CPI), снижается необходимость в долгой и трудоемкой подготовке модели TO BE.
Смотри также:
- Бизнес-процесс
- Модель бизнес-процесса
- Описание бизнес-процесса
- AS-IS модель
- CPI (Continuous Process Improvement)
- Пользовательское соглашение
- Политика конфиденциальности
- Карта сайта
- Файлы Cookie
Источник: piter-soft.ru
Описание функциональной модели процесса «TO-BE»
Модель TO-BE («как должно быть») описывает будущее состояние процессов, с учётом пожеланий заказчика, а также анализа и оптимизации существующих процессов.
Определение требуемых изменений процессов осуществляется на основании анализа полученной модели AS-IS («как есть») и требований заказчика к целевому состоянию исследуемых бизнес-процессов.
В рамках описания процессов TO-BE («как должно быть») выделяются все процессы исследуемой области деятельности, определяются участники, ответственные за результат, наделенные необходимыми полномочиями и правами и их взаимодействие между собой. [36]
В результате заказчик получает задокументированный перечень предложений по оптимизации процессов, что дает возможность внести соответствующие изменения и оптимизировать свою деятельность, значительно сократить издержки и повысить эффективность деятельности организации.
В процессе работы была спроектирована модель усовершенствованного процесса «Автоматизированная система управления учета студентов, получающих социальную стипендию» на примере ГБПОУ СО «Гуманитарный колледж», контекстная диаграмма которой представлена на рисунке 2, а диаграмма декомпозиции – на рисунке 3.
Как видно из диаграмм AS IS, TO BE и декомпозиции процесса TO BE (рисунок 2, 6 и 7), в усовершенствованной модели были более подробно уточнены входные и выходные данные, а также добавлено техническое задание и автоматизированная база данных.
Для описания логики взаимодействия информационных потоков более подходит диаграмма Workflow (IDEF3), которая используется в моделировании процессов для анализа завершенности процедур обработки информации. [20]
На диаграмме декомпозиции в нотации IDEF3 иллюстрируется процесс «Создания отчёта» (рисунок 8).
Рисунок 6 — Контекстная диаграмма процесса TO BE
Рисунок 7 — Диаграмма декомпозиции процесса TO BE
После описания системы в целом проводится разбиение ее на крупные фрагменты. Этот процесс называется функциональной декомпозицией, а диаграммы, которые описывают каждый фрагмент и взаимодействие фрагментов, называются диаграммами декомпозиции. После декомпозиции контекстной диаграммы проводится декомпозиция каждого большого фрагмента системы на более мелкие и так далее, до достижения нужного уровня подробности описания.
Рисунок 8 — Диаграмма декомпозиции IDEF3 процесса «Создание отчёта»
Для описания логики взаимодействия информационных потоков более подходит IDEF3, называемая также workflow diagramming, — методология моделирования, использующая графическое описание информационных потоков, взаимоотношений между процессами обработки информации и объектов, являющихся частью этих процессов. [31] Диаграммы Workflow могут быть использованы в моделировании процессов для анализа завершенности процедур обработки информации. С их помощью можно описывать сценарии действий сотрудников организации, например, последовательность обработки заказа или события, которые необходимо обработать за конечное время. [29] Каждый сценарий сопровождается описанием процесса и может быть использован для документирования каждой функции. IDEF3 — это метод, имеющий основной целью дать возможность аналитикам описать ситуацию, когда процессы выполняются в определенной последовательности, а также описать объекты, участвующие совместно в одном процессе.
Диаграмма дерева узлов показывает иерархию работ в модели и позволяет рассмотреть всю модель целиком, но не показывает взаимосвязи между работами. На рисунке 9 представлено итоговое расположение работ.
Рисунок 9 – Диаграмма дерева узлов
Таким образом, в построенной с помощью CASE средства BPwin усовершенствованной модели TO-BE были подробно уточнены входные и выходные данные, добавлено техническое задание на этапе управления. Результатам стала спроектированная база данных, которая поможет сотруднику учебного отдела сэкономить временной ресурс, выделенный на этот процесс, и оптимизирует выполнение этой процедуры.
ГЛАВА 3. РАЗРАБОТКА ПРОГРАММНОГО МОДУЛЯ «АВТОМАТИЗИРОВАННАЯ СИСТЕМА УПРАВЛЕНИЯ УЧЕТА СТУДЕНТОВ, ПОЛУЧАЮЩИХ СОЦИАЛЬНУЮ СТИПЕНДИЮ»
Источник: infopedia.su