The two factors that influenced the choice were:

• the Client was an out-and-out Microsoft shop – in terms of products as well as skills available
• SAP was the ERP used by its parent company and some of its sister companies – though there was no plan for consolidation or even integration, the availability of experts in the group is seen as a plus

The following are the factors the basis of the decision:

• SAP and Oracle did not differ functionally or even in non-functional characteristics in any significant manner (Gartner, Forrester, Customers, ERP Asia, ERPFacts.com, TEC – Technology Evaluation Center)
• From ease of use perspective also (based on the product demos, the business users felt that Oracle had an advantage here), according to Gartner report and ERP forums Oracle is as difficult (or easy) as SAP.
• Oracle is found to be slightly technically superior solution – achieved by exploiting Oracle as the Database to the best possible extent. But Oracle Database skills are not available within the company and when proceeding with a major ERP implementation this could turn out to be a unnecessary risk taken.
• Oracle Fusion to be delivered in 2013 being the focus of Oracle, the product roadmap for Oracle ERP is not clear
• SAP and Microsoft have an excellent relationship as shown in the SAP benchmarks, Duet initiative etc. SAP integration with Microsoft platform is very good – and makes sense in the context of Microsoft shop that heavily uses MS Office, Outlook, Share point etc.

In the process of this decision making, collated details on SAP and associated products and sharing the same as individual blogs.

The quote “It is a capital mistake to theorize before one has data. One begins to twist facts to suit theories, instead of theories to suit facts” – Sherlock Holmes – fits in consulting context perfectly.

First Meeting / Discussion

At the first meeting the client will tend to assess what the consultant can provide and if he is competent enough to deliver. But that doesn’t mean that the solution to the client’s problem will be arrived at in this discussion (actually this should be avoided – it is not necessary to prescribe a solution immediately, though sample of similar problems faced by other clients can be quoted). Rather the emphasis should be on getting a clear understanding of the problem and its impact on the business.

We need to ask the appropriate questions – and handle the associated human aspects – to put the client at ease. It is not crucial to get the entire picture at the first meeting (shouldn’t end up as an interrogating session). If more information is required, arrange for future discussions.

It is better that you paraphrase the client’s goals and concerns to ensure mutual understanding.

During the discussion, try to arrive at some judgement on “Why the client is seeking advice?” – lack of technical expertise, lack of business experience, lack of confidence in evaluating the options, for convincing the management the validity of their solution, feels a need for independent verification, lack of staffing, lack of ability to implement the solution etc.

Also try to figure out if the client is under any time pressure, if the client is enthusiastic about the project or treats it a burden, client demeanor – Casual, formal or restrained etc.

Further Data Collection 

Breaking down the data collection to different layers lead to simplicity and completeness. The layers could be Technology Infrastructure, Data, Application, Processes and Business.

The layer(s) to be explored and in what level of detail would differ from engagement to engagement. Irrespective of the primary focus, it is essential for the consultant to understand the business context within which he operates.

 Data collection methods (in the order of least intrusive at the top of the list):

1. Review of existing documentation – reports, plans, manuals, diagrams, forms, flow-charts, system manuals etc.

2. Observation – Watching the flow of activities that make up the system can help in understanding the environment, attitude as well as the process.

3. Inventory – Counting and documenting the physical components of the IT architecture.

4. Surveys – Questionnaires to a representative sampling or entire community

5. Facilitated work sessions – Group working meetings, led by facilitator, to discuss and uncover required information about the system under review

6. Interviews – One-to-one conversations with individuals and teams.

Clients find it distracting to constantly be answering queries which could have been easily obtained from available documents or by conducting surveys. During the course of the engagement – the interaction with individuals and teams will increase – mainly for discussions, ideas generation etc.

Group sessions have benefits in terms of – participation from all concerned, discourages hidden agendas, and provides concrete action items – thereby facilitating best results.

Some tips related to facilitating such sessions are:

• Ask Questions – Use open-ended questions (e.g., why is that)?
• Try getting feedback again by asking leading questions like “Have we covered this in depth?”, “Have all the major issues brought out?”, “Does everyone agree with the goals?” etc.
• Summarize – Restate and consolidate remarks and ideas. This helps test if the understanding is right
• Inclusion – Ensure that everyone participates. Try asking the silent participants directly for their opinions.
• Listen Actively – Don’t keep interrupting. Don’t frame responses while someone is speaking.
• Record diligently – Ensure that everything is recorded (use a scribe, if possible)