Aberdeen Group recently released a white paper called “Technology Strategies for Closed Loop Inventory Management“. This paper explains how inventory has and will continue to be the lifeblood of supply-chains and as such, needs to be properly managed.

Inventory drives revenue and efficiency for companies by reducing capital (with few inventories in stock) and simultaneously increasing customer service levels. – Aberdeen Group.

Those companies following the principle of closed loop inventory management can:

1. Determine safety stock targets
2. Replenish inventory into distribution buffers
3. View end-to-end inventory
4. Respond quickly to market events
5. Segment inventory based on customer service requirements

Closed Loop Operations Management

Decades ago, closed loop quality management was in vogue and most companies today have achieved this through total quality management programs. It’s certainly refreshing to see closed loop inventory management being discussed which is a must for a high-tech company to compete in today’s global market place, but the focus on just quality and inventory falls short. What sets best in class companies apart from the competition is closed loop operations management. Closed loop operations management encompasses inventory, quality, production, accounting, and other value added activities that help bring products to market.

Closed Loop Systems

Before exploring the attributes and benefits of closed loop operations management, let’s quickly review what a closed loop system is. In an open-loop system, there is no feedback. Inputs are calculated based on desired outcome only. An example of open loop management in high-tech operations is setting inventory levels, production schedules, and supply chain plans based on just sales forecasts and orders. A closed-loop system, on the other hand, is one that is controlled based on both desired outcomes and feedback from the system. Applying this principle to the former example, would mean that inventory levels, production schedules, and supply chain plans are determined not just by sales forecast and orders, but also feedback from ongoing operations. 

Having a closed loop system provides the following advantages over an open loop system:

1. Disturbance adjustment (such as actual yields and cycle-time)
2. Guaranteed performance even with model uncertainties (No supply-chain planning model matches the real supply-chain perfectly)
3. Reduced sensitivity to communication errors (developing the plan is one thing, but errors can develop when communicating it, especially to trading partners)
4. Improved reference tracking to plan

Visibility

So the different between open and closed loop operations management is the use of feedback from ongoing operations. One of the problems operations folks face today is they spend much time, effort, and money on planning to optimize operations by minimizing inventory, decreasing cycle time and lead time, and improving on-time delivery, but they lack visibility and execution ability to achieve their targets. As a result, buffers (inventories, freeze periods, longer lead times) are routinely accepted to insulate plans from disruptions, leaving decisions to be local in time and function, often based on historic performance at best.

To close the loop between planning and execution companies need to establish feedback through visibility to monitor for issues and trading partner compliance to instructions,trade laws, and environmental laws, systematic root-cause analysis, and decision supportfor proactive and concerted responses. This ensures plans actually happen rather than just replanning to adjust to reality. This is an ongoing process where visibility is established to continuously monitor and enable management by exception. Once alerted to an issue, the impact is assessed, a root-cause analysis is performed to help narrow down possible corrective actions, and different “what-if” scenarios are modeled to plan a response. The closed loop operations management process also leads to continuous learning and process improvements. It’s not enough to plan on having a lean supply chain with short lead times, you need to achieve it through closed loop operations management.

Real-Time Visibility

Gaining visibility into the complete picture is essential for closed loop operations management, but this is easier said then done. There are a variety of reasons that make it difficult to achieve high quality visibility. Before we discuss the challenges, let’s take a look at how to measure the quality of visibility in a closed loop system. There are two main factors that determine quality:

1. Resolution – how much feedback or visibility a companies has into operations including outsourced manufacturing
2. Latency – how quickly or real-time this information is gathered and available for KPI tracking and exception management

The drive for high quality visibility with high resolution and low latency feedback is simple. If you don’t have a complete picture of your current operations or the picture you have isn’t current, the feedback in your closed loop system becomes less useful decreasing your control over operations. An example to illustrate this in high-tech operations is a sudden increase in cycle time for a particular outsourced manufacturing process. If your organization doesn’t have visibility to this or doesn’t become aware of this increase for days or weeks, your ability to make the appropriate adjustments to reduce its affect on downstream operations and ultimately to the end customers is significantly diminished. With real-time visibility, the problem is acknowledged right away enabling an immediate response, minimizing the impact downstream. It’s not enough to have visibility, you need to have complete, real-time visibility into your operations including outsourced manufacturing.

The bar for visibility into operations has been raised in today’s demanding business environment. Two main market drivers responsible for raising the bar are the increase in the speed of business and globalization. Faster product lifecycles and increased customer fulfillment demands are changing the speed at which business is conducted. This in turn, increases the cost of any latency in responding to demand or supply-chain changes. Responding to a quickly changing environment requires real-time information. Secondly, the move to globally dispersed business models, where over 50% of the information needed to efficiently run operations resides outside your four walls, makes it increasingly challenging to achieve high resolution visibility. Hi-tech companies can no longer afford to take a hit on business agility when they outsource their manufacturing. All participants in the value chain need complete visibility for faster, better decisions.

Intelligent Operations Management

To address these needs and close the loop in operations requires a new category of solutions. Intelligent Operations Management has been recognized by leading analysts as a new and unique category of enterprise software that aligns business objectives with operational systems. Using real-time information from all parts of your extended enterprise, IOM completes existing infrastructure allowing better access to information, more effective collaboration between business units, and better operational decision-making. By closing the loop with Intelligent Operations Management, companies are able to control costs, improve service levels, decrease lead times, and address pricing pressures. Those companies who follow the principles of closed loop operations management enabled through an Intelligent Operations Management solution are best equipped to compete in today’s global business environment.

We’ve reported on our conversations on the concepts, derivation, and terminology regarding Intelligent Operations Management in several earlier postings, including “Collaborative Decision Environments“, “Notes on Enterprise Software“, “Shorter Time to Volume is the New Goal“, and “Defining the Category: Intelligent Operations Management“.

In addition to the discussions with Bob Parker of Manufacturing Insights mentioned in many of the above postings, Serus has also made presentations to Gartner Group, AMR, Aberdeen, ChainLink, Ventana, and CIMData.

One of the first external validations of Serus’ concept of Intelligent Operations Management has now been written and released by Manufacturing Insights.  Their recent white paper, describes all layers and concepts of IOM, and provides examples of its use.

The term Intelligent Operations Management can be broken down its three terms:

• “Operations” defines the scope of our solutions.  We address all parts of operations, including forecasting, planning, work in progress tracking, basically all the way from the manufacturing product specification (including ECO’s) and order placement through the fulfillment activities, WIP at your outsourced organizations, and finally interface with your financial systems for invoicing and reconciliation.  Not surprisingly, most of our sales are to the VP of Operations, though we have gained traction recently with the VP’s of Finance, and are starting to gain traction with the sales functions in our customers, these being on each end of manufacturing in the full lifecycle.
  We use this word because there are few systems that directly address the challenges within Operations.  Hence we provide unique tools that are based on real-world experience in operations, rather than trying to coble something together with a spreadsheet.
• “Management” defines what we enable our customers to do within that scope.  Our definition of management means first solving visibility challenges so that you understand the situation, in terms of inventory levels, backlog, etc., but most importantly allowing control of the situation, by making decisions regarding actions, orders, and instructions that are fed back to the organizations in the supply chain.
  This concept of management is most clearly thought of in terms of “feedback loops” which are a combination of visibility and control with the idea that corrective action is being taken, and new insights or information is being gained each time through the loop.
  Our product has dashboards that allow you to access information at the visibility, or raw content level.  A related concept is that the content has come from multiple sources, and hence has had to be collected and cleansed, meaning resolving errors or inconsistencies, such as inconsistent naming and organization.
• “Intelligent” defines the next level above Management, which adds the ability to define business goals and operational constraints within with the system’s operation.  A typical example of a goal is to “keep service levels above 98%”, or “Reduce stockouts to no more than 5%”, or “reduce inventory”, etc.  Adding goals into the decision making allows the system to suggest solutions or possible decisions that are biased toward the goal, again enabling the feedback loops to run more efficiently.  Another goal may be to carry out or advance a business process, as business processes act as the foundation for many feedback loops.
  Examples of operational goals within which decisions are carried out occur in often in finance, where for example a trading organization makes trading decisions but within a corporate goal of maximizing profit, and other goals that limit credit risk or cash utilization.

A classic example of a goal driven planning system is a supply chain planner, which has an engine that generates plans given a set of operational goals and thresholds.  However, many supply chain engines run overnight, and the plans that they produce are often out of date by 10 or 11AM the next morning, due to some unexpected change.  For this reason. Serus focuses on rapid tactical replanning, such as handling a supplier outage through a local replan, with a goal being to assure that this outage and plan does not affect other production activities.

Two important terms that don’t appear in the IOM term per se, are “collaboration” and “ecosystem”.

“Collaboration” defines the nature of the interactions between the different members of the supply chain.  It holds that no decision can be made in isolation, but instead have a context or state that defines them.  Typical examples are one of agreeing on an inventory stocking level by first communicating several different what-ifs or scenarios.  Or proposing different dates or product specifications between one organization and other, until agreement is reached.  Information can be changed, shared, retracted, committed, etc.

“Ecosystem” defines the set of participants within the collaboration, which can be all members from suppliers to customers, but also extends the definition of the information used in the decision process to include content from public and private sources, as well as content that is feedback, evaluations, and lessons learned within the ecosystem, in the same way that eBay or Amazon provide content about the members, books, and products that is created within the site augmenting the public information such as book descriptions.  In our case, ecosystems provide benefit when performing collaborative actions and decisions toward meeting a goal.

 The February 2008 issue of IEEE Computer has two important articles that follow up on the topic of using wikis and social networking software for collaboration.  Since our previous posting on Content Collaboration Software was one of the most popular postings of 2007, I’m bringing these articles to your attention.

The article “Wikis: ‘From Each According to His own Knowledge’” by Dan O’Leary of USC describes the history of wikis and typical usage today.  The first wiki was implemented in 1994 by Ward Cunningham.  Wikis offer the following advantages:

• Structure
• Consensus
• Collective Wisdom
• User Engagement
• Accuracy
• Delegation of Control
• User Management

They have the following limitations:

• Lack of authority
• No referees
• “Too many cooks in the kitchen”
• Bias
• Information insecurity
• Scope creep
• Decreased contributions – “slow death”
• Legal problems with content
• Vandalism

There are a number of potential applications of AI in the area of wikis.

The article “Social Networking” by Alfred C. Weaver and Benjamin B. Morrison of the University of Virginia describes how the mass adoption of social-networking websites points to an evolution in human social interaction.  It has discussion of MySpace, Facebook, Wikipedia and YouTube.

The first event of a multi-city roadshow profiling salesforce.com’s platform, called Force.com, was held yesterday in San Francisco.  We saw presentations on their latest platform capability, called VisualForce.  This is a tag-based toolset for building custom user interfaces.  In total, Force.com includes the following components:

• The runtime environment, which forms the basis of all operations, and persistence.  The runtime environment includes standard presentation facilities, standard navigation, on-demand load balancing, account management, and handling of all database-related operations.
• The building tools, which are all visual, drag and drop tools for creating applications.  These allow the definition of custom objects, custom layouts, custom controls, etc.
• The scripting/language environment, which is called Apex code.  This is a language similar to PL/SQL, Java or PHP, within which application logic can be written.
• The presentation environment, which is called VisualForce.  This is defined as a set of tag-based extensions to HTML, in the same way that JSP tags provide presentation tools.
• The AppExchange, which is Salesforce.com’s facility to package, present, and provide metered access to completed applications which are built with the above four components.

Not surprisingly, the concepts underlying Force.com are very content, or database, oriented.  The API’s have a database-like feel, with operations such as “query”, “update”, and “describe”.  The query language is SQL-based. 

For another description, see the article on the event by Phil Wainewright.  Force.com is one of a rapidly expanding number of cloud computing platform choices available to ISVs today.

It appears that platforms are going to be the important territory to control in the enteprise space during 2008.  This is the latest level of abstraction: we have moved from browser wars some ten years ago, to programming model battles (J2EE vs .NET) during the early part of this decade, to the platform struggles during the latter part of the decade.  There are clearly important platform plays coming from SAP and Oracle.

One of the major research areas that is now appearing in the IT industry is called “semantic information processing”, or the building and using of semantic information repositories.  A semantic information repository is a data collection that links concepts and names together.  We have probably all seen the need for this when performing Internet searches.  Suppose that we search for “chip”: this could mean a search for semiconductor chip, potato chip, or a person named Chip.  From the context, we can determine the meaning.

For instance, if I wrote the search:  “tell me about the nutrition value in chips”, I am probably talking about potato chips, since they are the only kind of chip that is food.

If I wrote the search “collect sales of the Intel T7200 processor chip”, the words “Intel” and “processor” would mean that I am talking about a computer chip or a semiconductor chip.

The intent is to enhance the usability and usefulness of the Web and its interconnected resources.

Historical Context

Early efforts in semantics were the knowledge representation and machine understanding efforts of the AI field in the late 60’s to late 80’s.  During this period, many researchers focused on how to represent knowledge such as scenes in stories, where character Jack is sitting in a house, Jack is married to Jill, Jack has a job of fetching water, water is located at the well, the well is located on a hill, and the hill is behind the house.  Each of these phases connects two nouns with a relationship.

Such knowledge context would then be used to guide the understanding of text or speech.  While many interesting presentations and demonstrations were given, the effort died with the “AI bubble” of the mid-late 1980’s.

Around the late 1990’s, some new efforts to organize semantic knowledge appeared based on the use of descriptive technologies such as Resource Description Framework (RDF) and Web Ontology Language (OWL), and the data-centric, customizable Extensible Markup Language (XML).  All take advantage of the hyperlinks already present in web-based context.

There was a very important article published in 2001 on “The Semantic Web” by authors including Tim Berners-Lee.

Recent Products

With the web plus today’s faster computers, the semantic information concept has been brought back.

One of the most interesting products in this area is called “Twine”, by Radar Networks. According to their description, Twine is using extremely advanced machine learning and natural-language processing algorithms that give it capabilities beyond anything that relies on manual tagging. The tool uses a combination of natural-language algorithms to automatically extract key concepts from collections of text, essentially automatically tagging them. These algorithms adroitly handle ambiguous sets of words, determining, for example, whether J.P. Morgan is a person or a company, depending on the context. And Twine can find the subject of a text even if a keyword is never mentioned, he says, by using statistical machine learning to compare the text with data sources such as Wikipedia.

See also Powerset’s presentation at IWSC.

Data Sources for a Semantic Processing Application

One of the data sources used is WordNet, which is populated with 137,543 word matching pairs.

These applications require, in part or whole, data that is available for sharing either within or across an enterprise. Represented in RDF, this data can be generated from a standard database, mined from existing Web sources, or produced as markup of document content.

Machine-readable vocabularies for describing these data sets or documents are likewise required. The core of many Semantic Web applications is an ontology, a machine-readable domain description, defined in RDFS or OWL. These vocabularies can range from a simple “thesaurus of terms” to an elaborate expression of the complex relationships among the terms or rule sets for recognizing patterns within the data.

The advent of RDF query languages have made it possible to create three-tiered Semantic Web applications similar to standard Web applications.  These applications have queries being issues from the middle tier to the semantic repositories on the back tier.

However, there is a three-way challenge that is holding up the implementation of semantic web systems:

• motivating companies or governments to release data
• motivating ontology designers to build and share domain descriptions
• motivating Web application developers to explore Semantic-Web-based applications

Web 3.0

We have all heard of Web 2.0, so what would Web 3.0 be?

Some of the best forecasts that I have seen match the above discussion.  A Web 2.0 application is a Web 2.0 application that has knowledge and “thinks”.

Lately the concept of semantic information processing has been appearing in the current IT world.  In one of Bob Parker’s presentations, he describes the role of a “Semantic Information Repository” as:

“essential to improving decision making will be the ability to organize all types of information.  At the heart of the repository for large organizations will be an operational data store that can organize large volumes of transactional data into hierarchical, analytic friendly forms.  The data store should be augmented by effective master data management that can provide a harmonized view of key subject matters like suppliers, products, assets, customers, and employees in the context of the value chain being monitored.  The ability to bring some structure to unstructured content like documents completes the repository”

Some of the places where we are seeing semantic resolution of information being important:

• Data cleansing – find product name equivalences
• Business process management – it combines easer to write a business process if all of the terms and references have been reduced to standards by an semantic pre-processing layer in the runtime engine.
• Business intelligence – it becomes easier to generate intelligence and conclusions if the corresponding data sets and events have been standardized through a semantic processing step.

This has been a great year for Serus and for the members of our community.  I haven’t discussed as much about Serus in this blog, since you can find that at the Serus web site.  Suffice to say that we grew by over 100%, and won a Deloitte award for 7th fastest growing company in Silicon Valley.

During this year, our visibility increased greatly, in media, with analysts, with organizations such as FSA (now GSA), and through this blog.  We recorded over 5,000 blog hits between the end of August and now (prior to that, our blogging system didn’t keep statistics).  Our most popular postings were:

• Best Practices for Fabless Semiconductor Companies (parts I and II) – this was published in October, and has become our number one article.
• Notes on Enterprise Software Architecture (all parts) – second most popular, and provides a reference point for many of the important ideas in our software
• Where’s the Content?  Reviewing Content Collaboration Software – third most popular.  This was a major read during early fall, as many people were interested in the choices we were making on software such as blogs and wiki’s.

A few observations about the trends during the year:  while the “enterprise 2.0″ term was very hot during the first half, I haven’t heard it mentioned as much recently.  Instead, we see an upcoming term being “collaborative decision environment“.

During 2008, we will be continuing to publish, and are expecting to get even more hits, because the blog will be tied to our new corporate web site.

See you in 2008!

Introduction

Supply chain planning is a critical task in operations management.  On the one hand, it algorithmically solves immediate problems of finding availability schedules, sourcing decisions and resource allocations to produce a plan that meets goals in an effective manner. But it also provides insight into the trade-offs of different factors, constraints and rules.

However, supply chain planning means different things under different situations.  In this post, we try to classify types of supply chain planning problems, address the modeling issues, and provide background regarding the algorithms used.

In the enterprise software paradigm, the supply chain planning element often goes under the name Advanced Planning and Scheduling (APS) in order to distinguish it from simpler approaches such as those based on simple demand accrual as used in MRP.  An APS module may help analyze the implications of alternative decisions and perform what-ifs.

Modeling

Models and data are two very important elements of supply chain optimization, and a plan’s usefulness greatly depends on the quality of both.  Here are a set of guidelines from a recent Supply Chain Digest article on “Rules for Supply Chain Optimization Technology“:

1. State Quantified and Measurable Objectives: For example, use an objective such as “minimize the sum of the daily fixed cost of assets”.
2. Faithfully Represent Required Logistics Processes in Models: It is easy to make mistakes in the model such that it doesn’t represent the way things work in the real world.
3. Explicitly Consider Variability: Too often, models associated with supply chain and logistics optimization either assume that there is no variability or assume that using average values are adequate.
4. Ensure that Data is Accurate, Timely, and Comprehensive: If the data is not accurate and/or it is not received in time to include it in the optimization, the resulting solutions will obviously be suspect.

For example, in semiconductor operations, models must capture a number of important complexities including:

• binning
• downgrading
• short product cycle times
• customer requirements on part sourcing

Several of the traditional supply chain engines do not handle these issues well.  For instance, a humorous story that our staff has heard is that one time a major supply chain vendor visited a fabless company.  When the vendor was presented with the problem of binning, they finally decided that this was a feature they would have to model as “scrapping”.

The structure and level of detail in the planning model determines the type of planning algorithm to use.  In this posting, we will look at several examples of plans and algorithms.

Levels of Planning

Different organizations have different ideas regarding the time period that is to be modeled and optimized, and the amount of detail.  For instance, shipment scheduling may be done on a day-by-day basis, while optimization of warehouse locations or changes in supply chain strategy may take place in a matter of quarters or years.

The following diagram (from AMR in 1998) shows the relationship between operational, tactical, and strategic planning:

Models that have a detailed and long time horizon or a large number of products, decisions, and constraints can be highly complex and difficult to optimize.  For example, a planning system might require an overnight runtime in order to generate the detailed production plans for several thousand products.  Hence, scoping the level of planning is critical when applying supply chain planning to your organization.

Aggregate Planning

First of all, let’s define the basic Supply Chain Planning problem.  This discussion is largely based upon the material in “Supply Chain Management” by Chopra and Meindl.  In this case, we seek to find values for the production and overtime levels, such that the solution meets the demand and minimizes cost.  We can formally state the problem as follows:

Given a demand forecast for each period in the planning horizon, determine the production level, inventory level, and the capacity level for each period that maximizes the firm’s profit over the planning horizon.

Inventory is allowed to be carried from one period to another, but at a cost.  There is a cost of adding a worker (factory) and a cost for overtime.  The objective function is the sum of the various costs:

• Production cost
• Overtime cost
• Material cost
• Inventory carry cost
• Hiring cost
• Layoff cost
• Stockout cost

Solution to Aggregate Planning

Aggregate Planning is simpler than other planning problems because it isn’t computing a specific schedule.  Hence, it can be solved with standard Linear Programming (LP) techniques.  For example, you can set up the following decision variables:

• Production in each time period
• Carry over in each time period.
• Number of workers added in each time period
• Number of workers laid off in each time period
• Overtime hours in each time period.

The resulting spreadsheet is shown below, with the decision variables shown in gray, and the optimal solution found using the Excel Solver

There are several factors worth considering when using LP modeling:

• Is the objective function strictly linear?  Not all models are.  Remember that a linear model cannot have step functions or products of two decision variables.
• Are the constraints linear?  If not, sometimes an approximation can be made.

Specific Supply-Demand Matching

While the above case is typical of Sales and Operations Planning, or Demand Planning, a different kind of model is needed for Production Scheduling, or Manufacturing Planning.  In this case, we are scheduling the specific manufacturing assignments for the products, matching each unit of demand to a specific manufacturing activity.

Rather than determine the total number of production activities in a period, consider a decision to determine a detailed list of:

(manufacturing start date, demand unit matched, supply unit consumed).

The number of decision variables is therefore three times that of total number of units — perhaps in the thousands, as opposed to dozens.

There are a number of different objectives that can be used in a planning problem.  Typically, the goal is to maximize, minimize, or satisfy something, such as:

• profits or margins
• costs or cycle times
• customer service  levels
• production throughput

Since a Linear Programming runtime increases as the square of the number of decision variables, a different approach is needed.  Instead, most of the approaches to planning are derived from robotic planning as developed in the artificial intelligence literature.  The paper by Nau, Gupta, and Regli specifically draws the relationship between AI planning and manufacturing operations planning.

Search-Based Solution to Specific Matching

The common approach is to carry out a search with backtracking.  The goal is to find a particular state that simultaneously satisfies all constraints.

The approach is to assign values to the constrained variables, each such assignment limiting the range of subsequent choices.   The set of possible values for the variables is called the “state space”.  Search algorithms, as discussed below, provide hints for how to handle dead-ends, and how to determine which possible assignment should be tried first in order to reduce the search time.

Example: The Eight-Queens Problem is to place eight queens on a standard chessboard in such a way that no two queens are attacking one another.  Here is an example of a possible solution:

The most common algorithm for solving constrained search problems is a type of depth-first search called backtracking. The most primitive version of backtracking assigns variables to values in a predetermined order, at each step attempting to assign a variable to the next value that is consistent with previous assignments and the constraints. If no consistent assignment can be found for the next variable, a dead-end is reached. In this case the algorithm goes back to one of the earlier variables and tries a different value.

The obvious approach is to assign variables in some order, then go back and change assignments when a conflict is detected.  For example, we would place the first queen in the upper left, and then place the second queen in a remaining valid spot, until we either succeeded or found a conflict.  Each time that a conflict is reached, we would back up a step and move the most recently placed queen to a different location and try again.

Backtracking and Thrashing

However, the run-time complexity of this approach is exponential, and it can suffer from thrashing; that is, search in different parts of the space keeps failing for the same reasons.

One common cause of thrashing is node inconsistency, in which there is a possible step or value that will cause the search to fail, independent of any other steps or values.  For example, if there are 4 possible load sizes that can be placed on each resource (for instance, a testing machine), but for machine 5, the largest load is not possible because of a machine defect, then any plan which tries to put the largest size load on machine 5 will be a failure and the search always fails immediately no matter how good the provisional plan is for machines 1, 2, 3, and 4. This can be resolved by removing such values before search begins.

Research in the late 1970’s and early 1980’s focused on improving planning and searches by controlling backtracking.  In general, the approach of non-chronological backtracking was developed, which uses additional information about dependency of choices that are being made.  There are two particular examples:

• Look ahead: if there is a simple-fast evaluator of a plan or subplan that can be used to determine the effects of upcoming choices, apply it to determine and restrict the set of choices.
• Look behind: rather than always undoing the most recent decision, look back through the set of choices made, and determine which one(s) had the most impact, then backtrack to that point.  This helps avoid the situation of exploring many choices in one low-value branch when there is another branch that contains high-value choices.

Another approach developed was tabu search: this enhances the performance of a local search method by using memory structures, and once a potential solution has been determined, it is marked as “taboo” (thus the name) so that the algorithm does not visit that possibility repeatedly.

Applying Heuristics

In the above example, the search process is largely exhaustive and blind.  Typically, a given path will be followed until the search finds that it either works or doesn’t, rather than using any available additional information about the path being followed.

Heuristics are guidelines that stem from practical knowledge and can be used to direct the search so that it doesn’t explore as many non-feasible solutions.

For instance, in a supply chain planning solution where distance leads to additional costs, one might ignore all solutions that try to source products from distant locations, in favor of solutionsinvolving closer locations.

The challenge is to determine useful heuristics and balance them, which is typically done by changing weights that are assigned to the heuristics.  Several commonly used heuristics in manufacturing operations are:

• Assign steps by critical ratio, which is an index used to determine how much a task is on schedule. A value of 1.0 is “on schedule.” A value less than 1.0 is behind, and larger than 1.0 is ahead of schedule. The critical ratio is derived by dividing the time to scheduled completion by the time expected to finish it
• Assign steps by First-in First-out, which is to complete each task in the order that it was started or assigned.
• Assign steps by Earliest Due Date
• Assign steps by Shortest Processing Time First

Approach Based on Theory of Constraints

A further example of heuristics that can guide the search process stems from what is called the “Theory of Constraints“.  This theory is often described as follows:

Think of your plant not as a collection of resources existing in isolation, but as a chain of resources required to perform in tandem towards common objectives. Just as its weakest link determines the strength of a chain, only a few critical resources constrain the performance of a plant. TOC is a systematic approach to identify such constraints and maximize their effectiveness.

The heuristics, then, focus on finding the critical constraints more than they emphasis finding the next possible assignment to make in the search.

At a conceptual level, the process is as follows:

1. Identify the constraint (the thing that prevents the organization from obtaining more of the goal)
2. Decide how to exploit the constraint (make sure the constraint is doing things that the constraint uniquely does, and not doing things that it should not do)
3. Subordinate all other processes to the above decision (align all other processes to the decision made above)
4. Elevate the constraint (if required, permanently increase capacity of the constraint; “buy more”)
5. If, as a result of these steps, the constraint has moved, return to Step 1. Don’t let inertia become the constraint.

Within the supply chain planning space, the planning engine would carry out phases of determining the most important constraint (often by increasing production through each resource until the limiting one is found), then continue to move on to the next resource.  At all times, the algorithm is maintaining a list of the critical constraints and adding production within them.

This is similar to the algorithm for solving a Linear Programming problem, but it doesn’t have the limitations of linearity imposed by such an algorithm.

A TOC-based approach is used in the planning engines of products from i2 and Thru-Put Technologies.

Repair-Based Solution to Specific Matching

Repair-based search algorithms start with an initial solution and attempt to improve it by iteratively applying repair operators.  Such algorithms can often handle large-scale problems that may be difficult for systematic search algorithms, as repair-based scheduling is a high performance scheduling technology that takes into account global optimization factors over a longer timescale, providing powerful advantages over pure dispatching approaches.

For instance, in the eight-queen problem, we would start by placing all eight queens on the board at first, and then determine where the conflicts are.

Each of these conflicts is a candidate for the next repair step.  For instance, we would move one queen to a different location, and determine if that increases or decreases the number of conflicts.  By keeping track of how many conflicts each queen participates in, and making repair moves to minimize the number of conflicts, N-queens problems that previously couldn’t be solved (i.e., N>100) became solvable in a matter of seconds even for large problems.

In the case of supply chain planning, we would start by assigning all demand units to an activity, and then determine which activities are causing conflicts.  Possible reasons for the conflict would be:

• Demand number not met
• Resource capacity limit exceeded

Performance Results

A series of tests were run based on actual fab data: 1850 lots with 44,600 tasks to be scheduled over 24 hour period.  This type of scheduling problem is one that occurs within many supply chain planning problems.  The data was derived from the SEMATECH 300mm process flows, with the following characteristics:

• a representative 300mm processing flow of 244 steps utilizing 35 different equipment types, divided into 95 stages for wafer move accounting. The nominal flow cycle time was 20.6 days.
• a modeled WIP level of 200 lots of 24 wafers each, of two different products, with an approximate steady state starts rate of 10 lots/day. The initial WIP distribution was approximately uniform along the flow.
• 4% hot lots among both WIP and new starts
• due dates for all lots based on nominal flow cycle time
• a close to capacity equipment complement, i.e. 8 of the 35 equipment types had expected utilization >90%
• unscheduled machine downtime consistent with a 5% to 40% derating value depending on equipment type, and an 8 hour MTBF – this provides a very high frequency of disruptive equipment events
• 14 day simulation interval with 10 minute resolution
• 244 steps using 35 different equipment types.

Move rate. The average stage move rate for each method is given in the following table. The rate for each was very close to constant over the entire 14d duration of the simulation, which lends confidence that initial conditions were not a significant perturbing factor.

RBS achieves a move rate 15% greater than CR, and 12% greater than FIFO.

Cycle time. The median and standard deviation cycle time per step is given in the following table, for all lots with >10 completed steps during the simulation timespan.

The reduction achieved by RBS over the dispatching methods is 11-16% in cycle time and 8-19% in standard deviation of cycle time.

Other Algorithms

Here are two other approaches:

• Simulated Annealing:   this is a class of probabilistic algorithms for the global optimization problem, that tries to find solutions by randomly generating solutions at different points in the search tree, rather than exhaustively evaluating all of them.
• Genetic Algorithm:  this is related to the repair-based approach, in that a partial solution is being improved on iteratively, but it takes to approach of maintaining a “population” of partial solutions and trying to combine them to form a full solution.  This is called an evolutionary computation approach in that it mimics how genetic changes occur in real populations, using ideas of mutation, selection, and crossover.

Use of Algorithms in Today’s Supply Chain Planning Software

In 2003, OR/MS conducted a survey of Supply Chain Management software.  They reported:

While the supply chain planning side of the industry seems to be hit more strongly than the supply chain execution software, a majority of the problems afflicting supply chain planning software are common in most other IT applications. Less than half of business software purchased in 2001 is up and running. Some of the problems relate to product complexity, inadequate management and technical support (internal and external), implementation lead times and flaws, poor project management, and unrealistic customer expectations that eventually result in customer dissatisfaction.

Despite all the bad news, supply chain management is still a priority for a majority of business executives who are currently operating under excessive cost containment pressures, extra capacity in their markets, and volatility of global markets affected by wars, terrorism and health threats. The scope of SCM keeps growing within a company and across enterprises, and the demand for effective planning and execution makes it extremely difficult to dismiss new technology and cling to traditional solutions over the long term.

There are no surveys that we have seen that tabulate the algorithms being used, although informal surveys indicated that the majority of the software providers are using search and backtracking techniques.  Many are built around the CPLEX engine from iLOG, which is a sophisticated LP-based solver.

The Serus supply chain planning engine is one of the few that uses a repair-based algorithm.

The Serus Managed Operations Services program provides outsourcing services for managing enterprise solutions and processes involved in semiconductor manufacturing operations.  This document describes the services that Serus can provide to manage such solutions.

Serus can provide a range of services necessary for successfully managing mission critical applications.  Customers can select any combination of services either within a service category or across categories depending on their needs.

Managed Operations Services

Serus Managed Operations Services are organized into three categories:

• Business Services:  focused on realizing the value of the Serus solution

• Applications Services:  focused on the operation, management and monitoring of the Serus solution

• Support Services:  focused on maintaining the Serus enterprise solution in an efficient and effective manner.

Business Services

Business Services are concerned with the business-related and functional aspects of the Serus solution deployed and how it is being used to deliver value to the organization.  These services are focused on maximizing the ROI a customer receives from the deployed solution and are critical to ensuring that a customer is getting the most out of their investment with Serus.

Business Services are designed to assist the client with:

• Master data modeling
• Financial valuation/cost modeling and tracking
• Coordination between Product engineering and Manufacturing
• Operations process coordination
• Supply chain planning activities and best practices
• Application change requests
• Exception management and root cause analysis
• SOX compliance and audit support

Serus Business Services teams work within existing client organizations to:

• Increase adoption of the Serus solution by users
• Provide ongoing recommendations to the customer’s business planning process
• Review and evaluate the quality of results generated by the Serus applications in the overall solution
• Make recommendations to improve the quality of the results and assist in implementation of quality improvements
• Monitor relevant business metrics (e.g., customer service levels, inventory levels, supplier performance)
• Provide “what-if” analysis to help decision making processes
• Help interpret generated reports and query results for functional and business users
• Generate specialized reports to facilitate further analysis of business data
• Make incremental changes to Serus application models in order to address changes in the business model
• Champion incremental changes into Serus applications in order to provide better results from the customer’s Serus solution
• Facilitate, assist and drive business change management.

Project Management

Project management services are concerned with providing in part or in whole the management services needed to ensure the availability and usefulness of a Serus solution.  These services are intended to assure the customer that the best project management techniques will be used by individual contributors and project leaders to manage the customer project.  These services range from providing project leadership to managing day-to-day administrative tasks.  Project management services include:

• Gather and communicate project requirements like:  outage windows, project organization, milestones, sub-projects, etc.
• Building, executing and monitoring tactical or strategic plans to improve the operating environments of the Serus solution or to meet customer requirements.
• Conduct project meetings and ensure the proper communications within the project team and with other teams
• Define track and report on service levels and/or key performance indicators.
• Report in projects and Serus solution status.
• Coordinate and allocate assigned resources.
• Conduct quarterly audits of the project (by someone outside of the project team).

Change Management

Change management is concerned with managing and controlling changes to the Serus solution in the Development, Test, Staging and Production operating environments.  Change management services ensure customers that changes to their mission critical application will only be made in a safe and controlled manner.  Change management services include:

• Define and/or administer change management processes
• Scope, prioritize, schedule, communicate, and coordinate changes to the Serus solution.
• Make requisite changes to the Serus solution
• Ensure initial configuration documents for the Serus solution are provided and updated as necessary for each change request
• Regular reporting on change request status

Application Services

Application Management Services are concerned with the typical day-to-day operation of Serus applications within a customer’s environment.  These are essential technical services that are required to properly support mission critical enterprise solutions.  Improper management of such applications can negatively impact the availability, performance, and scalability of the solution.

An enterprise-class business solution consists of a variety of applications that must be managed in a coordinated fashion to ensure proper operation and availability.  Because of the extensive number of technical tasks needed to manage an enterprise solution, Application Management Services are divided into the following categories:

• Capacity Planning and Systems Management
• Serus Applications
• Enterprise Application Integration Management
• Third-Party Software

Specific functions performed by the Application Services team include:

• 24×7 application monitoring / trouble shooting
• 24×7 supplier b2b monitoring / troubleshooting
• 24×7 supplier txn monitoring / troubleshooting
• 24×7 txn processing monitoring / troubleshooting
• High performance it system consulting services
• Upgrade and patch management services
• RDBMS performance monitoring and tuning

Capacity Planning

System Architecture and capacity planning services are concerned with the performance, scalability, reliability and availability of Serus solutions in the customer’s environments.  System architecture services are focused on how the server environments may need to be changed to achieve the customer’s objectives for availability and performance.  Capacity planning services are focused on how the server environments may need to be augmented in order to achieve the customer’s objectives for future scalability.  These services include:

• Periodic review of application performance to identify performance or capacity limiting resource constraints
• Recommend, design and implement system architectures to increase availability or performance
• Forecast storage for models and transactions
• Given appropriate benchmark data, forecast server capacity requirements over time
• Hold formal capacity evaluations based on forecasted volumes

Systems Management

Systems Management Services are concerned with providing services to manage a set of servers and their underlying network.  Through partners, Serus can provide a wide range of system management services for Serus solutions, in either an in-house or hosted environment.  System management coupled with Serus Basic Managed Services delivers a fully managed solution.  System Management services are broken out into the following categories:

• Process management
• Hardware management
• OS management
• System Monitoring
• Security management
• Network management
• Physical database management
• Storage management

Serus Application Management

These services are concerned with the operation and technical configuration of Serus applications within a solution.  These services include:

• Create or change application user profiles or user permissions
• Define processes and procedures for solution startup, shutdown or restart
• Maintain Serus application configuration files
• Restore and verify application to functioning state after backup or outage
• Install product patches or minor releases
• Manage application log files and directory structures and disk space usage
• Test system integration of Serus applications with third-party software patches
• Define, write, debug and/or support automation scripts or custom programs for batch processes, application startup, application shutdown, and application re-start
• Automate generation of specialized reports

Enterprise Application Integration Management

EAI management services are needed to support the integration between the Serus solution and other corporate, legacy or ERP systems.  Application integration may be provided using ad hoc techniques or by using industry standard tools.  The services provided include:

• Define and/or maintain job schedules
• Using scripts or integration software, execute and check data extracts and/or data loads from/to legacy and/or Serus systems
• Resolve problems with data mappings
• Extend or enhance data mappings
• Maintain documents describing data mappings and how to verify correct operation of data mappings

Third-Party Software

There is a wide array of third-party software that is required to support any enterprise class solution.  Such software includes database servers, web servers, application servers, LDAP servers, policy servers, etc.  Third party software services are concerned with the operation and technical configuration and maintenance of these applications.  These services include:

• Logical database management
• Design and deploy highly available database configurations
• Provide detailed schema and database configuration documentation
• Provide monthly reviews of database monitoring and performance reports and make specific recommendations for database modification to optimize Serus application performance
• Verify database business function after restore
• Assist in the development and implementation of disaster recovery plans
• Tune configuration, log file analysis, configuration changes
• Archive web server log files for troubleshooting, analysis or tuning purposes
• Tune web server configuration and recommend OS/network parameters
• Periodically analyze web server log files and report on application usage
• Specify, implement and test highly available web server configuration as agreed upon.
• Implement recycling schedules for log files
• Tune application server thread, memory, etc. settings
• Design, implement and maintain highly available application server configuration, as agreed upon.

Application Monitoring

Application Monitoring services are focused on monitoring the availability of the Serus solution at an application level, and detecting problems that arise in its operating environment.  Application Monitoring is an important service that provides the customer with the peace of mind that any interruptions to their business process will be detected and remedied before any damage can occur.

Automated Application Monitoring

Automated application monitoring goes beyond any server and network monitoring.  It will detect problems like applications hanging that cannot be detected by server or network monitoring.  Application monitoring is accomplished by up/down monitoring of selected Serus and/or third party applications critical to the proper functioning of the Serus solution.  These services include:

• Define customer’s application monitoring requirements
• Design, implement and maintain monitoring points needed to meet customer requirements
• Provision, setup and maintain monitoring tools and infrastructure
• Generate reports of alerts on a monthly basis

Operator Monitoring

Operator Monitoring involves a human operator overseeing the operation of Serus solutions.  It is for mission-critical environments that require immediate intervention in the event that a component fails or is delayed.  Operator Monitoring services include:

• Monitoring scheduled jobs within the production environment and taking corrective action when necessary.

Upgrade Services

Upgrade services are used to take an existing Serus deployment and upgrade that deployment to a later version of Serus product(s).  Upgrade services are very similar to implementation services, except that the existing business process and business model do not need to be designed.

Like implementation services, upgrade services are outside the scope of Serus Managed Services.  If there is an existing or new managed services team, they may assist the upgrade efforts, but only in the context of providing managed services to the customer.

Support Services

Support Services focus on Serus component and solution validation within the maintenance phase of Serus solution support.  These services cover all facets of quality management from customer education and training to solution test suite development, test suite maintenance and execution, and test case automation.  These services provide the resources, tools, and methods needed to validate and ensure the quality of Serus solutions within the customer environment.

These services ensure that the customer solution is fully tested using industry standard tools and proven methodologies to support on-going solution maintenance activities.  Selected test suite deliverables will be brought into the Serus solution test suites for upstream validation as part of the Serus Quality Management Program.

• 24×7 helpdesk services
• Application training

Support Services include:

• Provide custom training for regular and “super users” so they are more effective in their use of the Serus solution
• Conduct on-site workshop to educate customers about test plans, acceptance criteria, and associated impacts
• Review acceptance criteria and ensure that they cover all major components of the solution design.  Major components should include:  UI workflows, model functionality, integration, and performance-scalability-reliability elements.
• Maintain test suites by adding, modifying or consolidating test plans to cover acceptance criteria.
• Establish standard test execution reports
• Conduct training for end-users to maintain test suites and associated tools
• Execute acceptance tests using reference data sets prior to promoting any releases (major, minor or patches) to production.
• Submit and monitor Serus Support Cases related to issues found during customer test management activities and acceptance test execution.

End User Help Desk

End user help desk services provide customer branded, help desk services to all of the end users of a Serus solution, including internal end users as well as trading partner end users.  Serus-provided help desk services will not be needed for customers with a well established, corporate-wide help desk.  However, Serus help desk services are appropriate when there is not an existing corporate help desk, or when a help desk that can be used across firewalls is needed.  Help desk services include:

• Provides a reliable and centralized single point of contact for all end-user issues
• Author and maintain basic FAQs on the solutions
• Provide basic information on how to use the applications in the Serus solution
• Verify and replicate user interface issues
• Provide issue reports on a monthly basis
• Create and manage user profiles for the help desk system
• Modify part attributes, item numbers, prices, etc.

Problem Escalation and Management

Problem management is concerned with the identification, diagnosis and resolution of unanticipated problems that arise in the operating environment(s) of a Serus solution.  Problem management services are ensure that problems will be resolved in a timely and organized fashion, and provides the customer with escalation paths should they not be satisfied with the status of or resolution of a particular problem.  Depending on severity, problem management is conducted 7×24 in a production environment and 8×5 in all others.  Problem management includes:

• Define and/or follow problem management processes.
• Logging and/or acknowledgement of receipt of a problem and assignment to a member of the Serus Managed Services team to resolve the issue.
• Triage of a problem to determine if it is to be corrected by the Serus Support team, or routed to another Serus team or third-party.
• Keep the reporter of the problem updated on the status of a problem as appropriate, depending on problem severity.
• After resolution of the problem, provide root cause analysis indicating how the problem was resolved, or otherwise isolated to sources outside the scope of the Serus solution.

Excluded Services

There are several service areas that are explicitly excluded from the set of services provided by Serus Managed Services. 

Customer Support

Serus offers customers maintenance support to assist with problems they may encounter with their Serus solution, and to provide development support for resolving application defects.  Escalation procedures exist for escalating serious issues encountered by the customer.  Maintenance support entitles the customer to hot fixes, patches and ongoing software updates for all products that a customer has licensed.  These patches and releases do not include fixes for a particular customer, but fixes for issues encountered by other customers.  These support and development services can be so important that maintenance support is mandatory for the first year.

Problems a customer may encounter include:  modeling issues, product defects, user misunderstandings, environment problems, solution configuration issues, performance issues, etc.  If after a reasonable effort a customer cannot identify the source or cause of a problem, the customer can escalate the issue to Serus customer support.

Serus customer support provides services for Serus applications, and any third-party software bundled with these applications.  Customer support provides services to:

• Answer questions on how to use (or not use) functionality in the application
• Help determine if the cause of a problem lies in the application, in the customer’s environment or customizations for the Serus application, or is a user misunderstanding.
• For Serus application problems, verify the problem and communicate the problem to Serus development, so that Serus development may resolve the issue and provide a fix to the customer.

Customer support services are provided to assist the customer with questions and issues about their Serus solutions and with development to provide product fixes and patches.

It is the sole responsibility of the customer to operate, fix, and manage their solutions.  The Serus Managed Services program allows a customer to delegate management and operation of their Serus solution to an organization that is exclusively focused on managing Serus solutions.

On the other hand, Customer Support services are intended to assist the customer and entitle the customer to development support, patches, and new releases.

Tasks falling under the purview of Serus Managed Operations Services are customer responsibilities that have been delegated to a Serus Managed Services team.

Customer Support is an organization that assists customers and facilitates escalating product issues to development.

Deployment and Integration Services

Once the customer buys one or more Serus products, deployment and configuration to model the customer’s business environment is necessary.  Designing, building and deploying Serus solutions are outside the scope of the services provided by Serus Managed Operations Services.  If there is an existing managed operations services team working for the customer, this team may assist the deployment team, but only in the context of providing the managed services to the customer (e.g., IT environment promotion services).

Today I saw the following interesting post by Timo Elliott on the transition from business automation to business optimization.  He made the following point:

The last decade has been about automating business processes. The next decade will be about building business-centric applications. For the first time, organizations will have the opportunity to apply a systems approach to best-practice use of information across the organization as a whole, by synchronizing the two key components of corporate performance improvement: operational excellence and strategic change.

The posting goes on to discuss the combinations of ERP and BI companies that have occurred recently.