How can IT can evolve from “order taker” to a true business partner?
Tom Rodden, Director, Enterprise Applications at Varian Medical Systems took some time in September 2010 to speak with Insider Learning Network’s Sarah Cenedella, and take questions from members and SAPinsider and SAP Experts content teams.
Tom reflected on his recent experiences transforming his SAP IT department’s role within the organization. After own business and IT transformation project, Varian Medical Systems went live with SAP ERP 6.0 , expanding the user base for both its SAP NetWeaver Business Warehouse (SAP NetWeaver BW) and SAP CRM solutions. A second project, implementing an SAP ERP Human Capital Management (SAP ERP HCM) solution, extended the reach of Varian Medical’s HR systems to 31 countries.
For more on how this process unfolded, read the full insiderPROFILES article. The following is an excerpt from the full Q&A.
Sarah Cenedella: Thank you all for joining us today for this live Q&A with Tom Rodden from Varian Medical Systems. To start, I have a question submitted from a member of our content team here at SAPinsider:
Was redefining IT’s role within your organization the catalyst for the decision to use SAP Enterprise Support, or a by-product of a larger strategy?
Tom Rodden: Signing up for SAP’s Enterprise Support was part of a general decision in Varian IT to strive for world class performance. We felt that skimping on SAP support would undermine the rest of our efforts. But that decision was only part of the strategy we had to improve IT’s delivery. In fact, while it has been very beneficial, it was not a central component of our strategy, more of a logical extension of the strategy.
To elaborate a bit more: The strategy was: Separate project work from support work, bring in a vendor to provide support, and liberate the in-house applications team from the demands of routine support so that they can deliver new and improved functionality (through a substantial project portfolio).
The SAP Enterprise Support contract was part of the strategy because we felt the increased support would accelerate time to resolution and therefore reduce the time my team spends on support. So, to answer the question, you don’t
need Enterprise Support to make the kinds of org decisions we made, to engage a third party to play the support role, to get your employees excited about being the experts and leaders who implement the new functionality, or to steer the team towards more rather than less training. All of that is quite separate from a decision to use Enterprise Support.
Scott Priest: Did SAP's support team help you with GRC/security issues during the upgrade? And were business and IT on the same page about things like controls and authorizations?
Tom Rodden: SAP has been helping us with GRC/Security issues, both during the upgrade and since. It has been extremely beneficial as we have struggled in this area, particularly with portal security integrated to the ECC backend and Active Directory.
Molly Folan: In the article, you offered 5 lessons learned about Enterprise Support. What are some others lessons you learned during this IT transformation?
Tom Rodden: There were a LOT of other lessons! For example:
- Business buy-in: do not assume business “reps” are enough
- Hold regular meetings with business stakeholders/sponsors from the start
- Conduct an end-of-design integrated walk-through for Design sign-off
- Issue escalation: do not hesitate to escalate
- Make issues reviews part of your regular business meetings—project team agreement is not enough
- Document the issues! Too often VVP did—this comes back to bite you
- Planning: do not short-change planning
- Fight the urge to “do” at the expense of planning—
you will end up “re-doing” a lot of work
- Varian Out In Front: do not let the consultants become “managers”
- Ensure that Varian people are in every meeting and make sure Knowledge Transfer happens
- Otherwise, Production Support will suffer and costs will rise as we cannot roll off the consultants
- Documentation: do not skimp
- Build quality documentation into the project’s processes—support and KT will go more smoothly
- Data: do not assume that unit/string/integration/stress/perf testing suffices
- Take data cleansing seriously—plan for it, make it clear early on that the business needs to own this
- Look for additional forms of testing to check data quality
- Development: Even with a package like SAP that has so much functionality in the standard software, a strong development team remains critical
Billy Menger: From your experiences, what are the pros vs. cons of a big bang implementation?
Tom Rodden: That is a fun question for me. I come from 12 years of consulting prior to my 3 years now at Varian Medical Systems, and as a consultant I loved the idea of a big bang. I was less risk averse I suppose. Now back in "industry", I feel quite different and am more inclined to look at rollouts. However, for our big ECC6 / BI7 / CRM "upgrade" (actually "re-implementation"), we felt that it would take YEARS if we did a rollout, so we very carefully conducted a big bang (dinosaur) project!
As for pros and cons, to answer your question more directly, I think that the big pr
o is simplicity of delivery (hence why as a consultant I would like it). We just planned one cutover, one series of data conversions, one (massive) wave of training, and then we were switching off legacy systems and into support.
When I did rollouts as a consultant, it got quite messy -- for example, handling intercompany transactions between a part of the business still on legacy apps (or the old version of SAP) and the part of the business on the new SAP system. The other big attraction of big bang is time to benefit: we get the full benefits of the implementation and we get it faster. The con, of course, is risk. You are betting the farm when you go big bang.
Graceanne Bowe: You mentioned that IT is becoming more of a strategic partner to business areas such as sales, supply chain, etc. How have folks from the business side responded to this change? How has it impacted them?
Tom Rodden: This is a key change for the company that is in process. The business is changing along with IT. Yesterday I was in a meeting where the BUSINESS was asking me if I agreed that they should hire a Director-level person to play the role of coordinator of projects working with an IT counterpart. They see so much value in the development of our systems that they want more control of the project portfolio, more discipline in the way it is built (project identification), prioritized, quantified (business benefits and project costs translated into ROIs), etc. Naturally, I am very supportive!
Dave Hannon: Did you do any benchmarking before deciding how to proceed with this project? If so, any tips on that for other IT orgs?
Tom Rodden: Benchmarking is a great idea but usually tough to do or at least tough to find the time to d
o. We did our benchmarking for our big "re-implementation" halfway through the project. That was not ideal and in some cases you would have trouble getting the project launched without a justification that started with benchmarking current performance and then quantifying the future expected performance and benefits. We worked with Deloitte, who was our partner on the big project and they had a methodology for the benchmarking. I think that is a key. If you don't know how to do the benchmarking, they enlist some support. Usually you can get that for free from consulting implementation partners who are hungry for business.
Did I answer your question? If you are looking for "tips" I would say that the benchmarking should be based on two things: any changes you will make in the infrastructure/architecture that will affect cost or performance and the changes that you will make in business process. I like the idea of rally hammering on the latter, because that is where you will get the business to recognize and sign up for the benefits (which ultimately they have to deliver by using the system). This means however that you have to have a pretty good idea of the "design" of the new business processes. So, having a Project Prep phase that includes a high-level design and benchmarking/business case deliverable is ideal.
Dave Hannon: That's great advice. Thanks Tom.
Jacquelyn Howard: The article describes the benefits on this initiative to your organization, but what was the greatest benefit to your IT team? Thanks!
Tom Rodden: The biggest benefit to the Varian apps team that I manage was an increase in our ability to deliver projects on time and on budget. We just have more throughput on changes that improve the business.
to this, the change in strategy requires that the internal apps team be up to date on the apps we support--we are expected to be the "leaders", more knowledgeable than our third-party support team and knowledgeable enough to only have minimal needs for consulting support on our projects. That means people need to get trained and attend conferences, etc.
So, for us, that is not a "nice to do" distraction, but a "need to do." Of course, we still have the problem of balancing the work with the training, but we look at the training as more impact I think than many other organizations.
Jacquelyn Howard: Thanks, Tom! I can understand the challenges of balancing work and training -- that's great that your company values training so highly.
Lucy: Would you say that this new "IT as a business partner" outlook has had an impact on the motivation and morale of your IT team? Do you find that your IT folks are more charged up about the work they're doing? Thanks.
Tom Rodden: The simple answer is "yes", I think people like being listened to and being respected. But this is a two-edged sword--we have also raised expectations and the business is looking for guidance and for us to speak with authority. My team is compared toe the best consultants that we have had on projects and that is a high standard. Sometimes setting the expectations high can be an issue. But that is the right thing to do and most people react well. The greater risk/problem is that sometimes the pendulum swings so far in the new direction that the business expects us to have all the answers, including to their business process problems. That is a bit too high an expectation and we have to get the business to "own" their process at times.
Kristin Bent: How did you get stakeholder buy-in to make your IT team more strategic and outsource the day-to-day support? Any tips for obtaining this buy-in?
Tom Rodden: To get buy-in for our strategy to focus the in-house apps team on projects was not as hard as you might think--and we did NOT have to lay off a bunch of people to make room for the 3rd party support team. But our situation may be a little unusual or at least the attitude of the organization may be unusual. Basically, senior mgmt was on board because we were proposing a CHEAPER way to expand our capacity to deliver project work. Up until the point when we changed our strategy, the IT apps team was just not able to consistently deliver on its commitments. The team was constantly being pulled away to do support. Projects suffered delays or sometimes could not even start. The strategy was to liberate our “free” (internal) resources---"free" because these were already in our budget--and engage relatively inexpensive support resources. The alternative of engaging consultants to expand our project capacity we felt would be much more expensive than the buying the support capability.
Don Loden: Since IT’s role is now more of a strategic nature, how did you cultivate the skill sets necessary to evolve toward the new strategic challenges? Were these skills already present in your team or is this an ongoing transformation?
Tom Rodden: Don, that is a real challenge. To a degree, we fortunately had some of the necessary skills in the team already. But we had and have still gaps and work to do. What I think of as the skills needed are soft skills and project mgmt skills--the ability to facilitate meeting, tease out business proce
sses from users, nail down scope with the business, the ability to craft a good project plan, etc.. We have built this development into our annual "cascading objectives" (performance eval) process. We have called this "develop consulting skills" as shorthand for the kind of stuff I mentioned above.
Kristine: I’ve seen organizations talk of "IT transformation" but struggle with execution. You noted a couple of things that are making this a success - training, close relationships with support, and, I assume, top-down support in the business.
From your consulting and current work, do you see any big "first steps" that IT can take to overcome resistance to changing the role of the IT team?
Tom Rodden: That is a tough question and it is hard not to sound trite in responding to it since I am thinking of the same things people have heard before, at least at a high level.
Yes, top-down support is vital. I could not have gotten anywhere without the CIO's support on all this. The CIO had the support of our CFO as well. Support beyond that was not in place at the start. The transformation project (our ECC 6 re-implementation) was a very hard project but it was an opportunity for many people to see what it takes (hard work and skills) to operate as a real partner with the business and not as an "order-taker".
So, first steps might be: Make sure you have a good foundation of support for this kind of change at least among a few key business leaders. Times will get tough and you need some key people to have your back.
One other "step" is focusing on business benefit as you work with the business and asking them to really be clear about how the project or enhance
ment will help them. If they cannot articulate that, then something is wrong. If they can, document it and use that later to demonstrate to senior mgmt that the IT team is really doing what the business needs. The support will come even from the skeptics if they see that often enough...
Molly Folan: Sounds like your IT transformation project was a huge success! My question is this: Throughout the process (especially in the beginning), were there any communication challenges between business users and IT developers? And if so, how did you manage/overcome them? Thanks!
Tom Rodden: Hi, Molly. “Huge success"? Well, I think it was quite successful, but "huge"? Not sure I would go that far. But to your question about communication challenges: Yes, we had them at the beginning, in the middle and at the end -- and since the end! That is part of the skill set that I was referring to early in response to another question on the skills needed in my team to be a "strategic partner" with the business.
Communication is a critical skill. We struggled for example to explain throughout the project how we had to minimize customization in order for us to be able to upgrade later and to minimize support costs and to avoid backing ourselves into design corners, etc. Through most of the project that message was not being heard and we had to work hard to keep the customization under control. Since going live on ECC 6 enhancement pack 3, we have done the upgrade to enhancement pack 4 just a month ago and it was practically a non-event. The business is now looking at the opportunities identified in the release notes with us and we are talking about what enhancement pack 5 will bring.&
nbsp; So, people in the business are starting to "get it" in terms of minimizing customization, but the communication challenge is a long tough road.
Molly Folan: Thanks, Tom. This is a very good insight!
Scott Priest: Has your team begun working on any other technical projects following the upgrade -- other pieces of SAP (or third-party) functionality? If so, has your experience translated well to those projects?
Tom Rodden: Hey Scott, I just mentioned our work on EhP4 and we are already planning to upgrade to EhP5, so I think that addresses part of your question. We are also about to sign on with SAP for GRC 2010 as a "Validation Partner" which means we are one of just two customers worldwide to setup GRC 2010 at this point. This is a new phase of release by SAP, before "ramp up."
In terms of how our change in strategy is affecting that technical work, I think it is again helping us manage this kind of work a lot better (the PM skills are vital for these technical projects).
Molly Vaughan: Hi Tom. If you have time before you go: What was the greatest challenge you faced in changing how your organization views IT? If you had to choose one, that is. Thanks!
Tom Rodden: Molly, I can never limit myself to ONE, so here are my two greatest challenges in working with the business to recognize and also adapt to the changes IT has been making:
First, getting the business not to look at IT as an “order taker.” The relationship with the business is still not perfect and continues to evolve, but the apps team has spent a lot of time working with the business on process definition and exploring options to the point that the business in many cases will ask for our input on the business process (again, some of the softer skills). T
he apps team also has become the process expert in cases where we are rolling out functionality to new geographic locations. We know the process and the systems in these cases and are looked upon as the experts.
Second, as I mentioned already, the business understands better than it used to the impact of customization and how that can make upgrading difficult or impossible, driving “re-implementations” instead of upgrades. We still battle with requests for customization every day, but more and more people do understand and are willing to listen to how things can be done with “standard” tools.
Sarah: Thank you to all who joined us and participated in this Live Q&A, and especially to Tom Rodden for sharing his expertise and experiences with us and for all of his terrific answers.