Columbus ERP Software

How a Furniture Maker is Making a Difference With Microsoft Dynamics AX

For South Wales-based office furniture manufacturer Orangebox, Dynamics AX implementation experts Columbus are helping to build an ERP system with a difference.

If all goes well, this September should see innovative office furniture manufacturer Orangebox go live with a new ERP system – Microsoft Dynamics AX 2012.

In itself, the decision wasn’t a surprising one, concedes Orangebox commercial director Ewan Tozer. As the latest version of a popular and feature-rich ERP system from a world-class developer, Dynamics AX 2012 and its predecessors have been the system of choice for a wide range of manufacturers.

But take a closer look, and several unusual aspects of the implementation quickly emerge.

Known in the marketplace for its tag-line ‘Smarter Working’, and for the award-winning collaborative working spaces that epitomise Orangebox office furniture, it seems that Orangebox has taken the ‘Smarter Working’ message to heart in more ways than one. The result is an ERP selection and implementation process that turns out to be as distinctive as the Hengoed, South Wales-based business’s own innovative product line.

“The move wasn’t about ROI, and we didn’t spend long surveying the ERP marketplace,” says Tozer. “The decision to move to Dynamics AX was a strategic one, not an operational one, and had an operational impetus based around improved productivity, not cost savings. Dynamics AX 2012 was the right system for the business, and the time to switch was now.”

Future-proofing

In fact, he relates, the business had made the decision to move from its existing legacy system – the venerable Fourth Shift package, originally dating from the 1980s – two or three years ago. But back then, in the depths of the worst recession in sixty years, the time simply wasn’t right, says Tozer.

“We’ve used Fourth Shift for 14 years, and it does everything that we want,” he explains. “But it’s a legacy system with a shrinking customer base, and an unclear development path and future. As we’ve grown, and become more global, Fourth Shift is less appropriate for the business that we’ve become.”

In contrast, he relates, Dynamics AX 2012 did have a very clear development path and future. What’s more, it appeared to be one with very clear budget against it, and a fast-growing user base that endorsed those ambitions.

“We went to look at the system in action as more of a proofpoint, really,” sums up Tozer. “On paper it looked the right choice. And when we saw it, we realised that it was the right choice. At which point, we didn’t look any further: the more we looked at AX, the more we saw a good fit, coupled to an acquisition cost that seemed to be very reasonable value-for-money.”

That said, finding an implementation partner was less straightforward. And the eventual choice – manufacturing specialist Columbus – owed not a little to Orangebox’s insistence on continuing to use a third-party product configurator package, Eden, in which it had invested significant intellectual property.

“Our product range is very complex – far more complex than most people realise,” says Tozer. “We have 3,000 standard fabrics, so any combination of two fabrics is 9 million options, and any combination of three fabrics is 27 billion options.” And not only did Eden deal with that complexity, he relates, but the business had built-up twelve years of knowledge-based rules within the package.

What’s more, Orangebox wanted to replace its existing barcoding system, with its bespoke scripts, and move the functionality to Dynamics AX. The goal? Smoother, faster transactions, freeing people to add value, not just process data.

“We want people to be able make better decisions, and be better informed,” says Tozer. “We see Dynamics AX as a decision-making tool as well as a transaction engine. By making better decisions, and working more productively, is where the financial return will come from. It’s not about cutting jobs, it’s about growing the business faster, and with less pain.”

Two-way integration

And Columbus, he recalls, fully bought into that vision – despite the inherent challenges.

“We started by talking to half a dozen potential implementation partners – but only a couple of them really got their heads around our brief, and what we wanted to do,” he says. “Implementation has been slower than it might have been, but the result is that we’re going to get everything that we wanted, with little or no compromise.”

Employees accustomed to working in Eden, for instance, will continue to work in Eden, thanks to seamless XML-based two-way integration with Dynamics AX.

“If people are working in Eden, they’ll only ever see Eden, and Eden will be the only IT experience that they have,” explains Tozer. Behind the scenes, though, Eden-derived product design and configuration decisions will be translated into XML, and then output to Dynamics AX.

Bills of material, inventory levels, purchase requirements, goods inwards transactions and production schedules – all of these and more will operate seamlessly in Dynamics AX, driven by top-level sales orders generated in Eden.

“Outside the sales function, people will interact with Dynamics AX, just as they did with Fourth Shift,” says Tozer. “In finance, and purchasing, and in the stores, and on the factory floor: what people will see, and what people will work with, is Dynamics AX.”

And just as Orangebox remained with Fourth Shift for many years, he notes, the plan from the outset has been to build an equally enduring relationship with the new system.

“It’s been a strategic move: by design, we’ve gone for a solution that’s likely to be around for a long time. We didn’t want a solution from another small company that might be acquired and sidelined, we wanted a solution that had the impetus to survive.”

And this September, he concludes, the business will go live with a system that looks set to do just that.

Is Your Warehouse This Automated?

In this video we share the story of the Kiva robot and how it has automated the picking across its warehouse.

55 Second Video: Agile Manufacturing With Microsoft Dynamics AX

 

7 Steps to ERP System Implementation Heaven: Part 2 of 2

Purchasing and successfully implementing an ERP system is one of the costliest, labour intensive, stressful and business critical undertakings any business can embark upon. In this second part we look at the importance of data migration, ongoing development and user adoption.

5. Training and Understanding – User Acceptance.

There are many philosophies on how best to train staff, but the simple rule to follow is to actually train the staff.

During implementations there are many methods of training, but before any of this can really commence the software must be understood by the business, and the business must be understood by the ERP partner.

This is not simply how the incumbent software is used, but the business processes, requirements and the reasons behind why transactions and processes are undertaken. This understanding will lead to further questioning and mapping of processes to the new software to see how the software can be leveraged to full potential to meet the needs of the business.

Redundant system based processes adopted for historical or system restrictive reasons should be questioned, clarified and where possible integrated into a new method, or if possible dropped altogether.

With the harmonising of business and software understanding the processes can be mapped into the software and a training plan developed. This may include initial training sessions with the key members of the project team, in a train the trainer format. It may also include scheduled classroom sessions for departmental members, or entire departments. It is critical when training end-users that the processes are agreed with the key team members beforehand to ensure the sessions delivered meet the needs of the business.

The training itself can take many forms, but generally the most productive form is hands on sessions where the users have individual access to a test system and are given scenarios to create or follow.

The training of the users however is not the end of this process.

Once trained the users need to process train. Training in isolation may help the user gain an initial understanding of how the software works, but undertaking this in process loops is an essential step. By undertaking this the business gets to see how each department impacts on the other and how the decisions made upstream affect what the downstream departments “have” to do. Additional to this, and perhaps more critically, holes between the departments begin to appear from a software perspective. If discovered and understood at this stage provision can be made, but if this is not undertaken these issues can only be uncovered at go-live.

The acceptance of the users in totality is critical. Once the business understands how the business process flows through the software the business can assess the suitability of the processes, and whether they are really needed, or with the implementation of the new software whether other alternatives are now present from the software itself.

The entire processing cycle must be undertaken, and not simply once, different scenarios, different issues and different users should be used. All users generally bring a different perspective and a different set of questions and issues to the table. By collating all of these requirements the business has the best possible chance of going live smoothly. Undertaking this will mean all of the processes are understood, and the users understand how to use the software to meet the needs of the business.

If a business chooses to be trained and then go live without letting the users undertake static and process testing then all of the process gaps and issues will be discovered at go-live. The incumbent system will have been bent and abused to hide and conceal these gaps. The current system is as yet unaware of these issues and needs to be warned. It should not be expected that the new system will solve all of the issues of the old system, primarily because these are generally not software issues, they are process issues, but secondly because no one in the process of training has discovered they exist.

6. Data Migration

The common response to the question “What data from your current system do you want migrating to your new system?” is “Everything”. Whilst this is possible, it would probably cost more and take more time than the current ERP project being undertaken.

There are many pitfalls in the sub-project of data migration, but the underlying starting point is to be realistic. It should also be noted from the budgeting section that this area is not generally in the budget at the outset and therefore the business needs to consider what adding a multitude of days development would do to the budget at this stage.

The first question regards the areas of the business requiring data migration. This can generally be assessed on a volume basis. If there are 100,000 item records then they will be migrated, if there are 10 they will be keyed. Between these levels of volume assessments there is a grey line where a decision is made; and this line moves in volume depending upon the area of the records being migrated and the complexity. Another possible solution is the manual keying of data. This in itself acts as further training, and if the volumes permit can be used on open purchase and sales orders to dismiss the complexity of dynamic data migration.

Once the automated areas have been decided the next issue is the data itself. There are generally several issues with the data; the structure of the tables will be different, concepts in one system not being present in another, the data itself will be of poor quality, a common example of this is address records stored in completely separate text fields with different county references and no way of mapping these to the new and different address format, and the new system can be used in a manner that the existing data is not set up to handle.

One common requirement or request is for sales history to be migrated. To migrate into posted ledger tables and mark transactions as fully paid, with all of the reporting requirements of the new system catered for is a very lengthy and costly process that generally would never make a return on investment. Far more productive is to push the legacy data into a separate referenced SQL database or cube for cross analysis with the new system, or to simply leave the data where it is for user reference. Converting any form of historical data should be considered carefully with regards to benefit, timescales with the impact on the project, and cost.

Where the new system requires different settings and categorisations that do not exist in the current system the first issue is the transformation. The best method of this is to create these settings during the export routine of the legacy data if possible. The last option is to key these into the exported data ready for import – human errors will cause issues.

This project can run parallel to the ERP implementation project, and if possible the user acceptance training can be undertaken on the initial passes of migrated data.

The methods and processes for extracting, transforming and importing the data vary between systems, but one common factor is that the internal IT staff will be part of the process. It should be remembered that the IT staff are focused generally on the migration of data, that is to say the focus is on getting data from one field into another, and not that the end result meets processing requirements.

The final data routines should be finalised months in advance of a go live. Whilst initially testing will be undertaken on subsets of data it is imperative prior to live that at least one full import run is undertaken to ensure all of the possible issues from a full import are understood and potentially resolved in advance of the live date.

Once data exists and is present in a test system the end users responsible for the data must test this thoroughly. Responsibility for the acceptance of the resulting data in the end system resides with the end users and not the IT staff responsible for the transformation. This means to ensure the best possible results from the data migration project the routines must be run in full in advance of the live date and the end users must test, test and then test again.

7. Go Live perpetually

At the end of months and months, or even years and years, the business and the team will finally manage to drag themselves across the finish line. The business has made it, at last! That is it, the project is completed, there is relief all around as people can now concentrate on their day jobs. Simply put the answer to this is “NO”.

Going live is simply the start of the next phase of the project. There will have been requirements, issues, modifications and suggestions that were not on the business critical path, or were even purposely moved off the business critical path, and now these must be addressed. The original goals set out during the purchasing process should be reviewed for relevancy and achievement.

Whilst there is a period of settling in to the new system to gain the full leverage of the software and the change, the original reasons for change and the strengths of the new software and possibilities must be brought to the fore. Implementing a whole new system and getting back to where the business started with a new front end and a new way of processing the business through software is not success, it is a costly way of standing still.

Even if the business has implemented a system and there was very little in the second phase and they have made massive leaps forward throughout the business this is still not the time to do nothing. The go live process is perpetual. Standing still after go live will see the business begin to slip backwards from an ERP perspective.

The system needs to be constantly reviewed, processes and applications should be assessed for suitability and purpose, and where gain can be extracted from a change it should be made.
If at this stage the business stops the process of going live on the new software it is a distinct possibility that in the next five to ten years they will be undertaking a new implementation project to install a new system because the incumbent system does not meet the needs of the business. It does not meet the needs of the business because the business does not understand one of the costliest most powerful tools they possess and they never developed it to its full potential. This in turn brings us full circle, knowing your incumbent system – without it the business will not be going live perpetually, they will be implementing ERP perpetually.

There is generally no quick and easy solution to implementing an ERP system in a business of any size. This is gauged on the size of the business, you can implement an accounts system in a small business relatively quickly and cost effectively – but would you want the same timescales implementing in a multi-site, multi-million pound, 1000 employee business?

As a business the need to be realistic at the outset is paramount. The process, if done correctly, takes time, costs money and requires great internal resource commitment. All of these can be compromised to some extent, but there is always a balance in the end, and this will come in the system that the business ends up going live with. Compromise on the project and you are compromising the end solution, and potentially the growth and future of the business.
Implementing an ERP system is not straightforward, but remembering some of these simple suggestions will help the project have a greater chance of success than ignoring them.