Этим постом я возвращаюсь к теме визуализации процессов в профессиональных услугах.
Как я писал ранее, что мы можем интерпретировать такие процессы, как совместное накопление и обогащение знаний и привел несколько примеров.
Ключевой частью их является акцент на накоплении знаний и получении информации посредством последовательности совместных действий, а не производственных центров, технологических этапов и делегирования.
Теперь обратимся к связанной с этим проблеме: как начать с реальных процессов и создать правильное отражение в системе визуального управления.
Для команд и организаций, использующих системы Канбан, эта визуализация представляет собой значимую часть их системы.
Для тех, кто разрабатывает свои сервисы по методу Канбан, это важнейшая часть практики визуализации, которая является одной из практик метода.
Вкратце, диаграмма накопления знаний/информации, представленная следующим образом:
мы можем представить себе эту канбан-доску:
Метод картирования процессов имеет три важных аспекта:
- Что, собственно, и как делать – конкретный рецепт.
- Наблюдения, сделанные в ходе реальной работы с группами людей: плюсы, минусы, сюрпризы и подводные камни – мы узнаем только на практике.
- Обоснование того, что делать или не делать что-то определенным образом, — это то, что нам нужно понять, чтобы быть больше похожими на поваров, а не на поваров.
Блок-схемы, созданные в Visio и хранящиеся в SharePoint, отсутствуют. Этот процесс происходит в реальной жизни, и происходит главным образом посредством бесчисленных решений, принимаемых (в основном иррациональных) людьми с присущими им недостатками.
То, что происходит, — это норма, которую мы хотим улучшить.
Простые вещи: что и как делать Чтобы начать отражать наш процесс, нам нужна информация:
- определить организационную единицу и ее границы: обычно это отдел, коллектив, отдел или несколько родственных коллективов;
- определить интерфейсы и сервисы, которые предоставляет эта группа (внешним и внутренним клиентам), а также типы рабочих элементов сервиса;
- Найдите несколько примеров недавно выполненных рабочих элементов каждого типа.
.
Без них люди будут только обсуждать свое видение идеального процесса, ссылаться на существующую документацию процесса или спорить о том, как этот процесс должен происходить.
На примерах мы можем проследить, что происходит на самом деле: различные виды деятельности и решения, принимаемые в процессе этой деятельности.
Обычно достаточно трех-шести примеров для каждого типа рабочих элементов.
Должны присутствовать люди, непосредственно работавшие над этими рабочими объектами.
Не полагайтесь на видение менеджера, руководителя группы или тренера по процессам.
Рабочие элементы должны быть выстроены в ряд на правой стороне большой пустой доски.
При этом мы имеем десять вновь поставленных элементов четырех типов.
Затем каждый человек в комнате берет стопку стикеров, записывает действия, в которых он участвовал, или решения, которые он принял, которые привели к выполнению каждого из этих рабочих элементов, и помещает стикер на доску.
Основное внимание следует уделять тому, какие знания или информация были получены в результате каждого вида деятельности, а не фактическим процедурам и встречам, которые имели место.
Ведущий предлагает участникам склеить одна наклейка за раз и расположите их в хронологическом порядке.
Мы хотим отслеживать, что на самом деле произошло в процессе доставки.
Оказывается, эта деятельность сложный и социальный .
Люди не помнят большую часть того, что они делали, но они склонны стимулировать воспоминания друг друга.
Например, разработчик программного обеспечения может написать наклейку о том, что он написал код для функции, которую поставляет. Тестировщик может помнить, что на самом деле он тестировал незавершенную функцию, нашел в ней ошибки и предоставил отчет разработчику.
Тогда разработчик может вспомнить, что эта функция тогда действительно была незавершенной, что они посовещались с коллегой и планировали добавить несколько автоматических тестов, чтобы предотвратить возникновение таких ошибок, и, соответственно, им нужно было реализовать план.
Именно через эту сложную кооперативную игру визуализируются доминирующая деятельность существующего процесса, поворотные моменты, закономерности взаимодействия и выявляются явные правила.
Со временем группа начнет замечать сходство между ними (конечно, в рамках одного и того же типа рабочего элемента).
Ведущий должен уточнить у участников порядок расстановки стикеров со схожими действиями.
Иногда порядок становится очевидным достаточно быстро, и нет необходимости записывать каждый шаг для каждого рабочего элемента на стикере.
Базовый, доминирующий вид Затем действия можно определить, расположив их на временной шкале и соответствующим образом сгруппировав наклейки.
Как напоминание ( это подробно описано в предыдущем посте ), один из основных видов деятельности какое-то время доминирует над накоплением знаний, но в конечном итоге угасает и заменяется новым доминирующим видом деятельности.
В этом примере команда воссоздала график шести поставок определенного типа рабочих элементов и определила пять основных видов деятельности.
Явная политика Результаты этого семинара можно легко перенести на новую доску Канбан.
Каждый выявленный доминирующий вид деятельности будет представлен столбцом.
Группа должна решить, как назвать каждое занятие — эти названия станут заголовками столбцов на физической доске.
Поскольку существует несколько типов рабочих элементов, и каждый из них может иметь свой набор доминирующих действий, доска Канбан обычно имеет несколько полос, каждая из которых имеет немного отличающийся набор столбцов, отражающих различия в процессе.
Этот семинар также помогает выявить неявные, но подразумеваемые правила.
Помните, что одна из ключевых практик метода Канбан — четкое определение правил.
Это может включать в себя:
- критерии готовности (Определение готовности);
- критерии завершения (Определение готовности);
- правила упорядочивания или выбора элементов для выполнения (некоторые называют это расстановкой приоритетов);
- периодичность пополнения и доставки;
- и так далее.
Семинар обычно занимает два с половиной часа .
По моему опыту, лучше всего не торопиться, хорошо объяснять, поддерживать дискуссию с помощью хороших вопросов и давать людям достаточно времени, чтобы понять мысли друг друга и понять свой процесс.
Лишь в простых случаях мы справлялись с этим менее чем за два часа, и ни разу не было случая, чтобы это занимало более трех часов.
Я считаю, что сложность процесса компенсируется ограниченностью внимания и степенью погружения людей в детали.
Теги: #Управление проектами #Управление продуктом #канбан #метод канбан #визуализация процессов #визуализация процессов #визуализация процессов
-
Есть Ли На Вашем Компьютере Вредоносное По?
19 Oct, 24 -
Настройка Sap Business One Или С Чего Начать
19 Oct, 24 -
Справка По Linux
19 Oct, 24 -
С02.07. Windows Восемь
19 Oct, 24 -
Первый Нетбук На Базе Google Android
19 Oct, 24 -
Новая Версия Extjs 3.3.
19 Oct, 24 -
Программное Обеспечение Для Записи Подкастов
19 Oct, 24 -
Удобство Использования Капчи
19 Oct, 24 -
В Википедии Используется Nofollow.
19 Oct, 24