Tavant Support: Evolution & Growth Of Warranty System
While application support in the global software services industry is often treated as status quo maintenance, at Tavant, we see this as an opportunity to showcase continued improvement and excellence. We consider application support as no different from an innovation lab where new ideas are generated and implemented. In this blog, we will discuss Tavant Warranty Management System (TWMS) during its support phase and analyze its growth and evolution over the years. On November 21, 2005 TWMS went live and in 9 years of Tavant Support, the system has seen tremendous growth. Milestones in TWMS’s evolution (2006 to 2014): The Warranty system auto processed a hundred times more claims than it did in the year 2006 The Recovery module registered seven time’s growth The system processed 235 percent more claims, i.e. over 29 percent average annual growth Recovery claims were generated for 7 percent of the warranty claims in 2007 versus 21 percent today The TWMS has so far processed 1.7 million claims, i.e. net worth US$791 million In Tavant, we have always believed in holistic growth, and this is evident in our application development and support processes. TWMS and its accompanying accomplishments were possible because care was taken to ensure that innovation happened in every module to offer efficiency, automation and better performance. Processes that enable these accomplishments: Processes that enable these accomplishments: TWMS helps businesses to process claims faster and with minimal effort, by ramping up to automatically process claims Auto-processing is achieved through complex business rules using a powerful business rules engine It simplifies the process through which a dealer or user can file claims. TWMS helps to save claim filing and processing time by auto-populating known fields with the help of an intelligent processing engine It has effective recovery generation options and auto recovery initiation engines It offers multiple admin configuration setups to tweak the system flow as per business needs Tavant Warranty Management System is only an example of how Tavant Support evolves an application and helps businesses to grow. We believe excellence is not something to be achieved, but to be continuously pursued.
How to Overcome Challenges with Mobile App-Server Communication Process
Mobile applications (apps) have changed the way consumers act, interact, purchase, sell and search. According to a five-year report on the mobile Industry by Flurry*, “Apps have commanded 86% of the average US mobile consumer’s time, or 2 hours and 19 minutes per day in 2014.” One reason for this popularity is the instant gratification that consumers derive from mobile apps. However, mobile app performance is determined by networks & servers, putting much pressure on app developers. Is there a method to circumvent server and network performance issues? I suggest that, app developers, to mitigate server performance issues, should ensure that the communication process remains asynchronous, during the following three stages: The facilitation within the application to communicate The communication itself, and, The post- processing of the result. We normally assume that server communication code resides inside the Server Communicator (block) and cannot be reused for other server communication. However, that need not be the case. For example, one of the components of the server communication process is the Action Class. Action Class, is an independent component which knows the vital points about a particular network action. It knows the process to create a request, parameters to be used, headers to be created, etc. It assimilates responses and post process, extracts information to be consumed by the application. It brings up custom error responses and shows the method to handle the same. The `Action’ does not send out a request to the server but acts as a bridge between the two. Any new communication to the server will result in a new action class, keeping the existing ones untouched and unaffected. Thus, every step in the server communication process can be treated independently. It is possible to fit new server engines to support new servers, without disturbing the ecosystem, and it is possible to run parallel server communication processes without any of them affecting the application’s performance. To summarize, by following this method, it should be possible to ensure that every communication block is independent and yet works in tandem. To know more, read the whitepaper “Ensuring Effective Server Communication in Mobile Applications” by Deepak Mariyappa and Ravi Peravali.
Understanding the Relationship between Warranties and Customer Satisfaction
Original Equipment Manufacturers (OEMs), equipped with the latest and best product knowledge, help in enhancing customer value and product quality. Aberdeen Group, a well-recognized business-intelligence research organization, presented a study recently. It said one of the top priorities for organizations is to improve customer satisfaction, after which comes the objective of managing costs, improving product quality and increasing revenue. But how can manufacturers be equipped with the knowledge to meet these objectives? A warranty management approach can be the solution for these OEMs. If a warranty or service contract solution can generate a product record history, it becomes easy to track the product history throughout its service life-cycle. With this information, manufacturers can gain valuable insight into the product life-cycle, which in turn provides insight for service improvements. That is why manufacturers, nowadays, are looking at warranty solutions with a strategic perspective. To achieve these objectives, manufacturers need to upgrade their existing and isolated legacy systems to integrated warranty systems, which can use advanced analytics services to churn warranty data into meaningful information. Such information helps the OEM to improve its service offerings to the customers. With real-time analytics in place, manufacturers can gain substantial productivity, increase operational efficiency, and retain customer value. The Challenge A large automobile manufacturer was facing challenges with its equipment warranty services and parts logistics system. The customers were not satisfied with the quality of equipment and hence, there were frequent customer complaints. Additionally, the response time to service requests was high compared to competitors. The organization was unable to achieve the Key Performance Indicators (KPI) for equipment warranty and service parts. The biggest blow was that both, internal and external customers were complaining about the process lapse. Some of them were turning to competitors. The Solution With immediate effect, the OEM incorporated a warranty system for the client. Streamlining of processes and communication channels ensured that the equipment warranty KPIs were met. Furthermore, the analytics system traced products throughout their life-cycles and provided key insights to assess supplier performance throughout the supply chain. Moreover, it helped the OEM capture the service time taken by each of the servicing dealers, thereby keeping a check on the service turnaround time. It generated an effective internal process and helped immensely in managing and engaging internal and external customers. The Benefits Customer management & engagement Comprehensive reporting & analytics Reduced costs & customer complaints Process enhancement Proactive response to customers Development of contingency plans Improved efficiency of onsite service requirements Lesser turnaround time Increased brand credibility
Warranty Management – A Strategic Business Advantage
While warranty solutions began as a way to attract customers, their scope and application have seen radical changes over the years and organizations now realize that warranty management is a source of competitive business advantage. It offers a multitude of benefits like faster claims processing, decreased fraudulent claims, better operations management, and increased bottom-line results leading to improved satisfaction of customers and service providers. However, many fail to understand that effective functioning of warranty is hampered by a silos-based approach. Most organizations adapt the silos approach for warranty without giving it the focus it deserves. The fragmented approach to warranty leads to dissatisfied service providers and customers, greater turnaround time, high operating costs (which otherwise could have been avoided). A detailed analysis of the holistic approach can easily reveal the strategic impact it bears on each of the value chain functions, such as manufacturing, quality, sales, service, and finance. When the warranty-management process is integrated with all the key business functions, it can turn around the revenue chart of the business and multiply profitability. A holistic approach to warranty has various benefits: Improved customer satisfaction – Integrated information ensures greater connectivity, timely information and history recall for customers during product lapses. It, therefore, helps to increase commitment and boosts brand perception and organizational credibility. Faster claims processing – A closed-loop approach helps in streamlining the claims process and reduces operational discrepancies. It assists in tracking warranties across the product lifecycle and helps in optimizing product pricing while minimizing warranty costs. Decreased fraudulent claims – Processes and policies can be integrated into business logic. Streamlined processes lead to better visibility of warranty information. Integration minimizes warranty costs while enhancing the early error-detection process, thus widening the scope of improving product quality, well in time. Decreased operational cost & increased bottom line – An integrated warranty package minimizes process errors that rob organizations of strategic business focus. Product lapse trends can be closely examined for proactive measures to ensure quality and process control. An efficient warranty management solution fosters collaborative solutions, enhances product quality and customer satisfaction, addresses quality concerns, and improves partner relationships, thereby increasing operational efficiency and bottom-line results. The Client A global organization that specializes in providing diversified services to domains like home comfort, transportation & preservation of food & perishables, and securing homes & commercial properties. The Challenge The organization comprised multiple business units, each of which had diverse business requirements and ran on multiple legacy systems. Due to the market’s demand, the organization accepted additional responsibilities of spreading its services to Europe, North America, Asia, and Lagos. It faced a series of challenges in keeping up with requirements, as it lacked an inventory management system, coupled with ad-hoc retrieval systems, resulting in lack of transparency. All this led to inefficient realization of ROI. The organization was in need of a robust and comprehensive central solution to standardize the warranty management process. The Solution Massive data from all the business centers was integrated into a centralized platform. The analytics solution ensured timely projections across the value chain functions and helped in faster claims processing. It reflected early warnings of failures and identification of root causes to minimize product failures that were impacting the entire product lifecycle. The closed-loop solution transformed performance data into strategic intelligence, directly enhancing operational efficiency, decision making, customer satisfaction, reporting, and communication capabilities to identify and detect issues early. It also minimized warranty costs and enhanced business profitability. The Benefits Increased customer satisfaction & retention Better communication and collaboration Reduced warranty costs & claims processing errors Lesser turnaround time for settlement of warranty claims Greater process and operational efficiency Therefore it is crucial for organizations to ward off the one-dimensional perspective and move towards a holistic approach to warranty solutions. The integrated approach leads to a 360-degree perspective of information, efficient claims processing, better analytics, and reduced manual intervention. It also helps in achieving optimal business results and accelerated warranty management. It enables organizations to run their business functions with strategic alignment and purpose that can streamline their processes, enhance customer satisfaction, brand perception, and maximize scalability.
Understanding Concurrency in Mule 3 ESB
Enterprise service Bus (ESB) is an approach for application integration in distributed and heterogeneous environments. One of the requirements for ESB is a highly concurrent system. Mule ESB is a lightweight Java-based Enterprise Service Bus (ESB) and Integration Platform that allows developers to connect applications and enables data exchange. Mule provides three layers of highly configurable concurrency called `thread pools.’ Receiver Thread Pool – which originally receives the message, and either -Synchronously processes the entire flow, or -Asynchronously ends it by writing a message to a queue. 2. Flow Thread Pool – which asynchronously processes the bulk of the flow. 3. Dispatcher Thread Pool – which sends messages asynchronously to one-way endpoints. Synchronous vs. Asynchronous processing in Mule: For synchronous processing, the same thread will be used to carry the message through Mule. If the message needs to be sent to an outbound endpoint, the following will apply: If the outbound endpoint is one-way, the message is sent using the same thread. Once sent, the thread resumes processing the same message. It does not wait for the message to be received by the remote endpoint. If the outbound endpoint is request-response, the flow thread sends a message to the outbound endpoint and waits for a response. When the response arrives, the flow threads resumes by processing the response. For asynchronous processing, the receiver thread is used only to place the message on a SEDA queue. At this point, the message is transferred to a flow thread. The receiver thread is then released into the receiver thread pool so it can carry another message. When a message is processed, if it needs to be sent to an outbound endpoint, one of the following applies: If the outbound endpoint is one-way, the message is copied, and the copy processed by a dispatcher thread while the flow thread continues processing the original message in parallel. If the outbound endpoint is request-response, the flow thread sends a message to the outbound endpoint and waits for a response. When the response arrives, the flow threads resumes by processing the response. Conceptually, messages are processed by flows in three stages: The message being received by the inbound connector The message being processed The message being sent via an outbound connector. Even if the connector is not provided for inbound or outbound, Mule creates a default connector with default configurations for each endpoint. Example: There needs to be a sftp end point (inbound) and two levels of configured concurrency – the Receiver Thread pool and the Flow Thread pool. The Dispatcher Thread pool can be configured in the same way and will give the same performance. sftp:inbound-endpoint exchange-pattern=”request-response” and receiver-threading-profile doThreading=”false” – Multiple receiver threads get created and performance is very slow due to synchronous nature of flow (request-response exchange pattern) sftp:inbound-endpoint exchange-pattern=”one-way” and receiver-threading-profile doThreading=”false” – Multiple receiver threads get created, and performance is better than Case 1 but due to multithreading, a race condition could occur causing multiple threads to start consuming the same file. This is especially true when file size is large sftp:inbound-endpoint exchange-pattern=”one-way” and receiver-threading-profile doThreading=”true” maxThreadsActive=”1″ maxThreadsIdle=”1″ poolExhaustedAction=”DISCARD” – Only one thread gets created and performance is the same as in Case 2. However, there is no way to set the threadWaitTimeout in this case and hence once the thread times out after the default value, the system will stop consuming more messages (files in this case) sftp: inbound-endpoint exchange-pattern=”one-way” and receiver-threading-profile doThreading=”true” maxThreadsActive=”1″ maxThreadsIdle=”1″ poolExhaustedAction=”WAIT” maxBufferSize=”1″ threadWaitTimeout=”-1″ – Only one thread is created and performance is the same as in Cases 2 and 3. We have set the threadWaitTimeout to indefinite as there is only one active thread, and it will keep on pooling forever. Catch: The catch is that configuring the receiver-threading-profile doThreading=”false” has no impact whatsoever in the overall processing. Internally there will be multiple (default) receiver threads that will be created. So don’t rely on doThreading=”false” alone to stop multithreading. Instead do the same configurations as mentioned in Point 4 above. The same is applicable to dispatcher-threading-profile. Reference: http://www.mulesoft.org/documentation/display/current/Tuning+Performance
When to Use Enterprise Service Bus (ESB)
Point-to-point communication normally has issues with scalability. These issues are further compounded with increased systems. ESB, a middleware technology, is a Bus-like architecture used to integrate heterogeneous systems. In ESB, each application is independent and yet able to communicate with other systems. It, thus, prevents scalability issues and ensures that communication happens only through it. ESB’s guiding principles are: Orchestration – integrates two or more applications and services to synchronize data and process. Transformation – transforms data from canonical to application-specific format. Transportation – protocol negotiation between multiple formats like HTTP, JDBC, JMS, and FTP, etc. Mediation – multiple interfaces for supporting multiple versions of a service. Non-functional consistency – transaction management and security. When to use ESB architecture The first step when opting for ESB architecture is to map its value to requirements. Given below are some usage guidelines: When system integration points grow beyond two, with additional integration requirements. When using multiple protocols such as FTP, HTTP, Web Service, and JMS etc. When there is a requirement for message routing based on message content and similar parameters. ESB architecture Implementation Rules Messaging services like JMS can be used to de-couple applications XML format when canonical data is used for communication Using an adapter that is responsible for marshaling and un-marshalling data. The adapter is also responsible for communicating with the application and bus. It is then used to transform data from application format to bus format Non-functional activities like securities, transaction management are also performed by the adapter in ESB. To summarise, ESB provides for a flexible architecture. It enables multiple application communication and provides easy integration with other systems.
How to Manage Warranty Costs
Minimizing warranty costs has always been one of the most pressing concerns for organizations. While minimizing the warranty spend helps, it is also important to make an objective estimation of the costs involved. Due to the lack of information about every single step involved in the business process and the associated costs, a principle barrier becomes evident in charting the right budget. Cost mismanagement in warranty can rise from ad-hoc estimation techniques and planning for warranty reserves. The elements impacting warranty costs go beyond product repair and overflow into other areas. To estimate such hidden costs accurately, without some kind of integrated business logic, is extremely complex. The need of the hour is quantifiable strategies and techniques that can optimize the effectiveness of the warranty process. Time and again, warranty analytics have proved to show remarkable results by integrating data that helps to improve product and process performance. That helps not just in managing costs, but optimizing overall business profitability as well. Integrated technology can reflect warranty costs and assist in better operational and strategic business execution. That aids in formulating streamlined warranty management processes, building brand images, reducing operational costs, improving product quality and optimizing organizational efficiency. Business Case The Client One of the world’s fastest-growing automakers. The Challenge The existing warranty management system lacked a comprehensive analytics system that could integrate data across business functions. The organization faced a substantial revenue loss, maximizing ROI was a challenge, and organizational credibility was at stake. The team handled issues on the basis of client demands while using traditional legacy systems. The Solution With an intention to mitigate warranty costs, the organization integrated warranty data across all the business units into a single process with common business rules. The analytics solution helped reduce costs drastically and provided the organization with quantifiable data that highlighted areas profitable to the business, and the pain points that required immediate process upgrading. The outcome of the analytics system was a whopping cost reduction of close to 40% across all regions. Additional benefits included: Customer satisfaction Greater process transparency Scalable solutions Standardization of systems Quantification of results
Three Step Process to Automate Software Testing
Large software organizations have long been patronizing software testing. However, small and medium (SMBs) sized companies find manual testing time consuming and expensive. For such companies, automation can prove to be the right alternative. Given below is a three step process to automate your software testing requirements: STEP ONE Any software which requires functional tests, if supported by automation testing, must follow a Q&A process. To explain, if a user has ten acceptance test cases, assuming all these can be automated, the following questions need to be answered: Are these test cases within the scope of future releases? Are they a part of the regression suite? Will this particular functionality be used in a majority of flows? Are these tests of high complexity? Are they critical? Thumb rule is to not automate all scenarios, fields on pages etc. unless specified by the client. STEP TWO Understand the application architecture Synchronization process between third party vendors (if applicable) Database design UI design frameworks (e.g. JQuery, Knockout, Wicket, Vaadin, HTML5, etc.) Before finalizing the automation process, these factors also need to be considered: Customer expectations Costs involved (Closed loop or Open Loop) What is the type of application (AUT)? Application’s complexity System configuration support (OS, browser, 32/64-Bit etc.) Ease-of-use for maintenance Forecast on break-event point (ROI) STEP THREE Finally, the framework should have the following parameters: It should provide feasibility to users as per project requirements and also enable all (including non-technical personnel) to participate by writing and maintaining test scripts. The test design approach (E2E, Module wise etc.) The integration process with third party tools (need based) The framework’s flexibility in script enhancements. Automation ensures that testing can be undertaken by any company at any time. While automation has its advantages, it is not 100 percent foolproof and manual intervention is recommended at least at the final stages of product release.
Curious Case of Bombay Stock Exchange
BSE (Bombay Stock Exchange), India’s second largest exchange suffered a technical snag. Trading at BSE was suspended for 3 hours and 3 minutes. This comes as a major to blow to BSE, who is trying to regain its lost market share from NSE. Will the recent developments put BSE a distant second to NSE? Although trading halts at exchanges are not totally unheard of in the industry; In November 2009 LSE (London Stock Exchange) suffered a technical snag, which affected trading for more than 3 hours and in August 2013 NASDAQ was shut down for 3 hours due to a connectivity issue. But the case of BSE is baffling since this is the 4th such instance in the last 4 months! The recent one being the biggest of them all. Since the introduction of derivatives in the Indian market, BSE has been steady losing out its market share to NSE and lot of derivatives traders prefer NSE. However, many traders who trade in equity continue using BSE. However, such frequent snags will offer them a reason to shift. Yesterday for most traders especially day traders, NSE came to their rescue. The proof seems to be in the pudding for the brokerage industry too. Many brokerages that have launched their new trading systems this year seem to prefer NSE, which can be seen in the order entry panels. NSE appears ahead of BSE or in some systems, the order entry opens with the default option as NSE. As mentioned earlier, in the trading world, technical snags at exchanges may not be a new issue for traders and brokerages. They will accept the snags and move on. But the frequency of such occurrence bothers everyone. BSE need not tread a new path to avoid such issues in the future, rather it can pull a leaf out of LSE’s or NASDAQ’s or even NSE’s book, who seem to have averted such repeat occurrences successfully.
CUITe Might be the Next Step Forward in Functional Automation
Coded UI is a highly powerful module in Visual Studio which simplifies coding in terms of UI and Functional Testing. However, Coded UI, in spite of its advantages has one major flaw – it typically generates a code which is based on recordings of manual tasks performed in the UI! The recordings are done as per the pixels of the system and therefore difficult to decipher. A solution to this is Coded UI Test Enhanced (CUITe) framework. This framework involves an open source Microsoft Tool called CUITe, which instead of recording the actions performed on a given UI, records the UI elements by Object ID. How CUITE works CUITe focuses on the PageObject Model of Automation which involves having an in-house repository for all the objects recorded from the HTML page, as below: Advantages of CODED UI framework: Easier code maintenance. Zero need to change code to match UI changes (only the elements changed in UI need to be re-recorded). Auto generates code with namespaces, avoiding confusion regarding which namespaces are to be included. Code can be run on any system. (Please Note: As record and playback functions involve recording by pixel values, UI elements may not be rendered at the same pixel location on all the systems) Keyword and data driven testing becomes simpler as a result of automation and users can write their own custom code instead of customizing a system generated code. With CODED UI’s growing popularity among the development community, it is likely that CUITe might be the next step forward in Functional Automation.