The Architecture of Business

How to recognize a customer?

In response to yet-another-discussion at work about the “customers” of IT, I started thinking about coming up with a definition of what customers really are – and who actually deserves being called a customer within the organisation. My best shot for now is the following:

“A customer is any (external) person or entity that contributes a net positive cash flow to the enterprise”

Seems fairly simple (and no, it’s probably not perfect), but actually there are some important implications hidden in here:

  • In some industries, you may sell a ton products to certain people at very little to no margin but the resulting scale drives down your cost of operations overall and the overall relationship thus ends up being very cash-flow positive.
  • In other industries, you may sell some products to people where you then spend so much money on marketing contributions, after-sales service, various long-term incentive and retention schemes etc. that your relationship with the “customer” actually ends up cash-flow negative overall.

The challenge in both cases is of course whether you have the tools and the data to see when the balance, on an enterprise-wide scale, tips from one to the other side (my guess is that most companies, especially large ones, don’t).

So does that make my sales department a customer (because they claim that they bring in all the money?) someone asks? No, because the sales department in itself does not contribute any cash flow into the enterprise, but it acts as an enabler to get external entities to contribute (they are also internal to the enterprise which to me is a disqualifier, but some would definitely disagree here).

And of course last but not least does it mean that all business functions are “customers” of IT? Not to me, because there is no positive cashflow into the enterprise from what the LoB functions buy from internal IT – it’s just moving money from one side of the cigar box to another. Of course there is a significant cashflow from the business, via IT and out of the enterprise to suppliers, partners and consultants but that’s a different matter. Again, it’s redistribution of funds from one part of the enterprise to another, or it is a part of the enterprise cash flow that IT controls on behalf of the business. Of course that spend has to be made in the best interest of the enterprise, but the spend in itself should not be a problem  – you wouldn’t close down your procurement department because they are the company’s biggest spender, would you?

But wait, I hear someone shouting from the back, just because you’re cash flow positive doesn’t mean that you are profitable – no, and that’s what differentiates “a customer” from “a good customer” 😉

To centralise or not – that is the question…

(…with all due apologies to Shakespeare and Hamlet)

Have been involved in a few of these discussions lately and many people seem to present the opinion that centralisation is the best, if not only, way to achieve order, efficiency and effectiveness. Consequently, if you are against centralisation you must by definition (almost at least…) be an anarchist or even a saboteur – because who else would be against efficiency and effectiveness?

However, in my experience (and at least at the process level where I do most of my work) the truth isn’t quite so black and white. My theory is that there is a rough normal distribution of a company’s processes, where both tails should definitely be either central or decentral, but also the majority is somewhere in the middle. In this middle band, you can pursue both strategies with almost equal chance of success, as long as you actually follow through on the decision. By ‘follow through’ I mean that you deal with the inevitable downsides of your decision, meaning:

  • Want to do central data creation and maintenance with a CoE-type setup? Well, you get central knowledge and you get the opportunity to leverage scale and over time build a real center of excellence to improve your business,. However, do your current processes support getting information from the people ‘on the coal face’ to the central team that executes changes – and do people feel a sense of shared responsibility and urgency? If you haven’t specifically addressed this and taken steps to analyse, influence and monitor, then the answer is likely to be a no.
  • Want to do decentral invoice approval? Great, you get a chance to promote accountability in the organisation and a very good chance to influence unfortunate spending habits where it really makes a difference (with the individual and/or department) – but you need to deal with training, turnover, more training, continuous policy enforcement, even more training for new joiners and so on.

So, the discussion on centralisation is now a strategy vs. execution discussion, where it isn’t what you decide that wins, but instead what you actually act on afterwards that matters. And, as Peter Drucker observed; “Culture eats strategy for breakfast!”, meaning that to strategise is comparatively easy, whereas influencing habits is usually very hard.

So, the next time you are in a room with someone discussing the benefits of centralisation, start probing them on whether they are aware of the consequences of the decision and if they are ready to follow through when it matters…

When to act and when to wait?

OK, maybe a bit too broad as a headline, but this at least partly covers an oft-seen scenario when part of the organisation want to jump straight into building a solution for a given problem, while another part of the organisation wants to dig deeper into the problem first. In my experience, using the questions below is a good starting point to see if you are actually ready to start working on a solution – and it can defuse any impression that people that want to do more analyses aren’t just “slow” or “timid”.

Presenting the different responses to the questions (e.g. the five radically different perceptions of what the basic problem is) can be a very powerful way to show senior management and/or stakeholders without detailed knowledge of the situation that there are more versions of the truth out there. However, it can of course also be used the other way, to show that everyone are aligned on the problems and the best way forward is actually to try to build a fix for the problem and get some feedback on the effectiveness from the people that need to use it.

  • Problems and (potential) solutions:
    • Do all key stakeholders agree what the basic problem is? (you might be surprised how often this is a resounding “No!”…)
    • Do all key stakeholders agree on the (initial) scoping and prioritisation of issues?
    • Do all key stakeholders agree on the desired business outcome?

 

  • Impact:
    • Can we define clear success criteria for a solution and objective ways to measure them?
    • Can we predict the knock-on effects of what we are changing (systems/processes/organisation)?
    • Can we predict how a solution impacts our current way of doing business?

 

  • If answers are mostly YES = consider building a “minimum viable product”-based pilot and trying it. Use the collected experience and feedback from all stakeholders to refine and improve the solution.
  • If answers are mostly NO = consider doing more analysis and alignment to better understand the problem and it’s context. This will ensure that you have a solid foundation for any solution and hopefully avoid taking too many detours and wrong turns on the path from problem to solution.

Rational rationales…

I’ve long claimed that capturing the rationale for any business requirement/solution decision/whatever is possibly more important than capturing the actual requirement. Well, ok – as important as, then 🙂 Stumbled upon a good story today to back that up:

The problem is that if you can’t even explain why your own company does it this way, I am quite unconvinced that it could not be done better. For example, when more than a decade ago I worked with a large British newspaper company, I asked why their papers were so big. Their answer was “all quality newspapers are big; customers would not want it any other way.” A few years later, a rival company – the Independent – halved the size of its newspaper, and saw a surge in circulation. Subsequently, many competitors followed, to similar effect. Yes, customers did want it. Later, I found out that the practice of large newspapers had begun in London, in 1712, because the English government started taxing newspapers by the number of pages they printed — the publishers responded by printing their stories on so-called broadsheets to minimize the number of sheets required.  This tax law was abolished in 1855 but newspapers just continued printing on the impractically large sheets of paper.

Many practices and habits are like that; they once started for perfectly good reasons but then companies just continued doing it that way, even when circumstances changed. Take time to think it through, and ask yourself: Do I really understand why we (still) do it this way? If you can’t answer this question, I am pretty sure it can be done better.

From here.

This isn’t just important to prevent bad decisions now, but also to be able to prevent bad decisions later when circumstances change and business evolves. If you can’t remember why you did something in the first place, you don’t have a clue whether it is going to be a problem to do something else 🙂

The power of negative…

No, I don’t mean a negative attitude because although that feels great sometimes, I don’t think it is a particularly powerful way of accomplishing anything :). What I mean is “negative questions”, i.e. “what can you do without?”, “what should this not do?” etc.

Usually when developing requirements, the business stakeholder/sponsor has no incentive to remove any requirements, which either means you get a bloated list that isn’t realistic or you get to play the bad guy when you have to explain why the pitiful budget that was allocated does not cover the whole list of requirements. And sometimes both…

Even with an unlimited budget, asking what the requester can do without force thoughts about real needs and priorities, thus helping drive the really important discussions and tease out valuable information. In many of these situations you can “opt-in” on everything without any real cost and involvement, but you can’t “opt-out” of anything without considering the consequences first and that’s what the architect needs to take advantage of.

People are normally a bit taken aback when you ask them what a certain system/process should not do, but the answers are usually worth it – especially if they are open about their rationale for saying no. Try this technique and you may be surprised at the results as well.