6 posts tagged “erp system”

I love Microsoft Excel. I remember clearly the first time I came across an electronic spreadsheet application (for the record it was Smartsuite) and being blown away with the possibilities it offered. The ability to use macro’s and automate various tasks allowed for the creating of ‘mini-programs’ that would remove the mundane paper filling in the office and make data available for analysis.

Not long later I was taught, after much badgering of the IT department, how to create and download files from the ‘Master Business System’ which I could then import into the spreadsheet to then slice and dice and produce my own sets of figures for my management meetings.

At the time I was, at least for the business I was working in, quite a pioneer and I was very much lauded for producing reports that not only looked good but had information that was timely and accurate. No waiting for the production of reports overnight from the IT department on dot matrix printers with faded ribbons and fan-fold paper for me!

In truth this activity was responsible for my later selection to a project to implement a new ‘Master Business System’ – something that was called ‘ERP’.

Nowadays, as part of a company that implements ERP, both Microsoft Dynamics AX (formally known as Axapta) and Infor ERP LN (formally known as Baan, iBaan, SSA Baan, Triton etc, etc), I see a number of companies who have developed terrific spreadsheets with incredible macros and code that actually seem to be so essential to the business that, in the event of their loss, the business would be in serious trouble without them.

And herein lies the problem. In most cases the spreadsheets have been developed by people within the business who have used their talents and taught themselves to become spreadsheet Gurus.

Once these people move on (as I did) the ‘applications’ (in effect the business system) are essentially unsupported. The business has a choice; work out how and what the spreadsheet does, or employ someone from outside to do this, or start again.  An important aside here is that often these spreadsheets are not even backed up properly and reside on the authors PC introducing further risk.

A more robust answer is to implement a business system that doesn’t require all the spreadsheets to make the business work – such as ERP.

Or… actually look at what your current business system offers and make sure you are not ignoring what it could do for you therefore replacing the functionality of the spreadsheets. For instance some report enhancements or utilisation of modules that perhaps you currently don’t use.

Importantly, I would urge you to look at your business right now and see if you are in this situation – and if you are take some action before you find yourself facing an emergency.

I’d like to tell you about a recent project where we helped a customer save lots of money by reducing their stockholding of raw materials, saving space, bank borrowing and ultimately some headcount.

We found a business that seemed to have lots of stock but it was not always the right inventory to finish the shop orders on hand.  They had a lot of people in their purchasing department but they weren’t in control – nearly everyone was involved in expediting. Morale was pretty low because the rest of the business was kicking them for late deliveries.

We spent a little time interviewing the people in the department and then their co-workers in planning and production. Then we had a look at their processes and their ERP data.

Amongst many other things something jumped out that seemed incongruous – the lead times on almost every purchased item was, it appeared, to be generous.  We took the information back to the team and it became clear that a general policy was in place to always add a week to any quoted lead time by the supplier. The reason for this, it was explained, was that a number of suppliers in the past had been tardy with their delivery timings and it had led to shortages on the shop floor which later led to late delivery to customers. By applying this general rule they believed that hey would solve the problems of shortages.

To compound the problem they were also adding safety time, which was in theory, bringing in the stock even sooner.

We did some analysis and explained that all this stock was sitting around unused and that by bringing it in just in time would reduce their inventory significantly. ‘But why’ they asked ‘if we have all this inventory do we not have the stuff we need, when we need it? Why the shortages?’

The reason was this: at the end of each month it was recognised that they had too much stock. So they would, to reach financial targets, speak to all of their suppliers asking them to delay delivery of goods until the following month. It was only by a few days but it helped them meet the narrow fiscal target of stock on hand. They would then ask them to expedite the deliveries to meet production demand. Poor suppliers! They didn’t know if they were coming or going. The good suppliers were suffering and the poor suppliers were taking advantage. They had imposed a blanket policy and they had lost their focus on what was important.

We agreed to make the lead time reflect reality. We removed safety time where suppliers were reliable. We adjusted safety time where suppliers were not reliable. Where there was safety time we put a plan in place to improve supplier performance or change them. We convinced the business that the month end target of ‘X’ stock on hand was a false target.

Very quickly things improved. Stock reduced, the focus on poor suppliers improved their performance and so there were fewer shortages, and importantly, the people in purchasing had the opportunity to manage supplier relationships and gain greater discounts because they were no longer spending all their time expediting.

The important thing is that the company did not have to invest any money in new hardware or software – it was using ‘properly’ what they already had.

If you are looking for ways to save money right now take a look at your purchasing department – do you recognise the problems above?

I was tidying out my office at home the other day and came across a mobile phone that I used about ten years ago. I sat with it for a few moments and compared it to the latest Blackberry that I own. A number of things were different. The old phone was far heavier to begin with. The surface texture and design were what I would describe as ‘robust’. Thinking a little further on I recalled that the battery life was pretty poor, that it was only GSM, and above all – it was just a phone. Compared to my Blackberry that has e-mail, a camera, web browser, video, GPS map and a host of other things it is positively primitive.

I got to thinking about the evolution of ERP – what has changed in the last ten years? We know that a lot of businesses implemented towards the end of the last millennium so they will be sitting with software which in many cases will be as aged as my old phone. Some businesses, I am sure, have business software that is older than this – 15, even 20 years old. It’s an interesting thought that many of these business may consider themselves, relative to their peers, ‘up to date’ simply because they have an ERP system and not a bunch of non integrated legacy systems!

Of course some people will have upgraded to the latest versions of the ERP software they bought back then – but I come across a surprising number that have the originally implemented version and are still coming to grips with it.

When you consider the innovations around the web, RF and integration with the desktop that have happened over the past ten years or so, not to mention the ownership and strategies of the ERP package vendors, then quite a lot of people are looking at ten year old bricks whilst their competitors are availing themselves of multi-use devices.

If you consider that this may be the differentiator that offers competitive advantage then it’s time a number of people took a look at what’s out there, either considering upgrading their current system or replacing it completely. Take a look at my paper ‘Securing Competitive Advantage’ for a more in depth view.

In my early days of being involved in ERP implementation projects I witnessed a phenomenon that I later dubbed ‘Wobbly Wednesday’.

This was normally the day, often a week and a half after go-live of the new business system, when the ‘negatives’ and impact of the go-live reached a crescendo and the senior management sat down and seriously considered ‘pulling’ the project and returning to the old legacy system.

And it would normally all start so well. Go-lives are typically scheduled for a Monday so data migration and manual order entry can be completed over the weekend. Monday comes and goes and the users have been so nervous about the system they are surprised it all went so smoothly. Tuesday sees another ‘good’ day and the project team, who stayed late on Monday night getting things right for the Tuesday morning, actually get to go back home. Sometime later in the week the team get together and possibly drink to the success of the project. And then the wheels used to begin to fall off. In those first days all that was dealt with was the basic transactions – more difficult ones would be handled by the project team or consultants. As the week wore on users became more nervous and confused and started to make mistakes. They’d also begin to complain. A delivery would be missed. The wrong product would be made. And the ‘management; would hear and call a crisis meeting. They would honestly consider backing out of the project. This typically happened on the second Wednesday after go live hence me giving it the moniker; Wobbly Wednesday (though I guess I would come up with another alliteration had it been another day of the week).

Fortunately, these days, I don’t witness wobbly Wednesdays anymore. Our detailed planning and preparation for go-live of new ERP systems ensures that everyone has the training and knowledge to be effective from day one. Also, keeping clear communications with the project sponsors, and senior management, means that there are no surprises and no ‘wobbles’.

If you are about to run a large ERP implementation project then it is likely you will recruit an internal project implementation team. As I sat down to write this blog I thought I could condense my thoughts on how to pick the best ERP project implementation team into a short, readable blog entry. Then I thought about it a little bit more and decided to detail the type of people you really don’t want on your project team.
This is where the short blog entry turned into a ‘white paper’, though I accept that is not what it truly is….
In my paper I’ve identified 8 candidate profiles that you should avoid when putting your team together. It can be found here at http://www.neustro.com/whitepapers.aspx
Don’t agree with me? Or have I missed a profile? Let me know.

An important part of any ERP implementation project is establishing the ‘As-is’ business processes. This allows an understanding of the way the business runs, documenting the inputs and outputs, and then seeing how it maps to the new ERP system. There is also an opportunity to see if the business process could be done in a better way. Once the new way is designed and documented we have the ‘To-be’ business process.

Any business that has selected an ERP system, such as Microsoft Dynamics AX 2009, will soon realise that there is the opportunity to cut out swathes of paperwork and hours of filing. At first this will make a lot of people nervous as they will not have access to their trusty filing system. For a while they will feel lost when they realise that they cannot go though manual, multi-indexed, paper based records. So it’s important that training for the new system is not only about functionality but also about navigation. Ensure that you give users comfort by showing them where they can find the electronic equivalent of the paperwork they file manually now.

Mapping the ‘As-is’ business process may also reveal some redundancy in the current way of doing things. I recall once taking a business through a particular process that involved 28 different pieces of paper that referenced each other and required multi-part forms and transfer, by handwriting, of information between the forms. Ultimately the forms resided in 22 different filing systems in binders and cabinets. After 2 days I asked the question; "Typically, how often do you refer back to these records in a year?". After a long pause the reply was "I can’t actually remember the last time we did". A further question "What do you do with all this paperwork after 6 months?" (because the daily output was phenomenal and it was clear it wasn’t in the office we were in). This time a rapid reply, "We destroy it". Then, from me "Why are you doing it then?". "Because… ". Silence.