INOM EXAMENSARBETE DATALOGI OCH DATATEKNIK,AVANCERAD NIVÅ, 30 HP

, STOCKHOLM SVERIGE 2020

Let them use apps: The integration and adoption of mobile enterprise applications

DANIEL MOLIN

KTHSKOLAN FÖR ELEKTROTEKNIK OCH DATAVETENSKAP

Abstract

Den snabba ökningen i användandet av smartphones har lett till att företag i allt större

utsträckning anpassar sina interna system för mobilanvändning: så kallade mobile

enterprise applications. Tidigare forskning visar att dessa mobilapplikationer kan göra

företagets anställda mer effektiva, produktiva och nöjda. Att utveckla och lansera dessa

applikationer är långt ifrån trivialt, och företag har haft svårt att fullt ut anamma ett mobilt

arbetssätt.

Denna uppsats ger en detaljerad beskrivning av utvecklingen och implementeringen av två

interna smartphone-appar hos två företag. Genom en analys av appar samt intervjuer med

nyckelpersoner på två företag syftar den här uppsatsen till att besvara frågan: hur passar nya

smartphone-appar in i befintliga system så att de tillför värde för företagen?

Resultaten visar att även om de nya apparna har tämligen grundläggande funktionalitet,

räcker det faktum att de är mobila för att göra dem värdefulla och användbara. Ur företagens

synvinkel var tillgänglighet och anslutning de två viktigaste aspekterna hos apparna – de gav

medarbetarna enkel tillgång till företagets information. Även hinder för utvecklingen har

identifierats; främst hur man ska integrera apparna med de olika interna system som redan

är i bruk. Användbarheten hos mobilappar för företag diskuteras, och det föreslås riktlinjer

för framtida intressenter och utvecklare för att underlätta omvandlingen till mobila företag.

Let them use apps: The integration and adoption of mobileenterprise applications

Daniel Molin

KTH Royal Institute of Technology

Stockholm, Sweden

<dmol@kth.se>ABSTRACT

The rapid increase in smartphone usage has led enterprises

to start adapting their internal systems for use with

smartphones; so called mobile enterprise applications.

Previous research show that these mobile applications can

increase the efficiency, satisfaction and productivity of a

company's workforce. Developing and deploying the

applications is far from trivial, and companies have

struggled to fully adopt enterprise mobility.

This paper gives a detailed description of the development

and implementation of two smartphone applications for

internal use at two companies. Through two case studies

consisting of an app analysis and interviews with key

stakeholders, the research presented focuses on addressing

the research question: how do new smartphone applications

fit into existing systems to provide added value to

companies?

The results show that even though the apps developed are

simple in their functionality, the fact that they are used on

mobile devices makes them valuable in itself. From the

companies’ perspectives, availability and connectivity were

the two most important aspects of the applications - they

provided easy access to company information.

Developmental obstacles were also identified, most notably

how to integrate the apps with the different internal systems

already in place. The usefulness of mobile enterprise

applications is discussed, and guidelines for future

stakeholders and developers are suggested to make

transformations into mobile enterprises easier.

Author Keywords

mobile enterprise applications; smartphones; intranet;

mobile development;

INTRODUCTION

Many companies are moving towards a more mobilized

workforce through the use of mobile enterprise applications

run on smartphones. This can improve the efficiency,

mobility, perceived productivity and agility of the workers

(Basole, 2008; Chung, Lee, & Kim, 2014). Recent surveys

indicate that this trend is as much driven by the employees

themselves as being deliberately prepared for by the

companies - being used to ever more functionality on their

smartphones, employees are bringing their devices to work

expecting similar levels of freedom and usability from

work-related applications as more recreational ones

(Millman, 2013).

The phenomenon of people working from their self-

provided devices is commonly referred to as BYOD, or

Bring-Your-Own-Device. Adopting a BYOD policy creates

both possibilities and challenges for a company: some have

reported increased productivity and employee satisfaction

(Chung et al., 2014; Michels, 2013), while security can be a

constant worry. Despite the challenges, BYOD seems to be

the inevitable way of the future for most companies. This

makes it an interesting area of research both regarding how

companies are adapting to the increased use of mobile

technology in the workplace, and what type of impact

mobile enterprise systems have on the employees.

Regardless of how and why a company chooses to “go

mobile” and employ smartphone applications (apps) for

internal use, be it through adopting a BYOD policy or

taking a more controlled approach, this process has its

challenges. It is not as trivial as just continuing work as

usual but on smartphones and tablets. Enterprise

applications may need to be re-developed to fit a mobile

context and as effectively as possible utilize the advantages

that mobility brings to employees. This is a major hurdle for

effectively mobilizing enterprise systems; developing tailor-

made smartphone applications is something most small-

and medium-sized enterprises do not have the resources for

(Brans & Basole, 2008). The applications and systems

should preferably be built from the ground up to be truly

mobile and usable. In reality, though, many companies

build mobile apps on top of their existing internal systems

which may be problematic but can nevertheless bring a lot

of value to the company (Picoto, Bélanger, & Palma-dos-

Reis, 2014).

From a development perspective, building an app on

existing systems presents a different set of challenges than

building a mobile enterprise system from scratch. Ideally,

existing systems (such as databases of employees,

scheduling systems, intranets etc.) should be gracefully

connected to and interacted with from mobile applications

to allow the users to benefit from the unique advantages

that mobile technology brings. While many new services,

both publicly accessible and intended for internal use,

provide web-based APIs to access them and their data to

create so-called mashups (Daniel et al., 2007; Liu, Liang,

Xu, Staples, & Zhu, 2011), existing internal applications

may not have been designed with this use in mind. For each

new application, this gives rise to the challenge of how to

integrate these.

1

Successful transformations, even partial ones, of companies

into mobile enterprises can have a positive impact on the

workflow and workforce. This paper will build on previous

research to provide further insight about how companies are

developing and adopting mobile technology to create value

for the company. Through case studies, the research

presented here will strive to highlight common obstacles

and characteristics of the development process as well as

describe the uses of mobile technology and its impact on

the employees of the companies.

RELATED RESEARCH

Enterprise mobility

While enterprises have been employing mobile systems for

quite some time now, the rapid improvements in technology

of both devices and infrastructure, as well as more

sophisticated and powerful applications, are constantly

changing the characteristics of enterprise mobility (Basole,

2008). The level of mobilization at an enterprise can be

described as to what extent an enterprise adopts mobility

and implements mobile systems. This varies depending on

where the enterprises position themselves on the enterprise

mobility continuum (Figure 1). From simple point-solutions

like e-mail to fully mobilizing the workflow, the

implementations differ in how they should be realized and

how they affect the business and its workers.

Basole (2007) describes the tasks and processes commonly

being made into mobile systems by enterprises. Mobile

applications for basic processes such as e-mail and personal

information management tools (calendars, contacts etc.)

have been in use for a long time, and can by this point be

argued to be ubiquitous. The current challenge lies in

developing more specific applications that connect the

workers to business-critical data and processes. According

to Basole (2007), the types of applications most commonly

being made into mobile systems are enterprise resource

planning (ERP), customer relationship management

(CRM), supply chain management (SCM), and knowledge

management (KM). Which type of application an enterprise

needs depends on the needs of its workers, e.g. sales people

versus storage workers.

Balocco, Mogre, and Toletti (2009) take a further look at

what types of mobile applications have actually been

developed by enterprises. Their study builds on previous

research through a survey of 646 Italian businesses in the

manufacturing industry and case studies of 28 of these.

Focusing on the adoption of mobile applications, they

found that most applications adopted targeted sales force

optimization (44.5%). However, most applications used

were “very simple”, i.e. did not support too advanced tasks

and were very basically integrated with the systems like

ERP systems already used by the enterprises. This may well

be due to the fact that before 2009, smartphones and mobile

internet use were not nearly as ubiquitous as they are today

(the devices reported as used in the case study are PDAs

and laptops).

The findings of Balocco et al. (2009) show that the

applications used support the information processing- and

receiving operations described in previous research (Basole,

2007; Brans & Basole, 2008), although not necessarily in

one single application. Despite the fact that their study only

seems to include PDAs and laptops, their general

conclusions regarding how mobility affects the workforce

and workflow should theoretically hold true for

(successfully implemented) smartphone applications as

well.

A more recent study (Picoto et al., 2014) found that mobile

enterprise applications usually bring value to the enterprise

in several different ways. For internal operations, most

participants stated that their mobile solutions reduced

administration workload, improved employee effectiveness,

increased staff productivity and made internal operations

more effective, to mention a few. Portability and instant

connectivity are mentioned as unique characteristics of

mobile technology, allowing the workforce to work

anywhere and at any time, providing increased productivity

and increased staff motivation. The authors also confirm

that companies that already have technology in place such

as intranets and competence for IT systems within the

company can make greater use of mobile applications.

Developing for enterprise mobility

A common critical inhibitor for adopting mobile enterprise

applications is a lack of resources, both economical and in-

house competence (Brans & Basole, 2008; Picoto et al.,

2014). Since applications are often tailor-made by third-

party developers for one customer at a time, the

development costs are high as everything has to be redone

for each application. Brans and Basole (2008) give several

reasons for this, basically referring to how enterprises differ

regarding both back-end systems and work processes, as

well as a lack of general knowledge of how to adopt a more

mobile workflow. The existing internal systems of an

enterprise may be distributed over disparate services

provided by different companies. While resources may exist

within the company to manage these systems, the expertise

to develop mobile applications often does not.

The term “software reuse” has been used to describe the

identification, categorization and appropriation of software

components, ranging in detail from ready-to-use modules to

more general descriptions of functionality. As Krueger

(1992) describes the term itself was originally coined in a

paper by Douglas McIlroy in 1968, but has since

2

Figure 1: The Enterprise Mobility Continuum (Basole, 2008)

incorporated an adaption of the concept of design patterns,

introduced by Christopher Alexander in the field of

architecture (Homann, Wittges, & Krcmar, 2013).

The motivation behind software reuse is to make

development more efficient and less error-prone by using

established solutions to known problems instead of

developing new solutions from scratch for each software

project. It was born from the insight that many applications

share a lot of functionality and often provide solutions to

similar tasks (Krueger, 1992).

Brans and Basole (2008) investigate enterprise mobility

from the perspective of software reuse, while also taking

into account “the forces shaping mobile enterprise

applications development, adoption, and implementation”

(p. 2). They list the ways in which mobility provides value

to an enterprise, as well as the needs of mobile workers.

They also establish that information, and how that

information is provided to the user, is an essential part of

mobile applications, and go on to list four basic types of

interaction with the information: read (retrieving

information, e.g. price of a product), create (e.g. new sales

order), update (e.g. a checklist when doing inspections) and

alert (e.g. receiving instructions or orders while in the

field).

Frakes (2005) points out that software reuse is integral to

domain engineering (aka product line engineering), i.e.

when an organization mainly builds software systems

within a certain domain. This is examined by Homann et al.

(2013) in their survey of 20 Enterprise Resource Planning

(ERP) smartphone applications, all by the same vendor,

SAP. Their focus is on identifying UI design patterns to

simplify the mobilization of enterprise applications.

Desktop ERP- and other enterprise applications typically

have too complex GUIs for them to be directly converted

into smartphone applications. Tab views, windows, tables

and other elements commonly used in desktop applications

need to be substituted with modes of interaction more

suitable for smartphones, in order for the smartphone

applications to be usable.

By looking at existing ERP smartphone applications,

Homann et al. (2013) capture user interaction as task

models, notated using ConcurTaskTrees (CTT) (Patemo,

2000). Their research confirms Brans' and Basole's

(2008) findings that mobile ERP applications are largely

focused on processing business objects (e.g. customer-,

material- or sales order objects) through some operation

(e.g. create, read, update, delete). Selection-presentation-

interaction is identified as a common structure for how ERP

applications typically allow interaction with business

objects; users perform tasks by navigating from an

overview of object types by choosing one (selection),

getting a list of all objects of that type (presentation), and

lastly selecting one of them for a more detailed view that

allows some operations on the selected object (interaction).

Furthermore, they identify which business objects are being

processed and identify recurring tasks such as “Select

business object type” and “Display business object

Attributes”. Their intention is to use this information,

combined with the identified workflows, to create a set of

design patterns for the GUIs of enterprise smartphone

applications; however, the tasks and processes they identify

are a valuable contribution to the set of knowledge about

important features in mobile enterprise applications

regardless of how they are supported by the GUI.

While some have argued that broad and strategical

implementations of mobile technology provide the greatest

benefits to an enterprise (Basole, 2008), others show that

integrating mobile technology with existing systems has a

substantial impact on a range of factors, thanks to the

unique features of mobility itself (portability, accessibility,

connectivity etc.) (Picoto et al., 2014). Mobile enterprise

applications can be adopted successfully, providing added

value, by companies on different parts of the enterprise

mobility continuum. Several companies described in

(Picoto et al., 2014) have deployed smartphone applications

developed “on top” of their existing systems, rather than

completely transforming into a mobile enterprise.

By studying application structures and the companies'

motivations and intentions for going mobile, this paper

aims to give a more detailed, qualitative account of

companies' development and adoption process of mobile

enterprise applications. Identifying development obstacles

and needs, as well as discussing application content and use

cases with key persons and the companies, will help answer

the research question guiding this paper: how do new

smartphone applications fit into existing systems to provide

added value to companies?

The answer to this question may inform both how mobility

itself can be used as an advantage, and how future

development can be made easier and more effective through

software reuse and design patterns.

METHOD

The research presented in this paper is a case study of two

companies, containing analyses of the mobile enterprise

applications (apps) developed for internal use, as well as the

companies’ development process and view on the adoption

of mobile systems. The companies in this study were 1) a

large association of financial institutions having used an

internal app for some time, and 2) a major theater in

Stockholm currently developing and testing an application.

Methodological triangulation was used to ensure a detailed,

encompassing study: the applications were analyzed

separately to identify tasks and processes, and interviews

were conducted with key persons at the company

developing the apps and at the clients the apps were

developed for.

The applications were analyzed using the task analysis

approach described in (Patemo, 2000), which introduces the

term ConcurTaskTrees (CTT). Using CTTs provides a

3

structured way of describing an application in terms of

tasks and subtasks. Tasks are identified and extracted from

applications by the researcher, and can be defined as being

either user-, application-, interaction- or abstract tasks,

depending on how the task is performed. For example,

sorting a list is an interaction (sub-)task while comparing

elements in it would be a user task. CTTs also contain

information about temporal relationships between tasks,

types of tasks (ranging from cognitive user activities such

as comparing (e.g. elements in a list), to more concrete

tasks such as selection), and which objects are being

manipulated when performing a task. The result is a tree-

like description of the tasks that are supported by the

application. The analysis of the apps in this study was done

with the CTTs tool1 and tasks and the information objects

they operate on was cataloged in a way similar to that in

Homann et al. (2013), in order to make the findings easily

comparable to previous research.

This type of task analysis is a way to perform an evaluation

of a finished artifact that focuses on what services a given

application provides, in contrast to user evaluations which

aim to assess how well it achieves this with regards to the

user. Since this paper focuses less on the usability of the

apps than their intended use cases, CTT is a suitable method

to define tasks in a standardized way that enables

comparative analyses, and it has been used successfully for

this in the past (Homann et al., 2013; Patemo, 2000).

To get a more nuanced view of the apps and how they are

used, semi-structured interviews were conducted with key

people from the client companies and from the company

developing the apps. While the apps themselves give good

indications of which services the companies intend to

provide, interviews can provide more detailed information

on related topics, further explaining both the design of the

apps and the companies’ perspective on mobile enterprise

systems. Questions asked covered topics such as why the

features in the apps are there, are there any features that

would be desirable to add, what was the company’s

motivation for going mobile, and how have the mobile apps

changed the workflow and the company? The answers to

these questions will contribute to the overall understanding

of the current needs in mobile enterprise systems and how

they have been adopted by the companies.

By comparing and combining the results from the

interviews with the formal CTT-based descriptions, I'd be

able to discern what companies are currently doing, as well

as their future wants, compare it to previous research and

hopefully formulate some general assumptions of what

enterprise mobility looks like today.

Two companies were studied: a Scandinavian association of

monetary institute and a large Swedish theater. The

association of monetary institutes had been using their app

for a couple of months, whereas the theater was near the

1 ConcurTaskTrees Environment: http://giove.cnuce.cnr.it/ctte.html

end of the development process and had not yet deployed

the app to all employees. The interviews were conducted in

person with the head of the theater's IT department, and the

IT consultant at the association of monetary institutes was

interviewed by email - these persons were the ones most

familiar with the apps and their development. Both

companies were clients of the same Stockholm-based

startup company specializing in developing smartphone

applications for enterprises, and contact with the clients was

established via the developing company. Interviews with

the founder and marketing director at the company that

developed the app were also conducted to provide

additional material.

RESULTS

The results of the study will be presented case by case, i.e.

one company at a time. For each case I will first give a

thorough description of the current state of the application,

its supported tasks and layout; this information was

gathered mainly by analyzing and describing the apps as

CTTs. I will then present the information I gathered from

the interviews. The results section is finally concluded with

a short comparison of the applications.

Case 1 – An association of monetary institutes

The first mobile application looked at is used by an

association of monetary institutes, and have been in use for

a couple of months. At the time of the study, the association

was comprised of around 70 local banks, savings banks and

cooperative banks, employing about 8350 people in total

and operating in Denmark, the Faroe Islands and

Greenland. Its objective is to provide means for smaller,

local banks to cooperate, help each other with common

problems, and use the association as a unified body to

influence the financial sector. The function of the app is to

provide members with easy access to the information

provided by the association: the other member banks and

their managers, upcoming events for members and contact

information about the people working at the association.

Application structure

The application uses the common selection-presentation-

interaction structure mentioned previously. Upon logging in

with a pin code, the start page allows the user to pick from

four options: Managers, Banks, Events or Contact

Information.

Managers: Under Managers, the user is presented with a

list of all managers of the banks in the association, sorted

alphabetically (see Figure 2a in the final section of the

results). They are presented with name, title, the bank they

represent and a portrait photo. In this view it is possible to

search for a member by name or go to a certain position in

the list (A-Z). Upon selecting a manager, the user is

presented with more information about the manager and the

bank (such as e-mail address, phone number and website).

From this view, it is possible to call or email the selected

manager or bank.

4

Banks: This section is similar to Managers, only the

information presented is all the banks in the association:

their name and the name of the manager. As in Managers,

the list is sorted alphabetically and can be filtered with a

search function. Upon selecting a bank, more detailed

information is presented, such as address, email address,

phone numbers and the website, allowing the user to

contact the bank.

Events: The Events section presents a list of upcoming

events relevant to the members of the association. The list

view shows the event title, duration and a photo; the

detailed view shows a description, the location and a button

to open the location in an external maps application.

Contact information: This page simply shows the contact

information for the association; its address (with a button to

show it on a map), as well as its employees with names,

title and a photo.

Objects

Table 1 shows the information objects being operated on in

the application. Contacts and banks are stored in the

existing intranet of the association; events and general

information is managed in an external tool provided by the

app developer.

Object Properties

ContactFull name, phone numbers, email address,

website, associated bank, title, address, photo

EventTitle, start-/end date and time, photo, description,

address, location

Business

partner (bank)

Name, address, phone numbers, website, manager

(Contact)

General

informationGeneral information text (e.g company info)

Managed in: Intranet Tool provided by developer

Table 1: The information objects in application 1 and their

properties visible in the app. The color of the rows denote

where the data is stored and managed.

Motivation and development

The purpose of the mobile application is to make it easier

for members to access information about the association,

and the other members. It contains contact information to

all other members and their managers, the members of the

board of the association, as well as upcoming events such

as members’ meetings. As the IT consultant at the institute

put it, “The app is developed for the member-banks’ bank

managers, in order for them to have easy access to contact

information at hand.”

The choice of a mobile app as opposed to other solutions

was mainly motivated by accessibility for the users and

being able to change the content for the administrators. The

small, local banks in the association do not typically share

an intranet. Communication between them, and to the

association itself, was done by finding contact information

either through the association’s website or reading the

pamphlet distributed annually by the association. The

advantages of an app were, according to the IT consultant,

that they are portable and therefore always carried by the

managers, and that the data in the app can be updated

immediately. The address book information displayed in

the app is managed in the already in-place internal software

platform used by the association, and is simply imported

and displayed by the app. The events are created and

managed through a system provided by the app developer.

When updates are made to the data, information

automatically migrates to the app.

The marketing director at the developing company also

emphasized availability as an important value. While the

app may not provide much more sophisticated functionality

than a typical address book app, it is an “easy, efficient,

secure way to perform short, simple, defined tasks”. It fits

into the smartphone ecosystem as any other app, and is

easily accessible through a simple log-in with a pin. In

short, its “power” lies not in any specific innovation, but in

the fact that it is an app.

Future features

At the time of this study, there were no plans from the client

to include more advanced forms of interaction or provide

means for user-generated content. When asked about it,

social features such as a message board is “an idea that

could be worthwhile pitching - someday” - but not highly

prioritized as of now.

Case 2 – A large theater

The second application in this study was currently under

development by a major theater in Stockholm. The purpose

of this app is to make it easier to manage the large number

of casts, crews, productions, shows and venues that the

theater has to deal with, as well as the complex

relationships between these parts - who is working on

which production, where is the show and when are the

rehearsals? It also contains general information useful to

employees and actors. It had not yet been deployed for wide

use among the whole staff, but was at the time of this study

being tested by a reference group composed of employees

from key groups, such as technicians, stage managers and

actors.

Application structure

The application generally follows the selection-

presentation-interaction structure. The user logs in, and is

presented with the start menu showing buttons for My

schedule, Productions, Locations, Address book, News,

Contact information, Restaurant menu and Feedback.

This app contains a functional menu that allows for more

complex navigation to and between different views and

5

information objects. For example, the view for interacting

with a specific production can be reached both from My

schedule, Productions and Locations. In these cases, the

detailed view will be described in the following list under

its primary section, e.g. the detailed view for a production

will be described under Productions.

My schedule: This section shows upcoming events for the

current user, sorted chronologically. The events are related

to the production the user is currently involved in (either as

actor, crew, or similar), with a shortcut button to the current

date (see Figure 2b in the final section of the results). The

information provided is the title of the production, location,

duration, and type of event (e.g. make-up or show). When

an event is selected, a list of smaller time slots within the

event is shown (e.g. “Johan has makeup 10:00-10:25”).

From here, the user can navigate to the production related

to the event or the location where it will take place.

Productions: This sections shows current productions in an

alphabetically sorted list. The production’s name, premiere

date and location (venues and stages) is shown in the list.

Selecting a production leads to its detailed view. Here, the

user can show upcoming events in a similar fashion to

under My schedule, and choose to show either all events, or

only shows or rehearsal. Selecting an event here displays a

list of the cast and crew working on this production, and

gives the user the option to go to the detailed view for its

location.

Locations: This section deals with the different locations in

and outside of the theater. Again, all locations are displayed

in an alphabetically sorted list containing stages, rehearsal

rooms and other locations. Selecting a location in the list

brings up the schedule for that location like in My schedule.

Selecting an event in this list will display a list of all the

cast and crew working on this production, and gives the

option to go to its detailed view.

Address book: This view is a list of people working at the

theater. It is searchable by name and shows each person’s

name, profession, phone number and email address.

News: This view shows the latest internal news for the

employees, edited by the administrative staff.

Contact information: This view shows contact

information such as the visiting address (and a button to get

directions in an external maps application), email address,

various phone numbers, website and opening hours.

Restaurant menu: This view is simply the current week’s

menu for the staff restaurant.

Feedback: This page contains a form to send feedback and

bug reports to the app developers. There is an option to

attach a screenshot.

Objects

Table 2 shows the information objects being operated on in

the application. Contacts are stored in an address book

system; events, productions and venues are stored in the

scheduling system; general information is managed through

an administration tool provided by the developer.

Object Properties

Contact Full name, phone number, email address, profession

Event Title, start-/end date and time, type, location

Production Name, premiere date, location, cast and crew, events

Venue/location Name, events

General

information

General information text (e.g opening hours,

restaurant menu, info texts)

Managed in: Address book Tool provided by developer

Scheduling system

Table 2: The information objects in application 2 and their

properties visible in the app. The color of the rows denote

where the data is stored and managed.

Motivation

While there had been talk about setting up a proper intranet

for the last 10 years, the theater had at the time of this study

been involved in developing a smartphone app for around

five months. While an intranet of any kind would be helpful

to provide a common platform for all the different

administrative systems currently in used, the IT department

decided to focus on a smartphone app first.

The main reason according to the head of the IT department

was that not all of the intended users used computers

regularly. They (mostly actors) were not tech-savvy (“some

of them don’t even have computers”) and only used their

smartphones for communication. A smartphone application

would be the only way to communicate with these

employees in a way that, as far as possible, guaranteed they

would receive important information. Another reason was

that the most important administrative systems were already

in place and had been in use for a long time. Creating an

app to present the information in these systems in a usable

way would be faster and provide more immediate value

than setting up and integrating a more extensive intranet

would.

The app is intended to substitute some less-than-optimal

solutions already in place, the most crucial one being how

to communicate the schedule to the staff. The schedule is

administered in a scheduling system that has been in use for

around seven years. Administrative staff plan and edit the

schedule for all employees, and it can be accessed in a

couple of ways: the schedule is printed once a week and put

up on message boards; the schedule for each week is

displayed on TV screens distributed around the offices; and

staff can call in and listen to an answering machine playing

6

an audio loop recorded the same day, of the schedule for

that day being read by an administrator.

The app makes the schedule accessible anywhere at any

time, less cluttered for each individual (as different actors

and other staff have different schedules, in the old systems

all being showed at the same time) and “allows the actors to

take responsibility for knowing their work times”. It also

gives actors greater freedom, as it is not uncommon for

them to be scheduled to work 8-12 (e.g. for rehearsal),

while they actually only need to be present at the theater

between 9 and 11, something which is shown in the app.

Development

The interviews also provided some insights into the

development process and some of its challenges. The app

project was initiated by a project group at the theater, which

formulated a specification for the company that was hired

to develop the app. The developer and the client, as well as

the developers for the scheduling and address book

systems, have communicated continuously during the

development.

It was the outspoken intention of the client that the app

should mainly function as a tool for accessing and

presenting data from the already existing systems. That the

app developer did not administer or control these systems

was problematic at some points. For example, the schedule

system was not properly configured to be queried by the

app as often as necessary without being overloaded. This

led to a bespoke solution where data is being “dumped”

from the schedule service to server owned by the theater,

which is then queried by the app instead. This data is then

parsed and displayed in a user-friendly way.

This example highlights the different needs of the creators

and receivers of data, in this case administrative staff and

other theater staff. The needs of the receivers should not

affect how the creators work, and vice versa: the developer

noted that “It was important that the app could grow with

the data sources” and that the underlying systems could

change without affecting the user experience. This was also

pointed out by the theater's developer. An event in the

scheduling system could have different names meaning the

same thing. A show, for example, (in Swedish

“föreställning”) could in the scheduling system have titles

such as “FST”, “FST dag”, “Föreställn.”, “textas”, but

rather than merging these descriptions into one in the

schedule, the app defines how the events should be

presented. The developers did not “want to create new

information in the app” and thought it “very important that

the main system ‘owns’ the information”.

Although the app has not been deployed to all employees as

of this study, it has been used and evaluated by a reference

group consisting of different key people working at the

theater - actors, producers, stage crew, stage managers,

technicians, artists etc. They have so far met three times,

and had commented on “everything from background

colors and fonts to more advanced features”.

Future features

Although not yet implemented at the time of this study,

individual push notifications is an important feature

planned for future versions. Administrative staff should be

able to make changes to the schedule, which are broadcast

to the affected employees. For example, if an event changes

location or gets canceled, the people scheduled to attend

that event get notified. The key challenge at the time of the

study was how to allow administrators to send notifications

only to affected individuals or groups. This was problematic

for the app developers both because of the lack of a

specialized way of sending push notifications and because

of the need to combine information about user roles and

groups from the schedule and address book.

The IT department plans to incorporate a more full-fledged,

traditional intranet at some point, mainly to support

“creating and sharing documents". They do not intend to

put this functionality in the app, but the idea is that the app

should be connected to the documents in some way. The

app is not intended to become a mean for administration in

itself - “it serves as support for the existing systems”.

However, the app could very well incorporate a way for

employees to perform things like time reporting and

reporting sick days. “A good way to submit forms is

something we would really need”, and simple forms to fill

out are suitable for an app (Brans & Basole, 2008) (these

tasks are currently done through various systems with

notes, forms and sheets). The administrative system would

probably be implemented in the intranet first, with mobile

support added later.

Task analyses and app comparison

Table 3 shows a compilation of the information objects,

equivalent to business objects in (Homann et al., 2013), and

tasks, the notation for which has also been borrowed from

the same study. Objects and tasks common to all

applications are marked with an asterisk.

As can be seen in Table 3, while the two applications are

fairly simple regarding the number of different data types

they operate on (especially application 1), they share a set

of basic tasks for accessing and filtering information

objects.

Overall, the applications conform to the user interface

patterns identified in previous research, both regarding to

interaction design (Homann et al., 2013) as well as use

cases and the value they provide to the companies using

them (Balocco et al., 2009; Basole, 2007). Both

applications use the same selection-presentation-interaction

structure to allow a logical way of navigating from an

overview to more detailed information (Figure 2).

The main goal of the applications is to make large,

sometimes complex, sets of data easily accessible. The

underlying structures of the apps are thus similar: they both

7

Application Information objects Tasks

1

- Event*

- Contact*

- Business partner

- General information*

- Select business object type*

- Get list of all business objects*

- Search for business objects by

attribute value*

- Filter business object list by

attribute value*

- Display business object

Attributes*

2

- Event*

- Contact*

- Venue/location

- Production

- General information*

- Select business object type*

- Get list of all business objects*

- Search for business objects by

attribute value*

- Filter business object list by attribute

value*

- Display business object Attributes*

- Navigate to related business objects

Table 3: The identified information objects and supported tasks in the reviewed applications. An asterisk indicates that object/task

occurs in all applications.

integrate different systems into one application to provide

their users with easier access. Since the two applications

come out of two completely different user contexts, and

deal with different types of data as perceived by the users

(e.g. a bank compared to a theater stage), they have very

different use-cases and diverge superficially – despite

sharing data- and task-related problems and solutions.

Instead of replacing already existing systems or being part

of a large-scale transformation to a completely mobile

enterprise, both apps were developed primarily as a way to

provide easier access to systems and data used by the

companies.

Both people in charge of the app projects at the companies

cited availability and connectivity as primary reasons for

choosing smartphones as their platform for a new system.

The tasks should be able to be performed quickly and at any

time, with as little effort as possible. In the theater case, the

fact that smartphones was almost the only communication

medium used by some employees also made it more

suitable than a traditional, desktop-based system.

Buying and incorporating a new, extensive intranet was

thought to be more complicated than an app that could

deliver useful services sooner. Both companies had most or

all of their content already available in systems that had no

useful interface for the intended recipients of the content,

being primarily tools for administration. They lacked a

user-oriented way of accessing the data, which the apps

provided by integrating the output of different systems and

mapping it to a user-specific presentation.

To summarize and tie back to the research question (how do

new smartphone applications fit into existing systems to

provide added value to companies?), similar problems were

faced in both development processes: unique user needs

regarding what should be presented and how (although not

unique to these kinds of products); mapping data from

existing sources to a new interface; integrating data from

several sources into one cohesive app; and obtaining third-

party expertise for app development. As for the added

value, both companies mentioned availability and

connectivity as the most important aspects of their mobile

applications.

DISCUSSION

Smartphones are arguably becoming a, if not the, primary

tool for mediated communication. Their ubiquity and

accessibility at all times makes them perfect for both

accessing and transmitting data efficiently, and the fact that

they are “always on” makes them suitable for short, focused

interactions. As employees start wanting to use their

smartphones for a wider range of tasks and cannot be

“forced” to use traditional intranets (if these are even used

at the company), the challenge becomes how to support

these tasks in smartphone applications. By looking at

companies currently tackling these challenges, this study

provides information on typical problems faced, and user

needs garnered from real situations.

Previous research about the adoption of mobile enterprise

systems often talk about the management being a hindrance

to successful mobility, by having an incorrect understanding

of mobile computing and mobile enterprises (Basole, 2007;

Picoto et al., 2014). For instance, Basole (2007, p. 7) claims

that “the most complicated issues are related to managerial,

8

a)

b)

Figure 2: This series of screenshots show the similar

navigation in both apps (Figure 2a shows how to find

managers in app 1; Figure 2b shows “My schedule” in app 2).

From start screen (selection) to a set of objects (presentation),

and lastly a detailed view of the selected object (interaction).

strategic and organizational factors”, and cites lack of

management awareness as a key inhibitor. Although the

goal of the companies in this study is to create rather simple

apps as opposed to transforming their whole enterprises into

mobile enterprises (something I will return to later in this

section), the management all seemed to be aware of the ad-

vantages of mobile enterprise apps. They also seem to agree

on the path to mobile enterprise success being as described

by Basole (2007, p. 7): “matching mobile enterprise users

to the right enterprise functions and processes”. While the

competence for developing apps may not have existed at

the specific companies, the understanding of the

improvements an app could bring certainly did.

The cases presented in this study also reinforce the idea that

connectivity and availability are important and valuable

aspects that set mobile applications in particular apart from

traditional systems (Balocco et al., 2009; Brans & Basole,

2008), something that was mentioned as a key reason for

choosing a mobile app by both of the companies studied.

There are also some points to be made on how the apps in

this study fit into the already existing systems used

internally at the companies. None of the companies studied

intended the app to replace any existing underlying,

administrative system already in place. The apps were

instead created to function as tools for presenting data,

integrating existing, disparate sources of data to a

meaningful whole. This is a small-scale example of the

power of mashup applications (Daniel et al., 2007; Liu et

al., 2011), combining different services to create a new type

of service, and is probably the most likely way for small

enterprises to successfully create internal applications; let

the different parts (schedule, address book etc.) be managed

by specialized services (that should provide application-

friendly interfaces for interacting with data) and integrate

these services in a way that benefits the users.

This means that the examples presented here can not quite

be considered “mobile enterprises”, i.e. they are not

positioned towards the far right on the mobile enterprise

continuum. Restrained by the need to keep existing systems

not necessarily intended to be used as services by a mobile

app, adding an app to the work environment meant

additional challenges to make this work.

It can however be argued to show the benefits of software

reuse in this area, and point to where software reuse should

be applied. Seeing as both applications in this study mapped

similar data and services to completely different interfaces

and use-cases, reusable components would be beneficial

both for converting the output of many diverse services as

well as mapping arbitrary data to mobile apps designed to

support the common mobile enterprise app tasks (e.g.

according to the selection-presentation-interaction pattern).

Below is a collection of observations and guidelines for fu-

ture developers and stakeholders. Although they are based

on related research and the results presented in this paper,

they are not to be considered part of the results but should

rather be read within the frame of the discussion:

Design for mashup and integration — Developers of

systems intended for internal use at companies, e.g. admin-

istration tools, scheduling, contact databases etc. should

provide easy access to the stored data through usable APIs.

Allow for users to attach new interfaces by assuming that

the system will be used as an information-oriented service

at some point in the future (i.e. support at least read, create,

and retrieve).

Adopting a smartphone application does not necessarily

mean transforming the whole enterprise — Assuming the

internal systems already in place have sufficiently good

APIs, a new smartphone app can increase the value of these

systems by integrating their services to form a more useful

service in itself. The existing systems can be kept and used

by administrative staff (for example) as before, while their

data can be used by other types of employees for other

purposes.

Great value from simple apps — Perhaps one of the most

interesting findings was the high return from relatively

basic apps. Availability, connectivity, and the ubiquity of

smartphones is an advantage in itself - apps and services

developed for the platform are more “valuable” simply

because they can be used where- and whenever. They do

not necessarily need to provide more sophisticated

functionality than retrieving and presenting information.

Like the previous point, this may be an important factor for

enterprises planning to adopt a more mobile workflow.

The mobile enterprise is still a holistic concept — Mobility

is a trend with no apparent diminution in the near future.

While simply “adding” a mobile application to existing

systems can provide some immediate value, building or

acquiring new internal applications should be done with

mobility in mind, in order for an enterprise to fully be able

to reap the benefits that mobile apps bring.

Limitations of the method

With only two data-points, this study is fairly limited in

scope which has the possible effect of making the results

less generalizable. I have attempted to alleviate this by

collecting qualitative data describing in as much detail as

possible the processes and motivations of the companies

studied. My specific findings correspond well with previous

research, indicating that the problems identified in this

study can be considered general problems common to

companies adopting mobile applications.

The companies studied were both contacted via the

developer of their applications. The fact that they share the

same developer likely explains the similar design of their

applications, but through my interviews I found that the

contents of the apps were mainly decided by the clients.

They performed their own user studies, wrote their own

feature specifications and forwarded this to the developers.

Thus, although the developer was responsible for

9

implementing the GUI and solving technical difficulties, the

end products are largely the results of the client companies

visions, rather than the developer’s.

Future research

For future research it would be interesting to take a look at

companies who have more extensively adopted and

integrated mobile systems. How are large-scale mobile

enterprise systems developed, and how does a fully

integrated mobile workflow affect companies compared to

partially mobilized internal systems? Are there additional

values that can be realized, for example improved

communication between employees?

Future developers should also focus on providing ways of

integrating separate services and sources of data to facilitate

the common practice of creating mashup applications.

CONCLUSION

Although the number of smartphones in use have exploded,

enterprises struggle to keep their internal systems up to date

with the current technology, missing out on potential

improvements of their organizations. This paper presents a

detailed look at two companies currently in the process of

adopting mobile enterprise applications.

The findings presented suggest that small efforts to develop

mobile applications can give a large return to the company.

The apps included in this paper were relatively basic and

did not allow for editing or adding new information to the

system. Rather, due to the unique properties of mobile

technology, mobile enterprise applications increase the

availability of a company's information and the connectivity

of its employees.

To support the transformation of companies to mobile

enterprises, however, their internal systems need to allow

for easy integration with mobile technology – something

that the enterprises themselves and providers of enterprise

systems both need to take responsibility for.

REFERENCES

1. Balocco, R., Mogre, R., & Toletti, G. (2009). Mobile

internet and SMEs: a focus on the adoption.

Industrial Management & Data Systems, 109(2),

245–261.

http://doi.org/10.1108/02635570910930127

2. Basole, R. C. (2007). The Emergence of the Mobile

Enterprise: A Value-Driven Perspective. In

International Conference on the Management of

Mobile Business (ICMB 2007) (pp. 41–41). IEEE.

http://doi.org/10.1109/ICMB.2007.63

3. Basole, R. C. (2008). Enterprise mobility:

Researching a new paradigm. Information

Knowledge Systems Management, 7, 1–7.

4. Brans, P. D., & Basole, R. C. (2008). A comparative

anatomy of mobile enterprise applications: Towards

a framework of software reuse - Information,

Knowledge, Systems Management - Volume 7,

Number 1-2 / 2008 - IOS Press. Information,

Knowledge, Systems Management, 7(1-2), 145–158.

5. Chung, S., Lee, K. Y., & Kim, K. (2014). Job

performance through mobile enterprise systems: The

role of organizational agility, location independence,

and task characteristics. Information & Management,

51(6), 605–617.

http://doi.org/10.1016/j.im.2014.05.007

6. Daniel, F., Yu, J., Benatallah, B., Casati, F., Matera,

M., & Saint-Paul, R. (2007). Understanding UI

Integration: A Survey of Problems, Technologies,

and Opportunities. IEEE Internet Computing, 11(3),

59–66. http://doi.org/10.1109/MIC.2007.74

7. Frakes, W. B. (2005). Software reuse research: status

and future. IEEE Transactions on Software

Engineering, 31(7), 529–536.

http://doi.org/10.1109/TSE.2005.85

8. Homann, M., Wittges, H., & Krcmar, H. (2013).

Towards user interface patterns for ERP applications

on smartphones. In Business Information Systems

(pp. 14–25).

9. Krueger, C. W. (1992). Software reuse. ACM

Computing Surveys, 24(2), 131–183.

http://doi.org/10.1145/130844.130856

10. Liu, Y., Liang, X., Xu, L., Staples, M., & Zhu, L.

(2011). Composing enterprise mashup components

and services using architecture integration patterns.

Journal of Systems and Software, 84(9), 1436–1446.

http://doi.org/10.1016/j.jss.2011.01.030

11. Michels, D. (2013). BYOD’s Productivity Gains Are

“Hard to Calculate”, Study Says -. Retrieved March

1, 2015, from http://www.ucstrategies.com/unified-

communications-newsroom/byods-productivity-

gains-are-hard-to-calculate-study-says.aspx

12. Millman, R. (2013). Surge in BYOD sees 7/10

employees using their own devices. Retrieved March

1, 2015, from

http://www.itpro.co.uk/mobile/19944/surge-byod-

sees-710-employees-using-their-own-

devices#ixzz31cNhd9ul

13. Patemo, F. (2000). Model-based design and

evaluation of interactive applications. Springer-

Verlag London Limited.

14. Picoto, W. N., Bélanger, F., & Palma-dos-Reis, A.

(2014). An organizational perspective on m-business:

usage factors and value determination†. European

Journal of Information Systems, 23(April 2014),

571–592. http://doi.org/10.1057/ejis.2014.15

10

TRITA -EECS-EX

www.kth.se