Unicum ad Unicus

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

О тиражном ПО сказано достаточно много, его преимущества хорошо известны и подтверждаются реальными примерами успешных проектов. Заказчик получает в свое распоряжение мощное и гибкое решение надежного вендора, доступ к best practice в сфере своего бизнеса, набор стандартных бизнес-процессов и избавлен от необходимости самостоятельно развивать приложение. С каждым годом на рынке появляется все больше отраслевых решений, которые учитывают нюансы конкретных сфер бизнеса, настроечный аппарат систем становится все более гибким. Где же в этом многообразии предложений место заказной разработке? По мнению Алексея Потапенко, генерального директора компании E-Style Software House, «заказная разработка не конкурирует с тиражным ПО. Если мы видим, что бизнес-задача заказчика лежит в области стандартных решений и может быть в полной мере удовлетворена тиражным ПО, мы не беремся за разработку. Но если компания хочет на общем фоне стандартных процессов выделиться, вывести на рынок продукт или услугу, обладающие уникальными свойствами, ей необходимо уникальное ИТ-решение. У тиражного решения можно научиться мастерству, отточить умение вести бизнес в соответствии с лучшими бизнес-практиками. Но свободное творчество, создание принципиально новых бизнес-практик возможно только с заказным ПО».
К заказным разработкам компании могут обращаться в нескольких случаях. Во-первых, когда стандартный функционал тиражного продукта, который уже эксплуатируется в компании, не в состоянии поддерживать уникальные особенности бизнеса. Во-вторых, если изменения, которые необходимо внести в стандартный функционал эксплуатируемого решения для реализации новых задач бизнеса, потребуют слишком много времени. В этом случае заказчики идут на своеобразный эксперимент: быстро внедряется заказное ПО, и если оно соответствует задачам бизнеса, его либо интегрируют с другими системами, либо реализуют этот функционал в уже существующей масштабной системе. И, наконец, третий случай — когда на рынке нет тиражного решения, соответствующего задачам заказчика.

Возрастной ценз

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

«Сегодня довольно много организаций объявляет конкурсы на разработку приложений. Беда в том, что зачастую это недостаточно зрелые организации, — отмечает Мария Анчеева, директор по продажам E-Style Software House. — Им необходимо не только приложение, но и широкий спектр консалтинговых услуг, которые должны быть выведены в отдельный проект. Желание создать систему есть, но ни четкого понимания собственных проблем, ни модели бизнес-процессов пока нет. Находятся разработчики, которые берут на себя смелость реализовать проект в условиях, когда ни они, ни заказчики до конца не понимают целей проекта. В этом случае велик риск создания нежизнеспособной системы. Заказчик должен естественным путем достичь определенного уровня зрелости, и поставщик решения при всем желании не сможет ускорить созревание заказчика в ходе проекта. Такой проект будет провальным.

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

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

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

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

Что такое хорошо и что такое плохо

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

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

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

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

Домашний доктор

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

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

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

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

Поэтому одна из важных задач разработчика — продемонстрировать заказчику потенциал совместного сотрудничества. Большие компании — поставщики ИТ-решений иногда представляют собой «государство», в котором нередко царит междоусобица. Отдел продаж нацелен на получение денег от клиента, отдел производств — на внедрение проданного. Получается, что «к пуговицам претензий нет, но за качество никто не отвечает». Конечно, это несколько утрированное видение, но в нем есть большая доля правды. Небольшая компания-разработчик более мобильна — она может уже на этапе продаж подключить к обсуждению будущего решения сотрудников производственного отдела, чтобы они поняли требования заказчика, причем не только функциональные и технологические, но и к управлению проектом, выявили бы и оценили потенциальные риски. Нередко бывает, что изначальные требования заказчика невозможно реализовать в предполагаемые им сроки. Возникает необходимость расстановки приоритетов требований, поиска баланса между желаемым и возможным. Таким образом, уже на этапе переговоров начинается совместная работа над определением целей проекта, постановкой задачи и оценкой ресурсов. «На этапе реализации проекта небольшая мобильная компания может предложить гибкую методологию совместной работы над приложением, с учетом пожеланий заказчика, — рассказывает Алексей Прохоров, руководитель производственного отдела E-Style Software House. — Мы стараемся всегда идти навстречу заказчику. В тех случаях, когда заказчик выдвигает требования, которые грозят срывом сроков проекта или снижением качества, мы стараемся найти разумный компромисс. Если заказчик и исполнитель нацелены на результат, то решение, которое устраивает всех, найти всегда можно. Реальные сложности возникают, когда с помощью внедрения автоматизированной системы заказчик пытается решить какие-то внутренние конфликты и противоречия между своими подразделениями и отдельными сотрудниками».

Мода будущего

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

Другим сдерживающим фактором является отсутствие «моды» на внедрение заказных разработок. С политической точки зрения ИТ-директору выгоднее внедрить известное дорогостоящее решение, чем использовать заказную разработку. Это работает на имидж компании. Сэкономить, внедрив заказную разработку, значит, в некотором роде, сыграть против правил рынка. Это противоречит личному карьерному росту ИТ-директора: надо обладать достаточной смелостью, чтобы предложить бизнесу заказную разработку. «Моды на экономию пока нет, — говорит Алексей Прохоров. — Если провести аналогию с одеждой, то сегодня бренд костюма играет бо,льшую роль, чем его соответствие фигуре. Поэтому компании предпочитают приобретать продукцию SAP, Oracle, Microsoft — предложения дорогостоящих брендов мирового уровня, хотя известная узкому кругу компания-разработчик может создать менее дорогостоящее решение, гораздо более соответствующее потребностям бизнеса».

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

http://www.cio-world.ru