How many times have we heard that we already have the system template, and we just have to copy it, and then all we do is “localize” or “adapt” it to your environment and it’s all good, all the documentation is ready, and the implementation methodology is tried and tested……..”It’s as easy as that”?
But then very often, and even though the rules have been followed, the boxes have all been ticked, and we’ve done exactly what was asked of us, at solution go-live it seems like nobody knows what to do, and things are not running as smoothly as we thought they would?
In short, what has happened is simple: We are dealing with people, and people don’t often like to read the manual or follow rules.
Culture, environment, time zones and personalities affect the way an implementation template is deployed.
Don’t you find that in discovery workshops, it is the person that speaks the most often and with confidence who’s point seems to be accepted as the right one?
A template acts with that kind of confidence. It can force a direction and a decision-making process to overlook the small important details.
A comprehensive template guideline laid out on a great-looking spreadsheet with a column to capture comments is normally what we are faced with, during the requirements gathering phases. Unfortunately, even though we have all bought into the idea of adopting the template, in many cases, in reality, important requirements are overlooked. We often won’t speak up at that point as we feel they should be covered by the template at some stage, and we feel that this might not be the time to raise the requirement.
“Assumptions”
I remember an instance where we were dictating a template direction that required a certain barcode type and throughout the requirements, unit testing, and integration testing, this barcode type was always assumed to be supported by the business, only to find at go-live that barcode was not used at any point in the business process. At no point did anybody during requirements gathering raise this as an issue. We all trusted the template and usually we assume the detail is covered.
“Layout and People”
It is also important to note that when it comes to warehouse environments or areas where any physical stock has to move between locations, the physical layout of the facility can be so different from the one on which the template was designed. Some processes may need some extra delivery documentation or system confirmation steps to confirm the movement of stock. The template, however, assumes the warehouse areas are close together so critical additional controls are missed and (unless the designed system is tested in a real-to-life environment) this aspect will never be detected until go-live. – Make sure the right people are in the requirements gathering meetings (normally people that work with the stock) ask very detailed questions.
Templates also force the roles of people to change, this probably has the biggest impact on the business and is the most difficult to accept and change. – Align roles as early as possible and set expectations.
“It’s all in the detail”.
Warehouses and environments where physical stock movements take place at a case or pallet level require far more physical and system steps than other areas. When a system is faced with controlling every move of a parcel and every step in the process, the controls and mechanism become far more complex and at a much lower level than what template or accelerator solutions can manage. – Don’t neglect the small things, that might seem insignificant and ask detailed questions as often as possible. Templates are just a guideline not a solution.
“Manage that Scope”
Additionally, some template processes that are not required somehow land up in the design. While defining the scope everybody would rather have the process included even if it is never used just in case it is required. We have always said if the process happens once, it must be designed but it is important to figure out if the process ever happens at all. In many cases, templates can over design a solution wasting valuable consulting time on processes that will never be used. – Be practical and honest about processes that will never be used, keep processes as simple as possible.
“Documentation”.
Template implementation methodologies also come with a fair amount of documentation. There’s a need to complete sprint progress documents, then sprint handover documents, then data load sheets and finally signoff of design documents. All this takes a significant consulting time away from the design and build quality. Templates can lead to documentation overload, we find that although the template documentation does fast track the format and generation of documentation, in many cases most of the content needs to be adapted for the specific implementation due to localised naming conventions and requirements. – Cater for enough time to update critical documents.
“Test, Test, Test, Test and Test some more”
Ultimately the best solutions are tested solutions and testing that is not done in a meeting room or virtual sessions but tested in the physical warehouse with the actual stock. As a warehouse solutions implementation company, we insist on real-life testing for every template implementation, template project plans don’t always accommodate the time for these tests. – Test, Test, Test and Test some more.
In summary yes, templates are good accelerators of SAP implementations but with the very important caveat that they should not suffocate real requirements, quality build time and improvement opportunities.
For more information, email info@argonscs.com.
