"Drilling" and "jumping out" -- how can we control the requirements of information systems?

"Drilling" and "jumping out" -- how can we control the requirements of information systems? Author: Shang Rongrong Difficult to graspEnterprise Informatization is a complex system engineering that involves all aspects of management, such as strategic management, process control, personnel management, and performance appraisal. It involves various internal departments, such as the manufacturing department, marketing department, planning and operation department, and storage department. It involves all levels of personnel, such as IT engineers, frontline operators, middle managers, and senior leaders. Informatization is also an important project. Well-built projects can effectively improve operational efficiency, reduce management costs, strengthen internal control, and enhance core competitiveness. Poor Construction, it may lead to management chaos, fluctuations in people's minds, decline in production, shrinking the market, and weaken the company's original competitive advantage. For this reason, most enterprises that are determined to implement informatization are waiting to purchase advanced software and professional services at any cost. However, the results are far from satisfactory. Many shelved systems and failure cases show that informatization is not that easy. Why is informatization a perfect match for enterprises? The key lies in inaccurate and thorough understanding of requirements. Ambiguous demands and frequent changes are the culprit of many failure cases. "Jump out" and "drill in"Demand is the foundation of Information Technology. Leaving the demand system, there is no way to talk about it. When Planning Informatization Construction, enterprises must know what their fundamental needs are, whether they want to improve efficiency, optimize the process, or strengthen management. During System Selection and research, you must pay attention to the specific business status and improvement requirements, and discover potential needs hidden under the representation. Only by fully understanding the real needs of all parties can you ensure that the system can meet the needs of enterprises after implementation. To put it simply, we need to "Jump out" in the overall planning, grasp the most fundamental purpose and motivation, understand the real thoughts behind the details, and "Jump Out" from the limited thinking, design and plan the informatization blueprint of the entire enterprise at the height of the enterprise. Even for an application system, the ability to "Jump out" is crucial. You can grasp what you really want to achieve through the trivial and meticulous requirements and descriptions of users, it can avoid excessive entanglement in details and promote the promotion and implementation of the entire system. Besides, after "drilling" and determining the general direction of informatization, specific application system construction will follow. We need to have a detailed and in-depth understanding of the actual needs of users, without any doubt, I tried Sun Wukong's eye-catching eyes. From a brief description of the user's data, I grasped the implicit requirements that he might have become accustomed to but are crucial to the system. By mining all potential demand points, we can clear the obstacles for system implementation and launch, and lay a solid foundation for the stable operation of the system. Continuous "drilling"The truth is not unknown. We use specific cases to deepen our understanding. One afternoon, Mr. Wang from the sales department and Mr. Zhang from the Information Department were discussing the business system requirements in a conference room. Mr. Wang: "The format of the Order application interface is the format of this form. I hope that after the ordering staff of each branch enter the system, the system will automatically identify their branches and optional products, select the product code by specifying the level-1 category and level-2 category, and enter the number of orders for this time." John: "Well, the system can recognize the identity of the Creator based on the user ID ." Mr. Wang: "I want the system to automatically generate the unit price, OK ?" John: "The unit price is determined based on what conditions. Is it the product code ?" Mr. Wang: "Yes, I want to maintain it by myself. Different codes have different promotion prices ." Xiao Zhang: "It should be maintainable ." Mr. Wang: "That's too good. Can the system automatically calculate the total price? The unit price * is used to calculate the quantity, and the quantity is used to calculate the order quantity ." Xiao Zhang (a bit strange): "What is the order quantity? Is there another number? Isn't it just the number of orders for this time ." Xiao Wang (stunned): "Ah? There is also the number of gifts we will return to the Branch. The variety and quantity of gifts are different in different time periods. It is best to let me maintain this ." Xiao Zhang (sighs): "Well, that is to say, the number of products that the branch finally receives is the number of products he paid to order, that is, the number of orders ordered this time, plus the number of gifts, right?" Mr. WANG (nodded): "Yes ." John: "So what is the number of gifts calculated based on? Is it the product code? Or the order quantity ?" Mr. Wang: "Well, each product code varies with the order quantity and the return quantity ." Xiao Zhang (rubbing his forehead): "Can you give an example ?" Mr. Wang: "For example, if the branch company subscribes to 100 A products, we will return 10%, 1000, and 180 ." Xiao Zhang: "return by order range ." Xiao Wang (hesitated): "It's not all. Sometimes, if the number is less than 100, 10% is returned. If the number is equal to 100, 15 are returned. It comes in a tiered manner ." Xiao Zhang (for a moment): "Well, in short, you maintain a quantity range, er, that is, the tier, and then give the number or percentage to the branch for each tier, right?" Mr. WANG (nodded): "right, the number of rebates is tiered, and the unit price is also ." John (Khan): "Is there a unit price? Isn't the unit price of each product code fixed ?" Mr. Wang: "It's fixed. The prices of different tiers are fixed ." Xiao Zhang (helpless): "That is to say, the unit price is the same as the number of rebates, which are determined on a tiered basis. For example, 1-100 yuan is 1 yuan, and Yuan is 8 cents, -yuan is 7 cents, right?" Mr. WANG (nodding and moving): "Yes, yes, that's what it means !" Business personnel are as familiar with their own processes as they are in the palm of their hand. when describing their needs, they will inevitably omit many of the premises and conditions they think should be appropriate, these conditions are by no means dispensable for information systems. They must be accurately stated to ensure the correctness and smoothness of the process. For example, in the case of Mr. Wang, he can see that he is already very familiar with this process. Therefore, it is just as natural for him to determine the unit price and the number of rebates according to the order quantity, that's why we can't stop it when James asks about other numbers. In Mr. Wang's opinion, these are self-evident. Even if he doesn't, everyone knows. But for Mr. Zhang, if there is no special explanation, he will not think of the existence of the rebate quantity, nor will he think that the unit price should be linked to the order quantity, nor will he have it in the natural system. If Mr. Zhang is not keenly aware of Mr. Wang's outsourcers, this implicit demand point is likely to be lurking quietly. It may not be discovered until the system is launched. At that time, I'm afraid it's too late to regret it. The system has been developed, and it's not that simple to think about changes. Therefore, no matter how large the system is, how important it is, and how the Department is used, you should conduct detailed and comprehensive demand research before selecting software or developing the system, discover hidden, critical, and easily overlooked requirements in business operations, regardless of whether the user focuses on them. In many cases, users' concerns may not be difficult in system implementation, instead, it is a heuristic rule with a high degree of flexibility, complexity, and diversity that has long-term accumulation and plays a key role in the business, because it is closer to the human brain's thinking model, therefore, computer systems focusing on logical operations are not good at processing these "Hidden Rules", so it is difficult to implement them. Global "hops"In the same meeting room, Mr. Smith is explaining to Mr. Zhang the review process of the Order application submitted by the Sales Department for the branch office. Mr. Wang: "On the Order application review page, I hope to list all the items to be reviewed. Then, we choose to pass or reject them ..." John: "Wait a moment. I see that all the products in the order are listed in the table you provided ?" Wang: "I can see it clearly ." John: "Okay. So, during review, do you usually pass the review one by one or several products together ?" Wang: "Well, one by one ." Xiao Zhang (nodded): "Good, you can continue ." Mr. Wang: "The products that pass the rule are transferred to the allocation location. If the rule is rejected, the branch can be modified again, but the abolished order cannot be changed ." Xiao Zhang: "Apart from pass and rejection, Is there abolition ?" Wang nodded. Xiao Zhang: "What is the difference between abolishing and rejecting an order ?" Wang: "The abolished items cannot be modified, but they can be queried. Reject suspicious changes and resubmit them ." Xiao Zhang: "There is another problem. If the order contains multiple products, how do you reject it ?" Mr. WANG (a little hesitant): "That is, reject the product ..." Xiao Zhang: "is a single product rejected ?" John (think carefully): "Yes ." John: "So you think about it. If there are two products in an order and you reject one product through one product, will the status of this order be 'pass' or 'failed '? Should it be modified by the branch office or should it enter the next approval stage? What products have been approved at the time of modification will not be changed by the branch office ?" Wang frowned. Xiao Zhang: "also, if the rejected product Branch has been modified, will it be re-approved by you, or will it go to the next approval process with the approved product ?" Xiao Wang (wiping sweat): "I have never thought about it carefully ..." Xiao Zhang: "You must think clearly about this problem. Otherwise, the documents cannot be managed ." Wang nodded. Xiao Zhang: "From a system perspective, if there is one product that fails to pass the review, the entire ticket will be rejected. After modification, the ticket will be resubmitted, then, the entire ticket is approved and rejected. Of course, unless you need to manage the product separately, do you have management requirements for this aspect for your order application ?" Mr. Wang shook his head: "No, we ship the data out of the warehouse by order. We didn't split the data out of the Warehouse ." James nodded. "I suggest you approve, reject, and abolish the entire order, which facilitates Order Control and actual operations ." Mr. WANG (nodded): "It's still your major. Let's go on the whole order !" There is no doubt that specific business personnel are familiar with their jobs, but this familiarity also limits their thinking models to some extent, so that they are limited to their own perspectives, you cannot think about the entire process. However, the application system is not only designed to reduce the work intensity of a person or department, but cannot only meet the needs of some people. It must be measured from the perspective of the entire process, from the purpose of enterprise benefits, we must jump out of the limitations of individuals and departments and systematically plan the information construction scheme. For example, Mr. Wang is most familiar with things he does every day. Therefore, his requirements for the system are also based on his work habits. However, Mr. Smith did not consider the purpose and requirements behind the review because he was too specific to the details. He only knew his daily work and did not know much about the overall and purpose of the document transfer process. Therefore, Mr. Smith sweated when Mr. Zhang asked him how to deal with the various situations that occurred after the rejection of a single product. According to his previous system design experience, Mr. Zhang found the fuzzy design of the review process of the Sales Department from Mr. Wang's brief description and considered the possible confusion. Then, we put forward our own suggestions for the order review process to avoid the system design and business management troubles caused by product review. In particular, these troubles are not necessary at all. Therefore, in addition to in-depth understanding of requirements, jump out of the limitations of specific systems, departments, and individuals at the right time. It is also an indispensable capability for informatization builders. If, as the builder and planner of the application system, lack of system thinking vision and ability to control requirements, it is undoubtedly a major defect and risk for the informatization construction of enterprises, because, A system built based on the needs of the business department can only improve efficiency. It is of no benefit for process integration and competitiveness improvement. With the increase in the number of similar systems, information cannot be shared, and departments lack collaboration. In the end, even basic efficiency improvement functions cannot be achieved. Instead, information may become a bottleneck that restricts enterprise development and can be triggered at any time. TipsThe reason is clear. Let's talk about how to do it. Demand research is the first step in information system construction and the most critical and fundamental step. The quality of this work will directly affect the final use effect of the application system. Therefore, demand research is generally conducted by relatively experienced demand analysts or project managers. Their skills and experience have a high reference value for a good demand research. The following are some tips on demand research, which are also based on experience. 1. Make sure you are talking about the same thing.Due to the differences in the professional division of labor between researchers and business personnel, both parties have their own expressions and terminology, which can easily lead to barriers to communication. In order to reduce the occurrence of similar misunderstandings, it is best to use physical objects to describe the problem. For example, before discussing the problem, check whether the table you are about to discuss is in your hands, you can also print out the business department's flow chart, as shown in the figure below. 2. Use "Business Language" to talk.As mentioned above, researchers and business personnel have their own languages, which may cause difficulties in communication. Relatively speaking, the business personnel have a worse understanding of it terms, and the researchers should understand the business as much as possible to accurately understand the requirements. Therefore, it is recommended that the researchers use the "Business Language" to talk. This not only reduces the barriers to language communication between the two parties, but also facilitates researchers to quickly understand and grasp business needs. 3. Master listening skills.Business personnel are more involved in the demand research process, while the most important task of the research personnel is to listen, identify problems from the Demand description, propose and further confirm the problem. Therefore, listening skills are more important for researchers. When listening, obtain as much information as possible to discover potential requirements and rules hidden in the narration; When retelling, describe the problem as objectively as possible, without mixing with personal preferences and comments; when you have doubts, try to raise as few questions as possible and confirm the ambiguity. Such a listening process allows business personnel to fully express their needs and avoid system defects caused by narrative omissions and misunderstandings. 4. Examples.In the case of complicated and difficult to understand, it is best to use specific examples and data for further explanation. We should not only let the business personnel give an example, but also give an example of their understanding of the problem to avoid misunderstanding caused by the complexity of the problem. 5. Respect the opinions of business personnel and provide professional suggestions.For a specific process, business personnel have the most say, and they have a lot of experience accumulated in their work for reference. The researchers should fully pay attention to and respect this, you cannot sneer at your opinions because they are not comprehensive or correct. Of course, for business personnel to consider the demand for weeks, researchers can give suggestions based on their own experience and understanding, to help business personnel analyze and find a more appropriate solution. In short, the informatization construction of enterprises is inseparable from accurate and comprehensive demand research. To do a good job of research, we must be able to "drill in" and "Jump out ", the two complement each other. Only by understanding comprehensive business needs and grasping the overall construction direction can enterprises achieve the expected results in informatization construction and bring stable development to enterprises. (Welcome To The Author: shangrr@hotmail.com)

(This article is published in CCU)

Original post address: http://blog.vsharing.com/sarria/A900785.html