Управление технологиями для поддержания бизнес-импульса

Без суеты поддерживать импульс моего бизнеса с помощью ИТ

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

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

Таблица 4.1 может послужить первым шагом к определению бизнес-импульса вашей организации. Заполните те параметры, которые применимы к вашей компании, добавьте другие, если надо, главное — получить общее представление о массе, скорости и направлении движения вашего бизнеса. Только тогда вы можете начинать разговор со своими ИТ-специалистами.

И не надо слишком усердствовать. Все, чего мы пытаемся добиться на данном этапе, — это получить представление о том, каковы размеры организации, поддержку которой обеспечивает ИТ-отдел, насколько она зависима от вычислительных средств технической базы, и все ли точно знают, чего от них ожидают. Исходя из своего опыта, хочу сказать, что редко в какой организации могут ответить на все эти вопросы. Что же касается ИТ, то хотя многие организации не знают ответов на эти вопросы, они рассчитывают, что их ИТ-служба предоставит им инфраструктуру и услуги на многие годы вперед. Когда-то я работал в компании, которая вообще не имела стратегии. Все, что у них было, — это годовой бюджет. И они хотели, чтобы я как ИТ-директор составил план на ближайшие пять лет, исходя из какого-то абстрактного понятия о том, чего они хотели бы достичь в будущем. Мы смогли составить план. Для этого мы опросили пятьдесят топ-менеджеров о том, что для них важно сейчас и что будет важно в будущем, и на основании их ответов мы сформулировали «эмерджентную стратегию»1 и представили ее руководству. После еще одного раунда переговоров и определения приоритетов, мы смогли кое-как составить план и для ИТ, и для компании. Самое главное понять, что эта таблица не конечная цель, а первый шаг в обсуждении проблемы. Теперь вернемся к программе действий. Три функции, выполнения которых бизнес требует от ИТ-службы: управлять технологиями, не дергая его по мелочам и не докучая ему своими проблемами, непосредственно участвовать в бизнес-деятельности и осуществлять технологическое лидерство.

Таким образом, первый вопрос, на который мы попытаемся ответить, — как управлять ИТ без суеты.

Почему «управлять ИТ», а не «заниматься ИТ»?

Подчеркнем, что главное слово здесь — «управлять». Вот в чем дело: сегодня предоставление информационных технологий стало обычным делом. Дэвид Берчелл и Лоранс Лайонс (1995)говорят о том, что отношения между бизнесом и ИТ достигли своего рода переломного момента. Они утверждают, что до середины 80-х ИТ не могли в полной мере удовлетворить нужды бизнеса. ИТ-специалисты были в выгодном положении — на них всегда был спрос. Если помните, в конце 70-х ПК был всего лишь модной новинкой и не предназначался для использования в работе. Но к середине 80-х он превратился в стандартный инструмент бизнеса, появилось достаточное количество программного обеспечения для удовлетворения нужд и бизнеса, и индивидуальных пользователей, а аппаратные средства стали стремительно дешеветь. С тех пор у любого бизнесмена дома в кабинете компьютерных технологий было больше, чем ему мог предложить ИТ-отдел его компании, а значит, наступили последние дни традиционных ИТ-методов, организаций и специалистов.

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

Мне вспоминается одна правительственная организация, в которой пытались осуществить эту идею, но с треском ее провалили. ПБИ-менеджеры превратились из доверенных лиц в жандармов и добились лишь замедления процессов ИТ-поставки почти до полной остановки. Ключевая разница в том, что ПБИ-менеджер берет на себя определенные обязательства по отношению к организации, в которой работает, а затем обеспечивает выполнение своих обязательств. И в конечном счете, ИТ-услуги, поставляемые тем, кого выбрал ПБИ-менеджер, — это показатель его успеха или провала. ИТ-услуги — это его жизнь или смерть.

Итак, управление бизнес-импульсом через предоставление ИТ-услуг — вот что движет ПБИ-менеджерами. Их главные приоритеты:

• доступность и стабильность;
• операции и эффективность;
• управление ИТ-услугами;
• управление активами;
• результативность, оценка и отчетность;
• поддержка бизнес-импульса.

Доступность и стабильность ИТ

ПБИ-менеджеры поддерживают импульс своего бизнеса, обеспечивая доступность ИТ-инфраструктур и систем, когда и где это необходимо. Доступность включает в себя стабильность услуги — ее надежность.

А это само по себе уже является полноценной функцией, основанной на стандартных процессах, выполняемых ИТ-специалистами (рис. 4.1).

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

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

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

В плане дополнительного роста ПБИ-менеджер еще до начала использования технологии должен установить необходимые критерии, оценить объемы роста в течение каждого конкретного бюджетного периода и составить в соответствии с этим бюджет, используя первоначальное бизнес-обоснование и перерасчет выгод — на этом я подробнее остановлюсь в главе 7. И наконец, в пошаговом плане развития должен быть разработан процесс авторизации роста, и что очень важно, план должен работать в пределах параметров, утвержденных при составлении бюджета. Это подразумевает освобождение ИТ-отдела от постоянного потока согласований и передачу данного процесса бизнесу. Это отступление от обычного хода вещей: обычно бизнес запрашивает новые технологии или услуги, а ИТ-отдел либо утверждает их, либо отвергает. Однако в модели «3Ф» ИТ вместе с бизнесом вырабатывает критерии одобрения, и если приложение соответствует условиям пошагового плана развития, ИТ просто приобретает и устанавливает необходимую технологию.

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

У требований к доступности и стабильности есть также и временное измерение. Когда технология или система должна быть доступна? Решение остается за бизнесом и часто зависит от времени работы организации, но при этом имеет последствия и для ИТ. Технологические требования к системе, которая должна быть доступна с 6.00 до 20.00, в корне отличаются от требований к системе, доступной 24 часа в сутки 7 дней в неделю. Да и затраты тоже разные: предоставлять ИТ для работы с 6.00 до 20.00 гораздо дешевле. Бизнес должен осознавать последствия своих требований. Когда я был ИТ-директором, мои заказчики порой чрезмерно увлекались выдвижением различных требований. Тогда я спокойно записывал все требования и составлял калькуляцию их стоимости по скользящей шкале— от минимально необходимых до самых грандиозных и немыслимых технологических требований, определенных заказчиком. Всегда использовалась логарифмическая шкала, и всегда мы останавливались на наиболее реалистичном технологическом продукте. Если ИТ-отдел не предоставляет бизнесу в ответ на его требования несколько вариантов выбора, то это уже само по себе повод для беспокойства.

Для стабильности есть и другие временные показатели: необходимо знать «среднюю наработку на отказ» (MTBF), а также «среднее время устранения неисправностей» (MTTR)рабочей станции / системы. Первый показатель определяет, как долго рабочие станции / системы остаются стабильными без отказов, а второй — сколько требуется времени на то, чтобы устранить неисправности, когда что-то идет не так.

И наконец, вам, вероятно, понадобится установить уровни серьезности возникающих ошибок. Я обычно устанавливаю три уровня серьезности ошибок: уровень серьезности № 1 означает полную остановку базовых бизнес-операций в результате отказа ИТ, уровень № 2 — бизнес-операции нарушены (замедлены, не полностью доступны и т. д.) из-за отказа ИТ, уровень № 3 — бизнес-операции затруднены из-за отказа ИТ.

И еще одно замечение по восьмому этапу данного процесса. Очень незначительное, если не сказать больше, число ИТ-отделов считает утилизацию систем и инфраструктур событием, которое должно быть запланировано и предусмотрено графиком. Обычно они модернизируют старую систему или устанавливают новую и эксплуатируют ее параллельно со старой, пока все пользователи не перейдут на новую. После этого они могут удалить старую систему и ее файлы данных из инфраструктур. Зачастую они этого не делают, поскольку либо остается один особо упрямый пользователь, предпочитающий старую систему, либо они хотят иметь запасной вариант на случай неисправностей. Утилизация старых систем — неотъемлемая часть управления активами в работе ПБИ-менеджера.

Операции и эффективность

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

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

Управление выгодами предоставленных ИТ-услуг

Я абсолютно уверен, что ИТ-специалисты никогда и ни за что не должны заговаривать о расходах на ИТ, пока не будут иметь четкого представления о том, какие выгоды эти технологии могут дать их организации. Целая глава этой книги посвящена определению и оценке ИТ-выгод, которые включают и выгоды ИТ-инфраструктур и услуг. Однако ИТ-специалисты часто говорят бизнесу, что определить выгоды от использования большей части ИТ-инфраструктур и услуг невозможно, поскольку каждая отдельная технология имеет общий характер и обслуживает несколько систем в нескольких бизнесах. Есть, конечно, способ определить эти выгоды, — продолжают они, — но он потребует таких невероятных усилий, что стоит еще подумать, так ли это необходимо. Я же считаю, что для того, чтобы приблизительно определить выгоды, значительных усилий не потребуется, а сделать это надо обязательно. Я уверен, что за неделю работы можно рассчитать принцип 80:20 в отношении выгод от внедрения ИТ-инфраструктур, рабочих станций и т. д. В конечном счете, суть дела такова: ИТ обязаны определить, какие выгоды их услуги принесут организации. Они также обязаны отчитываться о полученных выгодах и оценивать их зависимость от любых изменений в ИТ-системах и инфраструктурах.

Управление активами

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

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

Но обычно ИТ-отделы грешат тем, что я называю «отчет на почтовой марке», когда вот такой график…

…превращается вот в такой…

…потому что они намеренно показывают спонсорам не всю картину, а только малую ее часть размером с почтовую марку.

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

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

Управление ИТ-финансами — это еще одна составляющая портфолио ПБИ-менеджера: он должен обеспечить, чтобы поставка услуг и технологий соответствовала счетам на нее. Подготовка ПБИ-бюджета или технологического бюджета — это особый вид деятельности, с которым мы подробно познакомимся в главе 9, где я представлю модель бюджета, составленную с учетом трех функций ИТ.

Производительность, оценка и отчетность

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

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

Поскольку ИТ-системы и инфраструктуры связаны друг с другом в виде цепочки, предоставляющей ИТ-услуги конечному пользователю, существуют сложные алгоритмы, специально разработанные для вычисления, например, доступности системы, но не доступности сети. ИТ-системы работают и последовательно, и параллельно. Чтобы понять, что значит последовательное устройство, представьте себе трубу в саду, соединяющую несколько поливочных установок, — поломка в любой точке трубы приведет к остановке всех установок «ниже по течению». Параллельные устройства (представьте несколько труб, ведущих к одной поливочной установке) тоже могут давать сбой, но это мало повлияет на работу самой установки. Теперь, конечно, ИТ-устройства имеют оба типа связи с ключевыми критическими элементами — так что даже если главная система приложений будет недоступна, но сеть останется стабильной, то пользователи, например, смогут работать с электронной почтой, хотя и не смогут оформлять поступающие заказы. Это усложняет процессы оценки и отчетности настолько, что большинство ИТ-специалистов начинают просто испытывать ужас при одной мысли об этом. Но само их выживание зависит именно от этих процессов, поскольку в последние годы бизнес все с большим скептицизмом относится и к самим ИТ, и к тем выгодам, о которых они заявляют. Я подробнее останавливаюсь на этой проблеме в главе 7, где цитирую Кита Гриндли (1991), изучившего мнения директоров о своих ИТ-службах. Один из директоров так описал свое впечатление о работе ИТ-отдела: как и у других директоров, у меня возникает ощущение, что меня шантажируют. и не только поставщики (это меня как раз не удивляет). нет, мои собственные ИТ-сотрудники, которые без конца твердят мне о том, сколько вкладывают в ИТ наши конкуренты.

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

Поддержание бизнес-импульса

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

Какой вклад ИТ вносит в достижение отдельных бизнес-целей?

Как существующая ИТ-инфраструктура и системы поддерживают стратегические намерения организации?

Как со временем изменяется бизнес-импульс? (Для ИТ нет ничего легче, чем информировать бизнес об объемах операций во всех основных бизнес-процессах.)

И наконец, каково мнение организации относительно ИТ-услуг, предоставляемых ПБИ-менеджером, посвятившим себя предоставлению этих услуг?

Управление предоставлением услуг — это главный элемент и главный показатель бизнес-деятельности ПБИ-менеджера. Многие ИТ-отделы предпочитают заключать со своими пользователями соглашения об уровне услуг (SLAs). Это квазидоговорное соглашение о том, какие услуги будут предоставлены со стороны ИТ, как они будут предоставлены и каков будет уровень их качества.

Я предпочитаю другой подход. И беспокоит меня, прежде всего, договорной характер соглашений об уровне услуг. Существует история о делегации американских бизнесменов, которые приехали в Китай на переговоры и достигли с китайской компанией соглашения о поставке определенных товаров. Все остались довольны, обменялись рукопожатиями, и американцы заявили: «Ну, значит, все решено. Теперь наши юристы напишут проект договора, и мы скоро снова с вами увидимся». Китайские бизнесмены были оскорблены — разве рукопожатие не означало, что они обо всем договорились?

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

Этот план затем должен стать основой для переговоров между ПБИ-менеджером и его бизнес-заказчиками.

А следовательно, он должен помочь ПБИ-менеджеру определить, какие параметры подлежат оценке и о чем необходимо отчитываться.

Деятельность ПБИ-менеджера

Хотелось бы еще раз повторить: человек или люди, ответственные за выполнение функции поддержания бизнес-импульса с помощью управления ИТ, берут на себя обязательства перед организацией предоставить определенную услугу, а потом управляют процессом предоставления этой услуги.

Обычно ПБИ-менеджер составляет план предоставления ИТ-услуг, в который включает следующие пункты (узнаете первый раздел?):

Параметры бизнес-импульса:

• количество сотрудников;
• количество ПК-пользователей;
• количество филиалов;
• сотрудники главного офиса;
• количество поставщиков;
• количество клиентов;
• количество продуктов и услуг;
• количество международных связей.

Параметры скорости бизнеса:

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

Параметры доступности ИТ-услуг и инфраструктуры:

• предоставление новых инфраструктур;
• параметры пошагового развития;
• планирование производственных мощностей.

Параметры стабильности ИТ:

• основные задачи по «средней наработке на отказ» и «среднему времени устранения неисправностей»;
• ключевые задачи ИТ-производительности: время отклика, оборотное время и т. д.);
• задачи / услуги по резервному копированию;
• задачи / услуги по безопасности;
• услуги по управлению поставкой ИТ.

Управление и поддержка инфраструктуры и приложений:

• задачи / услуги по планированию;
• задачи / услуги по организации / подбору ресурсов;
• операционные задачи / услуги;
• задачи / услуги по мониторингу;
• задачи / услуги по отчетности;
• задачи / услуги по составлению бюджета.

ИТ-архитектура — модели данных и технические модели:

• задачи / услуги по стандартизации;
• услуги по созданию ИТ-архитектуры;
• услуги по обработке данных;
• и т. д.

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

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

• Обратите также внимание на то, что во многих пунктах говорится о задачах / услугах. Это зависит от организации и ее отношений с ИТ-отделом. Возможно, вы захотите поставить перед ИТ-отделом определенные задачи, которые они должны выполнить, либо ИТ-отдел будет более комфортно себя чувствовать, предоставляя организации услуги. Тут все зависит от вашего выбора и культуры отношений. Однако ПБИ-менеджер должен принять на себя обязательства по выполнению этих задач или услуг. Я лично предпочитаю слово «задачи», потому что оно дает понять, что мы на одной стороне, а «услуги» снова имеют договорный привкус.
• В этот план включены задачи по мониторингу и отчетности. Не относитесь к этому как к чему-то второстепенному. От этих двух параметров зависят отношения между ИТ и организацией.
• И снова я хочу подчеркнуть, что воспринимаю этот список, скорее, как основу для программы переговоров между ПБИ-менеджером и организацией, а не как соглашение или контракт.
• И наконец, нет никакой причины, почему бы не поместить во внутреннюю сеть организации окончательный план действий и отчеты о результатах работы по перечисленным пунктам для обсуждения, внесения замечаний и предложений.

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

также — «реализуемая стратегия», от англ. «emergent» — «появляющийся, возникающий». Понятие, сформулированное Г. Минтцбергом в книге «Взлет и падение стратегического планирования», 1994, и обозначающее стратегию, которая естественным образом складывается из действий организации с течением времени при отсутствии обозначенных целей, либо несмотря на обозначенные цели. — Прим. научного редактора.

Версия для печати