Application Services: September 2013

« July 2013 | Main | October 2013 »

September 30, 2013

Business Agility - Do you have it in you?

Keeping in mind the current economic situation, global enterprises more than at any point in history need to innovate & drive operational excellence bearing in mind effective time to market constraints.

The past few years have seen a large number of enterprises embrace 'agile' practices to become more responsive to business needs. Most organizations want to adopt enterprise IT agility for quicker time-to-market owing to frequent releases and shorter feedback cycles, thus resulting in realizing early business value.

As a matter of fact, even after adopting agile in few projects, enterprises are

Unable to realize / validate the business case quickly
Still not responsive to market changes and customer demands - release cadence has not improved
Still figuring out ways to better utilize the capacity for building new features - More than 70% of the IT capacity is utilized for support, maintenance and defect fixing
Unable to realize business benefits of productivity and quality gains at the team / project level

Why is this phenomenon prevalent? Why are agile projects unable to deliver the intended benefit at organization level?

In any medium to large enterprises, the software product lines are complex, there are multiple dependent parts, which need to come together to make an effective software release. Thus, Enterprise Agile is not multiple project executions by multiple agile teams in an organization. Adopting Enterprise Agile is challenging with unchanged Organization structure and processes.

Most of the organizations are unable to scale agile from team ->program-> enterprise level due to lack of right business alignment among Portfolio, program and projects to work for a common goal. Each agile team creates a silo organization, and absence of one single organization wide agile process and standards, make the going difficult. Lack of on ground agile engineering solutions like Continuous delivery, code quality, ALM, Automated testing etc... creates further obstacles for collaboration.

To bring Business Agility, Enterprises need to break existing silos and implement a strategic roadmap that pervades agile principles into all enterprise functions - business, information technology and support. Bringing Agility and alignment to Portfolio and Programs and Projects using a proper framework, agile systems and process, agile tools and technologies, and an effective change management process is the need of the hour. Change management is probably the most crucial aspect as it steers the impact of agile on various groups and functions and allows organizations to design new processes and adopt better methodologies to evolve true enterprise business agility.

Posted by Prasad Prabhakaran at 6:01 AM | Permalink | Comments (1)

Joe makes IT a true business enabler!

Posted by Vijay Sairam Pratap, Marketing Head, Business IT Services, Infosys

Thanks to Infosys Virtual command center, it's indeed great to have Joe back. It's like having the entire IT support team at one place, if not physically, at least by virtual presence. I can have Joe present with me live to resolve my IT queries rather than dropping him an email or calling him and waiting for ages for him to respond. With Joe, turnaround times are definitely something of the past as my issues are resolved instantaneously and in real-time - the way I always liked it. With all these advantages, it is really no surprise to me that all my colleagues now are eager to have their very own Joe.

Thank you Infosys for leveraging the constructs of virtual physical collaboration and by bringing Joe back, you have provided me the luxury of

Same room experience - Connecting stakeholders through intelligent mediums such as virtual tele-presence, document sharing and video conferencing.
Dynamic service desk - Desktop sharing and remote control to ensure faster and efficient ticket resolution, multi-lingual chat and translations to enable a truly localized and uniform support irrespective of how distributed operations are.
Instant contextual knowledge and knowledge transition - Online knowledge transition rooms, organized online KT sessions, learning dashboards help Joe (the service engineer) and moderator resolve the queries without having to look elsewhere for similar cases and resolutions.

These features of the Infosys Virtual Command Center bring people, processes and transactions (not just online transactions) together, across global locations, making it a remarkably satisfying and efficient experience for stakeholders like us.

So, with Joe around IT is definitely a business enabler for me!

Posted by Guest Blogger at 5:55 AM | Permalink | Comments (0)

September 27, 2013

Joe is back!

Posted by Vijay Sairam Pratap, Marketing Head, Business IT Services, Infosys

Who is Joe? Joe was our IT guy, our veritable Mr. Know-it-all. He was Mr. Dependable and more importantly, was always there when you needed him. My problem was his problem, not just some random request that he tagged into his time sheet. Also, no matter where one sat, Joe was just a shout away. He represented IT hygiene; the kind that I couldn't live without.

A few years later, globalization happened. The great divide was called out between Strategic and Non-Strategic; as a result Joe was transformed into what they called a 'Centralized Support Center'. We essentially lost our Joe. In his new avatar, things were never the same. Granted that this was in-line with the corporate goals read cost optimization, but for me, having IT issues now was no less than it being a 'Friday the 13th'. Joe could now only be accessed by phone or mail. Forget about shouting for him in desperation. Interacting with him live was out of the question; seeing him but a desire. He became to us a helpline number, with the voice and name that changed each time you called in. Whatever happened to stakeholder satisfaction? I want Joe back now!

After years of research, penance and soul searching, Infosys has brought back our good old Joe! The only difference being, he now sits on your desktop, not a couple of desks away.

Feel free to meet and interact with Joe at Infosys' Virtual Command Center here

Posted by Guest Blogger at 5:47 AM | Permalink | Comments (0)

September 26, 2013

Website Upgradation: Creating a compelling multi-channel experience for your customer

22 10 Revised option - compelling mulitchannel compressed.jpg

With the boom in smartphones, tablets and an ever increasing choice of devices to access information and content, consumers expect that the websites they visit, would by default be enabled on the Android, Blackberry or iOS device they are using. In the event of pages getting truncated or the experience not seamless, the disgruntled customer is born.

So, if you have an existing website and are now looking at enabling the content for mobile/tablet devices, you have the following options with you:

Upgrading your existing website to a Responsive Website or ,
Create a separate Mobile website for access from small screen devices
There is even the Mobile application answer but that is not exactly a solution to your website browsing experience. Besides, apps suffer from other problems - the problem of discovery from App stores, the need for pushing updates that need to be manually applied by your consumers, security issues, etc...which is why they are not a popular solution

A Responsive Website is a website that is developed in such a manner that it fluidly detects and adapts to the screen width of the device being used. Using a single code base, it offers a Responsive and optimal viewing experience on any device. However, since this code base needs to cater to the experience on different devices, this will involve a re-think on the existing design to arrive at a unified approach. Development and testing will need to consider the complexity of cross browser and cross device compatibility. A Mobile website is a new website that is created specifically for use on mobile devices, such as 'm.facebook.com' for Facebook.

From a maintainability and support perspective, as well as to ensure better visibility in search engines, the ideal solution would be to build a single Responsive website for your business. The initial investment in development is well worth the returns in terms of increased conversion rates and brand loyalty.

However, from our experience, we see that some of our clients face challenges in upgrading their existing website to a Responsive design because of time or budget constraints. If you have similar constraints, following are some alternative approaches you can consider for enabling a multi-channel experience:

If time is a critical factor and you are looking at a quick GTM (go to market) solution, consider a temporary solution of creating a simple new Mobile website with the most important 50-100 odd links while developing the strategy for your Responsive Website. This ensures that you have catered for the mobile traffic to your website for business continuity. This approach is more relevant for a B2C or e-commerce scenario where giving your business the multi-channel edge fast is of essence. When designing your Responsive website, start with a Mobile-First approach to avoid complex, cluttered screens and ensure that content is planned for mobile/tablet usage. For static content on your website, Responsive design works well; for parts that are interaction heavy such as the shopping cart/checkout workflows in the case of e-commerce websites, content templates can be created for specific & predetermined device platforms.
In case of serious budget limitations, you can approach the solution to this problem by extending your existing website incrementally and in small steps for a multi-device experience using the Adaptive approach but this involves extensive conditional coding & scripting on the same code base (for predetermined devices) and in my opinion, may not be the best solution from a long term, maintainability perspective.

There are several examples of companies who have gone for Responsive websites and gained from the 'wow' impact - get inspired and join the club!

Posted by Deepti Seshadri at 5:06 AM | Permalink | Comments (0)

September 16, 2013

Striking the Balance: Waterfall and Agile - Part I

Today, companies have a plethora of choices such as SCRUM, Extreme Programming (XP), Behavior Driven Development (BDD), Feature Driven Development (FDD), Lean and Kanban software development methods under the umbrella of agile along with exiting waterfall method for project implementation. Companies can select the best combination of suitable methodologies to maximize business value for the customer.

In this blog series, we will discuss various methodology selection aspects across dimensions such as business/ application, location and teams, tools and also explore best-practices in both methodologies to balance agility with discipline and control.

This blog will talk about the methodology selection pointers around business and application related dimension.

It is important that, methodology goals are aligned with project goals. Projects are more suitable for agile development when the primary project goals are rapid value delivery and responsiveness to change. Waterfall will the right approach for projects that demand higher predictability, stability & assurance.

Agile adoption is more suited to projects that cover significant enhancements, entirely new development or initial prototyping of a new concept especially in dynamically environments where the requirements are emergent. Waterfall is useful in projects where:

There is a need to integrate several independently evolved applications
Improperly modularized existing systems that need to be replaced incrementally
Stakeholders desire to have rigorous manual and exploratory testing

Agile initially started with small to medium teams of people working on relatively small applications due to tight coordination and shared tacit knowledge constraints. However, recently, many large scale programs have documented successful delivery of agile transformation by use of scaling options available like Disciplined Agile Delivery (DAD), Scrum of Scrums (SOS's), Lean Kanban, Scaled Agile Framework and SAFe.

For very large projects where plans, documentation and processes enable better communication and coordination; when the requirements can be determined in advance and remain relatively stable across large and dispersed groups; waterfall approach can be effective.

Agile can be used in projects with greater dependencies with mitigation through following certain practices but with reduced benefits that agile has to offer. Waterfall manages multiple dependencies and constraints as well as systems complexity through upfront detailed planning and coordination.

A successful project needs to fulfill the following prerequisites of customer relationship, i.e., Collaborative, Representative, Authorized, Committed, and Knowledgeable (CRACK) business partners and representatives. Agile approach is well suited to projects where 'crack' performers such as product managers and product owners are identified and dedicated to the project. This allows scope for immediate response and clear decision making, enhancing communication between the entire team, thus reducing risk and uncertainty. In waterfall, some form of contract between the developers and customers is required as the basis for customer relations. They handle foreseeable problems by determining it in advance and formalize solutions in a documented agreement.

In Agile, undocumented, unclear or poorly defined requirements present very little difficulty and align well with an agile methodology that proposes 'just enough' documentation whereas in waterfall requirements have to be documented in detail such that the designers can accurately and proactively predict flaws. Also, sufficient number of resources has to be allocated for elaborate documentation to keep up with the goals of predictability, stability and assurance through standardization and process capability.

Agile and waterfall are not exclusive, but there has been considerable polarization associated with both approaches and much of these differences are rooted more in perception and misconceptions rather than in reality. In many cases, the manner in which companies apply their judgment and skills in using the methodology has a higher impact than the methodology itself.

In the next post, I will discuss about how Location and Team dimension impacts methodology selection considerations for waterfall and agile.

References:

Balancing Agility and Discipline: A Guide for the Perplexed By Barry Boehm, Richard Turner
Agile Project Management with Scrum Ken Schwaber Microsoft Press, 2003

Posted by Amol Patki at 11:54 AM | Permalink | Comments (5)

Distributed Agile vs collocated agile - Is it important to be in the same room?

8 11 Blog collocated agile vs distributed agile 1.jpg

Successful teams are built on trust. From a very long time, the success of IT projects has been dependent on the success of the teams that are running the projects, especially those teams, where the output of the team is greater than the sum of individual parts. In creating that greater sum, it is trust that is most important.

Let's take a look at the four supporting principles of Agile. Agile is more about Individuals and how they interact, rather than processes and tools. At the same time, it's more about getting the software to work, rather than creating broad documentation. It believes in involving the customer, rather than contract mediation, and it also believes in reacting to a change instead of following a set plan.

Collocated agile, has its advantages, when it comes to achieving these goals. Being in the same location, helps in interaction and getting together for the same strategy, but in this age of globalization, where teams are based out of different geographies, the scales would probably tilt in the favor of distributed agile.

Distributed agile can achieve the same outcome of collocated agile, if the right principles are in place. Firstly, it's important to build trust. Secondly, there has to be a project vision that is shared by all the team members. Thirdly and most importantly, the whole team has to be a part of planning, iteration and review.

For these to happen, there has to be a strong communication infrastructure, to improve the trust factor. Video conferencing are a must for distributed agile to achieve the same success that collocated agile would achieve. To create a shared vision for the project, distributed teams should come together, during different stages like release planning, sprint planning and daily scrum.

In addition, if the projects that are being dealt with are big, then for distributed agile, it makes sense to have short iterations so that feedback can be provided on a timely basis. Also, it would make distributed teams to come together for the initial duration of the project. This time spent together can be used for having discussions and for setting up the frame work, architecture and design, so that the rest of the work can be done smoothly, even if the teams are working out of different locations.

Most important of all, the whole team should participate in sprint planning, sprint reviews. This will ensure that all the people in the team are on the same page. This would also ensure that people have a sense of ownership of the project they are a part of.

Though, easier said than done, if these can be ensured, then distributed agile will be as effective as collocated agile.

Posted by Anil Radhakrishnan at 9:11 AM | Permalink | Comments (0)

September 12, 2013

Funding Tomorrow's Applications

In my previous blog, I argued for expanding the scope of 'modernization' to include new technology capabilities like Mobility, better UX and Cloud. These actions are necessary to keep the portfolio up to date and relevant to the changing business environment. While the 'rip and replace' option is always available, a more prudent financial option would be to make changes to existing applications and thus leverage the investments made so far.

But a fundamental question that dogs every IT organization is where to find the money to fund the projects for building new capabilities. In my experience there are broadly three ways to finance such modernization initiatives:

Business Funding - This is the primary source of funding for most application modernization programs, where there is a clear business case for bringing in new capabilities. New business realities will demand new capabilities that will receive appropriate funding. For example businesses like restaurants and event rating/booking, travel reservations, that are facing a customer base that is increasingly moving their spend to mobile handsets will be forced to find the money to extend their websites to mobile platforms.
IT discretionary spend - IT departments typically have a set amount of discretionary funding available to them to spend on different improvement activities. In boom years, this budget can be substantial and can support multiple modernization tracks. However, in recent years most organizations have found this budget to be shrinking year on year and is currently only sufficient to keep the critical projects going. Projects that are removed/replaced out of support application layers, shutdown applications with newer alternatives etc. will continue to be funded via. this route, as these are almost mandatory expenses for IT
Self-Funding - This is perhaps the most innovative yet difficult to achieve model. The investment for new technology interventions is sourced from reducing the spend on portfolio. The savings can be achieved by rationalizing the applications and technologies in the portfolio. Savings can also be brought in by moving to a managed service model for supporting the applications. For a self-funding model to work, the savings must be retained within the IT budget. The challenge with this model is finding the initial dollars to carry out the rationalization. This model needs a flawless business case and a detailed plan to manage the changes that will affect the program during its life-cycle

While market forces will provide the biggest impetus for building Tomorrow's Applications, it is important that IT leaders consider the various other ways to fund the needed improvements. Infosys has a strong framework in Value Realization Method (VRM) to create a compelling business case. Our IMPACT framework provides a full framework to manage the program. These help us create the right sources of funding for the programs to sustain themselves over many years.

Posted by Vageesh Patwardhan at 5:25 AM | Permalink | Comments (0)

September 10, 2013

Stop starting and start finishing with Scrumban

In my previous blog, I spoke about how it could take a service request around 5 months to circle back to the user. In this blog, we will try to understand the crux of the problem. Some of the reasons that I can think of are:

Lack of visualization of the end-to-end work flow, resulting in less focus on resolving the impediments which increases the lead time.
Work is pushed to the team; each team member handles multiple work items. This results in constant context switching which makes them inefficient.
Work is piled up in work-in-process stage, resulting in lost focus to finish work which adds up to the lead time.
My favorite ones are the UFOS, these land from nowhere, take most of team's bandwidth, and no one sees them except a few. Some examples of UFOs are estimation of backlog items, production text changes, and an urgent ad-hoc report. These requests land in team's inbox with the priority almost equivalent to a national emergency, so all the items in work-in-progress are compromised to attend to these UFOs.

So, how do we address these challenges? Though there are multiple versions of lean and agile methods, in my opinion, the one that is perfect for a maintenance scenario is "Scrumban". Yes, it is a combination of Scrum and Kanban.

Refresher on Scrum: Split the organization into small, cross-functional as well as self-organizing teams. Split the time into short fixed-length iterations and focus on regularly delivering shippable features to the users. Scrum places emphasis on individuals and their interactions over process and tools, working software over comprehensive documentation, customer collaboration over customer negotiation, and responding to a change over following a plan.

Refresher on Kanban: Visualize the workflow to improve the lead and cycle times. This too suggests splitting work into smaller pieces to make it easy to manage. This method prescribes limiting the work in progress for each workflow state, focuses on eliminating bottle necks, and emphasizes more on finishing existing items before starting new ones.

Then, what is "Scrumban"? In simple words, it is a combination of the two methods mentioned above to increase the flow efficiency of work stream with all the advantages that Agile Scrum offers.

How does it address our current problem?

Three focus areas: visualizing the workflow to remove any possible bottle necks and impediments, thus finishing work in hand before adding new work items and managing the high priority items without disrupting the planned work.
Two main cadences - The first takes care of planned maintenance requests, time-boxed, and delivered every 2 or 4 weeks, and without getting interrupted. It runs in a scrum iteration way. The second cadence takes care of unplanned work in a Just-in-Time fashion with focus on improving work flow.
Two charts - burndown chart shows the remaining work to be completed projecting a possible iteration completion date, and cumulative flow chart shows the trend on the average lead time and the flow efficiency.

The essence of Scrumban lies in its 3 core principles:

Continue with what you do now
Improvise best practices, processes, roles, and responsibilities
Make incremental and evolutionary changes

Except for a few policies, it does not prescribe whole lot of changes. So teams do not have to stop what they are doing now and start a new way. The change can be incremental and evolutionary, making it easy for the teams to adapt and evolve.

Like other agile techniques Scrumban is run by self-organizing teams, with focus on continuous improvement, delivering frequently or on-demand, with increased client collaboration.

So... stop starting and start finishing with Scrumban.

Posted by Nagesh Chilamkurthi at 7:09 AM | Permalink | Comments (0)

September 6, 2013

Curious case of a change request - Will it ever finish?

"My momma always said, life is like a box of chocolates. You never know what you're gonna get." A very famous line from the movie "Forrest Gump", and I couldn't find a better metaphor than this to describe software maintenance. Software maintenance is like a box of chocolates, you never know what you are going to get at any moment.

If I may, I would like to dwell a bit on what makes maintenance like a box of chocolates. Software maintenance has internal variability and external variability factors which make the execution uniquely challenging. For example: Internal variability factors such as flow of the work items is irregular or class of service mix is diversified (work item size ranges from 100 person days enhancement to 30 min effort simple user query). External variability factors such as requirements are never frozen, and they keep evolving or the priorities change overnight.

In spite of all the complexities, maintenance teams with their shining armor of platforms, tools and frameworks are very much capable of delivering work in a reasonable timeframe. One would assume that the lead time to deliver a change request is within reasonable time and meets user expectations. But the reality is far from our assumption and most certainly far from user expectation.

Surprised?

A typical maintenance request of 5 person days effort, on an average takes more than 150 days to get in to production. This is based on numerous studies, and I am sure you will find the same if start measuring the lead times in your engagements. Before you scream out loud saying "150 days? That's unbelievable", let me quickly walk you through the life cycle stages to justify this number.

Once the change request is raised by a user, he/she expects it to come back in two or three weeks or at the most 8 weeks, it sets sail on a long uncharted journey. It first sits in a queue waiting for impact analysis & estimation to be done, it goes through a prioritization process which typically happens once in a month, and then it sits in a queue waiting for the build. If lucky, it is build time, but it might get dropped or deferred depending on the other priorities of the team. After completion of the build, it has to wait some more to go through functional testing, system testing, user acceptance testing, and let's pray for the immediate availability of the environments and testing team's bandwidth. There is a possibility of a change in the requirement or defect leading to rework, thus the cycle repeats all over again. Finally, after packaging and deployment, the final stop is to wait for the next deployment window in to the production environment. You do know how rare these deployment windows are, don't you? It might take weeks before we get a deployment window to move the changes in to production. After all this pain...Ta da! It gets delivered to the user.

Now I guess you could see 5 months as a genuine possibility for the request to circle back to the user. This is in spite of having the best in class tools, people and processes. By the way, we did meet all our SLAs, schedule, effort estimates & other service management and engineering metrics. How ironic? I am not going to make any guesses regarding the satisfaction levels of the user community.

In my next blog, we will get to the crux of this problem & see how Scrumban can help overcome these challenges.

Posted by Nagesh Chilamkurthi at 7:43 AM | Permalink | Comments (0)

September 5, 2013

CIO Mantra: Assessing Value of Software Asset

Have you ever looked at a financial report of any reputed company and asked the CFO a question on the lines of what are the assets of the company? The answer you get will be in typical finance terms like infrastructure, buildings, land, machinery etc. A value is always associated with these assets.

If you pose same question to a CIO in terms of value of software assets; in most cases the answer is not as clear as you get in earlier case. Does it mean in the IT department, there are no assets with value associated or there is no standard mechanism to identify assets and assign value, or no one has looked at software artifacts as an asset? Let's deep dive, to get answers to some of these questions that are relevant to us.

In most of the cases, code artifacts were written long ago. The same piece of code is developed, maintained, upgraded by IT and used for supporting day to day business decisions. It has lot of business knowledge/processes embedded in it. It is the same piece of code that differentiates businesses from competition. So if the organizations are achieving success by using IT as a backbone then most of them will agree that software produced/managed by IT is an important asset that a CIO owns. It is important because it has value associated with it and it can be a potential source of future revenue streams. These assets are not necessarily only code artifacts but can even be systems, methodologies, processes, tools that are unique to the organization.

Once you start looking at software artifacts as an assets then whole perspective changes. Pertinent questions like the one's mentioned below are raised.

What is the potential value associated with it?
Do we need to have overall strategy to manage these assets?
Are we putting sufficient effort to identify right set of assets?
Are we defining it in right manner so that it can be used across groups?
Do we have strategy to maintain, enhance and distribute it in seamless manner?

The questions are not limited to these and there could be many more.

Assets are enterprise resources and organizations will define effective strategy to deal with it only if they see value in it. Now value does not exist in the abstract form and must be addressed within the context of time, place, and potential of the asset. In general, there are three standard mechanisms to find the value associated with software assets.

Cost based Value
Market Based Value
Income Base Value

Cost Based Value is a conservative approach. It is commonly known as accounting approach. In this approach value of the asset is decided based on cost of development or cost of replacement or replication.

Market based value approach focuses on comparing the asset with a similar asset in the market or the kind of revenues that the asset could garner in the market. This approach often assumes future benefit and values, which are yet to be captured by brand valuation. Typically it considers M&A scenarios to calculate the value of assets.

Income based approach focuses on projected cash flow that can be earned from asset either by selling or licensing it for the duration of asset life.

Apart from these methods, the asset value is also dependent on various factors like nature of the asset - Is it a product or a onetime custom build, usage of asset, technical health of the asset, agility etc.

Once organizations agree that their assets are valuable, then putting a strategy in place to manage the assets becomes a natural step.

An Organization's asset management strategy should address key things like asset creation, if created then segregation, knowledge dissemination, branding of assets , reuse across groups and of course the commercial benefit. The overall approach from creation to reuse will change the way artifacts are designed, implemented and released. Sheer focus on reuse will force the organization DNA to change and the overall community will be benefited.

The assets need to influence the future implementation to save cost, improve time and reduce business risk. In some cases these assets are very novel and can be converted into IP's. It leads to legal protection of asset and opens up new revenue generation avenues for the company.

Infosys has recognized the need for a full-fledged service offering around building custom applications using assets. These assets can be from a client's existing IT portfolio or could be Infosys' assets or third party assets. To support this service, new assembly development processes are being developed. Various sophisticated tools to store/host assets and to stitch them together to form custom applications are being developed. This asset based development service will effectively deliver future custom developed applications for selected line of businesses. Focus on particular line of business will enable organizations to create business as well as technical assets in that particular area. In turn it will help reduce development cost and define to deploy cycle.

This whole paradigm shift will enforce client organization CIOs to think differently. If CFOs are taking pride in reporting metrics around tangible infrastructure assets then the day is not far when CIOs will take pride and start reporting some of their metrics based on value generated out of their IT assets.

Posted by Prashant Pawar at 9:23 AM | Permalink | Comments (1)

Spices, India and Outsourcing

Posted by Suman Sasmal - Vice President and Service Delivery Head, CORPBITS, Infosys

NILF 2013:What is keeping the new age CIO excited and Awake

[Source: NASSCOMVideos http://www.youtube.com/watch?v=_vZK0cyuZrI]

Destination plays a crucial role in the outsourcing world. Various social, economic, technology and political factors trigger shifts in both "from where" services are offered and "to where" services are delivered. This is forcing outsourcing partners to quickly adapt and embrace near-shoring, global-shoring, captive-shoring or other models that benefit clients.

To know more, click here

Posted by Guest Blogger at 9:05 AM | Permalink | Comments (0)