As many companies look for ways to mobilize core SAP processes, a growing number of them are turning to purchasing functions for "quick wins" that allow them to extend the capabilities of their SAP Supplier Relationship Management (SRM) environment.
Particularly when combined with workflow approvals of capital expenditures (Capex), long-term service agreements as part of a normal purchase cycle, or requests for quote (RFQ) responses, mobilizing those purchasing functions helps traveling or busy management teams that need to approve and review information on the go.
The core SRM system has some capabilities that address the purchasing process, including vendor management, RFQ management and supplier compliance. The key master data functions in SRM provide ways to mobilize the information in these purchasing-related modules . However, it is important to note that regardless of what option you choose, building a mobile extension to SRM does not eliminate the need for having the core function in your on-premises SAP environment. In short, the SAP mobility solution needs to connect to the proper master data and transaction sets. If those aren't already in place, the solution has nothing to talk to. Remember, your SAP system is still your system of record no matter how deeply you decide to enable your environment for mobile computing. It's not a substitute.
SAP mobility options
Two approaches exist for companies when it comes to options offered within the SAP ecosystem. The first is a basic workflow approach using Microsoft Duet Outlook Exchange Server if your process is strictly for approvals only. The Outlook Exchange Server can enable a simple workflow approval process based on rule sets and authorizations to make simple purchasing transactions, including those that require a digital signature.
For more on SAP SRM:
Read one analyst's take on SAP SRM's strengths, weakenesses
Learn what questions remain around SAP's acquisition of Ariba
For more complicated transactions that require actually reviewing RFQ response categories, monitoring the status of key supplier management capabilties, or delegating and assigning decision-making powers to other organization units, a better approach is a mobile approach using the Sybase Unwired Platform (SUP) mobile enterprise application platform (MEAP) in conjunction with Mobile BusinessObjects (MBO) for mobile business intelligence (BI).
In this second scenario, getting an accurate mobile data set before you design the application is critical to the project's success. To optimize mobile applications for SUP, information is culled from the full BI or data universes needed for the mobile app. In the case of purchasing, this can be a subset of vendors that are approved for Capex transations, for example.
"Mobile BI provides an opportunity to revisit what information can be delivered to the customer," said Sampath Chaparala, senior manager for information strategy and architecture at a leading global pharmaceutical company. "You can decide which information is actionable as well as simply informational, and leave the deeper data levels within the on-premises BI platform."
Once you know what your mobile BI data requirements are, you can quickly build a mobile app around those requirements. There are two fundamental strategies for purchasing and other process applications. The first is to craft a landscape of point solutions. Each should have a specific fit and function -- Capex purchasing, for example -- or to leverage the SUP. Similar to getting the mobile BI data approach right, determining the best approach for your application is important, according to Anton Ansalmar, founder and CEO of Rapid Consulting Services Inc.
"Too often, organizations don't invest in a mobility strategy and base mobilizing their business processes on a loose collection of point solutions," Ansalmar said. "This may improve isolated operations for small groups of users, but a point solution strategy is difficult to manage when you need to mobilize a large enterprise. It can make collaboration across the enterprise cumbersome."
Enterprise-ready software like MEAP provide a common technology for building applications that run on any mobile device and can access any back-end database. MEAP-based solutions are inherently more scalable because applications built once will run on many different device types, and one set of management and security tools supports all applications and devices. Also, applications developed in a MEAP environment easily share data. So, for example, you could have several purchasing applications for Capex, commodity suppliers and service providers and each of these mobile apps can share the same vendor master data stored in the mobile BI environment.
"These characteristics make MEAP-based solutions less costly to support and manage over the long term," Ansalmar said.
Companies can build their own custom MEAP-based mobile applications or look to those provided by third-party vendors. If a MEAP-based solution is your preferred approach, remember that the function modules of SRM and other components of SAP business enterprise applications (such as ERP, SCM, SRM and CRM) need to be available or highly enabled by the MEAP solution. Mobile applications designed for these SAP applications don't update tables directly but leverage the Business Application Program Interface (BAPI) programs to do so.
Ansalmar recently observed this approach with one of his clients. "Once the BAPI or function module exposes data, like the vendor management master, the Mobile BusinessObjects set consumes the required subset for the application, depending upon what is needed," he said.
Companies can then double check the MBO requirements and authorizations once the SAP mobile application is in the testing phase to make sure the application has access to the necessary mobile BI data sets needed to execute transactions, like purchasing approvals or to review a vendor's performance history.
This was first published in August 2012