Developing mobile applications for ERP systems

At Claremont we work with many of our clients to develop mobile applications for Oracle E-Business Suite (EBS).

Over the last year, we’ve looked at the best way to develop these mobile apps, which has prompted a few questions on best-practice.

Why are Mobile Apps for ERP Systems different from others?

Mobile apps, which are intended to extend the features of an ERP system, are subtly different beasts from the collection of apps you probably have on your phone or tablet right now.

A stand-alone app on your phone is essentially a separate piece of software, which carries all of its features within the app. User interface (UI) control, logic and data – these are all encapsulated within the app on your device.

However, an app which extends ERP features to a mobile employee is doing something slightly different.

Although an ERP app works on a mobile platform, the majority of the app’s functionality resides in the main ERP application – not on the device itself.

That being said, the app must have enough of its own features and business logic to make it usable. This is especially true when the app is designed to function even when disconnected from the main ERP application.

Less is more: developing a mobile feature set

The apps that Claremont are developing have a small set of features in the mobile platform itself – but just enough to ensure the app is functional and most efficient (when both connected to and disconnected from the main ERP application).

We’ve seen that other mobile ERP apps have a tendency to try and replicate large parts of the ERP application. They attempt to transition all the ERP functionality onto the mobile platform, which can make the app unwieldy.

Choosing a technical platform is also key to developing the best ERP app possible.

But it’s really easy to get carried away with what you could put into an app, when you’re faced with a platform’s capabilities.

If we developed apps in iOS, for example, then we could call on all of the iOS features and come up with something Steve Jobs would have admired. But this isn’t what we’re trying to do.

We’re not in the business of saddling our clients with lots of new – but superfluous –  technologies.

No, we’ve developed our ERP mobile apps so that our clients can easily access their ERP application remotely – but we treat these apps as an extension of the ERP system itself, rather than an autonomous technical solution, with additional but unnecessary features, as this would only require extra time and support.

This means that our mobile apps are designed to complement the existing technology Oracle stack. They work to deliver real business benefits – remote access, cost savings, improved efficiency – but without the need for any significant additional support and/or staff training to use the mobile ERP apps effectively.

When selecting mobile technologies, one of the main aims is to complement the existing technology stack (Oracle) as far as possible. At Claremont we are always aware of the time and effort a customer will need to put into supporting these solutions. Choosing a complimentary technology is key to ensuring that the mobile apps are not a burden on the enterprise.

Choosing the right technology

Before getting into the nuts and bolts of building an app, there are some fairly basic choices to be made about which software to use.

There are plenty of choices available. But in order to make the right decision you will also need to consider which devices the apps are going to run on (Android, Apple or Windows).

Here are the pros and cons of a couple of approaches that you may want to consider:

• Native device development:

In order to get the most out of your device, your best bet is to develop your apps natively in the language supported for that device i.e.

• Android: Java
• iOS: Objective C & Swift (Apple’s Xcode integrated development environment (IDE)).
• Windows: C#, C++, Javascript

Advantages: you’re using the language in which your device’s operating system is written. This means that access to device specific features, libraries etc. will be more straightforward.

If you put the time and effort into this approach, you are going to end up with a highly polished app.

Disadvantages: you’ll need to know the specific language required for each type of device that your organisation supports. Then you’ll need to develop the same app in each different language.

The advent of BYOD (Bring Your Own Device) in the workplace in recent years has magnified this problem. The alternative is to PSE (Pay Someone Else) and get an external firm to develop your native apps for you. You don’t need the skills in house to follow this path – although obviously outsourcing may be more expensive. It’s also important to bear in mind how you will support these technologies after they are delivered.

• Device agnostic development:

This option involves developing the app inside a development framework. The app is developed once in whatever language your chosen framework uses. The framework (an app in its own right) then takes care of running your app on various different platforms.
Examples of this technology include Xamarin and Oracle’s own MAF (Mobile Application Framework).

Advantages: You only build the app once, but can still deploy to multiple mobile platforms. This lowers the cost of development and the need for on-going support. It also means you can develop an app that covers multiple platforms in less time (compared with building native apps for each platform).

Disadvantages: This is the ‘lowest common denominator’ approach, which means that in order for the container to work across multiple platforms, some of the more niche or advanced features of Android/iOS/Windows may not be available to you.

Claremont’s approach to mobile app development

At Claremont, we use the device agnostic approach, coupled with Oracle’s MAF framework, to develop our ERP mobile apps.

For us, this approach makes most sense, since we’re developing apps with little or no prior knowledge of what devices or platforms our clients might run the apps on. It also allows us to treat the apps as extensions of the ERP system itself, and ensure the apps work seamlessly with existing Oracle technology.

If you want to know more about Oracle’s MAF framework, there is plenty of information (including downloads) on the following link: Oracle Mobile Application Framework.

The third defining strand of our approach, is to treat these mobile extensions in a similar way as we would treat CEMLIs.

A CEMLI (Configuration, Extension, Migration, Localisation, or Interface to the uninitiated) is a custom extension built onto the standard code base in an ERP application. They are built to satisfy a specific requirement where the standard application does not provide some required functionality.

Our mobile apps work in a comparable way – plugging specific gaps in your wider ERP system and making that functionality accessible out in the field.

They are also designed to be supported by the same people who would support the main ERP application and existing CEMLIs.

ERP mobile apps are increasingly important for any business looking to get the most from their Oracle E-Business Suite. That’s why, at Claremont, we are always working to develop new ERP apps for, and with, clients.

In my next blog I outline our latest venture into mobile ERP – the Mobile Engineer – which started life as a proof of concept and is now being developed for one of our clients in the student accommodation sector.

Get in touch with Claremont to find out how mobile ERP apps could save your team time and help you to improve efficiency across the business.