Listen to the entire 22:23 podcast Download file

Gian Trotta: Welcome to another "First Look" podcast. I'm your host, ebizQ's Gian Trotta.

What do you do when you have eight different production facilities using eight different ERP systems and need to process 180,000 transactions a day? One major electronics equipment manufacturer solved the wasteful network imbalance by turning to JustSystems. Here to tell us about it is Paul Wlodarczyk, VP of Solutions Consulting for JustSystems. Welcome, Paul, and thanks for joining us!

Paul Wlodarczyk: Hi, Gian! It's good to be here today. Thanks for having me.

GT: JustSystems entered the US market last fall and has already gained recognition for its xfy software that allows businesses to cost-effectively deploy enterprise mash-ups. I'd like to discuss a case study we cited, Paul. But first, can you give me some company background on JustSystems?

PW: Sure, Gian! So, we've been around since 1979. We got our start in the word processing business in Japan. So, Ichitaro is the first Japanese-based word processing software package. And that was JustSystems. So we cut our teeth in the word processing market. And over time, as word processing and office applications and personal productivity applications could benefit from XML, we shifted our technology base to XML-based technologies. And so, JustSystems made the transition from desktop personal productivity software to enterprise software, pretty much through the XML technology.

And that parallels the development of XMetaL, which started off as a personal productivity package for creating XML documents. And we've now moved it to a platform for enterprise applications based on XML technology.

GT: We old-timers remember XMetaL. Any relation to HoTMetaL?

PW: Yeah, that's right. So SoftQuad was the company that brought us HoTMetaL, which was the first HTML editor. And then also, XMetaL. XMetaL has been around since 1998 and was acquired at the end of March of 2006 by xfy.

GT: So that's xfy’s lineage. What is its typical business usage?

PW: Well, the typical business usage for xfy. xfy started out, as I mentioned, as a text editor; an XML-based editor. And one of the things that was key to xfy was the ability to integrate it with back-end database. Essentially, because it's made of XML, it can integrate with anything that exposes XML. So that can be Web services. That can be an XML database. Or that can be XML content that was a file system.

So with that capability, one of the things that became really apparent in Xfy's development was that it's a great framework for mashing up content that's made available with XML from multiple sources. So in that sense, it becomes a mash-up framework. And when you sit it on top of an enterprise class database such as Oracle or IBM's DB2 9 product, the Viper product, you have the ability to get XML from enterprise applications and integrate it with XML content from anywhere else.

GT: That's very useful. It's almost like you had the solution before there was a problem.

PW: Well, it is interesting, because one of the things is fundamental technology now is that we're looking for solutions spaces where this makes sense. And the idea is to follow the XML. So we look for, where are there places where there's lots of XML and one area is clearly XML made available from enterprise system through Web services. The other area is legacy content that has been migrated into an XML database like DB2 9 and then made available as XML.

GT: In which sectors, Paul, have you seen the most interest for these new types of solutions?

PW: Well, we've seen interest in a couple of sectors. So one is, which is really interesting, is in the area of life sciences and pharmaceuticals. Where it's a classic, what I would call a data document convergence problem. You've got the requirements of reporting information to the FDA as part of the product market lifecycle, a document needs to be delivered as part of that delivery. When you communicate from research and development to manufacturing, to take a drug to market in its initial manufacturing, that communication is typically document-based.

But one of the things we're finding is that are XML standards out there that have been used for machine control. One of them is a good example of BatchML. It's been out there for controlling quality control devices and process manufacturing. And what we were able to do was to create an application in xfy that reads and writes BatchML, but creates the kinds of documents that you need for communicating between research and development and manufacturing, such as recipes. But also for communicating the drug filings that you need for the FDA. So it's a great opportunity for us to collect data from multiple sources, bring it together in a document format and then use it to improve the communication between people and the various roles in the product-to-market process.

GT: Okay, if you don't mind me delving a little more in its actual function? Do you need a specific developer to implement it? At what point can the average business user have input into xfy?

PW: Well, one of the uses of xfy is to create applications for business users so that you can hide the complexity of the underlying document structure from the end users. So the user experience can be as simple as dealing with a forms-based application. The thing that's interesting about xfy is that it does a really good -- because it's XML-based -- it does a really, really good job of separating formatting of information from the underlying data structure. So we're able to allow IT resources to focus on exposing enterprise content through Web services, for instance.

So the domain of IT would be creating the services that xfy then takes advantage of. Then we can move the development of solutions closer to the end user and into the line of business by having IT resources inside of the line of business. Create the enterprise mash-up application itself. And this is using user interfaces to map, user-interface characteristics like forms, like drop-down boxes, like charts, to data sources that are made available through IT.

And then the end user has the ability to tailor the interface because we have this clean separation between the interface that the user sees, which is a rendering of content and the underlying data structure itself. So end users can tailor and customize the application. And the end user experience can meet their needs. And have multiple views under the same piece of content. So you can have one piece of XML content such as a relational table, view it as a chart, view it as a table, view it as a different type of chart. And the end user can have control over that view, without having to do any sort of programming.

So, we're able to get really good division of labor between IT resources, line of business, you know, sort of weak programmer, super-user sort of role and then end user, business users, who have no notion at all of programming or of writing a query.

GT: That sounds like a very holistic approach to an enduring problem, Paul, and it sounds like a good solution. Can we go talk about the case study we cited in the start? I believe the company was Nippon Chemi-Con with the multiple plants and multiple CRM systems?

PW: That's correct! So, this was a classic example of -- the business problem was a classic, multi-plant network management problem. Where you've got multiple plants. You've got demand coming from multiple places. They had 180,000 orders a day. So if you can imagine, these are pretty small orders. They're little orders coming in from multiple sales offices. They have dozens of sales offices throughout the world in eight facilities. So the difficulty was one, modeling demand. You've got demand for their products and orders coming in from multiple places.

Two, was visualizing what the production capacity was at any particular plant. So the sales person had to pretty much guess, based on their experience, so it was an educated guess, which plant to send the order to, which plant had the production capacity available. The third problem they had was visualizing inventory. And in their case, some of the raw materials and some of the finished goods, which become raw materials in other processes, actually expired. They go bad. They've got a shelf life.

So at the end of every month, they would have to throw out inventory that had piled up that was expired. That was no longer usable for manufacturing. So there was a lot of waste in the product, in the process. So what they needed was one system -- if you look at the root cause. So inventory's out of balance because orders are coming in from all over the place and plant production capacity is not being visualized. And at the end of the day, if you want to solve the problem, the root cause is -- get the orders to go to the plants that have the capacity. Don’t send orders to busy plants, send orders to idle plants.

And so the solution that was put in place was, you had eight plans, eight ERP systems. Put one dashboard system that allows all of the ordering to take place and be routed to the plants that have the production capacity to execute the order.

GT: Right. So you have an application for business intelligence also, then?

PW: That's a really classic example of being able to visualize across multiple systems, right? So we've got eight systems and in a sense, the application is a BI application, that's absolutely right.

GT: So I read your case study with Excellus. And I know our time is getting tight, but we can go as long as you want to. That was, I thought, very interesting and probably very relevant to a lot of American consumers, if you can describe that.

PW: Sure, so Excellus is a Blue Cross Blue Shield company in western New York. And they provide health care products. And one of the things that they're doing that's really interesting is they're actually embarking on a project where they can describe any of their health insurance products, using an XML schema. So imagine, you know, if you were configuring an insurance product for a consumer, you'd say -- and actually you sell to the groups, you sell to the big employer. So in the case of Excellus, they're in Rochester, New York. So they sell to Xerox, and Kodak, and Bausch and Lomb, and the University of Rochester and the other big employers in the area like Wegmans.

Yeah, so the groups would say, we want a benefit with this kind of prenatal care. We want this kind of drug coverage. We want this kind of co-pay structure. We want this kind of overall premium. And, so they know, looking across all the employers in the region, what sort of product base they want to put in place and then they want to configure that product.

Well, if you go through now and you think about this, you've now got an XML definition of every product that they could possibly sell. The next thing is, all of the language that describes this product, the contracts, the end user manuals, the new member booklet that you get, the contract language that is signed between the group and the insurer, everything that needs to be filed with the New York State insurance department. All of these documents could actually be defined by that XML schema.

Once you've configured the product, all of the language that needs to go in all of the documents with that can be mapped back to that particular configuration. So what they want to do is pretty interesting. And one of the things they're interested in with xfy is that they're looking to have an end-to-end XML-based approach to defining their products and all of the documents that go with those products. And XFY enables them to build solutions that face different people in the process along the way, in terms of creating the contract language, in terms of providing a solution to the call center, for instance.

So, here's the classic problem. You get a claim denied letter from the insurer. And you go and look in your member handbook and you believe that you're entitled to the benefits. So you call up the call center and you say, "Well, it says here on page 37, that I'm entitled to this." But the person on the call center is looking at a database record on their screen. They can't see page 37 of the document that you received. So they're disconnected from your experience.

And one of the things that we're able to do by pulling together all of these information sources and all of these documents that are all going to be based on XML eventually is to create that view. That one view onto the content for the call center agent that gives them exactly what's relevant. So if you're calling about a dispute about your visit to the chiropractor and whether that was included, they know immediately what all the policies were that were related to that diagnostic code. They are able to display that information. They were able to look at your transaction record from that particular visit to the doctor and so on.

So, we're able to pull all of this information together from multiple systems and document sources and displayed in an interface that tailored to the needs of the person doing their job, in this case, answering the phone. Or in other cases, processing the claim at the claims center.

GT: Right. Again, what you mentioned before, a document rather than dashboard-focused interface.

PW: Right! And documents, document-based interfaces are interesting, because people are used to looking things up in books. So there's a lot of tacit information about how content is organized that's conveyed in a document form. And so one of the things we found over the years is that exposing information in a document-based interface makes it much more natural to the end user.

When you're introducing new systems, you can make them look like the old documents. And in that sense, you minimize the change that people have to go through. It's less disruptive and the change management is minimized. So one of the things we tend to look at, in an engagement, is we look at people and the work process they have, the content that they have and then we put the supporting technologies in place to help them do their jobs better. It's the people process technologies view that we take that is really focused on improving the way people work with content.

GT: That's very interesting and, you know, it begs the next question: with all these possibilities, where is your company going in the near future?

PW: I think in the near future, we're focusing on, we say: we're following the XML. So we look at where is XML adoption strong today? What are the logical applications for us to be able to build on? So one area is in the area of xfy and XmetaL as complementary technologies. So we're looking at xfy applications in the technical publications space. Another area is XBRL. We're looking at XBRL as a standardized way for public financial disclosure. So how you publish your 10K, your annual report, would be an XBRL format.

In the States, it's a voluntary program right now, but we're seeing movement from the SEC and other areas that are indicating that XBRL will become a standardized approach for submitting content in the United States in the very near futures. So, that's another area. In insurance, there are standards, the ACORD LOMA standards that originally started as data interchange standards for insurance companies sharing information about claims and transactions. But we're also seeing that to start to move into the document space as well.

So, in various areas, we're seeing XML being used not only for data interchange but document interchange and those are the areas where we think we're going to have the most interest, because xfy really brings value to companies that have XML lying around, that they need to visualize or analyze or bring together into work process. And that's where xfy really shines. Where there's XML, we can rapidly create a solution. In the case of the Nippon Chemi-Con case, we got that XML out of an XML database. In that case, it was DB2 Viper product from IBM.

GT: I wanted to circle back a little, to the last question. These seem to be very dynamic processes and documents are, of course, not static. When a document changes on the client's side because of a regulatory issue or just a market change, how does reverberate through your solution?

PW: The way a change would be made is just by pushing the change down to the client machine. So xfy is an enterprise-based application. We've got a server, the enterprise server. Where the view of the content is actually stored in a shared database. So we can push that new view. If we have to make a global change to the way information is viewed, we can make the change on the server and deploy it out to the client machine. So it's very easy for us to deploy changes to the end user application through the server.

GT: I'm actually, you know, disputing a few health care charges. It's funny that you mention that now! And let's say that they move the goal post, that they've changed the document on their end. But it hasn't really been communicated. I may be using an eight-month-old handbook? I guess that would be the solution to look for. Is there some way to just trigger an email or an update to my account because I'm a power user but I'm not using the online site yet, because I just haven't had time with a 2 ½ year old baby to sit down. You know, my baby always wants to use the computer to go on NickJr..com?

PW: That's right!

GT: So, I'm just wondering. And this could be all off, but I don't know if that's the last step. Maybe you have a last mile of communication there? And this happens with autos when there are recalls and things of that nature.

PW: Exactly. I mean, we've talked to several business partners that have technology that enables us to publish information as a PDF for instance, from an XML base and then keep track of the policies around that PDF, in terms of, you know, did somebody who was required to view this document actually view it? Was it distributed to everyone who got it? And if you think about those things, its notification in workflow, content management in versioning, these are all important aspects of any business process where it's not just a matter of publishing the content from the source, whether it's a relational table or whether it's a piece of XML content that then needs to be published out in a document through an XML publishing process.

What's really important at the end of the day is, who's using that document? How did they get it? Did they read it? Did they get it? And how do you know? And so, there's a variety of technologies from us and from our business partners that we look at. Whenever we've got one of these business problems. Such as, a classic example is aircraft documentation changes for service on aircraft. If a manufacturer of a jet engine, for instance, makes a change to a service procedure, they have to communicate it to every single airline that's flying aircraft with those jet engines on it. Every guy that bends a wrench on that aircraft needs to acknowledge in some system some place that he got this documentation change and that he read it. So in this case, the notification and recording process, the audit trail around the delivery of that information is as important, if not more important, than the information itself.

GT: That's understood. You look at auto recalls. I know that when I was at CBS, one of the most popular parts of our program was broadcasting product recalls. We we found that our audience appreciated it as much as the manufacturers no doubt.

PW: That's right! And I think it's very important in terms of maintaining happy customers, is making sure that they've got access to this information and we've got the technologies now such as RSS where people can subscribe to information, via RSS or ATOM technologies. So I think the Internet's brought us a lot more sophisticated ways of keeping people in touch, and the email generation with auto responding, putting a web link inside of an email so that you send it out to people so that you know that they've read the email, click here and register and you've got it. You know, subscribing to emails and email wait lists and other ways of keeping in touch with customers is very important.

And whenever we put a solution in place for distributing information, whether it's to customers or employees or other stakeholders, these are the type of technologies that we usually consider when we are creating a solution.

GT: Right. That's understood. I mean, I want to thank you, Paul, for taking time for a really excellent, you know, 30,000-foot view that at times delved into the real issues that all sides will find useful. I did want to end up by remarking for the third time on something I mentioned twice, and that's your title -- VP of Solutions Consulting is a bit singular, a bit intriguing. And I'm wondering if you can just expand on that. I think by definition, at the end of this podcast, we now have a better idea. Of what you do and what your core competencies are, but could you elaborate on it?

PW: Yes, sure. So, one of the things -- so there's the role we serve within the company. I guess I'll talk about that first. Which is identifying areas where our technology has good fit. And by putting it in the hands of real people with real business problems, people who are trying to get their jobs done and understanding what makes that technology compelling. What makes that technology valuable to a customer in terms of solving the problem? And then, really, how do we make that repeatable?

So from a business standpoint, from our standpoint, we want to not have a bunch of, what we call that's-one-in-a-row problems. Right? You've seen one; you've seen them all! Literally,right? From a business standpoint, you want to have problems that are highly repeatable. You want to be able to solve a problem once and solve it the exact same way over and over again for customers, because you're more profitable.

So part of our role in the organization is to be the feed on the street and understand where the value is being created by our products with customers -- to translate that into repeatable business solutions and also to be able to communicate back to the business what the needs of the customers are. So we're the early warning system. We're the advanced guard for the company in terms of understanding how we create value.

From a customer's standpoint, our role is really to translate technology into business values. So our goal with our customers is to improve their business process and to focus on business results. And that's very pure solution selling. And in terms of the title, there was actually some conscious work there. I googled the title to understand what do we call this role, right? Because there were a number of different things we could have called it. And "solutions consulting" was simple and descriptive, so that sort of fit the criteria around, you know, what's a good title. It's descriptive. We're in the solutions business. We do consulting.

But it's also a title that I've seen is coming into vogue and it fits into the businesses where the technology is really being placed into a business context and where you're really working with the customer to create an unique solution for them that is the perfect marriage of their business need and your unique technical capabilities. So that's really what our focus is. We're right there where business and technology run into each other.

GT: Okay. That's understood. And I'm advising my listeners that there will be a quiz afterwards -- we've covered so much ground! In the meantime, where can they go for more information on your systems and solutions?

PW: In North America? You can go to www.na.justsystems.com

GT: Okay.

PW: You can find out information about xfy, XMetaL and all of our products and services.

GT: Okay! I wanted to thank you, and hope we'll have you on again in about six months. I'm sure you'll have more exciting developments to report!

PW: Oh, it would be a pleasure to be on the show again, Gian. I really enjoyed this talk we had today. Thanks.

GT: Well, we did too. Okay. Thanks very much, Paul. For those wishing more cutting-edge podcasts, Webinars, white papers or blogs, the address, as always, is www.ebizq.net. We thank you for sharing your precious time with us.