Применяемые сегодня переводы термина lean часто не отражают его сути – наиболее точным эквивалентом является «тощий», но в России такое определение сочли коммерчески неудобным, приняв вместо него «бережливый» (реже – «экономичный»). В прямом смысле «тощее» производство, в том числе и производство ПО, не является ни бережливым, ни экономичным – оно более «эффективно», но эта экономическая категория проявляется только при правильном управлении.
В середине XX века стало ясно, что потребитель становится более разборчивым и перестает удовлетворяться просто «черным автомобилем» или просто специализированной программой, а хочет разнообразия моделей, функций и удобных интерфейсов. Продукты, тогда преимущественно машиностроения и радиотехники, позже – электроники и ИТ, становятся все более сложными и, как сейчас принято говорить, «конфигурируемыми». В этих условиях узкоспециализированное массовое производство, очень эффективное для выпуска одинаковых изделий небольшой номенклатуры, стало невыгодным. Первоначально, при создании системы управления производством, известной как Toyota Production System, была сделана попытка повысить эффективность поточного производства за счет снижения себестоимости путем исключения непроизводительных затрат: потерь времени из-за ожидания, лишних транспортировок, лишних этапов обработки или потерь из-за выпуска недостаточно протестированной продукции.
При дальнейшем развитии принципов «похудания» стало очевидно, что новые экономические условия общества потребления (конец 70-х) и появление новых видов «производства», в том числе и индустрия программного обеспечения, требуют не просто снижения затрат, а существенного изменения всей системы организации и управления производством. Первоначально предполагалось сделать производственную систему максимально «тощей», устранив излишние мощности, запасы и трудовые ресурсы. Для тощего производства типичной является кластерная организация, включающая одно или несколько основных предприятий и обширный набор вспомогательных и обслуживающих производств. При этом почти каждое предприятие – «тощее», но в целом кластер может быть весьма масштабным. Индустрия программного обеспечения также стремится к созданию подобных кластеров и применению принципов тощего производства – специфическая система управления разработкой программного обеспечения, аналогичная подобной индустриальной системе, имеет название «множественной параллельной разработки» (Set-Based Concurrent Engineering).
Важнейшим изменением в системе управления производством стало переосмысление понятия производственного потока. Если ранее, в массовом производстве, поток предполагался непрерывным и в некотором смысле бесконечным, то в тощем производстве поток привязывается к конкретным заказам клиента. Соответственно поток становится разрывным и состоит из коротких задач, возможно сильно отличающихся по содержанию работ в каждой из них. Таким образом, последний вариант тощего производства по своей сути является системой управления заказным производством. В отличие от российской терминологии, где под «заказом» понимается производственный заказ, в данном случае заказом считается «заказ клиента», и система управления отслеживает заказ от момента продажи до его получения клиентом.
Однако здесь возникает экономическая коллизия – себестоимость единицы изделия, посчитанная традиционным образом, в тощем производстве существенно выше, чем в поточном. Но если правильно организовать производственные потоки и их мощность будет достаточна, чтобы загрузить производственную систему тощего производства, то прибыль будет выше именно в «тощем» варианте. То есть в некотором смысле Lean – это более эффективная система организации в целом. Принципиально то, что характеристики потока в массовом и заказном производстве совершенно отличаются. Соответственно кардинально отличаются и требования к системам продаж и логистики.
Основные принципы системы управления выполнением «нового» потока работ обычно формулируются следующим образом: управление, основанное на ценности продукта; управление потоком создания ценности для этого продукта; непрерывность потока создания ценности продукта; принцип вытягивания; непрерывное совершенствование. Из этого перечня следует, что система организации производства ориентирована на повышение эффективности не за счет снижения затрат, а за счет создания ценностей в ходе выполнения заказа (см. рисунок). Таким образом, это некоторая клиентоориентированная система, при которой клиентом может быть как корпоративный заказчик, так и индивидуальный клиент. Такой подход более универсален, чем традиционный, и применим практически ко всем видам деятельности, включая разработку и внедрение программного обеспечения, что и привело к популярности идеи тощих предприятий во многих видах деятельности.
Попробуем проиллюстрировать принципы тощего производства применительно к индустрии программного обеспечения на примере проекта внедрения продуктов класса ERP. Любопытно, что компания-внедренец обычно как раз представляет собой производственный кластер, состоящий из нескольких относительно самостоятельных подразделений, объединенных общим по отношению к конкретному заказчику процессом «продажа – внедрение – поддержка внедрения». Данный пример по существу проблем полностью аналогичен таким задачам, как разработка заказного программного обеспечения или, скажем, изготовление новой продукции по заказу сети магазинов.
Двигатель программной революции
Истоки методология скорой разработки Scrum лежат в принципах lean manufacturing – именно оттуда был взят доказавший на практике свою эффективность принцип «вытягивания» требований. Для каждой очередной итерации команда «вытягивает» верхние элементы из списка приоритетов, разбивает полученный в результате список функций на список конкретных задач и начинает работать.
Формальным результатом проекта становится работающий на предприятии программный продукт, но реально для заказчика основным является не он, а решение конкретных проблем управления предприятием, которые, собственно, и привели к инициации проекта. Обычно это проблемы, связанные с финансовым управлением, планированием производства, логистикой и т.п. Ключ к успеху решения этих проблем находится не на последнем, завершающем этапе внедрения и сдачи ERP-системы в опытную или промышленную эксплуатацию, а на ранних этапах обследования предприятия, постановки задачи внедрения и системы управления изменениями. Аналогичная ситуация имеет место и при выполнении любого, сколь угодно сложного проекта создания программного обеспечения. Основные ценности проекта внедрения для заказчика проявляются уже на начальных стадиях проекта, когда в процессе взаимодействия с разработчиком и, возможно, консультантами, происходит корректировка целей и задач, результатом которых может быть вообще отказ от разработки нового ПО и лишь перенастройка уже существующих систем или модификация маршрутов выполнения бизнес-процессов. Организация проекта должна обеспечивать создание реальных ценностей для клиента, то есть в данном случае – управленческий и финансовый консалтинг. И в результате проект приобретает совершенно новые черты, становясь, по сути, проектом «взаимного развития» исполнителя и заказчика.
Возможны два варианта реализации системы управления созданием ценностей в ходе проекта для клиента: путем консалтинга со стороны компании-внедренца или путем внутреннего консалтинга заказчика. Оба варианта имеют свои преимущества и свои недостатки. Также случается, но относительно редко, что консалтинг выполняется «третьей стороной». Но в любом случае невозможно получить реально успешный проект, не организовав получение ценностного результата для клиента. Неудивительно, что существует статистика, согласно которой только 20% программных продуктов активно (эффективно) эксплуатируются после внедрения, а 45% вообще реально не используются.
Принцип непрерывности потока ценностей весьма прозрачен. Ошибки, заложенные на этапе постановки задачи и предпроектного обследования, приводят не только к существенным задержкам внедрения, но и нередко к краху проекта. С другой стороны, нежелательно допустить ситуацию, когда заказчик решит ограничиться лишь результатами консалтинга, не приступая собственно к внедрению программного продукта. Для этого ценности, предоставляемые исполнителем, действующим в духе традиционного массового производства, идентифицируются и распределяются по всем этапам проекта. При тощем производстве требуются и иные принципы организации проектной команды – в ситуации тощего внедрения команда консультантов и внедренцев должна быть высококвалифицированной, обладать знаниями не только программного продукта, но и предметной области деятельности заказчика, финансового менеджмента и управления производством. При продажах в стиле массового производства необходимо иметь специалистов, умеющих убедить заказчика в полезности программного продукта для его деятельности, иллюстрируя реальные ценности на конкретных примерах.
Принцип вытягивания выглядит следующим образом: для того, чтобы проект был успешным, команда внедренцев должна обеспечить непрерывную обратную связь через взаимодействие с заказчиком, периодически «сверяя курс» с направлением изменения его потребностей. Аппетит приходит во время еды – это и есть наиболее эффективная реализация принципа вытягивания во внедренческой проектной деятельности. Количество задач по мере внедрения увеличивается, и они усложняются, но для внедренцев важно сохранять «вектор компетентности», не поддаваясь соблазну получить легкую прибыль в смежных областях, пренебрегая высокими рисками.
Непрерывное совершенствование означает: четкую оценку клиентских ценностей; построение карты потока ценностей; идентификацию источников потерь; прогнозирование будущих изменений потока ценностей; фиксацию достигнутых результатов. Система непрерывного совершенствования в целом должна быть направлена на устранение причин ошибок управления и функционирования потока работ.
Применим принципы непрерывного совершенствования к нашему модельному проекту. Несмотря на внешнюю похожесть, клиентские ценности у каждого заказчика отличаются, и важно не находиться
в «шорах» успешных проектов, а уметь идентифицировать потребности конкретного клиента «здесь и сейчас». Для успешного управления продажами проектов и их внедрения в последующем необходимо использовать инструменты визуализации ценностей на каждом этапе проекта, привязки к ним плановых «освоенных объемов» и идентификации «владельцев» каждого из этапов проекта. Построенная карта ценностей может служить руководством к действию для руководителей и всех участников проекта. Поскольку основным ресурсом проекта внедрения являются люди, то нерациональные и непредвиденные потери времени вследствие их ошибок, несогласованности действий, противоречий с клиентом, а также неправильное планирование работ по проекту служат основным источником потерь. В свою очередь, потери времени часто вызываются проблемами взаимоотношений с заказчиком, неверным определением ключевых элементов проекта, а чаще всего – неверно определенными ценностями заказчика, из-за чего приоритет проекта в глазах его руководства резко падает под натиском текущих проблем.
Потребности клиентов постоянно меняются под воздействием внешнего «ветра перемен», изменения внутреннего состояния заказчика, зависят от этапа проекта, в конце концов. Единственный способ постоянно быть в тонусе – непрерывное отслеживание этих изменений и корректировка карты ценностей в соответствии с ними. Для управления потоком создания ценностей необходимо фиксировать результаты, достигнутые в ходе проекта, и проводить анализ перспектив развития клиента, его интересов и потребностей. В принципе все не только окончательные, но и промежуточные результаты проектов должны ложиться в «базу знаний» и становиться основой управления цепочками ценностей будущих проектов.
В целом современная интерпретация Lean Manufacturing как системы управления потоком клиентских заказов в условиях высокой конкуренции – очень перспективная методология управления «производством» в индустрии любого типа. Исполнителю необходимо устанавливать тесные партнерские отношения с заказчиком и стремиться к превращению проекта в цепочку положительных результатов, на основании которых взаимоотношения заказчика и исполнителя будут становиться прочнее и доверительнее.
Сергей Колесников (kolsn@inbox.ru) – независимый консультант (Москва).
Рисунок. Пример изменения ценностей по этапам
ERP потеряли, а SOBA еще не приобрели
Cегодня очень обострилась проблема адаптации программного продукта под конкретную производственную ситуацию, а повсеместное распространение методологий agile manufacturing и реанимированной идеи lean manufacturing привело лишь к технологической уникальности практически каждой производственной системы. Где выход?
