Читаем Практика дао Toyota полностью

Как всегда при создании потока, сложнее всего было сбалансировать время и объем выполняемой работы. В одних случаях на ввод заказа уходило больше времени, чем на работы с помощью САПР, в других все было наоборот. Узкие места то и дело возникали то тут, то там, и вариация времени выполнения заказа была очень высока. Ситуация обострялась, когда кто-либо из сотрудников отсутствовал на рабочем месте (особенно если текущие заказы требовали активного участия именно того отдела, где работал отсутствующий).

Сначала составили карту процесса и разбили продукты на семейства (потоки создания ценности). Решение выделить отдельные семейства продуктов было продиктовано необходимостью изолировать вариацию, как описано в главе 4. С учетом сложности заказа и времени его обработки были выделены три потока создания ценности. Самые сложные заказы с максимальным уровнем вариации были выделены в один поток, а более простые заказы на конечную доработку — в другой. Третий поток создания ценности (подавляющая часть заказов) включал заказы, сложность и время обработки которых приближались к стандарту.

Группа решила объединить сотрудников в команды, создав рабочие ячейки, каждая из которых будет заниматься отдельным потоком создания ценности. Планировку офиса изменили, и теперь члены одной команды сидели рядом. Это способствовало поточной обработке заказов. Группировка заказов с учетом сложности и времени, требуемого на обработку, позволила определить стандартное число сотрудников, работающих с каждым потоком создания ценности. Обычно при этом обнаруживается, что в процессе заняты «лишние» работники. На самом деле их нельзя считать «лишними», поскольку их время уходит на то, чтобы компенсировать различные виды вариации, включая отсутствие коллег. Для стандартизации работы и создания потока желательно верно определить необходимую численность персонала (с учетом времени такта и содержания работы). Если должностные обязанности стандартизированы, чрезвычайно важно, чтобы никакое рабочее место не пустовало! Поэтому «лишние» сотрудники становятся лидерами команд и выполняют множество важных функций, описанных в главе 10, включая подмену отсутствующих.

Перейти на страницу:

Похожие книги

Философия DevOps
Философия DevOps

IT-принцип «agile» стал мантрой цифровой эпохи. С ростом проектов, переходом от монолитных приложений к системе микросервисов, увеличением и накоплением продуктов возникают вопросы, которые требуют совершенно иного подхода. Теперь наибольший интерес вызывает находящаяся на стыке разработки и операционного управления методология DevOps.DevOps – это не просто набор техник, это философия. Разработчики, зацикленные на пользователях, должны уделять внимание поддержке и ее запросам. Сисадмины должны сообщать о проблемах продукта и вносить свой вклад в улучшение процесса работы. Но налаживание связей внутри компании – это лишь первый шаг. Чтобы продукт стал простым и удобным, придется вложить время и ресурсы в его доработку. Конфигурация через центральную службу, внедрение простым копированием, отсутствие внешних зависимостей, обдуманные метрики вместо мусора в логах – вот лишь часть задач, которые придется решать на этом пути.Книга «Философия DevOps» познакомит вас с техническими, культурными и управленческими аспектами devops-культуры и позволит организовать работу так, чтобы вы получали удовольствие от разработки, поддержки и использования программного обеспечения.

Дженнифер Энн Дэвис , Кэтрин Дэниелс

Деловая литература