• Big bang - Implementation happens in a single instance. All users move to the new system on a given date.
• Phased rollout - Changeover occurs in phases over an extended period of time. Users move onto new system in a series of steps.
• Parallel adoption - Both the legacy and new ERP system run at the same time. Users learn the new system while working on the old.

First, Take Our Survey
Have you been involved in an ERP implementation? Was it successful? We want to hear from you. We are hosting a survey to find out which implementation strategies are the most popular and most successful. We will collect results over the next two weeks and present our findings towards the end of the month. Select the link below to get started.



Big Bang
Just as the name implies, a big bang ERP implementation happens in a single, major event. All modules are installed across the entire organization all at once, more or less. Of course the changeover from the legacy system doesn’t happen without proper planning. There are many pre-implementation activities that need to be carried out prior to the big bang.

After the planning activities have been successfully executed, the old system will be turned off, and the new system will be launched. At this point there is no turning back. However, there should be fall-back scenarios prepared just in case the initial changeover is a failure.

The big bang implementation strategy has supporters on both sides of the fence. The most common criticism is the risk factor; there are a number of things that could go wrong in an instant changeover. However, the implementation is quick and less costly than a long, drawn-out phased approach. Here is a list of other benefits and drawbacks of big bang implementation:

Another downside of big bang implementations is Ken Eason’s “Initial Dip Phenomenon.” Eason, author of “Information Technology and Organisational Change” and one of the original authorities on implementation strategies, describes an “initial dip phenomenon” which happens shortly after an implementation. This catch-up period happens because users are struggling with the new system and organizational performance temporarily declines as a result.

Phased Rollout
In keeping with the theme of cosmological evolution, phased rollout would be analogous to the Steady State theory: instead of an implementation happening in a single instance, small changes occur over time. An organization moves off the legacy system and onto the new ERP system in a series of predetermined steps. This can be achieved in several different ways. Here are three well-known techniques:

• Phased rollout by module - This is the most common phased rollout strategy. ERP modules are implemented one at a time. Typically you begin with core business functions – those necessary for daily operations – then add in more modules and functionality with each phase. However, some experts suggest starting with easy modules like general ledger, or beginning with the less mission-critical modules. For a good explanation, read Insight Consulting Partner’s write-up.
• Phased rollout by business unit - Under this approach implementation is carried out in one or more business units or departments at a time. For example, you begin with implementing the new ERP system in human resources, then move to accounting. Some organizations may put together an implementation project team that travels between each department during implementation phases. As the team gains more experience with each implementation, subsequent phases become more efficient.
• Phased rollout by geography - For organizations with multiple locations, a phased rollout by geography is a frequent approach. The new ERP system is introduced at one or more company locations at a time. This is also referred to as the “pilot adoption method.” It’s common for large organizations that have multiple locations or independent departments.

Of course there are hundreds of options, including many variations and combinations of these three. Just like big bang, a phased rollout strategy has advantages and disadvantages. This table includes several common viewpoints:

Parallel Adoption
The third generic – though less talked about – ERP implementation plan is the “parallel adoption” approach. This has also been referred to as “parallel conversion,” “parallel running,” or “parallel cutover.”

Parallel adoption is thought to be the least risky implementation process. It includes running both the old and new ERP system at the same time. This way users can learn the new system while performing regular work activities on the old system. After requirements for the new system are met, then the legacy system is decommissioned.

Eason Strategy Matrix

Borrowing another illustration from Ken Eason, parallel adoption is presented as the “middle road” between big bang and phased adoption. For example, the pace of the changeover is slower than big bang, but faster than phased adoption. Similarly, user adaptation is easier than big bang, but more difficult than phased adoption.

The major trade-off – not illustrated in Eason’s matrix – is cost. Parallel adoption is the most expensive implementation method. Additionally, having employees enter data in both systems is not efficient. However, if the extra costs are less than costs incurred after a backfired big bang adoption, then it’s a reasonable plan. Still, organizations cannot predict cost overruns of big bang, so parallel adoption has become decreasingly popular because of perceived high costs.

Which ERP Implementation Strategy is Best for Your Business?
There certainly is no one-size-fits-all when it comes to implementing an ERP system. Every company has unique goals, and an implementation requires careful planning and analysis. Some companies may choose a combination of strategies, like a mini big bang mixed with phased rollouts (i.e. “big bang” the important modules, then add in the peripheral modules later). Others may choose to implement a mid-market ERP system (e.g. Microsoft Dynamics, Epicor) at the plant-level, while keeping a major ERP system (e.g. SAP, Oracle running at headquarters). And at times, the best implementation strategy will be obvious (as illustrated in this case study).

At a minimum, we hope this guide gets your organization off on the right foot. By choosing one of the above or developing an entirely custom strategy, you should be well on your way to success.

For all you Rhinoceros (Rhino) 3D fans, here’s a clip that demonstrates Rhino 5.0 WIPs new two-point perspective feature (by default, Rhino Perspective Viewpoint uses a 3-point perspective).

Of course the technology could be extended to other manufacturing software applications like product lifecycle management (PLM) software. This would be especially useful when manufacturing a complex product with multiple assemblies. Project members could better visualize the product and avoid costly engineer changes later on.

It may be years before Apple takes this technology to market, or until enterprise software vendors integrate it with their existing systems. In the meantime, feel free to leave us a comment and share your ideas on other ways this technology could work in manufacturing design.

With the recent launch of our ERP software service, we decided to shed some light on the Dynamics product family. For starters, here is a chart that shows the target market for each product. Industries are down the side, business sizes are across the top, products lie in the middle. Click on the image for an expanded view.

* These are our estimates and not officially from Microsoft.

Understanding the Microsoft Dynamics Portfolio
In 2001 Microsoft entered the server-based business applications market with the acquisition of Great Plains software. While they originally claimed otherwise, the acquisition was a strategic move to compete with enterprise software providers like SAP and Oracle. At stake were not only ERP applications revenues, but the database and operating system sales that are driven by new ERP projects.

In the $1.1 billion acquisition, Microsoft gained Great Plains Dynamics and Solomon, two accounting and business management systems with 45,000 customers and 2,200 channel partners. This would give Microsoft a strong presence here in the States, but the acquisition wouldn’t satisfy their global ambitions.

So, in 2002 Microsoft acquired Danish software company Navision, which offered enterprise-level accounting, human resources and CRM software. Through this acquisition, Microsoft also gained the Axapta product, another enterprise system originally developed by Damgaard – a company acquired earlier by Navision. Navision currently has roughly 70,000 installed customers with over 1.3 million users.

These four products – Great Plains, Solomon, Navision and Axapta – would make up Microsoft’s Business Solutions Group, later renamed “Microsoft Dynamics.” Of course, there were other smaller footprint products that had been acquired by each of these companies. Meanwhile, Microsoft has made subsequent acquisitions of related companies or technology assets.

Project Green – Denied the Green Light
Microsoft now owned four different enterprise suites, each written in a different language using a different development environment and sometimes running on different databases. Project Green was the codename given to the task of converting all four products to a single code base.

On one hand, Project Green would allow Microsoft to deeply integrate all four products with each other, and with their desktop and server software. This would extend the capabilities of each product, give users a shared experience and reduce the burden of support.

On the other hand, Microsoft would be faced with a very big technical challenge and customer service challenge. The upgrade path for customers would be split – NAV customers might be three releases back while GP customers might on the last release – and customers would face all the demands that come with an upgrade (training, implementation, etc). Not to mention, Dynamics partners that built their offerings around one of the products would also face a migration challenge.

So Microsoft eventually changed its development strategy. Instead of rewriting the code base from the ground up, they shifted to a top-down approach of integrating existing technology from the Microsoft stack. Subsequently, they re-branded the products to the current nomenclature: Dynamics GP, Dynamics SL, Dynamics NAV and Dynamics AX.

For a detailed history of Project Green, we suggest reading Frank Scavo’s blog.

Natural Selection
Over the years, each Dynamics product has naturally become popular in certain industries. For example, Dynamics GP – known for it’s strong general ledger and human resources (HR) capabilities – has become popular for professional services and the public sector.

Here is a quick breakdown of how the others have evolved:

Product	Differentiator
Dynamics AX	Great for multi-site and multi-country operations
	Strong in manufacturing and distribution
	Good for companies with a primary ERP that want to add software to a division of the company
	Fastest-growing of Microsoft's four ERP products
Dynamics NAV	Biggest seller among all Dynamics products
	Stronger in single-site or distributed implementations
	Highly configurable with a ton of vertical partners
	Easily customizable to sub-verticals within an industry
	Strong in manufacturing and distribution
Dynamics GP	Strong financial management and HR capabilities
	Popular among professional services, finance and public sector
	Robust out-of-the-box functionality
	Focuses on the Americas and English speaking countries
Dynamics SL	Good for project-based businesses (e.g. construction)
	Strong accounting and project management capabilities
	Suited for companies with less than 500 employees
	Does well in distribution

Keep in mind there are roughly 9,000 independent software vendors (ISVs) that provide support and customizations for Dynamics products. These partners have developed hundreds of industry solutions with deep vertical capabilities. So it’s possible to find any of the above being used in any size or type of business.

Today, Microsoft is extending functionality outside the traditional scope of some products. For example, in the next release of Dynamics AX, they plan on adding functionality for the public sector. This may be an indication of a move towards a single product – or fewer products – which would help them save on future development and support costs.

Moving towards one or two products is more conceivable when looking at an illustration like the chart below. Here is an apples-to-apples comparison of the modules within each product

Where the Sidewalk Ends
The Dynamics’ roadmap stretches out to 2017 with all four products extending three versions out from the current release. What happens then? Will Microsoft move the products down- or up-market? Will users be encouraged to migrate to one system over another?

Speculation aside, we expect Microsoft to continue supporting and investing in each Dynamics product. New versions of each ERP product are due out in 2010 and new features (e.g. “Environmental Sustainability Dashboard”) are being added on a regular basis.

By taking advantage of the Software Advice website, manufacturers can research and compare leading enterprise software systems. Additionally, manufacturers can contact Software Advice’s team of experts to receive:

• Free telephone “short list” consultations
• Product demonstrations and price quotes
• Answers to common software questions
• Information on the latest trends and best practices

“Manufacturers face an incredibly complex array of software options,” said Don Fornes, founder and Chief Executive Officer of Software Advice. “When evaluating enterprise solutions, manufacturers must consider which systems address their industry, their mode of manufacturing, their functional requirements and numerous other criteria. It’s exactly the type of challenge we set out to solve when we started Software Advice four years ago.”

Behind the Software Advice website is a sophisticated database with detailed information on leading software systems. Meanwhile, the company’s proprietary matching technology helps buyers quickly narrow down which software products meet their criteria. Manufacturers are able to develop a “short list” of systems to evaluate further, saving weeks of research effort.

Software Advice also serves as a powerful marketing channel for software vendors, who receive highly qualified sales referrals when buyers request information about their products. Currently, Software Advice profiles market leading products from vendors such as SAP, Oracle, Microsoft®, Epicor and IFS, among others. Participating vendors serve a wide range of industries and manufacturing modes.

About Software Advice
Founded in 2005, Software Advice (www.softwareadvice.com) has helped over 15,000 organizations – small, medium and large – make the right software purchase decisions. The company’s content-rich website provides visitors with detailed software product profiles, helpful selection tools and informative blog posts covering the latest software trends. Meanwhile, Software Advice’s team of “Customer Advocates” consults with buyers by telephone to narrow down an ideal “short list” of software systems for further review. Software Advice currently serves the construction, manufacturing, medical, property management, and retail industries.