Triad’s Rapid Implementation Methodology for Sage X3
TRIM – T for TIME
If one were to ask this question then 9 out of 10 respondents are likely to answer with a resounding “Yes”. Delays in implementation happen even with the most committed teams from the vendor and customer side.
The following are the most common reason for projects getting delayed:
- Business Requirement Documentation happens AFTER the PO is placed on the vendor as no vendor can afford to do a free pilot to understand the requirements in detail and no Customer wishes to pay for such services before confirming the PO.
A Catch 22 situation indeed.
The depth of clarifications sought by the customer and his perceptions of what he believes he is getting drives the expectations in the project. Some customers try to address this risk with punitive one-sided contracts leading vendors to buffer and markup their commercial offering in an effort to manage this “risk” - The process of understanding and documenting Business Requirements is one of creative engagement. The vendor identifies “experienced consultants” and the customer identifies a set of superusers who “know the business” Both teams huddle together with every good intention of nailing the requirements – a time-consuming process.
And involves deliberating and understanding what could be considered standard practices for a given business vertical. Sure there is an attempt to start with questionnaires and stick to a given structure – but as most of us know this is difficult to maintain. - Logistics of documenting what has been said or understood is done using some standards suggested by the product vendor but these standards are more focused on what needs to be parametrized in the product than to provide a document of TOBE Processes to the customer.
BRD documents are signed with Customer representatives without understanding the implications of product setup. As it becomes a contractual requirement to go forward this signoff happens without this clarity in an effort to move forward on the project
Change of project personnel – key employee moves out during the project implementation – from the customer or vendor – drops additional challenges of maintaining continuity of understanding. - So the real understanding of the deliverables starts sinking in when the Conference Room Pilot commences leading to rework, expectation management on what is included and excluded in the scope of work and consequent time delays
We looked critically at these very many steps and challenges and asked ourselves a simple question. What if we invested our effort and the collective knowledge of a vertical to document the standard solution which would cover 70 to 90% of a typical customer’s requirement. We have taken up the FMCG Distribution as the first vertical
This led us to reformat the implementation methodology and commitments made at the time of making a proposal.
- We have a detailed set of Scenarios that are typical of a FMCG Distribution entity
- We identify what is relevant to a given customer even before we give our demos
- We lock in the scope and modify the Standard Requirement Document – this forms a part of our proposal.
- We start our implementation with a workshop to identify the delta elements – specific to the customer
- This is the BRD for the customer – ready in a weeks time from the Project Kickstart
This way we nail
- Best Practices and scenarios required for a local FMCG player in the M East Distribution industry – this preliminary document is part of our proposal making the deliverables crystal clear and your choice of the vendor risk-free
- The document is in business-speak which a Sales Head or CFO will understand
- The level of detail in the document leaves less scope for perceptions that are far removed from the actual solution
- Perceptions match the reality when the time comes to do a Conference Room Pilot of the solution – less time spent in reconfiguration or “I said so” arguments
- The overall process takes less time – yours and ours – and lowers the cost of owning the solution