Использование теории ограничений в управлении проектами реферат

Обновлено: 04.07.2024

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

Но подавляющее большинство проектов все-равно выбиваются из графика. Узнать на этапе планирования длительность всех задач со 100%-ой точность практически невозможно, даже в тех случаях, когда такая задача уже делалась раньше. Этому могут помешать уже на этапе исполнения непредвиденные обстоятельства:

  • Смена исполнителя, например по причине болезни или увольнения ранее назначенного
  • Проблемы у поставщиков, если задача связана с внешними ресурсами
  • Проблемы с финансированием
  • и просто закон Мерфи — если что-то плохое может случиться, то оно обязательно произойдет

Любой проект имеет риски, связанные с неопределенностью. А значит каждая задача будет иметь вероятность завершения в запланированную дату меньше 100%. Так почему же мы рассчитываем, что весь проект, состоящий из множества последовательных и параллельных задач, которые не имеют 100% вероятности завершиться в запланированное время, должен завершиться в назначенную дату?


К этому нужно еще добавить, что вероятность завершения двух последовательно выполняющихся задач, имеющих вероятность завершения в запланированное время равную 90%, составляет уже 81%. Другими словами, если мы не будем использовать положительные отклонения тех задач, которые заканчиваются раньше запланированной по календарю даты, то вероятность закончить весь проект в срок стремится к нулю.

Но в этом то и состоит одна из проблем календарного планирования. Задачи, которые удалось завершить раньше срока, не могут передать эстафету следующим за ними. Ресурсы, которые требуются на эту задачу не готовы, они заняты в других задачах и на других проектах. Время этих ресурсов было заранее распределено в соответствии с календарными планами всех проектов, где они участвуют. Поэтому, перейти на ту задачу, которую смогли завершить раньше, часто просто некому.

Более того, если вы попробуете вспомнить из вашей практики случаи, когда задачи завершались раньше, чем в запланированную дату, то не так много таких случаев вспомните. Подавляющее большинство задач завершалось с опозданием, или в лучшем случае в строго назначенное время. Почему так происходит? А что бы случилось, если бы кто-то при планировании сказал нам, что ему требуется 20 дней на эту работу, а сделал ее за 10 дней? Скорее всего, мы бы в следующем проекте сразу бы планировали 10 дней на аналогичную задачу.

Поэтому, понимая что так произойдет, люди продолжают выполнять задачу, стараясь еще раз перепроверить результат, либо улучшить его. А так как нет предела совершенству, то улучшать можно до бесконечности, или до нужной даты. Хотя конечно, чаще все-таки люди переключаются на выполнение других задач, но не сообщают руководителю проекта об этом, чтобы в следующий раз не уменьшили время на эту задачу, и остался резерв на непредвиденные обстоятельства. Таким образом, положительные отклонения в длительности выполняемых задач, крайне редко помогают проекту завершиться вовремя.


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

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

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

image

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

Что такое ТОС

Теория ограничений систем (ТОС, Theory of constraints) — это методология управления системами в различных видах деятельности, суть которой заключается в поиске ключевых ограничений, определяющих успех и эффективность всей системы в целом.

ТОС была создана в 1980-х годах израильским физиком и философом Элияху Голдраттом, который прославился как автор нескольких бестселлеров деловой научно-популярной литературы. До этого Голдратт много лет работал в сфере разработки программного обеспечения для оптимизации технологии производства.

На данный момент это популярная методология, которой пользуются во всем мире. Вот небольшой список компаний и институтов, которые открыто заявили о том, что используют Теорию ограничений:

Причина популярности теории — простота и универсальность, поскольку принципы, методы и инструменты ТОС можно использовать для устранения ограничений любых систем, а значит и повышения их эффективности.

Вопрос эксперту

Несмотря на свои прорывные решения, ТОС в России не так популярна как Agile, про неё не говорит Греф. И её мало кто знает и еще меньше — кто применяет. Возможно, это связано с высокой стоимостью литературы, обучения или отсутствием литературы на русском языке. Насколько мне известно, по некоторым изданиям не удалось договориться о переводе на русский язык.


Основы ТОС

Положения

Основной постулат ТОС — большое количество целей системы недостижимы из-за небольшого количества ограничений. Для поиска ограничений используется фокусирование на проблеме, после того, как ограничение найдено, вся система начинает работать на то, чтобы его снять. То есть успех всей системы определяется ключевым ограничением.

Таким образом, если прилагать усилия к управлению небольшим количеством аспектов системы, можно получить эффект, который будет намного превышать результат от воздействия на все проблемные участки. Вместо того, чтобы растрачивать усилия, пытаясь улучшить сразу все, вы бросаете все ресурсы и внимание на самый слабый участок системы.

У вас работает 5 менеджеров по продажам, которые продают 50 сайтов на разработку в месяц. А программист в штате всего 1, и он успевает развернуть только 1 сайт в неделю. Итого возможности вашей системы равны 4-м сайтам в месяц, вне зависимости от того, сколько договоров вы продали.

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

Функция "чтения" служит для ознакомления с работой. Разметка, таблицы и картинки документа могут отображаться неверно или не в полном объёме!

СодержаниеВведение

1. Основные концепции теории ограничений

1.1 Общая характеристика теории ограничений

1.2 Пять шагов для ликвидации "ограничения"

1.3 Методы, предлагаемые теорией ограничений

2. Практические аспекты применения теории ограничений в России и за рубежом

2.1 Зарубежный опыт применения теории ограничений

2.1.1 Опыт внедрения Теории ограничений в Индии

2.1.2 Опыт внедрения Теории ограничений в Японии

2.2 Применение теории ограничений в России на примере медицинского учреждения

Список использованных источников

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

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

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

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

С появлением теории ограничений Голдратта (Theory of Constraints, TOC), и прежде всего той ее части, которая в литературе получила название метода рассуждений Голдратта, технологии работы со знаниями поднимаются на качественно новый уровень. Можно сказать, что "старательский" метод добычи драгоценного знания уступает место "индустриальному" подходу.

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

Объект исследования - теория ограничений, предмет - управление рисками.

Цель курсовой работы - раскрыть сущность теории ограничений, рассмотреть типы ограничений, узкое место. Задачи работы:

И тоже самое можно сказать о конфликтах в команде. Когда видишь конфликт интересов но решить его в лоб, административным рычагом, будет не самым правильным выходом. Нужно искать корневую причину конфликта и решать ее.

Ищем причины

Часто, анализируя деятельность компании мы видим множество разрозненных но очевидных фактов типа:

  • заказчик недоволен
  • много ошибок в коде
  • много доработок при сдаче
  • не успеваем со сроками
  • долго разрабатываем


Могут ли эти факты быть ключевой проблемой которую. надо решать? — Могут, а могут и не быть. Пока мы не попытаемся связать их в дерево причинно следственных связей.


Потому что скорее всего это не является истинной причиной проблемы. И нужно копать дальше.

И при ответе на эту группу вопросов можно выявить что:

  • Много ошибок в коде ПОТОМУ ЧТО нет тестирования
  • Нет тестирования ПОТОМУ ЧТО не хватает времени
  • Не хватает времени ПОТОМУ ЧТО контракт заключен поздно.
  • Не хватает времени ПОТОМУ ЧТО неправильно оценен объем проекта до заключения контракта.
  • Неправильно оценен объем проекта ПОТОМУ ЧТО не существует готовых метрик.
  • Не существует готовых метрик ПОТОМУ ЧТО не проводится анализ проектов.

Ух ты, оказывается что проблема лежит вовсе не на стороне разработки, а закопана глубже, и лежит еще в области подготовки к заключению договора.

Но ВАЖНО что на поверхности эти проблемы не лежали. И строя полную картинку



Можно найти ключевую проблему с которой и нужно применять изменения бизнес процессов. Данный пример короткий, но показывает что не все что лежит на поверхности действительно является ключевой проблемой. И при анализе состояния может выявиться еще 50 различных фактов влияющих на систему, а встраивая их всех в дерево причинно следственных связей и выявляя что является следствием а что причиной можно найти именно то самое ограничение системы которое нужно исправлять в первую очередь.

Решаем проблемы

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

И здесь мы можем прийти к конфликту.

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



  • мозговой штурм.
  • теорию решения изобретательских задач. (ТРИЗ)
  • шесть шляп мышления

Или применить тот же самый логический подход, и выявить ложные предпосылки приводящие выбору методов обеспечения наших условий. Такак метод выбирается не только для обеспечения условия но на основании каких-то еще влияющих факторов. Иногда бывает что метод выбран правильно, но ошибка может крыться в условиях которые приводят к этим методам и тогда нужно поставить под сомнение сами условия приводящие к конфликту. Для этого тоже нужно исследовать предпосылки.

  1. Экономия времени — Зачем? Сколько времени даст экономия? Есть ли другие способы экономии времени?
  2. Долгая поддержка — Насколько долгая? Как часто меняются команды? Какой прогноз темпов развития? Есть ли другие способы обеспечения условия?
  3. Не писать документацию — К чему это приведет? Какие будут нежелательные явления? Какие риски возрастут? Какой будет положительный эффект? Какие будут убытки?
  4. Писать документацию — Сколько это стоит? Сколько денег это принесет? Что для этого нужно? Какую именно документацию нужно писать? Как определить что это мы пишем а это не пишем?

Прорабатывая каждую из этих веток можно выявить каике-то ложные предпосылки лежащие в основе условия или выбранного метода, которые могут быть ложными или исходят из более других корневых причин.

Проверяем последствия

Если в результате анализа выявлено что наши условия действительно верные, но грозовая туча не решается, то можно проверить воздействия каждого из методов на систему в целом анализируя желательные эффекты (ЖЭ) и нежелательные явления (НЖЯ). Это можно проверить построив дерево будущей реальности:

Если мы будем писать документацию то

  • ЖЭ. У нас будет больше информации о принятии решений в будущем что повысит нашу стабильность выполнения работ.
  • НЖЯ. Но одновременно с этим нужно будет тратить время на документирование
    • Но мы можем встроить документирование в процесс обдумывания проектных решений
      • ЖЭ. ТОГДА документы будут рождаться как побочный продукт и
      • ЖЭ. Проектные решения будут лучше продуманы.