Sometimes when starting a new BMC Remedy implementation project, the customer, or your boss, demands an estimation cost of licenses and maintenance. If you have a reduced number of users, you can figure the number of required licenses. But if your case is more complex, the estimation of required licenses can be a mess (or guess).
In this post, I will show you how to estimate the required number of licenses for any product (not only BMC Remedy) without historical data.
Only to estimate cost
When starting a BMC Remedy deployment, I recommend you to reduce the number of acquired licenses. Then increase them as needed while in production. When the situation is normalized, then you can regularize your licenses, buying what you really need.
For this phase, updating the number of licenses of your system, there is a tool that can improve and accelerate the analysis of required licenses, while reducing the cost to the max: RRR|License.
But, as I said on the introduction, this post is not about telling you what to buy, but to estimate the overall cost before you buy the product, and helps you to complete the business case.
How to do the estimation
There is no rule-of-thumb for estimating the required number of licenses. Each company is different and any 3:1 or 5:1 strategy is useless. Even each user is different. You can have people that are continuously using the system, and other that only connect sporadically.
So, first to assume: there is no rule-of-thumb to estimate the required number of licenses!
To do it, we need to me a bit more specific and mathematical. There exists models for estimating the use of a shared resource based on the statistics of users, like the Erlang and Engset formulas. We will base our estimation on these mathematical foundations. But this is not a direct procedure, you need to do some work.
The steps are for this approach are:
- Define key users and predefined fixed licenses
- Define the acceptable blocking ratio
- Define usage groups
- Define time-frames
- Estimate the statistics for each group/time-frame
- Consolidate statistics
- Estimate the required number of floating licenses
- Evaluate the fixed optimization
During the next points I will guide you at each step.
Predefined fixed licenses
You can identify at a first stage a number of people that you know surely that they need a fixed license. This can be because of two reasons:
- You know that the usage of these people will be continuous or very high.
- They are VIP users, and you want to guarantee the access.
Do not consider these people for the rest of the computation, they will be fixed users.
Define the acceptable blocking ration
Unless the number of acquired licenses is equal or higher than the number of potential users, there will exists a probability of blocking, that is, that a user needs a licenses when all are in use. You need to establish your requirement in terms of a probability of blocking. The lower this probability is, the higher the number of required licenses.
If you set a 1% blocking probability, then each time a user attempts to log in, there is a change between a hundred to be blocked. So you must set this value carefully. I think that an acceptable value is 0,1%, but it is a value you must set.
Define usage groups
Not everyone at your organization will have the same use of the system. You can have help desk agents that are continuously connected, and manager that connect eventually. You must divide your users population between usage groups. The members of the usage group share the same statistics. So don’t define the usage groups by the function, but for the expected usage.
For instance I could set these usage groups:
- Help Desk agents: 5 people.
- Support groups: 12 people.
- Managers: 5 people.
This is a simplified estimation. In a real case, you should consider admins, groups working on different hours, countries, …
The deeper your analysis (and number of groups), the greater the accuracy expectation.
Define time-frames
You must divide the schedule in time-frames. You don’t need to consider each day or hour separately, just to divide them in statistically compatible time-frames. My recommendation is to divide this study in two days: workday and free-day. And for each day study your different timeframes.
For instance, I could set these time-frames:
- Workday: 8:00 to 16:00
- Workday: 16:00 to 21:00
- Workday: 21:00 to 8:00
- Weekend: 0:00 to 0:00
Again, you must suit these time-frames to your case.
To reduce the amount of work you can discard the time-frames with a very reduced use of the system.
Estimate the statistics for each case
Now you must do the hard work: estimate the usage statistics for each combination of time-frame and use. That means to consider the next parameters for each combination:
- Mean number of users present.
- Mean number of connection per user made during the time-frame.
- Mean duration of session.
Here is where you are defining the behavior of your people. Each company will have different values. For Instance I could say that during the night turn of workdays, there is one support user:
- Number of users: 1
- Number of connections: 2
- Session: 2 hours
Consolidate statistics
Now, this step is mathematical. You must define the combined statistics of your groups during a time-frame. That is, to combine all the values for each usage group for a particular time-frame, and do it for all time frames. The parameters will be computed as:
- Number of users: The sum of all groups. For instance, if help desk has 3 users for an specific time-frame, and support has 10, the total is 13.
- Number of connections per user: The weighted mean. For instance if help desk has 2 connections on the time frame, and support has 4, the mean is (2*3 + 10*4)/13 = 3,53 hours.
- Session time: The weighted mean. For instance, if help desk typically connects for 4 hours, and support groups connect for 30 minutes, then (4*3 + 10*0.5)/13 =1 hour and 18 minutes.
Now you have only one statistic for your group.
NOTE: This step is not mathematically correct. The designed behavior follow a Poisson distribution, and the combination of Poisson distributions is not a Poisson distribution. But, for our interest it can be a good approximation.
Estimate the required number of floating licenses
Now, with these values you must apply the mathematical method to estimate the number of required licenses. You need to use an Erlang-C or Engset calculator. Here you have one:
License calculator
Configure the applet with these values:
- Model: Finite Source, with queue (this forces to use Engset)
- Number of potential users: The estimated number of users.
- Number of sessions/workday/users: The number of connections or log ins.
- Average duration of a session (minutes): The estimated duration.
- Duration of a work day (hours): The duration of the time-frame.
- Allowed blocking probability (%): The percent established at the second step.
For each time-frame you will obtain an minimum number of licenses. Select the time-frame with the most, and you have the number of required floating licenses (without optimizing).
Evaluate the fixed optimization
Now, you must look at the most used time-frame (the one with the most use of licenses). Consider to move users from floating to fixed. That means to change entire usage groups from fixed to floating. This could be useful when the usage ratio of a usage group is greater than the 40% inside this time-frame. The usage ratio is obtained as the used time ration (session time * connection / time-frame duration) multiplied by the users ratio (number of users at the time-frame/number of users at the group).
For instance the help desk has 5 people. At the main time-frame there are 4 users (1 is assigned to the afternoon, or holidays, …). So the users ratio is 80% (4/5). The connection time is 2 connections of 3 hours (6 hours). So the usage ratio is 75 % (6/8, being 8 hours the duration of the time frame). Multiplying both ratios we obtain, 60 %, much greater that 40%. So we will consider giving all 5 members of the help desk a fixed license.
After deciding to give fixed licenses to some people, you must repeat all the computation, extracting those people from the floating license estimation.
Conclusion
Here I presented a method to estimate the number of licenses for budgeting purposes. Also is very useful if you want to justify why you put 100 licenses in your Business case, instead of 90 or 110. But, I repeat, this is to estimate your business case, not to decide what you need. My recommendation is to buy between a half and three thirds of this number of licenses and increase it as needed.
Sometimes when starting a new BMC Remedy implementation project, the customer, or your boss, demands an estimation cost of licenses and maintenance. If you have a reduced number of users, you can figure the number of required licenses. But if your case is more complex, the estimation of required licenses can be a mess (or guess).
In this post, I will show you how to estimate the required number of licenses for any product (not only BMC Remedy) without historical data.
Only to estimate cost
When starting a BMC Remedy deployment, I recommend you to reduce the number of acquired licenses. Then increase them as needed while in production. When the situation is normalized, then you can regularize your licenses, buying what you really need.
For this phase, updating the number of licenses of your system, there is a tool that can improve and accelerate the analysis of required licenses, while reducing the cost to the max: RRR|License.
But, as I said on the introduction, this post is not about telling you what to buy, but to estimate the overall cost before you buy the product, and helps you to complete the business case.
How to do the estimation
There is no rule-of-thumb for estimating the required number of licenses. Each company is different and any 3:1 or 5:1 strategy is useless. Even each user is different. You can have people that are continuously using the system, and other that only connect sporadically.
So, first to assume: there is no rule-of-thumb to estimate the required number of licenses!
To do it, we need to me a bit more specific and mathematical. There exists models for estimating the use of a shared resource based on the statistics of users, like the Erlang and Engset formulas. We will base our estimation on these mathematical foundations. But this is not a direct procedure, you need to do some work.
The steps are for this approach are:
During the next points I will guide you at each step.
Predefined fixed licenses
You can identify at a first stage a number of people that you know surely that they need a fixed license. This can be because of two reasons:
Do not consider these people for the rest of the computation, they will be fixed users.
Define the acceptable blocking ration
Unless the number of acquired licenses is equal or higher than the number of potential users, there will exists a probability of blocking, that is, that a user needs a licenses when all are in use. You need to establish your requirement in terms of a probability of blocking. The lower this probability is, the higher the number of required licenses.
If you set a 1% blocking probability, then each time a user attempts to log in, there is a change between a hundred to be blocked. So you must set this value carefully. I think that an acceptable value is 0,1%, but it is a value you must set.
Define usage groups
Not everyone at your organization will have the same use of the system. You can have help desk agents that are continuously connected, and manager that connect eventually. You must divide your users population between usage groups. The members of the usage group share the same statistics. So don’t define the usage groups by the function, but for the expected usage.
For instance I could set these usage groups:
This is a simplified estimation. In a real case, you should consider admins, groups working on different hours, countries, …
The deeper your analysis (and number of groups), the greater the accuracy expectation.
Define time-frames
You must divide the schedule in time-frames. You don’t need to consider each day or hour separately, just to divide them in statistically compatible time-frames. My recommendation is to divide this study in two days: workday and free-day. And for each day study your different timeframes.
For instance, I could set these time-frames:
Again, you must suit these time-frames to your case.
To reduce the amount of work you can discard the time-frames with a very reduced use of the system.
Estimate the statistics for each case
Now you must do the hard work: estimate the usage statistics for each combination of time-frame and use. That means to consider the next parameters for each combination:
Here is where you are defining the behavior of your people. Each company will have different values. For Instance I could say that during the night turn of workdays, there is one support user:
Consolidate statistics
Now, this step is mathematical. You must define the combined statistics of your groups during a time-frame. That is, to combine all the values for each usage group for a particular time-frame, and do it for all time frames. The parameters will be computed as:
Now you have only one statistic for your group.
NOTE: This step is not mathematically correct. The designed behavior follow a Poisson distribution, and the combination of Poisson distributions is not a Poisson distribution. But, for our interest it can be a good approximation.
Estimate the required number of floating licenses
Now, with these values you must apply the mathematical method to estimate the number of required licenses. You need to use an Erlang-C or Engset calculator. Here you have one:
License calculator
Configure the applet with these values:
For each time-frame you will obtain an minimum number of licenses. Select the time-frame with the most, and you have the number of required floating licenses (without optimizing).
Evaluate the fixed optimization
Now, you must look at the most used time-frame (the one with the most use of licenses). Consider to move users from floating to fixed. That means to change entire usage groups from fixed to floating. This could be useful when the usage ratio of a usage group is greater than the 40% inside this time-frame. The usage ratio is obtained as the used time ration (session time * connection / time-frame duration) multiplied by the users ratio (number of users at the time-frame/number of users at the group).
For instance the help desk has 5 people. At the main time-frame there are 4 users (1 is assigned to the afternoon, or holidays, …). So the users ratio is 80% (4/5). The connection time is 2 connections of 3 hours (6 hours). So the usage ratio is 75 % (6/8, being 8 hours the duration of the time frame). Multiplying both ratios we obtain, 60 %, much greater that 40%. So we will consider giving all 5 members of the help desk a fixed license.
After deciding to give fixed licenses to some people, you must repeat all the computation, extracting those people from the floating license estimation.
Conclusion
Here I presented a method to estimate the number of licenses for budgeting purposes. Also is very useful if you want to justify why you put 100 licenses in your Business case, instead of 90 or 110. But, I repeat, this is to estimate your business case, not to decide what you need. My recommendation is to buy between a half and three thirds of this number of licenses and increase it as needed.