alexroan

I like plain English in business.  I like plain English in general day to day life.  There are some exceptions that I agree with.  As a graduate student of engineering I understand that in technical professions specific terms are required.  And I also appreciate that in the arts whether poetry or theatre or other medium use of more complex language can be a great thing.

However the business world is already mired in complexity and opposing views.  You just have to venture into the world of ‘business guru’ books to realise that very rarely do they agree on anything - I still don’t know if I should hug or shout at a co-worker go get something done (I do know it’s better to hug people in general though!).

This morning I attended a meeting.  And discussing a clients issues / requests I heard terms such as ‘value driver’.  In an hour meeting no one actually mentioned what the value driver was?  I’m not sure if anyone new!

Please, in business if you want to talk about objectives, benefits, value etc.  Don’t say the buzzword, be specific refer to what you are actually talking about.  And if you can’t be specific and quantify it..  Well guess what - probably means you don’t know what you are talking about!

I feel that culture and working environment is overlooked in the business world.

My observations over the years are that businesses across industries frequently try to solve their problems by changing processes, organisation structure or other factors.  And consulting firms focus on trying to sell solutions with methods to implement them.

Even in the case of failed projects, people tend to first look at the method, the solution, the decision making to identify the cause of failure.

Now if you asked me, what is the main difference I see between successful and unsuccessful organisations and successful and unsuccessful projects.

It’s largely cultural, and if I was to be more specific it’s a sense of values, and importantly values that are believed in and promoted through all levels.  What do I mean by values - the usual buzzwords such as ‘trust’ ‘honesty’ ‘respect’ etc.  But the successful organisations apply these.  So ‘respect’ means the CEO will take the time to lesson to the junior analyst or factory line worker and will have an honest conversation with them about the business.

Never underestimate the effect of treating people well and creating a good working environment on peoples performance.

Here are some interesting snippets and examples of things I’ve seen go wrong in organisations and projects:

• The director sponsoring a project who used aggression and demanded long working hours to get work on the project done - result, the team spent more time complaining or making fun of that director than focussing on the actual business challenge
• The organisation director who noticing people use facebook, asked IT to block it (note - in this case, I saw the same director using facebook in her office).  The right question, is what is wrong with my organisation that people don’t want to work?
• The company the re-models the office to open plan with no privacy areas to save costs (see my post on group vs. individual work & creativity).
• The cases of people being pressured to do 12 hours days, but then having high sickness records and reduced effectiveness due to their stress levels affecting their health

If you are running a team or a project, please assess the working environment and question whether it is conducive to creativity, sharing and developing high energy levels, or if difficult working environment (location, people, stress levels) is reducing effectiveness.

And don’t forget it is also more rewarding to contribute to peoples happiness too.

Over the years I’ve worked some large change programs including:

 - opening shared service centres (business services)

 - upgrading IT systems

 - optimising business processes

 - corporate restructuring

 - acquisition business integration

Most of these programs (but not all) have a clear purpose.  For example shared services is commonly associated with an internal management desire to reduce costs.  While, another example - upgrading IT systems may related to existing systems nearing the end of their useful life.

What’s the issue?  The issue is that the why might be clear to the board.  But two problems can occur:

1. The why may be clear at the board level, but is not sufficiently described or deployed through the organisation to ensure all involved parties work towards the same goal.
2. The why is not defined at a granular enough level to plan the required change activities.  
3. In defining and focussing on a single reason for change other outcomes (which can be advantages or disadvantages) are not considered.

So I think it’s worth discussing further how you quantify the why? and also whether you have considered everything:

Quantifying your change driver

As a minimum you should have some clear written statements relating to the why.  These normally take the form of some defined objectives.  Ideally these should be quantified.  If cost reduction is an objective then how much and by when.  This should be defined in a format that can be communicated clearly to all parties involved in the change.  Advantages of doing this are:

• Your change know what they need to deliver when defining the vision and activities to achieve it
• There is no ambiguity, people do not have to waste time second guessing or debating management desire.
• The clear objectives at this level can be further broken down during the activities of defining the vision and activities to achieve it.  For example savings become employee, IT, admin savings etc.
• If you go into implementation having a clear view of the desired change and when it will be delivered is very important.  This allows you to control the program in terms of potentially even stopping if things go wrong.

If you are not clear on your objectives, this is a signal to stop!  Don’t go ahead with the change program.  Start with a smaller program to explore options and possible benefits.

Considering all relevant outcomes

When you set your reasons why.  Don’t think in a silo.  Consider the type of change you may undergo and think about all other possible outcomes.  This could results in delivering more benefits or avoiding some nasty surprises.

• Programs initiated to cut costs can often lead to quality or control issues.  Make your objective related to quality and control clear at the start.
• Major program of change are an opportunity, if you focus on only one thing you might miss free opportunities to fix or improve other things along the way.

I would recommend researching whether the top performers in your industry have performed similar programs to those you are considering and find out what their change drivers were and if they were realised.  

An interesting example is shared services and outsourcing.  Back in 2000 some leading global companies had success with shared services and outsourcing (including off-shoring).  In the years that followed there have been many shared service, outsourcing, off-shoring programs that fail to deliver benefits.  This is in part due to firms trying to capture cost savings without considering quality and control in their plans.

Good article on this in the NY Times.  Confirms my suspicion that open plan offices are not the most productive working environment and that meetings and team work are not always the most effective way to work.  

Teams do make sense, the the trick is using them when they deliver value and using solo work when it delivers value.

http://www.filipdujardin.be/

Many businesses use management consultants, although how effectively varies widely.  In the interest of helping people get the most out of management consultants I’d like to share with you five tips.

I’ve spent seven years working in the consumer products industry as a project manager and four years in the management consulting industry.  These tips are based on general experience and not any company in particular.

1) Ask Questions

I’ve observed that people in business have a tendency to want to show their knowledge and expertise and this often results in people competing to talk and get their point of view across.  I’ve personally been paid to work with clients who spend more time trying to convince me they know what they are doing than listening to my advice or asking questions.  My first tip is to listen and ask questions (and lot’s of them).  Get as much information as you can.  You can pick and chose which parts you agree with and discard the rest afterwards.

2) Use Their Extended Network

When you buy management consulting time you don’t just buy access to the individuals assigned to your project, you also buy access to the knowledge bank of that consulting firm (in particular  knowledge related to the engagement).  Make a point of asking your management consultants to bring back points of views, perspectives and solutions from around their firm.  If you have time I’ve even recommend having an exploratory discussion with them about their wider firm capability so that you can tap into skills that may be helpful to you.

3) Get Clear On What You Want

Given free reign management consultants will happily spend a lot of time writing beautiful highly formatted and lengthy reports and presentations.  Think about what is really important to you at the outset - is it a long report or is it a variety of ideas, solutions options, research data etc.  Be clear with your management consultants what you want them to spend time on and how you want that information to be fed to you.  I personally would rather have great ideas on a few simple slides than poor ideas on a hundred beautiful slides.

4) Share Your Problems

Some management consultants have a reputation for always trying to sell.  Realistically in most firms there are sales types and there are subject matter experts.  Regardless of which type you are working with don’t be scared to talk about other problems in your firm.  They may try to sell you additional services - if they do, just ask for a business case to show why the benefit outweighs the cost.  Worst case scenario you will have received some initial ideas on what options you have to deal with some problems.

5) Workshop, workshop & workshop

Management consultants occasionally get hired, locked in a room with a problem and  asked to solve it.  While they will know general solutions which may work in various industries they will not know the intricacies of your business (environment, culture etc.).  To come to the right solution for you, it’s very important to work together.  I recommend workshops continuously.  You can focus workshops around problem exploration, solution identification and solution testing.  The more people from your company you can integrate into this process the more likely you are to be successful.

I hope these tips are helpful.  If you have any comments or thoughts I’d be very interested in your contribution.

My favourite self improvement books / DVDs of the last year or so..  Highly recommended… http://amzn.to/rvrq1z

Lately I’ve been thinking a lot about the approach to different projects involving large scale IT systems.  When I was a project manager at P&G I had experience of managing SAP projects.  SAP is a large enterprise planning systems which manages activities such as accounting, shipping etc.  At P&G I didn’t have to consider the approach too much as we had a pre-defined solution and it was simply a matter taking this pre-defined solution and making minor adjustments to implement in the different local business units.

Every now and then I come across firms talking about ‘vanilla’ implementations of IT software. This seems to happen quite often with ERP systems (such as SAP and Oracle) which have a wide range of possible configuration and customisation. I’ve heard this in strategy discussions, seen it in RFPs and seen the results in live instances. I recently had the delight of running a short QA analysis on an in flight project which got me thinking about this topic.

What do people mean by Vanilla? 

I think everyone has a slightly different interpretation, but typically the following attributes could apply:

Aim to use the software as it exists of the shelf. Or at least minimising any configuration / customisation

An acceptance that some business processes will need to change to match the way the system works

Setting up data and reports by simple transfer from existing system, only using basic guidelines (e.g. field names) to map data

Accepting that whatever off the shelf reporting exists will be used

Relying on the systems standard processes and controls to be fit for purpose

The teams then tend to proceed with a gap analysis focussing on things the system doesn’t do at all. The conversation can be summarised to be something like ‘can the system handle invoice posting’ - ‘yes’, ‘can the system handle my local tax report layout’ - ‘no’ - this tax report would then be one of the few configurations or developments. Ok - my example is a bit flippant, but really quite often the project teams go to very little detail in assessing whether the system is fit for purpose at the level of detail of transacting in the system and even more rarely do they consider how non system steps integrate with system steps in the overall business process. Never mind the real interesting topics such as well structure data models and optimised report delivery.

I’ve always considered this Vanilla approach to be a bit crazy for large scale projects and typically supported by people without real experience. Consider the second bullet point above, if you manage a successful business would you rely on some software supplier having the knowledge to tell you how your processes should work - without validating it in detail - I certainly wouldn’t.

And at the end of the day the real problem is that Vanilla doesn’t really exist for a lot of software products. They are not designed to work of the shelf. They all need customisation and configuration to work effectively and not just for exceptional processes such as local legal reports and industry specific processes, but also ensuring the main processes work for the company in question.

What’s The Solution?

Now that I’ve had a nice rant about the use of the word Vanilla I can move on and say I accept there is a very good question here. It’s about getting the balance of investment in product configuration / customisation right for your specific requirements. And those can be very different from project to project consider two sample scenarios:

Example 1

Company A needs to undergo significant transformation of it’s Finance function, cut FTE, reduce ME close time and improve agility in reporting. In this case I would strongly recommend significant investment in configuration and customisation and tailoring the solution to help deliver the specific benefits needed. In this case you may also want to suplement a core solution with peripheral best of breed supporting solutions (e.g. reporting tools)

Example 2

Company B has no cost pressure, no major reporting problems, but has a burning platform. In this case you may sacrifice usability and many other factors just to get a fast implementation copying exactly the previous set up in terms of data, processes etc. 

When we are approached by clients to provide advice on implementation approach or to QA a vanilla project I think the best thing we can do is help them understand; based on their benefits case and individual situation, what the risks are in a vanilla approach and if they are really adamant we can at least help them focus their limited configuration and customisation effort on the most important factors. I’ve listed a few areas that normally need attention and in fact these were the unsurprisingly the same things which came out as issues in the recent QA analysis I did on a vanilla project in flight:

1) Data Model

Has the data relationships and reporting capability in the new system been analalysed and understood, has the data been set up in such a way as to optimise this and to ensure that the correct dimensions can be extracted and analaysed when reporting? In practical terms this can include considerations on how many different things are being reflected in the systems such as legal entities, functions, profit centres, cost centres, projects, shipping points, customers, products. This needs to address the individual data elements, how hierarchies work and what the interrelationships are.

2) Governance and controls

User roles, segration of duties, process controls. Very rarely are all of these covered adequately by standard system settings, has the firm undertaken the necessary work to design the correct user roles. Are all right controls in place for all processes, is the right documentation in place.

3) End to end process suitability

The main thing that tends to be missed here is the interaction of system and non system activities and secondly the seams between different functions. Simple example a great invoice processing systems doesn’t work if purchasing always enter the wrong prices or the invoice is received by a manager and left in an intray for a week.

4) Reporting Delivery

Will a dept of ten people have to spent ten days every month end reconciling interfaces, preparing excel workbooks, adding manual commentary and then be unable to trace back to the original transactions when asked a question? Are the daily and ad hoc reports fit for purpose, what is the performance like, can charts be easily created, is there web access to ensure everyone looks at one version of the truth (vs. 100 spreadsheets).

This is not meant to be comprehensive, but just some ideas on the key areas that are often missed on vanilla or other low cost IT implementations. The examples are quite specific to ERP and Finance; I’d be interested if people see similar things in other areas?

Through population growth and consumerism the Earth is taking a bit of a beating at the moment. Does IT contribute positively or negatively to this?

Some might argue that IT has a good effect. Citing examples such as videoconferencing and online colaboration, which remove the need to meet face to face. There is no doubt advances in technology are also helping develop greener production processes and advances in recycling in some areas.

However I believe IT is guilty in two ways:

1) The direct impact of IT on the environment

Many components of technology (e.g. phones, laptops, servers) are manufactured in an environmentally damaging way. These products are then generally not easily recyclable and contain toxic products. However I note that Apple now claim to have a completely recylcable laptop and there are companies who will buy your old mobile phone to re-sell abroad - a sign that things are moving in the right direction?

Secondly, IT consumes a lot of power. Corporate data centres can be extremely power hungry. Many large companies will have many thousands of servers running twenty four hours a day all year. Even those innocent looking social networking sites might be running power hungry server farms somewhere. What are the solutions to this? As a first step optimision of utilisation would be a move in the right direction. This is where cloud computing could help. By sharing power hungry servers and insuring the overall volume of harware is optimised.

2) The indirect impact of IT

The less observed impact of IT is a secondary effect. The creation of mobile phones, the internet, improved corporate IT systems (e.g. for supply chain) have all led to increase in mobility at both a personal and business level. I would surmise that the improvements in IT over the last fifty years have contributed quite significantly to environmental damage through these secondary effects. I don’t have data to prove this, but I think it’s quite obvious to see.

At the end of the day IT itself is not to blame for environmental damage but rather the way we use it. As a technology proffessional I think we need to build more awareness in our industry to the direct and indirect effects of the IT advice we give.

Having worked in several IT organisations over the years I’ve noted some common elements:

• Large technical infrastructure management teams (manage data centres, networks, bcp etc.)
• Large business applications teams (technical experts in execution of processes within the IT)
• Small teams of senior management including strategists and architects
• Very small teams focussed on innovation

This is a bit of a generalisation and I realise all companies are different, but I’d say I have honestly observed this kind of structure in several large organisation I’ve encountered. Obviously small and medium business and more innovative companies will differ.

With these organisation structures the majority of effort seems to be geared towards two main types of activity; on the one hand developing architecture direction and accompanying standards (technology and data), on the other hand focused on discrete projects which tend to follow the classical model of translating business requirements from the users to technical specifications which are then developed into new applications or changes to existing applications. The direction for these projects can come from any one of many directions depending on the way the business manages the delivery of it’s strategy.

What is changing as we move forward? With many new technologies we see more and more users developod solutions i.e. think of widgets, gadgets & apps - take the iphone platform as a good example. In terms of content users can directly build content and structure on formats such as Wiki. With SOA and cloud computing these applications can be managed on external infrastructure. In these situations the majority of the classic IT organisation activities are not required!

This changing world has been enabled by advancements in processing power and software capability. New technologies are much easier to use and have great interfaces which allow users to do more of the design and build.

Personally at a top level I see the IT organisation role in the future moving towards focus on innovation, specifically software tool analysis and selection and management of principles and standards. With SOA organisations will be able to quickly switch between technical solutions, for cost saving and efficiency reasons the IT team must be able to enable this quickly. The large area of technical infrastructure management will be slimmed down as services move into clouds, large IT companies will be able to leverage much more scale on managing clouds (e.g. HP, Oracle etc). Business application teams will be slimmed down as solutoins become more configurable by the end user.

Of course this won’t happen overnight. We will still need thinkgs like in house managed SAP ERP with expensive SAP consultants in the near term, but as we move towards Web 3.0 I expect simpler solutions to appear.

I came across an interesting book on twitter today; unfortunately it’s only scheduled to be published later this year. The topics is:

‘Cloud Computing & SOA Convergence In Your Enterprise: A Step By Step Guide’ by David S. Linthicum (http://my.safaribooksonline.com/9780321659392/ch06?close=0)

I think cloud computing is an exciting concept (perhaps too exciting! - I see quite a lot of references to ‘clouds’ but few tangible marketable solutions). But how do I make this a worthwhile topic for with clients?

Companies like Sun Microsystems are a good reference. They have taken cloud computing pretty seriously from the get go (perhaps this is one of the reasons Oracle decided to invest). Check out their website, they have some good free thought leadership (http://www.sun.com/solutions/cloudcomputing/index.jsp).

The thing I really like about SOA is its focus on setting standards and providing a set of tools which allow you to break down your architecture into a distinct number of tools. These then act as individual services, which can then collectively be built back up into your new SOA. While your services may change over time, your SOA will be quite stable.

How does this help you with cloud computing? Companies with SOA in place will find it much easier to utilise clouds. They are in a position to decide quickly which of their services are appropriate to be operated from a cloud and which are not. There will be a number of factors relevant to this such as technology platform, security requirements, business criticality etc.

Once this analysis is done, it’s a matter of migrating those distinct services to the cloud.

On the other hand companies that don’t run SOA will face a number of bigger challenges. I see the main two being:

Inability to segregate distinct parts of the architecture suitable for cloud computing

Lack of common data standard / semantic making cloud computing expensive to implement

Lessons From The Gaming Industry

I’m often amazed at the level of diversity and creativity found in the gaming industry. Take for example games such as the Nintendo Wii with it’s motion based user interface, EVE with it’s highly evolved free market economy or new games such as Braid with it’s quirky artwork and ability to manipulate time.

In contrast to this the world of operating systems and business applications can at times appear a bit dry and ‘samey’. Yes Apple is different from Windows. Oracle is different from SAP. But how different are they really?

Another thought - I came across an interesting blog about a guy who ran a bit of a social experiment about a homelesss guy and his daughter in The Sims 3. Check outhttp://aliceandkev.wordpress.com/2009/06/09/alice-and-kev/. The story is quite sad. But also surprising and interesting at times. The ability to set constraints and allow a system to make decisions can lead to some quite unexpected results (of course there is some user intervention). Could this type of intelligence be used to good effect with business modelling?

I wonder if we can capture some of the creativity and excitement from the gaming industry and improve the experience and results of using IT in business?

PS If your bored of your ‘samey’ Windows desktop try out Bumptop for something different (on your home pc of course!)

While quite a specialist question, this is a topic that challenges many medium and large scale companies. There are many relevant considerations and even similar companies can take quite divergent approaches.

From 2000 - 2007 I worked in Technology for Procter & Gamble. I re-call in 2000 P&G had just started what it called it’s Global Core Finance project which involved the design of a standard finance solution set using SAP. The standard global design was then rolled out across different countries. By the time I left P&G this single instance global core finance solution (hosted in the US) was used to an extent in almost every country P&G does business. This was a long term project subsidised with a high level of expertise (P&G has very high level of internal capability with Finance process design and systems knowledge such as SAP and one of the more advanced integrated global architectures around). As such one of my first experiences of SAP projects was seeing a single instance approach deliver big benefits.

But is the single instance approach right for everyone? Imagine a company has very different business units, say a Pharma company in the US (think high level of FDA restrictions and control standards) and a paper manufacturing site in China, in this case it might be fairly obvious that the effort and reward in harmonising reporting, standards, processes etc. outweights the benefits.

Therefore would it be correct to surmise that single instances work best for either large regional / global companies with similar operations in multiple countries? For other situations a multiple instance (could be a template solution, could be different software etc). approach may be more appropriate.

Thinking this through, some of the benefits and disadvantages I can see for / against the single instance approach follow (can you think of any others?):

First of all what are the Landscape Options?

Single solution provider, single instance (i.e application & database)

Single solution provider, template solution, multiple instances (i.e. multiple applications & databases, but with common configuration / data standards etc)

Single solution provider, multiple instances (i.e. multiple applications & databases set up differently)

Multiple solution providers, multiple instances (e.g. Oracle / SAP / Agresso) different solutions for different business units & countries)

And for the first one (Single Instance), what are the benefits?

1) Management Information

Ease of preparing consolidated reports, MI from all entities in a standardised structure and format.

Single view of key metrics across the business e.g. inventory, assets, liabilities

Faster time to produce reports with less interfaces / manual interventions

Simpler set up and use of data warehousing and reporting tools

Supports the development of a common MI language

2) Operations Management

Standardised process definitions, business rules making operational activities more reliable and less complex

Easier to building automation and improvements on a standard core design

Internal operations can be integrated, providing interoperability across the business

Remove barriers to collaboration across internal departments,

One platform for all users, reduced training and administration efforts

Leverage capabilities across regions / geographies, easier to build centres of excellence and advance optimisation work

Scalability across sites / geographies

3) Compliance, Statutory & Regulatory

Standardised data structures designed to meet compliance requirements, improved audit trail

Allows the company to think & comply globally & locally where systems meet a high percentage of global and local requirements.

4) Technology

Technology Maintenance is simplified and costs reduced

Rationalisation of IT architecture

Reduced reliance on interfaces, middleware etc.

What are the disadvantages?

Very strict control on approvel may cause slow reaction times to business driven changes

Limitation on meeting very specific requirements in order to protect standardisation / global requirements

Higher level of risk to business continuity (all eggs in one basket)

High performance WAN required between user sites and server location

Expensive hardware may be required to support processing requirements

While I don’t have a huge amount of practical experience with SOA, I’d like to share some of the theory:

Overview

There is some mysticism, but the technical concept is simple.

Software vendors (e.g. SAP, Oracle, IBM typically don’t explain the pure technical concept in a simple way, but rather sell you their take on how SOA fits into their products.

It can be used to describe the business approach or the technical architecture!

What’s the big idea? There are lot’s of advantages and disadvantages of SOA, but in simple terms it provides a supporting architecture to allow you to take the best of what you use everyday and package as a service to promote easy use and re-use.

Things do get more exciting though, as companies and vendors start to package more and more processes as a service you can start to use SOA to work with external parties!

One important concept of SOA is that it allows different technologies to communicate as ‘black boxes’. i.e. an HP Unix based application could use a service hosted by a Linux server.

Basic Technical Architecture

There are four key SOA components described below, ESB is also quite important so briefly mentioned:

Enterprise Service Bus (ESB)

Manages the transport of messages between software components.

A layer that runs on the network that provides guaranteed servicing.

Many software companies have mature ESB products available off the shelf

Registry

Simply a catalogue of services.

This is on call to provide information about services which are available to any requester.

Proves a useful reference in process design.

Can be used to publish services to external partners.

Registry software can be developed in house or purchased of the shelf.

Tip: Quite often SOA implementations make the mistake of trying to fully develop one service. As a first step business and IT can start by developing a list of potential services. This can be used to analyse the feasibility and justification of SOA in that organisation.

Workflow Engine

An evolution of workflow engines historically used in IT to model processes.

Used to connect and manage a business process end to end (assuming a business process requires some services to complete).

Also provides modelling technology to build processes.

Broker

Makes the actual connection between different components.

Uses information about components stored in the SOA registry.

Middleware, it’s really an evolution of Enterprise Application Integration (EAI) and Enterprise Information Integration (EII) software.- Tip: Many of the ESBs on the market can act as service brokers.

Supervisor

In SOA connectivity and communication are critical.

The supervisor simply tracks what’s happening in each stage of any process.

Measures service levels, reports when service gets bad / fails.

A Note On Communication

Now it starts to get more complicated (you may want to read up more on this part)… A primary aim of SOA it to enable diverse applications to provide services to each other (e.g. IBM mainframes, Unix, Windows, Linux servers and other proprietary formats). To do this SOA requires common formats and standards to communicate.

SOA uses a set of standards based on XML (Extensible Mark-up Language), this is a extendable tag based language. In summary XML is ideal as it supports the metadata and flexibility requirements that are critical to make SOA work.

Some important SOA data terms are: UDDI, SOAP, WSDL – if you want to know more you can easily review on W3C or other online locations.

How It All Fits Together

End to end business process – A purchase to pay invoice processing system which needs to validate delegation of authority approval limits via the HR system.

(1) Invoice processing system sends a request to service broker

(2) Service broker connects to the registry to search for a service

(3) Service broker then connects the invoice processing application to the DoA application (by passin