Documenting business processes can be time consuming, tedious and sometimes downright frustrating. Yet, the importance of documenting, sharing and updating processes is none the less, a value adding task. Regardless of the process, it is never worth spending a knowledge worker’s time drawing boxes and arrows in tools like PowerPoint, Gliffy or Visio. The days of formatting and aligning are finally over; now you can worry more about the data and collaborating with your team and leave the drawing to Ardoq.
There are two fundamental issues with traditional tools when it comes to documenting business processes. Firstly, they are primarily manual and focus more on the visualization than the actual information at hand. Consequently, this type of documentations is D.O.D (dead on delivery), meaning that it often falls victim to poor versioning, fragmentation and the inability to be held up-to-date.
These challenges are not unique to process documentation, and are the underlying motivation for the creation of Ardoq. Instead of developing a drawing app, Ardoq choose to focus on data first so that users can, search, share, update and analyse everything they document and leave the tedious part of drawing to the tool. Most importantly, by centralizing this type of documentation, we can distribute and collaborate across the organization to better understand how the business and IT are dependent on one another.
So with this blog post, we will show you how you can easily document, visualize and share your business processes. In the following post, we will show you can connect your processes to other crucial components across your organization like requirements or IT systems.
Documenting Business Processes in Ardoq
Ardoq is designed to capture data and add structure so that we can automatically create interactive visualizations like process flows and swim-lanes. In order to do this, we apply a simplified model to the documentation. But don’t be scared, this model is simply saying that a process consists of either manual or automated steps.By focusing on data first, we are able to capture more critical information and enable users to search, filter, and analyze their documentation. This can be beneficial for many reasons. For example, if you have a large process that is supported by multiple IT systems, your documentation can become overwhelming. But if you can add filters and dynamically drill down through your visualizations, you can look at your process in exactly the right perspective that is relevant to you, without having to contact others, find new versions or redraw diagrams.
By focusing on data first you can be more secure in the quality of your documentation and make decisions confidently.
We understand that everyone works differently and we wanted to be able to give you the tools you need to be effective. So, if you are in the conceptual phase and want to work visually you can open up the process flow and add content visually using the smart link editor. Basically put, this creates a new component and relationship with a single click. You can then go back and add the vital information per step after you are finished.
Another more effective option, if you have a lot of steps ready to be documented, is the table editor. This editor is similar to what you would expect in other worksheet tools. Columns and rows divided by individual component. Here you can hammer out a number of components and then use the component tree to start adding the links between the steps in your process.
We recommend keeping your models and documentation as simple as possible in order to maintain the likelihood of it being used by others and kept up to date. However, our simple model presented above may not be enough to cover your basic needs. For example, you may have multiple decision points and would like to have them as a unique component type or step in the process. Or, you may have simplified main processes that consist of multiple sub-processes. Having the ability to filter and search between the two can add a level of simplicity for a better overview.
In Ardoq, we allow our users to define the model that best suites them. Two examples to solve the above-mentioned scenarios could look something like this:
Next week we will take business process documentation one step further by building an example in which we explain how to document role-based processes. We will introduce a new model and show how the Swimlane view can give you a dynamic look into your processes and divide the steps by ownership.