Business Process -- Irrelevant, Distracting and Dangerous

Discussion of why the current focus on Business Process Mapping is seriously misplaced and is leading to major inefficiencies and negative project outcomes in the business information systems industry -- concludes that "Business Process Obsession is killing ERP"

<<< PREVIOUS SECTION:  Precision Configuration and Strategic Business Information Architecture

<<< PREVIOUS SUB-SECTION:  Example General Ledger Manual

Wikipedia statesBusiness process management (BPM) is a management discipline that focuses on improving corporate performance by managing and optimising a company's business processes”.

“Business Process” is arguably THE buzz word of the Business Information Systems world today.  Every major ERP product provides comprehensive support for Business Process including comprehensive workflow management and related capabilities.

However, this focus on Business Process, the vogue for at least the last ten years is associated with rocketing system implementation costs and escalating levels of project catastrophe and write off, see my Failure Catalogue.  Yet it seems that the industry does NOT stop to examine the correlation, let alone draw the uncomfortable conclusion that that consideration of this correlation calls for.

That Business Process, is, for the most part irrelevant, distracting and DANGEROUS!

Why should they?

BPM is a license to print money!


Bridgestone versus IBM

An example – Bridgetone Tires are currently engaged in litigation against IBM for damages resulting from a botched integrated business systems supply, development and implementation based on SAP technology.  See "IBM Rips Into Bridgestone Over $600 Million Lawsuit"

The name of the project? OTC – “Order to Cash” – a classic example of the meaningless gobbledygook that BPM proponents use to describe process orientated project activities.  Once one understands the implications the very use of the name “Order to Cash” is a pointer to a project with massive time overruns and high probability of damaging business outcomes – exactly what happened at Bridgestone.

In 2009, with a number of highly successful implementations under my belt – see the ASCO and V3 Case Studies, as evidenced by joint conference presentations with clients, the highest form of testimonial possible, I found myself confronted by a client who claimed that I did NOT know what I was doing because I did NOT “DO” business process.

They advised me that they would need to replace me with a consultant “who understands ERP”, which translated meant “a consultant who does business process”.  I did NOT know how to respond,  YES, I did NOT do Business Process, I never had and it had never been an issue.  Eventually, humiliated, I walked away and started to investigate and consider business process and BPM generally.

In the years that followed I have investigated and diagnosed (see “Pulse Measurement”) a number of disastrous Business Process centric ERP and other business systems projects with massive time and cost overruns, stalled projects, damaged client business being the regular experience.  In that time I have NOT encountered a single high value outcome or, for that matter, a single outcome that has met client expectations.  Some mediocrity? YES!  Success by my standards? -- see my article “What does a HIGH VALUE Business Information System Solution look like”? – NO, most certainly not!


Outcome of a successful business information systems project

Let me define success for an ERP or other business systems project in my terms:

1.  It goes in flawlessly without drama and works effectively immediately;

2.  It enables the business to run more smoothly and efficiently than it did before;

3. It strongly supports competitive strategic decision making and effectiveness such that three years on the client company is measurably more competitive and more profitable and is growing significantly faster than it was BEFORE the new system.

In other words, a quick call OFF the record, to the CEO results in a strong expression of satisfaction and perhaps some superlatives.

Why off the record?

Because many executives and managers LIE on the record and claim that their system is just fine because they do NOT want the shareholders to know what a mess it is and how much money they have wasted for little or no return.  I know of one multi-national with a SAP implementation on which they have spent over £50 million that is so useless that almost nothing is being done in it and yet executives have been led to believe it is working fine despite the army of contractors and staff who keep things running outside of SAP.


BPM over rated and overstated

Two years ago I presented a paper titled “BPM over rated and overstated” at the BPM Summit 2013 in which I criticised BPM severely – NO ONE objected and a few people agreed – an interesting experience.

In the ensuing two years I have seen further failures, including studying the Court papers of the Bridgestone – IBM case.  And I have finally concluded that in the context of business system, BPM, processing mapping and process language are irrelevant, distracting and dangerous!


Irrelevant?

Irrelevant because most parts of most organizations do NOT follow any relevant or meaningful workflow (the accurate meaning of process).  We have functional units that perform tasks to agreed standards, policies and in some cases procedures but generally NOT in terms of any discernible “flow”.

There ARE cases where workflow IS important and in those cases it should be optimized (or dictated by senior management), but most of the time we rely  on the intuitive initiative of well trained and responsible personnel to perform tasks in response to whatever circumstances life throws at them from minute to minute.

To perform these tasks staff work on computer screens that are logically organized with packages of related information and collated with menus or desktop icons that allow the staff member to gain quick access to whatever function they need to make use of in the moment.


An example – Workflow solution where flow charting was a waste of time

Some time ago I was involved in a project to implement a workflow management solution.

The consultants commenced by drawing flow charts and doing business process stuff – seemed reasonable at the time, after all we WERE implementing a workflow solution and I assumed they knew what they were doing!

However, once it got down to actually configuring the workflow software the fancy drawings that had taken months to perfect had to be all but totally discarded and the work redone because the REAL workflow was MUCH more complex, varied and finicky than the two dimensional diagrams could cope with.  The much more flexible and powerful workflow software was able to cope with this complexity, the text book process techniques not.

A powerful lesson that conventional workflow diagramming techniques with flow charts, etc as typically used are NOT sufficiently precise or accurate to in actual fact do anything but produce conceptual sketches of ROUGHLY how things work round here!  EVEN in the case of a process project!

From my engineering perspective, a total waste of time – a conclusion supported by a number of  failed and sub-optimal projects I have investigated.

Hence I conclude that traditional business process mapping in whatever shape or form it takes is IRRELEVANT!


Distracting?

Distracting because management consultants spends days and days in intense workshops producing diagrams that are difficult to understand because they are so abstract and inexact and try and capture real time “Process” that is  multidimensional rule based, complex, variable, discretionary and varies from person to person, situation to situation and day to day.

Flow Charts, Swim-lanes, Maps, etc – you name it the industry offers it – problem is that much of the time the consultant does NOT really understand the technique and is so caught up in their creative frenzy and drawings that they totally lose sight of the REAL  goals of the project!

And, because they are so busy drawing, be it on a white board, brown paper or computer screen, they waste huge amounts of client staff time AND miss the vast majority of the REAL information that they should be harvesting – see my article “Effective Discovery is Essential” for an approach that actually works.

The most extreme case I have ever come investigated was an ERP implementation which, after 2 years and over a million pounds had produced numerous large files of meticulous flow charts, swim-lanes, etc plus a number of tearful and frustrated client staff who had been marginalized because of their long hours of dedicated work away from the workplace such that their permanent positions had been filled by others.  The project had one of the most toxic project environments I have ever encountered.  People in tears, others refusing to speak to me except off the record.

The implementer blaming the client but inaccurately describing the client’s actual requirement!

The client intensely frustrated that their reasonably simple requirement for a small piece of clever web-based software was NO closer to being met than when the implementers were appointed.  The BRUTAL truth was that NOTHING that had been done in any way moved the client an inch closer to meeting their requirement.

The implementer? – the IT arm of one of the Big 4 Accounting firms – trusted advisors whose incompetence and indifference was breath-taking!

Hence I conclude that the entire business process activity on this project had totally DISTRACTED all involved from the REAL objective of the project and wasted huge amounts of time and money and seriously jeopardized honest and hardworking personnel!

Were the consultants incompetent and process obsessed or greedy and using process to milk the client?  That is a conversation for another day!


Dangerous?

The above example massively compromised needed client competitiveness, cost the client major expenditure and removed the best personnel from the workplace for a large portion of two years.  They never went live so their losses were contained.

The Bridgestone example evidences what happens when a system designed on the basis of Business Process goes live, see the reference in the Failure Catalogue.  Tires stacked in the parking lots, a huge warehouse rented to store stock.  Orders unfulfilled frustrated customers going elsewhere for desperately needed supplies and, it is the nature of things that once you lose a customer that way they virtually NEVER come back – so long term sustained loss of revenue and damage to profitability and competitiveness.  See the Failure Catalogue for further indication of the things that are happening.

Business process is NOT the only culprit, it is but ONE component of consistently ineffective and unreliable methods and incompetent practitioners associated with a massive lack of accountability and questionable ethics.

There is a huge need for statutory regulation of the industry and licensing of practitioners.


Conclusion

Having hesitated to stick my neck out for over ten years I have concluded that to all intents and purposes business process related activities on business information system projects, an area in which I believe I can justly claim some expertise, is irrelevant, distracting and dangerous and should be avoided.

My next article, “What to do INSTEAD of Business Process” discusses the approach that I advocate to achieving high value practical system outcomes.

Should you be battling with a business process orientated project and needing to understand where you are and how the project can be turned around please email me or call me to discuss how I can be of assistance.


Dr James A Robertson PrEng

Download Business Process – irrelevant, distracting and dangerous -- White Paper in Adobe pdf format


The Business Process Myth in the context of Bridgestone versus IBM

A major contributor to the Bridgestone failure appears to be the fact that the project was Business Process focused.

In this context the project name “Order to Cash” speaks volumes.

This was clearly a “Business Process” orientated project.

How do I know that?

Firstly the whole industry does it that way.

Secondly “Order to Cash” is a classic example of the nonsensical gobbledegook that Business Process proponents use to describe things.

“Order to Cash” is a substitute for -- order processing, works orders, warehousing, logistics, invoicing, credit control, …, or whatever Bridgestone exactly DID commission.

Wikipedia states “Business process management (BPM) is a management discipline that focuses on improving corporate performance by managing and optimising a company's business processes”.

The problem with “Business Process” is that most of the time it is NOT a “process” – a process is a sequential step wise flow of activities.  Most of business is NOT that way, yes there IS a progression from receiving an order to delivering the goods and receiving payment.  However, on a moment by moment basis it does NOT proceed in a sequential stepwise manner.

There are some people taking orders, some people making product, some people warehousing product, some people picking product, some people despatching product, some people generating invoices, some people following up overdue accounts and some people doing bank reconciliations, etc.

Each of these groups or individuals does their piece of work repetitively and reactively as phone calls and emails come in or people arrive at trade counters, as works orders come through in response to sales orders, as picking orders come through in response to sales orders, as trucks to particular destinations are filled or despatch deadlines are reached, as …, as ..., as…

Stuff happens and well trained staff keep things running.

Are there elements of process in places?

Yes, sometimes.

But the “order to cash process”?

What nonsense!

Then, to compound things expensive highly educated consultants come in and sit with client personnel and instead of listening, taking lots of notes and asking questions directed at gaining understanding – remember that the initial part of an engagement is, at least in theory, about the consultants learning how the business operates.  Remember that the staff KNOW how it works.

Instead the majority of consultants and certainly the GREAT majority of business process consultants almost immediately dive into drawing “Business Process Maps”, “Flow Charts”, etc.

In fact, the deception is so great that many of them insist on getting client personnel to learn how to draw these meaningless diagrams.  So, instead of client personnel quickly and succinctly explaining how the business works they are forced at best to digest and make sense of diagrams that make no sense and, at worst, they are forced to learn a techniques and do work that is entirely VALUELESS to them or their employer.  And then the consultants have the gall to CHARGE for this!

And, IF the consultant actually does the drawing themselves, they are so busy with their brown paper or their flip chart or their white board or their Visio or their proprietary software that they are only listening with half an ear and MISS half of what they are told.  Sometimes the miss is so severe that it only surfaces when the consultant presents a variation order because they were “NOT told about this” at which the personnel they imposed their arcane method on are either no longer there or are so intimidated that they do not argue.

Take a look at a typical business process map or flow chart of some component of an organization that you sort of understand.



What do you find?

There is MASSIVE real business complexity that is NOT reflected anywhere on the diagram because each block on the diagram needs anything from half an A4 page to MANY pages of text to fully describe it.  Yet the diagram has taken hours or days to prepare and forms the basis of the project documentation and all the work that follows.

And, because everybody does it and NOBODY really OWNS what is happening the people in the client organization who are ORDERED to sign this meaningless childish scribble do so for fear of seeming stupid!  Note that “sign-off” is one of those meaningless IT activities.

IF you want the signature to mean anything it MUST be associated with a TOUGH certificate which takes the form of “I the undersigned John Citizen do hereby certify that this process map fully and accurately represents my business function at a level of detail such that I am ENTIRELY satisfied that IBM (or other consultant) FULLY understand my function such that they will be able to design and implement systems that will work in my area”.

Try putting that in front of your average business representative and see if they sign it.

Going beyond that, there is a LIMIT to how much detail is accurately required about this thing they call the “as is”.

After all, we are ACTUALLY supposedly creating a NEW and better end state – that is the ONLY way we can justify the huge expenditure.

Yes, consultants DO need to understand the basics of the business and they DO need to know who is going to work with the system but, beyond that, how much detail is REALLY required?

Interestingly, NOT a lot.

The client personnel live all their lives in the “as is” so, provided the consultants CONSULT which most of the time they do NOT, mostly they storm along on their own mission and arrogantly DICTATE the solution they have decided that the client needs, the knowledge of the “as is” is always at hand.

The absurdity of the level of detail that many business information systems consultants insist on acquiring about the “as is” and getting paid for is highlighted by the following metaphor.



We are putting in a new road with a high level bridge over the gorge because the rough and winding track down one side of the gorge and up the other is slow and inefficient, so we survey the old road in minute detail even though it will simply be a tourist route once the new highway is commissioned!

 
 
There is a different and BETTER way and is discussed in some detail in my paper “The Power of an Executive with a Blank Sheet of Paper”.

Bring in a very experienced, very mature, executive level Strategic Solution Architect and starting with the Chief Executive have them DESCRIBE their vision of the future.  How they want the business to run when the new system is up and running.

Take off the blinkers of “as is” and focus on a practical and viable future state.  The business people know the present and its constraints and inefficiencies, facilitate them to take a view of an improved future state facilitated by someone who has the depth of experience and maturity to curb the vision when it runs away because people DO get carried away at times.  BUT focus on a high value future state and then go away and figure out how to get there.

This is NO different to the architect for a major new prestige office building sitting down with the CEO of the client company to understand their vision for the office of the future and going away to come back a few days later with sketches of concept designs.



If the architect forced the client to learn how to draw and make their own drawings the client would throw them out immediately.  Yet clients fall for this with Business Systems Consultants all the time.

The concept of a blank sheet of paper, informed by a pragmatic commercial view of what exists, which can ONLY be delivered by the top team initially, is THE way to go.

See also my article “Business Process -- Irrelevant, Distracting and Dangerous” for further discussion.

Using Business Process Mapping techniques to describe the desired future state of the business is so far off the mark that it hardly warrants comment.  Look at the arch bridge above – do you think that the engineers who designed that bridge studied expected traffic flow over the bridge to design it?  NO of course they did not!

The things that matter are the software functionality on a module by module basis correlated business function by business function coupled with the configuration of the system and particularly the validation data and master classification lists, see my article “The Alternative to Business Process – the RIGHT Approach” for a discussion of the correct approach.

Fundamentally, what is required is:

a.       Discovery of the strategic essence of the business – why it exists and HOW it thrives;

b.      High level functional definition of the components of the business;

c.       Definition of the key functional elements from a strategic essence perspective;

d.      Relate this to typical software modules available in the market place;

e.      High level specification of system requirements on a module by module basis;

f.        Tough procurement as discussed above;

g.       Determine what capabilities are to be delivered with standard software, what requires customization and what requires custom development;

h.      Detailed development of a comprehensive suite of representative configuration and master data -- determined by strategic essence;

i.         Specify and build software as required;

j.        Configure;

k.       Test, refine, test, finalize, accept;

l.         Laboratory program as discussed below including management prescribe workflow (aka process);

m.    Deploy and commission;

n.      Operate.

There is much on my website relating to this approach.

It is probable that IF Bridgestone had followed this approach there would have been MUCH less custom development.

This approach focuses attention in terms of deliverables on the two things that ALWAYS remain at the end of the project, the software and the configuration.  The Business Simulation Laboratory, described below, provides the mechanism to integrate this into the business and ensure that people are fully trained – the third component that remains.  The procurement approach should ensure that a rigorous project method that enforces the above points is followed.

068 - Discovery -- An Essential Element of SOA Implementation

Service Orientated Architecture Conference  -- June 2008

The importance of effective discovery and the issues that arise from inaccurate discovery including understanding the importance of communication in the first hour of engagement

 

EFFECTIVE DISCOVERY IS ESSENTIAL


As I work with clients seeking to achieve maximum value from their investment in business information systems I regularly encounter situations where considerable dedicated work has been done, yet is producing a sub-optimal or entirely inappropriate solution.  I have come to realize that the essence of discovery -- the process of understanding the business and its requirement -- is a fundamental art that is little understood and frequently incorrectly conducted -- this article discusses this aspect of achieving successful project outcomes.

 

Introduction

As discussed in a previous newsletter Strategy is "the essence of why the organization exists and how it thrives".

The essence of why an organization exists and how it thrives (strategy) is fundamental in undertaking ANY project that is intended to add value to the organization.

If the essence of why an organization exists is NOT understood, any number of actions may be taken which will at best not add value to the organization and at worst will damage or even destroy the organization.

If a project is to create real, sustainable value the project team must understand how the organization thrives and how to support the organization to thrive.  An organization that is thriving will be delivering exceptional value to its customers and will be delivering bottom line return.

In order for a project to contribute to an organization thriving, that project must be conceptualized with a clear understanding of what is required for the organization to thrive, that is, the essence of the strategy of the organization.

Strategy, the essence of how an organization thrives, is generally defined intuitively by the people who give birth to an organization and is frequently imbibed by like minded individuals who join the organization as it grows.

Many "strategic planning" processes fail to accurately identify and document the strategy of the organization in the manner defined above and many processes undertake an intellectual process rather than unlocking the essence of the strategy which is an intuitive, cognitive understanding.

Most I.T. projects are undertaken without the strategy being explicitly or even implicitly defined and therefore frequently end up cutting across the objectives of the organization.  The worst case scenario is typified by the lead consultant on a project that was going nowhere and giving rise to great client frustration who, when asked for the essence of why the business existed and how it thrived replied "that is an unfair question".

While this may be an extreme response, it is my regular experience that consultants and implementers have NOT accurately determined the essence of the business and how the project they are engaged in is intended to help the business to thrive and as a consequence they undertake all sorts of activities which are at best NOT essential and at worst highly destructive.

When a consultant or implementer understands the essence of the business and how it thrives they are able to formulate solutions that support the business in its endeavours.

In order to do this they need to DISCOVER this information at the outset of their engagement in order to chart a course that will create real sustainable value.

In doing this they may well discover that the project in question is NOT really necessary.  70% of I.T. projects fail outright and one of the major reasons for this is that many should never have been started in the first place!

In the sections that follow I will outline some points that are vital to understanding the importance of discovery -- discovery of the business by the external service providers AND discovery of the technical / methodological approach of the service provider by the business -- both are critical.

I hope that you will find this information useful.

 

1. Client: "I told you!  This is ridiculous!  How can you tell me this is NOT in your quote?!"

I regularly encounter situations where the client is intensely frustrated because the consultant or implementer tables a "Variation Order" for something that the client considers fundamental.

The client holds that the item is an essential part of the business and that the implementer should have realized that the item concerned was a requirement.

The implementer, on the other hand, considers the item to be a change in scope.

Frequently the dispute relates to something that the client holds they expressly stated at the first meeting with the implementer or the principals of the implementer.  Generally these people are no longer actively involved in the project.

In other cases the client did not think to mention the item because it was so obvious to them that it did not seem necessary to mention it, let alone to state it explicitly in writing.

The bottom line is that the service provider did NOT adequately DISCOVER the business and its requirement.

Frequently this means that they did not ask the right questions of the right person at the right time AND then communicate an accurate rendition of the answers to all members of their team.

Frequently external service providers allocate executives with excellent strategic insight to the marketing phase of the project.  These people demonstrate intuitive insight into the client's business and requirement and it is on the strength of this insight that the contract is awarded.

However, in many cases, these same executives seem to miss the point that their insight is critical.  Often they seem not to realize that their more junior staff do not have the knowledge, experience and intuition to gain the insight themselves and therefore they do NOT capture this insight in formal project documentation.

In a similar manner, frequently client executives participate in the initial discussions leading to the decision to appoint a particular service provider and they, in turn, fail to document what they understand as critical.

The result is an initial "meeting of minds" at an executive level that is NOT communicated to the operational staff on either side with the result that the project team heads off on the basis of a technical understanding that is disconnected from understanding why the client organization exists and how the project is intended to support it to thrive.

Sometimes the situation is compounded by hungry service providers in an intensely competitive environment where some would argue that somewhere there are competitors who are "less ethical than we are" and thus it is "not practical" to do the job properly.  The reality is that it is ALWAYS cheaper to do the job properly first time round.

I have increasingly come to conclude that while this situation results to some degree from a lack of ethics it primarily results from a lack of appreciation for the criticality of effective discovery and the impact that such discovery has on project outcomes.  This, in turn, is a reflection of a lack of maturity of the software industry.

By lack of maturity I am NOT suggesting lack of experience, I AM suggesting a need for an approach which results in higher levels of accountability.

My frame of reference for this is the engineering related industry as a whole and the construction of architect designed buildings in particular.  In the business of architect designed buildings there are typically four distinct groups of players -- the client, the architects, the engineers and the contractors.

Generally the three external roles are played by at least three distinct organizations and, in practice, each of these three distinct functions may be performed by a number of specialist firms within each area.

This results in a large architect designed building, such as an office tower, being executed by a project team in which there are distinct roles AND distinct tensions.

a. The client concentrates on obtaining the best possible, most aesthetic and most functional building for the best price.

b. The architect concentrates on aesthetics and usability.

c. The engineer concentrates on structural safety and reliability.

d. The construction contractor focuses on getting the job done to the agreed standards at the agreed price in the agreed timeframe and relies on a very detailed estimating and costing approach, frequently arbitrated by independent third party "quantity surveyors" to ensure that they get paid for what they do in a manner that enables them to work profitably.

The business software industry at this stage lacks these distinct roles or anything approximating them and relies frequently on a single firm to perform all functions ranging from the discovery and documentation of the strategic requirement through to the execution of the project to successful business outcome.

This situation is compounded by the reality that the client is, in fact, the prime contractor on an I.T. or strategy project -- such projects are about the business changing itself -- accordingly the ownership of the change process rests with the client.

All of these factors have a significant bearing, however, in the remainder of this document I will concentrate on "discovery", the first step in the journey for each of the role players -- ensuring that all role players are on the same road headed in the same direction.

 

2. Service Provider: "The client keeps changing the requirement!"  They 'signed off' on this!"

The flip side of the above situation is frustration on the part of the implementer / developer / consultant because there were documents tabled and agreed to that defined the scope of the project and now, as the project proceeds, they are told that there are requirements which they consider to be "out of scope" and which the client insists they should have known.

The reality in many of these situation is that BOTH parties are, to a point, correct.  Key issues were omitted from documents because the client did not explicitly think about them, they "just know" that these things are important.

On the other hand the external service provider did NOT ask about the subject because they were NOT aware of it.  The net result is that the two parties talk about the business with drastically different understanding.

This is often compounded by either or both parties allocating staff to the overall management of the project who are not senior enough to have the full picture of what is really important.

The CEO's on both sides hold that their people are competent and that the project can be delegated and do not recognize the importance of a meeting of minds at a strategic level.

In reality the executives on both sides need to invest time in ensuring that they see the same picture of the business AND the technology -- the service provider needs to devote time to discovering and documenting the essence of the business and how the business proposes to use the investment to thrive.  In the process it needs to be sober about the capabilities of its product and services to deliver the expected "thrive" outcome.

30% of I.T. projects fail because of mythology, the tendency of human beings to ascribe superhuman or human characteristics to computer systems or to expect computer systems to do things that only human beings can do.

Part of discovery on the part of the service provider is to ensure that there REALLY is a business case for the proposed investment AND that they can clearly see how this will be achieved AND that the role of the client in achieving this outcome IS explicitly documented.

The reality is that this is seldom done and thus the changing requirement is generally a reflection of the service provider's staff better understanding the business OR the client's staff better understanding the technology and proposed solution OR both.

A vital part of this ongoing discovery process is to prototype the solution with the software as soon as possible so that the business can start to get an understanding of what the service provider THINKS they have understood.

At a more fundamental level, the absence of an understanding of the essence of the business AND what it is that the client expects the investment to do in order to assist the organization to thrive results in the service provider's personnel doing things which are entirely inappropriate and often counter productive.

This is compounded by lack of understanding on the part of the client which results in the client stipulating requirements that they think they need based on a generally incomplete understanding of the technology.  The net effect is that both parties talk past each other.

 

3. The tension of talking past each other

In previous newsletters I have written about techniques of strategic analysis that translate unstructured thoughts into structured lists comprising a limited number (preferably about seven) of concise headline points which are then weighted in terms of relative importance.

I have also written about the extent to which a group of people who have been in the organization for years will see the problem and the solution differently.

I find the metaphor of climbing a mountain to be useful -- the same mountain looks completely different depending on which point of the compass one approaches it from and the experience of climbing the same mountain can range from a comfortable stroll to a vertical ascent that requires special equipment and special techniques by highly trained athletes or which may require a helicopter.

This diversity of view increases dramatically when one introduces two or more teams of people who have never previously worked together developing a solution for a business that one or more of the parties have never experienced before.

In considering this statement, one of the critical things that I have observed is the trap of "same industry" -- implementer and client alike hold that because the implementer has experience with the same software in the same industry that they "know" how to implement the software in the client business.

While at one level this IS correct, at another level it is entirely incorrect.

Two client organizations can deliver essentially the same product or service to apparently the same clients using apparently the same methods and yet be fundamentally different.

For example, I once did work for a bulk chemical manufacturer whose key differentiator was that they produced their product on a custom recipe basis to order and on credit.  Their order takers were technical specialists who used proprietary technology and method to analyse the client requirement and determine the exact mixture of components to produce an optimal outcome.  Their competitors produced standard recipes to stock.

Thus, while the mundane day to day content looked the same there were essential elements of content that were unique and the nature of the processes was different.  It is a fundamentally different thing to produce a custom recipe (that no other customer will use) on credit compared with producing a limited number of standard recipes to stock.  In the first case the credit granting process is a bottleneck process in the entire manufacturing process, in the second case credit granting is incidental to manufacture, there are a number of other critical differences.

The implementers of this solution failed to take account of the "manufacture to recipe on credit" essential driver of the business with the result that after three years the client found themselves loaded with a hugely inefficient and very expensive solution that they were seriously considering scrapping.  Diagnosing the gap together with the actions necessary to close the gap averted a very expensive abandonment of a system that was basically sound.

I regularly encounter situations like this, fundamental strategic misfit between the solution that is being implemented and the business.  In extreme cases this has resulted in projects being abandoned and in other cases diagnosing these factors has resulted in a rapid turnaround of the project to achieve the desired project outcome.

In all cases the situations have been characterized by significant to high levels of tension between the parties as they constantly talk past each other with regard to the critical issues.

 

4. The FIRST HOUR -- the things that seem obvious and are therefore NOT documented

Over the years I have come to conclude that in any engagement the first hour is the most important.

In the first hour of interaction the client will state things which seem so obvious to them that they may never mention them again unless expressly asked to comment.

The service provider may likewise make statements about their product or solution that seem so obvious that they never mention them again.

Many of the problems that I encounter could have been avoided if both parties had communicated more precisely during the first hour of their interaction AND documented the essence of what they said.

This requires particularly that the service provider listens attentively and asks questions directed at gaining concise insight into the essential issues AND takes notes which are converted to a reference document for use by members of the project team going forward.

Asking the question "what is the essential reason the organization exists and how does it thrive?" may well be the most important part of the whole project.  Answering the question clearly and concisely follows a close second.

Having for many years sought to understand the essence of the strategy of client organizations I have used various methods to seek to understand the core strategic drivers of the business.

At one stage I directly asked the executives I interviewed what the strategy of their organization was and, to my surprise, repeatedly found that I could NOT obtain a concise and consistent answer and in some cases even got a considered "don't really know" type of response.

In time this lead me to the question "what is the essence of why the organization exists and how does it thrive" which I have found to be more useful.

Nevertheless it is STILL vital to probe AND to listen attentively.

 

5. Are You (Service Provider) listening?

I have found that asking a few key questions, such as the "essence and thrive" question, saying very little and taking copious handwritten notes is a fundamental prerequisite for gaining insight into the real reasons for a project and whether the project is potentially viable.

I have heard it said that verbal communication is 80% listening and I was recently told that verbal communication was about 5% talking and the rest listening and non-verbal communication (body language, tone of voice, etc).

Frequently the client has NOT specifically thought about these key issues and it takes time for them to unpack the intuitive reasoning behind the project.  Attentive listening is vital.

In the process the listener should be analysing the information presented by the client and seeking to identify the things that the client is NOT saying because they seem so obvious as not to need saying.

As mentioned above, strategy in the early years of an organization is intuitive, as are the reasons for undertaking the project.

In the book "How to Win Friends and Influence People" Dale Carnegie cites an example of someone listening "intently" and being "genuinely interested" and states that this is one of the highest compliments it is possible to pay anyone.

Many times service providers need to move from sales mode to listening mode AND record what they hear.  A sales person who listens and accurately reflects back what they have heard and then FAILS to record that information and pass it on to their operational colleagues is doing their organization a huge disservice and could potentially result in a situation that costs their organization or their client a huge amount.

The service provider should constantly test the assumptions they are making and ask themselves what they do NOT know that they do NOT know -- because, if you don't know what you don't know then you don't know what you don't know and when you don't know what you don't know then you don't know what you don't know and then you CANNOT provide a relevant and valuable solution.

Then again, is the client listening?

Clients are also guilty of NOT listening or not taking notes -- service providers also provide information which client representatives do NOT fully understand and do NOT seek clarification of, making the assumption that what they think they heard is in fact what the service provider intended to communicate.

In this context one of the roles that I find myself playing is as a translator between the two parties, listening carefully and feeding back where I think that they have missed one another thereby facilitating greater clarity.

There is a great need for this role as a standard component of any significant I.T. project.

 

6. Are You (Client) accurately stating the essentials of your business and your requirement?

For the client it is critical to accurately state the essentials of the business and the essentials of the requirement.

In order to do this the client must think carefully and critically about what these are AND document them in a concise and easy to understand manner that facilitates the service provider accurately assessing the requirement and specifying the solution.

In doing this it is important for the client to realize that the solution is a BUSINESS outcome and NOT a technology outcome.  Clients who focus on the technology as being the solution are likely to miss the point and thereby contribute to a failed or sub-optimal business outcome.

The client should concentrate on the business outcome, what the business is going to do differently that will create new sustainable value and how the business will use the proposed new technology to assist the PEOPLE in the business to unlock this value.

In considering this question the business should ask what assumptions it is making and what they do not know and then seek to clarify these issues with the service provider.

As long as the business specification is technical, then it is NOT a business specification -- requirements like "easy to use" or "user friendly" are NOT business requirements, they are what Professor Malcolm McDonald refers to as "motherhood and apple pie".  The most user friendly software is the software that operators have been using for the last few years and are thoroughly conversant with and have mastery of.

What IS relevant is the essence of why the business exists, how it thrives and how it expects to use the software investment to support it in thriving.

If this is concisely documented then the possibility of the service provider producing an outcome that adds real business value is significantly enhanced.

 

7. Only PEOPLE effectively using technology deliver value

In previous articles I have made the point that technology and methodology do NOT deliver value, it is PEOPLE effectively using technology and methodology that deliver value.

A pen is inert and without value, except as an ornament, until it is held by a person who knows how to write.  If that person has wisdom and insight to share then the writing can be of great value and, by extension, the pen gains value.  Yet, if the wisdom shared is truly valuable it matters not whether the pen used was a cheap pencil or the most expensive hand crafted gold pen available.

Computer systems are just like pens, a simple system effectively used by well trained craftsmen (operators) is far more valuable than the most expensive system used by poorly trained and poorly motivated users.

Accordingly, discovery must focus on what people do in the business and what they will do differently to create sustainable value in the organization.

 

Conclusion -- Effective Discovery is Essential

Discovery is the essence of a successful I.T. project.

Discover the essence of why the organization exists and how it thrives AND the essence of how it will PRACTICALLY apply the proposed investment to deliver sustainable value and that will enable you to start the journey down the right road and stay on the right road.

Discover the essence of what the technology can do and how to apply it effectively and this will support the business outcome.

However, the essence of the solution lies with strategic insight and interpretation of that insight and business actions by business people effectively applying technology with quality content also designed with strategic insight and interpretation.

If you would like to discuss your I.T. issues and obtain advisory input on how to manage them please do not hesitate to contact me.

I would welcome the opportunity to advise any organization that is in pain or dissatisfied with regard to information technology as to the steps necessary to overcome failure and achieve success.

I offer a concise I.T. diagnostic "pulse measurement" investigation to establish the causes of sub-optimal I.T. performance and recommend specific actions to achieve success and also offer advisory services with regard to the implementation of these recommendations.

The essence of all advisory and other services is on assisting clients to achieve high value sustainable outcomes that assist the organization to thrive.




Download Discovery -- An Essential Element of SOA Implementation -- Slides in Adobe pdf format

Download Companion Article -- Effective Discovery is Essential in Adobe pdf format




Random Selection of Articles by Dr James Robertson

TxM 100 Taxonomy Manual Part 1: Introduction, Problem Statement, Definitions and Examples

An overview of the history of the approach and statement of the problem in terms of major deficiencies in high quality management information together with definitions and examples
Std 004 Procurement - 00a Approach and Instructions for Completion

Overview of the procurement approach and instructions for completing the tender document pack
SNw 023 What is computer software? REALLY? and ERP? And what determines the sustainability and maintainability of business software?

Many people have mistaken ideas regarding what constitutes computer software.  This article seeks to provide understanding
Std 024 The ART of Strategic Business Information System Project Leadership

The general tendency is to think in terms of Project Management for business information systems projects and the reality of many business information systems Project Managers is that they are administrators rather than strategic leaders.  This article discusses the role of the Strategic Business Information Systems Project Leader as effectively an interim executive who reports directly to the Chief Executive and acts as an advisor, agent and proxy for the CEO in managing the entire integrated business information systems project to achieve a high value business outcome

Prd 043 Strategic Guidance and Advisory Services

Overview of the full range of services that are offered by James A Robertson and Associates
Cnf 070 South Africa -- Engineering to Thrive

The application of the principles that I have developed and successfully applied in the business information systems and IT arena to the broader technology arena in South Africa with regard to the challenges being faced in the South African economy with a view to developing an initiative to turn the economy around from a technical perspective

Dr James A Robertson PrEng

Business Systems NOT delivering?

Call the Business Systems Specialist

Dr. James Robinson

Dr James A Robertson -- has been involved in the effective application of Business Information Systems, including but NOT limited to ERP, since 1987 and in the profitable and effective use of computers in Business since 1981.

Drawing on a diversity of experience, including formal military training in Quick Attack techniques at the Regimental Commander level, Dr Robertson has developed highly effective methods of investigating any sub-optimal Business Information Systems situation -- be it an established system or a stalled project or any other source of Executive frustration -- quickly and concisely diagnosing the root cause of the problem and prescribing concise practical actions that Business Executives can effectively act on see the Pulse Measurement page and also the Sample Reports page for redacted real reports.

He has also developed highly effective methods of strategically enriching systems to unlock the full potential of existing investments, see the Precision Configuration page and couples this to architecting small pieces of clever software that harness the full potential of your investment, see the Software page.

If you are having problems with your systems, your project or your IT Department, call The Business Systems Specialist
James@James-A-Robertson-and-Associates.com

Business System Failure is RIFE -- we offer insight into why this happens AND WHAT is required to prevent it.

Failure is at epidemic levels with massive damage done to client companies -- if you are NOT aware of the extent of the problem please visit the About Failure page for a catalog of major failures running to billions of Pounds and Dollars.

All evidence indicates that the established players do NOT know how to deliver stable, reliable high value solutions that WORK.

There HAS to be a better way!

This website provides information relating to that way with a large collection of white papers, presentations, standards documents, etc that you can use to start bringing the situation under control

We also offer high level advisory services with regard to the application of the principles advocated on this website

We offer an ENGINEERING APPROACH to addressing these issues

Click here to read more about the Engineering Approach

By Engineering I mean the formal, structured, highly disciplined, highly systematic, highly practical approach that consistently delivers results in ALL areas of human endeavor where formally trained and certified engineers are the ONLY practitioners permitted to operate -- think large buildings, factories, motor vehicles, aircraft -- highly complex systems that work at a level that we take it for granted that they WILL work and where failure is all but unthinkable and, when it happens, attracts immediate public attention and rigorous investigation directed at ensuring that such failures are prevented in the future -- in fact, everything that the management consulting industry that implements complex software systems is NOT

This approach is discussed further on the Engineering Approach page.

Search Articles

Search


Random Selection of Articles by Dr James Robertson

Book -- The Critical Factors for Information Technology Investment Success

In 2003 I undertook an in-depth analysis of all the information and experience that I had gathered with regard to the factors giving rise to Business Information System failure including ERP and general IT and classified this information into a number of categories including "The Factors Causing Failure" and "The Critical Factors for Success" based on this I developed a two day Course "The Critical Factors for Information Technology Investment Success" which is still offered today.

Based on this I wrote the book of the same name, which is available in electronic form here for download:

Subscribe to our Newsletter

Click here to send us an email subscribing to our free newsletter -- all articles posted by James Robertson will be emailed to you

Detailed information about James Robertson on LinkedIn

James has a very detailed profile on LinkedIn should you require further information about him.

You can also connect with him on LinkedIn at http://www.linkedin.com/in/DrJamesARobertsonERPDoctor

James has an open networking profile -- click on "Connect" and use email address James@LinkedIn-at-JARA.com.

Contact Us

You can contact us on

Email: James@James-A-Robertson-and-Associates.com

LinkedIn at http://www.linkedin.com/in/drjamesarobertsonerpdoctor

Facebook at https://www.facebook.com/james.a.robertson.393

Mobile: +44 (0) 776-862-2875

Landline: +44 (0) 207-059-0007

Fax: +44 (0) 844 774 4580

Articles by James A Robertson and Associates

There is a large body of white papers, articles and other content produced by Dr James Robertson available on this website

Please click here to visit the detailed listing of articles

Articles Issued by James A Robertson and Associates -- Article Categories



ArticleTagCloud for Articles Published by James A Robertson and Associates

7 steps to FIX your ERP      80:20 regarding software replacement      aborted projects      abstract      abstractness      accounting      actionable      adjudication      Advantage Data Transformer      advisory      agreement      all possible classifications      all reports      all software elements required      all spreadsheets      all tasks required to execute the project      Alpha Omega      analysis of data      analytics      animation      answers to the questions we have NOT yet thought to ask      Armscor      arrogant ignorance      art of strategic business information system project leadership      ASCO      attendance register      attorney      audit      audit cost reduction      bankrupt organizations      basis for achieving alignment      basis of payment      basis of pricing      better way      bid adjudication      bid adjudication score sheet      bid compliance      bid compliance checklist      bill of materials      bill of services      BIS      BIS failure      BIS success      boots in the mud      BPM      BPM dangerous      BPM distracting      BPM ineffective      brainstorming      break it until it does NOT break anymore      break it until it will NOT break any more      budget      budgeting      business engagement      business executives      business improvement      business information system      business information system failure      business information system success      business information system taxonomies      business information systems      business information systems procurement      business information systems projects      business integration      business intelligence      business intelligence models      business knowledge and experience      business participation      business process      business process mapping      business requirements focused      business requirements specification      business simulation laboratory      business systems      business systems laboratory      business understanding      by the book      care      case studies      case study      CEO      CEO -- project leader communication      CEO as custodian      CEO definite views      certificates      challenges      challenging presentations      change facilitation      change for strategic reasons      chart of accounts      classification schemes      clever software      client changing scope      client compact      clinical codes      coaching      Cobol      COBOL CAN be retained      Cobol still viable      code schemes      coding conventions and standards      cognitive span      collapse      communication      competitive advantage      competitive advantage through precision configuration      competitiveness      compiler      complexity      compliance      compliance checklist      comprehensive testing      Compuware      conference speaking      conferences      confidentiality      configuration      consultant NOT delivering what required      contract      contract certificates      contract law      contracting      contractors      corporate planning      cost      cost-quality-time      CPT 4      CPT4      critical factors      critical factors for IT investment success      critical factors for success      critical factors for technology success      critical human foundation      critical issues      critical issues analysis      critical requirements      CRM Risk Control      cubic business model      custom development      custom software      customer focused      data      data content      data engineering      data entities      data warehouse      DB2      definitions      design against failure      design and development      design for success      determination of strategic essence      determining strategy      diagnostic code      diamonds in the dust      differentiated      differentiation      diffusion of innovations      discovery      dislike of failure      dispute resolution      do NOT change systems because of alleged software redundancy      do things competitors could NOT do      document pack      Dr James A Robertson      Dr James A Robertson PrEng      dramatic benefits      dramatically improved strategic management information      driver of success      Dunning-Kruger effect      ease of use      economic collapse      economics      effective communication      effectiveness      efficiencies      efficiency      efficient filing of emails      eliminate light bidders      email      engineer against failure      engineered data      engineering      engineering approach      engineering approach to strategy      engineering failure      engineering laboratory      engineering services      engineering solution design      engineering techniques      enhance differentiators      enhance the differentiators      enhancing the value of your present investment      ensuring project success      enterprise resource planning      ERP      ERP configuration      ERP failure      ERP procurement      ERP success      ERP taxonomies      ERP value      essence IS different      essence of business      essence of the business and how it thrives      ethics      examples      exceptionally bad code design      executive briefing      executive briefings      executive custody      executive decision support      executive engagement      executive forum      executive frustration      expose hidden agendas      facilitation      factors causing failure      factors causing IT investment failure      factors causing technology failure      factors to manage for success      failure      failure to address soft issues      fashion      file table of contents      Financial Information System      financial information systems      financial management      fixing your ERP      focus for projects      folder design      foundation for delivery      full training      functional entities      future      Gantt Chart      gap analysis      general ledger      George Paton      go-live      go-live certificate      governance      governance = care      governance failure      group consolidation      Group Consolidation Chart of Accounts      growth      gut feel factors      hand holding      harshest judge of governance      hate failure      head count reduction      health management software      hierarchies      high level requirements      high road      high value      high value implementations      high value solutions      high value systems implementation      highly effective chart of accounts      holistic view of solution      how do you achieve executive custody      how the organization differentiates itself      how to      how to do it      huge opportunity      human foundation      hype      Hyperion      IBIS      ICD 10      ICD10      importance of executive custody      improved management information      in-box rules      incremental enhancement of existing systems      ineffectiveness      inefficiency      information required from third party suppliers      information technology      information technology failure      Information Technology Strategy      information technology success      Informix      in-house courses      innovative software solutions      innovator      inside head of CEO      insightful      instructions      intangible      integrated business information system      integrated view of business      integrity      intelligent data      interactive training material      interview      invitation to bid      isolated CEO = explosion      IT      IT and strategy      IT Audit      IT failure      IT governance      IT lies      IT management      IT mythology      IT non-performance      IT people who lie      IT personnel socialization      IT procurement      IT projects that fail      IT strategy      IT systems      IT systems procurement      IT the harshest judge of governance      James Robertson      Jof Nelson      key performance indicators      Kirsten Speer      knowledge management      laboratory      lack of an engineering approach      lack of precision configuration      lack of strategic alignment      lawyer      leadership      legal agreement      legislation      lies      list of required software      listen carefully      litigation      logical entities      loss information      low road      loyalty      MacDonald      maintain code schemes      maintenance      maintenance management      Malcolm McDonald      management      management information      managing contractors      manual      marketing hype      master data      master data classifications      master test data      mature facilitation      mature facilitator      measurable      measures of alignment      mentoring      Microsoft Outlook      misrepresentation      missing link      mistique      morals      Munich      mystique      mythology      new future state      New South Africa      no drill down      non-disclosure      NOT classic project management      obsolete is a fashion statement      obsolete software      old software IS viable      once software works it always works      on-line seminars      opportunities      opportunity to turn the economy around      organizing Microsoft Outlook      orientation of IT staff      own business experience      passion to enable clients to thrive      people are part of the system      personality matrix      planning      platform for a tough contract      precisio      precision      precision configuration      precision configuration advisory      precision configuration leadership      precision data      precision taxonomies      Predictive Index      preparatory steps      prescribed table of contents      presentation technique      presentations      preventing failure      preventing falure      preventing project failure      pricing      principles      problem statement      procedure code      process      processor ignorant of language      procurement      procurement timeline      professional speaker      Professional Speakers Association of Southern Africa      profitability      programming languages are for the programmer      project facilitation      project leader      project leader -- CEO communication      project leadership      project management      project management IT project management      projects      prove it works      PSASA      psychology      psychometrics      public conferences      public presentations      public speaking      Pulse Measurement      quality      REAL issues in Business Information Systems      REAL value      recognizing failure      redaction      reduced audit costs      reduced head count      reference documents      Reg Barry      regulatory body      relationship Almighty      relationship orientated      remediation of existing systems      Rennies Group      reports      reports not reliable      request for proposal      requirements specification      results orientated      RFP      rigorous process      rigorous strategic planning      risk management      Robert Priebatsch      robust business information systems procurement      robust business systems procurement      robust contracts      robust procurement      robust solutions      SAICE      SAP ABAP is similar to COBOL      scheduling procurement      scientific professional      score sheet      screen design      seminars      SEPT      service orientated      Service Orientated Architecture      simple techniques to enhance business information systems value      simulation      sloppy configuration      SOA      socialization      software      software assets      software design      software does NOT wear out      software is instructions for the bricklayer      software schedule      software specification      software specification standards      solution experience      solution knowledge      South Africa      South African Institution of Civil Engineering      speaking      Spirit Led      standards      strategic      strategic advisory      strategic alignment      strategic analysis      strategic analysis and design      strategic business improvement      strategic custom development      strategic definition      strategic discovery      strategic driver      strategic engineered precision configuration      strategic engineered precision taxonomies      strategic essence      strategic financial information      strategic gap analysis      strategic governance      strategic information      strategic management      strategic management information      strategic plan      strategic planning      strategic project leader      strategic snapshots      strategic software      strategic solution architect advisory      strategic solution architect leadership      strategic solution architecture      strategically designed chart of accounts      strategy      strategy defined      strategy focused planning      Strategy Snapshot Toolset      StratGap      StratSnap      strengthen differentiators      structured analysis      structured chart of accounts      substantial management information      succeed by engineering against failure      success      successful deployment      survive      system knowledge and experience      table of contents      tailored presentations      take notes      taxonomies      taxonomy      taxonomy software      technology      technology failure      technology issues      technology management      tender document pack      tender pack      tender pack table of contents      test data      testing      The Critical Factors for Information Technology Investment Success      the Critical Factors for Success      the essence of the business      the essence of the business and how it thrives      the essence of the organization and how it thrives      the factors causing failure      the first hour      The REAL Issues in Business Information System success      third party suppliers      third world countries      thrive      time      tipping point      tough certificates      tough contract management      tough contracts      tough procurement      tough terms      training      training material      treatment code      understanding of data      understanding the engineering approach      Uniface      unlocking value      use different languages for new components      V3 Consulting Engineers      validation data      value      versus process      video      webinars      weighted factors      what is executive custody      what is strategy      what is the essence of this organization and how does it thrive      what to do      where is IT going      why executive custody is required      why the organization exists and how it thrives      why your business information system is NOT delivering and HOW to FIX it      why your ERP is NOT delivering and how to fix it      workflow      writer     

Table of Contents

Home

About Dr James A Robertson PrEng -- The Business Systems Doctor -- and Other Topics

Catalogue of Major Business Information System Failures

About the Engineering Approach

James Robertson's Value Add

Attributes of a HIGH VALUE solution

Recognizing Business System Failure

The Critical Human Foundation

Old Software IS Viable

From South Africa

Competencies of Dr James A Robertson PrEng

About Professor Malcolm McDonald

Table of Contents

About my relationship with the Almighty Creator, Yah the Eternally Self-Existing

Comments relating to the Business Systems Industry and other topics

Testimonials and other positive material regarding James Robertson

Reference Articles

List of Articles

Article Catalogue

Achieving High Value Business Information System outcomes

Executive Custody -- What is it and HOW do you get it?

The REAL Issues in Integrated Business Information System Success

Part 1: Introduction

Part 2 -- Mythology and Lack of Executive Custody

Part 3 – Strategic Alignment and Precision Configuration

Why your ERP is NOT delivering and HOW to FIX it

IT Project Management

Pulse Measurement

CEO Anthony Lee Comments on his experience of the Pulse Measurement

No Charge Guarantee on the Pulse Measurement Service

Examples of Pulse Measurement Outcomes

Critical questions regarding the Pulse Measurement™

The Pulse Measurement Workflow

The Critical Factors for Business System (ERP+) Investment Success in the Pulse Measurement

Indicative Pulse Measurement Durations

What is a JAR&A Pulse Measurement?

Survival of the fittest – why it makes sense to measure the pulse of your business

Examples of Pulse Measurement Outcomes over 24 years

Sample Pulse Measurement Reports

Strategy

Strategic Essence: The Missing Link in Business Information Systems

Strategic Essence: Overview

Strategic Essence: Part 1 -- Strategy Defined

Strategic Essence: Part 2 -- Differentiation

Strategic Essence: Part 3 -- The Essence IS Different

Strategic Essence: Part 4 -- The Essence should be the Point of Departure

Strategic Essence: Part 5 -- Discovering Strategic Essence

Strategy -- the Essence of the Business: What is it and how do you develop actionable strategic plans?

Simple Steps to Increase the Strategic Value of your ERP Investment

Free Strategic Snapshot Toolset and Manual

A strategy focused planning system beyond traditional budgeting

Tough IT and ERP Procurement and Contracting that Works

Robust Business Systems Procurement

Part 1 -- Introduction

Part 2 -- Bill of Services, Laboratory, Go-live Certificate, etc

Part 3 -- Executive Engagement, Bid Compliance, Adjudication and other matters

Procurement Documents

Guidance and Advisory Services

The Art of Project Leadership

Why Regular Communication with the CEO is Vital

The Business Simulation Laboratory

Precision Configuration and Strategic Business Information Architecture

Precision Configuration based on Strategic Engineered Precision Taxonomies

The JAR&A Cubic Business Model

Highly Structured Strategic Chart of Accounts -- a Vital Element of your Corporate Information Arsenal

The Product Catalogue -- an Essential Element of any Precision Configuration

Attributes -- answers to the questions you have NOT yet thought to ask

Case Studies of Notably Successful Projects with high value Precision Configuration

092 Doing things differently and better -- ASCO Case Study 2-- BPM Summit 2013

088 Strategic ERP Invesment -- ASCO Case Study -- Service Management Conference and Exhibition Africa

026 Information Architecture and Design of FIS for Rennies Group -- Financial Information Systems Conf

018 CRM Risk Control: Designing and Implementing an Integrated Risk Mgmt Sys -- Integrated Risk Mgmt Conf

011 V3 Consulting Eng: Benefits of MIS to Professional Practice -- SAICE 15th Ann Conf on Computers in Civil Eng

Strategically Enriching your Business Information Systems

Part 1 -- Introduction

Part 2 -- Principles of Data Engineering

Part 3 -- Steps in applying these recommendations

Simple Steps to increase the strategic information value yield from your Business Systems Investment

The Full JAR&A Taxonomy Manual

Part 1: Introduction, Problem Statement, Definitions and Examples

Part 2: Why Use JAR&A, Required Knowledge and Experience, Cubic Business Model and Chart of Accounts and Taxonomy Software

Part 3: How to do it, Case Studies and White Papers and other References

Example General Ledger Manual

Business Process -- Irrelevant, Distracting and Dangerous

The RIGHT Approach

Custom Strategic Software Design and Oversight of Construction

Standards for Custom Software Specification

What IS Software?

IT Effectiveness

Organizing Outlook

Critical Factors for I.T. Success

A Moral and Ethical Dilemma -- Systems that Fail

Case Studies examining Business Information System failures

The BBC Digital Media Initiative Debacle

The Bridgestone -- IBM Conflict

Speaking and Training

Showcase of Conference Presentations

Most Viewed Presentations

Briefings and Seminars

Why your ERP/BIS is NOT delivering and HOW to FIX it

ERP and IT Procurement that Delivers Results

The Critical Factors for IT and ERP Investment Success

Other Seminars

Conferences and Public Presentations

Conferences 80 to 99 -- 2009 to Present

Conferences 60 to 79 -- 2005 to 2009

Conferences 40 to 59 -- 1996 to 2005

Conferences 20 to 39 -- 1994 to 1996

Conferences 01 to 19 -- 1989 to 1994

On-Line Seminars (Webinars)

Webinar on Preparing and Presenting Webinars

Contacting James A Robertson and Associates Limited