Expand +



Take A New Look at Business Process Monitoring with SAP Solution Manager

Nathan Williams' tips on BPMon and key drivers for managing business process risk & reporting

by Nathan Williams

July 22, 2014


Nathan Williams

Nathan Williams, author of IT Service Management for SAP Solution Manageranswers questions about a SAP Solution Manager tool that is sometimes overlooked: Business Process Monitoring (BPMon).   

Nathan discussed questions about getting started with the tool, and topics such as: What is BPMon? Who are champions and users of this tool? What are common scenarios for applying the tool, and what are the reporting results? 

For more on SAP Solution Manager, read one of Nathan's earlier interviews here, and the edited transcript, below.

This is Kristine Erickson with SAPinsider and I’m speaking today with Nathan Williams. Nathan is a Solution Manager consultant and author and we’re here to talk today about SAP Solution Manager, but in particular, what you need to know about Solution Manager’s Business Process Monitoring tool.

So, Nathan, it’s great to have you here.

Nathan Williams: Thanks, Kristine.

Q: Nathan, the last time that we spoke, you had just finished your book on IT Service Management and we were talking on the exhibit floor at TechEd, so it’s been a few months.

Do you want to give us an update? What does a consultant do with all that new-found free time after the book is off the presses?

Nathan Williams: Well I don’t know anything about free time, but it was definitely a relief to close the chapter, no pun intended, on my twelve month role as an SAP PRESS author. It was a good experience, but I was relieved to be done with that process.

Things have been really busy since we last spoke at TechEd. I think when we talked last time on the show floor we were discussing how I was starting out on my journey as an independent consultant. That’s been great, it’s been really rewarding. I thought working for myself would provide that free time and flexibility, but not so much!

It’s been a great ride so far. Within less than 12 months I’ve worked in several different organizations with world-class customers, been able to expand my network of consulting colleagues, which is instrumental in our business.

This year I’m looking forward to the same, looking forward to TechEd [or rather d-code] later this year.

Q: So let’s start with Business Process Monitoring - I guess it’s also referred to as “BPMon”, do I have that right?

Nathan Williams: That is correct. I don’t know how that originated, but the market is calling it BPMon so I just go with it.

Q: We’ve heard some buzz about that, but there also seem to be some misconceptions or lack of awareness about it, too, on the customer’s part. Maybe it hasn’t caught the attention of folks in the same way that ChaRM or technical monitoring have. So can you talk a little bit about, first of all, what it is?

Nathan Williams: Sure, and I’ve observed the same thing. It’s one of those functionalities that’s been fundamental with Solution Manager since the early releases. I believe it provides excellent functionality to monitor business processes and help overcome issues before they become issues, but I haven’t really seen that much attention with regard to business process monitoring as much as ChaRM or IT service management.

I think that stems from Solution Manager 7.1 and the support packs like 5 and 10 that really focused on these improvements that the market longed after with regard to ITSM and ChaRM. So maybe BPMon has suffered a little bit of an identity crisis as a result of that, but I’m particularly interested and a proponent of BPMon.

In a nutshell, it is a process-oriented tool that monitors critical business processes. So, for example, if you have an order-to-cash process, there are various steps for creating a sales order, having the outbound delivery created, having the goods issue posted. So all of these steps that occur in an end-to-end business process.

If there are failures at any one of those steps or critical KPIs that a customer needs to monitor, Solution Manager does that from a central location. So we can monitor how many outbound deliveries were not created. If there were less than five, I should see a big red traffic light alert in my dashboard, so it provides that kind of alerting more from a process-oriented perspective. We get these nice traffic light dashboards.

We get great interactive business process analytics, reporting functionality, and it also provides an escalation and notification path so we can understand what to do with the alert, who’s going to close it, who’s going to escalate it, and so on and so forth. That’s essentially what the tool is providing.

Q: So it’s obviously much more process-oriented, focused on the business side of it as opposed to technical monitoring which is more the focus of the Basis and technical teams. Who are you seeing typically as the champions or the users of this tool?

Nathan Williams: I think that’s important, because I think the champions, the stakeholders and the users  are somewhat overlooked when I see this tool being implemented.

Yes, the tool collects data for the mission-critical business processes; we’ve got this traffic light alert dashboard, we’ve got analytics, that’s all available. But once these alerts are coming into Solution Manager, once these notifications are triggered, what happens after that? Who in the organization is going to go in and look at the alerts, number one, right? Who is going to be responsible for escalating them? Who is going to be responsible for confirming them or closing them?

For all of these considerations, Solution Manager provides the framework to facilitate all of it, from both a functional and automated standpoint.

But it’s also important to understand and identify who will be impacted from an organizational standpoint. This can be across customers. I’ve seen application owners, business process owners. If the customer has an in-house support system, it can be the second-tier support layer. So that’s just a small example of who are affected or who would be interested in Business Process Monitoring.

It does overlap into the IT world as well, so it’s not just a siloed effort. If an alert is related to a technical error, Basis [teams] may want to look at these alerts. And also management, because Solution Manager provides these great dashboards that can give you a thumbs-up or thumbs-down on how the business process is being executed. Management always like to see those dashboards!

Q: I have two followup questions: Where you start planning and understanding which business processes to focus on is an important starting point. But do companies look to BPMon after they’ve experienced problems in their business processes? Or are they doing it proactively - understanding their critical business processes and then coming to BPMon?

Nathan Williams: It really depends on how the topic of BPMon surfaces in their organization. What exactly is the driver for us wanting to do this or even having the interest to do it?

For example, is there a critical reporting gap that we can resolve by implementing a standards tool delivered from Solution Manager like BPO mon? Can we resolve this gap without having to create a RICEF or a custom report? And if so, I think that’s a key driver.

I think once that driver is determined then you can take a little bit more of a technical look on how to execute the project. Or,  getting back to your question, where to start?

Sometimes I interact with clients that know exactly what they want. They’ve recognized critical reporting and alerting gaps in their order-to-cash process, for example. They know the steps in that order-to-cash process that are breaking down, what key figures they need to activate, and what thresholds to maintain in order to generate meaningful alerts.

There are alsoclients that have difficulty identifying - or even agreeing internally on - what processes are critical and what should be monitored. Believe it or not, that case is occurring more often than customers who know what they want to monitor.

While those two scenarios are really different, I believe the starting point is similar. My recommendation is start with a prototype in the Solution Manager development system. Keep it simple. You can hook Solution Manager up to your development ECC system, for example, and get familiar with the tool before you deploy it in production.

Assuming your Basis and security activities are in place - so there are some key prerequisites - the actual setup for BPMon prototype shouldn’t take that long at all.

Q: Do you want to talk about any next steps in setup for BPMon?

Nathan Williams: Typically you want to start out with a project plan. Just as if you were to implement ChaRM or ITSM, there are key phases that you want to execute -  and BPMon isn’t any different.

When I develop a project plan for BPMon I like to break up the build phase and the setup activities by different technical areas, so this helps me identify who will be responsible as well as what the dependencies are.

One area of the setup that I typically start with is security. The resources setting up BPMon will require specific roles, not only in Solution Manager itself, but also in the managed systems. The business process monitoring automated wizard - that’s something that’s delivered within SolMan setup - provides an accelerated mechanism to achieve the security setup. It creates template users, it defines the roles, so it’s really a win because it’s automated, it creates the roles automatically, but it also helps you understand who might be those stakeholders that we talked about.

Another key setup activity is the system preparation and the managed system configuration activities, so those are also within SolMan setup. This ensures that Solution Manager’s post-installation configuration settings are all good and, most importantly, that the systems that are connected to Solution Manager are there.

Finally the BPMon configuration itself; that involves completing some BPMon automated wizard activities that I mentioned earlier, creating the solution. So that represents your systems, processes and documentation that are in production, and setting up and activating those monitoring objects.

So that ultimately is what is going to generate those alerts. Three areas, like I said: security, Basis and SolMan-specific configuration. Those are all done in SolMan setup and also in the business process operations work center in Solution Manager.

Q: And the final question: How does this fit into the overall Solution Manager when it comes to the application lifecycle?

Nathan Williams: Whether it’s the first thing that a customer implements or the last thing, no matter where BPMon sits in their roadmap, the important piece that you mentioned is that the integration is there.

The integration of BPMon across ALM is, in my opinion, a critical element that actually helps define and even drive that organizational roadmap for Solution Manager. That means Solution Manager is an integrated platform and it’s intended to be the single source of the truth for both ALM functionalities as well as Run SAP Like a Factory functionality.

The tools within SolMan are completely integrated both from a process-oriented perspective as well as a technical perspective and there’s also the integration to third-party toolsets as well from Solution Manager.

So what does that mean for BPMon exactly?

If we take a fundamental scenario that most customers are familiar with or have even implemented - that’s the solution implementation piece, the SOLAR01 transaction, documenting and managing business processes as part of the build phase or even the blueprint phase - we can migrate all of that documentation to a solution once that project goes live.

For example, those business processes that we documented, the technical RICEF objects, the transaction codes, and even the systems are defined in a solution. So that solution represents what’s in production. Essentially that is where the BPMon setup is performed - in the solution. We assign monitoring objects and we activate those monitoring objects directly in the solution.

If you wanted to take that integration even further from a change control aspect, BPMon also integrates into Change Request Management or what we know as ChaRM. If changes are required to those business processes after they’ve gone live, we can check them out of the solution and do a maintenance project and then have the controlled via all of the workflows and automation that ChaRM offers.

Those are two examples that highlight how BPMon is fully integrated into the other ALM aspects of Solution Manager.

Q: Thank you, Nathan, that’s all great background. Thanks so much for taking the time to talk to us today.

Nathan Williams: Thank you, Kristine.

An email has been sent to:

More from SAPinsider


Please log in to post a comment.

No comments have been submitted on this article. Be the first to comment!