Infosys Microsoft Alliance and Solutions blog

« The need for a business applications framework | Main | Unique Column values in Azure Table Entity »

Connecting the Dots: Sizing & Percentage Fitment for Package Applications - A Perspective

While working on the Sizing Approach, we have found that there are various factors which come in play to define  a "true" fitment of the package application to the client needs. Some of these factors are described in my previous blog around "Percentage Fitment Anomaly - Gosh! Did I just over-sell/under-sell the product to my client?". There is a detailed blog by my colleague Amol Gupta around the Challenges in Sizing Package Application Based Implementations which brings forth the concept and its related dimensions. This blog is an attempt to try and explain this furthur to stress on the need of having a multi-dimensional view of the fitment before selecting a package of choice.

Sizing is an important aspect as it helps our clients and the delivery teams to be on a common foundation and understand the way the business needs of today and the future would be met by the package through package solution definition, configuration, customizations and workarounds.

Sizing is not only related to the cost of the project but is a good measure of assessing -

  • What is the size of the business need of the client that need to be achieved in the application?
  • What is that business functionality that is available out of box from the package?
  • What is the business functionality that is available in the package but is not the current business need for the client?
  • What is the future business need of the client that would have to be incorprated in a package?
  • What are the features in the product roadmap that may meet the client future business needs?

While recommending a package to our clients, we are always concerned about answers to these questions. Besides this, we also need to look at the overall portfolio and technology footprint. I had touched upon the EXIST framework for Application Porfolio Management which can work along with sizing perspectives to give real value to our clients.

I thought that it might be a good idea to depict this "Sizing Concept" in a visual form for clarity. The figure below depicts the footprint of the 3 buckets of fitment for 2 different packages and same client needs.

 

sizing_representation.jpgThis is the convention -

  • X represents the coverage of out of box functionalities of the product meeting the client needs.
  • Y represents the coverage of un-used out of box functionalities of the product that the client does not need.
  • Z represents the coverage of additional customizations that need to be done to the product for meeting the client needs.

In the figure, the first package is an advanced package application (like Microsoft Dynamics AX) with a lot of functionality. The client need would be met out of box (X1) with some customizations (Z1) while a large portion (Y1) would remain unused. Taking an example, we can have a client who needs Financial Management, Procurement and Sales as a business need. This can be met mostly out of the box in AX (X1); but there could be some customizations needed in the product (Z1) around the way credit history needs to be verified and holds applied on Sales Orders. However, there would be lot of functionalities like Warehouse Management, Manufacturing, Process Manufacturing, Master Planning, Project Accounting, CRM, Service Management, Human Resources Management, Employee Self Service Portal, Payroll, Expense Management, POS/Retail Solution, etc. which are available in the product but would remain unused (Y1). These may be needed by a larger enterprise as the need for an ERP expands into other business lines and functions. Hence, this will work well for clients where we have a clear future roadmap for the advanced features which may/would be implemented in future.

On the other hand, the second package is a leaner product with lesser functionality (like Microsoft Dynamics NAV). Here the same client need would be met to a lesser extent out of box (X2) with more customizations (Z2) while a smaller portion (Y2) would remain unused. Taking the same example as above, we can have another client who also needs Financial Management, Procurement and Sales. This can be met to a lesser extent out of the box (X2) and would need more customizations (Z2) around credit history, holds, workflow, requisitions, reporting, etc. There would be lesser functionalities available beyond this in the product (Y2). Hence, this may be a good option for client whose needs are more or less defined and would not change or expand into other areas too much.

From the sizing perspective; this means that in isolation percentage fitment can't be classified as GOOD or BAD. It is the overall context of X, Y and Z which will help define the true sizing and fitment.

Does this make sense? Do let me know...would look forward to your PoV on this.

 

Comments

There are two more dimensions I think we can add:
1. Modules/granules of product. Each product functionality (x1+y1 or x1+y2) should be ideally divided into relevant feature chunks so that when a client looks at a product the unused functionality (that is bought) viz y1 or y2 is minimum. This would provide max value for money for the client and is also a component of "good/bad" fitment
2. The features and functionalities of the product are also changing -(if we represent that as top corner of the trangle of product) what we call the product roadmap and focus areas. In that case, even is the existing product and business needs may have bigger gap, over time these can overlap to greater extent (top cornet moving to right to overlap more on business needs). This also becomes criteria for "good/bad" fitment.

Point 2 above is analogous to your point on business needs expanding.

Thanks Dayanand for your point of view. I fully agree to your points. The only thing is that on point 1, my assumption was that Y1 or Y2 is the functionality that the client gets along with the base cost of the product (no additional payment needed). For eg. When the client buys Advanced Management edition of Microsoft Dynamics AX for his Financial and PO/SO needs; he also gets Projects, Warehousing, Basic HR, Production, etc. which is not implemented but does come at the same cost (read license cost). These modules though available are not implemented. Here it may be a feature like Application Integration Framework (available in Advanced Management Edition but not available in Basic Edition of MSD AX) which decides the version, though lot of other freebies are also there that are not used. So, truely it may be difficult to qualify the fitment as "Good/Bad" on the economic scale. Does that make sense? Do let me know your views on this.

The second point of course if a very valid observation and we need to look at it closely when we recommend the product.

Very interesting POV, thank you - one can visual an algebra of sizing package apps, predicated on a certain granularity/complexity/effort and validate it with previous project data to create a baseline.

Thanks Aaman. We are actually using this sizing to help create a baseline. We are facing challenges in achieving an overall sizing number while considering the 3 variants X, Y and Z. Would look forward to any thoughts around this!
This would be important to define an overall score or a rating band which can be used to compare 2 similar project situations and in future may even help in defining productivity improvement norms which in the end will ultimatelty help reduce the TCO for our clients, This can act as a transparent mechanism to work together with client and have a common talking language based on 'Size'.

I believe that the lesser the Z portion of your diagram the better it is to the customer. The price of the software is negotiable. When we get to functionality and upgrades to the next versions, the lower customizations i have, the faster i can move on to the next version. Another point also is, lower the customizations, faster it is to deploy the solution to start with.

Another reason why i would prefer a lower Z area is that the functionality provided by the Publisher is more likely to be imporved from feedback from the field rather than a customized changes from a partner. Especially with Microsoft being the publisher.

Thanks Kartikeya for your comments.

I totally agree with you around the need for Z to be minimum and this has to be one of the important parameter at the time of package selection itself.

I see Z being higher when the client needs some niche processes (very much unique to their business) from the application. These need to be built into the application as the product vendor like Microsoft may not be willing to generalize / provide this in the next higher versions of the product.

I do understand your point of view and agree. If the publisher is not able to incorporate these unique changes for the customer, then it would completely depend on the implementing partner to provide this unique functionality with low impact programming/customization to the core product. It takes a lot of expereince for a partner to achieve optimum customizations without adding too much to TCO.

Thanks Kartikeya for your comments and insights.
I would like to add one more point here - besides the "experience" of the partner in such matters; it is sometimes "courage" which is more important. By courage i mean - walk up to the client and say - 'hey, this customization will cost you a lot in future; do you really think you need to build this into the application...why don't you do this as a XYZ workaround"...here the first part of sentence is courage and suggeting the workaround is experience.

Post a comment

(If you haven't left a comment here before, you may need to be approved by the site owner before your comment will appear. Until then, it won't appear on the entry. Thanks for waiting.)

Please key in the two words you see in the box to validate your identity as an authentic user and reduce spam.

Subscribe to this blog's feed

Follow us on

Blogger Profiles

Infosys on Twitter