This week I want to write about service level agreements (SLAs) as a tool EA teams should use throughout the enterprise to drive improved performance and measurement. In Chapter 2 of Enterprise Architecture As Strategy (Ross, Weill, & Robertson, 2006) the importance of defining a company’s operating model, and furthermore, on the integration between processes is stressed. It is here, with the integration between processes, that SLAs should be applied.
When operational problems arise at my current employer, it is fairly common for one department to lay blame on the preceding department (in the affected end-to-end business process). The dispersions sound something like “If Team Xyz would only provide complete and accurate inputs to our team, then we’d be able to do our job properly.” Ensuing discussions meander and usually devolve into a “venting” session rather than a constructive examination of the business process.
In a similar manner, there’s a catch-phrase we use of “clear to cheer” that is meant as a warning to teams that push for the rapid elimination of a backlog through overtime or incentives (hence the catchphrase, where clearing the backlog leads to cheers). The reason for the warning is that the backlog problem simply gets passed on to the next department in the process. We’re passing the problem on instead of solving the reason for the backlog.
The aforementioned are examples of what happens when the handoffs (the inputs and outputs) involved in a process are not formally defined and governed, and that’s where SLAs come in.
SLAs are extremely common in IT and other service-oriented organizations, but not common at all among the operating departments within an enterprise or business unit. Every inter-departmental handoff in an end-to-end process should be governed by an SLA, which will give us several benefits:
- Clear departmental accountability. Those meandering meetings with lots of “venting” will become more constructive.
- Goal and objective setting for individuals and teams become easier and more quantitative.
- Strategic opportunities become clearer and the ability to analyze the impact of changes becomes easier when input and output requirements are defined.
- SLAs will highlight the ideal granularity of business process documentation. We learned about the “burden of knowledge” in “Enterprise Architecture Pitfalls - Current State First?” (Bittler, 2012), where EA teams are cautioned against documenting too much of the current state. I would certainly characterize the documenting of processes within departments as a “burden of knowledge”, however, documenting processes at the level of each department-to-department hand-off (the SLA level) may be just the right level of process documentation.
- SLAs give us a set of measurement requirements. My blog posting from last week addressed designing for ease of measurement. If our business processes have SLAs in place, then future technology projects can take these requirements and actually design for ease of measurement.
Last week I asserted that EA teams should take the lead in ensuring that enterprise’s design for ease of measurement. This week, I will assert that EA teams should also take the lead in ensuring SLAs are a requirement for all inter-department processes. This strikes me as an opportunity for EA teams to show how they can positively impact the business and even transform it without always proposing new technology solutions.
References
Ross, Jeanne, Weill, Peter, Robertson, David. (2006). Enterprise Architecture As Strategy. Boston, MA: Harvard Business School Press
Bittler, Scott. (2012, January 31). Enterprise Architecture Pitfalls - Current State First?. Retrieved from Penn State EA-872 class material
Scott,
ReplyDeleteI like your proposal for SLAs in business processes. I really haven't thought of using SLAs in that perspective. Studying and implementing a SOA, it has been critical to establish SLAs to get the most value out of those services.
SLAs will help establish guidelines for processes that everyone understands and agrees are needed to be successful. It seems that they will help keep the guidelines at the forefront even as people come and go from the organization, support group or IT.
Great post. SLAs are very helpful when timely coordination in required, but like Troy, I had never thought about how to use them in an EA context. I personally think your second point is key: Goal and objective setting for individuals and teams become easier and more quantitative. I think if people clearly understand their goals and how their own service quality will be assessed, management can then expect to see more consistent outcomes. You've definitely provided food for thought on this subject.
ReplyDeleteI am curious about two things: first, how many organizations your group has SLAs with? Second, who generally brings forward the request to enter an SLA? Is it part of "doing business" with your organization?
Scott,
ReplyDeleteThis is a really interesting application of SLAs. I appreciate the idea that these SLAs will support specific goal setting, and should alleviate many challenges related to measurement and accountability.
I'm going to echo the question posed about who is responsible for creating the SLAs. I'd also be interested in learning how the oversight or governance of these agreements are carried out.
Thanks for sharing this information.
Agree with the previous comments. I have not thought about SLAs within the context of Enterprise Architecture but it is definitely an interesting and a good idea to include those in the discussions. It is an added benefit if SLAs are part of the business viewpoint principles as that will derive all other subsequent SLAs from the information and technology viewpoints. It would be interesting to see what an enterprise architect components and artifacts specific to SLAs would look like and who would administer the governance (i.e. make sure the teams and different responsible parties are in adherence).
ReplyDelete