От ИТ-проектов к информационным программам

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

Участники круглого стола
Александр Буйдов, директор департамента информационных технологий компании Крок
Леонид Винокуров, заместитель председателя совета директоров компании Техносерв А/C
Валерий Воробьев, заместитель директора по консалтингу и обучению "САП СНГ и страны Балтии"
Ростислав Рыжков, ведущий директор по специальным проектам компании Форс
Виктор Савицкий, заместитель директора систем управления компании "Сибинтек"
Борис Харас, управляющий консультант, IBM Business Consulting Services

От Intelligent Enterprise в круглом столе принимали участие
Константин Зимин, главный редактор Intelligent Enterprise
Сергей Костяков, заместитель главного редактора Intelligent Enterprise
Мария Шантаренкова, научный редактор Intelligent Enterprise

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Борис Харас: Вопрос, действительно важный. На мой взгляд, сегодня в России практически отсутствует культура ведения крупных проектов, в которых ключевой особенностью являлась бы тесная методическая интеграция процессов внедрения отдельных систем. Хотя, если выборочно анализировать отдельные ситуации, она все-таки появляется. На практике проблема выглядит следующим образом. Когда мы говорим о консолидации нескольких проектов, то цели и методы консолидации должны осуществляться на уровне бизнес-руководства. А на сегодняшний день в России они ведутся ИТ-подразделениями и во многом из за этого бывают не сильно связаны между собой. Даже в крупных компаниях, являющихся лидерами российского рынка. Проблема эта в целом типична не только для нас, и для ее решения предлагаются вполне определенные методические разработки, которые на западном рынке применяются достаточно широко. В том числе и компанией IBM.

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

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

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

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

Валерий Воробьев: Я также считаю, что сегодня в России надо в основном говорить про программы внедрения, имея в виду совокупность тех проектов, которые ведутся в компании, и в методическом плане пытаться объединять эти проекты (коль скоро потребность в интеграции проектов все равно есть) через программы. У нас в компании, например, уже полтора года существует такая позиция, как программный менеджер, в обязанности которого как раз и входит управление программами. И таких людей у нас сейчас порядка 15 человек. Ситуацию на местном рынке мы только что обрисовали, поэтому не могу сказать, что эти люди реализуют полноценные программы в режиме конвейера. Но, по крайней мере у каждого серьезного клиента, они видят внедрение не только SAP R/3, и даже не только совокупность проектов, а единую согласованную программу. Соответственно, они стремятся к тому, чтобы отдельные проекты не противоречили друг другу, а согласованно вели предприятие к достижению бизнес-целей.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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