考虑到大型组织的每个部门都有大量的数字化信息，重新关注信息系统开发的重点是远离连接各个系统，并开始考虑单一的基础设施，这些基础设施希望灵活，可扩展到足以满足每个部门目前和未来的所有要求？
例如，销售部门有一个CRM软件包，但希望与法律部门使用的定制系统集成。两者均指由工程和业务开发部门管理的产品数据库。跨部门的业务规则比比皆是。
这个依赖网络很乱 - 所以我想知道是否有任何最佳实践来处理这个问题。单一的“系统统治它们”是一种实用的方法吗？
此类目标是否对业务产生净积极影响，或者您是否经历过净负面影响？
这显然是一个迭代的开发过程，但是如果没有完整的规范+实现就会推出一些部分，或者运行并行系统并在特定时间切换它会更好吗？
我还没有提到财务部门的业务要求...... :)
答案 0 :(得分：3)
我已经研究了其中的一些......在试图让同一个房间里的所有玩家真正构建出“同意”的东西的早期阶段。无论发生什么，谁来做，它是如何发生等等，都是痛苦的。
现有组织中的问题是每个组 - 有时是部门，有时是产品团队 - 已经开发了自己的工具和方法来完成工作。无论效率如何低效或过时，都是他们的。如果你能让这些人愿意查看系统，那就是一个起点。
您将遇到的下一个问题是，每个团队的工作方式都有所不同，对于相同的事情有不同的术语，并希望以不同的方式存储/交互信息。虽然这似乎不是一件大事，但事实并非如此。
复杂性与您添加到混合中的每个组相关。如果你认为“好吧，我会从这个小组开始，并在我去的时候添加越来越多的小组！”，它并不是那么有效。一旦您使用一个组（销售？）启动它，其他组将把它视为“销售系统”并且不利于这样做。
相信我......有理由说ERP系统会遇到M的10个......这不是所有的技术，很多都要处理这种垃圾的意愿。
答案 1 :(得分：0)
一旦你能够建立一个开发组织，每个有损益责任的人都能达成一致，就会公平地平衡每个人的优先事项，至少和他们直接控制的人一样了解他们的需求，并且会分配资源尽可能有效地和响应地从他们那里获得它们，然后它才有意义。但我没有屏住呼吸。
答案 2 :(得分：0)
当你有一个单片大 - @ $$大型机/等时，它变得更加可行。但是，根据我的经验，我喜欢每个部门都有自己的优先事项，需求和需求。很多时候，它们彼此不兼容。如果您尝试将这些东西放在一起，那么您永远无法就最终产品达成完全一致，并且可能永远不会将您的部门服务到他们所需的级别。
这也导致了一个次要问题，即部门秘密建立自己的临时系统（可能在MS Access或Excel中）;当维护者退出/退出/ is_fired时，你发现了几年，并且部门发现它需要某种维护。
还有一个时间问题。您现在最终会有多个部门等待其他部门的升级，然后才能获得自己的部门。对不起，F＆amp; A - 在工程师获得他们的惊人增强之前，你不能进行税务更新，他们已经落后于计划2个月了。
我认为将多个系统专门用于手头的任务是更为合理的。如果数据需要从一个部门流向另一个部门;这就是胶水代码和接口发挥作用的地方。或者在最坏的情况下，您只需将其添加到人工任务列表中。 “秘书简，周一，你打算打印报告X并通过办公室邮件发送给Y部门。”
答案 3 :(得分：0)
简而言之：
答案 4 :(得分：0)
了解企业架构的概念，为了解决您提到的问题，存在多个框架。