Disaster Recovery

Because information technology is now integrated in most businesses, a business continuity plan (BCP) cannot be complete without a corresponding disaster recovery plan (DRP). While a BCP encompasses everything needed – personnel, facilities, communications, processes and IT infrastructure – for a continuous delivery of products and services, a DRP is more focused on the IT aspects of the plan.

If you’re still not sure how big an impact loss of data can have, it’s time you pondered on the survival statistics of companies that incurred data losses after getting hit by a major disaster: 46% never recovered and 51% eventually folded after only two years.

Realising how damaging data loss can be to their entire business, most large enterprises allocate no less than 2% of their IT budget to disaster recovery planning. Those with more sensitive data apportion twice more than that.

A sound disaster recovery plan is hinged on the principles of business continuity. As such, our DRP (Disaster Recovery Plan) blueprints are aimed at getting your IT system up and running in no time. Here’s what we can do for you:

Since the number one turn-off against BCPs and DRPs are their price tags, we’ll make a thorough and realistic assessment of possible risks to determine what specific methods need to be applied to your organisation and make sure you don’t spend more than you should.
Provide an option for virtualisation to enjoy substantial savings on disaster recovery costs.
Provide various backup options and suggest schedules and practices most suitable for your daily transactions.
Offer data replication to help you achieve business continuity with the shortest allowable downtime.
Refer to your overall BCP to determine your organisation’s critical functions, services, and products as well as their respective priority rankings to know what corresponding IT processes need to be in place first.
Implement IT Security to your system to reduce the risks associated with malware and hackers.
Introduce best practices to make future disaster recovery efforts as seamless as possible.

We can also assist you with the following:

Check our similar posts

Introduction to Matrix Management

A leader is responsible to empower his people and get the best out of them. Yet an organisational structure can either help or hamper performance. Worst, it can make or break success.

Looking at the fast-changing world of the global economy, whatsoever slows up and obstructs decision-making is a challenge. Hierarchical management is rather unattractive and functional silos are unlikable. Instead, employees desire to create teams equipped with flexibility, cooperation and coordination.

Recognising that companies have both vertical and horizontal chains of command, the matrix model is created. The concept of this principle lies in the ability to manage the collaboration of people across various functions and achieve strategic objectives through key projects.

Consider this scenario:

Ian is a sales executive of a company. His role is to sell a new product under the supervision of a product manager. The manager is expert about the product and she is accountable to coordinate the people across the organisation, making sure the product is achieved.

Moreover, Ian also reports to the sales manager who oversees his overall performance, monitors his pay and benefits and guides his personal development.

Complicated it may seem but this set-up is common to companies that seek to maximise the effect of expert product managers, without compromising the function of the staffing overhead in control of the organisation. This is a successful approach to management known as Matrix Management.

Matrix Management Defined

Matrix management is a type of organisational management wherein employees of similar skills are shared for work assignments. Simply stated, it is a structure in which the workforce reports to multiple managers of different roles.

For example, a team of engineers work under the supervision of their department head, which is the engineering manager. However, the same people from the engineering department may be assigned to other projects where they report to the project manager. Thus, while working on a designated project, each engineer has to work under various managers to accomplish the job.

Historical Background

Although some critics say that matrix management was first adopted in the Second World War, its origins can be traced more reliably to the US space programme of the 1960’s when President Kennedy has drawn his vision of putting a man on the moon. In order to accomplish the objective, NASA revolutionised its approach on the project leading to the consequent birth of ?matrix organisation?. This strategic method facilitated the energy, creativity and decision-making to triumph the grand vision.

In the 1970’s, matrix organisation received huge attention as the only new form of organisation in the twentieth century. In fact it was applied by Digital Equipment, Xerox, and Citibank. Despite its initial success, the enthusiasm of corporations with regards to matrix organisation declined in the 1980’s, largely because it was complex.

Furthermore, the drive for motivating people to work creatively and flexibly has only strengthened. And by the 1990’s, the evolution of matrix management geared towards creation and empowerment of virtual teams that focused on customer service and speedy delivery.

Although all forms of matrix has loopholes and flaws, research says that until today, matrix management is still the leading approach used by companies to achieve organisational goals.

Spreadsheet Woes – Burden in SOX Compliance and Other Regulations

End User Computing (EUC) or end User Developed Application (UDA) systems like spreadsheets used to be ideal ad-hoc solutions for data processing and financial reporting. But those days are long gone.

Today, due to regulations like the:

Sarbanes-Oxley (SOX) Act,
Dodd-Frank Act,
IFRS (International Financial Reporting Standards),
E.U. Data Protection Directive,
Basel II,
NAIC Model Audit Rules,
FAS 157,
yes, there?s more ? and counting

a company can be bogged down when it tries to comply with such regulations while maintaining spreadsheet-reliant financial and information systems.

In an age where regulatory compliance have become part of the norm, companies need to enforce more stringent control measures like version control, access control, testing, reconciliation, and many others, in order to pass audits and to ensure that their spreadsheets are giving them only accurate and reliable information.

Now, the problem is, these control measures aren’t exactly tailor-made for a spreadsheet environment. While yes, it is possible to set up a spreadsheet and EUC control environment that utilises best practices, this is a potentially expensive, laborious, and time-consuming exercise, and even then, the system will still not be as foolproof or efficient as the regulations call for.

Testing and reconciliation alone can cost a significant amount of time and money to be effective:

It requires multiple testers who need to test spreadsheets down to the cell level.
Testers will have to deal with terribly disorganized and complicated spreadsheet systems that typically involve single cells being fed information by other cells in other sheets, which in turn may be found in other workbooks, or in another folder.
Each month, an organisation may have new spreadsheets with new links, new macros, new formulas, new locations, and hence new objects to test.
Spreadsheets rarely come with any kind of supporting documentation and version control, further hampering the verification process.
Because Windows won’t allow you to open two Excel files with the same name simultaneously and because a succession of monthly-revised spreadsheets separated by mere folders but still bearing the same name is common in spreadsheet systems, it would be difficult to compare one spreadsheet with any of its older versions.

But testing and reconciliation are just two of the many activities that make regulatory compliance terribly tedious for a spreadsheet-reliant organisation. Therefore, the sheer intricacy of spreadsheet systems make examining and maintaining them next to impossible.

On the other hand, you can’t afford not to take these regulations seriously. Non-compliance with regulatory mandates can have dire consequences, not the least of which is the loss of investor confidence. And when investors start to doubt the management’s capability, customers will start to walk away too. Now that is a loss your competitors will only be too happy to gain.

Learn more about our server application solutions and discover a better way to comply with regulations.

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

Contact Us

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

How DevOps Could Change Your Business

Henry Ford turned the U.S. auto industry on its head when he introduced the idea of prefabricating components at remote sites, and then putting them together on a production line. Despite many industries following suit, software lagged behind until 2008, when Andrew Clay Shafer and Patrick Debois told the Agile Conference there was a better way to develop code:
– Write the Code
– Test the Code
– Use the Code
– Evaluate, Schedule for Next Review

The term ?DevOps? is short for Development and Operations. It first appeared in Belgium, where developers refined Shafer and Depois? ideas. Since then, DevOps became a counter movement against the belief that software development is a linear process and has largely overwhelmed it.

DevOps – A Better Way

DevOps emerged at an exciting time in the IT industry, with new technology benefiting from a faster internet. However, the 2008 world recession was also beginning to bite. Developers scampered to lower their human resource costs and get to market sooner.

The DevOps method enabled them to colloborate across organizational boundaries and work together to write, quality assure and performance test each piece of code produced in parallel.
DevOps? greater time-efficiency got them to market sooner and helped them steal a march on the competition.

There are many advantages to DevOps when we work in this collaborative way. Cooperation improves relationships between developers, quality assurers and end users. This helps ensure a better understanding of the other drivers and a more time-effective product.

Summary of DevOps Objectives

DevOps spans the entire delivery pipeline, and increases the frequency with which progress is reviewed, and updates are deployed. The benefits of this include:

? Faster time to market and implementation

? Lower failure rate of new releases

? Shortened lead time for bug fixes and updates

The Psycho-Social Implications of DevOps

DevOps drills through organization borders and traditional work roles. Participants must welcome change and take on board new skills. Its interdepartmental approach requires closer collaboration across structural boundaries and greater focus on overarching business goals.

Outsourcing the detail to freelancers on the Internet adds a further layer of opportunity. Cultures and time zones vary, requiring advanced project management skills. Although cloud-based project management software provides adequate tools, it needs an astute mind to build teams that are never going to meet.

The DevOps movement is thus primarily a culture changer, where parties to a project accept the good intentions of their collaborators, while perhaps tactfully proposing alternatives. There is more to accepting a culture than using a new tool. We have to blend different ways of thinking together. We conclude by discussing three different methods to achieve this.

Three Ways to Deploy DevOps in your?Organisation

If you foresee regular DevOps-based projects, consider running your entire organisation through an awareness program to redirect thinking. This will help non-participants understand why DevOps members may be ?off limits? when they are occupied with project work. Outsourcing tasks to contracting freelancers can mitigate this effect.

There are three implementation models associated with DevOps although these are not mutually exclusive.

? Use systems thinking. Adopt DevOps as company culture and apply it to every change regardless of whether the process is digital, or not

? Drive the process via increased understanding and feedback from key receivers. Allow this to auto-generate participative DevOps projects

? Adopt a continuous improvement culture. DevOps is not only for mega upgrades. Feedback between role players is paramount for success everywhere we go.

You can use the DevOps concept everywhere you go and whenever you need a bridge to better understanding of new ideas. We diminish DevOps when we restrict its usefulness to the vital role it plays in software development. The philosophy behind it belongs in every business.