The Stacks ApproachWhy It’s Time to Start Thinking About Enterprise Technology in Stacks

CONTENTS

Executive Summary

Layer 1: Enterprise Competency Domains

Layer 2: Platforms

Layer 3: Enterprise Technology Stacks

Making Sense Of It All: Stack Rationalization

Conclusion

Executive Summary

How do you run your business? It might seem like a loaded question that requires a complex answer, but the truth is the answer might be simpler than you think. And although each organization has its own “secret sauce” that makes it unique, there are likely more similarities between your answer and those of other organizations — not just those in your industry — than you expect.

You see, every organization has a set of competencies that are required to run the business, and only a portion of these competencies (known as core competencies) are unique to your industry. In addition to your core competency, these competencies include areas like customer engagement, performance management, administrative management and request servicing.

To further drive the effectiveness of these competency domains, modern organizations automate them with software platforms, which helps drive efficiency. These software platforms are typically further developed by adding layers of integrated applications on top of them. This setup creates what we can refer to as “enterprise technology stacks.” For example, you might automate your customer engagement with a CRM platform, which includes integrated applications for sales force automation, service, marketing and Configure, Price, Quote (CPQ) capabilities, therefore creating a CRM stack.

At its core, every single business operates on this stacks approach — whether you know it or not. But the time has come to recognize this technology setup and use it to your advantage. Why now? Because as your organization begins (or continues) its move to exploit the benefits of the cloud, developing a proper cloud strategy will require you to understand what your stacks are, what they currently look like and what you hope they will look like. Ultimately, this recognition will help you determine which applications are ready for a move to the cloud, which cloud solutions will best satisfy your needs and the stack in which they should reside. We can refer to this approach as stack rationalization.

So how do you get started with the stack rationalization approach? This paper will explore the approach in detail, including what each of the layers of looks like and how you can rationalize your stacks to support a successful cloud transformation.

Layer 1: Enterprise Competency Domains

Every organization has a number of different things that it does. For example, if you’re a clothing retailer, your organization might work closely with designers and buyers to stock its stores with inventory. This activity is considered your core competency. But like any other business in any industry, you also need to focus on how you sell to customers (customer engagement), how you manage your resources such as finances and people (administrative management), how you manage day-to-day performance, such as communication and collaboration among employees (performance management), and how you service internal requests, for example obtaining a document from the legal department (request servicing). We can refer to these areas of focus as enterprise competency domains.

Let’s take a look at each of these competency domains in more detail to determine how they set the foundation for running your business and for your enterprise technology stacks.

Customer EngagementEveryone has customers. After all, without customers, you have no business. Therefore, your business must have some sort of competencies around how you engage with customers. This domain often includes skills around marketing to, selling to and servicing customers. Because customer engagement has always been top of mind, this competency domain is typically well-defined in organizations across all industries.

Administrative ManagementWhile there are some smaller organizations that outsource some of these skills, every organization needs to manage its resources such as finances, supplies and people. For example, this competency domain includes managing your books to monitor income and purchases as well as human resources tasks such as managing employee codes of conduct, vacation days or health care plans.

Performance ManagementHow do your employees get work done? The answer to this question — including how they communicate with one another and partners, how they assign work and how they schedule meetings — encompasses the performance management competency domain. Although performance management has always been a part of

running businesses, we haven’t traditionally paid this domain the same attention as other domains like customer engagement and administrative management.

Request ServicingInside of your organization, everyone is someone else’s customer. For example, everyone is a customer of HR, finance and all of the other functions under which they don’t fall. When you need something, such as reimbursement for travel expenses, you need to get it from another function within the organization, which makes everyone a customer of other internal groups. Although this is certainly a new way of thinking about internal services, this behavior has always been a fundamental premise of how organizations operate. We can refer to this area of focus as the request servicing competency domain. It’s important to note here that the request servicing domain is different than the customer engagement domain because it focuses on how internal users service one another. For example, this domain asks: How do you get a form from HR, a key from facilities or a contract template from legal?

Core CompetencyUnlike the other competency domains that are more or less the same across all organizations regardless of industry, the core competency domain is unique to each industry and, sometimes, each business. The activities that fall under this domain are those that make your industry and/or business what it is. For example, a core competency for manufacturing organizations includes turning raw materials into products while core competencies for insurance firms include assessing risk and paying claims.

A Framework for Competency DomainsThese five competency domains — customer engagement, administrative management, performance management, request servicing and core competencies — are simply a starting point for the enterprise competency domain framework.

While these five domains repeat across all organizations, there’s no doubt that each of these domains can have subsets or even morph into a core competency depending on the organization. Performance management, for instance, has interesting subsets, such as communication and collaboration, that are emerging as key areas of focus and can sometimes become domains of their own. Similarly, marketing is a subset of customer engagement, but modern social technology has helped bring this subset into the limelight. Meanwhile, domains like administrative management might actually be a core competency depending on your industry.

Although these five domains don’t take a one-size-fits-all approach, they are without a doubt an excellent place to start as you evaluate the enterprise competency domains that power your organization. Chances are, you’ll be able to identify each of these five areas within your organization with ease. Once you do, the big question is whether you sufficiently possess all the competencies within each domain that are required to run your business effectively.

Diagram 1

PerformanceManagement

CoreCompetency

RequestServicing

AdministrativeManagement

CustomerEngagement

Layer 2: Platforms

Once you’ve identified your organization’s competency domains, it’s time to consider how you automate these domains with technology platforms. Modern organizations typically have some type of technology platform that helps them manage these domains. The three big technology platforms in this area are Customer Relationship Management (CRM), which automates customer engagement, Enterprise Resource Management (ERP), which automates administrative management, and workplace productivity, which automates performance management.

ERP was arguably the first to emerge as a recognized platform, followed closely by CRM. Both of these platforms grew and consolidated from different fields over time. For example, ERP started by focusing on finance management, but has since grown to include MRP, HRIS and other organizational resources. Similarly, CRM started out as independent automation applications for each of the major customer-facing functions — sales, service and marketing. Now, like ERP, it has merged into an integrated platform to provide a seamless view of customers across all dimensions and channels although they don’t always follow a standard name like ERP and CRM, workplace productivity platforms were technically the first to be created, automating activity like communication and task management. Capabilities such as email, calendar, document creation and management have been standard for some time. More and more, collaboration functionality has defined this platform further with capabilities such as chat, joint document editing and video conferencing.

Meanwhile, service management platforms, which automate request servicing, are now emerging following the idea that routing all internal requests through a central platform makes it more effective for employees to get what they need from one another. The idea here is that managing all different types of requests through a single service management platform (rather than piecemeal technologies owned by each department) not only simplifies usage for employees (who only have to master a single system and process), but also benefits the organization by spreading best practices to improve service delivery and creating economies of scale by replacing multiple solutions with a single one. We might argue that many service management activities traditionally fell the under administrative management competency domain and were thus managed by ERP systems, but have since broken away and become their own domain, now managed by service management systems.

Finally, the technology platforms that power the core competency domain are unique to each industry, but there are some similarities across the board. In general, these platforms are often large, custom-developed systems that are well engrained into organizational processes. A further challenge to IT and business effectiveness is that many of these platforms were developed some time ago and therefore their technologies are outdated and their authors are no longer available. As a result of these circumstances, these platforms create a precarious situation for many companies.

Regardless of whether it’s ERP, CRM, workplace productivity, the currently emerging service management platform or the potentially outdated core competency systems, the idea is that these technologies bring together a variety of capabilities into an integrated platform that powers each competency domain.

Layer 3: Enterprise Technology Stacks

Most organizations further develop these platforms by adding layers of integrated applications. At this point, each area of focus becomes what we can refer to as an “enterprise technology stack.” For example, the CRM stack might include applications for sales force automation, service, marketing and CPQ, all of which come together to power the customer engagement competency domain.

As we continue to stack more and more applications onto a base platform, these stacks grow. Remember how we said that ERP and CRM have evolved significantly since their inception? That evolution is largely due to growing their stacks. The idea here is that integrating applications directly into a platform makes it easier to fulfill the needs of each competency domain by taking more of a plug-and-play approach. As a result, we’ve seen ecosystems of vendors pop up around each of these base platforms. For example, your CRM or workplace productivity solution might have an “online store” where independent vendors market applications that integrate directly with the base platform.

Not All Stacks Are SymmetricalIt’s important to note that not all stacks are perfectly symmetrical. For example, some core competency stacks are much more mature (and therefore higher because they have more options for integrated applications) than others, it all depends on the industry.

Diagram 2

Diagram 3

Customer RelationshipManagement

Enterprise ResourcePlanning (ERP)

Core CompetencyPlatform

WorkplaceProductivity

ServiceManagement

Furthermore, some stacks may have offshoots. Looking at the workplace productivity stack, collaboration is such a huge area of focus today that it might end up forming its own secondary stack in many organizations. In this case, the collaboration stack would be a smaller offshoot of the main workplace productivity stack.

Introducing the Base Layer: Data Integration and Analytics

Once you’ve developed your stacks, you must also recognize that there’s a base layer of data integration and analytics. Data integration and analytics becomes the base layer of the stack model because it can be an element of any given stack or even serve as a bridge between multiple stacks.

For instance, some organizations may have a specific application dedicated to analyzing customer data that sits on its CRM stack while others might have data analytics applications that integrate the CRM and ERP stacks so that sales and service agents have easy access to customers’ financial data or that integrate the CRM and workplace productivity stacks so that salespeople can easily view calendars to schedule meetings with customers. And those examples are just the tip of the iceberg. As we continue to move deeper into the age of big data, the importance of this base layer and the use cases for it will only grow.

Common nomenclature often refers to the combination of these platforms, their stacks and the integration between them as the application layer.

Stacks Are Not Set In StoneIf the evolution of these platforms and their resulting application stacks have taught us nothing else, it’s that these stacks are far from set in stone. As enterprise technology evolved over the past 30+ years, we’ve seen applications, such as CPQ, which started out in the ERP stack and is now more commonly found in the CRM stack, jump from one stack to the next. And as the service management stack continues to grow, we can definitely expect to see it pull applications off of the ERP stack as well. Likewise, we can expect to see movement of certain workloads from other stacks onto the workplace productivity stack, particularly as organizations build more workflows there to automate tasks.

In general, as technology evolves over time, we see a trend of applications moving from one stack to another. Both the emergence of new stacks and platforms (such as the request

servicing stack and the service management platform) and the maturation of existing stacks and platforms (such as the performance management stack and the workplace productivity platform) contribute to these changes as vendors find their applications might be more suited to these emerging and developing technologies. Because there are multiple stacks and multiple platforms associated with each competency domain, applications are very likely to move from one stack to another based on market and industry trends.

Additionally, the rise of cloud technology has heavily influenced application stack changes in recent years. As more modern organizations move to the cloud and become more digital in nature, the entire migration process significantly impacts what each of these stacks look like. That’s because as your organization outlines its cloud strategy and plans for adoption, what you’re really doing is rethinking your stacks, including taking an intensive look at your application layer to determine which stacks and applications govern which activities, which of those applications and activities make sense to move to the cloud and the appropriate stack on which those new cloud applications and activities will fall.

Making Sense Of It All: Stack Rationalization

What’s the point of the stacks approach? Why is taking this approach so valuable and how can it facilitate your organization’s move to the cloud? Stack rationalization is where it all comes together.

Once you understand the stacks evaluation approach and have outlined what your organization’s stacks look like, you can begin to rationalize your stacks in order to answer two critical questions:

First, Which Applications Are Cloud-Ready?In order to modernize beyond simple automation and become a true digital business, your organization must move more and more of its stacks to the cloud. As part of this modernization process, you need to look at each stack individually to determine whether you can move the entire platform to the cloud or if you’re better off starting with certain applications. If it’s the latter, you then need to assess which applications within the stack are cloud-ready. And, in some cases, you may even decide to update your homegrown processes by introducing new applications in the cloud, like CPQ.

Diagram 4

Diagram 5

The key element here is understanding how your organization will benefit from any given move to the cloud. The best practice approach is to set criteria for taking applications — or even an entire platform — to the cloud. Some common evaluation criteria include legacy technology concerns, such maintenance and vulnerabilities, slow pace of change and end-of-life on software contracts, and changes in the market, such as social, mobile and data factors. During this evaluation, you also need to think about what’s driving your move. Is it increased flexibility, reduced cost, more satisfied business users?

Second, Is Each Application In The Appropriate Stack?During this modernization and evaluation process, you also need to consider how you’ve organized your stacks to determine if each application is associated with the right stack. As you undergo this part of the evaluation, you might ask questions like: Do some of the applications in our ERP stack, such as CPQ and HR requests, belong elsewhere, such as the CRM and service management stacks? Or should we take custom applications and move them to the workplace productivity stack because doing so would create a more integrated and user-friendly experience? Both of these are common trends happening in the enterprise technology ecosystem today.

Regardless of what stack rationalization questions you might ask, the key to answering them is to consider factors like ecosystem development, ease of integration and overall user experience. If you find better applications to meet your needs in another platform’s ecosystem, can better integrate applications with another platform and/or discover that moving an application to another stack can improve how users work, you likely have a strong case to switch that application from one stack to another.

ConclusionThe stacks approach outlined in this paper requires a different way of thinking. Traditionally, we’ve thought of the technology that runs our business as falling into a single stack; however, it’s time to look at it in multiple, competency-driven stacks.

By calling for us to view this technology in multiple stacks, not just one single stack, the stacks approach provides a clear framework to follow as we manage the cloud and digital transformations that today’s businesses must undergo to optimize effectiveness.

To recap, the stacks rationalization approach follows the mindset that each organization has a set of enterprise competency domains (most often customer engagement, administrative management, performance management, request servicing and core competencies). Organizations then automate each of these competency domains with a technology platform (typically CRM, ERP, workplace productivity, service management and industry-specific solutions). Each of these platforms then has its own stack of integrated applications that help power businesses processes. At the same time, data analytics and integration underlie all of these stacks as a base layer, often connecting two or more stacks.In the era of digital business, the stacks approach is superior to the traditional way of thinking because it helps you better visualize how technology supports key functions that power your business. As a result, this approach also helps answer two critical questions that you must ask as you develop your cloud strategy: Which applications are cloud-ready and is each application in the appropriate stack?

As your organization moves more and more applications, and even entire platforms, into the cloud, evaluating cloud-readiness and stack organization is essential to achieving success and realizing true business transformation.

Diagram Index

Diagram 1

Diagram 2

Customer RelationshipManagement

Enterprise ResourcePlanning (ERP)

Core CompetencyPlatform

WorkplaceProductivity

ServiceManagement

PerformanceManagement

CoreCompetency

RequestServicing

AdministrativeManagement

CustomerEngagement

Diagram Index

Diagram 3

Diagram 4

Diagram Index

Diagram 5

About AccentureAccenture is a leading global professional services company, providing a broad range of services and solutions in strategy, consulting, digital, technology and operations. Combining unmatched experience and specialized skills across more than 40 industries and all business functions—underpinned by the world’s largest delivery network—Accenture works at the intersection of business and technology to help clients improve their performance and create sustainable value for their stakeholders. With approximately 373,000 people serving clients in more than 120 countries, Accenture drives innovation to improve the way the world works and lives. Visit us at www.accenture.com.

Copyright © 2016 Accenture All rights reserved.

Accenture, its logo, and High Performance Delivered are trademarks of Accenture.