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

User-Friendly RASCI Accountability Matrices

Right now, you’re probably thinking that’s a statement of opposites. Something dreamed up by a consultant to impress, or just to fill a blog page. But wait. What if I taught you to create order in procedural chaos in five minutes flat? ?Would you be interested then?

The first step is to create a story line ?

Let’s imagine five friends decide to row a boat across a river to an island. Mary is in charge and responsible for steering in the right direction. John on the other hand is going to do the rowing, while Sue who once watched a rowing competition will be on hand to give advice. James will sit up front so he can tell Mary when they have arrived. Finally Kevin is going to have a snooze but wants James to wake him up just before they reach the island.

That’s kind of hard to follow, isn’t it ?

Let’s see if we can make some sense of it with a basic RASCI diagram ?

Responsibility Matrix: Rowing to the Island
Activity Responsible Accountable Supportive Consulted Informed
Person John Mary Sue James Kevin
Role Oarsman Captain Consultant Navigator Sleeper

?

Now let’s add a simple timeline ?

Responsibility Matrix: Rowing to the Island
? Sue John Mary James Kevin
Gives Direction ? ? A ? ?
Rows the Boat ? R ? ? ?
Provides Advice S ? ? ? ?
Announces Arrival ? ? A C ?
Surfaces From Sleep ? ? ? C I
Ties Boat to Tree ? ? A ? ?

?

Things are more complicated in reality ?

Quite correct. Although if I had jumped in at the detail end I might have lost you. Here?s a more serious example.

rasci

?

There?s absolutely no necessity for you so examine the diagram in any detail, other to note the method is even more valuable in large, corporate environments. This one is actually a RACI diagram because there are no supportive roles (which is the way the system was originally configured).

Other varieties you may come across include PACSI (perform, accountable, control, suggest, inform), and RACI-VS that adds verifier and signatory to the original mix. There are several more you can look at Wikipedia if you like.

Field service and improved visibility

A manager is someone who has control over a company. They are given the responsibility of overseeing what the company does and making important decisions. The manager is the most important person in the empire and needs to be in the know at all times. Not what happened a day ago but in real-time and from any place.

Information is necessary for this to happen. It needs to be concise, brief and straightforward. Ideally, access to job status, location information, customer information, notifications and location information should be on the palms of their hands.

To sum it all up, there should be fluid communication among personnel in the field. Information should be accessed easily from one place as it flows to another to maintain steady two-way communication. This is possible with automation meaning that no amount of data will be left unseen or unused because of paperwork that was never handed over or looked into, reducing the chance of misinformation or missing information to a minimum.

Ways improved visibility will help your business through Field Service

Organisations using field services will agree that improved visibility has more business benefits and the real question is what aspect needs improving rather than discussing the benefits.

Real-time visibility

Managers need to be in the know from anywhere at any time. The manager needs information about the company. The need not to be physically present to have an idea of what’s going on. They should know everything at all times, from what was planned for the day to real-time events.

All this information should be easily accessed from one central point and should contain everything about the company and other relevant information.

Extending the back office into the field

This two-way communication is virtually irreplaceable. At any time, the information should flow among technicians in the field and those in the back office. This will help to have a better idea of how to manage the workload and come up with solutions to some work-related issues.

Everyone in the team should be informed and be up to speed about real-time events. Keeping everyone updated improves visibility because they can make updates and decisions based on the kind of information they get.

No more lost paperwork

Managing paper trail can be quite a hassle for organisations. With tons of workload, there can be many delays meaning that some information might be missed or forgotten. People might also choose not to turn up for work for days on end and can affect how much info is processed. Some work can be left undone, and work not invoiced.

When organisations use field service management services, information is fed only once and everything else is done automatically. Say goodbye to lags or relying on last month?s data. Work will move faster because people will have more time to focus on important things rather than chasing an endless paper trail.

Business intelligence

Field service management technology will let you know what is being done in the field and with such an abundance of data, will make sound decisions for the business.

Every decision is hinged on cold facts. Information needs to be easily accessed and filtered into the right categories so that sound business decisions are made from the collected data.

Growing revenue

The abundance of real-time information and improved visibility can determine whether a business will grow or not. Each piece of information can show trends that are critical for any business to improve. Trends show how each sector is doing and sheds more light into specific areas that need a total overhaul. This may include improving customer service, products on retail or hiring more technicians.

Without information, a company is one step closer to going out of business. Every action should be geared to increase the revenue and this starts by making the right choices.

Visibility when working offline

Working offline is an issue that can affect visibility. Sometimes agents will need to work in areas that have little network coverage or are deep down working in tunnels or are around heavy machines and turbines. Field service solutions are built for the mobile environment and for workers who may find themselves in non-connected areas so that they can still use their device while offline. This makes sure that there is no loss of information while working in-field

Time-saving

Certainly, business is constrained to its environments and if the demand changes it should prove to be flexible enough to adjust to changes as they happen. Field service solutions operations like schedule need to update instantly. Once activities start rolling, nothing should create lags in the schedule so that operations flow seamlessly at all time.

Field workers can then make updates and document changes easily on the job site directly on their device by using responsive site menus, drastically saving time while feeding data and complete orders.

Improved customer service

It is not a clich? to say that the customer is always right. With real-time information, both field service and back-office technicians can improve customer relations and satisfaction. With a unified system of sharing information like the ERPs and CRMs, the field officer can know more about specific clients, their history and other data to know more about what should be done in current and future orders. This means that better decisions will be made for each customer.

How improved visibility benefits different parts of the organisation

Improved visibility in all areas of the business makes information more accessible. Here are some of the benefits that various sects of a business can get from improved visibility.

? The business owner
The manager owns the company and can access all information with just a single tap. A lot of data can be used to analyse the health of the venture. This includes revenue, inventory, customer surveys, employee hours, invoices and customer data.
Profitability is increased by putting more emphasis on customer satisfaction and improving the quality of end products and services.

? The service manager
The service manager can see what is going on in the field in real-time, and look into measures that can improve the productivity of staff members in various departments.
And with workflow automation, time-saving is at the maximum because there is less paperwork consequently improving scheduling and job completion rates.

? Service administrator/ dispatcher
For the team in the office, they can assign tasks faster. Scheduling is automatically done and updated in real-time. It eliminates the need for paperwork and leaves more time to be productive on other errands.

? The field technician
Improved visibility for a field worker means that they can do their best in any task. They can share or get critical information about orders and customers. This drastically improves job completion rates and customer satisfaction.

? HR
Live information can be used to track certain orders, the time it takes to complete orders, and the number of staff required in the organisation. Such data can be used in HR to reduce payroll errors and erroneous overtime costs.

? Finance
Field service management software can also benefit the finance team by automation of invoices. A work order can be tracked from start to the end and invoiced immediately to retain faster payments. Relevant data can be used to track revenue and expenditures, and costs.

Real-time visibility gives a company many solutions to manage the workload. In the end, visibility is also useful in increasing revenue and a smooth transition of information for the company.

What Is Technical Debt? A Complete Guide

You buy the latest iPhone on credit. Turn to fast car loan services to get yourself those wheels you’ve been eyeing for a while. Take out a mortgage to realise your dream of being a homeowner. Regardless of the motive, the common denominator is going into financial debt to achieve something today, and pay it off in future, with interest. The final cost will be higher than the loan value that you took out in the first place. However, debt is not limited to the financial world.

Technical Debt Definition

Technical debt – which is also referred to as code debt, design debt or tech debt – is the result of the development team taking shortcuts in the code to release a product today, which will need to be fixed later on. The quality of the code takes a backseat to issues like market forces, such as when there’s pressure to get a product out there to beat a deadline, front-run the competition, or even calm jittery consumers. Creating perfect code would take time, so the team opts for a compromised version, which they will come back later to resolve. It’s basically using a speedy temporary fix instead of waiting for a more comprehensive solution whose development would be slower.

How rampant is it? 25% of the development time in large software organisations is actually spent dealing with tech debt, according to a multiple case study of 15 organizations. “Large” here means organizations with over 250 employees. It is estimated that global technical debt will cost companies $4 trillion by 2024.

Is there interest on technical debt?

When you take out a mortgage or service a car loan, the longer that it takes to clear it the higher the interest will be. A similar case applies to technical debt. In the rush to release the software, it comes with problems like bugs in the code, incompatibility with some applications that would need it, absent documentation, and other issues that pop up over time. This will affect the usability of the product, slow down operations – and even grind systems to a halt, costing your business. Here’s the catch: just like the financial loan, the longer that one takes before resolving the issues with rushed software, the greater the problems will pile up, and more it will take to rectify and implement changes. This additional rework that will be required in future is the interest on the technical debt.

Reasons For Getting Into Technical Debt

In the financial world, there are good and bad reasons for getting into debt. Taking a loan to boost your business cashflow or buy that piece of land where you will build your home – these are understandable. Buying an expensive umbrella on credit because ‘it will go with your outfit‘ won’t win you an award for prudent financial management. This also applies to technical debt.

There are situations where product delivery takes precedence over having completely clean code, such as for start-ups that need their operations to keep running for the brand to remain relevant, a fintech app that consumers rely on daily, or situations where user feedback is needed for modifications to be made to the software early. On the other hand, incurring technical debt because the design team chooses to focus on other products that are more interesting, thus neglecting the software and only releasing a “just-usable” version will be a bad reason.

Some of the common reasons for technical debt include:

  • Inadequate project definition at the start – Where failing to accurately define product requirements up-front leads to software development that will need to be reworked later
  • Business pressure – Here the business is under pressure to release a product, such as an app or upgrade quickly before the required changes to the code are completed.
  • Lacking a test suite – Without the environment to exhaustively check for bugs and apply fixes before the public release of a product, more resources will be required later to resolve them as they arise.
  • Poor collaboration – From inadequate communication amongst the different product development teams and across the business hierarchy, to junior developers not being mentored properly, these will contribute to technical debt with the products that are released.
  • Lack of documentation – Have you launched code without its supporting documentation? This is a debt that will need to be fulfilled.
  • Parallel development – This is seen when working on different sections of a product in isolation which will, later on, need to be merged into a single source. The greater the extent of modification on an individual branch – especially when it affects its compatibility with the rest of the code, the higher the technical debt.
  • Skipping industrial standards – If you fail to adhere to industry-standard features and technologies when developing the product, there will be technical debt because you will eventually need to rework the product to align with them for it to continue being relevant.
  • Last-minute product changes – Incorporating changes that hadn’t been planned for just before its release will affect the future development of the product due to the checks, documentation and modifications that will be required later on

Types of Technical Debt

There are various types of technical debt, and this will largely depend on how you look at it.

  • Intentional technical debt – which is the debt that is consciously taken on as a strategy in the business operations.
  • Unintentional technical debt – where the debt is non-strategic, usually the consequences of a poor job being done.

This is further expounded in the Technical Debt Quadrant” put forth by Martin Fowler, which attempts to categorise it based on the context and intent:

Technical Debt Quadrant

Source: MartinFowler.com

Final thoughts

Technical debt is common, and not inherently bad. Just like financial debt, it will depend on the purpose that it has been taken up, and plans to clear it. Start-ups battling with pressure to launch their products and get ahead, software companies that have cut-throat competition to deliver fast – development teams usually find themselves having to take on technical debt instead of waiting to launch the products later. In fact, nearly all of the software products in use today have some sort of technical debt.

But no one likes being in debt. Actually, technical staff often find themselves clashing with business executives as they try to emphasise the implications involved when pushing for product launch before the code is completely ready. From a business perspective, it’s all about weighing the trade-offs, when factoring in aspects such as the aspects market situation, competition and consumer needs. So, is technical debt good or bad? It will depend on the context. Look at it this way: just like financial debt, it is not a problem as long as it is manageable. When you exceed your limits and allow the debt to spiral out of control, it can grind your operations to a halt, with the ripple effects cascading through your business.

 

Ready to work with Denizon?