At Cisco, we have many customers visit us at our Executive Briefing Center on a weekly basis. These one-on-one visits allows us to listen to their issues and plans.
So to précis,..
When it comes to cloud, it's clearly a struggle. Not because of the technology involved, but because the operational transformation required.This is the sticky stuff in the kit and kaboodle of change.
Which means organizational design rears it's toilsome and ambivalent honchiness.
Organizational design is the baroness hellion of human relationships.
It interrupts our walk from the parking lot to our office, and makes the entire day a Hobbsian rediscovery that without small, local Leviathans, our daily Starbucks becomes a walk through a IED-laden cublice-land.
So what to do?
Keep it copacetic. Any cloud requires at least three new actors to star: A product manager to specify the new offers, a service designer to design to the offering, it's order experience, policy management and workflow, and an automation engineer to automate the provisioning of the offering. Optionally, you may need a developer to turn this whole offering into an API (REST, SOAP, Java, Php, etc).
Which brings me to this blog post from Chuck Hollis, who by now I owe at least one martini. Enjoy
The next logical step is to dive down, and start to address the essential aspects of IT transformation: people, process and organizational models.
The organizational design activity works to define an idealized end-state after the transformation, and -- more importantly -- a logical sequence of steps and activities to move the IT organization in small, digestible increments.
Behind that is an enormous body of work around new roles, new skills, new measurement systems: basically a new "run book" for IT Human Resources.
And, of course, a plan to build and staff relatively new functions within traditional IT: e.g. go-to-market, business operations, cloud architects et. al.
If IT is to function as an internal service provider, then service design becomes an important activity: what are the processes that are used to assess service requirements, create the case, introduce the new service and assess its performance?
Again, most IT organization think in terms of delivering a specific application or project vs. creating a reusable set of services that are easy to consume and measure.
And, finally, serious design work around two key operational processes: how defined services are delivered in an orchestrated fashion, and how cost-to-serve is exposed back to the people consuming those services.
Comments