20.3.1EAS case background
Enterprise application suite [1] is an enterprise-level application software developed according to the requirements of software group application informatization. The software group provides software delivery services to all industries, delivering software in various modes such as onshore, nearshore, offshore, etc. The EAS system provides a large number of simple and fast operation interfaces, allowing relevant departments of the group to handle daily affairs faster, more conveniently and more efficiently, and provide managers with decision-making references and process simplification, establish a channel for communication between the group and various departments and employees, effectively improve work efficiency, and realize information management of the entire group.
EAS system has built a data sharing and business collaboration platform for enterprises, realizing the integration of human resources , customer resources and project resources . The system includes major modules such as human resource management, customer relationship management and project process management. The system users are all employees of the group, but the different roles determine the differences between their concerns. Global Analysis of
20.3.2EAS
In the global analysis stage, value requirements analysis is required for the target system.
1. Value Requirements Analysis
According to the description of the reference process model, an effective method is to help us determine the customer, vision and scope of the target system through the business model canvas. EAS is a B-side product, and its customers are actually employees of the software group. Employees have different roles, different departments, and different responsibilities, so it is very necessary to make customer segmentation . In fact, before conducting value demand analysis for EAS, we focused on investigating relevant personnel from the Human Resources Department, Marketing Department and Project Management Department. As supporters (providing department business knowledge) and beneficiaries (end users who use EAS), they each proposed business functions that meet their needs, including:
q marketing department manages customers and needs, and tracks contracts;
q project management department manages projects and project personnel, and tracks project progress;
q human resources department is responsible for recruiting talents and managing employees' daily work including work logs, attendance, etc.
When segmenting EAS customers and determining their respective value propositions , the team found that the most important stakeholder was missing: the group management. As decision makers of group business, their understanding of business goals is conducive to more accurate determination of the system vision.
As a group company that provides software delivery services, its core productivity is human resources engaged in software development. The main work of each business department is carried out around the supply and demand of human resources. The pain point of decision makers is that they cannot quickly and intuitively understand the supply and demand of the company's human resources. For example, the customer needs the group to provide 20 Java developers at all levels. Before determining whether to sign the contract, the marketing department needs to query the group's human resources library through EAS to understand whether the existing human resources match customer needs. If it matches, each participating department needs to review the labor costs and decide the subject of the contract. If the group's current human resources cannot meet customer needs, the Human Resources Department needs to start the recruitment process early or find candidates to meet the needs from the talent reserve library. Through EAS, managers can also promptly understand the idle rate of developers, track the progress of projects, and clarify the responsibilities and quality of tasks undertaken by developers in the project.
to obtain the channel channel for business model canvas. This is because EAS is different from other innovative products. It does not require finding various channels to promote the product. It only requires the use of administrative power to require relevant departments to use it. The customer relationship derived from this is actually a further review of various roles participating in the EAS system to understand when these roles will use EAS and how to use EAS.
EAS is the group's internal system and does not involve specific revenue business. Therefore, its source of revenue is more reflected in the control and reduction of costs, and also includes how to provide better services and support for the group's software delivery business. Although the source of EAS's revenue is not obvious, thinking about it is conducive to driving our exploration of core resources and key businesses.
In order to ensure the smooth delivery of EAS, what core resources are needed? What key businesses can be provided by the delivered EAS? After determining EAS's customers, value propositions, sources of income, and other content, those involved in the business model canvas brainstorming can easily answer these questions. Since EAS mainly solves human resources problems, the important cooperation it needs in should also be related to human resources recruitment and training. Finally, EAS is an internal system of the enterprise. Before considering implementing the system, it is natural to understand the cost structure of required to develop the system. Thus, the business model canvas shown in Figure 20-4 can be obtained.
[1] For detailed requirements, design and code in this example, please search for "agiledon/eas-ddd" in GitHub to get .
![20.3.1EAS Case Background Enterprise Application Suite [1] is an enterprise-level application software developed according to the requirements of software group application informatization. The software group provides software delivery services to all industries, delivering softw - DayDayNews](https://cdn-dd.lujuba.top/img/loading.gif)
Figure 20-4EAS's business model canvas
Although EAS is not an innovative product, exploring value needs through it in the global analysis stage, it will be easier to guide customers to describe their ideas in their minds and convey them truthfully through this visual form, forming a consensus on value needs to reach a consensus on the problem space.
Once the content of the business model canvas is determined, the value requirements of the EAS can be obtained based on the relationship between the various sections of the business model canvas and the value requirements as part of the global analysis specification. The value requirements that make up the EAS global analysis specification are shown below.
Stakeholders
q Group decision makers
q Subsidiary
q Subsidiary
q Human Resources Department
q Marketing Department
q Project Management Department
q Project Management Department
q q Project Management Office
q financial
q employee
q service center
q service center
system vision
Avoid information islands, realize controllability of human resources, and achieve the supply and demand balance of human resources.
3 System scope
3.1 Current status
q Created a feature team composed of project managers, business analysts, developers and testers
q Group Project Management Department is responsible for project process management
q Group already has OA system as process collaboration and message notification
q Group already has OA system as the process collaboration and message notification
q q Group has formulated the management measures for talent recruitment and project process management measures
q Software College and recruitment website resumes as the group's talent reserve library
q Employee training already cooperative training companies
q Marketing department provides a list of customers and potential customers
q Marketing department issued an administrative order by the group to promote the EAS system
3.2 Future status
q EAS system passed user acceptance on × year × month ×
q EAS system was launched online on × year × month × ×
q q is responsible for customer relationship management, project management, human resources management
q evaluates the value of the EAS system through customer satisfaction
3.3 Target List
q q reflects the supply and demand status of human resources through visualization
q manages the relationship between the group and customers and potential customers, manages market demand, tracks the contract
q manages projects and project personnel, tracks project progress
q adjusts employment needs in real time, formulates recruitment and training plans
q q manages employee attendance, work logs and other daily work
2. Business demand analysis
After completing the value demand analysis, business demand analysis can be started under the guidance and constraints of value demand.
business requirements analysis starts with the business process, which can enable the business functions of the target system to be "" " to execute a series of activities to meet the business value of the participating roles. In order to quickly grasp the panoramic view of EAS's needs, we can grasp the main process that reflects the core value of the business vision. Since EAS focuses on "'s supply and demand balance of human resources " as its core, then all the main business functions that all participating roles need to perform are related to this core value. Under the guidance of value demand, all participating roles can be abstracted into demand and supply-side in combination with supply-demand balance, and then from the perspective of supply and demand, the collaboration method and collaboration process between each participating role, as shown in Figure 20-5.
Figure 20-5 EAS's core business process
Figure 20-5 The relationship between demand and supply is clearly reflected, showing the key links of the core business process. Note that this collaboration diagram is not the current state before the project begins, but the future state of the expectation to solve the supply and demand balance problem. This collaborative relationship also embodies a systematic vision of breaking down information barriers between departments. Based on this collaboration diagram, we can express the core process of the entire system in the form of a business process diagram, as shown in Figure 20-6. The core process of
reflects the overall operation process of the business process and is a more macro business process expression. Many more detailed collaboration details are not clearly reflected, and the project management process and recruitment process are even encapsulated by "" as subprocesses. In order to explore the problem space more thoroughly, these business processes also need to be further presented. From the perspective of the target system providing services to the participant role, we present the following business processes of EAS through the service blueprint combined with the business flow chart. [1]
q For market personnel : business process for customer cooperation.
q for project management personnel : project management process.
q for training specialists : training process (training requirements are subsequent changes to demands).
[1] Due to space limitations, this chapter only provides a few typical business processes.
Figure 20-6 Swim lane diagram of the core process
Since all users of EAS are employees of the organization, if the service blueprint is used to draw the business process, the customer role is the user who initiates service requests to the target system, such as the market personnel in the business process of signing the contract, the project management process project managers and the recruitment specialist in the recruitment process.
() Customer cooperation
When market personnel initiate a service request to create market demand to the target system, a customer cooperation business process from market demand to the signing of a contract and forming demand orders is formed. Its service blueprint is shown in Figure 20-7.
Since the business rules require subsidiaries with independent legal person qualifications to be the bearer of market demand, the subsidiaries will become Party B in the contract. As customers in the service blueprint, market personnel will not participate in the signing of contracts, but are only concerned about whether the existing resources of the subsidiary can meet market demand. After signing a contract, market personnel can create demand orders through contract information and track demand orders to maintain a good relationship with customers. As front-end employees, a subsidiary needs to interact with the market personnel, but the market personnel cannot see the financial participation, because the financial accounting behavior occurs between the subsidiary and the finance as the front-end employees, so the finance belongs to the back-end employees of the service blueprint. As for internal supporters, they are either EAS itself or external systems outside the EAS range.
According to the service blueprint of the customer cooperation process, the entire process consists of 4 business scenarios: market demand management, resume management, contract management and demand order management. According to the judgment criteria of business services, judge the activities of business scenarios, and a business service diagram for each business scenario can be drawn. The business service diagram of
market demand management is shown in Figure 20-8.
For the " query market demand " business service, although it is not included in the service blueprint, when the subsidiary evaluates market demand, if this function is not provided, the specified market demand cannot be completed. The service value provided by the two is completely independent, so it is necessary to define a business service for them separately. The business service diagram of
resume management is shown in Figure 20-9.
Handler3The business process description for customer cooperation is that the system generates employee resumes, but in fact, this requires the operators of the subsidiary to interact with the system, with the purpose of exporting employee resumes, so the business services are identified to meet functional needs. The business service diagram of
contract management is shown in Figure 20-10. The signing of the
contract is carried out offline. The EAS system is only responsible for maintaining the contract information and uploading the contract scanned version to the system for archives so that market personnel can query the contract information. Therefore, the contract signing activities in the business process do not appear in the business service diagram of contract management. The purpose of market personnel creating a contract is actually to archive so that relevant personnel (mainly market personnel) can query it. Therefore, " Archive Contract " reflects the service value of this business service. The business service diagram of
Requirement order management is shown in Figure 20-11.
When sorting out the business services of the customer cooperation process, I found that the definition of concepts in several fields is not clear: What is the relationship between contracts, market demand customer demands and demand orders? What are the differences?
When we find that there are multiple confusing domain concepts that need to be clarified, we need to establish a unified language and reach a consensus on these domain concepts.
Through communication with market personnel, I found that the marketing department's understanding of these concepts is also unclear, and even used these concepts alternately in many scenarios. During the conversation, they sometimes mentioned the concept of " market demand order " . For example, when describing market demand, they will mention " entering market demand ", but at the same time, they will mention " tracking market demand orders " and " query market demand orders ". When discussing " customer demand " , they mentioned that they needed to specify " bearer " for customer needs, but did not mention this function when discussing " market demand " . This seems to be the difference between " customer demand " and " market demand ". Regarding the understanding of " contract " , they unanimously believe that this is a legal concept, which is equivalent to a cooperation agreement signed by Party B Group or Subsidiary and a client as Party A, and exists in the form of contractual requirements.
In view of the many ambiguities in these concepts, we and market personnel have sorted out the unified language and agreed that the concept of " order " (order) needs to be introduced. Order is not a demand (whether it is customer demand or market demand). It draws on the order concept in the e-commerce system and is used to describe the cooperation intentions reached by the marketing department and its customers. Each cooperation intention can contain multiple customer needs, equivalent to line items in the order. For example, the same customer may raise 3 customer needs:
(1) requires 5 senior Java programmers and 10 intermediate programmers;
(2) requires 8 junior .NET programmers;
(3) requires developing an OA system.
these three customer needs form an order. What customer needs are included in an order depends on the business background of the marketing department’s negotiation and cooperation with the customer. After
introduced the concept of orders, the difference between market demand and customer demand is clear at a glance. Market demand is the demand learned by the pre-sales personnel of the marketing department and has not been evaluated; the company does not know whether the demand can be met and whether it is worth doing. This is also the reason why the market demand does not require specifying the " demand bearer ". After the market demand is evaluated by each subsidiary and reviewed by financial personnel, it can be refined, and after sufficient communication with customers, an order is formed. Each market demand is evaluated and converted into customer demand in the order.
We still retain the concept of " contract ". " contract " field concept corresponds to the real world " contract " legal concept. It is relevant to orders, but is not essentially the same. For example, each customer requirement in an order can be borne by a different subsidiary, but the contract stipulates that there can only be one Party A and one Party B. Orders do not have those legal terms required by the contract. The content of unsigned contracts does come from the order content, but they are only part of the content of business cooperation. After the order has been determined, the marketing department staff can track the status of the order and modify the corresponding contract status when the order status changes, but the status of the contract is not consistent with the status of the order.
When executing business requirements workflows in the global analysis stage, you must use a unified language.After we visualize business services through the business service chart, we must speak out loudly for every field concept that may be ambiguity, eliminate differences and misunderstandings in a timely manner, and form a unified language within the team.
() Project Management
When the project manager (usually the project manager who designates the project) begins to initiate a service request for project establishment, a complete project management process from project establishment to project completion is formed, and its service blueprint is displayed as shown in Figure 20-12. The management process of
items items starts by project management personnel submitting the project application, and it goes through the complete life cycle of a project from a management perspective. Project managers play the role of customer in the service blueprint, and all stages of the entire process serve project managers. Such as subsidiaries, project management departments, project members and service centers, only participate in the project management process to provide interactive or supportive behavior.
project management process provides business value to project managers. If you want to reflect the business value provided by the target system to project members, you need to treat project members as customers of the service blueprint and think about its customer journey, such as the process of dealing with iterative problems. A service blueprint can be drawn for this process separately. Due to different perspectives, the identities of participating roles will also change.
3 items object management process is divided into 4 business scenarios according to different business goals: project management, project member management, project planning management and problem management. In addition, the allocation of hardware resources by the service center is a support scenario for project management scenarios and needs to be considered.
In the project management process, the business scenarios that are the same project management goals are split into two stages: the beginning and end. When determining the business service diagram of the project management scenario, it is necessary to unify the business services of these two stages to form the project management business service diagram shown in Figure 20-13. The allocation of hardware resources by
service center supports project establishment activities and allocates resources to the entire project team, and is placed in a separate business scenario as a support activity. Its business service diagram is shown in Figure 20-14.
Analyze the activities of project member management scenarios. When adding or removing team members, notifications are required through the OA system. The sending of notifications is not within the scope of the target system, nor is it initiated by a participant, but is performed after adding or removing team members. It is an execution step of a business service and does not need to be included in the business service diagram shown in Figure 20-15.
project planning management is also divided into two stages and merged into a business service diagram, as shown in Figure 20-16. The business service diagram of
problem management business scenario is shown in Figure 20-17. The acquisition of the concept of
" Question " (issue) was not achieved overnight. At the beginning, I tend to use tasks to express this concept. However, in the requirements management system, tasks belong to the same level as user story, epic, and defect. I need to find an abstract concept to cover these concepts at the same time, and thus I get the concept of " problem " . This field concept is used in Jira and GitHub requirements management tools.
When creating a problem, the project manager will specify the basic attributes of the problem, such as the title, description, problem type, etc. of the problem. So, do the iteration, owner, and reporter to which the problem belong also belong to the attributes of the problem? I was really confused when determining the business service chart for the problem management business scenario. For example, " allocation problem to iterate " and " allocation problem to project members " can be considered as editing the attributes of the problem.Since business services provide service value to roles, it is obvious that whether it is assigning a created problem to iteration or assigning it to project members to become the bearer of the problem, it has project management value. It is an independent and complete functional interaction initiated by the project manager to the target system and should be identified as two business services separately.
When determining the business services for project management, the unified language once again plays its value. When initially determining the business process of project management, the project manager needs to check the completion status of the problem to understand the iteration progress, so he named one of the activities in the process "" to check the completion status of the problem " . When identifying the business service, I think the name does not clearly reflect the service value of the business service. After communicating with the business analyst, I believe that the business service needs to clearly express the process of the problem during the iteration cycle. The accurate term is " progress " (progress), and named it " tracking problem progress " (trackingissue progress) is more in line with the unified language in this field.
(3) Training
Training is to improve the skill level of employees. Training needs to be formulated and training plans are carried out based on the employee's career planning and enterprise development. The entire management of training is the responsibility of the training specialist of the Human Resources Department. In addition to training specialists, the training process also involves department coordinators, employee supervisors and employees themselves. The system calls the training opportunities assigned to employees tickets, which is actually a metaphor for the concept of domain. The process of training specialist initiated training is actually the process of allocating tickets, and the entire process is shown in Figure 20-18.
Training specialist will set filters before allocating tickets. Filters are mainly used to filter the employee list and obtain a nomination candidate list that matches the training. The training specialist assigns the votes to the department coordinator, who then assigns the votes to department employees who are on the nomination shortlist. After receiving the training email, employees can choose " to confirm " or " to reject ". If the employee refuses, the ticket will be returned to the department coordinator, which will be redistributed by the department coordinator, and will eventually form a nomination list. During the training, every employee participating in the training needs to check in through the QR code presented by the training specialist, including the start of the training and the end of the training. After the training is completed, the training specialist can obtain an attendance list. Comparing attendance and nomination lists can get absentee list. After the training specialist confirms the absentee list, the system will add the absentees to the blacklist according to the blacklist rules. If an employee is blacklisted, he will not appear in the nomination shortlist in the future unless he is removed from the blacklist again. The training process is shown in Figure 20-19.
Figure 20-19 Training Service Blueprint
Training specialist can also set a valid date in advance when determining the training plan and allocating tickets to determine the validity period of the ticket. From the start of the training to the end of the training, there are 4 important deadlines:
q nomination deadline;
q absence deadline;
q training before the start of the training;
q training before the end of the training.
At different deadlines, the process of employees canceling tickets is different, and the rules for handling tickets are also different, as shown in Figure 20-20.
Nominated employees can cancel the ticket before the nomination deadline. After cancellation, the system will send emails to the department coordinator and employee supervisor respectively. As long as any person approves the cancellation request, it is considered that the cancellation is successful and the ticket will be restored to its available state. Employees can cancel tickets until the absence deadline.After cancellation, the system will send an email to notify the department coordinator and employee supervisors, but they do not require approval, but the training specialist is directly responsible for handling the ticket. When processing tickets, the activity policy set when allocating the ticket is first checked, either automatically processed by the system or the training specialist handles the ticket. There are three activity strategies for handling tickets:
qq share the tickets with other coordinators;
q assigns the tickets to employees;
q lets the tickets be invalidated.
Employees are not allowed to explicitly cancel tickets before the training begins. If the employee has not confirmed it after receiving the ticket, the system checks the policy set when allocating the ticket, either automatically handled by the system or the training specialist, and the policy of handling the ticket is the same as before. Once the training begins, employees are no longer allowed to cancel their tickets, and if there is any event that fails to attend, a leave application should be submitted. After assigning tickets to employees, the coordinator of the department can also cancel the allocated tickets. The cancellation process for different deadlines is different, as shown in Figure 20-21. The process of canceling tickets by coordinators of departmental coordinators is similar to that of employees canceling tickets. The difference is that it does not require approval when canceling tickets, and can be processed directly. Between nomination deadlines, there are three activity strategies for handling tickets:
q alternative list first come first served;
q alternative list is based on priority;
q alternative list is manually selected from the alternative list. The nomination alternative list (backup) here in
is the list after removing the nomination list generated by the filter set previously.
training specialists can also cancel the ticket, and the process is shown in Figure 20-22.
This execution process is almost exactly the same as the process of canceling tickets by department coordinators, so I will not repeat it here.
When analyzing the training process, I used the service blueprint and business flow chart to show the business processes of allocating tickets, training and canceling tickets, and determined the business scenarios based on the business goals of different stages. The business service diagram of
votes is shown in Figure 20-23.
When clarifying the business services of ticket allocation business scenarios, we found that there are two different business services for " vote allocation ":
q allocate tickets to department coordinators;
q allocate tickets to department employees. The allocation goals of
votes are different, and the behaviors are all allocations. Is there a problem of unclear semantics? In fact, although they are all allocation operations for votes, their business meanings are completely different from the value of the service. The department coordinator who obtains the vote is not the owner of the vote and will not participate in the training, but has the qualification to allocate the votes and can further allocate the tickets to employees. To avoid confusing these two concepts, the operation of allocating tickets to department employees can be considered as a nomination for employees. This clarifies the following concept.
q allocate tickets to department coordinator : The employee who obtained the ticket is the department coordinator, not the employee who participated in the training.
q Nominate department employee : Distribute the tickets to department employees so that he (she) is qualified to participate in the training. Although
are all department employees, they have different identities in different business scenarios of ticket allocation and training. Clarifying these identities (roles) can more accurately reflect the different relationship between department employees and training.
q candidate : Employees who use filters to filter or directly add them are all candidates for training. These candidates are eligible to be nominated for training by training specialists or coordinators, but it does not mean that the candidate has been nominated.
q Nominee : refers to the employee who obtains a training ticket and requires to participate in the training, that is, the nominated person.
q alternative : refers to employees on the alternative list. The alternative list is the list of employees who have removed the nominee from the nomination shortlist.
q trainee : The nominee confirms participation after receiving the training ticket and will become a trainee for the training.
Whether it is to clarify the meaning of "assignment" or to further refine the different identities of department employees, it is defining and refining a unified language. The determination of these unified languages needs to be immediately reflected in the business service chart. The cancellation service diagram of
votes is shown in Figure 20-24. Although the cancellation process of different participants is different, in the business service diagram, the actual business services to be executed are all "cancellation tickets". Both the training specialist and the system can handle tickets, the difference is that one is manual and the other is automatic. The triggering conditions and triggering timing of the latter are relatively complex. The description of these domain logic can be further refined through business service regulations during the domain modeling stage. The department employees who were nominated and participated in the training were called "trainees", which can better reflect their identity. The business service diagram of the training is shown in Figure 20-25.
Training business rules stipulate that if a student does not submit a training leave application or fails to pass the leave application, but has not participated in the training and has not signed in, it will be considered absent. In the service blueprint of the training process, according to business rules, absentee students will be blacklisted, but this activity is not reflected in the business service map. This is because the blacklisted student is actually a result of the "Confirm Absentee List" business service, not an independent business service.
When analyzing the business needs of EAS, it should be a natural process from business processes to business scenarios, and from business scenarios to business services. In this process, it is best to introduce "on-site customers" (a practice in extreme programming) to jointly explore business needs and sort out the overall picture of business needs in the problem space.
In order to avoid analysis paralysis, in the global analysis stage, business demand analysis can end when obtaining the granularity of business services and enter the architecture mapping stage. However, further refining business services is still a process of demand analysis. It is two parallel and uncontradictory work to carry out architecture mapping with the development team. The business service regulations obtained by refining will also be an important input in the field modeling stage. Therefore, requirements analysts can also write business service regulations for business services in core subfields during the global analysis stage. The business requirements for
constitute the EAS global analysis specification specification are as follows.
Business process
includes the core process of EAS and various specific business processes, which can be presented through business flow charts or service blueprints. It has been described in the previous article and is omitted.
Business scenarios and business services
For each specific business process, it is divided according to the business objectives, obtains each specific business scenario, and identifies business services according to the judgment standards of the business services, and presents it through the business service diagram. It has been described in the previous article and is omitted.
3 Business service regulations
refines each business service and obtains business service regulations. Enterprise application suite [1] is an enterprise-level application software developed according to the requirements of software group application informatization. The software group provides software delivery services to all industries, delivering software in various modes such as onshore, nearshore, offshore, etc. The EAS system provides a large number of simple and fast operation interfaces, allowing relevant departments of the group to handle daily affairs faster, more conveniently and more efficiently, and provide managers with decision-making references and process simplification, establish a channel for communication between the group and various departments and employees, effectively improve work efficiency, and realize information management of the entire group. EAS system has built a data sharing and business collaboration platform for enterprises, realizing the integration of human resources , customer resources and project resources . The system includes major modules such as human resource management, customer relationship management and project process management. The system users are all employees of the group, but the different roles determine the differences between their concerns. Global Analysis of In the global analysis stage, value requirements analysis is required for the target system. According to the description of the reference process model, an effective method is to help us determine the customer, vision and scope of the target system through the business model canvas. EAS is a B-side product, and its customers are actually employees of the software group. Employees have different roles, different departments, and different responsibilities, so it is very necessary to make customer segmentation . In fact, before conducting value demand analysis for EAS, we focused on investigating relevant personnel from the Human Resources Department, Marketing Department and Project Management Department. As supporters (providing department business knowledge) and beneficiaries (end users who use EAS), they each proposed business functions that meet their needs, including: q marketing department manages customers and needs, and tracks contracts; q project management department manages projects and project personnel, and tracks project progress; q human resources department is responsible for recruiting talents and managing employees' daily work including work logs, attendance, etc. When segmenting EAS customers and determining their respective value propositions , the team found that the most important stakeholder was missing: the group management. As decision makers of group business, their understanding of business goals is conducive to more accurate determination of the system vision. 20.3.1EAS case background
20.3.2EAS
1. Value Requirements Analysis
As a group company that provides software delivery services, its core productivity is human resources engaged in software development. The main work of each business department is carried out around the supply and demand of human resources. The pain point of decision makers is that they cannot quickly and intuitively understand the supply and demand of the company's human resources. For example, the customer needs the group to provide 20 Java developers at all levels. Before determining whether to sign the contract, the marketing department needs to query the group's human resources library through EAS to understand whether the existing human resources match customer needs. If it matches, each participating department needs to review the labor costs and decide the subject of the contract. If the group's current human resources cannot meet customer needs, the Human Resources Department needs to start the recruitment process early or find candidates to meet the needs from the talent reserve library. Through EAS, managers can also promptly understand the idle rate of developers, track the progress of projects, and clarify the responsibilities and quality of tasks undertaken by developers in the project.
to obtain the channel channel for business model canvas. This is because EAS is different from other innovative products. It does not require finding various channels to promote the product. It only requires the use of administrative power to require relevant departments to use it. The customer relationship derived from this is actually a further review of various roles participating in the EAS system to understand when these roles will use EAS and how to use EAS.
EAS is the group's internal system and does not involve specific revenue business. Therefore, its source of revenue is more reflected in the control and reduction of costs, and also includes how to provide better services and support for the group's software delivery business. Although the source of EAS's revenue is not obvious, thinking about it is conducive to driving our exploration of core resources and key businesses.
In order to ensure the smooth delivery of EAS, what core resources are needed? What key businesses can be provided by the delivered EAS? After determining EAS's customers, value propositions, sources of income, and other content, those involved in the business model canvas brainstorming can easily answer these questions. Since EAS mainly solves human resources problems, the important cooperation it needs in should also be related to human resources recruitment and training. Finally, EAS is an internal system of the enterprise. Before considering implementing the system, it is natural to understand the cost structure of required to develop the system. Thus, the business model canvas shown in Figure 20-4 can be obtained.
[1] For detailed requirements, design and code in this example, please search for "agiledon/eas-ddd" in GitHub to get .
Figure 20-4EAS's business model canvas
Although EAS is not an innovative product, exploring value needs through it in the global analysis stage, it will be easier to guide customers to describe their ideas in their minds and convey them truthfully through this visual form, forming a consensus on value needs to reach a consensus on the problem space.
Once the content of the business model canvas is determined, the value requirements of the EAS can be obtained based on the relationship between the various sections of the business model canvas and the value requirements as part of the global analysis specification. The value requirements that make up the EAS global analysis specification are shown below.
Stakeholders
q Group decision makers
q Subsidiary
q Subsidiary
q Human Resources Department
q Marketing Department
q Project Management Department
q Project Management Department
q q Project Management Office
q financial
q employee
q service center
q service center
system vision
Avoid information islands, realize controllability of human resources, and achieve the supply and demand balance of human resources.
3 System scope
3.1 Current status
q Created a feature team composed of project managers, business analysts, developers and testers
q Group Project Management Department is responsible for project process management
q Group already has OA system as process collaboration and message notification
q Group already has OA system as the process collaboration and message notification
q q Group has formulated the management measures for talent recruitment and project process management measures
q Software College and recruitment website resumes as the group's talent reserve library
q Employee training already cooperative training companies
q Marketing department provides a list of customers and potential customers
q Marketing department issued an administrative order by the group to promote the EAS system
3.2 Future status
q EAS system passed user acceptance on × year × month ×
q EAS system was launched online on × year × month × ×
q q is responsible for customer relationship management, project management, human resources management
q evaluates the value of the EAS system through customer satisfaction
3.3 Target List
q q reflects the supply and demand status of human resources through visualization
q manages the relationship between the group and customers and potential customers, manages market demand, tracks the contract
q manages projects and project personnel, tracks project progress
q adjusts employment needs in real time, formulates recruitment and training plans
q q manages employee attendance, work logs and other daily work
2. Business demand analysis
After completing the value demand analysis, business demand analysis can be started under the guidance and constraints of value demand.
business requirements analysis starts with the business process, which can enable the business functions of the target system to be "" " to execute a series of activities to meet the business value of the participating roles. In order to quickly grasp the panoramic view of EAS's needs, we can grasp the main process that reflects the core value of the business vision. Since EAS focuses on "'s supply and demand balance of human resources " as its core, then all the main business functions that all participating roles need to perform are related to this core value. Under the guidance of value demand, all participating roles can be abstracted into demand and supply-side in combination with supply-demand balance, and then from the perspective of supply and demand, the collaboration method and collaboration process between each participating role, as shown in Figure 20-5.
Figure 20-5 EAS's core business process
Figure 20-5 The relationship between demand and supply is clearly reflected, showing the key links of the core business process. Note that this collaboration diagram is not the current state before the project begins, but the future state of the expectation to solve the supply and demand balance problem. This collaborative relationship also embodies a systematic vision of breaking down information barriers between departments. Based on this collaboration diagram, we can express the core process of the entire system in the form of a business process diagram, as shown in Figure 20-6. The core process of
reflects the overall operation process of the business process and is a more macro business process expression. Many more detailed collaboration details are not clearly reflected, and the project management process and recruitment process are even encapsulated by "" as subprocesses. In order to explore the problem space more thoroughly, these business processes also need to be further presented. From the perspective of the target system providing services to the participant role, we present the following business processes of EAS through the service blueprint combined with the business flow chart. [1]
q For market personnel : business process for customer cooperation.
q for project management personnel : project management process.
q for training specialists : training process (training requirements are subsequent changes to demands).
[1] Due to space limitations, this chapter only provides a few typical business processes.
Figure 20-6 Swim lane diagram of the core process
Since all users of EAS are employees of the organization, if the service blueprint is used to draw the business process, the customer role is the user who initiates service requests to the target system, such as the market personnel in the business process of signing the contract, the project management process project managers and the recruitment specialist in the recruitment process.
() Customer cooperation
When market personnel initiate a service request to create market demand to the target system, a customer cooperation business process from market demand to the signing of a contract and forming demand orders is formed. Its service blueprint is shown in Figure 20-7.
Since the business rules require subsidiaries with independent legal person qualifications to be the bearer of market demand, the subsidiaries will become Party B in the contract. As customers in the service blueprint, market personnel will not participate in the signing of contracts, but are only concerned about whether the existing resources of the subsidiary can meet market demand. After signing a contract, market personnel can create demand orders through contract information and track demand orders to maintain a good relationship with customers. As front-end employees, a subsidiary needs to interact with the market personnel, but the market personnel cannot see the financial participation, because the financial accounting behavior occurs between the subsidiary and the finance as the front-end employees, so the finance belongs to the back-end employees of the service blueprint. As for internal supporters, they are either EAS itself or external systems outside the EAS range.
According to the service blueprint of the customer cooperation process, the entire process consists of 4 business scenarios: market demand management, resume management, contract management and demand order management. According to the judgment criteria of business services, judge the activities of business scenarios, and a business service diagram for each business scenario can be drawn. The business service diagram of
market demand management is shown in Figure 20-8.
For the " query market demand " business service, although it is not included in the service blueprint, when the subsidiary evaluates market demand, if this function is not provided, the specified market demand cannot be completed. The service value provided by the two is completely independent, so it is necessary to define a business service for them separately. The business service diagram of
resume management is shown in Figure 20-9.
Handler3The business process description for customer cooperation is that the system generates employee resumes, but in fact, this requires the operators of the subsidiary to interact with the system, with the purpose of exporting employee resumes, so the business services are identified to meet functional needs. The business service diagram of
contract management is shown in Figure 20-10. The signing of the
contract is carried out offline. The EAS system is only responsible for maintaining the contract information and uploading the contract scanned version to the system for archives so that market personnel can query the contract information. Therefore, the contract signing activities in the business process do not appear in the business service diagram of contract management. The purpose of market personnel creating a contract is actually to archive so that relevant personnel (mainly market personnel) can query it. Therefore, " Archive Contract " reflects the service value of this business service. The business service diagram of
Requirement order management is shown in Figure 20-11.
When sorting out the business services of the customer cooperation process, I found that the definition of concepts in several fields is not clear: What is the relationship between contracts, market demand customer demands and demand orders? What are the differences?
When we find that there are multiple confusing domain concepts that need to be clarified, we need to establish a unified language and reach a consensus on these domain concepts.
Through communication with market personnel, I found that the marketing department's understanding of these concepts is also unclear, and even used these concepts alternately in many scenarios. During the conversation, they sometimes mentioned the concept of " market demand order " . For example, when describing market demand, they will mention " entering market demand ", but at the same time, they will mention " tracking market demand orders " and " query market demand orders ". When discussing " customer demand " , they mentioned that they needed to specify " bearer " for customer needs, but did not mention this function when discussing " market demand " . This seems to be the difference between " customer demand " and " market demand ". Regarding the understanding of " contract " , they unanimously believe that this is a legal concept, which is equivalent to a cooperation agreement signed by Party B Group or Subsidiary and a client as Party A, and exists in the form of contractual requirements.
In view of the many ambiguities in these concepts, we and market personnel have sorted out the unified language and agreed that the concept of " order " (order) needs to be introduced. Order is not a demand (whether it is customer demand or market demand). It draws on the order concept in the e-commerce system and is used to describe the cooperation intentions reached by the marketing department and its customers. Each cooperation intention can contain multiple customer needs, equivalent to line items in the order. For example, the same customer may raise 3 customer needs:
(1) requires 5 senior Java programmers and 10 intermediate programmers;
(2) requires 8 junior .NET programmers;
(3) requires developing an OA system.
these three customer needs form an order. What customer needs are included in an order depends on the business background of the marketing department’s negotiation and cooperation with the customer. After
introduced the concept of orders, the difference between market demand and customer demand is clear at a glance. Market demand is the demand learned by the pre-sales personnel of the marketing department and has not been evaluated; the company does not know whether the demand can be met and whether it is worth doing. This is also the reason why the market demand does not require specifying the " demand bearer ". After the market demand is evaluated by each subsidiary and reviewed by financial personnel, it can be refined, and after sufficient communication with customers, an order is formed. Each market demand is evaluated and converted into customer demand in the order.
We still retain the concept of " contract ". " contract " field concept corresponds to the real world " contract " legal concept. It is relevant to orders, but is not essentially the same. For example, each customer requirement in an order can be borne by a different subsidiary, but the contract stipulates that there can only be one Party A and one Party B. Orders do not have those legal terms required by the contract. The content of unsigned contracts does come from the order content, but they are only part of the content of business cooperation. After the order has been determined, the marketing department staff can track the status of the order and modify the corresponding contract status when the order status changes, but the status of the contract is not consistent with the status of the order.
When executing business requirements workflows in the global analysis stage, you must use a unified language.After we visualize business services through the business service chart, we must speak out loudly for every field concept that may be ambiguity, eliminate differences and misunderstandings in a timely manner, and form a unified language within the team.
() Project Management
When the project manager (usually the project manager who designates the project) begins to initiate a service request for project establishment, a complete project management process from project establishment to project completion is formed, and its service blueprint is displayed as shown in Figure 20-12. The management process of
items items starts by project management personnel submitting the project application, and it goes through the complete life cycle of a project from a management perspective. Project managers play the role of customer in the service blueprint, and all stages of the entire process serve project managers. Such as subsidiaries, project management departments, project members and service centers, only participate in the project management process to provide interactive or supportive behavior.
project management process provides business value to project managers. If you want to reflect the business value provided by the target system to project members, you need to treat project members as customers of the service blueprint and think about its customer journey, such as the process of dealing with iterative problems. A service blueprint can be drawn for this process separately. Due to different perspectives, the identities of participating roles will also change.
3 items object management process is divided into 4 business scenarios according to different business goals: project management, project member management, project planning management and problem management. In addition, the allocation of hardware resources by the service center is a support scenario for project management scenarios and needs to be considered.
In the project management process, the business scenarios that are the same project management goals are split into two stages: the beginning and end. When determining the business service diagram of the project management scenario, it is necessary to unify the business services of these two stages to form the project management business service diagram shown in Figure 20-13. The allocation of hardware resources by
service center supports project establishment activities and allocates resources to the entire project team, and is placed in a separate business scenario as a support activity. Its business service diagram is shown in Figure 20-14.
Analyze the activities of project member management scenarios. When adding or removing team members, notifications are required through the OA system. The sending of notifications is not within the scope of the target system, nor is it initiated by a participant, but is performed after adding or removing team members. It is an execution step of a business service and does not need to be included in the business service diagram shown in Figure 20-15.
project planning management is also divided into two stages and merged into a business service diagram, as shown in Figure 20-16. The business service diagram of
problem management business scenario is shown in Figure 20-17. The acquisition of the concept of
" Question " (issue) was not achieved overnight. At the beginning, I tend to use tasks to express this concept. However, in the requirements management system, tasks belong to the same level as user story, epic, and defect. I need to find an abstract concept to cover these concepts at the same time, and thus I get the concept of " problem " . This field concept is used in Jira and GitHub requirements management tools.
When creating a problem, the project manager will specify the basic attributes of the problem, such as the title, description, problem type, etc. of the problem. So, do the iteration, owner, and reporter to which the problem belong also belong to the attributes of the problem? I was really confused when determining the business service chart for the problem management business scenario. For example, " allocation problem to iterate " and " allocation problem to project members " can be considered as editing the attributes of the problem.Since business services provide service value to roles, it is obvious that whether it is assigning a created problem to iteration or assigning it to project members to become the bearer of the problem, it has project management value. It is an independent and complete functional interaction initiated by the project manager to the target system and should be identified as two business services separately.
When determining the business services for project management, the unified language once again plays its value. When initially determining the business process of project management, the project manager needs to check the completion status of the problem to understand the iteration progress, so he named one of the activities in the process "" to check the completion status of the problem " . When identifying the business service, I think the name does not clearly reflect the service value of the business service. After communicating with the business analyst, I believe that the business service needs to clearly express the process of the problem during the iteration cycle. The accurate term is " progress " (progress), and named it " tracking problem progress " (trackingissue progress) is more in line with the unified language in this field.
(3) Training
Training is to improve the skill level of employees. Training needs to be formulated and training plans are carried out based on the employee's career planning and enterprise development. The entire management of training is the responsibility of the training specialist of the Human Resources Department. In addition to training specialists, the training process also involves department coordinators, employee supervisors and employees themselves. The system calls the training opportunities assigned to employees tickets, which is actually a metaphor for the concept of domain. The process of training specialist initiated training is actually the process of allocating tickets, and the entire process is shown in Figure 20-18.
Training specialist will set filters before allocating tickets. Filters are mainly used to filter the employee list and obtain a nomination candidate list that matches the training. The training specialist assigns the votes to the department coordinator, who then assigns the votes to department employees who are on the nomination shortlist. After receiving the training email, employees can choose " to confirm " or " to reject ". If the employee refuses, the ticket will be returned to the department coordinator, which will be redistributed by the department coordinator, and will eventually form a nomination list. During the training, every employee participating in the training needs to check in through the QR code presented by the training specialist, including the start of the training and the end of the training. After the training is completed, the training specialist can obtain an attendance list. Comparing attendance and nomination lists can get absentee list. After the training specialist confirms the absentee list, the system will add the absentees to the blacklist according to the blacklist rules. If an employee is blacklisted, he will not appear in the nomination shortlist in the future unless he is removed from the blacklist again. The training process is shown in Figure 20-19.
Figure 20-19 Training Service Blueprint
Training specialist can also set a valid date in advance when determining the training plan and allocating tickets to determine the validity period of the ticket. From the start of the training to the end of the training, there are 4 important deadlines:
q nomination deadline;
q absence deadline;
q training before the start of the training;
q training before the end of the training.
At different deadlines, the process of employees canceling tickets is different, and the rules for handling tickets are also different, as shown in Figure 20-20.
Nominated employees can cancel the ticket before the nomination deadline. After cancellation, the system will send emails to the department coordinator and employee supervisor respectively. As long as any person approves the cancellation request, it is considered that the cancellation is successful and the ticket will be restored to its available state. Employees can cancel tickets until the absence deadline.After cancellation, the system will send an email to notify the department coordinator and employee supervisors, but they do not require approval, but the training specialist is directly responsible for handling the ticket. When processing tickets, the activity policy set when allocating the ticket is first checked, either automatically processed by the system or the training specialist handles the ticket. There are three activity strategies for handling tickets:
qq share the tickets with other coordinators;
q assigns the tickets to employees;
q lets the tickets be invalidated.
Employees are not allowed to explicitly cancel tickets before the training begins. If the employee has not confirmed it after receiving the ticket, the system checks the policy set when allocating the ticket, either automatically handled by the system or the training specialist, and the policy of handling the ticket is the same as before. Once the training begins, employees are no longer allowed to cancel their tickets, and if there is any event that fails to attend, a leave application should be submitted. After assigning tickets to employees, the coordinator of the department can also cancel the allocated tickets. The cancellation process for different deadlines is different, as shown in Figure 20-21. The process of canceling tickets by coordinators of departmental coordinators is similar to that of employees canceling tickets. The difference is that it does not require approval when canceling tickets, and can be processed directly. Between nomination deadlines, there are three activity strategies for handling tickets:
q alternative list first come first served;
q alternative list is based on priority;
q alternative list is manually selected from the alternative list. The nomination alternative list (backup) here in
is the list after removing the nomination list generated by the filter set previously.
training specialists can also cancel the ticket, and the process is shown in Figure 20-22.
This execution process is almost exactly the same as the process of canceling tickets by department coordinators, so I will not repeat it here.
When analyzing the training process, I used the service blueprint and business flow chart to show the business processes of allocating tickets, training and canceling tickets, and determined the business scenarios based on the business goals of different stages. The business service diagram of
votes is shown in Figure 20-23.
When clarifying the business services of ticket allocation business scenarios, we found that there are two different business services for " vote allocation ":
q allocate tickets to department coordinators;
q allocate tickets to department employees. The allocation goals of
votes are different, and the behaviors are all allocations. Is there a problem of unclear semantics? In fact, although they are all allocation operations for votes, their business meanings are completely different from the value of the service. The department coordinator who obtains the vote is not the owner of the vote and will not participate in the training, but has the qualification to allocate the votes and can further allocate the tickets to employees. To avoid confusing these two concepts, the operation of allocating tickets to department employees can be considered as a nomination for employees. This clarifies the following concept.
q allocate tickets to department coordinator : The employee who obtained the ticket is the department coordinator, not the employee who participated in the training.
q Nominate department employee : Distribute the tickets to department employees so that he (she) is qualified to participate in the training. Although
are all department employees, they have different identities in different business scenarios of ticket allocation and training. Clarifying these identities (roles) can more accurately reflect the different relationship between department employees and training.
q candidate : Employees who use filters to filter or directly add them are all candidates for training. These candidates are eligible to be nominated for training by training specialists or coordinators, but it does not mean that the candidate has been nominated.
q Nominee : refers to the employee who obtains a training ticket and requires to participate in the training, that is, the nominated person.
q alternative : refers to employees on the alternative list. The alternative list is the list of employees who have removed the nominee from the nomination shortlist.
q trainee : The nominee confirms participation after receiving the training ticket and will become a trainee for the training.
Whether it is to clarify the meaning of "assignment" or to further refine the different identities of department employees, it is defining and refining a unified language. The determination of these unified languages needs to be immediately reflected in the business service chart. The cancellation service diagram of
votes is shown in Figure 20-24. Although the cancellation process of different participants is different, in the business service diagram, the actual business services to be executed are all "cancellation tickets". Both the training specialist and the system can handle tickets, the difference is that one is manual and the other is automatic. The triggering conditions and triggering timing of the latter are relatively complex. The description of these domain logic can be further refined through business service regulations during the domain modeling stage. The department employees who were nominated and participated in the training were called "trainees", which can better reflect their identity. The business service diagram of the training is shown in Figure 20-25.
Training business rules stipulate that if a student does not submit a training leave application or fails to pass the leave application, but has not participated in the training and has not signed in, it will be considered absent. In the service blueprint of the training process, according to business rules, absentee students will be blacklisted, but this activity is not reflected in the business service map. This is because the blacklisted student is actually a result of the "Confirm Absentee List" business service, not an independent business service.
When analyzing the business needs of EAS, it should be a natural process from business processes to business scenarios, and from business scenarios to business services. In this process, it is best to introduce "on-site customers" (a practice in extreme programming) to jointly explore business needs and sort out the overall picture of business needs in the problem space.
In order to avoid analysis paralysis, in the global analysis stage, business demand analysis can end when obtaining the granularity of business services and enter the architecture mapping stage. However, further refining business services is still a process of demand analysis. It is two parallel and uncontradictory work to carry out architecture mapping with the development team. The business service regulations obtained by refining will also be an important input in the field modeling stage. Therefore, requirements analysts can also write business service regulations for business services in core subfields during the global analysis stage. The business requirements for
constitute the EAS global analysis specification specification are as follows.
Business process
includes the core process of EAS and various specific business processes, which can be presented through business flow charts or service blueprints. It has been described in the previous article and is omitted.
Business scenarios and business services
For each specific business process, it is divided according to the business objectives, obtains each specific business scenario, and identifies business services according to the judgment standards of the business services, and presents it through the business service diagram. It has been described in the previous article and is omitted.
3 Business service regulations
refines each business service and obtains business service regulations.
3.1 Customer cooperation
3.1.1 Market demand management
(1) Create market demand
Service number: EAS-0001
Service description:
As a market person
ml3 I want to create a market demand
In order to understand the status of market demand at any time
Trigger event:
Market personnel enter market demand, click the "Create" button
Basic process:
. Verify the entered market demand, including the demand name, description, customer, notes
. Generate market demand numbers
3 according to the rules. Verify whether the market demand name already exists
4. Create market demand
alternative process:
a. When the market demand name already exists in the system, give prompt information
4a. If the market demand creation fails, give the reason for failure
acceptance criteria:
. The names of market demand can only be Chinese, English or numbers, and the length does not exceed 50 characters. You cannot repeat
. The market demand entered must include the market demand name, description and customer. The customer is an existing customer in the system. The note is optional
3. The market demand numbering rules are: EAS- Customer ID- self-growth number, and the market demand number does not allow duplication of
4. Market demand was successfully created
3.1.2 Contract Management
(1) Archive Contract
Service Number: EAS-0011
Service Description:
As a market person
As a market person
html l3 I want to archive the contract
so as to save the contract copy and avoid cooperation disputes
trigger event:
Market personnel select the contract document, click the "Upload" button
Basic process:
. Verify the validity of document types
. Upload the contract document
3. Save the contract document
4. Update contract information
Replacement process:
a. If the uploaded document type is not the PDF document, give prompt information
a. If the uploaded document exceeds the file size specified by the system, give prompt information
3b. If the file transfer fails when uploading the contract document, the reason for the failure is given
4a. The contract information is updated failed and the reasons for failure are given
acceptance criteria:
. The archived contract document can only be PDF file, and the extension of the document file can only be verified
. The main folder of the server archive is contract/archive. When archiving and saving, you need to verify whether the folder exists. If it does not exist, you need to create the folder
3. Create a subfolder for the contract archive file, the subfolder name is contract ID
4. If a file with the same name already exists in the specified folder during archive, it is the "Save As" operation, and the current file name is added with "()" as the suffix
5. The archive file attribute of the contract adds the archive folder path
…
3.3 Project management
…
3.3 Project member management
(1)Add project member
Service number: EAS-0105
Service description:
As project manager
As project manager
As project manager
html l2 I want to add project membersso as to manage project members
Trigger event:
Project manager selects employees and project roles, click the "Add" button
Basic process:
. Verify that employees work in other projects
. Join the project team and become project members
3. Modify the work status of employees
4. Send an email to notify employees
5. Add project experience to employee resumes
alternative process:
a. If the selected employee has joined other projects, give a prompt
a. The employee addition failed and the error message was given
5a. If the employee already has experience in the project, ignore the acceptance criteria of
:
. The selected employee should be in the "on bench" status
. After an employee is joined to the project team, his status should be changed to "in-project"
3. The project experience information in the employee resume cannot be repeated
4. Project experience in employee resumes includes: project name, project description, project role
3. The identification of problem space in the analysis stage of the molecular field
full bureau is also the identification of customer pain points and system value.The reason for developing a target system is to solve customers' pain points and provide customers with business value. In the process of identifying pain points and values, needs to always start from business expectations and vision and communicate with different stakeholders in order to achieve a common understanding of the problem space.
For EAS, if the group's decision-making level wants to solve the fundamental pain point of "supply and demand balance", it needs to timely understand which customer needs are currently and which human resources are available. This requires breaking the information barriers between the marketing department, the human resources department and the project management department, counting market demand, human resources, and project information, providing intuitive analysis results, and then providing support for management decisions based on these analysis results. We need to understand the pain points and value demands of department employees for these major departments. The pain point faced by employees of the marketing department (market personnel) is that they cannot efficiently maintain good cooperative relationships with customers through manual management. Therefore, their value demand is to improve the efficiency of customer relationship management, so that they can quickly respond to customer needs, keenly discover potential customers, grasp customer dynamics, and then carry out targeted marketing activities for potential customers. The marketing department employees hope to establish a fast track to promptly clarify whether the project undertaker (i.e., subsidiary) can meet customer needs and reduce market costs. The marketing department also needs to accurately grasp the progress of demand, follow up on the contract signing process, and improve customer satisfaction. The pain point of the employee of the Resources Department (recruitment specialist) is that it is necessary to formulate a reasonable recruitment plan so that the hired talents meet the growing customer needs without causing a large amount of human resources to be idle, resulting in wasting the group's labor costs. From the perspective of fine management, starting from the potential market demand, the recruitment specialist needs to work with the marketing department and subsidiaries to determine the recruitment plan. The basis for formulating a plan is the potential human resource needs, including requirements for skill level and language skills. It is also necessary to consider the current employee utilization rate of the subsidiary and refer to historical supply and demand relationships to make as accurate predictions as possible. Employee skills are an important output resource. The human resources department needs to formulate training plans based on customers' requirements for personnel capabilities, organize employee training within the enterprise, and improve employee skills, so that the maximum human resources value can be output at the minimum cost. Therefore, the value demand of the Human Resources Department is to make recruitment and training plan forward-looking and accurate, and to better maintain a balance between supply and demand between customer needs and human resources.
Project Management Department is responsible for the enterprise's "production management", and the management of projects and project members is directly related to customer satisfaction. Before there was no EAS, the marketing department was not understanding the implementation of the project signed. Even if the marketing department took the initiative to communicate with the project management department, the project management department could not provide accurate project information, let alone understand the progress of the project in a timely manner. Therefore, the value appeal of the marketing department is to understand the project progress to promote a good cooperative relationship with customers, while the value appeal of the project management department is to promptly understand the implementation of the project process, discover unhealthy projects, and avoid the risk of delayed delivery or even failed delivery through project management methods, and improve the success rate of the project.
recognizes pain points and values, and can use this to subdivide the problem space in the field. And distinguish core issues from secondary issues by identifying core subfields, general subfields and supporting subfields.
is used by in EAS to serve the software group's application informationization. On the basis of identifying pain points and value, we can determine the subfield of the entire problem space from the functional classification strategy combining business functions and business concepts. The core subfields obtained from this are as follows:
qq market demand management;
q market demand management; ml5
qclient relationship management;
q employee management;
q talent recruitment;
q skill training;
q project progress management.
In addition to these core subfields, such as organizational structure, authentication and authorization, all belong to common subfields, and each core subfield needs to call the functions provided by these subfields. Note that although the functions provided by the general sub-field are not the core of system services, the lack of these functions makes the business unable to flow. The reason why these functions are not identified as core subfields is because there is an understanding and analysis of the problem space. For example, organizational structure management is the key to ensuring the operation of business processes and employee management. User authentication and authorization are to ensure the security of system access. Neither directly provides business value to the business vision of "supply and demand balance", so it is not a pain point that stakeholders need to solve urgently.
When distinguishing the stakeholders of the system, the service center, as the business department participating in the EAS, mainly provides workstations and hardware resources for projects and project personnel, and what we need to solve is the problem of resource allocation. The introduction of this function can certainly help enterprises reduce operating costs, but it has no direct relationship with the system vision in value needs, so this sub-field can be used as a supporting sub-field. In addition, message notifications and file upload and download also support execution activities in most core areas and belong to independent support sub-fields. The sub-domain mapping diagram of
EAS is shown in Figure 20-26.
decomposed the problem space, allowing the team to reach a common understanding of EAS, and the identified sub-fields will also be used as references for the architectural scheme formed by the solution space, especially for the system hierarchical architecture. Sub-fields are also part of the global analysis specification.
This article is excerpted by "Deconstruction Field Driven Design". If you need to obtain the full electronic version, you can follow the editor and send a private message in the background: "333" to obtain it.
This book comprehensively explains the knowledge system of domain-driven design (DDDD), and covers the main models and mainstream methods of domain-driven design. On this basis, it proposes the "domain-driven design unified process" (DDDUP), which divides the entire software construction process into three stages: global analysis, architecture mapping and domain modeling. In addition to giving many cases to explain the methods and models in the unified process of field-driven design, this book also fully demonstrates how to implement and implement the unified process of field-driven design through a real and complete case. In order to better use the unified process of domain-driven design, this book also pioneered the introduction of methods and models such as business services, diamond symmetric architecture, domain-driven architecture, and service-driven design, and summarizes the domain-driven design capability evaluation model and reference process model. The complete set of method systems proposed in this book have been promoted and implemented in multiple projects.
This book is suitable for software architects who want to understand the nature of software architecture and improve their software architecture capabilities, developers who want to improve their field modeling capabilities and polish their software design capabilities, business analysts who want to master business analysis and modeling methods, and software industry practitioners who want to learn field-driven design and apply it to the reading reference of software industry practitioners in the project.
The reason for developing a target system is to solve customers' pain points and provide customers with business value. In the process of identifying pain points and values, needs to always start from business expectations and vision and communicate with different stakeholders in order to achieve a common understanding of the problem space.For EAS, if the group's decision-making level wants to solve the fundamental pain point of "supply and demand balance", it needs to timely understand which customer needs are currently and which human resources are available. This requires breaking the information barriers between the marketing department, the human resources department and the project management department, counting market demand, human resources, and project information, providing intuitive analysis results, and then providing support for management decisions based on these analysis results. We need to understand the pain points and value demands of department employees for these major departments. The pain point faced by employees of the marketing department (market personnel) is that they cannot efficiently maintain good cooperative relationships with customers through manual management. Therefore, their value demand is to improve the efficiency of customer relationship management, so that they can quickly respond to customer needs, keenly discover potential customers, grasp customer dynamics, and then carry out targeted marketing activities for potential customers. The marketing department employees hope to establish a fast track to promptly clarify whether the project undertaker (i.e., subsidiary) can meet customer needs and reduce market costs. The marketing department also needs to accurately grasp the progress of demand, follow up on the contract signing process, and improve customer satisfaction. The pain point of the employee of the Resources Department (recruitment specialist) is that it is necessary to formulate a reasonable recruitment plan so that the hired talents meet the growing customer needs without causing a large amount of human resources to be idle, resulting in wasting the group's labor costs. From the perspective of fine management, starting from the potential market demand, the recruitment specialist needs to work with the marketing department and subsidiaries to determine the recruitment plan. The basis for formulating a plan is the potential human resource needs, including requirements for skill level and language skills. It is also necessary to consider the current employee utilization rate of the subsidiary and refer to historical supply and demand relationships to make as accurate predictions as possible. Employee skills are an important output resource. The human resources department needs to formulate training plans based on customers' requirements for personnel capabilities, organize employee training within the enterprise, and improve employee skills, so that the maximum human resources value can be output at the minimum cost. Therefore, the value demand of the Human Resources Department is to make recruitment and training plan forward-looking and accurate, and to better maintain a balance between supply and demand between customer needs and human resources.
Project Management Department is responsible for the enterprise's "production management", and the management of projects and project members is directly related to customer satisfaction. Before there was no EAS, the marketing department was not understanding the implementation of the project signed. Even if the marketing department took the initiative to communicate with the project management department, the project management department could not provide accurate project information, let alone understand the progress of the project in a timely manner. Therefore, the value appeal of the marketing department is to understand the project progress to promote a good cooperative relationship with customers, while the value appeal of the project management department is to promptly understand the implementation of the project process, discover unhealthy projects, and avoid the risk of delayed delivery or even failed delivery through project management methods, and improve the success rate of the project.
recognizes pain points and values, and can use this to subdivide the problem space in the field. And distinguish core issues from secondary issues by identifying core subfields, general subfields and supporting subfields.
is used by in EAS to serve the software group's application informationization. On the basis of identifying pain points and value, we can determine the subfield of the entire problem space from the functional classification strategy combining business functions and business concepts. The core subfields obtained from this are as follows:
qq market demand management;
q market demand management; ml5
qclient relationship management;
q employee management;
q talent recruitment;
q skill training;
q project progress management.
In addition to these core subfields, such as organizational structure, authentication and authorization, all belong to common subfields, and each core subfield needs to call the functions provided by these subfields. Note that although the functions provided by the general sub-field are not the core of system services, the lack of these functions makes the business unable to flow. The reason why these functions are not identified as core subfields is because there is an understanding and analysis of the problem space. For example, organizational structure management is the key to ensuring the operation of business processes and employee management. User authentication and authorization are to ensure the security of system access. Neither directly provides business value to the business vision of "supply and demand balance", so it is not a pain point that stakeholders need to solve urgently.
When distinguishing the stakeholders of the system, the service center, as the business department participating in the EAS, mainly provides workstations and hardware resources for projects and project personnel, and what we need to solve is the problem of resource allocation. The introduction of this function can certainly help enterprises reduce operating costs, but it has no direct relationship with the system vision in value needs, so this sub-field can be used as a supporting sub-field. In addition, message notifications and file upload and download also support execution activities in most core areas and belong to independent support sub-fields. The sub-domain mapping diagram of
EAS is shown in Figure 20-26.
decomposed the problem space, allowing the team to reach a common understanding of EAS, and the identified sub-fields will also be used as references for the architectural scheme formed by the solution space, especially for the system hierarchical architecture. Sub-fields are also part of the global analysis specification.
This article is excerpted by "Deconstruction Field Driven Design". If you need to obtain the full electronic version, you can follow the editor and send a private message in the background: "333" to obtain it.
This book comprehensively explains the knowledge system of domain-driven design (DDDD), and covers the main models and mainstream methods of domain-driven design. On this basis, it proposes the "domain-driven design unified process" (DDDUP), which divides the entire software construction process into three stages: global analysis, architecture mapping and domain modeling. In addition to giving many cases to explain the methods and models in the unified process of field-driven design, this book also fully demonstrates how to implement and implement the unified process of field-driven design through a real and complete case. In order to better use the unified process of domain-driven design, this book also pioneered the introduction of methods and models such as business services, diamond symmetric architecture, domain-driven architecture, and service-driven design, and summarizes the domain-driven design capability evaluation model and reference process model. The complete set of method systems proposed in this book have been promoted and implemented in multiple projects.
This book is suitable for software architects who want to understand the nature of software architecture and improve their software architecture capabilities, developers who want to improve their field modeling capabilities and polish their software design capabilities, business analysts who want to master business analysis and modeling methods, and software industry practitioners who want to learn field-driven design and apply it to the reading reference of software industry practitioners in the project.
