Finding a clear path through appropriate prototyping and testing
As I reflect on the week that passed I think about things that I encountered that don’t make a whole lot of sense or at least challenge us to evaluate whether what we are doing works or not.
Among these is the concept of guide rails and barriers. Those of us who have ever played ten pin bowling are familiar with the rails or bumpers that you can pull up to prevent the gutter balls where the bowling ball careens off course and into the channel on either side of the bowling deck. The objective of the rails is to give the player at least half a chance of hitting a pin. They’re usually associated with novices but sometimes we put up rails in life to ensure that people follow a particular path or procedure.
Putting up bumpers to guide a process
This weekend I encountered some rails of a different kind, the kind that prevent large trucks from using narrow streets. The concrete barriers known as K-Rails or jersey barriers depending on where you are from and what industry you work in, are pretty effective however without careful layouts they can actually be more of a problem than a help depending on the circumstances. Where there are a large number of pedestrians they should have gaps at periodic intervals to allow the free passage of pedestrians.
Failure to accommodate pedestrian needs can lead to pedestrian clustering at the ends of the barrier and this can actually impair traffic operations further. We started off on a journey parallel to some barriers this weekend and at one point almost turned back when we thought that there was no easy way to cross the street. Common sense told us there should be a gap but the aspect of the barriers did not suggest where the gap might be in the barrier. Only when we moved closer to the end of the road did the gap become apparent.
Avoid over configuring the system
When I think about this in the context of guided procedures when working with SAP, the challenge is the fine balancing act between over configuring the system and making it very difficult to work with or making it so freewheeling and easy that you run the risk of having users entering garbage data.
The balance is not an easy one to find but one of the ways to get closer to the ideal is to spend more time on analysis and design and then on prototyping with real people with real data.
This is difficult with new processes or new systems but when you are rejigging an existing system this is the process that you typically red-line as process re-engineering or transformation.
I refer to the over-engineered solutions as being akin to getting stuck in the deadwood forest.
Another possibility is landing in the death valley where your systems are not keeping up with the complexity and demands of your business context and processes.
There is a clear path, a clear path for automation, not necessarily one that is always obvious.
It’s a path that hinges on understanding the dimensions and maturity of people, process and technology but also the context in which your business processes function.
For finance operations using SAP this means leveraging the skill sets that your people have along with the most commonly used tools like workflow and excel and honestly believing that your SAP ERP can be your system of record but that it is a hungry and demanding beast in terms of its data expectations.
One Winshuttle customer that I have dealt with on a regular basis has just such a problem, they have configured their system to catch every conceivable mistake that a user could make, or that they believed a user could make, however the performance of the solution is dog slow and the sheer volume of false positive error messages means that the business users have become desensitized to error and warning message inspection.
Technologists need to understand that business users ask for capabilities when the resources that they have are inadequate for the tasks that they have at hand. The business needs to understand that technology and solutions are provided for activities and initiatives that will yield either costs savings or increased revenue.
Test your assumptions
In the evaluation of an approach to finding the clear path you have to have vision and an idea of the lie of land as it is today but you also have to have some degree of trust in common sense as we did in our journey. This is not to say that you should have blind faith but rather that you should always test your assumptions as far as practically possible to determine fit and form of solutions.
If you have encountered some examples of deadwood forests I would be interested to hear more from you.
You can also follow me on twitter on winfin2