Saturday, 23 May 2015

Big Bang vs Phased implementation

The phrases ‘big bang’ and ‘phased’ are used to describe ERP strategies for introducing new systems into an organisation. A ‘big bang ‘implementation is typically used to describe a go-live or cutover scenario where a business switches from their old ERP system to their new system at a single point in time. In contrast, a ‘phased’ approach describes a scenario where elements or modules of the ERP system are introduced in a planned sequence, replacing the old systems gradually.
Many factors need to be considered when deciding on a go-live strategy. For example:
·         Does the implementation cover a single site or multiple sites? A big bang implementation on a single site is considerably easier to manage than a simultaneous big bang across multiple sites. However interdependencies between sites could dictate that a phased approach isn’t viable.
·         Does the implementation cover a single business or multiple businesses? If multiple business units are involved then it might make sense to phase the implementation by trading company or business unit.
·         If a phased approach is adopted, what will this mean for integration between the new system and legacy systems during the interim period? This is potentially one of the most problematic areas for phased implementations. If you introduce the new system in a piecemeal fashion then you have to work out how the new system and old systems will work together for a period of time. This can involve creating interfaces that wouldn’t be needed if all modules were introduced at once, as well as creating user documentation and Standard Operating Procedures (SOPs) that cover how business processes operate in the interim period.
·         Are there any other competing business activities that need to be taken into account? Factors such as regulatory compliance, acquisitions, new product introductions and other capital expenditure programs can influence the required timescale for an ERP implementation.
·         What level of risk is acceptable? The generally held view is that big bang implementations have an inherently higher level of risk. This is because the integrated nature of ERP systems means that a failure in one part of the system can have knock-on effects elsewhere. The scope of a big bang implementation can also mean that full end-to-end system testing is difficult to achieve, and it’s only when the system goes live that all of the interdependencies are fully tested.
·         Which costs more – big bang or phased? Phased implementations typically take longer to fully complete; this generally means more time from both the ERP vendor and the project team and therefore increased costs. The additional time and cost has to be balanced against some of the main arguments used against the big bang approach, such as the ability of the business to cope with a huge level of change happening all at once as well as the increased risk of failure. Temporary interfaces between the new system and legacy systems can also increase the cost of a phased approach.
Both approaches have their advantages and disadvantages. However it’s important to point out that an implementation strategy doesn’t have to be limited to these two options. Sometimes a big bang approach can be used to implement ‘must have’ functionality within the core ERP modules, followed up with a phased implementation of ‘nice to have’ functionality and the implementation of non-core modules such as document management, business intelligence and maintenance management. 


MTS, MTO, ATO, CTO, ETO… Strategies to connect


The interface between the Sales and Production departments is a critical one. Very often the two departments work in silos. All strategies discussed here, are at the crossroads between demand and supply. It is a goal to be agile and fulfill every customers wish on time and on quantity, but it is also important to minimize waste and enable smooth replenishment and production. Proper use of the planning strategy helps achieving both goals.
A big problem, one that I encounter a lot, is that products are not optimally set up for either one of these strategies. Either the wrong assignment happens, or Production has a different idea than Sales, about what the product assignment should be. Additionally there is the need to periodically analyze the product portfolio because what’s MTO today might be MTS tomorrow.
The ultimate achievement, one that both Production and Sales strive for, is to have the right product at the right place in the right quantity at the right time. Planning strategies are one of the most important drivers to achieve exactly that.

Make To Stock Planning

When your product is a commodity that can be sold out of a catalog and is defined and specified through a master record, it can be planned; if it is somewhat predictable. A steady consumption in the past helps predicting the future, however, there may be events in the future which require a more forward-looking planning process.
In any case, if you can somewhat predict what will happen, you may consider a Make To Stock strategy. Even if it is hard to predict the future, but the customer does not accept long delivery times, you might be required to make some of your product to stock.
Making to stock means production without actual requirements. The Sales Order does not drive the production program but the forecast does. Incoming Sales Orders use existing inventory for the delivery which keeps the customer lead time to a minimum.
Once your product is identified as a ‘Make To Stock’ the availability check in the Sales Order must look for inventory and not place additional load in the production program. If there is no stock your service level degrades and the customer needs to wait for the next receipt from production.
Disconnect between Sales and Production #1: the “customer is king” paradigm does not have any validity in an MTS scenario. If you want to make the customer the king you need to make your product to that customer’s order.

Make To Order Production

This strategy still is for standard products which have a clearly defined specification. Other than MTS, there is absolutely no forecast on products which are made to an order from a customer. You start production after the customer’s request comes in and not, like with MTS, beforehand.
When you identify a product to be made to order, the availability check in the Sales Order needs a lead time; the time it takes to replenish or produce the product from soup to nuts. Therefore when a customer requests the item, no freely available stock to fulfill the order can be found. Everything is made from scratch and takes its time.
Disconnect between Sales and Production #2: You cannot plan for a 100% (or more!) utilization on the production line and allow for the free flow of orders, which were set to MTO, into the production schedule. All too often there is pressure to fully utilize the line; and that can only be done with orders resulting from a forecast. If MTS fills the line and MTO orders drop on top, they fall into backlog and the quoted lead time to the customer is a farce.

Assemble To Order or Finish To Order with placement of the Inventory/Order interface

This type of strategy allows for a placement of a stocking point, the inventory/order interface, at the most effective spot in the product structure. What this means is that you can decide at what point in the BoM, material is kept in stock readily available for further processing. Therefore upstream of the inventory/order interface we are making to stock and downstream from it we are pulling to order.
This also means that downstream from the I/O interface we have lead time to the customer whereas the availability check does not need to consider time for the processes upstream from the I/O interface.
ATO provides flexibility, speed and helps reduce waste. Other people would say its agile and lean at the same time.
Disconnect between Sales and Production #3: Assembly strategies have the capability to generate a production order to assemble the finished product right out of the sales order. As this happens, the system can also check on component availability and if there is a shortage, it can provide a reasonable date for when the finished product can be delivered. If that date is not fixed, and I have not seen a Sales person fix a date yet, production scheduling is burdened with a demand for today… and tomorrow for tomorrow… and so on and so forth. Please take a moment to think about what is done here: the Sales Rep agrees a date with the Customer who would be quite happy to get the product on that date in the future. However, that same Sales Rep tells the Production people that the product needs to be available right away. Consider how many orders there are and that this pressure pops up every day from now on until the order is delivered, you can easily see that there is room for improvement in the communication department.

Configure To Order

When a standard product has variations in its specification, one needs to answer the question whether to create a material master record number for every variation or to make use of the variant Configurator. In case the VC is used, an underlying structure will have to be build, which allows you to configure a variation of one (configurable) material number based on features and options. The underlying structure has optional values and characteristics that have dependencies and limitations.  Be cautious to know that In the same way that there is a line where it becomes more efficient to use options and characteristics to build a spec, there is also a line where it becomes more feasible to use a whole new project to build a complex product which has never been built before; or in other words: to build the underlying structure with features and options and dependencies becomes far too complex.
So there is an upper limit as well as a lower limit in complexity where Configure To Order has its right to exist.
Configure To Order is a strategy that closely resembles MTO or ATO for the finished product and components can be made to stock using a forecast based on probability factors maintained for options and features.

Engineer To Order

The Variant Configurator most always fails when that fine line was crossed where ETO should have taken over! It is not the lack of functionality and features of the VC which make it fail, it is mostly that the VC is used for a structure where projects and work breakdown structures would much better suit the handling of the complex product or structure in question.
Engineer To Order is used when complex structures are build. In most cases these projects organize many tasks and follow a long timeline to produce large, highly customized products to specific customer specifications. The finished product, and also many components and subassemblies, have never been built before and receive brand new product codes. Work Breakdown Structures and Projects are used to structure and manage the procurement of long lead-time purchased parts, the dependencies in production and procurement and cost and timely delivery of the final product.

All of these strategies have many variations. What was discussed above is just a generic description. A more detailed discussion is to be had around SAP planning strategies where there are countless combinations and opportunities.
…so here is a summary of my view on these strategies on a very generic level.
MTS: standard product made to a forecast before any committed orders come in
MTO: standard products not held in inventory and made after a committed order comes in
ATO: standard product where some components are held in stock and the finished product is finished after the order comes in
CTO: The standard product has variations; as many as not to justify the creation of a part number for every variation but not as many as to make the underlying structure too complex to handle

ETO: complex structures and customer specified projects which were never built before and make it impossible to be handled with standard variations

ERP and Business Intelligence (some of the popular tools like Cognos, Business Objects)

Every business is data driven today. The inflow of humongous amount of big data requires equally competent tools to manage and analyse the information. Such pressing needs has led to an aggressive market of business analytical tools or Business Intelligence tools.
BI systems allow a company to gather (from environment), store (in database), access (from database) and analyze corporate data to aid in decision-making. Business intelligence tools are a type of application software designed to retrieve (from database), analyze (data), transform (data to information) and report data for business intelligence.

SAP became one of the leaders of the business intelligence market after acquiring Business Objects, a French company, in 2007. In 2007, one month after SAP bought Business Objects (for $6.8 billion), IBM took over Cognos, based in Canada for $4.9 Billion.
The BO applications of SAP enable generation of reports, creation of interactive dashboards, visual manifestation, online as well as offline analysis of big data, and an interface for navigation and search. 
The business intelligence platform offered by the Big Blue(IBM) is Cognos. Cognos 8 software was presented in November 2005 including a few refreshed tools: Report Studio, Query Studio, Analysis Studio (in the place of former PowerPlay), Metrics Studio (instead of Metrics Manager), and Events Studio (replacing NoticeCast).
Both platforms – IBM Cognos Series 8 and SAP Business Objects – have specific advantages and disadvantages. Some of them are major, some only minor. Nevertheless, when choosing the right business intelligence platform for your organization it might be a good idea to precisely define your needs, then talk to the technical sales people from both SAP and IBM and try to get a trial version of both platforms and test it in your business environment. This will say which platform suits the end-users best.