What you need to know about system or solution model implementations


How many times have we heard that we already have the model of the system, and we just have to copy it and all we do is “localize” or “adapt” it to our environment, and that’s all good; all documentation is ready and the implementation methodology is tried and tested? It’s that simple.

But sometimes, even though the rules were followed, the boxes were all checked and we did exactly what we were asked to do, why in the Go-Live solution it seems like no one knows what to do and things aren’t working as well as we thought?

In short, what happened is simple: we are dealing with people, and people often don’t like to read the manual or follow the rules.

Culture, environment, time zones, and personalities affect how an implementation model is deployed.

Don’t you find that in discovery workshops, it is the person who speaks most often and with confidence whose words seem to be accepted as the correct one?

A model acts with that kind of confidence. It can force management and a decision-making process to overlook the small, important details.

We are normally faced with a full template directive presented on an attractive spreadsheet with a column to capture feedback during the requirements collection phases. Unfortunately, although we have all bought into the idea of ​​adopting the model, in many cases, in reality, real or important requirements are overlooked. Often times we won’t speak at this point because we believe they should be covered by the model at some point, and we think maybe now is not the time to increase the requirement.

I remember one case where we were dictating a model direction that required a certain type of barcode, and throughout requirements, unit testing, and integration testing, that type of barcode was always assumed. be supported by the business, only to find out on the go that the barcode was not used at any point in the business process. But at no point during the gathering of requirements did anyone raise this issue. We all trusted the model and assumed it was covered.

It is also important to note that when it comes to warehouse environments or areas where all physical inventory needs to move between locations, the physical layout of the facility can be very different from where the model has been conceived. Some processes may require additional delivery documents or system confirmation steps to confirm inventory movement. The model, however, assumes that the warehouse areas are close to each other so that additional critical checks are missed and (unless the designed system is tested in a real environment) this aspect will never be detected before commissioning. Make sure the right people attend requirements gathering meetings (normally business people who work with the stock) and ask very detailed questions.

Managing warehouses and environments where physical inventory movements take place at a case or pallet level require many more physical and system steps than other areas where every transaction or movement does not require to be controlled. When a system or solution has to control every movement of a package and every step of the process, the controls and mechanism become much more complex and to a much lower level than model or accelerator solutions can handle. Don’t overlook small movements that may seem insignificant and ask detailed questions as often as possible.

In addition, some template processes that are not required are included in the design. When defining the scope, everyone would prefer the process to be included even if it is never used, just in case it is needed. We have always said that if the process happens once it has to be designed, but it is important to determine if the process ever happens. In many cases, models can over-design a solution, wasting valuable consultation time on processes that will never be used. Be practical and honest about processes that will never be used, and keep the processes as simple as possible.

The methodologies for implementing the models are also accompanied by a fair amount of documentation. It is necessary to complete sprint progress documents, then sprint transfer documents, then data load sheets, and finally the signing of the design documents. It all takes a considerable consultation time away from the design and build quality. Templates can lead to documentation overload; We find that although model documentation speeds up the format and generation of documentation, in many cases most of the content must be tailored to the specific implementation due to localized naming conventions and requirements. Allow sufficient time to update critical documents.

In the end, the best solutions are tested solutions and tests that are 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 testing for every model implementation; model project plans do not always take into account the time for these tests.

In summary, yes, models are good SAP implementation accelerators, but with the very important caveat that they should not stifle real demands, quality build time, and opportunities for improvement.

For more information, contact: [email protected]


Comments are closed.