I. Introduction
Some netizens exclaimed in a post on the forum: After finally installing the EBS system, I went in and looked dumbfounded. I don’t know where to start? The problem encountered by the netizen who exclaimed is actually a problem that many people have encountered or are currently encountering. For a long time, when domestic non-professionals (such as the media) mentioned SAP or ORACLE, many people like to describe it as "super difficult to understand". So, what are the views of domestic professionals? The most "thunder" statement I have ever heard comes from a senior executive of domestic software research and development: SAP/ORACLE is too complicated, and we will never be able to understand the things behind it and the deep-level things!
It's incredible. On the one hand, domestic industry insiders are almost unanimous in saying that compared with SAP/ORACLE, there is not much difference in technology, and the platform tools are all open, and there is no mystery at all. Due to the early development of SAP/ORACLE products, we even have the advantage of being a latecomer in technology. On the other hand, we often hear that some people in China mystify SAP/ORACLE, thinking that it contains "complex and profound management ideas", which are German/American things. It's normal not to use it. The national conditions are different and the models are different. Chinese people should find a path that suits them!
Is it really? Are SAP/ORACLE products really so mysterious and unattainable? Today's professionals engaged in ERP work, from the perspective of personal background, can usually be divided into two categories: "technical background" and "business background". People with "technical background" may have certain advantages in learning and familiarizing with the system, but in the process of communicating with users, they may have certain difficulties in quickly and accurately grasping the essentials of the business; Business communication may feel easier, but it may be relatively difficult to study and master the system. According to the survey and statistics that the author has done, it seems that the vast majority of domestic ERP practitioners are "technical background".
ORACLE EBS, as a highly integrated enterprise management software system with more than 100 business application modules, is a highly integrated modern computer technology and enterprise management practice. It is not a simple reproduction of "computerization" that imitates the manual business process of an enterprise. Perhaps this is the fundamental reason why many people feel that it is "difficult to understand and difficult to use". Therefore, " come from practice, then go to practice ", or " from the perspective of business to technology, and then return to business from technology " may be the methodology for us to open the door of ORACLE EBS step by step, wander in it and do a job with ease. (The so-called "technology" here means "system implementation").
In the industry, there are roughly three types of personnel engaged in ERP work: one is the so-called "technical consultant". For these people, mastering the corresponding software development skills is a necessary condition, and the focus of their work is generally on System background, such as developing system interfaces, business reports, solving some technical problems of the system, etc.; the second category is the so-called "functional consultants", these people have different degrees of familiarity with the relevant modules of the system, and are usually guiding enterprises to use the system. Or they are working hard to turn the business requirements of the enterprise into a systematic implementation plan; the third category is the so-called "management consultant". The overall height of the enterprise management business process gives consulting advice, and maximizes the important role of the ERP system in improving the enterprise management level (the "management consultant" here refers specifically, which is different from many people who do not understand the system and only know how to use it in the market) A "management consultant" who "talks about war on paper").
In actual work, there may be no clear boundaries between the above three types of personnel, but generally there is a process of development from low to high with the improvement of system awareness and the accumulation of business operation experience. Therefore, how to realize "seeing technology from a business perspective and returning to business from a technical perspective " is an eternal proposition faced by people in the industry, and achieving the "integration" of business and technology is the highest level of pursuit. For this reason, this article will start from the most basic application elements of the extensive and profound ORACLE EBS system, from business-technology-business, to discuss the so-called "things behind it, deep things" that make some people unpredictable and belittle themselves What is it, so that we can finally find the key and the way to help us enter the hall.
2. Form and query ( Form and Summary )
In the process of business operation under the manual mode, there are always various paper documents for recording business data or management information, such as "sales order, purchase order, storage order, storage order" and so on. With the increase of business volume, the number of these paper documents is so large that the enterprise has to spend a lot of manpower to summarize the important information on each document (such as suppliers, materials, quantities, price, amount, date, etc.), and establish an "index, list or ledger" of data records, etc., so that they can be queried or counted when needed.
The simplest software management system is to "digitize" the above-mentioned paper documents and put them into the system, and then provide a "query" function to find these documents in the system. If you study the current mainstream ERP products in China, you will find that these domestic ERP products are mainly used in the low-end market. item. The format and content of the documents in the system are so similar to paper documents that most enterprise personnel will not feel much difficulty in learning and mastering them.
In each module of ORACLE EBS, various documents (Forms) are also used to enter or save data (corresponding to the "table" in the background database), and provide corresponding query functions for them, but in ORACLE System documents are no longer a simple reproduction of paper documents. Various "forms" can be seen in the UI interface of the system (according to statistics, there are more than 3,000 kinds), which are not only different from paper documents, but also may differ greatly in their nature and query methods. To sum up, the "forms" in each module of ORACLE can be roughly divided into three categories according to their nature and function:
The first category is "business process" forms , such as "sales order SO, purchase order PO, manufacturing work order WO, invoice INVOICE", etc. They have a common feature of participating in the operation of core business processes, which are core business processes an integral part of it. This is obviously also highly corresponding to the actual business process of the enterprise. As the original documents of the business, they are so important that even after IT systematization, most enterprises may still have to preserve and archive their paper forms.
In ORACLE EBS, there are actually very few types of "business process" forms (each module is generally only about one or two), but each type of document accumulates over time, and the amount of business data may be large. The business process form is the most important form in the system. Compared with paper documents, the content is richer and more complex, and the format has also changed a lot. It makes full use of the capacity, scalability and Ease of use. It comes from business practice, but after being highly abstracted and integrated with the latest technological achievements, its functions and functions are much higher than the original paper documents. PO form as shown in Figure 1:
PO form is a typical "business process" form, which consists of two parts: "header and body line", which is still similar to paper documents. But the difference is that each "table body row" of the system form can also have its own "secondary sub-table row"; and each "secondary sub-table row" can also have its own "third-level sub-table row". table row", and so on. This form display method cannot be realized with paper documents. It greatly expands the information capacity that documents can contain, and has a high degree of flexibility and convenience. In Figure 1, the total purchase quantity in the first row of PO is 36, which corresponds to the second-level sub-table of "delivery" and is split into two rows with quantities of 20 and 16 respectively (indicating that the goods are delivered to two different receiving locations or the same location But the two delivery times are different); the quantity of the first row of the second-level sub-table of "Shipping" is 20, which corresponds to the third-level sub-table of "Distribution" and is split into two rows with quantities of 10 and 10 respectively (indicating that it corresponds to two different expense accounts or expenses are borne by two different departments).
The second type is the "data source" form , such as "price list in OM module, quotation in PO module," and "material, supplier, customer" data form, etc. Their common feature is that they do not participate in the core The construction of business processes, but they provide reference data sources for business process forms, such as purchase orders to obtain material-related information from the material form, supplier information from the supplier form, price-related information from the quotation, etc.; Most of the forms may also exist in the manual business mode, but the actual use and management in the manual state may not be strictly regulated;
In ORACLE EBS, there may be many types of "data source" forms in each module, and the content and format complexity of each form, as well as the number of documents are also very different. Although they are not indispensable, the management ideas of specialized division of labor and collaboration they embody have a significant impact on the efficiency of business process operations of enterprises.
The "price list" in the order management/pricing module shown in Figure 2 below is a typical "data source class" form, which can also have a complex structure:
The third category is "business control" forms , such as "orderability of materials for sale, list of approved suppliers for purchase, system parameter settings", etc. These forms rarely or do not exist in the manual business mode. In fact, it is actually difficult to use them to effectively control the business manually.
In ORACLE EBS, the types of "business control" forms in each module are relatively small, and the number of documents is also very limited, but they reflect the system control mechanism of enterprise management and have an important impact on the efficiency of business management control.
The list of approved suppliers for procurement (controlling which suppliers can be purchased from) as shown in Figure 3 below is a typical "business control" form, which can also have a complex structure.
Although in ORACLE EBS, there are more than 10,000 "tables" (Tables) used in the statistical background database, and the forms visible in the front-end UI are also various and numerous. After the above three categories, things will become much simpler, which allows us to use the limited types of "core business process forms" in each module as the "entry point" for learning and research, by analyzing the internal business of each document The analysis of connotation and technical connotation, as well as the research of business logic and technical logic between various documents, gradually expand and master other functions and applications of the system.
Based on the needs of actual work and the simplicity and convenience of system design, ORACLE provides different "query" methods for the above three different types of forms, which can be summarized into three categories: functional query methods and quick query methods method, simple query method.
The so-called "function query" method, there is a "query" function menu item in the system (such as PO Summary, purchase order summary), when you click this menu to enter, the system will first pop up the "search condition" input window (control), as shown in Figure 4 The shown purchase order function query menu and query condition controls:
Then, according to the input query condition, the query result LIST is given. As an extension of the query function, the system further provides related query (such as the upstream and downstream documents "purchase requisition" and "purchase invoice" of the purchase order) and detailed query functions in the toolbar of the UI interface, as shown in Figure 5 below. Output result view:
The function query method is usually only used for the query of core "business process" type documents, and the query function is powerful. Due to the importance of business process forms (and some data source forms), the system provides a special "query" function in the menu item.
The so-called "quick query" method means that after opening the document interface, you only need to click the query "icon" (flashlight) in the toolbar of the UI interface. There are two ways to input query conditions: one is that there is no dedicated "query condition" selection window , limited to the fields that are commonly used in the "search bar" of the search interface (the so-called "fuzzy query"), the system will directly give a LIST of all eligible items in the search interface, and the details need to be selected after entering the item Check the document interface, as shown in Figure 6 below, the "quick query" of "purchase order" in the document interface:
The other is that after clicking the query icon (flashlight) on the document interface, the "query criteria" input window will also appear. After entering the query criteria, the system may also display a simple result list LIST interface or view (some form queries are Maybe not), through the LIST view interface, you can choose to open the form of the related item. At the same time, you can also directly press the "Page Up" button (Page Down or Page Up) on the document interface to directly switch between the different items that have been queried in order. As shown in Figure 7: the query condition control and output result view of the material shortcut query method:
The above (two) shortcut query methods are applicable to the query of form data with a large amount of business data. The latter "quick query" method is somewhat similar to the "functional query" method, except that the relevant "functions" of the output view of the query results (such as the traceability of the upper query and the lower query, switching between summary and detail, etc.) do not have the "functional query" method so powerful. But for most of the "data source" forms, since they do not participate in the construction of the core process, and the information is not as complicated as the business process form, the "quick query" method can basically meet the actual work needs. If the "query condition control" and the query "output result view" are designed for all forms according to the "function query" method (as some domestic products do), the complexity of the system design will be greatly increased, and the subsequent system maintenance will also be difficult. Very troublesome, neither economical nor practical.
The so-called "simple query" means that after opening the document interface, all the fields of the "document" interface are directly used as the "search condition input window". To do this, after opening the document interface, select "Query Standard-Input" in the "View" toolbar of the UI (or press the F11 key), and the relevant fields in the document interface will be "grayed out" at this time, allowing Enter the specific query value, and then select "Query Standard-Run" in "View" (or press Ctrl+F11), the query result will be displayed on the document interface, and press the "Page Up" button (Page Down or Page Up), after the query has been Switch directly between the different items that appear in sequence. As shown in Figure 8 below: a schematic diagram of a simple query method for the BOM:
This query method neither needs the "query condition" control nor the query result output view. The system design is very simple and economical, and it is suitable for almost all forms. It should be noted that for some forms with a small amount of data in the system, the system may only provide "simple query" as the only available query method.
In addition, some forms in EBS may have HTML-based display and query methods under the WEB. The advantages and disadvantages of UI and HTML display and query methods are related to the usage occasions on the one hand and usage habits on the other hand. In short, understanding the use of various forms in the system and proficiency in various query methods is the basis for further study and research of the system, although the form display and query methods of each module of EBS may vary due to different businesses and style preferences of different designers. They are different, but the core essence is still the same.
An Overview of the Application Basis of ORACLE EBS System
Three, transaction processing ( Transaction )
4. Concurrent Process ( Current Process )
5. Folder ( Folder )
6. Flex field
7. Value Set and Lookup Code ( Value Set and Lookup Code )
Eight, the configuration file ( Profile )
Nine, document number ( Document Sequence )
10. Workflow ( Workflow )
11. Alert _
12. Application Open Interface ( Open Interface and API )
Thirteen. Conclusion
(Note: There is a problem with the batch of pictures sent by the website, and the display is not clear after uploading. After clicking the picture to open, the quality is acceptable)
Three, transaction processing ( Transaction )
If the above-mentioned EBS "form and query" system design reflects "from business to technology", it is easier to understand and master, then the so-called "transaction processing" is a part of the system that reflects "from technology to business". Paradigms, relatively speaking, are much more difficult to understand, because the corresponding processing methods and processes cannot be directly found in the manual business model.
Taking the receipt of purchased materials in the warehouse as an example, assuming that the company stipulates that it must be received strictly according to the PO , and in order to strictly control the inventory level, the company must receive small batches and multiple batches, then the warehouse personnel may need to open the same PO in a short period of time It is a heavy workload to issue more than N "storage orders". In order to reduce the workload and improve efficiency, the warehouse staff may simply mark the quantity on the PO paper documents found every time the supplier delivers the goods , and finally accumulate them together to open a "warehousing order" ". However, this "saving trouble" approach is obviously a "very irregular" approach. Although it can improve work efficiency, it will not be allowed in actual work because it will easily bring about many other management problems.
The ORACLE system solves the above problems simply by providing a "transaction processing" work interface. The transaction processing interface of purchase receipt is shown in Figure 9 below:
Similar to " simplely mark the quantity directly on the PO paper document when receiving the goods", every time the supplier delivers the goods, the inventory personnel only need to find the corresponding PO in the system , simply enter the delivery quantity and save it , the system will automatically generate a "transaction record" ( equivalent to a "receipt order" ) in the background . For the system, this processing method is very easy to implement technically, but it greatly reduces the workload of the operator, and effectively solves the efficiency problem caused by small batches and multiple batches.
Each business module of ORACLE adopts the above-mentioned similar "transaction processing" system working method in large numbers, which not only ensures a high degree of data integration of the system, but also ensures a high degree of coherence and integration for the process processing of each business link of the system . For example, the delivery processing of the OM system, the picking and warehousing processing of the WIP system, and so on. Some transaction processing work interfaces provided in the system may be named after "XX Workbench" (Workbench ) (this depends on the personal preference of different module system designers).
Furthermore, for some "business process" forms, such as "sales order, invoice", etc., the system also directly provides a button (Button) named "Action" on the form interface, which contains rich business Processing functions (not just input data), so that users ( User ) can perform various operations on the content of the form or obtain relevant information. As shown in Figure 10 below , the "Activity" button of the sales order interface:
In addition, ORACLE EBS also provides a similar transaction processing interface between certain business process documents to help users easily realize the conversion of business documents and the connection of business processes. The so-called "Autocreate" function from purchase requisition PR to purchase order PO as shown in Figure 11 below .
For a system user (transaction processing user) of an enterprise , if he masters the forms, form queries, and transaction processing related to his own work, he basically masters the use of the EBS system, and the system is no longer difficult to understand and use. "Transaction processing" in EBS solves the unification problem of "people and system" within the business process form, and solves the unification problem of "business and business, business and system" between business process forms. From the perspective of "pure technology" system implementation, there is nothing unfathomable about it.
It is very strange and regrettable that, so far, this kind of system implementation method is rarely seen in the systems of domestic mainstream ERP products. A netizen once asked the author through MSN : " Does the WIP transaction processing interface of EBS need to input items manually ?" , because I don’t understand or are not used to the implementation of EBS ’s “transaction processing” system, I will unconsciously and take it for granted that all EBS ’s FORM interface is regarded as a “business form” that has the role of “entity” and can usually correspond to paper documents. , such a question arises.
4. Concurrent Process ( Current Process )
From the perspective of system implementation, "concurrent process" or "concurrent processing" is a more technical concept than "transaction processing", and it is also a difficult point for people with business background and little understanding of "technology" to learn and master EBS one. But in fact, for today's computer systems, "concurrency" is actually a very common application, for example, we write articles on the computer while listening to music and so on. ORACLE makes it a bit pedantic. Compared with "online transaction" or "online processing", concurrent processing is called "background transaction" or "background processing", which seems to be better understood.
Taking the actual business process of the enterprise as an example, in the manual business mode, after the warehouse receives the materials and issues a "receipt of storage", the warehouse personnel must do a follow-up job: "manually" transfer the items on the receipt to the warehouse. The material receipt information is "posted" to the "Inventory Material Information Ledger" one by one to update the balance quantity of the inventory materials. In the EBS system, this boring and tedious work is completely done by the system. The system uses a concurrent program called "receive transaction processing processor" running in the background to process it online immediately or in batch cycles without affecting While doing other work, the user completes the "posting and registration" task that originally required manual work with high precision, and the "reconciliation" work that needs to be frequently performed to check for errors and omissions after posting in manual mode becomes no longer at all. need.
"Concurrent processing" is an indispensable and important part of the EBS system, and the above-mentioned concurrent processing of "material receiving" is just a very simple application. In EBS , "concurrency" can be mainly divided into two categories according to the processed objects: one is "process transaction" and the other is "report transaction". The system uniformly provides human-computer interaction in the form of "submitting a request ( Request )". "Query or submit a request" as shown in Figure 12 below:
For each concurrent "request", the system can allow input of relevant parameters and schedule it to run on a certain cycle, immediately or scheduled to run at some point in the future. The system presets a large number of "process transaction" type background transaction processing programs for business processes, and also provides some "report transaction" type output requests for enterprises' reference. Users can also easily customize some "personalized" background programs or report output by using the development tools provided by the system.
Compared with users, "concurrent processing" is actually a related work that runs in the background of the system. People who are just getting in touch with it may find it unfamiliar or difficult to use. The main reason is that there is no manual business or low-end management software. This way of working. This is like compared to small towns where traffic mainly depends on cycling or walking. Today, for people living in modern big cities, shuttle subways, buses that go round and round, and taxis that stop at hand have become indispensable to their lives. They are like the pulsation of the city's "vessels", constantly flowing, maintaining the operation of the city's life and vitality. The role or role played by EBS 's "concurrent processing" is basically similar to it.
Another important feature of EBS concurrent processing is its "system-level" planable, manageable, and controllable features. Concurrent programs are managed and scheduled to balance the system load and ensure high system performance. As shown in Figure 13 below, define a "concurrent manager" (including operating rules, work shifts, etc. This is similar to traffic scheduling and control in a city)
As for the concurrent requests of the "process transaction" category, because it involves the specific functional application of each business module of the system, it is inconvenient to talk about it here. The following mainly talks about the concurrent request issue of the "report transaction" category. Some netizens once complained, " ORACLE 's report function is not easy to use. To generate a simple report, you have to submit a request to the background, and the output is a text, which is too troublesome. The content of the standard report provided by the system cannot meet the requirements of the enterprise. It does not conform to the usage habits of Chinese people." This statement may be a misunderstanding due to the influence of some domestic products. At present, the mainstream ERP system in China basically adopts an implementation method similar to "query" for "report". Although this "query report" is convenient for users to use, it has caused endless troubles.
First of all, the report is an extremely "personalized" thing. Due to the different management levels of different enterprises, the focus of management is also different, and the reports required for the same problem will also be different. Even if the same enterprise is in different development stages, the required report content will not be the same. Therefore, it is normal for an enterprise that has used ERP for several years to continuously develop new (management) reports. If the ERP system makes the report function "explicit" and provides query condition controls and output result views in the system standard functions, it means that the so-called report function provided by the system must meet the requirements of all enterprises, but it is actually impossible. Achieved. In this case, enterprises will take it for granted that this is the responsibility of the ERP manufacturer, and the manufacturer must be responsible for solving it. At present, an important part of the product research and development of many domestic ERP manufacturers is to develop various query management reports for enterprises.
Secondly, if the content of the query report is complex and consumes a lot of system resources, the user can use it freely, and the IT system maintenance personnel cannot effectively manage and intervene in the "online" query, which may seriously affect the overall performance of the system and cause other problems. Users cannot perform normal work. From this point of view, the current domestic mainstream ERP products actually do not have a "report" function in the true system sense, but only an unrestrained and expanded "query" function. It is extremely unwise for the system to do so.
ORACLE puts the "report" function in the background in the form of concurrent requests for processing, which not only effectively solves the problem of personalization of "report", distinguishes the responsibility interface between ERP manufacturers and enterprises, but also provides enterprise IT system maintenance personnel with The convenience that the system can be managed and can be intervened. This is actually the flexibility and power of the ORACLE system ( SAP is similar). When some netizens claimed that their ERP is a "high-end" product for some domestic manufacturers, they questioned "it doesn't even have concurrency, can it be considered high-end?" How can a tall building without an "elevator" be regarded as a modern building!
The ORACLE system uses a large number of background "concurrent processing" programs, which realizes the separation of system users' process operations in "space and time", and eliminates the invalid waiting time of operators. While the concurrent requests submitted by the operator are running in the background, it does not affect its processing of other system affairs, which can greatly improve the user's work efficiency and convenience of use. " Concurrency" is as important to the ORACLE EBS system as the "heart" in the human body. It is the core tool for the system to achieve a high degree of data integration and process integration.
This is another concept that ORACLE has made a bit pedantic (there may also be reasons why the Chinese translation is not in place). The so-called "Folder" function, in simple terms, is the "user-defined query output interface view" function that anyone with a little IT system experience can understand . The system (can) provide so many query condition controls or query output result view fields, many of which may not be displayed by the user, and each system user User can use folders according to personal work needs or preferences Functions freely define their own visible UI interface. The ORACLE system provides folder functions for almost all important forms, query condition controls, and query result output views, which is where the flexibility, ease of use, and convenience of the ORACLE system lie. Purchasing PR query as shown in Figure 14 below:
