For the past 15 to 20 years, the IT organization’s fundamental role was to be operationally efficient. It started with the reduction in portfolios brought about by ERP implementation, passed through getting control over the distributed computing environment, and ended with consolidation and virtualization.
But, for the past few years, there’s been a different mandate emerging, brought about by the mélange of public cloud services, locally-acquired devices, and departmental applications commissioned for tablets, phones, and cloud-based infrastructure being layered on top of the rationalized environment run for cost containment. This is client-centric IT, and it forces some of the roles played within IT to change.
Relationship management: For many, relationship (or client) managers have become order-takers and meeting-conveners. Client-centric relationship management is about providing guidance: raising key issues and asking hard questions, ensuring the bits and pieces make sense and integrate well, and passing on cross-business contacts (“you want to do X — group A in Vancouver’s already done that, let me connect you with them”).
Good relationship management, for instance, would advise a portion of the business that needs an application but must spend years and millions modifying a package to deal with all the real business uniqueness involved that this is one of those cases where simply building the entire application as a custom job might make sense. It would likewise advise the business that millions for mods simply to avoid making changes to the business that competitors have already made that don’t add value shouldn’t happen.
Architecture: Architects have become the “oh, God, them again” unwelcome visitors in the business in far too many organizations. Yet architects ought to be a key part of client-facing, client-centric IT.
Enterprise architects should be working with in-business business analysts early — perhaps ahead of any project — socializing the future state the enterprise is working toward and the requirements it has that have to be built in (for regulatory, compliance, or security needs). They should be talking about the financial impact on the business of various types of decisions, to help the business do a better job of figuring out its needs and wants. Likewise, they need to communicate progress to date, so that it’s not always “cake tomorrow”.
Come project time, solution architects have an obligation to recognize when something is “good enough”. If you’re intervening to create a near-perfect solution once the project is commissioned, you’ve lost the initiative already, and holding up the works at that point simply makes enemies. At that point, cut your losses, make it good enough, and let it move forward (sell instead a revision cycle to improve the solution going forward).
Help desk/client services: Today’s typical enterprise has a host of services provided outside. This function’s in the hands of a business process outsourcer, that one’s handled by another company in the group, this other one’s a mix of cloud services and in-house operation. Even 99.99 per cent up time on all the components in the mix will now add up to incident after incident. Add the mobile devices to the mix, and the typical end user — even the typical intelligent, competent IT professional — can often be looking at the screen in front of them and be puzzled why things aren’t working as expected.
No service on offer is more important these days than acting as a first port of call for all problems — and handling the problem through to completion. That means that even though a business area bought a cloud service themselves, or outfitted their staff with Android phones while the company “standard” is Blackberry, you don’t walk away from providing service.
The goal of this function is to optimize enterprise productivity by working around — or repairing — what isn’t functioning properly, not merely to front-end the bits provided by the IT organization itself.
Solutions & maintenance: Those in the traditional development areas of IT need to add a fair number of vendor-type skills to their kit bag. How quickly can you estimate alternative paths for a user? Could you stand behind your quotes if you needed to and still perform without losses? Do you know where the break points are that make a “fork lift upgrade” preferable to maintaining what you’ve got for another three years? If you don’t, these are skills you need to add.
That’s the technology side of IT. We’ll look at the information side in the next posting.
