Spreadsheet Woes – Limited Features For Easy Adoption of a Control Framework

Like it or not, regulations are here to stay and for a company to comply with them, its IT and financial systems will have to be equipped with a suitable control framework. One common stumbling block to such an implementation is a company?s over-reliance on spreadsheets.

Why is it so difficult to adopt controls for a system that’s reliant on spreadsheets? To understand this, let’s pinpoint some of the strongest, most powerful attributes of these User Developed Applications (UDA).

By nature, spreadsheets are the epitome of simplicity: easy to develop, easily accessible and easily altered. All computers in your workplace will most likely have them and everyone in your organization may be sharing them, making their own versions, and storing them in personal folders.

Sad to say though, these strengths are also control weaknesses and constitute the very reasons why spreadsheets require effective risk management.

Easy to develop. Being easy to develop, most spreadsheet systems are created by non-IT users who have limited knowledge on best control practices. Being constantly under time pressure, these ?developers? may also relegate documentation, security, and data verification to the back burner in favour of coming up with a timely report.

Easy to access. Information in a spreadsheet can be opened by practically anyone within the organization?s network. Who accessed what? And when? If anything goes wrong, it would be difficult to identify the culprit, and the failure to pinpoint responsibility for erroneous data could lead to bigger, more costly mistakes.

Easy to alter. Lastly, if the information is easy to access, then it can also be easily altered, consequently making reports more prone to both accidental errors and fraudulent modifications.

The rise of multimillion dollar scandals due to accidental and intentional spreadsheet errors have prompted regulatory bodies to publish guidelines for mitigating spreadsheet-associated risks. These controls include:

Change control
Version control
Access control
Input
Security and data integrity
Documentation
Development life cycle
Backup and archiving
Logic inspection/Testing
Segregation of duties/roles, and procedures
Analytics

In theory, these controls should be able to bring down risks considerably. However, because of the inherent nature of spreadsheets, such controls are rarely implemented effectively in the real world.

Take for example Security and Data Integrity. One of the most common causes of spreadsheet error is due to ?hardwiring?. This happens when values are inadvertently entered into a formula cell, naturally changing the logic of the spreadsheet.

As a way of control, cell locking can be applied on the formula cells to prevent users without the proper authority from making any changes. However, when reporting deadlines approach drawing spreadsheets to the forefront of data processing, more people are given access rights to the locked cells. Ironically, it is during these crunch times, when errors are most likely to happen.

Because the built-in features of a spreadsheet support none of the controls mentioned above, some companies are tempted to purchase control-enabling programs for spreadsheets just to continue using them for financial reporting. But although these programs can integrate the required controls, you?d still be interacting with the same complex and outdated interface: the spreadsheets.

Thus, these band-aid solutions may not suffice because the root cause of these problems are the spreadsheets themselves.

Learn more about our server application solutions and discover a better way to implement controls.

More Spreadsheet Blogs

Spreadsheet Risks in Banks

Top 10 Disadvantages of Spreadsheets

Disadvantages of Spreadsheets – obstacles to compliance in the Healthcare Industry

How Internal Auditors can win the War against Spreadsheet Fraud

Spreadsheet Reporting – No Room in your company in an age of Business Intelligence

Still looking for a Way to Consolidate Excel Spreadsheets?

Disadvantages of Spreadsheets

Spreadsheet woes – ill equipped for an Agile Business Environment

Spreadsheet Fraud

Spreadsheet Woes – Limited features for easy adoption of a control framework

Spreadsheet woes – Burden in SOX Compliance and other Regulations

Spreadsheet Risk Issues

Server Application Solutions – Don’t let Spreadsheets hold your Business back

Why Spreadsheets can send the pillars of Solvency II crashing down

amazon.co.uk

amazon.com

Check our similar posts

How DevOps oils the Value Chain

DevOps ? a clipped compound of development and operations – is a way of working whereby software developers are in a team with project beneficiaries. A client centred approach extends the project plan to include the life cycle of the product or service, for which the software is developed.

We can then no longer speak of a software project for say Joe?s Accounting App. The software has no intrinsic value of its own. It follows that the software engineers are building an accounting app product. This is a small, crucially important distinction, because they are no longer in a silo with different business interests.

To take the analogy further, the developers are no longer contractors possibly trying to stretch out the process. They are members of Joe?s accounting company, and they are just as keen to get to market fast as Joe is to start earning income. DevOps uses this synergy to achieve the overarching business goal.

A Brief Introduction to OpsDev

You can skip this section if you already read this article. If not then you need to know that DevOps is a culture, not a working method. The three ?members? are the software developers, the beneficiaries, and a quality control mechanism. The developers break their task into smaller chunks instead of releasing the code to quality control as a single batch. As a result, the review process happens contiguously along these simplified lines.

Code	QC	Test	?	?	?
?	Code	QC	Test	?	?
?	?	Code	QC	Test	?
?	?	?	Code	QC	Test

Colour Key

Developers

Quality Control

Beneficiary

This is a marked improvement over the previously cumbersome method below.

Write the Code	?	Test the Code	?	Use the Code
?	Evaluate, Schedule for Next Review			?

Working quickly and releasing smaller amounts of code means the OpsDev team learns quickly from mistakes, and should come to product release ahead of any competitor using the older, more linear method. The shared method of working releases huge resources in terms of user experience and in-line QC practices. Instead of being in a silo working on its own, development finds it has a richer brief and more support from being ?on the same side of the organisation?.

The Key Role that Application Program Interfaces Play

Application Program Interfaces, or API?s for short, are building blocks for software applications. Using proprietary software-bridges speeds this process up. A good example would be the PayPal applications that we find on so many websites today. API?s are not just for commercial sites, and they can reduce costs and improve efficiency considerably.

The following diagram courtesy of TIBCO illustrates how second-party applications integrate with PayPal architecture via an API fa?ade.

The DevOps Revolution Continues ?

We close with some important insights from an interview with Jim Stoneham. He was general manager of the Yahoo Communities business unit, at the time Flickr became a part. ?Flickr was a codebase,? Jim recalls, ?that evolved to operate at high scale over 7 years – and continuing to scale while adding and refining features was no small challenge. During this transition, it was a huge advantage that there was such an integrated dev and ops team?

The ?maturity model? as engineers refer to DevOps status currently, enables developers to learn faster, and deploy upgrades ahead of their competitors. This means the client reaches and exceeds break-even sooner. DevOps lubricates the value chain so companies add value to a product faster. One reason it worked so well with Flickr, was the immense trust between Dev and Ops, and that is a lesson we should learn.

?We transformed from a team of employees to a team of owners. When you move at that speed, and are looking at the numbers and the results daily, your investment level radically changes. This just can’t happen in teams that release quarterly, and it’s difficult even with monthly cycles.? (Jim Stoneham)

Contact Us

(+353)(0)1-443-3807 – IRL
(+44)(0)20-7193-9751 – UK

Keys to Successful Matrix Management

Matrix management, in itself, is a breakthrough concept. In fact, there are a lot of organizations today that became successful when they implemented this management technique. However, there are also organizations that started it but failed. And eventually abandoned it in the end.

Looking at these scenarios, we can say that when you implement matrix management in your organisation, two things can happen – you either succeed or fail. And there?s nothing in between. The truth is, the effectiveness of matrix management lies in your hands and in your implementation. To ensure that you achieve your desired results, recognise these essential keys to successful matrix management.

Establish Performance Goals and Metrics

This should be done as soon as the team is formed, at the beginning of the year or during the process of setting organisational objectives. Whenever it is, the most important thing is that each team player understands the objectives and metrics to which their performances will be evaluated. This ensures that everyone is looking at the same set of objectives as they carry out their individual tasks.

Define Roles and Responsibilities

One pitfall of matrix management is its internal complexity. Awareness of this limitation teaches you to clearly define the roles and responsibilities of the team players up front. Basically, there are three principal sets of roles that should be explained vividly ? the matrix leader, matrix managers and the matrixed employees. It is important to discuss all the possible details on these roles, as well as their specific responsibilities, to keep track of each other?s participation in the projects of the organisation.

One effective tool to facilitate this discussion is through the RACI chart – Who is Responsible? Who is Accountable? Who should be Consulted? Who will Implement? With this, clarification of roles and responsibilities would be more efficient.

When roles are already clearly defined, each participant should review their job descriptions and key performance metrics. This is to make sure that the roles and responsibilities expected of you integrates consistently with your job in the organisation, as a whole.

Manage Deadlines

In matrix management, the employees report to several managers. They will likely have multiple deadlines to attend to and accomplish. There might even be conflicts from one deadline to another. Hence, each should learn how to schedule and prioritise their tasks. Time management and action programs should be incorporated to keep the grace under pressure.

Deliver Clear Communication

Another pitfall of matrix management is heightened conflict. To avoid unrealistic expectations, the matrix leaders and managers should communicate decisions and information clearly to their subordinates, vice versa. It would help if everyone will find time to meet regularly or send timely reports on progress.

Empower Diversity

Knowledge, working styles, opinions, skills and talents are diverse in a matrix organisation. Knowing this fact, each should understand, appreciate and empower the learning opportunities that this diversity presents. Trust is important. Respect to each other?s opinions is vital. And acknowledgement of differing viewpoints is crucial.

The impetus of matrix management is the same ? mobilise the organisation’s resources and skills to cope with the fast-paced changes in the environment. So, maximise the benefits of matrix management as you consider these essential keys to its successful implementation.

Why DevOps Matters: Things You Need to Know

DevOps creates an agile relationship between system development and operating departments, so the two collaborate in providing results that are technically effective, and work well for customers and users. This is an improvement over the traditional model where development delivers a complete design ? and then spends weeks and even months afterwards, fixing client side problems that should never have occurred.
Writing for Tech Radar Nigel Wilson explains why it is important to roll out innovation quickly to leverage advantage. This implies the need for a flexible organisation capable of thinking on its feet and forming matrix-based project teams to ensure that development is reliable and cost effective.
Skirmishes in Boardrooms
This cooperative approach runs counter to traditional silo thinking, where Operations does not understand Development, while Development treats the former as problem children. This is a natural outcome of team-centred psychology. It is also the reason why different functions pull up drawbridges at the entrance to their silos. This situation needs managing before it corrodes organization effectiveness. DevOps aims to cut through this spider web of conflict and produce faster results.

The Seeds of Collaboration

Social and personal relationships work best when the strengths of each party compensate the deficiencies of the other. In the case of development and operations, development lacks full understanding of the daily practicalities operating staff face. Conversely, operations lacks ? and should lack knowledge of the nuances of digital automation, for the very reason it is not their business.
DevOps straddles the gap between these silos by building bridges towards a co-operative way of thinking, in which matrix-teams work together to define a problem, translate it into needs and spec the system to resolve these. It is more a culture than a method. Behavioural change naturally leads to contiguous delivery and ongoing deployment. Needless to say only the very best need apply for the roles of client representative, functional tester and developer lead.

Is DevOps Worth the Pain of Change?

Breaking down silos encroaches on individual managers? turf. We should only automate to improve quality and save money. These savings often distil into organisational change. The matrix team may find itself in the middle of a catfight. Despite the pain associated with change resistance, DevOps more than pays its way in terms of benefits gained. We close by considering what these advantages are.

An Agile Matrix Structure ? Technical innovation is happening at a blistering rate. The IT industry can no longer afford to churn out inferior designs that take longer to fix than to create. We cannot afford to allow office politics to stand in the way of progress. Silos and team builds are custodians of routine and that does not sit well with development.

An Integrated Organization ? DevOps not only delivers operational systems faster through contiguous testing. It also creates an environment whereby cross-border teams work together towards achieving a shared objective. When development understands the challenges that operations faces ? and operations understands the technical limiters – a new perspective emerges of ?we are in this together?.

The Final Word ? With understanding of human dynamics pocketed, a DevOps project may be easier to commission than you first think. The traditional way of doing development – and the waterfall delivery at the end is akin to a two-phase production line, in which liaison is the weakest link and loss of quality inevitable.

DevOps avoids this risk by having parties work side-by-side. We need them both to produce the desired results. This is least until robotics takes over and there is no longer a human element in play.