Глава 5: Методология проектирования процессов – Станьте рабом машины или создайте коррупцию

Автор:нео Ян Время:2022/06/07 Читать: 4813

---

Схема документа

1. Характер процесса
2. Элементы процесса
1. Режим движущей силы
2. Задачи и статус
3. Узел
(1) Механизм проверки
(2) Механизм отбраковки
4. Механизм надзора
3. Шаблон проектирования процесса
1. Статусно-ориентированный (любой может это сделать, сосредоточиться на вещах)
ЧАС2. Узлоориентированность (не каждый может это сделать, ориентирован на людей)
3. Государственно-ориентированный или узлово-ориентированный, это вопрос.
4. Модель процесса
1. Модель стрелки
2. Многоуровневая модель
(1) Существует два типа составных моделей:
(2) Механизм обратной связи
3. Модель пула
4. Смешанное использование моделей
5. Проектирование многоуровневых процессов
1. Одна задача, многоуровневый статус
2. Одна основная задача, несколько подзадач.
3. Оба метода проектирования многоуровневых процессов имеют свои преимущества и недостатки.

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

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

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

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

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

1. Характер процесса

Сущность процесса — упорядочение положения вещей.

Что угодно, согласно определенным стандартам, может быть отмечено рядом состояний. Упорядочение этих состояний образует процесс.

2. Элементы процесса

1. Режим движущей силы

Пассивный режим и активный режим.

Любой процесс имеет свою движущую силу.

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

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

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

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

Активные и пассивные режимы могут сочетаться в рамках одного процесса. Во многом это зависит от конкретных дел и сценариев.

2. Задачи и статус

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

Задачей может быть документ, тикет, приказ, наряд-заказ, карточка и т.п.

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

3. Узел

Узел является исполнителем.

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

Узел может выполнять только одно состояние или несколько состояний. В основном это зависит от шаблона проектирования процесса (подробности см. в разделе «3. Шаблон проектирования процесса»).

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

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

(1) Механизм проверки

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

• Предварительная проверка:

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

• Пост-проверка:

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

(2) Механизм отбраковки

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

4. Механизм надзора

Каждый процесс должен иметь механизм мониторинга. Существует два основных типа регуляторных механизмов.

• надзор за ведением учета

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

• Контроль в режиме реального времени

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

3. Шаблон проектирования процесса

1. Статусно-ориентированный (любой может это сделать, сосредоточиться на вещах)

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

Сначала сделайте что-нибудь, а затем получите определенное состояние, затем сделайте что-нибудь еще раз, затем получите определенное состояние, а затем используйте распознавание изображений, чтобы получить определенное состояние, а затем сделайте что-то еще раз и получите определенное состояние. . . . . .

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

Вы можете думать об этом как о «сборочной линии».

2. Узлоориентированность (не каждый может это сделать, ориентирован на людей)

Это относительно редко. Легко на состояниях, тяжело на узлах.

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

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

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

3. Государственно-ориентированный или узлово-ориентированный, это вопрос.

Возможно, причина существования Бога в том, что этот мир несовершенен.

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

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

Ориентация на узлы может легко привести к концентрации власти и коррупции.

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

4. Модель процесса