从项目到计划：建立您的核心项目团队（下）

从项目到计划：建立您的核心项目团队（下）

流程架构和愿景

“在我们甚至可以为POC决定流程之前，我们需要捕获公司中的所有业务流程并将其置于流程环境中。否则，我们将无法理解全部情况，因此无法正确确定优先级！”

我们经常面对这种危险的思维方式。流程增长迅速，但您还没有获得足够的工作流自动化方法和BPMN经验来生成质量合适的模型。这时你可能会想，公司想保护过去的投资：“嘿，我们三年前就已经针对我们的质量和合规性计划分析了此过程。我们仍然有模型，让我们将其用于该自动化项目”。一定不行！

流程体系结构和环境各有千秋，但是它们对流程有更高级的了解，并且与松散的BPMN工作流只有松散的联系。当您开始使用Camunda的旅程时，您应该将第一个项目与这些计划中的任何一个脱钩，以确保该项目可以喘息，学习和做出自己的决定，而不会陷入无休止的政治或方法论讨论。一旦您完成了许多项目并获得了BPMN的经验，就可以开始调整公司中的不同流。

我已经看到精益方法最有效，因此，例如，一个简单的合流页面就可以用作流程格局的入口，它显示了链接到高级流程描述的基本结构。从那里，您可以直接在开发源控件或Cawemo中导航到可执行的工作流程模型 。

在您扩大采用范围时，让流程架构师对此流程架构进行概述是很有意义的，但在此之前是没有意义的。

促进合作

一个实用的过程比流程体系结构更重要，它是一种允许与所有重要利益相关者进行工作流设计协作的实用程序。在工具方面，这可以像带有BPMN插件的Confluence页面一样简单，也可以像利用Git和bpmn.io 允许联合建模的定制工具一样进行定制。我经常看到使用Camunda Modeler或我们的协作过程建模工具Cawemo打开的共享文件系统上的模型。如果所涉利益相关者对如何实现这一目标有明确的了解，那么所有这些工作都可以进行。理想情况下，您的COE可以提供帮助。

尽量避免仅由于业务部门已建立流程而推出这些工具。通常，它们不支持BPMN 或根本无法用于在可执行模型上进行协作。

当然，您还需要创建一种促进协作和公开讨论的文化。将模型从业务分析师“推翻”到IT部门实施模型永远是行不通的。

这部分是为了确保所有重要的利益相关者都可以访问流程模型和相应的工具。我经常看到一些公司不想向每个开发人员提供许可证，这将导致流程中断。如果许可成本是阻碍因素，请考虑使用轻量级解决方案。

不要忘了项目经济学

重要的是要专注于通过工作流项目交付业务价值。此外，您还需要一些机制来确定自动化候选者的优先级，以此作为决定下一步解决方案的基础。我不会在本文中介绍项目组合管理，因为它本身非常复杂，并且在整个客户群中的组织方式都非常不同。只要确保在进入项目之前就评估了项目的潜力即可。

请注意，选择POC项目可能不需要严格的规则，因为这可能更多是由技术问题驱动的。但是，在此工作完成后不久，每个项目都应该通过数量和业务价值来证明其合理性，而不仅仅是技术上的热情。

交给你

我希望您喜欢这个系列，并且找到了可以应用于Camunda项目的实用且有用的建议？我写了这个文章是为了让您对如何使用Camunda有一个更好的了解。魔鬼总是存在于细节中，每种情况都有其独特的挑战。