这些场景，您是否正在经历
提的需求都是功能，不是痛点
业务部门按自己的理解写需求，写出来的是臆想的功能；能不能解决问题没人管，做出来才发现不是想要的、根本用不了
只管自己，不顾上下游
提需求只考虑本部门，不考虑上下游的配合——造出来的系统，很可能又是一座孤岛
一人一个写法，系统跟着个人改
没有统一业务架构，不同人写出来的需求不一样；业务标准化不足，使用者不停抱怨，要求按个人习惯改，而不是按岗位标准来
这里说的需求，是业务部门提给数字化部门的系统建设需求
业务部门按自己的理解写需求，写出来的是臆想的功能；能不能解决问题没人管，做出来才发现不是想要的、根本用不了
提需求只考虑本部门，不考虑上下游的配合——造出来的系统，很可能又是一座孤岛
没有统一业务架构，不同人写出来的需求不一样；业务标准化不足，使用者不停抱怨，要求按个人习惯改，而不是按岗位标准来
直接要写功能，不管痛点、只管自己不顾上下游、一人一个写法——最后都变成新建系统的返工和抱怨。
提需求之前，"这个业务该怎么做"先要形成共识，基于共识才能实现标准化——跳过这一步，需求写得再多也是各说各话。
有了统一的业务架构——对业务标准化的理解和要求——才能形成大家认同的应用架构和数据架构，需求顺着这条线贯穿下来，才不会走样。
需求直接引用业务能力、流程、指标、数据目录、应用功能与集成关系，并标明成熟度现状与提升目标
输入的是结构化的架构基线，架构组件之间互相关联、层层承载——需求引用什么、影响什么，一目了然
项目级的业务架构、应用架构、数据架构，分域评审，过审才立项，才进入采购招标
输出的是基于基线的目标架构，带着成熟度的台阶，供应商拿到就能理解业务、明确需求，照着实施
EAMS 需求管理，按"基于企业架构的需求管理"设计：以架构基线为输入——业务、应用、数据架构组件结构化、互相关联、层层承载；每条需求引用基线组件，并标明成熟度现状与提升目标；项目级的业务架构、应用架构、数据架构，分域评审，过审才立项；输出的目标架构与输入一一对应，三个架构的目标态同源生成、互不扯皮——供应商拿到手，就能真正照着实施。
所有信息系统卡在"上线→不好用→推翻→再上线"的死循环，需求只有"一篇小作文"就拿去招标。星顺辅导客户建成企业架构基线，并立下机制：任何数字化需求，先完成四个架构并分别过审，才进入招标。需求从小作文变成一整套标准化文档——供应商拿到四个架构投标开发，要做的、要连的，一切明明白白；以前是上线了才发现不对，现在是没上线就把"做出来会是什么样"看清楚。
预约交流，我们用您企业的一个真实需求，演示一遍"基于企业架构的需求管理"怎么做
我们将在 1 个工作日内与您联系
服务热线 137 7034 9882（微信同号）
大型制造企业的企业架构与数据治理服务商
星顺企业架构双翼法：让需求落地，让数据贯通
