Marketing IT like a business

For many years, companies have been encouraging their CIOs to "manage IT like a business." By this, they usually mean that the CIO should exercise financial discipline, focusing on the bottom line in terms of costs and benefits of technology, not just on the technology itself. This, of course, is all well and good.

But running a business involves more than just financial management. If we really want to run IT like a business, we need a whole set of business functions and disciplines that we normally do not think of as part of IT.

For example, one of the most important factors in business success is marketing. Few companies can grow and prosper without a well-developed marketing function. Yet, how many IT departments really invest in "marketing" to their customers, their users? Too many IT groups seem to have the attitude of, "if we build it, they will come." Then they wonder why the sales force doesn't use the CRM system, material planners don't use the supply chain management system, or executives don't use the executive information system. These may be excellent systems that meet all the requirements of the business, but the problem is often that they have not been sufficiently marketed.

So, what do we mean by marketing IT like a business?

For sake of this discussion, let's consider marketing as three main activities: understanding the market's needs, developing products to meet those needs, and communicating with the market to stimulate demand for sales of those products. There are many other activities that could be mentioned, such as defining the market, choosing a market position, formulating a market strategy, and so forth, but for the sake of this discussion, let's keep it simple.

Understanding market needs and developing solutions
Many IT professionals think they understand the needs of their users. They interview users, gather requirements, and get sign-off on requirements documentation. But do they really understand the user?

One of the problems is proximity. Many IT groups are located far from the users they serve. They've never done the user's job, and they do not interact with users on an on-going basis. When it comes time to develop a new system, they hop on a plane, interview some users, and develop a requirements specification. But they do not have the background, or the time, to really understand the user's business.

I recall an early experience in my career as a systems analyst in an oil services firm. One day, I was tasked with developing the requirements specification for a system to track the performance of our company's products in the field. Even though, coincidentally, I had a degree in geology, I was not confident that I really understood the business. So, I signed up for a week-long boot camp for new sales people. It took quite a bit of effort to explain to my IT director why I was taking a week out of the office to attend training on various down-hole drilling techniques. Eventually, I moved out of the IT department and physically planted myself in the primary user department for whom we were developing the new system. At the time, I would have called these efforts requirements gathering. Today, I would simply call them understanding my market.

As a best practice, IT business analysts should be physically located in the departments or business units that they serve. They can still report up to IT, but they should be physically close to their users and even have a dotted line relationship to user management. They should shadow users in their daily activities and even perform some of those activities on a trial basis from time to time. The analysts that support the sales force should ride along on some sales calls, or they should help develop a sales quote. The analysts that support engineering should sit in on some product design sessions or new product introduction meetings. Business analysts should identify closely with their users and become advocates for those users within IT. Only then will IT really understand the needs of those users and be able to develop systems to meet those needs.

Marcom for IT
In business, the marketing function is responsible for planning and executing marketing campaigns with two related objectives: creating general awareness of the company and its products and generating leads for sales of those products. Market groups use general advertising, tradeshows, public speaking, press and analyst relations, direct mail, email marketing, and other forms of communication to accomplish these objectives.

Likewise, a well-managed IT organization should use a variety of means to market its services to its user community. Developing good systems is only half of the job. For systems to be actually adopted and used, they need to be advertised and regularly promoted to users.

Two clients of mine illustrate this point. The first, which I have written about previously, had spent quite a bit of money--too much in fact--to develop a B2B e-commerce site. Users had told me of their frustration with the system, but when I got an actual demo of the site, I was surprised to find that the IT group had recently introduced some enhancements that could offer real value to the organization. Circling back to the users, I found that few realized the good work that the IT project team had recently done to improve the system.

Here's the point: when I told the CIO that he needed to put a little more effort into public relations, his reply was that he didn't feel it was his job to blow his own horn. I pointed out that it wasn't a matter of praise or blame but ensuring that the company actually used the system that it had paid for.

Advertising IT to users
The second company, which I visited recently, is a positive example of marketing IT like a business. We are starting an IT strategy project with this client, so I asked to see any documentation they had on their existing systems. They handed me a 25 page document, just now being published, called the "IT Catalog."

The IT catalog looks just like a typical product catalog, describing a company's products. Only in this case, the audience is the IT user community throughout the world, and the products are the systems that the IT group offers to those users. Each page describes a company system, with editorial copy, crisp graphics, and screen shots, that outline the features and benefits of that system. Each page includes a picture of the system's primary IT analyst with contact details for more information.

This catalog will be soon distributed to all of the company's employees and will be given to new employees as they join. The same information will be posted to the firm's intranet. Essentially, it is an advertising campaign to build user awareness of the firm's IT systems and to promote adoption.

When a CIO understands the need to market IT like a business, all sorts of marketing communication methods become apparent. For example, the IT group might create a newsletter or contribute articles to the corporate newsletter. It might use email to distribute tips and techniques for certain systems, allowing users to opt-out if they found the information not useful. It might conduct periodic surveys to give users the provide feedback concerning use or non-use of various systems.

No more IT monopoly
The need is increasing for CIOs to market IT like a business because users are not the captive audience that they used to be. If the IT group is not satisfying the needs of its users, users can often go elsewhere to get what they need. For needs that do not require a great deal of integration across the enterprise, users can and do buy their own departmental systems, or they can sign up for a hosted solution on-demand, such as Salesforce.com, or they can hire their own consultants and develop their own departmental systems. Entire user departments and even whole business units can escape the orbit of the corporate information systems function in this way.

But some IT groups act as if they have a monopoly on IT services. When you are a monopoly, how much effort do you need to put into marketing? For example, prior to the break up of the Bell system, AT&T had a monopoly on telephone service in the U.S., and consequently it didn't even have a corporate marketing department. But after the AT&T divestiture, AT&T as well as the Baby Bells suddenly found that they needed to develop a whole set of marketing skills that they previously had not required.

In the same way, IT departments can no longer count on a monopoly position to keep users as customers. They must develop a true marketing function within IT. For smaller organizations, this job might fall directly on the shoulders of the CIO or his direct reports. For larger organizations, it might make sense to have one or more IT managers dedicated to marketing.

Either way, the job needs to get done.

Related posts
Putting a little public relations into IT

What is SSA's strategy in Epiphany bid?

Earlier this month, SSA Global announced that it is acquiring Epiphany, a $75 million CRM vendor. Epiphany was a big name during the dot-com era, when its CRM analytics were (and still are) an important part of e-commerce business development. Epiphany's products have been widely implemented among companies that have large numbers of direct customers, such as wireless carriers, financial services firms, and utilities. Epiphany boasts customers such as Nestle, The Gap, Citibank and Microsoft Corp.

SSA is paying $329 million for Epiphany, which had revenues of about $75 million and a loss of $16 million in the last 12 months. In fact, Epiphany has not ever shown a profit in any fiscal year since it went public in 1999. Furthermore, through its acquisition of Baan, SSA already has considerable CRM functionality.

So, why does SSA want Epiphany?
I listened to SSA's conference call regarding the acquisition, and SSA indicated that it plans to blend Epiphany's product into SSA's CRM suite. SSA claims that 20% of Epiphany's customers are already customers of SSA, so there are already synergies.

Furthermore, SSA claims there is actually very little overlap of Epiphany's CRM offerings and those that it acquired from Baan. Epiphany brings functionality for marketing automation and analytics, sales force automation, and online sales e-commerce, whereas SSA with its Baan product line has strong functionality for order management, field service, and sales order configuration. So, in fact, the two product offerings are complementary.

All this makes sense from the sales side.

Buying the Developers
But I think the key motivation is on the development side. SSA made a big point in the conference call and its press release about Epiphany's J2EE technology and component based architecture, that it was quite close to SSA's own technical direction. But that's the big difference. Epiphany's technology is already incorporated in its products. SSA's technology is just a statement of direction. SSA's products will need much retooling to conform to the vision of a service oriented architecture, and its going to need developers experienced in these technologies.

By buying Epiphany, SSA acquires a development organization that is already at the place where SSA wants to be. With demand for leading edge software developers increasing, the job market is tightening. SSA may have just satisfied a big part of its staffing need with this acquisition.

CRM Party with a No-Host Bar
The CRM market has been picking up this year, so SSA's timing might be perfect. But interestingly, with these sudden riches of CRM functionality, SSA still does not have an offering in the hottest corner of the CRM market: software on-demand. During the call, SSA said it has not considered the acquisition of a hosted CRM vendor. In fact, management indicated that they still see more opportunities for "on-premise" software--in other words, the old software licensing model.

SSA is swimming against the tide here. Although SSA points out that it does offer some hosted solutions, particularly in transportation management, it is highly organized around and committed to the traditional license sales model. There's something to be said for staking out a position and sticking to it. I'm just wondering whether SSA is on the wrong side on this one.

Related posts
SSA's IPO comes up short
SSA grows, but don't get no respect
SSA's strategy: acquire customers and technology on the cheap
Software on demand: attacking the cost structure of business systems

IBM and Oracle: strange bedfellows

Josh Greenbaum, writing for Datamation, has great insight into Oracle's budding relationship with IBM. Bitter foes on the database side, they now find themselves locked in a strategic partnership through Oracle's acquisitions of PeopleSoft (including J.D. Edwards), Retek, ProfitLogic, and most recently I-Flex, vendors that all had and still have deep relationships with IBM.

Josh also points out that Oracle's newfound relationship with IBM--whether intended or unintended by Oracle--has the side effect of undermining SAP's relationship with IBM.

The growing IBM factor isn't just interesting for what it means to Oracle, it also has tremendous repercussions for SAP. This “friend or foe” relationship with SAP has been going on for some time. In the run-up to SAP’s major partnership announcements this past spring, there was a lot of question about how close SAP and IBM could get. The result was SAP’s swooning embrace of IBM – and other new partners like HP, Cisco, and Microsoft – all designed in part to help isolate Oracle in the market. Ironically, Oracle’s unplanned bonus for its acquisitions may have been to trump the IBM part of SAP’s isolation strategy. Touché, Larry.

Whether Oracle had all this in mind when it first launched its bid for PeopleSoft is hard to say, but it certainly makes Larry Ellison look very foresightful. Personally, I don't think Oracle saw these developments. In statements by Oracle tri-president Charles Phillips immediately following the acquisition of PeopleSoft, he sounded wary of PeopleSoft's partnership with IBM. A few weeks later he spoke of maintaining relationships with IBM "as much as possible," as if he thought there might be problems on IBM's side in working with Oracle.

But, as Josh points out, an Oracle relationship really is in IBM's best interest. What IBM gets from its Global Services business in terms of its Oracle relationship is huge. It can still compete with Oracle in terms of Websphere and database sales. But services is the real money maker for IBM and it's not worth letting competition on the products side get in the way of making money on the services side.

Related posts
IBM: friend or foe to SAP?
IBM is a loser in Oracle/PeopleSoft deal
Oracle moves into core banking applications
Bidding war: Oracle fighting SAP over Retek
Oracle beefs up retail offerings with ProfitLogic bid
Brawl continues between Oracle and SAP

SAP: hosted CRM but not on-demand

It looks like SAP is going ahead with its on-demand CRM service, although it appears to be having some trouble describing it. In a Computerworld interview, SAP spokesman Iris Eidling said that the new service would combine elements of the "hosted" and "on-demand" model. I found this puzzling, since I don't think many observers make a difference between those two terms. There are different types of on-demand models, but they are all "hosted," in my opinion.

SAP is not particularly helpful in its clarification.

Eidling could not explain how the hosted and on-demand models would be combined, saying only that features of both would be a part of the new model. "What I can say today is that we will not call the new service 'on demand,'" she said.

SAP defines a hosted service as one in which customers outsource their hardware but purchase a license from the software vendor. An on-demand service, on the other hand, is one in which users outsource both the hardware and the software and which allows them to pay for applications on a usage basis.

"The problem with a pure on-demand model is that customers, who are sharing both their hardware and software with hundreds of other companies, can't easily customize and integrate applications into their systems," Eidling said. "By comparison, a hosted service allows them to make individual configurations."

Ah, so in SAP's view, the difference between "hosted" and "on-demand" is a matter of how the customer pays for the service. The fact that SAP expresses no interest in the on-demand model, which it defines as allowing users to pay on a usage basis, reinforces my opinion that it is very difficult for traditional software vendors to adopt this model. Customers may like the pay-as-you-go model, but it represents too great a change for traditional software vendors, such as SAP. By deferring revenue over the entire period of the customer relationship, it would entail a huge financial hit for such vendors--something that few, if any of them, could tolerate.

These comments strengthen my view that real innovations in software on-demand will continue to come from new entrants to the market, such as Salesforce.com.

Related posts
Software on demand: attacking the cost structure of business systems
SAP set to launch CRM on-demand
SAP denies plan for CRM on demand
Salesforce.com struggling at Cisco

Corporate takeovers triggered by IT non-compliance?

The always provocative Bob Cringley has an article this week, entitled "The New Robber Barrons: IT has become a competitive weapon for business," in which he predicts that corporate raiders will start to use the raft of new regulations on business--specifically those regulations that have heavy IT implications--to take over weaker competitors.

Cringley singles out the Sarbanes-Oxley Act (SOX or Sarbox), HIPAA, the Gramm-Leach-Bliley Act (GLBA), and the Family Educational Rights and Privacy Act (FERPA) in particular as regulations that corporate raiders could use as a tool to force companies into an acquisition.

Here's an example of how it will work. Imagine your bank is a medium-sized publicly traded bank headquartered in the U.S. midwest with a national charter (that is, regulated by federal, rather than state, banking authorities). Now imagine your bank is not in compliance with Section 404 of Sarbanes Oxley....If the bank isn't Section 404 compliant, which means they haven't applied sufficient internal controls to data, the auditors will report that.

Now what?

Well, if your bank isn't in compliance (many won't be), they'll have to very quickly get in compliance. They'll also have to pay a fine and perhaps one or more officers of the bank will do some time in prison. Really.

But there is a funny thing about banks, and that's the way they are regulated and controlled, which makes possible a very different outcome in the case of a Section 404 violation. Technically, the bank can't even continue to operate, because the legal definition of a bank is as a compliant organization. So a very real possibility is that your bank will be forced to merge with another bank that IS in compliance.

That's the new scam. Big banks with sophisticated IT operations are going to appear at the doors of smaller, less sophisticated, banks literally demanding the keys. They'll take over the building, the tellers, and of course the deposits for a price tag that may well be zero.

The trend is not limited to banks, according to Cringley. The same tactics could be used to gain control of any U.S. public company, and even educational institutions that receive federal money (i.e. virtually all of them).

Cringley predicts the winners and losers from a technology perspective:

What this means for the IT profession is a rapid appreciation in the value of a Security CCIE (Cisco Certified Internetwork Expert) especially if that CCIE comes with a Federal security clearance. There are presently only 494 Security CCIEs. It means a boost for IBM and Oracle, and a kick in the head for Microsoft and Great Plains. It is good for datacom companies and bad for telecom companies. And it is the best time ever to be a Big 4 accountant.

Read the whole thing on Cringley's website.

Related posts
SOX insanity takes hold in the IT department
Sarbanes-Oxley: stop the insanity
Making SOX compliance a meaningful exercise
Oracle moves into core banking applications

ITIL anyone?

We're running another poll over at Computer Economics. This one is,

Has your IT organization adopted
ITIL best practices
in at least one discipline?
The poll is on the Computer Economics homepage, in the right hand column. It will take you about five seconds. The nice part is, you can take the poll, even if you don't know what ITIL is!

Seriously though, check out this link if you want to know what is ITIL. It will tell you everything you'll want to know...and more.

SOX insanity takes hold in the IT department

I've gotten quite a bit of feedback on my post last week, "Sarbanes-Oxley: Stop the Insanity." Everyone has a story.

Here's one from a reader whose company shall remain unnamed, and I've disguised some significant details in the interest of confidentiality.

Frank, here is a stupidity that I am personally acquainted with at [major Fortune 500 Company.] Prior to the implementation of our current SOX project, we had some software mods implemented in our [well-known ERP system.]. Embedded way down in one of the frames, one of the programmers had misspelled the word "Inventory" as "Invetory".

One would think this a fairly simple fix for a programmer, but no. Now that we have implemented internal controls for Sarbanes-Oxley, we had to follow the SOX-compliant process.

1. First, we needed to answer a 50-item questionnaire and submit to the Program Management Office.



2. Two people then had to review the request and approve it.



3. The request was then assigned to a functional IT specialist to prepare a functional specification, which consisted of 18 sections.



4. The functional spec was then reviewed by a "key user," who approved it and submitted it back to the program office.



5. A programmer had to be "formally" assigned to go into the code and fix the problem. Of course, this was the quickest part of the process, as one would expect. The program code then had to promoted to a "Test Environment."



6. The functional IT specialist then had to prepare a user acceptance protocol (UAP) with test instructions, which she had to give to five users at our five facilities for testing. This step took five days and numerous phone calls.



7. The functional IT specialist then had to compile the completed UAP forms from the five users into a Test Report and copy them to a secure server and notify the programmer.



8. The programmer then had to go through a series of steps to promote the code from the test environment to the production environment. This is a step that the Company has been doing for years as part of basic configuration management.



9. Finally the misspelling error was corrected.

In the past, such a minor change request would have taken less than an hour for two people. Now, under Sarbanes-Oxley, it has turned into three-week process involving many, many people and has increased the cost to the organization probably 100-fold.

All to correct the misspelling of a single word.

To be fair, I'm not sure that the Sarbanes-Oxley Act is totally to blame here. It sounds to me like this company has designed internal controls with no consideration whatsoever of risk.

No organization has unlimited resources. Industries that are accustomed to doing business in a regulated environment, such as medical device manufacturers, are increasingly using risk management as a way of focusing limited resources on business processes and functions where there is genuine risk. Unfortunately, it appears that companies like the one described above have no understanding of risk management.

Companies implementing internal controls under SOX should apply the 80/20 rule: 80% of the risk is in 20% of the processes. If you try to control everything to the same level of concern, you over-control most processes and you under-control the 20% of the processes that genuinely represent a financial risk to the organization.

Every hour that the IT group spends planning and testing cosmetic changes to applications is an hour that it is not working on improving and automating internal controls for the 20% of business processes or functions that represent real risks. Shareholders of companies like this are not well served by such mindless compliance.

Related posts
Sarbanes-Oxley: stop the insanity
Making SOX compliance a meaningful exercise
Sarbanes-Oxley compliance: too often a wasted effort

Oracle moves into core banking applications

Oracle is acquiring a majority interest in I-flex Solutions, a vendor of software for the banking industry. The firm, based in India, is 41% owned by Citibank, which runs I-flex. Oracle is buying Citibank's stake and is offering to buy another 20% of the outstanding shares from other shareholders.

Strategically, this is an important move for Oracle. Although Oracle claims 17 of the world's 20 largest banks as clients, those banks are mostly running Oracle's database and accounting or HR software. Oracle has not, to this point, offered software applications to support banking operations. That's about to change with Oracle's takeover of I-flex, which Oracle will run as an independent entity, according to Charles Phillips, an Oracle tri-president who will join the board of I-flex.

The move into banking software is a strategic decision for Oracle. The market for such software is potentially huge yet immature.

• The market is huge. Today's ERP systems, which are at the center of offerings from Tier I vendors such as Oracle and SAP, started in the manufacturing industry. But if the manufacturing industry has been attractive for major software vendors in the past, the banking industry is potentially more attractive. According to our research at Computer Economics, as a percentage of revenue banks typically spend over three times more than manufacturing companies spend on information systems.


• The market is still young. According to industry research, something like 75% of software for core banking applications is internally developed. Whereas few manufacturing companies today would dream of developing their own manufacturing operations software, banks continue to maintain and develop new applications for their core banking operations. Admittedly, banks can be thought of as information businesses and therefore can justify more of a custom development strategy. But one has to believe that there are a lot of things that banking systems do that are common among banks and, therefore, good candidates for packaged software.

Although the market for banking software is fragmented, there are some significant players that Oracle will be competing with, starting with SAP, which already serves this segment. Other players include Misys, Temenos, Accenture's Alnova subsidiary, Fidelity Information Systems, CSC's Hogan suite, Chordiant, Financial Objects, FiServ, Infosys, Jack Henry, Kordoba, Metavante, Polaris, Sanchez, and System Access. The list goes on and on.

With SAP already established in this market, Oracle sees the banking sector as another key battleground in its war with SAP. At $1 billion, Oracle's price to enter the fight is far less than the $11 billion it paid for PeopleSoft. Oracle's move into banking is similar to its move into the retail industry with the acquisition of Retek, which it scooped out from under SAP's friendly takeover. In both cases, Oracle is moving into an industry where there are many opportunities for replacement of legacy systems and there is no concentration of dominant competitors.

Related posts
Oracle boasts strong growth in apps business
Bidding war: Oracle fighting SAP over Retek
Oracle beefs up retail offerings with ProfitLogic bid
Brawl continues between Oracle and SAP

Success of SAP America: awkward for SAP?

According to one source, the recent strong performance of SAP America is leading to some interesting dynamics within SAP.

First, the success of SAP America is reportedly shaking things up within SAP Global Marketing. The root of the problem appears to be that SAP Global has never been able to take credit for the turnaround in SAP America, so it is making personnel changes in the U.S. in an attempt to reassert itself--mostly in the name of "strategy." A top executive quit recently from SAP America's field marketing organization, and the politics are said to be getting intense.

If this is true, SAP would be smart to take more of a hands-off approach in the U.S. Over the past year or so, SAP America has clearly been on a roll. Why mess with success?

The second item--which is pure speculation--has to do with SAP America's CEO, Bill McDermott. As the one leading the strong performance of SAP America, McDermott has certainly earned his credentials as a turnaround specialist. These days, the software industry has plenty of big players that need such leadership. One has to believe that McDermott would be at the head of any list for the top spot at any of them.

Related posts
SAP luring top talent from Oracle and Siebel
Brawl continues between Oracle and SAP