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

· CEO и CIO - конфликт или взаимодействие

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

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

При этом практически все эксперты согласны, что главные факторы успеха ИТ-стратегии - вовлеченность руководства и выделение специального управленческого ресурса для этих целей. ИТ-отдел компании не сможет разработать полноценную ИТ-стратегию только своими силами. "Самая частая ошибка - когда такая разработка происходит внутри ИТ-отдела, - уверен Александр Тукунов. - Тогда как необходимо участие тех, кто занимается бизнес-стратегией в целом". Если такого участия нет, то, по меткому выражению Дмитрия Васильева, порой положение директора по ИТ напоминает попытку "догнать убегающий бизнес с его задачами, а бизнес все убегает и убегает. И непонятно - догонишь его или нет". "Качество планирования в сфере ИТ, т. е. ИТ-стратегии, и ее ценность для компании зависят в большей степени от вовлеченности в разработку ИТ-стратегии самой заинтересованной стороны - бизнес-пользователей, и в меньшей степени от наличия в компании бизнес-стратегии", - соглашается Феликс Гликман. Он уверен, что, как и в ситуации с внедрением ERP-систем, разработка ИТ-стратегии должна быть общим делом: ИТ-специалистов и ключевых пользователей, для которых планируется создание (модернизация) информационной системы компании. Работа с ключевыми пользователями и руководством компании в течение проекта выработки ИТ-стратегии позволяет не только получить более актуальную информацию о потребностях бизнеса компании (по сравнению, например, с изложенными в документе "Бизнес-стратегия"), но и доказать руководству необходимость инвестиций в сферу ИТ, заручиться поддержкой руководителей структурных подразделений при защите ИТ-стратегии на совете директоров компании. Поэтому формальное принятие компанией ИТ-стратегии и выделение инвестиций для ее реализации напрямую зависят от уровня поддержки этой ИТ-стратегии руководителями основных бизнес подразделений компании.

Наличие (или отсутствие) на предприятии сформулированной ИТ-стратегии влияет на:

· количество закрытых или "замороженных" ИТ-проектов;

· объем и структуру затрат на ИТ;

· структуру и численность ИТ-службы;

· долгосрочные финансовые показатели деятельности предприятия.

· Привлечение консультантов: аргументы "за" и "против"

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

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

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

Стоимость разработки ИТ-стратегии

Оценки стоимости разработки ИТ-стратегии, которые приводят эксперты, достаточно сильно разняться. С одной точки зрения, проекты по разработке бизнес-стратегии стоят от 800 тыс. до 2 млн долл., а продолжаются 3--6 месяцев. По другим экспертным оценкам, такие проекты оцениваются как от 10 -- 50% стоимости проекта по внедрению управленческой системы, то есть до 500 тыс. долл.

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

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

Исследование РА "Эксперт" выявило достаточно очевидную тенденцию - консультанты стремятся расширить сферу своей деятельности. Каждый из консультантов посягает на смежное поле деятельности: бизнес-консультант дает рекомендации по ИТ-стратегии, внедренцы ERP-систем и системные интеграторы претендуют не только на роль разработчика ИТ-стратегии, но и на роль консультанта по бизнесу. Преимущество консалтинга "из одних рук" очевидно - меньшая стоимость комплексного консультирования. Если на каждую задачу предприятие будет нанимать отдельного, "точечного" консультанта, общая стоимость услуг будет в 3-4 раза выше, чем в случае консалтинга "из одних рук". Но есть и проблемы, осложняющие привлечение одного консультанта для комплексного консультирования. Это непроработанность новых схем оплаты услуг (процент от полученного экономического эффекта, система бонусов - вместо традиционных схем Time & Materials и Fixed Price). Кроме того, заказчики не хотят попадать в зависимость к одному-единственному консультанту, да и выбор такого консультанта непрост - консалтинговая компания-претендент должна иметь в своем штате высоковалифицированных специалистов по всем видам консультирования.

Однако даже привелечение консультантов не дает гарантии, что их рекомендации принесут пользу. Ирина Шувалова, директор по развитию РА "Эксперт РА", приводит такой факт - 70% оплаченных услуг консалтингового рынка, по сути, являются для клиентов выброшенными деньгами, эти рекомендации так и не применили. Можно ли считать, что это результат простого недопонимания? По мнению Ирины Шуваловой, здесь скорее имеют место скрытые психологические механизмы, тормозящие стратегическое видение, - человек не склонен доверять радикальным рекомендациям, идущим вразрез с его собственным видением ситуации: "Это механизм психологической защиты управленцев".

8.5 Разработка стратегии с учетом стандарта Cobit

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

Cobit (control objectives for information and related technologies) -- это методология управления, контроля и аудита информационных систем.

Он был создан Международной ассоциацией аудита и контроля за информационными системами (ISACA) в 1996 году именно как средство аудита ИС. Но так как контролировать проще то, что стандартизировано, со временем методология аудита превратилась в рекомендованный ассоциацией стандарт - некий набор лучших практик. В итоге на сегодняшний день Cobit позволяет организовать системный мониторинг работы ИТ_службы, соотнесенный с целями и задачами бизнеса. Кроме того, его использование делает возможным сравнение организаций внутри отрасли на предмет уровня зрелости процессов.

Стандарт делит всю деятельность ИТ на четыре домена (сферы деятельности): планирование и организация, проектирование и внедрение, эксплуатация и сопровождение, мониторинг (рис. 1). Все вместе они включают в себя 34 процесса, каждый из которых привязан к определенной ИТ-цели, сопоставленной, в свою очередь, с бизнес-целью. Этот раздел Cobit наиболее интересен для построения ИТ_стратегии.

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

Рис. 2. Cobit и ИТ-стратегия

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

Концепция создания ИТ_стратегии

Любая ИТ_стратегия, претендующая на полноту описания, должна рассматриваться в пяти основных разрезах. Они также предложены Cobit и широко используются в стандарте: информация, приложения, инфраструктура, ИТ-процессы и люди. Кроме того, каждый из них должен рассматриваться в следующих пяти разрезах (рис. 2).

1. Ситуация «как есть» (AS-IS). Необходимо отразить состояние ИТ на текущий момент -- информационные потоки, архитектуру приложений и инфраструктуры, процессы и их уровень зрелости, оргструктуру и сотрудников.

2. Варианты развития (варианты TO-BE). Известный историк Бэзил Лиддел Гарт, написавший знаковую книгу «Стратегия непрямых действий», утверждал, что нельзя идти напролом, необходимо найти и использовать обходные пути достижения цели. Они всегда есть. По его словам, план без вариантов подобен дереву без ветвей и соответственно ни к чему хорошему не приведет. Любая стратегия при разработке должна учитывать наличие вариантов развития каждого из указанных направлений. Например, можно по_разному создавать инфраструктуру: арендовать каналы связи или прокладывать свои; ориентироваться на одного вендора или искать лучшие решения; создавать внутреннюю команду программистов или привлекать специализированные компании.

3. Лучший вариант (TO-BE). Он выявляется путем анализа на адекватность всех созданных вариантов, и на нем строится основная ИТ_стратегия. Остальные сохраняются для объяснения причин выбора текущего пути, а также на случай, если что_то пойдет не так, как предполагалось. Энди Гроув, бывший CEO компании Intel, написал книгу под названием «Выживают только параноики». Из общего числа литературы по менеджменту она выделяется, кроме названия, подходом автора к теме -- через всю книгу проходит сквозная мысль: «Надо бояться десятикратного». Автор все время ожидает, что произойдет нечто, способное изменить всю нашу жизнь, и предлагает периодически пересматривать позиции. Например, десятикратное уменьшение количества клиентов. Как показывают события, произошедшие в экономике за последний год, такие опасения могут быть далеко не напрасны, поэтому варианты надо хранить и периодически пересматривать.

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

5. Набор KPI -- индикаторов движения к цели. Показатели того, насколько мы продвинулись от AS-IS к TO-BE.

Роль Cobit при использовании этого подхода весьма велика. Во-первых, в нем перечислены и описаны высокоуровневые ИТ-процессы, список которых можно взять за основу при разработке своей модели процессов или просто использовать как есть. Во-вторых, в Cobit по каждому процессу написан набор KPI, а также KGI (Key Goal Indicators), которые тоже стоит проанализировать и использовать при создании своего набора KPI. И в_третьих, в нем содержится довольно любопытный инструмент, облегчающий привязку целей ИТ к целям бизнеса, о котором мы расскажем ниже.

Как от целей бизнеса перейти к ИТ-целям

В стандарте Cobit -- объемное руководство, в конце в приложении 1, показывается связь бизнес-целей, ИТ-целей и ИТ-процессов. В нем на основе сбалансированной системы показателей (BSC) описаны стандартные бизнес-цели, которых на самом деле немного. Им сопоставлены соответствующие ИТ-цели. Еще одна таблица показывает, какие ИТ-процессы необходимо развивать, чтобы достигнуть определенных ИТ-целей. Также в этом приложении опубликован список ИТ-процессов, для которых, в соответствии с предпочтениями авторов Cobit, указаны приоритеты.

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

Рис. 3. Пример связи бизнес-целей и ИТ-процессов

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

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

КЛЮЧЕВЫЕ МОМЕНТЫ ТЕМЫ №8

8.1. ИТ-стратегия определяет долгосрочные цели и направление движения предприятия в области ИТ. Результатом ее применения и использования является успешное существование компании.

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

8.3. Требований, которые должны присутствовать в «документе, определяющем ИТ стратегию предприятия:

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

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

· Определена функция ИТ-службы в компании, проведен анализ состояния ИТ-подразделения по отношению к компании.

· Определены общие подходы к реализации стратегических задач. Например: способы реализации проектов (разработка, аутсорсинг и пр.); подход к поддержке основных ИТ-сервисов (традиционный, SLA); организационные аспекты и т. д.

· Даны основные критерии успешного решения основных стратегических задач ИТ.

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

Признаки хорошей ИТ-стратегии

Хорошая ИТ-стратегия должна содержать:

1. Результаты анализа бизнес-процессов предприятия.

2. Детальный анализ требований к информационно-вычислительным системам, а также степени покрытия ими существующих бизнес-процессов.

3. Несколько вариантов ИТ-стратегии с оценкой факторов риска по каждому варианту.

4. Оценки стоимости, сроков и ресурсов для внедрения соответствующих информационных технологий.

Хорошая стратегия должна:

· быть увязана со стратегическими целями развития бизнеса;

· быть этапной, то есть предусматривать возможность изменений;

· быть многоплатформенной, то есть не привязанной к одному конкретному поставщику оборудования или программного обеспечения;

· предусматривать запасные варианты на случай неблагоприятного развития событий.

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

8.6. ИТ-стратегия для ИТ-департамента:

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

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

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

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

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

Тема 9. Консалтинг, как составляющая процесса создания автоматизированных информационных систем

9.1 Определение консалтинга

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

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

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

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

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

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

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

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

9.2 Виды консалтинга

Предоставляемые консалтинговой компанией услуги могут принимать следующие основные формы:

1. Аналитическая деятельность (анализ и оценка внутрихозяйственной и финансовой деятельности предприятия-клиента, анализ инвестиционных проектов, исследования деятельности конкурентов, рынков сбыта, движения цен и т.д.);

2. Прогнозирование (на основе проведенного анализа и используемых консультантом методик - составление прогнозов по указанным выше направлениям);

3. Консультации по самому широкому кругу вопросов, касающихся как деятельности компании-клиента, так и рынка в целом;

4. Ревизия деятельности предприятия-клиента;

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

9.3 Этапы консалтинга

Консалтинг предваряет и регламентирует названные этапы.

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

Нулевой цикл включает:

1) предварительное обследование и оценку состояния (предпроектное обследование);

2) предварительную переподготовку;

3) техническое задание;

4) технико-экономическое обоснование;

5) организацию проекта;

6) выработку целей.

Рассмотрим каждый этап подробнее.

1) Предпроектное обследование

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

С помощью специализированных средств (например BPWin) строится диаграмма бизнес-процессов (обычно - в нотации DFD), каждый из которых характеризуется объемным блоком информации:

· № и наименование процесса;

· № и наименование процесса верхнего уровня;

· №№ и наименования вложенных детальных процессов следующего уровня;

· текстовое описание процесса;

· перечень выходов процесса (документы, файлы, материальные ресурсы, являющие результатом выполнения процесса);

· события, инициирующие процесс;

· события, завершающие процесс;

· перечень функций процесса;

· перечень функций, контролирующих выполнение процесса;

· перечень входящих документов;

· перечень входящих материальных ресурсов;

· перечень исходящих документов;

· перечень исходящих материальных ресурсов;

· перечень подразделений и должностей, участвующих в процессе;

· типы используемых систем автоматизации.

На основе исследований строятся модели “as is” (как есть) и “to be” (как должно быть). Реорганизация представляет собой переход от одной модели к другой и позволяет навести элементарный порядок в организации процессов.

Как правило, руководство фирмы-заказчика требует также определить приблизительную продолжительность и стоимость проекта.

2) Предварительная переподготовка

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

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

3) Техническое задание

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

· требования к автоматизированным рабочим местам, их составу и структуре;

· разработка требований к программным средствам;

· разработка топологии, состава и структуры локальной вычислительной сети;

· требования к секретности и защите информации.

4) Технико-экономическое обоснование

Анализ “затраты-эффект” позволяет принимать обоснованные решения и подтверждает финансовую необходимость изменений.

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

В то же время определение и количественная оценка некоторых статей расходов до сих пор вызывает трудности даже за рубежом. Отчасти задача решается методом аналогий.

Менее благополучно дело обстоит с внедрением бухгалтерских модулей.

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

5) Организация проекта

Существуют три уровня организации проекта (для больших предприятий):

· Управляющий комитет (руководитель компании и его заместители). Регулярные совещания 1-2 раза в месяц. Определяет стратегию, ресурсы, принимает основные решения.

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

· Рабочая команда по внедрению (6-7 специалистов из разных областей). Разбивается на логические группы по подразделениям, производственным направлениям и программам. Осуществляет контроль на уровне фирмы и ее отделов. Члены команд могут работать над отдельными задачами.

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

Оптимальная структура рабочей команды:

· сотрудник (сотрудники) заказчика, работающие на данном участке. Задачи: консультировать ИТ специалистов, осуществлять текущий контроль и предварительную приемку внедряемых объектов (формы, документы, отчеты и т. д.);

· сотрудник (сотрудники) отдела информационных технологий (ОИТ) заказчика. Задачи: освоить в необходимом объеме инструментальные средства исполнителя (“1С”, “Галактика”, Scala, R3 и др.), участвовать в доводке и разработке автоматизированной системы, служить информационным “буфером” между сотрудниками клиента и консультантами исполнителя;

· консультанты-программисты исполнителя. Задачи: разработать, внедрить, адаптировать необходимые модули, консультировать сотрудников ОИТ заказчика.

6) Выработка целей

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

Как уже говорилось, расчет ROI (коэффициент эффективности инвестиций) для проектов по автоматизации вызывает значительные трудности даже в наиболее “продвинутых” странах. Цели не определяются с точки зрения чисто финансовой выгоды, а связываются с появлением новых источников информации или получением качественного экономического эффекта.

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

Вторая фаза автоматизации

Одним словом, можно приступать ко второй фазе автоматизации. Она также состоит из нескольких этапов.

1) Технический проект

Технический проект (техническое предложение, ТП) - это набор документов и спецификаций, описывающих конструкцию, архитектуру, устройство и состав как системы в целом, так и отдельных ее модулей.

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

В российской практике результаты предпроектного обследования, техническое задание и технический проект часто сводятся в один документ (техническое задание). Реализация описываемого плана в полном объеме предполагает, что в этом случае данные будут хотя бы тематически разделены.

2) Начальная переподготовка

Цель начальной переподготовки - обучение персонала, который затем будет работать над внедрением системы.

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

Большое значение имеет переподготовка по обеспечению необходимой точности данных (см. ниже “Управление данными”).

3) Планирование

Как правило, на предприятии существуют два плана автоматизации: стратегический и оперативный.

Стратегический план содержит базовые принципы, в том числе:

· цели;

· способ автоматизации (комплексная, кустовая и т. д.);

· долгосрочную техническую политику (стандарты и т. д.);

· ограничения (финансовые, временные и т. д.).

Стратегия автоматизации должна соответствовать общей стратегии бизнеса.

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

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

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

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

В оперативном плане определяются основные этапы автоматизации и сроки их реализации (переподготовка, внедрение новых алгоритмов управления данными, переход на новую систему и т. д.).

4) Параллельное внедрение

Новые технологии целесообразно внедрять параллельно в различных областях производственной деятельности (бухгалтерия, кадры, производство, контроль качества, САПР и т. д.).

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

5) Выбор системы

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

6) Ввод в эксплуатацию

Есть несколько способов приступить к использованию новой системы:

· Параллельная стратегия. Одновременная работа вручную, на “старой” системе и на внедренной. Результаты постоянно сравниваются, новая система адаптируется. Недостаток - значительные трудозатраты (вследствие дуюлирования), большие сроки внедрения.

· Скачок (шоковая терапия). “С понедельника работаем на новой системе!” Эффективно, но иногда приводит к провалу.

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

· Узкое место. Автоматизация самого “узкого” производственного места с постепенным расширением области автоматизации.

7) Этапы развития функциональности

Независимо от способа ввода в эксплуатацию, достижение максимальной функциональности системы обычно проходит в несколько этапов:

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

· Создание рабочих проектов. Рабочий проект - система с неполной функциональностью, на которой, тем не менее, можно проводить основные операции и обучение.

· Разработка и внедрение. Функциональность доведена до оптимального состояния, система готова к эксплуатации.

8) Оценка результатов

Получение “обратной связи”: результаты деятельности системы сравниваются с целями, сформулированными на начальном этапе и скорректированными в процессе внедрения. Данный этап позволяет понять, насколько успешен проект внедрения.

9) Анализ текущего состояния

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

Постоянная переподготовка

Переподготовка не завершается после внедрения системы. Она должна проходить регулярно.

9.4 Требования, предъявляемые к консалтинговой компании

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

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

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

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

Консультант (либо консалтинговая компания) обязан оказывать заказчикам помощь в использовании их собственного опыта для непрерывного совершенствования своей деятельности.

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

Консультант (либо консалтинговая компания) должен обладать обучающим воздействием на клиентов.

Структуры в России, которым оказываются консалтинговые услуги

Консалтинговая компания, работающая на российском рынке, может оказывать услуги следующим структурам:

1. российским предприятиям частного и государственного сектора, производящим продукцию и услуги;

2. иностранным компаниям, работающим на российском рынке (к таким компаниям могут быть отнесены западные инвесторы, вступающие в российский рынок и развивающие бизнес в стране, международные финансовые институты, внедряющие современные технологии в российский бизнес и осуществляющие крупные проекты в России, а также ряд других);

3. органам государственного управления и правительственным организациям (имеются в виду административные органы всех уровней, мэрии, министерства, ведомства, государственные комитеты и т.д.).

В каких случаях клиенты обращаются за помощью в консалтинговую компанию?

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

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

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

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

КЛЮЧЕВЫЕ МОМЕНТЫ ТЕМЫ №9

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

9.2 Этапы первой фазы автоматизации:

1. предварительное обследование и оценку состояния (предпроектное обследование);

2. предварительную переподготовку;

3. техническое задание;

4. технико-экономическое обоснование;

5. организацию проекта;

6. выработку целей.

Тема 10. Организационная модель и сервисный подход

10.1 Организационная модель в системе управления ИТ

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

Рис. 10.1. Организационная модель в системе управления ИТ

10.2 Ключевые элементы организационной модели

Организационная структура

Приступая к проектированию или реорганизации структуры ИТ_департамента, необходимо принимать во внимание следующие факторы: выполняемые ИТ_департаментом функции, географию бизнеса, ориентацию бизнеса на клиентов и продукты, степень централизации управления.

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

Рис. 10.2. Основные функции ИТ

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

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

Еще один способ формирования организационной структуры основан на степени централизации управления ИТ-функциями.

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



Рис. 10.3. Матричная структура ИТ

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

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

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

Роли и квалификация персонала

В настоящее время для построения организационной модели и определения должностных обязанностей персонала все большее распространение получает ролевая модель. Под ролью подразумевается набор взаимосвязанных типовых работ, который выполняет специалист в определенных условиях. У специалиста (например, системного администратора) может быть несколько ролей в рамках одной организации (администратор БД, ОС и т.?п.). В контексте сервисного подхода нас интересует, прежде всего, появление относительно новых ролей, таких как менеджер процесса, владелец процесса, менеджер сервиса и др.

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

Можно выделить три вида компетенций, определяющих квалификацию персонала современной ИТ_службы:

· технические компетенции - навыки и знания о технологиях, технической архитектуре в целом и отдельных ее элементах в частности, средствах разработки и проектирования систем;

· управленческие компетенции -- управленческие навыки и знания для специалистов, работающих в сфере информационных технологий, как правило, включают навыки и знания в области проектного управления, ИТ-процессов и подходов к управления услугами, архитектуры ИТ и управления архитектурой, руководства персоналом, навыки аналитической работы;

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

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

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