Project management 统一的、企业范围的信息系统是可行的还是有价值的目标？

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

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

这个依赖关系网很混乱，所以我想知道是否有处理这个问题的最佳实践。一个单一的“统治所有人的制度”是一个切实可行的办法吗

这种类型的目标对企业来说是净积极的还是净消极的

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

---

我还没有提到财务部的业务要求……：）

只要你能建立一个每个有盈亏责任的人都能同意的发展组织，它将公平地平衡每个人的优先事项，并至少像他们直接控制的人一样了解他们的需求，并将尽可能高效和负责任地分配资源，就像他们从其他地方获得资源一样，这样才有意义。但我不会屏息以待。

只要你能建立一个每个有盈亏责任的人都能同意的发展组织，它将公平地平衡每个人的优先事项，并至少像他们直接控制的人那样了解他们的需求，并将尽可能高效和负责任地分配资源，就像他们从其他地方获得资源一样，这样才有意义。但我并没有屏住呼吸。

我已经做了很多。。。在最初的阶段，只是试图让所有的球员在同一个房间里，真正建立了一些“商定”的东西。不管发生什么，谁做的，怎么发生的，等等，都是痛苦的

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

您将遇到的下一个问题是，每个团队做事情的方式有点不同，对相同的事情有不同的术语，并且希望以不同的方式存储/交互信息。虽然这看起来不是一件大事，但却是

你添加到混合物中的每一个组的复杂性都会增加。如果你认为“好吧，我将从这个组开始，并在我开始的时候添加越来越多的组！”，那就不太管用了。一旦你和一个团队（销售？）一起启动它，其他团队就会将其视为“销售系统”，并反对这样做

---

相信我。。。ERP型系统进入10年代的原因是多方面的。。。这不全是技术性的，很多人都愿意忍受这些废话。

我已经做了很多。。。在最初的阶段，只是试图让所有的球员在同一个房间里，真正建立了一些“商定”的东西。不管发生什么，谁做的，怎么发生的，等等，都是痛苦的

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

您将遇到的下一个问题是，每个团队做事情的方式有点不同，对相同的事情有不同的术语，并且希望以不同的方式存储/交互信息。虽然这看起来不是一件大事，但却是

你添加到混合物中的每一个组的复杂性都会增加。如果你认为“好吧，我将从这个组开始，并在我开始的时候添加越来越多的组！”，那就不太管用了。一旦你和一个团队（销售？）一起启动它，其他团队就会将其视为“销售系统”，并反对这样做

---

相信我。。。ERP型系统进入10年代的原因是多方面的。。。这不全是技术性的，很多人都愿意忍受这些废话。

当你有一个大型的单片计算机-@$$mainframe/etc时，这就变得更容易做到了。然而，根据我的经验，我喜欢每个部门都有自己的优先事项、愿望和需要。通常，它们彼此不兼容。如果你试图将这些东西结合在一起，你就永远无法在最终产品上达成完全一致，也可能永远无法将你的部门服务到他们需要的水平

这也导致了第二个问题，即各部门秘密建立自己的临时系统（可能在MS Access或Excel中）；当维护人员离职/退休/被解雇，部门发现需要某种形式的维护时，你会发现这一点

还有一个时间问题。现在，多个部门都在等待另一个部门的升级，然后他们才能拥有自己的部门。很抱歉，F&A-在工程部收到他们的“嘶嘶声”增强功能之前，您无法进行税务更新，因为他们已经落后计划2个月了

我认为拥有多个专门用于手头任务的系统更明智。如果数据需要从一个部门流向另一个部门；那是w