Оптимизатор бизнес-процессов 2.0. Лучшие инструменты повышения эффективности организаций, команд и систем - Александр Александрович Сорочан
1. Если эти и другие меры не помогают, то необходимо радикально менять ход выполнения операций за счет новой технологии, капитала и т. д.
2. Найти новое «узкое место», поскольку полностью их убрать в принципе невозможно, и продолжить.
1. Сбалансировать весь процесс таким образом, чтобы он работал на обеспечение узкого места, не создавая при этом избыточные запасы незавершенного производства.
Добиться этого можно благодаря инструменту:
«барабан – буфер – веревка», который позволяет:
● определить ритм, с которым должен двигаться процесс (барабан);
● рассчитать минимально необходимый запас материалов для обеспечения бесперебойности процесса (буфер);
● определить триггер, который инициирует подачу на следующий участок, чтобы не «замусорить» производство (веревка).
Рассмотрим его на нашем примере с машинками:
1. Допустим, мы сделали все, что могли, с шагом прикручивания колес и довели его до 8 единиц в час, то есть данный участок остался для нас узким местом. В таком случае он и станет нашим «барабаном», этапом, который задает ритм всему процессу. Если все операции будут двигаться в этом ритме, у нас не будет возникать простоев и авралов, не будет накапливаться незавершенное производство.
2. Чтобы процесс работал бесперебойно и с максимальной пропускной способностью, нужно, чтобы он был обеспечен всем необходимым, несмотря на статистические флуктуации (наличие комплектующих, поломки станков и т. д.), поэтому должен быть создан «буфер» перед узким местом. Буфер – это запас времени и ресурса, который требуется для обеспечения бесперебойной работы.
3. «Веревка» – нечто схожее с канбаном, сигнальная система, которая говорила бы процессу, что пора начинать операции, требуемые для поступления следующей партии точно тогда, когда с текущей партией машинок работы полностью закончены.
Веревка должна быть жестко связана с буфером. Очевидно, что, если мы дадим сигнал об изготовлении новой партии в момент окончания прикручивания колес, узкое место будет простаивать, пока со склада поступят комплектующие, пройдут все необходимые этапы и после сборки попадут на «барабан».
Поэтому веревка передает сигнал, например, в момент поступления следующей партии или когда в текущей остается три машинки для прикручивания колес. Таким образом, за то время, что идет обработка на узком месте, новая партия проходит все предшествующие технологические этапы и приходит точно вовремя к моменту начала работы.
«Прекрасно» – скажите Вы. Но это надо очень точно рассчитать и синхронизировать. Тут Вы правы. Скорее всего, понадобится несколько операций для этого. По сути, снимая ограничения в одном месте, легко создать его в другом.
Для нивелирования противоречий или «конфликтов» в Теории ограничений используется целый набор различных «деревьев».
«Дерево» – это блок-схема, которая отражает алгоритм выявления, анализа и снятия ограничений системы. (Подробнее о «деревьях» в Теории ограничений можно прочитать в книге Уильяма Детмера «Теория ограничений Голдратта: системный подход к непрерывному совершенствованию», ее можно найти в библиографии в конце книги).
1. Дерево текущей реальности описывает причинно-следственные связи между нежелательными явлениями в системе или процессе и ключевой проблемой. По сути это инструмент поиска корневых причина проблемы (как диаграмма Ишикавы в Лин 6 Сигма).
2. Диаграмма разрешения конфликтов помогает снять внутренние ограничения и обеспечить решение проблемы.
3. Дерево будущей реальности призвано смоделировать ситуацию после устранения конфликтов и понять:
a. Позволяют ли предложенные шаги решить проблему и улучшить ситуацию, а также получить желаемые результаты.
b. Не создают ли предложенные решения новых проблем.
5. Дерево перехода совместно с планом преобразований помогает понять, как осуществить перемены с учетом возможных препятствий.
Улучшения можно начать, но невозможно закончить.
Подводя итог, ответим на два вопроса:
Чем хороша Теория ограничений?
1. Она достаточно проста в понимании и освоении. Вам не потребуется больших временных затрат, чтобы с ней ознакомиться.
2. С ее помощью легче понять, с чего следует начинать улучшения (другие методологии не дают четкого ответа на этот вопрос).
3. Проекты не будут занимать много времени и могут принести значимые результаты в короткие сроки (на моей памяти, в течение месяца).
Какие у нее минусы?
1. В отличие от предыдущих подходов, она не позволяет разобрать ситуацию до атомарного уровня. Не вдаваясь в конкретные операции, она не позволяет докопаться до причины того, почему, собственно, узкое место стало узким, и нередко приводит к решениям, когда необходимо менять всю логику процесса.
2. Методология ТОС имеет ограниченный, по сравнению с другими подходами, набор инструментов, большая часть из которых базируется на принципах общей логики и не содержит четких алгоритмов действий. Отчасти поэтому она сложно приживается у части специалистов по улучшениям, которые любят подходы в стиле «делай раз, делай два».
3. Разработанная изначально для и на примере производственных компаний, она мало адаптирована под услуги и некоммерческий сектор.
5. Agile или гибкий подход к управлению проектами.
Подход к работе с IT-проектами, далеко стоящий от процессной истории, но имеющий истоки в бережливом производстве…
Несмотря на все возрастающую популярность подхода сейчас и его беспрецедентное развитие за последние пять лет, когда IT приобретают все более значимую роль, ему есть куда еще развиваться.
Правда, нужно оговориться, что в настоящий момент используется несколько подходов в рамках Agile, называемых фреймворками.
Однако всех их объединяет следование основным принципам, правилам и стандартный набор инструментов в их основе, а потому их можно рассматривать, не углубляясь в детали в рамках единой методологии.
Суть ее проста. Когда-то группа лиц, занимавшаяся разработкой, устала от того, что проекты, связанные с ПО, длятся бог знает сколько времени, а разработчики в конце показывают нечто, что даже отдаленно не напоминает «хотелки» заказчиков. И по предварительному сговору написали Манифест[17] на нескольких страницах. По сути, он и стал основным методологическим документом Agile.
В Манифесте отражено много здравых принципов. Например, что «сотрудничество с Заказчиком важнее условий контракта».
Основной метод работы предлагает поменять сам подход к разработке. Вместо подробного плана на шесть месяцев работа идет двух-трехнедельными Спринтами[18]. Сначала вместе с Заказчиком формируется так называемый Бэклог продукта, то есть все, что должно быть в конечном продукте, и все, что он должен уметь делать. Затем расставляются приоритеты и начинается работа.
В начале каждого Спринта фиксируется все, что должно быть в его конце (например, через две недели). Точнее, из Бэклога продукта берутся несколько пунктов и из них получается Бэклог Спринта. Затем при завершении Спринта уже работающий «кусочек продукта» демонстрируется Заказчику и Клиенту. Тут же вносятся корректировки в планы, принимается решение, что можно улучшить/сделать по-другому на следующем Спринте.
Таким образом, Заказчик и Клиент постоянно следят за ходом работ и могут оперативно вносить изменения, а Бэклог продукта постепенно исполняется от Спринта к Спринту.
При классических методах управления проектами сначала выполняются все работы, а уж затем, в конце тестируется конечный продукт. В случае возникновения ошибки это приводит к тому, что нужно затрачивать
