A Business Process, put simply, is a collection of activities toward a common business goal, usually with the end result being the completion of an objective that leads to increased revenue, reduced costs, improved compliance and better customer service. A business process can be as simple as the process for collecting payments from customers and depositing them in the bank, or as complex as moving natural resources like oil through production and distribution in a complex multinational environment.
Business processes are, or should be, one of the key areas of focus for any Enterprise Architect, 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 those process.
Creating Information From Data
There are a number of considerations that any Enterprise Architect 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 probably 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, 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.
Everything mentioned above just scratches the surface of what’s involved in any enterprise architect’s BPM project. When you consider the financial considerations, business case generation, requirements documentation, tool selection, implementation, and everything else that goes in to such a project, you begin to understand just how complex these projects can get.
XMPro iBOS
Part of our rationale for developing XMPro iBOS is because we understand that complexity, and the level of support that a BPM tool needs to provide. And one of the things that iBOS takes into account is the amount of unplanned events and unstructured work that should be taken into account by any BPM platform, but often isn’t. iBOS captures those things that shouldn’t impact your business processes, but do.
iBOS was built with Business Process Management in mind, and integrates its ability to receive inputs and detect events from a large range of sources like applications, web services, devices, time triggers and people, and integrate them into a single operational view, which not only allows you to track overall operations, but gives you a real time view of the effect of your BPM projects, so that you can track the actual effects of your projects.
As an enterprise architect, you need to work within a larger organization, and different groups have their own priorities and considerations when it comes to the processes that affect them and their team. That’s why you need to be able to capture those inputs and incorporate them into your business process review and overall BPM project. To that end, the iBOS tool allows you to gather input from all over your organization, and include them into your overall BPM project, using crowd questions and surveys, social-style messaging, and comments. iBOS also allows you to make those interactions part of the audit trail of a transaction.
Using a customizable workspace, iBOS allows you to track your BPM projects by defining the business rules, resources, and scheduling, and provides reporting around all of it. Users can interface with iBOS via Microsoft Outlook, Microsoft Sharepoint, Salesforce, web browser or mobile device.
Implementation and Conclusion
Once the processes have been captured and modelled, new requirements captured, and the tools for that process have been selected, the next general phase is to implement the new process. Team and project management is critical to this phase, especially when many of the team members are part of different groups and organizations. The tool you use to track their process and the progress of your project should be able to track relevant jobs and tasks, their status, time to complete, and so forth. iBOS was designed to do just this, and provide reporting on these tasks from a variety of standpoints.
When you consider all of the factors that go into Business Process Management, it’s easy to get lost in the weeds. There are, after all, a huge number of considerations, inputs, personnel and data points to consider, and it can get overwhelming quickly. But if you take the time to choose a tool that’s purpose-built for enterprise architecture and business process management, it can make your project flow much more smoothly and efficiently, and help you to positively impact the larger organization.