Library

Notes: A vibration control case study is described which demonstrates the application of magnetostrictive (Terfenol-D) actuators. The magnetomechanical properties of the material suggests that when incorporated in devices for applications a nonlinear response will result. This case study compares the performance of two kinds of control strategy (both discrete), a conventional proportional and integral (PI) algorithm and a variable structure algorithm (DVSC) in both servo and cancellation/regulation roles. Both strategies were implemented on an INMOS transputer based microcontroller with a sampling period of 300 μs. The results presented show that the control behavior of the DVSC strategy offers significant advantages over the PI strategy when controlling actuators with nonlinear characteristics, i.e., the rejection of a 5 Hz disturbance with a gain of −36 dB compared to a gain of −15 dB when using the PI strategy.

Notes: This paper concentrates on m e of the fundamental questions on which a Company needs to focus in generating a longer term corporate strategy, in particular—What is the environment within which the Company will have to develop?A longer term appreciation of this question is not only important for corporate strategy in general but is a key factor in establishing a viable, economic and relevant programme or plan for the Technical function.The actual approach used to study this longer term in a limited number of cases is described and the results in one case are summarized in principle in order to indicate the different fundamental questions with which a Company might be faced by taking a longer view in addition to the more normal short term one. The results also give an example of how the plan for the technical function may need revising. For this revision, however, specific business objectives could be given and many key aspects of the future business environment would have been very carefully considered and evaluated. This greatly improves the basis from which the technical function can develop its ideas and programmes.

Notes: In this paper the work of the technical function, along with that of the other functions is outlined in developing the Business Unit concept, put forward in the previous paper on Planning. It mainly covers the ongoing activities of the Business Unit and the work which can be seen as a natural evolution of its present activity. What it does not cover is the identification by both the Planning and Technical Functions of the longer term developments of a company or its Business Units, and also possibly the fields for still wider diversification. These will be dealt with in Part II.In many cases, however, a surprisingly high proportion of the Technical Function budget is spent on the natural extension of the present business and a means of analysis by business unit objectives is proposed so that other functions can participate in the setting of objectives and evaluating progress. Close identification with business unit objectives will be found helpful in eliminating waste and often identifying new problems for the Technical Function to pursue.

Notes: When corporate planning has been tried by a number of organizations a number of difficulties have arisen. These are often a consequence of the planning system itself and the manner of its introduction to the organization. A new approach is described in this paper by which planning is introduced in stages. Each is a logical development of the previous one but each makes a reasonable demand on the staff and there is time to ensure that the data needed at each stage by the staff is available. Furthermore, the staff contribute to the development of the planning system which, at each stage in its evolution, is adapted to their needs. Having thus described the introduction and evolution of a planning system in an organization, a later paper will review how the technical function of a company can link into it.

Notes: Early Warning Signals for R&D Projects. By R. Balachandra. Lexington Books, D. C. Heath and Co., Lexington Mass., 1989.

Notes: AbstractThis is the third paper to arise from the same piece of research concerned with the development of Expert Systems (ES's) in the management of R&D. The first paper described the overall approach to the work and summarised the problems encountered, whilst the second focused on the software side of the work and the problems it entailed.In this paper the focus is on the process of project evaluation itself. The simple purpose of creating an ES is to capture the expertise of those well versed in a particular field and try to reproduce it in the ES. In this work, however, the hypotheses on which the development of the ES was based, and their subsequent support by considering actual projects, cast doubt on the theoretical background of project evaluation as reviewed in literature. The basis of these doubts is set out in this paper together with discussion on what is necessary to improve the situation. It was necessary to come to these conclusions prior to the development of a final ES on project evaluation, and is here published not only because of its interest in its own right, but so that others who have already worked in the field might reconsider their data in the light of the criticisms. By this means they would have a contribution to make to a better understanding of evaluation and of the on-going work on a new ES, now developed and operational, which has been designed as a research tool as well as its normal function of giving managerial advice.

Notes: The work here described is the early stages of a programme to develop a series of Expert Systems (ES's) in the management of R&D.In particular, the development of a prototype ES using a package program Crystal Ver. 2.1 is the focus together with the problems encountered.The literature had suggested that the use of such packages facilitated the process for those exploring ES's. What was not clear from the literature or the program manuals was the limited range of problems which could be handled. The programs have a rigid structure such that unless the logic of the problem solving process matches that of the program, severe difficulties will ensue.This paper outlines the inherent structure of the programs and indicates the kind of problems which would fit. Specific problems which were encountered when trying to stretch the use of the program are explained in detail. It goes on to explain how these problems were got round using Lotus 1–2–3 which proved far more flexible in practice. This kind of understanding is essential if ES's are to become every-day tools of R&D management.The objective in developing the Expert System (ES) was for it to be advisory to those preparing project proposals for possible submission to higher management within the context of an R&D laboratory. Thus the intention was to capture the expertise of senior managers, make it available to more junior ones, and thereby improve the quality of their work. This concept proved to be naive in that the expertise proved to be so diffuse that a wholly new rationale to structure the expertise had to be developed. This process, the subsequent development into a prototype ES, and its evaluation, have already been published (Wilkinson, 1991).The literature on ES's had suggested that the use of available package programs was straight forward and that the real problem was in establishing the expertise to be used and in structuring it to fit the program. This too proved to be an over-simplification. When this work started, the exact nature of the package programs had not been spelt out adequately. The purpose of this paper, Part II, is to describe their inherent structure and the limitations which this imposes on the kind of problems for which they can be used.The insights gained in this work into the evaluation of projects and the inadequacies of previous evaluation techniques will form the contents of Part III of this series of papers.

Notes: The paper considers the implications for future corporate strategy of the probability that the capitalist world is in the down-phase of a 50-year long-wave Kondratieff' economic cycle. Without commitment to a universal theory of long-wave generation the author proposes a lifecycle model of a whole industry or dominant technology. He deduces from this the likelihood confirmed by some historical data that major industries will at best survive one cycle and will almost inevitably decline after the next. Individual firms within such sectors will go down with the industry unless they face the need early enough in the decline phase to embrace a new technology in the next up-phase. The author provides a framework for diagnosing the phase of the lifecycle occupied by an industry or firm. He suggests that by combining this with an existing model of corporate strategy a company can plan a course of action that will improve its chances of survival.

Notes: This paper reports interim results obtained from research on the development of an expert system originally intended to be advisory to managers at all levels of R&D on the selection of projects. Whilst diversity had been expected, when the ‘Experts’ were consulted, there was a total absence of agreement as to how projects were selected.This led to a shift in objectives. The first shift was from project selection to project evaluation which was identified as the real activity which managers undertook in conditions where the number of projects was likely to exceed the resources available. The second was to try to classify projects such that projects in one class might have similar criteria for evaluationIn pursuit of these new objectives, the rigorous thinking necessary to structure the guidance of the ‘Experts’ into an expert system gave new insights into the nature of projects themselves and their management in support of corporate strategy. This paper sets these out and will be followed by Pt. II which will report on structuring the actual Expert System, and Pt. Ill giving the details of the managerial approach and the decision support process of the actual expert system