1. Что же такое «Кайдзен»

Это концепция, согласно которой наша жизнь в целом (трудовая, общественная и частная) должна быть ориентирована на постоянное улучшение, совершенствование. Улучшения скорее носят незначительный, на первый взгляд, и даже не очень заметный характер. Иными словами, Кайдзен означает небольшие улучшения в ходе текущей работы, не меняющие статус-кво. Инновация представляет собой коренное преобразование, которое изменяет статус-кво и осуществляется в результате крупных инвестиций в новую технологию и/или оборудование. Это принципиальное отличие между Кайдзен и инновационным менеджментом, характерным для «западных» управленческих культур (США, Европа, Россия), где, если уж решились на «рывок», то он сопровождается масштабными, а значит дорогими и очень сложными изменениями. При этом риск провала таких изменений остается актуальным.

Что отличает кайдзен-ориентированные организации от традиционных? Два главных направления приложения усилий менеджмента – это поддержание и совершенствование. Под поддержанием понимаются действия, призванные сохранять текущие технологические, управленческие и организационные стандарты; под совершенствованием – действия, направленные на улучшение действующих стандартов (Рис. 1):

Рисунок 1. Различия в распределении рабочих функций

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

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

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

2. Семь принципов Кайдзен

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

2.1. Следующий процесс – это клиент

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

Этот подход также применяется к промежуточным и внутренним процессам компании. Это означает, что каждый сотрудник должен поставить себя на место следующего сотрудника, который будет оперировать результатами предшествующего процесса. Это возможно, если каждый сотрудник будет понимать, чего от него ожидает «последователь / клиент», и учитывать эти ожидания в своей работе (Рис. 2):

Рисунок 2. Следующий процесс – это клиент

2.2. Раннее выявление проблем качества

Выявление проблем с качеством в конце производственного процесса слишком дорого.

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

Это яркий пример из бизнеса автопроизводителей, когда проблемы обнаруживаются очень поздно и их устранение влечет за собой не только репутационные издержки в виде отзывов клиентов, но и затраты на логистику, предоставление подменных авто, компенсацию морального и физического вреда в результате судебных процессов, производство и замену проблемных узлов и т.д. (Рис. 3):

Рисунок 3. Проблемы с качеством выявляются слишком поздно

Если бы причины таких проблем прогнозировались и устранялись еще на этапе проектирования продукта, то себестоимость продукта была бы ниже. И в условиях конкурентного рынка клиент бы несомненно выиграл, имея возможность предпочесть более совершенный продукта, а не результат труда производителя из «проклятого места». Чем раньше выявляются проблемы качества продукта, тем дешевле и проще их решать (Рис. 4):

Рисунок 4. Проблемы качества лучше выявлять раньше

В идеале процесс необходимо выстраивать так, чтобы проблемы с качеством либо не возникали вовсе, либо об их появлении мы бы узнавали сразу и могли оперативно устранить их (Рис. 5):

Рисунок 5. В идеале - проблемы вообще не допускать

2.3. Качество прежде всего

Качество является наиболее важным фактором в процессе Кайдзен.

Чтобы быть уверенным в производстве качественных продуктов и услуг, необходимо соблюдать 3 простых правила (Рис. 6):

не передавать некачественный результат;
не производить некачественную работу;
не принимать некачественный результат.

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

2.4. Управление на основе данных

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

Если у вас нет надежных данных, на которых можно было бы основывать свои действия, вы должны остановиться, прежде чем действовать, и сначала собрать данные и проанализировать их.

2.5. Контроль неопределенности

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

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

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

Чтобы убедиться, что мы установили стандарты для каждой изменяющейся переменной, можно использовать диаграмму Исикавы (Рис. 7):

Рисунок 7. Рыбная кость для контроля энтропии

2.6. Ориентация на рынок (потребности внешних клиентов)

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

Многие Организации, достигнув успеха, остаются пленниками своих собственных парадигм и впадают в замкнутый круг самовосхваления; тем временем рынок продолжает развиваться, потребности клиентов меняются, а конкуренты предлагают новые продукты.

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

2.7. От S-D-C-A к P-D-C-A

Эти циклы менеджмента, получившие известность благодаря работам Эдвардса Деминга, одного из отцов-основателей японского чуда. Они необходимы для порядка в нашей деятельности, особенно, когда есть острый запрос на повышение управляемости, предсказуемости (SDCA), реализации и обеспечения приживаемости изменений (PDCA).

Справка:

SDCA: описываем стандарт – работаем по стандартам – проверяем результаты стандартизированной работы – изменяем стандарты.

PDCA: планируем изменение – реализуем изменение – проверяем результаты – корректируем или применяем результаты.

Эта концепция требует, чтобы перед тем, как приступить к каким-либо улучшениям, были стабилизированы процессы, которые не дают предсказуемых результатов; после стабилизации результатов с помощью цикла стандартизации SDCA можно реализовать цикл улучшений с помощью PDCA. Буква P в термине PDCA означает «планирование» (Planning) и в данном контексте относится к планированию улучшений (Рис. 8):

3. Что можно и стоит применить при внедрении ИС

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

3.1. Следующий процесс – это клиент и Раннее выявление проблем качества

На первом месте идут неразрывно связанные друг с другом принципы «Следующий процесс – это клиент» и «Раннее выявление проблем качества», применение которых позволяет устранить «необязательные» потери в производственном процессе и как можно раньше выявлять дефекты, т.е. предупреждать проблемы с качеством (Рис. 9):

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

Рисунок 10. Этапы жизненного цикла ИТ-проекта

Отдельного упоминания стоит процесс, в котором участвует несколько команд, разрабатывающих разные компоненты / подсистемы продукта ИТ-проекта (Рисунок 11):

Рисунок 11. При параллельной разработке возникают кросс-командные "фильтры"

Этот принцип применим не только к основной части продукта ИТ-проекта, информационной системе, но и к остальным частям:

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

Приведу несколько примеров.

«Классические» этапы реализации ПАП ИТ-проекта и они же с применением Кайдзен-принципа (Рис. 12):

Рисунок 12. Жизненный цикл ПАП в ИТ-проекте

Этапы подготовки и загрузки начальных и/или исторических данных ИТ-проекта без применения Кайдзен-принципа с ними (Рис. 13):

Рисунок 13. Жизненный цикл данных в ИТ-проекте

Кстати, в случае, когда в проекте планируется собирать данные вручную, стоит применить Poka-Yoke, когда в шаблоны сбора данных встроена «защита от дурака», которая не позволяет пользователям внести некорректные данные. Это легко делается средствами excel.

3.2. Качество прежде всего

Вспомним про три правила о качестве:

не передавать некачественный результат
не производить некачественную работу
не принимать некачественный результат

Стоит оговориться, что в случае с проектной деятельностью необходимо оперировать не «абсолютным» и постоянно (на протяжении всего жизненного цикла продукта) повторяемым качеством, к которому стремится операционное производство, а максимально возможным качеством, которое реально достижимо в рамках существующих проектных ограничений.

Иными словами, это понятие стоит сформулировать так:

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

Соответственно, три максимы о качестве стоит сформулировать с учетом проектных ограничений:

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

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

3.2. Управление на основе данных

В процессе реализации ИТ-проектов возникает масса объектов, которые влияют на качество, и должны быть посчитаны.

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

На Рис. 14 приведены объекты, которые могут и должны быть посчитаны:

Рисунок 14. Составляющие проекта, которые могут и должны быть посчитаны

Итак, измерить, посчитать и контролировать «по цифрам» можно и нужно следующее:

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

количество обращений пользователей после начала работы с продуктом проекта (системой)
тип и характер обращений (вопрос / ошибка)
количество обращений пользователей в работе у поддержки
скорость закрытия обращений
оценка пользователей по итогам закрытия обращений
количество ошибок в разрезе критичности
прочие метрики SLA.

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

Если в рамках проекта нет возможности автоматизировать их сбор, то целесообразно поручить их сборку и обработку администратора проекта, чтобы процесс анализа был сравнительно дешев.

3.4. Контроль неопределенности

В ИТ-проектах методы из Кайдзен применимы для:

управления рисками и проблемами;
контроля и управления качеством;
управления открытыми вопросами и проблемами;
формирования уроков на будущее;
работой с неопределенностью (допущения и ограничения проекта).

На рис. 15 приведен пример использования диаграммы Исикавы («рыбная кость») для идентификации рисков ИТ-проекта:

Рисунок 15. Идентификация рисков с помощью диаграммы Исикавы

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

Например, если мы говорим о таком компоненте, как «Люди / команда», то традиционными рисковыми зонами становятся «компетентность», «мотивированность», «готовность изменений» и т.д. Но для идентификации большего количества рисковых зон стоит рассмотреть не только этот компонент, но и обратить внимание на пересечение этого компонента с другими:

«Люди / команда» − «Оборудование»
«Люди / команда» − «Регулятор»
«Люди / команда» − «Стейкхолдеры»
«Оборудование» − «Регулятор»
«Разработка» − «Регулятор»
«Регулятор» - «Пользователи»

и т.д.

3.5. От S-D-C-A к P-D-C-A

Что касается циклического управления, то в зависимости от этапа жизненного цикла проекта целесообразно применять SDCA и PDCA следующим образом (Рисунок 16):

Рисунок 16. На каких этапах применимы циклы SDCA, PDCA

Когда речь заходит о цикле SDCA, то важно стандартизировать следующие сущности:

подходы к проектированию;
подходы к настройке, разработке, тестированию и deploy-процессам;
подходы к документированию;
отчетность и процессы коммуникации с заинтересованными сторонами;

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

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

3.6. Формирование уроков на будущее

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

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

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

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

Источником уроков на будущее должны стать минимум четыре группы заинтересованных сторон:

бизнес-заказчик и представители его команды;
участники «внутренней» ИТ-команды проекта
участники «внешней» ИТ-команды проекта (подрядчики)
команда управления проектом (руководитель проекта, администратор проекта, руководители функциональных групп)

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

Для претворения в жизнь полноценного цикла PDCA в качестве источника информации выступают следующие артефакты:

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

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

5. В завершение

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

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

В этом и прелесть этого довольно старого, но работающего подхода.

Данную статью я написал в продолжение нескольких постов в ТГ-канале "Безжалостный project" о кайдзен-практиках для руководителей проектов. Если сочтете канал интересным, подписывайтесь на него :-)

Кайдзен-подходы в проектах разработки и внедрения информационных систем