Skip to Content
Author's profile photo Former Member

Life and Times of a Business Process Expert: Part 3

Previous posts in this series provided some Life and Times of a Business Process Expert: Part 1 on our Business Process Expert group and what I view as our Life and Times of a Business Process Expert: Part 2

One of the things that I love about my job is the fact that I don’t have a ‘typical day’ and that each day brings new challenges, opportunities and excitement.  Here are just some of the tasks that I’ve participated in over the past year or two:

Requirements gathering – Sit down discussions with representatives of the business to define and document what it is that they want to get out of the system.  It’s important to get as much detail out of these meetings as possible to avoid multiple follow-up sessions.  What’s key here is to discuss the business requirements and not the potential technical aspects of a solution – we must first fully understand the requirements before we even begin to discuss how to formulate a solution.

Process mapping – Documenting, via diagrams and textual descriptions, the current business processes as well as future-state processes, with the latter being based upon the requirements gathered above.  Processes are mapped at various levels, so that they can be explained both to management (high level) and end-user (detailed/task level).

Functional specifications – Based upon the requirements gathered and processes mapped, functional specifications are documented and agreed upon with the business.  These functional specs describe, in business terms, how the business requirements will be met using SAP.  It is crucial to ensure that the work that will be done is clear to the business user as they are required to approve the functional specs before development can begin.  This approval is very important as any changes to the functionally specs after work has been started will delay the development efforts.

Technical specifications – After the three above activities have taken place, I help in the preparation of the technical specs that will be used to develop the solution.  Again, it’s not important that I know all of the technical details involved, but I need to be able to speak the language and understand the basics in order to ensure that the functional specs are translated into technical specs that will lead to proper development of the solution.

Development – In some cases, I may need (or get!) to do the development or make the required changes myself.  I find that one of the best ways to stay current in the solution is to get my hands dirty in the development of the solutions.  Specifically, as part of our BPC implementation, I performed most of the configuration of the Applications and Dimensions (for those familiar with BPC, I did a lot of the work that involved the Admin Console), and also developed Input Templates and Reports in BPC for Excel.  For me, I really enjoy doing this type of work every now and then, so I don’t mind doing it.  For the times that I’m not doing the work myself, I provide assistance to the developers by answering questions that they may have, where either the technical or functional specs were not quite detailed enough.

Testing – As I’m one of the closest to the details of the changes being made, I work with our Quality Assurance/Quality Control team to help them write test scripts that ensure that the development works as intended and meets the business requirements.  Sometimes I also help to perform testing on behalf of the business when users aren’t available to test.

Reporting – I’d be remiss if I didn’t touch on reporting as a part of what I do.  Most things (at least at our organization) that revolve around BPM boil down to generating more or better information from reports.  I help to design the reports (and in some cases in the past, I get to build them as well) that the business wants/needs to effectively run the business.  There are times that I also provide the business with ideas for reports to gather/present information that they didn’t realize we had and there are times that I can help change current reports that may no longer provide the information they need (or maybe just not enough detail).

Training – In the case of a new implementation or a major change in business process or functionality, I work with the business leads to develop power user and end user training courses and related materials.  I then teach the training course to the power users and either deliver the end user training myself or work with the power users to deliver it.  Included in training materials are generally a PowerPoint presentation, some exercises that we walk through during the training and work instructions.  Obviously, this is a lot of work when going through a major implementation, so I don’t do all of the course material myself – it’s usually a collaborative effort of the implementation team members.

Troubleshooting – While we all hope that everything goes without a hitch after going live with a new process, functionality or entirely new system, the truth of the matter is that there is always a period of stabilization.  During this period, I pitch-in to troubleshoot any issues that users are encountering.  I try to stay out of user-error related questions that come in and allow our super users or help desk tackle those; however, I do need to be aware of these issues so that we can adjust any training materials or perhaps re-train users.  What I’m helping to troubleshoot are problems encountered due to the activities performed during the process or bugs in the software solution that was developed.  Even after ‘stabilization’ has occurred and we have turned over support to our help desk or application support teams, I’m still involved as a last resort when they are unable to resolve the issue.

Super User Meetings – While I’ve gotten away from hosting super user meetings (since the business now hosts them!), I still participate in them so that I can get some good feedback on how things are going using the systems and processes that I’ve helped them put into place.  Also, our forecasting process changes on a monthly basis – at the very least there are subtle differences – so I like to participate to provide any feedback or give them a heads-up as to potential missteps that could occur that month.  Currently, we meet twice a month with one meeting as a preparatory meeting for that month’s process, and the second meeting used as a review of the prior month’s activities and what went right or could be done better.

Keeping Current – Since I’m responsible for improving our processes, I absolutely have to stay current on what’s going on from a few different perspectives outside of our current process.  First, I have to know what changes are being made to the software to know whether it will impact our process or configuration – both from a negative perspective (i.e. something we’ve got now could break as a result of a change) or from a positive perspective (new functionality available in a more current release).  Second, I need to stay current on industry trends and/or process trends – this requires participating in webcasts, reading articles online, etc.  Personally, I like attending ASUG events – these help me to network with people with similar interests and also the educational sessions provide some insight into how other companies are using the same software we are.

In the final part of this series, I’ll cover the value that our BPX team provides, some challenges that we’ve encountered and the direction I think we’re headed.

Assigned Tags

      You must be Logged on to comment or reply to a post.
      Author's profile photo Former Member
      Former Member
      As a technical development consultant since more than 10 yr, I observed that more close to business more the better. More so in these days of offshore craze. The BPX'er role is a God-sent for my aspirations.
      Except being involved more in technical design and development, and less in the business requirement gathering and functional design phase, a technical architect and BPX'er role would be almost the same. Is that right ?
      Any how more functional and business knowledge is the way to go, for a successful BPXer career.

      Great detailed blog. I can concur 100% with your BPX'er experience.

      - Prasad Nutalapati

      Author's profile photo Former Member
      Former Member
      Thank you for the kind words and for your engaging response.

      My opinion is that a BPXer can be technically oriented, but probably faces some different challenges such as a thorough understanding of a business process and what exactly the business is trying to accomplish with the process.  Coming more from the business/functional side, I have another set of challenges once the discussions turn more technical.

      I think that the technical architect would/should work closely with the BPXer depending on the project, but the roles are different, and you've identified correctly that there is more functional/business knowledge needed.  There are some good diagrams on Jon Reed's blog post below that show the roles/sweet spots for a BPXer.

      Author's profile photo Tammy Powlas
      Tammy Powlas
      but not the process mapping, attend Super User Meetings.

      In some cases, depending on the project, I do "development".

      So in your final series, will you cover what your goal, next steps are as BPXer - would it be to become the Enterprise Architect?

      These are great blogs, so I hope you keep them up, Jim!

      Author's profile photo Former Member
      Former Member
      Thanks again Tammy for your response.

      I hadn't planned to cover exactly what I see as my career path in the next/final post (moreso where I see our team headed), but I can give you some thoughts here. 

      I see myself being relatively versatile in terms of career development:

      1) I could continue for quite some time in my current role as I think that we have a lot of work to do to execute our vision.  Ok, well maybe it's just my vision 🙂
      2) I could move up to the role of a BPX lead (more of a manager of the team of BPXers we have here)
      3) Move up to the role of an Enterprise Architect (or junior architect with longer term aspirations, but we don't have a junior architect position - at least not yet).
      4) Go back into the business side of the company as a Business Analyst (or some other role if the right fit was identified). 
      5) Move somewhere else within IT as a manager type of role

      In summary, I think I have a lot of different places I could go, and with our company going through many changes right now, it's hard to say what new opportunities will come up in the future, both within IT and the business.  As a last resort, I could always choose to leave the company and become a consultant, though I have no desire for the out-of-town travel that comes with that job.