The Revenue Element

An important example of the distinction between primary and secondary elements is provided by two elements we are quite familiar with by now the Cost and Revenue elements that describe these two dependencies of the irreducible element. The Revenue element is a primary functional element generating a revenue is a measure of what a plant does, of its purpose. The Cost, on the other hand, is a secondary element the purpose of a plant is not to generate a cost the cost is a consequence of having to create and operate a plant in order to provide... 

Fig. C6.18 Symbolic representation of the Revenue element for the Control System influence model.

The accuracy of the models need only to reflect the high level of the Revenue element in the top-down process, but even so, the models will usually allow us to make some in-principle decisions about the way forward in the design process. 

The third model (in C6.3.6) demonstrated the flexibility of the methodology. In this case, the plant under consideration is the control system, but in itself this system does not generate any revenue the revenue is only generated through the influence the control system has on the production system. The revenue element describes the revenue-generation of the production system, but the dependencies of the element. e. the inputs to the model) are not functions of the production system, but of the control system (via a dependency matrix). 

The underlying reason for dwelling on this issue of the Revenue element is, of course, that our application of the system concept to engineering is based on a top-down approach a step-wise development of the system (as a description), starting with the purpose of the plant. The irreducible element is the top element in this development process at the next level down, the Revenue element starts to reflect the specific purpose of a class of plant. The description of that purpose and the revenue generated by it sets the direction for all of the following development of the functionality of the plant i.e. for the process of design in the functional domain. 

For any project, the repayment of the loan must effectively come out of its proceeds over the years, i.e. the total net revenues (cash flow) must be at least as large as the amount borrowed, on top of the other costs of construction, etc. However, the repayment element of the loan is not included in a financial appraisal, because its equivalent in plant cost has already been included in the balance as part of that cost. (An alternative way of looking at this is that the company, in paying back the loan, is just replacing that part of the original cost with an equal but differently sourced sum of money.)... 

Price - the only element to generate revenue, the crucial engine of market success and driver of profitability. 

This problem of finding the revenue that must be generated each period to justify a capital expenditure is one of the most common facing the engineer. The analyst should be reminded that there are two elements of the capital recovery factor. The first is the recovery of the 120,000 original investment, and the second is the necessity of earning 20% on the capital invested over the life of the project. In this case,... 

As products flow along the supply chain, the prices for one entity become the costs for the next. Thus, for the commercialization of new technology, the word cost has different meanings for producers and users. For users, the price and cost of a product or service are the same. For producers, however, cost is the expense incurred to produee a product or supply a service. To earn a profit and a return on investment, the producer s aggregate costs over time must be lower than the aggregate revenue. Time becomes the key element in the equation. In the short run, costs are often higher than prices but there must be an expectation that, in the long run, prices will exceed costs. 

The cost elements are obviously interrelated. Design changes and modifications made to improve reliabihty and maintainabiUty, will shift the revenue curve upward. This shift is achieved because production interruptions are reduced, and production at maximum capacity is possible at a greater percentage of time. Improved rehabihty and maintainahihty... 

O M activities represent a significant share of the expenses during the lifecycle of the projects (Kaldellis and Kapsali, 2013). O M costs can be considered to comprise of labour costs, material costs, access vessels lifting vessels costs and potential revenue losses. In this respect, it is important to identify the critical elements that can significantly reduce overall costs. 

The developed methodology is illustrated in Figure 1. The overall model consist of four blocks. The inputs of the model are introduced in the Inputs block. The inputs are processed in the Data Process block and then considered for the Simulations block. In the Simulations block, processed climate series, forecasted failure behaviours and vessel accessibihty and operabiUty values are synthesised and OPEX calculations are performed. The cost elements which influence offshore O M activities are then employed along with these results to support the decision making. Final decision choices are determined not only from a power production point of view, but also in terms of cost, revenue and profit. 

ABSTRACT Paper presents a numerical method for determining changes of availability of web applications implemented in virtual environment. It takes into account the reliability and performance aspects of software and hardware elements of the web system. The revenue process model takes into account working hours of administrators and a time of repair (or reconfiguration) for each type of failures. The described method was a basis for the development of a Monte-Carlo simulator that allows calculating variability of web application availability over a week. The paper contains the numerical results for a test case web application implemented in virtualised environment. 

The cost precedes the revenue, at least to some extent, and so it is in the nature of an investment, and the quantity of interest is the revenue relative to the investment, or the Return on Investment (ROI). The exact definition of this relationship in accounting terms may vary somewhat between various application domains and, in particular, due to the different compositions of the stakeholder groups. This will be discussed in Sec. C4.5, but for the time being the simplest relationship, such as revenue minus cost, divided by cost, is an adequate definition of ROI. The function of generating a return on investment then becomes the universal top element in developing a functional system the starting point of design in the functional domain, and what we shall call the irreducible element. 

Because the irreducible element is the same for all projects, we can define it in more detail as long as we do not introduce any variables or functions that would be project-specific. In accordance with the format of functional element introduced in Sec. C3.2, the functional parameter is the return on investment, which we had already decided to identify by U (Sec. B2.4). It is defined in terms of the two dependencies cost, C, and revenue, R, as follows ... 

A further feature of the structure of the functional domain arises from the central role of the irreducible element in the description of functionality and the definition of that element, as depicted in Fig. C4.4. Due to this view of an engineering project as an optimisation of the balance between cost and revenue, the secondary elements fall into two completely separate categories the elements describing aspects of the cost, and the elements describing aspects of the performance, as already mentioned at the end of Sec. C4.3 and illustrated in Fig. C4.6. 

The secondary elements describe aspects of the functionality that are additional to the actions described by the primary elements, and they arise out of two very different groups of requirements. Some secondary elements are required in direct response to corresponding requirements in the stakeholder requirements a typical example is a stakeholder requirement for dependability of the service, which then needs to be reflected in a requirement on the reliability of the system of primary elements. Other secondary elements are required as inputs to the primary elements, and again, reliability (or availability) might be required as input to a revenue element in order to be able to optimise the ROI, even if there is no explicit stakeholder requirement for reliability. Another example of this is cost there may not be any direct requirement on the cost, but a requirement for optimising the ROI will demand that cost is included in the description of the functionality. 

The symbolic representation of this simple Revenue element is as shown in Fig. C6.6. 

Fig. C6.6 Symbolic representation of the simple Revenue element, with the three vectors a, b, and c characterising the valne the users place on the service.

Because the Revenue function is now restricted to a particular class of projects, the upgrading of the control systems within infrastructure systems, it can be more specific and detailed. The following should be seen as an example of how such a Revenue element is developed. 

The process of developing a Revenue element is relatively straight forward Define the service to be provided identify the parameter(s) describing the main features of this service, including its/their value(s) allocate it/them to feature(s) of the plant and express this as an executable model of the revenue generation. 

Cost accounting is a well-developed discipline, with numerous methods and standards. And normal life cycle costing, as it is employed in traditional systems engineering, is described in various publications [4]. The life cycle aspect is reflected in our approach, as both the Cost and the Revenue are measured per accounting period over the life of the project. But as noted at the end of Sec. C4.3, when working in the functional domain, cost is seen as a consequence of requiring the plant to have a particular functionality. Consequently, the primary requirement on a cost accounting appropriate to the functional domain is that the cost elements correspond to primary elements. The additional properties of the primary elements, such as reliability and durability, as may be expressed by secondary elements, influence these cost elements. 

---