Книга: Оптимизатор бизнес-процессов. Лучшие инструменты управления для повышения эффективности
Назад: Глава 7. Это скучная-скучная методология
Дальше: Глава 8. Человеческий фактор

Методология методологии рознь

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

Начнем.



1. ЛИН, ИЛИ БЕРЕЖЛИВОЕ ПРОИЗВОДСТВО.

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

Суть его сводится к трем постулатам:

1) В ПРОЦЕССАХ ПРИСУТСТВУЮТ ПОТЕРИ, ТО ЕСТЬ ДЕЙСТВИЯ, КОТОРЫЕ НЕ НЕСУТ ДОПОЛНИТЕЛЬНОЙ ЦЕННОСТИ И ДЕ-ФАКТО НЕ НУЖНЫЕ ДЛЯ ИЗГОТОВЛЕНИЯ ПРОДУКЦИИ. «ТОЙОТА» ВЫДЕЛИЛА ИХ СЕМЬ, ПОТОМ ДОБАВИЛАСЬ ЕЩЕ ОДНА:

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

• Излишняя обработка. Вы когда-нибудь консультировались в банке по получению, скажем, кредита? Сначала в колл-центре вас расспрашивали обо всем на свете, включая цвет сидений в вашей машине (зачем это нужно, никто не знает, но, наверное, банкам виднее), потом переводили на специализированного сотрудника… и снова спрашивали о том же самом. Вас направляли в офис, и там… все снова с чистого листа. Будьте уверены: каждый сотрудник записывал за вами эту жизненно необходимую информацию, а затем тратил драгоценное время, спрашивая то, что и так должно было быть известно.

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

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

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

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

• Восьмая потеря. Интеллект. Нет, она действительно так называется.

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



2. ВЫТЯГИВАНИЕ ПРОЦЕССА И КАНБАН.

Избежать потерь можно, не только устраняя их, но и изменяя логику обслуживания клиентов. Если не производить тоннами ценную продукцию в надежде, что кто-то ее купит, а работать от заказчика (есть заказ – работаем, нет – не производим), то перепроизводства не будет. Загвоздка в том, что для этого следует переделать процесс таким образом, чтобы можно было выполнить любой заказ быстро. Поможет в этом Канбан: принцип (и карточка на производстве «Тойоты»), согласно которому последующий этап процесса направляет к предыдущему требование выполнить операцию. Например, вам заказали велосипед. Отдел доставки обращается к отделу сборки, тот просит начать работать отдел колес, тот, в свою очередь, обращается за комплектующими в отдел снабжения, и т. д.



3. КАЙДЗЕН.

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

Итак, ЛИН делает процесс быстрее и логичнее и, как следствие, позволяет зарабатывать больше с меньшими затратами в единицу времени. Что же в нем не так?

ЛИН не всегда может вылечить брак, он не всегда позволяет избегать новых ошибок. Почему? В нем нет инструментов глубокого анализа причин возникновения потерь. Возникли – борись. Но инструментов, чтобы докопаться до сути, не так уж много.

ЛИН не всегда позволяет идти от проблемы, он не персонифицирован, если хотите. Нередко он применяется как ковровая бомбардировка, которая подходит ко всем процессам одинаково. Да, в итоге это позволяет ускорять процесс, повышать эффективность на 10–15 или даже на 20 % на первых этапах, а потом? Борьба за каждые полпроцента дополнительной эффективности может растягиваться на годы, а то и на десятилетия.

2) 6 СИГМА.

Придумка компании Motorola. Ее цель – максимально повысить качество. За эталон взят процесс, в котором брак в среднем происходит в 3,4 случая на миллион операций. Достигнуть этого позволяют:

• Цикл DMAIC. Помните, мы уже говорили о нем выше в этой главе? Все шаги проекта максимально стандартизированы, и под каждой фазой определен точный набор инструментов.

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

СТАНДАРТ – ЭТО ОТПРАВНАЯ ТОЧКА ДЛЯ ДАЛЬНЕЙШИХ УЛУЧШЕНИЙ. БЕЗ СТАНДАРТА НЕ МОЖЕТ БЫТЬ ПРОЦЕССА, РАБОТАЮЩЕГО В ПРОМЫШЛЕННОМ ОБЪЕМЕ.

То же самое и с процессом. Если проблема в логике, то можно десять раз поменять персонал и оборудование, но в итоге только усугубить ситуацию.

DMAIC позволяет анализировать глубинные причины, которые влияют на процесс (то есть ставить «диагноз»), и предлагать решение.

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

Как оказалось, причин было две.

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

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

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

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

6 Сигма позволяет докопаться до корневых причин проблемы на основе статистики. При этом предлагает достаточно четкий алгоритм ведения проекта.

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

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

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

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

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

В общем, картина складывается невеселая. С одной стороны, требуются данные:

• ОБЪЕКТИВНЫЕ,

• ПОЛУЧАЕМЫЕ МАКСИМУМ ЗА ДВЕ НЕДЕЛИ,

• НАДЕЖНЫЕ,

• В ЛЮБОМ ТРЕБУЕМОМ РАЗРЕЗЕ.

Дать все вышеперечисленное может только хорошая компьютерная система с базой данных и программой по формированию отчетов (например, Business Objects).

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

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

• КАЖДЫЙ ЗАМЕР ОСУЩЕСТВЛЯТЬ МИНИМУМ ВДВОЕМ, ТАК КАК ОДИН ЧЕЛОВЕК ГАРАНТИРОВАННО УПУСТИТ ЧТО-НИБУДЬ ПРИ ХРОНОМЕТРАЖЕ.

• ПРОХОДИТЬ ПРОЦЕСС НЕСКОЛЬКО РАЗ, ЧТОБЫ БЫЛА ПОНЯТНА КАЖДАЯ ДЕТАЛЬ, ИНАЧЕ РАЗБИТЬ ЗАМЕР НА ШАГИ ИЛИ ЭТАПЫ БУДЕТ ПРОСТО НЕВОЗМОЖНО.

• ДОКАПЫВАТЬСЯ ДО СУТИ КАЖДОЙ ОПЕРАЦИИ. ПРЕДСТАВЬТЕ СЕБЕ: ВЫ СМОТРИТЕ ИЗ-ЗА СПИНЫ ОПЕРАТОРА НА ТО, КАК ОН БЫСТРО-БЫСТРО НАЖИМАЕТ КНОПКИ. И ЧТО? ВЫ МОЖЕТЕ С УВЕРЕННОСТЬЮ СКАЗАТЬ, КАКУЮ ОН СЕЙЧАС ДЕЛАЛ ОПЕРАЦИЮ? И ПРАВИЛЬНО ЛИ?

• ЗАКЛАДЫВАТЬ ДОПОЛНИТЕЛЬНЫЕ РАСХОДЫ НА ЛОГИСТИКУ, ТАК КАК ПРОЦЕСС НУЖНО МЕРИТЬ В НЕСКОЛЬКИХ ТОЧКАХ, ЧТОБЫ ИСКЛЮЧИТЬ ФАКТОР МЕСТНОСТИ.

• ЖДАТЬ. НЕКОТОРЫЕ ПРОЦЕССЫ ПРОТЕКАЮТ РАЗ В НЕДЕЛЮ ИЛИ МЕСЯЦ И МОГУТ ДЛИТЬСЯ ДО ПОЛУГОДА. БЕЗ ОБЪЕКТИВНЫХ ДАННЫХ ОСТАЕТСЯ ТОЛЬКО СИДЕТЬ И ЖДАТЬ.

3) ЛИН 6 СИГМА.

Современный подход, который используется в настоящее время чаще всего. Основу составляет уже знакомый нам цикл DMAIC, насыщенный инструментами ЛИН.

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

а) остается достаточно сложным в освоении; из всех описываемых методик на его изучение потребуется больше всего времени;

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

4) ТЕОРИЯ ОГРАНИЧЕНИЙ ГОЛДРАТА.

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

Все гениальное, как известно, просто. То же самое можно сказать и об идее, лежащей в основе теории ограничений. Возможности любой системы ограничены самым слабым (наименее производительным, наиболее длинным и т. д.) ее звеном.

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

Например, мы хотим, чтобы наш конвейер по производству игрушечных машинок выдавал не менее 10 игрушек в час. Допустим, у нас 4 шага в данном процессе: сборка, прикручивание колес, покраска, добавление наклеек (см. рис. 4).

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





Рис. 4 Шаги процесса

УЛУЧШЕНИЯ МОЖНО НАЧАТЬ, НО НЕВОЗМОЖНО ЗАКОНЧИТЬ.

Теория ограничений позволяет вам работать с разбалансированным процессом (в котором есть авралы и простои) и делать работу более прогнозируемой.

Ключевыми понятиями в ней являются:





1. МЕТОД «БАРАБАН – БУФЕР – ВЕРЕВКА», КОТОРЫЙ ПОЗВОЛЯЕТ:

a. определить ритм, с которым должен двигаться процесс (барабан);

b. рассчитать минимально необходимый запас материалов для обеспечения бесперебойности процесса (буфер);

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





2. РАЗЛИЧНЫЕ «ДЕРЕВЬЯ» (ДЕРЕВО ТЕКУЩЕЙ РЕАЛЬНОСТИ, ДЕРЕВО БУДУЩЕЙ РЕАЛЬНОСТИ, ДИАГРАММА РАЗРЕШЕНИЯ КОНФЛИКТА И Т.Д.). НЕ ВДАВАЯСЬ В ПОДРОБНОСТИ, СКАЖУ, ЧТО ЭТО ЕЩЕ ОДИН АНАЛИТИЧЕСКИЙ АЛГОРИТМ.

Чем хороша теория ограничений? Она достаточно проста в понимании и освоении и не требует больших временных затрат.

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

5) AGILE.

Подход к работе с IT-проектами, далеко стоящий от процессной истории, но имеющий истоки в бережливом производстве…

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

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

В Манифесте отражено много здравых принципов. Например, что «сотрудничество с Заказчиком важнее условий контракта».

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

В начале каждого Спринта фиксируется все, что должно быть в его конце (например, через 2 недели). Точнее, из Backloga продукта берутся несколько пунктов и из них получается Backlog Спринта. Затем при завершении Спринта уже работающий «кусочек продукта» демонстрируется Заказчику. Тут же вносятся корректировки в планы, принимается решение, что можно улучшить / сделать по-другому на следующем Спринте.

Таким образом, Заказчик постоянно следит за ходом работ и может оперативно вносить изменения.

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

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

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

6) РАЗРАБОТКА ПРОЦЕССОВ: DFLSS (DESIGN FOR LEAN SIX SIGMA).

Относительно молодая методология. Ее задача – не улучшать, а изначально создавать оптимальный процесс. Во многом она базируется на инструментах ЛИН 6 Сигма, но при этом имеет много самобытных решений.

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

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

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





И последнее

Закончилась самая нудная глава книги. Существует еще множество методологий, которых мы касались вскользь в тексте (дизайн-мышление, ТРИЗ и т. д.), и тех, которых не затрагивали вовсе.

Для успешного их применения нужно помнить два простых правила:

1. ДЛЯ КАЖДОЙ ПРОБЛЕМЫ – СВОЙ ИНСТРУМЕНТ. НИ ОДИН ЧЕЛОВЕК В ЗДРАВОМ УМЕ НЕ ПИЛИТ МОЛОТКОМ И НЕ ЗАБИВАЕТ ГВОЗДИ РУБАНКОМ. БЕРИТЕ С НИХ ПРИМЕР.

2. ПРОЧИТАТЬ КНИЖКУ И ДАЖЕ ПРОЙТИ ТРЕНИНГ НЕДОСТАТОЧНО, ЧТОБЫ СТАТЬ СПЕЦИАЛИСТОМ В ЛЮБОМ ИЗ ДАННЫХ ПОДХОДОВ. ЧЕРНЫЕ ПОЯСА, НАПРИМЕР, НЕ ТОЛЬКО СДАЮТ ЭКЗАМЕНЫ И ТЕСТЫ ПРИ СЕРТИФИКАЦИИ, НО И ДЕЛАЮТ НЕСКОЛЬКО ПРОЕКТОВ (РЕАЛЬНЫХ, А НЕ УЧЕБНЫХ РАЗБОРОВ КЕЙСОВ) И ЗАТЕМ ЗАЩИЩАЮТ ИХ. И ДАЛЕКО НЕ ВСЕ ПОЛУЧАЮТ ЗАВЕТНЫЙ СЕРТИФИКАТ.

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

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

Назад: Глава 7. Это скучная-скучная методология
Дальше: Глава 8. Человеческий фактор