The Post-implementation Agility of Enterprise Systems: An Analysis
From Technology Evaluation/P.J. Jakovljevic and Olin Thompson
To say that implementing enterprise applications has not customarily been a simple feat would be a gross understatement. But to give the devil its due, over a long period of time, enterprise applications providers (and their resellers and system integration [SI] partners) have made some notable strides to partially ease implementations, and ensure some pre-implementation alternatives—and thus flexibility for their customers.

Indeed, leading enterprise resource planning (ERP) systems now offer broad functional coverage which nears best-of-breed capabilities and end-to-end process scope. Other notable evolutions include vertical industry extensions; ever-improving technical architecture; training, documentation, implementation, and process design tools; continual product enhancements; global support; and an extensive list of software, services, and technology partners. A good example might be SAP's application management platform, SAP Solution Manager, which offers improved processes and tools for managing SAP applications portfolios. By providing tools, integrated content, services, and best practices from SAP, this centralized platform aims at helping customers implement, operate, and monitor applications with improved visibility across the entire SAP landscape.

Yet the current state of the market consists of largely “standard, best-practice, configurable” applications; the (often false) assumption is that standard “vanilla” software applications can bring best practices to a business, and be made flexible enough to accommodate the majority of businesses without significant modification. Through the use of complex tables, parameters, and switches, the software can be pre-configured to handle a large number of pre-determined, supposedly “flexible” options. But in truth, such commoditized flexibility only means choosing from a list of existing, predetermined options, and if the required option does not exist in the vendor's menu, there is no real flexibility available.

Furthermore, once the options are selected, the flexibility to change any of the options is often non-existent, or comes at a hefty price. In other words, it might be possible (since almost everything can be achieved in the realm of information technology [IT]), but only by leveraging an army of well-paid consultants and programmers who are glad to oblige any specific customer's requirement. However, the point is to achieve user self-sufficiency, and to leave them feeling as though they can tweak the system to their personal needs, at will.

Moreover, this limited parameterized configuration approach ironically comes with heavy costs in terms of the increased complexity of software code, which leads in turn to erratic quality, extensive implementation lead times, and difficulties in changing the software once implemented. The issue of flexibility might be solved for an initial implementation, but ongoing business innovation and change is not supported. Software templates and quick implementation tools might help to solve the problem of long implementations arising from complex tables and switches, but they do nothing to address the underlying problem of inflexibility after implementation.

A key objective of “standard, best-practice, configurable” applications has been to eliminate the need for modifications. While this has been the stated goal (and nirvana) of many user companies, the statistics repeatedly prove that it is not, in fact, how the majority of companies are running their enterprise software in real life. There have been many indications that the majority of ERP customers have modified their systems “quite a lot.” The real truth about standard software applications is that very few companies really run them as standard or “as implemented” products, since every business changes constantly, in small ways and large. Successful companies are increasingly taking on new business models and business processes in an ongoing effort to outmaneuver their competition.

These companies have found that there is an inherent conflict between the fluidity and agility with which they want to run their businesses, and the rigidity and control with which their enterprise systems operate. This incompatibility between agile businesses and static underlying enterprise systems has hampered efforts to change the business effectively and rapidly—changes which are required to capitalize on ever-occurring business opportunities. Whether a company is aggressive or conservative in its adoption of change, change is inevitable and ongoing. Some vendors have recently made attempts to enable some post-implementation flexibility via improved product connectivity and openness, role-based user access and communication, improved analytics and reporting tools, user-definable processes, and workflow modeling.

ADVERTISEMENT

However, it is dubious whether and how software originally built for static business environments can accommodate today's indisputably dynamic business environment. The fact is that most current commercial enterprise systems are architecturally imperfect, inflexible, and entrenched in outdated concepts of some pre-implementation flexibility and almost total post-implementation rigidity. The analogies to “pouring concrete over the users' feet” or “being as flexible as a PVC pipe after the glue has set” have become proverbial by now. In other words, the ability to support the user company in staying competitive usually involves working around the system and waiting for the next re-architected release, or completely implementing a redundant system that overrides the base ERP system. In addition to unnecessary time and cost, this leaves companies at a competitive disadvantage because they are continuously suffering from either the opportunity cost of not changing the business, or the operational cost of working around the system—or often a combination of the two. What's more, ironically, the core objectives of installing an ERP system in the first place (best practices, integration, etc.) are themselves eroded over time.

At this stage, we might also want to note that most enterprise systems were designed to cater for the needs of material-centric (material managing or “make, move and maintain”) organizations, whose typical system requirement has traditionally been a common group-wide process control and reporting system. For such organizations with centralized control from the head office (and with divisions with similar operations that run under standard procedures and standard reports), current vendors' post-implementation flexibility (or lack thereof) might be enough. In fact, ERP system tables and parameters allow for fairly easily changing or adding new machines, operations, warehouses, and so on.

Some might even say that the key design goal of such manufacturing- and supply chain management (SCM)-oriented environments is control, and that the supporting enterprise systems were designed to resist change (and not only because of architectural inabilities and product design concepts at the time that these products were devised and deployed). In other words, maximized efficiency of processes and enforcement of best practices are often mandated by management. Also, although there might be heavy investment in the material management infrastructure, the information needs (while not necessarily minimal) are mostly aimed at a limited number of users.

Certainly, there are a number of issues working against the complacency of such environments, including increasing globalization, shorter economic cycles, regulatory pressures, acquisitions, consolidations, public offerings, and trading partners' collaboration and agility requirements. Soon, most of us will realize that intelligent implementation is not only about meeting the needs we can see today, but also about the needs we do not even know about yet. Thus, “post-implementation-no-modifications” is one of the most basic (and yet flawed) assumptions made by companies about their enterprise applications. Consequently or not, most enterprise vendors believed the “no modifications” assumption when they architected their products. However, this assumption is basically untrue, since even the largest customers using software from the largest vendors require customization and agility.

The situation becomes quite a bit more complicated for enterprise applications providers that intend to cater to the needs of people-, project-, and service-centric organizations, which differ from their material-centric counterparts in many regards. Perhaps these companies can be called “staff, source, and serve” (as opposed to their “make, move, and maintain” brethren). To that end, Lawson Software offers two different product lines, Lawson S3 and Lawson M3 (formerly Intentia Movex), aimed respectively at “staff, source, and serve” and “make, move, and maintain” enterprises. For one thing, people-oriented user organizations are different for the simple reason that they manage people and teams rather than physical products. It is all about managing knowledge, skills, and intellectual property, as well as relations (which are all of a “fluid,” ever-changing nature). And for another thing, success in these organizations is about attracting, developing, and retaining the right people in order to create the right personnel composition to meet ever-increasing service level requirements. The astute enterprise system must be able to optimize the user company's resource pool at all times, and not only while they are working on projects.

From a structural point of view, people-centric organizations often consist of different units or operations, each with their own goals and objectives. The management within each unit have a big need to feel independent, and the underlying enterprise system they use should be tuned towards their own specific needs and requirements. From a geographical point of view, there are all types of scenarios—from organizations with a local or regional structure, to organizations that are spread around a country or continent, or even around the world. All these organizational characteristics have an impact on architectural needs and requirements when it comes to selecting a business information system. In other words, typical system requirements for people-centric organizations include tailored business systems for each unit with different operations, geographies, objectives, etc.—but also the ability to provide a holistic view of the business at the top.

The trick is thus to maximize overall efficiency and reduce overhead, by streamlining core competencies and outsourcing non-core activities. Functionality without sound and flexible technological foundation is often not enough to accommodate requirements related to the organizational characteristics of people-centric organizations. These requirements might include dealing with decentralization and devolved responsibilities of units, diverse demographics of the organization and its users, and different users with different requirements. Again, these environments are collections of a large number of services that are impossible for a single set of individuals to run. Although it is important to set corporate-wide directives, one has to empower the people in each of the service areas, and enable all business managers to have online access to accurate, relevant, and up-to-date information.

One example of dealing with complex requirements involves divisional procurement departments with requisition self-service capability and intrinsic review and approval processes. These might arise from delegated budgets, different authorization rules, different locations, different ways of information access, different types of users, external partners and outsourcing (subcontractors), and many other complicating factors. Furthermore, systems supporting these requirements need to support casual users with a little computing experience, since information needs to be easily accessible by and disseminated to everyone who needs it—at all levels and from remote locations. On the other hand, they have to allow information to be updated directly by those who know it best.

The next big characteristic of people-centric organizations is the continual management of change and growth. Business changes are often forced by external forces such as governmental regulations and legislation, customer or citizen demands, changes in technology or means of communication, competitive pressure, or even central directives. Creative thinking within such organizations is also often a reason for change, and the ways these firms can change are numerous. They can range from a change in types and levels of information requirements to changes into the geographical structure (new subsidiaries, mergers, acquisitions, etc.), to changes within the geographic locations in terms of services or “products” delivered (or the way they are delivered).

The very nature of these people-centric organizations calls for fluid, project oriented teams. The makeups of the teams are ever-changing, with skill set requirements and individuals changing frequently. Change comes in many other ways and has to be managed adequately, quickly, and in a qualitative way, and one has to be able to measure, understand, and improve, with accuracy, timeliness, and relevancy in the background. For relevancy, it is important to note that transactions alone do not provide enough depth without analytic and business process context. Also, to complicate things even more, what is relevant to a chief financial officer (CFO) is not necessarily relevant to a project manager—what is relevant to department A is not necessarily relevant to department B, and the information needs of today will not necessarily match the requirements of tomorrow.

Because of these organizational characteristics, people-centric organizations have typically had to invest in a variety of enterprise solutions. One of the facts to be recognized here is that the bigger the organization gets, the more applications and data sources it has to implement. Unfortunately, IT projects have often been relatively piecemeal and unconnected, whereas packaged applications have as a rule enjoyed architectural isolation (whereby integration and ease of change were afterthoughts). Furthermore, until recently, enterprise standards were circumvented or overridden, and their focus was on the individual processes, not on the overall big picture of end-to-end processes (from the supplier's suppliers to the end customer).

Consequently, such organizations have been overloaded by a network of “spaghetti code” and “multiple versions of the truth,” depending on the user group (which might consist of human resource [HR] professionals, trading partners, program management, top management, buyers, controllers and accountants, etc.). Yet, for any organization (people-centric or not), adequate information delivery is crucial. As mentioned before, it is all about the accuracy, timeliness, and relevancy of data. Moreover, the well-known “one version of the truth” still has to be presented differently to different constituencies, since no one can change what they are not aware of.

For these reasons, the reporting and analyses information portfolio has to be disseminated, both in a push and pull manner (as required), and in a form appropriate to various audiences. For instance, the finance department speaks in a language of division, budget type, property, credit controller, and so on; but the sales department understands sales person, campaign, channel, market, etc. Furthermore, the operational folks speak in terms of contracts, projects, work orders, and activities, whereas purchasing wants info about suppliers, buyers, requesting employees, cost centers, etc.

Yet, what has been keeping many managers awake at night has been a number of disconnected applications and data sources that do not make sufficient analysis easily available. Not only can business changes not be accommodated quickly enough, but the bad consequence of this is that it might also stop the flow of information altogether, which will make the situation even worse. Finally, when decisions have been made (based on often outdated and unpredictable information), the time it takes to implement the necessary changes will take so long that the next change has already occurred. In other words, implementation times are much longer than the change cycles.

To recap, people-centric or “staff, source, and serve” organizations have more pronounced requirements for complete business support, complex reporting and communication, flexibility, and adaptability. To enable these, one needs a tightly integrated functional system (including solid capabilities for financial management, budgeting, payroll, HR, resource planning, resource deployment, training and skills management, recruitment, estimating and bidding, project follow-up, project control and billing, travelling, time and expense capture, procurement, etc.). And the system must also be architecturally sound. In other words, the system has to be not only a data and transaction repository, but also an application featuring a single data model for the data dictionary (which defines technical attributes about the data fields within an enterprise system's database), business logic, information delivery, and process control— all of these spanning the entire application portfolio. On one hand, the user has to be able to capture all relevant data in multiple ways and transactions have to feature multiple analytical dimensions; on the other hand, data and logic must be more tightly connected so that “intelligent” alterations can be made quickly, easily, and correctly.

About the Authors
Predrag Jakovljevic is a principal analyst with Technology Evaluation Centers (TEC), with a focus on the enterprise applications market. He has nearly twenty years of manufacturing industry experience, including several years as a power user of IT/ERP, as well as being a consultant/implementer and market analyst. He holds a bachelor's degree in mechanical engineering from the University of Belgrade (in the former Yugoslavia), and he has also been certified in production and inventory management (CPIM) and in integrated resources management (CIRM) by APICS.

Olin Thompson is a principal of Process ERP Partners. He has over twenty-five years of experience as an executive in the software industry, and has been called the “father” of process ERP. He is a frequent author and award-winning speaker on topics such as gaining value from ERP, supply chain planning (SCP), e-commerce, and the impact of technology on industry.
http://www.technologyevaluation.com/

ADVERTISEMENT

The Modelling Approach to Post-implementation Agility in Enterprise Systems
From Technology Evaluation/P.J. Jakovljevic and Olin Thompson
One way to approach the requirements of changing an implemented enterprise resource planning system would be via so-called model-based architectures. These are application development frameworks that allow software applications to be described in terms of what they must do (the business view of the software) rather than how they must do it (the technical view of the software). Such an approach puts the emphasis on designing the business processes and the business rules up front, to make sure that business functionality is complete and correct before coding begins. For a discussion of the challenges faced in changing an enterprise system post-implementation.

The modelling approach allows visualization of the intended solution so that business analysts, users, and developers can ensure that business needs are met before implementation in software code renders changes difficult and expensive to make. Using this model, the framework automatically generates the executable application, instead of a programming team manually converting the specifications into software. This code generation increases development efficiency and typically allows generation onto a range of platform choices.

On the other hand, an organization-wide information warehouse (as an intrinsic part of the enterprise transactional backbone system rather than a separate information “twin tower”) has to provide such intelligent availability to data throughout the system. The applications should thus reside within a single shared environment in which metadata (data about data) is defined once and made available immediately to financial, procurement, project costing, HR, payroll, and other applications. This data model not only serves as a shared repository of information for the applications, but also acts as an automatically defined “catalogue” for a range of specialized reporting and information delivery tools. In other words, fully integrated analysis, reporting, and communication facilities (with user-defined business views in an “anytime, anywhere, anyway” manner) are becoming a given in people-, project-, and service-centric organizations. Only by providing all these elements within an integrated ecosystem and context can one hope to achieve a rapid response to change.

Increasingly, central governments worldwide are mandating the use of computer automation and the Internet, in order to link and manage the agencies under their authority, and to enable better employee empowerment. The idea is also to enable better provision of local services and accountability to local authorities, boroughs, cities, towns, and ultimately, end users (citizens). In addition, local authorities, health care, or emergency services have an obligation to report their performance to larger governmental units, whether they are states, provinces, cantons, or the central governing bodies. These bodies, in turn, have to publish the results to the electorate. Thus, public officials not only must provide online services to their clientele, but must also be able to retrieve, amalgamate, and report data on the success of their agencies and the status of their progress toward information automation. They require a complete view of management information at all times to make effective judgments about resources and service delivery. Therefore, software applications in support of the public sector must be integrated across all processes, and they must support the internal aspects of the agency or governmental body in its management of data, people, finances, and its particular mission—as well as the public that should, at the end of the day, benefit from the body's charter.

Furthermore, applications using model-based architectures are built on business processes and rules, which allows business analysts to understand and make customizations to the application without compromising the quality of the application. This also obviates complex switches and parameterized tables for configuring the application with simple changes to rules. Custom applications can be built rapidly for very unique businesses or business functions, and such architectures allow for less complexity in the code and significant automation of the software code development, which promises significantly increased application quality.

The service-oriented architecture (SOA) concept should (in theory) be able to help businesses respond more quickly and cost-effectively to changing market conditions by reconfiguring business processes. It should eventually enable agility, flexibility, visibility, collaboration with trading partners (and between functional and information technology [IT] departments), and so on, by promoting reuse at the coarser service (software component) level, rather than at the more granular (and convoluted) object levels. In addition, SOA (again, in theory) should simplify “plug and play” interconnection and usage of existing IT assets, including the legacy assets.

According to Forrester, from the vantage point of business drivers, the concept should in the long run enable users to adapt their system to processes (and not vice versa); improve system intuitiveness and usability; deliver relevant analytics; connect to external data and services; and leverage readily available best practices and industry knowledge within the vendors' repositories. In the technology lingo, SOA should reduce custom coding through configuration; promote open standards to reduce integration costs; enable end user self-sufficiency (meaning no reliance on nerdy programmers); and provide more flexibility to use best-of-breed products (possibly within composite applications).

Data published in InformationWeek on September 4, 2006 concurs with the above findings. According to a survey conducted by InformationWeek Research, 72 percent of companies hope to achieve increased flexibility in application development by moving to SOA; 61 percent hope to create service-oriented applications faster; 58 percent are aiming at increased software modularity; and 32 are aiming at greater potential for customization.

Still, in addition to still-maturing (and sometimes even conflicting) commonly accepted standards, challenges facing SOA implementation include managing disparate software metadata repositories (meaning frequent data rationalization and replication), disparate software abstraction incompatibility, and appropriate levels of security. Directing and supplying information on the interaction of services can be complicated, since the architecture relies on complex multiple messaging that opens the door to messy code and broken communication, on top of potential non-compliance with government regulations. The flexibility of SOA poses security threats, since these applications engulf services, especially those external to company firewalls. The services are thus more visible to external parties than traditional applications, which is why businesses must set policies to protect who can see exactly what information.

Problems can also arise when users try to connect services that were not developed in the exact same manner, which is very likely if this not controlled within a certain vendor's ecosystem. One of the key goals of SOA is to remove hardwired, purpose-written point-to-point links and replace them with generic links centred around business functions and processes. However, to achieve this, new software components such as orchestration and workflow engines, communication adapters and translators, testing tools, and service locators have to be added to the already complex architecture. Such large, mega implementations might be another opportunity for the consulting giants like IBM that hope to make a small fortune on SOA projects, which rekindles a sense of déjà vu with respect to the pre-year-2000 (Y2K) salad days. Considering the probable expensive and disruptive upgrades with unproven benefits (and the fact that vendor hype is forging ahead of actual SOA capabilities), many prospective customers might at this stage see these projects as yet another exercise in IT department futility.

Ironically, although seen as helping heterogeneous and legacy environments rejuvenate themselves, SOA might function best within a homogenous domain and context, where data and processes are well aware of each other, as in the case of the Agresso Business World (ABW) or Epicsor for Service Enterprises products. Lawson Software has also recently embarked on a major SOA-based product rewrite called Landmark, where the idea is to automatically generate product code (and services), and to avoid the possible SOA traps mentioned above, since the code generator will have all the validation rules and constraints within the context of the scope for the Lawson S3 product .

These provisos aside, we still have a ways to go before post-implementation change becomes a solid, controlled process with built-in management and quality, while providing the business user visualization and evaluation of potential modifications. Ideally, it should assist the business user to understand what the system will look like and how it will operate after the change—in order to avoid surprises and rework, and further user acceptance. The full impact of any change must be known in advance, including the impact on the system, and the cost and time required to make the change. This should be reflected in the “total system,” including documentation, user manuals, help text, and so on, as such information will facilitate the management process. However, most of the current SOA developments are far from the promised nirvana of new product releases that will allow any modification to be easily re-evaluated and re-applied as necessary at a realistic time, cost, and quality—to say nothing of modifications that evolve with the needs of the business and the advances made by the vendor.

To recap, while SOA does facilitate standardization, allow for loosely coupled software components (services) assembly and integration, accommodate customized portal-based presentation, and thus perhaps facilitate integration, it is not yet a panacea. Hence, it is a fallacy to expect that the mere concept will turn rigid products written in ancient code into flexible applications providing analytic information that has not been natively enabled, and like benefits. To radically change, the underlying product has to be either properly architected from the ground up (as with Agresso, which likes to compare its agility to a chameleon's ability to adapt to the environment), or totally rewritten in new, modern languages and technologies. Without true modernization of underlying applications, the SOA embellishments will largely be analogous to “putting makeup on a pig.”

While in theory, one can abandon the existing infrastructure and go to an ideal, agile applications world, this will not prove practical for the vast majority of heterogeneous environments. For most of us, the IT world is a mix of multiple applications, technologies, and so on, and the preferred architecture will be the one that can rationalize business processes without ripping out the current investments that most companies have made in applications.

Change happens, and it will always happen in virtually every business environment. The underlying enterprise system should thus be an aid to changing the business, rather than an obstacle, as is the usual case today. The enterprise system architecture of the future should accept and assist in the reality that business changes and software must change with the business. User companies do need best practices, but they also need “differentiating practices” and the ability to respond to the needs of customers, employees, and trading partners. Modification projects are often very large, but to be responsive, the applications must be economically changeable for small and large requirements alike.
http://www.technologyevaluation.com/

ADVERTISEMENT

Master Data Management Research Quantifies and Benchmarks Maturity
From Ventana Research
New research on Master Data Management from Ventana Research reveals significant trends in master Data Management (MDM) and the maturity of organizations adopting this process and technology.
“This is groundbreaking research because it will serve as a guide to assess organization's MDM position relative to others” said Dr. David Waddington, Ventana Research VP and Research Director for Master Data Management & Information Architecture and former Chief IT Systems Architect for Unilever. “While there are a lot of opinions on MDM in the industry this research provides substantive and quantified research on MDM from over 500 IT and business professionals.”

Among the key research findings, Ventana Research found:
1. Maturity Levels: Organization maturity with respect to MDM is very low—between Tactical (36%) and Advanced (34%).

2. Growing Awareness of MDM: More than 80 percent of respondents reported that they were aware of the meaning of the term “master data management”.

3. Timeliness and Consistency of Information is Paramount: 42 percent ranked improving timeliness and consistency of information as most important expected benefits.
http://www.ventanaresearch.com/


ConAgra Tackles the Challenge of Wal-Mart's RFID Mandate
From ARC Advisory Group/ John Blanchard (first published in Packaging World Magazine, October 2006:
ConAgra Foods Inc. is one of the largest packaged foods companies in North America, with a major presence in retail outlets as well as foodservice institutions, and is one of the top 100 suppliers to Wal-Mart. Headquartered in Omaha, NE, they have over 150 manufacturing sites and fiscal 2005 sales of nearly $14.6 billion. ConAgra Foods offers many favorite consumer food brands and popular items across a variety of food categories and channels. More than 30 percent of ConAgra Foods brands are number one in their category. ConAgra Foods brands are in 96 percent of U. S. households.

Some major consumer brands include Hunt's ketchup, Peter Pan peanut butter, Orville Redenbacher's Smart Pop popcorn, Banquet, Healthy Choice, Marie Callender's, Egg Beaters, Kid Cuisine, Chef Boyardee, Swiss Miss, Van Camp's, and Hebrew National.

Over the last several years, ConAgra Foods has transformed itself into an effective and responsive, industry-leading, branded, and value-added food company. ConAgra Foods was one of the first companies to comply with the Wal-Mart RFID mandate and is now one of Wal-Mart's top food-products suppliers with high volume tagging, with more than 500,000 cases tagged since January 2005. In fact, ConAgra Foods received top supplier recognition from Wal-Mart in 2005.

In November 2003, Wal-Mart informed its top 100 suppliers about its pending RFID mandate. While exciting ground was being broken, it did not change the overriding notion of Wal-Mart suppliers that a lot of money had to be invested with no tangible return-on-investment in sight.

“However, choosing to move forward was an easy decision for ConAgra,” says Phillip Hubble, manager of business analysis RFID. “Not complying with a very important customer was never even a thought.”

So in mid 2004, ConAgra began a very proactive, collaborative effort with Markem Corporation to delve into RFID and learn together before the Wal-Mart RFID mandate went into effect. Michael Martinez, director of distribution process improvement and integrated logistics for ConAgra, emphasized that the team's first priority was to understand exactly what their customers were looking for to satisfy their requirements. “Our target was to facilitate case tagging in the most accurate, efficient, and consistent way,” says Martinez.

The project began with pilot plant testing to determine tag selection and placement. Actual on-site testing and development on this joint project began with a line in ConAgra's Fort Worth, TX, distribution center in conjunction with their third party logistics partner, AmeriCold Logistics. This warehouse was chosen because it was the warehouse that supplied the Wal-Mart distribution center in Dallas. Markem's semi-automated RFID distribution center tagging solution was chosen to help achieve ConAgra's goal by applying the tags on cases in exactly the same place, every time. The tagging position could also be changed for different SKUs, and the first products chosen for tagging were popcorn, condiments (such as ketchup packets), peanut butter, and cases of tomatoes, including small and gallon-sized cans.

“The real guts of the whole project was in real operations,” said Martinez. “You can do all the lab testing you want, but you can't test all the inefficiencies you have on the line until you've really put it through production and that's what we saw here. We had until January 5th to bring tagged product to Wal-Mart and we knew we needed to tag six SKUs.”

The obstacles overcome and key lessons learned were:
1. Placement of the tag was critical and varied from SKU to SKU

2. In a DC, outside radio interference can be a significant issue

3. Placement of RFID antennas for initial encoding and downstream verification was critical for coding and reading

4. Quality of tag conversion is essential to increasing tagging yield

5. Material handling and product positioning with varying SKUs were very important

Crucial to the successful deployment of this RFID technology for ConAgra Foods was the RFID application experience of all the companies involved in the project.

The first line started on time and scaled up throughout February and March with many of the most difficult products for RFID-tagging. “We evaluated the first line after getting it started for the January deadline and doubled the SKUs in February and March,” says Hubble. “So eventually we had 18 SKUs and were averaging about 40,000 cases per month. We were doing ten percent of Wal-Mart's total volume in February 2005.”

Even before the first line was deployed, the scope of Wal-Mart's mandate continued to escalate and other clients such as Albertson's and Target began mandating their own RFID tagging. As a result, ConAgra Foods issued a request for proposals to the open market for a second RFID label/applicator system for an additional tagging line. They were looking for a total RFID software, hardware, and services solution. The line two project requirements included throughput of up to 4,000 cases a day. The line needed to be able to reject bad tags at the applicator and also verify tag readability downstream on the line, rejecting tags that didn't read properly. The system also needed to scale to 100 percent of ConAgra's SKUs.

ConAgra Foods looked at five or six suppliers that had submitted bids. The key reason for selecting Markem was because ConAgra already had a relationship with Markem and had established trust with the company.

Lessons learned from the first line were applied to the second line. An automated product reject system was added to the system as well as new conduit and electrical designs that minimized potential RF interference.

“The second line also needed to have increased capacity, satisfy requirements of different customers, and have the ability to capture more data,” explains Michael Snyder, systems coordinator for AmeriCold Logistics, who was in charge of operating the system.

ConAgra Foods went live with the second line in April 2005, running only SKUs for Wal-Mart, then extending it to SKUs for Target and Albertsons. “Now we are running multiple SKUs for Wal-Mart, Target, and Albertsons and shipping to seven distribution centers. We've run more than 500,000 cases to date and 40,000 cases per month,” says Hubble.

The improvements in the design of the packaging line equipment and controls also allowed ConAgra Foods to operate with two rather than three operators. Overall it was a highly successful RFID implementation and an example of ConAgra's exemplary customer service.

The ConAgra de-palletizing and re-palletizing RFID case and pallet tagging system includes:
1. Markem CoLOS™ RFID Software (controlling software for device and line management and EPC allocation; ERP/WMS integration)

2. CoLOS Control operator panel—industrial PC user operator panel to provide input

3. CoLOS Manager—interface to management of master database table information such as items, orders, and authorized users

4. CoLOS Report—detailed production reports

5. CoLOS Allocate—EPC number allocation

6. CoLOS Sync—interfaces to other information systems

7. Markem Cimjet RFID encoder/applicator—built-in RFID encoder and tag reader for verification and rejection of bad tags

8. Sensors linked to CoLOS Control—which controls and manages the photo eyes to interface to printer devices, PLC sensors, and conveyor control components

9. RFID reader/verifier—optional external RFID reader for final RFID tag verification; could be utilized to initiate optional case reject or line diversion in the event of damaged tags

10. Zebra RFID printer for pallet labels—automatic RFID pallet label generation after a pallet has been stacked; controlled by CoLOS software

11. Bar code reader linked to CoLOS Control—fixed or wireless handheld bar code scanner linked to CoLOS databases can update information on demand; used to capture case to pallet association

12. Flatbed conveyor and controls

With hundreds of product SKUs, the need to further consolidate more than 150 manufacturing sites, and a technology that does not yet deliver 99.999% reliability, ConAgra Foods has no immediate plans to migrate RFID technology to their manufacturing packaging lines. However, high speed RFID tagging will be required as the technology matures and the scope of customer RFID mandates expands. Further, food and consumer packaged goods manufacturers are realizing the potential benefits of this increased product information cannot be realized until more standard data formats and automated data support infrastructure is in place.

As for Markem, the firm is providing and continuing to develop products, application solutions, and services to support distribution center and manufacturing packaging lines for product, case, and pallet labeling and serialized tracking and tracing solutions. The new Markem 800 Series high speed Gen 2-compliant RFID encoder/applicator is designed for high speed manufacturing line applications. The 800 Series high speed encoder/applicator with automated tag rejection can tag up to 100 cases per minute and handle multiple RFID tags, including on-pitch inlays.

It is Markem's view that RFID tagging will move to manufacturing facilities in the long-run. Today in North America, many cases and pallets in the supply chain are not serialized. RFID lets companies leapfrog serialized bar codes and move to unique identification. This will enable many track and trace applications, including recall scope and time reduction, inventory reduction, and better regulatory compliance.

Markem has built a traceability software infrastructure so that RFID can be used for traceability. Markem provides a complete packaging line solution for device management, and product data management, line management, template management, reporting, and serialized product-case-pallet traceability. Solutions include integration software to interface with other control, production management (MES), ERP, and warehouse management systems.

While most companies in the food and beverage and other Consumer Packaged Goods (CPG) industries have automated their product processing operations, many have yet to gain the benefits of effectively automating their packaging operations and integrating them with their other manufacturing and business operations. ARC sees many companies still in need of more reliable and granular tracking and tracing systems, like the MARKEM CoLOS system. Benefits include improved manufacturing efficiency and responsiveness and minimization of the potential business and financial impact that a major product recall might pose in this age of instant information.
http://www.packworld.com/


Click here to subscribe or renew your subscription to Global Logistics & Supply Chain Strategies magazine