jump to navigation

How close is your software vendor? 10/12/2011

Posted by TBoehm30 in Software.
Tags: , , , , , ,
1 comment so far

 

The other day I had a software problem.  My client had come to me with an issue and I had to come up with a solution.  I have been working with them for a while so I know their software pretty well.  I can usually figure out their problems and either solve them or come up with a workaround.  At the very least I can use their testing environment to document all the steps to recreate the problem as well as the steps taken to try to solve it.

My client has a valid contract with the software vendor and has full access to their help desk.  I am sure you have dealt with many ‘help’ desks and are completely familiar with what that means.  Some of them are very good and some of them are worse than a hot day in the desert.  I have to admit that this one is actually pretty good.

The trick is in the communication.  The people who I work with can’t always communicate their problems in such a way that the help desk can solve them.  They also have trouble understanding the responses.  Sometimes the tech-speak is just too complicated.  That’s where I come in.  I can help translate for both sides to get the problem solved.

Today, I found what I thought was a bug in the software.  The company that created this software is very sensitive about criticism of their programs.  I didn’t want to go to the help desk with this one until I had verified functionality with one of their senior consultants.  Since I am on good terms with several of them, my options were open.

The project manager for our implementation likes for me to go through him before talking to the consultants.  I shot him an email with my problem.  Within a few hours he had confirmed my problem, sent it off to tech support, and came back with a solution.  It wasn’t really a bug, but a setup problem.

I have dealt with many software companies throughout my career.  I have talked to people who were really good at their job, but the company was terrible; and I have talked to people who couldn’t help a cat out of a bag, even when their company was great.  A response within a few hours with a solution, going around the help desk, is above average support.  I would recommend that any day of the week.

When you are looking for software it is important to determine what kind of relationships they develop with their clients.  Sure, you will get references and talk to them about the pros and cons about the software; but you also need to find out about their responsiveness.  You need to find out about their personnel.  Do they stay in touch with their clients?  Do they come back to find out if there are any lingering issues?

Before you make a decision on your software, find out who your main contact will be.  Try to meet with him or her at a time and place where you have plenty of time for questions.  This person needs to be someone with whom you can trust and build a relationship.  They need to listen; you need to feel like they are listening to you and not thinking about what they will say next.  They need to be flexible.  Throw them a hypothetical curve ball; how do they react?

If this person doesn’t meet your criteria, don’t abandon the software vendor entirely, just ask for someone else.  Most companies would be happy to switch personnel if it means a chance for a sale.  Make sure you still have time to repeat the process with someone new.

My criteria is for someone who understands that it’s a global world out there and Technology makes it happen.

ERP implementation can be successful if… 08/27/2011

Posted by TBoehm30 in ERP.
Tags: , , , , , ,
1 comment so far

This is a special contribution from one of my Tatum colleagues.  See below for a short bio on Dan Gingras.

If there are three letters which can wreak fear in the “c suite” it’s the letters ERP.   Enterprise Resource Planning will bring visions of costs overruns, schedule delays and general havoc to most company officers, and with good reason;  most ERP Implementations fail to deliver the benefits promised in the sales cycle according to numerous studies into the success of these projects. 

It doesn’t have to be that way though.   We’ve studied these implementations for decades, and the causes for these substandard implementations are well known and widely documented, so why do we still have unsuccessful implementations.    The key to these failures is that there is a disconnect between what we know and what we actually do.  So let’s review what we’ve seen in the ERP implementation marketplace over the past few years.

•  Lack of Top Management Commitment

Clearly this is the most significant contributor to project success, and unless the top officers are part of the project from the beginning it’s a sign that you’ll have problems.  The litmus test for commitment is whether the top officers are willing to demand that the top salespeople change to best practices as part of the implementation.  When the salespeople say “our customers won’t support that change” the CEO usually will cave.   Unless there’s significant pushback by the CEO, you can rate the commitment as “lukewarm”     It’s easy to say, but it’s difficult to execute change.

•  Inadequate Requirements Definition

Failing to understand the detailed requirements accounts for nearly 60% of ERP implementation failures, based on our experience.  Creating an adequate Requirements definition document for a system selection is an effort that takes months and involves most of the company.  There are dozens of functions within most companies, and within these functions there are hundreds of processes.  Each of these processes can have hundreds of elements, so the requirements can be extremely complex, and unless each feature/function is properly defined, you will not find out until you well into the implementation, and generally this will require some pain (read: customization) to fix.  It’s important to understand not only what is done, but what is possible, and this requires a thorough understanding of the ERP marketplace.

•  Poor ERP Package Selection

How many ERP packages are selected based on a demo or set of demos done by the software vendor?   Too many, because unless the demo scripts are based on the requirements definition study, and scripted to follow the desired processes of the company then they’re not of much value.   A demonstration of a system should represent the business process of the company exactly.  If you make cement, than watching a demonstration of the software make a bicycle isn’t going to show you how the system will work in your business, and users who see the demo will be distracted by features, functions and the user interface, which may not be applicable to your business.   The script of a demo must reflect the requirements gathered in the requirements gathering phase of the selection.  If not, then don’t waste your time.

•  Inadequate Resources

Implementing a new ERP system involves re-designing processes, sometime from scratch.  Do you really want your processes designed by anyone less than the best person in your company?  Most ERP implementations involve creating a core team of full time employees to design, test and train.  Unless you pick your “best and brightest” you are short-changing the organization.  We like to tell our clients that they should pick the future leaders of the company, because this core team is going to completely re-engineer the company and it will be the group who knows all the new processes the best since they designed them.   Taking the ‘best and brightest’ out of the company for a significant period of time is expensive and painful, but it’s the way to succeed.  Short change the resources, or select less that the best at your own peril.   Easy to say, but tough to do.

•  Resistance to Change/Lack of Buy-in

“Paving Cow Paths” as Michael Hammer of “Reengineering the Corporation” is pretty easy to do, and it generally involves getting the new software to do what is being done now.   It’s difficult to comprehend why a company would buy a new system to improve its processes, and then try to get it to work exactly like the old system, but it happens every day.  Remember that the “institutional knowledge” or best practices of hundreds or thousands of other companies are  “baked into”  the new software, and you should take advantage of that knowledge by changing your processes to fit the new system.  Yes, it’s painful, but it’s the best way to succeed.

There are a number of other keys to success in implementing a new ERP system, but these are the ones we see most often, and the ones which are most troubling since they’re so well known.  The difference between knowing and doing is surprising and troubling, but it continues.    Share this list with your team and discuss how you can avoid the gap between knowing and doing.

A special thanks to Dan Gingras for this article: 

Gingras is a Partner in the New England practice of Tatum.

He has 25 years of experience as a technology executive with extensive qualifications in all facets of project life cycle, from initial feasibility analysis and conceptual design through documentation, implementation, user training and enhancement. He is well know as the author of numerous articles in trade magazines and writes a regular column for CIO Update.

ERP Without Accounting? 08/11/2011

Posted by TBoehm30 in ERP.
Tags: , , , , ,
3 comments

ERP (Enterprise Resource Planning) is usually defined as more than one software module that helps you run your business.  Usually that means that accounting is connected to another aspect of the company.  The manufacturing would automatically load the cost of goods produced into the accounting module.  The invoices can automatically be generated from the Sales Orders.  It saves time for the accountants.  It is also far more accurate that any sort of manual effort, and more timely than intermittent interfaces.

I work with a number of accountants.  They were shocked to learn that I am about to implement an ERP system without including the accounting module.  I was told that they wouldn’t try it.  They didn’t see the purpose.  They said that the risk outweighed any reward.

I started thinking about that.  Would this really be worth it?  Could we make it work?  I once read an analogy that an ERP implementation was like heart surgery.  Holding to that, would we want to perform heart surgery, but only fix 3 of the valves?  You know you’ll have to open the patient up again eventually, to fix that 4th valve.

If I am the doctor in that analogy (my dad would be so proud that I am following in his footsteps), then I have to make the call.  If the patient isn’t going to survive a full operation, then maybe we split the procedure into 2 separate operations.  We perform half now, let the patient recover, and then perform the next one when he is ready.  Hopefully the first operation will fix enough so that the patient will make it to the second one and then a full recovery.

OK, enough with the medical analogy.  I am not a doctor, I don’t play one on TV or the internet, and I know very little about performing surgery.

I do, however, know when a company needs to get off of its current software system.  When Excel spreadsheets are so big that the computer freezes trying to make a change, it’s time for a fix.  When you spend more time dealing with data problems than you do handling your ‘real’ job, it’s time for a fix.  When the system you’ve got doesn’t show you the data required by your corporate entity, it’s time for a fix.

So, we optimistically set the schedule too tight.  The accountants have been completely distracted from the project by other responsibilities.  The processes cannot be changed in a timeline that everyone will agree on.  Our only choice was to delay the project.  Our only choice, that is, until we came up with the brilliant idea of only turning on operations.  We will avoid accounting and finance for another few months; until the patient is healed enough to continue.

ERP without accounting just sounds silly; but we can make it work.  We will use the ERP system mainly for tracking inventory (yes, the cost and price of materials will be tracked, but not as the system of record).  We will be able to get new reports that will show what the company is producing, what they need to produce, and when they need to produce it.  We will eliminate the need for extremely large Excel spreadsheets by using a real database.

We then get 5 more months (3 if you remove the weeks that people will take off for the end of the year holidays) to prepare for accounting.  The accountants will have more time to figure out how to best use the new system.  They will have more time for validation and system testing.  They will have more time to design the reports they will need on the new system.

So, yes, I think we can make it work.  Yes, I think it’s worth it. Do you?

ERP – Just another tool? 07/06/2011

Posted by TBoehm30 in ERP.
Tags: , , , , , ,
add a comment

Is there a case for using ERP software outside of your Production system?

Imagine running a 20 million dollar manufacturing company on spreadsheets.  Oh sure, you can use Peachtree or QuickBooks for accounting, but what about manufacturing?  How many Work Orders are going on currently?  How many Sales Orders are due today? Or this week?  Can you determine what your margins are, when you can’t even track labor?

The obvious solution is an ERP system, but how fast can you implement it?  You need the new system yesterday: the spreadsheets are so big that the computers are crashing; there are numerous versions of each list and no one knows who has the latest version.  Can you get a project going fast enough to solve the problem?  What if you can’t?

Maybe now you can understand my dilemma; and why my solution makes sense.  The company has several factories already running a very good ERP system.  They use the accounting and manufacturing modules to coordinate with the corporate accountants and to track and plan the manufactured goods.  One factory, however, is not quite up to speed.  The project to put them on the system is falling behind and they will not be able to make their deadlines.

Their implementation team is small, which sped up the decision making process.  We were able to design their processes quickly, and understand most of the issues.  Next was loading, testing, and validating data.  The small team hurt them because each member had too much going on.  With several validation scripts each, plus their regular job, they couldn’t keep up.

We have to deal with the amount of time it takes the accountants to do a month-end and quarter-end close.  Corporate needs standard monthly statements in a timely fashion, and without a regular system, that takes a while.  The time they are working on that is time away from the ERP project.  We also lost a few days while they installed a new payroll system.  The problems encountered during that project took the accountants away for several days.

The solution is pretty elegant, even though it is convoluted.  We will implement the ERP system in a non-Production folder.  We will only use that system for operations to track inventory (POs, Receipts, Work Orders, Sales Order, Shipments).  We will not use that system for accounting (invoicing, A/R, payments, journal entries, corrections, etc.). 

Leaving out the accounting side should reduce the scope enough to allow us to finish on time.  By including the main functionality to track inventory they will have the tools they need to run the business.  They need to stop relying solely on giant spreadsheets, and this will give them the data they need to do it.  They will be able to download anything they still need into Excel format, but have a SQL database as their system of record.

There are risks, of course.  They will need to officially give up their spreadsheets and not rely on them anymore.  Some people were used to seeing the whole picture through the spreadsheet.  That picture could be limited and more condensed as seen through the ERP.  They will have to figure out what screens and what reports are equivalent to their old spreadsheets.

They will have to be able to synchronize some of the processes between the existing accounting system and the new ERP system.  Anything with money on it will need to be put into the accounting system, but the quantities will be in the ERP system.  They wouldn’t have an ‘old’ accounting system if they could just go-live with the whole ERP system.

What about dual entry?  Sales Orders will need to be on both systems.  Can they manage the ERP system without worrying about prices?  Can they keep the quantities in synch?  Invoicing will have to be done from the accounting system, but match with shipments from the ERP.  POs will need to be in synch as well.  How much time will be spent chasing down inconsistencies?

They will be using the ERP system only to track inventory.  The dollar amounts will, hopefully, be correct but irrelevant.  This is a temporary solution, so we still have to plan for an eventual go-live on the Production ERP system.  We still have to figure out when to move all the accounting information and processes along with the manufacturing data into the Production ERP system.

The bottom line is that they can’t go-live on the Production system; they can’t stay where they are now, with spreadsheets.  This is the next best alternative.  Do you have any alternatives?  Have you faced a problem like this?  Let me know.

Can we get it done in time?  We must, because it’s a global world out there and Technology makes it happen.

The Conference Room Pilot – Change Management 04/30/2011

Posted by TBoehm30 in Project Management.
Tags: , , , , ,
1 comment so far

Someone once said “If you stand still you die” (or something like that).  People need change – both in our private lives and our business life.  Some people crave change, while others avoid it like the plague.

The other day before work, I thought I heard thunder.  I went downstairs and asked my wife if it was beginning to storm, or was she moving furniture.  My wife loves to change the house around.  She’s been doing it since she was old enough to walk.  Her parents talk about a tiny little girl pushing a giant dresser around the room inch by inch.  This morning she had switched our living room and our dining room.  She had already pushed the dining room table into the other room – that was what I thought was thunder.

I may not be much of a mover, but after a bit of work I realized that she had a great idea.  The new dining room would allow us to seat more people in one room; we had family coming over for dinner the next week and could use the space.  I wasn’t originally thrilled with the idea, but now I really love it.  Next, she’ll want me to paint the new living room.  I’m not looking forward to a weekend of painting, but again, she’ll be right and it will look great.  (shh, don’t tell her I said she was right.)

Employees, who are like my wife, will really enjoy learning about a new software system.  They will be active participants, learn what to do, and help others.  Their energy can be contagious, helping others to feel good about the changes that are coming.

Others, however, will fear the change.  They will worry about not being able to handle the new aspects of their job or worse, their job going away.  They will fight the change with arguments that range from the simple to complex, from obvious to the outrageous.  It is important not to scare those people away, but to work with them in a way to get them to accept the change and work with you and the new system.

I once worked with a client that had a couple of people like that.  They stored their documents in Word and had an entire notebook dedicated to the rules on changing them.  These documents were very important to their processes and kept the company running smoothly.  Changes to the documents had to be approved at several levels and the changes themselves had to be documented.

The new software could dynamically create the documents to be printed, eliminating most of the procedures in the big notebook.  This was scary to them.  The FDA audits the company every so often and required real quality control.  What would the FDA say to a new system?

 How could they prove that the system still printed out the right documents?  Would it even be possible to prove the validity of a new system?  How much testing were we signing up for to make sure that the new software did what it was supposed to do?  How could they control the changes to the documents if they weren’t stored in a central location?  All these questions needed to be studied in detail to provide a good answer to scared employees. 

They needed to see that the new system would make their job easier and more fun.  It would take some work to get there, but the work would be worth it.  They would have to put in some extra effort to get to the point where the new system could take over, but at that point they would be able to put their energy into innovation instead of following rules.

The Conference Room Pilot is a great way to slowly bring people like that around to a new way of thinking.  I didn’t tell them outright that we were going to do it my way.  I assured them the paperwork could stay the same until they were comfortable with the new system.  We walked through the new functionality numerous times.  We created documents from the new system, just to show them how it worked.  We created the new procedures so that when they changed their mind, printing the new documents could easily be added.  Eventually they realized that the new system would only improve their business.

Change Management is an art.  People who don’t like change or are afraid of change exist everywhere.  They are still valuable employees and an important part of the company.  Fear is a legitimate feeling that lets us know danger is approaching.  A new software system can be a scary project to see coming.  It is important to be ready for change management.

Every project manager needs to recognize the people who are worried and have a plan to deal with them.  They aren’t going away and you don’t want them fighting you at every step.  There is plenty of information on the internet about how to prepare for change management.  Just do a Google search on Change Management to get some very good frameworks.  Include lots of information in the Pilot; do a lot of explaining to ease people into the project.  Address their fears head on or slowly show them the advantages of the new system.

Have you dealt with people afraid of change?  Tell me your stories, what they were afraid of, and how you handled it.

Not everyone accepts change at the same pace.  If you take the time to bring everyone into your camp, they will all realize – just like you do – that it’s a global world out there and Technology makes it happen.