–

SaaS 2.0

MB: I want to come back to a point about SaaS deployment that is germane to where we were just going—which is security. Because once you go to these SaaS 2.0 kinds of applications, you are talking about your enterprise data being sent over to another provider that’s going to give you information services of some kind. You have to place a fair amount of trust in that party.

I’ll tell you an interesting thing. We—as a SaaS vendor, of course—want to be able to use our infrastructure in the most efficient and scalable way we can, in providing services to those customers. That allows us to add new customers at quite a low cost, and provide a higher quality of service to them.

A lot of customers have adopted the mentality of, “Well, okay. I’ll let you have my data, but you’d better give me my own private server.” It’s because they have this sense that it will be more secure somehow. In fact, I’ve been trying to convince people that, in fact, it is less secure.

I tell people at this point: “Why would you want have a private server if you’re interested in security?” You’re going to put it on a special separately handled box just for you instead of putting it on the proven secure infrastructure that we’re taking care of carefully for all our customers to make sure it’s secure every day.

MM: Mike, the other thing, too—if you’re dealing with regulated industry—whether it’s FDA or DOT or whatever… Dealing with regulated industries, as a SaaS provider, you have to meet such a high threshold in terms of transparency and IT governance –oftentimes, higher than the user organization has in its own IT operations.

MB: Yes. That’s right. This cuts both ways. If you’re a large enterprise, you might be very concerned about a SaaS company being able to live up to those kinds of security standards. If you’re a small enterprise or small business—an SMB business—a SaaS vendor, as an aggregator of responsibilities for data processing for multiple customers, is very likely to have a high-quality infrastructure. Higher than what an SMB company can afford to do.

There’s a SaaS vendor for the credit card fraud detection space, for example. It of course has built a system to meet the highest industry standards of credit card processing for data security and so forth. It said one of the great things is that other companies feel its solution is more secure than they themselves are.

–

–

Cross-integration of many system

MM: In fact, Mike—as we were doing the quick recap of the history of data warehouses… I think one of the things that had developed or emerged out of ERP and the data warehouses as they interact… A lot of the data that people need aren’t inside the organization. They’re outside the organization in suppliers and in trade partners.

MB: Well, that’s certainly the case. There’s information that’s down in the supply chain. But in fact, in the organizations we visit the systems that are facing the supply chains at customer sites are actually comprised of a variety of systems like warehouse management systems (WMS), transportation management systems (TMS), freight payment systems, customer relationship management systems (CRM), budgeting and financial planning systems, and so forth.

These systems provide functionality not found in ERP systems and therefore sit next to them—so companies always have many disparate, systems where important data resides and needs to be integrated for analysis and other purposes. There still needs to be some cross-system integration of this information. ERP systems in some sense have not quite lived up to their billing of consolidating all of this information. It remains important to be able to reach across different systems as well as across multiple ERP systems to be able to provide the visibility that companies need.

You mentioned the organizational barriers. Those are really quite significant as well. I’ll mention a couple of significant problems there. These are good examples for contrasting the way we approach these issues at Oco versus the way others in the industry have historically gone after these problems.

Historically, people will set out to put the data from their whole organization into the data warehouse. They’re trying to get data — all the data — in one place and also must cleanse that data—an enormous task. It’s an open-ended business intelligence activity that will enable the company to utilize the data warehouse…someday.

In other words, they’re building the data warehouse without already knowing exactly what they want to get out of it. They want to get whatever can come out of it.

–

–

––

MM: In large part, Mike, they fail for—I think—several reasons. One—the production data sources have data that’s somehow compromised or incomplete. Therefore, it requires a tremendous amount of reconditioning to make them usable, so companies can upload them into a data warehouse. Or—two—you simply have incompatible datasets from one system to another. And then I would suspect that there are probably some organizational issues around control of data, and therefore the difficulty of accessing various legacy or enterprise data sources. Does that sound about right?

MB: I would agree that the three things you’ve outlined are some of the factors why BI projects fail. I think that certainly there’s a data quality issue, which was the first issue you’ve raised. That’s still there, although with ERP packages that issue is lessened—but certainly is not gone. Companies still have ERP systems in addition to other point-solution systems, and large companies have multiple ERP systems. So they have the problem of reconciling them. But at least within any one system, there’s a sense of completeness of the information. There is still the issue of compatibility when you operate with multiple ERP systems.

There are problems that companies get into with master data management. They’ve got multiple ERP systems, and they have the same part or customer represented in several of them. And they don’t actually have them identified in the same way, which they don’t realize—and so forth. Those are significant problems in large enterprises.

This master data problem is one of the bigger challenges. At Oco, our key competency is reconciling data from multiple systems to address this problem.

–