К слову сказать, на это понадобилось лет шесть изысканий.
Очевидно, что если вы что-то производите (или выполняете проекты, это не так принципиально), то очень-очень хочется делать это:
— быстро
— качественно
— точно в срок
— с минимальными затратами (инвестициями)
Это значит, что должно быть найдено какое-то решение, позволяющее делать именно так.
Но есть нюанс. Любая многопользовательская среда не приемлет сложных решений. Или вам придется разориться на обучении и повышении квалификации, доведя уровень образования сотрудников до кандидатов наук.
Свои изыскания в этой части мы начали году в 2006-м, полагая, что лучшее решение для производства — это MRP. В 2010-м году, после некоторых опытов по внедрению, мы поняли, что MRP не ведет к увеличению эффективности. Количество заказов, произведенных точно в срок, не увеличивается, запасы не уменьшаются, скорость производства не растет. А зачастую даже наоборот. Я написал статью об этом. Довольно эмоциональную. Видимо серьезно задев тех, кто зарабатывает на внедрении MRP. Но ведь целью внедрения любой системы менеджмента должно быть увеличение эффективности, не так ли? Многие об этом забывают, как, впрочем, и о том, что цель бизнеса – зарабатывать деньги. Поэтому внедрение MRP чаще всего превращается просто в проект по внедрению MRP, а в не в проект по улучшению эффективности производства.
В 2009 году мы нашли нужное решение. Это Теория Ограничений (Theory of Constraints, TOC), которая к тому времени уже около 10-15 лет активно распространялась на западе (Hitachi, Boing, GM, P&G, ABB, Philips и т.д.). Но в России, как это часто бывает с инновациями, о ней почти никто не слышал. Теория Ограничений предлагает алгоритмы как для управления производством, так и для управления проектами. Мы сделали уклон в сторону производства, однако и про проекты не забывали.
Я прочитал книгу «Та самая цель» и понял, что Теория Ограничений позволяет производить и выполнять проекты (это уже другая книга, «Критическая цепь») в соответствии с теми четырьмя тезисами, о которых написано в начале этой статьи. Читая книгу, ты понимаешь, что это то, что тебе нужно. Но как слова превратить в программное обеспечение???
Нужны алгоритмы, а их не было. Найти людей, хорошо знающих TOC, было почти невероятно. Я ходил на курсы, но там был либо банальный пересказ книги, либо просто отстраненные от жизни выкладки. А мне надо было понимать, как выдавать задания на производство, как строить график производства, как определять важность задачи по проекту и т.д.
И мы начали собственные изыскания и начали пытаться разрабатывать ПО. Начали активно рассказывать про это. И вот тут то и появились люди, которым это тоже интересно. Начались встречи, обмен опытом. Мы по крупицам собирали информацию, моделировали, были уже и внедрения, после которых мы вводили коррективы в алгоритмы. И вот, в 2013 году у нас таки получилось то, что мы задумывали.
Теория Ограничений гласит: в компании всегда есть только одно место, которое ограничивает производительность всего предприятия. И производительность всего предприятия равна строго производительности именно этого места.
Вы можете сколько угодно инвестировать в новые станки (или другие объекты), но если они не являются узким местом, вы не получите прироста производительности всего предприятия. Это легкое отступление для тех, кто хочет оценить эффективность инвестиций. Эффективность инвестиций в неузкие места в лучшем случае равна нулю, а может быть и отрицательной, если вы инвестируете в новое оборудование до узкого места и не согласуете мощности. В то же время инвестиции в узкие места — самые эффективные, поскольку они позволяют увеличить производительность всей компании.
Пять основополагающих шагов Теории Ограничений.
1. Идентифицируй узкое звено.
2. Используй его возможности по максимуму.
3. Согласуй мощность всех остальных участков со слабым звеном (ограничением).
4. Увеличь производительность узкого звена.
5. Вернись к шагу №1.
Систематическое исполнение этих шагов неминуемо приведет к росту производительности всей компании.
Стоп.
А как найти узкое звено? А как использовать его возможности по максимуму? А как согласовать мощности других участков?
Вот и мы задавали себе эти вопросы на протяжении ряда лет и искали на них ответы.
И вот после долгих изысканий ответы найдены и переведены в алгоритмы программного обсепечения.
Итак, сначала немного философии. У вас есть клиенты, им от вас что-то нужно. Вы должны сделать то, что им нужно в строго установленный срок и тогда клиенты будут лояльны и будут заказывать еще. Выполнение заказов (проектов) точно в срок — один из способов увеличения продаж. А если вы это делаете еще и быстро, то…
Голдратт исходил из этого правила. Все должно быть подчинено достижению именно этой задачи. Выполнение заказапроекта точно в срок — главная задача, и работа компании должна быть выстроена в соответствии с ней. То есть все части предприятия — закупка, производство, выполнение задач — должны работать на выполнение этой задачи. Тогда и цель бизнеса — делать деньги — будет достигнута.
Основы нашего алгоритма
1. Определяется необходимо производить то, что заказал клиент. Нужно ли вообще это производить? Если заказ обеспечен складскими запасами, его производить не нужно. Но это очень быстро может измениться. Необходимость производить изделие из каждого заказа определяется при любом изменении ситуации. Пример для наглядности:
Вам позвонил клиент и заказал товар №1 в количестве 3 штуки и попросил это ему предоставить к 31.05.2013г. Если у вас на складе есть 3 штуки, то производить ничего не надо. Или если у вас есть производственное задание, в котором такой товар делается с некоторым запасом и этого запаса достаточно.
Но завтра вам позвонил еще один клиент и попросил точно такой же товар, тоже в количестве 3 шт., но уже к 15-му мая.
Вопрос: под какой заказ производить?
Ответ: конечно, под первый, хотя вчера под него ничего делать не надо было.
Таким образом необходимость производства под тот или иной заказ определяется при любом изменении ситуации в компании, касающемся этого товара.
Затем система по той же самой схеме определяет необходимость производства узлов различных уровней в вашем изделии и необходимость закупки комплектующих. И в результате строится два согласованных по датам списка. Так называемых «to do листа».
- Что мы должны купить
- Что мы должны произвести
Оба листа “живые” и меняются при любом изменении ситуации.
Но этого не достаточно. Недостаточно понять, что ты должен купить. Нужно определить когда это закупать и когда это производить. Если у вас есть необходимость купить товар, то это не значит, что его надо купить сейчас. Закупишь/произведешь слишком рано — потратишь драгоценные оборотные средства, которые затем будут “лежать” на складе. И займешь ресурсы, которые мог бы занять чем то более приоритетным.
Закупишь/произведешь слишком поздно — сорвешь итоговые сроки. Для этого Теория Ограничений предлагает использовать так называемые буферы времени, которые мы тоже встроили в to do листы.
Расстановка приоритетов! Вот что важно! Важно понять, что самое важное в данный момент. Что делать сейчас, а что делать потом. Тоже самое касается и задач при управлении проектами. Важно понять — какая задача самая важная при выполнении проекта. И важность задачи определяется именно состоянием буфером времени проекта. Чем меньше осталось буфера в проекте, тем выше уровень задачи.
2. Для достижения максимальной скорости производства каждый производственный участок должен делать именно те задания, которые имеют наивысший приоритет с точки зрения решения главной задачи. Главная задача — выполнение заказа точно в указанный срок. Для этого система выстраивает очередь производства, где у каждой записи есть свой приоритет. Каждая запись — это наименование. Это совершенно не обязательно то наименование, которое заказал у вас клиент. Верней оно то там точно есть, но помимо него там могут быть и другие. Например, промежуточные узлы изготавливаемого вами изделия. Приоритет определяется степенью приближения часа X. Чем ближе час X, тем выше приоритет. Таким образом каждый участок получает те задания, которые наиболее важны. В очереди производства используются те самые буферы времени, о которых я писал чуть выше.
3. Но и этого недостаточно. Описанные выше пункты не решают проблему подчинения всех участков производства узкому месту. Если этого не делать, то есть все шансы организовать “пробку” в производстве. Чтобы не “засЫпать” узкое звено, задания должны выдаваться строго в той скорости, которую способно “переварить” узкое звено.
И для этого мы придумали так называемый светофор. Прежде, чем выдать задание на участок, диспетчер смотрит на показания светофора. Если светофор красный, значит, скорее всего, выдавать задание нельзя. Но все зависит от специфики производства. Если узкое место работает в режиме 24/7 (максимальное использование ресурсов узкого звена, шаг №2), то к вечеру перед ним может скопиться некоторая очередь, которая к утру будет ликвидирована, потому что неузкие места, например, работают только днем.
Короче говоря, светофор помогает диспетчеру принять правильное решение, выдавать задания на участки или нет, согласуя тем самым производительность всех участков с узким местом. Кстати светофор же помогает и идентифицировать узкое место. Узкое место — то, которое чаще всего “красное”, то есть постоянно опаздывает по срокам. Оно не всегда очевидно, поэтому помощь «светофора» нужна.
Зачем нужно подчинять неузкие места узкому месту.
Почти все знают, что такое пробки на дорогах. Они возникают либо в том месте, где происходит резкое сужение, либо при возникновении препятствия. В результате возникновения пробки общая скорость потока резко снижается, иногда почти до нуля. Если дорога всегда будет иметь постоянную ширину и все автомобили будут двигаться с постоянной скоростью, без постоянных торможений и разгонов, пробок возникать не будет и скорость потока будет значительно выше, чем скорость потока с пробками.
Тоже самое происходит и на производстве. Задача очень проста — сделать так, чтобы на производстве постоянно сохранялась скорость. Это возможно сделать только если эту скорость поддерживать на уровне скорости узкого звена. И только после этого можно приступать к шагу №4 Теории Ограничений, то есть увеличивать пропускную способность слабого звена, увеличивая тем самым пропускную способность всего производства.
Ну, а затем шаг №5 :-)
Удачи вам во внедрении TOC.
Автор: erp_shnik
