I'm not all that familiar with the details of ITIL. When I've run across it, what I have usually found is the process was stagnating the origanization.
What I would advise is flip things around, instead of laying in a large process (with all the documentation, training, ramp up, etc), start where you are and develop something from there. This falls under the loose concepts of Kaizen, start where you are, which comes from the Toyota Way.
Here is the outline I would recommend:
- Do absolutely nothing. You're new, you don't know how all these teams work today. Spend the first 90 days learning.
- Do a Gemba Walk (Google the term). It's another thing from the
Toyota Way concepts. Go to each location and observe. See how things
are running. See their challenges. Hear what they have to say.
- Do Value Steam Mapping: Identify the three most common things your
teams do or will do. Map out the timeline for getting from idea to
done. You are particularly looking for wait times, when you're
waiting on someone else and on "throwback" points where the project
can get thrown back to an earlier phase (QA, for example).
- Decide on your goals. Now you need to decide what you want your organization to be. Create goals based on these. These goals should be "Why" or "What", not "How". Enough guidance that the teams can then figure out the best way to get to those goals. Remember, goals need to be measurable, or you'll have confusion. "Is fast" is not a goal, "reduce delivery time by 50%" is a goal.
- Start. Just start. Don't create process, don't go into details. Just start.
- Inspect and Adapt. Now you start looking weekly or even daily at how things are going. Tweak things to work, document what works and move on.
You should also be prepared that different teams will end up with different "How" processes. If they are meeting the "What" goal and they've documented the working process, then that's fine.