Categories
Articles Project management

Improving project management by focussing on strategy and people

Many of the projects I’ve come into contact with over the years run into problems that stem from a lack of focus in two areas. A lack of ability to effectively deal with people. And a lack of depth of knowledge of strategy.

I’ve been around projects for almost 20 years. Working in roles such as systems analyst, business analyst, project manager, program manager, management consultant and change manager. During this time I’ve seen a wide variety of methods and tools applied, but regardless of those, there are consistent underlying problems.

The profile of the project manager is critical to a projects success. What experience do they have? what do they focus on? what tools do they use? how do they manage conflict? a good project manager needs a wide variety of skills.

If I were to estimate I would say around 1 in 5 projects that I come into contact with have good, multi-faceted project managers. The good news is we can all become better project managers and in this article I’d like to address one of the biggest opportunity areas for improvement.

I’ll start from where project managers are strong; methods and tools. Project management seems to attract people who are organised and enjoy structure and detail. They feel confident about studying approaches and tools and applying them to their projects. I often see a huge focus on topics such as:

  • Documenting the project e.g. writing scope statements;
  • Drafting plans including the very popular GANTT chart;
  • Preparing lists; issue lists, problem lists, change lists, stakeholder lists etc.

These are very important. However, having these in place doesn’t mean a project will be successful. In some cases, an over-reliance on these may cause problems.

The areas I don’t see enough focus on are strategy and people.

Strategy

Strategy can be challenging in many ways:

  • It’s difficult to access senior people responsible for strategy;
  • Strategy information is often not well deployed through an organisation;
  • To understand strategy requires a broad view of business, many project teams suffer from a silo focus on functions or technologies.

Ensuring you understand corporate documentation on strategy including annual reports or internal communication packs are a good start, but ideally you want to understand the nuances that senior management are focussed on.

People

Anthropology is a huge topic of it’s own. Why do people behave the way they do? This requires developing observational skills and experience of how to intervene in various situations.

As a starting point just being aware that people are a factor and taking this into consideration can make a difference.

Project management – where’s the people advice?

My path into project management will be somewhat familiar to many. I spent three years working as a systems / business analyst before being given the opportunity to manage my first project. I was both excited and scared about the prospect of becoming a project manager.

I had enough experience to know how projects worked. I had worked under good project managers and because of this I felt comfortable with the tools and methods. I had a solid understanding of how to:

  • Scope a piece of work;
  • Estimate effort and put together a team;
  • Create a work breakdown structure and draft a plan;
  • Plan and execute the stages of a systems development lifecycle;
  • etc.

Despite this, I was nervous about taking on my first project. The root cause of my nerves came down to the dependency on people. When we work as an analyst we can rely on technical skills and effort to deliver our work successfully. When we switch to project management it’s a completely new paradigm, we suddenly need to rely on a disparate team of individuals for success.

This is not the same as becoming a team leader. As a team leader we have levers such as career management, performance reviews etc. to build a relationship with our team. A project manager is in a unique position of relying on a team of people, while often having very little power over them.

Not all of the individuals on our project team will care about project success. Some may even be against it.

The question that none of the project methodologies would answer

As I started leading projects one challenge came up over and over again, and it appears very simple:

How can I get people that don’t work for me to do things?

I read the PMBOK from PMI, I read websites on Prince2, I studied my employer’s internal project management methods, I read our software vendors methods, I read various books, including the ‘project management for dummies‘; which I thought was very good.

(books / versions shown only for illustrative purposes)

In my opinion none could provide a satisfactory answer through the methods and tools listed. To illustrate the point; a google search for the PMBOK contents shows the 6th version of it as covering:

  • Section 1: Introduction
  • Section 2: The Environment in Which Projects Operate
  • Section 3: The Role of the Project Manager
  • Section 4: Project Integration Management
  • Section 5: Project Scope Management
  • Section 6: Project Schedule Management
  • Section 7: Project Cost Management
  • Section 8: Project Quality Management
  • Section 9: Project Resource Management
  • Section 10: Project Communications Management
  • Section 11: Project Risk Management
  • Section 12: Project Procurement Management
  • Section 13: Project Stakeholder Management

The titles alone show a lack of focus on strategy and people. I realise some aspects of strategy and people are considered in the sections above, but it’s not enough. I would propose chapter one should be about strategy and chapter two should be about people.

Scope, time, cost and quality relationship

An often cited relationship in project management is scope, time, cost and quality:

The idea being that the relationship between the the four are tied. For example if you have a delay (a problem with time), you may be able to reduce scope, to still hit your deadline. Or alternatively bring on extra resources (increase cost).

If you observe projects in practice I think this simply isn’t true. There are more factors that influence the relationship between these things. As a starting point I would re-draw it like this:

The way you work with people has a relationship with scope, time, cost and quality. If you use people well (with the same no. of resources and hence cost) you can deliver more work, faster and with higher quality.

If you have a clear understanding of the strategy your project supports; including the nuances of what the stakeholder wants, you can focus more accurately and provide better quality given the same scope, time and cost. It could be argued that ‘directing focus’ equates to managing scope, but I think this is too nuanced to be bundled in with scope management.

People problems – diving deeper

So far, I have spoken in conceptual terms. I’d like to go into some detail based on my own experience. In one of my first projects part of my team consisted of peers. From the first team meeting my peers decided to challenge me on various aspects of the project approach. Understandably the mindset of some team members at the start of a project might be, “why do we have to work for this person?”.

Dealing with resistance is a very common issue. If a project simply had to execute it’s planned deliverables the effort would be vastly less than what it often takes to complete a project. A huge amount of time and effort is spent on managing resistance, and justifying actions etc.

The starting point is to consider the source of resistence:

  • Team members don’t think project managers are experienced enough;
  • Team members don’t like project managers telling them what to do;
  • Team members simply don’t like their project manager;
  • Team members think they are better qualified to be the PM;
  • Team members think that the project is a distraction to their work;
  • Team members are too busy;
  • Team members believe the project puts their job or position at risk;
  • Team members have managers who don’t support the project;
  • (the list goes on…)

Often; if you make a list of resistance affecting your own project, you will find very few relate to a lack of capacity. Many are emotional. Some are related to fear; which can be founded or unfounded. Some are political.

Regardless of the reason for resistance the challenge remains the same:

How do we get people to do something they don’t want to do?

What the methods say

Popular project management methodologies tend to try to deal with getting things done through estimation, planning and monitoring:

  • Build a plan;
  • Regularly monitor progress on the plan;
  • Report status and escalate tasks that are behind schedule.

This can help organise work and ensure it’s clearly convey what is required. However it’s not always effective at making sure work is done on time and with quality. Examples:

Tracking task completion – assume there are tasks such as ‘map process’, ‘write development spec’, ‘build development’, ‘run integrated test’. Some project managers will regularly ask task owners for progress updates in the form of percentage complete. The percentages that are collected will often be inaccurate. There may be task owners who work diligently to provide accurate progress reports, but there will also be task owners that provide false percentages and leave work until the last minute. With larger projects, there isn’t time to micro-manage and check honesty. This can lead to finding delays only at the deadline which can have a critical path impact and cause a project delay. I recommend not to allow percentage completion tracking on tasks, consider them either done or not done. Keep pressure on for completion prior to deadlines.

Reporting status and escalating tasks which are behind schedule – another way to get tasks done is through escalation. There are a number of issues with this:

  • By the time escalation can happen there is already a delay;
  • On bigger programs sponsors and stakeholders can be demanding; in some circumstances project managers are expected to not escalate things to management;
  • In some cases the task owner that should be escalated may be connected to a stakeholder who is unsupportive of the project. Escalating can cause relationship levels at the executive level.

A people orientated approach

This is why I recommend a ‘people’ focussed approach. This is not rocket science. We all have skills in dealing with people, we learn these naturally as we grow and live. We just need to be conscious of people as a focal point and apply some consideration to them in our project management. A simple process might look like this:

1) Identify problem people

I suggest spending some time to think through the project organisation and identify people who may cause a problem. Make sure to consider the full time project team members as well as the extended team composing of stakeholders, operations representatives and third parties etc.

As you think through this categorise people into the type of problems they have or might cause. The list from “people problems – diving deeper” above could be a starting point.

In stakeholder analysis there are many approaches to consider stakeholders and categorise them as either “for” or “against” the program, these methods can be applied to the wider team.

2) Understand their perspective

The next step is to put yourself in their shoes. Often you may find that their ‘problem attitude’ is warranted. Putting yourself in other people’s shoes is one of the most useful business skills, this will help you tailor your presentations and discussions to gain buy-in and resolve conflict in many situations.

Questions to consider include:

  • What’s their reputation in the organisation?;
  • Are they difficult in general, but they deliver, or do they fail to deliver?;
  • Are they a peer, how do they feel about being ‘on your project’;
  • Career – are they happy in their role, are they trying to move out of it;
  • Are there any non-work items that might impact their contribution to the project (take care with respect to human resource sensitivities).

Plan an intervention

After you’ve identified people that need attention and understood what is motivating them you can start to think about how to intervent.

In the personal example I gave above I had peers who were uncomfortable working under my project leadership, my approach was to:

  • Subtly message that I don’t see it as a leader/subordinate relationship, I see them as an equal and I need/value their input;
  • Giving them space to do their own work (where I trusted their capability);
  • Showing my value by helping them resolve any problems they were having, or making minor adjustments to the plan to help them out.

There are different views on the role of project managers. I’m sometimes surprised by some project managers who seem to think they are the most important person and should be served by their team. I personally believe project managers are there to help the team succeed.

Another example. As a management consultant I was often hired by senior stakeholders, but working with people more junior staff. Many people have a bad impression of consultants or feel that consultants are there to steal their job. I’ve been in this position many times. On one project with a multinational financial services organisation, we were designing a new pan-European business unit and accompany technical architecture. We had one highly skilled technical architect from the client’s UK firm. His initial approach to joining the project was to disagree with and complain about everything. To leverage his skills and remove the conflict I asked him to take a lead role in facilitating the architecture for Europe. This allowed the project to get the benefit of his expertise while still providing our ideas and also allowed him to signal to his management that he was making a valued contribution.

In general I’ve found that with problem people the following actions can work:

  • Get them on-board with the conceptual objective of the project;
  • Build mutual respect;
  • Give them space;
  • Bring them more on-board, give them bigger responsibilities;
  • Help them with their challenges/issues in their own tasks;
  • In the worst-case scenario de-scope or limit the impact of the project on their areas, to make success possible even without their cooperation.

Monitor and adjust

As you work through the project continue to monitor resources that are coming on or going out of the project as well as your existing team members.

Focus on strategy alignment

Project managers may not be involved in strategy development. This means they may never see a study or business case that led to the project they are being asked to manage. This can lead to project managers having only a rudimentary understanding of the objective.

This doesn’t empower the project manager to make nuanced decisions on where to focus effort, what risks to accept and other similar topics.

Example – project managing an ERP and CRM system upgrade during a period of high organic growth

A business is upgrading their ERP and CRM systems. The existing systems are:

  • Technically slow;
  • Have a number of problems with effort-intensive workarounds in place;
  • Do not feature modern capabilities.

This is a must-do project to provide stability for operations and reduce effort spent on manual workarounds.

In parallel the company is experiencing strong organic growth. They are currently hiring in the sales and customer service areas, creating new teams and opening new sales offices. Management are also considering small acquisitions.

The program managers for the ERP and CRM systems may have written objectives summarised to:

  • Replace the existing system without out any negative impact to the business;
  • Resolve workarounds caused by existing systems;
  • Deliver new features to help modernise sales and customer service processes.

If the program manager only considers their own work and has limited interaction with the executive team, they may take a very rigurous and comprehensive approach. They may plan to push the organisation to do everything in it’s power to maximise the benefit of the new ERP and CRM system.

But is this the right approach?

While this is excellent in terms of getting the highest value out of the new systems, this approach could require significant effort requirements from operations and be significantly disruptive.

The result of this could be an impact on how well operations are maximising the value from the growth period they are in. The project may distract them from driving sales, on-boarding new hires and setting up the new teams.

The value gained from the ERP and CRM initiative may never pay for the potential value lost in focussing on business as usual in a growth phase.

Further, in this scenario where we have multiple things happening at once – there is a risk of over-loading people, which can lead to key employees burning out or leaving.

Note that it’s typically a major problem in strategy projects that executive committees will take on too many change initiatives. Therefore I believe it’s critical for project managers to know where their project sit’s on the list of priorities so they can resolve conflicts with other initiatives in the best interest of the complete organisation.

If the program manager for ERP and CRM has a good relationship with the executive and a good understanding of the strategic priorities they can steer their program to best help the organisation. Things to consider:

  • What’s the priority between the different elements of driving growth, vs the various projects underway;
  • What’s nice to have vs. must have;
  • For the resolution of workarounds – what is the value of solving each problem?
  • For the enhancements – what is the value of each enhancement?

With a good understanding of all of the work underway in an organisation and how it connects to strategy, a project manager can minutely adjust their scoping, phasing and solution to better support the overall priorities of the business.

This could be as simple as not fully training teams on enhancements during a busy period and activating them later on a schedule over a number of months.

Example – building an offshore shared service centre

Consider a company is setting out to open an offshore shared service centre. A high level business case was created. It defined an offshore location. It also defined a rough order and timeline for the transition of different teams. The program managers start the work based on this plan.

The program manager creates a detailed plan to execute. Whilst moving into the detail a number of issues can arise which make certain parts of the original plan difficult to execute. The project manager can move ahead with brute force and try to execute in line with the business case.

However, if the project manager makes the effort to understand the principles behind the business case and the perspective of the executive committee they may find factors that open up more options, such as:

  • In years 1 – 3 cash flow or cost is not a concern for the organisation, but they envisage a downturn on year 4 and onwards;
  • Quality is critical for the organisation, any loss in service levels is unacceptable;
  • The shared services have to be scalable to support long term growth;
  • Because the business is currently doing well, they should avoid any major disruption in the current period.

With this perspective it starts to become clear that the order of transition of teams is not as important in year 1 and 2. The quality of the platform and the stability of the transitions is important for the long term. With this strategic background the project manager can better plan alternate transition scenarios to avoid issues and present options to the stakeholders.

Common mistakes in project management

To make this article useful I’d like to cover a few of the most common mistakes I’ve seen in recent years and some tips. In keeping with the theme, these are mostly connected to what project managers focus on and how they deal with people.

Death by project admin

A good PMO should be somewhat invisible. All project quality measures should improve with a reduction in management effort. One of the most common mistakes I see being made in project management is using what I call a ‘heavy’ PMO. By this I mean:

  • Using complex and long-winded formats of project templates and tools;
  • Taking a highly theoretical approach and following e.g. PMI by the book;
  • Long meetings with a large number of attendees;
  • Focussing more on the project management method that the project work;
  • Complex review and approval;
  • Overstaffing – there are studies that show as teams get bigger they can do less.

I’ve seen teams where for every 1 person doing an actual project task there are 5 people doing ‘project methodology’ work – writing updates, hosting meetings etc.

I believe that certain aspect of agile and scrum are useful in minimising project admin and re-focussing on project tasks.

Using project tools as communication tools

Long-winded project initiation documents, GANTT charts and detailed issue logs are not communication tools. They shouldn’t be shared widely. They are planning tools for project managers and PMO.

For communication use simple, clear and targetted messages. If you want to present a project plan to stakeholders you can share a summary of the critical path elements. To illustrate effort and complexity you can reports statistics on the total no. of tasks planned, in progress, completed etc. they don’t need to see the actual list.

Using project management tools as communication formats can create an environment of ‘complexity’ and ‘stress’ by pushing too much content to people.

Inserting PMO between leadership and teams

In the past I set up a PMO to help the leadership of an organisation manage 7 different programs.

One of the mistakes the PMO lead made was with the handling of the weekly review with leadership. The approach they took was to gather the status information from 7 programs and then present that to the leadership. This was a disaster for several reasons:

  • The PMO trying to understand and repeat details of 7 programs each week is wasted effort (remembering the are not domain experts this is very hard);
  • The PMO couldn’t answer questions, or commit to actions from the leadership;
  • The individual programs do not get direct access to ask the leadership questions or to get direct instructions/context from the leadership.

In this case, the PMO should have been the chair of the process and the meeting. The should ensure each program brings an appropriate update and presents it and they should make sure questions and follow up actions are managed.

I recommend trying to create a flat project structure where even the most junior resources can access messages from senior stakeholdres. Of course this has to be expertly facilitated.

Under-communication

Project teams often communicate either incorrectly or not enough.

It’s important to keep everyone involved or impacted by a project appropriately briefed. A few suggestions:

  • For stakeholders or extended stakeholders an initial briefing consisting of 1-2 slides clarifying the objective, the key dates and the impact to them;
  • For the full team a weekly summary of tasks due that week;
  • For intensive projects or phases within a project a daily standing scrum can be an effective way to keep communication flowing in an efficient amount of time.

Frequent meetings can be important for certain projects, but they shouldn’t take a lot of time.

I recommend avoiding situations where large groups of people are sitting working through Gantt charts or excel lists together, this can be time-consuming and de-energizing etc. Try to limit attendance to meetings to those that need to be there.

Document and confirm all actions and agreements

At some point in your career as a project manager, things are going to go wrong. If you are unlucky it will be something serious. Not everyone plays nicely in business and you should be ready to prove your approach was diligent and your actions correct.

  • Document all actions and agreements (concisely);
  • If verbal agreements occur follow up with a brief e-mail to confirm;
  • Carefully archive all key agenda, minutes, e-mails etc. so you can access when needed;
  • Think like an auditor. Make sure to ask your stakeholders or peers or whoever is best for feedback on plans, risk lists etc. make sure people had an opportunity to input. This removes the opportunity to blame.

I don’t advise playing in ‘politics’ but I do advise protecting yourself from ‘politics’.

Too many resources

When projects run into trouble extra resources are often onboarded. It’s important to remember that there is an optimum effective team size. It’s also important to recognise that resources w/out the correct expertise and experience may slow projects down. Project progress is normally limited to a certain number of people that are “bottlenecks”. Make sure to identify those areas early. They are normally either in the most complex technical part of a new product or the busiest function/team.

Change management – avoiding one danger of using change managers

As a final topic I’d like to address change management.

Change management is often connected to strategy, people and communications. I believe that one of the reasons change management has become popular is due to the gap in skills displayed by project managers.

Change managers can be excellent and can have a very important role in a project, but when mis-used they can cause a lot of problems for a project.

The situation I would urge organisations to avoid is adding an extra level of change management between project managers and stakeholders this can result in a lot of extra effort for project teams and also a reduction in the amount of information they receive from stakeholders.

On more than one occassion I’ve seen the following happen:

  • A change manager joins a project team and immediately requires a lot of time from the project manager and other team members to educate them;
  • The change managers work directly with senior stakeholders, sponsors, and business leads and add an extra layer between those people and the project team reducing communication and clarity in a critical area;
  • Sometimes the approach taken by change management can help make people feel good but have no solid benefit in terms of what the project delivers.

Change managers should not replace what the project manager should be doing. It’s critical that project managers lead stakeholder involvement and communication, change managers can assist and consult, but should not be another level in the organisation chart hierarchy.

Learning resources to improve people management skills for project managers

Prosci ADKAR

I’d recommend applying tools like ADKAR to your project

ADKAR is often used with management teams, stakeholders or customers to check if they understand and can contribute positively to change. The diagram shows the ideal timing to apply ADKAR steps, but you can start with them at any time.

I highly recommend using Awareness and Desire. You can use these to run interviews, surveys, brainstorming sessions with your team. I recommend using them with all team members, not just management.

In awareness, you can investigate how much your team really understands what you are trying to do. This can be excellent in helping refine the focus of your team members to what is really important.

With desire, you can easily help team members find out what is in it for them. You can also find out why they might not be behind the project.

Others

I’d recommend picking up some books on leading change, influence, persuasion. There are lots of great titles amongst the lists of top business books.

I’d also recommend that where possible try to identify a role model. Someone who can lead work effectively with people. This doesn’t need to be an active coaching relationship. A lot can be learned just from considered observation.

Final thoughts

What do you focus on when you working as a project manager? What do you see as missing skills or issues that come up repeatedly on projects?

Categories
Newsletter

ITW – Interesting things this week # 1

by alexander roan

Welcome to the inaugural version of ITW – ‘Interesting Things this Week’ ??

In this newsletter I’ll be sharing some content from across the web that I found interesting. It’ll be loosely connected to business strategy and operations transformation, and I’ll try to avoid duplication with mainstream media.

This weeks post is around 900 words and a 3.5 minute read.

1) Opening an account

(by builtformars)

In this post ‘builtformars’ analyses the different experiences while opening a bank acccount across challenger and traditional banks. While the blog is focussed on UX, it’s also an interesting study on process. Whilst reading this I was thinking that a similar analysis could be carried out across various processes to easily compare customer experience across competitors. It’s a fairly cheap and low effort way to gain some insights, and isn’t often done so pro-actively.

2) Public attitudes on the fair use of data and algorithms in finance

(by the behavioural insights team and centre for data ethics and innovation)

Neural networks are the most common form of machine learning applied to decision making. These networks can; given an input, categorise it which is a kind of decision making. They do this based on ‘training data’. The classic examples relate to images. If you train a neural network with 1,000,000 images of cats from the internet the networks gain a degress of accuracy in being able to identify when a cat is present in an image on the internet. The accuracy is based on the range of cat images provided during the training stage.

Because of this training bias is big issue. Consider a neural network that reviews loan applications, it might be trained on previous loan applications and whether they were approved or rejected. Any bias in this training data will be designed into the neural network.

The report linked looks at the perceptions of the fairness of proxy information used in algorithms. If for example a neural network finds a pattern of certain postcodes having a high rejection rate, this may represent; just for illustration, an area where ethnic minorities live, in this case the postcode may be acting as a proxy for ethnicity.

The CDEI and BIT study looks at public perction on the use of algorithms. Unsurprisingly one of the conclusion is that the there is a negative perception of algorithms in loan-making.

Even though this technology is not well understood by the general public it’s promising to see that the public are cautious here. I expect that we wil see more focus on fairness and bias as these technologies find more and more commercial applications.

3) Morality in business

An example of good morals and an example of questionable morals

On Monday I read about Javier Rodriquez, CEO of DaVita; a chain of kidney treatment centres. His company automatically qualified for and received nearly $250 million from the US health care enhancement act (part of the pandemic relief package). The company and it’s directors decided to return the money as they felt they didn’t weren’t in need of it.

On the other hand, last night I read about Take-Two Interactive; the parent company of Rockstar, producer of the massively successful games Grand Theft Auto and Red Dead Redemption. Apparantly they cancelled a contract with a smaller developer; Star Theory Games, and then proceeded to poach over a 1/3 of the staff. It seems they started poaching even before the contract cancellation was finalised or communicated.

What’s the right line between profits and morality? A lot of companies incude a section on corporate social responsibility in their annual reports, but this tends to address topics like diversity, the environmen etc. I don’t see much on morality and ethics within commercials or supply chain.

4) Another failed use-case for blockchain

Recently I wrote a short article on how blockchain works. Once you understand how it works and how it compares to other technologies it becomes much easier to identify the use-cases that hold genuine value. On Tuesday I heard that Civil a blockchain journalim start up has closed down. I think this is a clear example of being excited about a technology and just looking for applications w/out really thinking about how appropriate it is and what the value proprosition is.

5) The Endangered Asian Century

I came across an interesting article from Lee Hsien Loong; no other than the prime minister of Singapore, addressing APAC and the sometimes difficult position the countries are palced in between America and China.

I remember since my University days; way back in 1996 – 2000, there was always talk of asia pacific becoming the economic super power of the world, with the west in decline. It’s interesting to see a slightly different perspective.


What I’ve been up to this week?

If you are interested in ERP or SAP I wrote about their HANA and S/4HANA products.

And finally, something fun…

When I’m working, or exercising or even taking a nap I sometimes like to play some music in the background. Recently I’ve been into lofi music. It’s super relaxing and it’s not at all intrusive so you can enjoy it while doing other things. You can look up some excellent artists like Jinfang, Tomppabeats or Nujabes or you can tune into one of the many streaming channels on youtube and let them do all the hard work of curating a playlist, I particularly like a channel called “ChilledCow”


I’ll also be sending this newsletter via e-mail in future, if you would like to receive it in you inbox please subscribe:

#mc_embed_signup{background:#fff; clear:left; font:14px Helvetica,Arial,sans-serif; width:100%;} /* Add your own Mailchimp form style overrides in your site stylesheet or in this style block. We recommend moving this block and the preceding CSS link to the HEAD of your HTML file. */
Subscribe

Categories
Articles Technology

SAP HANA and S/4HANA

Recent years have seen a resurgence in large organisations taking on major SAP upgrades with the relatively new SAP business suite 4 HANA (S/4HANA) collection of applications. But what exactly is HANA? and what is S/4HANA? How is implementing or upgrading to it different from the R/3 upgrades that were significant programs for many organizations over the last few decades?

As SAPs core products have advanced and their portfolio has broadened it’s become difficult to understand how it all fits together. In recent years I’ve met team members and stakeholders working on SAP programs who struggled to articulate the basics of HANA. SAP projects can be complex and challenging partly due to this lack of knowledge. SAP have been addressing this by improving their communications and training, but understanding HANA can still be quite a lot to navigate.

In this article, I’ll briefly explain the history of SAP and hence the context that led to HANA as well as clarifying the technical concepts behind HANA, why they are important, and how the business application has changed.


A brief history of SAP and ERP

SAP has a large portfolio of applications. If we stick to the main enterprise resource planning products we can abbreviate the history of the company to six key versions, roughly a major iteration each decade.


R/1

Let’s start from the beginning.

SAP was founded by a number of ex-IBM employees in the early 1970s. Their first system was called RF (real-time financials) and was later re-named R/1. SAPs product strategy was based on three main concepts:

  • Provide a standardised ‘of the shelf solution’ – in the days when many companies were building their own applications from scratch SAPs plan was to build a software product that worked for many companies only with minor configuration;
  • Real-time – information entered into the application is available across the entire application in real-time;
  • Integrated – the same data is shared across multiple functional parts of the system reducing the need for redundant data entry.

What exactly does ‘real time integrated’ mean?

Consider an example from manufacturing. Raw materials are converted to finished products and sold and shipped to a customer. This process involves many departments; procurement, warehousing, manufacturing, finance, sales etc. If we consider only a part of this; the receiving of raw materials from a supplier, two activities need to occur.

Prior to ERP, these activities may have been done separately, for example, warehouse management may have updated their inventory list at the end of the day and then sent a copy of the information for finance to update the accounts. Throughout the day inventory and financial information would not have been up to date or aligned. And the effort has been wasted entering the same data twice.

With ERP,  When warehousing update inventory, the accounting records are updated automatically in real-time. Under the hood, ERP has a lot of connections across different tables that keep information in sync for different functions and teams.

Once we understand this we understand the value of ERP systems and why they became so popular. We can start to imagine how complex they are as they connect processes and data across the entire enterprise. Take the simple example above and imagine how the same logic could be applied across sales, marketing, production etc.


R/2

Moving onto 1979 R/2 was released.

The switch from R/1 to R/2 was a more subtle evolution from a technical perspective with increases in the core functionality as SAP started to increase their customer base.

I can’t write too much about R/1 and R/2. When I started my career in an IT team in 2000 R/2 was on the way out. I was trained in using AS/400 mainframe and R/2 but I had only a short time to use it. In fact, most of my experience of R/2 is extracting data from it to cleanse before loading to R/3!


R/3

Moving onto the 90s and R/3.

The switch from R/2 to R/3 was significant with a number of major changes:

  • R/1 and R/2 are classed as mainframe systems and R/3 as a client/server system. Skipping the technicalities this allowed for:
    • A fuller ‘graphical user interface’ on desktops (i.e. windows desktops or laptops);
    • Cheaper, easier to scale, and more flexible set up the server-side (note: some complex debate exists on some of these).
  • The shift from R/2 to R/3 and the ongoing development of R/3 through the 90s also represented significant expansion in the business processes covered.

R/2 and R/3 are very different systems. To switch from one system to another you need to extract and transform data before loading to R/3, you also have to map all processes. In my experience switching from R/2 to R/3 was similar to switching from a non-SAP system to R/3. In the 2000s I managed several upgrades from R/2 to R/3 as well as upgrades from mainframe systems like BAAN and the approach and work involved was similar.

When talking about R/3 it’s also important to consider scale and globalisation. Mainframe systems were typically implemented for a single country or business unit. The cheaper more scalable architecture of R/3 provided an opportunity to implement one R/3 system covering an organisations business across an entire region or the world. This is important as it’s one of the factors which lead to bigger data volumes and more performance challenges.

R/3 was evolving year by year as a complex, integrated system that was being used in large organisations on a global scale. This set’s the scene for what is to come with HANA.

A note on the R/2 vs. R/3 look and feel

For a simple illustration of how different R/2 and R/3 are we can look at a couple of screens.

An R/2 terminal screen
An R/3 graphical user interface screen
  • R/2 has a very simple interface where function keys and codes are used to navigate between fields;
  • R/3 includes menus, tabs, buttons, ‘help lookups’ etc.

We will see that there is also a significant jump in how SAP looks and feels between R/3 and S/4HANA.

A note on R/3 process scope

This is a diagram that anyone that worked on R/3 will fondly remember, it outlines the different modules or ‘functional areas’ covered by R/3.

While ERP and R/3 may seem complex; and it is, all it does is record business activities by entering transactions in a system and having the information about what happened stored in a database. It then lets you view and adjust the information to manage your enterprise. Here are some simple examples for a few of the modules shown above:

  • FI – finance
    • Record periodic accruals.
  • CO – controlling
    • Record / view expenditure against a department
  • SD – sales and distribution.
    • Record a sales order for a sale to a client
  • PP – production planning.
    • Plan a production schedule
  • HR – human resources
    • Pay employees.

2000 – 2015: mySAP.com / ERP

When we come to 2000 the branding becomes a little confusing.

There were a number of key focus areas and we saw R/3 being referred to as mySAP.com and also ERP (technically ECC). Noteworthy focusses were:

  • The emergence of web technologies and the need for ERP to be able to connect on a B2B or B2C basis via the internet, mySAP.com was used as a brand and various integration technologies were available.
  • An increasing number of ‘add on’ products for data analysis;
  • Acquisition of and integration of niche competitor software into the SAP landscape.

A note on data analysis

R/2 and R/3 are technically optimised as systems to record data. They are not optimised to analyse data. The late 90s saw the release of the first business warehouse system (BW). This system is technically architected to analyse data. Organisations would use ERP to record data and carry out simple real-time reporting and then send data in daily batches to BW for more complex analysis. I’ll come back to this with an illustration later.

Acquiring competitors

During this period there was a boom in niche software providers, particularly in areas such as data analytics. SAP took the opportunity to acquire some leading competitors to cover areas where their applications were weaker, for example, this covered:

  • Analytics, planning & reporting – e.g. Outlooksoft, Business Objects
  • User experience & process execution in niche process areas – e.g. Successfactors, Concur, Ariba.

What’s interesting to note is that with the addition of business warehouse the SAP solution was no longer a real-time integrated architecture.

Furthermore, the architecture for many companies was becoming somewhat convoluted with many different applications from different providers. This in fact leads to a lot more solutions in areas like interfacing and master data management.


Business suite

During the 2000s the number of processes covered by the R/3 or ERP was continuously increased, in addition to that a number of additional applications were launched to provide more advanced capabilities in certain areas. SAP started to package a number of these together in the late 90s under the name, “business suite”. The main components of business suite are:

  • ERP (enterprise resource planning):
    • Basically the evolution of R/3 – the core of business suite including financials, human capital management, operations, corporate services etc.
  • CRM (customer relationship management):
    • Sales, marketing, and service.
  • SCM (supply chain management):
    • Procurement networks, production networks, distribution networks, planning, organisation and execution of supply processes.
  • PLM (product lifecycle management):
    • Product ideation to production.
  • SRM (supplier relationship management):
    • Procurement for materials, goods and services. Requirements determination to ordering to payment.

A note on OLAP vs. OLTP

As mentioned a major issue that existed with R/3 was the inability to handle reporting for increasing data volumes, especially with the growing demand for quick analysis. R/3 as a system is not designed to read data quickly. This led to the development of stand-alone systems such as SAPs business warehouse that were optimised to read data. The following terms were used to describe these two different types of systems:

  • OLTP – online transaction processing (e.g. R/3)
  • OLAP – online analytical processing (e.g. BW)

As a result of this large organisations often ended up with systems landscapes that include multiple OLTP systems and multiple OLAP systems all connected together.

And this is before we even consider topics such as web applications, big data etc.!

Increasing complexity

Prior to the launch of HANA it’s useful to reflect on where the SAP portfolio was:

  • The core of ERP had been developed over decades with a continuing increase in the volume and complexity of processes covered;
  • Multiple industry-specific solutions were also available;
  • Requirements for many geographies were covered;
  • There was a split between applications for recording transactions (OLTP) and carrying out simple reporting and applications for information analysis (OLAP). Real-time integration was not present across the entire range of applications;
  • The product portfolio became huge, in part due to multiple new products being developed by SAP and in part by a large number of acquisitions;
  • Major advancements in the standards and approach to integration and web technologies over the years.

Altogether the complexity of business systems landscapes has been massively increasing since the mainframe days. I think this is a topic which is not addressed as much as it should within architecture plans, while we should embrace new technologies we should also rationalise old technologies.

This brings us to the 2010s where part of the focus from SAP is on reducing the complexity of the core product, while also continuing to advance in new technologies. HANA plays a significant role in reducing complexity and bringing real-time back to include analytics capabilities.


S/4 HANA

This brings us to the question of what is S/4HANA?, it’s short for “SAP business suite 4 SAP HANA” and it’s a collection of different things. This is one of the reasons why HANA is not well understood. It can’t be correctly called either a technical upgrade or a functional enhancement, it’s a combination of the two. Furthermore, as part of a S/4HANA conversion, there are a lot of optional items. Each company needs to define its own scope for a S/4HANA conversion based on their own objectives.

In this article I’ll cover three main building blocks of S/4HANA. These are:

  • The HANA platform (or HANA database) – a new database that solves the problems faced by ERP;
  • S/4HANA (i.e. the HANA business suite) – an updated version of business suite 7 taking advantage of the benefits of the HANA platform;
  • Fiori – a new approach to UI with more focus on flexible app style development and mobile.

In this post, I’ll spend most of the remaining time explaining the HANA platform and how it impacts business suite, which I think is not commonly understood. For the business suite and Fiori I’ll give a very brief overview as these topics are quite deep and SAP has plenty of information available. Plus when looking at these topics it needs to be done piece by piece e.g. by function or UX case.


The HANA Platform

Understanding memory

To understand HANA we need a little consideration to how memory works in a computer. Bear with me, it’s not that technical!

As with many applications, ERP was designed based on what could be done at the time with the technology availabe. The main constraints were the cost of processing power and storage. The hardware limitations led to limitations in the logic of the software which led to a number of the problems that we have already discussed above.

However; considering Moore’s law, the increase in processing power and storage and reduction in hardware costs gave SAP the opportunity to re-think the architecture of ERP. This brings us to HANA.

HANA is the term used to refer to a new database whose development was led by one of the founders of SAP. HANA stands for:

  • Hasso’s New Architecture ;
    • (Hasso Plattner is one of the five founders of SAP);
  • or alternatively, “High-Performance Analytical Application”.

You can learn about HANA from Hasso himself on the open learning platform from the Hasso Plattner Institute for software systems engineering (note this is very technical, only for people who love databases I guess!):

https://open.hpi.de/courses?lang=en.

There are three key features that allow the HANA platform to solve the problems ERP and BI were facing, these are:

  1. In-memory computing;
  2. Columnar database managemnet & data compression;
  3. Parallel processing.

We will take a look at the first two topics to understand better what HANA is. The third; parallel processing, is a fairly common concept where modern computers can use multiple processors simultaneously on an operation.

How memory works

To start the explanation of how HANA uses memory, let’s consider the example of a regular desktop computer. Memory can be categorised into 3 types:

  • Auxiliary memory: the largest and cheapest memory. Either magnetic disk or solid state drive. Data is retained when the power is off. To write or read data is extremely slow;
  • Main memory: mostly made up of RAM, more expensive, but much faster than auxiliary memory. Data is lost when power is off.
  • Cache memory: A small amount of very fast memory close to the CPU that stores data the CPU is currently using.

The biggest factor in determining the speed a computer can process is how quickly it can read and write to memory. If the processor needs to access auxiliary memory then the process will be very slow.

R/3 doesn’t run on a desktop, it runs on a server. But don’t be concerned about IT terminology a server is the just a computer in the same way a desktop is a computer.

So we can consider R/3 ERP as a big computer, with massive data volumes, one of the main reasons it can’t be used for advanced data analysis is the time it takes to retrieve data from auxiliary memory.

In memory computing with HANA

As technology becomes more advanced and component prices go down, main memory is now available at a cost where it can be used for the volume of storage that was previously was only possible to store in auxiliary memory.

To directly quote SAP, “SAP HANA runs on multi-core CPUs with fast communication between processor cores, and containing terabytes of main memory. With SAP HANA, all data is available in main memory, which avoids the performance penalty of disk I/O (i.e. read / write to auxiliary memory).

In plain English the complete dataset within ERP is stored in what we think of as ‘RAM’ on our desktops or laptops and is easily accessible by the processor.

With HANA we don’t need auxillary memory for day to day operations as shown below. However note that it is used for back up / disaster recovery, for example in the case of power being lost.

Columnar data store with HANA

In addition to in-memory, HANA applies database management methods that are much more efficient at compressing data. And the more compressed data can be the faster the system can run. 

Consider the table below. Traditionally an OLTP type database will hold data in a row store. If you compare the row store with an alternative method; the column store, you will quickly realise that for the column store a lot of values may be duplicated side by side. Intuitively we can see a columnar store may be much easier to compress.

Compression is a fairly broad and technical topic, but simply imagine a column for ‘city’ in a table of addresses, we will have hundreds if not thousands of entries of e.g. ‘London’, if that’s the case we don’t need to store London every time, we can instead store the range of rows that have London as a city, this means if there is a query about London, the application does not need to work through every row to get the results.

More information:

https://help.sap.com/viewer/52715f71adba4aaeb480d946c742d1f6/1.0.12/en-US/421691c7c0514928b3f15030600ef964.html

Taking into account ‘in-memory’ design with ‘columnar’ store, the HANA platform provides a database that can operate hugely faster than the database options used in R/3 or business suite 7 or any traditional OLTP system. This is quite a big deal:

  • We no longer need to separate OLTP and OLAP applications to different databases/applications. A single HANA database and application can do both types of operations effectively. This is an opportunity to massively simplify the hardware, technical architecture and data architecture.
  • We can simplify the business suite applications. One example of this: Because OLTP systems were generally slow at reading and analysing data there are often many subtotals and totals tables that are updated when transactions are processed. These tables along with a lot of complexity can be simplified or removed.

SAP Business suite 4 HANA – simplification items

Recall we said there are three main components of S/4HANA

Now that we covered the HANA platform we can look at business suite. The business suite present in S/4HANA is essentially an updated version of business suite 7.

We could say that the conversion from say R/3 to S/4HANA is a technical upgrade from a database perspective. But from an application perspective, there are further changes and enhancements many of which are enabled by the database conversion.

A big part of a S/4HANA implementation is understanding which simplifications and enhancements are available and which you would like to implement. Not all simplifications are mandatory. And each simplification or enhancement has its own unique impact on the process, data etc. 

SAP provides a simplification list for each HANA release. The current S/4HANA version is 1909 and the list is here:

https://help.sap.com/doc/0080a18cdc1045638d31c87b839011e7/1909.000/en-US/SIMPL_OP1909.pdf

I won’t go through these in detail, it’s a huge list. One key note worth mentioning is that the majority of simplifications are within the finance and logistics areas. Some examples from finance:

  • The universal journal (major simplification to the tables/ledgers and hence reporting in the finance area);
  • Changes to transaction codes (removal of old / introduction of new);
  • NewGL (an updated version of GL which was available prior to S/4HANA is implemented as part of S/4HANA);
  • New Asset Accounting;
  • etc.

For finance the simplification journey started back with ERP (ECC 6.0), at this time NewGL was launched which provided a significant simplification to the way financials and controlling worked:

  • Simplifying the no. of internal ledgers (e.g. removal of FICO reconciliation);
  • Adding leading / non-leading ledger functionality for multiple valuation requirements;
  • Extending the GL code-block e.g. for IFRS segmentation requirements.

NewGL provided a starting point for further simplifications enabled by HANA.

Fiori

Fiori is SAPs new approach to user interface design.

One of the main objectives of Fiori is to allow developers to quickly create ‘apps’ as an interface for specific activities or tasks within SAP.

These apps can feature improved visual design, role-specific actions and be adaptable between desktop, tablet and mobile etc.

Fiori starts from the launchpad where different apps can be placed as tiles along with global elements such as user personalisation options, search and notification.

Image source: https://experience.sap.com/fiori-design-web/launchpad/

This provides a significant step forward in the ability to customise the interface to specific roles and improve the user experience. It’s easy to see how having key figures and activities available at a glance could have a number of benefits.

Fiori comes with a number of SAP provided apps and organisations can also develop their own apps.

For a S/4HANA conversion how much effort should be placed on Fiori? How many apps will be deployed? How much time will be spent on optimising launchpads for specific roles?

Implementation considerations

As with any ERP implementation or upgrade, a conversion to S/4HANA will be a complex project. SAP provide free training available on open sap:

https://open.sap.com/

In addition to training there is a recommended roadmap. Between these it’s possible to plan out all required activities.

I’d like to highlight three areas of focus:

1. Business case development

As we’ve seen an S/4 conversion is like a hybrid between a technical upgrade and an introduction of new business features. With this in mind, what is the business case behind the investment? It could range between:

  • It’s a ‘must-do’ program to ensure we stay on the latest version, but we want to minimise cost and effort;
  • It’s an opportunity to simplify our IT architecture, access as many of the business suite enhancements as possible and implement Fiori for all our users with our own apps. We want to invest a lot of time and effort and improve the way we work.

When considering the benefits, it’s critical to ensure that experts who understand the state of the current systems and current ways of working are involved.

In my experience the pre-sales and business case activities are often limited to senior management and architects, this can lead to an overestimation of the benefits that the users of the system will receive.

I’d recommend validating the business case with functional and technical experts. This may lead to an adjustment of the plan for improved scope, more refined focus and a more realistic project plan.

2. Preparation is critical

The recommendations and learnings which I’ve applied to R/3 and ERP upgrades also apply to S/4HANA. The biggest of these is related to preparation. Serious work should start 3-6 months prior to the start of the project proper. The work that should start early includes topics such as:

  • Master data cleansing
  • Transaction data cleansing (i.e. aging analysis)
  • Ensuring that existing processes are understood and documented
  • Ensuring that existing configuration is understood and documented
  • Ensuring issues and problems are understood and documented
  • Ensuring custom developments are understood and documented
  • Ensuring the right resources are available for the project
  • Ensuring the biggest pain points within the current process / system steps are understood and have been included in the scope consideration as part of the business case.

The majority of SAP projects run into problems in the requirements, fit-gap and testing stages because the current system and process was not well understood or considered or there were hidden issues. It’s critical to surface these early.

3. Involve the right people early

Typically a large organisation may run a global SAP upgrade/implementation something like the below:

  1. A small team develops a business case with senior management involvement;
  2. A first project runs the upgrade for one business unit/country/region as a pilot and as part of this defines a global standard approach to the upgrade, the project is highly biased to one business unit/geography;
  3. The upgrade is then executed across different geographies/business units, they struggle with the design decisions made by the first unit;
  4. Within each individual project, the first stages start with the involvement of a small number of people and as they progress an ever-increasing number of people up to user acceptance and training activities with the full teams.

With this approach the best experts and ‘real knowledge’ may not see the planned solution until user acceptance testing occurs. By this time it’s too late to change anything without major project delays. I’ve always disliked how user acceptance testing is included in traditional IT projects, it’s never a chance to accept a system works acceptably for a business, it’s often more an argument on whether the system works according to what was agreed and written down in previous project stages.

When you plan your project, look at the team staffing, from the very first phases:

  • How many of the team members have worked in your business operations?
  • How many of your team members are middle managers?
  • How many of your team members are external contractors or consultants that don’t know the details of your operations?

Free up your at least one operational experts from each in scope function and ensure they are involved from the start. Make sure the profile of this person is someone that will continuously socialise and gain feedback and input from their peers.

Final thoughts

There are still a lot of topics to be considered such as the details of the simplification list for each function and the impact on ‘add on’ systems e.g. analytics. However hopefully understanding what HANA and S/4HANA are from an evolutionary and technical perspective makes it easier to figure out how it all fits together.

What aspects of understanding and planning SAP related work do you find most challenging?

Categories
Articles Technology

A No-Nonsense Guide to Digital and Technology Strategy in 2020

‘Digital’ – A Magnet for Nonsense!

‘Digital’ was and still is a popular term in the business world. In recent years a lot of papers, presentations and communities of interest have appeared on this topic. Unfortunately, the majority of them seem to create a lot of content, but little meaning. Put simply, a laymen could read a typical brochure on ‘AI’ or ‘Blockchain’ and still have no clue what the physical product or service is and how it differs from more traditional techology.

Back in 2000, I first started my career in information technology, not long after joining we were re-branded as ‘information & decision solutions’. I think the majority of people in information technology will be familiar with the constant re-branding of teams and functions.

This is the case with ‘digital’

Digital technology is a hodge podge of technologies which are new / popular / highly saleable. I tried to figure out what the common theme is with technologies that get accepted into the ‘digital’ podium, but there doesn’t appear to be one.

In this post, I’d like to have a plain english, no-nonsense discussion of digital (or more simply new & popular) technologies.

I’ll start by taking a look at what major companies are saying about digital, then I’ll look at structuring it into a simple taxonomy to promote a clearer understanding. I’ll then take a look at key areas of digital one by one. Finally I’d like to talk about the approach taken to develop a digital strategy.

Before getting into the detail I would like to give some advice to anyone thinking about investing in digital products or services:

  • Take a ‘doubtful’ stance, don’t get caught up in the hype;
  • If someone can’t explain a technology; how it works and why it’s useful, in a few sentances to a laymen, do not listen to them;
  • Be careful of conflicts of interests when dealing with suppliers and partners, I’ll talk a little more about this next.

The ‘Digital’ Cash Cow

There is no doubt that ‘digital’ was and is a cash cow for consultancies, systems integrators and other tech orientated firms.

It’s a perfect sales opportunity for these businesses:

  • It covers a broad range of products and services;
  • There is a level of mystic involved;
  • It’s fast moving, and hard to stay abreast off;
  • In some domains a high degree of technical competency is required;
  • There are stories of massive wealth / success (e.g. Bitcoin).

This creates a situation where companies want to invest in it, but they are not always well placed with knowledge and skills to plan or execute.

There is a positive role for consultancies, systems integrators, research companies and even independent contractors in helping define and implement digital strategy, but extra care needs to be taken:

  • Make sure you are not being sold nonsense!
    • Looks for clear and easy to understand descriptions;
    • Look for live examples that are delivering benefits;
  • Don’t use expensive partners for very simple technologies – Robotic Process Automation is a good example of this;
  • Don’t invest in overly complex solutions – I’ve seen a variety of ‘proof of concepts’ developed with Blockchain where a more traditional database would be much more suitable;
  • Be careful to ensure that people involved in digital strategy have the right experience and expertise. As digital and tech has become more popular it has attracted a lot of professionals who lack real experience and understanding of technology.

Let’s Look at Specific Technologies

The scope of digital is loosely defined. If I were to brainstorm a list of terms from the top of my head it might look something like this:

  • Internet of things / smart things etc.
  • Blockchain / distributed ledger
  • Artificial Intelligence
  • Natural language processing
  • Voice recognition
  • Facial recognition
  • Virtual reality / Augmented reality
  • Mobile devices – 5G etc.
  • Geolocation / maps / google earth etc.
  • Robotics
  • Next generation ERP
  • Cloud

But, as a more structured starting point let’s start by looking at what some experts say as of May 2020.

What the Experts Say

I’ve decided to look at two firms; Accenture – which can represent both a management consulting and systems integrator perspective and Gartner – which can represent a research perspective.

Accenture

Accenture UK’s technology home page leads with a 2020 trends report entitled, “We, The Post-Digital People – Can your enterprise survive the tech-clash?”.

Despite the vagueness of digital, I like the use of “post-digital” in their title, it suggests a broader way of thinking than simply referring to a bundle of new technologies as digital.

Accenture start by referring to tech-lash (pushback against tech), before highlighting data to infer people are generally still positive about tech, they then coin the phrase tech-clash as a way to describe the situation we find ourselves in where tech is theoretically good, but often isn’t designed or implemented well. I like this viewpoint and I think it summarizes the one of the major challanges we face designing and implementing technology.

They go on to talk a challenge existing in how companies plan and deploy technology according to business / customer requirements etc. It reads to me that their viewpoint is that the old way of managing tech is no longer appropriate.

I am not sure about this. I think that before we say that we have to check whether a business has a formalized and effective way of managing their tech portfolio (many don’t), after we assess that we can think about whether it works for new technologies. To my mind; theoretically, methods like ITIL and COBIT etc. should work with new and old technologies alike. In fact, when you think about it, technology by it’s nature has always been new & disruptive. Can you imagine the excitment on the project to set up the first mainframes!

I would definitely accept that many technology departments have become bogged down in with too many processes / levels / standards / products etc. but this should be fixed regardless of ‘digital’.

Following this brief intro Accenture call out 5 key trends.

If I read the text and try to pull out the technology products or services I get the following:

  1. The I in Experience
    • User experience
    • Data ownership / privacy
    • 5G
    • Augmented reality
  2. AI and me
    • Automation of simple tasks
    • Collaboration between human employees and machines
  3. The Dilemma of smart things
    • I’m not sure what this refers to but it sounds like systems for subscription style products e.g. Peloton or Zipcar
  4. Robots in the wild
    • ‘Physical’ robots outside of factory / industrial use
  5. Innovation and DNA
    • Distributed ledger / blockchain
    • Artificial intelligence
    • Extended reality
    • Quantum computing

Let me critique them one by one:

1. This is pretty clear. It’s a focus on major points of importance or interest for the end-user. However I wouldn’t call this a new trend. This has always been a key area of focus for technology. The topics covered are also quite wide and don’t centre around any specific technology, plus it omits some key end-user topics.

2. The is not clear to me. I assume AI refers to artifical intelligence. Looking at the specific examples cited, automation of simple tasks is not something that would require AI (there are problems with this term that I’ll come to later). Collaboration between human employees and machines could mean almost anything related to technology, but I accept if it get’s more specific there is some really interesting stuff coming in this space.

3. I’m not clear at all what this means. If I was to guess ‘smart things’ would refer to smart devices i.e. internet of things, but the description points more towards subscription style services. Smart devices and subscription combined do open up a lot of interesting scenarios.

4. Robots in the wild is fairly clear.

5. This one seems clear, but appears to be a catch-all for other areas of interest that don’t fit the four themes above.

Gartner

Navigating to the Gartner information technology home page a number of featured articles / insights are shown.

Looking through this page of trending topics the following technologies are mentioned:

  • Internet of Things
  • Cybersecurity
  • Autonomous things
  • Blockchain
  • Digital twins
  • Smart spaces
  • Artificial intelligence
  • Cloud

This is the kind of basic list that I might expect to see. And very typical of the issue of using generic terms w/out explaining what we are really talking about. The only one that stood out as less common was digital twin, “a replica of a living or non-living physical entity”. This immediately reminded me of the interesting article of how the model of Notre Dame in the computer game Assassins Creed could be useful in re-building Notre Dame following the fire damage in 2019. I’m also reminded of Elon Musk talking to Joe Rogan last week on the more sci fi aspect of digital copies of living beings.

It’s a little more challenging to critique Gartner as most of the detail is hidden behind report downloads.

For the purposes of the critique on Accenture and Gartner I am purposefulluy only looking at their high level descriptions. They should be able to clearly explain the ‘how’ and ‘why’ of their viewpoint on digital strategy to a layman on their landing page. It is arguable that if I dig into the detail I will get a much clearer view, but past experience of doing so is a hit or miss.

This particular critique aside, I’d note that Accenture and Gartner both have some excellent content and services.

Creating a Map for New Technologies

To build a better understanding of how this all fits together the first thing I suggest is to build a simple map of digital technologies that you may be interested in. I think it’s better to cast a wide net in the beginning and then eliminate those that may not be relevant to your business.

By map, the form can be a simple categorised list. There are different ways to approach this, one might be to categorise the technology by the way it impacts the user, another might be to categorise the technology by how it works or what it does.

The digital maps presented by companies are often confusing as they categorise things in various ways in one list. One minute they are looking at the end user impact, the next how the technology works.

I prefer to first categorise the technology according to how it works and then look at customer impact as part of a value assessment. One major advantage of this is that it fits well with traditional technology methods and aligns well with how systems architecture is managed.

For this discussion, I’ve 8 category buckets:

As with any taxonomy you can spend a long time debating the right categories. In my experience it’s best to draft a hypothesis quickly, debate with some colleagues and don’t be afraid to adjust as you go.

In this example I split user experience into three sub categories, I wanted to categorise virtual and augmented reality as primarily ‘visual’ ‘user expereince’ technologies.

After categorisation, we can start to note in specific technologies that we want to consider for our business. Let’s fill in the matrix with my list, Accenture’s list and Gartner’s list.

This is as far as I’ll take this taxonomy for this discussion, however for a real business I might turn it into a matrix in various ways allowing me to map e.g. benefits or business units to the technologies mentioned. I might then colour code by complexity or value etc. This should be a useful format to ensure a team / function have a similar understanding of what is being discussion.

Let’s look next at each of these categories in more detail.

User experience – touch / type

The way we interact with desktops, laptops, tablets, phones and smart watches etc. is continuoully evolving. At one extreme – smart use of touch on mobile, and at the other – more traditional technologies are investing heavily in user interface (e.g. the major ERP company SAP focussing on their customisable Fiori interface).

User experience – virtual

Augmented reality – An example I discussed with colleagues last year is a product based on glasses which can project context-relevant information. Imagine you are onboarding a new shift worker in a factory. The worker wears the glasses, then when looking at varius parts of the manufacturing equipement, the glasses overlay operating instructions or status info. This can accelerate on-boarding, reduce errors, reduce downtime etc.

Virtual reality – An easy example is training for certain dangerous or difficult jobs e.g. pilots. As virtual environments get better and VR wear becomes cheaper and more accessable I expect an explosion in this space.

Smart spaces – A smart space is simply a space which includes multiple smart devices that can connect together to give a space relevant experience or benefit. Examples include airports with facial recognition for passport control and barcode scanning for baggage handling. Or alternatively hospitals with trackers for patients and medical equipments / drugs etc.

Non-traditional databases

Databases are a broad and complex topic. Luckily most business people don’t need to a deep understanding of database technology. However as databases are being used in marketing and sales materials it’s worth investing a little time to understand the basics.

The last decade has seen something of a revolution in database design. Traditionally databases were designed to record and store primarily numerical records. Think of a list of shipments or a list of accounting entries. As IT hardware became cheaper and the internet arrived on the scene data volumes exploded and shifted from primarily numerical to a wide variety of formats; images, text documents, audio, video etc.

Databases rely on database management systems that control how information is writen and read. Advancements in the management systems as well as hardware has created a lot of new database products that have massively changed what is possible.

Big data, refers to the ability to handle massive amount of data across different hardware. This is a technical solution that can allow companies to handle these massive data volumes in an efficient way. There are excellent articles out there which outline examples such as the way Amazon set’s up it’s data centres. In a nutshell by using multiple devices cheaper technology can be used at scale rather than cutting edge expensive devices.

In-memory computing, refers to the increasingly cheap price of random access memory. This means more information can be stored and read without writing to disk. In general a huge part of the response times of computers relates to the time taking to read and write data. In-memory computing has allowed traditional systems such as ERP to become much faster. The major ERP company SAP have led with this using in-memory to develop a new database management system they call HANA. Up until recently systems landscapes have been designed with one ‘operational’ database for recording information and one for analysing information. This is because it’s difficult to optimise a traditional database to both read and write effectively. HANA is disruptive in that it can work effectively as an operational database and an analytics database.

NoSQL, refers to a wide range of new database operating systems that can handle non traditional data requirements. A popular example is MongoDB; a document orientated DB.

Distributed ledger / Blockchain, I choose to categorize Blockchain as a database as it’s a technology that essentially records information. The benefit of a public block chain network is that the information is ‘immutable’ i.e. cannot be changed. And also, it can be distributed amongst participants with no central ownership. These are great benefits and make blockchain very interesting. However these only apply to a truly public network. Many corproate applications of Blockchain are not public, for those that understand the tech they replace proof of work with proof of authority. This removes the benefit and in my opinion a traditional database would be a simpler, cheaper, and more appropriate solution.

Information Processing

I think this is the area that lacks clarity the most and is the area where we see terms such as AI or algorithms being used to make products and services seem more advanced than they are. Let’s take a look at some of the key terms:

AI / Artifical intelligence: This term should set alarm bells ringing in your head. I think it has become meaningless through application to almost any technology product. Some people will label any system with logic that replicates human behaviour e.g. IF the kettle is boiling, THEN pour the water in the cup, as AI. Other people will only consider something as AI if it can beat a human at Chess and has potential to wipe out humanity! You can’t take this as a meaningful term when considering technology.

Machine Learning: This is getting closer to a specific technology. Machine learning describes the ability of a computer system to ‘train’ itself. Machine learning is very popular in the field of image recognition. An often cited example is giving a system 1,000,000 images of cats on the internet, the system will learn to recognise when a photo on the internet has a cat in it. Machine learning is a general term that describes this, but is still not specific in how the technology actually works.

Neural Networks: This is one type of machine learning. It’s based on an attempt to mimic the way the human brain works. It’s constructed of ‘nodes’ that mimic nuerons and each carry out one simple operation. Layers of nodes can then carry out more complex operations. Nueral networks are quite interesting and worth a read.

One important thing on machine learning and neural networks is that they have to be trained on existing samples and often a very high volume. If there is any bias in those samples the neural network will build in that bias. I believe there are already examples related to insurance quotes for minorities etc. I expect to see a growing need to audit these and potential litigation here in the future.

Algorithms: An algorithm is simply a mathematical formula. If I have a small program that converts degrees fahrenheit to degrees celsius I could brand it as an AI algorithm driven solution.

Analytics: Another term that is quite often misused and can represent anything from very simple to very complex. Essentially when talking about analytics we should be referring to applied statistics and mathematics. Sometimes analytics is broken into the following:

  • Descriptive: Explain what happened and why
  • Predictive: Forecast what will happen in the future
  • Prescriptive: Understand why what is forecasted will happen.

The bottom line in information processing is to make sure to understand what specifically is being talked about.

  • If buying or building an analytics solution I want to know what specific statistical and mathematical methods and models are included.
  • If I am buying or building a machine learning solution I need to understand the details e.g. is it a neural network, how much training is required, what is the accuracy, how is biased handled etc.

Cybersecurity

Cybersecurity is a complex topic that deserves it’s own detailed discussion. Advancements in computing power, analytics and the volume of data stored in a cloud environment make it easier than ever for actors to attack private networks. With this in mind any organization needs a solid cybersecurity plan and also needs to carefuly consider the security impact of any new digital technologies brought into their network / architecture.

The best way to get a feel for the importance of cyber security is to listen to some episodes of darknet diaries

Privacy

Traditionally systems are not advanced in how they manage data. A good example is GDPR which tightly controls what personal information can be held and for how long. Any systems that handles personal data has to have capability to manage this. Further to that specialized ‘data management’ systems exist that can help to manage that across an organizations technology landscape.

Internet

Internet infrastructure and standards themselves are an important enabler for new products and services covered in other areas. This can be particularly important when considering customers from different geographies and income groups where their method and quality of interent access will vary.

Internet is a key consideration for a wide range of technology initiatives such as Cloud / homeworking / offshoring etc.

It’s also particularly important when designing mobile applications. Does bandwidth support video calls, does the internet infrastructure support geo-location etc.

Devices

Different form factors create opportunities for how we use various componenets of technology with end users.

Mobile in particular has had and continues to have a hugely disruptive effect on traditional industries. Think of staffing, delivery and taxi’s. Mobile devices have allowed app based businesses to form and succeed which utilise the following capabilities in conjunction with a mobile device:

  • A customer user interface with booking / delivery requests etc.
  • A partner user interface to sort / display active requests and allow acceptance
  • In built e-contracts / legal documents where necessary e.g. staffing
  • Geo-location / map integration showing partners where to go e.g. in the case of delivery to the customers location or staffing to the work location.
  • Pay integration – ability to pay via card / paypal etc.

Automation.

In the technology map I’ve considered two forms of automation

Physical robots is it’s own space and I won’t consider it in detail here.

Process automation or ‘robotic process automation’ is a fairly traditional space. There has been a recent boom in this with firms such as UiPath becoming quite successful. This is often branded under ‘digital’ as exciting and disruptive, however the technology at play is very simple.

In a nutshell robotic process automation allows you to take a set of steps a user does with one or more systems and automate it.

For example, if an accountant looks up a record, then checks the client against another systems, then say checks a rate against another systems and then approves or declines, if fixed rules for all cases can be written this can be automated using RPA.

I recall around 15 years ago we used automation tools to mass test transactions in ERP systems which more or less did the same.

I have a couple of recommendations on RPA

  • RPA itself is very simple and does not require consulting or systems integrator assistance. Companies can learn to develop RPA scrips themselves, simple training is all that’s required.
  • However I do recommend RPA work should only be considered as part of a broader process improvement initiative, there are better options than RPA in many cases e.g. eliminating the process entirely or changing underlying systems that require high volume of manual effort.

RPA could be considered as a ‘band aid’ that sits on top of poorly designed systems. It can provide a large benefit in terms of freeing up a lot of human time, but all RPA scrips will need to be managed on an ongoing basis.

Next generation ERP

Traditional enterprise resource planning software providers such as SAP, Oracle, Microsof etc. are also developing their own disruptive changes. We already touched on the HANA database which has allowed them to vastly improve their business suite product; which is now called S/4 HANA.

There are too many new and changing products in the ERP space to cover here. However a noteworthy area of interest that I would like to highlight is subscription management.

Traditional customer relationhip management systems are not designed to handle subcritpion models, however this is becoming a more and more popular way to engage and contract with the customer.


Creating a digital strategy

To cut through the nonsense at the strategy level I recommend we should treat digital strategy as no different from any other part of strategy. Innovation should be a fundamental part of strategy and digital is simply an innovation slant on technology.

Different companies do strategy in different ways. Generally speaking there is a higher level corporate strategy that will define key targets (sales, margin etc.) as well as direction for each business unit (e.g. objectives for products and customer groups).

The strategy then will typically flow down to individual business units who will create a more detailed plan that aims to deliver the goals in the corporate strategy.

Information technology should be part of the plan for each business unit (specifically how tech will support that BU), and should also have it’s own comprehensive plan.

The plan for information technology itself should deal with topics such as overall architecture, systems development and systems support etc.

When you consider this process, they key for a successful strategy is to ensure that the IT experts are correctly involved at each stage.

  • The CIO with the support of senior architects works with the Executive Committee on technology elements of the corporate strategy. This will often focus on things such as budget for major projects, new technologies to support business objectives.
  • Domain specific architects and technology product experts will work with the individual business unit leads on the business plan for each business unit, ensuring that technology is embedded in each plan.
  • Finally, the information technology strategy will involve all key leaders in information technology and bring together everything they are doing.

At each stage thought should be given to how technology can be contribute to the business. Some smart questions to ask are:

  • What technologies are our competitors investing in?
  • Are there any ‘new digital businesses’ entering our market segments (if so, find out everything about them!)
  • What direction are our existing technology partners taking with their products / services
  • What are the experts saying about our industry / geography etc.

This is a somewhat simplified view of strategy development. I would highly recommend companies take a proactive approach to optimzing strategy. If your strategy does not result in good plans for digital it’s highly likely you are missing other opportunities in the market and not addressing all relevant business risk.

I’ve seen instances of talk of creating seperate digital strategies and forming seperate digital teams. I don’t like this approach for a number of reasons. This will end up in silo thinking and silo product development. It might have to be done on a tactical basis, but I would not recommend it.

If you silo digital thinking too much the following issues may occur:

  • Your digital investments may not align well to business objectives as it’s somewhat removed from the general strategy and planning process;
  • Setting up a new ‘digital’ team is likely to result in a group of people who are biased towards digital and are more likely to invest in products that are not yet ready or have a lack of value;
  • Even if your digital investments are successful they won’t bring the rest of the business along with them.

If the existing organization lacks capability and capacity to embed digital in the existing strategy process and existing business management systems then I simply suggest adding new employees or consultants into the existing teams to beef up capacity and capability.

Those people can also create a virtual CoE on digital to bring thinking together and present summarise on the topic, but the key thing is they are embedded with existing management in all units and levels.

Dealing with digital disruptors

If you are are in an established business facing competition from ‘digital’ disrupters e.g. new app based businesses. I would recommend splitting your digital aspects of your tech strategy into two:

  • Innovation of existing products and services. This will often involve things like automation and improved analytics.
  • Development of new products and services based on the ‘art of the possible’ with new technologies.

The reason I would split this out as it may be impossible to leverage new technologies on existing processes. Existing IT architecture may also make it impossible or very expensive or difficult to change some existing processes and systems.

This may sound like I am contradicting what I said earlier. This work should still be developed and done within your existing strategy process and management structure, but the products defined should be split on this axis.

This is really an accelerator for businesses facing current or future market share loss due to disrupters.


What’s your view of ‘digital’ technology?

What technologies did I miss that you think are interesting?

What would you be interested to read more of my thinking on connected to this topic?