Earlier this year, I had the chance to catch up with jCatalog, a vendor that's not particularly well known in North America, but that should be for companies that have SAP SRM deployments. jCatalog falls squarely in the P2P plumbing category, providing core content and catalog management capabilities to enable eProcurement initiatives (think Vinimaya, albeit with a very different technical approach and architecture to solving the same problem). While jCatalog has been around for a decade and has 70 employees, they've been relatively quiet in North America, preferring to sell through channels and partners. But hopefully, given the strength of their solutions, this will soon change. In this initial post on jCatalog, I'll provide a few basic details on the company and their solutions. And later in the week, I'll talk a bit about what I've learned when actually seeing the product and talking with reference customers (some of whom are quite familiar with competing solutions). Let's begin.
In Europe, jCatalog's core business revolves around both product information management (PIM)/configuration on the sales side and serving procurement organizations with an online product catalog tool, a catalog management cockpit, a PIM module for buyers and a capability that enables supplier self-service and overall content administration. In talking to jCatalog, it quickly became clear to me that this is first and foremost an engineering company versus a sales and marketing machine. Today, they've got 30 developers focused on their catalog management solution.
The feedback I've gotten from customers (including some of whom that have bought jCatalog's solutions through Perfect Commerce) is almost universally positive with limited exception (in one case where a hybrid Vinimaya / jCatalog deployment exists in different divisions of a large multinational). jCatalog picks up the pieces where SAP catalog management and MDM come up short, particularly in the areas of multi-catalog search, configuration and supplier self-service. For companies that need to manage complex internal buying or product requirements and rich technical data, it's a potential match made in content management heaven.
Even though I'm not the most technically astute person in the world -- I've tried to stay out of the deep technology trenches since my first job in the consulting world which occasionally took me down to the packet and switching levels -- it's important to call attention to the fact that jCatalog takes a few rather important approaches with its overall architecture that help to differentiate it from others. For example, supplier catalog processing is file, not database, driven. This decision reduces the complexity of the supplier catalog process and makes it more cost effective to administer.
jCatalog's fundamental product design is based around the need to support complicated and global supplier content management requirements -- operating primarily in an existing catalog paradigm (versus a virtual one where suppliers only need to maintain or publish data versus managing a catalog). However, jCatalog claims that they can also provide a federated search capability if customers request it (which is a relatively new offering and one that I've not spoken to references about).
The application is truly global in potential usage and scope, allowing users to easily toggle between various languages, changing both the UI and the content (which is far more complicated in the context of eProcurement than in other sourcing, for example). Moreover, jCatalog excels in the case of complex and integrated purchases where options, kits or bundles become part of the buying equation. For example, a decision to buy one SKU can then lead to a required request/form to order another related item (or a series of related items). But despite the complexity that such conditional bundling and relational matching require, the actual maintenance and configuration of the content does not require IT resources. Rather, business users (e.g., procurement or suppliers) can manage and maintain all of this information on their own.
It is this level of combined self-service and granularity / attribute-driven configuration that makes the application quite powerful relative to the resident capabilities in ERP catalog and content management tools that make no apologies for their complexity and IT-led management and administration requirements. Moreover, from a user perspective, masking this underlying self-service power is what I'd describe as a moderately friendly (very friendly by traditional SAP standards) UI that just about anyone could walk up to and use with no training from a search and requisitioning perspective.
Stay tuned for additional analysis on jCatalog later this week.