Using an intranet for real-time production management: experiences and effects

Abstract

Newspaper production is a complex and suboptimised process, characterised by heterogenous computer systems in a distributed environment and with tight time schedules. Attempts to optimise this process have generally been on a local subsystem level, without an overall perspective. With the emerging IFRAtrack standard for exchanging tracking and scheduling information, new possibilities for global production management are emerging. This paper describes a three-tier intranet-based solution for a production management system in newspaper production. Tracking information is collected from subsystems via IFRAtrack messages. It is then stored in a production database and distributed to the client modules. Clients can either poll the server for updates, or they can subscribe to particular events. The user interface runs in any WWW browser, thus facilitating installation and maintenance, and ensuring that information is dispersed throughout the company. The entire system is written in Java and is built around ODBC-compliant databases, thus ensuring a high degree of portability and platform independence. The prototype described is being used in daily production since June 1997 at a middle-sized Swedish newspaper with good results. Interviews with personnel suggest several benefits: Employees have increased their awareness of the production process. Cooperation between traditionally separated departments has improved. The newspaper has gained a more thorough understanding of its production process and its bottlenecks.

Keywords

Intranet; Real-time; Java; Workflow; Production management information system

1. Introduction

Newspaper production consists of two very different production processes linked together: on one hand, the creative process of manufacturing an original; on the other hand the high volume mass production and distribution of copies [1]. Both processes are highly susceptible to disturbances, and delays are propagated along the production chain, causing high delay costs.

Modern newspaper publishing is an extremely heterogenous, multivendor, multiplatform environment. There is no common database, nor are there any means of production control. Today, the actual production status and the implicit production plans are held in the minds of a few persons responsible for getting the paper out on deadline. The few systems that exist take a local approach to optimising. They concentrate either on the prepress area, or on the printing plant. However, they do not take into account the complex interrelationships that exist between steps in the production workflow [1].

The basis for global production management is a standardised mechanism for exchanging tracking, scheduling and control information between different subsystems [2]. With the advent of the IFRAtrack recommendation, there is now a platform for building such systems. The IFRAtrack recommendation [3] defines a set of objects (Fig. 1), workflows, and states. The objects are divided into different object classes. The state of an object is modified through processes. The changing of the state of an object is called an event. Production tracking consists of the registration of events. By associating the events with objects, workflows and states, a tracking system can follow the progress of the production run.

For instance, an IFRAtrack message could carry information that a particular page for tomorrow's issue has been completed in the page assembly workflow. The message will also contain information about the time when the event took place, which computer was used and the personnel involved. It may also set a deadline for subsequent steps in the production chain. If the next event does not take place within the expected time limit, a warning will be generated.

Fig. 1. The IFRAtrack object model.

The development of intranet technology and the Java programming language has been truly impressive during the last two years. We have reached the point where they can be used as a set of tools for building the kind of platform- and vendor-independent systems needed in the newspaper publishing industry, or, for that matter, in any other industry.

Based on the IFRAtrack recommendation and on theoretical work [4], [5] conducted at the Division of Graphic Arts at The Royal Institute of Technology in Stockholm, Sweden, our research team has implemented a prototype for a global production management system applied to newspaper production [6], [7]. Five newspaper companies and two distribution companies have participated in the project during the last two years.

The resulting prototype has been installed and tested at Östgöta Correspondenten for the last six months. This is a middle-sized Swedish newspaper, with two editions and a circulation of around 67.000 copies six days a week.

2. System functionality

2.1. Overview

The aim of the system is to cover the entire production chain of a daily newspaper, from planning of the issue, through the different steps involved in original production, further on to multiplication and distribution. The system is not a production system, but a production management system. This means that the system is not involved in the actual production of the newspaper, it's task is just to supervise it. In addition, the system must be able to provide decision support, generate reports, archive old data and accumulate knowledge about production characteristics. Figure 2 shows some of the modules available.

The system must add value for managers on different levels, for personnel in the actual production line, and for the economy department alike. At the same time, from the point of view of a user, it must be as unobtrusive as possible. The amount of extra work required to feed the system with data must be minimal, preferably non-existant.

Fig. 2. The system toolbar.

2.2. Planning and scheduling

Figure 3 shows the schedule planning module. Every evening, before actual page production starts, the supervisor in charge creates a page schedule. The page schedule then serves as a basis for the entire production chain.

Page producers are selected and pages are assigned to them by interactively clicking and dragging the pages. The production manager moves pages around until a satisfactory schedule is obtained. The visual nature of the tool quickly gives an overview of the feasibility of the schedule. For instance, it is important to have no more than five pages in the last priority group, otherwise production bottlenecks will lead to delays.

Fig. 3. Page scheduling module. Objects are white, indicating that production has not begun.

Based on the page schedule, plans can be made for subsequent steps in the production flow. In Fig. 3, for instance, plate making must be reported as completed at most 45 minutes after page production is scheduled to be completed. The entire schedule can also be moved by a certain amount of time, either back or forward. For instance, if an important event occurs, the newspaper may choose either to reschedule certain pages, or to postpone the printing start so the event can be covered.

2.3. Tracking

Figure 4 shows one of the tracking modules, i.e. the page tracking module. Each rectangle represents a page in the newspaper. Pages are colour coded and contain information about the characteristics of the page (e.g. black and white, four colour, two colour), the current production status (not started, in progress, on hold, completed) and whether the page is late or not.

Fig. 4. An overview of the current page production status. Objects are colour coded.

A quick glance at the production overview is often enough to see whether the deadline will be met or not. When a page passes a deadline it turns red, and a warning is sent to the page producer it is assigned to. A warning can also be sent to the production supervisor.

Figure 5 shows a detailed view of the production history for page A8. It reveals that page assembly began at 15.23 and was not finished until 22.14. There were no deadlines assigned to the image setting and plate making workflows. Film quality control, however, had a deadline for 22.50, which was exceeded.

Fig. 5. Detailed view of production history for one page. Objects are colour coded.

Most of the tracking data is collected automatically, to mimimise the amount of extra work needed to run the system. Page assembly for instance is done in Quark Xpress, with a special Xtension. The first time a new document is opened, the page producer is asked to identify the page from a list of pages that have been assigned to him. The Xtension then adds a bar code to the page in a non-printing position, as well as an invisible tag. The bar code and the tag identify the page in subsequent steps.

When a page is sent to the printer, the page producer is asked whether the printout is final. In that case, an IFRAtrack message is sent to the system. Messages are also sent when a document is opened or closed. Further on along the production chain, messages are sent automatically by the RIP (Raster Image Processor), the film recorder and the plate line. All these systems have been provided with IFRAtrack generating modules by their vendors. Experience has shown that it is extremely easy to generate IFRAtrack messages from modern production systems.

2.4. Reporting

Figure 6 shows an excerpt from a production report. Reports are generated automatically every night. These reports are presented on the Web, and they can also be ordered and received by mail (Fig. 7). Each user can configure the reports he receives, in order to satisfy his particular need for information. For instance, a manager in the printing plant may be interested in the waste figures, while people in the editorial department need to know when they sent the laste page to the printing plant.

Today, reports are generated through simple scripts, but in the near future we plan to use a commercial report generator. This would increase flexibility and enable generation of more advanced reports. It would also make it possible for non-technical users to search the production database and to generate statistics.

Fig. 6. Excerpts from a production report sent by mail.

Fig. 7. A form for ordering various reports.

2.5. Archiving

Production data is only stored for a week in the production database. Efter that, it is archived and compressed in an archive database. An archived issue can be restored at a later stage if there is a need to study it in detail.

When an issue is archived, some key parameters are extracted and stored in the production database. It is useful to save the number of products, pages, inserts and circulation for each issue, as this can serve as a basis for decision support. Newspaper production exhibits trends over a year, a month and a week. These trends influence the total circulation, which in turn affects the amout of advertisements and the number of pages. This, of course, has an impact on paper requirements, production personnel and time schedules. All factors influence each other. For instance, the maximum press speed depends on the number of pages and inserts, as well as on the colour configurations.

3. System design

3.1. Hardware

The system runs on a Sun Ultra 1/170 with 64 Mb of memory and 6 Gb of diskspace, with the Solaris 2.5 operating system. The choice of server platform is partly due to the fact that Sun/Solaris is a common combination in the newspaper industry, and partly because new software is often released earlier on Sun/Solaris than on other platforms

The client computers run different flavours of MacOS, Windows 3.1 and Windows 95. The user interface runs either in a Netscape browser with Java support, or as a standalone application. Frequent users prefer to install the standalone version because of the higher performance and reliability obtained, whereas infrequent users run the applet version.

The pilot newspaper company has a fiber optic network with a capacity of 100 Mbit/s.

3.2. Software

The system is built around a standard Oracle 7.3.2 relational database. Since no Oracle-specific features are used, it would be easy to change to any other ODBC-compliant database. In view of the amount of advanced administration needed to operate an Oracle database, we are considering evaluating other solutions.

Most of the server software is written using Javasoft JDK-1.1, without any auxiliary packages or libraries. Some parts, more specifically the IFRAtrack parser and the reporting modules, are still written in Perl 5.003, because of its powerful string manipulation features. However, we are working on rewriting this code in Java.

The user interface is written using Javasoft JDK-1.0.2, since later versions have not been available on MacOS until recently. When porting this code to JDK-1.1, we expect to reach higher reliability and more predictable behaviour on different browsers.

The connection between server and database uses Oracle's database connectivity package for Java. Since this is not yet available on the MacOS, we also use a workaround. The clients construct SQL queries and call a CGI-script which executes them and returns the result. This is of course not an efficient solution, and will be changed as soon as possible.

The Web server used is Apache 1.1.1.

3.3. System design

Conceptually, the system uses two databases (Fig. 8). The IFRAtrack database stores the messages sent by external production systems, such as Quark Xpress, the plate scanner or the press control system. This database is open to all local systems, since they need to provide tracking data. All systems are also allowed to read from this database if they so wish.

Fig. 8. The system design.

The messages are retrieved from the IFRAtrack database and parsed. Information is stored in the production database, and mirrors the format of the current issue, i.e. all objects that constitute it according to the IFRAtrack specification (Fig. 1), their current status and their entire history. The production database also contains information about available production resources, such as personnel, computers and machines and their characteristics.

The production database contains data only for the last week's production. After a week, data is transferred to an archive database. Key parameters, such as the number of pages, the average time for page production, the press setup, printing start and printing time, are computed and stored in the production database. This information will later serve as a basis for adaptive decision support.

The object server has a number of tasks. First of all it handles the storage and updating of tracking information. It also handles requests from client modules, and subscription for particular events. For instance, a Quark Xpress client module, i.e. a Quark Xtension, can subscribe to all events concerning scheduling changes for all pages it works with. When such an event occurs, the object server will notify the client of the change. The object server is also responsible for archiving and deletion of old data, as well as extraction and storage of key parameters.

3.4. Design considerations

One of the main requirements on the system is platform independence. We began by evaluating different packages that claimed to facilitate porting between for instance MacOS and Windows. However, we found most of them too cumbersome and also too expensive for our research project.

With the advent of the Web, we found a solution and began exploring its possibilities. Early versions of the prototype generated HTML files and GIF images on-the-fly. However, this technology was not sufficiently powerful to create good user interfaces. Therefore, we moved on to Java, which offered both the power and the platform independence we sought. To achieve maximum portability we have used pure Java, without any vendor-specific features.

Another important design consideration is modularity. The system must be easy to install and to modify according to the needs of different newspaper companies. To achieve this, we have separated the conceptual databases, so as to be able to run them on different machines, or even in different DBMSs. Through the use of a well-defined API we have facilitated adding on new modules, and exchanging information between them. All information generated by the clients, as well as all information generated within the system is sent using IFRAtrack. Furthermore, the internal data model closely follows the IFRAtrack object model. Therefore, it would be easy to replace any subsystem with another IFRAtrack-compliant system.

4. Results

During the six months the system has been in daily use, benefits have been discerned in two main areas: the daily newspaper production and the organisational level. These effects have been established through interviews with personnel throughout the company, both with managers and with ordinary employees.

4.1. Improved production efficiency

Production managers now have better overview, and thus a much better basis for decision making. Formerly, they had to keep track of production status in their heads, or on scraps of paper that were passed around. Now they can keep track of each page, each film, each plate and so on. A schedule for each object is created and followed, with warnings received when a deadline is missed. This makes it possible to discover potential problems at a much earlier stage, thus ensuring faster feedback and a smoother production flow. "For instance, if a page is transmitted to the printing plant, and the film never shows up in the recorder, this will be discovered in a matter of minutes, instead of hours" (manager in the prepress department).

Through the system, data is collected and presented in a consistent way on monitors throughout the company. Everyone can also check the current production status on his or her own computer. This has reduced the number of phone calls and the amount of time spent checking whether things are ready or not. This is, of course, difficult to measure, but the interviews point in this direction. "Since the system can be used via the WWW from anywhere around the world, managers have the ability to follow production even when they are travelling, which is very useful" (technical director).

Thanks to the improved overview, the pilot company now feels that it could create a third edition of its newspaper. This was tried earlier, before the system was installed, but could not be carried through. The increased number of objects simply could not be managed without a production management system.

4.2. Improved understanding of the process

The system stores each object's history, and also generates reports. This information is now presented and analysed at daily morning meetings, where production is followed up. "Earlier guesses and speculations have been replaced by objective figures that cannot be questioned or obscured by inter-department conflicts" (managing director).

These figures are also distributed to managers. Therefore, the head of each department can see the effects of his or her decisions on the following production steps. He or she can also see whether delays can be traced to a preceding step. "Attaching cost figures to different delays has proven particularly successful, since the importance of meeting deadlines becomes clearly visible. This also makes it possible to charge delay costs to the appropriate departmental budgets" (economy controller).

This has led to an improved understanding of the production process. As a direct consequence of using the system, a number of bottlenecks and unsatisfactory conditions have been discovered and proven. Several projects aiming at solving these problems have been initiated.

Fig. 9. A printing job (straight line) and the corresponding distribution plan (jagged line).

For instance, as the printing curve in Fig. 9 shows, the irregular truck loading plan is too steep and too close to the actual printing curve. "This explains why some routes are very sensitive to delays in the printing process. The printing process causes delay costs in the distribution workflow" (economy controller).

4.3. Ethics and improved awareness

The introduction of a global production management system in a newspaper company is bound to meet with initial resistance from personnel representatives because of the sensitive information that is extracted (Fig. 10). This has also been true in our test case. Therefore, it is of utmost importance that management make an effort to explain their goal with the system. The point is not to watch over individual employees, the point is to discover problems at an early stage and to help everyone do a better job. It is not interesting to find out who is late with a page, only the fact that the page is late.

In our case, those opposing the system the most at the beginning, are now the most enthusiastic. "People soon realised that the system is not a threat, but an opportunity, and they adopted a positive attitude" (page producer). For instance, based on the figures accumulated by the system, a manager in the ad department has established that his personnel could go home one hour earlier every day, since they are always ready on time. This has become a strong incentive for personnel to use the system regularly to accurately report the progress of their work.

Fig. 10. A report showing late pages and page producers.

We believe the system has contributed to better cooperation between different departments. Impartial information is presented throughout the company and can serve as a basis for constructive discussions. It also sheds light on the complicated relations between the different steps involved in production, improving awareness among personnel. "The intranet makes people become more involved and participate more actively in quality improvement projects" (technical director).

5. Conclusions

The use of intranets for distributing information within a company is gaining acceptance. Using intranet technology for actively monitoring a production process is not as common. We believe our prototype shows that this is a viable solution. This approach is by no means limited to newspaper production, it may prove equally successful in other industries with a need to supervise a distributed process. The future will see an increase in the number of intranet solutions for real-time applications.

The advantages of an intranet solution over traditional client–server solutions is platform independence, ease of use and ease of maintenance. The main disadvantage is the relative immaturity of Java. However, we believe that the advantages outweigh the disadvantages, and that this will become increasingly so with future versions. In the near future the distinction between applications and Web interfaces will disappear. Instead, through the use of Java technology, any application will become networked and Web-based at no extra cost, as well as platform independent.

A newspaper company needs to change production systems in order to maintain its competitive lead and its flexibility. Unfortunately, until now, systems have been tightly interconnected and vendor dependent. Since newspapers have been forced to change several systems at the same time and with higher costs, development is sometimes inhibited. The use of intranet technology, together with the IFRAtrack standard for information interchange, offer a greater freedom of choice.

6. Future work

The system has been in use for six months now and a thorough follow-up study must be undertaken. Production characteristics for the last, say, three months should be compared to the three months prior to the installation of the system, in order to find trends regarding production efficiency and economy.

The system must be developed further. First of all it must be optimised, made faster and more user-friendly. The amount of extra work for users should be close to zero, which requires further automation of status reporting. Users should be able to enter information about why things are being late, so the reason for problems can be discerned more clearly.

Functions for follow-up and reporting must be improved. There is a strong need for the ability to create customised reports and search through the production database. Decision support must be added, as well as a simulation module that makes use of the accumulated data [6]. The ability to try what-if scenarios in real-time during daily production must exist. Stronger connections to economic parameters must be established.

Work should be undertaken with the aim of generalising this approach to other industries.

References

[1] N. Enlund, Production management for newspapers, in: Proceedings of Seybold Newspaper Conference, London, April 1994, pp. 32–45.

[2] N. Enlund, Global production management in the publishing industry, in: Proceedings of 4th St Petersburg International Conference on Regional Informatics, St Petersburg, Russia, May 1995

[3] F. Fällström, IFRAtrack 2.0 – A specification for the interchange of status and management information between local and global production managemenet systems in newspaper production, IFRA Special Report 6.21.2, Darmstadt, Germany, 1997.

[4] S. Nordqvist, A model for global production management systems in newspaper production, Ph.D. thesis, The Royal Institute of Technology, Division of Graphic Arts Technology, Stockholm, Sweden, 1996.

[5] J. Stenberg, Global production management in newspaper production and distribution – Coordination of products, processes and resources, Ph.D. thesis, The Royal Institute of Technology, Division of Graphic Arts Tecnhology, Stockholm, Sweden, 1997.

[6] F. Fällström, V. Ionesco and B. Hedin, Using a simulator for testing and validating a newspaper production decision support system, in: Proc. of 30th Hawaii International Conference on System Sciences, Hawaii, January 1997.

[7] B. Hedin, F. Fällström and V. Ionesco. An intranet solution for a real-time GPMS in newspaper production, in: Proc. of 30th Hawaii International Conference on System Sciences, Hawaii, January 1997.