Question

How to write correctly: company or campaign? Both spellings appear, including on your website.

Company And campaign - homonyms. More precisely - Homophones. Because of the akanya, their sound coincided, but not their spelling.

Company –

1. society, a group of people spending time together;
2. commercial or industrial enterprise, commercial and industrial association of entrepreneurs.

Campaign –

1. a set of military operations united by a common strategic plan and carried out at a certain stage of the war in one theater of military operations;
2. period of navigation or military operations of the fleet (obsolete);
3. a set of measures to implement the next important socio-political or economic task.

The origins of these words differ radically. Our consultant N.I. Bereznikova wrote to us about this:

COMPANY – from Latin company. Console com-corresponds to the Russian prefix "s(o)-" Root pani- from panis – « bread". Initially– a group of dining companions, and this meant a lot in the ancient world– Those who broke bread became friends, almost brothers.
CAMPAIGN - lat. campania from campus – « field". Including« battlefield". Further, in general, it is clear. In French campagne – hike, work (in the field).
You can remember this: the company runs a campaign, but not vice versa.

Distinguish

Company And campaign

When implementing MRP systems at industrial enterprises, sooner or later the term “application campaign” or “application” appears in the vocabulary of automation specialists. Often, specialists are very reluctant to start automating the “request”, explaining that the process “does not fit” into the MRP system. “Does not work” means that the process is not implemented using standard system tools, which means that instead of simply setting up standard system modules, you need to write your own software solutions and integrate them with standard functionality. The support of such a solution, one way or another, will depend on the programmers, with a full “bouquet” of disadvantages, which they tried to avoid when introducing the MRP system.

Key users of the logistics service and company management are usually unanimous in their opinion: “Since we bought such an expensive system, it should be able to do everything we need” - and, indignantly, blame the IT service for its inability to implement serious systems. And not every IT specialist will be able to explain that these difficulties are objective and due to the limitations of business models implemented in MRP systems. Why do seemingly simple processes cause big problems when automating them using such “advanced” systems?

Stages of a typical application campaign

A typical application campaign consists of the following stages:

Statement of primary needs from departments. The purpose of this stage is to obtain information about needs from direct recipients. This is something like a maximum plan, with each receiving department claiming materials only on its own behalf and operating only in quantities of materials without prices.

Expert analysis of needs by nomenclature specialists. In industrial enterprises, as a rule, there are experts who are responsible for the use of certain groups of materials. For example, the chief mechanic's department is responsible for rolled metal, pipes and hardware, and the chief power engineer's department is responsible for lamps, cables and electric motors. The positions of these experts can be called differently - chief specialists, functional specialists, nomenclature specialists, nomenclature experts, and so on. They are the ones who formulate for the enterprise the rules for working with a certain range of materials and equipment. Ideally, they also maintain a nomenclature directory of materials. As a rule, these specialists work in the relevant functional departments, but at some enterprises they work within the structure of the logistics service.

As part of the application campaign, nomenclature specialists conduct an expert analysis of needs in terms of the validity of the declared nomenclature and the quantity of materials (“I wonder why we need 100 tons of nails for January?”).
The responsibility of nomenclature specialists also includes monitoring needs for compliance with the unified nomenclature, a certain standard adopted at the enterprise (“instead of screwdrivers with a length of 20 cm and 25 cm, we will use screwdrivers with a length of only 25 cm”), as well as identifying and eliminating duplicates of the nomenclature directory. For example, the declared positions “Lamp 220 V”, “LAMP 220 V”, “lamp 220”, “incandescent lamp 220 V” from the point of view of the directory are different nomenclatures, and the task of the person in charge is to determine the reference entry, and prohibit the rest or even delete from the directory.

Setting limits for material write-offs for departments. From the consumer's point of view, there should be enough materials in the warehouse to “enough for the rest of your life.” But from an economic point of view, it is profitable to purchase and store exactly as much materials as the enterprise can actually consume to ensure production at the planned cost. Therefore, it is necessary to somehow limit the stated needs. The amount limits for writing off materials for production are used as such limiters.

Limits are calculated for each division of the company based on data from the production program for the year, planned production volumes and costs for each type of product. This creates a limit for writing off materials as costs, which is planned and controlled by the planning service. But in order to compare the stated needs and the established limits, the needs must be assessed in total (price) terms, which is why the next stage is needed - pricing.

Preliminary assessment of needs. At the stage of expert analysis of needs, specialists authoritatively confirmed only that “the applicant really needs this item in exactly this quantity.” But from an economic point of view, no assessment was made, which means that economic planners may simply not allow all declared materials to be released into production due to exceeding the limit for writing off materials as costs.

The only department that can conditionally evaluate materials is the logistics service (materials and technical support). In practice, for materials that have already been purchased, the prices of the last purchase are taken, multiplied by a certain deflator (price change coefficient). For new materials that have not been purchased before, a quick assessment is usually carried out through the first supplier found on the Internet. As a result, for each material appearing in the demand request, a conditional price for writing off this material into production appears, and all requirements become suitable for comparison with the limits.

At the pricing stage, logistics service specialists also identify obsolete product items that are no longer produced, cannot be purchased and are not in stock. For example, computer and instrumentation models often change several times a year with little change in performance characteristics. The logistics service informs product specialists and applicant departments about all changes in the nomenclature directory in order to adjust the need at the next stage.

Adjustment of needs taking into account prices and replacement of items. The most stressful stage of the application campaign is the process of “fitting into limits,” since departments are forced to reduce the declared positions so that the total amount of costs is within the limit. All outdated items at the adjustment stage must be replaced with analogues or completely removed from the application.

After the adjustments, the requirements again go to the nomenclature specialists for approval - in fact, this is an iteration of the second stage, only after the nomenclature of materials and the number of items have been clarified.

Selection of supplier and updated pricing. At the stage of selecting a supplier, an updated estimate of materials takes place, based on clear supply volumes and substantive negotiations with suppliers. At some enterprises, this stage is carried out beyond the framework of the application campaign, during contracting.

After a detailed estimate of the declared materials, the final adjustment of the demand requests takes place with mandatory approval from product specialists.

Calculation of the procurement plan. At the final stage of the application campaign, the procurement plan is calculated. The calculation algorithm is generally similar to the standard calculation included in MRP. Next, the calculated procurement plan is transferred to the supply service executives.

From the description it is clear that the price ultimately leads to an adjustment of needs. That is, it turns out that a certain position is needed not based on objective necessity, but depending on its price. This is precisely what contradicts the MRP/MRPII concept embedded in modern resource management systems.

For most Russian companies, MRP principles can usually be applied in their pure form only to standardized materials for main production. And the purchase of everything else must either be organized manually or come up with other automation methods.

Approaches to automating application campaigns

By and large, there are only four approaches:

> Refusal of application campaigns in favor of the standard functionality of the MRP system.
> Modification of the standard functionality of the MRP system.
> Creating new functionality using built-in MRP system development tools.
> Development of specialized external software and its integration with the MRP system.

The first option is still rather hypothetical. Examples of the practical implementation of a complete change in planning methodology are extremely rare. As a rule, this approach can be implemented for standardized materials required in the main production, since their purchase does not depend on price, or for a small group of materials (chemicals, light bulbs, pens, paper), the consumption of which is calculated statistically.

Modifying standard functionality is a very popular approach. The most successful examples of its implementation are based on the use of the functionality of standard requests for the issuance of inventory items from a warehouse, to which their own tables of prices and conditions are added.

The main advantage of this approach is the ability to use standard functionality to calculate the procurement plan. Another important advantage is the relatively small volume of in-house developments.

The main disadvantage of this approach is that the interface of standard requests is usually poorly suited for working with a large number of item numbers in the edit mode, since navigation, search, and mass replacement tools are poorly developed. Therefore, for ease of use, we also have to develop our own user interfaces. In addition, standard requests for the issuance of inventory items are intended in the system for precise planning of the receipt of inventory items from the warehouse (before a specific date and time), and in the application campaign they are used for expert assumptions about the receipt of inventory items, with an accuracy of up to a month.

When the need arises to automate the direct release of incoming inventory items from the warehouse, the object intended for this in the system is already used for other purposes. You have to program again, for example, add special features to separate applications used in the application campaign, and so on.

The application campaign automation options associated with development are essentially identical and differ mainly in the tools and programming environment. Below we will look in detail at one of these options using the example of implementing our own functionality in the SAP/R3 system.

Implementation of your own functionality in the SAP R/3 system

The key advantage of this approach is the ability to design a system with virtually no restrictions, which to one degree or another are characteristic of standard interfaces. At the same time, the labor intensity of such work is relatively small: 3–4 qualified developers with high-quality design documentation can complete the work in 2–3 months, including testing and acceptance. The development of new functionality allows us to take into account most of the user requirements in terms of interfaces and service functions that make working with the system easier.

The main disadvantage of this approach (we mentioned it at the very beginning) is the need to support our own developments. By the way, with proper implementation of new functionality, the risk of incompatibilities appearing when the system switches to a new version will be even less than in the case when the standard functionality was improved. After all, its own functionality exists on its own and is integrated into the “standard” in just a few places. Therefore, even with significant changes to the standard functionality in the new version, you will have to adapt your own developments only in connecting “bridges” - places of integration.

The figure shows a schematic diagram of a solution for an application campaign in the SAP R/3 system. Functionally, it consists of several related subsystems and uses standard directories of material master records (MMR), cost centers (cost centers), project structure plan items (WBS elements) and other cost objects.

The “Requirements” subsystem is designed to collect primary requests for receipt of inventory items from the company’s structural divisions, analyze and approve these needs by item specialists and check for compliance with the write-off limits for inventory items. The subsystem supports separate planning by types of requirements and destination objects (projects, cost objects).

The “Limits” subsystem serves to implement the limit policy for writing off inventory items by structural divisions and cost objects. Its users are employees of the economic planning service. The subsystem interface is implemented in accordance with the principle of “screen interface = control form”. This means that the input interface matches the printed report form by which the service monitors these limits.

The “Pricing” subsystem is designed to maintain planned prices for the write-off of materials into production and allows, based on “basic” (indicative) prices and a number of coefficients (deflators, planned coefficients of transportation and procurement costs, etc.) used by the logistics service, to calculate planned write-off prices for each planning period.

The “Purchase Plan Calculation” subsystem allows you to calculate a purchase plan based on needs, forecast balances and inventories of materials, taking into account standard planning calendars and information from material master record views. The subsystem resembles the standard functionality for planning material requirements, but allows more flexibility to take into account various features of delivery and packaging in calculations (for example, navigation schedules for northern delivery, distribution of hazardous substances that cannot be transported together over different periods, etc.).

The “Settings” subsystem allows you to flexibly configure functionality, including setting formulas for calculating the procurement plan, methods for distributing the estimated quantity of items over periods, price coefficients and the procedure for their use, setting up periods, stages of working with demand, and so on.

It is important that the standard MRP calculation of material requirements (for example, for main production) can work simultaneously with additional functionality. For each material, the master record specifies the planning method (standard or custom). This allows you to switch to standard MRP calculation gradually, in groups or even individual materials.

Separately, it is necessary to note an important specific problem associated with the licensing policy of MRP system manufacturers. With full automation of application campaigns for a large enterprise, the number of final applicants reaches several thousand. If you buy a license for each user, this results in serious financial costs. Since vendors do not officially recognize the problems of application campaigns, they are not yet ready to consider preferential licensing conditions.

To overcome this limitation we have to come up with workarounds. For example, in the figure in the “Requirements” subsystem, the “thin client” web interface is highlighted in yellow. This is a separate system implemented in the ASP .NET environment. The system performs two important functions. The first function is to provide users with a web interface to operate, which reduces the requirements for user space and eliminates the need to install client applications on hundreds of computers. The second function is to provide work in the MRP system through standard remote call interfaces under the guise of several technical users, while processing requests from hundreds of actual users.

Of course, it is somewhat difficult for technical implementation, but it is completely legal from the point of view of licensing policy, convenient for users and economical for the customer.

Application campaigns

ERP class systems are very popular today all over the world. This is explained by an integrated approach to solving management problems, rich functionality, standard implementation of modern effective business process models and the possibility of flexible configuration.

However, despite all the functional completeness of ERP systems, the basic models do not have a Russian-specific business process for planning material requirements, the so-called “application campaigns.”

Application campaigns appeared in the USSR under the conditions of a planned economy. Enterprises stated their needs for materials and equipment for at least a year in advance, and strategically important and remote enterprises - even for two years. All needs were calculated and approved within the framework of various financial funds and limits. The financial plan and procurement plan were defended in the relevant departments.

During the transition to a market economy, the management of most industrial giants had no time for innovative solutions in the field of supply. And the performers who worked at the enterprises were accustomed to the accepted methods, so application campaigns remained practically unchanged for a long time. The emergence of new managers and young logistics specialists is gradually moving the supply process towards world practice, but until now, for many industrial enterprises and holdings, the application campaign remains essentially an unchanged and familiar process.

The purpose of the application campaign is to formulate, based on the needs of the enterprise, an appropriate procurement plan, balanced in terms of product range, financial resources and delivery periods.

The essence of the process is that data on the needs for goods and materials (inventory assets), expressed in the form of requests from structural divisions - consumers, are processed several times a year during an official centralized procedure. In this case, an important criterion for assessing needs is price, that is, a characteristic that logically arises in the process of logistics at a later stage - during contracting. Such a contradiction does not fit into the MRP/MRPII algorithms, which are based only on quantitative rather than sum (price) criteria.

Additional conditions for successful automation of the application campaign

The most remarkable system from a functional point of view may turn out to be useless if three important conditions are not met:

• Availability of a single nomenclature reference book for all participants in the process.

Let us give as an example the most common violations of this condition:

• use of separate directories in each department;
• maintaining a single directory, but with a large number of duplicates. In this case, each division declares the same material under different nomenclature numbers;
• distribution of the directory as service information in the form of spreadsheets or text file. In this case, many errors (random and special) arise due to the influence of the human factor, the reconciliation and correction of which usually falls on the MTO service.

• Clear delineation of tasks and powers of participants in the process.

Typical mistakes:

• an attempt to shift responsibility for a process from a person to a computer. In practice, this leads either to the involvement of IT specialists in the business process, or to the uncontrolled flow of the process;
• having more than one person responsible for the process. In this case, everyone who considers the process “their own” tries to change it “for themselves.” At the same time, IT specialists have to coordinate each change with all users of the process;
• an attempt by users to overly control the process, which ultimately results in a lack of control as such. For example, a user requires full control over each item included in the summary requirement calculation. Having received such authority, he soon realizes the enormous amount of work and shifts it to another employee who, not being responsible for the process, performs it mechanically, negating the original idea of ​​control.

• Availability of centralized process control.

As a rule, logistics service employees are appointed responsible for conducting application campaigns. At the same time, they are usually forgotten to be given real powers to manage the process. It’s funny and at the same time sad to watch how MTO employees repeatedly remind that the deadlines for the application campaign are being missed, and beg colleagues from the applicant departments to adjust the need.

Although these conditions are obvious, failure to comply with them often makes it difficult to successfully automate application campaigns.
Finally, I would like to note that the automated process of the application campaign gradually brings users closer to understanding the “correct” organization of the process. After working for two to three years, users begin to optimize their work methods. Moreover, optimization proposals resemble attempts to reinvent the wheel and refine the procedure to standard functionality that already exists in the MRP system.

The conclusion suggests itself that the true goal of automating the bid campaign is to ensure controlled bid and procurement document flow with a gradual transition to standard MRP algorithms. It seems that someday at Russian enterprises the usual application campaigns will become an anachronism. And one day, in the not very distant future, some seasoned, gray-haired logistics consultant will try to remember and explain to a young colleague why earlier in Russia it was impossible to solve supply issues using long-known simple and logical methods.

ERP, MRP, MRPII…

From the point of view of automation of application campaigns, the ERP/MRP/MRPII management systems are identical. In this article, they are all united by the term “MRP system”.

An MRP system (MRP - Material Requirements Planning) is understood as an automated management system that implements planning and provision of an enterprise with material resources using the MRP method. The method itself, along with its name, appeared about 40 years ago in connection with the development of the use of computer technology for business needs.

Despite the well-established expression “in accordance with the MRP standard,” this is still not a standard, but simply one of the methods for calculating the needs for the procurement of materials, the essence of which is that the calculation of the procurement of material resources is made on the basis of the volumes and timing of production needs and the forecast warehouse stocks.

But MRPII (Manufacturing Resource Planning) is a standard supported by the American Production and Inventory Control Society (APICS). From a methodological point of view, in addition to needs and inventories, the MRPII method takes into account production capacity limitations in the calculations, in contrast to the MRP method, which assumes that production capacity is not limited.

The term "ERP" (Enterprise Resource Planning) was coined more than 10 years ago by Gartner Group to define an MRPII system integrated with a financial planning (FRP) system. By now the definition is virtually outdated.

The term ERP now refers to a system in which, at a minimum, a combination of financial, material, manufacturing and human management is implemented, that is, the main resources of an enterprise. The maximum “package” includes all known systems for managing various resources and aspects of activity (up to conducting design developments) - at the request and capabilities of the manufacturer. Due to the lack of a clear definition, disputes periodically arise as to whether a particular system can be classified as an ERP.

From time to time there are attempts to introduce new terms to describe various “ERP packages” (for example, ERM, EWRP). These terms are found in foreign literature, but in Russia they have practically not taken root.

Modern ERP/MRP/MRPII systems do not have a standard solution for automating the process of application campaigns and iterative pricing of inventory items, which is significant in duration and involves human resources.

" target="_new"> http://www.cio-world.ru

Managing the progress of the application campaign

Before the start of the annual logistics planning process, the main specialists of structural divisions and service enterprises responsible for the implementation of projects form a system of relevant measures, for each of which a cost limit is indicated. The latter should not exceed the funding limit established by the planning and budget department. After this, needs can be formed only for the activities for which they are specified, which allows you to clearly identify the performers and those responsible and subsequently monitor the implementation of the plan. An enlarged functional model of interaction between enterprises is shown in Figure 10.

Figure 10 - Enlarged functional model of interaction between enterprises

Structural divisions and service enterprises form requests for primary needs (annual requests) for materials and equipment, linked to activities and detailed down to specific materials or equipment, broken down by month. The generated annual application is sent for approval to the chief specialist, then a consolidated need for all main specialists is generated and agreed upon, and further up the chain is the need of the entire company. Coordination of consolidated needs is carried out according to the register of applications.

In addition, when new applications are received, links to them are automatically sent by email to all persons involved in the approval process. Control over the progress of approval is carried out through the status and tracking system (STS), which includes sending relevant notifications by email to all participants in the business process.

The authority system limits access to applications. Structural divisions do not have access to information on other structural divisions, and the chief specialist does not have access to information on other chief specialists. A superior employee additionally has access to the information of subordinates. Based on the approved annual requests, the planning and budget division creates a materials write-off plan and sends it to the logistics division, where a financing plan for the acquisition of materials and equipment is automatically created, taking into account the planned balances at the beginning of the year, the seasonality of imports and payment terms.

Organization of purchases and inventory accounting

All company purchases can be divided into two groups: centralized purchases, which are carried out through the parent company, and decentralized, or in-house, purchases of logistics departments. The centralized procurement process is fully implemented in the system, while the decentralized one is in the process of trial operation.

In centralized purchasing, once the inventory plan is approved, unprocessed items grouped by purchasing group and delivery basis are sent to the central purchasing unit of the parent company for processing. After receiving the register of unfulfilled orders, the trader processes the positions to determine their availability on the market and the possibility of purchasing. The budget is also checked here (the supplier’s price should not differ significantly from the planned price).

For materials not available on the market, the company's central purchasing department suggests replacements and sends them to the subsidiary for approval. After new positions are approved by specialists of the subsidiary company (adjustment of the logistics plan), they are returned to the center for processing. Having selected the necessary positions, the trader holds a tender for them. In this case, information is automatically exchanged with the electronic trading platform (ETP): using universal protocols, the system integrates with any external trading platforms. An analysis of supplier proposals for tenders is carried out, and an analytical report is created on selected items (reflecting all important delivery conditions). A supplier is selected, an agreement is drawn up with him and the subsidiary company that ordered the product. To optimize the process of working with suppliers, the latter are provided with remote access to the Gazprom Neft portal (Fig. 3). Notification of the supplier about the appearance of a purchase order in the system is carried out automatically by e-mail, followed by placing the completed payment request form in the document repository.

Figure 11 - Working with suppliers

Having sent the goods to the customer, the supplier enters an electronic invoice into the system, which is registered as a preliminary invoice. When a document is received by a subsidiary, it is registered with a link to the appendix to the relevant contract; after confirmation of delivery of the goods, the status is automatically updated in both the subsidiary and the parent company. Next, the accounting department posts the supplier document and issues a sales invoice to the subsidiary.

To control the process of delivery of goods to a subsidiary company, invoice numbers and vehicle details are entered into the system. After this, the goods are considered shipped and sent to the place of acceptance. When materials and equipment arrive at a subsidiary, they are registered and the invoice status is updated in the parent company. The storekeeper creates an initial receipt report (PRA), where he indicates the actual quantity of goods received (in this case, the system creates a document “Dispatching Advice”) with reference to a preliminary invoice or purchase order and confirms that the goods have been received. On this basis, the receipt of materials into the warehouse and their write-off for response storage are registered. At the same time, the change in status is also seen by the accounting department, which receives grounds to demand the originals of the closing documents. The supplier, in turn, can control shipment using reports.

Information about the receipt of goods triggers accounting entries in the system to debit the inventory account and credit the clearing account, thus quantitatively increasing the material inventory. Together with the receipt of materials, an incoming batch of material is created with a classification of batch characteristics (date of receipt, area of ​​activity, chief specialist, etc.). The processes of moving to structural units, writing off and selling materials to subsidiaries and third parties, as well as collecting actual costs are also recorded in the system.

The basis for making payments is the supplier's invoice (the latter, in turn, is created on the basis of a purchase order). Payment orders are generated for unpaid invoices. The system implements the function of electronic approval of payment orders. As a result, the entire selected block of approved invoices is printed (for example, for a specific date), and only invoices already pre-approved by him are brought to the manager for signature. The approved payment is transferred to the accounting department for payment. After completing the payment documents, the accountant confirms the payment.

Using paper versions of the preliminary invoice, storekeeper's PPA, and receipt order, invoices are checked in the system, necessary adjustments are made, and accounting is carried out. At the same time, the system makes accounting entries for the debit of the clearing account and the credit of the supplier's account, as well as entries for input VAT, and accounts payable are formed. These mechanisms make it possible to organize a unified cost and quantitative accounting of materials inventories in real time.