В бытность мою студентом - а надо сказать, что я специализировался на компьютерных науках и экономике и при этом страстно желал стать журналистом, - мне удавалось производить на редакторов различных изданий настолько благоприятное...
В бытность мою студентом — а надо сказать, что я специализировался на компьютерных науках и экономике и при этом страстно желал стать журналистом, — мне удавалось производить на редакторов различных изданий настолько благоприятное впечатление, что они, бывало, приглашали меня на ланч. Понятно, я старательно готовился к этим встречам и никогда не упускал возможности задать пригласившему меня редактору вопрос: «Скажите, в чем, на ваш взгляд, главная проблема работы с внештатными авторами?» (Идея состояла в том, чтобы уверить собеседника: уж я-то проблемы не создам.) Услышав этот вопрос, редакторы откидывались на стульях, вздыхали, качали головами и изрекали: «Главная проблема в том, что они не хотят писать кратко. В итоге нам всегда приходится сокращать их тексты».
Я мотаю на ус: ясно, длинных текстов не писать!
Наконец, подают кофе и десерт. Беседа прошла успешно. Время пришло, я задаю свой главный вопрос: «А сколько вы, собственно... э-э... платите авторам?» В этой ситуации все редакторы без исключения наклонялись ко мне и произносили: «Ну, получается где-то по доллару за слово».
Ах, по доллару за слово! И они еще удивляются! Да потому и пишут длинно, что чем больше слов, тем выше гонорар! Я был просто потрясен тем, что редакторы не видят очевидной связи. И если бы только редакторы. Точно с такой же ситуацией я столкнулся, беседуя с группой ИТ-менеджеров на обеде в Массачусетском технологическом институте.
Каким образом измеряется — и оплачивается — труд программистов в большинстве ИТ-организаций? Универсальным мерилом в свое время стало количество строк кода, написанных за единицу времени. И после этого мы удивляемся, почему программные системы необоснованно разбухают, отличаются неэффективностью и слабой документированностью? Кого же, собственно, мы хотим провести?
Ошибочные критерии в сочетании с ошибочными стимулами всегда оборачиваются ошибочными результатами. Это железный закон человеческой природы и экономики.
Хотите знать, в чем секрет успешного решения поставленной задачи? Определите для себя, что есть «успешное решение», и ответьте на вопросы: а не вытекают ли из этого определения ошибочные стимулы к работе? И не придем ли мы к показателям, которые можно признать рациональными и использовать для оплаты труда?
Таких показателей, которые не соотносятся с ожиданиями, с процессами, с вознаграждениями и результатами, в современной ИТ-индустрии хоть пруд пруди. Руководители информационных служб посвящают слишком много времени анализу целевых задач ИТ-подразделений и компаний в целом. А вот анализу показателей и стимулов, которые облегчают решение упомянутых задач и позволяют делать это экономично, уделяется совершенно недостаточное внимание. И на выходе мы всегда имеем ошибочные, неудовлетворительные результаты.
Наглядные примеры дают нам управленческие решения в сфере снижения издержек и аутсорсинга. Во многие показатели заложена некоторая пристрастность; они улавливают прежде всего сокращение затрат ИТ-подразделений — скажем, сокращение числа обращений в службу поддержки (Help Desk) — и не учитывают повышения эффективности бизнес-процессов. В соответствии с этими показателями, лучшими являются те ИТ-менеджеры, которые «снижают издержки» и «прилагают усилия к тому, чтобы их работа была не нужна». Что ж, в этом плане стимулы работают замечательно: расходные статьи ИТ-подразделений и в самом деле сокращаются, а ретивые ИТ-менеджеры получают щедрые пособия по увольнению.
Хорошо известно, что если какие-то средства изымаются у ИТ-подразделений, они очень часто в конечном итоге передаются другим корпоративным структурам: ведь ни серверы, ни базы данных сами по себе не функционируют. Да, экономия вылилась в увольнение ИТ-менеджеров, но на кого теперь ложится ответственность за управление информационными системами, которыми они занимались?
Иными словами, пусть удалось резко снизить бюджет ИТ-подразделения, но значит ли это, что снизились фактические расходы предприятия? «Поголовье» ИТ-специалистов, бесспорно, сократилось, но так ли уж сократились управленческие расходы на координацию, модернизацию, обслуживание и снабжение в сфере ИТ?
Простой и честный ответ, который могли бы дать на эти вопросы в большинстве предприятий, звучит так: «Понятия не имеем». Почему же, позвольте спросить? Да потому, что на этих предприятиях замеряют совсем другие показатели. Они замеряют расходы ИТ-подразделений и инвестиции в ИТ с той же точностью и изощренностью, с какой некогда измерялась производительность труда программистов. И почему они это делают? Ответ совершенно очевиден: им платят не за снижение расходов на уровне организации, а за снижение расходов в сфере ИТ. Между тем если кто-то считает, что снижение бюджетов ИТ-подразделений и сокращение средств, затрачиваемых предприятием на ИТ, — это одно и то же, такому человеку нечего и думать о карьере директора информационной службы.
Некоторым из наиболее «успешных» современных ИТ-руководителей будет очень неприятно, если достоянием гласности станет подлинная цена их достижений: им удалось резко снизить бюджеты своих отделов, а расходы на ИТ в остальных структурных подразделениях предприятий повысились. Конечно, в некоторых случаях новая схема расходов, может быть, лучше соответствует потребностям отдельных корпоративных подразделений. Но уж это никак не отражает особых талантов директора информационной службы в решении стратегических вопросов или в управленческих делах.
Участвуя в серии семинаров, организованных в прошлом году корпорацией Microsoft, я с изумлением слушал, как разработчики ИТ-инфраструктуры предприятий обсуждают проблемы несоответствия показателей, измеряющих улучшение технических характеристик, и показателей, измеряющих производительность. Надо сказать, что разработчики структуры предприятий находятся как бы между двух огней. В большинстве ИТ-организаций инвестиции и стимулы более четко увязаны с проблемой совершенствования технических показателей — которые, кстати, гораздо проще замеряются, — чем с совершенствованием бизнес-показателей (для достижения последней из указанных целей требуется, чтобы менеджеры, определяющие прибыльность и убыточность, четко определяли, чего они хотят от ИТ-подразделений). Цели бизнеса и цели архитекторов вступают в неустранимый конфликт.
И вот участники семинаров пустились в рассуждения о том, как следует измерять коэффициент отдачи от повышения технической мощности (return on technical capacity improvements, ROTCI) и как — коэффициент отдачи от повышения бизнес-производительности (return on business capability improvements, ROBCI). Должен ли ROBCI зависеть от ROTCI? Или, может быть, ROTCI следует использовать для того, чтобы заинтересовать линейных менеджеров в достижении более высоких значениях ROBCI? Как лучше увязать эти величины? В конце концов, участники дискуссии начали оперировать показателями не как техническими терминами, а как средством осмысления и формулирования представлений о том, что должны означать в контексте всего предприятия такие понятия, как «мощность» и максимально возможная производительность».
Директорам информационных служб было бы опасно брать на вооружение представление о том, что ROTCI всегда определяет ROBCI. Им следует сосредоточиться на другой проблеме: как линейные менеджеры определяют степень совершенствования бизнес-показателей и в соответствии с какими соображениями инвестируют в технические мощности. И когда они разработают такие новые показатели, им нужно будет придумать более совершенные стимулы для достижения бизнес-целей.
Система измерений — и соответственно вознаграждений — по принципу «доллар за слово / за строку кода» просто не работает. По правде говоря, такие не требующие напряжения и усилий со стороны администраторов показатели и стимулы не работали и раньше, просто раньше эта система сходила предприятиям с рук. Но теперь руководители уже не могут ее использовать. Да и не должны. Дальновидным ИТ-руководителям следует быть одним из тех, кто берет на вооружение новейшие средства мотивации в сфере ИТ. Для этого у них есть очень серьезные мотивы.
Майкл Шрейг — соруководитель реализуемого лабораторией MIT Media Lab проекта eMarkets Initiative. Связаться с ним можно по адресу schrage@media.mit.edu
Michael Schrage. The metrics trap. CIO Magazine, February 15, 2004.