Too often, modules and estimated licences are sold in sales processes that end up lying idle either due to incorrect assessment or processes that have not been implemented. This means that the customer gives away money and cannot easily adjust the subscription. Nevertheless, it can make sense to examine this circumstance more closely and thus increase the return on investment or exploit the potential.
Wirtschaftswoche writes about this in its article of 27.01.2022 - https://www.wiwo.de/28012136.html - What happens to unused licences that arise in the course of an SAP software implementation?
Behind the consulting firms sits a marketing and sales machinery that is driven to strengthen and increase sales in certain areas. One may not assume it is intentional, but the "quantity" of software is often measured with a large ladle. However, this is not only up to the seller, but the buyer must also know approximately how much he needs or how much he wants.
It's like at the sausage counter: if I order too much, I either have to throw the rest away or "recycle" it as best I can.
1. Reasons for too many licences
First of all, what are the reasons for too many licences? Mostly lack of precise knowledge about the "hunger" that the client brings with him. The fact is that not all tenders are the result of preliminary projects, but are sometimes a by-product of day-to-day business and were written just like that.
But it is a fact that it is not always the actual processes that are relevant for the tender, but the target processes - and these do not have to correspond to the status quo by far. It is not an easy undertaking to set up a tender - not in addition to the daily business anyway. How often do we experience requests like "I'm supposed to find out what your software can do" from working students? This is not meant to be an affront to working students - the ones we know are top, but rather to show that the priority of such measures is not necessarily recognised and the importance is not appropriate.
It is simply right and important that methodological principles are adhered to in order to strengthen tenders and one's own statement in the direction of the provider. We all too often accompany SAP pre-projects in which so-called design thinking workshops are carried out, fit/gap analyses, i.e. actual and target are compared, requirements management is also an issue, as are critical questions from the outside as to whether everything really has to be like this, right up to early communication and change management (not necessarily only in the main project). By definition, scope management is an essential component of all projects and thus a basic prerequisite for clean specifications. The fact alone that these documents and their importance are too often pushed into the background shows that the value of tender documents is not where it needs to be.
By the way, we have also had cases where "the degree of coverage of software A,B or C was advertised" in the tender - sometimes formal errors, but at least a bad signal to the competition of the tender; by the way.
This is not meant to be a lecture, just to make clear how important the project is before the project. So if scope management is no longer part of the actual project as it used to be, then it should be set up methodically and cleanly within the framework of pre-projects. The arguments "it costs money", "we don't have anyone to do it" or "too little time" - well, we're just talking about paying twice or more in the end.
So, if I can't estimate my hunger, I take too much home with me in advance.
2. Project implementation
Once the tender has been completed and the partner for the implementation has been found to the best of our knowledge and belief, we usually move from the specifications to the requirements specification. Roughly speaking, the "objects" to be delivered are described in detail and, importantly, provided with acceptance criteria.
Now, here too, there are more parties at work, stupidly on one side, the employees in the company. They know their daily business very well and know how their applications are most likely to support it. Actually, one would have to conduct interviews with all of them and understand how the software supports the daily business (benefit case). To speed this up, project teams are usually formed, which then sit opposite the implementation partner. In the best case, at least with industry know-how and professional experience, in the worst case, neither. On the one hand a consolidated team working as advocates and on the other a team of "consultants".
This is not meant to be arrogant or pejorative, but it is the best way to grasp the problem. Communication is immensely important at all levels - it takes at least a decent amount of motivation to get things going. If we can now assume that a preliminary project has been established and the necessary processes have been clearly defined, then "only" details and corresponding criteria remain to be defined.
Now nothing should stand in the way of the successful implementation of the processes. The only breaking point remains the communication - sender / receiver stuff.
So, if I can't describe what I want to eat to the chef in the best possible way, then it won't taste good or I'll get the wrong dish. If the description was the best possible, then maybe the cook had no talent.
3. In a dilemma and then ...
Additional costs arise from the short descriptions in each case. On the one hand, we now have too many licences unused because too many users do not need the application or worse, do not use it. On the other hand, because we have bought licences for processes that were ultimately not implemented or are not usable for the users. Either way - we are giving away money or potential.
We pick up where we left off and look at how everything can be ideally "utilised" and put together to form an enjoyable meal.
This is one of the most difficult levels of entering a project where the constraints are at least yellow (budget at the end, time overrun, scope not implemented, quality rather less good). We are aware of this, but we still believe in our expertise over the years.
How we do it: Roughly speaking, we approach the steps described above in a fast-forward manner. Based on our experience from other projects, we have a good eye for the essential and important details. Since we often advise on preliminary projects, we are equally aware of the results. This gives rise to questions and concrete recommendations for action, which we introduce at the process and communication level.