2008 Software Re”solutions”

A new year is upon us and with that, the word “resolution” comes to mind…

res-o-l-u-tion – [rez-uh-loo-shun n] - noun

1. a resolve or determination: to make a firm resolution to do something.

2. the act of resolving or determining upon an action or course of action, method, procedure, etc.

3. the mental state or quality of being resolved or resolute; firmness of purpose.

4. the act or process of resolving or separating into constituent or elementary parts.

5. the resulting state.

6. a solution, accommodation, or settling of a problem, controversy, etc.

7. reduction to a simpler form; conversion.

Taken from: Dictionary.com Unabridged (v 1.1)
Based on the Random House Unabridged Dictionary, © Random House, Inc. 2006.

“Well, there’s always next year…”

Some people call this time of year the “holiday season.” Others just call it winter. And then there are those of us who call it the “end-of-the-year-crunch”—that special time when it seems there are far too many things to do, and way too little time to get any of them done. Some things just can’t wait, like putting the snow tires on your car before the first big blizzard (too late now, for people in most parts of Canada). Other things can get put off indefinitely, even when you know they have to be done—whether for deadline or not.

One of those things that can get put off indefinitely just might be your enterprise’s software selection project.

You’ve already obtained executive approval for the acquisition of a new XYZ software solution. Maybe a projected deadline has even been set for its implementation. And you’ve recently found out that you’re the lucky chump delegated to take charge of what can often be a rather complex and time-consuming task.

But you have your usual responsibilities, so this software selection thing… well, there’s always next year to get a start on it…

Well it shouldn’t come as a surprise to you, but next year is mere days away. Before you know it, you’ll be standing at a party, counting down the minutes to midnight, champagne in hand trying to mumble your way through “Auld Lang Syne.”

So maybe you’d better start making your Software Selection Resolution list now (and maybe even check it twice) so that you’ll be ready to set the process in motion the minute you sit back down at your desk on January 2nd, hangover remedy in hand, to start your software selection process.

Software Selection Resolution # 1

I promise to gather and prioritize my requirements, and to create a working document that defines all of my requirements.

Imagine it: sitting down to create an extensive spreadsheet that you send around to every department, imploring the employees to define exactly what they need from a software solution. And imagine waiting for all of them to send those lists back to you, so you can cross-check and collate those requirements to avoid any duplication.

Or, you could save yourself some time and use a request for proposal (RFP) template. An RFP template lists hundreds of criteria for each type of software solution; RFPs are often sent to vendors later on in the software selection process, in order to elicit from the vendors which features and functionality their solutions support. But you can use an RFP like a checklist, making quick note of the functionalities you require, and even rating how important each is to your business activities.

Software Selection Resolution # 2

I promise to research all possible solutions, identify those that are relevant to my enterprise and industry, and eliminate those that are unsuitable, in order to create my long list of possible solutions.

The Internet is a great research resource. But there’s so much information out there, it’s sometimes hard to know where to begin—and how to sort out the reputable from the not-so sound. And when it comes to making a decision that involves a major financial investment, you need to ensure your information is irrefutable, up-to-date, and unbiased.

To start your research, browse through some white papers and case studies published by the software vendors themselves. This can be a great way to compile information about different solutions, and can form the basis of an effective comparison.

But, you probably won’t have tons of time to read a legion of white papers. So, how can you cut to the chase? Are there any resources available with ready-made comparisons of software solutions?

As a matter of fact, Software Evaluation Reports are a good way to get comparative reviews of several vendors’ software products. Software Evaluation Reports consist of two or more vendors compared side by side to demonstrate whether or not they support each criterion in a list of available functionalities. (Sample evaluation reports, with two vendors and up to 50 criteria, are available as free downloads.)

Once you have done these things, you will have a long list of potential vendors.

Software Selection Resolution # 3

I swear that I will, in timely fashion, send a request for information (RFI) to all the vendors on my long list (and I swear that I will be patient in waiting for their responses).

What more needs to be said, really? Unless, of course, you don’t know why you’re sending RFIs to your long-listed vendors… (Here’s a hint: this gives them the opportunity to confirm that they do indeed support your prioritized criteria, and how well they do so. All of which is the first part in the process of creating your short list of vendors and solutions. (But more on that shortly.)

Software Selection Resolution # 4

I hereby vow to build a decision matrix…and to dutifully rate each solution against the requirements of my organization.

A decision matrix is a decision support tool that uses algorithms to examine a set of metrics, in order to create a quantified comparison. A decision matrix provides a score based on an evaluative comparison of each prioritized criterion. Doing this will help you to more quickly determine your list of potential solutions.

(Imagine if Santa used a decision matrix to decide who’d been naughty or nice. Or if your boss used one to determine your performance on such tasks as, oh, choosing a new software solution.)

Software Selection Resolution # 5

I pledge to analyze the strengths and weaknesses of each solution, so that I will be able to rank them and create my short list.

This step is essentially an extension of Software Resolution # 4. Once you determine that the selected vendors’ products do support your criteria, you need to know to how well each one meets your requirements, according to your established priorities.

Doing all of the above steps can take a lot of time and effort. You could spend the entire week between the 24th and the 31st going through spreadsheets. Or, you could set aside twenty minutes of the last day of the year to perform the same effective comparison. Find out how easy it can be to create your shortlist with TEC’s eBestMatch decision support system.

Software Selection Resolution # 6

Furthermore, I promise to let all rejected vendors down easy, so as not to upset their sensitive little hearts.

And even if their hearts are lumps of coal that even the Grinch wouldn’t touch with a ten-foot chimney brush, it’s still good business sense to be diplomatic and professional. You never know when you might require a vendor’s services in the future (or meet them in an awkward social setting). So don’t assume they’ll be pleased as spiked punch if you figure that not sending them any response is adequate rejection. If you don’t call—or, better yet, send an official letter—to tell them why they didn’t make the cut, they’ll probably call you. And it won’t be to chat about what a nice holiday you had.

In spite of your diplomatic and professional approach, it is possible that disputes will arise. The vendors’ sales representatives may try to give you a slew of reasons why you should reconsider their products. In order to make it clear that your decision is final, you should specify why their solutions were rejected (without actually using that word), while not coming across as overly critical of their products.

Software Selection Resolution # 7

I agree to undertake the responsibility to issue a request for proposal (RFP) to all short-listed vendors.

On your company’s formal business letterhead, write a cover letter inviting the vendor to submit a proposal. Your RFP should define the entire project’s requirements, and allow the vendor to propose a number of things: contractual terms, technical specifications, delivery terms, time frame and strategy for implementation, training services, support, and of course… the price quote.

Preparing a proposal can be a lengthy process. So, you should give your short-listed vendors some time to complete and return the RFPs (two to three weeks is generally enough—about the same amount of time it takes most people to start smoking again, or let the stationary bike start collecting dust). And you should probably wait until you have received all the vendor proposals before going ahead with the next step of the process.

Software Selection Resolution # 8

I declare that I will create a comprehensive demo script according to my specifications, and then invite my short-listed vendors onsite to show them my enterprise’s current system, as well as provide them with the opportunity to do a demonstration of their solutions.

A scripted demonstration is an essential part of the software selection process. (A software selection without a scripted demo is like a New Year’s Eve party without the stupid hats, noise-makers, and cheap champagne). By providing vendors with your own demo script, you can more clearly see how the vendors’ solutions address the factors that are important to you. Your scripted demo should cover: supplier introduction, system overview, menus and features, system navigation, customization capabilities, security features, and more.

Software Selection Resolution #9

And I attest that I will rate the vendor’s demos, assemble their RFP proposals for consideration, and revisit the analysis steps, in order to select the one and only solution that best fits my enterprise’s needs.

Not knowing how to assess vendor demos is kind of like Santa not knowing why a child is naughty versus nice—which makes the whole idea of rewarding good behavior—good demos—moot.

Each member of your project team attending the demo should participate in scoring the scripted vendor performances. Break down the demos into different sections in order to facilitate the scoring process. You might consider the solution’s functionality or performance, ease of use, process and flow, flexibility, and adherence to your script. Score each section using a rating scale (you can decide how precise you want the scale to be, but “0” to indicate that the factor was not presented in the demo, and “3” to indicate an excellent performance or capability—with according values for “1” and “2”—should suffice).

And then, you also need to know how to rate the RFPs responses. Keep in mind that although these responses can tell you a lot about the vendors, the RFPs are essential sales pitches, designed to persuade you to buy the vendors’ products. Ask your self the following questions:

* Did the vendor respond to your RFP on time?
* Did the vendor answer every question?
* Are any of the responses unclear?
* Did each vendor include a price quote?

Vendors should also provide you with the contact information for a few references, from organizations that previously installed the software and can answer questions about the quality of the vendor’s implementation services, ongoing maintenance support, and the quality of the training provided. Compile a list of these questions and send each referee a copy. When these questionnaires are returned, you can use them to help you further weed out the unsuitable candidates.

And now you’re ready to go back to the analysis steps discussed above, in order to take your short list of vendors down to the one single vendor that best fits your needs. (Just a reminder of the things you should revisit in order to determine your best match:

* create or use a decision matrix

* rate how well vendors’ solutions support your criteria

* analyze the solutions’ strengths and weaknesses, in order to rank the vendors, based on all the new information you have received, including the demos, the RFPs, and the client references…

Software Selection Resolution #10

And finally, I swear to prepare for the full implementation process, so that the new software solution I have so carefully selected does exactly what my enterprise needs it to do.

How extensive your implementation is may depend on whether or not you specified in your selection criteria that the solution should fit with your existing hardware. If so, then you can move straight into the installation phase of implementation. To begin with, the vendor should test and refine the application.

You have now arrived at one of the most important parts of the implementation: educating users and administrators. This involves not only the usual training; the training team must also provide a complete explanation of how the solution will affect business processes, what people’s new roles will be, and all other aspects of the new system that may cause users to resist acceptance. Training is the crucial ice-breaker that can make the difference between reticent and enthusiastic software users.

After further tests, to ensure that users are “on board” with the new system, the system is ready to “go live.” But the implementation doesn’t stop there. In order to make the most of the new software application, you must manage and measure how it is benefiting your enterprise, and keep in mind that continuous business alignments are necessary in order for you to make the most of the solution’s potential.

If you want to ensure the vendor adheres to the stipulations for implementation as agreed to in the contract, you can hire a consulting firm, such as Technology Evaluation Centers (TEC), to conduct an implementation overview. Learn more about TEC’s evaluation and selection solutions.

And there you have it! You’ve just resolved to do the most effective software selection process ever! Now, you can sit back and breathe a little bit easier over the holidays (so long as you clean out your chimney, and remember to open the flue before lighting a fire, and don’t catch a cold).

But before you get all weepy-eyed that all the fun of learning about software selection is over, here are a few more resources to help you, just to make sure nothing is overlooked:

* A checklist to help you plan your software selection, step by step
* A wide selection of free sample software evaluation reports
* Request for proposal (RFP) templates to help you define your criteria
* Hundreds of articles written by industry experts, covering a variety of categories
* White papers and case studies from software vendors all around the world
* Podcasts and webinars on a number of topics to give you further insight into software tricks of the trade
* A vendor showcase, providing lists of certified vendors and descriptions of their products

“Act Vertical” vs. “Go Extinct” Retailers – Part 3

Part 1 of this blog series set the historical background for supply chain management (SCM) evolution and presented the advantages and shortcomings of vertical vs. horizontal integration. The analysis then moved onto the generally embattled retail sector, where a select group of innovative retailers has found a “happy medium” approach to stay well above the fray.

Kurt Salmon Associated (KSA), the leading global management consulting firm specializing in the retail and consumer goods industries, dubbed this strategy “Act Vertical” in its seminal research study. The firm presented the highlights of the study at the National Retail Federation (NRF) Annual Convention & EXPO 2009 (also known as the Retail Big Show) in January in New York City. The accompanying slide deck can be downloaded here.

Part 2 of this blog series then outlined the five drivers for retailers to act vertical, and the three key tenets of the approach. The post explained in depth the following first two requirements for acting vertical:

1. Effectively bring unique and compelling products and services to consumers; and
2. Offer differentiating customer experiences through multiple, integrated channels.

This final part will focus on the need for retailers to collaborate and synchronize internally and externally with customers and suppliers, often via customized agile supply chains, as necessary.

This supply network agility and flexibility is critical to creating products based on the attributes of smaller consumer segments and “fast tracking” greater numbers of products to respond to ever-shorter selling time windows. Different products have different supply chain requirements, given that many products’ variables may combine in different ways, each variable suggesting its own type of supply chain strategy.

Different (Supply Chain) Strokes for Different Folks

In his Harvard Business Review 1997 article entitled “What Is the Right Supply Chain for Your Product?” Marshall L. Fisher distinguished two types of products that call for different supply chain strategies: functional and innovative. They differ as follows:

* Functional products, like canned soup and blue jeans, have longer life cycles (perhaps more than two years), relatively low contribution margins, and little variety. Because demand for them is stable, they are fairly easy to forecast, with a margin of error in the 10 percent range, very few out-of-stock situations, and no end-of-season markdowns.
* Innovative products differ from functional products in every aspect. They have unpredictable demand, relatively short life cycles (e.g., three months for seasonal clothing), and high contribution margins of 20 to 60 percent. They may have millions of variants in each category, an average stock-out rate from 10 to 40 percent, and end-of-season markdowns in the range of 10 to 25 percent of the regular price. The margin of error on forecasts for innovative products is as high as 40 to 100 percent, but the lead time to make them to order may be as low as one day and is generally no more than two weeks.

The idea that the same type of product can be either functional or innovative implies that one company might have more than one supply chain. And that’s the contention of Jonathan Byrnes, a professor at MIT. Writing in the Harvard Business School’s Working Knowledge 2005 article entitled “You Only Have One Supply Chain?”, Byrnes also asserts that one supply chain is not enough: two, three, or more would be preferable.

“One size fits all” supply chains may have been sufficient in the past, he believes, when that was the competitive norm, but modern IT makes it possible to have multiple, dynamic chains that can accommodate different product and information flows. Byrnes breaks apparel products into the following three categories: staples, seasonal products, and fashion. These products have very distinct design and replenishment characteristics.

Much like Fisher’s functional products, staples (e.g., white underwear) have steady, year-round demand and low margins. He advises stocking them only in retail outlets in small quantities and transporting them in truckload quantities (a full truck is more cost-effective for the shipper than a partially loaded vehicle, i.e. less-than-truckload [LTL] shipping.) Fashion products are like Fisher’s innovative items with unpredictable demand.

Consequently, Zara, the famous Spanish clothing manufacturer, has two supply chains, one for staples and the other for fashion clothing. To get the fastest response time, Zara uses pricey Western European suppliers for the fashion items. But for the more predictable demand items, it uses Eastern European suppliers, which have poorer response time (not a major concern here) but at much lower cost.

In addition to varying the supply chain by product type, Fisher recommends several other variables to consider, such as store type and time in the season or product cycle. Demand varies considerably over the life cycle of many products, whereby the same item might have infrequent demand at first, more stable demand in its maturity phase, and falling demand at the end of its life cycle.

With more than one supply chain, a master retailer can move its products from one chain to the other in response to changing variables, such as type of channel or life-cycle stage. Yet most retailers still move all three types of items to their stores through the same supply chain. Conversely, leading vertical retailers have multiple supply chains, based on a combination of factors such as service levels required, type of demand (e.g., basic products should never be out of stock), and display.

By having a variety of tailored supply chains, retailers that Act Vertical can actually reduce supply chain costs by streamlining the flow of goods. KSA points out one unnamed multibillion-dollar retailer that expects to boost earnings by US$40 million annually and generate more than US$100 million in cash next year by replacing one inefficient supply chain with three streamlined ones.

You Can Control Only What You Measure

Moreover, to Act Vertical, retailers must also change the way they measure supply chain performance, which should be in a holistic, balanced scorecard manner. Namely, many retailers today manage with the goal of achieving the lowest transportation and logistics costs. However, that can increase inventory levels at the store, in the truck, at the distribution center (DC), on the boat, or in the factory.

Excess inventory often then needs to be marked down, and lower margins from markdown sale items can greatly reduce profits and wipe out the cost reductions achieved in transportation. Instead, retailers that Act Vertical track their supply chain performance according to “net-realized-margin,” which takes into account the total profitability and total landed costs of getting products from the factory to the store, including their selling price.

These retailers also use different measures to track the performance of products in the stores, based on different in-stock goals and service strategies by product category. According to Module One of the APICS CSCP Learning System, the appropriate supply chain for functional products should emphasize predictability and low cost with key performance indicators (KPIs) such as the following:

* High average utilization rate in manufacturing;
* Minimal necessary inventory with high inventory turns;
* Short lead times (consistent with low cost);
* Suppliers chosen for cost and quality; and
* Product design that strives for maximum performance and minimal cost.

Conversely, the supply chain for innovative products should emphasize market responsiveness rather than physical efficiency, with KPIs such as the following:

* excess buffer capacity and significant safety stock (buffer stock) of parts or finished items;
* aggressive reduction of lead times;
* suppliers chosen for speed, flexibility, and quality (rather than cost); and
* modular design that postpones the customer order decoupling point (CODP) decision (and differentiation) as long as possible.

The KPIs for each supply chain differ because the products’ characteristics differ too. Aggressively reducing lead times, for example, is appropriate for innovative products but would be irrelevant for functional products that can be manufactured and delivered on predictable schedules in high volumes.

On the other hand, inventory reduction makes good sense as a KPI for supply chains if the product is functional but not if it’s innovative. Because profit margins are low on functional products (those markets tend to be very competitive), cost reduction in the functional supply chain is essential.

Innovative products, however, with their high margins and unpredictable demand, justify extra expense for holding costs. In addition, manufacturers of innovative products can look for other solutions to the problem of unpredictable demand, such as to aggressively reduce lead times and build products to order rather than in a made-to-stock (MTS) manner.

The same class of product, the author argues, can be either innovative or functional. For instance, coffee can be functional (e.g., for business meetings, at gas stations, or on airplanes), in which case it should be available quickly at a low price with perhaps cream and sugar as options. At an upscale coffee shop, on the other hand, patrons are willing to endure longer lead times and pay more money for their coffee, but they want variety in return. As a Starbucks addict, I can vouch for the latter case.

All of the above practices increase the likelihood of delivering the right product to the right place at the right time, and at the right cost (and price). Basically every retailer will have to act vertical over the next few years to react quickly to more-demanding consumers whose tastes are changing faster than ever.

The Seven Magic Core Competencies

So how were the abovementioned act-vertical retailers able to create and execute distinctive and compelling offerings and customer experiences, and what exactly did they do to achieve superior financial performance? First, KSA points out that they have a clear retail-brand strategy: a sharp articulation of their target customers and the kind of offering and experience they would deliver to them.

Second, these retailers have developed the following seven core capabilities that enabled them to deliver unique and compelling offerings and customer experiences:

1. Market research that identifies emerging customer needs and product opportunities. Research that PetSmart Inc. conducted in the late 1990s opened its eyes about how critical pet services were to pet owners. Aeropostale Inc., the mall-based specialty retailer of casual apparel for young people, empowers its employees to travel extensively to see what its core young teen segment is wearing.
2. Product design and development that balances creativity and commercial appeal. Both Coach Inc., a leading American designer and maker of luxury lifestyle handbags and accessories, and Aeropostale, make sure that the quantitative analyses don’t dominate the design creativity.
3. Extensive consumer testing that shapes the offerings and customer experiences and reduces the risk of product innovation. For example, Coach spends US$5 million annually on such consumer research, including 70,000 in-depth interviews.
4. Tight relationships with sourcing vendors, which enables manufacturing capacity to scale up quickly and quality to be maintained. This accelerated manufacturing cycle also allows the delay of key product decisions to accommodate consumer and fashion changes in the nick of time. In addition to Zara’s abovementioned example of two supply chains, Coach works directly with leather suppliers to ensure its handbags meet its exacting standards.
5. Inventory management (assortment, allocation and replenishment) capabilities that can rapidly move products to places of greatest demand and maximized pricing.
6. Design and execution of an engaging and consistent brand experience across all shopping channels stores, catalogs, and the Web. Apple organized its stores (which have the highest per square foot sales in retailing) not by technology categories but rather by how customers use them. Its about 250 stores group hardware, software, and accessories in sections such as music, movies, photos, and children.
7. Marketing that communicates the brand promise across all channels and showcases how the retailer’s offering and experiences enhance their customers’ lifestyle.

More details and examples can be found on KSA’s website.

The Act Vertical Imperative as the Conclusion

Part 2 outlined the reasons that are driving retailers to Act Vertical, i.e., control over most decisions about the products that flow through their stores. These drivers are not abating; if anything, they are increasing.

Indeed, consumers have a fast-expanding variety of shopping choices, and Internet-based retailing continues to take a bigger slice of the pie. And in a global world, the number of product brands consumers can choose from continues to grow in categories from high-tech gadgets to apparel.

Therefore, all retailers must radically change their business models to keep once-loyal consumers from defecting. Retailers that can adopt and embrace an Act Vertical business model will increase their influence on the design, development, manufacture, and distribution of the goods they bring to market. They will be then able to put a differentiating and recognizable stamp on those products, as well as on how consumers experience them, thereby distinguishing their stores (and online storefronts) from the pack.

It is interesting to note, thought, that most retailers have put just a few Act Vertical elements in place. Only a few have created the three-part foundation (outlined in Part 2) that is essential to creating a successful act vertical business model.

But despite their rapid and profitable growth, none of the retailers that KSA has studied had mastered all seven components of acting vertical. This might present considerable opportunities both for laggard retailers that have yet to pursue an act vertical model and for retailers that are already operating this way.

Segregation of Duties and Its Role in Sarbanes-Oxley Compliance Issues

In the aftermath of some highly publicized cases of corporate fraud, the US government announced legislation designed to implement compliance and financial-reporting standards. The most notable of these laws is the Sarbanes-Oxley Act (SOX) of 2002. The primary goal of SOX is to enforce a higher level of transparency into organizations' business processes, financial transactions, and accounting methods, to ensure that known and accepted accounting principles are practiced.

In this new SOX era, the issue of compliance spans several industries, attempting to harmonize evolving standards across both public and private sector organizations. The requirement of standardized reporting of financial information now forces organizations that had once been less transparent to tighten and streamline their audit and control practices on an ongoing basis.

Traditional Audit and Compliance Standards Prior to SOX

Pre-SOX standards were designed to ensure a modicum of corporate governance by focusing on the areas outlined by the Committee of Sponsoring Organizations (COSO) and on an IT system process framework. This framework was provided by the Control Objectives for Information and Related Technology (COBIT) IT process standard, which was developed in 1992 by the Information Systems Audit and Control Association (ISACA). COBIT was to provide adequate control levels for organizational structure, ethical standards, and board and audit committee review. It was the earliest set of audit standards established to cope with IT processes and audit procedures. COBIT focused on application controls, general control of information systems, and security issues.

Reporting standards used prior to SOX remain in place today. Of these, the most notable are the EU's adopted version of the International Financial Reporting Standards (IFRS) and the US's Generally Accepted Accounting Principles (GAAP). In 2002, an accord known in financial industry circles as the Norwalk Agreement was struck. This agreement states that US-based companies' financial-reporting procedures are to be harmonized with the European standard by the end of 2008. The implementation of SOX for firms that import into and export out of the United States is yet another layer of compliance standards recently introduced. Table 1 lists several other audit control standards, both pre- and post-SOX.

Regulation	Purpose/Target Industry
SOX	publicly traded US companies
ISO 17199	IT security standards
Canadian bills 198, 52-109, and 52-111	Canada 's SOX equivalents
Basel II Accords	G8 regulations for international banking
Health Insurance Portability and Accountability Act (HIPAA)	US health and medical industries
Office of Management and Budget (OMB) Circular A-123	US government agency financial standards
Solvency II	European insurance industry standards
IFRS	European accounting standards
Office for Economic Co-operation and Development (OECD) principles	EU agencies of internal controls
GAAP	US-based generally accepted accounting principles

Segregation of Duties:

Within SOX is a provision entitled Section 404. This section is a comprehensive list of accepted internal controls organizations must have in place to be deemed SOX-compliant. The list targets application internal controls and highlights areas where fraudulent reporting is likely to occur, whether intentional or not. Among key provisions in this section is segregation of duties (SOD). SOD aims to close loopholes that would otherwise permit questionable accounting practices; one of its key attributes is that it allows the monitoring of processes and cross-verification of transactions processed in real time.

In simplified terms, SOD is based on the concept of having more than one person in an organization that is able and mandated to complete a task. SOD is a security principle whose main goals are the prevention of fraud and errors. These two objectives are realized through the reviewing of business processes and the dissemination of tasks and associated authorizations among several levels of hierarchy. Such actions serve as validation—in other words, they are a series of checks and balances.

One way to illustrate the key tenets of SOD is to consider an accounting department in any small to medium business (SMB). Here, some of the day-to-day activities include the receiving of checks as invoice payments, approval of employee time cards, processing of payroll checks, and reconciliation of bank statements. Within these activities a form of SOD is already in place—usually the issuing of checks requires different levels of authorization and more than one signature. In essence, more than one person validates a process or activity.

In terms of IT, SOD issues are not as clearly defined, and in many instances, individuals in an SMB have multiple levels of responsibility, which can call into conflict the stated goals of SOX and SOD.

Following are five circumstances in which IT processes can conflict with the goals of SOD:

1. Improper account provisioning for change, meaning access rights to applications are not changed (revoked) when employees leave the organization or a department.

2. Insufficient control of change management issues, meaning a change is made to a financial application or process without documented record of the date the change occurred, the nature of the change, and which persons in the organization are impacted by the change, for quality assurance purposes.

3. IT departments lack an understanding of key system configuration workflow processes.

4. No audit logs are used to document unusual system or application occurrences.

5. No root cause analysis is performed to determine what caused an unusual event.

Twin Pillars of Protection

In any organization, IT serves as both the gatekeeper and the distribution point for information. Financial-reporting serves as the means to support an IT infrastructure. Insofar as systems infrastructure and financial reporting are linked, the requirement to ensure the integrity of the system and the processes that support it are in compliance with accepted standards and practices. Within these twin pillars of protection are principles that must be adhered to in order to ensure the integrity of the system, the public's confidence in the system, and that all key requirements of SOX Section 404 are met. Figure 1 depicts the basic steps to take to meet these requirements.

Figure 1. Key elements to support SOX and SOD.

1. Study business control processes.

Below are three of the primary business control processes essential to support SOX compliance:

1. Controls found within most ERP systems—these controls reconcile orders processed only with prescribed customer credit limits. All goods shipped have an associated invoice.

2. General IT controls—these allow authorized individuals access control to order management and receivables applications. This process ensures that system upgrades and fixes are documented.

3. Manual controls—these controls ensure that only authorized individuals can alter or cancel a customer order.

2. Develop and automate internal testing to support the system.

Most organizations typically run financial reports on a monthly and a quarterly basis, reporting the organization's performance in terms of budget and projected sales. To ensure compliance to SOX-SOD requirements, these two procedures are essential:

1. Using internal data to ensure that no sales or financial records can be altered without being identified, logged, and reviewed by three levels of authorization.

2. Reviewing examples of where individuals contravene SOD requirements (e.g., persons who perform procurement activities cannot also be involved in the receiving of inventory and the posting of accounts payable).

The purpose of this exercise is to demonstrate that an internal, documented process exists to segregate responsibilities and prevent any ability to alter or destroy financial-related data.

3. Analyze test results with known compliance standards (e.g., COBIT, COSO).

When organizations are in the process of selecting enterprise software applications (e.g., an ERP system), due diligence is advised as part of the request for proposal (RFP) process to ensure that the proposed vendor's solution adheres to known financial-reporting and compliance standards in its industry. When interfacing a new solution with a legacy application or with an internally developed in-house system, the COBIT and SOX models should be the fundamental criteria for assessing whether the new system meets your organization's compliance and financial-reporting requirements. Following are some additional points to consider:

• Data revision management—changes to financial-reporting data should be carefully managed, ensuring that all modifications are authorized and documented.

• Contracts—all IT vendor contracts and service level agreements (SLAs), including their financial implications, must be clearly defined.

• Third-party equipment—third-party software must abide by known and accepted standards. License and user requirements must be defined in vendors' contracts, as these requirements are also subject to known performance criteria indicated in the vendor SLA at the time of software purchase.

• Access control—ensure users have an identifiable security password and user code, which tracks access and transactions performed.

• Security—the system must be in compliance with ISO 17799 and designed in a way that limits disclosure or access to unauthorized parties.

• Incident management—the system must record all incidents of failure or loss of data, and must support Information Technology Infrastructure Library (ITIL) guidelines. Corrective action to be taken must be documented so that it can be retrieved, and the work performed by another person.

SOD Checklist

If your organization is planning to review its SOX- and SOD-readiness, then a good starting point is to obtain a copy of the ISACA's segregation of duties control matrix to use as a general guideline. If after reviewing the matrix you conclude that your company performs certain tasks that cannot be segregated, then you can implement a series of further controls. Below are a few separate control procedures to help achieve SOX-SOD compliance:

• Ensure that transparent audit trails are in place, that management is aware of each individual's level of responsibility, and that corresponding authorization is established.

• Ensure that information related to who did the work, who approved the work, and the date and time the activity was executed are documented in the audit trail.

• Enable the ability to review transactions at random times, thus instilling confidence in the process.

A Final Word

The introduction of SOX is hoped to bring a new level of accountability to the corporate world. It is believed by many that from the cases of corporate fraud in the United States several years ago, a new opportunity has emerged for corporate America to show integrity and prove that the interests of customers, employees, and shareholders are its primary concern. The positive outcome in all of this has been that those running organizations realize that their companies are part of the community they serve, and unethical behavior will not be tolerated. The compliance aspects of SOX and SOD, though challenging to understand at first, limit the opportunity (or chance) for wrongdoing, and ensure that organizations employ streamlined and verifiable processes to run their business.

Stay tuned for an upcoming blog post that will feature TEC's own SOX-SOD compliance matrix. This checklist will highlight the key areas to review in order to determine your organization’s SOD-readiness, as well as show how your organization compares with industry standards.

Thou Shalt Comply (and More), or Else: Looking at Sarbanes-Oxley

Most enterprises have to compete globally and thus adhere to largely nonnegotiable legal and regulatory requirements in almost every region or vertical sector they are targeting. Thus, regulatory compliance and the management of a multiplicity of prospective risks have lately pervaded the minds of most executives and upper managers.

Indeed, no single chief executive officer (CEO) would—with a sound mind—like to be apprehended for embezzlement and placed in handcuffs in front of sensation-hungry TV cameras. Neither is any manager eager to face the severe consequences (penalties, lawsuits, brand erosion, tainted reputation, etc.) of a major product recall that is brought to the public's attention because of some extremely unlucky consumer's death or serious illness. Some such recent occurrences include the recall of a major sport utility vehicle's (SUV's) track tires; contamination due to a dangerous chemical leak, causing fatalities; and an E. coli outbreak caused by a contaminated food product. Further, no company is willing to have its imported goods kept at the ports indefinitely, let alone pay severe penalties for (knowingly or not) trading with rogue countries and blacklisted parties, or for having dangerous goods or contraband in its shipments.

Sure, regulated environments have been around a long time, as exemplified by the existence of the US's Robinson-Patman Anti-Price Discrimination Act of 1936 and Hart-Scott-Rodino Antitrust Improvements Act of 1976. More recently, in 1991, US President Bush signed into law the Telephone Consumer Protection Act of 1991 (TCPA), which amended Title II of the Communications Act of 1934. Also known as the "Do Not Call" program, the United States Congress enacted this law to reduce the nuisance and invasion of privacy to the public caused by telemarketing and prerecorded calls.

However, a number of recent events that have negatively affected consumers and damaged public trust has led to the awareness of and the insistence on corporate social responsibility and accountability. Possibly the greatest attention so far has been given to ensuring compliance to the US Sarbanes-Oxley Act (SOX). Namely, the now proverbial Enron, Tyco, and MCI/Worldcom scandals of a few years ago, in which these companies were proven to have falsified their financial statements, have cost billions of dollars and devastated public trust in financial markets (see Claudia Delto's 2005 article Checking It Twice—Basel II, Sarbanes-Oxley Act, International Financial Reporting Standards).

These companies have especially hurt several million small investors by nearly wiping out the investors' pension plans. Much of the abuse that occurred at that time simply came down to either the failure to remember or a deliberate disregard for basic ethics and common sense. The US government reacted in July of 2002 by instating a law that defines how corporate reporting must be performed—the law that was deemed instrumental to restoring investor confidence by providing transparency in corporate financial reporting. Even more recent (albeit much less grave), the disclosure of financial results restatements and of shady executives' backdated compensations at some renowned corporations (Apple, for example) might be showing us that one can never be too careful and work merely on an honor system.

SOX "Preying" on (Almost) Everyone's Mind

To put it into context, SOX was passed by the US Congress in response to the high-profile financial scandals involving companies like Enron, Tyco, and others. The idea was to make corporate accounting procedures more transparent to investors and regulators.
Even before these scandals ever took place, the raft of missed earnings announcements that had for some time occupied headlines in the business press during the 1990s exhibited one common thread—time and again, chief financial officers (CFOs) would moan that they had failed to meet expectations due to a "lack of visibility." These executives would frequently blame major events that they could not have predicted as the cause of poor quarterly performance. Either a key customer cancelled a major order unexpectedly; major product lines were becoming obsolete (and non-marketable); or suppliers were ramping up prices due to a shortage of raw materials.

Increasingly, however, CFOs are being called upon to give more accurate estimates of their earnings potential, and if the company fails to meet these estimates, then they should at least be able to give a detailed explanation as to why.

SOX sets new standards with regards to responsibility, accountability, transparency, and correct behavior in companies. The act also sets requirements for the effectiveness of internal monitoring of companies' financial reporting (see Checking It Twice).The US Securities and Exchange Commission (SEC), established by the Securities Exchange Act of 1934, is responsible for the law and for corporate compliance with it. SOX applies to both US and multinational companies that are listed on the US stock exchanges, such as NASDAQ, while foreign companies that are listed on US stock exchanges are subject to SOX for all fiscal years that ended after July 15, 2006 (see Checking It Twice).To be more accurate, it is applicable to all companies whose securities are registered and that are required to file reports under 15(d) of the Securities Exchange Act.

The motivation behind SOX was to restore investors' trust in the reliability of financial data that companies publish about themselves, and to mitigate the risk of false financial statements. The act also set up a supervisory committee for auditing companies (see Checking It Twice). Specifically, each affected company has to establish fully independent audit committees (that are responsible for oversight of the auditor); must wait at least one year before hiring an audit management team member to be a CEO, CFO, or the equivalent; cannot extend loans to directors or corporate officers; has to make annual internal control reports; must disclose information about material changes on a real-time basis (initially in two business days, but now in four); and must establish "whistle-blower" (informant) protection for employees (who are typically subordinates).

Moreover, as the act creates severe criminal penalties (fines or imprisonment up to twenty-five years) for defrauding shareholders, a publicly traded company's top managers have been made personally accountable for their company's actions, especially for the accuracy of their companies' financial statements and the effectiveness of their internal auditing. Indeed, CFOs and CEOs of publicly traded companies are nowadays very much aware of SOX and its impact on their firms, since even an honest but disengaged or naïve executive may face a career-ending and disgraceful fate. Also, the whistle-blower protections and prosecutions of lower-level managers too will make subordinates unlikely to remain silent or cover up any wrongdoings.
CEOs and CFOs have to certify financial reports quarterly, since Section 302 of SOX requires certification to the accuracy and fairness of the financial statements, and to the adequacy of the internal control framework around the financial statements. Officers, directors, and others are hereby prohibited from fraudulently misleading their auditors, while executives have to disgorge (give back) bonuses and profits after restatements due to misconduct. This point, however, can still cause conflicts with regulations in other countries. In Germany, for example, executive board members are currently not held personally responsible by law for their companies. While solutions to such conflicts are still yet to be found , some regional SOX variants have emerged, such as Japan's version of the law—"J-SOX" (see Checking It Twice).

Oversight Board Established

SOX implementations within public companies have been overseen by the Public Company Accounting Oversight Board (PCAOB), which consists of five full-time members that are appointed and overseen by SEC. Two of those five members must be or must have been certified public accountants (CPAs), while the remaining three must not be and cannot have been CPAs (so as to bring alternative perspectives). The board, which is funded by public companies via mandatory fees (while accounting firms that audit companies must register and pay fees too), is responsible for overseeing and investigating the audits and auditors of public companies, and has the authority to sanction both enterprises and individuals for violations. PCAOB is authorized to regularly inspect the operations of registered accounting firms, and also has international authority over foreign accounting firms that prepare or furnish audit reports involving US registrants.

The tricky thing is that while the PCAOB standard does not require a single form of report documentation per se, each company must still report and provide reasonable support that includes, according to Resources Global Professionals (the operating subsidiary of Resources Connection, Inc. [NASDAQ: RECN], a multinational professional services firm that helps business leaders execute internal initiatives), the following elements:

1. Design of controls over relevant financial statement assertions
2. Information about how significant transactions are initiated, recorded, processed, and reported
3. Sufficient information to identify where material misstatements due to error or fraud could occur
4. Identification of controls designed to prevent or detect fraud, including who performs them and the relegated segregation of duties (SODs)
5. Controls over period-end financial reporting processes
6. Controls over safeguarding of assets
7. Results of management's testing and evaluation

SOX has included a number of new mandates, with two sections having clear implications for corporate information systems, and some that are especially relevant to supply chain management (SCM). In their efforts to comply with these new and stringent regulations, companies have adopted a variety of methods to handle the technical challenges that SOX has created for them, which will be explored in subsequent parts of this series.

Preparing for Product Development in Process Manufacturing

As seen in such articles as Product Life Cycle Management in Process or Process Manufacturing Software: A Primer, what the process manufacturing industry lacks in glamour, it certainly makes up for in complexity. Traditionally, manufacturing is divided into two categories: process and discrete (if one is not counting hybrid, mixed-mode environments). Many differences exist between the two environments, but most differences can be grouped into one of two areas: 1) those differences derived from material issues, and 2) those differences derived from production issues.

Process manufacturing materials (ingredients and finished products) are different from their discrete counterparts. Process materials are customarily powders, liquids, or gases, which must be confined and which are more difficult to measure accurately. Process manufacturing materials are typically also processed close to their natural sources (e.g., farms, mines, oil wells, etc.). In addition, the materials are of inconsistent quality, which means extensive quality procedures, segregation (lot control), restriction of use (i.e., "this lot is OK for one customer but not for another"), and, usually, the inclusion of quality attributes as part of their inventory definition needs to be implemented.

Process materials can also vary over time. They can get better, they can get worse, and they can even completely change their identity down the track (e.g., owing to the aging process or a limited shelf life). In addition, ingredients often come in a variety of grades and specifications, which can impact the properties of the produced goods. This additional inherent variability leads to both product lifecycle management (PLM) and production or supply chain operations challenges.

It is the differences in production issues between process and discrete environments, however, that reveal the simplest definition of process manufacturing: once one produces the finished product, one cannot distill it back to its basic ingredients. Process materials often involve irreversible mixing, blending, heating, melting, and other operations, while the duration, operating conditions, and sequence of production steps can have a dramatic impact on the yielded material. Has anyone ever attempted to turn orange juice back into its original water, sugar, sodium, and, of course, unpeeled oranges; extract crude oil from derivatives; or extract the pigments out of paint? Conversely, one can disassemble a finished car into its original components, such as tires, spark plugs, axes, chassis, carburetor, and engine block. Thus, where with discrete manufacturing one talks of parts or components, with process manufacturing one speaks of ingredients. Similarly, formulas take the place of bills of materials (BOMs), and convertible units of measure (i.e., pounds, bags, boxes, ounces, and liters) can be related to units.

Thus, food, beverages, chemicals, paints, drugs, and many consumer packaged goods (CPG) are produced quite differently than their discrete counterparts. This is because process manufacturing typically produces products (including coproducts, byproducts, and recurring materials) based on formulas or recipes that detail the ingredients, production steps, and processing parameters, as opposed to on precise BOMs and routing operations, which is typical when making and assembling discrete items.
There are also more subtle differences between the two types of manufacturing. One of these differences is the fact that process manufacturing is scalable. For example, if the formula calls for 1,000 pounds of cake flour, but one only has 500 pounds, one can still bake cakes, just not as many. Conversely, in discrete manufacturing, one missing part means waiting for it to arrive before the finished assembly unit can start rolling off the production line. With process manufacturing, one also tends to make products in bulk or batches, as in a vat of coke or a 500 gallon tank of solvent, and then pack it off to fulfill customer orders. On the other hand, in discrete manufacturing one would expect to see one appliance or car at a time coming down the production line.

The Challenges of Process Manufacturing

For decades, enterprise applications vendors have used technology to automate the business processes that are found in the more straightforward discrete manufacturing setup, where much of the complexity lies in coordinating the great number of widgets that are assembled into computers, minivans, and television sets. The capacity needed to assemble the multitude of intermediate parts and subcomponents into finished goods is a simple function of the number of assemblers brought to the task, which can be increased or decreased according to demand.

Conversely, it is not easy to make changes in process manufacturing. For example, the amounts of chemicals that a plant can produce are fixed by the design characteristics of the tanks and reaction vessels it uses to make them. Adding capacity is a costly endeavor involving months of design work, followed by multimillion dollar construction projects. Disposal of off-spec material is another costly operation, even in cases where the material can be sold to another plant. Rework of unused material is preferable, but requires careful planning so that production of premium-grade products is not adversely affected.

Additionally, unlike with discrete manufacturing, switching from one product to another in a process plant involves significant downtime during which maintenance is performed and vessels and piping are cleansed to prevent product contamination. A classic example is a brewery, which has to mix and brew a variety of product flavors, handling hundreds or thousands of actions involving the complexities of pipes, tanks, and supplies. When one type of beer is being made, the tank being used to produce it is no longer available for other operations. Effective process enterprise resource planning (ERP) software needs to be able to control how long it takes to fill the tank, determine what ingredients will be used, and determine how long the beer needs to brew. Once the brewing is completed, the software must schedule when the beer will be pumped out to be bottled, and arrange for the tank to be cleaned. When one extrapolates from this simple one-product example, one can see that scheduling an entire plant to meet customer demand for a variety of products is too complex a process for ordinary mortals. It requires specialized software with high-level mathematical capabilities.

Product Development for Process-oriented Industries

Product development can also be a challenge for process manufacturers, as product development requirements differ widely between the two styles of manufacturing. Because process PLM systems revolve around recipes and formulas (for more information on what constitutes a full-fledged PLM system, see Critical Components of an E-PLM System and The Many Faces of PLM), and because of the aforementioned variability in ingredient quality, product designers often must experiment with multiple formulations before they achieve the desired result.
Defining and formulating recipe-based, industry-tailored products can be a complex process, involving developing, perfecting, and protecting franchise products, their potential successors, and even the failed prototypes that preceded them. Often, as part of the development process, materials have to be provided to customers free of charge so that the customers can evaluate the product's performance in their process. This back-and-forth between customers and developers may be reiterated multiple times. Thus, many producers are still struggling to balance development and production costs (while factoring in the impact of manufacturing capacity and supply chain speed) against the potential value of a new product.

Furthermore, product development is steadily becoming more about customer service than about mere product and process innovation, involving, for instance, developing unique products for preferred customers. Customers are increasingly demanding services that go far beyond mere delivery and replenishment. This is particularly true when it comes to specialty chemicals, where product development is often more about a one-to-one relationship with the customer and understanding its needs than it is about building a better molecule, since in this industry brands matter much less than in, for example, the retail or automotive sector.

Nevertheless, by combining process industry—oriented PLM capabilities with process manufacturing—oriented ERP ones, it may be possible to produce a unified sample management solution that would allow product samples for evaluation purposes to be delivered in the same manner that commercialized products are delivered. Further combining these PLM systems with process manufacturing—oriented supply chain management (SCM) solutions could provide additional recipe optimization capabilities, such as the evaluation of current inventory to develop least-cost or best-fit product formulations or recipes. Such evaluation would accelerate the new product development and introduction (NPDI) or new product development and launch (NPDL) process, help lower development costs, and shorten time to market for globally compliant products.

This would be particularly helpful in the specialty chemicals sector, where the NPDI process wins more business by recognizing and exploiting customers' needs (e.g., for adhesives, flavoring or scenting agents, polymers, etc.) than by trailblazing a new market with a purely technological innovation. In many chemical companies, but particularly in specialty chemical companies, every order might represent a new product, since it is often sufficient to tweak an existing formula or replace this chemical ingredient with that chemical ingredient. Thus, the faster the time to market and time to volume, the greater advantage these companies have over their peers, and the greater chance of gaining market share.

Regulatory Requirements for Process Manufacturing

Process-oriented industries may also benefit from the recent focus on regulatory management within the product development context, which parallels a general industrial trend toward better management of global regulatory requirements and environmental impact (see Atrion User Conference Highlights Need for Regulatory Compliance in PLM). This is because process manufacturers face different regulatory requirements than their discrete counterparts, which places additional demands on their software. The problem is in addressing compliance in a cost-effective manner. All of the benefits of PLM (including faster introduction of products to markets; reduced product cost; increased product sales; higher product quality; reduced waste; and more valuable product portfolios) can be quickly erased by significant, noncompliance events that impact the company through fines, penalties, negative publicity, or a prohibition on selling a new product in key markets.
In fact, regulatory management is only becoming more important as many regulatory bodies have renewed their focus on product compliance. Because these regulatory requirements vary from industry to industry, as do many other PLM requirements (see PLM Is an Industry Affair—Or Is It?), and because PLM functionality is becoming an essential element of an enterprise application portfolio, industry-specific functionality is increasingly critical to buyers of enterprise applications.

For instance, certain discrete manufacturing sectors are facing new regulatory requirements. Automotive companies, for example, must address the new requirements of the Transportation Recall Enhancement Accountability and Documentation Act (TREAD) in the United States, while electronics and high technology companies in the European Union (EU) must meet the demands of the Waste of Electronic and Electrical Equipment (WEEE) legislation.

On the process manufacturing side, food industry regulations range from developing nutritional and allergen information for product labeling, to the definition of control points to prevent contamination through a hazard analysis and critical control point (HACCP) process. Rising fears over bioterrorism and concerns with product safety and integrity are generating new government regulations that require food and beverage companies to track products throughout their life cycle. This means technology that tracks the original genesis of the food supply is of paramount importance. Thus, government regulations are driving the sector to invest in technologies that synchronize product labeling with formulation systems. For more information, see Process Manufacturing: Industry Specific Requirements Part One: Introduction and Food and Beverage.

The manufacture and use of hazardous chemicals are also governed by strict regulations, especially in North America and the EU. Thus, the chemical industry and companies that rely on chemicals within their plants must address a myriad of regulations, including Restrictions on Hazardous Substance (ROHS) and other regulations that require compositional analysis, the development of material safety data sheets (MSDS), environmental analysis, and hazards identification. The chemical industry must also deal with the impact of European Classification and Labeling Inspections of Preparations, including Safety Data Sheets (ECLIPS); Registration, Evaluation and Authorization of Chemicals (REACH); Science, Children, Awareness, Legislation, and Evaluation (SCALE); and Global Harmonized System for the Classification and Labeling of Chemicals (GHS). For more information, see Process Manufacturing: Industry Specific Requirements; Part Two: Chemical.

But it is the life science and pharmaceutical manufacturers that face possibly the toughest restrictions of all, requiring strict adherence to good manufacturing practices as well as to comprehensive and highly enforced Food and Drug Administration (FDA) regulations. Implementing and ensuring compliance with employee safety guidelines, possible food contact rules, monitoring emissions (which are often delineated by regulatory permits), and even validating the origin and composition of products are all mission-critical processes that contribute to the cost of doing business.

For such manufacturers, a further layer of complexity is added by the introduction of hazardous materials and dangerous goods that are closely regulated and must be reported. Software can greatly simplify this in two ways. First, when creating a new formula or modifying an existing one, that formula must be analyzed for the presence of hazardous materials. Performing this check requires a continuously updated and current list of regulated materials that are considered hazardous. It also requires knowledge of the percentage of these materials relative to the other ingredients.

Secondly, the reporting of hazardous materials must comply with a specific format, namely MSDS. These MSDS will usually accompany the customer's bill of lading (BOL), and therefore must be integrated with the billing process. While copies of MSDS can be kept on file and manually matched with the BOL, most companies will not want to risk noncompliance and would rather seek an automated remedy. Likewise, most companies will not want to rely on manual procedures to determine when a formula or product requires an updated MSDS. Instead, these companies will seek to have update notification incorporated into their enterprise-wide software, in order to automatically generate new MSDSs when needed. Thus, it is apparent that programming hazardous material compliance is not a trivial matter, particularly when one considers that it involves list processing and matching, percent of total analysis, scheduling, and formatting.