Журнал ИКС

Разделы сайта

• Новости
• Блоги
• Аналитика
• Новости компаний
• В СНГ и в мире
• Анонсы

Календарь

		Май 2024
Пн	Вт	Ср	Чт	Пт	Сб	Вс
		1	2	3	4	5
6	7	8	9	10	11	12
13	14	15	16	17	18	19
20	21	22	23	24	25	26
27	28	29	30	31

Ближайшие события

Why IT Needs To Push Data Sharing Efforts

03 сентября 2010

As IT organizations change their focus from cost cutting to growth, one of the single best things they can do for their businesses is enable effective data sharing. Sounds like a no-brainer, right? The right data sharing can open new markets, win new customers, improve relationships with existing customers, and expedite jobs from materials delivery to inventory management to payment reconciliation.

Yet data sharing, particularly automated systems that give your external business partners access to your data when they want it, are not ubiquitous or easy, and the level of data sharing of any kind is surprisingly low at points before and after the sale, our exclusive research finds. Your colleagues resist data sharing, but they're not the only problem. IT is way too slow at creating such integrations--taking months, not days, to build new links, in many cases.

FedEx and UPS make package tracking so simple, it's easy to take that capability for granted. Yet only half of companies even share order status with customers. Meanwhile, in the most sophisticated supply chains, companies share data as deep as inventory levels with key customers, such as manufacturers looking to coordinate just-in-time deliveries. With vendors, electronic invoicing is the simplest level of sharing. On the other end of the spectrum are companies that share point-of-sale data with vendors, something fewer than one in six companies in our survey do.

Understand the value of virtualization so you can begin discussion and planning

It's such an important trend that IBM in late May said it would pay $1.4 billion for Sterling Commerce, an integration software and services company owned by AT&T. While the deal didn't attract a lot of attention, it was IBM's largest acquisition in three years. The appeal to IBM is straightforward: Data sharing and integration projects always require some custom integration and ongoing maintenance of the links. Therein is the opportunity for IBM's consulting and services army, and the challenge for most IT organizations. But the problems go well beyond creating and maintaining data integration links. Our survey of 281 IT professionals finds that while technology is part of the problem, organizational resistance is a bigger obstacle.

Almost every company we surveyed shares data with someone. Most (74%) share data with customers, while 62% share data with suppliers. Almost half of respondents are required to share data with other third parties, mostly government agencies. Yet there's wide disparity in data sharing strategies: A fourth consider it a top IT priority, about a third build connections on request, while 22% admit they resist data sharing to some extent.

When it comes to what frustrates data sharing efforts, the classic culprit, budget limitations, tops the list of survey respondents, followed by complaints about the multiple sets of tools and the care and feeding required by legacy connections. However, we suspect that it goes deeper than any technology.

Sales, manufacturing, or merchandising tend to drive the decision to build new data sharing relationships with suppliers and customers. "They're usually the starting point and are a major factor in getting a program expanded," says Jim Frome, chief strategy officer at EDI software-as-a-service provider SPS Commerce. That trio historically doesn't have the greatest relationship with IT in many organizations, Frome says. Yet IT really needs to have an active role in educating the different teams about capabilities and options available both internally and externally.

Unfortunately, IT doesn't typically get to play that role, or even tries to avoid it. "The company doesn't really care about sharing data," says one senior developer summing up his team's sentiment. "There's usually an initial scream to get the integration project done as quickly as possible to meet a short-term target, then it's never looked at again. No attempt to grow it, no ongoing review, no deeper analysis, and no feedback unless something breaks."

IT needs to break out of this reactive mode. IT's expected to create an integration point, but is it also trying to promote its use? IT can shine here with a bit of evangelizing.

One Northeast distributor was trying to figure out a way to cut costs. It had a few clients who had been doing electronic transactions for years and were relatively happy, but most of its customers relied on good old paper. IT came forward with an idea to build a sales campaign to push all forms of streamlined invoicing, including integrated data and electronic invoicing.

After some initial pushback by the sales team, which was overridden thanks to huge support from finance, the campaign was approved. The result was a 20% increase in customers switching from paper, saving a few thousand dollars a month and two full head counts in terms of man-hours.

Why We Don't Share

IT has an opportunity to evangelize because companies' data sharing doesn't go very deep, which is evident when we look at actual sharing levels in our research. For companies that share data with customers, initial order feeds are either in production or being piloted or planned by 70% of respondents. However, the level of information sharing varies widely as you move through the phases of the sales process.

The least amount of sharing occurs prior to the sale of a product; most organizations don't share any product development, Web traffic, or marketing data, and most don't even quote information electronically with customers.

Once a sale is made, there's a spike in sharing, with 53% sharing the initial order details electronically. Then the drop-off resumes as fewer and fewer organizations bother sharing order status, tracking information, invoicing, sales reports, or warranty details.

While not everyone in the company may be receptive to new data sharing efforts, you can usually find an ally in the CFO's office. We spoke with multiple integration vendors for this survey, and they all point to one of the hottest trends in data sharing: electronic reconciliation of payments. A step beyond invoicing, it ties payment transactions directly back into the core systems, reducing reconciliation and payment cycles. A CFO's dream.

Here's how it works: A U.S. sports equipment manufacturer thought it was missing a lot of opportunities to take cash discounts from suppliers. It had the cash to make payments, but the processing took too long. Hiring more staff wasn't feasible. The manufacturer opted to push for electronic payment processing of invoices, even adding incentives for suppliers to bill electronically. It was able to offset the cost of the incentives and add to the bottom line by paying earlier and taking 90% of the potential early-payment discounts--up from 30%.

Perhaps the only thing worse than an IT organization not taking the lead on data sharing is when IT is left out of the process. One example: A large U.S. manufacturer of educational products was deep into a review of its pricing strategy. It had a mishmash of information about current prices, supplier-recommended costs, and competitors.

The primary teams involved--merchandising, purchasing, and finance--set up a plan that included cost and pricing feeds from sup- pliers and different divisions, and some from old-fashioned Web scraping. The project created a ton of excitement, particularly when data started coming in.

However, the project was doomed to Excel hell; the manufacturer had the data, but not the systems to do anything with it. IT has a choice: It could see such efforts as just another rogue project foisted upon them, or as a golden opportunity to help the company succeed in an area getting hammered with spending cutbacks. What would your team's reaction be? Excitement, disdain, fear, anger?

The Insurmountable Queue

You know the right answer, but we suspect most would react negatively given the potential to crush budgets and supersede existing projects. That's a manageable problem, a matter of setting the right priorities. A bigger problem is if IT simply doesn't have the ability to respond quickly to new requests. Too many companies can't move fast enough.

When we asked how long it would take their teams to establish a new data link with a customer or supplier when both have compatible connectivity options, only 23% could do it in less than a week. Another 41% could get it done in a month and the rest would "add it to a list." And that's for compatible systems.

The response when a new integration point is needed is even more troubling. Only 29% could get it done in a month or less. Eleven percent said it would take more than six months and 10% were willing to admit they can't (or won't) do it--at least not themselves.

Regardless of how long it takes to build the links, we're not very good at getting a lot of customers and vendors to take advantage of the options. A whopping 83% of respondents have fewer than 1,000 different connections in total--customers, suppliers, and third parties combined.

Here's how we see it: A midsize, $200 million company that has an average order size of $1,000 would likely have more than 20,000 clients and 2,000 to 5,000 suppliers. A larger enterprise is likely to have more than 100,000 possible connections. Where should you be?

What About Standards?

While the biggest obstacle for IT may be overcoming the company's internal culture, that doesn't mean there aren't plenty of technical obstacles. EDI standards have existed for more than 30 years, starting initially with orders and invoices and expanding from there. However, if you talk with many companies they'll say EDI and other standards don't give them enough options and aren't very deep. They're simply wrong.

EDI standards aren't just for invoicing or manufacturing. A quick check of Accredited Standards Committee (ASC is part of the American National Standards Institute), the keeper of U.S. EDI standards, shows more than 300 active standards that support manufacturing, finance, retail, healthcare, even professional services.

Order flow? That one's easy and often used. Push it a bit, though--appointment confirmations, student loan apps, product and service reports, personal credit reports, customs details, product information, patient records, even text messages. You name it and there's probably a standard for it.

And it's not like you're required to use dial-up lines. There are multiple methods, including traditional FTP, HTTPS, AS2, and even some nifty Web or e-mail integrated tools. They're highly efficient--sometimes by an order of magnitude over their XML-based kin--though EDI has earned its reputation as notoriously inflexible, particularly for flat files.

Classic EDI does have its limitations, but these are addressed by other standards including some of ASC X12 XML based standards, plus a host of competing standards, including cXML, RosettaNet, and xCBL.

cXML and xCBL are both XML-based standards that grew from an early need to expand beyond EDI functionality and evolved to open standards available beyond the networks of their creators (Ariba and Commerce One, respectively). RosettaNet is more of a classic consortium, part of GS1 U.S., the group that gives us the 10-digit UCC bar codes we know and love. None of them is a universal standard, but they add some critical frameworks for Web-centric or interactive sessions. All are free standards, open to anyone who wants to use them.

Here's the rub: While standards exist, they are often ignored by large vendors creating data exchanges. If a standard doesn't serve the interests of a particular provider, that provider simply doesn't follow the standard and instead makes up its own. If a vendor is big enough or you want its business, IT just adapts. It doesn't matter if there's one standards group or five, many companies, especially Web-centric ones, opt to roll their own--either creating a new format or modifying one to suit their needs. One case in point is online pricing information.

The Web Catalog Nightmare

Getting your product and pricing information on the Web is now a critical part of almost every company's go-to-market strategy. It doesn't matter if you sell consumer, business, or industrial goods; users go online to check your pricing. If you don't provide such data, your customers are likely to find some rogue price posted by a partner or competitor, or even an old customer contract that's floating around. Worse case, they'll find nothing useful and simply go to a competitor who does provide pricing. The tendency of individuals to Google it is the new norm.

There is a sharp group of companies in our survey that have identified this challenge and are publishing price and product information beyond their main Web page. They're publishing to government sites, Amazon, and Google, as well as to business-to-business integration vendors like Ariba.

Good news, right? Not for IT. Amazon, Google, and most government online systems don't follow anyone's standard--not the EDI 832 standard, not cXML, not RosettaNet, or anyone else's standard for product information. Your team has to create and maintain a feed for those vendors separately, dealing with the different field requirements and rules on a case-by-case basis.

IT needs to let this reality sink in. The existing levels of standards and interoperability aren't going to improve any time soon. Don't wait for it. The Web has transformed business and social relationships on multiple levels. However, the most successful Web-centric vendors don't want true interoperability.

Take your supply chain team out for a beer and you'll hear the story. Ariba for one set of clients (or vendors), EDIOne for another, GXS for the largest clients, SPS for the retail channel, EduMart for the education market, and so on. Most offer one or more of the standards, but each has its own rules and none of them share.

Google, Microsoft, and Amazon aren't any better. Each has critical sets of data you either want or need to be a part of, but don't expect these guys to have a standard you can use interchangeably among them. Google made waves by adding product feeds to its basic search service. Loading a product feed is free, but you have to follow its rules: separate field definitions and upload processes with no "free" way to simply point to an existing data feed.

There's no way Google's going to make it easier for a company to publish prices on Google by pulling from a competitor's search site. It's the No. 1 destination, and Google wants to keep it that way.

This resistance to sharing even extends to the growing SaaS sector. Some vendors, such as Salesforce.com, are pushing their own data clouds as a place to connect. But once you integrate with Salesforce, it's hard to get out. It'll send you a nice spreadsheet. That's it. Here's your data. Good luck. Also, would it be possible to integrate competing data systems? Possible, if you're flowing data into ERP or other enterprise apps. But another division using SugarCRM or Oracle CRM?

You already know the answer. Not gonna happen for a long time. Don't gripe about it; plan around it.

By Michael Healey

Источник: Information Week

Оставить свой комментарий:

Комментарии по материалу

Данный материал еще не комментировался.

Заметили ошибку в тексте? Выделите её мышью и нажмите Ctrl+Enter. Спасибо!