Service entity management method and system
By calculating the service entity's capability parameters and coverage radius to generate a shift schedule, the problem of managing service entities' night shifts was solved, improving operational efficiency and reducing costs.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2025-12-04
- Publication Date
- 2026-04-07
AI Technical Summary
Existing technologies are insufficient to effectively manage the night shifts of service providers, resulting in high operating costs and difficulty in meeting residents' nighttime purchasing needs.
By acquiring basic capability parameters of service entities, such as sales volume coefficient, variety coefficient, and typical radius, the initial and final service entity capability coefficients are calculated, and the service coverage radius is calculated based on these coefficients to generate a schedule to reasonably arrange the operating hours of service entities.
It improved the operational efficiency of service entities, reduced operating costs, and better met residents' nighttime purchasing needs.
Smart Images
Figure CN121809907A_ABST
Abstract
Description
Technical Field
[0001] This application mainly relates to the field of service entity management, and in particular to a service entity management method and system. Background Technology
[0002] To enhance convenience, many service establishments operate 24 hours a day to meet the needs of the surrounding community, such as bank branches and convenience stores. Pharmacies, for example, are sometimes required by certain administrative regions to operate 24 hours a day to meet the purchasing needs of local residents due to their specific nature. However, for most service establishments, nighttime demand is low, and it's difficult to break even during nighttime operations. With economic development, the market for similar service establishments is becoming saturated, and intensified competition is leading to a continuous narrowing of profit margins. Consequently, retail service establishments and large chain service establishments are increasingly calling for the elimination or restriction of nighttime operations.
[0003] To address the challenges of service businesses operating at night, some administrative districts are proposing a system where designated retail service businesses within their jurisdictions operate on a shift system. This involves allowing these businesses to take turns opening at night, aiming to minimize the number of service businesses operating at night while still meeting the nighttime purchasing needs of nearby residents, thereby reducing their operating costs. Therefore, there is an urgent need in this field for an effective method to manage the nighttime shift scheduling of service businesses. Summary of the Invention
[0004] The technical problem to be solved by this application is to provide a service entity management method and system that can effectively schedule each service entity according to its sales capacity, thereby improving the operational efficiency of the service entities and reducing their operating costs.
[0005] To address the aforementioned technical problems, this application provides a service entity management method, comprising the following steps: obtaining basic capability parameters of the service entity, wherein the basic capability parameters of the service entity include a sales coefficient within a preset time period, a product coefficient within the preset time period, and a typical radius; calculating an initial service entity capability coefficient based on the basic capability parameters of the service entity; determining a final service entity capability coefficient based on the initial service entity capability coefficient and the capability coefficient boundary interval; calculating the service coverage radius based on the final service entity capability coefficient and the typical radius; and generating a schedule based on the service coverage radius to manage the stores.
[0006] Optionally, the basic capability parameters of the service entity may also include the community population coefficient.
[0007] Optionally, the management method further includes establishing a first functional relationship between the basic capability parameters of the service entity and the initial service entity capability coefficients, and calculating the initial service entity capability coefficients based on the first functional relationship and the basic capability parameters of the service entity, wherein the first functional relationship includes:
[0008] M1 = K + P + Q
[0009] Wherein, M1 is the initial service entity capability coefficient, K is the sales volume coefficient, P is the variety coefficient, and Q is the community population coefficient.
[0010] Optionally, the management method further includes establishing a second functional relationship between the final service entity capability coefficient, the typical radius, and the service coverage radius, and calculating the service coverage radius based on the final service entity capability coefficient, the typical radius, and the second functional relationship, wherein the second functional relationship includes:
[0011]
[0012] Where D is the service coverage radius, R is the typical radius, and M2 is the final service entity capability coefficient.
[0013] Optionally, obtaining the basic capability parameters of the service entity includes calculating the sales coefficient within the preset time period. Calculating the sales coefficient within the preset time period includes the following steps: obtaining the sales volume of each service entity within the preset time period; obtaining the average sales volume of multiple service entities within the preset time period; establishing a third functional relationship between the sales volume, the average sales volume, and the relative difference in sales volume of each service entity within a typical radius area; calculating the relative difference in sales volume based on the sales volume, the average sales volume, and the third functional relationship; and calculating the sales coefficient based on the relative difference in sales volume.
[0014] Optionally, the third functional relation includes:
[0015]
[0016] Where X represents the relative sales difference, Xi represents the sales data, and Xav represents the average sales.
[0017] Optionally, calculating the sales coefficient based on the relative sales difference includes the following steps: performing relative difference boundary processing on the relative sales difference, which includes comparing the relative sales difference with a relative difference interval, the relative difference interval including a left endpoint and a right endpoint, wherein if the relative sales difference is less than the value of the left endpoint, the value of the left endpoint is taken as the final relative sales difference; if the relative sales difference is greater than the value of the right endpoint, the value of the right endpoint is taken as the final relative sales difference; if the relative sales difference is within the relative difference interval, the value of the relative sales difference is taken as the final relative sales difference; establishing a fourth functional relationship between the final relative sales difference and the sales coefficient, and calculating the sales coefficient using the fourth functional relationship and the final relative sales difference.
[0018] Optionally, the relative difference interval is [-1, 1].
[0019] Optionally, the fourth functional relation includes:
[0020] K=1-L
[0021] Where K is the sales coefficient and L is the relative difference in final sales.
[0022] Optionally, obtaining the basic capability parameters of the service entity includes calculating the variety coefficient within the preset time period. Calculating the variety coefficient within the preset time period includes the following steps: obtaining the historical product varieties sold by each service entity within the preset time period; calculating the total historical product varieties sold by multiple service entities based on the historical product varieties sold by each service entity; establishing a fifth functional relationship between the historical product varieties sold, the total historical product varieties sold, and the variety coefficient; and calculating the variety coefficient based on the fifth functional relationship, the historical product varieties sold, and the total historical product varieties sold.
[0023] Optionally, the fifth functional relation includes:
[0024]
[0025] Wherein, P is the variety coefficient, Yi is the historical variety of goods sold, and Y is the total historical variety of goods sold.
[0026] Optionally, obtaining the basic capability parameters of the service entity includes presetting the typical radius, which ranges from 500m to 800m.
[0027] Optionally, obtaining the basic capability parameters of the service entity includes calculating the community population coefficient. Calculating the community population coefficient includes the following steps: obtaining the community population of multiple communities and the affordable population baseline for each service entity; establishing a sixth functional relationship between the community population, the affordable population baseline, and the community population coefficient; and calculating the community population coefficient based on the community population, the affordable population baseline, and the sixth functional relationship.
[0028] Optionally, the sixth functional relation includes:
[0029]
[0030] Wherein, Q is the community population coefficient, E is the community population of the multiple communities, F is the affordable population baseline for each service entity, and G is the adjustment coefficient.
[0031] Optionally, determining the final service entity capability coefficient based on the initial service entity capability coefficient and the capability coefficient boundary interval includes the following steps: presetting a first capability coefficient value and a second capability coefficient value; using the first capability coefficient value as the left endpoint of the capability coefficient boundary interval and the second capability coefficient value as the right endpoint of the capability coefficient boundary interval; when the initial service entity capability coefficient is within the capability coefficient boundary interval, using the initial service entity capability coefficient as the final service entity capability coefficient; when the initial service entity capability coefficient is less than the first capability coefficient value, using the first capability coefficient value as the final service entity capability coefficient; when the initial service entity capability coefficient is greater than the second capability coefficient value, using the second capability coefficient value as the final service entity capability coefficient.
[0032] Optionally, the center of the service coverage radius includes the location of the service entity.
[0033] Optionally, generating a service entity schedule based on the service coverage radius includes the following steps: calculating the service coverage radius of multiple service entities; determining whether the service coverage radius of the current service entity covers the location of the candidate service entity; if the service coverage radius of the current service entity covers the location of the candidate service entity, then the candidate service entity can operate in place of the current service entity.
[0034] To address the aforementioned technical problems, this application provides a service entity management system, comprising: a memory for storing instructions executable by a processor; and a processor for executing the instructions to implement the method described above.
[0035] To address the aforementioned technical problems, this application provides a computer-readable medium storing computer program code, which, when executed by a processor, implements the method described above.
[0036] Compared to existing technologies, this application obtains the final service entity capability coefficient through the basic capability parameters of the service entity, and then calculates the service coverage radius based on the final service entity capability coefficient. This allows for reasonable and effective scheduling of each service entity according to its sales capacity, improving operational efficiency and reducing operating costs. Furthermore, by boundary-mapping the initial service entity capability coefficient to obtain the final service entity capability coefficient, the final service entity capability coefficient is more consistent with real-life situations, further enhancing the practicality of the management method. Attached Figure Description
[0037] The accompanying drawings are included to provide a further understanding of this application; they are incorporated into and constitute a part of this application. The drawings illustrate embodiments of this application and, together with this specification, serve to explain the principles of this application. In the drawings:
[0038] Figures 1-5 This is a flowchart illustrating a service entity management method according to an embodiment of this application;
[0039] Figures 6-9 This is a schematic diagram of the service coverage radius of a service entity using a service entity management method according to an embodiment of this application for scheduling management;
[0040] Figure 10 This is a schematic diagram of the structure of a service entity management system according to an embodiment of this application. Detailed Implementation
[0041] To more clearly illustrate the technical solutions of the embodiments of this application, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the drawings described below are merely some examples or embodiments of this application. For those skilled in the art, these drawings can be applied to other similar scenarios without creative effort. Unless obvious from the context or otherwise specified, the same reference numerals in the drawings represent the same structures or operations.
[0042] As indicated in this application and claims, unless the context clearly indicates otherwise, the words "a," "an," "an," and / or "the" are not specifically singular and may include plural forms. Generally speaking, the terms "comprising" and "including" only indicate the inclusion of explicitly identified steps and elements, which do not constitute an exclusive list, and the method or apparatus may also include other steps or elements.
[0043] Unless otherwise specifically stated, the relative arrangement, numerical expressions, and values of the components and steps described in these embodiments do not limit the scope of this application. It should also be understood that, for ease of description, the dimensions of the various parts shown in the drawings are not drawn to actual scale. Techniques, methods, and devices known to those skilled in the art may not be discussed in detail, but where appropriate, such techniques, methods, and devices should be considered part of the specification. In all examples shown and discussed herein, any specific values should be interpreted as merely exemplary and not as limitations. Therefore, other examples of exemplary embodiments may have different values. It should be noted that similar reference numerals and letters in the following drawings denote similar items; therefore, once an item is defined in one drawing, it need not be further discussed in subsequent drawings.
[0044] In the description of this application, it should be understood that the orientation or positional relationship indicated by directional terms such as "front, back, up, down, left, right", "horizontal, vertical, horizontal" and "top, bottom" is usually based on the orientation or positional relationship shown in the accompanying drawings, and is only for the convenience of describing this application and simplifying the description. Unless otherwise stated, these directional terms do not indicate or imply that the device or element referred to must have a specific orientation or be constructed and operated in a specific orientation, and therefore should not be construed as a limitation on the scope of protection of this application; the directional terms "inner" and "outer" refer to the inner and outer contours relative to the outline of each component itself.
[0045] For ease of description, spatial relative terms such as "above," "on top of," "on the upper surface of," "above," etc., are used herein to describe the spatial positional relationship of a device or feature as shown in the figures to other devices or features. It should be understood that spatial relative terms are intended to encompass different orientations in use or operation beyond the orientation of the device as described in the figures. For example, if the device in the figures were inverted, a device described as "above" or "on top of" other devices or structures would subsequently be positioned as "below" or "under" other devices or structures. Thus, the exemplary term "above" can include both "above" and "below." The device may also be positioned in other different ways (rotated 90 degrees or in other orientations), and the spatial relative descriptions used herein will be interpreted accordingly.
[0046] Furthermore, it should be noted that the use of terms such as "first" and "second" to define components is merely for the purpose of distinguishing the corresponding components. Unless otherwise stated, these terms have no special meaning and therefore should not be construed as limiting the scope of protection of this application. In addition, although the terminology used in this application is selected from commonly known and used terms, some terms mentioned in this application's specification may have been chosen by the applicant according to his or her judgment, and their detailed meanings are explained in the relevant sections of this description. Moreover, this application should be understood not only through the actual terms used, but also through the meaning implied by each term.
[0047] This application refers to Figures 1-6 A commodity management method 10 (hereinafter referred to as "management method 10") is proposed. Figures 1-6 A flowchart illustrating the specific method of management method 10 is shown. This application uses flowcharts to illustrate the operations performed by the system according to embodiments of this application. It should be understood that the preceding or following operations are not necessarily performed precisely in sequence. Instead, various steps can be processed in reverse order or simultaneously. Furthermore, other operations may be added to these processes, or one or more steps may be removed from these processes.
[0048] Specifically, refer to Figure 1 Management method 10 mainly includes steps S1 to S5. Step S1 includes obtaining basic capability parameters of the service entity, including the sales coefficient, product coefficient, and typical radius within a preset time period; Step S2 includes calculating the initial service entity capability coefficient based on the basic capability parameters; Step S3 includes determining the final service entity capability coefficient based on the initial service entity capability coefficient and the capability coefficient boundary range; Step S4 includes calculating the service coverage radius based on the final service entity capability coefficient and the typical radius; Step S5 includes generating a schedule based on the service coverage radius to manage the stores.
[0049] For example, the aforementioned basic capability parameters may also include other operational data of the service entity, such as customer traffic and other quantifiable operational indicators, depending on the actual situation. This application does not impose any limitations on this. On the other hand, the service entity referred to in this application may include business entities with service characteristics, such as banks, restaurants, repair shops, pharmacies, convenience stores, and supermarkets. To better understand management method 10, the implementation process of management method 10 in steps S1 to S5 will be specifically described using a pharmacy operating at night as an example.
[0050] In this embodiment, step S1 involves obtaining basic capability parameters of the service entity. These parameters include a sales volume coefficient, a product variety coefficient, and a typical radius within a preset time period. The sales volume coefficient reflects the sales volume of the service entity within the preset time period; the product variety coefficient reflects the variety of goods that the service entity can sell within the preset time period; and the typical radius represents the furthest typical purchase distance for consumers (e.g., the furthest walking distance from home to the service entity). For example, the preset time period can be six months or one year, or different time periods can be selected according to the actual application scenario; this application does not impose any limitations on this. Obtaining these basic capability parameters allows for a comprehensive consideration of the important factors affecting the operation of the service entity, helping to form a more reasonable scheduling plan.
[0051] Furthermore, obtaining basic capability parameters for service entities includes a preset typical radius. For example, for pharmacies operating at night, the typical radius can be set to 500m-800m, with a walking time of approximately 7-12 minutes. In this embodiment, 500m is preferred. Setting the typical radius to 500m primarily considers that the furthest distance residents need to walk to buy medicine at night should not be too far, as buying medicine at night is often an emergency; therefore, a typical radius of 500m is more appropriate. In other embodiments of this application, other service entities can flexibly set the range of the typical radius according to actual usage scenarios, and this application does not impose any restrictions on this.
[0052] In this embodiment, refer to Figure 2 , Figure 2 The flowchart illustrates the specific process for calculating the sales coefficient within a preset time period. The calculation includes steps S21 to S25. Specifically, step S21 involves obtaining the sales volume of each service entity within the preset time period; step S22 involves obtaining the average sales volume of multiple service entities within the preset time period; step S23 involves establishing a third functional relationship between sales volume, average sales volume, and the relative difference in sales volume between each service entity within a typical radius area; step S24 involves calculating the relative difference in sales volume based on sales volume, average sales volume, and the third functional relationship; and step S25 involves calculating the sales coefficient based on the relative difference in sales volume.
[0053] In this preferred embodiment, the third functional relationship is as follows:
[0054]
[0055] Where X represents the relative sales deficit, Xi represents the sales data, and Xav represents the average sales. Calculating the sales coefficient of each service entity can accurately reflect its sales performance and help determine the final service coverage radius.
[0056] Furthermore, refer to Figure 3 As shown, Figure 3 The specific steps S31-S32 in step S25 for calculating the sales coefficient based on the relative difference in sales are shown. Specifically, S31 involves performing relative difference boundary processing on the relative difference in sales. This processing includes comparing the relative difference in sales with a relative difference interval, which includes a left endpoint and a right endpoint. If the relative difference in sales is less than the value at the left endpoint, then the value at the left endpoint is taken as the final relative difference in sales. If the relative difference in sales is greater than the value at the right endpoint, then the value at the right endpoint is taken as the final relative difference in sales. If the relative difference in sales is within the relative difference interval, then the value of the relative difference in sales is taken as the final relative difference in sales.
[0057] Further, step S32 involves establishing a fourth functional relationship between the relative difference in final sales volume and the sales coefficient, and calculating the sales coefficient using the fourth functional relationship and the relative difference in final sales volume. For example, the relative difference interval is [-1, 1], and in this preferred embodiment, the fourth functional relationship is as follows:
[0058] K=1-L
[0059] Where K is the sales coefficient and L is the final sales relative difference. The above steps allow for boundary processing of the initially obtained sales relative difference to arrive at the final sales relative difference. This enables a better determination of the impact of the sales relative difference on the sales coefficient based on actual conditions, thereby better determining the impact of the sales relative difference on the final service coverage radius. In other words, the sales coefficient can be controlled within a reasonable range, further improving the accuracy and reliability of the data. This is beneficial for improving the efficiency of the final scheduling design, and ultimately, further improving the operational efficiency of the service entity.
[0060] Specifically, this embodiment targets pharmacies that operate at night. For pharmacies operating at night, calculating the sales coefficient requires first obtaining the sales data of each pharmacy within a certain area over a preset period, and then converting the sales data into values between [0,2]. For example, consider pharmacy A, whose sales volume over the past six months is sales volume a1. First, for pharmacy A, a circular area is drawn with pharmacy A's location as the center and the aforementioned preset typical radius as the radius. This circular area also includes pharmacy B with sales volume b1 over the past six months and pharmacy C with sales volume c1 over the past six months. Then, according to the third functional relationship... We can calculate the relative sales difference of pharmacy A. In this case, Xi is a1 and Xav is (a1+b1+c1) / 3 (number of pharmacies).
[0061] Next, boundary processing is performed on the relative sales difference of pharmacy A to obtain the final relative sales difference. In this embodiment, the relative sales difference of pharmacy A is limited to the relative difference interval [-1, 1], where the left endpoint of the relative difference is -1 and the right endpoint is 1. Assuming the relative sales difference of pharmacy A is 0.2, then the final relative sales difference of pharmacy A is 0.2. Assuming the relative sales difference of pharmacy A is -1.25, then the final relative sales difference of pharmacy A is -1. Assuming the relative sales difference of pharmacy A is 1.25, then the final relative sales difference of pharmacy A is 1. This boundary processing allows for a better determination of the impact of the relative sales difference on the sales coefficient based on the actual situation, thereby better determining the impact of the relative sales difference on the final service coverage radius. In other words, the sales coefficient can be controlled within a reasonable range, further improving the accuracy and reliability of the data.
[0062] Finally, based on the relative difference in final sales of pharmacy A and the fourth functional relationship, the sales coefficient of pharmacy A can be obtained. For example, if the relative difference in final sales of pharmacy A is 0.2, then the sales coefficient of pharmacy A is equal to 1 minus 0.2, and the final sales coefficient of pharmacy A is 0.8.
[0063] On the other hand, obtaining the basic capability parameters of the service entity also includes calculating the variety coefficient within a preset time period, referring to... Figure 4 As shown, Figure 4 The flowchart illustrates steps S41-S43 in calculating the variety coefficient within a preset time period. Specifically, step S41 involves obtaining the historical product varieties sold by each service entity within the preset time period; step S42 involves calculating the total historical product varieties sold by multiple service entities based on the historical product varieties sold by each service entity; and step S43 involves establishing a fifth functional relationship between the historical product varieties sold, the total historical product varieties sold, and the variety coefficient, and calculating the variety coefficient based on the fifth functional relationship, the historical product varieties sold, and the total historical product varieties sold.
[0064] For example, the fifth functional relationship is shown in the following formula:
[0065]
[0066] Where P is the product variety coefficient, Yi is the historical product variety sold, and Y is the total historical product variety sold. Calculating the product variety coefficient of a service entity reflects the types of goods sold by the entity within a preset time period. Knowing the product variety coefficient can help better coordinate the scheduling of various pharmacies and further improve the operational efficiency of the service entity.
[0067] Taking pharmacy A as an example again, we can count the types of medicines sold by pharmacy A at night over the past six months. Using pharmacy A's location as the center and a circle with a pre-defined typical radius as the radius, we can draw a circle containing pharmacies B and C. The total number of historically sold items within this circle represents the total number of items sold by pharmacies A, B, and C. In practical applications, the historically sold items of pharmacies A, B, and C may overlap. Therefore, overlapping items are counted as one item when calculating the total historically sold items. After obtaining the types of medicines sold by pharmacy A at night over the past six months and the total historically sold items, we can calculate the item coefficient for pharmacy A using the fifth functional relationship.
[0068] In this embodiment, the basic capability parameters of the service entity also include the community population coefficient, and the calculation of the community population coefficient includes, for example: Figure 5 The steps S51-S53 are shown below. Step S51 involves obtaining the population of multiple communities and the affordable population baseline for each service entity; Step S52 involves establishing the sixth functional relationship between the community population, the affordable population baseline, and the community population coefficient; Step S53 involves calculating the community population coefficient based on the community population, the affordable population baseline, and the sixth functional relationship. Obtaining the community population coefficient reflects the purchasing power of the population within the community where the service entity is located, thus helping to understand the service entity's affordability. Comprehensively considering various influencing factors on the service entity's purchasing power helps in better designing work schedules, further improving operational efficiency and reducing operating costs.
[0069] In this preferred embodiment, the sixth functional relationship is as follows:
[0070]
[0071] Where Q is the community population coefficient, E is the total population of multiple communities, and F is the affordable population baseline for each service entity. For example, F can be 5000, while the adjustment coefficient G helps adjust the weight of the community population coefficient in the final determination of the service entity's basic capability parameters; for example, G can be 0.01.
[0072] In this embodiment, referring back to reference 1, after determining the sales volume coefficient, variety coefficient, and community population coefficient, step S2 can be performed. Step S2 involves establishing a first functional relationship between the basic capability parameters of the service entity and the initial service entity capability coefficient, and calculating the initial service entity capability coefficient based on the first functional relationship and the basic capability parameters of the service entity. In this embodiment, the first functional relationship is:
[0073] M1 = K + P + Q
[0074] Where M1 is the initial service entity capability coefficient, K is the sales volume coefficient, P is the product variety coefficient, and Q is the community population coefficient. The initial service entity capability coefficient can then be obtained based on the first functional relationship, sales volume coefficient, product variety coefficient, and community population coefficient. For example, in practical application scenarios, the community population coefficient surrounding the service entity may not be easily obtained through public data. If some community population coefficient data is lacking, it can be disregarded when calculating the initial service entity capability coefficient (i.e., M1 = K + P). In some application scenarios, the sales volume coefficient or product variety coefficient may also be disregarded when calculating the initial service entity capability coefficient, resulting in M1 = K + Q or M1 = P + Q. Of course, there are also cases where M1 = K, M1 = P, or M1 = Q, and this application does not limit this.
[0075] Further, continue to refer to Figure 1 After obtaining the initial service entity capability coefficient, step S3 can be performed. Step S3 is to determine the final service entity capability coefficient based on the initial service entity capability coefficient and the capability coefficient boundary interval. Specifically, determining the final service entity capability coefficient based on the initial service entity capability coefficient and the capability coefficient boundary interval also includes presetting a first capability coefficient value and a second capability coefficient value, using the first capability coefficient value as the left endpoint of the capability coefficient boundary interval, and the second capability coefficient value as the right endpoint of the capability coefficient boundary interval; when the initial service entity capability coefficient is within the capability coefficient boundary interval, the initial service entity capability coefficient is used as the final service entity capability coefficient; when the initial service entity capability coefficient is less than the first capability coefficient value, the first capability coefficient value is used as the final service entity capability coefficient; when the initial service entity capability coefficient is greater than the second capability coefficient value, the second capability coefficient value is used as the final service entity capability coefficient.
[0076] By determining the final service entity capacity coefficient by using the initial service entity capacity coefficient and the capacity coefficient boundary interval, the impact of the service entity capacity coefficient on the service coverage radius can be better determined through boundary processing. This further improves the authenticity, reliability, and rationality of the data, which is conducive to improving the efficiency of the final scheduling design, thereby further improving the operational efficiency of the service entity.
[0077] In this embodiment, for pharmacy A, the first capability coefficient is set to a value between [0, 1], preferably 0.6, and the second capability coefficient is set to a value between [1, 2], preferably 1.5. Therefore, the capability coefficient boundary range in this embodiment is [0.6, 1.5]. Assuming that pharmacy A's initial service entity capability coefficient is 0.23, then pharmacy A's initial service entity capability coefficient is not within the capability coefficient boundary range and is less than the first capability coefficient value of 0.6. In this case, the first capability coefficient value of 0.6 is used as the final service entity capability coefficient. Assuming that pharmacy A's initial service entity capability coefficient is 2.15, then pharmacy A's initial service entity capability coefficient is not within the capability coefficient boundary range and is greater than the second capability coefficient value of 1.5. In this case, the second capability coefficient value of 1.5 is used as the final service entity capability coefficient.
[0078] Next, return to the reference. Figure 1 After obtaining the final service entity capability coefficient, step S4 can be performed. Step S4 involves establishing a second functional relationship between the final service entity capability coefficient, the typical radius, and the service coverage radius, and calculating the service coverage radius based on the final service entity capability coefficient, the typical radius, and the second functional relationship. In this embodiment, the second functional relationship is as follows:
[0079]
[0080] Where D is the service coverage radius, R is the typical radius, and M2 is the final service entity capacity coefficient. As can be seen from the above settings, the service coverage radius can be controlled by setting the first and second capacity coefficient values. For pharmacy A, if pharmacy A is very busy and cannot handle the business within the circle drawn with pharmacy A's location as the center and the typical radius as the radius, then the final service entity capacity coefficient of pharmacy A, calculated above, will be large. Therefore, the first capacity coefficient value can be used to reduce the pharmacy's service coverage radius, thus controlling pharmacy A's carrying capacity. If pharmacy A is not doing well, and there is almost no business within the circle drawn with pharmacy A's location as the center and the typical radius as the radius, then the final service entity capacity coefficient of pharmacy A will be small. Setting the second capacity coefficient value can expand the pharmacy's service coverage radius, allowing more people to buy medicine at pharmacy A, thereby controlling pharmacy A's carrying capacity.
[0081] In this embodiment, after obtaining the service coverage radius, step S5 can be performed. Step S5 is to generate a service entity schedule based on the service coverage radius to manage the service entities. Step S5 further includes calculating the service coverage radii of multiple service entities and determining whether the service coverage radius of the current service entity covers the location of the candidate service entity. If the service coverage radius of the current service entity covers the location of the candidate service entity, then the candidate service entity can operate in place of the current service entity.
[0082] Specifically, Figures 6-7 A schematic diagram illustrating the service coverage radius of a service entity in a scheduling design based on management method 10 is shown. (Example) Figure 6 and Figure 7 As shown, taking pharmacy A as an example, pharmacy A is the current service entity. A circle is drawn with pharmacy A's location as the center and the aforementioned preset typical radius as the radius. Pharmacy B also exists within this circle; therefore, pharmacy B is the candidate service entity. The service coverage radii of pharmacy A and pharmacy B are calculated according to management method 10, as follows: Figure 6 As shown, at this time, the service coverage radius of pharmacy A covers the location of pharmacy B. Therefore, during nighttime business hours, when pharmacy B (the candidate service entity) is open, pharmacy A (the current service entity) can rest.
[0083] Furthermore, it can be seen that Figure 6 and Figure 7 The difference in the illustrated embodiments is that Figure 6 In the example, pharmacy B's service coverage radius covers the location of pharmacy A, while Figure 7 In the illustrated embodiment, the service coverage radius of pharmacy B does not cover the location of pharmacy A. When considering whether other pharmacies can replace pharmacy B, a circular area needs to be drawn with pharmacy B's location as the center and the aforementioned preset typical radius as the radius. In this case, the current service entity is pharmacy B. In this embodiment, the circular area corresponding to pharmacy B also includes pharmacy A, making pharmacy A a candidate service entity. Figure 6 It can be seen that at this point, pharmacy B's service coverage radius covers the location of pharmacy A, therefore pharmacy A can operate in place of pharmacy B. And according to... Figure 7 It can be seen that the service coverage radius of pharmacy B does not cover the location of pharmacy A, so pharmacy A cannot replace pharmacy B in operating at this time.
[0084] Based on the above results, a shift schedule can be created for pharmacies A and B, that is, for... Figure 6 In one implementation example, pharmacy A and pharmacy B can take turns working shifts; that is, pharmacy B can rest when pharmacy A is open, and pharmacy A can rest when pharmacy B is open. And regarding... Figure 7In the example shown, pharmacy A can remain closed while pharmacy B is open. However, since pharmacy B's service coverage radius does not cover the location of pharmacy A, pharmacy B still needs to operate according to the actual situation when pharmacy A is open.
[0085] on the other hand, Figure 8 Another embodiment of this application is also shown, in which three service entities need to be scheduled. Taking a pharmacy operating at night as an example, this is based on... Figure 8 As can be seen, pharmacy A has the largest service coverage radius, covering both pharmacies B and C. This means that if either pharmacy B or pharmacy C is open, it can replace pharmacy A. Pharmacy B has the smallest service coverage radius, not covering either pharmacy A or pharmacy C. This means that neither pharmacy A nor pharmacy C can replace pharmacy B. Pharmacy C's service coverage radius covers pharmacy A but not pharmacy B. This means that pharmacy A can replace pharmacy C, but pharmacy B cannot replace pharmacy C. Therefore, the following work schedule can be generated:
[0086] Day 1: A opens the door, B opens the door, C rests;
[0087] Day 2: A rests, B opens the door, C opens the door;
[0088] Day 3: A opens the door, B opens the door, C rests;
[0089] ...
[0090] Day N: A opens the door, B opens the door, C rests.
[0091] ...
[0092] In this preferred embodiment, pharmacies are kept away from continuous operation as much as possible within a cycle (e.g., N days), thereby dispersing the opening hours of each pharmacy and giving the surrounding residents more choices.
[0093] Furthermore, Figure 9 Another embodiment of this application is also shown, in which three service entities need to be scheduled. Taking a pharmacy operating at night as an example, this is based on... Figure 9 As can be seen, pharmacy A has the largest service coverage radius, encompassing both pharmacies B and C. This means that if either pharmacy B or pharmacy C is open, it can replace pharmacy A. Pharmacy B has the smallest service coverage radius, not covering either pharmacy A or pharmacy C. This means that neither pharmacy A nor pharmacy C can replace pharmacy B. Pharmacy C's service coverage radius includes both pharmacies A and B. This means that both pharmacies A and B can replace pharmacy C. Therefore, the following work schedule can be generated:
[0094] Day 1: A opens the door, B opens the door, C rests;
[0095] Day 2: A rests, B opens, C rests;
[0096] Day 3: A rests, B opens, C opens;
[0097] ...
[0098] Day N: A opens the door, B opens the door, C rests;
[0099] In this preferred embodiment, pharmacies are kept away from continuous operation as much as possible within a cycle (e.g., N days), thereby dispersing the opening hours of each pharmacy and giving the surrounding residents more choices.
[0100] This application obtains the final service entity capability coefficient through the basic capability parameters of the service entities, and then calculates the service coverage radius based on the final service entity capability coefficient. This allows for reasonable scheduling of each service entity according to its sales capacity, improving operational efficiency and reducing operating costs. Furthermore, by boundary-mapping the initial service entity capability coefficient to obtain the final service entity capability coefficient, the final service entity capability coefficient is made more consistent with real-life situations, further improving the practicality of the management method.
[0101] An embodiment of this application also proposes a method such as Figure 10 The service entity management system 90 is shown. According to... Figure 9 The service entity management system 90 may include an internal communication bus 91, a processor 92, a read-only memory (ROM) 93, a random access memory (RAM) 94, and a communication port 95. When applied to a personal computer, the service entity management system 90 may also include a hard disk 96.
[0102] The internal communication bus 91 enables data communication between components of the service entity management system 90. The processor 92 can perform judgments and issue prompts. In some embodiments, the processor 92 may consist of one or more processors. The communication port 95 enables data communication between the service entity management system 90 and external systems. In some embodiments, the service entity management system 90 can send and receive information and data from a network through the communication port 95.
[0103] The service entity management system 90 may also include different forms of program storage units and data storage units, such as a hard disk 96, read-only memory (ROM) 93, and random access memory (RAM) 94, capable of storing various data files used for computer processing and / or communication, as well as possible program instructions executed by the processor 92. The processor executes these instructions to implement the main parts of the method. The results of the processor processing are transmitted to the user equipment via a communication port and displayed on the user interface.
[0104] In addition, this application also proposes a computer-readable medium storing computer program code, which implements the above-described voice interaction method when executed by a processor.
[0105] The basic concepts have been described above. Obviously, for those skilled in the art, the above disclosure is merely illustrative and does not constitute a limitation of this application. Although not explicitly stated herein, those skilled in the art may make various modifications, improvements, and corrections to this application. Such modifications, improvements, and corrections are suggested in this application, and therefore remain within the spirit and scope of the exemplary embodiments of this application.
[0106] Furthermore, this application uses specific terms to describe embodiments of the application. For example, "an embodiment," "one embodiment," and / or "some embodiments" refer to a particular feature, structure, or characteristic related to at least one embodiment of the application. Therefore, it should be emphasized and noted that "an embodiment," "one embodiment," or "an alternative embodiment" mentioned twice or more in different locations in this specification do not necessarily refer to the same embodiment. In addition, certain features, structures, or characteristics in one or more embodiments of the application can be appropriately combined.
[0107] Some aspects of this application can be executed entirely by hardware, entirely by software (including firmware, resident software, microcode, etc.), or by a combination of hardware and software. The aforementioned hardware or software may be referred to as a "data block," "module," "engine," "unit," "component," or "system." The processor may be one or more application-specific integrated circuits (ASICs), digital signal processors (DSPs), digital signal processing devices (DAPDs), programmable logic devices (PLDs), field-programmable gate arrays (FPGAs), processors, controllers, microcontrollers, microprocessors, or combinations thereof. Furthermore, aspects of this application may manifest as computer products residing in one or more computer-readable media, including computer-readable program code. For example, computer-readable media may include, but are not limited to, magnetic storage devices (e.g., hard disks, floppy disks, magnetic tapes, etc.), optical discs (e.g., compressed CDs, digital multifunction DVDs, etc.), smart cards, and flash memory devices (e.g., cards, sticks, key drives, etc.).
[0108] A computer-readable medium may contain a propagated data signal containing computer program code, for example, on baseband or as part of a carrier wave. This propagated signal may take various forms, including electromagnetic, optical, and so on, or suitable combinations thereof. A computer-readable medium can be any computer-readable medium other than a computer-readable storage medium, which can be connected to an instruction execution system, apparatus, or device to enable communication, propagation, or transmission of a program for use. The program code located on the computer-readable medium can be propagated through any suitable medium, including radio, cable, fiber optic cable, radio frequency signals, or similar media, or any combination of the above media.
[0109] Similarly, it should be noted that, in order to simplify the description of the present application and thus aid in the understanding of one or more embodiments, the foregoing description of the embodiments of the present application sometimes combines multiple features into a single embodiment, drawing, or description thereof. However, this disclosure method does not imply that the subject matter of the present application requires more features than those mentioned in the claims. In fact, the embodiments contain fewer features than all the features of the single embodiments disclosed above.
[0110] In some embodiments, numbers describing the quantity of components and attributes are used. It should be understood that such numbers used in the description of embodiments are modified in some examples with the terms "approximately," "approximately," or "generally." Unless otherwise stated, "approximately," "approximately," or "generally" indicates that the numbers are allowed to vary by ±20%. Accordingly, in some embodiments, the numerical parameters used in the specification and claims are approximate values, which may be changed depending on the characteristics required by individual embodiments. In some embodiments, numerical parameters should take into account specified significant digits and employ a general method of digit reservation. Although the numerical ranges and parameters used to confirm their breadth of scope in some embodiments of this application are approximate values, in specific embodiments, such values are set as precisely as feasible.
[0111] Although this application has been described with reference to specific embodiments, those skilled in the art should recognize that the above embodiments are only used to illustrate this application, and various equivalent changes or substitutions can be made without departing from the spirit of this application. Therefore, any changes or modifications to the above embodiments within the essential spirit of this application will fall within the scope of the claims of this application.
Claims
1. A service entity management method, characterized in that, Includes the following steps: Obtain the basic capability parameters of the service entity, which include the sales coefficient within a preset time period, the variety coefficient within the preset time period, and the typical radius. Calculate the initial service entity capability coefficient based on the service entity's basic capability parameters; The final service entity capability coefficient is determined based on the initial service entity capability coefficient and the capability coefficient boundary interval. The service coverage radius is calculated based on the final service entity capability coefficient and the typical radius. A schedule is generated based on the service coverage radius to manage the stores.
2. The service entity management method as described in claim 1, characterized in that, The basic capability parameters of the service entity also include the community population coefficient.
3. The service entity management method as described in claim 2, characterized in that, It also includes establishing a first functional relationship between the basic capability parameters of the service entity and the initial service entity capability coefficients, and calculating the initial service entity capability coefficients based on the first functional relationship and the basic capability parameters of the service entity, wherein the first functional relationship includes: M1 = K + P + Q Wherein, M1 is the initial service entity capability coefficient, K is the sales volume coefficient, P is the variety coefficient, and Q is the community population coefficient.
4. The service entity management method as described in claim 1, characterized in that, It also includes establishing a second functional relationship between the final service entity capability coefficient, the typical radius, and the service coverage radius, and calculating the service coverage radius based on the final service entity capability coefficient, the typical radius, and the second functional relationship, wherein the second functional relationship includes: Where D is the service coverage radius, R is the typical radius, and M2 is the final service entity capability coefficient.
5. The service entity management method as described in claim 1, characterized in that, Obtaining the basic capability parameters of the service entity includes calculating the sales coefficient within the preset time period. Calculating the sales coefficient within the preset time period includes the following steps: Obtain the sales volume of each of the service entities within the preset time period; Obtain the average sales volume of the multiple service entities within the preset time period; Establish a third functional relationship between the sales volume, the average sales volume, and the relative difference in sales volume of each service entity within a typical radius region; The relative difference in sales volume is calculated based on the sales volume, the average sales volume, and the third functional relationship. The sales coefficient is calculated based on the relative difference in sales volume.
6. The service entity management method as described in claim 5, characterized in that, The third functional relation includes: Where X represents the relative sales difference, Xi represents the sales data, and Xav represents the average sales.
7. The service entity management method as described in claim 5, characterized in that, Calculating the sales coefficient based on the relative difference in sales volume includes the following steps: The relative difference in sales volume is processed by performing relative difference boundary processing. This relative difference boundary processing includes comparing the relative difference in sales volume with a relative difference interval, where the relative difference interval includes a left endpoint and a right endpoint. If the relative sales difference is less than the value of the left endpoint, then the value of the left endpoint is taken as the final relative sales difference; if the relative sales difference is greater than the value of the right endpoint, then the value of the right endpoint is taken as the final relative sales difference; if the relative sales difference is within the range of the relative difference, then the value of the relative sales difference is taken as the final relative sales difference. A fourth functional relationship is established between the relative difference in final sales and the sales coefficient, and the sales coefficient is calculated using the fourth functional relationship and the relative difference in final sales.
8. The service entity management method as described in claim 7, characterized in that, The relative difference interval is [-1, 1].
9. The service entity management method as described in claim 7, characterized in that, The fourth functional relation includes: K=1-L Where K is the sales coefficient and L is the relative difference in final sales.
10. The service entity management method as described in claim 1, characterized in that, Obtaining the basic capability parameters of the service entity includes calculating the variety coefficient within the preset time period. Calculating the variety coefficient within the preset time period includes the following steps: Obtain the historical product varieties sold by each of the service entities within the preset time period; Calculate the total historical product variety of multiple service entities based on the historical product variety of each service entity; Establish a fifth functional relationship between the historically sold product varieties, the total historically sold product varieties, and the variety coefficient, and calculate the variety coefficient based on the fifth functional relationship, the historically sold product varieties, and the total historically sold product varieties.
11. The service entity management method as described in claim 10, characterized in that, The fifth functional relation includes: Wherein, P is the variety coefficient, Yi is the historical variety of goods sold, and Y is the total historical variety of goods sold.
12. The service entity management method as described in claim 1, characterized in that, Obtaining the basic capability parameters of the service entity includes setting the typical radius, which ranges from 500m to 800m.
13. The service entity management method as described in claim 2, characterized in that, Obtaining the basic capability parameters of the service entity includes calculating the community population coefficient, which includes the following steps: Obtain the population of multiple communities and the affordable population baseline for each of the service entities; Establish a sixth functional relationship between the community population, the carrying capacity baseline, and the community population coefficient; The community population coefficient is calculated based on the community population size, the sustainable population baseline, and the sixth functional relationship.
14. The service entity management method as described in claim 13, characterized in that, The sixth functional relation includes: Wherein, Q is the community population coefficient, E is the community population of the multiple communities, F is the affordable population baseline for each service entity, and G is the adjustment coefficient.
15. The service entity management method as described in claim 1, characterized in that, Determining the final service entity capability coefficient based on the initial service entity capability coefficient and the capability coefficient boundary interval includes the following steps: A first capability coefficient value and a second capability coefficient value are preset, with the first capability coefficient value as the left endpoint of the capability coefficient boundary interval and the second capability coefficient value as the right endpoint of the capability coefficient boundary interval. When the initial service entity capability coefficient is within the boundary range of the capability coefficient, the initial service entity capability coefficient is used as the final service entity capability coefficient. When the initial service entity capability coefficient is less than the first capability coefficient value, the first capability coefficient value is used as the final service entity capability coefficient. When the initial service entity capability coefficient is greater than the second capability coefficient value, the second capability coefficient value is used as the final service entity capability coefficient.
16. The service entity management method according to any one of claims 1 to 15, characterized in that, The center of the service coverage radius includes the location of the service entity.
17. The service entity management method as described in claim 16, characterized in that, Generating a service entity schedule based on the service coverage radius includes the following steps: Calculate the service coverage radius of the multiple service entities; Determine whether the service coverage radius of the current service entity covers the location of the candidate service entity. If the service coverage radius of the current service entity covers the location of the candidate service entity, then the candidate service entity can operate in place of the current service entity.
18. A service entity management system, comprising: Memory is used to store instructions that can be executed by the processor; and a processor for executing the instructions to implement the method as described in any one of claims 1-17.
19. A computer-readable medium storing computer program code that, when executed by a processor, implements the method as claimed in any one of claims 1-17.