Business process is (or should be) one of the key benefits in Enterprise Architecture, because the work you do directly affects those processes, and may even create new ones for the business. Understanding the business processes that your organization uses to achieve its goals is critical, because you’re in a unique position to affect, support, and create these processes.
Creating Information From Data
There are a number of considerations that any architecture governance needs to take into account when they’re engaged in Business Process Management (BPM). Obviously, an understanding or catalog of at least the principal business processes used by the enterprise is step number one. But a key part of your Enterprise Architect BPM job is to find ways to improve those processes, or develop new processes that benefit the business.
To perform those Enterprise Architect BPM activities usually requires a number of tools and methods, like the upcoming BlueDolphin tool, and a coherent approach to BPM projects. BPM projects can get very complex very quickly, so care should be taken to understand the actual schedule requirements before the project is begun. Process discovery typically takes the greatest amount of time, but other areas like functional and technical specifications and documentation, tool evaluation and selection, and implementation of the new process all take significant amounts of time as well.
The Ideal Process vs. Competing Factors
As mentioned above, navigating the business processes of almost any enterprise or organization can be a complex activity. The bias, of course, is to believe that all processes within a given enterprise are rational, and only performed because they bring an easily identifiable value to the organization, and that the way they’re performed is the most logical way to achieve the end result. But while most processes usually start out that way, over time they become subject to obsolescence, politics, budgetary pressures, and other factors that alter the process (or everything around it), so that it’s no longer as efficient as it once was. Part of any Enterprise Architect BPM project is to sort through that mess, to figure out the ‘whys’ in the process, keep any parts that still make sense, and replace or refine those that no longer do.
Another aspect of processes that enterprise architects need to take into account is the presence of any regulatory requirements that might affect the processes under evaluation. In some cases, regulatory requirements might help explain why a process functions the way that it does, and those same requirements have to be addressed by any new or refined process that is developed. To that end, the enterprise architect needs to not only understand those regulatory requirements, but they also need to be able to map their BPM project to those requirements, and track that progress.
Putting it all into Perspective
Once the relevant processes have been captured, generally the next step is to model them, so that a visual representation can be created that lets the team understand how the overall process works, and identify areas for improvement. This is critical for either existing processes under review, or during the development of new business processes, because it helps the team to reduce much of the surrounding complexity and see the overall process in a more simple light.
