FOCUS:

When defining IT architectures, IT teams must focus on business requirements, while avoiding poor planning and system overlap

By Mark Cubine

Paper Industry IT Architectures: Putting the Software Pieces Together

You may have noticed lately that there are lots of pressures coming into play for information technology (IT) management in the paper industry. When large companies merge, IT systems, staffs, assets, and operating locations all have to be rationalized and integrated. Additional pressures include the dynamics of planning for and implementing e-commerce, without a clear picture of how this new business method will play out in the paper industry. On top of those challenges are the typical IT department demands of supporting existing applications, planning and executing upgrades of legacy systems, implementing new systems and projects, and recruiting and retaining IT talent in an old-line industry.

FIGURE 1. When designed appropriately, IT architectures are driven by a company's business strategies, which they then support.

Fortunately, in-house software development is one burden that is almost obsolete for IT departments in manufacturing companies. Selecting, implementing, integrating, and, to some extent, supporting commercial off-the-shelf (COTS) applications software is what IT departments now do. Today, managing the applications architecture for any manufacturing company is really about how you put the pieces together.

If you look closely at the fundamentals of planning, implementing, and sustaining an IT applications architecture for a manufacturing enterprise, they haven’t really changed in a long time. A company’s operating and manufacturing strategies drive information systems requirements, which define the applications and systems that are put in place. These applications then support the business and manufacturing processes targeted by the company (Figure 1).

However, when business requirements cease to be the driving force behind information systems applications, the net effects can be very negative (Figure 2). There are examples of information systems deployed in the paper industry that were so out of alignment with the real requirements that they inhibited the company’s ability to do business. In at least one situation, an enterprise resource planning (ERP) system deployment caused the company to become less effective in taking orders, planning production, controlling waste, and making product shipment commitments. In short, it made that company less effective from an operations and manufacturing perspective than it had been before the system went online.

Unfortunately, in this age of commercial off-the-shelf software, the scenario in Figure 2 happens just a little too often. It is not just limited to COTS application strategies focused on ERP systems, but for a variety of information system types. There are many reasons for those arrows to turn in the wrong direction, as in Figure 2, and the following sections discuss some ways the IT team can avoid these traps.

DOCUMENT BUSINESS PROCESSES. It is crucial that IT departments adequately understand and document the business and manufacturing processes a designated application must support. Unfortunately, IT departments are not necessarily better at this than they were ten or fifteen years ago. Ironically, some even paid closer attention at that time, because they knew they had to actually design and write the applications.

Today, there is a major temptation to shortcut the requirements definition process. The most typical symptom is when the IT team identifies a short list of vendors, assembles a team of end users and management to select the application, and then proceeds to orchestrate a beauty contest of vendor demonstrations to drive the decision. Many times, these events occur without ever producing a decent requirements document of any type.

It works much better when the entire team, including IT, end users, and management, have a clear understanding of the current processes and where they want to go in the future before selecting vendors. If executed correctly, the requirements definition process provides this understanding. It also better serves the COTS vendors being evaluated, since they are more clearly able to understand what is expected of their product and can better explain how it adds value while meeting those requirements.

FIGURE 2. When business requirements are not the driving force behind IT architectures, it limits a company's ability to do business.

REALIZE APPLICATION LIMITATIONS. As we all know, most application packages were not designed for the pulp and paper business. Let’s face it, paper manufacturing is different from the automotive, electronics, food and beverage, pharmaceutical, chemical, and petroleum businesses that most major COTS products were designed for.

There are only a handful of applications written from the ground up for the paper industry. All of those are either from relatively small companies or very small divisions of large companies, so each tends to address a specific niche or set of functions for paper manufacturing companies. And, none of the native paper industry COTS applications do everything needed, so even if a company were to stick with those vendors, it would still have to piece a number of them together to derive all the required functionality.

There are two things to be cautious of here. The first is the inclination many IT professionals have to follow current IT industry trends with respect to off-the-shelf applications. Many IT teams gravitate toward mainstream COTS products that other non-paper manufacturing companies have implemented. This has led more than one company to try and implement applications that appear as market leaders for the manufacturing sector as a whole, but ones that are not a good fit for paper applications. Choosing any mainstream off-the-shelf product will probably not have any real negative impact on the financial systems, purchasing, or human resource products your team chooses. However, it could be a real mess if you try and force fit systems designed for other industries into customer service, production scheduling, order processing, and manufacturing for the paper business.

Secondly, corporate IT teams in the paper industry need to be prepared to assemble some sort of “best-of-breed” approach in architectures built on COTS products, recognizing in advance that no vendor can do it all in most cases. Some of the successful best-of-breed approaches paper companies have taken in recent years created architectures that included as many as three or four products from different vendors. For example, one company’s current best-of-breed architecture includes SAP’s R/3 ERP system integrated with Mountain Systems Inc.’s manufacturing execution system (MES) and product life cycle management (PLM) system, plus part of Greycon’s advanced planning and scheduling system (APS) solution.

STANDARDIZATION AT ANY COST? Many IT departments have set up a single applications architecture standard for all business units under their corporate umbrella. This is not a bad idea in some cases, and such standardization can provide huge savings for the enterprise in terms of IT costs and support costs. In addition, this approach can be used to standardize business processes and practices. It can also leverage scarce IT resources to provide the greatest value to a large number of sites.

However, such a standardized architecture becomes a problem in cases where business and manufacturing processes can’t or shouldn’t be standardized across very diverse businesses that happen to be under the same umbrella. For example, some comprehensive solutions appropriate for a large mill simply cost too much and add too little value to be deployed in smaller mills. It is unreasonable to expect a solution that is ideal for one papermaking division will necessarily work for a converting division or a division making a very different set of products serving a completely different market.

Corporate IT strategists need to be cautious that the drive towards standardization does not begin to limit the best operating and manufacturing strategies in diverse mills and plants in the name of standardization. In other words, don’t drive the business units in directions that don’t make good business sense, because IT strategies and architectures need to be flexible enough to accommodate more than a single set of components or products from specific vendors. It is very important to allow individual business units to use systems and products that offer the specific functionality/scalability they need and at a price they can afford.

RECOGNIZE AND ADDRESS APPLICATION OVERLAPS. When you decide to purchase and implement two or more major COTS packages in a paper manufacturing environment, you are likely to encounter serious functional overlaps (Table 1). IT teams must work with business management teams to determine how best to resolve these.

There are two sticky issues here. One is determining which version of the function from what application is best suited for the business requirement. The only way for the team making those decisions to do a good job is to have a very clear picture of the requirements based on understanding the business and manufacturing processes, as described earlier.

The second challenge is determining how to technically integrate the rest of the architecture around the decision made for resolving the functional overlap. This is much tougher than it sounds. It can lead to difficult and sometimes expensive workarounds when two or more applications are dependent on the same data and one application must control and synchronize with another. It is quite possible that the technical challenges associated with resolving a specific functional overlap between two application products will be the issue that tips the scale in favor of one direction over another.

START PLANNING ON DAY ONE. Comprehensive planning for the IT department is not limited to vendor selection and applications architecture design alone. Program and project management, roll out programs, short term and long term support, ongoing training, and a host of other issues must be dealt with. These are not things to be put in the “later” category, because close examination of those issues should be part of the decision process when the team is making architecture decisions.

The need to define or refine and re-think software applications architectures will not be limited to companies coming out of mergers in the next few years. It will also arise out of the need to respond to changes in the paper business as a whole, including e-commerce initiatives. Doing it well represents both a challenge and a chance to add a lot of value to the company for the IT professionals in the paper industry. *

Mark Cubine is vice president of EnteGreat, Birmingham, Ala.