Text four business modeling period (on)
content:
· All projects have business modeling periods
· Modeling principle
· About the author
Before a large-scale demand research, there is an important job to do. This work is very small in the project, but it is very important. Different people, different methods have different descriptions of this work. In our article, according to UP thinking, it is called "business modeling".
All projects have business modeling periods
1. What is business modeling?
Business model, business modeling is a complex process, which is difficult for the next accurate definition. Explain it in the glossary of RUP:
"Contains all modeling methods that you can use to visualize your business. These are the subsets of the method you can use to perform business engineering."
As can be seen from the definition, it is a collection of modeling methods to model business. This work may include modeling of business process, modeling, improving business processes, field modeling, etc.
2. Why do you want to model your business?
Master Brooks said that more than 30 years have changed a variety of repair modifications, which has become unrecognizable, like a group of monsters, difficult to tame.
Master Rogerson also said the Application IS A Rock in The River of Change. (Application (System) Became the plain in the trend of the change).
For many companies, there is an integral of information systems in the universities of the company seem to have become a luxury. There will be some application systems in the enterprise, and there will be automated operations of the auxiliary enterprise. When the company's information is hoping to integrate the current information system, they can be disappointed when they can cooperate with the development of the company. Most applications lack a unified interface, it is difficult to integrate.
In the bank we conduct project development, we also discovered this problem, and the system of different departments could not be interconnected, and cross-sectoral business processes must be handled.
Previously, the development of applications was built based on sectoral functions. Simply establish an application system only for the purpose of solving purposes. So this way is established in this way is based on a specific functional area (FUNCTION AREA). As for how to make multiple applications within the company work together, they are not in the designer's consideration. As the company's development, it will find that the company needs to change to adapt to market changes, and the original series of applications have become the road to the company's development, which makes the company have to return to the manual era.
In response to this situation, there is no corresponding solution? The solution is from the business modeling, not from the lower level (department-level or less). Through the use case analysis technology, establish a business model of the company, perform appropriate cutting, select a stable software architecture, analyze the business entity of the company (the small inability to be small in business entry, abstract or concrete, such as accounts, contracts, etc. It is called Business Object, which is based on this, assembles the component, implements the corresponding three-layer structure to establish an application system for a particular functional area.
The enterprise application system made in such a process, regardless of the size of the department, or has an enterprise-level, there is room for extension. The three-layer architecture based on the components, and it is possible to better cooperate with the business of the company (the cost of the corresponding change is small). The first step in the whole process is business modeling. In the previous period, China is very popular with the name of the BPR (Business Process Re-Engineering). The term R (RE-ENGINEERING) in this term is proposed by Dr. Hammer, indicating that companies must promote four levels of redesign: Re-position, Re-Organization, Re-System, Re-Vitalizing Rehabilitation Project P (Process) in the name is managed by sales, purchasing to finance, all levels, and strive to reduce costs, improve output, and must have precisely designed enterprise management procedures. This word is currently in series with ERP, has become the pre-engineering of ERP, but also becomes the most important factor in ensuring ERP to establish a corporate perfect management system to support high performance. In fact, this BPR is the business model we talk.
It can be seen that business modeling is highlighted in ERP engineering, and BPR in ERP has become an independent discipline. Not only that, even in ordinary information systems, business modeling is also very important, alone, just their scale. At this point, you may not understand, if you just establish an application for the business automation of the company, don't you just turn it out? There are two reasons here, one is that the original business model is very good in people-oriented environments, but it will not be appropriate to move this model. People's capabilities and computers have a lot of access, so the process must be adjusted to accommodate the computer; the second reason is the application system that avoids sector-level, partial functional areas that have been mentioned above.
In RUP, business modeling is highly emphasized as a downstream process: business model is an important input of a demand workflow to understand the needs of the system. Business entity is an input to analyze design workflows to determine entity classes in the design model. (RUP)
3. Demand and business modeling
Business modeling is the initial stage of demand engineering and the initial phase of the entire project. It is to be pointed out that the span of business modeling time has a big difference in different projects. In some projects, such as large ERP systems, it may take a few months. For ordinary projects, the time of business modeling may only take a few days.
Demand is technologically independent. There is no meaning in discussion technology during the demand phase. That will only make your attention. The implementation details of technology are analyzed after the analysis, and the design phase needs to be considered. In the business modeling stage, it is not only necessary to ensure the technical innocence of the demand, but also to ensure that your needs should not be detailed. Because of the business modeling phase, the most important thing is to understand the full picture of the business, and in-depth details will be wasted time and energy. To know, discuss business details in an enterprise, even if you give you a month, you have no need to end.
In practice, these two points are difficult. For example, companies have a system originally, this has to be compatible with your discussion and new and old systems. At this time, it is important to pay attention, if you are a systematic architecture, then it is a category of technology. If you will discuss the details of each specific module / component, it is not the technical independent, and it is also in-depth details. . On the issue of not deep details, it is often difficult for you to prohibit the status of the project, and you will not discuss some relevant business details. At this time you can record these details, then return to the business modeling. 1A Stakeholder Is Defined As Anyone Who is Materially Affected by the Outcome of the Project.
All people involve all people who have affected by the project.
4. Main tasks during business modeling
The common vision of the project is: If you want to succeed, you can freely open the support of the project. At the beginning of the project, whether the project is involved or developers, the project's task, the scope is ambiguous. But with the deepening of the project, the original vague scene will slowly clear and stereo. But in order not to waste time, we need to erect a common vision before project injection.
The erection of the common vision can not be as simple as imagined, because every public is concerned about his own interests, all have its own evaluation standard. You can listed everyone on the whiteboard, then discuss each item by item, make a correction, until everyone's opinion is consistent. In the erection of the common vision, there are two things that have been made, and the project scope and high-level demand are available.
Project Scope: What should I do, what should I do, I need to have a clear definition at the beginning. For the demand within the project, don't let go, and the project is not to care. Although sometimes, the variation of the range will benefit the project itself, such as the customer's reasonable requirements or changes in market target customers, this change should be carried out under the premise of "resource support" and "approval".
The description of the project range can be carried out by statement and illustration. I suggest you use the illustration. Because the statement statement is relatively vague. For example, I often hear a customer. "I want to build our company's e-commerce system." This sentence is a vague, your e-commerce system is what products sell? " What customers are facing? Do you want to support online payment? According to these questions, this statement can be further modified, "establishing online ordering systems, for the current product product product of the current target customer sales company." This is clear. However, the way the image will be better, on the selection of the figure, you can use the DFD map or use an example. Depending on the experience, DFD graph is relatively easy to accept customers.
High-order demand: This part we will discuss in detail below. Since it is a high-order demand, you can't discuss excessive details. When discussing high-order demand, try to ensure the quick discussion of the system's profile, establish a demand model, resulting in the consistent pass of the project.
Support: In order to ensure the smooth progress of the demand plan, the support of the project is critical. You can choose to tell the project at this time, the rights and obligations of the project, as well as the rights and obligations of developers. In this regard, I don't want to say more, you can refer to the second chapter of "Software Demand". The main thing is "The right to change the demand, and it is necessary to undertake the obligation to explain demand to developers." The rights and obligations of developers are just the opposite of the people.
Business Modeling Conference: All of this is conducted through business modeling meetings, and other conferences are that this conference requires all projects to participate, if you can't get the opinions of all projects, it is not perfect. The most important tools in the meeting are whiteboards, and an excellent quick book is also necessary. Modeling principle
5. Use cases in business modeling
In the previous one, we discussed a lot of knowledge, but when we implemented it in the enterprise, we often feel difficult to grasp the use of enterprises, this is also mentioned in the misunderstanding of the use case. In the actual situation, you may have a very detail of the classification of roles, division of use cases, grasp of grasping, etc., the actual thing is very impact on your project.
In RUP, there are a variety of concepts to support the implementation of use: Business Actor, Business Entity, Business Use Case, Business Worker, Business Use Examples (Business Use- Case instance). In order to be more clearly displayed, we adopt a representative of the UP method - RUP. However, in practice, it is necessary to determine the specific situation. The concepts mentioned here are to help you understand the modeling process, not let everyone move hard.
When we don't understand the system, we will see the system as a big black box. This big black box we will call him business domain, seeing its exterior as a business. Business environment. Those who have relationships in the business environment and the business domain (may also be object) are called business actors. In actual examples, we may put credit services (note is not credit business systems, here is business modeling, and the system is not existed.) Is called business domain, we have been investigating, discovering our usage and credit business have customers, Other systems used by the People's Bank, the Foreign Exchange Authority, other banks, and credit departments, and other departments within the bank. So these people (things) are the business leads. Examples of business leads generally include clients, suppliers, partners, potential customers ("Markets"), local governments, colleagues who have not modeled in their business. It must be noted that the specific type of user represented by the business lead is not a particular user. One role may have many actual users, and an actual user may also have a lot of roles.
The definition of business use cases and business case instances in RUP is as follows:
A business use-case instance is a sequence of actions performed in a business that produces a result of observable value to an individual actor of the business. A business use case defines a set of business use-case instances. A business use case has a Name.
Business use examples are a series of actions performed in the business, which produce results with visible value for the individual protagonist of the business. The business usage defines a set of business example instances. Business use has a name.
Just starting everyone may have questions about business use cases and business case instances. In fact, they can regard them into the relationship between base classes and subclasses. In a business, there may be a lot of workflows. For example, when you go to McDonald's, the workflow of the point of the panter and the oat cattle is different. Many processes have caused a certain difficulty in the investigation of demand. Even the oldest philosophy also tells us that the surface phenomenon is complicated, the essence is simple. In order to simplify demand work, we hosted the mergence and point fries into order. In this way, ordering is a business use case, and the merger, the potato is the corresponding business case example. Business case
The concept of business roles and business leads is also very easy to make people don't touch your mind. In fact, their English is more likely to understand their differences: Business worker, business actor. Worker has the meaning of workers, and actor has the meaning of participants. So the difference is that one is internally, one is outside. Business roles are people who implement business use cases, the business leads are people related to business. For example, for the bank's bill of payment, the customer is the business lead, he is related to the business. The parish is a business role because they are people who implement business use cases. In RUP, the two are defined as follows:
A Role Or Set of Rolis In The Business. A Business Worker Interacts Wells..................
Business role represents one or a set of roles in the business. When participating in business case implementation, a business role and other roles interact, and manipulate business entities
................... ..
The business lead represents a business-related role, which is served by someone or object in the business environment.
Business role
Business lead
The distinguished business role and the business leads are required to see the environment. When you develop a company's ERP system, the staff of the department belongs to the business role, and when you develop a department-level application, employees of other departments may belong to the service lead.
Business entities, in some articles, known as business objects. Whether it is called, the meaning of the representation is the same. For example, in this example of bank credit, we involve a lot of business entities: contract, single loan, customer, etc. So business entities are those very basic elements in the enterprise. If you feel that the example of bank deposit is not understood. You can imagine menu in the restaurant, burgers, etc. are business entities. In RUP, business entities are defined as:
A Business Entity Represents A "Thing" Handled or Used by Business Workers.
Business entity represents "things" that is handled or used by business roles.
Business entity
Upon recently, we discussed demand variability. Compared to the continuous change of demand, it is possible to exist in a business entity object in a considerable period of time. Airlines are discounted today, and tomorrow is not hit, there is a discount, and it is difficult to fold. However, the ticket has never seen any changes, and there is only one of the same properties: price, flight, departure, destination. Therefore, the business entity is relatively stable. This is very significant for us:
"A business entity often represents a certain thing for multiple business use cases or use case instances. Therefore, the survival of business entity objects is quite long. In general, a good business entity does not contain the main body and method of use. Information. "(RUP) The business use case consists of business entity will be stable. In the past, the development method used a module-based method, and when the demand changes, the module had to be rewritten. If a stable business entity is used to realize business use cases, the change of business use cases only need to be combined with business entities. Of course, there are still many technologies that need to be realized and is not as simple. You know, four modernization can be implemented one day.
There is also an important reason for using business entities: the characteristics of business entities determine it has natural reuse. Just as McDonald's sales system, there are Hamburg entities, and there are also in the production system. God, this world is really beautiful!
A big confusion using business entities should be made as class or attributes. This depends on the level of importance of this entity on the business environment. A customer is a very important class in the bank credit department, and in the deposit department is just a attribute of the credit verification example. This problem is very important. The mistakes in design may lead to a great pain in the future system improvement. For example, the business entity of this design is designed to be attribute, and it has to face the adjustment and system modification of the database when the attribute is increased in the future.
6. Establish a business case model
Business Use-Case Model defined in RUP as:
The Business Use-Case Model IS A Model of The Business Intended Functions. The Business Use-Case Model Is Used As An Essential Input To Identify Roles and Deliverables in The Organization.
The business case model is a model for explaining business expectations. As a core input model, the business use case model is used to determine the various roles of the organization and the deliverable workpiece.
As can be seen from the definition of the business case model, it is the core of the company, the most summary business description. It is mainly composed of business use cases and business leads. Its main purpose is to explain how customers and partners do business. It describes the main way of business is through business use cases. The figure below shows the illustration of the business case model in RUP.
Business case model
From the figure, we can also see that the business use case model includes a set of business cases. This is because the business in the enterprise is usually constructed of multiple instances of a number of business use cases. The enterprise workflow formed by these business use cases may be triggered by the business protagonist, or may be triggered by business rules 2.
2 Business Rules: Business rules are a statement that must be observed. Business Rules Are Declarations of Policy OR CONDitions That Must Be Satisfied.)
The business case model is actually a description of the business operations. In order to establish a complete and accurate enterprise use model, you should focus on the business's business, but should not focus on how to do it. Although this may generate some business cases, the conflict of business, but RUP's thoughts are iterative, which can be perfect in the next iterative cycle.
The business case model is the closest computer model with the business business. Many of their thoughts and business days are as follows. In the daily activities of the company, there may be many kinds of services. In some articles that tell the ERP ideology, it usually emphasizes three categories:
One is work closely related to the main business, such as banking department, credit department, deposit department, etc. This kind of work passes the person's labor, converting a resource into another resource, producing value.
One is a management type, such as the company's management, finance department, etc. This work does not produce value, but it has been guided, managed, and detects the first work to increase the output value of the first work.
There is also a support work, such as system management, security, etc. It is not very important and has the nature that supports other work.
This classification can also be used in business models. Through this classification, you can better grasp the core business use case, and make the foundation for the next step.
There are many business use cases that are triggered by the business lead, and the business use cases related to the business leads in RUP are also referred to as core business cases. This emphasizes the purpose of building a business model to provide users-centered service. This is also what we should pay attention to when we build a business case.
Of course, sometimes the trigger of business use cases is to generate the result of the user needs. For example, the market research behavior of the company is not triggered by the business lead, but the company has accumulated a large number of user requests. For managed, support, non-direct and business leads, there are also their specific business leads, such as management type business case needs and board of directors, support for business use cases and suppliers Contact.
After establishing a basic business case model, it is very necessary to refine this model. At this time, in the previous chapter, the extension and use relationship we introduced in the previous chapter have used the land. In addition to these two relationships, there is a new relationship.
7. Use relationships in business modeling
Generalization: According to my understanding, you can see it as a similar relationship with our more familiar inheritance relationship. The word Generalization is generalized, summary. It is a relatively abstract word. Although it is very similar to inheritance relationship, they are different in use in the use of the environment and the purpose. The following figure describes the generalization relationship between four business entities:
When you go to McDonald's (don't misunderstanding, I am not very often going), I will choose Mai Xiang Chicken Hamburg, Mai Xiangfish Hamburg or Hamburg. However, it doesn't make sense to establish a business entity for these three burgers. So you can summarize them into a business entity of Burgers. The same reason, some common attributes and behaviors can also be summarized in the business process of the enterprise. In order to avoid multiple documentation, you can put a common behavior in a separate business case. The use case example of the execution sub-case will follow the event stream of the parent case, while inserting an additional behavior or modifying the behavior defined in the sub-event stream.
8. Selection of methods
The above principles I have used UP methods. However, in addition to the UP method, there are XP, FDD, etc. Therefore, when doing business modeling, you should choose the appropriate workpiece according to different methods. For example, material and function. The quality of the method is not the focus of our article discussions, I will discuss the method in another article. It is necessary to emphasize that the RUP's workpiece discussed above is just to learn, so it defines a more complex workpiece and distinguishes the difference between them. But in practice, there is no need so much workpiece, which will only make your project involvement and developers confused. The difference between these workpieces is as long as you are in your heart. As for specific practices, we will discuss in the next article.
