Любая информационная служба на практике имеет правила. Независимо от того, рассылаются ли они по корпоративной сети intranet или существуют негласно, правила отражают закономерности, устанавливают порядок действия и нормы поведения, регламентируют полномочия.
Билл Васс, Sun Microsystems. Рон Бониг, Университет им. Джорджа Вашингтона.Билл Годфрей, Dow Jones.

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

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

Тринадцать золотых правил, которые Рон Бониг, исполнительный директор по техническим операциям Университета им. Джорджа Вашингтона, написал для своего подразделения, изложены простым языком с легким оттенком юмора. Сотрудникам при принятии решения дается достаточная свобода. «Я не могу находиться здесь постоянно, - говорит Бониг. - А полномочия подчиненных регламентируются набором правил».

С помощью правил Билл Годфрей, директор информационной службы компании Dow Jones, устанавливает контакт между ИТ и бизнесом. «Мне нужны определенные механизмы, некоторые конструкции, помогающие урегулировать ситуацию, - отметил Годфрей, выпустивший свой сборник Основных правил в 2004 году. - Все правила в той или иной форме нацелены на то, чтобы поддерживать и стимулировать этот процесс».

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

Директора, предлагающие своды правил, признают, что эта часть жизни предприятия порождает много вопросов. «Простое размещение правил на Web-сайте зачастую имеет весьма отдаленное отношение к их интеграции в корпоративную среду», - пояснил Годфрей.

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

Но самое главное - то, что руководители ИТ-служб обязаны показывать пример подчиненным. «Ведь сотрудники время от времени будут ловить вас на том, что вы сами не выполняете своих же правил, - отметил Васс. - Вам придется жить по тому закону, который вы сами и придумали».

Основы успеха, предложенные Биллом Вассом

Правило 1. Открытые системы пользуются успехом

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

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

Правило 2. Закрытые системы в долгосрочной перспективе терпят крах

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

Правило 3. Отделяйте логические уровни

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

Правило 4. Стандарты играют не последнюю роль

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

Правило 5. Новое - это хорошо забытое старое

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

Правило 6. Технология - не самое сложное

Во многих случаях проектирование, реализация и развертывание технологии не вызывают затруднений. Гораздо сложнее заставить сотрудников принять эту технологию и осознать те преимущества, которые сулит ее применение. Это самая трудная задача, которую предстоит решить руководителю ИТ-службы. Его работа связана с техническими вопросами всего лишь на 5% и на 95% с организацией взаимодействия, оказанием содействия персоналу и описанием открывающихся перспектив, проведением мероприятий, направленных на то, чтобы помочь пользователям преодолеть страх перед переменами.

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

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

Правило 7. Оценивайте сроки с учетом поправки

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

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

Правило 8. Управляйте оценочными параметрами

В качестве оценочных используйте только те параметры, которые вы считаете действительно важными, и доведите это до своих подчиненных, коллег и руководства. Нужно, чтобы они поняли и одобрили ваши приоритеты. Если вас не заботит стоимость, не нужно ее рассчитывать. Если сроки для вас не существенны, не оценивайте сроки. Нельзя управлять теми параметрами, которые не имеют количественного выражения. В компании Sun главное - качество и готовность. Мне известен уровень готовности и производительности всех моих систем, для оценки каждого из этих параметров я собираю все необходимые данные.

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

Правило 9. Не позволяйте лучшему стать врагом хорошего

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

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

Правило 10. Надейтесь на лучшее, но готовьтесь к худшему

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

Золотые правила Рона Бонига

Правило 1. Главная задача - обеспечить выполнение всех процессов.

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

Правило 3. Ничто в мире, включая и то, что относится к срокам сдачи, проектам, специальным мероприятиям, никогда не может считаться оправданием нарушения Правила 1 и Правила 2.

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

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

Правило 6. Важнейшей составной частью плана является стратегия восстановления. Вернуть информацию в устойчивое состояние можно, если у вас заранее составлен четкий план действий.

Правило 7. Несущественных и нелогичных изменений быть не должно.

Правило 8. Никогда не отвечайте пользователям отказом - просто объясните им, во что обойдется решение их вопроса.

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

Правило 10. Позаимствовано у Марка Твена: «Сложите все яйца в одну корзину и внимательно следите за ней!»

Правило 11. А теперь, перефразируя Клаузевица: «Ни один план не остается в неизменном виде уже после первого контакта с пользователями».

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

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

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

Основные правила управления ИТ-службой Билла Годфрея

Правило 1. Стратегическое планирование

  • У всех технических подразделений имеется документированный план развития технологий.
  • Все технические подразделения открыто объявляют свои цели и задачи.

Правило 2. Определение производственных приоритетов

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

Правило 3. Корпоративная архитектура

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

Правило 4. Управление проектами

  • При реализации всех нетривиальных проектов (оценочное время реализации которых превышает две недели) необходимо полностью соблюдать процедуры управления проектами Dow Jones (DJ).
  • Перед началом реализации любого проекта за ним закрепляется персональный куратор, представляющий основной бизнес, а также технический руководитель проекта.
  • За всеми проектами, требующими поддержки со стороны инфраструктуры, закрепляется специально подготовленный персонал, который принимает непосредственное участие в проектировании системных решений.

Правило 5. Управление временем

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

Правило 6. Управление технологиями

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

Правило 7. Управление утверждением финансирования

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

Правило 8. Запросы на предложения независимых организаций

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

Правило 9. Управление взаимоотношениями

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

Правило 10. Управление инфраструктурой

  • Службы инфраструктуры предприятия на 100% подотчетны руководству глобальной инфраструктурой DJ.
  • Корпоративная информационная служба - единственная организация, принимающая решения в отношении инфраструктуры.
  • Корпоративная информационная служба управляет и распоряжается всем инфраструктурным капиталом.

Правило 11. Обеспечение соответствия требованиям законодательства и нормативных актов, создание условий для проведения аудита

  • Информационные службы должны выполнять все требования, предъявляемые к проведению аудита, соблюдению нормативных актов и законодательства.
  • Руководство ИТ-службы несет ответственность за выполнение всех соответствующих предписаний.

Правило 12. Соблюдение операционных процедур

  • Полное соблюдение всех корректив, вносимых в политику управления предприятием и процедуры.
  • Соблюдение соглашений об уровне сервиса для всех корпоративных приложений.

Правило 13. Информационная безопасность

  • Технический персонал обязан соблюдать политику информационной безопасности Dow Jones.
  • Перечень мер, обеспечивающих информационную безопасность, должен быть утвержден до начала внедрения новой технологии или внесения каких-то значительных изменений в технологию существующую. Соответствующие меры необходимо рассмотреть и утвердить до принятия DJ любых формальных и неформальных обязательств перед поставщиками.
  • Управление разграничением полномочий и уровнем доступа к приложениям, содержащим важную финансовую информацию, осуществляется с учетом требований к информационной безопасности.

Правило 14. Соблюдение закона Сарбейнса - Оксли

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

Thomas wailgum. The Rules of IT. CIO MAGAZINE. OCTOBER 1, 2005