A critical analysis of the the Bridgestone - IBM Dispute

This article, which is in course of preparation will analyze in some depth key observations with regard to Bridgestone's dispute with IBM with regard to the catastrophic failure of a comprehensive Business Information Systems project that caused Bridgestone to suffer massive losses, they are claiming US$600 million from IBM see IBM Rips Into Bridgestone Over $600 Million Lawsuit for a report on the case

It is planned that this article will provide an in-depth analysis of the situation applying the methods advocated on this website in order to highlight measures that executives can take to prevent their organizations being damaged by similar situations

<<< PREVIOUS SUB-SECTION:  the BBC Digital Media Initiative Debacle

NEXT SECTION:  Professional Speaking and Training >>>

NEXT SUB-SECTION:  Showcase of Conference Presentations >>>


Bridgestone versus IBM -- The REAL Issues

Executive Summary

Bridgestone are suing IBM for $600 million following a catastrophic systems implementation failure that did huge damage to the business, unable to process orders, stock piling up, losing customers, … the business information systems nightmare of every CEO.

This article examines the REAL reasons these things happen and how to prevent them by analysing the key elements of the Bridgestone – IBM situation and explaining how to prevent them occurring in your project.

Issues discussed include the viability of old software, valid governance for projects of this nature, the need for a tough and robust procurement approach and resulting contract, the Business Process myth and why the Business Process approach is dangerous, the need for a rigorous “engineering” approach, the critical need for a Business Simulation Laboratory, the benefits of tough certificates and the non-negotiable need to provide a roll-back capability in the event of disaster.

It is concluded that both parties made mistakes, that the mistakes are common place and, in reality, part of the established order and that there is a need for a radically different approach – this approach is outlined in the article.


Introduction

Bridgestone sues IBM for $600 million after suffering massive damages – tires stacked in the parking lot, hiring a third party warehouse to store stock, unable to fulfil orders, lost customers – THE business information systems nightmare of any CEO.

http://www.businessinsider.com/bridgestone-sues-ibm-for-600m-2013-11

The system cost over $75 million and went live in January, 2012. It immediately experienced "system-wide failures" for three months, Bridgestone alleges:

"Tires which should have been delivered to fill customer orders … piled up in distribution centres, smaller warehouses, and trailers parked in parking lots. Ultimately, [Bridgestone] was forced to lease an enormous amount [of] public warehouse space at great expense."

The complaint also says:

“IBM’s defective system lost or deleted scheduled customer orders, would not process orders, duplicated, or partially processed orders and, for those limited orders that were processed, did not complete critical corresponding business applications.”

But IBM says the problems were caused by Bridgestone. The company failed to do its part so that IBM could build the system on time and on budget. IBM sent this statement to the Tennessean:

Google “Bridgestone sues IBM for $600 million” in quotes so you get an exact match – 4,560 results!

This is big news.

It MIGHT be THE event that redefines the business information systems in the way that dramatic construction engineering failures a century earlier redefined the construction industry .

Why do these things happen?

Fact is that failure is rife – see my “Failure Catalogue”, failure that involves mainstream firms like Bridgestone, BMW, The BBC, etc as clients and IBM, Deloitte, EDS, etc as service providers.

In fact the indications are that the failures are getting bigger, more frequent and more damaging.

There is NO real indication that anyone has an answer to THE CRITICAL QUESTION “how do we prevent our organization getting hit by such a catastrophic event?”

This article seeks to answer that question from a very different point of view – a point of view that I term “the engineering approach”.

Before you ask what an engineer has to do with an industry that is the preserve of accountants and MBA graduates I ask you to note that ALL significant engineering structures are designed using computer based systems that are far more complex than business information systems and which are required to operate at exceptionally high levels of reliability.  Engineering MORE than accounting drove the creation of high performance computers over the last fifty years.

 

Failure is rife

Fundamentally, failure has been rife for decades but the big implementers and the NOT so big implementers continue to focus on getting better and better at what they are doing seemingly oblivious to the principle that “if you do what you have always done you will get what you have always got”.


A DIFFERENT approach

This article seeks to present a DRASTICALLY different, and I contend, BETTER way of looking at this sort of situation directed at enabling you, as an executive of a company faced with the prospect of replacing your systems, or sitting with a project that is failing or a system that is under performing, to take DIFFERENT decisions to your counterparts in Bridgestone, BMW, The BBC, etc.

I have been investigating failures and sub-optimal outcomes of business information system projects since 1989, speaking about the reasons they happen since 1992 and learned a large amount to the point where I am now in a position to actively publish what I have learned after undergoing an intense and lengthy process of discovery, inquiry, analysis, practical application and refinement.

Following are the points that stand out for me about the Bridgestone situation:

 

1.  COBOL – NOT a valid reason

The project commenced with a fundamentally unsound supposedly technical motivation, existing systems were written in COBOL, COBOL was “obsolete” and therefore needed to be replaced.

 

Note that this is a technology driven decision.

 

Reality is that in the real world there is still a huge amount of Cobol in operation and there is NO technical reason to replace it, except a CIO who is NOT prepared to invest in people and standards to maintain the software.

 

COBOL is obsolete is NEVER a valid reason to change software.

 

We have a vision for a far more advanced solution tightly optimized with the way we want the business to run in the future” (NOT Business Process Re-Engineering) – IS a valid business case IF it comes from the business AND provided the old systems are properly maintained until the new system is fully operational and stable.

 

For more discussion on why OLD systems ARE viable and also relating to COBOL please see the article “Old Software IS Viable”, there is a piece on COBOL lower down the page.

 

Note that the existing systems at Bridgestone were working fine, they worked so well that Bridgestone had tens of millions of dollars to pour into their massive new systems project and still remained in business.

 

The balance of this article is based on the assumption that you DO have a sound business case for moving to new technology and want to do this with minimum risk and maximum value add.

 

My point here is simply that Bridgestone DID have a choice to move but apparently the executive were misled.  In the same way in a properly managed environment it should NEVER occur that the business has to go-live no matter what, as happened with Bridgestone.

 

2.  Governance – the BIGGEST single cause of failure

OK, so Bridgestone decided for good or bad reasons to change.

They went with SAP because SAP is supposedly THE leading brand although a look at my Failure Catalogue has SAP occurring rather frequently.

They went with IBM because IBM is a household name and surely to be trusted – although a look at my Failure Catalogue has IBM also occurring rather frequently.

Two supposedly good reasons for the executive of Bridgestone to believe they were making a good decision – SAP and IBM!

So, what went wrong?

Well, Bridgestone had some governance problems – they are alleged to have replaced their Chief Information Officer no less than SIX TIMES in two years during the project!

Inspecting the “Bridgestone USA Executive Bios” page we find that there is NO Chief Information Officer on the Executive team.

After some digging on Google I was unable to establish who the CIO reported to but it seems clear that the Chief Information Officer was NOT really a “Chief”.

Yes, it IS so that in about 70% of cases the Chief Information Officer reports into a member of the executive team, most frequently the Chief Financial Officer – because somehow businesses mistakenly believe the CFO is better qualified to manage the systems that run the company than anyone else.

One of the reasons there is so much failure and so many sub-optimal outcomes is exactly because the CFO has NO formal training that in ANY way equips them to manage technology.

IF you are NOT prepared to have the IT Manager – a person who reports to a C level executive who reports to the Chief Executive is NOT a Chief Information Officer, they are an IT Manager and calling them a CIO does NOT make them an executive.  Sitting them at the top table with a reporting line directly to the CEO and operating on a FULL peer basis with the rest of the executive team is what determines if a manager is a CIO.

So, it seems probable that Bridgestone changed its IT Manager six times during the two year project NOT their CIO.

Thus IBM have some basis to allege lack of leadership on several fronts.

Most importantly, the so-called OTC (Order to Cash) project involved almost the entire spread of the business.  The custodian of this integrated view of the business and the ONLY person with the muscle to make decisions stick across multiple operating components of the business is the CEO.

Since the CEO does NOT have the knowledge or the time to manage a project of this size and complexity they need an advisor and Project Leader – someone to direct the project.  This needs to be a person who has done this before, a gray beard so to speak, someone at least over 50 years of age who specializes in managing this type of project on behalf of the client.  The IT Manager simply does NOT have the clout and, in all likelihood does NOT have the experience to manage something like this.

Remember that when you put in place a massive new integrated system it touches just about every part of the business, it touches just about every person in the business and, by definition, it RIPS THE GUTS out of the business and replaces them with something that is supposedly better.  The Bridgestone debacle provides graphic evidence of what happens when you rip the guts out of the business in a badly planned and badly managed project – you cannot ship product, you lose customers, you lose millions of dollars!

IF you get the picture of what can go wrong you will recognize that for ANY organization embarking on a project of this nature pretty much the FIRST thing you do is go out and find a REALLY senior, REALLY experienced expert who has done this a number of times before and knows what works and what does NOT work.  Make sure that they have rapport with the CEO, make sure that they demonstrate intuitive understanding of YOUR business and then bind them contractually for the duration and give them an open door to the CEO as an Interim Executive.

On the face of all the evidence Bridgestone did NOT do this – probably because no one told them it was necessary – probably because almost no one does it that way which is a major reason why so many projects fail or come in seriously short of expectations.

That said there was obviously something TOXICALLY WRONG with the way Bridgestone were managing their IT Manager -- remember, since he or she was NOT on the Executive Team they were NOT really CIO – that alone could be enough reason for all the resignations.  Bridgestone embarked on a massively complex and very large project and, seemingly put a lot of responsibility on this person they called CIO and then did NOT give that person the muscle and support needed to do the job.  OR did something else that made the position totally untenable.

A recipe for failure!

So, does that let IBM off the hook?

NOT from where I sit.

Given that there clearly WAS a problem, it is a key element of IBM’s defence, then IBM should have done something about it.

Something like raising a “red flag” on the project and advising the CEO that in the absence of a robust and sustainable solution to the CIO problem they would have to cease work and withdraw their team until a suitable person was put in place.  But that would have been bad for planned revenue so I am guessing that typical IT person temerity (people who are good with computers are generally NOT good with people, particularly when faced with conflict) coupled to quarterly revenue target driven greed got in the way of IBM’s integrity!

That is a major problem with the business information systems industry, for the most part it is driven by people who are in the game for the money and NOT for the passion of exceptional solutions delivered to high quality standards that meet or exceed client expectations and come in on time and on budget.  The folk who are turned on by good solutions generally do NOT make it to the top.  So, if your fundamental commercial driver is NOT aligned with a quality outcome you will make technically BAD mistakes.  It seems that IBM did this.

After all, it seems they were working with an IT person who was punching below IBM’s weight and Bridgestone, according to their pleadings, was counting on IBM to provide the wisdom and maturity necessary to deliver the required outcome.  Problem is that in this case IBM were, seemingly both the main player AND the referee, because there was NO in-house referee of any substance, they changed on average every four months and you CANNOT learn about the business or the project in four months let alone manage a major player like IBM. 

Not to mention deal with whatever ugly governance toxicity caused all your predecessors to leave!

So, YES Bridgestone were at fault and NO that does NOT exonerate IBM – they should have intervened one way or another to stabilize the situation.  Perhaps they were cutting costs and deploying light weights on their side too?  Bridgestone allege they were.

The lesson for your organization

a. Make the CEO responsible – see my material on Executive Custody for guidance;

b. Appoint a highly experienced expert to run the project on behalf of the client and have that person report VERY closely to the CEO in an Interim Executive capacity with a VERY tough mandate to act on behalf of the CEO and a strong contract for the duration of the project – see my article on “The Art of Project Leadership” for some suggestions;

c.  and … see the sections that follow.

 

3.  Procurement – securing a robust, tough and enforceable contract

From the fact that Bridgestone are litigating against IBM one has to conclude that the contract was shaky.  In fact, if one reads the full pleading document it is apparent that whatever contract existed did NOT have teeth.

One of the reasons that the construction industry consistently produces high quality deliverables is that the construction industry makes use of well-established tough contracts that provide all the basis necessary for legal action against the contractor in the event of failure or sub-optimal outcomes.  So litigation is seldom required.

Signing the contractors contract, as it appears that Bridgestone did, after all everyone does it, is the first step in a journey to a sub-optimal outcome.  Having that contract signed by an IT Manager dressed up to look like a CIO is a recipe for disaster.

Before you can sign a tough contract you must follow a tough procurement process.  From the documents it appears that IBM were appointed on a “sort of negotiated basis”, they were already there, they drew up the requirements specification and then negotiated to execute it so, in a sense, they were again judge and jury.

For procurement to lay a foundation for a successful project:

a. It is vital that the CEO has first appointed their tough interim executive Project Leader / Project Director, someone with a large amount of procurement experience;

b. It is also vital that the procurement takes place against a tough and comprehensive procurement pack;c. with at least three to five bidders;

d. with a tough multi-stage adjudication procedure;

e. resulting in a tough contract.

 See the discussion of the requirements for such a procurement approach on my website.

 Such a contract must lock the contractor into a fixed price for a clearly defined business outcome.

It must contractually bind provably competent contractor personnel individually to the project for the duration.

It must provide for detailed discovery BEFORE the price is finalized and the contract is signed so that there is NO room for “change of scope”.

There must be a comprehensive and highly detailed project plan and “Bill of Services” such that there is NO ambiguity about what the contractor quoted to do and how much they quoted for each component so that in the event that there really IS a legitimate basis for a variation order this can be managed effectively.

Please read the material on my website for more information.

 

4.  The Business Process Myth – irrelevant, distracting and DANGEROUS

Next issue.

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:

  1. Discovery of the strategic essence of the business – why it exists and HOW it thrives;
  2. High level functional definition of the components of the business;
  3. Definition of the key functional elements from a strategic essence perspective;
  4. Relate this to typical software modules available in the market place;
  5. High level specification of system requirements on a module by module basis;
  6. Tough procurement as discussed above;
  7. Determine what capabilities are to be delivered with standard software, what requires customization and what requires custom development;
  8. Detailed development of a comprehensive suite of representative configuration and master data -- determined by strategic essence;
  9. Specify and build software as required;
  10. Precision configure;
  11. Test, refine, test, finalize, accept;
  12. Laboratory program as discussed below including management prescribe workflow (aka process);
  13. Deploy and commission;
  14. 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.

 

5.  Absence of engineering rigor – sloppy projects and sloppy solutions

It is clearly apparent from the Bridgestone pleadings that IBM ran a sloppy project.  I do NOT say IBM AND Bridgestone, I say IBM – they CLAIM to be the experts.

Bridgestone in their pleadings make it clear that they appointed IBM as trusted advisors, as experts, as a leading brand in the field with a high level of confidence and trust that IBM would do right by them.

IBM failed outright and even allowed Bridgestone to go live despite acknowledging there were problems.  There is a point at which a responsible consultant stands firm and REFUSES to allow the client to go live or, at the very least requires the CEO to sign a TOUGH indemnity clause.

A HUGE problem with the business information systems industry is that it is dominated by people who are NOT engineers and who do NOT understand that failure occurs UNLESS prevented and do NOT have a focus on preventing failure.

It is fundamentally so that success is the necessary consequence of a well-conceived project NOT failing!

Every successful engineering system and structure is successful for ONE ultimate reason, because it does NOT fail!

You can be positive and use positive language and have road shows until you are exhausted but you will NOT make a bridge stand up that has a defective design element or loading conditions massively in excess of the design.

The bridge in Minneapolis depicted in the photograph failed because of a series of operating management oversights that resulted in an extreme overload condition in the centre of the bridge, a small component failed and the bridge collapsed.  The event was so extreme that it was published globally on TV and radio within minutes of the failure.

If bridges failed the way business information systems projects fail NO ONE would ever cross a bridge, in fact there would be NO bridges to cross.  In fact, if the entire engineered environment operated to the extreme standards of sloppiness that characterizes the business information systems arena we would be living in grass huts – at least they would not kill us when they collapsed!

My point?

I am advocating a level of rigour, precision, accountability, etc that is far beyond ANYTHING that occurs in the business information systems industry, see my article on “The Engineering Approach to Business Information Systems Defined” for a discussion of the characteristics of this thing that I refer to as “The Engineering Approach” – it is a culture, a way of thinking, a way of doing that is unique to people who have made it their life long goal to create things of lasting value from nothing, these people are engineers and they know that without intense rigour and discipline bridges do NOT stand up!

So, you need a Project Leader who understands these principles and you need to find a contractor who understands them as well.  And then you need to apply them rigorously and conscientiously.

 

6.       Lack of formal Business Simulation Laboratory testing

Another very obvious element of the Bridgestone complaint and IBM’s response is that there WERE known problems BEFORE going live!

 

Bridgestone respond by saying that the failures that occurred did NOT correlate with the concerns purportedly raised by IBM.

So the situation degenerates to an admission by BOTH sides at some level that there WAS a decision taken to go live knowing that at some level there were problems.

BUT IT PROJECTS ARE LIKE THAT YOU SAY?

Why?

There is NO reason for them to be.

They are a field of engineering endeavour like any other, failure is inevitable UNTIL you eliminate every possible cause of failure from the solution.

In the case of software where admittedly the solution IS complex and abstract – see my article on “The Critical Human Foundation” on the real world human complexities that have a HUGE impact on projects of this nature it is necessary to be particularly disciplined and thorough.

The problems are compounded by the lack of formal engineering training and rigour, as discussed in the previous section but that is NOT my point here.

When an engineer is designing something that requires design elements that are different and unknown they resort to the Engineering Laboratory, a place where the REAL WORLD is simulated.  It looks nothing like the real world but the structures and test equipment behave like the real world.

 

The photograph shows an engineering laboratory in which a miniature steel frame bridge built by second year engineering students using accurately scaled miniature steel structural sections is being tested to destruction using a “Gravity Load Simulator”, the three triangle heavy frame in the centre right of the picture which allows a large vertical load to be applied to the miniature bridge in such a manner that the bridge will fail in a manner that accurately models the way a full scale bridge to the same design would fail if overloaded.

Engineers are schooled with this type of exposure to failure and how to prevent it.  The bulk of the undergraduate university curriculum for engineers relates to preventing failure and the construction of large buildings and other engineering structures is ALWAYS coupled to engineering laboratories that constantly test representative samples of material to destruction in order to provide required quality control.

A Business Simulation Laboratory LOOKS different, it is a room with tables and computers and a data projector or two but the principle of its design and application is the same.  The most experienced personnel of the client organization systematically work with small quantities of carefully selected representative data to do everything possible to cause the system to fail.

The dictum is “break it until you cannot break it any more”.

ONLY once this state has been achieved can the software then be fully configured and again tested, the workflow (that is process) dictated by management and configured, the reports, models (data warehouse), alerts, etc defined, built and tested and training material developed.  The training material should preferably be interactive.

Once ALL of the above has taken place and the system / systems have been manifestly proven to be ROBUST and reliable and ALL components are working THEN and ONLY then are ALL staff brought into the laboratory environment to be trained in SIMULATED live operations.

Rigorous application of this approach and a tough stand that management at every level and particularly the CEO WILL NOT authorize commissioning until the laboratory delivers a clean bill of health is critical to preventing the sort of catastrophe that Bridgestone suffered.

Should IBM have done this?

Categorically yes!

Were they negligent that they did not?

Well, YES BUT, there are very few people in the industry who know to do this let alone know HOW to do this.

That said, IF, as they claim, IBM told Bridgestone at some level that there WERE problems and they should NOT commission and Bridgestone overruled them then it is my contention that Bridgestone may have a different case but their present case is shaky.

On the other hand if, as Bridgestone claim, IBM grossly understated the problems and led them to believe that there might be a few issues but nothing serious whereas the entire solution was allegedly riddled with problems then it would seem that Bridgestone have a strong case.  The challenge for the judge is going to lie in establishing where the truth lies relative to those two poles.

And the ANSWER is that NEITHER position is actually defendable.  Either there were issues in which case the system should NOT have been commissioned or there were NO issues in which case the system should NOT have fallen over the way it did.

Those arguing in IBM’s defense will argue that the solution was too large and too complex to test thoroughly to which I respond that in ALL fields of engineering endeavour engineers find ways to ensure that failure does NOT occur and point to the International Space Station as an extreme example.  Accordingly, I hold that with effective engineering management of a formal Business Simulation Laboratory the Bridgestone systems would NOT have been commissioned when they were.

Ultimately it comes down to whether IBM were more negligent than the industry norm and that is a difficult question!

As a whole the evidence indicates that the industry IS habitually negligent and does NOT know a better way!

As far as I am concerned there is NO alternative to the Business Simulation Laboratory and a rigorous and robust testing program managed by a tough no nonsense senior person who will brook NO arguments for compromise.

 

7.  NO certification

There is an extension to the previous point, something that, on its own might have greatly reduced the risk of going live prematurely and that is a robust and tough “Readiness to Commission Certificate” or “Go-Live Certificate”.

Once ALL staff are trained in the Laboratory, THEN the entire project team are required to progressively sign a certificate of the following form – starting with the most junior team member:

 

Certificate of Readiness to Commission

We the undersigned:

Client Team Leader  . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 

Implementer Team Leader  . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .  

In our capacities as Team Leader of the Client Laboratory Test Team and Implementer Team Leader respectively of the teams comprising ourselves together with the following team members:

 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .sign . . . . . . . . . . .

 

 

Have completed Comprehensive Laboratory Testing of the full configuration

We hereby confirm that:

1.      In issuing this certificate we are aware that premature issue of this certificate could lead to serious business damage, inconvenience and unbudgeted costs;

 

2.   The team has invested sufficient time to thoroughly and comprehensively review and test the configuration;

 

3.       The configuration has been substantively stable in the Laboratory with ongoing testing activity for not less than thirty business days;

 

4.       We are fully satisfied that all required functionality is working correctly;

 

5.    We are fully satisfied that all reports, models and dashboards are accurate and functional;

 

6.       All training material has been prepared and tested;

 

7.       All personnel have been thoroughly trained and tested and are skilled at a level that they can rapidly and accurately adjust to running the new system;


 8.     That we have assessed all possible risks in-depth and are satisfied that all measures necessary to mitigate these risks are in place with appropriate accountabilities and ownership.

We accordingly advise that it is our considered opinion that it is safe to commission the system and we advise that it is our considered opinion that  . . . . .   (Name of Implementation Company) has fully complied with their contractual obligations in delivering the required solution in the Laboratory and that the retention applicable to this stage of the project can be released and that the software can now safely be commissioned.

Sign


The certificate must then be signed by the Project Leader, the Implementer Executive Sponsor and finally the CEO of the client company BEFORE the system is commissioned

Similar certificates should be required at different stages of the project.

The value of such a certificate is that it forces people to think.

Conventional IT “sign-off” concentrates on getting a signature on a piece of paper – I have seen project managers rushing round getting people to “please sign” because it is the target date for sign-off and since the goal is to get signatures it is relatively easy to do.

Turn it around, and put a tough certificate on the table that has clear contractual significance and “sign-off” suddenly becomes orders of magnitude more difficult.

Business Information Systems and IT Generally is primarily about people, see my article on “The Human Foundation” to better understand this point.

Thus the psychology of how one manages people on these projects is of paramount importance.  The psychology of a tough certificate with wording that clearly holds the people signing accountable cannot be under estimated – it forces people to think very carefully before putting their signatures on such a document.

And THAT is EXACTLY what you want.

You do NOT want people agreeing to the system being commissioned because of ANY pressure, you want them to ONLY agree because it is SAFE to proceed.

And you want each one of them to clearly understand that they WILL be held accountable.

So signing of the certificate might involve getting all relevant team members in a room with the CEO at the head of the table with the CEO looking each person in the eye, questioning them and ENSURING their commitment to their signature BEFORE they sign.  Make it DIFFICULT TO SIGN and easy NOT to sign.

 

8.  NO roll-back plan

Beyond that note that Bridgestone did NOT have a roll-back position.  They were apparently unable to roll back to the old systems.  That is an act of gross negligence that needs to be laid equally at the door of IBM and the CIO / IT Manager.

Frequently there is NO roll-back position because someone cannot figure out how to do it – that is negligence, find someone who CAN figure out how to do it and do it.

This should be NON-NEGOTIABLE!

 

Conclusion

From the documentation there are other factors.

Consideration of my factors relating to “The REAL Issues in Business Information Systems” – the factors causing failure and the Critical Factors for Success (the subject of my book – available on the website together with the course of the same name) will give you many more pointers to what went wrong and how YOU can avoid a similar catastrophic outcome for your organization.

Remember that “if you do what you have always done you will get what you have always got”, in this case, if you do what the IT and Business Information Systems / ERP industry has been doing for the last twenty years you will get what they have been delivering for the last twenty years – expensive projects that run over time and over budget and deliver sub-standard outcomes or outright failure.

I suggest for your consideration that there IS a better way that will deliver MUCH better outcomes, see my article on “What does a HIGH VALUE Business Information System Solution look like” for more ideas.

This outcome is outcome in which every aspect of the business runs smoothly, efficiently and effectively.  The systems “flow” with the business and most activities take LESS time than they did previously.

Most importantly executives and managers have a wealth of strategic, operational and tactical management available literally at the touch of a button.  Information that is of the highest quality and entirely reliable.

Executives and managers have time to be more creative and the business is able to sustain greater production, sales, etc with existing headcount or headcount has reduced by natural attrition over a  year or two.

The business is booming, it is growing faster than it did before, new customers, new products, new services.

All of this traceable back to the new systems that have been expertly configured to EXACTLY model the real world in which the business operates such that the systems are easy to use and FLOW with the business.

This is what IBM should have delivered to IBM and failed!

Please browse my website for more information, the home page, http://www.james-a-robertson-and-associates.com will give you a good overview of what I am advocating and help you to navigate the entire site.

The Table of Contents lists all the webpages on the site, there is a lot of deep content that is NOT immediately visible.

The Article Catalogue lists well over 150 articles on diverse topics.

The Article Keyword Cloud provides alphabetic keywords linking to many of the articles

The Conference page lists around 90 conference presentations, nearly all different with around 40 of the presentations live on the site for you to view and download -- email me if there is a presentation you would like that is not on the site.

 

Pulse Measurement

I offer a concise diagnostic “Pulse Measurement” light touch, high impact investigation that in the space of a day to ten days for most organizations, depending on size and problem complexity, will deliver you a concise written report that will accurately diagnose what is wrong with your current systems OR your project OR your IT Department and prescribe meaningful and actionable treatment for the conditions I identify.

I look forward to being of assistance to you.


Dr James A Robertson PrEng



Random Selection of Articles by Dr James Robertson

SNw 046 The Real Issues in BIS: Part 2 -- Mythology and Lack of Executive Custody

Information Technology Mythology, the wide spread of marketing hype driving misrepresentation of the business information systems environment coupled with lack of integrity and other factors that result in the industry generally failing to deliver on its promises, together with Executive Custody, the ownership of integrated Business Information Systems by the CEO of the business are discussed
SNw 043 Strategically Enriching your BIS: Part 1 -- Introduction

Introduction to the principles of precision configuration and strategically enriching your business information systems
Sem 05 IBIS – The Strategic View of Business Information

A three hour Executive Briefing that outlines the most important aspects of what I advocate with regard to Integrated Business Information Systems, including ERP
Std 016 Procurement: 08 Bid Adjudication Score Sheet

The Bid Adjudication Score Sheet is a set of weighted factors designed to focus the adjudication team on those requirements that are CRITICAL to the success of the project measured in terms of Business Outcome.  Factors are determined in close consultation with the client Chief Executive and Executive Team

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

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:


Random Selection of Articles by Dr James Robertson

Cnf 068 Discovery -- An Essential Element of SOA Implementation

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
SNw 056 The Alternative to Business Process – the RIGHT Approach

Having established that business process is irrelevant, distracting in dangerous in designing and configuring business information systems, what do we put in its place?  This article discusses the progression of activities that an effective business systems specification, configuratoon, testing and deployment project should follow

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

Connect with 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