Secrets of the Madrid court Or the device of the main business processes of the company Ultima. Part 1
This post is conceived as the first in the series of the same name, in which we will talk about how everything inside us works.
Also here we are going to highlight some issues of internal organization that are solved in different companies in different ways (and nowhere is 100% satisfactory) and are of common interest for any business related to software development.
The following is the fruit of many years of evolution. Which, of course, is by no means complete.
')
That is why our solutions to sick issues and the technologies used are by no means positioned as the best. On the contrary, with the intention of telling our colleagues in the dangerous business about our own developments, we expect to receive constructive criticism and counter ideas, which have not occurred to us.
In the first series, we consider the organization of the business support process.
Traditionally, we first define the meanings of words.
Support - the process of evolution of the implemented ERP-solution as a result of changes in the client's business processes. Which, in turn, continuously occur under the influence of the outside world - from development plans from shareholders to changes in the competitive environment. Business analysts and developers are involved in this process from the serving partner Ultima.
The serving partner of Ultima , he is simply a partner - in fact, an organization authorized by Ultima for sales, implementations and support for its own products. If in a simple way - an analogue of 1C franchisee, and if many are bukof and in all details - then here . Further in the text we will simply use “we” and derivatives.
We are not going to further clarify who the developer is, he is a programmer, and the meaning of a business analyst’s life is to translate (as a rule) customers ’soaring dreams into a language understandable to programmers.
Looking ahead, business analyst has another critical function. But more about that in the next series.
The task is the Change Request, or a change request, or just a request. Description of what needs to be changed in the program. Requests are created by the client’s staff, if necessary, by incorporating business analysts into the process. All applications are stored and processed in the tracker.
The tracker is the Change Request Management System. In our case - a web interface for entering, viewing the status and the whole set of other operations with orders. The tracker, in turn, is part of an ERP solution that we use for our own needs. Naturally, on the Ultima Businessware platform.
Cobbler with boots, yes.
The customer is an employee of the client who created the application in the tracker.
The responsible employee is the employee of the client who has the rights to transfer applications in the tracker to work. In other words, approve the application for implementation. In practice, the client has many employees (customers) who can create applications, but only responsible employees can transfer them to work.
Labor on the implementation of applications is paid by the client according to the good old scheme Time & Material.
The total cost of the implementation of the cost of the application is equal to the product of the number of hours spent by the hourly rate.
Below we will show what the application has customizable properties and how they affect the final rate, as well as how the hours spent are fixed.
And now directly to the device business support process.
Let's go in stages.
The client employee has an idea.
Or a problem.
As soon as an idea grows to a verbalized state, a potential customer can turn to a business analyst, or, subject to some degree of preparedness and rights, proceed independently to the next stage.
In the simplest case, the completed customer creates an application in the tracker, describes the task in it (the text can flow from a business analyst, whose work is paid by the hour) for the developer and sends it to work.
Each application has three properties that significantly affect its processing and final cost, namely:
In addition, the application has an error sign (error or not), and can store a link to the “parent” application.
Let us consider in more detail each of them.
The priority of the application, as is easy to guess from the name, affects its speed of execution.
Priority - a set of three options:
Applications with critical priority are executed at any time of the day or night, the response time is determined in the SLA (usually, during working hours - up to 15 minutes, during non-working - up to an hour).
Normal and urgent applications are executed only during business hours, urgent ahead of normal.
The presence of the application of increasing priority means the presence of increasing tariff coefficient to the base cost of an hour.
Ultima certified developer for commercial use qualifies in three levels:
Note in brackets that the internal grade system is somewhat more complicated, and will be covered in a separate text.
When creating an application, the customer chooses from the same three options, while Developer - by default. It also corresponds to the base cost of an hour.
Junior - reduction factor, Senior - raising.
Juniors are used for the simplest tasks such as editing a form or correcting a report. Seniors - for large-scale change projects.
Going into details, I note that the customer can not only set the level of a specialist, but also indicate a specific specialist. In general, the hourly rate will be changed according to the level of the specialist. However, if a particular specialist is in excess demand, according to the laws of the market it is possible for him to introduce an additional incremental factor separately (he also has a positive effect on income)
It is worth paying special attention to the fact that in tasks that are more difficult than complete triviality, it may well be that using a senior for a client will be cheaper than a junior - because he spends so fewer hours that, despite the higher rate, the total will be less.
Our pricing technology is based on the principle of actual hours spent fixed by the programmer in the time-keeping subsystem — not budgeting, according to preliminary estimates, by a specially trained person.
As a result, the extra hours are probably added to the small things, but this is exactly the case when the damage from the struggle with the problem is much more than from the problem itself.
Again, the customer chooses from three options:
The boundaries between the values ​​of volume / complexity are very vague, and, frankly, are almost completely subjective.
The characteristic volume / complexity of the task is used in the mechanism of automatic dispatching of tasks between the pool of programmers.
When the robot chooses which developer to assign the newly fallen task, it is repelled by the principle of uniform loading (all other things being equal). The duration of the task queue for execution for each developer is predicted precisely on the basis of their complexity and the average statistics for the execution time of tasks of this category that is usual in statistics.
It is clear that for each individual task, the error can be several times, but the whole line - the results of the predictions are quite acceptable.
Here it is. As a result, the application was created, the parameters were selected by the customer, and then it falls into automatic dispatching in the warm soulless paws of the same robot, which was discussed in the previous paragraph.
2. Application dispatching
So, the warm check robot determines the performer independently.
Critical tasks are handled in a special way.
When a request appears with a critical priority at any time of the day, on weekends and holidays, the robot looks for a performer - any suitable level (if no specific performer is indicated) who is not busy with other critical requests.
To do this, use a system with minimal changes identical to that previously described in one of our cases , so we will not repeat.
When receiving a critical task, the executor stops working on the current task (if at all the working time).
Urgent and ordinary applications are processed only during business hours.
We can assume that each developer has 3 task queues (by priorities).
Tasks come to work only after the queue with the highest priority is exhausted; the developer must disassemble all urgent tasks before receiving the task with the usual priority.
Going into details, I note that applications with an error mark and a reference to the parent application are processed as critical applications. The executor in such an application is taken from the parent application. Applications without reference to the parent are distributed along with the usual tasks.
Otherwise, the distribution of all tasks is arranged in the same way - all developers are selected, with a sufficient level of qualification, and from them the performer with the smallest forecast date for completing the task is selected.
It is worth noting that the developers themselves form their working calendar indicating when and how they work - i.e. every day indicate what time they will work.
The electronic time sheet is used to ensure that the robot (and humanoid administrators, if necessary) know what resources they have at each time point.
A task with a chosen Junior Developer level can be obtained by any developer if his turn is shorter. To evaluate the queue, the scale of the task is used. This, of course, is an estimate from above, but it is better to live up to expectations than to give unjustified promises.
Thus, all tasks in the queue have a forecast date of execution, respectively, and a new task that appears at the tail of the queue receives its forecast date for the completion of work automatically.
Keeping the forecast dates for submission of applications by the developer has a positive effect on income (in more detail about the developer motivation formula - in the next series).
Thus, the developer is interested that the application would receive a real deadline and, in turn, upon receipt of a new task and the existence of objective arguments about an error in estimating the estimated date of completion, may ask the manager to postpone the date to a later date.
As a result, each task is immediately assigned a responsible person who is interested in meeting the deadlines for the execution of the task. In turn, the customer is interested in specifying the most accurate parameters of the application, because he sees that the deadlines are met.
The developer in the tracker interface at any time can see the queue of his tasks (more precisely, 3 queues - by priority), which application is assigned to him at the moment, there are notifications about new tasks. Having done the necessary work, the developer makes the time spent on the application. If the task takes more than one day, it enters data on the time spent every day.
The task of the developer is to do what he is asked to do in the application.
Often (especially if the application is placed without the help of an analyst), the developer can suggest some or other improvements on the application (acting in a certain sense in the role of analyst).
It is very pleasant and useful to clients, therefore it is encouraged in our company. The developer himself is trying to rise above the technical details of the implementation and look at the task from a slightly different angle, maybe even through the eyes of the customer.
If a developer succeeds, he has a great chance of becoming a business analyst.
To help the developer, integration tests, control checklists (a list of what the developer should check to avoid messing up), verification mechanisms in the platform, etc.
Finished - well done.
The completed task is passed to testing.
According to our approach to the organization of internal processes (“not to accept, not to create, not to transfer a marriage”), the application should be executed and passed to testing without errors.
We do not have testers.
So, the programmer is (financially) responsible for the quality of the application.
An additional incentive to make fewer errors is a) the fact that they are corrected by the programmer for free and b) the presence of uncorrected errors blocks the ability to work on other tasks - you cannot charge watches and receive new applications.
Actually at this stage there are applications with an error sign and a link to the parent. You cannot return the task to work - just create a new application.
In the end - the guy, you had a lot of time to check everything before putting it to the customer, nobody rushed. If you were too lazy to check it yourself, others worked for you.
If the customer agrees to accept the application, he marks it as accepted. In this case, the system offers him to evaluate the work on the application on the following scale:
- Do not climb into any gate (2)
- through the stump-deck, but won (3)
- good, though not without rough edges (4)
- brilliantly, it is impossible to wish for the best (5)
When setting the estimate, the customer sees a slider with text options, can set the slider to an intermediate position.
For an assessment of 5, the developer will receive a premium, for an assessment of less than 4, they will be deprived. 2 - disassembly.
It happens that tasks hang in testing and are not processed on the client side.
When it took an indecently large scale for one of the clients (well, it was just too lazy to go to customers and close the application, the functionality itself was already available) made a limit on the simultaneous number of applications in testing.
If the limit is exceeded, the customer cannot send new tasks to work.
Another problem from practice is that customers are sometimes embarrassed to give bad marks to developers. Even with real jambs. In this case, the situation looks good in terms of statistics, but dissatisfaction is accumulating.
Moreover, the overall mood of the client is affected (sometimes more than anything else) by the work of analysts.
Therefore, quarterly Ultima partner center conducts a survey of customers on the topic of integrated assessment of the level of satisfaction with cooperation. I will quote the questionnaire from the support article on our website :
A
Using the Ultima solution has a clear positive effect on the company's operating performance. Ultima service partner consultants display high business competence and regularly offer effective solutions to optimize business processes, leading to higher profits and / or reduced costs.
B
It is difficult to unambiguously separate the positive contribution of the Ultima solution from the action of other factors, but we are undoubtedly satisfied with both the results of the software operation and the cooperation with the Ultima service partner.
C
ERP-system Ultima implemented and working.
No other significant achievements were noted.
D
We were deceived. In practice, nothing to do with what you promise on your site.
Actually, this is how the support business process is arranged. Confused, slurred? Sorry, the first experience, ask clarifying questions in the comments.
In the following series:
Programmer motivation. The role of business analysts and their motivation. The ideology of the approach to the implementation of Ultima. Letters from readers.
The author thanks Ultima Consulting for their invaluable assistance, both in the actual construction of the company's business processes and in the creation of this series.
Also here we are going to highlight some issues of internal organization that are solved in different companies in different ways (and nowhere is 100% satisfactory) and are of common interest for any business related to software development.
The following is the fruit of many years of evolution. Which, of course, is by no means complete.
')
That is why our solutions to sick issues and the technologies used are by no means positioned as the best. On the contrary, with the intention of telling our colleagues in the dangerous business about our own developments, we expect to receive constructive criticism and counter ideas, which have not occurred to us.
In the first series, we consider the organization of the business support process.
Traditionally, we first define the meanings of words.
Support - the process of evolution of the implemented ERP-solution as a result of changes in the client's business processes. Which, in turn, continuously occur under the influence of the outside world - from development plans from shareholders to changes in the competitive environment. Business analysts and developers are involved in this process from the serving partner Ultima.
The serving partner of Ultima , he is simply a partner - in fact, an organization authorized by Ultima for sales, implementations and support for its own products. If in a simple way - an analogue of 1C franchisee, and if many are bukof and in all details - then here . Further in the text we will simply use “we” and derivatives.
We are not going to further clarify who the developer is, he is a programmer, and the meaning of a business analyst’s life is to translate (as a rule) customers ’soaring dreams into a language understandable to programmers.
Looking ahead, business analyst has another critical function. But more about that in the next series.
The task is the Change Request, or a change request, or just a request. Description of what needs to be changed in the program. Requests are created by the client’s staff, if necessary, by incorporating business analysts into the process. All applications are stored and processed in the tracker.
The tracker is the Change Request Management System. In our case - a web interface for entering, viewing the status and the whole set of other operations with orders. The tracker, in turn, is part of an ERP solution that we use for our own needs. Naturally, on the Ultima Businessware platform.
Cobbler with boots, yes.
The customer is an employee of the client who created the application in the tracker.
The responsible employee is the employee of the client who has the rights to transfer applications in the tracker to work. In other words, approve the application for implementation. In practice, the client has many employees (customers) who can create applications, but only responsible employees can transfer them to work.
Labor on the implementation of applications is paid by the client according to the good old scheme Time & Material.
The total cost of the implementation of the cost of the application is equal to the product of the number of hours spent by the hourly rate.
Below we will show what the application has customizable properties and how they affect the final rate, as well as how the hours spent are fixed.
And now directly to the device business support process.
Let's go in stages.
0. Idea
The client employee has an idea.
Or a problem.
As soon as an idea grows to a verbalized state, a potential customer can turn to a business analyst, or, subject to some degree of preparedness and rights, proceed independently to the next stage.
1. Formulation of the application
In the simplest case, the completed customer creates an application in the tracker, describes the task in it (the text can flow from a business analyst, whose work is paid by the hour) for the developer and sends it to work.
Each application has three properties that significantly affect its processing and final cost, namely:
- a priority
- Required Qualification
- volume \ task complexity
In addition, the application has an error sign (error or not), and can store a link to the “parent” application.
Let us consider in more detail each of them.
1.1. A priority
The priority of the application, as is easy to guess from the name, affects its speed of execution.
Priority - a set of three options:
- Normal (default)
- Urgent
- Critical
Applications with critical priority are executed at any time of the day or night, the response time is determined in the SLA (usually, during working hours - up to 15 minutes, during non-working - up to an hour).
Normal and urgent applications are executed only during business hours, urgent ahead of normal.
The presence of the application of increasing priority means the presence of increasing tariff coefficient to the base cost of an hour.
1.2. Requested performer qualification
Ultima certified developer for commercial use qualifies in three levels:
- Junior Developer
- Developer
- Senior Developer
Note in brackets that the internal grade system is somewhat more complicated, and will be covered in a separate text.
When creating an application, the customer chooses from the same three options, while Developer - by default. It also corresponds to the base cost of an hour.
Junior - reduction factor, Senior - raising.
Juniors are used for the simplest tasks such as editing a form or correcting a report. Seniors - for large-scale change projects.
Going into details, I note that the customer can not only set the level of a specialist, but also indicate a specific specialist. In general, the hourly rate will be changed according to the level of the specialist. However, if a particular specialist is in excess demand, according to the laws of the market it is possible for him to introduce an additional incremental factor separately (he also has a positive effect on income)
It is worth paying special attention to the fact that in tasks that are more difficult than complete triviality, it may well be that using a senior for a client will be cheaper than a junior - because he spends so fewer hours that, despite the higher rate, the total will be less.
Our pricing technology is based on the principle of actual hours spent fixed by the programmer in the time-keeping subsystem — not budgeting, according to preliminary estimates, by a specially trained person.
: - , , . - 2 , , . 2- ( , - ). 1. , . . , , . 2. , - , . , “ ” , , - , . , , . , , , . , 2 - , , , , . , , - . - , . - “” 100%. , , . , , - , . “ ” : ? . : (), (), : . As a result, the extra hours are probably added to the small things, but this is exactly the case when the damage from the struggle with the problem is much more than from the problem itself.
1.3. Volume / complexity of the task
Again, the customer chooses from three options:
- Trifle
Move a button, make a hint, add a simple check and warning, etc. Roughly speaking, within an hour. - Task (default)
For example, a new print form, a report, and so on. A few hours to days. - Megazadacha
Complex complex business process change. For example, change the work delivery. The appearance of its own mini-production of salads in the supermarket. The opening of the direction of mail order. The emergence of own foreign purchases and direct imports.
The boundaries between the values ​​of volume / complexity are very vague, and, frankly, are almost completely subjective.
The characteristic volume / complexity of the task is used in the mechanism of automatic dispatching of tasks between the pool of programmers.
When the robot chooses which developer to assign the newly fallen task, it is repelled by the principle of uniform loading (all other things being equal). The duration of the task queue for execution for each developer is predicted precisely on the basis of their complexity and the average statistics for the execution time of tasks of this category that is usual in statistics.
It is clear that for each individual task, the error can be several times, but the whole line - the results of the predictions are quite acceptable.
Here it is. As a result, the application was created, the parameters were selected by the customer, and then it falls into automatic dispatching in the warm soulless paws of the same robot, which was discussed in the previous paragraph.
2. Application dispatching
So, the warm check robot determines the performer independently.
Critical tasks are handled in a special way.
When a request appears with a critical priority at any time of the day, on weekends and holidays, the robot looks for a performer - any suitable level (if no specific performer is indicated) who is not busy with other critical requests.
To do this, use a system with minimal changes identical to that previously described in one of our cases , so we will not repeat.
When receiving a critical task, the executor stops working on the current task (if at all the working time).
Urgent and ordinary applications are processed only during business hours.
We can assume that each developer has 3 task queues (by priorities).
Tasks come to work only after the queue with the highest priority is exhausted; the developer must disassemble all urgent tasks before receiving the task with the usual priority.
Going into details, I note that applications with an error mark and a reference to the parent application are processed as critical applications. The executor in such an application is taken from the parent application. Applications without reference to the parent are distributed along with the usual tasks.
Otherwise, the distribution of all tasks is arranged in the same way - all developers are selected, with a sufficient level of qualification, and from them the performer with the smallest forecast date for completing the task is selected.
It is worth noting that the developers themselves form their working calendar indicating when and how they work - i.e. every day indicate what time they will work.
The electronic time sheet is used to ensure that the robot (and humanoid administrators, if necessary) know what resources they have at each time point.
A task with a chosen Junior Developer level can be obtained by any developer if his turn is shorter. To evaluate the queue, the scale of the task is used. This, of course, is an estimate from above, but it is better to live up to expectations than to give unjustified promises.
Thus, all tasks in the queue have a forecast date of execution, respectively, and a new task that appears at the tail of the queue receives its forecast date for the completion of work automatically.
Keeping the forecast dates for submission of applications by the developer has a positive effect on income (in more detail about the developer motivation formula - in the next series).
Thus, the developer is interested that the application would receive a real deadline and, in turn, upon receipt of a new task and the existence of objective arguments about an error in estimating the estimated date of completion, may ask the manager to postpone the date to a later date.
As a result, each task is immediately assigned a responsible person who is interested in meeting the deadlines for the execution of the task. In turn, the customer is interested in specifying the most accurate parameters of the application, because he sees that the deadlines are met.
3. Development
The developer in the tracker interface at any time can see the queue of his tasks (more precisely, 3 queues - by priority), which application is assigned to him at the moment, there are notifications about new tasks. Having done the necessary work, the developer makes the time spent on the application. If the task takes more than one day, it enters data on the time spent every day.
The task of the developer is to do what he is asked to do in the application.
Often (especially if the application is placed without the help of an analyst), the developer can suggest some or other improvements on the application (acting in a certain sense in the role of analyst).
It is very pleasant and useful to clients, therefore it is encouraged in our company. The developer himself is trying to rise above the technical details of the implementation and look at the task from a slightly different angle, maybe even through the eyes of the customer.
If a developer succeeds, he has a great chance of becoming a business analyst.
To help the developer, integration tests, control checklists (a list of what the developer should check to avoid messing up), verification mechanisms in the platform, etc.
Finished - well done.
The completed task is passed to testing.
4. Testing
According to our approach to the organization of internal processes (“not to accept, not to create, not to transfer a marriage”), the application should be executed and passed to testing without errors.
We do not have testers.
. - , , . . -, ( , ), , . -, , . . - - . “, ? ? , ”. - , , . So, the programmer is (financially) responsible for the quality of the application.
An additional incentive to make fewer errors is a) the fact that they are corrected by the programmer for free and b) the presence of uncorrected errors blocks the ability to work on other tasks - you cannot charge watches and receive new applications.
Actually at this stage there are applications with an error sign and a link to the parent. You cannot return the task to work - just create a new application.
In the end - the guy, you had a lot of time to check everything before putting it to the customer, nobody rushed. If you were too lazy to check it yourself, others worked for you.
5. Acceptance
If the customer agrees to accept the application, he marks it as accepted. In this case, the system offers him to evaluate the work on the application on the following scale:
- Do not climb into any gate (2)
- through the stump-deck, but won (3)
- good, though not without rough edges (4)
- brilliantly, it is impossible to wish for the best (5)
When setting the estimate, the customer sees a slider with text options, can set the slider to an intermediate position.
For an assessment of 5, the developer will receive a premium, for an assessment of less than 4, they will be deprived. 2 - disassembly.
It happens that tasks hang in testing and are not processed on the client side.
When it took an indecently large scale for one of the clients (well, it was just too lazy to go to customers and close the application, the functionality itself was already available) made a limit on the simultaneous number of applications in testing.
If the limit is exceeded, the customer cannot send new tasks to work.
Another problem from practice is that customers are sometimes embarrassed to give bad marks to developers. Even with real jambs. In this case, the situation looks good in terms of statistics, but dissatisfaction is accumulating.
Moreover, the overall mood of the client is affected (sometimes more than anything else) by the work of analysts.
Therefore, quarterly Ultima partner center conducts a survey of customers on the topic of integrated assessment of the level of satisfaction with cooperation. I will quote the questionnaire from the support article on our website :
A
Using the Ultima solution has a clear positive effect on the company's operating performance. Ultima service partner consultants display high business competence and regularly offer effective solutions to optimize business processes, leading to higher profits and / or reduced costs.
B
It is difficult to unambiguously separate the positive contribution of the Ultima solution from the action of other factors, but we are undoubtedly satisfied with both the results of the software operation and the cooperation with the Ultima service partner.
C
ERP-system Ultima implemented and working.
No other significant achievements were noted.
D
We were deceived. In practice, nothing to do with what you promise on your site.
Finally
Actually, this is how the support business process is arranged. Confused, slurred? Sorry, the first experience, ask clarifying questions in the comments.
In the following series:
Programmer motivation. The role of business analysts and their motivation. The ideology of the approach to the implementation of Ultima. Letters from readers.
The author thanks Ultima Consulting for their invaluable assistance, both in the actual construction of the company's business processes and in the creation of this series.
Source: https://habr.com/ru/post/255081/
All Articles