The growth of mobile technology -- including mobile procurement -- has been a double-edged sword for many organizations. On the one hand, employees have become more productive with on-the-go access to internal networks, the Internet, mobile apps and the ability to easily communicate with anyone at any time. The productivity improvements go way beyond that, however, since many employees routinely use their personal mobile devices to work during off hours.
At the same time, mobile tablets and smartphones are creating headaches for the people responsible for managing the devices, particularly in
Part of the problem is cultural. Within many procurement and IT groups, mobile technology is still viewed as a sideshow, toy or nuisance. The IT department's role has traditionally been to support mission-critical systems. If a system isn't used within the four walls of the organization -- mobile procurement is a good example -- some mistakenly believe it isn't worth managing. That's about to change.
As more employees buy their own mobile devices, they will want to connect to company networks. Furthermore, the tidal wave of mobile procurement apps that integrate with enterprise systems is just beginning. ERP and CRM software vendors are rushing to fill the void, and without question, mobile procurement technology is about to explode. Organizations that fail to stay ahead of the wave could get swept underneath.
More on procurement
Read how to choose between ERP and best-of-breed procurement
Learn what to ask when buying procurement software
Getting ahead of the curve first requires developing a mobile procurement strategy. This involves more than simply negotiating a contract with a provider for pricing and service or telling employees to abide by bring your own device (BYOD) policies. The goal should be to manage the total cost of ownership of mobile procurement technology and provide a secure and supported computing environment, all while addressing the needs of the business and users.
Mobile procurement technology starts with requirements
The purchase of any technology should begin with a definition of business needs. Unfortunately, many IT managers make buying decisions with only a vague understanding of what they will do with the tools once they're acquired. The more critical and sophisticated the use, the more seriously businesses should take defining their requirements.
For example, in the early stages of adoption, many business department managers view tablets and smartphones as just personal productivity tools. Beyond having access to the Internet and a few standalone mobile apps, most users need limited interaction with internal networks such as email and other forms of remote access available from laptop PCs. This is where most organizations are today, and the needs are relatively easy to identify.
However, organizations that are considering mobile enterprise systems to support key business processes should take a much deeper dive into requirements. The approach should be comparable to the one employed when choosing any other important technology. This means arriving at a consensus on how business processes will function in the future and how mobile procurement technology will enable improvements.
The need for standardization
For most users, the word "standardization" invokes thoughts of rigid IT controls, less autonomy and applications that don't meet their needs. The main concerns were expressed years ago when personal computers first came onto the scene. For the most part, these fears never materialized. As was the case with PCs, as mobile systems become more important to the success of the organization, standardizing the infrastructure is a necessity.
This means selecting a single mobile procurement service provider, the one or two devices that will be supported and the mobile procurement applications that are best for the organization, not just for any one individual. The alternative is a proliferation of vendors, hardware and applications that results in higher costs and less support from IT.
With the exception of volume discounts gained from standardization, most of the other savings aren't obvious to people outside IT. For one thing, fewer methods are needed to connect to other systems, thus reducing infrastructure costs. Also, with some foresight and coordination of the types of apps required, integration costs can be reduced.
Finally, organizations should address the issue of proprietary versus nonproprietary technology. Proprietary systems always increase total cost because they require businesses to buy the vendor's other products to make it all work together. They also limit the availability and choice of applications. In mobile technology, this is a tough issue. Presently, Apple devices are proprietary by definition. Android is considered the closest thing to an open operating system, but there are many different flavors.
MDM should not be an afterthought for procurement
Before purchasing any system, consider how the system will be administered. Mobile platforms create inherent problems because the technology might be used for nonwork related activities and is more susceptible to being lost or stolen. All of these increase the risk of unauthorized access to company data through the mobile procurement apps.
Systems administration tools can greatly increase the security of mobile procurement apps, because they allow for data encryption, remote locking of devices and data removal. They also prevent unapproved mobile apps and other capabilities while reducing support costs.
Mobile technology policies and procedures should be another priority, covering topics such as device password protection and the types of mobile applications that are permitted. Mobile technology policies should also prohibit connecting unapproved smartphones and tablets to internal systems.
For any organization, as the number of devices increases and mobile enterprise applications are introduced, a centralized means to manage all devices -- no matter where they are located -- is critical.
Follow SearchManufacturingERP.com on Twitter: @ManufacturingTT
This was first published in September 2012