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

Проект: Платформенный продукт дорабатывается инженерами под требования покупателей. У нас железяки, поэтому у нас есть и производство (сборка) из многочисленных компонентов, которые мы заказываем у сторонних поставщиков.

Что такое Изменение? У нашего продукта есть Платформа: базовое устройство, на которое «навешивается» сверху все требования покупателя и его инфраструктуры. Когда мы приходим к покупателю с ценой – она за Продукт. Продукт = Платформа + Специфика. Продукт – это то, что будет описано в Спецификациях и ТЗ. Но потом начинается работа по детальному проектированию и подготовке к производству. И вот тут начинаются Изменения. Изменения – это Дельта к Продукту. То есть Проданный_Продукт + Дельта = Произведенный_Продукт.

У нас есть разные источники, откуда растут изменения:

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

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

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

Оптимизация со стороны производства
Первая волна изменений происходит на этапе Mock-up (это когда мы из глины и веток делаем наш продукт и показываем покупателю, после чего он обычно ужасается и уточняет/снимает/добавляет некоторые требования). На этом этапе наши коллеги из производственного отдела и покупатель уже дают первую обратную связь инженерам. Вторая волна изменений – когда готов прототип. Прототип – это сборка первого Устройства. Если все срослось с первого раза, то это будет просто первый из серии. Если же что-то не получилось, то отсюда пойдет вторая волна изменений. Третья волна – при полноценном начале серийного производства. Тут начинает выясняется, например, что что-то быстрее скручивать, чем спаивать. Четвертая волна – это когда последние устройства еще не произведены, а первые уже работают и с ними начинают случаться гарантийные случаи.

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

***

Как видите, при таком количестве источников изменений и этапов жизни продукта изменения не только неизбежны, но еще и многочисленны. И даже могут быть лавинообразны (например, после mock-up). Более того, каждое изменение может затрагивать по цепочке и поставщиков и другие отделы. Поэтому мы внедрили процесс управления этими изменениями и назначили в проекте ответственного за Change management.

Когда кто-то хочет/должен что-то изменить, то они сначала формулируют изменения и представляют их Ответственному за изменения (в просторечии он у нас Изменятор, но не все любят такое название). Он смотрит на изменение и затем согласовывает с каждым отделом (Инженеры, Производство, Закупки, Продажи) с одной стороны техническую осмысленность изменения, а с другой – его стоимость.

Стоимость изменения состоит из двух частей: стоимость самого изменения и стоимость его последствий.

Например, инженеры говорят: нам чтобы внести изменения в конструкцию нужно 120 часов, но зато мы сможем у поставщиков закупать попроще компонент (дешевле на Х денег) и при производстве будем экономить 5 часов.

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

Итак, сначала техническая оценка, затем экономическая. Теперь нужна временная оценка: приходит отдел планирования и говорит: ребята, вы, конечно, все это здорово придумали, но если мы будем это делать, то мы тупо по плану не успеем все устройства вовремя доделать и доставить. Тогда подключаем продажников и закупщиков. Закупщики идут к поставщикам и давят, чтобы те сделали/ доставили компоненты раньше (иногда за деньги, иногда за сроки оплаты, иногда из любви к сотрудничеству с нами). Продажники идут к покупателю и говорят: “мы придумали, как сделать наше устройство на 0,1% надежнее, но нам нужно еще немножко времени. Можно мы без штрафов на неделю позже доставим?” При такой аргументации обычно можно договориться. А вот когда наше устройство становится дешевле, то объяснить это покупателю уже очень трудно. Иногда (если экономия от изменения прямо очень существенная), мы можем поделиться с покупателем, иногда мы осознанно задерживаем поставку (в этом случае штрафы за задержку становятся частью стоимостью последствий изменений).

Но, извините, мы забежали немного вперед.

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

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

Раз в неделю мы проводим час обсуждая реестр изменений. Это встреча Change Board. На ней присутствует и руководитель проекта и представитель от каждого отдела.

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

Этапы:
«Мы придумали» — «Мы оценили» — «Мы поговорили» — Одобрено или Отклонено

Борд может отклонить изменение. В этом случае пишется обоснование и изменение остается в реестре со статусом Отклонено. Инженеры сами, уже отдельно от Изменяторов, иногда собираются и обсуждают отклоненные изменения. Иногда изменения возвращаются с этого статуса снова в статус “Мы придумали”, потому что инженеры придумали как это изменить, чтобы это стало более целесообразно.

Если же изменение было одобрено, то работа Изменятора на этом не заканчивается. Он координирует процесс, чтобы все участники поняли, что именно, как и когда надо изменить и отслеживает реальные косты. Потому что так бывает, что инженеры говорят: мы сделаем это за 50 часов, а потом внезапно выясняется, что не все так просто и реально они тратят на это 100 часов. Или производственники говорят, что это изменение сделать сборку быстрее на 20 минут, а на практике ничего не меняется.

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

История: Однажды последствия изменения настигли нас через три года после окончания одного проекта. На борд пришло серьезное изменение. Пришло одновременны в борды двух проектов, которые были примерно на одной стадии и вообще очень похожи. Изменение было дорогое, в серьезный компонент, но инженеры обещали повышение надежности и упрощение сборки. Проект А поколебался и одобрил. Проект Б поколебался и отклонил. Проект А выложил деньги на доработку конструкции. Оценка оказалась очень приблизительной и итоговая стоимость изменений превысила смету в два раза. Проект Б похихикал и порадовался за себя. При сборке в Проекте А оказалось, что это ни фига не упрощение, а даже наоборот. Проект А с матом размышлял, а не откатить ли изменение (было уже поздно) и тратил больше денег на сборку. Проект Б уже ржал. Проекты сдались, доставили покупателям в срок. Первый год – полет нормальный. Проект А на lessons learned жалеет о потраченных деньгах, так как прибыль проект в итоге оказалась скромнее ожидаемой. Второй год – полет нормальный. Третий год – последний год гарантии. И вот тут оно рвануло в Проекте Б. «Серьезный компонент» без доработок посыпался. Треть устройств вернулась на практически полную пересборку. Затраты съели всю прибыль. Устройства Проекта А благодаря Изменению пережили этот год на полном расслабоне. Изменения в «серьезный компонент» внезапно оправдали себя спустя три года.

Самое трудное в работе с изменениями, это их координация после одобрения. Борд одобрил, инженеры свое дело сделали, в конструкцию изменения внесли и спят спокойно. Но вот убедиться, что все изменения дошли до закупщиков, от них до поставщиков компонентов, производственников и прочих участников — это то, где лучше всего проявляется работа Изменятора. Особенно, если изменения происходят после начала производства. Потому что тут крайне важно совместно с ответственным за производство понять, в каких устройствах уже произошли изменения и в каких нет, обсудить со всеми, что делать с уже собранными (пересобирать, использовать по-другому или доставлять как есть), успеть донести до поставщиков, что нам нужен другой компонент, когда мы уже оформили заказ на всю партию, переписать инструкции и чертежи для сборки. Изменятор не тот, кто все это делает, но именно он бегает между всеми и пинает, чтобы все происходило и никто ничего не забыл. На нашей памяти случались встречи, когда люди садились рядышком и проходили по таблице с карандашиком, проставляя галочки, что уже сделано и что нет, а потом подписывали эту таблицу. Это ужасно, что в наш век высоких технологий на производстве высокотехнологичных устройств мы все еще прибегаем к галочкам в табличках, но иногда это единственный способ. Для отслеживания жизни Изменения, мы внедрили целую серию разных статусов изменения, чтобы было понятно, что, например, уже обсудили с закупками, а что еще нет. Между статусом “Одобрено” и статусом “Внедрено полностью” еще два десятка статусов, между которыми прыгает изменение.

“Внедрено полностью” — это тоже не конец работы Изменятора с изменением. Изменение все еще не просто присутствует в реестре, но и отделы вносят информацию по фактическим затратам и изменение просматривается на Борде в общем реестре. После окончания проекта (выпуск всех устройств и передача их покупателю) реестр изменений вместе со всем остальным добром проекта передается в гарантийный отдел. Они будут вносить туда информацию о том, как вело себя изменение в гарантийной фазе, привело ли к дополнительным экономиям или затратам.

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

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

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

PS: Мы уже дописали эту статью и дали посмотреть коллеге. Он вздохнул и сказал, что слишком много слов там, где можно добавить три-четыре блок-схемы процессов. Но наш опыт показывает, что многие люди с трудом читают блок-схемы и нарратив обычно идет легче. А вам как?