INNOVATE. INTEGRATE. TRANSFORM.

Business Solutions with SAP

SAP Implementation Focus: Engineer Software or Business Processes?

April 29th, 2010 by

SAP Software Engineering or Business Process EngineeringYou’ve selected SAP as your software application, now you move on to look for competitive bids from several software vendors to implement the system.  You have a good understanding of the scope of the business processes you want to address but what do you look for and where do you begin? [FN1]

Your Primary SAP Implementation Focus

There are two primary ways in which SAP can be installed in your company; you make your company fit the software or you make the software fit your existing processes.  These two methods provide the end-point markers or goal posts and all implementations fall somewhere between them.  They present the classic options you have available, either you do a software re-engineering project or you do a business process re-engineering project. 

Let me assure you, SAP as an application has such a massive depth and breadth of functionality, combined with a significant number of industry vertical solutions that this decision can not be underestimated.  No matter what some SAP system integrator or some competing vendor might try to sell you on SAP’s business software applications cover at a minimum 80% and in most cases more than 90% of any business requirement with standard functionality.  After over 100,000 implementations, in nearly every country on earth, in nearly every industry vertical, there just aren’t a lot of gaps in the applications.

SAP Software Engineering or Business Process Engineering

As a business what is your core competency?  If you bring the right business people to the project, is your business competency software engineering or process design to meet customer / marketplace requirements?  If you think of it in those terms the answer for any successful business is clear, you do what it takes to meet customer / marketplace requirements (unless you are a software company).

If your core competence were software engineering and software design you probably wouldn’t need many consultants.  When it comes time to do your SAP implementation the best approach is the one that leans heavily on vendors who can provide the right consultant for your needs. 

If you want to stay closer to the business process engineering goal post (change the business to fit the software) then consultants with heavy project experience will likely be able to help you through the critical change management activities.  In any event your focus will be more on training, communication, and change coordination (see Screening Methods to Find the Right Consultant – Part 2). 

Either you do a software re-engineering project or you do a business process re-engineering project

If your goal is to re-engineer the software application then you will focus more on the technical competence of the army of coders you will pay for.  A significant amount of time will be spent on business process analysis and fit gap analysis (the old “as is” and “to be” analysis).  Your testing will need to be far more extensive and thorough; the number of “break-fix” support resources for your go-live will be significantly higher; you will need extended support resources (read, expensive consultants and developers) for a much longer period of time.  Mind you some of the change management activities will still be needed; they just won’t be needed quite as much.  But you will be gaining SAP system integrator “lock in” for a long time as they support their custom-coded design work.

If your goal is business process re-engineering you will need solid consultants who know the application.   They need enough skill to ensure that the thousands (and in some cases tens of thousands) of system settings are made to meet 90 – 95% of your business needs without any custom coding.  SAP is that broad and that deep in terms of functionality and in terms of industry specific options.

Should You Do SAP Software Engineering or Business Process Engineering?

No matter which route you choose, there should be clear business justifications for the approach you take.  In other words, do you have specific processes that are part of your core value proposition or processes which create significant competitive advantage in the marketplace?  If your processes are that unique to your business model are there other ways to accomplish the same process advantages?  These types of key questions help to clarify whether or not there is a business justification for one approach or another. 

If those unique process areas directly impact your industry or market position then they might make sense for customized modifications.  However in less unique areas, such as purchasing, or accounting, or inventory management, it makes more sense to try to stay close to the standard functionality.  Sticking close to the standard system functionality may require change management, but it will be far more cost effective and less troublesome throughout the entire application lifecycle.  With very few exceptions, be very suspicious of the consultants who frequently seem to need something custom coded.  It may be required, but you should still be suspicious.  Over the years I’ve done SAP the most common area for custom coded requirements is in Sales and Distribution (SD).  The only reason it is required there is because these are customer facing processes most companies just will not change how they do things no matter how compelling your case may be (this is why as a consultant we jokingly refer to SD as the “land of user exits”).

No matter which goal post your implementation is closest to (“out of the box” standard or “make it fit our business”), there should always be a direct business-related justification for custom-coded modifications.  Usually this is not the case.  The most common reason I hear on projects for modifying things is “this is the way we’ve always done it.” 

The closer you stay to the “out of the box” goal-post the less expensive the entire application lifecycle will be: 

  • The initial implementation will be less expensive.
  • Ongoing support and maintenance will be less expensive.
  • Upgrades will be less expensive.
  • And there will be fewer issues and bugs to resolve.

Of course many system integrators love custom-coded solutions.  The more you customize the more revenue they make, both in the initial implementation and in ongoing support and maintenance (which is NOT covered by your SAP support contract).  The more customized the solution the more dependent you are on them for maintaining and supporting it.  And if you go all out with changing the application to match your business processes, and if you build lots of custom solutions, then you might as well get used to those expensive consultants (who have billing rates at 2 – 4 times your salary) as long-term pseudo-employees of your company.  You will likely be paying them for several years after you go live.

Differences in SAP Consulting Models Depending On Your Goal Post

If you are content with modifying, coding, customizing, and otherwise re-engineering SAP your consulting needs lean more heavily toward software engineers.  You will likely require an “army” of ABAP and Java programmers together with lots of consultants who have deep experience evaluating processes and writing technical design specifications for all of the custom coded work. A number of very large consulting firms specialize in this kind of talent by bringing numerous “generalists” to the table.  These are supposed “process experts” with little or no specialization in SAP but are tasked with designing your SAP solution.

Maximize Your SAP Investment

If you wish to use the application to its fullest extent, with minimal modifications or customizing [FN2], then only consultants with deep application experience will do.  As my friend Steve Phillips writes, there are times when modifications are needed and they are justified (see ERP Software: Are Modifications Always a Bad Idea?).  However knowing when that is and when there might be other alternatives takes a significant measure of experience and a very deep understanding of SAP (to know what the application’s limitations are).  For the biggest benefit and the most productive solutions it also takes consultants with some measure of work experience before they started doing consulting work. The most experienced consultants will be able to more accurately identify when it would be best to change the business processes rather than changing the application.  They will be able to evaluate the personalities and culture of the area they are responsible for and understand how much change they can absorb and whether or not certain functionality is appropriate.

Because of the depth and breadth of SAP’s business software solutions there is no substitute for real, verifiable, and deep experience.  If you have any desire at all for staying close to the standard functionality then the “generalists” from many large consulting companies, and the “low cost” providers can not do the job.  The reason is simple.  The generalists just don’t have the application exposure or application experience to know when you should, or should not pursue custom alternatives.  The low cost providers usually (though not always) provide questionable resources with sketchy and hard to verify experience OR they take a project approach that is so narrowly limited in scope that the end result is frequently less functionality and less automation than the systems SAP’s applications replace.

Whether your vendor considerations are a low cost provider or one of the big consulting companies there is no substitute for experience if you want to stay close to the standard system functionality.  I still learn new things all the time because of SAP’s massive depth and breadth (even after doing SAP projects since 1994 and being an entrepreneur and tech “geek” since the mid 1980’s). 

Consequences of Custom Coded SAP Solutions

The custom solution will require significant testing and may require additional iterations.  It is a very frequent occurrence that a custom-coded solution goes into a live productive system and new bugs or other unintended consequences occur.  These bugs and fixes are not supported by SAP’s software maintenance and online solution database.  That means every fix requires additional levels of coding, rigorous testing, and verifying that some new dependency from the fix does not affect or break something else–, unintended consequences of the change.  That custom coding requires lots of long-term hand holding from the vendor who developed it–, you get SAP system vendor lock in.

The custom coded approach requires much more skilled and disciplined project management around testing and coding quality checks.  While testing is critical for every project, and for every part of the system that is going to be used, the custom-coded testing requirements are very different.  Where testing standard application solutions is more for fit and function (does it do what it needs to and is the data correct) the custom coded solution has new dimensions of dependencies.   Some of the things you have to consider are:

  • Does the custom coded solution even work as planned? 
  • Does it create new data dependencies and new data maintenance requirements? 
  • Does it interfere with the operation of other system functionality? 
  • Does it create new dependencies requiring additional processes to be coded to “bypass” other standard system functionality that it is not compatible with?
  • Does it create performance problems? 
  • Is it coded correctly so that data inconsistencies do not occur? 
  • Can it scale up? 
  • Are there regulatory implications (such as in healthcare and FDA validation)?
  • Etc., etc., etc.

The list really could go on and on, but this provides some idea about the differences in testing requirements.  And it isn’t that the standard options don’t have these same issues, they are just less intensive and less dependent on correction. 

Frequent Custom Coded Messes and Ongoing Maintenance Costs from Bad Design

The standard application functions need to be tested more for fit and function, not whether or not they even work.  And if you do discover an actual problem with the standard options your SAP maintenance agreement covers SAP providing a fix for their own application.

These issues may be present with a standard solution as well; however you have the benefit of many other customers discovering these items; referring them to SAP for a correction; and then SAP providing a solution as part of the standard maintenance.  For example if you notice a performance issue with standard functionality it may require an hour of researching SAP OSS (Online Support System) Notes, and then applying the fix in that note at some convenient time.  Depending on the system setup and design, testing may be performed relatively quickly.  And here again, the level of testing even for applying note fixes depends on the amount of custom coding.  If there has been a lot of custom coding the testing will be extensive to ensure that the custom coding was not broken by a “standard” system  fix.

For the custom coded solution, this relatively “easy” fix might take the time of an experienced system guru (an SAP Basis expert) to run performance traces and logs, then after the source of the performance problem is isolated program debugging, program fixes, testing, possibly additional iterations of fixes and testing, and then moving it to production and hoping something else doesn’t break.

The level of project management skill is more significant with the level of testing rigor for large projects with significant amounts of custom-coded solutions.  The number and types of variations of testing and potential problems is also more significant.  Rather than just testing for fit and function (as with standard functionality) the level of integration testing between and among all other areas is increased.  And where the standard SAP solutions have had the benefit of hundreds, or even thousands of customers and system integrators beating on it and testing it, you are the only company testing or resolving your custom solution.  No matter how thorough you are and no matter how skilled the consultants are something will be missed.

On top of this, inconsistent or poor coding methods can cause huge problems and creates major risks.  I have seen many problems that are not readily apparent during the “controlled” testing that most projects do which causes huge problems in a production environment:

  • Whole tables (all records) being locked from processing rather than individual table records thereby preventing all users in all locations from being able to process similar functions.  Single record “controlled” testing did not reveal this until live in production.
  • User exits (custom coding points in the source code provided by SAP) coded improperly so that they create other records or other processes before the record that triggers the requirement is completed.  If anything happens and the initiating record does not post then an inconsistency is created.  Again, another anomaly that is a rare occurrence and probably would not be discovered in testing.
  • Massive performance problems from poor coding and repeated select statements that are unnecessary (rather than using proper join statements in selects to minimize the number of database hits).
  • Badly coded forms that cause entire transaction processes to “crash” without any indication there was a problem.
  • Poor use of fields for selection options, or missing selection options that then process massive data tables without any restrictions.  This is not seen in the “controlled” testing and may only be discovered after larger amounts of data are available.
  • Direct table updates that bypass normal system checks and create huge data “messes” and data “orphans” when they do not process correctly.
  • Over engineered and overly complex custom solutions when much simpler and more elegant options were available.  Sometimes the option is change the business process rather than trying to custom code a more painful “fix”.
  • Hard coded program values rather than using parameter tables so that every time a key value changes in a company or organization the program has to be modified, re-tested, transported, and then hopefully nothing that is dependent on it gets broken (because other dependent programs may have hard coded values) .
  • Etc., etc., etc.

I’m always amazed at the amount of “hidden costs” of all of the “gee whiz” we really need that custom solution which too many system integrators are happy to accommodate.  Sure, some of it is required, but some of it is also a complete waste when there are other alternatives.

In the end it is your system and your solution.  There are always some good reasons to move some areas of the application toward the goal post of modifying the software to fit your business processes.  However many times standard functionality, or only slight variations on the delivered standard functionality is all that is needed.  The more you are able to minimize the custom coded solutions and make the changes to standard application options the less expensive your application lifecycle will be.  In the end some things will need custom coding, but minimizing that will minimize your costs and headaches as well.

Always keep in mind that there are tradeoffs, just like pushing on one side of a balloon.  As you push in one area it comes out in another.  If you choose to keep the application closer to standard functionality then you will likely need to budget accordingly for change management because processes and jobs will be changing.  If you make the application fit your business processes change management issues may not be as significant (but they will still be there), but you will pay more throughout the entire application lifecycle. 

What can you do to minimize this?  Insist that every custom coded request be supported by a specific business justification, and then insist that a whitepaper be written that shows what other alternatives were considered and why they would not work.

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

[FN1]  One thing to keep in mind is that SAP’s ERP application primarily addresses value propositions related to operations.  It is not because the functionality and the capabilities do not exist to do something different, it is because system integrators don’t generally know how to do it.  While there is both functionality and the ability to build integrated custom solutions within the application for increasing revenue and profitability this is rarely done because the marketplace hasn’t demanded it (see Using SAP to Improve Revenue and Profitability).

[FN2]  In SAP there is a technical type of “customizing” that is more like core application modifications or adding additional and specialized custom coding to existing places in the software where this is allowed.  However, there is another type of “customizing” that is frequently referred to as “configuration.”  This type of customizing is very different.  It involves setting up new standard system data types, such as new document types for POs, Sales Orders, Accounting Documents, Production Orders, etc., and then making standard system settings to support specialized business process requirements.  Because the “configuration” type of customizing in SAP has literally hundreds, and in many cases THOUSANDS of potential settings and options for any single process chain (such as order to cash, requisition to pay, plan to produce, etc.) there is no substitute for experience.  These requirements and more also mean there is no room for fakes or “freshers” as they are often referred to by the consulting fraud factories (see Screening Methods to Find the Right SAP Consultant and Screening Methods to Find the Right Consultant – Part 2).




Popular Searches:


  • What type of information should be provided to a software company when you want to integrate with an SAP system

Related Posts:

The Top 5 ERP Success Factors by Project Stage from 22 Critical Success Factors

April 26th, 2010 by
Top ERP Success Factors

Top ERP Success Factors

 

Recently I was reviewing academic material on ERP / SAP Project success factors.  One particular study stood out because it laid out 22 specific success factors by project stage.  [FN1]  Even though this study dates from 2001, the Critical Success Factors (or CSFs) still ring true today, and the conclusions are consistent with what I have seen on SAP projects since I started in 1994. 

While the sample size was somewhat limited (86 completed questionnaires) the data and information provided was useful for understanding some of the key or critical success factors. 

The stages reviewed were:

  • Initiation – business need, software selection, vendor selection.
  • Adoption – beginning of the implementation process and system design.
  • Adaptation – implementation, adjustment, and business fit stage.
  • Acceptance – go-live and productive business use of the system.
  • Routinization – the overall acceptance and sustained productive use of the system.
  • Infusion – long term acceptance and use of the system as well as additional functionality additions.

Based on the academic literature when the study was done, there were 22 key ERP Project Success factors that were defined (in order of the study’s response importance):

Importance Description
1 Top management support
2 Project team competence
3 Interdepartmental communication
4 Clear goals and objectives
5 Project management
6 Interdepartmental cooperation
7 Management of expectations
8 Project champion
9 Vendor support
10 Careful package selection
11 Data analysis & conversion
12 Dedicated resources
13 Use of steering committee
14 User training on software
15 Education on new business processes
16 Business Process Reengineering
17 Minimal customization
18 Architecture choices
19 Change management
20 Partnership with vendor
21 Use of vendors’ tools
22 Use of consultants

This study went on to break out the top 5 reasons, by project stage, for project success.  And what I have done is added one additional dimension.  I assumed significant results to be at least 3% above the median result.  This showed that in each of the project stages there are areas that are statistically significant, and areas that are more likely dependent on each individual project.  One important item to note is that while any particular project may have a completely different makeup, equating to entirely different factors of importance, these initial assumptions provide a great place to start an analysis.

Top 5 Success Factors by ERP Project Stage:

To make as much sense of the data as possible I assumed the lowest value of the top 5 was my baseline value and anything within 3% of that value was within any margin of error (the sample size may actually make the margin of error closer to 5%).  As a result, anything within that margin of error I am considering a “toss-up” for any particular project.  However, anything outside of that 3% range I am considering statistically significant and having much wider and more general application to most projects.

However, no item in the top 5 list by each stage of the project can be underestimated or overlooked.  After all, these are the distilled “critical factors” for project success by project stage. 

Stage: Initiation    
1. Architecture choices 71% Statistically significant
2. Clear goals and objectives 63% On the margin
3. Partnership with vendor 61%  
4. Top management support 61%  
5. Careful selection of package 60%  
     
Stage: Adoption    
1. Top management support 68% Statistically significant
2. Project team competence 61%  
3. Use of steering committee 60%  
4. Partnership with vendor 60%  
5. Dedicated resources 59%  
     
Stage: Adaptation    
1. Interdepartmental communication 65% Statistically significant
2. Interdepartmental cooperation 63% On the margin
3. Project team competence 63% On the margin
4. Dedicated resources 60%  
5. Use of vendors’ tools 60%  
     
Stage: Acceptance    
1. Interdepartmental communication 64% Statistically significant
2. Interdepartmental cooperation 63% Statistically significant
3. Top management support 56% On the margin
4. Project team competence 55%  
5. Education on new business processes 53%  
     
Stage: Routinization    
1. Interdepartmental communication 51% Statistically significant
2. Top management support 42% Statistically significant
3. Interdepartmental cooperation 41% On the margin
4. Vendor support 36%  
5. User training on software 36%  
     
Stage: Infusion    
1. Interdepartmental communication 39% Statistically significant
2. Interdepartmental cooperation 35% Statistically significant
3. Top management support 32% Statistically significant
4. Vendor support 28%  
5. Partnership with vendor 28%  

One thing that stands out in this analysis is that through much of the project stage, and then after the system is productive and live, interdepartmental communication and cooperation rank consistently at the top.  Right behind them, top management is a consistent theme, and then vendor related prospects round out the top (vendor support, partnership with vendor, vendor’s tools, and project team competence).

Conclusion on ERP Project Success Criteria – The Top 3 Recurring Success Themes Across All Dimensions of an ERP Project

So, in broader or more general terms the academic literature bears out my personal experience.  Across the entire project and application dimension the key success factors for ERP projects like SAP are (in order of importance):

  1. Interdepartmental communication and cooperation.
  2. Top management involvement (presumably this would help encourage the first item as well; see the post entitled “The Real Reason Executive Participation Creates IT Project Success”).
  3. The quality of the implementation vendor (consultants, tools, etc.).  For more information on selecting a quality vendor see this four part series:

               Achieve Breakthrough ERP, SAP, or IT Project Success: 1 of 4
               Breakthrough Project Success: 2 of 4, IT Vendor Proposal RFP
               Breakthrough Project Success: 3 of 4, Vendor Selection and Contracts
               Breakthrough Project Success: Part 4 of 4, Last Low Risk Chance for Results

So Why do SAP or other ERP Projects Fail?

Obviously there can be any number of reasons why they would fail.  Even the 22 success criteria for ERP or SAP projects listed in this post is not comprehensive.  However you can be sure that when there are consistent themes across nearly all dimensions of a project, any of them that are lacking would create significant risk for failure.  At some future date I will be publishing a proprietary and unique evaluation model which will help to clearly identify the key project risk areas specific to your company and your implementation.  

For a quick summary of the 3 key areas and one of the high risk areas that you have the least amount of control over consider the following: after having selected the application system and the technical infrastructure to support it, these three items are critical ingredients for your ERP project success.  Top Management involvement and interdepartmental cooperation are directly and completely within a company’s control, however the ability to influence the type of vendor is only indirectly controllable through the selection process.  If the vendor selection process leads to the selection of a less than optimal vendor you may not realize your desired business benefits even if you get everything else right.

What this study points out even more clearly is why it is so critical to have consultants with verifiable experience (Screening Methods to Find the Right SAP Consultant), who can bridge the technology to business gap with strong communication skills (Screening Methods to Find the Right Consultant – Part 2).   There is no substitute for Protecting Yourself from SAP Consulting Fraud.

The second item related to top management involvement may have reasons not considered here or in other resources; like the ability to imprint future strategy and business direction on the technology implementation.  The post already noted (The Real Reason Executive Participation Creates IT Project Success) points this out and demonstrates the importance of senior level management involvement in a project.

Without those quality resources provided by your consulting or resource vendor your chances for project success diminish significantly.

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

[FN1] Somers, T., and Nelson, K., (2001) The Impact of Critical Success Factors (CSF) across the Stages of Enterprise Resource Planning Implementations.  Proceedings of the 34th Hawaii International Conference on System Sciences.




Popular Searches:


  • erp success factors
  • key success factors for implementing 3rd party vendor software

Related Posts:

ERP Project Plan: Getting Real (Part 2)

April 16th, 2010 by

SAP Project DimensionsThirteen Dimensions of Project Scope

In many cases the ERP project plan is not worth the paper on which it is printed. Worse yet, many project managers shoot themselves in the foot by prematurely committing to a project schedule and budget that sets unrealistic management expectations. The problem is once cast, expectations will not go away and only come back to haunt you later.  Could this be one reason why many ERP projects “fail”?

Even when the schedule and budget are “formally” published, inadequate definition of project scope (and boundaries) is a major reason the plans are invalid and quickly tossed out the window. In other words, we need a project scope, schedule and budget that closes expectation gaps. A project plan people can believe and use to actually manage the project. What a crazy idea!

Project scope not only drives baseline project schedule and budget; but it also sets user expectations regarding what they will get (and not get) within the software functionality. When users are later told something is out-of-scope they really need, the project is in for many unhappy users or scope creep that results in surprise cost and schedule overruns. Take your pick.

Finally, a good scope document represents a major tool for the project manager to control the project. Like a referee in a football game the project manager needs the ability to throw the yellow flag. However, it is always best when all parties involved understand the rules of the game before the ball is put into play.

Purpose of this Project Scope Article

The purpose of this article is not to imply good or bad scoping decisions. The goal is to assist the practitioner in understanding the key elements of scope, potential implications, and set the right expectations. Next this enables the practitioner to develop a schedule and budget that is real and people can support. After all, it is people that must make this plan a reality.

I make reference to the “dimensions” of project scope. This is because scope and boundaries do have dimensions in terms of different views of the project, level of detail and other twist that warrant a separate and distinct perspective on scope. With regard to the actual deliverable, most of the dimensions below should contain a list of items, and each with a “degree of complexity or effort” (high, medium or low).  In the next blog entries, we discuss how this information is used to develop a project schedule and budget.

The Thirteen Dimensions of ERP Project Scope and Boundaries

1) Align scope with project objectives

The fact is most organizations implement ERP for business reasons. Therefore, project objectives (what you want to accomplish) must initially drive project scope, not the other way around. It is never a good idea to proclaim the project will solve all the world’s problems, and at the same time, limit scope to the bare bone necessities to get the software running on the computer. This is where “rapid deployment” strategies get into trouble since they are  designed to limit scope for the sake of time and cost (though outcomes are far from guaranteed).

Furthermore, last minute acts of desperation to cut scope to get back on schedule are usually done without a full understanding of the original objectives that are now compromised. Therefore, if scope is to be cut half-way through the project, objectives and expectations must be realigned with the new reality.

On the other hand, too much scope beyond what is required to achieve objectives (and for the software to function effectively) is not a good thing either. This is usually not a popular philosophy among users, but a necessary one since “scope creep” is inevitable to some degree on any project. Therefore, early on it is important to “condition” managers and users that the system is not intended to be “all things to all people” and expanding scope will not be easy. In fact, once approved, any proposed changes must be business justified and approved by senior management.

2) The Number of “Sites” involved

For the purpose of this discussion, a site is defined as: 1) a physical location, or 2) a logical site. For example, there could be more than one “business unit” at a location, each having its own customer service group using the same software. In “multi-site” scenarios, the scope issues are three fold.

First is the coordination and communication effort required to get and keep all team members, key managers, and users at each site on the same page. Not to mention, I have yet to see any multi-site implementation where a certain amount of politics and finger-pointing between sites did not slow progress. This does impact project effort and how quickly things move along.

It gets worse when the same software module is to be installed in more than one site. In this case, decisions regarding “common” versus “unique” requirements at each site are necessary; and this takes time. This also plays into the decision to treat a given business process at each site, as a single or separate process from a design and set-up perspective. In any event, if the plan is to “reinvent” the wheel for each site, this will increase complexity, schedule, and cost (scope).

Finally, each scope dimension below should be defined at the site level (if the goal is to get a good picture of what the project truly entails).

3) Software Modules

The modules to include in scope drives the overall footprint of project. No doubt, this is one of the first steps in addressing scope. The bad news is when some put a project plan together, the software modules in-scope are one of only a few things considered.

The problem is without further definition, it is difficult to understand what “modules” mean from the standpoint of establishing expectations with users and estimating project duration and budget.

Beyond the fact that modules lack sufficient detail, some modules are more involved than others. For example, anything with the word “advanced” in front of it usually means more complexity, more risk, more time, and more money.

In addition, whether a module implies advanced or not, some modules are  inherently more difficult to implement for most organizations. As an example, the Purchasing module in most packages is usually less of an issue than the Sales Order module. This of course is not universally the case; but level of complexity should not be ignored.

4) Key Features and Functions within each Software Module

This is a lower level of software detail often over looked. Each module has features, functions, and capabilities. It is always best to consider  the capabilities to be utilized right up-front. Otherwise, consultants and the team will waste time and money setting up software functionality that client management has no intention of implementing (or adds little value to the overall objectives). Granted, some discovery may be required to understand the applicability of features and this is never a perfect process. However, this is different then going far down the road spending time on features of marginal value (and no one cares about).

5) Business Processes

The client must identify the business processes to automate. In doing so, one must get into the “sub-process” level. For example, “Procure-To-Pay” is a major business process; but this alone does not tell the story. When we go to the next level, it starts to have meaning.

For example, within this major process, some of the “sub-processes” include: 1) Quotation process, 2) Requisition / Approval process, 3) PO process, 4) PO Receipt process, 5) Invoice / Voucher match process, and 6) Payment process.

6) Business Process “Variants”

All too often people assume a particular “sub-process” (examples above) represent a single workflow. However, in many cases nothing could be further from the truth. A simple example is “receipt of a purchase order”. In most companies, there are many types of purchase orders that are received and transacted very differently (and for good reasons).

As a result, from a scope standpoint each may require unique analysis, system set-up, and testing to the point they should be treated as separate sub-processes (or perhaps children of a sub-process). No matter what we call them, when included they expand scope and must be recognized.

7) Degree of Business Process Redesign anticipated

It is one thing to say a business process is in-scope; but again this is only half the story. This is similar to the complexity factor, but I like to highlight it separately because it can have huge project implications.

For each business process, it begs the following questions:  How convoluted is the current business process? Does it need significant reengineering? Are you planning to implement an entirely new operating philosophy? On the other hand, are you attempting to automate a current process that is well defined and works well today?

There is no right or wrong answer here, but the more one must redesign a process, the more decisions to be made (usually the longest pole in the tent), the more design work to be done, the more emotional it gets, the more issues and unknowns, and the more testing required. There is nothing unusual about any of this, but there is no way around it. When significant process changes are needed, schedule and budget for it accordingly.

8 ) The Number and Complexity of Data Conversions

In scoping conversions, get to the level of understanding the key files in the new software (target system), where the data is coming from (source system or otherwise) and how it is going to get there (manual or automated). Also, do not forget how history records are to be addressed (if at all).

The level of effort comes into play with the following considerations: 1) Source data clean up required prior to converting, 2) The format of key fields in the existing system and the need to get the data into the format of the new software. This includes not only field sizes, etc for important data items, but also how the data is used within the business. 3) The anticipated complexity of the conversion process, program logic required and level of effort to test. 4) Keep in mind, it could be much less time consuming to load data manually versus the alternative of writing conversion programs.

9) The Number and Complexity of Interfaces

This includes interfaces between “other” systems and the new ERP system. The time and cost to design, develop, test and maintain interfaces are almost universally under-estimated. The cost issue includes design and mapping of interfaces, third-party developers or additional “middleware” required (software and hardware). From a quality standpoint, even when thoroughly tested, no interface is fail proof (expect problems at some point).

Therefore, ideally one wants to replace as many legacy systems as possible within each project phase to minimize or eliminate temporary interfaces (that exist only during the transition) and permanent interfaces (to legacy systems deemed outside the final project scope). This tends to be the case even when a few modifications to the new software are required to replace the legacy system.

Expanding the number of modules (to eliminate interfaces) is a trade-off between interface scope and additional module scope. From a user perspective, interfaces are usually assumed the path of least resistance, but often times they later find out this is not the case.

Each interface and the level of complexity should be documented in the project scope. When identifying interfaces, realize there may be more than one interface between two systems (and some going in opposite directions). Therefore, what may initially appear on the surface as a single interface may actually be two or more interfaces.

Do not forget “one-off” databases in the user area that are out-of-scope but linked with the legacy system. They may or may not be supported by the IT department, but nevertheless, can be critical to the business. Also, interfaces to other new third-party software or hardware included in scope must be acknowledged.

It can get worse. Interfaces may force customization to the target or source system to add additional fields and screens to either system (to support the data needs of the other system).

Finally, the complexity issue includes (but not limited to) the frequency of the interface, real-time or batch updates, sequencing and dependencies of data transmissions and data format issues that impact the complexity of interface program logic (similar to data conversions). The question from a user standpoint: Must the users work in both systems (instead of one today)? If so, for how long?

10) The Number of Reports

The number of reports should be estimated since the accumulation of all reports can represent a significant effort. First, get a complete list of reports (from ALL current systems to replace), the distribution list for each, and frequency of usage.

Ask the users to review the list and comment on what reports they “must have” within the new system (wrong, right or indifferent – at this point we are trying to estimate. It is OK if the revised list from the users is full of assumptions) However, this will eliminate many reports that exist today.

Next analyze the list to see if the “must have” reports can be combined, eliminate by standard reports from the new system (or with slight modifications) or the availability of data on-line (or via spreadsheet user downloads) from the new system eliminates the need to write reports. Once this is accomplished the list should be more manageable.

Finally, add a contingency of about 15% to 20% to cover new reports the team or users will eventually asked for once they figure out the additional information available in the system.

11) The Number of End-Users

Whether there are twenty end-users or a thousand end-users, the team still must do all the process and software work for implementation. However, the number of end-users impacts the number of “key users” (subset of the entire population) to be heavily involved. Of course, the more people involved, again, the greater the scope. Not a bad thing, just reality.

The number of end-users also affects the end-user training timeline and resources. During the planning phase, it is necessary to get a handle on training time and resources requirements. Think of this as a rough-cut end-user training plan (not a detail training schedule). Do not wait two months before training to start this planning.

The project team must train end-users as close to go-live as possible. Training more than three or four weeks prior to go-live is a problem since users will not retain what was learned. The more one compresses the timeline to meet this objective the more resources typically required.

This time constraint could drive the need for more trainers since some training sessions may run concurrently. It can also impact the number of facilities, equipment and other resources that otherwise could become bottlenecks. Therefore, one must consider the trainers and resources now in order to get the right people involved early on, estimate a duration for end-user training in the schedule and to properly budget for it.

12) Software Customizations or Enhancements

Most know by now software “mods” (customizations or enhancements) increase risk, time, cost, and can negatively impact software quality. Therefore, eliminating or keeping them to an absolute minimum is always recommended. However, in the real world organizations make mods and often for very good reasons. The question is: How do you handle them during the scoping and planning phase of the project?

Here is the answer. After evaluating software, when there are strong perceptions mods are required, do NOT automatically include them in the project scope unless ALL of the following apply:

A.    Software limitation is verified

Early testing / verification (immediately after the software evalution) has been performed to confirm the software limitations exposed during the evaluation.

B.    Functionality is linked to key project objectives

The proposed mod is deemed by management as critical to the success of the project.

C.  It is understood what is required and how the mod is to be made.

The mod is defined in terms of specific functionality, external design attributes(screens and logic) and how the mod will be accomplished from an internal design standpoint. Internal design means: Are we proposing outright “customizations” to existing programs and tables? Or changes through more external “enhancements” that integrate with the system while attempting to minimize the impact on existing programs and tables? (for the sake of future upgrades).

D.   The Mod is “pre-approved” for scope planning purposes only    

Management has “pre-approved” the mod with a full understanding of alternative solutions and project impact (extra time and cost). Pre-approval means the mod is recognized as “in-scope” and included in the schedule and budget, but NO coding is allowed to proceed as this point.

E.    There really are no other viable solutions

The need for the mod is tested and verified again during the prototyping phased (usually following project team training and runs currently with current process analysis). The reason is, regardless of the original perceptions, once the team learns more about the software and looks closer at different ways of doing business, a proposed mod may not be required after all.

F.  Final Approval

After prototyping, if a mod is still deemed necessary, estimates are revised and present to management for a final approval. Afterwards,  the scope, schedule and budget are revised accordingly and the modifications can now proceed.

Get a Jump Start on Modifications Discovered Early On – They are on the Critical Path

Disposition of proposed modifications discovered during the software evaluation process must occur before the “official” design phase of the project . This allows for an “early start” in programming the modifications. The balancing act to consider is while any proposed mod must be understood and justified (with due diligence), waiting too long to start coding can put the schedule at risk. Always remember, most mods are on the “critical path” within the project schedule.

Other Potential Modification Scenarios

In the situation where some mods are expected, but none are yet defined or approved, it is a good idea to build some reasonable “contingency” in the schedule for good measure(even though senior management must later approve any mod and the project schedule is revised accordingly).

When there is a “no modifications allowed” policy proclaimed by senior management, do not plan for any. If mods are later proposed, they must be approved by senior management. In this case, the decision to expand scope rest with senior management, not the project manager.

13) Boundaries (what is out-of-scope?)

For all dimensions of scope discussed above, it is always best to go back and document what is “out-of-scope”. This more clearly establishes the project boundaries. The reason is people sometimes “hear what they want to hear”, and make assumptions on their own about what “in-scope” means.

We have all been there before when the manufacturing manager says (for example): “Steve, I thought shop floor control included wireless data collection!”  Response: “Sorry Joe, that is not what we meant.”  The point is, “in-scope” states what is included, but it only implies what is not include.  Why not state the out-of-scope items up-front to avoid confusion or prevent someone from attempting to slide it in the back door later?

The problem is even though the project manager may “win” this particular scope issue, he or she may actually lose in the long run when Joe no longer supports the project. It is better to get Joe on board with the decision early on or recognize it as in-scope before we put the ball into play.

Conclusion

The “Scope and Boundaries” document is a key deliverable within the “scoping and planning” phase and is completed before the project schedule and budget are finalized and the project is officially launched.

The scope document is the responsibility of internal project manager, with the help and guidance of the consulting project manager. It requires the participation of the executive steering team, executive sponsor,  project team, application consultants, key managers (process owners) and some knowledgeable and influential end-users. Though many are involved and provide valuable input, scope must be managed very closely, and tough decisions are usually required by the project manager and senior management.

The final version of the scope deliverable is next presented to all the above as a last review. Depending on how formal the organization, it is  signed-off by the executive steering team. Now, as a project manager, you have something valid to serve as input into scheduling, budgeting and later controlling  the project. 

http://it.toolbox.com/blogs/street-smart-erp




Popular Searches:


  • how might the project team recommending an erp design strategy justify its recommendation as compared with other types of design strategies?

Related Posts: