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