To centralize or to federate—this is a question that every automation program asks and re-asks at several points in its journey from start to hyperscale. As someone who has experience working within both models, I can honestly say there are valid benefits and drawbacks on each side. So, what will work best for you? Here are my thoughts...

First, let’s briefly review the purpose and importance of a Center of Excellence (CoE).
 

COE’S PURPOSE

A CoE plays a pivotal role in an organization, defining the vision, strategy, and best practices for an automation program. While it may have a specific focus area, a CoE should not be confused with a business department. The CoE itself does not perform operational tasks but rather oversees best practice adherence, provides training and support to staff, and governs proper resource allocation. For a CoE to be successful, it must have a unwavering commitment to overcome obstacles along the journey!

With that in mind, let’s explore the nuances of centralized vs federated models.
 

ALL ABOUT CENTRALIZED MODELS

In my previous role before joining Boston Scientific, I was part of a centralized CoE. It was a much smaller company, and operating in a centralized model was completely manageable. We oversaw the relationship with our vendor and controlled the automated solutions across the entire enterprise, from development and process improvement to production support. We were one team, completely in sync with our program and goals. This can be difficult in a federated model, but I’ll get into that in a minute.

One downfall I’ve observed working in a centralized CoE, as well as speaking to my peers who operate in a centralized model, is that, inevitably, certain departments with a high volume of transactions start to get prioritization in the pipeline and production support since they are driving the most value in the automation program. In turn, smaller departments are consistently put on the back burner or even overlooked entirely for new automation opportunities.

Quick anecdote: At this previous company, we never touched HR. It was a smaller department in terms of number of employees and volume of recruiting efforts. With bigger departments in our pipeline, we never felt it was worth our time to prospect opportunities in HR. Now, I sit in HR at Boston Scientific, and I’m working on impactful automation within HR every day. This has provided a valuable learning experience to look back and acknowledge that, even though the previous HR department was small, there were likely valuable untapped opportunities there.

That’s not to say you can’t achieve growth enterprise-wide with a centralized model—you definitely can! This is where democratizing automation and citizen development come into play. Citizen developers can develop solutions for those smaller use cases. And I’ll be the first to admit that it does take additional energy to nurture and govern a citizen development program. But if you have the resources and interest from business users, it’s hugely beneficial to centralized models!
 

THE FEDERATED MODEL LOW DOWN

A federated model, on the other hand, is a more extensive community of people working similarly across multiple CoEs. Boston Scientific has 50-100 people working in automation and six dedicated CoEs. My specific HR CoE is comprised of three developers and myself, who manage the production, support, and business analysis of HR-related automations. If there’s ever a use case we can’t solve on our own, we can collaborate and benefit from all the folks across the other five CoEs, see what tools they’re using, or if they have any similar use cases that could provide insights or frameworks for us.

One drawback to the federated model is that if you don’t have open lines of communication between teams, you’re doing yourself a disservice. You could be duplicating efforts or tackling a solution that may be better suited for a different CoE because of the systems it touches. It easy to go about your day-to-day working independently. A federated model requires a conscious, intentional effort to create consistent lines of communication between CoEs. At Boston Scientific, we have an IA Council comprised of each CoE lead that meets monthly to share ideas internally. Additionally, the developers from each CoE meet weekly to share code and align on big efforts, such as outlying bugs, platform advancements, or, specifically, the migration happening for us right now. We’ve also had a recent push to create automation catalogs that will showcase lists of automations and summaries of their features and regional impact. We believe this will be a critical tool for sharing the use cases, technology, and tools we’re using with the other CoEs. Having a multitude of touchpoints in a federated model is key!

I mentioned a more extensive community of automators in a federated model, which also means a stronger community of practice. When I worked in the centralized model, it felt like every conversation I had when promoting our program was with a new person—like I was starting from zero with each person when it came to informing them about RPA. Conversely, my experience in a federated model has been far easier. Many people already know what RPA is from each CoE doing work to spread the word about automation, which means I don’t need to do nearly as many roadshows and a great deal of my backlog comes from people who already know we exist.
 

THE CHOICE IS YOURS

The moral of the story? Ultimately, there are benefits in both models, and which will be best for you completely depends on your organization’s unique situation, size, and what it wants to achieve. As your program grows and your business evolves, don’t feel married to your current model either. Shifting from a centralized to a federated model as you scale is common and, in many cases, essential if you are noticing cracks in your operation. But if it ain’t broke? You know the rest…