Михаил Токарев: Бизнес-процессы IT-организаций. Бизнес-процессы: настройка и внедрение автоматизации

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

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

1. «Начальное заражение бизнеса информационными технологиями». Было время, когда ИТ реально воспринималось субъектами бизнес-процессов как игрушка, новая мода, более мощный, но непонятный и сложный калькулятор.
Я помню до сих пор бухгалтеров старой закалки, которые доверяли больше железным арифмометрам, и это было милое время, когда между ИТ-специалистами (поголовно называемыми программистами) и бизнес-подразделениями царила «гармония». Никто друг другу не мешал.
Но потом молодые бухгалтеры (двоечники, не научившиеся в институтах считать на арифмометрах и калькуляторах) стали требовать, чтобы ПК не зависали, чтобы программа считала быстрее, чтобы печать бланков соответствовала ГОСТам, чтобы (о боже!) два сотрудника одновременно могли работать с одной базой.
Айтишники встретили новое время с энтузиазмом, заразившим руководство готовностью утверждать новые штатные расписания и расходы на сервера, СКС, модемы и даже цветные лазерные принтеры стоимостью с новый автомобиль.

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

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

4. «Зрелость» — тот этап, к которому шли раньше предприятия годами, и который сейчас должен реализовываться в течение нескольких месяцев после начала работы бизнес-единицы, а ещё лучше за несколько месяцев до начала.
Зрелость — это когда все информационные потоки, образующие информационную систему, как раз и являются отражением структуры предприятия и всех её бизнес-процессов.
То есть ИТ перестает быть всего лишь инструментом-палочкой (раньше даже термин был — «костыль»). Роль информационных технологий в бизнесе изменилась. Теперь ИТ и есть бизнес, неотъемлемая его часть, зарабатывающая не деньги на покупку серверов, а вообще ВСЕ деньги для компании.
На этом этапе топ-менеджеры уже не могут «переводить стрелки» на сисадмина (или ИТ-менеджера) при невыполнении задач из-за неработающей электронной почты.
И у ИТ-менеджера метрики и KPI завязаны на результаты всей компании, а не только на uptime серверов. Это этап общей ответственности и понимания, что ИТ (информационные технологии) — это общий термин для бизнес-технологий.

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

Мария Каменнова , генеральный директор,
Андрей Коптелов , директор по ИТ-консалтингу,
"IDS Scheer/Логика бизнеса"

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

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

Стратегическое управление ИТ-подразделением

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

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

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

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

Преимущество внедрения BSC/ССП состоит в том, что ИТ-подразделение получает некую систему координат для организации действий в соответствии со стратегией и возможность последующего ее мониторинга при помощи ключевых показателей результативности - КПР (Key Performance Indicators, KPI).

При построении единой комплексной системы стратегического управления ИТ-подразделением следует учитывать накопленный опыт в области управления ИТ, творчески применяя его к каждой конкретной ситуации. Данный опыт сосредоточен в Библиотеке передового опыта организации ИТ (IT Infrastructure Library, ITIL).

Формирование целей ИТ-подразделения

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

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

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

Дерево целей дает четкое и связанное понимание направлений и логики развития ИТ-подразделения.

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

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

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

Стратегическая карта ИТ-директора

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

На стратегической карте цели распределяются по четырем перспективам (рис. 2) - точкам зрения на организацию, которые важны для оценки эффективности бизнеса.

Перспектива "Финансы" показывает ожидания бизнеса от ИТ-подразделения (как деятельность ИТ-подразделения повлияет на финансовое состояние всей организации).

Перспектива "Клиенты" отражает ожидания клиентов ИТ-подразделения (как деятельность ИТ-подразделения должна выглядеть перед его клиентами).

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

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


Рис. 3. Стратегическая карта ИТ-директора.

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

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

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

Взаимосвязь целей и ключевых показателей результативности

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

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

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

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

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

Например, достижение цели "Обеспечивать оптимальный уровень надежности и доступности ИТ-сервисов" (рис. 5) можно отслеживать с помощью следующих КПР, источником которых выступает информационная система:

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

Достижение данной цели зависит от выполнения проекта по разработке "Плана доступности" и от эффективности следующих процессов: "Управление инцидентами" и "Управление проблемами".

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

В результате внедрения системы стратегического управления с использованием BSC ИТ-подразделение получает следующие преимущества:

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

Совершенствование бизнес-процессов ИТ-подразделения

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

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

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

Описание процессов ИТ-подразделения происходит "сверху вниз": сначала определяются процессы верхнего уровня, т. е. деятельность подразделения описывается "крупными мазками", а далее они детализируются до уровня рабочих мест. Пример процессов верхнего уровня ИТ-подразделения приведен на рис. 6. Для выделения процессов верхнего уровня ИТ-подразделения могут использоваться так называемые референтные модели, а именно ITSM HP Reference Model (Hewlett-Packard), Microsoft Operations Framework (Microsoft), IT Process Model (IBM), ARIS ITIL Reference Model (IDS Scheer).

Основываясь на опыте проектов, можно выделить следующие процессы ИТ-подразделения:

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

При выделении процессов необходимо верифицировать цели и процессы, добиваясь их согласованности. Для каждой цели необходимы процессы, направленные на ее достижение, и каждый процесс должен быть направлен на достижение определенных целей в дереве целей.

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

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

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

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

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

В рамках совершенствования для каждого из рассматриваемых процессов определяют следующие параметры:

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

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

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

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

В то же время, помимо совершенствования процессов, необходимо регламентировать взаимоотношения между бизнесом и ИТ, что достигается разработкой "Соглашения об уровне услуг" (Service Level Agreement, SLA), которое регламентирует предоставляемые услуги в области ИТ и формализует требования к процессам на этапе их создания.

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

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

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

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

Под термином workflow понимается управление потоком работ и через него - бизнес-процессом. Согласно глоссарию международной организации Workflow Management Coalition (WfMC), workflow - это автоматизация, полная или частичная, бизнес-процесса, при которой документы, информация или задания передаются для выполнения необходимых действий от одного участника к другому в соответствии с набором процедурных правил. Автоматизация предполагает наличие набора правил, которые намного сложнее нарушить (умышленно или случайно), чем регламент или должностную инструкцию.

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

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

Вместо заключения

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

11 марта 2009 г. 09:20

Вероника Климентионок, консультант по управлению, консультационная компания «Украинский Имидж» (г.Киев)

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

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

Идея и необходимость описания бизнес-процессов

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

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

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

Подготовка компании к проекту по описанию бизнес-процессов

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

Цель

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

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

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

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

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

Обучение

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

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

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

Команда

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

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

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

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

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

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

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

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

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

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

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

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

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

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

План

Последний шаг в подготовке проекта по описанию бизнес-процессов - это планирование.

Сначала определяется структура работ, исполнители и необходимые трудозатраты. Затем делается календарная привязка и определяется длительность работ: в плане учитываются праздники, дни рождения босса, корпоративные выезды и командировки.

К примеру, на согласование модели бизнес-процесса надо всего-то 3 часа. С этой целью вы запланировали две встречи с Владельцем и Экспертами этого бизнес-процесса с перерывом в два дня. Длительность работ по согласованию модели бизнес-процесса составит 4 дня, но если в этот период Владелец бизнес-процесса уедет в командировку или возьмет несколько отгулов на празднование своего дня рождения, то длительность работ может существенно увеличиться. Конечно, помимо запланированных бывают и «внезапные» командировки, а для этого между работами проекта оставляется временной лаг. Это означает, что если длительность работ по согласованию модели бизнес-процесса составляет 4 дня, то перед началом следующей работы по формированию структуры процессного регламента надо оставить 1 резервный день. Когда такие лаги выставлены по всему проекту, то даже незапланированное отсутствие кого-то из участников проекта не повлияет на суммарную длительность проекта.

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

Бизнес-результаты проекта по описанию процессов компании

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

● повышению прозрачности деятельности компании;

● закреплению зон ответственности сотрудников компании;

● улучшению взаимодействия подразделений;

● решению проблемы «незаменимых сотрудников».

И если проект по описанию бизнес-процессов компании инициирует ИТ-подразделение, то достичь перечисленных результатов оно может только в тесном сотрудничестве и взаимопонимании с бизнесом. По этому поводу хорошее выражение прозвучало в выступлении Эдуарда Савушкина (корпорация «Инком») на съезде ИТ-директоров 2007 г. в Киеве: «Не бывает ИТ-проектов - бывают бизнес-проекты с вовлечением ИТ» .

Как выбирать персонал

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

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

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

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

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

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

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

Как измерять эффективность

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

На первом уровне , когда инвестиции в ИТ минимальны и основная финансовая составляющая – это зарплата сотрудников, эффективность ИТ-отдела можно оценивать по соотношению числа ИТ-сотрудников и общего количества работников компании. Приемлемой считается такая цифра: один ИТ-специалист на 50–80 человек, в зависимости от размера компании.
На втором уровне зрелости, когда стоимость ИТ-отдела начинает в большей степени определяться инвестициями в ИТ-технологии, имеет смысл ориентироваться на более комплексный показатель, такой как стоимость ИТ (люди + + технологии) в процентах от оборота компании. В этом случае для типичной не-ИТ-компании можно ориентироваться на цифру 1–3% от оборота. Для высокотехнологичных бизнесов сумма бывает больше.

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

Пирамида зрелости ИТ-отдела с учетом показателей эффективности его работы представлена на рис. 2.

Особенности больших компаний

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

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

  • Централизация.
  • Виртуализация.

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

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

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