SAP & ERP Consulting from the Customer Point of View

Why SAP Process Understanding, Troubleshooting Ability, and Knowledge Transfer Techniques are Missing in SAP or ERP Projects

Because an ERP system like SAP has a single database or a single instance of data, a full process chain of dependencies is developed.  Every organizational function becomes dependent on the process steps before and after it no matter what department or area is responsible (Kallinikos, 2004).  Because of these dependencies, a data error is no longer contained in a single isolated system as in times past.  Each data error, or each problem that occurs has both upstream and downstream consequences and the corrections cannot be made in isolation. Improper configuration or system design can have huge impacts on the amount of effort to correct the data and to maintain the system in an ongoing fashion (Sia and Soh, 2002).

A good consultant’s role on an SAP or other ERP project is to guide the company through design decisions and make the system settings to support those design requirements.  This is usually called the “implementation” process.  During this process they should be focusing on knowledge transfer as well.  However, many of the “consultants” who implement SAP or other ERP systems have little process or troubleshooting understanding (see A Cautionary Tale About SAP Knowledge Transfer).  As a result of this lack of consulting experience, or of the number of fakes in the marketplace, knowledge transfer is usually not sufficient.

Speaking in technical terms may make a consultant SOUND smart or knowledgeable, but it does not mean they ARE smart or knowledgeable. The mark of experience, intelligence, and knowledge is the ability to make the complex or technical seem simple or at least understandable.

For long term business benefit and ROI your implementation vendor must provide consultants with solid overall process understanding.  Without this process understanding, as well as their module specialization, those consultants will not  be able to achieve a process oriented implementation.  If they do not have a process understanding how will they help you realize any process efficiencies or improvements during the design process?  Without the overall process understanding how can they guide your company through the change management process needed for competitive business transformation?

If you fail to demand that the SAP implementation vendor provides strong end to end process consultants your company will struggle with day to day operations after the consultants are gone.  Without those strong end to end process consultants your transition to proficiency with the system will take much longer and be more difficult.  In the end any increases in productivity, or in business value will take much longer to realize, if you ever realize them.

SAP systems are typically implemented for business transformation.  That transformation generally is related to process improvements, automation, and customer focus; to address competitive pressures and business value propositions.  One of the most important components of that business transformation effort is the change management and knowledge transfer (however you describe those activities).

Achieving SAP Maturity by Using the Correct Knowledge Transfer Techniques

Business transformation and change management techniques are often described by many different names:  knowledge transfer, learning organizations, sustainment, production support, knowledge management, agile enterprises, etc.

There are a number of quality change and training programs available for SAP projects but few of them achieve a level of competence needed for an SAP Center of Excellence.  As the next post lays out, Change Management Strategies and Knowledge Transfer Processes for a Successful SAP Project 2, change management and knowledge transfer for business transformation requires several activities.  A more complete list of knowledge transfer methods includes:

1. Transactional processing (typical keyboard training).
2. Business process understanding (some projects use this method with transaction flowcharts for showing dependencies).
3. Master data dependencies (few projects do this level of end user training because it is generally the implementation consultants who have this level of understanding).
4. Operational processing (fewer projects still do this type of training because this is the production support “troubleshooting” type of training that requires seasoned consultants to be on site long enough to help users work through the issues).
5. Ongoing knowledge transfer activities such as ad hoc troubleshooting meetings with all affected users (work through problems as a group in a conference room).
6. Continuing communication about tips and tricks after the system is live.

For long term success in the marketplace, beyond the operational excellence proposition, a continuing change and transformation program needs to be undertaken after the system is live.  This requires post production support efforts to begin evaluating real areas of opportunity in the marketplace.  Organizational and business change is no longer an option, as Mike Myatt notes, it is an imperative in today’s global economy (see Leading Change and Change Management http://www.r3now.com/leading-change-and-change-management).

Poor Knowledge Transfer Planning or Methods and Implications for Long Term System Support and Cost

One of the biggest workforce readiness problems with any SAP implementation is that the consultants who implement the system rarely have any significant production support experience.  Without that production support experience, and the end to end process understanding, it is impossible for meaningful knowledge transfer techniques you need for long term success.  Without the understanding of support they are unable to address items 4, 5 and 6 listed above.  And without that complete level of knowledge transfer organization maturity takes much longer.

That lack of production support experience (and I do not mean the month or two after go-live, but longer term support) means these consultants don’t know how to design a solution that avoids some of the “lessons learned” from the past.  They do not know how to prevent you from “driving off the road” with your solution after you go live because they have never had to live with the decisions and “solutions” they have provided.  Most of the consultants who come to these projects do not understand how to untangle, resolve, or fix problems that occur in the system when it is productive (cf. Scott and Sugar, 2004).  Because they aren’t even aware of what to expect in a live environment they don’t have any basis to transfer that knowledge of troubleshooting techniques or methods to you as the customer.  As a result your support pains may be far greater and last much longer than you anticipate.

This same lack of consultant experience with post-production issue resolution prevents them from being able to transmit operational understanding to you, the client.  In other words, consultants without deep and broad experience are not capable of ensuring you have a relatively smooth go-live.  So not only do they fail to design solutions that are more streamlined or automated, they have little ability to ensure you have a smooth go-live experience.  When you combine this lack of support experience with the number of outright fakes and frauds in the SAP consulting space it is no wonder there are so many unhappy ERP customers (see Screening Methods to Find the Right SAP Consultant Part 1).

My experience has been that consultants who lack this broad and deep experience with production support rarely know what needs to be tested before the system is live.  And without adequate testing you can expect to find ongoing data and system design or setup problems for some time after you go live.

How Do You Remedy the SAP or ERP Knowledge Transfer Plans and Methods to Support Change Management Processes?

1. If the consultants speak in overly technical terms, have a language barrier, or if there is a lack of overall process understanding ask your SAP implementation vendor to replace them (see Screening Methods to Find the Right SAP Consultant Part 2).  Speaking in technical terms may make a consultant SOUND smart or knowledgeable but it does not mean they ARE smart or knowledgeable. Baffling the uninitiated with technical jargon is a classic smokescreen to mask inexperience and incompetence. The mark of experience, intelligence, and knowledge is the ability to make the complex or technical seem simple or at least understandable.
2. Communicate to ALL internal company project members before the project begins that they will be responsible for long term support and training of end users.  Let them know that they must immediately notify project management if any consultant(s) have significant barriers to transferring knowledge or understanding.  This must be communicated early in the project because by the time the knowledge transfer for training begins it will likely be very disruptive and risky to make the needed resource changes.
3. If you need to remove a consultant don’t wait until the timeline is so tight it would create a significant project risk. Include a contract provision that if a consultant is replaced for lack of skill, language barriers, or other reasons related to skill, performance, or ability to ensure knowledge transfer that a credit for at least the prior 4 week’s billing is due (four weeks is reasonable for you to discover the problems and is not unreasonable to insist on a credit).
4. Avoid customized or technical solutions for anything except mission critical requirements or for solutions that directly address business goals and marketplace competitive pressures (see SAP Implementation Focus, Software Engineering or Business Process Engineering?).
5. Use the RFI and RFP process to solicit comments, methods, tools, and resource examples of how knowledge transfer will be handled.  Be sure to leverage a Request for Information process and the RFP process as an educational experience (see Breakthrough Project Success: 3 of 4, Vendor Selection and Contracts).
6. Use the RFI process to ask for sample consultant resumes, and the RFP process to insist that final resumes for the actual project must be submitted.  Note in the RFP that any non-response may disqualify the vendor.  SAP is mature enough that there is no reason an SAP implementation vendor should have problems providing key resources.
7. Check with client references from the consultant’s resumes who are submitted (and not the sales pitch references) for application skill, ability to do knowledge transfer and for change management skills.
8. Construct your services contract with an expectation of knowledge transfer (which I define as “operational independence”) or with a penalty for failing to do so.    For some ideas on how to structure a contract agreement to cover this see the section titled “Operational Independence is the Key Success Criteria or Measure of SAP or ERP Knowledge Transfer” toward the bottom of the post  A Cautionary Tale About SAP Knowledge Transfer.
9. Be ready for a drop in productivity right after the system goes live.  However this should be a temporary situation and the better the knowledge transfer and change management has been the less pronounced and shorter the duration will be.  If done successfully there should be an improvement in overall productivity after the initial drop.
10. As you move into support mode after going live then begin to document the transaction processing steps necessary for fixing, resolving, or troubleshooting problems that arise.  Conduct weekly or bi-weekly training and knowledge transfer sessions to internal employees and provide different tips, tricks, or techniques for problem solving.
11. Monitor progress within each process area and continue to keep the communication program going within the company after the system goes live.

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

Kallinikos, J. (2004), “Deconstructing Information Packages. Organizational and Behavioral Implications of ERP Systems.” Information Technology and People, Vol. 17, No. 1, pp. 8-30.

Scott, J. and Sugar, D. (2004), “Perceived Effectiveness of ERP Training Manuals.” Proceedings of the Tenth Americas Conference on Information Systems, New York, pp. 3211-3215.

Sia, S. and Soh, C. (2002), “Severity Assessment of ERP-Organization Misalignment.” Proceedings of the Twenty-Second International Conference on Information Systems, New Orleans, pp. 723-729.

Related Posts:

• Tactics, Strategy, ROI, TCO and Realizing Business Benefit from SAP
• Series on SAP Competency Center or SAP Center of Excellence
• Opportunities for INNOVATION SAP, HELLO?
• Using SAP to Improve Revenue and Profitability
• SAP System Vendor Project Success Criteria 1

Back in the late 1990′s, while at Grant Thornton, and then later when the management consulting organization was sold to Hitachi I worked on a comprehensive knowledge management model (see the image below).  The model  has application and relevance to integrating collaboration tools into any enterprise application.

Carefully structured and planned integration of collaboration tools can produce great results,  but it is a challenge.  Finding ways to tie collaboration into the business technology for productive use in the enterprise is the goal of a lot of social media types but few of them have any idea how to do this.  Clearly there is a lot of hype around “Web 2.0″ interactive functionality but little in the way of productive business use.

By moving outside of the enterprise walls to integrate customer interaction and the extended supply chain the enterprise can gain valuable insight.  By using structured data gathering and organization techniques business value can be achieved.

In this post we will look at a few approaches I’ve taken over the years that have been effective and powerful for creating dynamic collaborative organizations.  They don’t use the trendy new tools like Facebook, or Twitter, or other communication mediums, but they do leverage the collaboration concept.  Maybe someone can create a use model for tools like Facebook or Twitter combined with enterprise applications.

Why Enterprise Collaboration Tools have Not Yet Taken Off

Too many organizations undertake the introduction of social media for the purpose of introducing social media into the enterprise.  In the Knowledge Management area this is like having information without any context of how to apply that information or the experience to apply it properly.  Information alone is NOT knowledge and social media or collaboration tools which do not have a specific business purpose are not very productive (if at all).  Without a specific “context” to apply social media tools, and the understanding of where they might fit, and how they will be used, they are more likely to be a distraction (see Social Media Fads and the Risk to the Enterprise ).

There are few methods, and even fewer tools to filter through all of the “noise” from social media tools to find what is meaningful.  From there, it is still even more difficult to distill what is meaningful into something useful.

So, for example, Facebook, MySpace, and Twitter may NOT fit in your enterprise.  However, being able to capture employee, customer, and vendor knowledge, suggestions, or criticisms (information) and then publishing this internally to the right people (the context of applying that information) may make a huge difference for your company.

Few social media “gurus” have any idea on how to start this type of structured information gathering dialog from an unstructured information source (see the graphic below).  They do not know how to develop a structured program to take advantage of the unstructured data by finding meaningful ways to apply that information.  There are few methods, and even fewer tools to filter through all of the “noise” from social media tools to find what is meaningful.  From there, it is still even more difficult to distill what is meaningful into something useful.

What do they say in response to this?  What is their excuse?  You don’t understand social media and it is all about building relationships and you haven’t spent enough time and you can’t apply old business rules and, etc., etc., etc.  Snake oil, snake oil, snake oil…  And I have lots of swampland in Florida that was never hit by the housing downturn and it is worth more now than ever!

All you get are excuses and that you’re not doing enough or spending enough.  Few social media”gurus” have any idea at all on how to generate real value from these new channels.

Why Consultants and Collaboration Evangelists Have Not Shown Much Progress

Neither consultants nor business have 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 or social media tools to propel a company’s key value propositions.  Even if you move down one layer beneath the value proposition to the competitive pressures in the marketplace these “social media mavens” there is still no coherent method for social media use.  Beyond things like video conferencing and webinars which help to reduce expenses related to travel and coordination, not much has been done to move social interaction in business to the next level.  There is a lot of hype, a lot of claims that this is the “next big thing” but not a lot of substance yet.

The real issue is not to use social or collaboration tools in the enterprise just to collaborate.  They must serve a business purpose and a business need.  The business enterprise is not a social club, but social tools can be used to serve the business purposes or goals.

In my prior post on SAP, ERP III, SOA — Learning Organizations through Social Media Collaboration there are 9 steps noted toward the end of that post on exactly how to use open source forum software for developing a learning organization.  That integration doesn’t deal with the cool, hip, or trendy social media tools of today, but they are effective collaboration methods.  The same concepts in that post can be generalized and applied to knowledge capture activities around innovation or customer experience.  The way you use these forum type tools inside the company depends on what your goals are, but the instructions for use are there.  And properly used they can be very powerful business tools for competitive advantage.  Little if any of this type of direct, clear, and understandable use case information exists for the “trendy” social media of today.

Toward Transforming Information to Knowledge – A Working Knowledge Management Model

By using collaboration tools properly, or by finding meaningful ways to use the Web 2.0 tools in a more structured way, it is possible to make systematic progress to support business purposes.

Back in 1997 and 1998 I worked through the model and developed a systematic approach, by using primitive collaboration and social media tools, to convert consulting into knowledge centered learning organizations.

It relied heavily on:

• collaboration,
• cooperation, and
• information dissemination.

This was done by using the tools that were available at the time.  A systematic process was developed to capture, then synthesize, organize and disseminate the information and knowledgeable individuals throughout the organization.  By doing this a collaborative learning organization was developed.

The knowledge management graphic and model I produced years ago (see below) was used to advance the concept of a learning organization because that was a clear business fit for consulting companies.  A consultant’s capabilities are directly tied to their knowledge, and that knowledge is a consulting company’s capital or stock in trade.  From that learning organization real business transformation and business benefit can be achieved.  A learning organization is more dynamic and adapts to change more readily.  As a result of the ability to absorb change, dynamic market conditions help ensure you are a leader rather than a laggard in the marketplace.

Early Collaboration and Social Media Efforts that Started to Produce Results Shortly After Y2K

Even the most knowledgeable, talented, and proficient consultants get stuck at times. The nature of complex business and technology problems means there are times you need a little help.  At Grant Thornton, and then later at Hitachi, we recognized the need to have dynamic but high quality tools, templates, and resources available to consultants.  At the same time we also recognized the need to be able to tap into other knowledgeable experts within the organization on a moment’s notice, even if the consultant who needed the help didn’t know the individual.  Outside of a consultant’s own personal network they didn’t know where to look for the specific skills or expertise they needed to resolve a particular issue.  The solution had to be simple and almost instantaneous.

It had to be, the right knowledge, right now!

We wanted a structured method that was simple and intuitive to create a collaborative environment.  After looking at our technology landscape right after Y2K we started to use MS Exchange Public Folders, Outlook Shared User Folders, e-mail, and MS Messenger.

A Simple Collaborative Solution Using MS Exchange Public Folders and MS Messenger

We developed an MS Exchange folder structure that matched our client project needs and sales force needs for tools, templates, resources and our own best practices on demand.  The beauty of MS Exchange was that the Web Access version allowed our consultants to leverage public folders through the web interface from anywhere, just like they were using MS Explorer / MS File Manager.  The public folder structure was the perfect fit because there was little to learn beyond the new folder structure of how we would store the data.  Dragging, dropping, and opening files in this MS Explorer like interface was intuitive and took no time to adjust to.  This was immensely helpful at some client sites where security is very high so that only the client’s computers or hardware were allowed on the client’s corporate network.  In other words, where access to internal resources would have been limited or non-existent this allowed for ready access to anything that was needed.  Add to this the MS Exchange folder permissions are robust so security was meaningful.

Together with this we used MS Messenger, but rather than just having an employee’s  name which was unknown to those outside that employees “circle” or network, we applied their key skill to the logon name.  From a standard list of key skill codes for SAP (SD, MM, PP, FI, CO, AM, CRM, SRM, APO, etc.) we placed that in front of the person’s name so that it automatically grouped like skills, and placed the skill reference first in a list of over a hundred resources.  In an instant if you needed some input from a seasoned Sales and Distribution person you would just look on the list for those names starting with SD_Employee_Name.  SAP practice users were then exposed to each other all over the United States and even in other countries by their skill codes so that even if they did not know the user, if they had a question of a colleague or peer they could just ask in real time.

There was also a regular weekly publication containing special “tips and tricks” for productivity or functionality.  This was simply sent through e-mail and a copy stored in the knowledge management folder in MS Exchange.  It could be referenced at any time in the future.  This created a reusable knowledge repository that allowed the quality of the tools, templates, resources, presentations, and other material to be continually advanced and quickly reused.

When I left we had just started on the internal forum posting initiative.  This was to provide a central location to capture knowledge sharing or information discussions in a searchable database.  Using open source content management systems and open source integrated forums our goal was to create a central communication collaboration hub to capture and exchange ideas, custom coded solutions, and best practices.  With the many available add-ons to the open source CMS systems we considered adding an internal high level project management status tracking system and resource request system for senior level managers to gain near real-time visibility to the status and resource needs of all of the many projects taking place all over the country.

This was a very practical way we leveraged existing social and collaboration technology by building the structure and processes to add business value.  It enhanced the customer value proposition by providing better and faster customer solutions, more customer focus, and better internal employee interaction.  In other words, this whole solution was low cost and used existing collaboration tools to advance business interests.  It helped to promote end client satisfaction because of the nature and ability to gain “the right answer right now.”

The real issue is not to use collaborative tools in the enterprise just to collaborate.  They must serve a business purpose and a business need.  The business enterprise is not a social club, but social tools can be used to serve the business purposes or goals.

Refinements, Enhancements, and New Dimensions to Collaboration and Knowledge Tools

As the efforts and my research on the subject matured I wrote a piece about my perspective on this issue as it had matured and called it SAP, ERP III, SOA — Learning Organizations through Social Media Collaboration.  That article laid out a way to integrate social media tools like Forum software into the SAP help system.  What this means is that end users can capture real time information about the system, or shortcuts, or requests for simplification or other useful information and disseminate it to the organization.  This also provides a method for workers in any department or area, in real time, to provide feedback that focuses on the company value proposition or competitive pressures.  Here is the model I produced:

1)  Raw Information:  The unstructured data, ideas, “crib notes,” and thoughts that we all have.  However in this instance, it is the raw information surrounding the job or responsibility that the individual performs within the enterprise.  Sometimes these are the “workarounds” to get something done when you run into obstacles or roadblocks, other times they are just shortcuts, techniques, to perform a job or function.

2)    Organized Information:  This is the process of capturing and classifying that raw information.  This is where the “knowledge bases” and other types of information systems come in.  Many enterprises make it this far. Sometimes these are the “workarounds” to get something done when you run into roadblocks or obstacles.  Other times they might be the shortcuts or techniques to more efficiently perform a job or function.

3)    Acquired Information Experience: This is the interaction with the organized information.  This can be through search functions, employed taxonomies, reports, or other methods of accessing the organized information.  This is after the capture of the information in steps 1) and 2) above, and involves its wider availability than in the individual who originally developed or “held” the knowledge or information.  Few organizations or enterprises make it much further than this.  However, this is the beginning of the true learning organization.

4)    Applied Experience (Knowledge!):  This is the practical application of the organized information after it has been acquired.  Whether this acquisition is through word of mouth, training, or some type of information management system (that is wrong named a knowledge management system) or through a “knowledge base”. This is where the cost savings, revenue opportunities, continuous process improvement opportunities, and real competitive advantage begins to come to fruition.

5)    Refined Experience:  This is more of the inherent “knowing” what to do in a broad variety of contexts that may not be directly related to the task or issue at hand.  It is when an individual can draw on that level of inner experiences mixed with intuition and make the right decision or provide the right answers when there is not enough information to make such a determination under normal circumstances.  This can also be a type of “making the complex appear to be simple.”

This knowledge model I created in the late 90′s seems to be pretty well accepted today [Fn1].  Notice it is very different than an information model because knowledge by its very nature requires information together with the context of how, what, and when to apply that information together with experience.

The ERP III future will rely heavily on delivering on the value propositions of customer focus and innovation.  By moving outside of the enterprise walls to integrate customer interaction and the extended supply chain the enterprise can gain valuable insight.  By using structured data gathering and organization techniques business value can be achieved.

It is my belief that both of these pillars will occur through the use of corporate collaboration tools–, but only corporate collaboration tools that are focused on the business goals of capturing critical “knowledge” and information around these two key premises.

~~~~~~~~~~~~~~~~~~~~

[FN1]  The knowledge model I produced was based on a synthesis of a number of sources I had studied at the time to try to bring some clarity around the confusion between “information management” and “knowledge management.”  At that time, or possibly earlier, there may have been someone else with the same ideas and a similar model but I couldn’t find it then.  Today I see too many variations of these terms but the same basic process all over the place.  If someone else can claim *earlier* authorship I won’t dispute it.  I produced my first version before Y2K.

Related Posts:

• Striving for a Customer Focused Approach to Innovation 3 of 3
• ERP vs. ERP II vs. ERP III Future Enterprise Applications
• Tactics, Strategy, ROI, TCO and Realizing Business Benefit from SAP
• SAP, ERP III, SOA — Learning Organizations through Social Media Collaboration
• SAP IT Convergence Beyond Business to IT Alignment

What if some little guy like me–, a lowly contract consultant came along and said “SAP, I’ve got some really, really great ideas on how you can dramatically change the application for far greater success in the marketplace!” 

What if it would make a significant change in the usefulness of the application, AND would not cost that much in developer time or resources. 

What if it could be done with almost completely pre-existing functions, functionality, and code that SAP already has but has not done a good job themselves of integrating?

Low cost, high benefit, game changing scenarios in the ERP application space.  Game changing because the changes below and many more I know of cover the vaunted three areas of value proposition all at once–,  product innovation, operational excellence, and customer experience.

What if these changes demonstrated enough benefit to create a compelling case for version upgrades without expiring support as the reason? 

What if these changes made it an easier sell into the Small and Midsized Business (SMB) space?
 
Would SAP take up the cause?

I’ve got just such a set of propositions for you.  Just the thing to completely change the ERP competitive landscape and move the application to the next level without much cost, complexity, or difficulty involved.
  
Remember when you paid millions upon millions of dollars to do the “EnjoySAP” design work, employ the consultants (internal and external), developer coding, and lots of expenses to build that user experience.  I’m giving you the next generation application process FREE and it will make a huge difference in the application experience. 

SAP, knock, knock, anybody there?  You know basic value proposition issues like “customer experience” leading to better user acceptance.  These and other solutions also cover the operational excellence value proposition of reducing the post-go-live change management “valley of despair”?
 
SAP, what if I can deliver without all the bucketloads of cash you paid for “EnjoySAP”?  Are you interested?

“EnjoySAP”? 

Years ago I remember when SAP embarked on a transformation project called “EnjoySAP.”  The idea was to design the application to be more user friendly, and to be just plain more usable.  Along the way we ended up with a new GUI interface and lots of “N” transactions for the new interaction paradigm.  That was about 10 years ago.  It’s time for a change…

SAP has the ability today to add tremendous value to its transaction processing and to be able to take the application to the next level by doing a few “relatively minor” changes.  These would appear to be dramatic changes on the surface, but underneath they are relatively simple and low cost.  Best of all, all of them can be made 100% backward compatible, and most of that even without having to use a “switched framework.”  How’s that for benefit?
 
Most can be done with few or no core application code changes to existing transactions, and even when there must be a few changes, they can still be done without tremendous difficulty.  Even when those changes are necessary, SAP can simply incorporate its “switched framework” for coding enhancements and add the switches to the IMG to give customers the option of using the old, existing ways, or the new, significantly enhanced methods.

Here we Go…   

For many years I’ve done full-cycle, full-module, functional configuration in SD, MM, and PP.  Along the way I’ve encountered some interesting things that have made me wonder why in the world SAP hadn’t done more work on application “usefulness” to the end user.  We’re talking one of the vaunted three value proposition pillars here SAP –, “customer experience.”

DIMP solution add-on transaction, ADSUBCON 

The SAP subcontracting functionality has always been a royal pain in the backside.  Separate t-codes for nearly every process, separate inventory management processes, separate stock report t-codes (forget about MMBE here), you name it.  Overall it is a disjointed and painful process.  However, one day on a DIMP project at an automotive company I accidently ran into this absolutely amazing subcontracting processing cockpit transaction called ADSUBCON.  It is probably one of the most useful, well thought out, and well-designed transaction options in the system.
 
Why isn’t this included in the core application for every customer, whether they use DIMP or not?  SAP, are you listening?  This is a BIG win for end customers.
 
This “cockpit” paradigm should be extended to other process areas of all of the modules.  Simply create the transaction code process flows, with all of the options, and enable configuration to be done to include or exclude certain transaction “buttons” or “options” in the cockpit.  Here are the advantages of the cockpit paradigm.  Users are exposed automatically to the full breadth of the process so they gain a more holistic business process perspective (even if they can’t execute certain transactions).  Knowledge transfer and usability are facilitated by the common look and feel of the cockpit.

ME21N – Do we need a VA01N? 

One of the really useful functions in ME21N is the document overview and the ability to drag requisitions to the shopping cart to create new POs.  Why doesn’t this exist for Sales Orders?
 
Come on SAP, you could easily incorporate the VA05 transaction processing behind the scenes to make this more usable.  The VA05 could be the document overview like what is used in ME21N.  The copy control could easily be used to copy document to document, or item to item.  And on top of that, depending on how the transaction is structured, it could also include a list of the last X orders / deliveries / invoices (based on configuration settings) for that Ship-To party as soon as that customer number is entered and you press ENTER.  Wow, now that would be useful.
 
On top of that, the development for a lot of this has already been done in several function modules that are used for the R3 Internet Sales application.  What are you waiting for?  This would create a dramatic change in usability for a key transaction string.  Along with that it would not require a huge amount of development work. 
 
SAP, can you see the benefit to the end customer who uses these transactions?

Document Flow in MM and PP 

The PO History was a good start in the ME”xx”N transactions, but this should be extended to material documents, accounting invoice displays, etc.  This was done in SD and has been a tremendous asset and help for troubleshooting, understanding document history, etc.  Why hasn’t this same paradigm been applied to MM and PP yet?  Come on SAP, the info is already there, it’s not that hard to attach the data.

Pricing, Schmicing, SD-MM coordination 

This one would require some re-design but in the end it would be worth the pain.  I’ve always been baffled by the “differences” between SD “Pricing Procedure” maintenance and MM “Schema” maintenance.  A significant amount of the backend plumbing, tables, etc. are the same between the two modules.  Even a lot of the programs are the same but are separated by application area settings.  Why again are they named differently?
 
In reality lots of these things should be made exactly the same, but in reverse.  I’ve even been on many clients where they wanted to do similar types of posting functionality that is available on the SD side but on the MM side.  Instead of revenue accounts, maybe expense and liability account determination. 
 
The consistency in naming conventions in the IMG for SD and MM pricing would be helpful.  The similarity in functionality would open doors to more consistent thought and condition setup leading to better business benefit.  The ability to be able to drive more granular General Ledger level spend tracking on PO’s by having similar functionality to SD’s Revenue Account Determination functionality would provide greater ability for business to track discrete components of the competitive pressures that vendor power creates.

Making the pricing processes both similar and just as robust on both the SD and MM side, along with the expanded FI integration opens a whole new world of possibilities for business.

Output Processing WMTA-Style 

On nearly every project I’m on there is always some request to automate this transaction into that one, etc.  The process chain automation seems to be a consistent and routine theme no matter what module it is. 
 
Over the years I’ve used Lean WM and the Auto TO creation through the standard WMTA condition. 
 
This paradigm is a great solution to performing any kind of auto processing throughout the system.  Because of the number of BAPIs and Function Modules that are already produced for most of the document creating (or changing) transactions, this would be relatively easy to do.  Simply include a BAPI or function module in a condition to create the follow-on document and pass the data to the function module or BAPI through the print program.
 
This solution is tremendously flexible because of the ability to control the individual behavior of each output through the use of the condition technique and access sequences.  What a great way to get the job done!
 
On top of that, you could develop a standard print program with all of the standard supported output options, and a configuration switched framework that uses the application area and standard or custom condition type to be processed.  Then unnecessary processing would not be required, only a single print program would need to be maintained, and the output condition could have its own separate BAPI or function module assigned.
 
Do I hear highly flexible workflow without all of the difficulties, pain, and setup work of normal workflow?  This is a great way to enable business process flows with standard functionality and standard programs for processing or re-processing outputs.  This is the type of innovation that small and midsized businesses badly need.

Conclusion 

SAP, if you’re listening at all, I have many more areas where you can substantially improve the ERP application, without significant expense, time, or resources.  These and many other improvements begin to provide a compelling case for upgrades even without support ending.  Between these and several other ideas I have you could make the case so compelling for an upgrade that it might create a rush to “keep up with the SAP Jones’s” so that their competitors don’t gain too much of an advantage.
 
With some of these enhancements, the case for ease of use, business process focus, and innate knowledge transfer are so strong that it provides reasons for small and midsized business sales as well.  
 
If you’re listening and interested have one of your key developers from Palo Alto or Waldorf call me.  After over 20 implementation projects I have a pretty good idea what customers are looking for and what is meaningful to the small and midsized business space.  Let’s work together to “supercharge” the ERP application and in the process shoot for 90% of the entire ERP application space!  It’s time for order of magnitude changes on the customer experience and business process side of the house.

Think about it, these changes cover the vaunted three areas of value proposition all at once–,  product innovation, operational excellence, and customer experience.  How could you possibly go wrong! 

Related Posts:

• Tactics, Strategy, ROI, TCO and Realizing Business Benefit from SAP
• Using SAP to Improve Revenue and Profitability
• Competitive Pressures and Value Propositions, Is Lean the Answer?
• The Real Reason Executive Participation Creates IT Project Success
• Business and IT Alignment – Integrating Technology and IT Spend with Business