Integration – Is It Really Just a Test Phase?

December 2nd, 2006 |   Send this article to a friend!

One of the key advantages to Oracle Applications that distinguishes itself from other competitors in the ERP market is its flexibility.  In other words, a client implementing Oracle has the ability to pick and choose the functional modules that are specific to their business requirements (for the most part).  Combining this modular structure with the flexibility of its application interfaces, reporting tools, database, and workflow driven processes; Oracle becomes a very favorable option to many clients who find themselves limited to what they can do under different applications.

While flexibility is a great advantage - it poses many significant challenges during the implementation process.  An obvious challenge is the difficulty in integrating the chosen modules to form one integrated process.  And it starts from the very beginning with initial scope.  Compared to other software products, it’s quite difficult to make decisions in the early stages of an Oracle implementation to decide what modules to implement when you have to consider the client’s short term requirements and long term vision – all while keeping in mind the

interdependencies of the chosen modules.  This creates a unique situation that is not encountered as often in implementations of other alternative software products where what you see is what you get.

Traditionally, because of the modular structure of Oracle, organizations tend to build their project team in a formation similar to that of the modules the organization is implementing.  For example, a large manufacturing organization would most likely have an Order to Cash team to handle Order Management, Shipping Execution, and Advanced Pricing; a SCM team, usually broken down into separate sub-groups, would take on Planning, Purchasing, and MRP.  A manufacturing team would take on the entire manufacturing process, including items.  While your finance team focuses on general ledger, account receivables, and the rest of your core financials.
 
You get the idea.

All of these teams come together to bring their ideas and expertise within their respective modules to become a driving implementation force.  And while project management encourages the functional teams to work together in designing a truly integrated process, the end product can still result in a system with obvious process integration gaps.  Why does this happen?

An answer to this question could be found by analyzing how the project team is structured.  The intention is to align the organization with the modules you have chosen to implement which provides opportunity for your subject matter experts to focus their strengths on each of their respective modules.  However, this leaves no focused attention to how each of these modules will interact to form one integrated process.  This lack of attention to process integration can result in the process gaps that may be discovered during integration testing.

Many organizations have recognized this organization gap and have attempted to assign the responsibly of module integration to team members whose module is affected.  While this may improve the situation, the results can be minimal.  Adding this additional responsibility, all while your organization aims to meet aggressive budget goals and deadlines, can result in a high-stress environment and an overloaded project team.  This can make it difficult for team members who have been given the additional task of module integration to pull themselves away from their team obligations to dedicate time to integration touch-points. 

Additionally, since integrated process involves multiple modules, it often results in project management assigning members across several functional teams the responsibility of drafting a solution.  But from a management prospective, this type of a situation can be quite difficult to hold accountability.  Unless management does it themselves, there is a reliance on this group to expose and drive to resolution all integration issues.  Thus, there is an inability for management to have complete visibility over the integrated design.  This can become a very difficult situation to manage.

Regardless of the reasoning, the result is an integration gap that exists in the overall system design.  Then it’s back to the drawing board.  Cross-functional meetings are held to discuss the touch-points with the ultimate goal of maintaining their respective designs; only to find that their original design plans need to change to close the gaps.  The next phase of integration testing occurs and reveals more gaps due to design changes that were made to close the initial gaps that were found.  This cycle can continue for several iterations over a period a months.  Even if it results in a successful solution, the organization has suffered possible setbacks and additional costs that were not accounted for.

Some may argue that it is the intention of integration testing to expose these gaps and serves as a sufficient approach to refining the integrated process.  But does it take more than just integration testing to ensure all teams truly stay integrated?  What else can be done to ensure integration gaps are visible and/or resolved so that they don’t come as a surprise in integration testing or later in the project life cycle?  It’s quite possible that other approaches could be taken to ensure integration gaps are closed without having to go through additional integration testing phases.

One idea is to schedule on a regular basis several smaller integration tests which focus on a specific touch point between two functional teams.  In doing this, more face time is provided between the two teams to address the touch-point.  Dedicating the appropriate subject matter experts to the touch-point and not the entire process also ensures you have focused expert attention to a specific piece of the integrated design.

While this provides a good opportunity to expose integration gaps for a touch-point, sole focus on a touch-point and not the process in its entirety could lead to decisions that negatively impact other process touch-points within the integrated process.  Additionally, it still does not address who owns and drives the process to a solution.  And as I mentioned earlier; assigning ownership of the touch-point across several teams can make it difficult to monitor from a project management prospective. 

So how can management affectively assign ownership to the design of an entire integrated process?

One possibility could be to build a separate integration team who would have sole responsibility of finding and facilitating solutions to all integrated designs.  It’s more likely to eliminate the confusion around who has ownership.  Rather than dividing it across multiple teams, a single team has been assigned sole ownership of the task.

Members of such a group would not require an expertise on a specific module, but could instead have a general knowledge of Oracle ERP as a whole.  Having this high-level knowledge, in addition to an understanding of the organization’s business processes, creates a team who can fully take on the responsibility of overseeing the process integration effort and ensure all design decisions made by the functional teams are aligned with the overall process design.  Including in this team an individual who was involved in initial scoping would bring to the group an understanding of the decisions that led to the selection of the modules.  Bridging this knowledge could potentially add a powerful group to your project organization.

Having an integration team would also be essential to scheduling and facilitating all touch-point testing leading up to the formal integration test.   The team would then have responsibility of logging and tracking issues and seeing to it that all integration issues are brought to resolution.  In doing this, your organization can ensure that all integrated designs are receiving constant attention so that gaps are exposed from the beginning and don’t come as a surprise later in the project lifecycle. 

There’s no question that staffing additional resources to build an integration team can increase the project budget, but it’s sure to save time and money that is usually spent on additional iterations of testing and fighting the costly fires of those surprise integration gaps found late in the project lifecycle.  If you’re an organization just starting an Oracle implementation or you’re well within the implementation phase and have experienced the pain of finding integration gaps; adding an integrated process group to your project team could prove to be a very good move.

---

Mr. Thompson is a Senior Oracle Applications Consultant with Lexerd Group Consulting. Visit www.LexerdGroup.com to find out more about our firm.

Interested in hosting your own blog? Lexerd Group’s Internet Services division provides specialized blog hosting services that utilizes the Wordpress blogging platform. Visit http://www.lexerdgroup.com/blog-yourself/ for more details.

Entry Filed under: General