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. 

Activities
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.