Канбан - тоже система, построенная, по сути, на пооперационном (детальном) планировании (прошу прощения у тех, кому тема канбан малоинтересна). Чем более детально в ней все учтено, тем меньше размеры партий. Чем меньше размеры партий, тем выше КПД потока создания ценности. И тем выше требования к ритмичности и устойчивости процессов. "Незначительные" перебои в одном звене могут обрушить весь процесс. Читал рекомендации специалистов по этому поводу, что канбан-планирование имеет смысл применять на тех производствах, у которых флуктуации (колебания) рыночного спроса не превышают 20%. (Спрос - это тот аспект процесса, который в существенной степени определяет работу процесса, но на который не имеет возможности влиять управление производством). Однако, наличие колебаний спроса - это, хотя и важный фактор дестабилилизации процессов управления, он далеко не единственный фактор, который может создать риски срыва сроков канбан-процессов. В частности, типичные проблемы с задержками поступлений от поставщиков могут создать не менее серьезные риски. Поэтому крупные предприятия, применяющие канбан-планирования стараются навязать канбан-планирование также и своим поставщикам, и сменить схему работы с поставщиками от поставок крупных но редких партий (со скидками за размер партии) на принципиально иную, наиболее оптимально, ежедневных поставок малых партий (часто, но мелко). При этом системы планирования нескольких предприятий, использующих канбан, объединяются в систему интегрированного планирования, когда заказчик запчастей изначально оповещает своих поставщиков об ожидаемых изменениях в стратегических и тактических планах. Такая схема достаточно четко работает в Японии (и всё чаще стало слышно про применение подобных практик в Европе, в частности в Швейцарии и Германии). В России, увы, пока можно только мечтать. Место стыка канбан-системы с системами иного рода - это очень болезное место. Именно на этой самой болезности некототорые спецы добились мировой известности, стыкуя канбан и MRP-планирование. Помедитировав над литературой соответствующих гуру, я сделал для себя забавный вывод - для того, чтобы канбан-система могла достаточно бесперебойно работать, в состыкованной с ней MRP-подсистеме должны иметься слегонца завышенные страховые запасы, посредством которых и обеспечивается приемлемый уровень рисков канбан и достаточно высокий уровень эффективности. Получается, что в состыкованных системах планирования MRP-стык-канбан на MRP-часть ложатся дополнительные расходы, которые примерно соразмерно экономятся в канбан-части. Когда стык находится между разными (пусть даже и дружественными) бизнесами, это, по сути, означает, что бизнес-партнер, использующий канбан, получает выгоду за счет прогоды другого бизнес-партнера, использующего MRP.

К чему всё это лирическое отступление? К тому, что все "родовые" и хорошо известные риски, болезни, а также и позитивные качества канбан-планирования можно практически без изменения спроецировать на любые иные способы детального и пооперационного планирования, в том числе использующие математики теории расписаний, теории графов и т.д. и т.п.

Иными словами, детальное планирование - это и хорошо, и плохо одновременно. Хорошо потому, что позволяет, если получится бесперебойно доставлять малые партии нужных частей и компонент на нужное место обработки точно-к-моменту ("Just-In-Time", JIT), когда они потребуются, если время каждой операции до такой степени точно определимо, что плановое время практически никогда не отличается от факта, если однотипные операции всегда выполняются за в точности одинаковое время, если все операции настолько автоматизированы и механизированы, тогда можно действительно свести уровень запасов до мизерной величины, операционные издержи сократить до революционно-мизерных величин и добиться потрясающей эффективности. Но! Стоит затесаться в процесс одному звену с пресловутым "человеческим фактором", которому то приспичило покурить, то в туалет, то вдруг биоритмы не в той фазе, то невыспался, то недоперепил вчера вечером,.. и во всей системе резко (на порядки!) вырастают риски, связанные с непредсказуемыми флуктуациями, которые приводят либо к тому, что какие-то звенья регулярно простаивают из-за недостатка компонентов на входе, а какие-то из-за затаренности на выходе. И так или иначе, клиентам приходится озвучивать плановые сроки изготовления "с запасом". А что, по сути, означает это самое "с запасом"? Это означает, что весьма часто продукция оказывается уже изготовленной, но "кантующейся" в запасах, хотя ее можно было бы поставить и раньше. Флуктуации могут свести на нет смысл этого самого детального планирования. А могут и не свести... :)

Так вот, если говорить о "правильных" методиках внедрения пооперационного планирования, то, как я себе представляю, это такие методики, которые позволяют постепенно (а не скачком!) сокращать флуктуации времени выполнения операций, выявляя и устраняя те причины, которые их вызывают. Как это делается при внедрении канбан-планирования, я себе хорошо представляю. Канбан-систему делают максимально похожей на "as is", затем в ней очень постепенно начинают сокращать размеры партий, пока не столкнутся с какими-нибудь проблемами (не особо масштабными именно по причине плавного уменьшения размера партий). Устранив причины, которые вызвали проблемы, размеры партий сокращают по чуть-чуть еще и еще, пока вновь не столкнутся с проблемами. И таким способом постепенно "нащупывают" уровень системы, на котором она может достаточно четко работать, флуктуации процессов носят, в основном, внесистемный характер (почему сократить их больше уже не предоставляется возможным), и риски перебоев нормальной работы системы при этом поддерживаются на некотором допустимом уровне. А когда это не канбан, тогда каковы основные приемы для снижения рисков, связанных с изначально высокими флуктуациями в системе? Сахават, есть, что рассказать по этой теме?