Нередко можно слышать, что заказная разработка ПО для предприятия менее выгодна, чем покупка готового бизнес-приложения (или ERP-системы), поскольку в готовом продукте затраты на его создание распределяются на множество покупателей, а при заказной разработке один клиент оплачивает ее полностью. С другой стороны, необходимость тщательной настройки “готового приложения” практически в каждом проекте внедрения свидетельствует о том, что, купив коммерческий пакет ПО, заказчик все равно вынужден заниматься его доработкой. Есть ли место для заказных разработок на высококонкурентном российском рынке ERP? Об этом научный редактор PC Week/RE Сергей Свинарев беседует с генеральным директором компании CUSTIS Владимиром Рахтеенко.

PC Week: Каковы, на ваш взгляд, достоинства и недостатки этих двух моделей построения систем управления предприятием?

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

Нередко говорят о том, что уникальные процессы можно реализовать и в готовом коммерческом решении, используя его инструментальные средства. На таком пути заказчика ждет множество опасностей. Люди, занимающиеся доработкой, как правило, не представляют себе в полной мере ИТ-архитектуру готового продукта и поэтому могут породить множество проблем, которые начнут проявляться по мере усложнения системы. А усложнение — это обычная практика: у нас есть одно заказное приложение, функциональность которого по просьбе заказчика за шесть лет была расширена в 15 раз. Чтобы такая скорость была возможна, приложение не должно содержать ничего лишнего, нередко закладываемого вендором “на всякий случай”. Мы с этой целью иногда прибегаем к так называемой “управляемой санации” своих приложений: к удалению по согласованию с заказчиком избыточных или отживших своё функций. Что же касается коммерческого продукта, то для реализации необходимой заказчику функциональности иногда необходимо вносить исправления на уровне ядра, но если это будет сделано, вендор снимает с себя ответственность за безошибочное функционирование своей системы.

PC Week: Как распределяются затраты на создание и сопровождение бизнес-приложения на протяжении всего его жизненного цикла в том и в другом случае?

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

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

PC Week: Насколько снижает объем необходимых доработок ПО рост числа так называемых отраслевых решений, построенных на базе коммерческих ERP-систем?

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

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

PC Week: Чем должен руководствоваться заказчик, принимая решение, покупать ли ему тиражный продукт или заказывать разработку приложения? Кто ему может помочь в этом выборе?

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

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

PC Week: Какие дополнительные требования на ИТ-департамент заказчика накладывает развертывание у него заказного, а не тиражного ПО?

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

PC Week: Спасибо за беседу.