Monthly Archives: June 2010

Our brand is worth everthing

I don’t know how many times I’ve heard that statement. Too many, I expect. Unfortunately it usually means that engaging with the root cause of the problem we’re trying to solve is too awkward or uncomfortable, so it’s time to reach for the magical (technological) pixie dust. The glib, absolute statement thrown onto the table is a flag that the root cause of the problem is cultural, or even a leadership issue. Solving the problem is going to require a bit more than a little technology delivered by smiling consultants.

Every couple of years I seem to come across another glib “Our brand is everything”. (Though, at the moment the rise of cloud computing is providing more “but its not secure” glibness than anything else.) I’ll be sitting around a table with some senior IT and business folk talking about a broken manual process. More often than not it will involve a workflow based on emailing spreadsheets around the team.

The risks are fairly obvious. Aside from the double entry problems and the risk of lost orders, there’s always the chance of litigation over an implied contract in some casually sent email (or tweet). There’s also the risk for a disenchanted insider sending something they shouldn’t to someone they should not.

After wandering around the issue for a little while, we start discussing possible solutions. My first question is usually something like “What resources are you willing to commit to solving the problem?” It’s at this point that the comment is thrown onto the table; usually in earnest. “Our brand is worth everything.”

Rather than go to the effort actually trying to engage with the problem we’re dealing with, the statement indicates the desire for a magical cure-all. If we sprinkle magical technology pixie dust over the problem then it will just go away.

Technology can only ever go so far to solving a problem. We can use technology to speed something up (swapping paper shuffling for bit shuffling). Or we can use technology to stop specific things from happening (i.e. enforcing governance policies). We can’t use it to prevent something we never imagined.

Most interesting problems — like the manual workflow example — are rooted in peoples’ behaviour, and only have a small technology element. While the action, the bad event might change in each instance, the intent behind the action is probably the same. Even if we were given a blank cheque (which is probably the next thing I should ask for), we can’t hope to make more than a small dent in the problem. It’s like squeezing a ballon in your fist. Each time we push in one bulge, another one (or two) pops up in a different gap.

If we want to have a significant impact, then we really need a mandate to change the way the organisation works. Are the organisations own policies actually incenting employees (or partners, or customers) to work against the best interests of the organisation? (Like the point guard mentioned in the No-stars, all-star{{1}} article.) Do the existing IT solutions cause more problems than they solve? Just why did the problem happen in the first place?

[[1]]The no-stars all-star @ The New York Times[[1]]

Even a mandate has its limits though. Ultimately the behaviour of an organisation is determined by the behaviour of its leaders. The behaviour that caused the problem was a result of the culture created within the organisation.

The most useful tool to solve this sort of problem is the time and attention of the leadership team, along with a willingness to admit that no one is perfect, that mistakes will happen, and a sincere desire to improve the organisation.

When someone drops “Our brand is worth everything” on the table these days, I like to point out that bad things can happen, and will always happen. We can use technology to trap a few things, but the only long term solution is to create an environment when everyone involved — all the way from employees through partners, channels and customers — is naturally inclined to do the right thing.

Yelp seem to be learning this the hard way{{2}}. Accidents will always happen, and speedy and considerate response is acknowledged as the best we can do. However, creating a culture where “doing the wrong thing for the wrong reason” is accepted will eventually get you in trouble that you might not be able to get out of.

[[2]]Inside Yelp’s “Blackmail” Lawsuit: CEO Stoppelman Seems to Hate His Advertisers[[2]]

And hence we arrive at the real problem. A brand’s worth, after all, is a measure of what people think of an organisation; both customers buying your products or services, or the investors who want to know where you”re going. When bad things happen, and sometimes they happen quite regularly, the only real long term solution is to change the way we manage the organisation so that the root cause is no longer present. This means the people at the top need to change what they are doing. And give that the rules of IT have changed{{3}}, and we need to change with them.

[[3]]Some new rules for IT[[3]]

Innovation [2010-06-21]

Another week and another collection of interesting ideas from around the internet.

As always, thoughts and/or comments are greatly appreciated.

Vacuum flasks: fulfilling a need

As seen on a plaque at Scienceworks in the House Secrets exhibit.

James Dewar invented the vacuum flask in 1892 to keep laboratory gases cold. Twelve years later, Reinhold Burger manufactured the Thermos to keep our picnic drinks hot.

A nice demonstration of the third of Peter Drucker’s seven sources of innovation.

Innovation based on process need.

Or, put another way, James Dewar scratched an itch; though he did play Edison to Reinhold Burger’s Sameul Insull.

Posted via web from PEG @ Posterous

What I like about jet engines

Rolls-Royce{{1}} (the engineering company, not the car manufacturer) is an interesting firm. From near disaster in the 70s, when the company was on the brink of failure, Rolls-Royce has spent the last 40 years reinventing itself. Where it used to sell jet engines, now the company sells hot air out the back of the engines, with clients paying only for the hours an engine is in service. Rolls-Royce is probably the one of the cleanest examples of business-technology{{2}} that I’ve come across; with the company picking out the synergies between business and technology to solve customer problems, rather than focusing on trying to align technology delivery with a previously imagined production process to push products at unsuspecting consumers. I like this for a few reasons. Firstly, because it wasn’t a green fields development (like Craig’s List{{3}} et al), and so provides hope for all companies with more than a few years under their belt. And secondly, as the transformation seems to have be the result of many incremental steps as the company felt its way into the future, rather than as the result of some grand, strategic plan.

[[1]]Rolls Royce[[1]]
[[2]]Business-Technology defined @ Forrester[[2]]
[[3]]Craig’s list[[3]]

A Rolls-Royce jet engine

I’ve been digging around for a while (years, not months), looking for good business-technology case studies. Examples of organisations which leverage the synergies between business and technology to create new business models which weren’t possible before, rather than simply deploying applications to accelerate some pre-imagined human process. What I’m after is a story that I can use in presentations and the like, and which shows not just what business-technology is, but also contrasts business-technology with the old business and technology alignment game while providing some practical insight into how the new model was created.

For a while I’ve been mulling over the obvious companies in this space, such as Craig’s List or Zappos{{4}}. While interesting, their stories don’t have the impact that they could as they were green fields developments. What I wanted was a company with some heritage, a history, to provide the longitudinal view this needs.

[[4]]Zappos[[4]]

The company I keep coming back to is Rolls-Royce. (The engineering firm, not the car manufacturer). I bumped into a story in The Economist{{5}}, Britain’s lone high-flier{{6}}, which talks about the challenge of manufacturing in Britain. (Which is, unfortunately, behind the pay wall now.) As The Economist pointed out:

A resurgent Rolls-Royce has become the most powerful symbol of British manufacturing. Its success may be hard to replicate, especially in difficult times.

[[5]]The Economist[[5]]
[[6]]Britain’s lone high-flier @ The Economist[[6]]

With its high costs and (relatively) inflexible workforce, running an manufacturing business out of Britain can be something of a challenge, especially with China breathing down your neck. Rolls-Royce’s solution was not to sell engines, but to sell engine hours.

This simple thought (which is strikingly similar to the tail of the story in Mesh Collaboration{{7}}) has huge ramifications, pushing the company into new areas of the aviation business. It also created a company heavily dependent on technology, from running realtime telemetry around the globe through to knowledge management. The business model — selling hot air out the back of an engine — doesn’t just use technology to achieve scale, but has technology woven into its very fabric. And, most interestingly, it is the result of tinkering, small incremental changes rather than being driven by some brilliant transformative idea.

[[7]]Mash-Up Corporations[[7]]

As with all these long term case studies, the Rolls-Royce story does suffer from applying new ideas to something that occurred yesterday. I’m sure that no one in Rolls-Royce was thinking “business-technology” when the company started the journey. Nor would they have even thought of the term until recently. However, the story still works for me as, for all it’s faults, I think there’s still a lot we can learn from it.

The burning platform was in the late 60s, early 70s. Rolls-Royce was in trouble. The company had 10% market share, rising labour costs, and was facing fierce competition from companies in the U.S. Even worse, these competitors did not have to worry about patents (a hangover from the second world war), they also had a large domestic market and a pipeline of military contracts which put them in a much stronger financial position. Rolls-Royce had to do something radical, or facing being worn down by aggressive competitors who had more resources behind them.

Interestingly, Roll-Royce chose to try and be smarter than the competition. Rather than focus on incremental development, the company decided to designed a completely new engine. Using carbon composite blades and a radical new engine architecture (three shafts rather than two, for those aeronautical engineers out there) their engine was going to be a lot more complex to design, build and maintain. It would also be a lot more fuel efficient and suffer less wear and tear. And it would be more scalable to different aircraft sizes. This approach allows Rolls-Royce to step out of the race for incremental improvements in existing designs (designing a slightly better fan blade) and create a significant advantage, one which would take the company’s competitors more than the usual development cycle or two to erase.

Most of the margin for jet engines, however, is in maintenance. Some pundits even estimate that engines are sold at a loss (though the manufactures claim to make modest margins on all the engines they sell), while maintenance can enjoy a healthy 35%. It’s another case of give them the razor but sell them the razor blades. But if you give away the razors, there’s always the danger that someone else may make blades to fit your razor. Fat margins and commoditized technology resulted in a thriving service market, with the major engine makers chasing each other’s business, along with a horde of independent servicing firms.

Rolls-Royce’s interesting solution was to integrate the expertise from the two businesses: engine development and servicing. Rather than run them as separate businesses, the company convinced customers to pay a fee for every hour an engine was operational. Rather than selling engines, the company sells hot air out the back of an engine. This provides a better deal for the customers (pay for what you use, rather than face a major capital expense), while providing Rolls-Royce with a stronger hold on its customer base.

Integrating the two business also enabled Rolls-Royce to become better at both. Maintenance data helps the company identify and fix design flaws, driving incremental improvements in fuel efficiency while extending the operating life (and time between major services) tenfold over the last thirty years. It also helps the company predict engine failures, allowing maintenance to be scheduled at the most opportune time for Rolls-Royce, and their customers.

Rolls-Royce leveraged this advantage to become the only one of the three main engine-makers with designs to fit the three newest airliners in the market: the Boeing 787 Dreamliner, the Airbus A380 and the new wide-bodied version of the Airbus A350. Of the world’s 50 leading airlines, 45 use its engines.

Today, an operations centre in Derby assess, in real time, the performance of 3,500 jet engines enabling to Rolls-Royce to spot issues before they become problems and schedule just-in-time maintenance. This means less maintenance and more operating hours, fewer breakdowns (and, I expect, happier customers), and the operational data generated is fed back into the design process to help optimise the next generation of engines.

This photograph is reproduced with the permission of Rolls-Royce plc, copyright © Rolls-Royce plc 2010
Rolls-Royce civil aviation operations in Derby

This service-based model creates a significant barrier to competitors for anyone who wants to steal Rolls-Royce’s business. Even if you could clone Rolls-Royce’s technology infrastructure (hard, but not impossible), you would still need to recreate all the tacit operational knowledge the company has captured over the years. The only real option is to recreate the knowledge yourself, which will take you a similar amount of time as it did Rolls-Royce, while Rolls-Royce continues to forge ahead. Even poaching key personnel from Rolls-Royce would only provide a modest boost to your efforts. As I’ve mentioned before{{8}}, this approach has the potential to create a sustainable competitive advantage.

[[8]]One of the only two sources of sustainable competitive advantage available to us today @ PEG[[8]]

While other companies have adopted some aspects of Rolls-Royce’s model (including the Joint Strike Fighter{{9}}, which is being procured under a similar model), Rolls-Royce continues to lead the pack. More than half of its existing engines in service are covered by such contracts, as are roughly 80% of those it is now selling.

[[9]]The Joint Strike Fighter[[9]]

I think that this makes Rolls-Royce a brilliant example of business-technology in action. Rolls-Royce found, by trial and error, a new model that wove technology and business together in a way that created an “outside in” business model, focused on what customers what to buy, rather than on a more traditional “inside out” model based on pushing products out into the market that the company wants to sell. You could even say that it’s an “in the market” model rather than a “go to market” model. And they did this with a significant legacy, rather than as a green fields effort.

In some industries and companies this type of “outside in” approach was possible before advent of the latest generation of web technology, particularly if it was high value and the company already had a network in place (such as Rolls-Royce success). For most companies it is only now becoming possible with business-technology along with some of the current trends, such as cloud computing, which erase many of the technology barriers.

The challenge is to figure out the “in the market” model you need, and then shift management attitude. Given constant change in the market, this means an evolutionary approach, rather than a revolutionary (transformative) one.

Some new rules for IT

The other week I had a go at capturing the rules of enterprise IT{{1}}. The starting point was a few of those beery discussions we all have after work, where we came to wonder how the game of enterprise IT was changing. It’s the common refrain of big-to-small, the Sieble to Saleforce.com transition which sees the need for IT services (internal or external) change dramatically. The rules of IT are definitely changing. Now that I’ve had a go at old rules, I thought I’d have a go at seeing what the new rules might be.

As I mentioned before, enterprise IT has historically been seen as an asset management function, a production line for delivering large IT assets into the IT estate and then maintaining them. The rules are the therefore rules of business operations. My attempt at capturing 4 ± 2 rules (with friends) produced the following (in no particular order):

[[1]]The rules of Enterprise IT @ PEG[[1]]

  • Keep the lights on. Much like being a trucker, the trick is to keep the truck rolling (and avoid spending money on tyres). Otherwise known as smooth running applications are the ticket to the strategy table.
  • Save money. Business IT was born as a cost saving exercise (out with the rooms full of people, in with the punch card machines), and most IT business cases are little different.
  • Build what you need. I wouldn’t be surprised if the team building LEO{{2}} blew their own valve tubes. You couldn’t buy parts of the shelf so you had to make everything. This is still with us in some organisations’ strong desire to build – or at least heavily customise – solutions.
  • Keep the outside outside. We trust whatever’s inside our four walls, while deploying security measures to keep the evil outside. This creates an us (employees) and them (customers, partners, and everyone else) mentality.

[[2]]LEO: Lyons Electronic Office. The first business computer. @ Wikipedia[[2]]

Things have changed since these rules were first laid down. From another post of mine on a similar topic{{3}} (somewhat trimmed and edited):

[[3]]The IT department we have today is not the IT department we’ll need tomorrow @ PEG[[3]]

The recent global financial criss has fundamentally changed the business landscape, with many are even talking about the emergence of a new normal{{4}}. We’ve also seen the emergence of outsource, offshore, cloud computing, SaaS, Enterprise 2.0 and so much more.

Companies are becoming more focused, while leaning more heavily on partners and services companies (BPO, out-sourcers, consultants, and so on) to cover those areas of the business they don’t want to focus on. We can see this from the global companies who have effectively moved to a franchise model, though to the small end of town where startups are using on-line services such as Amazon S3, rather than building their own internal capabilities.

We’re also seeing more rapid business change: what used to take years now takes months, or even weeks. The constant value-chain optimisation we’ve been working on since the 70s has finally cumulated in product and regulatory life-cycles that change faster than we can keep up.

Money is also becoming (or has become) more expensive, causing companies and deals to operate with less leverage. This means that there is less capital available for major projects, pushing companies to favour renting over buying, as well as creating a preference for smaller, incremental change over the major business transformation of the past.

And finally, companies are starting to take a truly global outlook and operate as one cohesive business across the globe, rather than as a family of cloned business who operate more-or-less independently in each region.

[[4]]The new normal @ McKinsey Quarterly[[4]]

So what are the new 4 ± 2 rules? They’re not the old rules of asset management. We could argue that they’re the rules of modern manoeuvre warfare{{5}} (which would allow me to sneak in one of my regular John Boyd references{{6}}), but that would be have the tail wagging the dog as it’s business, and not IT that has that responsibility.

[[5]]Maneuver warfare @ Wikipedia[[5]]
[[6]]John Boyd @ Wikipedia[[6]]

I think that the new rules cast IT as something like that of a pit crew. IT doesn’t make the parts (though we might lash together something when in a pinch), nor do we steer the car. Our job is to swap the tyres, pump the fuel, and straighten the fender, all in that sliver of time available to us, so that the driver can focus on their race strategy and get back out on track as quickly as possible.

With that in mind, the following seems to be a fair (4 ± 2) minimum set to start with.

  • Timeliness. A late solution is often worse than no solution at all, as you’ve spent the money without realising any benefit. Or, as a wise sage once told me, management is the art of making a timely decision, and then making it work. Where before we could take the time to get it right (after all, the solution will be in the field for a long time and needs to support a lot of people, so better to discover problems early rather than later), now we just need to make sure the solution is good enough in the time available, and has the potential to grow to meet future demand. The large “productionisation” efforts of the past need to be broken into a series of incremental improvements (à la Gmail and the land of perpeputal beta), aligning investment with both opportunity and realised value.
  • Availability. Not just up time, but ensuring that all stakeholders (both in and outside the company, including partners and clients) can get access to the solutions and data they need. There’s little value in a sophisticated knowledge base solution if the sales team can’t use it in the field to answer customer questions in real time. Once they’ve had to fire up the laptop, and the 3G card, and the VPN, the moment has passed and the sale lost. Or worse, forcing them to head back to the bricks and mortar office. As I pointed out the other week, decisions are more important than data{{7}}, and success in this environment means empowering stakeholders to make the best possible decisions by ensuring that the have the data and functions they need, where they need, when they need it, and in a format that make it easy to consume.
  • Agility. Agility means creating an IT estate that meet the challenges we can see coming down the road. It doesn’t mean creating an infinitely flexible IT estate. Every bit of flexibility we create, every flex point we add, comes at a cost. Too much flexibility is a bad thing{{8}}, as it weighs us down. Think of formula one cars: they’re fast and they’re agile (which is why driving them tends to be a young mans game), and they’re very stiff. Agility comes from keeping the weight down and being prepared to act quickly. This means keeping things simple, ensuring that we have minimum set of moving parts required. The F1 crowd might have an eye for detail, such as putting nitrogen{{9}} in the tyres, but unnecessary moving parts that might reduce reliability or performance are eliminated. Agility is the cross product of weight, speed, reliability and flexibility, and we need to work to get them all into balance.
  • Sustainability. Business is not a sprint (ideally), and this means that cost and reliability remain important factors, but not the only factors. While timeliness, availability and agility might be what drive us forward, we need still need to ensure that IT is still a smooth running operation. The old rules saw cost and reliability as absolutes, and we strived to keep costs as low, and reliability as high, as possible. The new rules see us balancing sustainability with need, accepting (slightly) higher costs or lower reliability to provide a more timely, available or agile solution while still meeting business requirements. (I wonder if I should have called this one “balance”.)

[[7]]Decisions are more important than data @ PEG[[7]]
[[8]]Having too much SOA is a bad thing (and what we might do about it) @ PEG[[8]]
[[9]]Understanding the sport: Tyres @ formula1.com[[9]]

While by no mean complete or definitive, I think that’s a fair set of rules to start the discussion.

Innovation linkage

I gave a talk on innovation at Chisholm tonight in their Business Innovation Seminar Series, and promised to provide links to some of my references. Here they are:

Leave a comment if I’ve missed anything and I’ll try and find a reference.

Experiments in delinkification

Nick Carr’s recent blog post on delinkification{{1}} (putting the links at the end of a post as footers, rather than as hyperlinks in the text) made a lot of sense to me. Perhaps I’m old (though its all relative, as one bloke told me this morning{{2}}), but I find myself leaning heavily on browser tabs and Instapaper{{3}} to try and manage the distractions of links in text.

So I’ve decided to experiment. I’ve dropped in a plugin which converts links to footnotes (though it relies on magic markup, rather than doing it automatically and retrospectively as I would prefer), and going forward I’ll give footnotes a go. It might work, or it might suck. Who am I to know though. Ping me with your thoughts, if they lean one way or the other.

[[1]]Experiments in delinkification @ RoughType[[1]]
[[2]]Peter Fingar[[2]]
[[3]]Instapaper[[3]]

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.

Innovation [2010-06-07]

Another week and another collection of interesting ideas from around the internet.

As always, thoughts and/or comments are greatly appreciated.

Business is like a train…

The following analogy popped up the other day in an email discussion with a friend.

Running a business is a bit like being the Fat Controller, running his vast train network. We spend our time trying to get the trains to run on time with the all too often distraction of digging the Troublesome Trucks out of trouble.

Improvement often means upgrading the tracks to create smoother, straighter lines. After years of doing this, any improvement to the tracks can only provide a minor, incremental benefit.

What we really need is a new signalling system. We need to better utilise the tracks we already have, and this means making better decisions about which trains to run where, and better coordination between the trains. Our tracks are fine (as long as we keep up the scheduled maintenance), but we do need to better manage transit across and between them.

Swap processes for tracks, and I think that this paints quite a nice visual picture.

Years of processes improvement (via LEAN, Six Sigma and, more recently, BPM) had straightened and smoothed our processes to the point that any additional investment has hit the law of diminishing returns. Rather than continue to try and improve the processes on my own, I’d outsource process maintenance to a collection of SaaS and BPO providers.

The greater scale of these providers allows them to invest in improvements which I don’t have the time or money for. Handing over responsibility also creates the time and space for me to focus on improving the decisions on which process to run where, and when: my signalling system.

This is especially important in a world where it is becoming rare to even own the processes these days.

We forget just how important a good signalling system is. Get it right and you get the German or Japanese train networks. Get it wrong and you rapidly descend into the second or third world, regardless of the quality of your tracks.