Tag

cost of ownership

Services Buyers: Don’t Overlook Technical Debt in New Techs | Sherpas in Blue Shirts

By | Blog

Any replacement of new technology for an old technology, or a new approach to technology acquisition, incurs a technical debt that the consumer of the technology must pay down. Providers make all kinds of promises around SaaS, BPaaS and platforms, which lead buyers to believe they can avoid the technical debt when they adopt these newer technologies. But avoidance is just a myth.

A good example of technical debt is companies that move from waterfall to agile. They must invest in a DevOps platform with automated testing, invest in training new and existing talent and invest in changing the way they architect applications to allow for frequent updates.

Let’s consider a Salesforce (SaaS) implementation. In theory, it’s very easy to start using Salesforce.com for your CRM. But in practice, it turns out to be more complicated. Data must be loaded, APIs must be connected, Salesforce must be configured, user training must be conducted and, finally, all this must be tested.

The technical debt tends to increase the more disruptive the change and, unfortunately, the more impactful the changes on the business. In the case of SaaS or BPaaS, which in large enterprises tend to be point solutions, there is a modest technical debt. But in the case of platforms, where the buyer must make large structural changes to important systems of records, the technical debt is significant.

The technical debt creates complications that slow down migrating to SaaS, BPaaS or platform technologies. It also creates user frustration because of ongoing issues in transition/migration. The business users are eager to get to the resulting capabilities and are impatient with the time it takes to get there and the learning curve they must go through to be productive in the new environment. Users are unwilling to invest in the cost and effort to pay down the technical debt, but it surrounds the users’ ability to integrate the new technology and make necessary changes to be able to use it effectively.

As your business moves forward with adopting new technologies, be aware that the technical debt is a key issue in successful adoption. Service providers must be clearer and more honest about the scale of the technical debt and work on approaches that limit it. Nevertheless, buyers need to remember that the technical debt resides with the consumer. And no matter what the provider tells you, the debt is there and it’s likely to be large.

The Automation Technology Starter Question | Sherpas in Blue Shirts

By | Blog

A question that we are often asked about service delivery automation (SDA) is “What technology should we use to automate our business processes?” The answer to this, of course, depends on the organizations requirements and existing capabilities, but there are some basic and general rules that can help organizations get started on their automation journey.

Before that journey begins, to facilitate internal communication, it is very important for organizations to develop a common vocabulary for automation. For example, not every type of automation is robotic and not every robotic automation does screen scraping!

Everest Group’s first principles of SDA and definitions can help organization develop a unified vocabulary for automation:

  • SDA is utilization of technology to replace a series of human actions
  • Much automation is already embedded in software systems (e.g., linking customer information across finance and procurement functions), but since it is part of the normal feature-functionality of a system, it is generally not considered as automation, but rather simply a more powerful system(s)
  • SDA can refer to automation in IT infrastructure and application management services as well as business processes.

The focus of this post is SDA in business processes. A simple way of grouping automation tools for business processes is by the type of data or information that they can handle:

  • A subset of SDA is Robotic Process Automation (RPA). This refers to a group of tools that interact with computer-centric processes, typically, through the user interface and so can do away with the need for other types of integration with the underlying system:
    • RPA handles structured data, for example, taking data from electronic forms and entering them into databases. RPA software vendors include Automation Anywhere, Blue Prism and UiPath. The graphic below provides Everest Group’s definition for RPA.

KeyDefinition-RPA_amr

  • Another subset of SDA is a group of tools that we refer to as cognitive. These are intelligent tools that use machine learning to build a process-related knowledge-base to automate processes:
    • Cognitive tools typically handle unstructured data – Examples include Celaton’s inSTREAM and iPSoft’s Amelia.

If your organization is looking to automate traditional data entry processes, such as order processing, then a starting point is to look at RPA tools. If on the other hand, the process has to handle non-voice customer interactions such as emails, documents and multi-media and web content, then cognitive tools could provide the answer to your requirements. Examples include:

  • A telco that uses RPA for high volume transactions such as SIM swaps
  • A financial services company that uses RPA for processing of redemptions and asset migrations
  • An insurance loss adjuster that uses a cognitive tool for automating processing of in-coming customer documents including evidence for insurance claims.

Other aspects of automation technology to consider include but are not limited to:

  • Depth and breadth of functionality – for example a feature-rich automation development and testing environment
  • Integration capabilities – as well as integrating with departmental software such as finance, the tools may need to interact with enterprise software (e.g. Microsoft Exchange), business process management software (e.g. Appian, PegaSystems, Tibco) or document management software (e.g. IBM FileNet or OpenText)
  • Scalability and performance – ability to grow volumes of transactions as the need grows
  • Support for virtualization – for example in the user environment via Citrix
  • Deployment options – such as on premise or hosted by the vendor
  • Commercials – licensing models and prices
  • Support and maintenance options in your geography
  • Customer references and proven business cases.

Vendors are always happy to arrange demonstrations of their software. You could give them a test scenario to set up for and demonstrate. Some organizations have gone a step further and have run different proofs of concept in parallel to find the best solution for their requirements.

It is important to note that you are not limited to one type of automation:

  • Service delivery automation can be accomplished by combining multiple technologies. For example, traditional Business Process Management (BPM), workflow and document management technologies can be combined with newer UI/robotic process tools
  • Cognitive tools can be combined with RPA tools, which in turn can orchestrate tasks back and forth between workflow tools and people
  • The output of one process can also act as an automatic trigger for the next to start.
  • The entire process need not be fully automated – partial automation is also highly valuable and the most common approach.

In my next post, I will look at the types of processes that make good starting points for automation.

Everest Group publications on SDA include:


Photo credit: Flickr