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

Вопрос: какой вариант лучше?

Давайте сделаем небольшое отступление и взглянем на суть проблемы. Рассмотрим следующую упрощенную схему.

Данный экземпляр ПО может варьироваться от купленного в магазине готового программного пакета (commercial off-the-shelf, COTS) — скажем, такого, как Microsoft Word, — и до созданной на заказ написанной с нуля программы. Между этими двумя крайностями можно назвать адаптированные и (или) сконфигурированные коммерческие пакеты, заказные программы, созданные с использованием коммерческих платформ и библиотек, а также сложные прикладные системы, включающие всё из перечисленного. Как показано на рисунке, эта ось кастомизации от низкой до высокой обычно прямо коррелирует с тремя другими параметрами: стоимостью, пригодностью для потребностей заказчика и временем до внедрения.

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

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

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

А теперь давайте вернемся к нашему вопросу: какой вариант лучше? Покупать или писать заново? Очевидно, выбор того или иного подхода будет определяться факторами, перечисленными выше, а именно стоимостью, пригодностью для потребностей заказчика и временем до внедрения. Но конечно же могут быть ситуации, когда готовое коммерческое ПО просто отсутствует, так что у вас нет иного выбора, кроме как писать самому. А если выбор всё же есть (как в ситуации, описанной в начале статьи), то можно предложить очень полезное правило, которое учитывает ваши потребности:

  • покупайте, если система служит основой ведения вашего бизнеса;
  • создавайте сами, если система даст вам преимущество перед конкурентами.

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

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

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

Всё это стоит иметь в виду.