OR stack exchange 高分问题
你可能在行业内做过一些运筹学相关项目，或者如果你在学术界，也可能为行业做过一些运筹学项目。我想知道你是否看到过一些此类项目失败（或者至少没有满足客户要求）的案例。当然，可能部分原因是其他非运筹学项目也存在的，但我特别感兴趣的是一些只在运筹学项目失败情况下出现的那些原因。
高层管理人员； 中层管理人员； 用户； 后端开发人员； 在客户公司内有一名团队成员； 可交付成果（我认为这包括实际的优化模型 / 软件）。
顾问被请来为一家复杂的制造企业改进决策流程。其中一名团队成员在公司生产总监能听到的情况下说他们能比生产总监做得好得多，于是生产总监对这个项目产生了敌意。 顾问为一家汽车租赁公司的预订业务提供决策支持。他们开发出了一个比现有解决方案效率高得多的系统，但提供必要的数据输入需要做很多工作，而后端技术部门不愿意支持它。
问题快速变化。随着客户对优化所能提供的东西有了更好的了解，问题常常会非常迅速地发生变化（例如，硬约束变成软约束）。如果你不能跟上这些变化并开发出真正解决客户项目的决策支持系统，客户可能不会接受它。 用户的信任和接受度。如果用户不接受或不信任已构建的决策支持系统，那么他们就不会使用它，这是最糟糕的情况之一。根据我的经验，有两项措施可以对此有所帮助：尽快让用户参与进来，并让他们感觉自己仍然掌控着最终决策，例如提供几个解决方案供他们选择。 很多软约束。在实际应用中，常常有很多软约束，根据客户的偏好对它们进行加权（以及让客户找出他们的偏好！）并设计能够解决这种复杂模型的求解方法可能非常具有挑战性。 对被取代的恐惧。我听说过客户方的领域专家抵制项目的情况，可能是因为他们害怕被决策支持系统取代（通常这种担心是有道理的）。 领域语言。可能不是项目的关键问题，但如果某领域专家和数学家使用相同词汇但不同的某领域语言，这可能会成为误解的来源。例如，如果一个数学家谈到 “约束”，他们可能意味着它是硬约束，而对于领域专家来说它也可能是软约束。 “一直都是这样”。在一些客户那里，你可能会遇到由某人（这个人通常早已离开公司很久了）制定的业务规则或流程规则，并且没有人记得为什么要这样做。识别这些情况并揭穿它们可能很困难，但如果你做到了，你会更好地理解潜在问题，并且通常可以提供更好的解决方案。 “难以言说” 的约束。有些约束客户无法提供给你。例如，在设计排班表时，可能有员工由于个人原因不想一起工作，所以你不应该把他们安排在同一个班次。然而，将这种信息放入数据库中（然后从中提取这些约束）是不道德的。在这种情况下，你的问题模型将无法完全准确，也无法产生客户实际上更喜欢的解决方案。
为这里的其他精彩答案做补充……
未能采用迭代过程。
认为通过几次会议来沟通和理解问题、确定运筹学解决方案的范围、期望的输出等等，就能让运筹学魔法师消失，然后带着圣杯回来，这是一种幻想。
这需要迭代。开发初步能力，评估，改进或增加能力，评估…… 继续下去。
如果在每次迭代会议中，运筹学团队和利益相关者明确地问 “这个方案不可行的十个原因是什么（对利益相关者而言）？”，然后解决这些问题，那么当他们采用这种策略时，团队通常可以实现收敛。通常，利益相关者对初步解决方案提出的问题是可以解决的。
点一点「在看」支持我们~
