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

Intelligent Enterprise: Ваша компании имеет уже сложившуюся инфраструктуру автоматизации бизнеса. Что для вас означает информационный проект, и каковы ключевые моменты, связанные с подготовкой к его реализации?

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

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

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

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

У нас на предприятии существует специально выделенная группа специалистов, называемая Business Process Support (всего в компании их около 30 человек, из них 10 работают в России). Она по большей части сформирована из людей, ранее работавших с информационными бизнес-системами. Постоянно ведя работы по автоматизации, эти люди более, чем другие ИТ-специалисты, углубились в различные функции бизнеса и, по сути, стали экспертами по тем или иным его направлениям. Собственно по этому признаку и происходит "селекционный отбор" сотрудников в указанную группу. Члены этой группы на этапе подготовки технического задания формируют представление о будущем процессном решении проблемы, учитывая возможности той системы, которая внедряется на предприятии. При развертывании нового ИТ-проекта они также могут и должны адекватно учитывать особенности тех решений, которые были применены ранее. Этих людей, если кому так удобнее, можно назвать бизнес-аналитиками или внутренними консультантами. Главное здесь - суть их работы.

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

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

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

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

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

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

Следующим "пунктом" подготовки у нас, кажется, была оценка рисков…

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

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

У нас с вами остался нерассмотренным еще один вопрос: каков ваш подход к оценке стоимости проекта? Какие приемы оценки, предшествующие проекту, вы применяете?

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

Предпроектная оценка целесообразности проведения проекта у нас всегда ведется по классическим параметрам - по величине чистой приведенной стоимости проекта NPV (Net Present Value), а также по сроку окупаемости. Другое дело, что для небольшого числа наиболее стратегически важных проектов величина NVP может быть малой, а то и вовсе отрицательной. Но их оценка все равно проходит по стандартной процедуре.