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

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

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

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

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

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

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

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

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

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

Правильный дизайн проекта

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

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

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

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

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

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

Техническая архитектура

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

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

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

Разделение ответственности

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

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

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

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

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

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

Управление изменениями

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

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

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

Связь культур

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

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

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

Овчинка стоит выделки

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

Судхи Синха (Sudhi Sinha) — консультант по системам предприятия в компании Tata Consultancy Services (http://www.tcs.com). Специализируется во внедрении многоуровневых BI- и ERP-систем. С ним можно связаться по e-mail: sudhisinha@hotmail.com.