Infosys Microsoft Alliance and Solutions blog

« August 2010 | Main | November 2010 »

October 21, 2010

Application Portfolio Management - Have you chosen the right mode of transportation for your organization journey?

While working on EXIST framework as highlighted in my post (Defining the Application Portfolio using the "EXIST" framework ) and a subsequent post around trying to clear some myth and misconceptions in next post (As you sow, so shall you reap: Effective Application Portfolio with 'Cloud Inclusivity'); i was thinking of highlighting some live examples from public sources which support this model.

Since i found a lot of them, my thoughts actually went in another direction where i tried to answer a simple question - "Why is there so much of competition between on-premise and SaaS models?" .You search the web with keywords 'SaaS' & 'On Premise" and there would be prescriptive solutions and comparisons between the two deployment options and each trying to outdo the other. Is this needed?

I thought of comparing this situation with Transportation Sector.

Starting from pebbled streets to Mach speed commercial liners, we have come a long way. When Steam engine was invented, was it considered an end to road travel? When the huge commercial ocean liners were constructed, did it mean an end to railways? When the airliners came, did we think that railways (railroads) and ocean liners would be extinct? To me answer to all these questions is an overwhelming 'NO'. The reason behind this is simple. Let me explain...

The purpose of all these means of transportation is the 'need' for movement of people and goods from Point A to Point B. It is this greater goal that has kept all these options alive. While sophistication, speed, safety and comfort increased over time as we moved from Horse Carts to Airplanes; the essence is that 'the need' was to move from Point A to Point B. The points kept on getting refined and maybe farther from each other. However, no single means was able to satisfy this complete 'need' of travelling from Point A to Point B.

I will take an example - To move from My Home (Point A) to a destination like my client location (Point B); i need to first take a lift and reach my apartment lobby where i take a taxi to reach the airport from where i take a flight to city where my client is. After that i take a metro/underground to reach the business district and probably take another taxi or a bus to the client's building before entering into the lift to reach the floor where i can shake hands with my client. What this means is that i have used several modes which are not necessarily connected together (while they may have their individual maturity in terms of timings, frequency, tec.). However, my 'need' is completely satisfied by this 'conglomerate' of modes. Please also note that some of the modes are 'private' while some are 'public'.

Drawing a parallel an organization is also looking at business needs and goals and need to move from point A to point B. The 'modes' could be IT enabled and there could be multiple products (along with delivery options); but at end of day they all work in sequence to ensure the 'need' is fulfilled. Hence, none of the 'modes' are competing but are actually complementary. 



The mix of modes can vary from person to person based on his/her needs. For e.g. I myself may prefer an overnight train rather than an early morning flight to reach a destination. Not only do i save the cost; i may reach there more refreshed which may improve my productivity during the day. Similarly, each organization is unique and based on the 'needs'; the 'modes' have to be selected very carefully while striking a balance between cost, flexibility, effort, risk and returns. Also, the modes can be exclusive to the organization (On premise, hosted, private cloud) or can be public (public cloud). Do you see a similarity??

In the EXIST model (please refer to my first post for details); the framework, essentially, breaks the applications into 5 categories based on the "purpose" for which they will be used.. This helps in laying down some standard decision making criteria while choosing on the application types. This does not mean that there are solutions or packages that do not cut across this segmentation.  What this simply says is that recognition of these needs leads to a more informed decision with a solid business case backing the decision making process. Some of the factors that can vary across this classification are sponsorship, business needs, goals, benefits envisaged, duration of use of application, legal & regulatory constraints, Local/Country level regulations, Language needs, extent of change in process, uniqueness of the business need and the impacted line of business & user base. This also decides the mode of delivery of these applications - On Premise, On Cloud, and Hybrid.


In conclusion, i think that there is a need to fundamentally look at these options as complementary and the need of the organization being of utmost important. Everything else will just follow. Let the application and their modes not decide on what the business really needs to create a strategic differentiation in the market for its own good.

This is Part 3 in the series of 3 posts around this topic. You can access previous 2 posts here -
Part 1:
Defining the Application Portfolio using the "EXIST" framework

Part 2: As you sow, so shall you reap: Effective Application Portfolio with 'Cloud Inclusivity' 


Application Portfolio Management is an exciting area and i am sure you too would have your thoughts. Please share the same. I would look forward to listening on this from peers, practitioners and clients whom i am sure would be jostling with few of these questions themselves.


October 15, 2010

Library Functionality for a Service Unit

Building on my previous thought of library functionality this blog explores its usage for a service department in a manufacturing organization.

Consider a scenario - there is a service and maintenance department in a manufacturing organization. The department takes care of all the servicing and maintenance activities of the production machines (work centers).

The primary business objects in the operations of this unit are:

  1. Human resources - these are service engineers with various skills. These are people who are required to do the job
  2. Tools (portable) ranging from low cost spanners, screw drivers to high cost sensors and meters. These are items which are not consumed but are required for the service activity to be completed. Typically the high cost items are limited in number and need to be tracked.
  3. Replaceable items like low cost screws, oil to high cost replacement spares. These are the items which are consumed in the process.
  4. Machine to be serviced - these are the work-centers which need to be serviced. They can have preventive maintenance schedule or can be serviced for breakdowns.
  5. Service orders (or work orders) - these are transactions against which work is completed. This transaction requires culmination of human resources, tools and service items to complete the order.

In Dynamics AX (or even NAV), we have business objects which map to each of these except tools. 

  1. Human resources are mapped to employees or even as work-centers.
  2. Replaceable service items are inventory items which are expensed out.
  3. Machines to be serviced are work-centers or assets.
  4. Service order is available functionality.

Tools are entities, I feel, lack intuitive mapping. Given the characteristics of tools, they can be mapped to resources within the library.

Let's look at features that are needed around the library to make it suitable for usage in the service and maintenance scenario. We will also note what can be standard features of library and what scenario specific features are:

  1. Booking of tools: Functionality to book tools for any specific time slots either on service orders or by employees. This feature of booking library resources by any entities (masters or transactions) could be a standard feature of library.
  2. Check out and check in of tools: Functionality to check-out and check-in tools against service orders or employees. This could be a standard feature of library.
  3. Tools availability view:  Since the same tool will be given out against various service orders, we can track the expected time of availability of the tool. This can help to commit the time and book the tool for service orders and give more predictability on service order SLA adherence. This could be a standard feature of library.
  4. Linking of library items to combination of service order types and machine (tools to work-service order type and center): The setup of linking service orders, work centers and tools can help in automating the allocation of tools for service orders, which can be leveraged in automatic scheduling of orders. This feature is specific to the scenario.
  5. Linking financials related to tools:
    • Rental rates - can be setup at the tool level
    • Usage cost - can be calculated on the service orders considering how much time the tool was used. These can also give expected (before service order execution) and actual costs (after execution of service orders).
    At feature level, linking of financials for costing can be made standard feature.
  6. Reports on usage of tools:
    • Utilization of tools - count and total time
    • Tool usage and availability
    • Service order cost variance of expected and actual values
    • Tool-work center usage - how frequently a tool is required to be used with specific work centers
    First three bullets can be standard reports of library feature, while fourth is a specific feature for the scenario.

Thus, by having an explicit library model, it gives a more intuitive mapping of tools for a service and maintenance department of an organization. This would help a large number of clients in manufacturing, transportation and of such nature where machine maintenance is one of the core activities.

Subscribe to this blog's feed

Follow us on

Blogger Profiles

Infosys on Twitter