精心构建的数据架构所带来的收益不仅限于运营流程。 其好处包括战略运营效率、更深入的业务洞察力以及获得相邻业务机会的能力,所有这些都以更灵活的方式执行。
在之前的文章中,我们介绍了一种假设的食品订购和配送服务,并介绍了几个关键的日常运营工作流程:客户订购流程、取货和食品配送工作流程以及付款处理。 我们探索了围绕工作流关键数据输入的有意数据策略如何带来更稳健、更敏捷、更可扩展的业务流程。
在本文中,我想超越日常运营效率,展示深思熟虑的数据架构设计所带来的长期、更具战略性的好处。 将我们最初的设想快进 6 个月,假设我们的应用成功,企业领导者现在已经发现了一些新的和正在出现的机会。 他们现在询问技术人员底层系统能够多快速、轻松地调整并适应一些特定的机遇和相关挑战:
列出的四个示例挑战可分为两大类:
一、调整并提高日常关键(“战术”)业务流程的效率。
二、通过公司的客户直接或间接地创造新的见解,为公司创造长期(“战略”)价值。
首两个新的挑战——地域扩张和相关的合规要求——围绕着战术业务流程,因此本质上更具操作性。 最后两个挑战的性质更具战略性。
我们首先来看一下战术和操作方面的考虑。
随着地理扩展到更多城市,我们可能会遇到一些不同的问题。 对于交付工作流程来说,一个潜在的问题是街道地址可能存在歧义问题——同一个地址(例如“100 Main St.”)可能存在于多个城市。 另一个可能的问题是不同的城市可能跨时区;如果不考虑这一点,那么下午 6:00 接机。 MDT 时间到邻近的 PDT 时间城市送货可能会晚一个小时(下午 6:30)。 太平洋夏令时)。 我们上一篇文章中描述的数据架构采用了数据元素“规范化”——全局唯一——表示的想法,解决了两个潜在问题,从而允许应用隐式地满足这些额外的要求。
第二个战术关注点是遵守加利福尼亚州的额外数据治理要求。 围绕加州消费者隐私法案 (CCPA) 的全部担忧本身就是一整套文章,但其中一个方面是能够收集客户的所有数据,并注明收集时间以及数据来源。 如前所述,构建一个数据架构框架,允许主要数据提取管道添加元数据注释(例如时间戳),从而可以简单地满足额外的数据治理要求,并且只需最少的增量工作。
除了通过改进公司的日常战术工作流程和流程而产生的商业价值之外,另一个好处(可以说是更重要的好处)是能够既倾斜现有的竞争环境,又能开辟新的参与环境的战略价值。
一类战略优势是能够通过改变关键运营工作流程的蓝图来“改变局面”。 这不仅仅是对它们进行简单的优化,更是对它们进行重新构想。 强大而具有前瞻性的数据架构能够灵活高效地利用聚合和数据分析等关键功能,通过动态定价来解决上述由需求变化导致的交货时间缩短的挑战。
因此,来自两个不同工作流程(订购和交付)的数据可以关联、分类和汇总。 此外,可以利用灵活的元数据架构来用丰富的上下文信息注释整理后的数据以供分析。 考虑整体配送延迟——从下订单到食物送达的时间。 可以通过关联订购和交付工作流程来计算延迟。 此外,由于两个工作流中的地理位置数据表示也使用一致的语法和语义,因此传输延迟计算和关联可以按位置(例如邮政编码)进行分离。 因此,凭借数据策略的深思熟虑,我们可以更轻松地以每小时、每个邮政编码的粒度创建总体传输延迟的数据集。 最后,通过利用我们灵活的元数据方法,每小时的统计数据可以用额外的上下文信息来注释,例如交通状况和降水总量。
此时,我们拥有丰富的信息可以输入分析管道,然后分析管道可以使用预测性 AI 方法识别与总体交付时间增加相关的模式,甚至预测未来的此类情况。
作为这个故事的最后一步,我们可以想象企业现在将交付工作流程重新想象为供需问题,使用定价来匹配供需。 一个具体的例子是允许送货司机的报酬根据时间和地点进行调整,可以通过固定的时间表,也可以根据实时情况动态调整。 这在数据循环中形成“闭环”,通过利用数据采取可行的步骤(价格调整)来解决业务问题(管理整体交付延迟),并使用闭环反馈(根据观察到的延迟进行动态价格调整)使工作流程“自适应”。
数据的另一种价值是利用它“开辟新的竞争领域”,创造商业价值,并通过直接给客户带来利益而实现货币化。 我们在 6 个月后的场景中提到了一个例子:为我们的供应商方合作伙伴即餐馆提供价值。 为我们的应用程序客户提供洞察力的业务需求的解决方案是再次利用我们的应用程序的操作工作流收集的数据 - 这次作为为我们的客户和合作伙伴提取业务洞察力的原材料。 这些商业洞察可以采取多种形式;例如:
这些商业洞察的发现不仅仅是因为有大型数据存储,还因为有使用一致的元数据词汇以结构化方式注释收集的数据的数据策略。
放大一个特定的商业洞察故事,考虑如何确定菜单定价洞察。 从原材料(从订购工作流程中收集的操作数据)开始,元数据注释数据策略的价值就变得显而易见。 具体来说,不仅记录了特定餐厅的菜品价格,还保留了相关元数据。 考虑食品的其他描述属性,例如份量大小、食品“类型”(例如“软饮料”或“汉堡包”)和特殊“增强功能”(例如“包括配菜”或“辛辣”)。 如果数据架构使用一致的元数据标签词汇(例如“份量盎司”、“食物类别”、“增强功能”)和一组规范化的元数据值,用这些属性的元数据来修饰食物数据,那么就可以在各个餐厅之间比较食物信息。 例如,如果从代码数据库中得知的是“Burger Basement”有Man Cave Burger ,而“Heart Attack Grill”有Double Bypass Burger ,那么就没有进行有意义的比较的基础。 但是,如果我们添加元数据注释词汇,我们就可以进行比较和分析——系统会理解这两个项目是可比较的,因为它们都属于“汉堡包”的“食物类别”。 此外,分析还可以使用其他元数据字段来规范份量大小(即,“Man Cave”可能是 8 盎司,“Double Bypass”可能是 12 盎司)。 最后,使用标准的“增强”值空间,例如“包括奶酪”,也可以用来根据次要的相似性和/或差异进行额外的调整。 再次,对数据架构的深思熟虑——这次是围绕元数据策略——使得企业能够通过简单地利用现有工作流程的数据废气来快速地实现新的业务机会。
大多数企业领导者都敏锐地意识到,他们的成功取决于规划关键运营工作流程,以及对这些工作流程执行的可见性。 优秀的商业领袖还明白,快速有效地产生这些见解,并基于这些见解采取行动(包括内部和外部)的能力是他们持续成功的关键。
作为技术专家,我们需要构建解决方案来实现持续提高运营效率和业务敏捷性等业务目标。 可悲的是,工程师们过于关注解决方案的数据处理软件元素,而对数据架构本身关注不够。 这通常会导致付出巨大努力,并导致内部工作流程改进和新衍生客户产品推出的部署时间延迟。 正如本文所示,预先关注数据架构(数据词汇、表示形式和元数据策略)是敏捷和强大的数据驱动业务的技术基础。