ИТ-инфраструктура_КонспектЛекций. Учебнометодический комплекс Управление итинфраструктурой предприятия
 Скачать 6.41 Mb.
|
Правление   Комитет по изменениям CIO – член правления Комитет попланированию    Подразделение 1 Подразделение 2 Подразделение 3 Рисунок 7.1. Структура управления службой ИТ Часть решений, касающихся управления службой ИТ, должны приниматься правлением организации. Эти решения следующие:
Руководитель службы ИТ — вице-президент по информационным системам (Chief Information Officer— CIO) — должен иметь ранг члена правления организации. Столь высокое положение необходимо в силу нескольких соображений:
Комитет по оценке изменений (комитет по изменениям — на Рисунке 1) создается при правлении организации и состоит из ответственных менеджеров (обычно заместители руководителей подразделений — заказчиков службы ИТ), CIO и сотрудников службы ИТ. Комитет выполняет следующие функции: • согласование соглашения об уровне сервиса до вынесения его на рассмотрение правления организации. В силу специфики работы правления документ, выносимый на его рассмотрение, должен представлять собой согласованную позицию всех за интересованных сторон;
Комитет по планированию согласует бизнес-план и финансовый план организации в целом и выносит его на рассмотрение правления. Частью этого бизнес-плана является бизнес-план службы ИС. Наконец, подразделения службы ИС отвечают за выполнение задач и функций в соответствии с организационной структурой службы ИС и эталонной моделью процессов, которая будет рассмотрена в следующем параграфе. Таким образом, служба ИС в общем случае имеет три уровня управления: высший уровень — правление организации, утверждающее стратегически важные решения и документы; средний уровень — уровень согласования интересов службы ИС и подразделений-заказчиков, этот уровень представлен СЮ — руководителем службы ИС, комитетом по оценке изменений и комитетом по планированию; наконец, низший уровень — уровень функций службы ИС как таковой — представлен подразделениями службы ИС. К взаимосвязи функций ИС и ее организационной структуры мы сейчас и переходим. 2. Организационная структура службы ИТ До рассмотрения организационной структуры службы ИТ отметим, что эта структура зависит от многих факторов. В их числе, прежде всего, следует отметить: • масштаб службы ИС — более крупные службы ИС обычно имеют более сложную и разветвленную организационную структуру;
Этот перечень отнюдь не исчерпывающий, в него входят и другие факторы, например состав используемых в организации ИС. Однако подробный рассказ о принципах формирования организационной структуры службы ИС выходит за рамки настоящего учебника, так что в этом параграфе мы ограничимся лишь основными факторами. Итак, рассмотрим распределение функций службы ИС по ее организационной структуре. За основу будут взяты три базовые структурные схемы: плоская структура службы ИС , характерная для службы небольшого размера; развернутая структура , характерная для крупных служб ИС, имеющих один офис; наконец, дивизиональная структура, характерная для компаний, имеющих территориально удаленные офисы. 2.1. Плоская структура службы ИТ Функции планирования в ней выполняются руководителем службы ИС — CIO (рисунок 7.2). Именно по этой причине такая структура пригодна только для службы ИС небольшого размера — в более крупных службах ИС объем работ по планированию требует обособления отдельных функций планирования.  Рисунок 7.2. Плоская структура службы ИТ Непосредственно подчиняются CIOуправление разработкой, выполняющее функции разработки, приобретения и внедрения информационных систем, и управление сопровождением, выполняющее функции предоставления и сопровождения сервисов ИТ. Организационное разделение разработки и эксплуатации имеет принципиальное значение. Успешная эксплуатация ИС в течение сколько-нибудь длительного времени возможна лишь тогда, когда она не требует постоянного вмешательства разработчика. Это обеспечивается соблюдением существующих методологий разработки и тестирования ИС, а также надлежащей пользовательской и эксплуатационной документацией. Тестирование ИС и документации на нее на соответствие требованиям устойчивой эксплуатации обеспечивается в ходе передачи системы в эксплуатацию. Этот процесс и определяет важность разделения двух функциональных направлений. Передача ИС от одного управления службы ИС другому, равноправному первому, обеспечивает всестороннее тестирование созданной ИС и документации на нее. Напротив, внутри одного управления передача в эксплуатацию осуществляется обычно формально, с учетом возможности последующих доработок. Таким образом, во втором случае качество эксплуатируемой ИС обычно оказывается ниже. Рассмотрим теперь организацию каждого из управлений, начиная с управления разработкой. В рамках процесса разработки одна и та же группа — проектная команда, подчиненная одному руководителю, — должна последовательно выполнить все функции процесса разработки применительно к определенной ИС. Следовательно, распределение функций разработки по различным подразделениям не имеет смысла. Напротив, имеет смысл выделить различные проектные группы для различных видов ИС, требующих от сотрудников различных знаний и навыков. В результате в нашем примере выделены два отдела разработки — отдел офисных систем и отдел распределенных систем. Офисные системы представляют собой разработки в среде пакета MS Office, распределенные системы — многопользовательские системы, специализированные для выполнения отдельных задач. В малых организациях типичным примером таких задач и соответственно ИС являются бухгалтерские системы. Отдел офисных систем решает задачи «малой автоматизации» задач пользователей в среде MS Office. Отдел распределенных систем занимается внедрением бухгалтерской системы, а после того как внедрение завершено, расширением ее функциональности — внедрением дополнительных модулей, написанием отчетов и других программ в среде данной распределенной системы. Наконец, в штате управления разработкой необходим хотя бы один менеджер проектов. В простейшем случае им может быть руководитель управления разработкой, однако совмещение этих двух позиций может стать узким местом проектов этого управления. Таким образом, CIO должен отслеживать ситуацию с управлением проектами и при необходимости расширить управление разработкой за счет одного или нескольких менеджеров проектов. Перейдем к организации управления сопровождением. Как и в управлении разработкой, в управлении сопровождением целесообразно выделять группы специалистов сходной квалификационной базы. Отделами, состоящими из сотрудников сходной квалификации, проще управлять, поскольку однородность упрощает найм персонала, диспетчирование работ, бюджетирование и др. Типичный набор отделов в управлении сопровождением в плоской структуре (рисунок 6.2) включает отдел ЛВС (локальной вычислительной сети), отдел распределенных систем, отдел связи и телекоммуникаций, отдел офисных приложений. Первый отдел осуществляет поддержку локальной сети, включая сервер и его ОС, второй — поддержку распределенных систем, например бухгалтерской, третий — связь, телефонизацию и доступ в Интернет, четвертый — поддержку оборудования рабочих мест — компьютеров, принтеров и т.д., а также офисных приложений. Функции мониторинга в плоской структуре выполняет отдел Service Desk, непосредственно подчиненный CIO. В этот отдел поступают сообщения пользователей об инцидентах1, он же сообщает об инциденте соответствующим отделам службы сопровождения и контролирует ход работ по разрешению инцидента. Наконец, в этом отделе накапливается большой объем статистики инцидентов и времени их разрешения. Функции мониторинга более высокого уровня — контроль планов работ, графиков проектов, бюджета службы ИС в целом и отдельных ее подразделений — выполняет CIO. 2.2. Развернутая структура службы ИТ Увеличение размера организации и объема работ службы ИТ ведет к усложнению ее организационной структуры. Если организация не создает новые офисы, удаленные от первоначального (т.е. офисы в другом городе или стране), большой объем работ ведет к созданию службы ИС развернутой структуры (рисунок 6.3). Развернутая структура службы ИТ возникает при большом объеме работ по сопровождению и развитию ИС в том случае, если сопровождение ИС осуществляется из одного центра. Строго говоря, это не исключает наличия удаленных офисов. Однако развернутая структура эффективна тогда, когда объем работ в области ИС в этих удаленных офисах невелик, так что управление работами может осуществляться централизованно. Рассмотрим отличия развернутой структуры ИС от уже рассмотренной нами плоской. Первое отличие состоит в обособлении ряда функций планирования. Именно по этой причине возникают три новых управления или отдела, подчиненные непосредственно CIO (далее для определенности будем говорить об отделах): отдел архитектуры и стандартов, финансовый отдел и отдел управления проектами. Отдел архитектуры и стандартов реализует функцию разработки архитектуры ИС организации и системы стандартов в области ИС и ИТ. Корпоративный стандарт фиксирует набор технологий, применяемых в компании. Разработка архитектуры ИС определяет обновление этого набора.  Рисунок 3. Пример развернутой службы ИТ В рамках этой функции проводится исследование вновь появившихся на рынке технологий с целью, во-первых, оценить их пригодность для решения задач, стоящих перед организацией, и во-вторых, сопоставить их с имеющимися технологиями и системами. Если портфель применяемых технологий значителен, то эти две функции должны быть обособлены от прочих функций планирования и организации. В то же время их очевидная взаимосвязь требует объединения в одном отделе. Финансовый отдел реализует функцию разработки бюджета службы ИС и контроля его исполнения. Объем этой функции также значительно возрастает с ростом операций службы ИС, включая в себя, с одной стороны, бюджетирование всех проектов и сервисов ИТ, с другой — контроль всех проводимых службой ИС платежей с точки зрения соблюдения бюджета и условий заключенных договоров. По этой причине финансовая функция также должна быть обособлена в отдельное подразделение. Отдел управления проектами включает в себя проектных менеджеров и проектный офис службы ИС. Проектные менеджеры реализуют функцию управления проектами. Проектный офис реализует учет работ по проектам и диспетчирование ресурсов проекта — помещений, встреч, командировок и т.д. О причинах обособления функции управления проектами уже говорилось применительно к плоской структуре. В развернутой структуре совмещение управления проектами с какой-либо другой функцией не представляется возможным. Функции управлений в иерархической структуре мало отличаются от функций управления в плоской. Основное отличие в том, что функция текущего производственного планирования в этой структуре делегирована именно управлениям, так же — пропорционально объему выполняемых задач — усложняется структура управлений. В управлении разработкой появляется отдел внутренних приложений — проектов создания распределенных систем собственной разработки. Обычно в рамках таких проектов создаются системы производственного учета, не представленные на рынке в Виде «коробочных» продуктов. Усложняется и структура управления сопровождением. В нем появляется отдел передачи данных — структура, объединяющая в своем составе локальную и глобальную сети организации, а также активное сетевое оборудование, сопрягающее сети в единое целое. Соответственно, в составе отдела выделяются группы активного оборудования (серверов, коммутаторов, маршрутизаторов и др.), группа СКС — структурированной кабельной сети объединяющей в своем составе электрическую, телефонную кабельные сети и кабельную сеть ЛВС, и группа связи, обеспечивающая внешние каналы связи. Сопровождение учрежденческой АТС в зависимости от применяемой технологии может входить как в функции группы активного оборудования, так и в функции группы связи. Цифровая АТС, по сути, представляет собой коммутатор, т.е. активное сетевое оборудование, и должна относиться к полю деятельности соответствующей группы. Аналоговая АТС традиционно сопровождается группой связи. Наконец, в развернутой структуре, как правило, появляется управление метрологией и производственной автоматикой. На производстве к его сфере деятельности относятся системы автоматизации технологических процессов (АСУ ТП — автоматизированные системы управления технологическими процессами), в торговле — системы учета движения товаров, сопряженные с цифровыми весами и кассовыми аппаратами, в банке — банкоматы. Необходимой составной частью всех систем промышленной автоматики являются измерительные приборы и/или датчики, поставляющие в системы исходную информацию. Соответственно, в управлении метрологией и промышленной автоматикой выделяются два отдела — отдел метрологии, отвечающий за сопровождение измерительных приборов и датчиков, и отдел промышленной автоматики, отвечающий за сопровождение систем промышленной автоматики. 2.3. Дивизиональная структура службы ИТ Эта структура (рисунок 7.4) удобна в тех случаях, когда сопровождение всех ИС из единого центра невозможно или неэкономично, например при наличии крупных офисов и/или производственных подразделений в различных городах или, тем более, странах. В этом случае управление сопровождением и ряд других служб необходимо распределить по всем регионам, где оно требуется. Тем самым в службе ИС возникают сравнительно независимые подразделения, которые в теории управления часто называют дивизионами. Именно поэтому данный тип организационной структуры называется дивизиональным. На рисунке 4 каждый дивизион называется департаментом.  Рисунок 7.4. Пример дивизиональной структуры службы ИТ В качестве примера рассмотрим структуру службы ИТ нефтяной компании. Нефтяные компании обычно имеют подразделения в различных регионах, так что обычно они сами и их службы ИС имеют дивизиональную структуру. При этом разнообразные функции службы ИТ имеют множество полезных примеров илллюстрирующих организационные решения. В нашем условном примере компания состоит из штаб-квартиры, расположенной в Москве, и двух подразделений-дивизионов. В Тюмени расположен центр нефтедобычи компании. Его служба ИС обслуживает офисы, управляющие нефтедобычей, но прежде всего — промышленную автоматику нефтяных полей. В Ярославле расположен центр переработки нефти и сбыта нефтепродуктов. Его служба ИС обслуживает офисы, промышленную автоматику нефтеперерабатывающего завода (далее — НПЗ) и промышленную автоматику нефтебаз, реализующих сбыт нефтепродуктов. Рассмотрение дивизиональной структуры службы ИС мы начнем с централизованных служб — архитектура и стандарты, КИС, проекты, стратегия, финансы. Новым подразделением среди них является отдел КИС. Этот отдел отвечает за функционирование двух элементов инфраструктуры ИТ, отсутствующих в более простых структурах: корпоративного центра обработки данных и каналов связи, соединяющих региональные офисы. Эти элементы инфраструктуры ИТ объединяют корпоративную сеть в единое целое на уровне данных. У остальных централизованных служб изменяются функции. Вышеописанные сферы деятельности дополняются функциями установления стандартов и методического обеспечения деятельности региональных департаментов ИС. Финансовый отдел устанавливает формы бюджетирования и отчетности для всех региональных департаментов, архитектурный отдел согласует архитектуры региональных подразделений между собой и с архитектурой корпоративной сети. Отдел стратегии устанавливает единую стратегию развития ИТ в организации, детализированную в разрезе региональных департаментов ИС. Наконец, функции отдела управления проектами практически совпадают с таковыми в развернутой структуре службы ИС. На уровне региональных департаментов структура службы ИС напоминает развернутую структуру. Однако для расширения кругозора читателя в разных региональных департаментах даны разные варианты такой структуры. Структура департамента ИС в Москве имеет две особенности. Во-первых, функции офиса в целом чисто управленческие, поэтому в ней отсутствует управление метрологией и промышленной автоматикой. Во-вторых, частые изменения инфраструктуры ИТ (обычные для головного офиса) обусловливают необходимость создания отдела инфраструктуры ИТ. Этот отдел занимается перемещением вычислительной техники, адаптацией бесперебойного питания и другими вопросами обеспечения изменений в инфраструктуре ИТ. В зависимости от предприятия, текущих задач и целей, работы могут выполнятся собственными сотрудниками или заказываться «на стороне». В случае крупной ИТ структуры, рекомендуется отдельно выделять крупные центры компетенций в ИТ, а также разделять функции Заказчика и исполнителя. В этом случае будет иметься простая возможность анализа: следует ли использовать собственные ресурсы или воспользоваться аутсорсингом. Выбор между централизованной или децентрализованной организационными структурами. Одним из таких вопросов является выбор между централизованной или децентрализованной структурами управления услугами ИТ. Это решение не всегда принимает именно ИТ-директор, в некоторых компаниях оно рассматривается на более высоком уровне. Однако если ИТ-директору выпала возможность выбирать, именно он должен решить, какие услуги будут централизованными, а какие — локальными. Это вечная проблема, и здесь можно встретить сильное противодействие со стороны региональных подразделений. Они обычно считают ИТ вопросом исключительно своей компетенции. В то же время сотрудники удаленных офисов обычно не располагают видением целостной картины; меняющиеся отношения исключительно сложны, и все это может представлять одну из сложнейших проблем ИТ-директора. Пассивное сопротивление, местные привычки, не понимаемые центральным менеджментом, культурные различия и корпоративная культура центрального офиса — вот важнейшие факторы, на которые нужно обратить внимание. Работа централизованной организации требует от сотрудников главного офиса определенной гибкости, чтобы понять потребности региональных отделений. Проблемы, связанные с разницей во времени, осведомленностью о деятельности на местах и синдромом «большого брата», обычно вызывают у ИТ-персонала особые затруднения. Сотрудники ИТ-организации, как правило, обладают развитыми техническими навыками, но в своей занятой жизни не любят проблемы, обусловленные уязвимостью человека. Рекомендаций по по выбору схемы подчинения Поддержка и обслуживание клиентов (Help Desk) и поддержка настольных ПК Если политика компании и внутренние процедуры хорошо про думаны, основные функции технической поддержки, стиль и ха рактер ее реагирования на запросы должны быть одинаковы во всей организации. Функция поддержки в региональных офисах должна быть всегда согласована с центральным офисом (т. е. вос ходить ко второму уровню поддержки, осуществляемой штаб- квартирой). Приобретение оборудования и стандарты поставок должны быть, по возможности, унифицированы по всей компании. (Это не означает, что любые поставки должны быть централизо ванными, так как этому могут препятствовать высокие затраты.) Малые офисы нуждаются в более сильных специалистах поддерж ки, чем центральные отделения, где задачи распределены более четко и есть возможность привлечь менее опытных молодых сотрудников. Стиль местного менеджмента меняется от одного офиса к другому. Самые большие сложности, как правило, встречаются в инженерных подразделениях. Инженеры (разработчики) в целом имеют слабое представление об ИТ-функциях и архитектуре сети. Им обычно нужны самые базовые функции, такие, как регистрация и доступ к приложениям, резервное копирование и хранение информации, доступ в Интернет, электронная почта и работа в корпоративной сети для совместного использования документов. Любое нарушение работы сети может отразиться на графике выпуска продуктов. Отношения с инженерными подразделениями должны быть особенно хорошо продуманными. Для подразделений, обеспечивающих продажи, важен доступ к сети, возможности удаленного доступа и техническое обслуживание ноутбуков. Структура подчинения может быть как локальной, так и централизованной. Как только политика компании и необходимые процедуры выработаны и согласованы с корпоративным и местным руководством, тип подчиненности не имеет существенного значения. Наибольшая опасность расхождения местных групп поддержки и обслуживания клиентов с политикой центра возникает, когда региональный менеджмент вносит свои изменения или формирует свое собственное видение. Например, приобретение нестандартного сетевого и телекоммуникационного оборудования может пагубно сказаться на общей инфраструктуре компании. Когда местный менеджмент контролирует функцию поддержки настольных ПК, может возникнуть значительный конфликт с установлением приоритетов для сотрудников, обеспечивающих такую поддержку. И здесь могут пострадать глобальные проекты и другие стратегические инициативы ИТ-организации. Исключительно важно, чтобы менеджер по операциям ИТ-организации в центральном офисе оправдывал ожидания и собственного руководства, и ИТ-специалистов из регионов. На эту позицию очень сложно найти нужного человека, потому что эта работа часто приводит к конфликтам. Это как раз тот случай, когда локальная функция поддержки должна быть подотчетна только местному руководству. Глобальные же проекты должны обслуживаться централизованно, а ресурсы для их обеспечения предоставляться центральным руководством. Помощь локальных служб должна быть сокращена до минимума. Небольшие и средние компании испытывают существенные затруднения в достижении этого баланса. Влиятельные лица на местах, связанные с руководством, могут существенно осложнить выполнение глобальных стратегий ИТ-организации. Это область, которой многие ИТ-директора не уделяют должного внимания. Благодаря высокой визуализации деятельности служб поддержки, т. е. тому, что она оценивается непосредственно окружающими, некачественный менеджмент и неверно выбранная структура могут привести к неприятностям, затрагивающим и ИТ-директора, и всю ИТ-организацию. Лучший совет здесь — назначить сильного менеджера по операциям с большим опытом ведения переговоров, который может достичь формального или неформального соглашения об уровне услуг с местным менеджментом. Структура подчинения Здесь можно выделить три типа взаимоотношений, которые нужно постоянно контролировать и пересматривать для достижения оптимальных результатов. Взаимосвязи между разными группами практически одинаковы для большинства ИТ-организаций, а существующее варьирование обусловлено разной специализацией подразделений. Например, отношения между локальной группой поддержки ИТ и локальной группой менеджмента организации являются предметом переговоров. Локальные группы поддержки ИТ своими действиями потенциально могут нанести серьезный вред другим пользователям, поэтому важно, чтобы любые изменения перед внедрением обговаривались. Центральному менеджменту нужно поддерживать местные инициативы ИТ-подразделений, устанавливая взаимоотношения с локальными группами. Функции сетевого и системного администраторов Функции сетевого и системного администраторов требуют особого рассмотрения. В небольших компаниях, где ИТ-директор непосредственно управляет ресурсами, рассредоточенными по всему миру, физическое местонахождение людей относительно неважно. Сегодняшние технологии предусматривают удаленное системное управление; физический доступ к устройствам требуется только при неисправностях аппаратных средств, и это может обеспечить служба поддержки настольных ПК на месте. Главная проблема — доверять удаленному персоналу, верить, что сотрудники будут справляться с обязанностями удовлетворительно. Таким образом, главная проблема для менеджера по ИТ-опера-циям заключается в создании доверительных отношений с удаленным персоналом. Другая важная проблема, которую предстоит решить для достижения успеха, состоит в необходимости иметь глобальную систему мониторинга и строгие политику и процедуры, позволяющие избежать дублирования или сбоев в обслуживании из-за плохого обмена информацией между офисами. Хорошим примером здесь может служить ситуация, когда удаленные сотрудники вносят изменения в объекты Active Directory в среде Microsoft без уведомления других офисов. Эти нарушения негативно отражаются на всей ИТ-организации. Понятно, что такая деятельность должна исключительно хорошо регулироваться и получать одобрение руководства. Заниматься этим должны топ-менеджеры по операциям. Выполнение сетевых функций в ИТ-организации должно управляться центральным руководством ИТ. При этом допускается подчинение локальных ИТ-команд местному операционному менеджменту в вопросах информирования и координации при внесении изменений в работу сети. Сами изменения проводятся после согласования всех вопросов на переговорах между центральным и локальным менеджментом. Структура подчинения В этом случае лучше использовать только централизованную модель. Функции поддержки телекоммуникаций Эта функция - централизованная с точки зрения архитектуры На сегодняшний день вопросы поддержки телекоммуникаций приобретают все большее значение. Это связано с тем, что телекоммуникационное оборудование стало более тесно интегрировано с информационными системами. Например, голосовая связь через IP-линии (Voice over IP) и Unified Messaging требуют точного планирования и глобальной поддержки. Поддержка пользователей в этой области является специализированной функцией локальной группы и часто осуществляется в режиме аутсорсинга, так как региональные офисы могут не иметь достаточного опыта или времени.. При планировании инфраструктуры используется модель для сетевых функций, а для локальной поддержки пользователей — модель по обслуживанию персональных ПК. Структура подчинения При проведении изменений в инфраструктуре специалисты по телекоммуникациям должны быть связаны как с функциями ежедневного обслуживания настольных ПК, так и со специалистами, отвечающими за работу сети. В операционной деятельности они должны быть подотчетны локальному менеджменту. Все остальные вопросы должно координировать центральное руководство. Функции поддержки приложений Критерии, определяющие деятельность департамента поддержки приложений, могут существенно меняться в зависимости от вида организации. Крупные системы, требующие большого количества изменений и затрагивающие глобальные функции, должны быть централизованы. В то же время владельцы процессов должны быть рассредоточены по всей организации, чтобы можно было учесть местные особенности. Для обработки различных и иногда противоречивых запросов требуется хороший аналитик центральных бизнес-процессов. Выполняя свои функции, менеджер департамента поддержки приложений должен уметь выстраивать прочные отношения с владельцами процессов из различных департаментов и менеджером по операциям. Временные отключения систем для технического обслуживания должны согласовываться между менеджерами департамента поддержки приложений и менеджером по операциям — во избежание перерывов в обслуживании. Многие небольшие компании используют децентрализованные системы там, где не требуется интеграции данных в масштабах всей компании, например, для ведения бухгалтерской отчетности и в отделе кадров. Централизованная поддержка приложений требуется далеко не всегда и иногда даже способна принести определенный вред, если централизация тормозит процесс принятия решений. В долгосрочной перспективе небольшие системы должны либо объединяться, либо замещаться глобальными системами. Структура подчинения Задача центрального менеджмента (в глобальных системах) состоит в том, чтобы оперативно отслеживать проблемы, вызванные культурными различиями или отличающимися правовыми нормами в других странах. Для успеха в этой области жизненно важным становится быстрое решение нестандартных проблем. Многие американские компании прилагают колоссальные усилия для адекватной поддержки зарубежных офисов, и эта практика таит в себе определенные риски для крупных компаний и грозит потерянными возможностями. Локальный менеджмент часто возмущает неспособность центрального руководства эффективно реагировать на местные требования, и он часто прибегает к созданию собственной команды по поддержке приложений — с известными плачевными последствиями для компании. За этой проблемой ИТ-директор должен следить особенно пристально. При формировании эффективной команды поддержки глобальных приложений он должен не уступать давлению со стороны локального менеджмента, а заручаться поддержкой центрального руководства. 3. Оценка результативности службы ИТ Одним из самых серьезных вопросов, с которым сталкивается любой руководитель ИТ-подразделения, является определение параметров, которые позволят оценить эффективность работы службы ИТ. Не менее сложной является задача оценки этих параметров. Однозначного ответа на эти вопросы, как правило, нет. Примеры Как измерять работу групп разработчиков приложений? По строкам внедренных программ? Или по количеству разработанных приложений?
Нужна ли каждой организации своя система измерений? Даст ли она полное представление об эффективности или неэффективности ее управления? Позволят ли эти цифры узнать об операционном совершенстве каждой конкретной команды? Вся искомая информация должна акцентироваться на основных проблемах. Теперь поговорим о трудной задаче поиска этих данных. Какие подходы можно использовать для ответа на эти вопросы? Для многих организаций существенный объем новых данных становится доступным с введением сертификации ISO, Baldridge quality или какой-либо другой системы всеобщего управления качеством (TQM). Получение таких сертификатов, постановка процессов и процедуры реинжиниринга бизнес-процесов иногда могут выходить за рамки финансовых возможностей многих крупных компаний. Однако принципы, лежащие в основе этих конкретных сертификации, заслуживают того, чтобы использовать их как фундамент для успешных измерений и управления. Но все это требует больших объемов работ, вместе с тем значительного повышения качества можно добиться, если удастся выявить (с помощью соответствующих измерений) места, где существуют операционные и методологические проблемы, и разработать механизмы их устранения. Полезным побочным продуктом таких усилий бывает создание контрольных точек, которые можно использовать для измерения эффективности бизнеса в сравнении со значимыми критериями и для определения ключевых возможностей бизнеса. Качество и ISO-программы могут затем лечь в основу при создании руководителями бизнес-единиц собственных целевых измерений операционной эффективности. Самым важным результатом этих разнообразных инициатив является то, что бизнес-единицы вырабатывают те способы измерения своей деятельности, которые специально приспособлены к ихкритериям успеха. Появившись однажды, эти документированные процессы и измерения способны привести к значительному повышению качества и эффективности по всей компании. Новые требования к приложениям, выдвигаемые бизнесом, включают: создание технических решений, которые позволяют учитывать все данные и специфику организации. К сожалению, эта новая возможность измерения каждого аспекта бизнес-операций влечет за собой другую опасность: близорукую сосредоточенность на слишком мелких деталях операций. Теперь, вместо того чтобы создать несколько значимых областей измерения показателей, можно прийти к культу «управления всем по цифрам», который может привести бизнес к краху. Какой путь избрать в этом случае? Ключ к этому — понимание того, как использовать информацию в качестве инструмента, а не конечного результата. Более того, конечной целью является использование правильной информации в нужных количествах — с целью достижения намеченных показателей развития бизнеса. Но, если компания делает слишком большой упор на цифры, это может оказаться тяжелым бременем для нее, потому что необходимо, чтобы показатели могли изменяться вместе с бизнесом. Если же результат зависит от целых серий других точек данных (такие долгосрочные бизнес-проекты, как разработка крупных систем — CRM, ERP и др.), а каналы передачи данных оказываются нарушенными из-за сильных изменений в структуре бизнеса (например, по причине недостаточного внимания к каким-либо из этих проектов), то такие показатели перестают быть статистически достоверными. К тому же если компания начинает долгосрочный инвестиционный проект, то все соответствующие изменения должны быть внесены в бюджет. Внеплановые расходы на осуществление серьезных проектов обычно способны разрушить все усилия по многолетнему планированию. Можно оптимизировать уровень расходов, но инвестиционные проекты являются обязательными (наряду с лицензионными программами, программами поддержки и т. д.). Для постановки стратегических целей, сужения количества альтернативных инвестиционных проектов с целью минимизации расходов и для постоянной оценки достижений на пути к успеху — для всего этого необходимо использовать хорошие показатели. Во время периодов сокращения затрат финансовые директора обычно используют примитивную, но всегда удобную для них политику «процента от выручки» в качестве единственного финансового показателя. ИТ - директор узнает о том, фирма должна потратить на ИТ не более Х% выручки, а этот X очень небольшое число. Хотя проценты, как упоминалось ранее, достаточно просто измерить, такой показатель абсолютно неприменим для оценки расходов ИТ - организации. Более того, Использование такого показателя обычно приводит к неспособности ИТ-организации достичь поставленных целей. У этого показателя есть еще один негативный эффект, который почти не позволяет привязать индивидуальные операционные цели каждого конкретного Исполнителя к общим производственным показателям. При Использовании таких показателей в номинальном выражении возможны всего два Исхода: либо задачи не будут решены, либо нет. Для нормального управления этого явно не достаточно. Как должен вести себя в подобных ситуациях руководитель службы ИТ. Начинать необходимо с корректировки требуемого показателя по каждой из стратегических или операционных потребностей бизнеса. Вместо того чтобы просто создавать бюджет для ИТ-сотрудников, расходы выражаются в терминах потребностей и влияния на бизнес. Например, определите, какой процент бюджета необходим для покрытия операционных и постоянных расходов:
Необходимо привязать несколько ключевых показателей деятельности операционных групп не к эффективности, а к денежным величинам. Не надо перечислять «количество запросов, закрытых службой поддержки и обслуживания клиентов (help desk)», их нужно измерять в терминах выручки. Например,
500 тыс. руб., или 0,5% выручки. 50 тыс. запросов ежегодно. процент от выручки за каждые 10 тыс. запросов = 0,075%. Тогда для организации, оказывающей поддержку конечным пользователям, можно поставить задачу сократить затраты на 10 тыс. запросов с 0,075% до 0,070% или 0,065% выручки. Хотя проценты выглядят небольшими, такие числа легко считать, и их можно непосредственно привязать к измерению работы каждой отдельной группы в вашей организации. Вместо обобщенных требований к достижению показателей, ставятся конкретные задачи, понятные каждому менеджеру по операциям. Для стратегических проектов можно разбить общую сумму расходов на несколько частей, по каждому продукту или проекту. Вместо того чтобы говорить, что бюджет проекта CRM должен составить 900 тыс. руб., можно показать это следующим образом:
При этом появляется возможность говорить с гендиректором гораздо более продуктивно. Теперь, вместо обсуждения общих по отрасли показателей затрат как процента от выручки, можно не только продемонстрировать способности к достижению этих целевых показателей, но и четко показать, как это произошло. На собранные вручную результаты измерений тратится больше усилий, чем получается отдачи. Горы информации, которую необходимо систематизировать, превратив в определенные показатели, могут сделать задачу невыполнимой. К тому же определение показателей производится не только для самой ИТ-организации. Нередко в маленьких компаниях ИТ-организация также служит в качестве единого Источника информации для составления отчетов в других подразделениях. Там принято поручать составление отчетов членам администрации или сотрудникам вспомогательных служб, но при постоянных изменениях и обновлении приоритетов, эта работа будет наверняка требовать все больше людей. Сегодняшний уровень развития технологий и промышленности позволяет большому количеству предприятий автоматизировать сбор почти любой возможной информации о своей деятельности. Внутри отдельных бизнес-единиц, деятельность которых измеряется с помощью каких-то особых индикаторов, могут существовать свои возможности для сбора и обработки показателей. Это возможно при правильной организации Использования хранилищ данных и других инструментов предоставления и анализа информации. 4. Использование системы сбалансированных показателей для оценки работы ИТ-службы предприятия Людям свойственно корректировать свое поведение с целью достижения каких-либо желаемых показателей эффективности. Из-за таких особенностей поведения, любого отдельно взятого показателя обычно бывает недостаточно, и это может негативно повлиять или даже разрушить всю идею Использования измерений. Поэтому важно, чтобы общая оценка деятельности любой организации проводилась путем измерения тех же данных с разных позиций. Подобный взвешенный подход к показателям вылился в концепцию, называемую «Сбалансированная система показателей». Этот подход к стратегическому менеджменту и измерениям был разработан в начале 1990-х годов докторами Робертом Капланом (Гарвардская школа бизнеса) и Дэвидом Нортоном (компания Balanced Scorecard Collaborative). Признавая некоторые слабости и неясности предыдущих подходов к менеджменту, Сбалансированная система показателей предоставляет компаниям четкие рекомендации в отношении того, что именно нужно измерять, чтобы в итоге «сбалансировать» финансовые показатели. Что такое Система показателей?
На рисунке 7.5. приведен пример сбалансированной модели показателей, которая позволяет измерять финансовые и другие нефинансовые атрибуты.  Рисунок 7.5. Сбалансированная система показателей компании с точки зрения клиента, эффективности бизнес-процессов, сотрудников, исследований и перспектив роста Когда определены стратегические показатели высокого уровня, а также ключевые операционные показатели, встает задача представления информации. Задача построить согласованные показатели деятельности вашей организации крайне важна, но для представления подобной информации требуется персонификация одних и тех же данных для разных пользователей. Одной из самых популярных и удачных технологий, позволяющих использовать измерения на пользу всей компании, является как раз Сбалансированная система показателей. Как и любая другая система менеджмента, разработанная в наше время, Сбалансированная система показателей при неправильном Использовании может вызвать множество нежелательных последствий. Тем не менее, она остается одним из наиболее простых и эффективных подходов, с помощью которого измерения остаются в центре, как ежедневных операций, так и долгосрочного планирования. Сбалансированная система показателей позволяет непрерывно оценивать возможности основных бизнес-процессов компании в сравнении со стратегическими задачами. Проще говоря, она помогает ответить на вопрос, «действительно ли моя компания (и департамент) успешна в тех областях, которые важны для достижения наших ключевых целей?». Разработка Сбалансированной системы показателей поможет сосредоточиться на стратегических целях компании на уровне руководства, а затем Использовать это для нисходящей постановки задач. Лучшим первым шагом при Использовании данной модели должна стать оценка основных стратегических целей и разделение их на категории. ИТ-директор находится в уникальном положении, позволяющем ему сформировать свое видение ситуации во всех областях бизнеса. Он должен брать на себя активную роль, помогая различным группам преодолевать неудачи в их деятельности и сбои в процессах, поскольку это влияет на эффективность всей организации. Такие рекомендации со стороны ИТ-директора могут касаться различных областей, где есть проблемы, при этом он выявляет: лучшие способы поддержки клиентов в сервисных организациях, методы повышения финансовой эффективности в финансовом отделе, возможности сокращения времени вывода на рынок при разработке продукта, улучшение способов удержания рабочей силы в отделе по работе с кадрами и т. д. Несмотря на то, что нужды каждого департамента, несомненно, важны для него самого, равномерное распределение ИТ-ресурсов или прочих ресурсов компании по всем группам может привести к неудаче. Руководство компании должно принимать решения по установлению относительных приоритетов для каждой стратегической цели. Для наибольшей эффективности эти меры должны проводиться во всей компании и охватывать все категории деятельности. Подобное ранжирование будет применяться для оценки и распределения ресурсов по каждой группе. Результатом станет инструмент перевода и презентации общих показателей ИТ-организации и индивидуальных показателей ее сотрудников для остальной части компании. Если развить предыдущий пример, в котором от ИТ-директору требовалось достичь показателя расходов не более 5% выручки, можно увидеть, как описанный подход меняет представление проведенных измерений. Допустим, у нас есть корпоративная цель повышения валовой прибыли на ХХ% или сокращения общих и административных расходов на УУ%. Теперь, вместо измерения эффективности команды в пересчете на выручку, показатели могут устанавливаться в терминах увеличения валовой прибыли: • Суммарный бюджет = 10 млн. руб., или 5% выручки. Операционный бюджет = 8 млн. руб., или 4% выручки.
Из этого следует, что каждые 4000 запросов, закрытых службой поддержки и обслуживания клиентов, увеличивают валовую прибыль на 0,002%. Сбалансированная система показателей должна быть «живым» документом, который поддерживает команда руководителей и использует вся компания. Она становится важнейшим инструментом для постоянной корректировки курса, оптимизации ресурсов, распределения ресурсов и изменения приоритетов, в отличие от ежеквартальных отчетов, отражающих прошедшую ситуацию, которую уже нельзя отправить. Чтобы заставить такую систему работать, требуется создавать ежемесячные, еженедельные или даже ежедневные отчеты, которые были бы непосредственно связаны с целями Сбалансированной системы показателей. Концепция системы сбалансированных показателей хорошо подходит для оценки результатов деятельности служб ИТ, связанных с информационными технологиями, причем ее эффективность во многих случаях гораздо выше по сравнению с традиционными методами. . К количественным показателям эффективности в мире ИТ давно привыкли. В течение многих лет текущее состояние инфраструктуры определялось характеристиками готовности и времени отклика, а также качеством техподдержки (оперативностью разрешения возникающих вопросов и скоростью реакции на поступающие сообщения). Оценивались поставляемые приложения, уровень технического сопровождения, соотношение времени реализации и стоимости проекта, а также степень удовлетворения потребностей пользователей. Некоторые организации делали упор на функциональных возможностях, считая, что именно они оказывают основное влияние на общий коэффициент полезного действия и являются ключевым параметром при планировании будущих разработок. Другие основное внимание уделяли соглашениям об уровне обслуживания (service level agreement — SLA) для критически важных служб. Эти соглашения позволяли оценить общее качество функционирования системы. Но, несмотря на все свои достоинства, данные параметры не позволяли дать ответ на следующие вопросы.
Использование подхода BSC позволяет ответить на все эти вопросы и обеспечить более четкое понимание причин успеха информационных служб, а также выявить те области, в которых возможно дальнейшее улучшение. |