BPX: Real World Responsibilities
While being the first to have the Business Process Expert job title may be true (read more about this in Life and Times of a Business Process Expert: Part 1), I feel that everything we do as BPXers at Forest City has to be taking place at other companies, and if it isn’t, I think that there’s a good argument to be made that it should be.
Responsibilities and Expectations
The key theme during our implementation of SAP, and I think it is still relevant today, was “Better Information Faster.” Taking this to heart, my core responsibility as a BPX is to ensure that the people running our business have reliable, accurate information on which to base their decisions, in a timely manner. What may be considered a ‘timely manner’ today may not necessarily be considered that tomorrow, so processes must continuously improve, or at the very least, improvements must be sought after. It’s not just important to get the business the information that they need, I also need to help them get it in the most efficient and effective ways possible. This means that I have to work with the business to design processes that are neither cumbersome nor confusing and I have to make the end user experience as intuitive and straightforward as possible. This is an absolute necessity, otherwise end users could end up getting frustrated to the point that they don’t want to use the system or follow the process.
As a BPX, I’m responsible for the full life cycle of process improvement – evaluating our processes to ensure that they are optimized, identifying potential improvements in our processes, helping lead the design and build of those process improvements, and helping roll out the updated process to the business. In order to meet these responsibilities I have to stay up to date on enhancements that are available in the software, but also keep up to date with recent trends in processes. I have to be able to think through our business processes and determine whether it makes sense to take advantage of these enhancements and, if so, how we can go best about making the changes to our systems and processes.
A couple of examples that are particularly relevant for me are driver-based budgeting and rolling forecasting – they’ve become popular trends in today’s economic environment in an effort to trim time spent on budgeting/forecasting to get information to business leaders more quickly. We currently deploy a zero-based budgeting process that is very time consuming and painstaking and while I personally feel that we could take advantage of these methodologies (or at least aspects thereof), I have to be able to come up with a solution that the business will think is worthwhile and be willing to change their current process to. At the same time, the solution must still meet the budgeting requirements, such as the level of detail of the information (very detailed budgets are often a requirement of our business/joint venture partners). What it really boils down to is, can we implement these changes in our process to achieve some time and/or cost savings, yet still maintain the quality of information (or better) that they are currently getting?
At the heart of the definition of a BPX is the concept of bridging the gap between business and IT; therefore, I am responsible for speaking the language of both and be able to translate when in meetings where both sides are involved. I feel that a BPX could have a background in IT and learn the business and vice versa, so some BPXers could be more technically-oriented or some (like me) may be more business-oriented. As a business-oriented BPX, I don’t feel like I have to know absolutely everything that there is to know about the IT side of the processes that I’m trying to design/improve; however, I do have to know the very basics (at a minimum) and I have to know who to turn to in our IT department in order get to the more technical details. I need to be able to take the requirements as dictated by our business and be able to develop functional specifications to meet their needs and compose these functional specifications using business language that they understand so that they can feel comfortable providing an approval. I then must work with our technical team to translate these functional specifications into the technical specifications so that it’s clear to the developers exactly what they need to build.
With some high-level responsibilities mapped out for our BPXers, the next blog will dive into some of the types of activities that I’ve been involved in over the past few years to give readers a feel for the work that I do as a BPX.