恭喜。 你有一个问题、一个项目、一个预算和一个截止日期。 软件不是解决问题的方法，而是解决方案，但现在您需要决定构建还是购买，这就是问题所在。 或者是吗？ 我不太确定这是否是一个明确的决定。
构建使用是指雇用内部程序员来编码任何必要的系统，而购买是指可以购买和运行的现成产品。 当我们谈论会计系统、交易系统、CRM、报告时，这是有道理的，
借贷、催收、CLM 等。我们现在生活在低代码环境中，构建某些东西不需要编码经验。 它可以被拖放。 再加上购买现成的解决方案，这些解决方案最终会被定制化，您可能会认为
很好已经建造了它。 那么我们在哪里做出建造或购买的决定呢？ 让我们看看我们真正需要什么。
现代系统不再依赖单一入口点。 客户的期望决定了各种渠道是必要的。 面对面、通过电话直接或呼叫中心、电子邮件、社交媒体、短信、网络、移动设备、平板电脑 – 移动设备和本地设备
应用程序，所有这些都需要在不丢失内容或上下文的情况下互换。 在分行/商店或亲自出发但必须离开去赴约的客户希望能够在当天晚些时候在线登录时从上次中断的地方继续。 或者
如果他们从网上开始但感到沮丧并寻求帮助，他们不想从头开始这个过程。 这也适用于内部利益相关者。 组织内的信息链需要与所面对的客户一样灵活
选项。
那么我们接下来要从任何地方开始数据输入呢？ 嗯，我们首先需要这些数据是有原因的。 无论是新客户想要与该组织合作，现有客户想要新产品或服务，甚至只是日常查询、投诉
或信息请求。 所有这些都应该开始定义但灵活的流程，以尽可能高效、轻松地完成请求。 该流程通常是经过定义的，并且通常对员工进行培训以遵循一系列任务，以按照预定的方式完成该流程
基于某些数据输入的操作。
如果信息已在某处捕获，最终客户和系统用户都不必在任何地方重新键入信息。 事实上，如果信息可以在组织内的任何地方或从数据提供商、信用机构等第三方来源获得，
筛选提供商等。它应该在整个过程中可供所有需要它的用户访问。 该流程已定义，但接触点应在整个过程中互换，收集的数据应在可能的情况下进行整合，并在允许的情况下进行结构化。
下拉菜单、查找值、日期字段和受控自由文本值，以确保预先捕获尽可能多的数据质量。 这使得整个过程更加自动化，并减少异常处理。
现在数据正在被主动捕获或更新，人工智能就可以应用了。 工作人员不需要了解所有细节，甚至新成员也可以处理更复杂的案例，因为系统使用策略编码规则
自动做出决策的逻辑，而员工以前必须经过广泛的培训和经验才能处理这些决策。 不再出现错误，同时还允许监督甚至质量控制检查或在需要时进行手动干预的彻底异常队列。
这一切都需要系统的方法。 将马尼拉文件夹放在员工抽屉里存放客户资料的旧想法已经过时，并且会带来不必要的风险。 孤立处理的客户端可能既有限又多余
同时。 如果一个企业客户的董事与多个其他客户同时任职，为什么每个单独的审查都会忽略更大的情况。 您是否还会在每种关系中多次审查同一位董事，或者您可以吗？
只做一次并在整个组织中重复使用该信息？
他们甚至不需要有共同的关联方就能获得明显的利益。 类似的行业，类似的客户客户，如果您的客户供应商本身也是客户怎么办？ 这让我们了解您需要如何处理信息
以及为什么当今组织在考虑软件时需要放眼整个企业。 如果您孤立地看待问题并单独对待它，为每个 CRM、金融犯罪、客户外展组件制定预算并发布 RFP，那么您最终将
花费更多的资源试图将所有内容整合在一起，而不是最初希望的任何潜在节省。 现在将其应用到可能获得单独预算和监督的每个地区或业务线，您最终将得到 8 个版本
由于每个区域的大量定制，需要与自身集成的相同软件消除了它们可以实现的任何规模经济。
抽屉里的文件夹需要每年或以其他方式进行审查，需要培训员工做什么以及何时做。 整个审查（或新的入职/附加产品/服务/等）可以分解为复合部分，这些部分可能或
可能无法由其他人/团队处理。 然后，系统可以确定任务何时完成，或者何时捕获足够的数据以发送给下一个人以供其输入。 所有这些都被构造为案例和子案例。 这样每个元素
案件可以有自己的截止日期、升级路径、受让人和批准人。 现在，系统会分配工作，而不是让工作人员需要有足够的经验才能知道如何完成以及该向谁完成其中的各个要素的大型任务
并通过尽可能多的自动化任务来确保整个公司的及时完成，从而使决策者能够专注于重要的事情。
从商业角度来看，这一切都很好。 这项工作以及需要做什么是已知的。 但是，当我们试图决定是否应该购买或自己构建软件时，这会如何影响事情呢？ 好吧，我们假设有多个来源
跨多个系统的数据。 任何现代系统都应该由 API 驱动并具有低代码/无代码功能。 更快、更灵活的软件的合理假设。 如今，一切都需要被视为某种微服务，以避免
旧式软件单体。 应该安装和使用软件，因为它是最好的可用软件，并且能够适应未来的需要，适应变化。 太多的产品被根深蒂固，只是因为它们太困难且耗时而被维护
取代。 这主要是因为规则是硬编码的，可能与数据本身交织在一起，数据不仅被集成，而且为信息链中每个单独的软件多次复制，如果你尝试替换一个，
整个系统可能会崩溃。 太多的旧思维过程，如果它没有被打破，那就不要修复它。 真正需要的是所有这些组件都成为微服务，获取所需的数据，应用自动化规则或用户输入/评论，
将其传递给下一个微服务。 数据不应存储在多个位置。 它可以联合，但不能在备份之外复制。 您的 CRM、Onboarding、KYC、客户外展等系统应该只访问它们需要的数据，而不应该访问
数据存储库本身就是数据存储库，除非您选择了其中之一。 在多个位置复制相同的数据以及管理它的规则是徒劳的，因为添加的每个额外系统都会增加所涉及的复杂性。
这给我们带来了最后的考虑。 无论您拥有单一事实来源/黄金副本还是多个冗余且相互竞争的记录以及可以更新它们的系统，您仍然会发现自己处于基于以下行的另一层需求中：
业务、司法管辖区、客户类型和产品/服务。 个人与公司或信托的待遇不同，并且消费者/零售、商业或企业业务线的要求和适用性也有所不同。 在最基本的例子中，如果
我们有 10 种类型的客户（个人 – 单身、已婚等、私人公司、上市公司、信托、慈善机构等），您可能在 10 个地区开展业务，并且您可能提供 10 种类型的产品/服务，我们已经在可能有 1000 多个规则
被应用。 为一个区域、一个业务线、一个客户类型和产品或服务定义规则并让系统解决需求不是更容易吗？ 删除重复项并重用以前的数据点
假如。 这是从数据层抽象流程和规则的好处。
因此，现在当我们考虑购买或构建软件的老问题时，我们知道我们需要全渠道编排、尽可能的流程自动化、灵活的规则逻辑、用于监督和可审计性的案例管理、低代码和 API 驱动、抽象
数据层和可以继承不同逻辑层的智能规则引擎。 科技市场充满了创新者，他们很乐意满足每一个可以想到的利基问题，但在什么时候“现成的”就不再有意义了
所有产品都需要定制并相互集成，而不是自己构建。 低代码平台可以让您满足 80% 的需求，而您只需要配置 20% 的增量。 两全其美的是低
其他人也为其构建了可重用组件的代码平台，因此您可以获得“现成的”产品作为您的业务加速器，同时您的员工或经过认证的第三方也能够构建其余的特定需求
给您的组织。 购买还是建造？ 确实应该两者兼而有之。
