In recent months IFS has ramped up its mobile apps development efforts, tripling the size of the development team. With this comes the need to create a larger backlog of “wanted apps”. That in turn leads to lot of interesting discussions with colleagues, customers, sales reps etc. about what apps we really should build.
Through this process I have realized two things which, at least for me, give some clarity to what we should and should not do when it comes to apps in the enterprise.
The first thing I realized is what apps we don’t want.
Before the iPad when there was just the iPhone, BlackBerry and various Android smartphones, things were a lot easier. The phone was (and still is) the thing you always carried on your own person. In business it was used for sending messages and checking e-mails. It was used whilst waiting in the security queues at the airport, when in the taxi, or slouching in the TV-couch at 11 pm. In essence – the phone was the device used when you only have a short moment, or when you are away from anything that resembles a desk.
On the phone we had apps, and these apps were designed for tasks you could do in a short space of time, that could get interrupted at any point, and that required a minimum of typing. In the consumer world it for example meant games where you could complete levels or the whole game in minutes or seconds. For business use we were discussing apps to quickly review and approve purchases, to have a quick look at some KPI:s etc. Most of us agreed on what business tasks could be suitable to do on our phones.
Then came the iPad and confused us all. The first group of people who came to me and said we should build apps for the iPad asked for pretty much the same things they had wanted on the phone. Although relevant in some cases, it is not in all since you don’t cary your iPad with you all the time in the same way that you do your phone. The pad is left behind much more easily at your desk, in the hotel room and so on.
Then we all started to realize that actually the display on a pad was big enough to view more or less the same things that we view on our laptops. With this came a stream or requests for just about anything. One customer I spoke to wanted a project planning app for the iPad since their project managers preferred bringing iPad rather than laptops into the meetings. Another customer said they would like an apps for several functions in the finance modules since they were considering buying iPads for all the managers in the finance department. One of our sales reps came buy and said he would like the complete CRM module on his iPad.
This is when it hit me. Although people are asking for all sorts of apps for pads, what they really want is the same range of features from the business application suite that they today use on their laptops.
In my opinion, when it comes to enterprise use the pad is much more a laptop replacement (in the meeting room, when sitting down with a customer, when discussing a project plan with a colleague) than it is an alternative to the smartphone. The pad is, just as the laptop, used when sat at a desk or table for some reasonable length of time–not when standing in that airport check-in queue.
So rather than developing hundreds (or eventually thousands) of iPad apps to cover all functions and processes asked for, why not instead take the existing user interface for the business application and make it available for pads? There are of course differences between a pad and a laptop, the most important being that the pad is operated with touch interface rather than mouse and keyboard. So an existing UI would need some changes to become more “touch friendly” and easy to use with touch. But trust me–making those changes is a lot less work than developing hundreds of apps. And it allows the same user experience to be offered on pads, tablets, as well as traditional laptops with or without touch enabled screens.
OK, so iPad confusion aside, what apps for the enterprise should we have then? The picture is certainly getting more clear on that question. Tell you all about it tomorrow.
Örjan
Yes, I agree.
One important part of the current cloud-service possibilities would then be to allow extended access via the existing user interface. Making certain fucntions and parts of existing user interface availble in the cloud (or DMZ).
Today we spend a lot of time on integrations usually just sending data to humans that are not users in our system. Sometimes these users responds back on this in a structured way (integrated or not).
If they could access IFS directly we would save a lot of integration work and would be able to add a lot of additional value that an integration cannot give. The missing piece here is the data dependent security models you would need. These external users should just see a restricted set of data (very much like one of our own sales guys could just be allowed to see his own prospects and contacts in CRM).
Here a traditional user license model can be questioned.
With this kind of possibilities IFS user interface would be reached not only by IFS customers’ end user but also their customers and suppliers. IFS would really be setting standards, being discussed, be in the flow etc. So the potential in this would justify rather large investments, wouldn’t it?
The earlier b2b web client solutions where one user is connected to one customer id or vendor id is not possible to use for us. We want it more flexible when defining the different datasets an external user should be allowed to access.
Dan Matthews
It would be interesting to hear some specific scenarios (i.e. what processes you would like to enable for non-users / consumers) and your thoughts on appropriate channels. Drop me a mail if you wish.
Stig Johnsen
Reading this article got me thinking about what kind of app could be useful to different kind of our IFS users in the company, and in which situations this could be useful. Then it strikes me that the overall popularity of apps both in Apple’s App Store and Google’s Android Market are driven by the high numbers of developers actually working on different approaches to customer’s satisfaction. Possibly the best strategy for IFS to exploit the mobile and tablet market, is to make it easier for other developers to make custom made apps. If there was a documented developer model available then a market would develop with third party interests, increasing the general value of having an IFS Business Systems installed for your customers. Over time the most popular apps would stand out, helping IFS consider where to put your efforts.
Dan Matthews
Opening up IFS Touch Apps development to third parties is one thng we are considering for the roadmap going forward. However I feel it is important that we in IFS first provide enough apps for the concept to demonstrate that is commercially successful.