让我们扮演魔鬼的拥护者：您不让管理层编写解决方案，而是购买昂贵的软件包的原因是什么？
问问题
954 次
16 回答
25
- 买进更便宜。
- 如果现有开发人员不熟悉该域
- 如果风险水平高得无法接受
- 时间紧迫性。
尽管在一天结束时，一切都以某种方式归结为第 1 点。
于 2009-04-17T11:05:47.223 回答
11
简单的; 当您自己编写的总拥有成本 ( TCO ) 大于软件包的 TCO 时购买。（如何可靠地计算出自己编写的 TCO 是留给读者的练习 ;-)）
没那么简单; 当软件是你的核心业务，或者当软件是一个独特的卖点时，DIY。你不想外包你的大脑或心脏。
于 2009-04-17T11:04:36.337 回答
2
已经存在一个非常相似的程序。除非您是出于娱乐/学习目的而这样做
于 2009-04-17T11:05:32.187 回答
2
购买组件的优势： - 购买它可能比开发它更便宜 - （在某些情况下）团队不知道如何开发该组件。因此，收集该专有技术的时间令人望而却步 - 维护成本转移给了供应商
缺点 - 无法控制组件的生命周期（包括何时发布新版本，应该进行哪些修复等） - 可能需要适应/集成工作。- 由于集成问题，它可能会引入性能惩罚。
于 2009-04-17T11:17:43.297 回答
2
我见过很多这样的例子，我认为它分为两半。首先，您的“商品”软件——消息传递中间件、数据库等——通常总是被购买。我永远不会坐下来编写自己的异步消息传递系统，除非那绝对是我业务的核心。其次，还有增值部分，我认为是比较不同的。
我从事金融工作，有一些供应商系统（例如 Murex、Summit 和 Sophis）为各种金融市场产品执行风险/预订/后台功能。我认为选择这些是危险的，原因有两个。
第一个原因是您在软件方面并没有进一步领先于您的竞争对手，您没有增加自己的价值，所以就您可以收取的价格或价格而言，它只是一场“竞相”你可以承担的风险。
第二个原因，从软件开发人员的角度来看更重要的是，虽然供应商的系统现在可能适合您，但可能在两三年后不适合您。如果您在此基础上建立了自己的业务，但它突然发生了变化——或者在您需要时没有变化——您可能会被抛在脑后。或者，如果公司破产或想要退出市场，您有两种选择 - 购买它，或者从头开始重新编写您的所有系统。
我已经数不清有多少公司拼命尝试关闭增值供应商系统（典型的例子是 Murex、Sophis、Summit ......见上文 :) 并编写自己的系统。
反对供应商系统增值的补充论点是顾问/承包商通常要贵得多。可以在这里以每天 x00 英镑的价格聘请高级 c# 顾问。具有供应商系统经验的顾问将增加约 20-25%。
于 2009-04-17T11:27:39.793 回答
2
我会给他们真正的原因（假设我在一家我真正想工作的公司，也就是说，而不是被 PHB 奴役）。通常这是“如果我有这个，我会更快地完成我的工作，我的时间对你来说很有价值”。
但更有帮助：如果问题是“什么时候出现你想为软件付费的情况？”，那么：
- 当有问题的软件不是公司赚钱的核心竞争力时。在非软件公司的情况下，同样的事情，但用“部门”而不是“公司”和“证明其存在”而不是“赚钱”。所以我们要买一个包裹，问题是要不要买那个贵的。
在这种情况下
- 当没有好的免费选项存在时，或者由于更好的功能、更低的 TCO（因为不必自己修复错误）或其他原因，昂贵的软件比免费的软件更好。
或者：
- 当软件包不仅仅是软件，它是一项托管服务时，组织培训某人安装服务并让整个人 24/7 全天候待命维护它的成本甚至比“昂贵”还要高包裹。这是 TCO 的另一部分，但即使软件本身的成本相同，它也适用。
第一点的意思是，游戏公司不应该编写自己的 IDE，Web 应用程序公司不应该编写自己的编译器，银行软件部门不应该编写办公应用程序等，除非你真的认为自己' 这样做比编写游戏、网络应用程序、交易软件或任何你有实际截止日期的东西要好。显然有一些例外：如果您想要一个很小的脚本或 web 应用程序，那么编写它可能比找到可以满足您需要的现成的东西更容易。
第二点，“更好”对不同的组织意味着不同的东西。假设功能相同，如果您的部门充满了 linux 极客，那么免费选项可能比您没有 linux 极客有更多的加分，并且还需要有关软件包的 SLA。如果“包”将被编译到您的非自由产品中，而不是仅仅支持您的开发，那么显然 GPL 中的免费软件对您毫无用处，而 MIT 中的免费软件可能是美好的。等等。
于 2009-04-17T13:52:38.307 回答
1
大大简化，但选择最小的：
- 对于自制工具：成本 = (task_execution_time * uses * $/user-h + tool_development_time * $/dev-h
- 对于购买的工具：成本 = task_execution_time * uses * $/user-h + tool_purchase_price
- 没有工具：cost = task_execution_time * uses * $/user-h
cost 是执行task uses次数的成本。task_execution_time 是执行任务所需的（人）时间，包括任何开销，tool_development_time 是开发工具所需的时间。
为了简单起见，我省略了很多变量。添加更多以适合:)
于 2009-04-17T12:02:59.520 回答
0
这部分取决于管理层希望开发人员编写什么代码。
如果它是一家游戏开发公司并且他们正在推出自己的电子邮件解决方案，那将是一种浪费。有才华的游戏开发人员编写自己的 SMTP 客户端和服务器系统，而不是进行更有趣的游戏开发（更不用说这可能会违背开发人员在被录用时可能想到的任何“使命宣言”） .
相反，如果它正在编写一些小实用程序或其他代码，那么它可能是值得的。如果有实习生，这可能是一个很好的项目，可以让他们开始，或者如果一些开发人员厌倦了游戏物理并想做一些更平淡的事情，他们可以工作一段时间。
于 2009-06-09T13:55:27.653 回答
0
当我想自己编写一些代码，而我的老老板认为我们应该买它时，他会说，“买最好的，做剩下的。”
另一个经验法则：当它是您业务的核心产品之一时，请自己动手。如果不是，请考虑外包或从有核心产品的人那里购买。反正他们会做得更好。
于 2009-06-09T13:58:46.257 回答
0
我认为一个类比是合适的。
假设您对最新的赛车引擎有一个想法，该引擎可以立即使任何汽车以 20 英里/小时的速度行驶。你之所以能够做到这一点，是因为你在量子层面深入了解了如何优化引擎以使它们更好地工作。但是，您在其他领域（例如设计车架或车轮）的工程技能只是平均水平。您是否打算花时间尝试提高这些技能并重新发明轮子（或原来的框架？）？不。
相反，您将与制造最好的轮胎和制造最好的车架的人合作，并将您的引擎与他们结合起来。这可以节省您的时间和金钱，因为您专注于您的产品，而不是提供支持基础设施。
这也适用于软件。如果您需要的工具非常复杂，请从其他地方获取它们，因为您希望专注于制作最终产品，而不是让您制作产品的基础设施。
于 2009-06-09T14:01:15.940 回答
0
与购买解决方案所涉及的成本和时间相比，开发新解决方案所涉及的成本和时间很高。通常管理层对这两个因素非常敏感。
于 2009-04-17T11:07:16.737 回答
0
它会更便宜，但前提是您准备修改您的业务实践以适应该软件包的工作方式。在包上执行大量定制以适应您的业务实践几乎总是比从头开始创建定制应用程序花费更多，而且常常以泪水告终。
于 2009-04-17T11:10:08.713 回答
0
购买软件的原因有很多。在我看来，最重要的是：
- 组织内部缺乏知识和专业知识
- 缺乏快速适应市场或法律变化的人力（税收）
外包优势：
- 更容易预算
- 无需雇佣、培训人员
- 能够签订严格的服务水平合同
于 2009-04-17T11:24:40.877 回答
0
如果您要从头开始制造自己的汽车，那可能会非常昂贵且非常不可靠，但如果您要购买现成的汽车，则可能会便宜得多，而且更可靠。
软件也是如此（大多数时候），每一位定制代码不仅需要开发，还需要测试和支持。如果您可以使产品符合客户的要求，那么它通常是一个更具成本效益的解决方案。然而，我认为当一个产品被硬塞进一组需求时，问题就会出现，这些需求需要一些它不是为它设计的东西。
于 2009-04-17T11:31:30.797 回答
0
一些原因
- 该解决方案不支持核心业务流程，而是支持商品流程，例如财务、人力资源、设施管理，您与竞争对手没有什么不同（您的核心/非核心流程会有所不同！）。您的内部开发技能将更好地用于创建和维护使您的公司具有竞争优势的解决方案。
- 如果解决方案不需要与您现有或未来的解决方案高度集成（它支持相对孤立的过程），则前者适用。
- 在内部开发的应用程序的整个生命周期中，无需为维护预算和人员。数字各不相同，但我看到并认为相当可信的一个数字是自定义应用程序的初始开发成本仅占总生命周期成本的十分之一。当然，这包括最终用户培训、O/S 升级和集成等内容，这些内容也会影响外部采购的解决方案，但初始价格标签的 10 倍因素将使大多数管理人员暂停。
- 前者的一个特例：您的组织可能缺乏开发、维护和运营技能或存在瓶颈。每个技能短缺都可以用足够的时间和金钱来填补，但不一定在可接受的范围内。您的员工需要获得的每一项额外技术技能都意味着更少的时间来开发和维护现有技能：多样化技术环境的技能成本以超过线性的速度增长......
- 正如彼得所说：可预测但高成本可以胜过启动开发项目的风险，在一个企业中，20% 的成本超支通常被认为是一个成功的项目，而不成功的项目基本上没有限制......
- 正如 vatine 还注意到的那样：商业软件现在可以拥有，仅因安装和最终用户培训而延迟。诚然，SAP 之类的安装不是一天就能完成的……
这适用于您的供应商相当稳定的情况。如果他们规模小或财力薄弱，那么商业软件可能比内部开发是一场更大的赌博。
不管你走哪条路，你都会得到锁定效应。从真正有用的应用程序中迁移出来从来都不是免费的，而且很少便宜。
于 2009-04-17T11:43:51.813 回答
0
一次性内部开发可以取代订阅软件，即，如果您有可用的开发资源，一次性开发成本 2X 可以取代 X 的年度订阅。这也可能意味着最终解决方案完全针对业务需求，而第三方解决方案可能不完全匹配或需要额外的支持或解决方法。这适用于我在过去一两年内从事的项目，其好处是新系统更准确，因此需要更少的支持人员。是的，好的软件会让人变得多余。
公司核心软件也应该进行内部开发，该软件允许您作为一个实体存在，这样您就不会在下次软件支持合同或订阅到来时闲逛，或者通过一个解决方案不完全适合您的需求。
但是，不提供核心功能的基本软件的一次性成本很容易证明是合理的，无论是对甲骨文来说是巨额资金，还是上周您需要的体面的 CMS、CRM 或客户票务系统。
于 2009-04-17T11:48:42.410 回答