Functionality of ERP in mechanical engineering: "Kings can do everything"?
The question of areas of a functional covering of ERP systems in mechanical engineering is particularly acute enough. A part of experts believes that a standard ERP system does not cover even 50% of functional requirements of engineering enterprise, at the same time, with it examples of rather effective implementation of ERP systems in the industry in close integration with specialized software products are known.
Question of that, the functionality of ERP systems and whether it is possible to do effective business is how broad, using only possibilities of the ERP system, without implementation of additional applications of best-of-breed, rises quite regularly. At the same time representatives of developer companies as it is easy to guess, argue the point of view about self-sufficiency of the systems of the class ERP, motivating it with "broad functionality", "flexibility", "advanced technologies", "decades of experience", "deep industry expertize" and similar widely known phrases.
At the same time, those who directly are engaged in implementation and operation of automated information systems at the enterprises, in particular, Chief information officers, speak about the absolutely return. According to them, the ERP system just not capable to cover all subjects of automation processes of the company. And the it is more difficult these processes at the enterprise, the ERP system from becoming "the answer to all questions" in the field of automation is farther. And, as the organization of work of engineering enterprises is one of the most difficult, the problem of "functional insufficiency" of ERP systems and, therefore, lack of alternative of "scrappy automation" has a direct bearing on them.
The practice (which is, as we know, the most reliable criterion of truth) confirms correctness of the point of view of the second party of this correspondence discussion (customers). Naturally, at the enterprises such specialized information systems as CAD/CAM/CAE, PLM/PDM, SCADA, MES, etc. are used. However, they, generally speaking, do not treat "business applications", and the methods of representation and data processing implemented in them and the stored and processed data, significantly differ from like those in ERP systems. Therefore, formally, the systems of the listed classes and similar to them do not belong to area of a covering of ERP systems at all. Respectively, sharing of similar information systems and ERP systems, instead of synthesis and inclusion all of them in the structure of ERP, looks quite reasonable (though among recent trends of development of ERP systems a number of analysts notes "descent" of the similar systems to the level of workshop and even technology equipment). Similar "symbiosis" of information systems at the enterprise is, perhaps, the most natural.
However not less often ERP systems are used with business applications of best-of-breed. Similar sharing of the information systems of similar orientation duplicating work of each other at first sight does not seem logical. Whether it is valid, reasonable to purchase additional business applications from independent developers (spending for them occasionally very notable amounts) if in the ERP system the corresponding functions are implemented as it is? It appears — reasonably. The matter is that the problem of a ratio of universality and specialization concerns also ERP systems: the station wagon "is able to do almost everything", but "is not strong" in a reality and parts; the specialist, on the contrary, knows data domain "backwards", but has no system vision and is not capable to go beyond specialization. Respectively, today's ERP systems are capable to provide complexity of automation, but, as a rule, concede in each separate application area to specialized solutions. Thus, main advantage of ERP systems really is the "common information space" integrating all guidance loops within a system (though sometimes it turns out that in separate ERP systems the specified unity is implemented not completely). Now, ERP systems in many cases are used together with independent solutions of classes: SCM, SRM, WMS, TMS, CRM, ECM/DMS, BI, HRM and even FM and MRPII which cope with the problems of automation facing the enterprises with higher quality and effectively (including economically), than the corresponding modules of the ERP system. Developers of ERP systems, on the one hand, try to resist to similar practice, purchasing independent developers and turning on in the product lines the solutions which are earlier relating to best-of-breed, and, on the other hand, develop integration tools of applications, implementing the concept of "Packets of business applications the" (Enterprise Apllication Suites — EAS) allowing to use solutions of independent suppliers on an equal basis with the modules ERP systems.
Except described above, sharing of ERP systems from different developers is frequent (including leaders). In some cases such situation arises accidentally, after consolidation or a company takeover, but there is also a practice of purposeful joint implementation of different ERP systems and their integration for expansion of their functional covering. At the same time one ERP system, with more developed financial and analytical functionality, can be implemented in management company or head office, providing consolidation of data, management of budgeting, financial planning and the analysis while other system, with the developed industry functionality, can be developed at specific manufacturing enterprises. In this case, ERP systems mutually supplement each other, compensating shortcomings of width and (or) completeness of functionality of each other (however at the same time the unity of data is in many respects lost). Similar practice exists including in Russia and, most likely, will continue.
Thus, there is an objective confirmation to the fact that the area of a functional covering of ERP systems not only has the restrictions, but, actually, is even narrower, than nominally declared width of functionality of the systems of this class as a number of the functions implemented in them is not worked out to the level really necessary for customers.
Along with it it should be noted that the way of development of ERP systems based on "push" in them the increasing number of functions and also deepenings of already implemented functionality as it was already noted by experts, is deadlock. First, it is impossible "to embrace the immensity" and to compete on functionality at once with all independent developers, each of which is a strong specialist in the area. Secondly, purely technology, having reached a certain level of complexity (because of a functionality overload), the information system will just cease to work reliably, and expenses on its permanent fine tuning and recovery after failures will reach such level that it will be simpler to refuse it and to work with separate applications.
Therefore, ERP systems even in the long term will not be able to become "electronic nervous system" of the enterprise and to provide its complex automation only with the means which are built in them.
However whether follows from this what use of ERP systems is unpromising? By no means not. First, as it was already stated above, there is an ability to integrate and sharing of ERP systems with specialized business applications and even with other ERP systems (or their modules). It is so possible to solve many problems connected with a lack of a functional covering of solutions "from some hands" though as a result and it is necessary to renounce a possibility of deep data analysis (Drill Down) and also to resolve issues of synchronization of databases of different applications.
Secondly, development of integration platforms and service-oriented architecture together with leaving from monolithic information systems to modular and consisting of sets of services should change the current provision and provide a possibility of considerable expansion of functions of the unified information system of the enterprise without the negative effects described above. Ideally the enterprise information system will be under construction on a certain core (the integration platform, "middleware", the corporate service bus) which will provide unity of data and approval of work of the separate services implementing separate functions or their sets. At the same time services can be executed as locally, on ADP equipment of the customer, and far off, on the hardware of provider. Respectively, functional filling of future packets of business applications will be provided not only their vendors, but also independent developers who will be able to integrate high qualification of the specialists with the standard environment of execution of corporate services.
It should be noted, however, that real implementation of SOA is integrated to a large number of difficulties and considerable costs, "service buses" at different vendors are incompatible, the declared use of "open standards" turns into quite closed their implementation and "corporate" expansions, and there is practically no finished unified information system constructed on service-oriented architecture in one company. Also, according to TAdviser, without standardization of infologichesky models (and not just data transfer protocols and the interchange formats data) will hardly possible to achieve a high integration scale of diverse services and to provide an emerdzhentnost to the information system constructed on their base.
At last, thirdly, it is worth to remember that even today's "broad" functionality of ERP systems is under-exploited by the enterprises far not completely. According to materials of the last research conducted by Aberdeen company, in mechanical engineering less than a half of functions of ERP systems is used. On unofficial assessments of participants of the Russian market at us this percent, most likely, even lower. Therefore though, of course, it is necessary to think of functional completeness of the ERP system at a stage of its choice, in practice the problem of mastering even of that functionality that it is implemented in the basic version of a system, is very difficult, and its successful solution provides to the enterprise enough advantages in order that then without extra risk for business to solve all problems with further expansion of functionality.
Thus, on the one hand it is necessary to understand that possibilities of ERP systems are limited and that to automate the complex enterprise, especially machine-building, using only the ERP system, it is impossible in principle. From other party, it is not necessary and to try to solve all problems of automation of the enterprise by means of the ERP system. Anyway it will need to be integrated with other applications, including, with those which suit the enterprise more, than "native" modules of the ERP system. Besides, not bad at first really to implement at least a half of the Enterprise resource planning functions, and after it to estimate need and prospects of its expansion.