Take an enterprise architect level approach to succeed with Intelligent Automation
Amidst all the noise and hype around all things automation and AI, there is nothing more calming than to catch up with a client who is actually assessing and integrating all those wonderful innovations. I have known, and always greatly appreciated, the guidance provided by Wayne McQuoid Director, Head of IT Automation at Credit Suisse for some years now. Every time I catch up with him, I leave with the reassurance of feeling grounded. Looking at Wayne’s remit, which includes patching processes on a vast array of technical and process debt to support a large estate of computers across regions, you get a sense of the complexity he must deal with and why a pragmatic sense of realism is so important.
As every region had its own processes, they had to drive the change management. This included capturing the “as-is state” of those processes, analyze any potential scenarios to then integrate selected innovative technologies into each process with the goal of standardizing the way these processes are being run and managed. While innovation remains top of the agenda, the biggest problem in patching these processes was something pretty mundane: endless “disk full” messages that indicated that one couldn’t deploy the code because there is not enough space. The processes were set up with an industrial mindset to achieve global scale, but they were struggling to cope with changes in the environment. Listening to his reflections on Credit Suisse’s journey and his take of the state of the industry should provide ample food for thought.
Wayne, amidst all the noise in the market, as an industry veteran (in the best sense of the word) how do you guide your stakeholders on the evolution of service delivery and automation?
“For me, it is all about data and process. The discussions are being led by the information you have available, being led by tickets, being led by analysis, being led by the key use cases. Ultimately, everything is a data-driven discussion. You need the right data points if you talk to your organization. A lot of the tasks that you deal with are atomic in nature, but you need to build them up to a process-related view of things which for me is the target state. Doing that you have to keep in mind that going to a process-centric approach rather than a task-centric approach is a much more complex problem. Thus, creating those building blocks that address your high frequency, low complexity problems then gives you the opportunity to make those building blocks to solve broader process-related problems.”
Are the hyped discussions on concepts such as RPA, AIOps, Autonomics complicating the discussions with your stakeholders?
“That’s a tough one to answer. Lots of tools could do a job, no doubt. And in many ways how you apply those tools at the problems at hand, and the understanding of the process are critical issues. For me RPA is the patchwork quilt, it is one of the capabilities within the solution architecture, but it is not the answer. It is the common landing zone for people who understand the underlying problem. Reflecting the marketing noise, RPA in its own right is not the answer, you need an enterprise architecture, with APIs, you need the right technologies to solve your problem. They can be RPA, they can APIs, they can be the Aragos of this world. But you need to ask what your problem is and then how you marry your tool kits to it. Those are the tactical approaches and then in a broader context, you need to create your ecosystem to support more dynamic processes.
Thus, in terms of guiding stakeholders, you work with them to identify the right tools that help to solve the right complexity of problems. And then you set about the execution of resolving that problem. Whether these are the high-frequency actions that occur across organizations like server patching, server provisioning, server decommissioning. Understanding those requirements and understanding the process nuances around those processes and then normalizing those processes as standardized ways of doing things is really the methodology that I work with my stakeholders on. As are breaking the problems down into piecemeal constituents parts and then I help to work with my partners to solve those problems with technology be it the noise around RPA or something else. There is no doubt there are hype discussions. I would argue there is an overinterpreted understanding of what the tools can do for you. In my experience, understanding the organisational setup can often be more important than the technology used to solve the problem. You can use many tools, but you really need to understand the problem and the capability in order to select the tools to solve that problem at scale. There are many point solutions, the more I look at it, the more I see enterprise-level architecture and thinking is required to really make progress. Within the Intelligent Automation Continuum, you can’t solve things piecemeal, you have to have an enterprise architecture with a strong understanding of your data layer, with a strong understanding of your process, in order to address your problems in a meaningful way but not a facile or piecemeal way.
What are the strategic goals that Credit Suisse is aiming to achieve?
“It is organizational efficiency, time to market, quality improvements, customer experience, all of those things. We are applying all those innovative technologies to move from a reactive mode of managing things to a more proactive, predictive way. Thus, avoiding a problem before it happens, pretty much getting on the front foot, enabling self-service for customers, breaking down barriers between technology siloes, and improving processes at the same time. Ultimately to free up people to focus on high-value tasks but not on low frequency, low complexity tasks.”
What are the key learning experiences (for better for worse) on your journey?
“We touched upon this before, it is about uncovering those opportunities, using data to drive you to those opportunities, using your knowledge of the stakeholders. I really think stakeholders are critical in all of this because mostly processes traverse organizational boundaries. And organizations go through reorganizations a lot, you centralize, decentralize, centralize and so on. The processes though don’t necessarily change as organizations go through these stages, and consequently, these processes tend to become disjointed, fragmented with unclear ownership. So, you need to work with your stakeholders to understand those processes end-to-end. And then attacking the instances in a domain-specific way in the first call of action, but then wrapping an end-to-end view around them and understanding the flow through the end-to-end process in order to then trying to optimize each of these stages of the end-to-end process.”
If you could change one thing of the current discussions on Intelligent Automation, what would that be?
“It is less about tools and more about processes and in particular the problems those processes bring to you. You always need multiple tools to solve various problems. But ultimately how you break down the processes using Lean or whichever methodologies you use is ultimately the way you make improvements. For instance, if you break down those processes into the underlying requirements to fulfill those process needs. Whether these are robotics capabilities, or robotics fused with natural language or OCR capabilities, aspects of cognitive as well. You need all those tools in your tool kit in order to achieve the outcomes for process optimization. And then you can potentially start to evolve as you optimize at a higher level. The lower level discussions can be quite distracting and opportunistic. But you need to evolve to a higher level, enterprise architecture level landing of processes and knowledge curation rather than just piecemeal. One thing that you often see is that a process is not understood end-to-end. Consequently, if you have fragmentation of how someone should be working or equally a fragmentation of ownership, it never works appropriately. You can maintain and curate the knowledge around that process, and then ingest that into a capability and execute against, then you have a much greater chance of making progress. Where your knowledge is distributed and in fact in many instances a lack of an overall inventory of processes. Where that is distributed across the organization, I think you are de facto set up to fail. You need a methodology for managing your processes, have a standard way of curating the knowledge around those processes, and have measured as to how effective or ineffective those processes are, and continue to curate the knowledge around that process as it evolves.
Wayne, there was a good reason why I wanted to do the interview with you and your great insights have just confirmed this. We are looking forward to expanding our collaboration with you and to more great discussions!
