Разработка или покупка ПО в ОАЭ: корпоративное программное обеспечение

Бизнесу в ОАЭ, решающему, разрабатывать или покупать корпоративное ПО, стоит смотреть дальше первого релиза и спрашивать, кто всё ещё будет управлять системой через три года. Покупка выводит рабочую систему перед сотрудниками быстрее и перекладывает патчи, обновления и поддержку на кого-то другого. Разработка даёт рабочий процесс, построенный точно под то, как бизнес на самом деле работает, ценой того, что каждое будущее решение о нём придётся принимать самостоятельно. Большинство компаний, которые делают этот выбор правильно, оказываются где-то посередине: купленная платформа, которую действительно расширяют, а не разработка с нуля и не неизменённый продукт из коробки.

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

Разработка или покупка ПО в ОАЭ: короткий ответ

Для большинства компаний в ОАЭ практичная отправная точка, это купить платформу, построенную под общую форму задачи, будь то ERP, CRM или система бронирования, а затем решить, насколько сильно её на самом деле нужно расширять. Полноценная индивидуальная разработка окупает себя только тогда, когда рабочий процесс достаточно специфичен и достаточно ценен, чтобы ни одна платформа не подходила близко, и когда бизнес готов владеть этим ПО столько, сколько будет им пользоваться. Всё остальное в этом руководстве, по сути, один длинный ответ на единственный вопрос: на какой стороне этой черты находится ваш проект. Задать вопрос, разрабатывать или покупать ПО, до начала проекта, а не после демонстрации у поставщика, это то, что на самом деле экономит время позже.

Вопросы, которые на самом деле решают выбор между разработкой и покупкой

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

• Насколько существующая платформа близка к сегодняшнему рабочему процессу без тяжёлой кастомизации.
• Действительно ли процесс, который поддерживает ПО, отличается от того, как ту же функцию ведут конкуренты, или он просто ощущается иначе, потому что так было заведено всегда.
• С каким числом других систем этому ПО нужно обмениваться данными сейчас и в ближайшие два года.
• Кто внутри бизнеса или какой именованный партнёр останется ответственным за эту систему после того, как человек, заказавший её, уйдёт.

Для бизнеса в ОАЭ ответ «не очень близко», «действительно иначе» и «мало других систем», это реальный довод в пользу разработки, а не покупки. Бизнес, отвечающий противоположным образом на большинство этих вопросов, скорее всего, покупает и расширяет платформу, каким бы ни было первоначальное чутьё в комнате.

Совокупная стоимость владения простыми словами

Совокупная стоимость владения, это просто все затраты, которые ПО создаст за весь срок своей работы, а не только стоимость первой версии. Для системы, которую бизнес планирует купить или разработать, этот список обычно включает:

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

Купленное ПО обычно перекладывает несколько этих затрат на поставщика в обмен на регулярную плату и меньший контроль над планом развития. Разработанное ПО обычно возлагает все эти затраты на бизнес в обмен на рабочий процесс, который подходит точно, и план развития, который бизнес контролирует сам. Ни один из этих компромиссов не бесплатен, поэтому «мы уже платим за лицензию» и «мы уже заплатили разработчику», оба неполные ответы на вопрос, во что на самом деле обходится владение системой. Совокупная стоимость владения, это честный способ сравнить варианты разработки или покупки ПО для бизнеса в ОАЭ, что особенно важно на местном рынке, потому что она ставит обе стороны на одну временную шкалу, вместо сравнения лицензионной платы с разовым счётом.

Настоящая стоимость корпоративного ПО не в том, что нужно, чтобы его разработать или купить. Она в том, что нужно, чтобы поддерживать его работу после того, как человек, выбравший его, ушёл.

Интеграция: часть, которую чаще всего упускают при выборе разработки или покупки

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

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

Риск выхода при покупке: жизненные циклы платформ и решения поставщиков

Покупка не убирает риск, она меняет его форму. Это компромисс, на который бизнес соглашается в момент, когда выбирает покупку, а не разработку ПО: поставщик платформы контролирует собственный график релизов, и старые интерфейсы в итоге перестают поддерживаться по расписанию поставщика, а не по вашему. Собственная документация разработчика Salesforce утверждает, что каждая версия API поддерживается минимум три года с момента выпуска, с уведомлением как минимум за год до того, как более старая версия будет объявлена устаревшей, и что любой запрос к снятой с поддержки версии просто возвращает ошибку. Это разумная, чётко опубликованная политика, и одновременно реальное ограничение для планирования: интеграция, построенная на купленной платформе, должна поддерживаться в соответствии с жизненным циклом этой платформы, а не оставаться неизменной.

Та же логика применима к кастомизации. Собственные рекомендации Microsoft по Dynamics 365 проводят чёткую границу между расширением платформы через её документированные точки расширения и инвазивными изменениями того, как ведёт себя ядро продукта, предупреждая, что именно инвазивная кастомизация, главная причина, по которой стоимость обновлений остаётся высокой с течением времени. Бизнес в ОАЭ, который покупает платформу, а затем сильно изменяет её ядро вместо того, чтобы расширять её через поддерживаемые поставщиком пути, в итоге несёт значительную часть нагрузки по обслуживанию, как при индивидуальной разработке, продолжая при этом платить за ПО, которое изначально пытался купить, а не разработать.

Риск выхода при разработке: кому это принадлежит, когда разработчик уходит

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

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

Рабочий чек-лист для бизнеса в ОАЭ, взвешивающего разработку или покупку

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

1. Запишите рабочий процесс таким, каким он реально работает сегодня

   Не идеализированную версию, а ту, которой сотрудники действительно следуют, включая исключения и обходные пути.

2. Проверьте, насколько близка существующая платформа

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

3. Составьте список каждой системы, с которой должно общаться это ПО

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

4. Решите, кто владеет системой на протяжении всего срока её работы

   Назовите человека или партнёра, ответственного за неё после запуска, а не только того, кто её разрабатывает или покупает.

5. Сравните два риска выхода напрямую

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

Чем может помочь Digital Marketing Dubai

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