I recently had the opportunity to work with a company that had a long sales and construction process. In their industry it generally took three months to complete the process, but with this company they knew it was taking much longer. They were challenged to even measure what their cycle time was with any degree of accuracy. To rectify this, they decided to implement a business process management (BPM) workflow tool.
As a business analyst, this afforded me an interesting opportunity to go much further into the software delivery pipeline than I normally do. What’s interesting about most BPM tools is they are based off models, many of which can be created by anyone with some minor training and some familiarity with the underlying models. In the case of the tool my customer deployed, it was very straightforward to take our process flows and implement them directly in the tool. It wasn’t a complete one-to-one mapping between our process flows and the tool. Since the process flows in the tool generally connected screens, there were steps in our business process flow that were collapsed to a single screen. We organized our business rules in Team Foundation Server (TFS) around each step/screen, and this made it quite straightforward to simply code our way through the process. This worked well enough that we were able to implement the first application in 2 weeks, to the great astonishment of our business partners!
The nice thing about BPM tools is they are already speaking the BA language. There are natural mappings between any number of Requirements Modeling Language (RML) models (Org Charts, Business Data Diagram, Process Flow, System Flow) and specific definable models in the tools. This is nice, because it allows BA’s who may not be formally trained developers to actually implement portions of the solution. BPM tools aren’t “code free”, but they are certainly “code light” with some exceptions at the interfaces of the system.
Of course the downside to BPM tools is the tools that they give BA’s also form the “boundaries” of what you can do easily with the systems. The further you stray from convention, the more development work you’ll need to do in order to fight the framework.
