SAP ROI -- Enterprise Architecture & Business Solutions

9 Games ERP Consultants Play

Steve Phillips — Mon, 14 Jan 2013 12:25:04 +0000

ERP Consultant Games

Most in the ERP industry agree that software consultants can play a major role in helping their clients successfully implement a new ERP package. While some consulting firms have more expertise than others do, at least most firms try to operate with their client’s best interest in mind.

However, there are many firms within the ERP industry that are outright thieves. They will not hesitate to take advantage of their clients in order to pad their own wallets. In fact, some firms are so good at this it has become part of their standard operating procedures.

Clients that are educated and aware of the games consulting firms play can save themselves a few headaches and a lot of money. Below are some of their tricks to watch out for.

1) The “Bait and Switch” Routine

During the sales process, this is when certain consultants are brought in to display the expertise within the firm. They may know best practices and the software, but it might be the last time you ever see them.

2) Resumes: Lies and Half-Truths

Outright falsification of consultant resumes is more common than you think. In addition, many resumes presented by the firm are not really resumes, but vague “profiles” that lack detail and read like sales literature.

3) “Lowballing” the Quote

This is the oldest trick in the book, yet surprisingly many clients continue to fall into this trap. For example, all consultants know that for time and material quotes the actual implementation costs are usually much higher. Also, most fixed price quotes are only fixed until further notice. When the client wants to make only minor changes in the project scope, they are hit with expensive change orders. The change order costs are usually 100% greater than the actual time for the consultants to perform the work.

4) The “Best” Implementation Tools & Methods

Most firms claim to have the very best implementation methods and tools available. However, do not be surprised when their consultants run off and do something entirely different during the project. Maybe the tools are not so great; otherwise, their consultants would use them!

5) The Less You Know – The More Money They Make

For some firms, a potential client that has ill-conceived project objectives, an undefined scope, or lacks basic knowledge of ERP; is considered a gold mine. The idea is to gloss over these “minor” details until after the client signs the contract.

6) Marquee Accounts for Reference Checks

When a potential client asks for a list of the firm’s other clients for a reference check, many firms provide only their “marquee accounts”. These accounts are compensated by the firm in some form for being a reference. Therefore, do not expect these clients to mention anything bad about the firm.

7) Not Enough Time and Talent

Most consulting firms would love to “camp out” on your ERP project. One way to do this is convince the client that the organization lacks the right employees for the project. Also, some firms too easily support the premise that the client’s best employees have other tasks to perform that are more important than an ERP project. That is, “No need to get your hands dirty. Our consultants will do the project for you.”

8) “Add-on” Services

Once consultants get their foot in the door, many try to sell their clients additional services. These include more consultants for readiness assessments, change management programs, best practices, and other services you may not truly need. Also, do not be surprised when your consultants push for software functionality that was originally out-of-scope.

9) The Promise of Software Knowledge Transfer

Most firms state that one of their goals is to “work themselves off the project” by transferring software knowledge to the client. However, nine times out of ten, if it is going to happen, the client must force the issue. Considering their hourly rates, what incentives do consultants have to transfer software knowledge?

This guest post is by Steven Phillips, author of the Street Smart ERP blog and the new book Control Your ERP Destiny.

=========================

Contact me today through our site contact form ( http://www.r3now.com/contact ), phone, or e-mail.

Bill Wood
+1 (704) 905 – 5175

=========================

Will SAP HANA Lead to a Big Data Revolution?

Bill Wood — Mon, 17 Dec 2012 12:40:31 +0000

SAP HANA – Big Data

Lots of folks focus on HANA as a competitor to Oracle, and it is. Even if HANA adoption and sales were to completely devastate SAP’s biggest competitor (Oracle) that would not be HANA’s biggest impact–, the HANA product has the potential to disrupt entire industries in the context of Big Data.

Unlike Big Data, I’ve been skeptical about the benefits and use of social media in the enterprise, writing about it in Why Social Media Marketing Success Is Elusive for Business and Social Media Fads and the Risk to the Enterprise. On the other hand, Big Data hasn’t gotten anywhere near the attention even though it has a fairly clear business case. Big Data has the capability to transform enterprises, organizations, and even entire industries. We are not talking about abstract “build it and they will come” theories here either. We are talking about a revolution in the way business is done.

Big Data will have huge impacts on customers, products, even whole regions of the world. What do I mean when I refer to Big Data?

BIG DATA: The ability to analyze large volumes of both structured data (like transactional data streams) AND unstructured data (social media, industry information, news trends, etc.) leading to market makers and market losers across virtually all industries.

This ability to synthesize structured and unstructured data streams with technology advances WILL transform companies and industries.

Over the next 5 – 10 years:

Computing power will continue to grow.
High speed memory processing (like in SSD drives) will improve.
Massive memory storage will come down in price.
In-memory database technologies will mature.

This “perfect storm” of Big Data know-how and technology advances will lead to the ability to identify:

Subtle and even unknown market segments.
Market and sales trends.
Customer sentiments, needs, and wants.
- Leading to new product or service opportunities.
Competitor strengths or weaknesses.
Etc., etc., etc.

Big Data will be part of the ERP iii [FN1] technology innovation driving customer focus related to customer acquisition, customer retention, and marketplace performance. Big Data represents a business transformation shift in how business will be done in the future–, it represents a potential seismic shift in business performance in the marketplace.

The Big Data Revolution

The struggles are the semantics in how to synthesize the information and filter the nuggets from the noise. Big Data allows you to understand what the keys are in terms of words, concepts, and ideas. It then allows you to synthesize those keys with the various data sources.

In other words, how do you take the product sales information (transactional data), customer demographics (transactional), corporate market knowledge (unstructured internal), key word search (semi-structured internal and external such as with Google or Bing), with marketplace intelligence (unstructured external, including external social media), and innovate new or existing products and services? That is the challenge that some folks are beginning to work on today. That is the challenge that SAP’s HANA product enables for the future enterprise.

Big Data means “Business Intelligence” will finally become, well, intelligent!

————————-

[FN1] For more information on ERP 3 see this comprehensive ERP treatise ERP vs. ERP II vs. ERP III Future Enterprise Applications.

=========================

Contact me today through our site contact form ( http://www.r3now.com/contact ), phone, or e-mail.

Bill Wood
+1 (704) 905 – 5175

=========================

SAP Third Party – Indirect Usage Licensing Part 2

Bill Wood — Mon, 03 Dec 2012 12:20:25 +0000

SAP Software License

For those who may not be aware, SAP is not the first company to require user licenses for third party or “indirect usage.” It is becoming more commonplace and some companies are quite aggressive with it. This follow up to last week’s post on SAP Third Party – Indirect Usage Licensing Part 1 will address real opportunities here.

Over the years SAP has set itself apart by aggressively pursuing sales while generally maintaining good customer relations. It is a balancing act that has served SAP well. Over the years SAP has avoided the market perception of a ruthless, do anything to get the sale, software vendor.

This whole third party, indirect software usage can undermine that.

But there IS an answer!

SAP Are You Listening? There IS a Third Party / Indirect Usage WIN-WIN Here!

Like any other company, revenue growth is a primary focus. For software companies, directly related to revenue growth there is also expanding the software footprint within the customer base.

SAP as a company wants to grow revenue and expand their software footprint. What if there IS a way to achieve this AND satisfy your customers too.
Would you agree this would be a WIN-WIN?

Customer Perception of the SAP Third Party Indirect Usage Licensing

Purchasing licenses for “indirect usage” feels to a customer like they are paying for something and not receiving any benefit. There is no “value” in this approach from a customer perspective. Yes SAP, you have your Intellectual Property (“IP”) to protect, and yes, you developed that IP.

I am not talking about a legal issue with your IP, instead I am referring to a sales, marketing, and customer relations issue.

Add a customer’s lack of awareness to the perception of “no value” and you have a recipe for difficult customer relationships. SAP third party or indirect software usage presents an unbudgeted “pure expense” from a customer viewpoint. Most customers really are not aware of the indirect usage requirement so they don’t budget for it!

SAP, Your Third Party or Indirect Usage Answer

Provide your customers a value added alternative to indirect usage or third party compliance issues. Give them an option to substitute the third party or indirect usage cost they would have incurred in the form of other SAP applications or solutions. In this way your customers are receiving something of value, you are expanding your software footprint, and you are still gaining the revenue you were looking for without the nasty reputation. If necessary, give them a deferred payment window so they can plan for and budget the change.

Provide your customers a value added alternative to indirect usage or third party compliance issues.

You can gain a HUGE advantage by targeting certain application deployments–, for example if you want to expand your Cloud sales, HANA, or mobile, you could pick the various products you will allow as a substitute for the indirect usage fees. This in turn boosts your sales of these newer products and provides your customers with something that is meaningful. This has huge strategic benefits, for example, each HANA sale potentially displaces Oracle. Each CRM sale substitute (for the indirect usage) potentially displaces Salesforce.

Expand Application Footprint and Increase Revenue

ALWAYS be ready to trade the 3rd party integration for a deeper footprint which keeps a competitor out of the client. Clients benefit from new software capabilities and SAP benefits from a revenue stream WITHOUT the negative relationship consequences of “forcing” the 3rd party maintenance issue. This also becomes a differentiator with Oracle and other vendors who will push the 3rd party issue. SAP STILL gains the additional revenue.

ALWAYS be ready to trade the 3rd party integration for a deeper footprint which keeps a competitor out of the client

You could structure contracts to defer 3rd party usage fees by adding some tradeoff in contracts like “as long as annual license revenue is at least ‘x’ no 3rd party licenses.” By doing this you are taking a “gentler” approach in preparing customers for a possible future license event. This takes the surprise, frustration, and shock out of the equation while keeping your revenue stream more predictable and giving them a chance to budget for the spend.

Conclusion on SAP Indirect Usage or Third Party Usage Sales and Marketing Options

Seriously SAP, you have a LOT of options here. You can be less adversarial and note that you will defer indirect usage or third party fees as long as a customer’s annual, net new license spend is “X” amount a year. If they need new licenses for additional users the customer perceives this as a benefit and they can gain additional time to budget for an eventual indirect usage fee. You are still satisfying your CORE requirement to grow revenue while increasing your solution footprint within your customer base AND in a way that is less offensive than the customer perception of a cost for no benefit. Many customers look at this as a penalty for choosing SAP solutions. While the IP is yours SAP, it is offensive to a customer because the data and business are theirs.

This creates a more open environment and many more customers may be willing to “come clean” about indirect usage. By providing some kind of perceived benefit they are more likely to address the compliance (rather than hiding it) AND the customer AND SAP gain something of value. Talk about a “Win-Win”!

=========================

Contact me today through our site contact form ( http://www.r3now.com/contact ), phone, or e-mail.

Bill Wood
+1 (704) 905 – 5175

=========================

SAP Third Party – Indirect Usage Licensing Part 1

Bill Wood — Mon, 26 Nov 2012 12:40:31 +0000

SAP Software Licensing

Many SAP customer license contracts contain either a direct or an indirect reference to SAP’s third party usage licensing requirements. That requirement is referred to as “indirect usage” and carries a hefty potential financial penalty. The basic idea is that if you use any non-SAP system to access SAP data the user of that external system must acquire an SAP Named User License.

While I understand SAP’s argument that if you use portions of the SAP software (BAPIs, RFCs, Function Modules, etc.) that you are using their Intellectual Property (“IP”) then they should be paid for that–, it still frustrates many customers.

Where is the Reference to Indirect Usage?

Unless you have explicitly negotiated OUT (or around) the indirect usage it is most commonly contained in SAP contracts in 1 of 2 ways. It is either explicitly spelled out in the contract language, OR it is buried in some boilerplate language related to the order in which any contract confusion (or dispute) is to be resolved. Frequently that language lists a hierarchy which references the SAP Price List.

The SAP price list (in its January 2012 form) is currently over 120 pages AND contains detailed language related to indirect usage. When it comes time to Untangle SAP Software Licensing your organization should become very familiar with its various provisions. Like it or not most contracts do subject you to the price list’s terms. You might as well consider that 120+ pages part of your contract.

SAP Indirect Usage or Third Party Usage Enforcement

Recently SAP has gotten more aggressive about customers paying for third party system connections to SAP applications. The current push is that you must have a Named User License for any user who gains access to SAP data – even from external systems. While there are some narrow exceptions the push is to just license any user who acquires the data.

From a customer standpoint Indirect Usage or Third Party Usage creates no value. It only creates friction, frustration, and mistrust between SAP and their customer base.

In a recent license and contract negotiation with SAP and a fair sized customer, with a significant annual license and maintenance spend rate, this issue came up. It became a major hurdle to reaching a reasonable agreement that everyone could be happy with. While SAP was willing to concede special Named User licenses for the Indirect Usage (at a very low cost) it was still a problem. The customer perspective is that if they decide to use another vendor’s product, and are not engaged in some unethical means of SAP software use to avoid paying SAP licenses there shouldn’t be any fee. This is becoming a serious issue because from a customer standpoint Indirect Usage or Third Party Usage creates absolutely no value. It only serves to create friction between SAP and their customer base.

The current focus seems to be on going after third party applications such as Salesforce.com which serve to displace SAP’s own CRM solution. The SAP User Experience has become a big part of the reason many customers choose alternative solutions and SAP has got to do a better job of addressing that. Because of SAP’s CRM application shortfalls I have also suggested SAP consider SugarCRM as The PERFECT SAP Acquisition Target, but the real issue is that sales people and customer facing processes want “pretty.” The SAP CRM option comes up short in the “pretty” and usability category.

There are options for SAP customers, and there are better options for SAP as a software vendor. Yes SAP, there actually is a way to grow your revenue, increase your software footprint AND have happy customers too! There really is a way to “have it all” if you will consider it!

The discussion next week is around an SAP Sales and Marketing option which can significantly change this customer pain point. It will help set SAP further apart from competitors while still growing the application footprint AND increasing revenue. SAP, if you’re reading this, you don’t want to miss next week’s post!

=========================

Contact me today through our site contact form ( http://www.r3now.com/contact ), phone, or e-mail.

Bill Wood
+1 (704) 905 – 5175

=========================

Storms Coming on the Salesforce.com Cloud Front

Bill Wood — Mon, 19 Nov 2012 12:30:43 +0000

Salesforce.com financial clouds

I recently ran into a post from a pretty well respected investor blog over at “Seeking Alpha.” The basic takeaway is that the Salesforce.com cloud business is not all it is hyped up to be and that shareholders may be in for a seriously rude awakening [FN1].

——————–

The way it is described there sounds a LOT like Enron accounting. They called it a Ponzi Scheme and here is how it works:

Employees receive stock options INSTEAD OF cash compensation for various raises, bonuses, etc.
Salesforce.com takes the DIFFERENCE in stock value that they gave to their employees (an expense under GAAP and IFRS) verses what it WOULD HAVE COST in cash and books THAT DEFERRED COST as actual cash flow. Viola! Magical cash flow appears!
THEN they add the “saved cash flow” (deferred cost, i.e. Expense) to non-GAAP earnings as “profit” thereby doing a complete Enron to convert an expense into profit.

So, let’s sum this all up. They issue more stock certificates, they provide them to internal employees, then they simply count the stock certificates as profit. WOW! That is some creative accounting.

The post goes on to explain the shareholders have their share value diluted, not necessarily in dollar terms in the SHORT TERM, but most definitely in quantity terms in the short term. It is only a matter of time before it all catches up with them however. Their whole premise is the Salesforce.com Cloud sales model is unsustainable in the mid to long term.

An added expense to the shareholder is the dilution that these increasing stock-based compensations are causing. Every quarter, the share count is rising. So the shareholder is fooled in a double manner. By dilution and representing costs as profits.

They go on to add that while some investors may be fooled in the short term on the non-GAAP claims the GAAP numbers tell a story that the company may have some very serious storm clouds ahead.

Without deeper insight, instinct would tell you there must be a catch, simply by asking the following question: How can you raise cash by spending more than you earn? Spending more than earning is exactly what Salesforce.com is doing, as evidenced by the company’s increasing GAAP losses.
The summary is that Salesforce.com excludes the huge expense of stock based compensation to present NON GAAP profits (masking that this expense results in GAAP losses), but on the other hand they include it in their cash flow statement to present rising cash flow (masking that true cash flow from operations is falling).

Consequences of a Salesforce.com Stock Fall

A Salesforce.com stock slide would have significant ripple effects across all of the software space, but most aggressively on any of the cloud vendors. Because it is such a high profile cloud vendor, and a high profile CRM software company, the effects would likely have at least some short term impact even on companies like SAP.

[FN1] Salesforce.com Accounting Shenanigans Explained

http://seekingalpha.com/article/857361-salesforce-com-accounting-shenanigans-explained

=========================

Contact me today through our site contact form ( http://www.r3now.com/contact ), phone, or e-mail.

Bill Wood
+1 (704) 905 – 5175

=========================

Where Does Agile Fit in SAP Projects?

Bill Wood — Mon, 12 Nov 2012 12:30:47 +0000

Agile SAP Success

After offering insight based on my personal experiences around “Agile Project Methods for SAP ERP Projects?” I thought it would be helpful to highlight a couple of areas where Agile does work.

Development efforts (i.e. coding)
Data conversions

Once you begin to move very far beyond these two areas you quickly encounter dependent work streams that need much more coordination. Those additional dependencies make it difficult to apply Agile methods beyond development and data conversions.

While Agile tends to emphasize the 1 week to 1 month “sprint,” I would define a “sprint” in more of a completed requirements and planning package rather than a pure time-box approach.

Applying Agile Methods to ABAP Software Development and SAP Data Conversions

Development (ABAP, Java, or other coding)

Since Agile methods have been used for some time with small, discrete components of software development I won’t spend a lot of time there. On a typical SAP project you will end up with a functional spec which defines the program requirements and a technical spec which informs the development details. Even though the more typical “Agile Manifesto” method would not require the documentation it is well-placed on an SAP project. In fact, it is foolish not to have it for long term support and maintenance.

Development can work well for the Agile stages of build / prototype, demonstrate, gather feedback, adjust, and repeat. The key here is to limit the number of these “Agile” cycles to no more than 3 for software development. By 3 cycles I mean 3 completed cycles too. This is not a demonstration with feedback that is only partially built. If the feedback cycle is not completely implemented then it is not a complete cycle. Even though Agile would consider these “sprints,” I would consider them a FAILED sprint if the requirements of the current plan, or the subsequent plans, are not fully realized in the prototype or demonstration.

SAP Data Conversions using Agile Sprints

With data conversions I suggest at least 3 complete cycles or “sprints” (not including a minimum of 1 mock go-live conversion, probably 2 or more if you can).

Build the initial conversion program to all of the requirements (again, partial requirements do not count as a full cycle).
Pilot a test conversion with all data, no matter how much fails, and capture all necessary changes. This will include data dependencies and sequencing. At this point you will be lucky to achieve a 70% success rate when considering all of the data dependencies. This step is not about getting things perfect but about identifying data and programming issues to resolve.
Implement all SAP data conversion changes the conversion pilot exposes, script every conversion step and rough timings, and aim for a successful test target of at least 90%.
Make additional changes and attempt to follow the scripted conversion, making adjustments to the conversion script where necessary, and achieve a goal of at least 98% conversion completeness and accuracy.

Once you achieve this level of conversion consistency it is ready for a mock-conversion. These Agile “sprints,” or as they are starting to call them now “Scrum-ban” (as a spinoff of Kanban) will help to ensure a successful data conversion.

Conclusion on Agile ABAP Development and Data Conversions

Even with newly packaged Scrum, Agile, or other methods, on an SAP project there are so many moving parts and work streams to coordinate that there is no substitute for a good waterfall project approach. Using “Agile-like” methods for the ABAP development or data conversions is not a substitute for good project management either. Done properly this approach can work well as long as it is carefully managed along with the rest of the work streams.

=========================

Contact me today through our site contact form ( http://www.r3now.com/contact ), phone, or e-mail.

Bill Wood
+1 (704) 905 – 5175

=========================

Building an Effective SAP ERP Delivery Organization

Bill Wood — Mon, 05 Nov 2012 12:50:36 +0000

Effective SAP Delivery

There are generally 3 big components for improving SAP delivery. These 3 components have the capability of improving SAP and technology delivery in general while impacting corporate business performance and marketplace success.

Delivery Approach
Delivery Methodology
IT Organizational Development

The following content is written with a focus on SAP, however it can be completely generalized to virtually any IT organization.

A careful focus on the delivery approach is needed. Here there are 2 key paradigms to focus on. The first paradigm is service delivery vs. value delivery (SAP Service Delivery versus Value Delivery), and the second paradigm is software engineering vs. business process engineering (SAP Implementation Focus: Engineer Software or Business Processes?).
A formal, structured, internal delivery methodology. This should include a “checklist” of all project requirements including templates, tools, and resources for project delivery. Because I know SAP I use it, however they have a powerful methodology which can also be generalized to virtually any IT project. For more information see Why Use the SAP ASAP Methodology?
A strong focus on IT organizational development. The current “best practices” around IT Organizational Development includes a 3 tiered maturity structure: Service provider, Business Partner, and Business Peer (Organizational Change Management Inside the SAP IT Support Organization). The second part of that is a structured approach to creating the premier IT “Center of Excellence,” converged business-IT delivery organization (see SAP Service Provider to Business Peer Through Center of Excellence Maturity). You can use 3 Development Phases for SAP Center of Excellence Maturity as a completely structured organizational outline. It includes key activities and maturity steps.

Adopting these three pillars will create a great foundation for your company or organization for the long term. They will also help immediately and transform your enterprise in the mid-term.

=========================

Contact me today through our site contact form ( http://www.r3now.com/contact ), phone, or e-mail.

Bill Wood
+1 (704) 905 – 5175

=========================

Agile Project Methods for SAP ERP Projects?

Bill Wood — Mon, 29 Oct 2012 12:25:48 +0000

SAP Project Guidance

Looking at the “Agile Manifesto” and how Agile methods are applied generally involves small, discrete, “digestible” work and task components.

Trying to juggle the number and complexity of dependencies on a full scale SAP ERP project involves management and coordination efforts which completely go against the idea of Agile methods.

======

ERP projects tend to have too many moving parts for Agile–, there are too many dependencies and Agile provides too little control and coordination. The level of coordination required for a large business package implementation flies in the face of “Agile” methods and techniques. For example, you have to coordinate:

process configuration teams,
custom code development teams,
data conversion,
change management,
training,
testing,
governance,
infrastructure, etc.

On complex projects like this all those “sprints” that are not carefully coordinated and planned (which goes against the “Agile Manifesto” listed below) become completely disjointed disasters. There are too many work streams with dependencies that can not be going in “their own direction” regardless of the impact to other work streams.

Agile Manifesto Activities

The following chart, from the Agile Manifesto, illustrates serious trouble spots for ERP projects like SAP.

Valued	DE-Valued
Individuals and interactions	Processes and tools
Working software	Comprehensive documentation
Customer collaboration	Contract negotiation
Responding to change	Following a plan

Notice, 3 out of 4 of those items on the RIGHT side are often precursors to ERP implementation failures according to the academic literature. Numerous case studies prove Agile “De-Valued” areas are the places ERP projects fail. For example:

Failure to follow good processes and have solid tools.
Failing to have adequate documentation (training materials, help, etc.)
NOT following a well laid out plan (i.e. SAP’s PROVEN ASAP implementation methodology, including sample project plans, templates, etc.).

The only Agile Manifesto item that might have strong need to be followed in the ERP space is the focus on the customer over the system integrator contract.

All of those Competing Stakeholders and Constituents

Not only are the project related dependencies and work streams significant, there are numerous competing constituencies which must also be coordinated:

business stakeholders or organization,
IT,
external business customers,
external vendors,
system integrators (when you use consulting companies),
internal business senior management,
business department heads who don’t always agree with each other, etc.

While Agile methods might work well for small, discrete, component areas of an SAP or other ERP project the academic literature proves it is a disaster for ERP implementations.

Agile is not a waste of time, it must just be understood and used in the PROPER CONTEXT of an overall SAP project. Even the ASAP Methodology includes an “Agile” overlay. This is an overlay of the existing ASAP Methodology–, it does not replace more traditional waterfall methods and does NOT adopt the “de-vauled” Agile Manifesto areas.

Does Agile Have a Place in ERP Projects?

It might.

Agile is not suitable for projects with multiple, overlapping / parallel activities with dependencies between them. The parallel and overlapping dependencies create a requirement that is more suitable to traditional project management methods with:

full project plans,
discretely defined tasks and responsibilities (to avoid “border wars” at transition points),
clearly defined deliverables,
management of parallel work-streams and parallel critical paths, etc.

Applying Agile principles to an overall SAP project creates a high likelihood of blown timelines, blown budgets, and collapsed scope — delivery suffers while stress balloons.

Agile in SAP ERP Project Examples

I know about the struggles, stresses and messes of Agile SAP projects. I’ve been on three of these types of projects and none of them went well.

On one SAP project they tried to manage it with “Agile” and it was a complete mess –, the coordination and responsibility struggles forced a change to the more traditional waterfall approach. Using Agile methods the project had an unsustainable burn rate for the budget, dates were ALWAYS slipping, inter-team coordination and planning were a complete disaster, and before the mid-course correction this project was not going to go live.

Worse still because of the “Agile” methods of only planning small, discrete work components just before they are due, each dependent group tried to minimize their own work and risk by dumping many of their traditional responsibilities and tasks onto any other group. With Agile they were allowed to “self define” much of their own effort and naturally tried to minimize their effort while maximizing their success (at the expense of other project participants and work streams).

I do NOT place this responsibility on the clients who hire outside help, they obviously recognized a capability gap or a need they are willing to pay for. I hold the outside project managers responsible for this and if you ever encounter one of these snake oil salesmen then you should FIRE THEM!

My Conclusion on SAP and Agile Deployments?

Wide application of Agile is a disaster on any major SAP, ERP, or business software implementation project. I can absolutely guarantee you that any Agile SAP project delivery “success” claim violated the Agile Manifesto to get there. There are too many moving parts and too many constituents to use pure Agile on a full blown SAP project.

=========================

Contact me today through our site contact form ( http://www.r3now.com/contact ), phone, or e-mail.

Bill Wood
+1 (704) 905 – 5175

=========================

Figuring Out IT’s Future in an Organization

krheinlander — Tue, 23 Oct 2012 12:25:38 +0000

Business Transformation

“What is the value proposition for IT in your organization?”

IT can be just a service organization, providing a commodity service (and be outsourced to a cheaper provider), or they can identify where to add value to an organization, to the business, and to business leadership.

Hallmark does not sell greeting cards – you can buy the same card cheaper at the grocery store – Hallmark sells empathy, and customer intimacy.

Exemplary restaurants do not sell food, they sell service. You can buy food anyplace.

Apple is NOT a computer or technology company, but sells instead, a compelling user experience.

It may not be intuitive, what one’s value proposition actually is. In each case, the distinction between just someone in each of their industries, and being superlative, is understanding that regardless of the currency of trade (technology, in Apple’s case), the value proposition itself is what distinguishes your organization, your company, your success from everyone else.

IT Organization Leadership

Leadership is not something that is done by the tired cliche of leading by example, but in creating a compelling vision, unique value, and the ability to enable others to succeed, that gets you to the top. You rise not on the backs of others, but carried on their shoulders in triumph. What can you do to make your business counterparts into heroes? It is not about making IT look good, but in making the business players be everything possible with your help.

What Can You Do as an IT Leader to Move to the Next Level?

Get IT people invited to staff meetings in every organization.
Create a liaison/business partners group with technical people that can understand business.
Meet the business leaders daily – find out what they need;
- share the unique insights as to what IT capabilities can provide;
- work out if it makes financial sense, balancing the risk/reward tradeoffs.

And Mr. CIO, take down that wall. If you want to be part of business then join the business. Change the dialog. A CIO should be 80% outside of IT; the 80% inside is your VP/IT’s function.

You think disaster recovery is an IT function? You weren’t listening. 80% of business continuity and disaster recovery don’t even have an IT component. Be the leader, and bring the WHOLE plan into play, not just getting your data back.

You think system reliability is measured in 3-4-5 nines? The business could give a rat’s behind. They care about 2 things; tolerance for planned downtime measured in window of opportunity and duration, and tolerance for unplanned downtime measured in duration and time to recovery. The latter provide a completely different engineered result, with far different costs that some arbitrary statistical number.

Learn to speak in those (and other) business terms, and business will be your partner, not your customer.

Conclusion and Summary on Building a Business Centered IT Organization

IT today, typically covers half of what the functional role of the organization should be – the half that all IT organizations are comfortable with striving to deliver.

The other half is business intimacy – moving from the back end of business requirements to the front end, and moving to a business partner, who works hand in hand on solving identified needs, up to business peer, collaboratively identifying new needs and how IT can expand business success, and maybe even to business leader, where business capabilities encompass how technology can best enable future business strategy. The transition is from reactive services organization, to improved business interactions, to trusted adviser, to proactive definition of future state business vision.

If your organization is in a functional delivery role then your CIO is functionally equivalent to a VP of IT, with an inflated title. If your organization is integrating with the business then your CIO is on the path to C Suite success and peer respect. Welcome to a small, but highly successful group.

=========================

Contact me today through our site contact form ( http://www.r3now.com/contact ), phone, or e-mail.

Bill Wood
+1 (704) 905 – 5175

=========================

SAP Change Management Program Success

Bill Wood — Mon, 30 Jul 2012 12:51:09 +0000

SAP Change Management

Lots of literature, information, and resources focus on change management for successful enterprise application projects. To help address SAP change management the SAP ASAP Methodology provides lots of resources, tools, and templates along with guidance for Change Management during your SAP project. This is one of the key reasons for Why to Use the SAP ASAP Methodology?

Even though the ASAP methodology and various other resource provide some great sources the high level guiding framework always seems to be a little vague. For example, there is a constant message that people resist change and that it is so hard. That is not true. As I have often said, if people resisted change no new product or service would ever be sold. No new invention, gadget, method, or anything else would ever be developed. There would be NO innovation in anything.

People do NOT simply resist change–, they resist change they do not understand and change they perceive is a threat.

Applying Sales and Marketing Principles to SAP Change Management

If sales and marketing departments for every type of organization in the world manage to sell new products or services maybe we should look to them for what works. For both marketing and sales there are four key phases for customers considering a purchase:

Awareness (Marketing)
Consideration (Marketing, sales)
Evaluation (Sales, marketing)
Purchase (Sales)

These four general stages or phases of buyer behavior correlate well to a solid change management program–, messaging, engagement, credibility, and commitment. To be successful you must be committed to Leading Change (and Change Management).

1. Messaging – This is the beginning of the stakeholder analysis process. Exploration, active listening, and facilitation are critical. At this stage messaging is outbound.

Product or Service Sales Phase

Awareness

Customers understand and can communicate their desire or problem or need. What are your constituents facing? What are their struggles and what will help them do what they need to do better? If the change will add more burden to them then why is the change necessary?

Enterprise Change Phase

Discovery and blueprinting

A good SAP or enterprise application change program must start right from the beginning of the project. First the identification of the key stakeholders at all levels of the organization must be made. Afterward a clear effort must focus on the benefits to the affected users. You must focus on the WHY of Achieving Business Value from SAP Investment.

A system-centric blueprint which does not connect to user needs will only breed mistrust and fear.

Analysis

Surveys are distributed and results tabulated.

2. Engagement – Deeper determination of the issues, active communication, and targeted messaging. Stakeholders at all levels must be encouraged to participate and be heard. At this stage communications and messaging just start to go both ways (inbound and outbound).

Product or Service Sales Phase

Consideration

Marketing and communications are directed at addressing customer desires, problems, or needs. Assurances are provided that the product or service will meet those issues. The customer begins to solidify whether or not to explore a purchase decision.

Enterprise Change Phase

System functionality demonstrations and stakeholder feedback

Key stakeholders have the first part of their issues addressed. There are 4 key types of change categories each user fits into here. They are:

Opposed
Unsure, anxious, or fearful
Accepting or willing
Promoting

This phase of the change process is designed to aggressively uncover and then address those who are opposed or anxious about the upcoming changes. These key stakeholders must be heard and their concerns answered. It is also where the key message around SAP Service Delivery versus Value Delivery is promoted.

Analysis

Survey results are synthesized, reviewed, and then communicated to the broader enterprise. Action plans to address the survey results are developed. Any evaluation metrics are defined.

3. Credibility - benefits messages, demonstrations, insight, and information. Change activities must promote openness and clearer understanding of the reasons for change. More of an inbound and outbound dialog begins to occur. Communications are actively going both ways.

Product or Service Sales Phase

Evaluation

Understanding of key features of a product or service and how they are different or better than competitors occurs. Price considerations are also important.

Enterprise Change Phase

Aggressive information sharing and open dialog

One way you can Achieve Business Benefit is Through SAP Prototype Demonstrations. Part of the communication and benefits program involves live system demonstrations (demo days), active engagement of super users, subject matter experts, and key change agents throughout the organization. Messaging would also include external web resources, links, presentations, and other information to help “sell” the organization on the coming changes.

The goal of this phase is to overcome objections, fear, and anxiety.

Analysis

Action plans from the surveys are communicated to the organization and execution activities are carried out. Evaluation metrics are refined, communicated, and adjusted to the organizational requirements.

4. Commitment - full user participation is critical at this stage. If they are not involved in the process all of the previous effort falls apart here.

Product or Service Sales Phase

Purchase

For the purchase of a car this is the test drive and price negotiation. For services or other items it is the understanding of key differentiators and how the service will help or enhance the customer’s issue, customer references, and possibly case studies.

Whether it is a test drive, understanding differentiators, price negotiations, or the benefits of a product or service these are all directly related to building a level of trust which in turn produces commitment.

Enterprise Change Phase

Acceptance, Adoption, and Promotion

More user demonstrations, training, super user network, subject matter experts, and pilot processes are all important here. This is where everything starts to come together.

This is also where any changes to originally expected benefits or reductions in scope must be carefully managed. Another key area is the Organizational Change Management Inside the SAP IT Support Organization. A key component at this phase involves Change Management Strategies and Knowledge Transfer Processes for a Successful SAP Project 1 (and Part 2).

The goal of this phase is to produce acceptance and even promotion of the changes. However acceptance, adoption and promotion are not possible if the stakeholders have not established trust in the coming change.

Analysis

Execution activities are carried out and nearing completion. Reviewing, analyzing, and then distributing the results of the previously defined metrics results occur. Lessons learned are captured and communicated.

Conclusion on SAP Change Management for Business Application Project Success

Every phase of your SAP or enterprise application project must be wrapped in the appropriate change management processes. Just as with sales and marketing people do not resist change as much as they resist change which they perceive as a threat or do not understand. So the key is to learn to sell the change and its benefits so that the perception of a threat is removed. In doing so you will help to transform your project and company into a winner, both now and in the future.

=========================

Contact me today through our site contact form ( http://www.r3now.com/contact ), phone, or e-mail.

Bill Wood
+1 (704) 905 – 5175

=========================

SAP ROI -- Enterprise Architecture & Business Solutions

9 Games ERP Consultants Play

Related Posts:

Popular Searches:

Will SAP HANA Lead to a Big Data Revolution?

The Big Data Revolution

Related Posts:

Popular Searches:

SAP Third Party – Indirect Usage Licensing Part 2

SAP Are You Listening? There IS a Third Party / Indirect Usage WIN-WIN Here!

Customer Perception of the SAP Third Party Indirect Usage Licensing

SAP, Your Third Party or Indirect Usage Answer

Expand Application Footprint and Increase Revenue

Conclusion on SAP Indirect Usage or Third Party Usage Sales and Marketing Options

Related Posts:

Popular Searches:

SAP Third Party – Indirect Usage Licensing Part 1

Where is the Reference to Indirect Usage?

SAP Indirect Usage or Third Party Usage Enforcement

Related Posts:

Popular Searches:

Storms Coming on the Salesforce.com Cloud Front

Related Posts:

Popular Searches:

Where Does Agile Fit in SAP Projects?

Applying Agile Methods to ABAP Software Development and SAP Data Conversions

Development (ABAP, Java, or other coding)

SAP Data Conversions using Agile Sprints

Conclusion on Agile ABAP Development and Data Conversions

Related Posts:

Popular Searches:

Building an Effective SAP ERP Delivery Organization

Related Posts:

Popular Searches:

Agile Project Methods for SAP ERP Projects?

Agile Manifesto Activities

All of those Competing Stakeholders and Constituents

Does Agile Have a Place in ERP Projects?

Agile in SAP ERP Project Examples

My Conclusion on SAP and Agile Deployments?

Related Posts:

Popular Searches:

Figuring Out IT’s Future in an Organization

IT Organization Leadership

What Can You Do as an IT Leader to Move to the Next Level?

Conclusion and Summary on Building a Business Centered IT Organization

Related Posts:

SAP Change Management Program Success

Applying Sales and Marketing Principles to SAP Change Management

Related Posts:

Popular Searches: