Shared Services ? Are They A Good Idea

Things happen fast in business and we need to stay on top. It does not seem long ago that some enterprises were still hands-on traders or artisans with a few youngsters to help out. People like that did not do admin and their accounting was a matter of making sure there was enough money in the jar.

When Wal-Mart’s Sam Walton took over his first shop in 1945 things had moved on from there, although he did still deal directly with his customers. When he died his legacy was 380,000 jobs, and a business larger than most economies. So there?s plenty we can learn from how he grew his business.

One of Sam?s secrets was his capacity to centralise what needed gathering together, while empowering store managers to think independently when it came to local conditions. His regional warehouses had individual outlets clustered around them within one day?s drive each. This shared service eliminated 90% of safety stock and released capital for expansion.

Wal-Mart took sharing services a step further in February 2006, when it centralised accounts payable, accounts receivable, general accounting and human resources administration at Wal-Mart Stores and Sam?s Clubs in the U.S. and Puerto Rico. The objective was to bring costs down, while allowing local managers more time to focus on their business plans and other initiatives. As a further spin-off, Wal-Mart was able to integrate its data on a single SAP platform and eliminate significant roadblocks.

This is an excellent example of sharing services by creating own centres of excellence.? Of course, this is not the only business possibility. Other corporates have successfully completely outsourced their support activities, and Wal-Mart has no doubt had a variety of similar offers too. But, is the Wal-Mart picture entirely rosy, or is there a catch?

The Association of Chartered Certified Accountants has indicated that top talent may be the loser globally. This is because the Wal-Mart model removes many challenges through standardisation, and offers less scope for internal promotion as a result. Language and cultural differences may also have a long-term detrimental effect on the way the departments work well together.

Local outsourcing ? this is the business model where several firms engage a shared service provider independently- may hence prove to be a more malleable option for smaller companies. It often makes more sense to hunt down made-to-order services. Offerings such as the professional support we offer on this site.

Check our similar posts

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.

 

Telemetry and the Survival of the Human Species

Without moisture, plants die. Without fodder, the animal food chain collapses. This is why climate change is the greatest threat humankind faces. Crop management needs timely information regarding ambient conditions, and also in the soil itself. In dry areas, online knowledge of trends in rainfall, sunlight, wind speed, leaf moisture, air temperature, relative humidity and solar radiation are indicators of soil stress that can be deadly for plants, and everything that relies on them.

As climate change bites, the need to find solutions accelerates. Drones swoop across to monitor ambient conditions, while probes sunk into plants and the earth in which they grow transmit information to big data repositories for feedback to administrators. In Australia, a remarkable cattle farmer is applying the same approach to his herds.

Nuffield scholar Rob Cook has always been on the edgy side of things. He lost his mobility in a helicopter crash in 2008 patrolling farmland but that has not deterred him. If anything, it has freed his mind to explore the potential that telemetry offers farmers in Australia. He shared this potential with the young beef producers in Roma Australia recently, and here is a summary what he said.

Being wheelchair bound he had to shift from herding with cattle dogs to a more scientific approach. He bought a farm 230 miles / 370 kilometres inland from Brisbane in a warm, temperate climate with significant rainfall even in the driest months. He uses observant software that reports on critical issues like water levels indicating animal consumption, and supplementary water flows from a central irrigation channel.

He also monitors fodder sources for dryer months, and moisture levels in food stocks. Rob is committed to making every blade of grass count. ?We even have the ability to take a photo of the cattle when they are taking a drink of water,? he explains, and that provides valuable information regarding tick and fly infestation and overall condition.

None of this would be possible for Rob Cook without telemetry, which is the process of collecting data at remote points and transmitting it to receiving equipment for analysis. Independent farmers do not have equipment to fund these analytic resources on their own, and use big data resources in a cloud to obtain reports. ecoVaro is on top of current trends. Please speak to us when you need independent advice.

?

How to Reduce Costs when Complying with SOX 404

Section 404 contains the most onerous and most costly requirements you’ll ever encounter in the Sarbanes-Oxley Act (SOX). In this article, we?ll take a closer look at the salient points of this contentious piece of legislation as it relates to IT. We?ll also explain why companies are encountering difficulties in complying with it.

Then as soon as we’ve tackled the main issues of this section and identify the pitfalls of compliance, we can then proceed with a discussion of what successful CIOs have done to eliminate those difficulties and consequently bring down their organisation’s IT compliance costs. From this post, you can glean insights that can help you plan a cost-effective way of achieving IT compliance with SOX.

SOX 404 in a nutshell

Section 404 of the Sarbanes-Oxley Act, entitled Management Assessment of Internal Controls, requires public companies covered by the Act to submit an annual report featuring an assessment of their company?s internal controls.

This ?internal control report? should state management’s responsibility in establishing/maintaining an adequate structure and a set of procedures for internal control over your company?s financial reporting processes. It should also contain an assessment of the effectiveness of those controls as of the end of your most recent fiscal year.

Because SOX also requires the public accounting firm that conducts your audit reports to attest to and report on your assessments, you can’t just make baseless claims regarding the effectiveness of your internal controls. As a matter of fact, you are mandated by both SEC and PCAOB to follow widely accepted control frameworks like COSO and COBIT. This framework will serve as a uniform guide for the internal controls you set up, the assessments you arrive at, and the attestation your external auditor reports on.

Why compliance of Section 404 is costly

Regardless which of the widely acceptable control frameworks you end up using, you will always be asked to document and test your controls. These activities can consume a considerable amount of man-hours and bring about additional expenses. Even the mere act of studying the control framework and figuring out how to align your current practices with it can be very tricky and can consume precious time; time that can be used for more productive endeavours.

Of course, there are exceptions. An organisation with highly centralised operations can experience relative ease and low costs while implementing SOX 404. But if your organisation follows a largely decentralised operation model, e.g. if you still make extensive use of spreadsheets in all your offices, then you’ll surely encounter many obstacles.

According to one survey conducted by FEI (Financial Executives International), an organisation that carried out a series of SOX-compliance-related surveys since the first year of SOX adoption, respondents with centralised operations enjoyed lower costs of compliance compared to those with decentralised operations. For example, in 2007, those with decentralised operations spent 30.1 % more for compliance than those with centralised operations.

The main reason for this disparity lies in the disorganised and complicated nature of spreadsheet systems.

Read why spreadsheets post a burden when complying with SOX and other regulations.

Unfortunately, a large number of companies still rely heavily on spreadsheets. Even those with expensive BI (Business Intelligence) systems still use spreadsheets as an ad-hoc tool for data processing and reporting.

Because compliance with Section 404 involves a significant amount of fixed costs, smaller companies tend to feel the impact more. This has been highlighted in the ?Final Report of the Advisory Committee on Smaller Public Companies? published on April 23, 2006. In that report, which can be downloaded from the official website of the US Securities and Exchange Commission, it was shown that:

  • Companies with over $5 Billion revenues spent only about 0.06% of revenues on Section 404 implementation
  • Companies with revenues between $1B – $4.9B spent about 0.16%
  • Companies with revenues between $500M – $999M spent about 0.27%
  • Companies with revenues between $100M – $499M spent about 0.53%
  • Companies with revenues less than $100M spent a whopping 2.55% on Section 404

Therefore, not only can you discern a relationship between the size of a company and the amount that the company ends up spending for SOX 404 relative to its revenues, but you can also clearly see that the unfavourable impact of Section 404 spending is considerably more pronounced in the smallest companies. Hence, the smaller the company is, the more crucial it is for that company to find ways that can bring down the costs of Section 404 implementation.

How to alleviate costs of section 404

If you recall the FEI survey mentioned earlier, it was shown that organisations with decentralised operations usually ended up spending more for SOX 404 implementation than those that had a more centralized model. Then in the ?Final Report of the Advisory Committee on Smaller Public Companies?, it was also shown that public companies with the smallest revenues suffered a similar fate.

Can we draw a line connecting those two? Does it simply mean that large spending on SOX affects two sets of companies, i.e., those that have decentralised operations and those that are small? Or can there be an even deeper implication? Might it not be possible that these two sets are actually one and the same?

From our experience, small companies are less inclined to spend on server based solutions compared to the big ones. As a result, it is within this group of small companies where you can find a proliferation of spreadsheet systems. In other words, small companies are more likely to follow a decentralised model. Spreadsheets were not designed to implement strict control features, so if you want to apply a control framework on a spreadsheet-based system, it won’t be easy.

For example, how are you going to conduct testing on every single spreadsheet cell that plays a role in financial reporting when the spreadsheets involved in the financial reporting process are distributed across different workstations in different offices in an organisation with a countrywide operation?

It’s really not a trivial problem.

Based on the FEI survey however, the big companies have already found a solution – employing a server-based system.

Typical server based systems, which of course espouse a centralised model, already come with built-in controls. If you need to modify or add more controls, then you can do so with relative ease because practically everything you need to do can be carried out in just one place.

For instance, if you need to implement high availability or perform backups, you can easily apply redundancy in a cost-effective way – e.g. through virtualisation – if you already have a server-based system. Aside from cost-savings in SOX 404 implementation, server-based systems also offer a host of other benefits. Click that link to learn more.

Not sure how to get started on a cost-effective IT compliance initiative for SOX? You might want to read our post How To Get Started With Your IT Compliance Efforts for SOX.?

Ready to work with Denizon?