Systems & Solutions

System implementation tips…

A million and one (and counting…) of these already, but here’s my view. This is based on my experience with the SAP ecosystem, but I am fairly certain that most of it applies to most other ERP- and ERP-like enterprise software packages as well. It is more or less the antithesis to the large, System Integrator (SI)-driven business transformation programs that I have been part of for the last years, but these are hard learnings based on many hours of my life so that must count for something – right?

So, very quickly why doesn’t the “business-as-usual” approach work?**:

  • “Waterfall” project models give a very long feedback cycle on the quality of the chosen solutions as the whole project is effectively design-build-test-deploy-evaluate. The long feedback cycle also prevents effective business feedback on the solution because the “real users” don’t see it before it is too late to make significant changes. To quickly and effectively deal with unforeseen technical issues and weak business requirements you should aim for design-build-validate (cyclic) and then test-deploy (linear).
  • Functional silo-thinking overlooks end-to-end solutions: In any (complex) business process, end-to-end alignment is king because the hard part is not solving a problem, the hard part is solving one problem without causing five new ones in a different area of your end-to-end process.
  • Functional silos impede progress: If the focus from program management in designing/building/testing (and this might be typical for SI-driven programs) is “why do you have so many issues in sales” then the challenge for any functional team will be to reduce the number of issues – not to deal with the issues causing the biggest impact for other areas. This might paradoxically lead to cases where teams prioritise the simple issues to make their stats look better, rather than solving the hard problems that genuinely impede progress and reduce solution quality. Defects and other issues should therefore be rated in order of their importance, but the criticality needs to be two-axis, both business/solution impact and project/progress impact.
  • Functional silo thinking prevents focus on real results: The ultimate goal is a successful business transformation – not just a successful golive. So instead of a focus on outputs, the focus must be squarely on achieving the desired outcomes.

**Obviously, it does work in the sense that stuff gets delivered. My claim is just that by following these guidelines you’ll be able to get a) more stuff done that really matters b) more done for less money invested.

Now, in terms of more practical advice, here are a few of the most important points for me:

Methodology:

  • After basic solution scoping and initial design of the solution, adopt a semi-agile approach instead of the normal design/build/test/deploy waterfall:
    • 1) Configure/develop the basic standard process and test with the business experts to ID gaps in functionality.
    • 2) Build the “core integration” (interfaces) and major functional enhancements that significantly impact the process flows. Repeat testing/validation to fix issues and ID additional gaps.
    • 3) Once the basic process is stable and working E2E, build on other functional enhancements and “cosmetics” such as outputs, forms etc. that are necessary but has less impact on the E2E process flow and stability of the process (this would include any unavoidable, legally-mandated outputs etc. because they may be important but they do not change the process)
    • 4) Feed each sub process into the testing cycle once it is ready (or via a stage-gate procedure to allocate scarce resources between development and testing).
      This should mean that the most basic flows and those with the highest business benefits are handed over to testing first and receive the most attention.
  • Use a project manager/lead for each E2E process to manage scope, ensure gaps are constantly prioritised and that overall progress is maintained.
  • For integration- and acceptance testing with more people/functions involved, a key metric should be rate of flow, which can be helped by “loading the test pipeline from the back”. This means e.g. making OTC-scripts that are simple in sales/logistics and complex in finance and then building up the complexity in sales/logistics gradually. This should ensure that you quickly get testing to a stage where everyone has stuff to work on, instead of having massive complexity in sales blocking logistics and finance from doing anything for a long time.

 

Team/resources:

  • Use a small team of business experts and system experts with focus (= 100% assignment to the project) and a clear mandate to make decisions on behalf of the business. Only expand the team if it is absolutely needed to fulfil specific needs in terms of capability or capacity. Work normally expands to fill the available hands anyway and having as few people in the loop as possible reduces complexity and speeds up issue resolution.
  • Let the business leads decide whether to add more people to the project or not, not the SI. When what you are selling is people’s time, it’s no wonder that the automatic response to any sign of trouble usually is “we need more people”. Your business leads will normally be able to judge whether there is really a benefit of more people or whether the marginal cost/complexity of enlarging the team outweighs any benefits (because at some point it will…).
  • Build the project organisation on a process-based E2E structure and responsibility, e.g. an MTC-team responsible for making the entire market-to-cash process work instead of only the sales part of the process. Use these teams to ID the process variants of the business and prioritise them based on business value (usually share of revenue/profit), frequency of execution and customer impact as part of the initial scoping and design phases.
  • Functional alignment in sales, logistics etc. should be used as well, but mainly to prevent inconsistent approaches and conflicts where there are overlaps in configuration and functionality. Each process lead needs to be accountable for this cross-functional alignment activity as well.
  • Note that this is a big change in the way of working for many organisations, so if you’re concerned that this is too much to swallow, then start out with a functional organisation during requirements gathering and move into the process organisation towards the start of testing. A project like this will always be a matrix-structure anyway, so the only question is really which part of the matrix structure that leads and that should then change over time as the project progresses.

 

Requirements gathering:

  • When designing and building the solution, don’t aim to solve the business “how” but the business “why”. Differentiate between “business requirements” and “solution requirements”.
    A business requirement is a request for a specific output or outcome and it may be grounded in a real need – or it may be grounded or in legacy thinking, misunderstandings in what the system can do, stakeholder conflicts, weak/undocumented business processes and so on.
    A solution requirement on the other hand is an approved addition to the solution that has been screened and assesed based on at least three key criteria:

    • 1) It adds overall value to the business.
    • 2) It passes at least a very simple “value for money” test on business benefit vs. cost to implement.
    • 3) It is delivered in the most technically appropriate way, taking into account as many technical and business process considerations as needed (both long and short term).
  • Ensure that nothing is accepted as a solution gap unless the business rationale for the gap is captured and the impact is clear enough to be used for prioritisation. The key reason for this is that requirements change and/or become obsolete over time and so the rationale will be key to managing the solution after implementation. The rationale is what tells you whether something needs to be considered when new requirements come along or if it can comfortably be ignored or changed because its out of date.

And last but not least: If anyone comes in claiming that their solution design or approach is “best practice”, kick them out of the room as quickly as possible before they do any real damage… Always ask for rational for choosing something vs. your requirements. You’re not interested in what worked for others, you’re interested in something that will work for you 🙂

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.