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

Intellegent Enterprise: Наверное, и в вашей компании, применяющей западные методики управления, возникают проблемы взаимодействия подразделений? Как вы их решаете?

Игорь Ковалев: В Ford говорят, что у нас не бывает проблем, а только возможности проявить себя через "новые всплески активности, вызванные давлением обстоятельств" (challenges). Если говорить серьезно, то у каждого процесса, каждой ИТ-системы и продукта, который используется в нашей компании, есть два владельца: один со стороны ИТ-департамента, тот, кто знает эту систему и отвечает за ее поддержку и функционирование с точки зрения информационных технологий, и бизнес-владелец из подразделения, деятельность которого данная система автоматизирует. Это общая политика компании, которая не обсуждается, принимается всеми и действительно работает.

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

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

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

В проектировании ИТ-систем бизнес-подразделения тоже принимают участие?

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

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

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

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

Вы упомянули о выработке механизмов контроля. Для вас это отдельная задача?

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

Каким образом организована "обратная связь", ведь очень часто больше всего сил уходит не на создание чего-либо, а корректировку созданного?

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

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

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

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

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

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

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

Ford в России

Ford присутствует в России с 1907 года. Имеет офисы в Москве и Санкт-Петербурге. В 2004 продажи Ford Motor Company в России (брэнды бренды Ford, Volvo, Land Rover и Jaguar) составили 46 835 автомобиля. Действует завод во Всеволожске (Ленинградская обл.), в этом году компания инвестирует 50 млн. долл. в его дальнейшее развитие. ОоткрытОткрыт склад запчастей в Москве. Территория склада составляет полтора гектара,. Площадь хранения, занимаемая в данный момент Ford и Land Rover, — 9 700 кв.м. В этом году Ford планирует расширить свою партнерскую сеть до 120 дилерских компаний в 85 городах России.