Самое сложное в ССП — это правильно определиться с показателями и графиком их измерения и сравнения, считает ветеран использования системы сбалансированных показателей Джордж Тиллман. Вице-президент по ИТ компании Booz Allen Hamilton делится своим опытом стратегического управления корпоративной ИТ-функцией.
Когда в 1992 году Нортон и Каплан опубликовали в журнале Harvard Business Review свою "установочную" статью об ССП, сама идея измерять эффективность бизнеса не только по финансовым, но и нефинансовым показателям выглядела более чем оригинальной. Однако придуманная ими сбалансированная система показателей (Balanced Scorecard) сильно укрепила мнение, что эффективный подход к таким измерениям должен обязательно включать все точки зрения на бизнес. Многие организации вносили изменения в базовую схему Нортона и Каплана и нашли для нее множество вариантов практического применения. Хотя изначально ССП была предназначена для оценки текущего состояния здоровья всего бизнеса, систему сумели адаптировать и для работы с отдельными подразделениями. Когда ССП реально работает, она становится мощным инструментом, который помогает топ-менеджерам оценить прошлые и текущие результаты и составить план на будущее.
В том числе — для управления корпоративной ИТ-функцией. Во-первых, в этом случае имеются вполне адекватные данные, с помощью которых можно измерять производительность информационных систем. Во-вторых, показатели для ИТ можно разработать таким образом, чтобы они измеряли выгоду конечного потребителя ИТ-сервисов и степень его удовлетворенности. В-третьих, показатели могут служить эффективным средством для наведения мостов между ИТ-профессионалами и внутренними бизнес-заказчиками, которых они обслуживают. Поэтому, когда в начале 2000-х я занял пост CIO в компании Booz Allen Hamilton, первым делом я решил внедрять систему сбалансированных показателей для своего департамента.
Ведь большинство высших руководителей компаний отнюдь не стремятся вникать в задачи, стоящие перед ИТ-службой. Причиной ли тому начальническая технофобия, загадочность информационных систем или слабый внутренний маркетинг со стороны ИТ-менеджеров, но наши нужды и проблемы для них выглядят не очень-то привлекательными. Между тем отчеты о работе ИТ-отделов и производительности ИТ-систем, которые готовятся в том же формате, что и отчеты по другим бизнес-функциям, могут приоткрыть деловым людям дверь в сферу информационных технологий, особенно когда они дают топ-менеджерам и руководителям бизнес-подразделений понимание того, какие выгоды они могут получить от ИТ.
Почему ССП может не сработать
Как и в случае с другими бизнес-инструментами, ССП, к сожалению, не волшебная палочка, способная решить все проблемы. Польза от этой методики во многом зависит от того, как ее применяют.
До прихода в Booz Allen я консультировал топ-менеджеров этой компании и, в общем-то, имел представление о том, с чем мне придется столкнуться. Кроме того, мне довелось наблюдать не одну попытку крупных корпоративных ИТ-отделов внедрить систему ССП или ей подобную. И я был свидетелем достаточного числа примеров неудачных внедрений, чтобы понять, где кроются причины неудач. Взять, к примеру, задачу составления системы показателей (пожалуй, это самая трудная задача) и графика их измерений: здесь легко наделать ошибок, и множество проектов по внедрению ССП провалилось именно по этой причине.
Так, CEO одной американской компании, занимающейся медицинским страхованием, с которым мне довелось работать, хотел создать такую систему показателей, которая давала бы более оперативную информацию, чем он получал из традиционной учетной системы. Действующие в компании ИТ-системы поставляли отчеты о работе каждого из четырех ее подразделений раз в неделю. Это были весьма детализированные отчеты, но сводных данных, которые бы на самом высоком уровне показывали динамику всего бизнеса, у него не было. Этот руководитель полагал, что если бы он мог отслеживать эту информацию ежедневно, у него было бы больше возможностей превращать недостатки в достоинства. И он пришел к выводу, что ему необходимо получать сведения по всем отделам не более чем суточной давности и в таком виде, чтобы было удобно их сравнивать.
Но даже в этом случае, когда заказчиком системы выступал генеральный директор, проект по ее внедрению провалился. Поначалу менеджеры грешили на технические проблемы, из-за которых так и не удалось интегрировать данные из разных бизнес-подразделений и создать сводный отчет по требованию начальника. Я входил в команду, которую привлекли для оценки ситуации и поисков решения. Как оказалось, проблема была вовсе не в ИТ-системах, а в определении необходимых для отчетности данных. Мы обнаружили, что каждый отдел определял показатели по-своему. Ни один из них не предоставил в одинаковом формате даже данные о доходах, что делало их сравнение бессмысленным.
В другой компании, которую мы консультировали (издательский дом), был неверно определен временной интервал для измерения и сравнения показателей. Когда эта компания решила внедрить ССП, руководство попросило начальников отделов предоставлять необходимые данные к пятому числу каждого месяца. Чтобы выполнить задачу в срок, руководители подразделений, которые хотели просмотреть материал до его подачи в команду по ССП, просили своих подчиненных присылать им данные за предыдущие 30 дней к 25-му числу каждого месяца. Ну, а эти подчиненные были вынуждены запрашивать сведения к 20-му числу, и так далее. Впрочем, такой подход все же имел какой-то смысл, поскольку большая часть дедлайнов попадала в те периоды, когда данные посылались или получались от внешних партнеров и контрагентов. Но, хотя ССП аккуратно фиксировала все бизнес-события, пользоваться ею было крайне сложно. Поскольку время подачи данных варьировалось в зависимости от уровня их предоставления, общей точки отсчета не было. Младший персонал видел какое-то событие в одном отчете, и оно же могло попасть в отчет старшим менеджерам спустя месяц. И выяснение, когда же именно это событие произошло, создавало напряженность в коммуникациях и затрудняло сравнение показателей. Система проработала пару лет и быстро пришла в упадок, когда появились новые системы с отлаженным циклом предоставления отчетных данных.
Еще одна проблема, с которой часто сталкиваются при внедрении ССП,— противоречивость данных. Администраторы баз данных знают: ничто не может так подорвать доверие к базе, как непоследовательность и противоречивость информации. Пусть лучше в базе будет один неверный факт, нежели правильные дублирующиеся сведения. Любой администратор вам скажет: если в базе содержится несколько одинаковых записей, нужно удалить все, кроме одной. (Один неправильный номер сотрудника — это проблема для отдела кадров. Два разных номера одного и того же сотрудника — уже проблема для ИТ-систем). То же самое с ССП.
Что будет, если данные в вашей системе показателей не совпадают с данными в других, более авторитетных учетных системах? Ждите неприятностей: спонсоры более авторитетных систем (независимо от того, чьи данные правильные) будут выступать против нового ССП-приложения. Даже если обе подборки данных будут правильными, но два источника информации противоречат друг другу, то точность, по крайней мере, одной из систем будет подвергнута сомнению. В итоге доверие ко всем управленческим системам, не только ССП, может пошатнуться.
Другая частая причина того, что ССП не приносит должного результата, кажется очевидной: некоторые люди просто не хотят, чтобы на их дела обращали слишком много внимания. Представьте производителя промышленных товаров, который пережил весьма сложный период внедрения корпоративной информационной системы (КИС), более широкой по функциональности, но схожей с ССП. Всю вину за пережитые трудности взвалили на программное обеспечение и анализ, проведенный корпоративной ИТ-службой. Но более тщательное расследование выявило действительного виновника проблем: глава одного из бизнес-подразделений всеми силами старался не допустить, чтобы сведения о работе его отдела поступали по системе на самый верх — гендиректору. Он сам относил свой отчет CEO, оставляя при этом полтора часа на то, чтобы вместе с ним пройтись по цифрам. Благодаря этой хитрости он мог выделить или же подать нужным образом любые данные. КИС, которая позволяла бы главе компании самостоятельно знакомиться с данными, ему была просто не нужна. Более того, он как-то сказал мне, что информационная система будет работать здесь только "через его труп".
Еще пример. Директор по маркетингу компании, выпускающей стройматериалы, желая "зарубить" проект внедрения ССП-приложения, на каждом шагу вставлял ему палки в колеса и с нетерпением ждал, когда же система наконец загнется. Я наблюдал за этими его попытками, а затем — за разочарованием от невозможности добиться своей цели.
Опытные менеджеры проектов знают, что между первичным энтузиазмом по отношению к новому проекту и первыми проблемами есть два критических периода. Первый — это "медовый месяц". Он длится обычно от 12 до 26 недель. В этот период рвение "отцов" проекта заставляет дело двигаться вперед. Горячие сторонники проекта преувеличивают его потенциальную значимость, критики же предпочитают пока держаться в тени. Но "медовый месяц" заканчивается, и над головами адептов сгущаются тучи. Былые энтузиасты нервничают, а противники проекта выходят "из подполья" и начинают открыто, в свое удовольствие критиковать проект. Если "черные дни" длятся слишком долго, скажем, дольше двух или трех месяцев, то проект, который, казалось, получил прочную поддержку, может быть заброшен или даже свернут. Проекты по внедрению ССП особенно уязвимы, когда случается нечто, отвлекающее внимание руководства компании: экономический спад, убытки или неожиданные изменения в подходах к управлению.
"Показательные" нюансы
Итак, став CIO Booz Allen, я рассчитывал избежать ошибок моих бывших клиентов при внедрении ССП в ИТ-департаменте компании. Для начала мы взялись за вопросы, связанные с интеграцией данных, включая обеспечение их непротиворечивости и устранение расхождений в определениях. И как назло многое было сделано на низшем и среднем менеджерских уровнях, но практически ничего на высшем. Так что мы получили почти пустую карту показателей.
Там, где значений не было, мы вводили их после изучения и определения соответствующих ключевых показателей результативности (КПР). Существуют два подхода к определению показателей деятельности ИТ-отдела: КПР обеспечивают нас информацией, которую мы хотим знать, а показатели исполнения (ПИ) — это актуальная информация, которую мы можем получить или вскоре получим. КПР — это знания об эффективности использования активов, работы процессов или групп, такие как рост продаж, степень удовлетворенности клиентов или надежность работы электронной почты, которые мы хотим иметь. ПИ — измерения, по которым мы можем узнать общее количество контрактов, число тех, кому понравилось обслуживание, или долю времени, которую пользователь потратил на работу с электронной почтой.
Всеобщее согласие в компании достигается тогда, когда КПР и ПИ практически одинаковы. Основные сложности возникают, когда их значения сильно расходятся. Чтобы избежать этого, мы потратили на определение данных времени больше, чем на любой другой аспект ССП. И этот процесс никогда не заканчивается: по мере включения в ССП новых систем, процессов или групп все определения должны пересматриваться и подтверждаться.
Другой критический момент — определение целевой аудитории ССП, которая в нашем случае включает менеджмент на корпоративном уровне и на уровне бизнес-подразделений, старших и младших ИТ-менеджеров, а также помощников в ИТ-отделе. Мы хотели создать такую систему показателей, которая подходила бы всем. Но для этого необходимо совместить два совершенно разных подхода: айтишники полагают, что они продают технологии, а их клиенты — что покупают услуги. И такое разночтение служит главной причиной всего плохого в работе ИТ-отдела, особенно в сфере взаимоотношений с бизнес-подразделениями.
Все больше руководителей ИТ-служб начинают понимать, как важно помнить об этом, когда представляешь бизнесу оценку своей работы. Дело ведь не в том, что один подход важнее другого, они оба необходимы. Различие только в форме представления. В Booz Allen наша система показателей в ИТ-отделе многоуровневая: верхние уровни содержат минимальный объем технической информации и сфокусированы на предоставлении услуг, которые пользователь хотел бы получить и за которые готов заплатить. Примеры — совместная работа, коммуникации, обработка заказов, финансовый отчет. Бизнес-пользователи находят верхний уровень ССП-карты наиболее полезным для себя.
Технический персонал использует нижние уровни карты, чтобы отследить статус и работу каждого технологического компонента: электронная почта, глобальные и локальные сети, серверы, системы хранения данных и т. д. Инфраструктура — это то, чем традиционно занимаются айтишники и что контролируют их внутренние системы. Если смешать эти два подхода, возникнет путаница и недоверие. Попробуйте заявить пользователю, который не смог воспользоваться электронной почтой во вторник, что с системой на прошлой неделе все было в порядке, и вы поймете, что я имею в виду. Он уверен, что почта во вторник была сломана, ИТ-менеджер уверен, что все работало. А почему? Да потому, что были проблемы с сетью, которую поддерживает другая ИТ-группа. Но семена сомнения посеяны и дали всходы.
Обычный элемент в системе ССП для ИТ-служб — сведение обобщенных показателей верхнего уровня к конкретным деталям. Что необычно для нашей системы ССП, так это природа используемых уровней. Показатели на каждом уровне тщательно выбираются для вполне определенной аудитории. В самом деле, создание карты показателей для широкого круга пользователей с обширными информационными запросами означает, что мы должны проанализировать каждый сегмент потребителей информации, чтобы понять, какие КПР они хотели бы в ней видеть. Но когда КПР были определены, уже довольно просто было подобрать метрики для измерений. Имея четкое представление о нашей аудитории, мы смогли выбрать необходимые показатели и разработать правильные определения для нашей карты.
Кроме того, мы знали, что для успеха нашего проекта многоуровневой ССП нам необходимо:
> поддерживать программу популяризации проекта на полном ходу и "давить" на его участников;
> следить, чтобы все ведущие ИТ-менеджеры публично демонстрировали энтузиазм в отношении проекта (даже если в частных беседах они отзывались о нем скептически);
> хотя бы раз в месяц вводить новые, пусть и не слишком значительные, функции в системе. Тактика постоянных улучшений гарантирует, что ошибки будут не слишком серьезными и устранить их будет легче, так что риск провала всего проекта резко снижается. Подобная тактика поможет также сократить число "черных дней" проекта, когда первоначальная поддержка и энтузиазм ослабеют;
> заботиться об уровне поддержки проекта со стороны пользователей с помощью встреч и презентаций, неформальных шоу и личных контактов. Мы стараемся лишний раз подчеркивать значимость проекта и управлять ожиданиями от него. Лучше всегда недообещать и потом перевыполнить.
И пока мы вполне довольны результатами. Наша система выдает на одной страничке самую важную информацию об основных наших услугах, плюс к этому финансовый отчет, данные о степени удовлетворенности клиентов и сведения о людских ресурсах. Все — по принципу светофора: зеленый — хорошо, желтый — нужно обратить внимание, красный — есть проблема. Всем цветам соответствуют детализированные сведения (численные, где это возможно).
Отчеты второго уровня карты охватывают те же 14 сфер, что и на первом уровне, но более детально — примерно по 140 показателям. Здесь также используется светофорный индикатор. Первый и второй уровни вместе составляют общий отчет о деятельности ИТ-службы, который ежемесячно посылается руководству компании.
Начиная с третьего уровня карты и до самого низа акцент переносится на технологические компоненты. Данные здесь численные, и они связаны с такими же числовыми целями. На низших уровнях система организована исключительно для ИТ-специалистов и может включать тысячи специфических показателей. Вся эта информация доступна для всех сотрудников ИТ-отдела. Подкрепляет все уровни карты и все показатели пакет определений, содержащий сведения о том, что именно измеряется и каковы целевые показатели по уровню предоставляемых услуг.
Постоянные улучшения
Дальнейшие шаги для нас вполне ясны. Мы плавно внедряем нашу месячную карту с множеством ежедневных и практически в режиме реального времени отчетов, следя за тем, чтобы не допустить противоречивости и дублирования данных. Мы планируем добиться того, чтобы с помощью ССП можно было не только отслеживать текущее положение дел, но и предсказывать ситуации в будущем.
Мы все еще совершенствуем нашу внутреннюю структуру (процессы, бюджеты, саму организацию), чтобы отражать запросы потребителей ИТ-услуг лучше, нежели состояние технологических компонентов. Это означает внедрение в отделе матричной структуры, в которой наша структура управления в части предоставления ИТ-услуг была бы ортогональной традиционным уловкам айтишников. ИТ-персоналу придется научиться отчитываться перед двумя менеджерами: традиционным менеджером по технологиям и новым менеджером по предоставлению ИТ-услуг. Но самое важное — культура будет меняться таким образом, чтобы уйти от привычного и комфортного для айтишников "технарского" подхода, чтобы каждый принимал близко к сердцу все, что связано с предоставлением ИТ-услуг. Это ускорит процесс принятия решений и отразится на наших успехах или неудачах. Заложенная в нашу карту показателей ориентация на услуги — ранняя фаза этих культурных перемен.
Мы понимаем, что если ССП нечто большее, чем просто система отчетности, другими словами, если она призвана отражать, какую роль мы играем в бизнесе компании и чем занимаемся, то ее совершенствование будет непрерывным процессом, а не очередным краткосрочным проектом. Наша цель — использовать систему как движущую силу улучшений в работе ИТ-службы и позитивных изменений для компании в целом.