migrating operational spreadsheets to the cloud with force v2

8/6/2019 Migrating Operational Spreadsheets to the Cloud With Force v2

1/9

www.silvertreesystems.com

Migrating Operational Spreadsheets to the Cloud

With Force.com

Executive Summary

Spreadsheets are often used to build a class of applications that are

fundamentally ill-suited to the spreadsheet model. The reason for this is

that there has been no other way to build these types of applications, since

IT is not geared up to build small, quick, rapidly changing situational

applications. Besides not having the resources available, the cost of having

IT build (and deploy) them is likely to be prohibitive.

But with the advent of Cloud Computing platforms, there is an

alternative. In the Cloud, IT is no longer the sole owner of production

(development teams) and delivery (the data center). Custom applications

can be built much faster using less skilled resources, and deployment

concerns like servers and backup are virtually eliminated. In addition, these

applications can leverage the kind of functionality and resource that is only

available in the Cloud, like social networks and access to massive storage on

demand. Lastly, using a database-driven platform can address the single

source of truth question that plagues every organization using

spreadsheets for operational applications, by providing a centralized

repository of validated, consistent and high quality data.

While this gives business units the ability to build solutions on their

own, IT departments can play a championing role, educating business users

on how to take advantage of situational application capabilities in the Cloud,

without getting bogged down in traditional application development and

deployment. IT can also provide the guidance business people need so they

wont create havoc, and help them stay out of compliance ( e.g. Sarbox) hotwater.


2/9


Introduction

It is rare for a core software application to support an organizations entire gamut of activities

and needs. This is especially true when things change over time, and when organizations need to

react quickly to take advantage of an opportunity or face down a challenge. This leads to gaps

between the organizations needs and the systems capacity to fulfill them.

As a result, most companies use spreadsheets to fill these gaps. Typical examples include

employee timecard tracking, pricelists for wholesale vendors, defect tracking, pipeline forecasting,

production planning, project management, sales data collection, bonus calculations, and so on.

Unfortunately, once a spreadsheet is created, it is often assumed that it will be replaced shortly

after with a fully architected system. In fact, many of these temporary spreadsheets may be used

for years, becoming more difficult to manage as time goes by. And as business processes mature,

requirements become more complex, the need to scale across multiple users and departments

increases, the liability of spreadsheets become a significant liability.

Just because users can use spreadsheets to build these types of applications, doesnt mean that

they should. Indeed, most of these applications would be better suited and more valuable to the

organization if they were built on a database platform instead of a spreadsheet.

Until now, it has usually been too costly and time consuming for IT to build these applications

using traditional application development techniques. Hence these projects never make it high

enough in the IT priority list to ever be done. So they end up in a state of spreadsheet purgatory.

But the advent of Cloud Computing is changing this. Firstly, cloud-based platforms as a service

are making the development of these types of applications much faster and cost effective; and

secondly, it is becoming imperative that many of these applications are migrated to the Cloud so

they can take advantage of the services provided by cloud-based platforms, including Web services

for data mashups, participation in cloud-based workflows, and providing access through mobile

devices.

Modeling versus Operational Spreadsheets

In the corporate world, spreadsheet use is basically divided into two categories: modeling and

operational. Spreadsheets created for modeling purposes act as complex calculators and address a

particular activity, like mergers and acquisitions. Spreadsheets created for operational use support

transactional processes, thus becoming core business systems.


3/9


Differences between modeling and operational spreadsheets include:

Modeling Spreadsheets Operational Spreadsheets

User(s) Single. Built and used by the

same individual most of the

time.

Multiple. Built by a power user

or IT for corporate-wide use.

Duration of use Short term. Spreadsheet

models, often complex, are

built for days or weeks only to

be redundant after the

relevant business decision is

made.

Long term. Spreadsheet

models, both simple and

complex, become part of the

business' information flow and

persist for months or years.

Structural and

Functional

Volatility

High. Substantial structural

revisions are likely to occur

from one day to the next as

major elements are added or

replaced.

Low to medium. All key

structural elements are likely to

be in place. Further evolution of

the business process requires

spreadsheet maintenance, with

rare structural overhauls

Data Volatility Medium. Data are related

primarily to the exploration of

alternative scenarios.

High. As the application

matures, transactional data

become key spreadsheet

variables.

Use Intensity Intensive. Use is likely to beintensive for a short period of

time, and the knowledge of

the spreadsheet's structure

among its users is retained

throughout its life.

Sporadic. Use depends on thenature of the business process

being supported. For example,

many spreadsheets in financial

reports are used at the end of

the month. This means

employees may forget how to

use key spreadsheet functions

Symptoms of the Problem

Operational spreadsheets are the obvious candidates for migration to the Cloud, especially

those that exhibit some of these common symptoms:

multiple interrelated worksheets have a tangle of forms and formulas; spreadsheets are emailed around for data collection and synthesis;


4/9


spreadsheets are placed on a shared drive for access and update; spreadsheets are used as part of a core process without anyone really knowing how it

works

spreadsheets are so massive that a human cant possibly comprehend them; employees spend an inordinate amount of time cutting and pasting, updating,

consolidating and re-entering data onto spreadsheets;

employees enter the same data into separate spreadsheets in order to see informationin different ways;

the person who maintains the companys spreadsheet application leaves the companyor goes on vacation or takes a leave of absence, forcing other employees to spend

countless hours trying to maintain the reports;

finding out-of-date information in spreadsheets frequently or all the time; multiple versions of the same spreadsheet circulate around the company; and spreadsheets are used to produce error-prone recurring reports.

The Hidden Costs of Operational Spreadsheets

The ease with which spreadsheets can be used to build simple applications is both a blessing and

a curse. It allows you to build a quick and dirty solution to a situation, but it often then grows into

something well beyond its original purpose. Since it usually does so over time, the users of the

system take it for granted, its limitations are endured, and it is rarely migrated to a more suitable

environment.

This is unfortunate, because there are many serious problems with using spreadsheets as

database applications:

Security and Stability

Since spreadsheets can be easily copied and shared with only limited security, they are open to

tampering, which leads to undetectable (and sometimes costly) errors.

Scalability

Spreadsheets are not designed to handle large amounts of data, or to accommodate a significant

number of users.

Aggregation

It is difficult to aggregate data from multiple spreadsheets, especially when this needs to take

place often, and when the spreadsheets to be aggregated are maintained by multiple users.


5/9


Data Validation

Creating and enforcing validation rules is often difficult to do in spreadsheets, making data errors

more likely.

Transparency

Calculations and other business rules, as well as the type of user interaction taking place, are

often not transparent to the rest of the organization.

Permissions

Spreadsheets do not easily (if at all) provide the ability for each user or group of users to have

different data permissions down to the field level.

Interoperability and Dependency

A single spreadsheet used in isolation is easy to manage. But when a spreadsheet is used as a

system, there is a need to introduce dependency checks, because certain actions dictate the

validity of further actions. For example, consolidating the results of all departments is invalid if

some of those departments have not yet completed their budgeting input. A dependent process

requires knowledge of the factors on which it depends. The ability to indicate status and pass

status between processes is not easily managed.

Wasted resource

One of the largest drawbacks of spreadsheet dependency is the accumulated amount of time

staffers devote to creating spreadsheets, maintaining them and formatting them.

Complexity

Inter-workbook links create hidden dependencies and make data consistency difficult to assess.

Carelessness

It takes some effort often a lot of effort to develop and maintain sound, proper, and

effective spreadsheet practices. The spreadsheet's very ease of use encourages sloppy habits,

lack of foresight and minimal design.

Integrity

There is no audit trail, it is often difficult to prevent tampering without expending significant

effort, and data validation is often weak.

Quality

Novice programming can result in complex data structures and poorly developed logic.


6/9


Integration

Spreadsheets are not designed or intended to integrate with other systems.

Version Control

Version control and change control are difficult to implement.

Consistency

Spreadsheets are unable to support consistent methodologies and consistent consolidation of

data.

Single source of truth

Data quality, validity and consistency problems make it difficult for the users of the application to

know where the single source of truth resides. This is exacerbated by the diffusion of data

among many disparate, siloed data repositories.

Knowing you have a problem

The paradox of the spreadsheet is that despite these shortcomings, users overwhelmingly

embrace them as a tool and do not want to give them up. While they may pose difficulties when

used repeatedly in business processes, they are an IT tool that most people feel comfortable using.

These factors appear to cause people to turn a blind eye to the cumulative impact on company

performance. People who use spreadsheets as databases have become numb to the difficulties

they pose and the extent to which using them hinders their efficiency. Even though the time they

spend addressing problems with these spreadsheets is noticeable, they think their job description

includes debugging spreadsheets as a regular duty. Indeed, one of the biggest barriers to

addressing spreadsheet shortcomings is peoples acceptance of them as an inevitable cost of doing

business.

But spreadsheet use carries a more serious risk. Spreadsheet users record, manage and analyze

important processes that can have a negative impact on a companys bottom line. And

spreadsheets are usually used extensively throughout corporations not just in finance

departments to manage many critical business processes.

The growing need to leverage the power in the Cloud

In addition to the problems associated with using spreadsheets for operational applications, the

advent of the Cloud has made the use of spreadsheets in this way even more of a bad practice.


7/9


This is because the Cloud provides new services and opportunities that cannot be realized easily

or at all - in a spreadsheet environment. These include:

Use of Web services

One of the advantages of the Cloud is the ability to easily extend an application to take

advantage of other nodes in the Cloud . This includes services like Google Apps, Amazon S3 storage,

Facebook, Paypal, and so on.

Inclusion in workflow

Cloud-based workflow is promising to be a significant area of productivity improvement. A

Platform as a Service (PaaS) like Force.com usually has workflow built into it, allowing your

applications to both use and participate in inter- and intra-application workflows.

Sharing across the globe

With many workforces spread out across the globe, and the increasing use of global outsourcing,

the ability to easily make applications securely available is only going to increase. Force.com

provides powerful user administration and permissions management, and facilitate workflows

across multiple organizations.

Multiple languages

Sharing applications across the globe also includes the need for applications to be easily available

in multiple languages.

Mobile devices

The ability to access the application from any device is becoming more and more critical, as

mobile device capability is extended and their usage becomes more prevalent.

How Force.com can help

There are many reasons why operational spreadsheets are used: applications start off too small

to be done by IT, given the overhead that each project needs to bear; applications need to be

deployed somewhere, which involves procuring hardware, installing software, integrating with the

network, etc.; or the amount of time to get a project done and extend it takes too long using

traditional IT methods.

A Cloud computing platform like Force.com addresses these issues by significantly reducing

development time, and eliminating the need to provide a deployment environment. They do this

by providing a comprehensive set of integrated functionality, including databases, workflow,

reporting, forms, etc.


8/9


This means that any Cloud-based application automatically inherits all this capability before the

application is even built.

Force.com also eliminates infrastructure and operational requirements by taking care of thingslike server deployment, operating systems, storage, disaster recovery, authentication, availability,

monitoring, patch management, upgrades and backup.

But most important is the change in methodology that suits these types of applications.

Traditional application development involves a complete team of experts, like database

administrators, technical architects, technical writers, etc.

Force.com removes the need for many of these roles: the system architecture is already in place,

the database is managed through a simple point-and-click interface, and the need for programming

is reduced at least five-fold. The development process is much more iterative, involves less people,

and for most projects obviates the need for a dedicated project manager, technical writer andformal QA.

A typical project on Force.com is much more likely to be analyst-focused, where the analyst

works directly with the user to build the majority of the application. Programmers are brought in

only when the platform cannot accomplish what the analyst needs to do. This dramatically reduces

the time and effort it takes to build and evolve an application, making it much more attractive than

it has been until now.

The Role of ITCloud computing for the first time opens up the possibility for businesses to build and deploy

powerful systems that dont depend of the resources of the IT department.

But IT departments can play a role, by educating business users on how to take advantage of

situational business process capabilities in the Cloud, without getting bogged down in traditional

applications development and deployment. IT can provide the guidance business people need so

they wont create havoc, and help them stay out of compliance, e.g. Sarbox, hot waters. Lastly, IT

can provide controlled access to enterprise data as needed to build situational applications.

What To Do Next

Despite their obvious appeal, spreadsheets in their current form may be the most

pernicious technology-related problem organizations face today all the more so because most do

not know how much spreadsheet errors and problems are costing them or how much more they

could be getting out of an application if it were on a more suitable platform.


9/9


Your company cannot fix the problem until it sees that it has one. For many companies, that can

be challenging because people recognize the benefits but are often oblivious to the costs.

Spreadsheets have been a huge source of productivity. As a one-time situation, spreadsheets

work well. The slippery slope begins when a spreadsheet is reused more than a few times and

becomes part of a collaborative business process. At that point, users (and their organizations) have

made a devils bargain. Errors will multiply as the spreadsheet is passed through multiple sets of

hands, multiple specification changes, and multiple iterations. There will be no record of who did

what when. And the ability to extend the application beyond the limitations of a spreadsheet as a

database becomes more and more limiting.

Having recognized the problem, the next step is to identify some low hanging fruit, typically a

spreadsheet experiencing some of the symptoms discussed above. You can then kick off a pilot

project to re-build the application on Force.com. Once the power of the platform has been

established through the building of the first application, your company may take the next step ofbuilding in-house expertise.

Conclusion

Fast, easy and extremely flexible modeling spreadsheets will always have a place in an

organization. Unfortunately, ad-hoc tools lead to ad-hoc designs, ad-hoc designs are hard to test,

hard to maintain, and hard to extend. Operational spreadsheets tend to live on and develop well

beyond their initial life expectancy and scope. They are unable to take advantage of the power of

Force.com, thereby limiting their value to the organization.

This does not have to be. With the advent of Cloud Computing and Force.com, there is a

ready alternative to abusing spreadsheets. With Force.com, organizations can rapidly build and

deploy solutions that until now would have meant bending spreadsheets well beyond their original

purpose.

migrating operational spreadsheets to the cloud with force v2

Documents