Перевод статьи «"Project Charters: What They Are & How to Use Them» Элизабет Свон выполнил Вадим Сеничев
В мире Бережливого Производства и Шести Сигм устав проекта играет роль скрепляющего договора между командой по улучшению и спонсором или чемпионом проекта. Он обеспечивает среди всех участников процесса понимание того, что каждый из них должен делать в рамках проекта. Это помогает согласовать команду внутри себя, со спонсором проекта и с компанией в целом.
Его часто называют
«живым документом», что означает, что
его следует регулярно обновлять, особенно на этапах определения и измерения DMAIC. Когда команда картирует и измеряет процессы, появляется больше новой информации о проекте, что влечет за собой изменения информации в Уставе. Обновляется базовый уровень, добавляется глубина к постановке задачи и расширяется рабочая группа, если это имеет смысл. Устав «жив», но дальнейшие изменения редко вносятся после завершения фазы анализа.
Существует шаблон Устава проекта (таблица xls сверху), и, хотя требуемая для внесения в нее информация кажется разумной, способ заполнения таблицы не всегда очевиден. Даже с примерным списком вопросов, на которые стоит ответить, более полезно посмотреть, как это делали другие команды. Еще более полезно посмотреть на то, чего делать не стоило.
Хотя причиной появления Устава проекта является обнаружение проблемы, существует гибкость в отношении того, какие его элементы следует выполнять в первую очередь. Мы будем следовать типичной последовательности и проработаем 6 основных сегментов Устава проекта. В этой статье предложим рекомендации, рассмотрим примеры и выделим несколько наиболее опасных ошибок.
- Постановка проблемы
Постановка проблемы или заявление о проблеме проясняет конкретную проблемную ситуацию, иначе говоря, «что болит». На эту «боль» обычно ссылаются с точки зрения избыточного времени, дефектов или превышения стоимости производства или оказании услуги. Процессы занимают слишком много времени, и в них слишком много ошибок, и то и другое увеличивает расходы. Это «боль» с точки зрения клиентов процесса - внутреннего или внешнего. Постановка проблемы невозможна без использования такого инструмента, как Голос Клиента.
Определение проблемы звучит просто: «Мы теряем деньги на учебниках» или «Процесс подачи заявки занимает слишком много времени». Эти утверждения определенно звучат как проблемы. Но цель Устава проекта состоит в том, чтобы обеспечить ясность, и ни одно из этих заявлений полностью не разъясняет сути проблемы. Сколько денег мы теряем? Какие именно учебники убыточны? Чтобы упростить определение проблемы, мы создали 5 вопросов, требующих ответа в Уставе:
Нам нужно знать:
- В чем именно состоит проблема?
- Когда она происходит?
- Какова величина или частота проблемы?
- Где она происходит?
- Как она влияет на клиентов и организацию?
Эти вопросы приводят нас к большей ясности:
«В течение последних 2 лет (когда) поставки учебников по естествознанию для средней школы Бета (где) не поступали в библиотеки (что происходит) в 30% случаев (величина) , что привело к среднегодовым затратам в размере 150 тыс. долларов (воздействие)».
Это полезная Постановка проблемы. В ней можно проследить множество подробных наблюдений. Обратите внимание, что это заявление включает только одну проблему, отсутствующие учебники. В это утверждение не пытались добавить другие вопросы, такие как «учебники по естествознанию не поступили и имеют низкое качество». В конкретной ситуации мы пытаемся решить проблему пропавших учебников. Очень важно удерживать фокус на единственной проблеме. Но даже очень целеустремленные команды могут сбиться с пути во время ее определения.
Мне доводилось встречать и такие варианты постановки проблем:
«Команда по техническому обслуживанию теряет 30% наших учебников из-за дезорганизации, которая потребует установки нового программного обеспечения для мониторинга и отслеживания всех доставленных учебников, чтобы сократить ежегодные затраты на замену в размере 150 000 долларов».
Читая это, что вы можете почувствовать назревающие проблемы. Что произойдет, когда такая команда проекта, работающая из лучших побуждений, обращается к группе обслуживания для сбора данных? Что произойдет, когда новое программное обеспечение не сможет решить проблему? То, что вы видите в этом заявлении, является 3 смертными грехами в постановке проблемы:
- Поиск виновного
- Корневая причина
- Решение
1. Поиск виновного (команды техподдержки)
Если вы называете человека, группу или отдел ответственным за проблему, вы создаете беспроигрышную ситуацию. Даже если вы правы и все данные указывают на определенную группу, что вам будет сложно получить какие-либо данные, информацию или сотрудничество от ключевых заинтересованных сторон.
Никогда не ищите виновного при постановке проблемы.
2. Корневая причина (из-за дезорганизации)
Если вы назвали основную причину и вы правы, тогда вам следует решить ее и прекратить тратить время на анализ основных причин с помощью DMAIC. Но если вы не правы, то вы начали проект с ограничивающими основаниями.
Не предполагайте корневую причину при формулировке проблемы.
3. Решение (программное обеспечение все исправит)
Если вы включите решение в Постановку проблемы, вы можете прийти к двум ситуациям. Если это поддающееся проверке решение известной корневой причины, то внедрите его и получите Quick Win (не тратьте время на DMAIC). Но если решение основано на необоснованных предположениях или инстинктах, то реализация ваших будет стоить денег, тратить время копании и при этом, шансы на решение проблемы будут невелики. Не включайте никаких решений в Постановку проблемы.
Постановка проблемы - это «стартовая линия» проекта. Он объявляет базовый уровень проблемы и разъясняет состояние процесса «как есть». Возможно, у вас нет точных цифр, но вы должны знать, что вы ищете, и проинформировать заинтересованные стороны на этапе измерения - «X% отгрузок учебников было пропущено». Теперь давайте вернемся назад и рассмотрим экономическое обоснование для решения этой проблемы.
Бизнес-кейс или экономическое обоснование является «причиной существования» проекта. Он поднимает проблему до организационного уровня. Глядя на этот проект глазами бизнеса и конечных клиентов, имеет ли смысл ее решать? Стоит ли заниматься проектом?
Экономическое обоснование
Бизнес-кейс или экономическое обоснование является «причиной существования» проекта. Он поднимает проблему до организационного уровня. Глядя на этот проект глазами бизнеса и конечных клиентов, имеет ли смысл ее решать? Стоит ли заниматься проектом?
Бизнес-кейс должен решить эти 4 вопроса:
- Почему этот проект стоит делать?
- Почему это важно сделать сейчас?
- Каковы последствия
отказа от этого проекта
Как это согласуется с бизнес-инициативами и целями?
Вот экономическое обоснование для осуществления проекта с недопоставленными учебниками:
В течение последних 2 лет школьный округ Акме заказывает новые учебники взамен тех, которые были утеряны или списаны. Это происходит по всему округу и приводит к потерям примерно 100 тысяч долларов на школу ежегодно. В некоторых случаях это приводит к тому, что на начало учебного года учащиеся остаются без учебных материалов. Учитывая текущую стратегическую инициативу по сокращению потерь при поставках учебных материалов и оборудования, решение этого проекта повлияет на ключевой индикатор процесса (KPI) затрат на снабжение. Если мы не решим эту проблему сейчас, затраты на замену отсутствующих учебников уменьшат бюджет округа на общие учебные материалы для учащихся. Это угрожает нарушить учебный процесс по всему округу.
Становится понятно, насколько важно сделать этот проект. Он связан с организационной стратегией всего округа, соответствует его целям и связан с ключевым индикатором процесса. У нас есть проблема, и ее стоит решить - пора установить цель с помощью заявления о цели.
Продолжение следует)
Сообщество Lean+6Sigma в России
Всё что нужно знать участнику проекта в онлайн курсе 
Обучаем и внедряем с 1999 года!
Создадим систему вместе и вперед за результатом!