Tag Archives: ERP

Have we reached peak SI

Have we hit the peak for systems integrators (SIs) (just as we appear to have reached “peak oil”), and it’s all downhill from here? While SIs are doing well at the moment, structural changes in the IT market suggest that the long term forecast is not all sunshine and roses as some pundits are predicting. With IT spend migrating from IT departments (the SI’s traditional buyer) into the lines of business, the ongoing shift to smaller projects delivering on-demand (rather than on-premesis) solutions, and the replacement of traditional support arrangements with outsourced and managed services, it’s hard to see how SIs will continue to grow when demand for their services seems to be tipping into decline. Globalisation, software as a service (SaaS) and cloud computer are reconfiguring the IT landscape and SIs look like they will be the big losers.

Predictions for the continued growth of the SI market are based on the understanding that companies are consuming more IT today than they were yesterday, and the assumption that increased IT consumption will result in tidy profits for SIs. Predictions are a funny things though, based as they are on historical trends. Guess that the market will continue to rise when you’re in the midst of a bull market and you’ll be right, most of the time. That is until something happens, something you didn’t anticipate, something that catches you unawares. The assumption that SI revenue is tied to IT consumption might no longer be true. New tools such as SaaS and cloud computing are enabling line-of-business leaders to step around the traditional IT department and engage with technology directly, bypassing the SIs traditional relationships in IT and providing them with fewer opportunities to sell their wares. At the same time the shift from on-premises to on-demand solutions – solutions which the business is happy to rent rather than own – is slashing the effort required to install, configure and integrate these new solutions, often by as much as seventy to eighty percent. On-demand solutions also have much lighter support needs relying on self-help wikis, users forums and power users, leaving the SI with little more than a small help desk to manage. With only limited access to this new class of IT buyer, dramatically smaller projects, and lower support revenue, the SIs role as IT enabler seems to be in decline. All good things come to an end though, and you usually only realise that the end has come after it has already passed. IT consumption might be going up, but there’s a good chance that SI revenue could soon be going down at the same time.

SIs are fundamentally sandwich shops{{1}}. When we don’t have the time or money to maintain our own kitchen or make our own sandwiches it can be more efficient to head over to the local sandwich shop to pick up what we need. Their margins are thin and revenue is largely tied to the size of the sandwich you just bought, so they’d really like you to buy a larger and more expensive sandwich. (Notice how sandwiches have grown so much bigger over the years, and everything is now gourmet?) And, of course, pre-made sandwiches are always a lot cheaper than special orders. This sandwich shop model is something that was established early on in the history of business IT. How else could companies afford to access the rare (and expensive) IT skills they needed to create all the systems they need? This might be a payroll system, or stock management, sales pipeline reporting, or the dreaded enterprise resource planning (ERP). Consuming IT used to mean hiring an SI to build and integrate something for you.

[[1]]Business models for the old rules of IT @ PEG[[1]]

The world has changed since then. Back when I started in the industry my home computer couldn’t hold a candle to the beast I was given at work. Today, however, my shiny new 17″ MacBook Pro makes the locked down Windows XP laptops I’m offered seem like a bit of a joke. A new breed of business manager has crept into the business while the world has changed, these are people who grew up with technology and are comfortable solving their technology problems on their own. They know that there are alternatives to the expensive solutions proposed by the IT department (solutions that IT will engage an SI to deliver), and they’re happy to use these alternatives. Why spend a seven figure sum and wait a year for the IT department’s perfect, enterprise-wide project portfolio management solution when there’s one that is good enough, one you can buy on-demand via a company credit card, and one which you know will be up and running in a couple of weeks? We might argue about the regret cost{{2}}, but the art of business is to make a timely decision and then make it work; it’s not to sit on your hands and wait for the perfect solution which will be delivered sometime in the distant future. While demand for new IT solutions might be growing, every time a business manager steps around IT to engage and on-demand solution SIs have one less opportunity to sell their wares.

[[2]]The price of regret @ PEG[[2]]

At the same time we find that these on-demand solutions – when SIs do get their hands on them – only provide a fraction of the revenue that a tradition on-premisis solution does. Time is money for an SI (literally, as most avoid risk by sticking to time and materials contracts) and fielding a SaaS solution takes only a fraction of the time required for a more traditional solution. There’s no hardware to commission with SaaS or cloud computing, nor are there disks to wait for or backup strategies to create. (You still need to worry about business continuity, but that’s another post.) There’s also little chance for customisation, and integration tends to be via standard APIs or pre-built adaptors. It’s not uncommon for a SaaS project to be eighty percent smaller than the more traditional solution. Fewer resources on ground and fewer billable hours means that that the SI can expect their revenues to head in the same direction: south.

We’re also seeing the erosion of SI support revenues. Support used to encompass both the application – in terms of application maintenance, patching and security – and the users – with training and a help desk. Many SaaS and cloud providers don’t want to provide traditional support services as it erodes their margins, margins based on huge scale and little human contact. One solution is to engage an SI to provide these services for them, either on a client-by-client bases or as part of some sort of alliance. A more attractive solution is to move – as much as possible – to a self support model where clients support each other via user forums or a Google search. We soon find that a much smaller help desk will suffice as it’s only required to be the point of last resort, or to support the more technologically illiterate users.

Taken together, these trends – reduced access to buyers, lower project revenues, and lower support revenues – seem to show that the future is not as rosy for the SIs as we first thought. Demand for IT might be growing, but growing demand for IT no longer implies growing demand for the services provided by SIs. The final nail in the coffin is the fairly recent move into SaaS by established IT application vendors. Microsoft has gone on record as wanting to capture a greater percentage of IT spend as license revenues, converting SI installation and customisation costs into licenses by providing clients with prepackaged configurations which can be turned on at the flick of a switch. Rather than pay for a SaaS CRM and then engaging an SI to configure it to your liking, you pay for the SaaS CRM along with a canned sales methodology (Miller Heiman{{3}}? Holden{{4}}?) which works out of the box (as it were). Integration between SaaS solutions is also being converted into a configuration option as SaaS vendors sign alliances – just as Google and Saleforce.com did with GoogleForce – enabling these alliances to offer complete application suites which work together out of the box.

[[3]]Miller Heiman: The Sales Performance Company[[3]]
[[4]]Holden International: Outsell You Competition[[4]]

Whichever way you look at it, now is not a good time to be a SI.

The rules of enterprise IT

As I’ve pointed out before (possibly as I’m quite fond of games{{1}}) the game of enterprise IT has a long an proud history. I’ve also pointed out that the rules of this game need to change if enterprise IT — as we know it — is to remain relevant in the future{{2}}. This is triggered a few interesting conversations at the pub on just what are the old rules of IT.

[[1]]Capitalise: A game for the whole company to play![[1]]
[[2]]People don’t like change. (Or do they?)[[2]]

Enterprise IT, as we know it today, is an asset management business, the bastard son of Henry Ford’s moving production line. Enterprise IT takes the raw material of business processes and technology and turns them into automated solutions. From those first card tabulators through to today’s enterprise applications, the focus has been on delivering large IT solutions into the business.

The rules of enterprise IT are the therefore rules of business operations. After a fair amount of coffee and beer with friends, the following 4 ± 2 rules seems to be a fair minimum set (in no particular order).

Keep the lights on. Or, put more gently, the ticket to the strategy table is a smooth running business. Business has become totally reliant on IT, while at the same time IT is still seen as something of a black art run by a collection of unapproachable high priests. The board might complain about the cost and pain of an ERP upgrade, but they know they have to find the money if they want to successfully close the books at the end of the financial year. While this means that the money will usually be found, it also means that the number one rule of being a CIO is to keep the transactions flowing. Orders must be taken, products shipped (or services provided), invoices sent and cash collected. IT is an operational essential, and any CIO who can’t be trusted to keep the lights on won’t even have time to warm up their seat.

Save money. IT started as a cost saving exercise: automatic tabulation machines to replace rooms full of people shuffling papers, networks to eliminate the need to truck paper from one place to another. From those first few systems through to today’s modern enterprise solutions, applications have been seen as a tool to save time and money. Understand what the business processes or problem is, and then support the heavy information lifting with technology to drive cost savings and reduce cycle time. Business cases are driven by ideas like ROI, capturing these savings over time. Keep pushing the bottom line down. These incremental savings can add up to significant changes, such as Dell’s make-to-order solution{{3}} which enabled the company to operate with negative working capital (ie. they took your cash before they needed to pay their suppliers), but the overall approach is still based on using IT to drive cost savings through the automation of predefined business processes.

[[3]]Dell’s make to order solution leaves competitors in the dust.[[3]]

Build what you need. When applications are rare, then building them is an engineering challenge. You can’t just go to the store and by the parts you need, you need to create a lot of the parts yourself in your own machine shop. I remember the large teams (compared to today) from the start of my career. A CORBA project didn’t just need a team to implement the business logic, it needed a large infrastructure team (security guy, transaction guy …) as well. Many organisations (and their strong desire to build – or at least heavily customise – solutions) still work under this assumption. IT was the department to marshal large engineering teams who deliver the industrial grade solutions which can form the backbone of a business.

Ferrero Rocher
Crunch on the outside, soft and chewy in the middle.

Keep the outside outside. It’s common to have what is called a Ferrero Rocher{{4}} approach to IT: crunchy on the outside while soft and chewy in the middle. This applies to both security and data management. We visualise a strong distinction between inside and outside the enterprise. Inside we have our data, processes and people. Outside is everyone else (including our customers and partners). We harvest data from our operations and inject it into business intelligence solutions to create insight (and drive operational savings). We trust whatever’s inside our four walls, while deploying significant security measures to keep the evil outside.

[[4]]Ferrero[[4]]

It’s a separate question of whether or not these rules are still relevant in an age when business cycles are measured in weeks rather than years, and SaaS and cloud computing are emerging as the dominate modes of software delivery.

Why we can’t keep up

We’re struggling to keep up. The pace of business seems to be constantly accelerating. Requirements don’t just slip anymore: they can change completely during the delivery of a solution. And the application we spent the last year nudging over the line into production became instant legacy before we’d even finished. We know intuitively that only a fraction of the benefits written into the business case will be realized. What do we need to do to get back on top of this situation?

We used to operate in a world where applications were delivered on time and on budget. One where the final solution provided a demonstrable competitive advantage to the business. Like SABER, and airline reservation system developed for American Airlines by IBM which was so successful that the rest of the industry was forced to deploy similar solutions (which IBM kindly offered to develop) in response. Or Walmart, who used a data warehouse to drive category leading supply chain excellence, which they leveraged to become the largest retailer in the world. Both of these solutions were billion dollar investments in todays money.

The applications we’ve delivered have revolutionized information distribution both within and between organizations. The wave of data warehouse deployments triggered by Walmart’s success formed the backbone for category management. By providing suppliers with a direct feed from the data warehouse—a view of supply chain state all the way from the factory through to the tills—retailers were able to hand responsibility for transport, shelf-stacking, pricing and even store layout for a product category to their suppliers, resulting in a double digit rises in sales figures.

This ability to rapidly see and act on information has accelerated the pulse of business. What used to take years now takes months. New tools such as Web 2.0 and pervasive mobile communications are starting to convert these months into week.

Take the movie industry for example. Back before the rise of the Internet even bad films could expect a fair run at the box-office, given a star billing and strong PR campaign too attract the punters. However, post Internet, SMS and Twitter, the bad reviews have started flying into punters hands moments after the first screening of a film has started, transmitted directly from the first audience. Where the studios could rely a month or of strong returns, now that run might only last hours.

To compensate, the studios are changing how they take films to market; running more intensive PR campaigns for their lesser offerings, clamping down on leaks, and hoping to make enough money to turn a small profit before word of mouth kicks in. Films are launched, distributed and released to DVD (or even iTunes) in weeks rather than months or years, and studios’ funding, operations and the distribution models are being reconfigured to support the accelerated pace of business.

While the pulse of business has accelerated, enterprise technology’s pulse rate seems to have barely moved. The significant gains we’ve made in technology and methodologies has been traded for the ability to build increasingly complex solutions, the latest being ERP (enterprise resource planning) whose installation in a business is often compared to open heart surgery.

The Diverging Pulse Rates of Business and Technology

This disconnect between the pulse rates of business and enterprise technology is the source of our struggle. John Boyd found his way to the crux of the problem with his work on fighter tactics.

John Boyd—also know as “40 second Boyd”—was a rather interesting bloke. He had a standing bet for 40 dollars that he beat any opponent within 40 seconds in a dog fight. Boyd never lost his bet.

The key to Boyd’s unblemished record was a single insight: that success in rapidly changing environment depends on your ability to orient yourself, decide on, and execute a course of action, faster than the environment (or your competition) is changing. He used his understanding of the current environment—the relative positions, speed and performance envelopes of both planes—to quickly orient himself then select and act on a tactic. By repeatedly taking decisive action faster than his opponent can react, John Boyd’s actions were confusing and unpredictable to his opponent.

We often find ourselves on the back foot, reacting to seemingly chaotic business environment. To overcome this we need to increase the pulse of IT so that we’re operating at a higher pace than the business we support. Tools like LEAN software development have provided us with a partial solution, accelerating the pulse of writing software, but if we want to overcome this challenge then we need to find a new approach to managing IT.

Business, however, doesn’t have a single pulse. Pulse rate varies by industry. It also varies within a business. Back office compliance runs at a slow rate, changing over years as reporting and regulation requirements slowly evolve. Process improvement and operational excellence programs evolve business processes over months or quarters to drive cost out of the business. While customer or knowledge worker facing functionality changes rapidly, possibly even weekly, in response to consumer, marketing or workforce demands.

Aligning technology with business

We can manage each of these pulses separately. Rather than using a single approach to managing technology and treating all business drivers as equals, we can segment the business and select management strategies to match the pulse rate and amplitude of each.

Sales, for example, is often victim of an over zealous CRM (customer relationship management) deployment. In an effort to improve sales performance we’ll decide to role out the latest-greatest CRM solution. The one with the Web 2.0 features and funky cross-sell, up-sell module.

Only of a fraction of the functionality in the new CRM solution is actually new though—the remainder being no different to the existing solution. The need to support 100% of the investment on the benefits provided by a small fraction of the solution’s features dilutes the business case. Soon we find ourselves on the same old roller-coaster ride, with delivery running late,  scope creeping up, the promised benefits becoming more intangible every minute, and we’re struggling to keep up.

There might be an easier way. Take the drugs industry for example. Sales are based on relationships and made via personal calls on doctors. Sales performance is driven by the number of sales calls a representative can manage in a week, and the ability to answer all of a doctor’s questions during a visit (and avoid the need for a follow-up visit to close the sale). It’s not uncommon for tasks unrelated to CRM—simple tasks such as returning to the office to process expenses or find an answer to a question—to consume a disproportionate amount of time. Time that would be better spent closing sales.

One company came up with an interesting approach. To support the sales reps in the field they provided them with the ability to query the team back in the office, answering a clients question without the need to return to head office and then try to get back in their calendar. The solution was to deploy a corporate version of Twitter, connecting the sales rep into the with the call center and all staff using the company portal via a simple text message.

By separating concerns in this way—by managing each appropriately—we can ensure that we are working at a faster pace than the business driver we supporting. By allocating our resources wisely we can set the amplitude of each pulse. Careful management of the cycles will enable us to bring business and technology into alignment.