Michael Lane, Claremont Technical Lead, spoke at the UKOUG Apps17 event about navigating the choices in the mobile application world – and how to make the right choice for your company.
Mobile ERP apps
Mobile Enterprise Resource Planning (ERP) apps are subtly different from most of the apps on your phone. They are the end-point to the service provided by the back-end application. Therefore, when considering a mobile ERP app, you need to think more about how you’re going to build and support it, and how it will keep pace with the changes in the ERP application and less about the appearance of your new mobile app. In other words, treat your mobile apps in the same way that you would a custom extension to your ERP system.
In general, ERP applications are not known for their engaging user interfaces; they are business applications, built to perform business functions, so how they look is a secondary consideration. The most important thing to consider is whether it has enough functionality to make it usable.
How to go mobile
The first thing to do is work out who will most benefit from the app. Think about people who work away from a desk, for example service engineers (one of the more obvious ones that come to people’s mind when thinking mobile), warehouse operatives, accommodation managers. The accommodation manager example come from Claremont’s existing client base where we specialize in property management solutions. The accommodation managers are the first point of contact between the organisation and the customer, therefore they will need mobile functions that take real actions. Some examples would be the ability to update a customer’s account, take a payment, update a bad debt repayment plan etc. If the employee can do these transactions on the spot, that’s all good for the customer relationship.
Once you’ve chosen your role, you need to be very specific about what the app should do, for example stock-taking or placing a sales order. Users should be able to perform the function in less than 45 seconds – any longer and the process becomes frustrating (and people start to think you’re looking at Facebook).
The question then becomes whether to buy or build or download for free.
Buy something
There are lots of 3rd party apps out there for common business functions such as approvals and ordering and if these fit your needs out of the box then great! Pay-up, download and off you go.
If you are and Oracle ERP user then your ERP module license may well include the use of mobile applications at no extra cost. This is certainly the case for E-Business users where mobile Inventory, Approvals, Expenses, Timecards, Field Service and Procurement are all available from the iStore.
Note: some patching and secure connectivity setup is required to connect these apps to your servers, but at least you’re not going to spend money developing anything. One final word of warning on the E-Business Apps: you cannot customise them.
However, if you’re going to build something yourself. Here are some options:
Native app development
The advantages of building your own app are that you can code in the device’s own language and create highly polished apps. The disadvantages are that you need skills in the specific languages, such as Java (Android apps) and Objective C (iOS apps). The alternative is to pay someone else to build it for you . For this you don’t need the skills, just the money,
but you will also have to pay support costs once the app is live. You’ll then need to think about how you’re going to support these apps going forward.
Device agnostic development
Device agnostic development is where you develop the app in a framework tool, not directly in the native language. This framework takes care of the translation between the development language and the device language. Example platforms include: Oracle Mobile Application Framework, Xamarin and MS Visual Studio.
The advantages are once it’s built you can deploy it anywhere (therefore you achieve maximum reach in terms of mobile devices), the disadvantage is that it takes the lowest common denominator approach – which means device features from the latest version upgrades may not be accessible.
Oracle Application Express Option
Apex, is mostly associated with developing web applications and not generally thought of as a platform for mobile apps. I hadn’t considered it as a subject for the presentation until I saw a presentation by Neath Port Talbot Council. Briefly, they used a tablet running an Express Edition Oracle database with the Apex app running in it. This was synchronised back to base to the enterprise server which had the same application in the database and used the DBMS_COMPARISION PL/SQL package to keep the two sets of data in synch. DBMS_COMPARISON has some handy features which allow you to set rules for which database has precedence in terms of updates to records. In Neath’s case only one engineer could work on a job at one time so the mobile database took precedence. The useful feature about this configuration is that the local database and Apex app would happily work disconnected until connectivity was available.
At least one member of the audience when I presented this idea got interested and went off to investigate the method for her own company. It’s good to share
I can’t take any credit for the idea, I was just lucky I happened to attend the Apex SIG when Neath presented their idea.
Making mobile adoption successful
The key points for making your mobile application adoption a success:
- Do a skills impact assessment. Will the adoption of the new apps stretch your development and support teams too far? Are you adding new training requirements in order to deploy a new app? If so, is it really worth it?
- It’s important to do an impact assessment on whether there is a real need for the app:
- Does it have business benefits / fill a real business gap,
- Can your existing team support it, and does your team need new skills/training to build and support it?
- Does it have the maximum reach possible?
- Does it retain the terminology from your main ERP functions?