Subscribe
  • Home
  • /
  • TechForum
  • /
  • What you need to know about system or solution template implementations

What you need to know about system or solution template implementations

By Peter Kerr, Founder, Argon Supply Chain Solutions

Johannesburg, 19 Oct 2021

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 “localise” or “adapt” it to our 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 sometimes, even though the rules have been followed, the boxes have all been ticked and we’ve done exactly what was asked of us, why at solution go-live does it seem 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 who speaks the most often and with confidence whose 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, true or 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.

I remember an instance where we were dictating a template direction that required a certain bar code type, and throughout the requirements, unit testing and integration testing, this bar code type was always assumed to be supported by the business, only to find at go-live that the bar code was not used at any point in the business process. But at no point did anybody during requirements gathering raise this as an issue. We all trusted the template and assumed it was covered.

It’s also important to note that when it comes to warehouse environments or areas where any physical stock must 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 business people that work with the stock) and ask very detailed questions.

Warehouse management and environments where physical stock movements take place at a case or pallet level require far more physical and system steps than other areas where each transaction or movement need not be controlled. When a system or solution 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 movements that might seem insignificant and ask detailed questions as often as possible.

Additionally, some template processes that are not required land up included 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 and keep processes as simple as possible.

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, sign-off of design documents. All this takes 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.

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.

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, contact: info@argonscs.com.

Share