Просмотр исходного текста страницы Многие тиражные продукты начинаются как заказные разработки

[[:Категория:Владимир Рахтеенко (Статьи)|Владимир Рахтеенко]], генеральный директор ООО «Заказные ИнформСистемы».

<blockquote>
«Многие тиражные продукты начинаются как заказные разработки»
<ref>[http://www.cnews.ru/reviews/free/software2005/int/custis/ Обзор-интервью] на сайте CNews («Рынок корпоративного ПО-2005»).</ref>
</blockquote>

{{question}} ''Как бы вы охарактеризовали ключевые отличия заказного ПО от тиражного?''

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

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

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

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

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

{{question}} ''Можно ли, на ваш взгляд, сравнить заказные и тиражные системы по характеристикам жизненного цикла?''

{{note}} Да, и здесь можно увидеть достаточно наглядные различия. Цикл жизни тиражной системы более четко делится на этапы. Конечно, идеальный тип найти трудно. В действительности, многие тиражные продукты начинаются как заказные разработки.

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

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

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

{{question}} ''Насколько сложнее, из вашей практики, стоятся отношения с заказчиком при разработке на заказ? Какие ключевые риски связаны с подобными проектами?''

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

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

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

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

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

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

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

{{question}} ''Как, из вашей практики, решаются вопросы сопровождения в рамках заказных проектов?''

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

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

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

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

{{question}} ''Заказным разработкам, очевидно, трудно конкурировать с тиражными решениями — в исполнении они сложнее, эффект масштаба отсутствует, да и клиента проще привлечь, имея на руках готовый продукт. Можно ли говорить о постепенно вытеснении подобных проектов с рынка?''

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

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

{{question}} ''Какие направления разработки являются сегодня для вас приоритетными?''

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

В малотиражных решениях приоритет принадлежит коммунальному биллингу ([http://www.radey.ru/html/index.htm система «Радей»]), автоматизации социальной защиты населения ([http://www.radey.ru/html/radey-social.htm система «Радей-Соцзащита»]), а также новому решению для финансовых компаний — [http://www.custis.ru/html/gl-xml-edition.htm CustIS General Ledger, XML edition].

{{question}} ''Каковы ваши планы по развитию бизнеса в ближайшие годы?''

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

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

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


== Ссылки ==

<references />

[[Категория:Владимир Рахтеенко (Статьи)]]
[[Категория:2005 год (Статьи)]]
[[Категория:CNews (Публикации)]]

[[Категория:Технологии разработки ПО (Статьи)]]

{{replicate-from-custiswiki-to-lib}}