Причины не кодировать программу?

Question

Давайте сыграем адвоката дьявола: по каким причинам вы бы дали руководству НЕ кодировать решение, а приобрести дорогой пакет?

Answer 1

Однократная внутренняя разработка может быть оправдана заменой программного обеспечения для подписки, т. Е. Разовая стоимость разработки в 2 раза может быть оправдана для замены годовой подписки X, если у вас есть доступный ресурс для разработки. Это также может означать, что окончательное решение точно соответствует потребностям бизнеса, в то время как стороннее решение может не соответствовать точно или требовать дополнительной поддержки или обходных путей. Это относится к проектам, над которыми я работал в прошлом году или два, с преимуществом, что новая система является более точной и, следовательно, привела к требованию меньшего количества людей поддержки. Да, хорошее программное обеспечение делает людей лишними.

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

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

Answer 2

Некоторые причины

• Решение не поддерживает основной бизнес-процесс, но товарный процесс , такой как финансы, управление персоналом, управление объектами, где вы ничем не отличаетесь от своих конкурентов (ваши основные / неосновные процессы будут отличаться!) , Ваши навыки внутреннего развития лучше использовать для создания и поддержки решений, которые дают вашей компании конкурентное преимущество.
• Первое применяется в пиках, если решение не нуждается в сильной интеграции с вашими существующими или будущими решениями (оно поддерживает относительно изолированный процесс).
• Нет необходимости в бюджете и персонале для обслуживания в течение всего жизненного цикла разработанного собственными силами приложения. Цифры меняются, но одна цифра, которую я видел и нахожу вполне правдоподобной, состоит в том, что первоначальные затраты на разработку пользовательского приложения составляют всего одну десятую от общей стоимости жизненного цикла . Конечно, это включает в себя такие вещи, как обучение конечных пользователей, модернизация O / S и интеграция, что также затрагивает решение, приобретенное извне, но 10-кратный коэффициент первоначальной цены заставит большинство руководителей взять паузу.
• Особый случай первого: навыки для разработки, обслуживания и эксплуатации могут отсутствовать или стать узким местом в вашей организации. Каждый недостаток навыков может быть заполнен достаточным количеством времени и денег, но не обязательно в приемлемых пределах. Каждое дополнительное технологическое умение, которое необходимо приобрести вашим сотрудникам, означает меньше времени на развитие и поддержание существующих навыков: стоимость умений в разнообразном техническом ландшафте растет более чем линейно ...
• Как, например, Питер утверждает: предсказуемо , но высокие затраты могут превзойти риски, связанные с началом проекта разработки, в бизнесе, где перерасход средств в 20% часто считается успешным проектом, в то время как неудачные проекты в основном не имеют ограничений ...
• Как замечает и Ватин: коммерческое программное обеспечение может иметь сейчас , задерживается только из-за установки и обучения конечного пользователя. Конечно, установка чего-то вроде SAP не будет сделана за один день ...

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

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

Answer 3

Если бы вы собирали свой собственный автомобиль с нуля, это, вероятно, было бы очень дорого и совершенно нереально, но если бы вы купили готовый автомобиль, это, вероятно, было бы намного дешевле и было бы намного более реалистичным.

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

Answer 4

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

• Недостаток знаний и опыта в организации
• Недостаток рабочей силы для быстрой адаптации к изменениям рынка или законодательства (налогообложение)

Преимущества аутсорсинга:

• Более легкий бюджет
• Нет необходимости нанимать, обучать персонал
• Возможность иметь жесткие контракты на обслуживание

Answer 5

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

Answer 6

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