统一的、企业范围的信息系统是可行的还是值得实现的目标？

Question

考虑到大型组织的每个部门都有大量数字化信息，将信息系统开发的重点从链接单个系统转移到开始考虑具有足够灵活性和可扩展性的单一基础架构，以满足每个部门当前和未来的所有需求，这是一个有价值的目标吗？

例如，sales有一个CRM包，但希望与法律部使用的定制系统集成。两者都指的是由工程和业务开发部门管理的产品数据库。跨部门的业务规则比比皆是。

这种依赖关系的网络是混乱的-所以我想知道是否有任何处理这个问题的最佳实践。一个单一的“系统来统治所有人”是一种实用的方法吗？

这种类型的目标是否等于业务的净正面，或者您是否经历过净负面影响？

这显然是一个迭代的开发过程，但是否应该在没有完整的spec +实现的情况下推出一些部分，或者运行并行系统并在特定时间切换会更好？

我还没有提到财务部门的业务需求...:)

Answer 1

我做过很多这样的工作……在早期阶段，只是试图让所有的玩家在同一个房间里，真正建立起一些“一致同意”的东西。无论发生什么，是谁做的，它是如何发生的，等等，都是痛苦的。

现有组织中的问题是，每个团队-有时是部门，有时是产品团队-都开发了自己的工具和方法来完成工作。无论它多么低效或过时，它都是他们的。如果你能让这些人愿意检查这个系统，那就是一个起点。

您将遇到的下一个问题是，每个团队做事情的方式略有不同，对相同的事情有不同的行话，并且希望以不同的方式存储/交互信息。虽然这看起来不是什么大事，但它确实是。

复杂性随着您添加到混合中的每个组而复合。如果你认为“好吧，我将从这个组开始，然后随着时间的推移添加更多的组！”，这是不太可能的。一旦你与一个小组(销售？)一起推出它，其他小组就会认为它是“销售系统”，并反对这样做。

相信我。ERP类型的系统运行到M的10%是有原因的。这并不全是技术上的问题，许多人都愿意忍受这些废话。

Answer 2

一旦你可以构建一个每个有损益责任的人都能同意的开发组织，它将公平地平衡每个人的优先事项，至少像他们直接控制的人一样理解他们的需求，并将像他们可以从其他地方获得资源一样有效和响应性地分配资源，那么这将是有意义的。但我不会屏住呼吸。

Answer 3

当你有一个巨大的@$$mainframe/等时，这就变得更可行了。然而，在我的经验中，我发现每个部门都有自己的优先事项、需求和需求。通常，它们彼此不兼容。如果你试图让这些东西结合在一起，你永远不会在最终产品上达成完全一致，也可能永远不会为你的部门提供他们所需的服务。

这也导致了第二个问题，部门秘密地(可能是在MS Access或Excel中)构建自己的临时系统；多年后，当维护人员退出/退休/被解雇时，部门发现它需要某种类型的维护。

还有一个时间问题。你现在有多个部门在等待另一个部门的升级，然后他们才能得到自己的升级。对不起，F&A -你不能有你的税务更新，直到工程人员得到他们的冒泡增强，他们已经落后计划2个月了。

我认为将多个系统专门用于手头的任务会更明智。如果数据需要从一个部门流向另一个部门，这就是胶水代码和接口发挥作用的地方。或者在最坏的情况下，您只需将其添加到人类任务列表中。“简办事员，星期一，你要打印X报告，并用办公室内部邮件寄给Y部门。”