|
Персональные инструменты |
![]() |
||
|
![]() |
![]() Многие тиражные продукты начинаются как заказные разработкиМатериал из CustisWikiВладимир Рахтеенко, генеральный директор ООО «Заказные ИнформСистемы».
Существует, образно говоря, два с половиной типа заказной разработки. Первый тип сейчас на слуху. Как правило, именно его имеют в виду, когда говорят о заказном ПО. Это офшорное программирование. При такой схеме разработчики экранированы от конечного заказчика. Они создают программное обеспечение (попутно заметим, что программное обеспечение — не то же самое, что программный продукт) по готовым спецификациям. Для этой модели нужно иметь хорошо отлаженную «фабрику кодирования», плюс устойчивый канал заказов. Взаимодействие с пользователем может быть минимальным или вообще отсутствовать. Второй тип — заказные проекты. Это более сложная модель, при которой компания-исполнитель непосредственно взаимодействует с конечным заказчиком от начала до конца проекта — от этапа постановки задачи до пуска в промышленную эксплуатацию и далее — на всем протяжении жизненного цикла системы. Мы занимаемся именно этим типом заказной разработки. Наконец, еще один — «половинчатый» тип — фактически заказная разработка под вывеской внедрения тиражного решения. К этому типу относится значительное число известных и не очень известных проектов внедрения формально тиражных систем на российском рынке. То есть сделка заключается на поставку готового продукта, но на деле стоимость услуг по его «докручиванию» в разы превышает стоимость лицензий. Мы специализируемся на заказных проектах. В соответствии с этой моделью мы работаем в финансовом секторе, в торговых сетях. У нас в портфеле есть и тиражные решения, например, в области коммунального биллинга и социальной сферы. Но, поскольку мы трезво сознаем всю сложность ситуации в этих отраслях, мы предпочитаем называть свои решения «малотиражными» несмотря на успешный опыт прошлых внедрений. Это означает, что в каждом конкретном случае мы допускаем возможность достаточно радикального реинжиниринга предлагаемого решения в соответствии с требованиями нового заказчика.
Представим себе, что разработка тиражной системы идет с нуля или имеет небольшой задел. Компания-разработчик должна спрогнозировать спрос на тот или иной функционал, вложиться в разработку и через полтора-два года получить конкурентный продукт. В современных условиях лаг в два года — это немало. Цена ошибки велика, но основные риски несет компания-разработчик. Неправильно спрогнозировали спрос, плохо запроектировали — внедрения будут тяжелыми, расходы на продвижение высокими, а клиенты недовольными. Зато с производственной точки зрения создание тиражного решения является более управляемым. Процессы в нем разделены: техническое задание, кодирование, тестирование и т. д. следуют графику каскадного типа. Клиент не вмешивается в процесс разработки, а «интерфейсы» между специалистами внутри компании могут быть более формальными, можно сказать бюрократическими. В заказной разработке технологические этапы тоже должны быть четко выделены, но дистанция между ними меньше. Создание системы происходит итеративно, и все основные этапы присутствуют почти в каждой итерации. Часть рисков переходит на заказчика, и это является платой за индивидуальный подход, за возможность влиять на постановку задачи, за автоматизацию его конкурентных преимуществ, а не общеизвестных подходов, которые спокойно могут работать и на коробочном решении. Кроме того, в начале проекта надо не столько прогнозировать направление развития отрасли, сколько прояснить стратегию предприятия на ближайшие годы.
Задача исполнителя в заказном проекте — добиться утверждения более или менее формальной процедуры работы с требованиями, чтобы не быть погребенным под их массой. Думается, немало технически грамотных и талантливых команд было развалено только из-за неумения работать с требованиями в условиях заказного проекта. Отсюда же происходят многие разочарования у клиентов, буквально начинающих душить в объятиях подрядчика, убедившись в его способности выдавать «на гора» работающие решения. Как мы видим, отчасти такой неконтролируемый поток требований возникает именно тогда, когда менеджеры клиента убеждаются, что «это работает». Возникает естественное желание «выжать» по максимуму. Еще одной, более банальной причиной развала проекта может послужить незаинтересованность менеджеров заказчика в результатах проекта. Если оставить в стороне случаи саботажа или головокружения от успехов, то следует обозначить основную, фундаментальную причину сложностей комплексной автоматизации предприятия. Индустрия информационных технологий все же относительно молода. И если с подготовкой ИT-специалистов в наших вузах все обстоит далеко не блестящим образом, то в плане преподавания информатизации экономическое и бизнес-образование делают только самые начальные шаги. Хотя классики, вроде Фреда Брукса, еще в 70-е годы описали особенности создания программных решений в терминах инженерных систем, многие управленцы не допускают мысли о том, что корпоративная система — это такое же сложное техническое сооружение, как, например, современное офисное здание. Вряд ли у кого-нибудь в здравом уме возникнет идея вынуть, между делом, из офисного здания шахту лифта или заменить фундамент. Но в отношении сложных информационных систем такие инициативы возникают у заказчиков сплошь да рядом. Неудивительно, что система становится похожей на многоквартирный дом, где владельцы квартир (руководители подразделений) ломают несущие конструкции и ставят себе какие-нибудь джакузи. То же самое относится к сопровождению. Все понимают, что дома, мосты и даже телеграфные столбы нуждаются в техническом обслуживании и ремонте. Но в отношении программного обеспечения опытные, казалось бы, люди ожидают чуда — чуда бесконечной идеальной работы без вмешательства специалистов сопровождения и невзирая на любые ошибки пользователей. Иногда это непонимание связано с тем, что люди не различают программное обеспечение разного уровня сложности и не видят разницы, к примеру, между почтовым клиентом и системой класса ERP. Можно сказать, что мы имеем дело с недостатком просвещения. Такие вещи нужно преподавать в институтах и бизнес-школах. Потому что когда об этом говорит разработчик, неподготовленный клиент воспринимает его слова как саморекламу и повод для раздувания стоимости услуг. И чем более искушенной является та или иная отрасль в вопросах автоматизации, тем меньше там возникает подобных вопросов.
На начальном этапе бывает трудно согласовать с клиентом стоимость сопровождения. Это происходит не только в силу известной сложности торговых переговоров, но еще и потому, что стоимость сопровождения, как правило, определяется в процентах от стоимости лицензий. Но в заказной разработке, по предложенному нами определению, основной акцент делается на услуге, а не на лицензиях. Трудно, иногда невозможно спрогнозировать направление «дрейфа» заказного решения на протяжении жизненного цикла, предсказать объем доработок. Именно поэтому так просто ошибиться со стоимостью сопровождения. Будучи утверждена на начальном этапе, когда будущие параметры и масштабы системы еще не полностью видны, она часто бывает неоправданно занижена. Заниженная стоимость сопровождения грозит развалом системы индивидуального сопровождения, что создает для клиента высокие риски. В этой связи хорошей практикой является перенос даты заключения договора о сопровождении на более поздние сроки — ближе к этапу опытной или промышленной эксплуатации. На этапе промышленной эксплуатации тема сопровождения заказного решения становится менее актуальной. Но не потому, что сопровождение не важно (совсем наоборот), а потому, что заказчик уже хорошо чувствует не предполагаемое, а реальное место информационной системы в управлении бизнесом. Он может правильно оценить критические точки системы, определить минимально необходимые режимы поддержки и обозначить потребность в развитии. В некоторых случаях, если речь идет о динамичном бизнесе или отрасли, слово «развитие» становится для заказчика более актуальным, чем слово «сопровождение».
Но бизнесу нужно двигаться дальше. Возникают новые задачи, появляется необходимость пересмотреть способы решения старых проблем, в процесс автоматизации включаются новые виды деятельности. И тогда на передний план снова выходит заказная разработка, с ее чуткостью к проблемам «пионеров» автоматизации и способностью обеспечить динамику развития. Место найдется для всех. Важно только вовремя диагностировать класс задачи и правильно выбрать решение.
В малотиражных решениях приоритет принадлежит коммунальному биллингу (система «Радей»), автоматизации социальной защиты населения (система «Радей-Соцзащита»), а также новому решению для финансовых компаний — CustIS General Ledger, XML edition.
Второй блок задач заключается в том, чтобы находить и поддерживать правильное соотношение между заказными и тиражными проектами. Сбалансированный портфель из индивидуальных и типовых заказов позволяет поддерживать креативные качества команды и, в то же время, использовать преимущества масштаба. Третий по счету, но не по значению, блок задач направлен на развитие партнерской сети. Мы постоянно ищем возможность установить взаимовыгодные отношения с теми компаниями, которые не конкурируют, а дополняют наши услуги, будь то системные интеграторы, поставщики оборудования или разработчики базового ПО. Важным элементом этой стратегии является обучение региональных технических центров, способных не только поддерживать наши решения, но и внедрять новые.
Ссылки
Внимание! Данная статья выбрана для репликации во внешнюю базу знаний компании. Пожалуйста, не допускайте в этой статье публикацию конфиденциальной информации, ведения обсуждений в теле статьи, и более ответственно относитесь к качеству самой статьи — проверяйте орфографию, пишите по-русски, избегайте непроверенной вами информации. |
![]() |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
![]() |
![]() |