ARCast.TV - Office Business Applications at Epicor (Part 1)

Ron Jacobs: Hey, this is Ron Jacobs, here in sunny San Diego, where I've come to Epicor Software. And, man, it reminds me, I used to live here in California. It's so sunny and warm here. I can't believe I ever left. [laughs] I'll tell you, that said, if you want to be at Microsoft, you've got to be in Redmond.

So anyway, we're going to have a great time today talking to the folks here at Epicor, and enjoying the sun and the palm trees. Whew. Got to love it. San Diego. Stick around. We'll be back with more.

[new segment]
Ron: Welcome back to ARCast. This is your host, Ron Jacobs. And today, I'm here in San Diego, where it's lovely, beautiful, sunny, and a little humid today, I noticed, at least, it feels that way to me. But I'm here at the offices of Epicor, and I'm joined by Bart and Scott. Guys, welcome to ARCast.
Scott: Thank you very much.
Bart: Thank you.
Ron: So, tell me about Epicor. What does Epicor do?
Bart: Well, Epicor is a company that really specializes within the mid-market, producing software for the distribution market space, for manufacturing, for retail, and also global financials. So we've got operations in 140-plus countries within the world, operating with software in 30-plus languages. We have specialized software that fits specific segments, so we have multiple product lines. We've got about 20,000 customers worldwide. So, good business.

Epicor's been around since the mid-'80s, 1984, and a couple of the acquisitions even before that. So a good pedigree within the space, a number of years experience, and working with Microsoft for a massive majority of it.
Ron: [laughs] So when you say "good pedigree," I think that means like lots of legacy code to live with, right? [laughs]
Bart: A little of that, too.
Ron: OK, OK. So, kind of financials, ERP type stuff, CRM, that sort of thing, right?
Bart: Right.
Ron: OK, OK. Now, today, I wanted to talk to you guys about some of the work you've done with what we call OBA, or Office Business Applications, because it's a really interesting idea to take and use Office in these kind of environments, in these type of applications. So, Scott, what were some of the drivers that led you guys to think about this?
Scott: Well, I was talking to Bart earlier today. This is something that, really, everybody was trying to do, probably since the onset of Office '95, right? But there really wasn't a platform there to be able to do something specific in an ISV space. You could start integrating. You could start getting information to Office. But really, at that point, it stopped.

So, what's happened recently, especially with Office 2007 and Visual Studio Tools for Office, a pattern here and a platform was being produced by Microsoft that allowed us to be able to build business applications on Office and combine that with Epicor, within an ERP platform.

So the drivers here were, if you look at an ERP software, it's really something that's segmented to a specific number of users within a company. If you add CRM to that, you're starting to touch more, but you're not getting everybody within the application community.

So, what an Office Business Application allowed us to be able to do, and what we wanted to target, was to be able to have that information that's available within, say, the back end system, pushing that forward within Office, giving them a user interface and an environment that they're familiar with.

So, inhibitors within the ERP: typically, I'm looking at core applications. There may be a high amount of training. How do I take more people involved in that situation and be able to reduce that training effort? So the natural fit there, really, was to be able to take information, be able to have it in context, and be able to have actions upon it so that I can actually drive processes, from Outlook, from Word, from Excel, and be able to distribute that to far more users within the space.
Ron: Oh, OK. I mean, I can understand that, because, at Microsoft, we have all those kind of software applications. I don't use any of them. I don't know how to use the ERP system they have or the...
Scott: Yeah.
Ron: The CRM, I've seen it a few times, but I don't have it installed. I haven't been to training on it, don't know how to use it. But it might be useful if I were able to access that data once in a great while, kind of when I need it, through something I'm familiar with. But this is kind of feeling all very abstract, so let's talk about some scenarios. Can you give me an example of, if I were somebody using your software, what kind of thing would I do with Office?
Scott: Let's take the most basic example. ERP or CRM applications typically have customer information and contact information. These are people that I'm dealing with every single day.
Ron: OK.
Scott: Well, I'm also in email every single day.
Ron: Right.
Scott: So just the fact of being able to integrate and push contact information back and forth between the two systems, that's an immediate, easy type of a win.
Ron: OK.
Scott: I say "easy" because it sounds very simple.
Ron: Right.
Scott: I've got contacts in one place I need to get in the other place. But how do I then make this as simplified and transparent as a normal user just going up and opening up an Outlook, and there's my email? It automatically arrives. I don't have to actually tell the Exchange Server, or something of that nature, to be able to bring it to me; it just happens.

How do I do the same thing in the ERP space and be able to coordinate that synchronization, take information offline, and the like? So the simplest case is how do I just take those contacts and be able to bring them together? Now that I've got my contacts, I want to know what my orders are with this customer. I want to be able to view that. I may be able to want to change the status of an order or the status of a CRM call. And how do I actually bring information so that I don't have to into an ERP system, and keep it completely within the context of Office?
Bart: Or if you do want to go into the ERP system, you want to drill in directly from an email that you're looking at from a particular customer that's complaining about some situation. Maybe they can drill directly into the line of business application, in context, and go right to the sales order for that customer that they're concerned about.
Ron: OK. So if I'm like a salesman, and I say, "Well, I've got my set of customers."
Bart: Right.
Ron: "The ERP system has 10,000 customers. I don't want all of them in my Outlook. I just want mine."
Scott: Exactly.
Bart: Yeah.
Ron: So I can say, "Synchronize them to my Outlook." I'm going to open my contacts. Maybe I have a special folder, and it's like, "Here's my contacts from the ERP system"?
Scott: Maybe.
Ron: Oh? Very cool. Yeah. This actually reminds me of something I did a long, long time ago, when I first was working in Silicon Valley. I was doing product support for a development tools company, and in our support system, oftentimes we would need to send email about a support incident or something. But there was no integration. This was a long, long time ago... [laughs]
Bart: Yeah.
Ron: There was no integration. So all I ended doing was writing a thing that would basically format a support incident, put it on the clipboard, so that you could go to your email and paste it. [laughs] But it worked. People loved it. It was like a great step forward, when we could just paste a support incident into an email. That's a small example of the kind of thing that you could do to make this information much more accessible, outside kind of its UI silo, if you will.
Bart: Yeah. Having a user of Outlook be able to go ahead and have an email being sent off to a customer, the system automatically noting, "Oh, this is one of your customers. Let's go ahead and log that as a correspondence with this customer, or a CRM call."
Ron: Yeah.
Bart: And just seamless. It just works the way a user would expect. That's one of the really driving factors about the whole OBA. And the initiative we've taken is to try to get the barrier of entry of the ERP systems to nothing.
Ron: Right.
Bart: Or as close to nothing as possible.
Ron: Yeah. Well, what about, though, like Excel? You hear that, when it comes to financials or accounting departments, more business logic's written in Excel than anything else.
Bart: Yeah.
Ron: So I'm sure a lot of people want to bring that data into Excel, work with it, or do their own custom reporting thing or whatever. You do that kind of stuff?
Bart: Absolutely. And it needs to be contextual, both at the spreadsheet level, which is, "I'm working at this whole series of numbers from this one customer, or from this one sales order or this one set of parts." Maybe you're doing some price modeling. But also, at the individual cell level, or the paragraph or the word level, within Word. Kind of a smart tags, so it's a macro level for the whole spreadsheet, given context into your ERP System.

But also down to the individual piece of data within a cell or within a paragraph. That's where smart tags come in. So, you have multiple levels of contextual awareness that you need to go ahead and provide to the user.
Ron: OK. I'm sure a lot of people will say, OK, I totally get, yes, you can do this with the ESTO and all that. But if we step back for a minute and say, "Was it worth it?" You know. I mean, for every software company, you're always trying to make the call.
Bart: A good investment.
Ron: Yeah, we're going to spend a lot of money creating these functions. Does the market demand it? Do our customers want it? Does it return a competitive advantage? Is it going to produce some kind of really difficult legacy code that we're going to have to live with and that's buggy and difficult to support? Looking back on this now what do you think some of the issues there were?
Bart: The biggest problem that we probably had is just some of the legacy Microsoft object models.
Ron: Oh, right.
Bart: I mean, Outlook and Excel and Word have gone through one or two revisions and their idiosyncrasies to the different object models. From a framework perspective or tools perspective we wanted to try to go ahead and keep that away from the person that's actually building the application content.

That's the costly thing with building ERP Applications, is the application content. That's a legacy value that you want to be able to maintain and go forward with minimal maintenance cost. So, if you can have one tool person or a couple of tool people maintaining the engine or the wrapper, the layer there, it's a lot easier than having dozens of application developers having to re-invent the content over and over and over again.
Ron: Oh. OK. Yes.
Bart: So, Microsoft has given us some framework obstractions and we built a couple more because certain things aren't there for Microsoft yet that are initiatives like Lobby, etc. So far the migration from like Office 2003 to 2007 was almost free. So that was really nice to say the worst thing we ran into was a couple of new reserved words and that was minor to tweak.
Ron: Yeah. You know it's funny when you mentioned the revisions Office has been through, I noticed that Office 2007 was known as "Office 12" and they are already working on "Office 14," I saw the other day. [laughter].
Bart: Already been to the software design review on that. Yes.
Ron: [laughter] Did they just skip over 13?
Bart: Yes.
Ron: I guess that would be bad luck. Yes.
Bart: I think there are some cultural things there they wanted to stay away from.
Ron: [laughter] But, you know, there are not many products that have lived that long to be through that many revisions, you know, without a couple of you starting over or something.
Bart: Exactly. That's why I say, the biggest struggle we had was some of those idiosyncrasies. If we had been doing some add-ins inside of Office for ten years at a framework level we probably would have been aware of a lot of these things. But it's like every time you come along there was a little hiccup every week or two that we would get on the phone to Microsoft and, oh yeah, this is this, this is why, this is how you get around it. Oh. OK. Didn't know that one. Thanks.
Ron: Yes, Yes.
Bart: So, that was the hiccups that we had along the way.
Ron: Well, you know my brother is a salesperson and he is kind of a geeky salesperson. He likes CRM Software and he is always trying different ones and he works in a fairly small company so he can go out and buy his own thing. But he's always telling me about the various ones he tries and how a lot of them will try to duplicate things; functionality that is found in Office. Like, so instead of launching Word with a template or something they'll have their own kind of funky little word processor or something like that.

So it kind of makes you wonder what were these people thinking? Are you in the business of writing word processors? That's what you want to do or what?
Bart: Yeah. Absolutely. Just think of the simple spell check.
Ron: Yeah.
Bart: I mean, yeah. There's tons of things like that. And we've really taken the thought process in this whole initiative to go ahead and steal as much, excuse me. That's developer-speak.
Ron: Yeah.
Bart: We utilize.
Scott: We utilize, yes.
Ron: Leverage.
Bart: Leverage, yeah, there you go. Leverage everything that we can from the productivity tools that Microsoft has. So it's interesting.
Ron: So I'm curious, Scott, if your customers have said, "We like this, we want more of it, we don't care about it." What is the customer reaction?
Scott: We've had a tremendous reaction, positive reaction, from it. I go back to what you were saying before. You wrote a piece of code at one point that did a copy-and-paste mechanism into the application.
Ron: Yeah.
Scott: One of the applications that we targeted initially was Information Worker. It's actually targeted at all upper core applications, but the very first one is our manufacturing line. And there was a functionality within the application that does a copy and paste. I can take my email, I can paste it into CRM, and it's an alt-tab approach.
Ron: Yeah.
Scott: Copy, paste, alt- tab. And one of the things, the mandates within Information Worker, is in the alt-tab, in the copy and paste.
Ron: Oh, OK.
Scott: So just that one feature and that one feature alone has just been huge within our customer base.
Ron: Wow.
Scott: The fact that I can have an email come in, it automatically understands that this is a contact that I've already synchronized with Outlook. So what happens in the user interface, things get lit up. It says go ahead and launch our application and contacts, and pass that contact or pass that customer information. Or go and create a brand new CRM call, and that CRM call can either be done within the application or within a form directly within Outlook.

Another copy-and-paste, the email automatically gets transferred and put into the transaction. And this can all be done off-line also. That was the other key thing that we wanted to be able to do, is that we can take things and do things off-line and then synchronize in the backend later on.

So our customers right now are really eating it up. The big thing is we focused at the beginning on being able to say here's key functionality, key use cases for our CRM side of the business.
Ron: Yeah.
Scott: And the only, I would say, it's a positive yet negative reaction is they want more.
Ron: Yeah. Yeah.
Scott: They want to be able to have more functionality. We built it so that we can expand the functionality as far as the retrievals, the synchronization processes. And we're in the middle of actually producing an SDK so that our customers can be empowered to be able to even leverage more things. So take what Microsoft has given us, write a framework on top of it, and then our customers can actually built custom on top of that too.
Ron: Yeah.
Scott: But as far as the acknowledgement and the reaction from our customers, it's been tremendous.
Ron: You know the off-line case is really interesting.
Bart: Yeah.
Ron: Because off-line is a notoriously difficult thing to do. The synchronization is very, very hard.
Bart: Absolutely.
Ron: And I think about how a lot of these kind of applications typically work. Like we have a lot of in-house ones at Microsoft. Our invoice system works this way.

So like they'll send me an email, and it says, "You have an invoice to approve" and here's a link.
Bart: Right.
Scott: Right.
Ron: And that link takes me to a website, but that website's only on the carpet network.
Scott: Yep.
Ron: I can only get there if I'm on-line, on the carpet network.
Scott: Yep.
Ron: So if I'm sitting on the plane reading email, and I'm going, oh, I got an invoice to approve, I've got to remember when I get back to the hotel to plug in, connect up, and do this, wouldn't it be so much...All they need from me is yes or no, right?
Ron: Yeah.
Scott: Simple action.
Ron: Wouldn't it be easier if I could just say, "Yes. Done." And let Outlook do the hard work, synchronize that message back later for me.
Scott: Yeah. Some of the scenarios we're getting into are these hybrid OBAs, things that we've been doing the last few years, last ten years it seems like now, within share points and portals and those kinds of things. But that needs to be extended down to the disconnected client, and that just hasn't been done well.

And so the off-line client story within Office Tools -- as opposed to our own power user UI, if you will, which is what I usually call our line of business applications -- that need custom training. There are idiosyncrasies on retrieving data and searching for things, understanding the business rules and whatever.

So you have to scale down that power user functionality down to some simple use cases. Like you said, all I need is approval.
Ron: Yeah.
Scott: All I want is to log the fact that I contacted or sent an email to this person.
Ron: Yeah.
Scott: Simple scenarios like that. Those users would never use the ERP system, they'd be talking to somebody else or doing a sneaker-net kind of data thing, or an alt-tab.
Bart: It's the outliers.
Ron: Yeah.
Bart: It's the ability to be able to touch a system without actually getting in and creating a transaction.
Ron: Right.
Bart: It's the approval process. It's the, maybe, updating a status piece of it. "I need to take a call. And it was open, and I'll close it and add some small text to it."

But getting a little bit further, too, is where is the use cases that I can leverage authoring engines like Word? So I'm looking at a quote. I wanted to be able to take that information. I've got information about the customer. I've got information about products. I've got all this information that's a storage...
Ron: Yeah.
Bart: And how do I then populate it and create a quote, or a pro forma quote, almost, and do that potentially offline? And when you're looking at service-oriented architectures or you're looking at distributed systems, or you're looking at these things, you don't want to take complex business logic around pricing or configurators, or all of these type of things. You want to keep it simple. I don't want to distribute that code all the way down the client.
Ron: Right.
Bart: That's one of the things that's been difficult.
Scott: Not again.
Bart: Yeah.
Ron: [laughs]
Scott: Not again.
Ron: Oh, you've been down that road. [laughs]
Scott: Not again.
Bart: That's one of those things that's very difficult about synchronization.
Ron: Sure.
Bart: So how can I do things a little bit differently, and take that information, take a template that I can do in Word, fill that information in, tell the customer, "This is a pro forma quote. I've got the list pricing on it." And if I'm connected, great. I save that off. I can send it off to a work flow in SharePoint or within the Epicor application. It runs all the pricing and what have you, and then updates the quote and sends it to the customer.

So there are ways that you can say, "I want to take the simplest outlying piece," or "I want to take the document-centric things that people understand that are within Office," and hide all the potential complexities that are in the system. Not replicating business logic--keep it all where it needs to be--but then have this document flow that are basically doing a collaboration between people within the organization and outside the organization.
Ron: You know what's an interesting trend that I see happening that, I think, plays into this is, as mobile computing has become more and more mainstream...
Scott: That was a stat I saw: three times as many mobile devices sold last month or last year than PCs or laptops.
Ron: Yeah. So everybody's got mobile devices. They've got laptops with wireless connectivity. And we've kind of come through an era when everybody was like, "Oh, let's just build web apps. Web apps can do everything. We'll just make Ajax web apps. That's fine."
Scott: And they are.
Ron: Yeah, and they are. But you assume that you have ubiquitous connectivity, which is true in some places -- big cities and whatnot -- but even in those places, you run into kind of dead spots, places where you can't connect. And I think the expectation, if we thought that people were going to just be patient with that, I think we're wrong.

I think people have said, "I've got a mobile device. It does something. I want it to do it all the time, no matter where I am. If I'm on a plane, or if I'm in the basement of the building under loads of stuff that's keeping me from a wireless connection, to kind of expect that I can do something useful right now."
Scott: And you're assuming decent bandwidth when you are connected.
Ron: Yeah.
Scott: The mentality that we're finding that you need to go towards is that occasionally connected or low-bandwidth, high-bandwidth kind of scenarios. So if you plumb for the disconnected user type of scenarios, then you can support those occasionally or low-bandwidth scenarios, as well, a lot easier than assuming that you're always going to have a high or a reasonably good connection for that Ajax app or whatever.
Ron: So that's an interesting picture, though, when you're talking about, "Let's put the heavy weight business logic on the back end, with services. On the front end, let's let people use different kind of tools to author, if you will, the messages that are going to hit these backend systems."
Scott: Yeah.
Ron: So they can use Outlook as a tool. It has great synchronization support. Let them use it. And then let the back end carry the heavy load. I think that's a good model.
Scott: And it's not just synchronization. I mean Outlook, anybody who's a real power use in Outlook, and I've ran into many especially in the sales side of the world, with categorizing and tagging things and formatting the data the way they want, categorizing their emails, categorizing just different information. All the different filtering capabilities that a lot of people didn't realize they had or they know a little bit of it but they didn't know all of it. And it's been really interesting to see people light up, wow, I can use that. Not only with your app but also just Outlook generally.
Ron: Yeah.
Scott: So it goes back to another mantra I've had in the past of no throw away knowledge. So if somebody really knows Excel they shouldn't have to learn anything new to take advantage of cool things they can do to the application or Outlook or Word. So that no throw away knowledge is really nice for users. That really resounds with them.
Ron: You know what else is really powerful about this is that the searching and indexing capability now is very cool because like I subscribe to a lot of RSS feeds. And so, you know, I'll be going to search for something in my inbox and then it's also finding the RSS articles that relate to that and all that.

And I'm thinking wow that's pretty cool, you know. What if you could publish some -- maybe I say here's five customers that I want to watch the activity on their -- maybe they're my top customers and I could get like a RSS feed of their orders or something like that.
Scott: [laughing]
Ron: You know and I could go in and say, you know, "company X" and then bam it shows up in my search and right there in Outlook all the stuff about their orders. You guys have that kind of thing?
Scott: Well the fact that anything that you pull offline is filterable, yes. In Outlook, for example. But you're also talking about some scenarios that hopefully by the time this airs we will already be, you know, shipping some things in that area we're talking about.
Bart: Yeah, there's two things there. You're subscribing to a RSS feed. You're subscribing to those five customers I want to be able to have filter off and get their orders in the way. And I can pull that in but I've actually done that subscription. IW is handling that through a sync engine.
Ron: Oh, OK.
Bart: RSS would be another piece that's monitoring on the backend. And it's basically saying these things all happened. Go send it to them right now. And we actually then do a RSS feed. It's not a subscription through IW. And we prototyped a few things on doing that, really building off the same... the blocks that we had used for information.
Ron: Yeah. So you know what I think the bottom line for me about what you guys have done here is that in the old style model ERP or CRM was only really useful to the power user.
Scott: Right.
Ron: The guy who went to the training, the guy who installed the bits on their machine. You know, like you said that's a small fraction of the company.
Scott: Yeah.
Ron: So the company says well yeah we get some value out of this but a lot of people never touch it, you know, we've got all this really useful data but it's kind of locked away for only this select group of users. And what you've done is kind of blown open the doors and let a lot more people get some of the value of the information.
Scott: Yeah, exactly.
Ron: Well, very cool. So we're going to have more about the Epicor story here. When we come back we're going to talk about the architecture of this solution so stick around.

[audio cut]

[music]

Hey this is Ron Jacobs and I'm looking out my hotel window here in beautiful downtown Hong Kong, where I'm staying here for Tech Head 2007. Which we just wrapped up last night and so today I'm finally getting back to some art cast episodes here in my hotel room.

And that was just a fantastic chat with the guys at Epicor. You know and they had some really great insight into what it takes to build an office business application. Some things that, you know, I never really thought about but really matter a lot. And we're going to have a lot more from them we're going to get more technical.

OK, so yeah, we'll do that on the next episode. And over the coming weeks we're going to have more from a lot of different places I've been; Las Angeles, New Zealand, Australia, some from Fiji [laughs] and here in Hong Kong.

So, I'm looking forward to bringing more to you in another year of ARCast. I guess I kind of almost think of this as almost being the beginning of a new year. We started in September two years ago. We have a lot more to come. We'll see you next time on ARCast TV.