Текст книги "Как навести порядок в своем бизнесе. Как построить надежную систему из ненадежных элементов. Практикум"

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

По традиции процессы располагают по вышеописанным категориям.

Процессы управления

Перечень или укрупненные схемы процессов управления

Основные процессы

Перечень или укрупненные схемы основных процессов

Вспомогательные процессы

Перечень или укрупненные схемы вспомогательных процессов

Процессы совершенствования

Перечень или укрупненные схемы процессов совершенствования

Практическое задание 28

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


[Закрыть].

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

Рекомендую сейчас только перечислить процессы своей компании. А их укрупненные схемы создать чуть позже: после прочтения п. 3.3.2 «Тело процесса: задаем логику его выполнения».

Когда ландшафт будет утвержден, рекомендую повесить его на стенах у всех руководителей своей компании. Это будет в очередной раз напоминать им, что они работают не на благо своего отдела – «удельного княжества», а участвуют в сквозных процессах, в которых задействовано множество подразделений[110]110
  См. п. 4 «Авторитарный и процессный подход к управлению» книги «Бизнес-процессы: как их описать, отладить и внедрить. Практикум».


[Закрыть].

Вот мы и добрались до сути работы компании. Копаем дальше.

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

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

– понять, как же действительно работает процесс;

– улучшить его;

– протестировать на практике;

– и широко внедрить обновленную версию.

Описание процесса мы обычно делим на шапку и тело (рис. 6).

Рисунок 6. Шапка и тело процесса

В шапке задаем общие параметры процесса, а именно:

1. Название. Правильно выбранное название четко задает наше понимание процесса. Удобно, когда название состоит из «отглагольного существительного» (то есть образованного от глагола) и некоторых уточнений.

Например, «Обслуживание клиента в ресторане».

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

2. Цель процесса. Опять же, отслеживайте точность формулировок.

Например, «Обеспечить удовлетворение клиента и его желание многократно пользоваться нашими услугами в будущем, текущую и долгосрочную выгоду ресторана от обслуживания клиента»[111]111
  Работая над своими процессами и т. п. – думайте в команде, а не списывайте с примеров, механически заменяя слова.


[Закрыть].

3. Архитектор процесса (АП). Он отвечает за разработку технологии выполнения процесса и ее дальнейшее улучшение. Конечно, он делает это не один, а управляет рабочей группой, а которую входят все ключевые люди, причастные к данному процессу. Как правило, это представители подразделений, через которые проходит процесс[112]112
  Напоминаю, что большинство процессов – сквозные.


[Закрыть]. Их задача – прояснить, как сейчас выполняется процесс, и договориться о том, как делать его наилучшим образом.

4. Руководитель процесса (РП). Это тот, кто отвечает за выполнение всего процесса целиком: от первого шага до последнего:

– за соблюдение технологии;

– за результаты выполнения – достижение целевых показателей по процессу.

С точки зрения процессного подхода, у каждого экземпляра процесса должен быть определен РП. В противном случае за результаты его выполнения никто не отвечает. Даже если каждый из сотрудников, участвующих в процессе старается на всю катушку. Как у Аркадия Райкина: «Кто шил костюм?» – «Мы!»

Экземпляр процесса – это каждая «штука» процесса, выполняемого по данной схеме. Например, обслуживание каждого конкретного клиента в ресторане, создание кухонного гарнитура по каждому конкретному заказу клиента и т. д.

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

– архитектор процесса;

– руководитель процесса.

Архитектор – «законодательная власть» в процессе, руководитель – «исполнительная». Все просто и понятно. Рекомендую использовать именно эти выражения – жизнь команды сильно упрощается.

И АП, и РП – это роли. По аналогии с ролями, которые мы с вами разбирали в пункте 1.1.2 «Бизнес-архитектор, оперативный управляющий и исполнитель».

Здесь, в шапке процесса, записывают ту должность, представители которой могут быть назначены на роль АП или РП. Не ФИО[113]113
  Фамилия, имя, отчество.


[Закрыть] конкретного сотрудника.

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

Часто хочется поставить сюда больших боссов, в среднем и малом бизнесе часто – директора[114]114
  См. про «вертикальные колодцы» в п. 3.3.4.1 «Типичные ошибки в процессах».


[Закрыть]. Разумно ли это? Наверное, у него есть другие задачи и до развития конкретного процесса у него просто не дойдут руки. А уж тем более до управления всеми его экземплярами.

Во многих основных процессах руководителем процесса часто является продавец или эккаунт-менеджер[115]115
  От англ. account-manager, т. е. менеджер (правильнее сказать, продавец) по работе с ключевыми клиентами.


[Закрыть], который отвечает перед клиентом за выполнение его заказа, ведет заказ от начала и до конца (до получения оплаты, обратной связи и т. п.). Хотя не считайте это догмой – бывает очень по-разному. Все зависит от логики построения вашего бизнеса.

В описанном выше примере основного процесса (рис. 5) роль РП может выполнять администратор зала.

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

Пример 43. Михаил Филиппов, учредитель и директор компании «ОфисМакс», Нижний Новгород: «В подтверждение приведу пример. В нашей компании хозяином бизнес-процесса “Обслуживание клиента” (кстати, разработанного и внедренного после знакомства со статьей Михаила Рыбакова “Как навести порядок в своем бизнесе”) является оператор – сотрудник, который принимает заказ клиента по телефону, факсу или e-mail и ведет его (заказ) до момента отгрузки клиенту. В процессе обработки заказа оператору приходится общаться:

• с отделом снабжения (для заказа недостающего или редкого товара),

• со складом (согласование замены одного товара другим, аналогичным),

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

• со службой доставки (чтобы заказ был доставлен клиенту в желаемое им время),

• с руководителем (чтобы подписать договор или согласовать отсрочку платежа сверх допустимого лимита).

Всё это время оператор является представителем интересов клиента в нашей компании. Клиенты это знают и ценят. Наверное, поэтому, обращаясь в нашу компанию с очередным заказом, спрашивают конкретно Машу или Юлю».

5. Показатели процесса. Они позволяют определять, насколько успешно выполняется процесс[116]116
  См. п. 3.3.4.2 «Количественные и качественные показатели процессов» и главу 11 «Определяем показатели процессов» в книге «Бизнес-процессы: как их описать, отладить и внедрить. Практикум».


[Закрыть], насколько они эффективны.

Например: скорость выполнения заказа, выручка, прибыль и т. д.

Мы рекомендуем определять показатели процесса только после того, как хорошо разобрались с логикой его выполнения, внедрили процесс, добились четкого его выполнения[117]117
  Обычно до показателей добираются как минимум через несколько месяцев после начала работы над процессами.


[Закрыть].

Пример 44. Алексей Тимонин, генеральный директор интернет-магазина путешествий OZON.travel: «Перед началом описания бизнес-процессов (или в начальной стадии) следует определиться с ключевыми понятиями. Они могут быть материализованы в виде глоссария прикладных терминов или в другом виде, но это точно должно быть. Причем стоит дать максимально четкие и непротиворечивые определения самым фундаментальным понятиям, которые, казалось бы, очевидны, – “заказ”, “клиент” и т. д. В полезности этого упражнения не перестаю убеждаться».

Михаил Рыбаков. Да, по нашему опыту глоссарий сильно помогает команде в работе. Рекомендую вам сейчас его завести, занести в него первые понятия – те, которые вызывают максимум споров[118]118
  См. п. 7.2 «Управление архитектурой бизнеса».


[Закрыть].

Практическое задание 29

Выберите один из основных процессов вашего бизнеса, которые вы выделили на прошлом этапе[119]119
  См. п. 3.1.1 «Основные процессы».


[Закрыть].

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

Определите ключевые параметры выбранного процесса (опишите его шапку).

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

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

Каждый процесс состоит из шагов. Их состав и порядок по-крупному определяют его логику.

Для выделения шагов есть несколько основных правил. Все они родились из нашей многолетней практики в различных компаниях.

1. Выделите в процессе 7–12 шагов. Это не догма: может быть, к примеру, 6 или 15. Но не сильно меньше – в этом случае процесс остается непонятным. И не сильно больше – слишком много шагов не умещаются в голове.

В одном архитектурном бюро главный инженер на радостях, что его наконец-то услышали, принес на второй день рабочей сессии схему основного процесса, в котором был большим докой. Процесс насчитывал 42 шага (пять страниц формата А4)!

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

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

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

Все нюансы лучше оставить для более детальных уровней описания.

3. Описывайте процесс как линейный. Да, именно так: без параллельного исполнения шагов, логических ветвлений (если выполняется условие A, то делаем Х, иначе Y) и циклов. Мне с образованием системного аналитика и опытом программирования было трудно это принять. Но практика убедила в важности простоты – по опыту, если в логике выполнения процесса есть развилки, исполнители начинают «косячить». Опишите наиболее типичную последовательность шагов[120]120
  Ведь это процесс, а не проект! В управлении проектами для отображения параллельного выполнения этапов используют сетевой график и диаграмму Гантта. Подробнее в п. 4.3.2 «Управление сроками в проекте», п. 4.7 «Проекты и процессы»; а также в главе 10 «Проекты и процессы» книги «Бизнес-процессы: как их описать, отладить и внедрить. Практикум».


[Закрыть]. А тонкости выполнения поясните при их детализации.

Многие наши клиенты сначала сомневаются в том, что реально использовать линейные описания процессов. А потом благодарят: наконец-то все стало понятно. Часто до работы с нами они пытались использовать различные навороченные методики, запутывались и бросали.

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

4. Включите все основные этапы процесса. Даже те, которые выполняются не каждый раз.

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

Или некоторым клиентам вы доставляете заказы, а некоторые забирают их сами с вашего склада. Включите шаг «Доставка продукции клиенту» в описание процесса.

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

Например – производство. Допустим, ваша компания изготавливает продукцию разных типов по заказам клиентов. При описании процесса на верхнем уровне производство все равно будет одним шагом. Все тонкости вы опишете при раскрытии этого шага в виде подпроцесса[121]121
  См. п. 3.3.2.3 «Подпроцессы (“Матрешки”)».


[Закрыть].

6. Смотрите на процесс с точки зрения его руководителя: например, называйте его шаги соответственно.

Так если в каком-то шаге мы получаем оплату от клиента, то так и пишем: «Получение оплаты от клиента», а не «Оплата» (мы же здесь не платим, а получаем деньги).

7. Называйте шаги отглагольными существительными. Например, «Подписание договора», а не «Договор».

8. Описывайте процесс «как есть + ЗБР». То есть за основу берем то, как он выполняется сегодня. Если по-разному (у разных исполнителей и пр.) – выберите вариант, наиболее распространенный в вашей компании. Хорошо бы – самый лучший из обнаруженных вами.

Часто в ходе обсуждения процесса в команде, хочется его улучшить. ЗБР – это «Зона ближайшего развития»[122]122
  Термин ввел детский психолог Л. С. Выготский. Он обозначал им ту область знаний и навыков, которая на сегодня доступна ребенку при поддержке значимого взрослого: родителя, педагога.


[Закрыть], улучшения, которые вы действительно собираетесь внести в выполнение процесса в течение ближайших 1–3 месяцев. Идеи на более дальнюю перспективу пока не стоит вносить в описание процесса. Просто сохраните их где-то в удобном месте – рассмо́трите в будущем.

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

Рисунок 7. Описание шагов бизнес-процесса

Рассмотрим подробнее.

С номером шага все понятно.

Название шага – то самое, которое ему дали на предыдущем этапе. Правда, по опыту, состав и названия шагов при более пристальном взгляде могут измениться.

Результаты шага – это то, ради чего он выполняется, что выдает на выходе. Они бывают:

• Материальные (например, товар на складе);

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

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

Кстати, часто у одного шага результатов несколько – вспомните и запишите их все. Если оказалось слишком много (больше пяти), объединяйте в смысловые группы (например, пакет документов от клиента). Раскроете на более детальном уровне.

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

Ответственный всегда должен быть один. Хорошо, если ответственый за шаг – из числа его исполнителей.

Исполнители шага. А вот их может быть много. Желательно вспомнить всех. Если получается слишком много – объединяйте, например, рабочие цеха покраски.

Комментарий – это поле для ваших заметок. Например, сюда можно записывать ЗБР по шагу. Но лучше не перегружать эту колонку, пусть лучше она останется пустой.

Практическое задание 30

1. Определите шаги выбранного ранее процесса, соблюдая принципы, которые я рассказал выше.

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

Флипчарт вам в помощь ☺.

Так мы в шутку называем крупные шаги («черные ящики») процессов, которые есть смысл раскрыть более детально (рис. 8). Для их описания мы обычно предлагаем клиентам использовать тот же «язык», что и для процессов более высокого уровня – мы с вами разобрали его чуть выше.

Рисунок 8. Подпроцессы («Матрешки»)

Название шага процесса переходит в название подпроцесса.

Ответственный за шаг становится РП в подпроцессе, исполнители «расходятся» по его шагам.

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

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

Иногда бывает полезно разобрать процесс в виде «матрешек» и на следующем – третьем уровне глубины.

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

Практическое задание 31

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

К девятому изданию. Наверное, когда я писал первую версию этой книги, я был перфекционистом[123]123
  От англ. perfect – совершенный. А перфекционист – тот, кто стремится к совершенству. Иначе говоря, идеалист.


[Закрыть]. И я питал иллюзии, что все такие ☺. Однако время и новый опыт расставили все по своим местам.

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

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

Только, пожалуйста, не ныряйте в SIPOC как в омут с головой – утонете. Примеров немало. Сначала опишите процессы на верхнем уровне, как мы с вами разобрали. Протестируйте их, внедрите, получи́те результаты. Поживите с этим какое-то время – чтобы прижились обновленные процессы и привычка по ним работать. А вот уж потом, если будет нужно…

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

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


[Закрыть].

* * *

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

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

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

Для описания бизнес-процессов в мире разработаны десятки методологий, каждая из которых позволяет отобразить те или иные аспекты деятельности компании. Это такие подходы, как ARIS, IDEF0 (SADT), IDEF3, DFD и многие другие (рис. 9). К сожалению, зачастую их применение в практической работе неоправданно и даже вредно[125]125
  Тут многие коллеги могут на меня обидеться. Почему – см. ниже.


[Закрыть].

Рисунок 9. Пример схемы в формате SADT[126]126
  Пример из книги D. Marca, C. McGowan, Structured Analysis and Design Technique, McGraw-Hill, 1987.


[Закрыть]. Как вам?..

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

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

В одном из проектов нас позвали в компанию, где до этого в течение нескольких месяцев штатный бизнес-аналитик занимался описанием процессов. Он часами сидел с руководителями подразделений, старательно выспрашивая их о нюансах работы. Результаты заносил в схемы стандарта IDEF0. Была создана громоздкая иерархия процессов. Как в кулуарах выразился один из топ-менеджеров: «И что толку? Время потрачено – а в реальной работе НИЧЕГО не изменилось».

Почему же тогда подобные методики применяются? Потому что это выгодно тем, кто их продвигает: проект получается долгий, а значит дорогой. Часто еще и бесполезный, но кого это волнует? Деньги-то потратили[127]127
  См. п. 10.1 «Антикоррупция».


[Закрыть]. Ну и мода сказывается.

Пример 46. Алексей Тимонин, генеральный директор интернет-магазина путешествий OZON.travel: «Методология описания БП крайне важна. Люди вообще не любят читать описания БП, а если описания состоят преимущественно из текста, то они его почти гарантированно не прочитают. В итоге у нас в компании была выработана собственная упрощенная методология описания БП – с упором на визуальные представления (диаграммы), а текст используется исключительно во вспомогательных целях. Распространенные методологии описания БП действительно нам было сложно использовать в полном масштабе. Я думаю, в том числе из-за того, что каждая из таких методологий создавалась в определенную историческую эпоху, для определенной индустрии и даже для определенных языков – и их адаптационные возможности ограничены».

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

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

У другого клиента – известной консалтинговой (!) компании – ушел год на то, чтобы собрать вместе учредителей, руководителей и ключевых сотрудников. А потом – один день, за который мы с ними разгребли годами копившийся бардак в основных процессах.

Методика называется SIPOC[128]128
  Очень краткое описание данной методики я встречал только в некоторых источниках по системе «Шесть Сигм», преимущественно на англоязычных сайтах. Данную трактовку методики я изначально узнал от своего коллеги – консультанта Александра Шмайлова, за что ему благодарен. В дальнейшем методика была доработана нами.


[Закрыть] по первым буквам английских слов.

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

Сверху разместим шапку нашего процесса: его название, цель, РП и т. д.[129]129
  См. п. 3.3.1 «Шапка процесса: определяем его ключевые параметры».


[Закрыть] Напоминаю, что пример называется «Обслуживание клиента в ресторане от встречи до проводов».

Под ним равномерно распределите по горизонтали слова:

• Поставщик (Supplier)

• Вход (Input)

• Шаг (Process)

• Выход (Output)

• Клиент (Client)

Получится примерно следующее (рис. 10):

Рисунок 10. Шапка схемы SIPOC

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

1. Сначала запишем его по центру под словом «Шаг» и обведем прямоугольником. Можно проставить номер шага (рис. 11):

Рисунок 11. Шаг процесса в схеме SIPOC

Рисуйте компактно: справа и слева вам понадобится много места.

Кто отвечает за встречу и размещение гостя? Скорее всего – официант.

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

Рисунок 12. Шаг процесса с указанием ответственного и исполнителей

Ответственный и исполнители – те же, о которым мы говорили при описании тела процесса в формате таблицы. Хотя, конечно, при более глубоком рассмотрении процесса вы можете уточнить как состав шагов, так и их параметры[130]130
  См. п. 3.3.2. «Тело процесса: задаем логику его выполнения».


[Закрыть].

2. Теперь нам надо определить выходы данного шага. Выходом может быть информация, а также нечто материальное[131]131
  Если идет материальный поток, то он обязательно должен сопровождаться информацией в форме какого-либо документа.


[Закрыть].

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

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

Что будет выходом нашего шага? Информация о размещении гостя. То есть сведения о том, какой столик он занял.

Часто у шага бывает несколько выходов.

Удобно соединить шаг и каждый его выход отдельной стрелкой. Получается следующее (рис. 13):

Рисунок 13. Шаг процесса и его выход(ы)

3. А сейчас давайте подумаем: а кому в ресторане нужна такая информация?

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

Администратору зала, который отвечает, в том числе, и за загрузку ресторана (рис. 14).

Рисунок 14. Шаг процесса, его выход(ы) и их потребители

В данном случае старший официант и администратор зала являются клиентами (потребителями) данного шага[132]132
  Пишем их под словом «Клиент».


[Закрыть]. То есть теми, кому нужен выход данного шага, кто предъявляет к нему требования. Задача исполнителя данного шага – удовлетворить своего клиента: внутреннего или внешнего. Дать то, что ему нужно, и в той форме, в которой это ему нужно. Исполнитель шага является поставщиком для своих клиентов.

• Внешний клиент – это клиент компании, потребитель ее товаров и услуг.

• Внутренний клиент – тот сотрудник вашей компании, который использует результаты данного шага.

Концепция внутренних клиентов и поставщиков – ключевая в современном управлении[133]133
  См. далее в этой главе.


[Закрыть].

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

Давайте представим себе на минуту, что удовлетворение внутренних клиентов – никому не нужная глупость.

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

А что будет, если администратор зала не будет знать о том, сколько столиков сейчас занято? О том, что приехал гость, который бронировал столик на определенное время? Даже если руководитель – гений, при такой кривой системе он вряд ли сможет нормально управлять работой ресторана. Особенно при большом масштабе бизнеса.

Напомню, что «любая операция должна оставлять след»[134]134
  Подробнее см. п. 3.3.2.2 «Продолжаем описывать тело процесса».


[Закрыть]. То есть информацию о ней нужно где-то зафиксировать. Говорю ли я о бюрократии? Отнюдь! Чем меньше времени будет у сотрудников занимать запись и передача информации, тем лучше. В данном случае в зале может быть установлен сенсорный дисплей, на котором официанты могут отмечать занятие и освобождение столиков. Если электронная система – слишком большая роскошь, администратор зала может вести у себя простую бумажную или электронную табличку. Или же эти записи можно делать на маркерной доске, которая находится в общем доступе.

4. Хорошо. Теперь посмотрим, а что нужно официанту, чтобы качественно встретить и разместить гостя? Например:

• пожелания гостя;

• информация о свободных / занятых и забронированных столиках.

Это – входы данного шага. Нарисуем их слева от шага[135]135
  Под словом «Вход».


[Закрыть] и соединим с ним стрелками (рис. 15):

Рисунок 15. Шаг процесса и его входы. А также выходы и внутренние клиенты

5. А от кого официант может получить всю эту информацию? Смотря какую.

• Пожелания гостя – от него самого.

• Информацию о свободных / занятых и забронированных столиках – от администратора зала (рис. 16).

Рисунок 16. Полное описание одного шага в SIPOC

Мы дошли до очень важного момента. Сейчас гость и администратор зала являются внутренними поставщиками для официанта. И должны удовлетворить его потребности. Пожалуй, все, кроме гостя (внешнего клиента): от него официант должен получить информацию сам, причем в приятной для того манере. А вот если администратор зала не сообщил своему сотруднику нужную информацию – как он может требовать от него качественной работы?[136]136
  См. п. 6.9 «Управление знаниями».


[Закрыть] Ведь это и есть бардак! Спонтанный бизнес…

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

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


[Закрыть] (рис. 17).

Рисунок 17. Цепочка «клиент – поставщик»

Если развить эту мысль дальше, между клиентами и поставщиками (как внутренними, так и внешними), можно заключать «соглашения об уровне обслуживания»[138]138
  Service level agreements (SLA).


[Закрыть]. В них стороны фиксируют договоренности по тем или иным параметрам взаимодействия (скорость, количество допустимых дефектов и т. д.). Результаты (не) выполнения этих соглашений могут иметь вполне материальные последствия для сторон.

Рисунок 18. Несколько шагов схемы процесса в нотации SIPOC

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