"Реинжиниринг корпорации. Манифест революции в бизнесе" - читать интересную книгу автора (Хаммер Майкл, Чампи Джеймс)

Глава 7 Поиск возможностей проведения реинжиниринга

Как уже говорилось, объект реинжиниринга — процессы, а не организации. Реинжинирингу в компании подвергаются не отделы продаж или производства, а работа, выполняемая их сотрудниками.

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

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

Мы не придумали процессы, чтобы писать о них. Любая компания на самом деле состоит из процессов: они представляют собой ее деятельность. Они соответствуют естественным операциям, но часто фрагментированы и скрыты за организационными структурами. Процессы незаметны и не имеют названий, потому что люди думают об отделах, а не о процессах, в которых они участвуют. Процессами обычно никто не управляет — в том смысле, что людей назначают директорами отделов или рабочих подразделений, но ни на кого не возлагают полную ответственность за выполнение работы.

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

— разработка продукции; от концепции до прототипа;

— продажи: от потенциального покупателя до оформления заказа;

— выполнение заказов; от оформления заказа до получения оплаты за него;

— сервис: от получения запроса до решения возникшей проблемы.

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

Это можно увидеть на карте процессов верхнего уровня в направлении полупроводников компании Texas Instruments, занимающейся производством микросхем и разработкой решений для обработки цифрового сигнала. (На рис. 2 карта приводится в несколько упрощенном виде.) Выделяются четыре интересные особенности.

Первая — простота карты в сравнении с организационной схемой той же компании. На карте показано только шесть процессов для бизнеса стоимостью в $4 млрд. Один из руководителей Texas Instruments заметил: «Пока мы не нарисовали эту карту мы думали, что наша компания гораздо сложнее». Этот пример не является уникальным; скорее всего приблизительное количество главных процессов в любой компании — не более десяти.

Рис. 2. Карта процессов в направлении полупроводников компании Texas Instruments

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Рассмотрим симптомы, по которым можно диагностировать болезни организации.

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

Если разные организационные группы обмениваются одной и той же информацией, каждый раз заново вводя ее в компьютер или пересылая ее электронным путем, это означает, что естественный ход дел разбит на фрагменты. Организационные единицы с продуманной схемой работы должны посылать друг другу законченные продукты. Активный обмен данными — не лучший способ преодолеть искусственно созданные границы. Чтобы решить эту проблему, нужно объединить разрозненные элементы деятельности или процесса. Другое название этого метода — межфункциональная интеграция. Она позволяет зафиксировать данные всего один раз, а затем делиться ими, а не находить способы быстрее передавать их туда и обратно.

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

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

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

Многие компании переходят к организации запасов по принципу «точно вовремя» (JIT, just-in-time); на самом деле большинство из них создает запасы «на всякий случай» (JIC, just-in-case). Компании и подразделения знают, что им нужно поставлять свою продукцию клиентам (внутренним иди внешним), но обычно не могут предугадать, когда на нее будет спрос или сколько ее понадобится клиенту. Поэтому они создают резервы (иногда значительные), и не только материальных активов, но и работы, информации, денежных средств и даже сотрудников на случай неожиданного спроса.

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

Организации выполняют много работы, которая не добавляет ценность их продукту или услуге. Мы предлагаем простой тест, чтобы определить, добавляет ли работа ценность. Поставьте себя на место клиента и спросите: «Эта работа имеет для меня значение?» Если ответ отрицательный, работа не добавляет ценность. Важны ли клиенту внутренние меры контроля компании, аудит, управление и отчетность? Нет, все это его не волнует. Это полезно только компании и никак не повышает ценность продукта или услуги.

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

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

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

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

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

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

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

В приведенных примерах описаны самые распространенные симптомы (нарушения функций), с которыми мы часто сталкиваемся в компаниях и которые обычно сигнализируют о проблемах с процессом. Но мы должны еще раз подчеркнуть, что реинжиниринг является в равной степени искусством и наукой, а симптомы не всегда ведут к постановке правильного диагноза. Иногда они могут вводить в заблуждение. Мы работали с одной организацией, где в процессе выполнения заказов были серьезные недостатки, но клиентам так не казалось. Они считали, что компания прекрасно выполняет заказы — без ошибок и вовремя. На первый взгляд, с этим процессом было все в порядке; сильно хромал другой процесс — продажи. Процесс продаж был неисправным? Нет. В очень плохом состоянии был именно процесс выполнения заказов: клиенты вовремя получали продукцию только потому, что продавцы шли на склад, выбирали заказы и доставляли их сами. Клиенты были довольны, но продавцы занимались не своим делом.

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

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

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

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

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

Другие факторы, которые следует учитывать при оценке осуществимости реинжиниринга определенного процесса, — сила команды по реинжинирингу и целеустремленность руководителя процесса.

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

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

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

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

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

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

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

Возьмем ранее приведенный пример с Wal-Mart и Procter amp; Gamble. Pamp;G могли бы просто спросить Wal-Mart: «Какую форму наших счетов вы бы предпочли?» или «Вы хотите, чтобы товары доставляли быстрее?» Но вместо этого Pamp;G и Wal-Mart вместе рассмотрели ситуацию в целом и спросили себя: «В чем реальная задача Wal-Mart?» В этом случае ответ был — максимизировать свою прибыль от продажи подгузников. Затем Pamp;G могли бы спросить: «Как мы можем помочь вам продавать подгузники с большей прибылью? Какие у вас проблемы? Что вам нужно?» Это очень отличается от вопроса: «Как мы можем помочь вам улучшить качество нашего взаимодействия?» Для понимания нужно учесть основные цели и проблемы клиента, а не просто механику процесса, связывающего две организации.

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

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

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

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

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

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

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

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

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

Когда в Xerox решили усовершенствовать процесс выполнения заказов, то сравнивали себя не с другими производителями копиров, а с фирмой L.L. Bean, которая продавала одежду по почтовым заказам.

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

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

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