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

Речь идет об окрасочном участке с тремя отдельными камерами покраски. На этом участке основная линия разветвлялась на три, каждая из которых подавала изделия к одной из трех камер. При таком разветвлении основной линии для обеспечения потока продукта очень важно, чтобы подача изделий осуществлялась в определенной последовательности с учетом цвета и модели. Это единственный способ избежать чрезмерной нагрузки на какую-либо из камер и заторов на линии. Наблюдение за окрасочным участком (стояние в кругу) показало, что потоку продукта через одну или две камеры часто препятствует затор перед другой камерой. Из-за этого весь процесс подачи изделий останавливался, что сказывалось на показателях совокупного времени простоя линии. Проблема была чрезвычайно острой, поскольку заторы при окраске сдер-

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

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

Для определения порядка подачи изделий на окраску, который учитывал бы все требования к цвету и ассортименту, была создана команда из трех человек, хорошо знакомых с процессом. Команда потратила почти три дня, чтобы разработать последовательность, удовлетворяющую всем параметрам и условиям. Представьте, как сложно было запомнить такую последовательность наизусть! Неудивительно, что операторы не соблюдали правила, ведь даже сформулировать их оказалось весьма непросто.

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

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

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

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

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

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