Solomon Stands the Test of Time Despite Changing Masters Part Three: Product Differentiators

Furthermore, as mentioned earlier, MBS Solomon offers several series or groups of integrated modules that address different business types and needs. This modularity has the advantage of allowing the prospects to start frugally with only necessary base modules (e.g., accounting) and to incrementally add more functionality as needs demand and budgets permit, without the complexities of switching accounting application vendors or converting databases.

Of all the MBS' products, Solomon is apparently the purest in terms of a standard Microsoft technology stack, and without any proprietary additions (such as Great Plains original Dexterity environment, Navision's proprietary integrated development environment C/SIDE, which includes a proprietary Navision Server database and a proprietary 4GL programming language; Navision strong analytical features using Sum Indexed Flow Technology (SIFT); and the proprietary MorphX graphical development suite for Axapta). It is also a single-code product, with the same look and feel for both small and midsize customers, which has long differentiated the product from its competitors and MBS siblings (e.g., MBS Great Plains vs. Dynamics, Epicor Vista vs. Vantage, Best Software Peachtree vs. MAS 200, etc.) that currently offer separate products for the lower and upper ends of the mid-market. MBS Solomon Standard, a lower-priced offering of the Solomon edition that addresses the needs of lower mid-market enterprises with smaller information technology (IT) budgets and less-complex business structures (e.g., fewer companies or fewer divisions) that have twenty-five to ninety-nine employees, annual revenues of $25 million (U.S.) or less, and up to ten licensed users.

Furthermore, its sharp focus solely on Microsoft technology from the ground up, coined in "the power of one" motto (one OS platform—Windows XP/NT/2000, one database platform—MS SQL Server, one development environment—MS Visual Basic, etc.), also presents an attractive, risk-adverse option for penny-pinching mid-market customers. Solomon IV has consequently been very competitive in speed of implementation (from only two weeks to four months duration), feasibility of customization, total cost of ownership (TCO), and price/performance ratio. The product architecture has been devised entirely from scratch within the Microsoft context, which provides for flexibility and ongoing agility.

While its former and current competitors, particularly Sage (Best Software's UK-based parent company) and Great Plains, may have a more extensive partner channel within the industry, Solomon's indirect channel is more nimble and focused. This is due to its single-code product portfolio that reduces the deployment and support requirements for its entire market segment. In addition the former Solomon had supplemented its over 500 VARs through its above-mentioned STC network, which would provide for global service consistency and additional leverage for the channel.

Financial Series

At the heart of MBS Solomon is the Financial Series, which is made up of typical accounting and financial applications such as General Ledger (GL), Accounts Payable (AP), Accounts Receivable (AR), Cash Manager, Currency Manager, Multi-Company, Financial Statement Translation (FST), FRx Reporting andd Payroll/Direct Deposit. GL account and sub-account numbers can be up to thirty characters in length, whereby the main account number can be up to ten characters, and the remaining twenty characters can include up to eight user-defined segments. GL transactions can be entered using several types of transaction batches, including non-recurring, recurring, manual and one-sided adjustment, and GL account determines whether the transaction will operate in multi- or single-company mode. Transactions can be entered for any prior fiscal period or year as well as for future periods, which allows for things such as installments and prepayments to be managed at a single time, rather than month after month. The Financial Statement Translation module is compliant with Financial Accounting Standards Board (FASB) Statement 52, Foreign Currency Translation, and International Accounting Standard Board (IASB) Statement 125. The module supports translations from one set of books to another set of books, and supports multi-tier translations and consolidations.

Solomon Stands the Test of Time Despite Changing Masters Part Two: Market Impact

Still, due to its quite belated expansion into the ERP world (let alone extended-ERP), the vendor had suffered the reputation of a best-of-breed accounting software provider only. While former Solomon had accelerated its delivery schedule of new functionality, it was also hard pressed with tight "time-to-market" constraints and limited resources at the time. The following intended functionality delivery schedule in 2000 would have been a tall order for even much more resource abundant competitors, given that some of these have seen the daylight only within the above-mentioned releases within Great Plains and MBS, well after 2000—repetitive build and MRP modules within the Manufacturing Series (yet to be released natively); replenishing, commissions, and shipments modules within the Distribution Series; employee utilization and time and billing within the Project Series; additional e-business functionality like eVoucher; and Solomon Object Model within the System Tools suite.

However, given that all is well that ends well, MBS Solomon, due to its distinct differentiators (e.g., project management, advanced distribution, and field service capabilities, the product flexibility, having integrated but modular applications, powerful reporting capabilities, multi-company accounting features, etc.) and weaknesses (e.g., rudimentary manufacturing functionality), has been blessed in disguise with possibly the most distinct niche and the least overlap (gray area) with the other MBS ERP products (i.e., MBS Great Plains, MBS Navision, and MBS Axapta). Indeed, MBS Solomon remains the choice for organizations that seek flexible financial systems, integrated with distribution, project, or service operations. The strongest customer base thus comes from construction—special trade contractors, wholesale distribution—durable goods, business services, engineering, accounting, research, and management service organizations.

Solomon Stands the Test of Time Despite Changing Masters

Microsoft Business Solutions Solomon, formerly Solomon IV and Microsoft Great Plains Solomon IV, a prominent business management and e-business suite of applications for small and mid-market companies, and the product that some had prematurely written off after being acquired first by one of its erstwhile greatest nemeses, former Great Plains Software in 2000 (see Will Solomon Finally Satisfy Great Plains' Insatiable Appetite?), and particularly after its new owner subsequently ended up under Microsoft's roof in 2001 (see Microsoft And Great Plains — A Friendship That Turned Into A Marriage), only soon after to share the fraternity home with yet another former nemesis, Navision in 2002 (see Microsoft 'The Great' Poised To Conquer Mid-Market, Once and Again), seems to be doing just fine, if not even much better than that. It appears that the product has several truly differentiating traits, which cannot be easily or quickly replicated by its seemingly more robust brethren products within Microsoft Business Solutions (MBS) division. Thus, Microsoft has reason to continue to bolster the product for Solomon's loyal customer base and resellers instead of promoting less popular options (e.g., stabilization and replacement).

Most recently, in summer 2003, Microsoft Business Solutions (MBS) announced the availability of Microsoft Business Solutions Solomon 5.5, which includes several new features and enhancements in the product's Foundation Series, Financial Series, Project Series, and Service Series of modules. Owing to the product's renowned sweet spot of project accounting, MBS has further developed Solomon 5.5 to meet the needs of small to midsize project-driven organizations, specifically in the industries of business services, management and engineering services, social services, special trades contracting, general contractors, and wholesale trade (durable goods). To that end, Solomon 5.5 includes Microsoft Business Solutions Professional Services Automation (MBS PSA) product features that combine the power of MBS Project Accounting Solomon and the new enterprise version of Microsoft Project 2002 to provide externally focused, project-driven organizations with an integrated financial, project and resource management, knowledge management, time and expense, project accounting, financials, and reporting and analytics solution, based on the Microsoft .NET platform. Additional enhancements to the project accounting capabilities include new indirect rate calculation and new audit trail tracking abilities for contractors of the US federal government, particularly those subject to Defense Contract Audit Agency (DCAA) audits.

The MBS PSA vertical solution became generally available in North America at the end of 2002, following its quite vocal announcement during the Stampede 2002 partner conference (see Microsoft Lays Enforced-Concrete Foundation For Its Business Solutions).

Reflections on Lean Philosophy and the Theory of Constraints

This is Part Seven of a multipart note entitled Lean Manufacturing: A Primer.

For these reasons, a TOC production planning solution might be appropriate for manufacturers with make-to-order (MTO) environments, where demand is volatile and where different product lines share the same resources, resulting in bottlenecks. It could also be used for mixed mode manufacturing. In fact, by offering daily production planning for customer orders received, TOC enables business performance improvements in such environments in terms of lead time or cycle time reductions, increased throughput and sales, service level improvements, and inventory level reductions.

Thus, despite the fact that many people immediately invoke a vision of kanban when lean manufacturing is mentioned, TOC supports a lean philosophy where there is a complex environment. However, where lean planning focuses on the flow and the takt of the flow through the factory, TOC optimizes the flow through the factory by focusing on planning the takt of the flow through the bottleneck. TOC is also consistent with lean manufacturing in that both kanban, which is a part of the just-in-time (JIT) philosophy, and drum-buffer-rope (DBR), which is a part of the TOC philosophy, represent synchronized and pull signal production control approaches.

For an exhaustive discussion of lean manufacturing in previous notes, see Lean Manufacturing: A Primer, Lean Tools and Practices that Eliminate Manufacturing Waste, How to Achieve Lean Manufacturing, Manual versus Information Technology Enabled Lean Manufacturing, Enterprise Resource Planning Vendors Address Lean Manufacturing, and The Theory of Constraints Enters the Lean Manufacturing Arena.

The TOC Vernacular

More similarities between TOC and lean can be extracted by analyzing some TOC definitions. For example, in the TOC lingo, throughput is the rate at which the system generates money through sales. In other words, throughput is production that can be invoiced—only monetized sales generated by the system get counted. Building inventory (just for the sake of stocking up), on the other hand, is not throughput in TOC terms. This is consistent with lean manufacturing's focus on the customer and customer value-adding activities. Another example is TOC's definition of inventory, which includes all investments in procuring materials to meet customer demand, such as raw materials, work-in-process (WIP), finished goods, and scrap. The crucial point, however, is that, according to TOC, inventory is a liability and certainly not an asset. This is consistent with lean manufacturing's focus on eliminating waste. Finally, TOC's definition of operating expenses encompasses all the money the system spends to turn inventory into throughput, such as all employee time, depreciation, etc. Therefore, TOC focuses on increasing throughput, while reducing inventory and lowering operating expenses. A TOC cost and managerial accounting system thus logically accumulates costs and revenues into these three areas.

The TOC accounting system is somewhat similar to activity-based costing (ABC), since it does not create incentives (through allocation of overhead) to build up inventory. It is considered to provide a truer reflection of actual revenues and costs than traditional cost accounting. Since it is closer to a cash flow concept of income, TOC accounting provides a simplified and more accurate form of direct costing, one that subtracts true variable costs (those costs that vary with throughput quantity). Also unlike traditional cost accounting systems, in which the focus is generally placed on reducing costs in all the various accounts, the primary focus of TOC accounting is on aggressively exploiting constraints to make more money for the firm. Similarly, TOC's goal is to maximize throughput on the bottleneck, which is equal to the profit, since, according to Goldratt et al's 1984 blockbuster business novel, The Goal, "an hour lost on the bottleneck is lost forever and an hour saved on a non-bottleneck is a mirage."
In practice, TOC is implemented by following the subsequent five straightforward steps.

1. Identify the constraints. This should not be too difficult, since large piles of WIP are very noticeable, and every plant supervisor should know intimately the sore spot or bottleneck within the plant.

2. Exploit the constraint. One has to maximize the possible amount of work going though the constraint, while ensuring that there is an uninterrupted flow of work coming into the constraint, so that it never has to wait for work (i.e., an inventory buffer is kept in front of the bottleneck to ensure that it is never idle).

3. Subordinate everything else to the constraint. Since the efficiency at other resources does not really matter, there is no point in upstream work centers producing more work than the constraint can absorb. It is sufficient to provide an indication of the task priority of other non-bottleneck resources, since the utilization of non-bottlenecks is determined by the critical bottleneck.

4. Elevate the constraint. If possible, increase the capacity of the constraint by offloading some work, subcontracting work, adding more capacity (by buying more machine, adding another shift, etc.), and so on. 5. Repeat the entire process for continuous improvement. This is another similarity with the lean philosophy. It is likely that elevating the constraint will stop it from being a constraint, but a new constraint will come to light. One then has to exploit, subordinate, and elevate this new constraint.

DBR Explained

The DBR process is used within TOC to manage resources in order to maximize throughput. In simplified terms, throughput becomes the critical index of production performance. The barrier to maximum throughput is typically thwarted by a single capacity-constrained resource (CCR), or bottleneck, so the focus is on maximizing utilization of that bottleneck.

The term drum-buffer-rope encapsulates the main concepts of DBR. The drum refers to the rate or pace of production set by the system's constraint. The buffers establish protection against uncertainty (e.g., machine breakdowns, material shortages, labor problems, etc.), so that the system can maximize throughput. The rope is a communication process from the constraint to the gating operation that checks or limits material released into the system to support the constraint (i.e., a sort of a pull system, which is yet another similarity with lean).

In TOC, the constraint is viewed as a drum, and non-constraints are, according to Dr Eliyahu Goldratt, like soldiers in an army who march in unison to the drumbeat—that is all the resources in a plant should perform in unison with the drumbeat set by the constraint. In this regard, one should note that the system constraint may be either internal or external. In fact, Infor reveals that the vast majority of its customers who have implemented the lean and TOC approach have discovered, once the work flow has been corrected, that the market becomes the constraint. Other constraints to throughput include resources, materials, and, most insidiously, management.

Thus, DBR begins by identifying a critical bottleneck, which is the strategic drum or synchronous control point. The drum schedule for the plant, which sets the pace for the entire system, must reconcile customer requirements with the system's constraints. Other resources may be a temporary bottleneck for a short period depending on the order mix. Market pull is scheduled on the drum, and material is released onto the floor at the rate that the drum can operate. This rate is the rope, which consists of the minimum set of instructions to ensure that non-constraint resources are used (and not over-activated or misallocated). Material is consequently released into the system and flows to the buffers in a way that supports the planned overall system throughput. In fact, material release occurs a set buffer time ahead of demand, so that some buffer physical inventory (but not too much) is present at the drum resource to guarantee its performance in order to plan against uncertainty. In TOC, buffers can be either time or material to support throughput or due date performance. They can be maintained at the constraint, convergent points (with a constraint part), divergent points, and shipping points.
Enterprise systems come in handy when calculating complex TOC algorithms, such as, for example, defining the planned start and stop time per order down to the minute, or determining the production rate for the entire factory. A system such as Infor's Easy Lean/DBR system can manage internal constraints, time buffers, and replenishment or kanban buffers. Users can thereby execute operations on the bottleneck according to the planned start time. In addition, the priority on each operation and remaining buffer levels can be visualized—the earliest start time of the buffer indicates how realistic the plan is, while the remaining buffer controls execution priority depending on when it is planned on the bottleneck. As with kanbans, the rule of thumb is to start with a large buffer size and keep reducing it until one has a smooth flow, since the smaller the buffer sizes, the shorter the lead times and the faster the production flow.

When it comes to the execution on non-bottleneck resources, this can be done by indicating the remaining buffer in the system using red, yellow, and green buffer flags. Red flags indicate the highest priority tasks that should be focused on, while yellow designates less critical tasks, and green denotes tasks that are in the buffer and thus still in "good shape". Operators use these flags to execute tasks according to the priority level, rather than according to a defined order sequence and specific times as in material requirements planning (MRP) or advanced planning and scheduling (APS) systems. This gives operators more flexibility and the ability to make some decisions about which task to execute next. This can increase the motivation level, and is in tune with lean philosophy's employee empowerment mantra.

Yet another thing that differentiates TOC systems is the fact that, since inventory is only held in front of the critical bottleneck, it is normal for the company to end up with significantly less inventory in a TOC system than when using MRP or JIT. WIP inventory is often lower than those of kanban systems because aggregating the buffers offers the same protection overall, while simultaneously reducing the amount of protection required. Shorter production cycle times also have a similar result.

The Theory of Constraints Enters the Lean Manufacturing Arena

Just as manufacturing realities are continuously changing, so is lean thinking evolving. For example, traditionally, given competitive realities, it was almost exclusively automotive companies that deployed lean techniques such as kanban and sequencing. Today, however, there are some strong indications that only one in five companies using kanban are in the automotive industry.

This is Part Six of a multi-part note.

Customarily, lean endeavors lead almost inevitably to flow manufacturing, focused factories, or cellular manufacturing. This is because a key focus of lean is to do only what is needed. It is the polar opposite of the traditional economies of scale, with their large batch approach and resulting long lead times and bloated inventory levels. Large lot sizes are a way of compensating for the fixed cost of a process, such as changeover or set-up costs, transaction-level costs (e.g., releasing orders, issuing parts, closing and reconciling orders, moving product batches into stocks, etc.), and other per order factors. With a large run, these costs can be distributed over a larger number of units, and thus become a smaller cost on a per piece basis. As long as changeover costs are high, small lot quantities are not cost efficient or justifiable. The obvious solution, then, is to lower or eliminate these fixed costs as much as possible so that smaller runs become feasible.

It is this type of thinking that results in production lines that are designed so that there is little or no cost to change from one product to another. This means that a lot size of one (or only a few) is as economical as a large lot on less efficient, non-lean premises. But to achieve this, it is often necessary to restrict the range or variety of product processed in a given cell. Thus, despite those who proclaim that flow manufacturing principles can be implemented successfully regardless of the industry, type of manufacturing environment, or product volumes, the concept has not been all things to all people so far. There are many instances where either flow manufacturing is not appropriate or it is simply not affordable for companies to rearrange their facilities to accommodate the convenient movement of work from one resource to the other.

In fact, manufacturers need to do quite a lot of preliminary work, such as adapting their plants to a flow production model, before even thinking about deploying demand-driven manufacturing software. In other words, they will have to operate in work cells that build families of products, rather than in functional work centers that produce large batches of components or products. They will also need established rules for sending replenishment signals to their internal (i.e., preceding work station) and external suppliers. By establishing time-based process families (and techniques similar to pitch) and monitoring resource loads routinely, there could be a relatively rapid and significant reduction in manufacturing cycle time and a corresponding improvement in delivery performance and productivity, even in job shop environments. Still, these changes will not happen overnight, and the process should begin with the conversion of a few appropriate products with relatively simple production processes, and then progress to other product lines. The implementation of such changes explains why many manufacturers happen to be in a hybrid production mode, with part of the plant running according to flow principles and the rest using traditional material requirements planning (MRP) methods.

For some companies, however, there is simply not enough product similarity to make even this practical. It is challenging or even unsuitable to deploy flow or cells in a job shop that makes highly configured-to-order (CTO) or engineered-to-order (ETO) products with high setup times and long lead times. These companies might still appreciate kanban replenishment and demand smoothing, but not line design and standard operation procedures (SOP) or operation method sheets (OMS), since these features would not bring much benefit, if any, to ETO manufacturers. However, such companies' product families often include products that require one or two unique and expensive components in addition of their share of common parts, which could benefit from flow methods of smoothing spikes in demand.

In fact, with appropriate changes in workflow management and the appropriate software to help manage the approach, even companies operating in particularly complex environments can realize significant benefits. For instance, smaller make-to-order (MTO) companies, those that make large or complex products in small quantities or one-at-a-time, and those unwilling or unable to rearrange the plant for flow manufacturing should still be able to reap the primary lean benefits of smaller lots, shorter lead times, reduced inventory and work-in-process (WIP), and higher quality. Infor, for example, claims that dozens of its customers, operating in a similar environment, have had significant improvements in performance and profitability within two or three months. As long as management buys in, the methods and the tools are available. There is some relativism to be considered, however, since the improvements may not be on par with those obtained by high volume, repetitive manufacturers. Nonetheless, relative to industry competition, results could be quite impressive.

In a nutshell, flow systems cannot handle demand variability, variable product mix, shared resource constraints, or complex products with long lead times. This limits flow's applicability to items where variability is only at the end item mix, and not with frequent content variations of option mixes. For this reason, as well as all the above reasons, most manufacturers implement this method gradually and use flow manufacturing to make one product family at the time. This necessitates the use of enterprise resource planning (ERP), MRP, or advanced planning and scheduling (APS) for the rest of the business (see Best Manufacturing Scheduling Systems).
While flow manufacturing may have limits in terms of the complexity it can handle, MRP is not without its drawbacks either. MRP is a set of techniques that uses bills of material (BOM) data, inventory data, and the master production schedule (MPS) to calculate requirements for materials so as to make recommendations to release replenishment orders for materials. Because MRP is time-phased, it makes recommendations to reschedule open orders even when due dates and need dates are not in phase. MRP will, by default, create orders with specific due dates for products. Consequently, to manufacture these orders, companies prioritize resources based on these calculated due dates. The unfortunate result is that other orders, perhaps more important orders, are neglected, which often leads to overtime in the factory. Therefore, slack needs to be built into the schedule through conservative, often unjustifiably pessimistic lead times.

Combined with information from actual customer orders, MRP is still the tool most widely used in manufacturing industries to track, monitor, and order the volumes of components needed to make a certain product. However, for the above reasons, many manufacturing environments have discovered that MRP has trouble controlling stock levels, which results in poor delivery performance.

Moreover, MRP is incapable of handling demand-driven, ever-changing manufacturing, since it works especially well when demand for a particular product is constant and predictable. If there is any variation in demand, however, MRP loses many of its advantages and the benefits of using alternative planning approaches increase. In fact, the main flaw with MRP is that it is too deterministic—it does not allow for the natural variation that occurs in real life (e.g., people get sick or go on strike, trucks or shipments get delayed, machines malfunction, quality issues require scrap or rework, and customers do not always, if ever, order according to forecasts). In other words, MRP is a static model of a stochastic reality. Manufacturing requirements change all the time, according to customer orders, available parts, and so on; thus, MRP attempts to apply a high degree of precision to something that is inherently imprecise.

However, Just-in-time, Lean, and Flow Are Not Universal Panaceas

The challenge in using lean and flow manufacturing as a panacea for the shortcomings of MRP is often in setting the number of kanban cards in the system and the size of the kanban. Even with a help of computerized systems, this can become complex if the demand for each product varies significantly and the production layout is not line- or cell-based.

The just-in-time (JIT) approach normally begins with limiting inventory in the system using a two-bin kanban method. This prevents the shop floor from being flooded with inventory and WIP, and the result is shorter production cycle times and improved inventory control. With JIT, production planning centers efforts on takt time, and the result is that production volumes are determined by the market rate of pull. Process improvement is achieved by gradually reducing kanban size and monitoring decreased inventory, but JIT is useful mainly where demand is relatively stable and there is single-piece flow production feasibility.

In more of a job shop environment, however, the kanban JIT approach no longer makes sense, since the product mix by product type, routings, and process times becomes widely divergent, causing the prediction of kanban sizes to be impractical and temporary, or wandering bottlenecks to appear all over the shop floor. Indeed, where the order mix changes or not all resources are dedicated to lean flow manufacturing, then kanban sizes must continuously be reevaluated. In these situations, a theory of constraints (TOC) approach is often more appropriate.

Manual versus Information Technology Enabled Lean Manufacturing

This is Part Four of a multipart note.

The trouble is further compounded by the army of software providers (including enterprise resource planning [ERP], supply chain management [SCM], manufacturing execution systems [MES], and product lifecycle management [PLM] providers, as well as best-of-breed, bolt-on lean specialists) that have been hyping their lean capabilities, despite the fact that most of them still support mere nuggets of pseudo-just-in-time (JIT) ways of accommodating mass customization. Providing only support for kanbans, order-less repetitive scheduling, or vendor managed inventory (VMI) or supermarkets, so as to push inventory elsewhere (e.g., onto suppliers) rather than to reduce it across the entire supply chain, is a far cry from true support for lean or demand-driven manufacturing. Where most of these flow manufacturing, lean ERP, or repetitive manufacturing systems fall short is that they have simply automated the most basic of tasks within a lean environment, without addressing larger issues of how to implement lean and pull practices in environments that are not easily amenable to these.

Then again, some people question whether computer systems are even needed for achieving lean manufacturing. After all, some lean tools entail merely physical processes and best practices on the shop floor, where transactional enterprise systems have little to offer. Also, given that computers were not widely available when lean manufacturing and kanbans first emerged, many enterprises have stuck with manually-driven lean methods. For such methods, an evolutionary step forward entails the use of custom spreadsheets and reports to support lean functions such as kanban management and heijunka calculations (see Lean and World Class Manufacturing and the Information Technology Dilemma—The Loss of Corporate Consciousness). It is interesting to note, however, that even in such cases, material requirements planninng (MRP) systems still can be used to hold core master data on items and bills of material (BOM), though these records have to be tweaked with an eye toward lead time-oriented information.
Some lean purists go even further, and believe that lean manufacturing does not mesh well with information technology (IT) systems. For some, the only appropriate technology is Microsoft Excel spreadsheets. Others claim that the best scheduling method is "no schedule at all", giving the lean enterprise the utmost agility to react to any unpredictable event. On the other extreme, many people have become so accustomed to the use of enterprise systems, that they believe we can no longer return to manual procedures (see Run your Business with No Software!).

As usual, the truth might be somewhere in a middle—lean manufacturing and IT are not in opposition, and all good lean systems have both physical systems in the plant and near real time IT backbones that centralize data, especially if there is an automatic data entry and capture function. In fact, some people say that the whole point of the lean philosophy is to simplify the physical processes so that one does not need to manage overly complex data systems, though it is still necessary to manage the relevant data at the points where corrections are needed. To that end, many IT systems are designed to bring from the field only the data that management or decision-makers can do something about.

The reality is that most companies operate in a hybrid, mixed-mode environment where flow or lean and traditional batch or push manufacturing models coexist within the same facility, and where production and demand requirements can change throughout the different stages of a product's life cycle. Manufacturers can produce both high-volume goods with steady demand and low-volume goods with fluctuating demand, and their product mix may include engineer-to-order (ETO), make-to-order (MTO), and make-to-stock (MTS) items.

To successfully operate in this mixed-model environment, one has to take advantage of the strengths of each model and apply them where best suited. Thus, one should use traditional ERP systems for handling long lead-time items, one-of-a-kind production, and products with long production cycles, and for long-term budgeting and planning. On the other hand, lean manufacturing is often more easily applied to manufacturing operations with low-mix, high-volume, make-to-demand products. Moreover, one should not necessarily preclude pull-based execution processes from being implemented in to-order or highly configured operations, where it has also occasionally been done with great success.

Also, as lean spreads beyond the relatively stable manufacturing environment it was originally designed to support, companies realize that IT can play a vital role in streamlining the supply chain (see Moving Beyond Lean Manufacturing to a Lean Supply Chain). Namely, while the lean factory may use kanban pull signals to move product more efficiently through the manufacturing process and out of the door, it is missing the feedback loop from the factory to other functional departments within the organization or to the entire supply chain. That information is primarily transmitted and received via enterprise systems.
So, how can IT support lean manufacturing? For one, while complex packaged enterprise (ERP, SCM, etc.) systems may seem inconsistent with the simplicity of visual control, they actually work well together. In fact, although visual signals, such as kanbans and status indicator lights, are an effective way to trigger factory floor activities and the movement of materials, their inherent weakness is their lack of memory—visual signals cannot be recorded or tracked to determine historical performance or provide real time status for anyone that is not in direct view.

Yet, by coupling visual controls with real time collection of data from the factory floor, manufacturing enterprises should be able to capture the critical information behind the visual control signals for management oversight, planning, and accounting purposes. This information can be used for statistical analysis, to measure historical performance, and to monitor status—all of which are essential elements of the continuous improvement that lean manufacturing emphasizes. Lean aspiring manufacturers can also use enterprise systems to replace some visual controls, such as physical kanban card signals, with electronic ones, as a way to improve efficiency further and eliminate non-value adding activities.

Furthermore, these systems can play a critical role in establishing and ensuring standardized work. This is because they can serve as the central repository for critical engineering or product data management (PDM) information for standardized work, including BOMs, process routings or operations, valid product configurations, work instructions or SOPs, engineering change notices (ECN), schedule information, and costs. More robust solutions can even track as-designed, as-built, and historical actual product information, which can be analyzed to determine the impact that product changes have on efficiency and productivity.

Manual versus Information Technology Enabled Lean Manufacturing

It is easy enough to grasp the potential benefits of lean manufacturing (see Lean Manufacturing: A Primer, Lean Tools and Practices that Eliminate Manufacturing Waste, and How to Achieve Lean Manufacturing), but selecting the most appropriate lean techniques or tools and the accompanying packaged enterprise software for an individual enterprise has never been that simple. In fact, it is a major exercise for an enterprise to initially identify the most appropriate tools for eliminating different types of waste. For instance, overproduction could be mitigated by improved changeover times and balanced lines, whereas defects and rework could be curbed by improving visual controls, initiating more complete standard operation procedures (SOP) or operation method sheets (OMS), and implementing mistake proofing techniques at the source of error. Furthermore, waste of excessive inventory could be reduced by implementing kanbans and other similar pull systems, while waiting time could be handled by using takt times, and so on.

This is Part Four of a multipart note.

The trouble is further compounded by the army of software providers (including enterprise resource planning [ERP], supply chain management [SCM], manufacturing execution systems [MES], and product lifecycle management [PLM] providers, as well as best-of-breed, bolt-on lean specialists) that have been hyping their lean capabilities, despite the fact that most of them still support mere nuggets of pseudo-just-in-time (JIT) ways of accommodating mass customization. Providing only support for kanbans, order-less repetitive scheduling, or vendor managed inventory (VMI) or supermarkets, so as to push inventory elsewhere (e.g., onto suppliers) rather than to reduce it across the entire supply chain, is a far cry from true support for lean or demand-driven manufacturing. Where most of these flow manufacturing, lean ERP, or repetitive manufacturing systems fall short is that they have simply automated the most basic of tasks within a lean environment, without addressing larger issues of how to implement lean and pull practices in environments that are not easily amenable to these.

Then again, some people question whether computer systems are even needed for achieving lean manufacturing. After all, some lean tools entail merely physical processes and best practices on the shop floor, where transactional enterprise systems have little to offer. Also, given that computers were not widely available when lean manufacturing and kanbans first emerged, many enterprises have stuck with manually-driven lean methods. For such methods, an evolutionary step forward entails the use of custom spreadsheets and reports to support lean functions such as kanban management and heijunka calculations (see Lean and World Class Manufacturing and the Information Technology Dilemma—The Loss of Corporate Consciousness). It is interesting to note, however, that even in such cases, material requirements planninng (MRP) systems still can be used to hold core master data on items and bills of material (BOM), though these records have to be tweaked with an eye toward lead time-oriented information.
Some lean purists go even further, and believe that lean manufacturing does not mesh well with information technology (IT) systems. For some, the only appropriate technology is Microsoft Excel spreadsheets. Others claim that the best scheduling method is "no schedule at all", giving the lean enterprise the utmost agility to react to any unpredictable event. On the other extreme, many people have become so accustomed to the use of enterprise systems, that they believe we can no longer return to manual procedures (see Run your Business with No Software!).

As usual, the truth might be somewhere in a middle—lean manufacturing and IT are not in opposition, and all good lean systems have both physical systems in the plant and near real time IT backbones that centralize data, especially if there is an automatic data entry and capture function. In fact, some people say that the whole point of the lean philosophy is to simplify the physical processes so that one does not need to manage overly complex data systems, though it is still necessary to manage the relevant data at the points where corrections are needed. To that end, many IT systems are designed to bring from the field only the data that management or decision-makers can do something about.

The reality is that most companies operate in a hybrid, mixed-mode environment where flow or lean and traditional batch or push manufacturing models coexist within the same facility, and where production and demand requirements can change throughout the different stages of a product's life cycle. Manufacturers can produce both high-volume goods with steady demand and low-volume goods with fluctuating demand, and their product mix may include engineer-to-order (ETO), make-to-order (MTO), and make-to-stock (MTS) items.

To successfully operate in this mixed-model environment, one has to take advantage of the strengths of each model and apply them where best suited. Thus, one should use traditional ERP systems for handling long lead-time items, one-of-a-kind production, and products with long production cycles, and for long-term budgeting and planning. On the other hand, lean manufacturing is often more easily applied to manufacturing operations with low-mix, high-volume, make-to-demand products. Moreover, one should not necessarily preclude pull-based execution processes from being implemented in to-order or highly configured operations, where it has also occasionally been done with great success.

Also, as lean spreads beyond the relatively stable manufacturing environment it was originally designed to support, companies realize that IT can play a vital role in streamlining the supply chain (see Moving Beyond Lean Manufacturing to a Lean Supply Chain). Namely, while the lean factory may use kanban pull signals to move product more efficiently through the manufacturing process and out of the door, it is missing the feedback loop from the factory to other functional departments within the organization or to the entire supply chain. That information is primarily transmitted and received via enterprise systems.
So, how can IT support lean manufacturing? For one, while complex packaged enterprise (ERP, SCM, etc.) systems may seem inconsistent with the simplicity of visual control, they actually work well together. In fact, although visual signals, such as kanbans and status indicator lights, are an effective way to trigger factory floor activities and the movement of materials, their inherent weakness is their lack of memory—visual signals cannot be recorded or tracked to determine historical performance or provide real time status for anyone that is not in direct view.

Yet, by coupling visual controls with real time collection of data from the factory floor, manufacturing enterprises should be able to capture the critical information behind the visual control signals for management oversight, planning, and accounting purposes. This information can be used for statistical analysis, to measure historical performance, and to monitor status—all of which are essential elements of the continuous improvement that lean manufacturing emphasizes. Lean aspiring manufacturers can also use enterprise systems to replace some visual controls, such as physical kanban card signals, with electronic ones, as a way to improve efficiency further and eliminate non-value adding activities.

Furthermore, these systems can play a critical role in establishing and ensuring standardized work. This is because they can serve as the central repository for critical engineering or product data management (PDM) information for standardized work, including BOMs, process routings or operations, valid product configurations, work instructions or SOPs, engineering change notices (ECN), schedule information, and costs. More robust solutions can even track as-designed, as-built, and historical actual product information, which can be analyzed to determine the impact that product changes have on efficiency and productivity.