Жить по фэншуй

Сколько раз вы слышали про «лучшие мировые практики»? А сколько раз вы их видели? А в среднестатистической компании? А сколько раз внедряли? И сколько раз получилось?

Цели, средства и люди

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

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

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

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

К слову, многие консалтинговые компании живут как раз по схожему принципу: их консультанты выступают в качестве методологов, а внутренние сотрудники компании – в качестве экспертов. По моему оценочному мнению, подобные структуры, пожалуй, одни из самых эффективных с точки зрения достижения конечного результата. Почему? Да потому что консультант (внутренний или внешний) знает, как сделать правильно. Знает, как должно быть в идеале с точки зрения процесса. При этом эксперт знает, как должен выглядеть результат, что должно быть сделано для максимальной эффективности внедряемых решений. И да, они работают вместе, потому что делать правильно и эффективно – далеко не всегда одно и то же. Более того, сделать хорошо также отличается от «правильно и эффективно». Хотя бы тем, что для оценок этих понятий применяются различные метрики. Кроме того, оценка зачастую может зависеть от того, кто ее дает. Например, оценить эффективность проекта можно с позиции финансового аналитика и получить хороший результат (итоговая экономия по отдельным статьям, выраженная в процентах). А можно – с позиции исполнителя, и результат окажется не столь радужным: прибавилось работы и в 90% случаев скажут «ненужной работы». При этом «ненужность» будет оценкой эмоциональной, основанной на узком сегменте знаний.

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

Про опыт

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

Чтобы проиллюстрировать этот тезис, зададим себе простой вопрос: какие вообще бывают процессы? На самом верхнем уровне всего два класса: процессы, призванные обеспечить требования законодательства, и процессы, которые к требованиям законодательства условно не относятся. Условно, потому что так или иначе даже самые простые вспомогательные процессы упираются в законы (например, соблюдение нормативов при закупке канцелярских товаров и т. д.). Так вот, проще в текущих условиях потому, что в рамках законодательства любая компания вольна менять процессы, как ей нравится. Точнее, как ей удобнее. И нормативная база, которая регламентирует процесс, чаще всего тоже существует только в рамках компании. Соответственно, пройдя сквозь череду итераций и изменений, процесс приобретает некий адаптированный вариант, который обеспечивает приемлемый для руководства эффект. Казалось бы, при чем тут лучшие практики? А при том: лучшие практики, как правило, описывают те же (или схожие) процессы. И говорят о том, как должен быть выстроен процесс для достижения некоего идеального результата. При этом практически во всех лучших практиках говорится про адаптацию. То есть что любой описанный в них процесс должен быть адаптирован к конкретным условиям. Это же касается и методологий – там, как правило, декларируются процессы, декомпозируются до определенного уровня. Те же процессы eTOM или ITIL – они рассказывают, как должно быть, но оставляют простор для реализации.

Но и eTOM, и ITIL – удел больших компаний (в полном объеме процессов). Маленькие компании просто физически не вместят в себя весь объем процессов. Но жить, так или иначе, надо. И тут очень ярко встает вопрос о том, что «не ITIL’ом единым». Ведь была жизнь и до ITIL? Необязательно же внедрять все процессы? Если текущая ситуация требует определенной гибкости, то почему бы ее не проявить?

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

Про метрики

Все, что измеримо, можно измерить. Что неизмеримо – привести к измеримому и все равно измерить. Если вернуться к началу статьи, то там немного поднималась тема метрик. Как говорится, а давайте об этом поглубже.

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

Это, понятное дело, крайний случай, но, проектируя метрики, важно понимать, что всегда есть риск, что сотрудники начнут работать не на результат (цель процесса), а на метрики качества (есть KPI – отрабатываем его). И неважно, что цель процесса немного другая – «своя премия ближе».

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

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

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

Вывод

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

В больших компаниях ситуация менее человекозависима, там все зависит от поставленных целей. А цели могут быть самыми разными: от, например, полного соответствия ITIL и ISO 9000 для сертификации до выстраивания максимально дружественной к пользователю ИТ-среды. И уже в зависимости от целей применяются либо опыт, либо методологии, либо то и то, разбавленное здоровым цинизмом и приправленное здравым смыслом. Главное – понимать, куда надо прийти, и четко отслеживать направление движения.