Saturday, May 31, 2008

Building Intelligent Systems - Some Thoughts

The customer service representative receives a call from a disgruntled customer about a service that s/he had requested for the order but had passed the committed date. One is bound to hear such stories if you have ever been a customer or a service provider.

As per a research study conducted by TARP research way back in 1999 it was discovered that on an average one unhappy customer will tell ten people about their experience. In turn, these ten people will each tell five more people. Just imagine how fast an experience can flow these days due to internet and rise in the tele-density.

For all practical purposes there are orders that should have completed but did not and therefore needed human intervention to complete. As a result of such instances, the company requires at least two people to look at the order after the unhappy customer calls. Apart from the probability of losing the customer, time is lost in reacting to the call.

Earlier in my career, I was managing a stack of such order fulfilment systems. There, as a matter of habit, I used to look at the percentages of order fall outs for a day and then try and find patterns. Then, this experience was used to proactively address issues and help the orders complete on time. While all this was happening, I had asked my team to make daily logs of the issues that prevented the order from completing.

The number of issues, though different each time showed a trend. So, an automated report was generated every night and the incomplete orders were manually completed by the product support group. Taking it a little further, the application support team wrote scripts to identify such orders and complete them. This significantly reduced the calls to the customer service centres.

All this was done in less than six months along with major enhancements and patches being applied to the system and with other hardware and database issues.

All this pain could have been avoided had the systems been made a little intelligent during the design itself.

Here are some of my suggestions on how it can be achieved:

1. Order life-cycle: Old legacy system tended to be simple, sturdier, self contained and of limited importance to business success. Their modern counterparts are often very complex, interacting with other large stack of heterogeneous systems that are equally business-critical. This indicates that we must understand each finite state in the order processing and provide a ‘check pointing’ mechanism which links the various life cycle stages of the order and enables us to support each of these systems in concert. It is very difficult to orchestrate the order when the application support groups and the business support groups work in silos. Moreover, it becomes all the more challenging in a multi-vendor support scenario.

2. Intelligent and Predictive Interfaces: When an order is being processed or the order fails, each of the interfaces should interact with the other systems in the stack. If the orders are being processed as required then the order processing agent should automatically forecast and reserve computing resources in the cascading systems or in case of a system resource crunch or a wrong resource being allocated should trigger a fix it job, a call out to the support engineer or trouble ticket be raised.

3. Utility function based services: The goal based and the non-goal based states of an order should be used to calculate the probable order completion. This utility function should help the interfaces to decide the resource allocation. If a non-goal based state is observed in any of the sub-systems in the stack then the order should be passed on for a stage 3* monitoring to the exception management system.

4. Exception Management Systems: As mentioned in the 2nd and the 3rd point, when any of the sub-systems in the stack encounters a problem, the intelligent agents and the utility function should identify the order state and the order then should be passed on to the Exception Management System. This is quite similar to the exception block in a code except that the exception management system, based on the inputs, has the ability to intelligently compute and take appropriate action. A very simplified diagram below depicts the behaviour.



5. Learning system: One of the must have features of an intelligent system is that it should be a learning system. This is a little hard to achieve but system can be built with simple learning logic. If many orders fail for a certain reason than the exception management system should understand various actions taken earlier by the support engineers to fix the job and apply the same logic (lessons/learnings) to the failed order.


6. Throttle/Release Control: In most of the order fulfilment systems the SLAs are defined as number of orders completed in a day but the systems are sized based on the average number of orders that will be handled during the peak load. In practice it is very difficult to size the stack, as the owners of each of the sub system in the stack could be different or the subsystem could be in a different life-cycle stage. This could make one of the subsystems prone to failure or in an asynchronous system build a backlog in subject to peak load. In such a case it is very important that the order processing on the other systems are throttled. I have used this mechanism extensively and had developed a formula to compute the control parameters.

I am fully cognizant of the fact that there are practical challenges and there are a lot of other important considerations while designing the system but going forward the designers and the budget owners will have to start thinking of building intelligence in the system and the suggestions given above are some of the things that I feel that can help design intelligent systems.

Due to lack of data, it can be argued that this will increase the design and the development cost but personally I feel that a multipurpose bots can be built and configured for each of the systems. Also, considering the revenue loss, due to disgruntled customers, and the reduction of the number support engineers the TCO of the system or the stack would be greatly reduced.

Thursday, May 22, 2008

Dare To Dream

Think big, if the life’s so small,
And in just that while you’ve got to span it all.
Set grandiose goals for a feeble sight,
But for an age ahead should breed delight.

Dream so big, that the dream once come,
In eons and epochs to few chosen some.
The winner’s path, how tough it may seem,
Fight all impediments and “Dare To Dream”

Mahendra Jape

Sunday, May 18, 2008

Dream Teams: My Experience

According to the classical definition, teamwork is the concept of people working together cooperatively. Projects more often than not require that people work together to achieve a common goal. The spirit of collaboration is therefore necessary to work well in a team environment.

I was reading a report on a national representative survey conducted by Level Playing Field Institute, USA. It revealed that most of the Americans think that 'being a team player' was THE MOST important factor in getting ahead in the workplace. There were several factors like 'merit and performance', 'leadership skills', 'intelligence', 'creativity ' and 'long hours' that were considered.

I have always been fascinated by the Game Theory. According to this theory each participating member is treated as a player and the assumption that each of the players in a given set will try and maximize his or her payoff. There is a branch of the game theory, namely the cooperative games, where the teams work together in coalition and compete against the other teams or coalitions. So, when a team is formed, it is imperative that the team shares a common goal and the entire team works together without any unilateral incentive for the players to deviate. My experience has been practically similar and also it’s the captain's or the project manager’s job to keep the team focused and on track.

Interestingly, most of the teams that I have worked with were remarkable. The experience with each of the team was different as well and the happiness of achieving the targets and the journey towards the goal was also varied. I have tried to list some of the common values and skills that I observed in the successful projects.

Respect: it is important to treat each other in the team with respect. I have observed that sometimes based on the background of the individual players / team members there is a tendency to form a sub team within a team. This tendency should be discouraged. This is the most important value that should be observed by the team. Never ever back bite or crib. It never helps.

Be assertive: It is very important to interact with people, who are sometimes quite authoritative, while standing up for you feel is right. Being assertive benefits the individual and the team most of the times but it does not mean that one always gets what he/she wants.

Share: it is important to share knowledge, tools and techniques with the team to create an environment of teamwork. Often, many companies create peer competition which forces the team members to share but I strongly recommend that the spirit of comradeship should be created such that teams do not need extrinsic motivation to do basic bonding.

Listen: it is important to listen to other people. Team members should be allowed to freely express their ideas, these initial ideas and trust me this will do wonders. My ex-teammates still call me up and discuss some brilliant ideas that they recently had. I guess every team member needs a mind but the team just gives them an ear. So, when you are a part of the team, listen to team members with your heart and soul. In my teams I would more often encourage individuals to exchange, defend, and then to ultimately rethink their ideas.

Help: It is crucial to help one's coworkers both professionally and personally. Do this only when asked for. Be very careful that you do not encroach on their personal space, seek permission where ever necessary and know your professional boundaries well when you extend help.

Communicate: For a team to work effectively it is essential team members acquire communication skills and use effective communication channels between one another e.g. using email, viral communication, group meetings and so on. This will enable team members of the group to work together and achieve the team's purpose and goals.

Relationship: Always aim that the team grows with the sense of developing long term professional relations. This helps the team members to quickly shrug off their short term unilateral incentives.

As teams grow larger, project managers or captains must use these values and skills to create or maintain a spirit of teamwork. These are some of the skills that are must have for a dream team.

© Mahendra Jape 2008