Любой бизнес стремится к автоматизации, подразумевающей стандартизацию бизнес-процессов. Но, несмотря на огромное количество отраслевых разработок, все описать невозможно. При внедрении IT-систем всегда требуется внести дополнения. Но что делать, если в организации есть специфичные бизнес-процессы, создающие ее конкурентные преимущества? Или предприятие переживает период бурного роста? Такие компании зачастую решают не приобретать готовые программные продукты, а заказывают IT-решения «под себя». Всего, по данным IDC, в 2005 году они потратили на их разработку $231 млн.
Прихотливое ПО. Разработчики, со своей стороны, готовы как писать программы с нуля, так и создавать дополнительные функции в уже готовых системах. Первое обычно заказывают компании среднего и малого бизнеса. Второе — крупные предприятия, в деятельности которых есть нюансы, не включенные в функционал базовой системы. В таком случае «диагноз» о необходимости доработки может быть поставлен и самим вендором. Наконец, возможен вариант, когда бизнес-процесс невозможно автоматизировать, используя один типовой продукт. Тогда выгоднее создать новое программное обеспечение. «Типовые решения способны отразить индивидуальные бизнес-процессы даже внутри статичной компании только на 10%, — говорит директор компании «АйТи Сфера» Александр Осипов. — Предприятия малого и среднего бизнеса постоянно меняются. Добавляются новые механизмы, которые невозможно динамично отражать в типовом продукте». В результате приходится докупать новое ПО, возникают проблемы совместимости и обучения персонала. «При разработке систем под конкретного клиента во внимание принимаются любые требования и задачи, — размышляет Илья Зенин, исполнительный директор компании Crystal Development. — Заказчик в любой момент может внести коррективы». Разработка интегрируется с используемыми приложениями, закладывается возможность экспорта и импорта данных в популярные форматы, например Word или Excel.
Заказная разработка способна гибко реагировать на расширение бизнеса. Например, компания «Собикс», занимающаяся поставкой и внедрением систем безопасности и видеонаблюдения, заказала создание программного продукта для автоматизации документооборота и ведения клиентской базы. «Организация раньше использовала подобное типовое решение, — рассказывает генеральный директор «Собикса» Степан Баркасов. — Оно не предполагало поддержки удаленных клиентов и добавления новых функций». С развитием бизнеса эти ограничения переросли в существенное препятствие. Компания попросила разработчика сохранить интерфейс и схему работы, но сделать необходимые доработки. В результате через три месяца «Собикс» получил систему, которую при необходимости можно расширить благодаря доступности исходных кодов и документации. Степан Баркасов обещает, что в будущем его компания будет приобретать только заказное программное обеспечение.
При создании заказного решения сначала проводится анализ требований клиента. Затем предлагается несколько способов автоматизации бизнес-процессов и устранения «узких» мест. Заказчик выбирает подходящий вариант, далее составляется техническое задание, по нему пишется программа. Процесс завершается проведением серии тестов, по результатам которых судится о законченности и безотказности системы. В течение гарантийного срока компания-создатель бесплатно исправляет ошибки в программе.
Создание ПО с нуля влечет за собой некоторые неудобства. Это большее время на автоматизацию бизнеса, привязка к конкретному разработчику. Кроме того, затраты на поддержку уникального решения, как правило, выше, чем при обновлении типовой системы. Возможен шантаж со стороны уже обученного персонала. Однако права на использование нового продукта обычно переходят к заказчику. Возможен вариант уничтожения всей проектной документации, сопровождающей разработку, после завершения внедрения. В отдельных случаях заказчик, напротив, выступает за дальнейшие продажи своей программы, получая скидку на разработку.
Обычно «индпошив» дороже приобретения стандартного набора. Разница в цене может быть троекратной. Но лишь в том случае, когда бизнес-процесс можно автоматизировать с помощью одного типового решения. Если же процесс специфичен и для его автоматизации требуется сочетание нескольких типовых решений, то сумма вложений может превысить стоимость заказной разработки. Основанием для создания новой системы является эффективность автоматизируемых бизнес-процессов. Она должна превышать стоимость нового продукта.
Типовая доработка. Альтернатива заказному ПО — создание специфичных дополнений для ключевой системы. Если организация решила пойти по такому пути, то для начала необходимо определить оптимальное количество доработок. Далее создается методология решения задачи и утверждается техническое задание. После этого процесс плавно переходит в фазу конкретного исполнения. Стоимость доработок зависит от конкретных задач и требуемых для их решения ресурсов. «Суммы могут колебаться от $5 тыс. до $70 тыс. при создании новых функций», — рассказывает Илья Пантелеев, генеральный директор системного интегратора «АНД Проджект». Обычно доработки связаны с отраслевой спецификой компаний-заказчиков или с расширением межотраслевой функциональности. Значительная часть дополнений приходится на финансовый блок и связана с потребностью в более глубоком анализе информации.
Основными сложностями, подстерегающими исполнителя при написании доработок, являются уровень менеджмента, квалификация задействованного в проекте персонала и качество данных. Затруднения могут возникнуть и из-за недостатка общения разработчика с конечными пользователями системы. Например, если при постановке задачи разработчик контактирует только с топ-менеджментом, то почти со стопроцентной вероятностью при внедрении возникнет масса неучтенных нюансов. В результате они будут решаться либо административными мерами, либо доработками системы. Подобные изменения неминуемо увеличивают сроки и стоимость проекта.
Еще одну проблему называет начальник управления разработки и сопровождения ПО компании ОТР Георгий Суетин: «Большой сложностью разработки с нуля является риск неточной формулировки требований заказчика, — говорит он. — Только исходя из качественно проработанных требований подрядчик может оценить трудозатраты, спланировать срок и бюджет проекта». Главное наиболее точно и детально формализовать задачу. Для этого недостаточно согласовать с клиентом требования к интерфейсам, формам отчетов и алгоритмам. Необходимо проанализировать автоматизируемые бизнес-процессы и спроектировать организационно-технологическое решение, которое впоследствии будет реализовано на основе функционала приложения. «Трудности для исполнителя возникнут также в том случае, — рассказывает Павел Егорихин, директор по маркетингу компании «Микротест», — когда базовое решение содержит модули, которые должны интегрироваться с другими, ранее установленными информационными системами. При разработке этих блоков очень сложно получить от заказчика документацию. А если она и есть, то настолько неполная, что приходится самостоятельно исследовать приложение». Зачастую отсутствует площадка тестирования проведенной интеграции. Особенно если речь идет о каком-либо дорогостоящем приборе, с которого нужно получить, к примеру, измерительные данные.
В случае согласия заказчика компания-разработчик может в дальнейшем использовать созданные ею блоки при формировании собственных полноценных отраслевых и «горизонтальных» решений. При этом она будет самостоятельно поддерживать и переводить на новые версии. По словам Ильи Пантелеева, именно так и создаются наиболее емкие отраслевые решения. Это в свою очередь является конкурентным преимуществом продуктов разработчика. Системный интегратор может сертифицировать систему у вендора. Это позволяет включить IT-решение в международный каталог партнерских отраслевых и «горизонтальных» систем.
Журнал «Финанс.» № 21 (158) 5 июня – 11 июня 2006 — IT+финансы
Наталья Анищук
Подписывайтесь на телеграм-канал Финсайд и потом не говорите, что вас не предупреждали: https://t.me/finside.