Как повысить эффективность работы инженеров? Системный инжиниринг: два определения эффективности

Что является основной проблемой инженерного процесса? Если спросить профессионалов, они дадут разные, но во многом похожие ответы. И в целом будут недалеки от истины. Роберт Хэллиган, директор одной из ведущих компаний в области системного инжиниринга «Project Performance International», дает на этот вопрос краткий и однозначный ответ: «Основная проблема инженерного процесса — разрабатывать не то».

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

Мы приблизимся к ответам, если внимательно исследуем явление эффективности. Казалось бы, зачем исследовать интуитивно понятное явление? Но еще древние китайцы знали: правильно назвать — это правильно понять. Посмотрим внимательно на само слово «эффективность», и приготовимся к неожиданному открытию.

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

Попробуем перевести слово «эффективно» на английский язык, и внимательно посмотрим на результат. Это слово переводится двумя похожими, но разными английскими словами: «effectively» и «efficiently». Если мы выполним обратный перевод, то обнаружим, что оба этих слова переводятся на русский, как «эффективно». Так что же, эти слова — синонимы? Отнюдь. Если мы примем эту гипотезу, то ничего не поймем.

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

• effectively — in a way that is successful and achieves what you want;

• efficiently — working well and not wasting time or energy.

На русский язык это переводится так:

• effectively — успешно, и с достижением того, что вам требуется;
• efficiently — работать хорошо, не тратя зря время и энергию.

Мы уже гораздо ближе к пониманию. Чтобы его достичь, прочитаем известную мысль знаменитого бизнесмена Питера Друкера, причем в ее полной версии (в скобках указаны английские слова из оригинала): «Главным образом, путаница между эффективностью (effectiveness) и эффективностью (efficiency) стоит между тем, чтобы „делать правильные вещи“ и „делать вещи правильно“. Однозначно, нет ничего бесполезнее, чем делать с большой эффективностью (efficiency) то, что вообще не следует делать».

Нам все понятно! Значения слов «effectively» и «efficiently» таковы:

• effectively — делать правильную работу;

• efficiently — делать работу правильно.

Вооружившись этим пониманием, легко сформулировать положение, которое объяснит мысль, с которой началась эта статья: «Коллектив квалифицированных инженеров, эффективно (в смысле efficiently) разрабатывающий не то, не работает эффективно (в смысле effectively)». Другими словами, чтобы работать эффективно, недостаточно делать работу правильно — необходимо при этом делать правильную работу.

Поэтому, на вопрос «как повысить эффективность работы инженеров», мы задаем встречный вопрос: «какая эффективность имеется в виду — делать работу правильно, или делать правильную работу?».

К слову, делать работу правильно — тоже очень важно. Средства для этого хорошо известны: программное обеспечение CAD/CAM/CAE и PLM, обучение работе с этим ПО, его внедрение и техническая поддержка со стороны официальных вендоров.

Но мы уже знаем, что делать работу правильно — недостаточно. Требуется еще делать правильную работу. И ответ на вопрос «как делать правильную работу» звучит так: системный инжиниринг.

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

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

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

Главное место в парадигме системного инжиниринга занимает анализ системы на требования. Это четко регламентированный процесс, имеющий целью выявление всех требований, которые предъявляются к системе на всех этапах и во всех контекстах ее жизненного цикла. Именно здесь закладывается фундамент для успеха системы и для гарантии ее качества. Очевидно, что качественная система — это система, отвечающая всем предъявленным требованиям.

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

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