SAP & ERP Business Alignment Answers for IT Leaders

Today’s IT landscape is filled with hype around Web 2.0. While collaboration is a key forward looking initiative for any organization it requires a specific purpose and goal. Without a clear direction and purpose for social media initiatives they are at best a distracting fad, and at worst an enterprise disaster.

Anyone who carefully and objectively looks at today’s “Twitter” and “Facebook” applications can see that they are a fad. Popular today, and they will be around for a while, but like all “social” outlets they are a fad waiting for the “next big thing.”

Are they important to the IT organization and future? Yes, but ONLY in the context of a genuine and legitimate business purpose.

Social Media Study Shows Current Tools Have Little Value In the Enterprise

The other day, while on a flight to a client site, I picked up the airline magazine and read through a Harvard Business Review synopsis of an experiment done with Facebook and an Austin based company.   Although very upbeat about promoting the wonders of using social media there is little real evidence of consumer behavior changes that could be attributed to Facebook.

First, a little over 2% of the thousands of customers the company contacted actually joined Facebook.  The ones that did were already “raving fans” of the company.  They did slightly increase their overall spend BUT, it is really unknown if the increase in spend wasn’t more related to the offers and promotions on Facebook rather than the use of the medium itself (in other words, would other marketing channels to provide similar offers have produced similar, of even better results?).  Very few new folks were added to Facebook over the 3 months of the experiment…  Etc., etc., etc.

There is little value to the organization in any form of customer conversion and that the bulk of “fans” for a company on facebook are those people who already like the company.  It is questionable if the medium had any bearing on changing customer buying behavior beyond other types of marketing–, it’s efficacy as a sales source is debatable.   So, in the end, Facebook and other social media outlets may just be all hype.  And keep in mind, in the particular experiment there was a business purpose, and there was promotion and coupon activity.  So if in the end it turns out to be an effective marketing medium it must be looked at as a small part of an overall marketing portfolio with limited appeal to customers who are already some of the best buyers.  The next question would be whether or not there is any cost / benefit.

The facebook study confirmed my suspicions about the “value” of these type of social media outlets in the enterprise. That does not mean that some types of social media do not have a clear place in the enterprise, only that today’s hype is overblown and risky to business.

Social Media and Collaboration Must Have a Specific Business Purpose to Have Any Value

In a nutshell, as I have written

“Collaborative initiatives that are divorced from a specific business purpose are disasters waiting to happen.”

From Collaboration to Innovation to Market – Toward a Working Model
http://www.r3now.com/from-collaboration-to-innovation-to-market-toward-a-working-model

I’ve been working with collaboration technologies as a Knowledge Manager for about a dozen years now. I started with collaboration tools in the enterprise long before the hype and the Web 2.0 fervor and I say the hype is all HOGWASH!

Based on my years of collaboration experience, a short excerpt from a recent post:

ERP III – Is the Integration of Collaboration the Future of Enterprise Applications
http://www.r3now.com/erp-iii-is-the-integration-of-collaboration-the-future-of-enterprise-applications

Too many organizations undertake the introduction of social media for the purpose of introducing social media into the enterprise. Again, this is like having information without the context of application and experience. That information is NOT knowledge, nor are collaboration tools which are divorced from a specific business purpose very productive (if at all).

Niether consultants nor business has learned how to use social media to drive business value. There are few consultants out there with a coherent or even minimally functional method for business to use collaboration tools to propel a company’s key value propositions.

What say you?  Are you considering social media in your enterprise?  If so, does it serve a specific business purpose or objective?

Over the years I’ve been on projects where there was great project management and others where the project management really stunk!  The projects with really good project management generally ran smoother, had less stress, and the project team was generally more productive.

A FEW of the Characteristics of a Well Managed ERP Project

There are a few things that I saw which were consistent with projects that were well managed.  In a nutshell they are summed up in the following key points:

1. The project manager produces a published project plan with tasks, timelines, deliverables, milestones, and checkpoints.
2. The project plan was at sufficient detail to manage the rolled up tasks, but not so detailed that the individual tasks were micromanaged. 
3. Team leads had individual responsibility at a deliverables level.
4. The deliverables were constructed at the detailed task level so that their progress could be reported to the rolled up project task.
5. The project manager knew ahead of time what was coming in the next major phase and communicated that to the whole project team ahead of time, and at the transition times to the next phase.
6. The “tools” or deliverables templates, resources, and tracking mechanisms were defined AHEAD of time, and then presented to the whole project team with explanations on what information was needed and how to use them as they were needed (JIT or Just In Time).
7. Team leads held regular weekly status and progress meetings on deliverables status which was then regularly reported to the project manager and directly tied into the rolled up project tasks.
8. There were several scheduled proof of concepts / prototypes / demos of functionality long before a solution went to testing.

This list is fairly generic and can be applied to just about any project.  Many, if not all of these items may seem common sense, intuitive, or basic but you would be shocked at how many projects deviate from these basic principles. 

SAP Prototyping, Proof of Concepts, Functionality Demonstrations, or Playback Sessions

And that last item, the numerous proof of concept reviews, prototypes, or functionality demonstrations throughout the project were critical.  These prototyping sessions were valuable because if they were properly scheduled (early and often) they quickly reveal:

• Consultants who might be better on your competitor’s project(s)
• Areas for genuine business value-add or ROI that might require a scope adjustment but the benefit far outweighed the cost
• Capture and correction of process gaps before integration testing
• Adjustment to process focus through better articulation of business need after “seeing” what functionality is there
• Identification of gaps and risks in application functionality
• Indicates whether your outside project manager is able to coordinate the necessary work-streams to accomplish the proof of concept sessions
• Work through and resolve any early warning signs of performance problems

By insisting that your first proof of concept or prototype session occur right at the end of blueprint you have sufficient time to make any necessary staffing adjustments.  Maybe your competitors need some “help” on their projects :)

Warning Signs to Be Aware of In Prototyping

The first warning sign is if a prototyping session or timeline is missed without a clear justification.  For example, if the system landscape was not set up in a timely manner to construct the demo or prototype.  Unless this was due to procurement, logistics, or security issues outside of the project manager’s control then this should be viewed with suspicion. 

If there are SAP or ERP application problems which cause the delay you may want to take a hard look at any consultants who are responsible for installing and maintaining the various software applications.

Another warning sign is if the prototyping sessions are chaotic, disjointed, and generally fouled up experiences.  Usually this will fall into two categories, either a) the project manager is not as experienced as you might need, and therefore might be better off working for your competitor(s), or b) the project timeline might be too tight and there is not enough time to do the prototyping in a proper manner.  How can you tell the difference? 

There are lots of things to consider, but here are a few:

• Is the problem because one key process area is not ready
  • Is the dependent process, or process bottleneck too complex for the time frame?
• Would a few more days make a significant difference in the readiness, coordination, and execution of the prototype / demo?
  • If only a small time adjustment is needed, and there are obvious or clear results from just a few days, the timeline might be a little too tight
  • If a short delay does not produce a significant improvement in the organization of the prototype presentation as well as the fit and finish then you may have a project management or a consultant problem that needs to be addressed

To gain additional insight on this critical stage of the project, especially in the beginning when a properly formed foundation is so critical please see the post entitled “Breakthrough Project Success: Part 4 of 4, Last Low Risk Chance for Results.”

Recently I went on a sales call to propose for helping a fairly large retailer do a software selection and then a vendor selection.  Because of my many years of experience with SAP one of the initial concerns they raised was whether or not I could be objective and unbiased.  That is not only a fair question but a critically important question.  

I decided to approach this sales presentation effort in a very different manner by providing solid, verifiable, and objective methods to evaluate software fit as well as vendor fit.  Although the proposed client company was very gracious, accommodating, and well-meaning it was painfully obvious that another presenter’s bias toward JDA software was apparent.  

Because of what I perceived (possibly wrongly so) as a previous sales “snow job,” I decided to begin a series on software selection.

Every Company Wants to Make the Right Software and Vendor Selections

I know for a certainty that this prospective client, like so many others, want to make the right decision for their company.  I also have no doubt that the CIO, the Supply Chain VP, and all of the others present want the very best for their company.  Frankly I’m not so sure they are making the best decision and only time will tell.

During the presentation I was peppered with several SAP specific questions although I was clearly not coming in to propose or push SAP solutions.  In fact I went to significant measures to ensure the presentation was as unbiased and as substantive as I could possibly make it.  I even went so far as to provide them with a clearly objective and proven method for software and vendor evaluation which is widely accepted, reliable, and fairly mature.

In the end the selection went to another company.  I am not sure if it was the company who proposed JDA who also slammed SAP and brought in lots of articles but I thought it was important to clarify a few things here because of the slimy sales scams that appeared to be presented.

JDA, i2, and Software Acquisition New Customer Ramifications

Serious considerations for JDA “supply chain” customers:

• JDA just acquired i2 Software
• i2 was ignored by Oracle in it acquisition bender [FN1]
• In terms of financial payments the purchase price was barely above the company’s annual revenue [FN1]
• i2 internal development and investment has been dormant for about 5 years
• On top of that, with an active R&D development plan and funding it would take at least a couple of years to integrate i2 into the JDA application

For the client I just visited that last item on the bullet point list above should be frightening. Translated into practical application, if this company chooses JDA based on their acquisitions of i2 and Manugistics they will likely be paying a whole lot more for development and implementation than they ever planned for or budgeted.

I wish this company the very best in their efforts, and I hope that we might be able to do business at some point in the future.  But whether we do or not I am a little disgusted with many of the software sales scams and shell games.  So, I am going to begin a series of posts to help companies everywhere understand software selection workings, the sales scams, and the methods to prevent them.

Dennis Howlett at ZDNET notes of JDA’s acquisition [FN2] that:

“[T]he combined company expects to ramp up  EBITDA to 23.9%, in part based upon $20 million near terms savings but also combined maintenance revenues of 46.9% total revenue. I’d prefer to see JDA invest more heavily in innovation for the vertical markets in which it has successfully focused.”

So, based on shareholder financial communications it would appear that no development will occur to i2 without JDA sales efforts being able to find customers to fund the development.  Good luck to any customer undertaking JDA / i2 supply chain projects, these companies often find those “development dollars” in someone’s pockets when they won’t directly fund their own R&D initiatives.

After I left I provided this prospective client with a clearly defined selection methodology and followed up the meeting with more solid, substantive information on how to ensure that they select both the very best software for their company, and the very best vendor to implement that software.  To that end I sincerely hope they do not make the mistakes that many companies do when embarking on these selection activities [FN3]. 

Upcoming Series on Using the AHP Method for Software Selection

I have decided to fully develop and provide freely over the next several weeks and entire selection methodology that anyone can follow.  I will lay out much of the key academic research as well as key templates, considerations, approaches, and guidance on performing useful software selection efforts.

Stay tuned for this software selection series over the next several weeks.

[FN1] i2: The Software Company Even Oracle Didn’t Want http://www.typepad.com/services/trackback/6a00e55185411c883300e553f9317b8834

[FN2] JDA acquires i2: Oh how the world has changed http://blogs.zdnet.com/Howlett/?p=454

[FN3] How to Kill Your Software Selection Project in 10 Very Easy Steps

http://blog.technologyevaluation.com/blog/2007/12/06/how-to-kill-a-software-selection-project-in-10-very-easy-steps/

 The following site was also referenced for some of this information.

JDA to acquire i2, creating major SCM player

http://fscavo.blogspot.com/2008/08/jda-to-acquire-i2-creating-major-scm.html