Quantcast
Subscribe!

 

Enter your email address:

Delivered by FeedBurner

 

E-mail Steve
  • Contact Me

    This form will allow you to send a secure email to Steve
  • Your Name *
  • Your Email *
  • Subject *
  • Message *

free counters

Twitter Feed

Entries in ERP (9)

Wednesday
Sep222010

Oil changes for life

Quick show of hands - do you change the oil in your car yourself, or once every few months or so roll up to the local QuickJiffySuperFast Lube place and have someone else take care of it?

I will bet most of you don't change your own oil any longer.  There are plenty of reasons why these lube places seem to be on every corner.  Changing the oil yourself is a hassle. It is a dirty, occasionally difficult job.  Engines have become increasingly complex over the years making even simple maintenance tasks beyond the skill level of the average motorist. On many new cars, 'oil changes for life' done by the dealer are part of the purchase discussion. Disposing of used oil is a real hassle, (I don't want to tell you what my Dad had me do with the used oil from his cars back in the day).

For the vast majority of drivers, we need our cars to take us where we need to go, in relative comfort and safety, and really can't be bothered with the grease, spare parts, and complex systems that make the car 'work'.  We just need it to work.  And more and more, we want our cars to do more, embedded GPS, enhanced safety capability, better fuel efficiency (maybe no fuel at all), and able to provide backseat entertainment for the kids. Oh yeah, and also pop a warning light on the dash when it's time to change the oil.

I have been sitting in sessions this week talking about the approach to another major ERP system upgrade.  It is just as you would expect, an old version of the suite, (and really showing its age), installed on-premise, loads of customizations, with application and database hardware probably not equal to the task.  Major, major cost and effort to effect this upgrade. Nothing (save the data) in the current deployment to remain.

I even heard a random, 'this is going to take 18 months', comment tossed about.  And the thing is, the 'latest' version of the suite the organization would be upgrading to, is already a few years old. Tack on the time for planning, testing, re-training, and deploying and by the time the effort is complete, the organization will be the proud owners of a five year old system. 

 

Lots of time and effort by dozens of smart people working hard to deliver a 'slightly pre-owned' system to a set of drivers/users that really just want all the best features of the newest models on the road. Systems that have the newest capabilities, features, updated interfaces, integration with internal and external social networking, mobile apps, and more.

And oh yeah, toss in the 'oil changes for life' and we have a deal.

Thursday
Sep032009

Time to Stop Digging

This is what was said in the Enterprise Systems planning meeting:

We have to expand the ERP system footprint, get more business processes integrated, really 'use' the system, and maybe we will start to see the return on investment that we've been waiting for.

This is what is closer to the truth:

We've sunk about $5M into this, we are in upgrade, maintenance, and crappy UI hell, so we better figure out a way to make this seem worth it to the executives or we're all in trouble.

The exact amount of the sunk cost in the installed system is not really the issue, it's more the fact that whatever the (large) investment was, many organizations are at the crossroads.

They've implemented big ERP systems for core HR, maybe payroll, tossed in a bit of self-service, perhaps dabbled in workforce management, but more or less have not really leveraged the capabilities of the massive system.

To the left, upgrade the ERP, get on the latest release (a daunting proposition for many), and try to take advantage of the new capabilities and features that are available (that will never be backported to your release from 2002), and upgrade the UI to something that looks relatively modern.

To the right, scrapping the upgrade, patching the legacy ERP together for employee tracking, payrFlickr - AidanBrooksoll, and benefits and looking to a modern SaaS-based platform for more strategic functions like Performance Management, Succession Planning, and Learning and Development.

Now there is even a third option, tossing the ERP entirely and moving to a SaaS HR system that will over all of those processes like Workday.

Obviously there isn't a blanket one size fits all solution for organizations in this predicament, and I won't offer any sweeping recommendations, but I will say this:

When you have dug yourself into a deep hole, it's probably time to stop digging.

Friday
Apr172009

ERP and the Ford Taurus

Ah, 1997.

Elton John's Candle in the Wind was on the charts, you saw Titanic two or three times,  and one of America's top selling cars was the Ford Taurus.  Maybe you bought one, or more likely had one as a rental car. I swear I drove a Ford Taurus something like 72 weeks in a row when I was still in ERP consulting. 

 Stylin' in the Taurus

She's a beauty, no?

You know what else you might have purchased in 1997? 

Your ERP system. The same one that still runs your HR, Payroll, Accounting and Distribution processes.  In 1997, about $14B was spent by organizations on ERP.  By now you would have had to go through two or likely even three significant upgrades, each one getting progressively more complex, costly, and time consuming.  But underneath it all, the chances are the 'core' of the system is still largely the same as the 1997 model.  The data model you are using today, is probably largely unchanged from the original version of the system you implemented in 1997.

What about your business? How many things have changed since 1997?  Would you still make the same ERP purchase decision today that you did in 1997, when chances are you were in a panic over Y2K and you were pretty sure your Cobol mainframe system was going to spontaneously combust?

Is it really time for your organization to begin to let go of the loyalty to a system you bought over a decade ago? 

Many organizations still feel the need to only look to their ERP solution and try to add-on Talent Management functionality, or the ATS module rather than do a comprehensive assessment of the market, the business issues, and make an informed decision about the right technology solution for the business. 

You eventually sold (or junked) that '97 Taurus, didn't you?

NOTE : I ran this post, more or less on my old Wordpress blog, but after an interesting Twitter chat with Byron Abramowitz and Michael Krupa about ERP, upgrades, and creaky data models, I decided to run it today.  Also, it was WAY easier than writing a whole new post.

Saturday
Mar212009

When 'free' can be very expensive

You are a mid to large size company.  You bought and deployed a big ERP solution for your HRMS, Payroll, maybe your Accounting and Procurement as well. Flickr - JeffChristiansen

It was crazy expensive, likely took longer and cost way more to implement than you figured, and you ended up making lots more customizations than you had planned for (despite the initial desire for a 'plain vanilla' project).  Aside - you know your Project Manager used that expression at least 10 times in the beginning.

You finally have the ERP running relatively smoothly, to the point where it's time for other long put off projects to get considered.  More 'strategic', high value-add type projects. Things like a new Applicant Tracking System, an automated Performance Management tool, or perhaps Succession Planning.

But in these tough economic times, do you even have any funds for new software?

After all, you are locked in to some hefty annual maintenance/support fees for the big ERP system. But wait, the ERP system can support all these 'strategic' processes. And five years ago, when you hammered out the ERP license contract, you made sure that you would have the right to use all those modules at any time in the future at no additional cost.

It's a no-brainer then, right?  You will simply use whatever functionality that is inherent in the ERP package for your new ATS or Performance Management solution. It is already paid for, it integrates with the rest of the system, and you have functional and technical staff who know the technology.  Slam-dunk.

But wait a second, five years ago when you did your due diligence in the ERP purchase process, did the modules for ATS, Performance, or Succession even factor in to the discussion?  Did you even consider them at all? If you approached ERP selection like most organizations, you spent 95% of your energy on things like integration, technology, and 'core' business processes.  These are all important, and it was altogether fitting and proper that they were the priority. 

But now, when you are ready to deploy some of these 'strategic' modules, are you realizing that while your ERP package supports them, they are difficult to use, don't offer most of the latest advances in the technology, and are not well-received by your end users?  ERP packages are developed and sold from the 'inside-out'.  The tight integration, the unified database, the ability to leverage tools like workflow and security management across a wide swath of the enterprise is what 'sells' ERP.

No one, I mean no one, ever bought an ERP solution for the wonderful E-recruitment capability, or for the fantastic Performance Management module. 

It is a concept that has been repeated for 20 years, it is almost a cliche, but it usually bears true. The big ERP packages simply cannot be as good at all the ancillary strategic capabilities as the best-of-breed vendors.

And when you implement ERP-based, sub-standard capabilities for ATS, Performance, or Succession, areas that impact a much, much wider audience than your core HRMS, you had best be prepared to justify and support that decision. 

When the candidates, hiring managers, line managers, and executives start complaining and griping about the solutions that you have implemented, and adoption rates are slower than you would have liked,  is your primary response going to be, 'Hey it was free'?

'Free' can be very expensive.  Implementing software just because you have already paid for it can be a very costly mistake in the long run.

 

 

 

 

 

 

Monday
Mar162009

Planning versus Adoption

Recently, a Twitter conversation regarding the success or likelihood of success of so-called 'Enterprise 2.0' projects made me consider some of the fundamental differences between Enterprise 2.0 and more traditional corporate software project implementations, like ERP.

Traditional

The planning, testing, and prototyping steps are typically quite lengthy, frequently involving many months to even years, but once the 'go-live' date is reached, you have almost 100% adoption rates right away.

If you were to chart traditional ERP project timelines and user adoption levels it would look something like this:

Think of major system implementations for Core HRIS or Accounting. The 'adoption' of these systems is not 'optional' for the vast majority of end users, it is normally an 'all-or-nothing' proposition. The old systems are turned-off, and all users almost simultaneously 'adopt' the new system on Day 1.

Enterprise 2.0

Contrast that timeline to a typical Enterprise 2.0 deployment, where the software tools themselves are dramatically simpler, the time spent planning prior to deployment is usually significantly less, but achieving higher levels of user adoption can be much more difficult and take much longer.

These projects may be internal social networks, blogs, micro-sharing, wikis or idea markets, but commonly they are presented as 'alternatives' to traditional ways of communication and collaboration. Companies, at least initially, rarely 'force' adoption, rather they try to 'build' adoption through training, word of mouth, a visible internal champion, or small pilot programs.

Companies don't get rid of the e-mail or voice mail systems just because a new wiki is available.

Consequently, the length of time required to achieve full or the desired levels of user adoption could actually be longer for these on the surface 'simple' applications.  Of course 'time' is not the only important factor to consider in any kind of enterprise implementation, but it is certainly an important component.

These large E2.0 projects are probably not going to be any simpler, faster, and less problematic than traditional projects.  But, they will present a whole different set of problems for the organization, the kind of problems that many 'traditional' project managers and organizational leaders may not be prepared to address.

What two or three things can E2.0 project leaders do to try and mitigate these issues?