A process of elimination?

6 mins read

For years now, IT vendors serving the process industries have been convincing themselves and their users that central control and management of recipes and processes is the way to go. Andrew Ward finds it might not be.

According to the IT vendors, batch production control systems are getting ever better at doing their job, especially in the process industry sectors of bulk chemicals, pharmaceuticals and food and beverage. In theory, we’re moving much closer towards the ideal of being able to hold both recipe and process information in one centrally-based enterprise IT system, enabling any manufacturer to produce anything anywhere, according to demand, by downloading this information to local plant-based control systems. If this goal could be achieved, there are plenty of benefits in store for the manufacturer, according to Dale Barrington, product development director at mid market enterprise software developer SSI. “You’ll get better data accuracy, cross-business consistency and co-ordination – financial and costing information is going to be the same, thereby supporting centralised planning, forecasting and costing operations, and even centralised sales and procurement activity.” Other benefits include common product coding and structuring, and common central quality management. “Achieving better quality is easier if you have global consistency in the way products are made, regardless of what plant they’re manufactured in,” says Barrington. Centralised recipe management requires integration of process control systems with centralised enterprise (ERP) systems, and that in itself yields significant benefits too, explains Mark Chung, systems sales manager at automation giant Siemens. “By bridging the gap between upper-level MRP and ERP systems, all the way down to the factory floor, a fully electronic system delivers greater repeatability, with avoidance of human error as a result of inputting data from multiple sources.” To meet this goal, manufacturers would need multi-business, multi-plant IT systems that can centrally store both recipe and process information. “They must allow you to easily integrate information, and replicate data between the systems,” explains Barrington. “But they must be flexible – you must be able to differentiate between responsibility for data at the plant and corporate levels. “Some data will belong to cross-business corporate functions managed centrally, and other data will be owned at plant level,” he continues. “However, the line between them will vary from company to company, depending on the structure, goal and culture of the company – and the software needs the flexibility to accommodate these differences. For example, some companies may want central product coding, but local sales and purchasing. Thus one single, all-encompassing database that holds everything is unlikely to be the right solution – manufacturers are more likely to want several systems with effective integration.” Products to achieve this are available today, according to both Chung and Barrington. “It’s completely feasible in our product to define a whole range of characteristics for a particular process, going beyond just a hierarchical bill of materials,” explains Barrington. “Thus, you can hold centrally both the how – the process definition – as well as the what – the recipe.” However, they both caution that this is all theory, rather than fact. “I’ve never seen it done at a detailed level for process definitions – only at the recipe management or bill of materials level,” says Barrington. Chung also comments: “It’s certainly achievable – we have the systems software and products to store complete enterprise-wide recipes at one location, and then send them to any plant – but I wouldn’t like to say anyone’s done it yet.” Part of the reason for the delay is the wait for standards. “S88 is key to making life easier at the operations layer,” explains Chung, “while de facto standards such as Windows NT come into play at the next layer up.” Another factor is the amount of work necessary. “For example, everybody now claims to be talking about SAP, but how many people have really fully implemented it? Things are moving at a fast pace in the batch world – pieces of the jigsaw are coming together. Electronic signatures and batch records are becoming more and more prevalent, and are making life easier than manual paperwork-driven systems, with operators entering recipes by hand. Each bit of the technology takes us nearer.” One important element that needs to be in place is integration between plant and business systems, and this is frequently being driven by the need for faster and more accurate information that results from e-commerce initiatives. “You need packages to provide the links into higher level systems such as SAP – we can transfer recipe information from SAP through to the control system,” says Chung. One manufacturer planning to implement such a link is Clariant, a global speciality chemicals company with more than 32,000 employees and annual sales of over 10 billion Swiss francs. At Clariant UK, David Gunton, senior process control engineer, says: “We currently have individual control of a batch process through batch management software at the plant floor level. We also have a world-wide implementation of SAP [at the enterprise level], which we use for production planning for batch recipes at the business end.” Currently, these systems aren’t linked. “Although we do foresee a link between them in the medium term, it would be passing information and not control,” explains Gunton. “We will have standard recipe information that would be held in SAP, and then downloaded into the plant control systems. However, the operator will modify these during the process run.” This means that the integration has to be in two directions – not just the imposition of a recipe on the local plant. “The operator will have to enter any necessary corrections to take into account such things as different strengths of raw materials, and what’s actually available at the time on the local market.” Information on what was actually used in the production batch would then be sent back to SAP. Chung accepts it’s likely we will always need human intervention. “By storing recipes centrally and downloading that information to local plants you will have achieved some of the objectives, but if you’re manufacturing chemicals in four different continents, there are going to be differences – someone local has to have knowledge of the process.” Barrington confirms this view: “Many multi-company groups and multi-plant operations need to retain local management of process definition, because of different plant characteristics. In a completely green-field site this wouldn’t be such a problem, but for most manufacturers you tend to be controlled by the machines and process capability you have. Different makes of hardware are going to have different characteristics – the age and condition of the plant, the climatic conditions, all these factors are going to give you different optimum operating conditions in different plants.” Scalability is also an issue, as Barrington explains. “In the chemical industry, for example, recipes can vary depending on the process you are using – in different size vessels the ingredients may change in a non-linear fashion. So a standard recipe is fine, but standard process characteristics are not really feasible.” For some companies, another benefit of centralised recipe management is simplification of R&D. “You don’t want to invest in R&D expertise in every environment – replicating boffins around the world, each working in their own little islands,” says Barrington. But at Clariant, even centralised R&D isn’t appropriate. “We’re building complex molecules, and there are different ways of doing that,” explains Gunton. “Centralised process definitions and even centralised recipes would stifle innovation. We encourage plants to try differentiation – to find a better or cheaper process. Our driving force is to reduce overall cost, and centralised control would actually defeat these efforts.” And he continues: “Other factors mean that one process will never be appropriate for every plant. We have 150 plants around the world, and all are at different levels of investment standard and technology. There are also differences in local economic conditions that may mean it’s more appropriate to use a labour-intensive process in one economy and a highly automated one in another.” There are other obstacles in the way of achieving centralised control, as Barrington explains. “The areas that many organisations would have difficulty with are global management of product coding and resource management. Differences in culture, language, communication and geography are all inhibiting factors, and while it tends to be easier with simpler processes, even then you’ll encounter significant local variations.” Whatever the challenges, Chung believes that even smaller companies can benefit at least from the efficiencies of a paperless regime, where recipe information is communicated directly to batch control systems. “The systems usually used to generate the recipes, such as Baan, SAP or JD Edwards, represent a high capital expenditure – which restricts them to medium to large companies. But you can also use standard office applications for recipes, so you can cover all the way from single-stream single-products to multi-stream multi-products.” It’s clearly early days yet for totally centralised batch process control systems. Many manufacturers still have to put in place a lot of the groundwork, including even the interfaces between plant controls and business systems, although advances in IT systems and standards efforts are making that more achievable. But for some organisations, there will always be significant obstacles in the way of a single, enterprise-wide recipe and process definition. However, in whatever form it can be achieved, integration between ERP and process control systems will help make forecasting, planning and costing much easier, also providing better real-time information as a foundation for effective electronic business.