Joseph D. Blackburn

Reverse Supply Chains for Commercial Returns

The flow of product returns is becoming a significant concern for manufacturers. Typically, these returns have been viewed as a nuisance, resulting in reverse supply chains that are designed to minimize costs. These minimum cost reverse supply chains often do not consider product return speed. The longer it takes to retrieve a returned product, the lower the chances that there are financially attractive reuse options. Unlike forward supply chains, design strategies for reverse supply chains are unexplored and largely undocumented. The most influential product characteristic for reverse supply chain design is the marginal value of time. Responsive reverse supply chains are the appropriate choice when the marginal value of time for products is high, and efficient reverse supply chains are the proper choice when the marginal value of time for products is low. Product returns and their reverse supply chains represent a potential value stream and deserve as much attention as forward supply chains.

Time Value of Commercial Product Returns

Manufacturers and their distributors must cope with an increased flow of returned products from their customers. The value of commercial product returns, which we define as products returned for any reason within 90 days of sale, now exceeds

Improving speed and productivity of software development: a global survey of software developers

100 billion annually in the United States. Although the reverse supply chain of returned products represents a sizeable flow of potentially recoverable assets, only a relatively small fraction of the value is currently extracted by manufacturers; a large proportion of the product value erodes away because of long processing delays. Thus, there are significant opportunities to build competitive advantage from making the appropriate reverse supply chain design choices. In this paper, we present a network flow with delay models that includes the marginal value of time to identify the drivers of reverse supply chain design. We illustrate our approach with specific examples from two companies in different industries and then examine how industry clockspeed generally affects the choice between an efficient and a responsive returns network.

The impact of a rolling schedule in a multi-level MRP system

Time is an essential measure of performance in software development because time delays tend to fall directly to the bottom line. To address this issue, this research seeks to distinguish time-based software development practices: those managerial actions that result in faster development speed and higher productivity. This study is based upon a survey of software management practices in Western Europe and builds upon an earlier study we carried out in the United States and Japan (Integrated Manufacturing Systems, vol. 7, no. 2, 1996). We measure the extent to which managers in the USA, Japan and Europe differ in their management of software projects and also determine the tools, technology and practices that separate fast and slow developers in Western Europe.

Concurrent software engineering: prospects and pitfalls

Abstract This paper presents a cost performance comparison of different lot-sizing algorithms under multi-level rolling schedule conditions. Most multi-level studies have focused on fixed horizon problems, omitting an important characteristic of an operating MRP system. The results indicate that, under certain conditions, the computationally simple Silver-Meal heuristic provides lower lot-sizing costs than the Wagner-Whitin algorithm. In addition, cost modifications are introduced which greatly enhance the multi-level performance of these single-level lot-sizing heuristics.

Concurrent software development

Software development remains largely a sequential, time-consuming process. Concurrent engineering (CE) principles have been more widely adopted and with greater success in hardware development. In this paper, a methodology for marrying CE principles to software engineering, or concurrent software engineering (CSE), is proposed. CSE is defined as a management technique to reduce the time-to-market in product development through simultaneous performance of activities and processing of information. A hierarchy of concurrent software development activity is defined, ranging from the simplest (within stage) to the most complex (across products and platforms). The information support activities to support this activity hierarchy are also defined, along with two key linking concepts-synchronicity and architectural modularity. Principles of CSE are developed for each level in the activity hierarchy. Research findings that establish limitations to implementing CE are also discussed.

Simultaneous lot-sizing and capacity planning in multi-stage assembly processes

By necessity, software development has become a critical skill for many industrial firms. Software that captures the intellectual assets of the firm in its products and services increasingly defines the critical path in development and thus governs the firm’s speed-to-market. When embedded in hardware, such as with a television or an office copier, software can be a particularly strong determinant of development cycle time. What happens when software development exceeds its time targets and is late to market? One example, widely reported in the press, illustrates that dilatory software development can devastate the bottom line and affect the boardroom. In 1994, Novell purchased WordPerfect for over

Time and product variety competition in the book distribution industry

855 million in an effort to create an integrated software product to compete with Microsoft’s Office suite; Novell later sold WordPerfect (and Quattro) to Corel for

Offshore Remanufacturing with Variable Used Product Condition

186 million. What caused the calamitous 80% drop in market value? Simply Novell’s inability to keep apace with Microsoft in the race to bring new software features to market. Speed is obviously a key to retaining a competitive edge in these markets. Software productivity is another key development performance metric with direct financial consequences. Firms such as Microsoft recognize that software development is a fixed cost business with virtually no variable production costs; higher productivity thus results in lower input costs, and higher profit margins [6]. The twin objectives of speed and productivity raise vexing issues for a software development manager. Cycle time and productivity are not perfectly correlated because a developer can achieve a shorter cycle time even with low productivity, by adding developers to the project. Brooks [4] and others have noted that the practice of adding bodies to a project to lower cycle time may have the opposite result, since coordination complexities make larger teams more difficult to manage. With low productivity, speed is achieved at high cost. Fortunately, the pursuit of speed and productivity is not a zero-sum game. The

MULTI-ITEM LOTSIZING IN CAPACITATED MULTI-STAGE SERIAL SYSTEMS

Abstract This study has demonstrated the potential savings in expenses and capacity requirements that can be obtained through the use of modified values of the cost parameters in capacity constrained situations. Thus the findings from noncapacitated settings [6] are seen to extend to this situation as well. The results must be considered tentative at this time due to the limited experimentation. As mentioned earlier, however, the findings are consistent with studies which examined the unconstrained case and with the analytical results presented in Section 2. There are several directions for future research suggested by these results. First, to expand the experimental set examined in this study in order to test further the validity of the findings. Second, to examine the performance of the heuristics in a rolling schedule, capacity-constrained setting. While little work in this area has been done, previous research on the unconstrained, multi-stage lotsize problem has demonstrated significant differences in results between static and dynamic (a rolling schedule) environments (see [5] and [7]). A third direction for future research is to consider the multiple end-product (or arborescence) version of this problem.