On the CIO – CEO Gap

I read an interesting article on the gap between CIO and CEO technology priorities. Looking at the Gartner 2012 technology priorities (and using that as a proxy as what CIOs think is important) the CIO’s list revolves around Tablets, Mobile, Social, BI and Cloud. On the other hand the CEOs list is:  ERP, CRM, Specific business-line applications, E-commerce expansion, General IT modernization,  IT infrastructure improvements, Business mobility as it relates to major platforms, Business intelligence, Supply chain management and Security – interesting that process doesn’t show on either list, but I’ll leave for later.

What can I tell you?  CEO’s are right – they are essentially saying that a lot of previous technology initiatives aren’t finished yet, and they still need to maximize their value to the business. CEOs are also saying that technology isn’t interesting unless it serves a business purpose. The CEO’s list focuses on technology initiatives that actually affect the business or as I like to think about it can either optimize and streamline current business delivery (increase the bottom line) or generate new business (increase the top line). Most of the CEO’s focus is on ITs ability to increase the bottom line, not the top, which is the gist of how CEOs view CIOs – as the owner and manager of the infrastructure used to make the business machinery run – not as a partner on the business side, and certainly not as a seat of business innovation. Many CIO’s balk at being pigeonholed in this way, they would like to consider themselves full fledged partners on the business side and maybe even as a candidate for CEO.

I think that the technology lists really highlight the difference between a CEO and CIO. The CEO focuses on things like ERP which is “technology in the large” – a number of technologies applied as a large business transforming initiative. The CIO list is “technology in the small” specific technologies that have unclear impact on the business as a whole.

CIOs need to think of technology in the large – and they actually have the technical ability to translate it into the different small technologies needed to make the initiative work. CIOs need to view technology as a tool for business, not an end in itself. They shouldn’t focus on ”cloud computing” but rather the business benefits of “agility” – and then break that down into what is really needed by to enable agility (and maybe the cloud fits).

Here is my list of possible CIO technology initiatives, each has a set of related technologies – but I am sure there are many others I have left out (and hopefully others will point them out to me):

1. Process management – since IT touches almost every business process, the CIO is really the only person that could understand how the business actually runs.  By taking a process oriented view of how IT supports the business a CIO could create real value for the company.  There are quite a few process management related technologies that could be relevant, and process management should certainly be on the short list of initiatives  for any CIO that wants to be CEO. I am surprised it didn’t show up on the technology list at all – though it did on the CEO’s list through ERP, CRM, applications and supply chain management.

2. Running IT as a Business – I am always surprised about how IT is actually run - IT could be a showcase of how information technology can be used to manage business, but it usually is not (and quite often the opposite). Eat your own dogfood – need I say more?

3. Leveraging Data for Business Value - the good news is this is actually on both lists. The bad news is the IT itself doesn’t do such a good job of leveraging their own data for their own needs. Again – shouldn’t IT be a showcase of how data can help make a business run better? Shouldn’t they be doing it themselves for their own business?

4. Application agility – applications are what business cares about – not how applications are delivered. The good news is that some of the technologies on the CIO’s list could be used to target appplication agility – cloud, app orientation, mobile – but if they are viewed as separate, distinct activities they probably won’t end up having a profound impact on the business. The point here is that the technology doesn’t matter from a business perspective – but applications do. How many innovative applications that help the business has IT come up with lately?

Are BPM suites another 4GL (fourth generation programming language)

Lately I have been spending more time with various IT issues (especially around application performance management) than with business process management (BPM) or adaptive case management (ACM). What I think surprised me most is how little BPM is used by most development and IT shops for their own use. Even when a truly structured IT process is being implemented (like deploying an application into production) – the tools are never based on BPM suites. The only time I see BPM suites being used is when there is an IT management decision to take a more process oriented approach to certain business applications. In that case a BPM team is created and they implement certain processes – it never seems to leak much into the broader IT domain. It also seems to be used mostly in the context of business application built by enterprise IT departments.

So where does that leave BPM suites? - they aren’t used by most developers, and aren’t used by business people. So in many ways it resembles a 4GL (a fourth generation languag,e for anyone old enough to remember) for implementing structured business processes that don’t have a packaged application available. Just like 4GLs in their day it provides value for a nice sized niche – but still a niche.

What does that mean for the future of BPM suites?

BPM suites could try to branch out and try to encompass unstructured processes – but that would mean essentially building a different tool as Max Pucher continually points out in his blog and Neil Ward-Dutton shows in his presentations on ACM vs BPM.  This can work in a suite context (as Keith Swenson points out in his blog) and I believe that this is where many BPM suites are headed – but I doubt if they’ll make it. It is a lot more complex then just adding some “social features” to BPMS. Most vendors don’t understand that, and neither do many analysts – just take a look at how much focus Forrestor puts on the structured part of case management (and how little on the unstructured part) -  in their dynamic case management wave. As I have said before we’ll know BPM vendors have nailed it when we see knowledge workers using their BPM applications on a daily basis instead of email.

A second direction would be to provide more value to participants in the niche – or expand to the folks who can benefit from data derived from the niche (like BI capabilites). I think all BPM suites will expand in this direction – but I question whether that will be enough to keep them from going the same path as 4GL languages – essentially a niche business that never breaks out into the mainstream -either from a IT or business direction.

A third direction would be for BPM suites to embrace their 4GLness and focus providing more value to developers so that BPM suites could be used by a broader set of developers, while evolving into general purpose business application developments suites – but I don’t see any BPM vendors going in that direction.

If Agile Software Is A Cop-Out; Is BPM the Next Studio for Software Development?

Continuing my comments on Mike Gualtieri’s post on the state of software development (which seems to have hit on a real issue, based on the number and quanitity of comments it generated), Mike states that there are 4 pillars needed for a methodology for creating a new paradigm for software development:

• Parallel. Development teams must have the confidence and insight to do parallel streams of development.
• Immersive. Software is a means to an end. That end is to deliver applications that exhibit the seven qualities of great software: user experience, availability, performance, scalability, adaptability, security, and economy.
• Software. That’s what we develop. That’s what we deliver. However, the future software development is experience.
• Studio. Software development is not pure coding, engineering, architecture, management, or design. It is cross-disciplinary. Better yet, it is its own discipline.

These are all good, important points but they ignore the business perspective! I have been a user experience advocate forever – since being the user experience advocate for IBM Research in the late 90s. User experience is a critical perspective for developers to understand, and critical for the success of any software. But I have learned it isn’t enough – software development needs to take into account two more critical business aspects:

• Business Value. Software must deliver business value, and that isn’t always completely aligned with user experience or any of the immersive points Mike lists. A application can have a great user experience but bring no value to the business, which means it will either be killed or die from lack of attention. In most cases business value needs to come first, and foremost.
• Platform. Software (even what ends up as applications software) is either a platform itself, or built on (and used to enrich) a platform. This is both a business and technical decision, and can greatly affect the long term success of any software. See a great rant on the subject here.

So how do BPM platforms stack up as supporting the pillars of software development?  Theoretically they stack up pretty well.

• Parallel – the modeling process is a bottleneck, but once completed things can be implemented in parallel
• Immersive - the BPM and its model driven development platform should make it much easier to obtain the immersive aspects too.
• Software – most BPM platforms put no focus on user experience. I have written about this before, but it a real failing of most BPM suites.
• Studio – certainly BPM suites are built to support multi-disciplinary teams (though with great differences in the level of support for different audiences)
• Business value – BPM suites should get high ratings here – since the theory is that the is driven by “the business”
• Platform – A BPMS is by definition a platform, and theoretically every application built on the BPMS could enhance it

The problem is the distance between theory and practice. Most BPM suites try too hard to make themselves of value to the business side, and miss a lot of what is needed on the high-end development side. I really don’t know of any BPM suite that focuses solely on developers and their needs, or positions itself as a better development environment for business applications. BPM suites are sort of a camel, while developers are looking for a better horse. So BPM suites could be part of the answer for the problems in software development, but in practice they aren’t.

Aren’t Software Developers the Archetype Knowledge Worker?

I haven’t been posting much on case management lately, and have been focusing on other topics. One post I read the other day about software development really got me thinking about unstructured processes again – I thank Mike Gualtieri for his great post on “Agile Software Is A Cop-Out, Here’s What’s Next“.

Mike makes an interesting point about agile software development methodologies. Whenever I hear about agile methodologies I get confused – since top software developers and designers always used agile as part of their bag of tricks – just never codified it to death. That is what I see as the main failing of agile it started as a way to spread knowledge aen experience, but is now trying to morph into a standardized methodology. It took various apparent truths about software development and then tried to build a set of “rigorous” processes around them. The problem is that “agile as process” took on a life of its own and lost the original purpose. From my perspective that is why a manifesto works much better than a methodology/process – but once a manifesto is hijacked by consultants and vendors – they immediately make it a “process”. I actually think that is what is happening in the case management\bpm debate too – what needs to remain as a flexible methodology supported by tools, is slowly being killed so that it can be standardized.

What I don’t get is that software development is a shining example of what people in the process community call knowledge work. As far as I can tell, a lot of the latest thinking around managing knowledge work is being done by the business process and case management communities. Even though most of the people talking about tools for BPM and case management are software developers themselves – the tools and methodologies advocated by BPM\Case management are not being adopted by the software development and operations community themselves. I see this as vendors not eating their own dog-food (or maybe not drinking their own Kool-Aid) and I have been posting about it for a while – see my last post on this and Scott’s great rebuttal here.

So from my perspective a lot of the thinking around knowledge work is for techies and analysts talking about “other people’s knowledge work”, not for the work they themselves do. I don’t understand the wide gulf between knowledge work as it is done by software developers, consultants and analysts – or any other “specialty” knowledge work,  and the work done by “standard” business process knowledge professionals and executives (who seem to called case workers by the community?) -

1. All software development in commercial enterprise is being done in service of a business process – therefore all software development should also be considered part of business process management. It is a sub-process of the overall business “aha to ka-ching” process – from an idea to increase\enhance business to the implementation and deployment of that idea through software.

2. Software developers are knowledge workers. Their macro processes are the same as those for any knowledge worker. Like any knowledge worker they also use specialty tools,  tailored for their specific domain. Therefore a BPM tool that isn’t used to support software development as a process (e.g. Waterfall and ITIL, or Agile and Iterative methodologies) while connecting to domain specific tooling is a cop out, a way for vendors to say “use this tool for all other knowledge processes, but of course I won’t use it for mine”.

3. Analysts and consultants are knowledge workers- if they aren’t using a tool for managing their own knowledge work, then they too suffer from the ”all knowledge work except mine” syndrome. If all they use are standard productivity tools for their work (e.g. email, wikis, blogs, twitter, word processing, spreadsheets and presentations) – then I would ask them what is keeping them and their organizations from adopting the tools they say your organization should adopt.

The 10 Commandments of Enterprise Startups

There was an interesting article on enterprise startups in CIO.com – Enterprise Startups: A Long Road Ahead. I started my career at IBM, but have been doing startups for a while now – and by far most have been enterprise software startups (Actionbase, ConicIT, Correlsense, Itemfield). eXeedTechnology and Dapper were the only “non-enterprise” software startups of the bunch. What was said by the jury in the article (or at least what how I read it) really resonated with me, and the experience I have with enterprise software startups. I think services based enterprise startups are probably different, but I don’t have much first hand experience with them – so this only for software. Here is my list of ten things an enterprise software needs to pay attention to early on:

1. An enterprise software startup needs a REALLY compelling value proposition for anyone in the enterprise to even consider them.
• That means you are addressing a KNOWN pain point that hasn’t been addressed before
• or are drastically lowering the cost of doing things already being done
2. Unless you provide direct value to the business user (in other words, value that they can see for themselves or their direct reports) you’ll be talking to IT.
• Even if you provide direct value to business user, unless you can deliver COMPLETELY over the web, you’ll still be talking to IT.
3. If you are talking to IT – you need for them to understand what is in it for them, not just for the business users.
4. Points 2 and 3 mean only people that directly benefit from your product will be willing to pay for it – a really important lesson.
5. Channel sales work only if you are replacing a known functionality. If you are doing something new, channels just don’t work. Later, when you have identified the customer, established the need and method of selling you can start using channels.
6. Direct selling to enterprises is expensive – really expensive. I believe that is the real reason enterprise software is so expensive – multiple proof of concepts, mutiple stakeholders that keep changing along with the requirements, integration with legacy systems and exitsing work processes – all make for a long, expensive process. If you aren’t selling a product that costs 6-7 figures, you just can’t  afford it.
7. The big vendors really have a lock on enterprise customers, and have really good, well-oiled sales\marketing machines. They may not have the best products, or even the right products – but even today no one gets fired for buying IBM – and IBM (or any of the other large enterprise software vendors) is really good at selling at all levels.
8. If you have a tactical product (solving a relatively low level business problem), you’ll have trouble getting people’s attention, if you are selling a strategic product the large vendors will generate so much static that it will be hard to get a message across.
9. The platform you build on matters – everything else being equal I would choose Linux, Java with a Browser UI (maybe MS if I had to, but only for the UI). This works in almost any enterprise (of course the exact version of each could be a problem too). On the sophisticated UI side, I worry a bit about Flash, but HTML5  still isn’t widely adopted – so if possible I would try and use neither. If push came to shove, I would probably opt for HTML5.
10. Analysts play an important role – if you are doing something that is already on their radar, make sure they know about you (and like you). If what you are doing isn’t on their radar – the best thing you can do is convince them that it is the next big thing.

Invention, Innovation and Knowledge Work

I heard a corporate presentation yesterday about innovation – I won’t mention the context, but suffice it to say it was the standard stuff that you hear from many corporations about the need to innovate or die – and then find out the group tasked with innovation isn’t even the size of a small startup – and reports somewhere deep in the bowels of the company.

But it did get me thinking abou the difference between invention and innovation. Putting it glibly -

Invention – From nothing to Aha!

Innovation – From Aha to Ka-Ching!

It used to be that you needed invention before you could do innovation. Get the basic science right – and then figure how to leverage that into products that people want. In social software, I think what we are seeing is that the innovation (actual products being used in the field) is the invention – though many of better social software systems heed well know truths about organization and social interactions. The reason this works is that the internet makes it cheap and easy to try out and iterate on new ways for people to collaborate – testing a hypothesis on real users. There is also enough funding available (through venture capital) to do this on a large scale. Back when I was at IBM research we used call this “research in the marketplace”.

This doesn’t hold in the corporate environment – which is why it is lagging and we don’t see knowledge worker productivity products with the blowout success of a Facebook or a Twitter. Not that I don’t think Facebook-like or Twitter-like product won’t be valuable in the enterprise – it is that they won’t make a significant difference to overall knowledge worker productivity.

The problem is that an eco-system isn’t there to easily try new way of increasing productivity for knowledge workers and there no real VC support. An organization will only adopt tools that have been proven to work. So how do we get around that “chicken and egg” problem? How can we increase “research in the marketplace” for the enterprise market to increase the productivity of knowledge workers?

Knowledge Work: Conversations, Publishing and Search

I happen to stumble up on an interesting blog by JP Rangaswami, the chief scientist of  salesforce.com - what caught my eye wasn’t a specific post, but rather the claim that there are only 4 application archetypes needed  in any enterprise:

• publishing,
• search,
• fulfilment and
• conversation

I tend to agree with JP Rangaswami and claim that for knowledge work all you need is: publishing (the creation and management of documents and content), conversation (sometimes structured conversations with systems or between people based on regulations, sometimes unstrutured conversations between people) and search (a way to link the two and use context to find information within that content and those conversations).

That leads me to Keith Swenson’s post on “Self-Organizing Business Networks“  where he listed three critical features of enterprise social software:

• self forming relationships,
• everything is relative, and
• bring your own identity

which I think are a good list of basic features needed for social software, but there seemed to be an implicit assumption that social software isn’t just a nice to have, but rather solves a pressing need. I actually think that assumption is main barrier to the wide scale adoption of enterprise social software.

What companies really need is a way to increase the productivity of knowledge workers. Social software (at least at it stands for the most part today) is focused on facilitating conversation – but it seems more for conversation participants than for the organization as a whole, which means that is only a part of what is needed for wideapread adoption.  The benefit to the organization as a whole isn’t completely clear. It also isn’t clear that social software will actually improve productivity - management is worried that it will just give people another way to “goof off”. It is very difficult to provide value to A, but then try and charge B. B needs to know explicitly what is in it for them - in this case B is the organization.

For social software in the enterprise  to really take off it will need to expand to provide value to conversations both from the personal and enterprise perspective, link conversatons and publishing (and make those conversations available to the enterprise), and enable searching (but not just as a standard search on unstructured data, but rather as a context aware search on the information that relates conversations and content).

TIBCO acquires Nimbus Partner

I really don’t know anything about the acquisition, but it gives me the opportunity to talk about the problems of selling business tools for unstructured (unpredictable?) processes. We were different than Nimbus in that we focused on unstructured process execution, while they focused on process design – but I think some of the lessons we learned hold true.

The main driver for enterprise adoption of process management technologies is the BPMS (Business Process Management Suites) ecosystem (vendors and analysts). BPMS are purchased, owned and used by IT. IT buys a BPMS to build various processes used by the business – but in the end the business sees only the resulting applications and for the most part don’t know or care how they were built. The business may have been involved in some design or brainstorming sessions when the application was being designed – but that usually was long ago and far away from their perspective. The business sees it is as an IT project to automate a process and IT got input from the business. Then sometime much later the business received an application that was supposed to be the new way to execute the process.

This works because IT is convinced that a BPMS allows them to automate business processes faster than doing it using standard programming. The BPMS model works because it took an existing paradigm (IT building applications for the business) – and enhanced it. A BPMS provides a good IT methodology\process for creating business applications (though as I always complain – a BPMS is not the mechanism used to manage the development process – you would think that the dogs should eat the dog food), and the resulting application should be available faster, better documented, more modular and more reusable than if it was done from scratch.

On the other hand, if you have a BPM tool that targets the business, rather than IT – your life will be very hard. If the tool tries to empower the business user and get IT out of the equation – IT certainly aren’t going to press for budget to buy it. On the business side the benefit is at the level of a process owner, or a project owner. So they need to find the budget for it. That means that you need to reach those folks, convince each one to use your tool. After that you probably need to also provide them with some level of training – since there are no real standards that can be leveraged (and don’t day BPMN – that isn’t a business tool). Oh, and you might have to involve IT too – since it is a technical tool. So you have all the pain of an enterprise sale, but without the ability to charge enterprise prices.

So what does this mean? Well first of all it means that the best way to get unstructured process management tools to market are in conjunction with a structured process tool. Almost every real world process is a combination of the two, and being able to sell a solution that spans both is a way to start getting the tool into the market. The structured tool will drag the unstructured tool. I believe that the sale will still be to IT – but it enlarges their arsenal to answer business concerns over “structured” BPMS. Over time you could imagine that things could work the other way (unstructured drags structured), but we are a long way from there.

Another thing we learned is that you can’t sell through partners – since this type of sale to a business user requires a certain amount of evangelism and business knowledge – you need to do it yourself. TIBCO will need to learn how to leverage (and when to bring in) the Nimbus team for a sale – TIBCO won’t be able to sell a joint tool without them.

Integrating a Startup after Acquisition

I have been through a number of M&As – on both sides of the fence. I thought it could be useful for me to share what I have learned about making an acquisition work. First of all – let me make it clear, integration after an acquisition, even when handled perfectly, is hard (and it is never handled perfectly). Second, distance makes a difference. Unless the companies are located walking distance (or a short drive) from each other – the distance (both physical and cultural) will be a real obstacle. Let me start with some rules for the acquirer:

The trouble starts with the whole mechanism of the deal – everyone is focused on closing the deal – no one is thinking about what happens the day after. This leads me to rule 1 – make sure that someone is thinking about the day after. There should be one person from each side, but at least one senior person on the acquiring side. Give that person both responsibility and power. Make sure they have clout in your organization, know how to get things done – and have exceptional people skills. Actually people skills are the most important attribute.

Rule 2, 3, 4 – Communicate. Communicate. Communicate. You can never communicate enough. The startup is far away, and has a unique culture. Because of the distance you can’t have impromptu meetings in the hallway, lunchroom or at the coffee machine. You need to keep people informed, and if the Brits and American are two people divided by a common language – just imagine when there is no common language. Even if the two management teams both speak english, if it is a foreign company you can assume they don’t always understand the nuances of american english – especially in a corporate environment. Constant communication is the only way to keep a misunderstanding from festering into a full-blown crisis.

Rule 5 – Pretend you are a doctor and have taken the Hippocratic oath – first do no harm. Don’t change anything until you have learned the landscape of the new company. I know successful US executives have a penchant for action – but this is a case where early action can be disastrous. Understand that it will probably take a year until the company is more or less integrated. Maybe I should have put this rule first.

Rule 6 – Get help. Try to find someone that has some experience in these types of mergers and get them to help. It will keep you from having to learn only from your own mistakes.

Rule 7 – visit early, visit often. Make sure that the new company gets to know you and your team. Make sure that you get to know them.

Rule 8 – remember that the company acquired is different than your own, with their own unique culture. That is probably one of the reasons you acquired them – figure how to work within that culture without breaking things too badly.

Rules 9, 10 – Make sure you remember why you did the transaction. Sometimes in the grind of the day-to-day and with executives switching in and out of roles – the actual strategic reasons for the acquisition are lost. Make sure you keep that knowledge alive, and use it to help with the day-to-day decisions.

Now for the startup side of the acquisition. First understand that even if the company acquiring you has done this before – it was probably by a different group of people. It may have even been in a different country. Cut them some slack – they probably mean well, but they are learning too. Don’t assume that they can tell you what to do (or that they know), they are looking as much for input from you as you are from them.

Make sure you know how things are decided in your new company, and how to influence decisions. Delegate roles and responsibilities among yourselves so that you can have different routes of communication back to HQ. Go visit them at HQ and be on the lookout to see who has real influence and power. Assume that things will be hard in the beginning, but there are real benefits to being part of a larger  corporation – budgets are larger, career opportunities are greater and you can make a big difference. Find some advocates for you at HQ, or send some.

Finally – and most important – make sure there is a headquarters SPOC (Single Point of Contact) for any decision concerning the remote location – for any decision that comes out of HQ that is not day-to-day business as usual. Someone who cares about the over health and well-being of the lab, even for things that don’t directly effect them, or their department. This is especially true if the remote location consists of a conglomeration of smallish groups reporting to different HQ functions. Otherwise, the different HQ departments will try to optimize things for their own group – but these local optimizations can a have a huge impact on the overall health of the lab – which won’t be noticed until it is too late (unless their is a SPOC).

For example, two HQ departments  could decide to streamline their organizations and remove some positions – for example each decides to remove one person in the remote location.  Even though each decision on its own makes sense – taken together it could have a very negative effect on the remote location – lowering moral and motivation. Cleaning up the fallout could take months….

So make sure you have a SPOC. Live long and prosper!

Does Process Matter?

There was an interesting discussion on ebizQ around the question “What does enterprise tech have to learn from Steve Jobs’ success?” What made it even more interesting for me is that even though the question was asked of the process community, not one person answered “better process management” and certainly not “leveraging a BPMS”. So does that mean that even the process community doesn’t see any way to link outsize success to better process management? – or is this just a quirk related to Apple?

If the same question would have been raised 60 or so years ago about the great manufacturing companies like GM – I’ll  bet we would have heard a lot more process related answers. Those companies really became succesful because of better processes. But today, when process professionals were asked about what made Apple great – the answer revolved around design, user experience, customer understanding and innovation.

It is clear that companies need to manage processes well, but that isn’t what makes a company great. I am sure Apple had some really good processes, but today those are table stakes. The real battlefield is in the realm of knowledge workers – design, user experience, innovation, customer understanding - and most of today’s process thinking and tools don’t help much there.  That is why I don’t think ignoring process as a success factor is a quirk related to Apple, it reflects what is really important for a company to be succesful in today’s world. Process won’t make your company great – design, user experience, customer understanding and innovation will.