Supply Chain Management

Over this weekend, while reflecting on various points and going through the proposed framework to integrate Agile in the current project set up, I realized that there are some key points to consider for a package implementation and specifically for a complex business process like Order Management.

1. Know the process and issues - Even before the decision is made to select and implement a package, it is important that a high level business process framework is defined and key issues are identified. This is important as the framework and the issues will become the drivers for defining the priorities in later stages. The objectives need to be definitive, driven by numbers and should have a buy-in from the executive team.

2. Involve all the stakeholders - It is important to identify the key business stakeholders for the process. Simple thumb rule is - if a business process causes a code to be executed in the application - it must have a business owner. Complex business processes like Order Management straddle multiple realms - Customer Service, Supply Chain, Marketing and Logistics. It is important to identify the owners for each process and mechanism to break deadlock when the objectives of functions contradict each other. For example, it is very important to identify which business owner will define how 'back orders' will be handled, Supply Chain or Customer Service.

3. Focus on end objective and not the 'how' - I must say that I picked this point from the ppt of introduction to Agile Methodology. A a very obvious but hard to swallow truth for business users - a lot of requirements actually try to define 'how' instead of 'what'. This constrains the solution designers in finding the optimal solution to the real 'what'.

4. Introduce numbers early in the game - Most package applications have pre defined best practices integrated as work flows and also allow modeling of business processes using customization frameworks. This flexibility sometimes works to the disadvantage as well. During requirement gathering and process definition phase it is not uncommon that designers spend a lot of time working with business to find the middle ground between a customization and business process change. This is the phase where tools from the agile methodology can help the most. Tools like use of User Story, Use Cases, demos and Priority Assignment can help the users and designers work iteratively to define the detailed business process and requirements. Involving the technical resources early in this phase allows building realistic estimates for customizations. These must be used as basis for prioritization of the User Stories/functionalities and the customizations requested. Attaching a number to the user story or use case allows business users to evaluate the cost/benefit trade off and also allows the team to estimate the TCO for delivering the solution.

5.  Plan the base and the increments - In today's dynamic business environment short increments to the base application allow businesses to keep their applications in sync with the business needs. It is important that the stakeholders, IS and solution design team identifies the critical to business processes based on two parameters:

  a. What can be on-boarded to the package application without much customization?

  b. Business critical functionality.

It is very important to define the business critical functionality. In my experience, a lot of customizations are made to applications to meet vague business scenarios that might happen once in six months. It is very important that business stakeholders and design team include only those scenarios that are 'must have' and define a workable workaround/manual process for the remaining scenarios during the first base code drop. Every business process that requires customization must satisfy the following criteria:

  a. The process provides competitive advantage and is unique to the organization

  b. The customization will lead to exponential increase in busness value added 

The base application delivery can then be executed either using the traditional SDLC waterfall model or using agile methodology. The increments are aways prime candidates for short sprints using Agile.

As we continue on the journey to integrate agile methodology into our project execution, I see a hybrid approach evolving for executing large programs. Looking forward to hear your experiences with using Agile in large business transformation programs.