• Innovative Thinking
  •  + 
  • Strategic Consulting
  •  + 
  • Superior Solutions
  •  = 
  • Excellence in ERP
"Innovative Thinking" A Newsletter from Innovative IT Consulting In This Issue

January 2011

It's all too common. The ERP vendor is conducting the demo, and a few things come up that the software doesn't handle just the way you need them to. The vendor says "No Problem" - but is it? Read our lead article to help guide you through software modifications.

And in the useful tips section John Pellegrino talks about Execution as a critical part of Project Success.

Don't forget to read Paul Sita's ERP Blog Posts for the Sage Business Management Blog. Check out the latest post on Total Cost of Ownership - learn a few things that might keep you from getting off track! TCO - Don't Underestimate or Overestimate.

By Paul Sita, Principal, Innovative IT Consulting, LLC. Paul can be reached at 631-549-1685 or psita@innovativeitc.com.

Sales is sales and systems are systems. Never forget that when you are evaluating an ERP system you are in a sales process, no matter what the sales, or pre-sales consultants tell you. They are under pressure to close deals and sign up customers. The "No Problem - the system can do that" comment may be nothing more than an optimistic guess on the part of the sales team. "CAN DO THAT" is a far cry from "DOES DO THAT" when it comes to ERP systems. Even with good motives, pre-sales consultants tend to be overly optimistic!! But once the deal is closed they are on to the next one - leaving the technical and consulting teams to make it all work.

First piece of advice. Avoid modifications if you can. When we're talking modifications we're not talking about changing a screen, or adding a new field, even if it's a calculation based on other fields. We're not even talking about adding completely new functions to view things. We are talking about fundamental logic about how an ERP system works. ERP systems each have their own personality, their own flavor. However, by their very nature of being an ERP system --- EVERYTHING IS CONNECTED. And this means there is no such thing as a trivial modification. There are always unintended consequences somewhere else in the system. It can seem so simple on the surface - we'll just rename this field and use this one instead . . .and lo and behold your GL is now out of balance, or stock allocations are a little off. And don't forget that modifications have to be dealt with with EVERY MAJOR UPGRADE, and the programmer who did them the first time and really understands them most likely won't be around when it comes time to do that major upgrade. But there are times when it's just unavoidable . . . so

Talk to other users who have had modifications done. It's very hard for even the ERP vendor sometimes to determine all the issues relative to a modification. That's why it's good practice to talk to other customers who have had mods done and get their insight and experiences. Find out about the process. What specifically did they have done and how does it compare with your needs in terms of scope? Ask them what they would do differently if they had to do it over again?

Get a detailed explanation. Work with your vendor to get a detailed explanation on 2 levels. First is the business level. What business issue are you trying to solve? What does the system need to do? If the vendor can't write this down in simple English, then stop right there. Once you get this, you will most likely have to pay (yes PAY) the vendors development team to dig ino the technical details of how they plan to execute the modification. This is actually good for you, since this is the only way that they can really know what's involved. The key step is now to follow a good process to getting the work done.

Practice makes perfect. There is always a gap between the vision of a modifcation, something that is being designed for the first time, vs. a system that has been implemented hundreds or thousands of times. Insist on seeing the modifications in small increments. The best way to insure quality is to have the vendor design in multiple iterations where you see the mod, walk through the business process, and then re-evaluate if you are heading where you need to go. Many vendors will push back, indicating that this is not productive for their development team. However, insist on this approach, and insist that the technical team participate in walking through the modifications. There's no guarantee that they fully understand the specifications that were written for them. So how close is a close fit? It's hard to tell!! But following the above process will help you find out.

By John Pellegrino, Principal, Innovative IT Consulting, LLC. John can be reached at 631-549-1685 or jpellegrino@innovativeitc.com.

Over the last few months I have spoken about overall techniques for running an implementation or a development project. In this month’s tip I will wrap this series up by discussing the critical success factor for any project – execution of the plan. Since the NFL playoffs are in full swing towards the Super Bowl and, as of this writing, the team I root for is still in the hunt I will use football as the analogy.

Basic blocking and tackling. First, let’s recap the tips presented in previous issues.

1. Not working in a “black hole” – when one player on the defense does their own thing instead of working with the other 10 players it can be disastrous (think blown coverage). And, they have to work together iteratively (every play).

2. Break the project into sub-projects – you have defense (with a defensive coordinator), offense (with an offensive coordinator), special teams (with a special teams coach) and layers below each of them (e.g. defensive line coach, linebacker coach, backfield coach). Enough said.

3. Communicate the good, the bad and the ugly “up” the chain of command – we know what happens to the coordinator/coach that doesn’t do this well, they get fired.

Winning the game. We have heard over and over again from every head football coach that the game plan and strategy is only as good as how well the players execute it. After all, the game is played on the field. So what are some of the key things a coach (project manager) can do?

1. Put the players in the best possible scenario for them to succeed For example, don’t ask an immobile quarterback to run rollout plays. For a project, this means getting the right resources lined up for the job.

2. Monitor the execution Adjust the game plan tactically based on internal or external influences (someone gets hurt, the other team is doing something you didn’t plan for). For a project, this means regular status updates and strategy reviews that may lead to resource changes.

3. Keep your eye on the “big picture" (“winning isn’t everything, it’s the only thing” – Vince Lombardi). For a project, this means getting the system implemented or developed and obtaining the desired benefits is the only thing.

"Sometimes modifying an ERP system can result in these. (2 words )"

E D N U N I T D N E   N S C E O U Q N E E S C

_ _ _ _ _ _ _ _ _ _   _ _ _ _ _ _ _ _ _ _ _ _

Answer to last month's word scramble.

"One of the characteristics needed in an organization to implement ERP." ( DISCIPLINE)

Look for more timely and relevant content on real world ERP and Enterprise software issues including cost of ownership, change management, Business Intelligence and more . . . delivered right to your in box. Please keep checking the INNOVATIVE WEB SITE for useful tips, and our newsletter archives. Amaze your friends and colleagues with your expertise!

ERP Systems - dealing with modifications.

How Close is a Close Fit?

Tip of the month.

Execution - the Key to Success.

Word scramble.


Innovative Ideas
in your Inbox

If you would like to receive Innovative Ideas as an Email Newsletter, please sign up here: