Как встраивать качество в бизнес-процессы?

Одна из ключевых идей бережливого производства – сокращение потерь. Все типы потерь так или иначе связаны с качеством результатов выполнения работ, но два из них – «дефекты» и «дополнительная обработка» – напрямую. 

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

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

В статье мы рассмотрим практики встраивания качества, применимые для команд и подразделений, работа которых связана с разработкой каких-либо бизнес-, технологических, программных и прочих решений, подразумевающих уникальность создаваемого результата, а значит, и вариативность в выполняющихся рабочих заданиях. Сегодня достаточно хорошо проработана идея встраивания качества в бизнес-среду в рамках  Scaled Agile Framework® , идеями которого мы будем пользоваться далее.

1. Организовать поток

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

Правильной практикой здесь будет избегать проектного подхода  «старт – стоп – старт» , при котором недопустимо вносить изменения в процесс разработки. Лучше разбивать всю разработку на множество максимально независимых и небольших по сложности элементов. Они будут выстраиваются в поток и постепенно продвигаться в реализацию, улучшая и модифицируя задел оставшейся работы. Для улучшения скорости и качества потока мы должны использовать крайне важную в Lean практику – ограничивать  объем незавершенной работы  – количество элементов, одновременно находящихся в процессе разработки.

2. Обзор работы коллегами и парная работа

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

3. Коллективное владение на основе стандартов

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

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

4. Автоматизация

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

• автоматизация операций, связанных с разработкой;

• автоматизация операций, обеспечивающих необходимые проверки качества.

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

5. Определение завершенности

Эта практика подразумевает, что все участники команды разработки приняли и одинаково понимают перечень действий, которые должны быть выполнены, чтобы работы по данному элементу были признаны завершенными. В ИТ набор таких правил называется  DoD . Отдельные пункты такого определения должны касаться проверок и подтверждений различных аспектов качества. Важно понимать, что здесь идет речь об универсальном определении, которое относится ко всем работам, выполняемым командой. У самой работы  может быть  специфический набор критериев приемки, который на уровне общего определения команды будет звучать как «все критерии приемки элемента выполнены». 

Рассмотрим некоторые примеры определений завершенности на уровне команды:

• работа просмотрена кем-то из коллег (получена рецензия);

• все критерии приемки элемента выполнены;

• все тесты качества пройдены успешно (в идеале – в результате автоматизированного тестирования);

• все физические артефакты внесены в систему учета и переданы;

• все результаты работ сгенерированы и опубликованы;

• уведомления по электронной почте отправлены и т.д.

Такие определения, отвечающие на вопрос: что значит «работа завершена»? – позволяют создать единое понимание того, в чем заключается качество и какие операции, кроме разработки, необходимо выполнить, чтобы встроить качество непосредственно в процесс создания решения.

Использовать производственный Lean в бизнес-организациях без его существенной адаптации в части  вариативности бизнес-процессов  нельзя. Это, к слову, было причиной многих неудачных lean-трансформаций бизнес-процессов на предприятиях в разных странах мира. Зато, если вы уделите должное внимание пяти практикам встраивания качества, описанным выше, у вас все получится.