If exploiting the new technology requires process redesign, new knowledge, and new skills, then the solution provider’s ability to effectively transfer that domain expertise to the user team is a major consideration. This might seem obvious, but lack of domain expertise within the team is often the source of many poor implementations. Here again, we examine the desired business outcome and ask the question.
The question becomes not just “does the vendor really know my industry and business as well as I do”, but rather “do they know this piece of it much better than I do?” – are they actually adding knowledge and expertise to my total equation. The reality in supply chain is that there are many intangibles that cannot be fully encapsulated in the technology application, so what else can the technology firm bring to the table? If you take this dimension to its logical extreme, the ideal solution to achieve the desired business outcome may be to outsource that process to a partner who will take responsibility for the enabling technology. Obviously, that is not the path for most engagements. Vendors, on one end of the spectrum, only offer technical assistance to get the product up and running…on the other end, they are capable of actually taking over the process and managing it effectively (3rd parties- 3PLs, EMS, etc.)
Another point of note is the continued survival of small focused domain leaders, in spite of the intense competition and dominant position of the ERP vendors. In fact, software firms who have high Domain Knowledge (i.e. Best of Breed) have been consistently adding value to their clients through excellence in enabling their customer to continuously improve. In fact, Domain players are the most confident and most capable to discover and deliver the value proposition.
Let’s look at two examples that can apply.
Service parts planning
Like all business function areas, service management is a complex web of challenges—how much inventory to position where and when to ensure customer up-time. But Service Management is also a business that has to make money. So, not only do I look to optimize the dollars that I spend on customer care, but also what to actually price the services and parts that I sell.
Our Domain Knowledge leaders such as MCA, Servigistics, Xelus, and coming up from the CRM side, Oracle, can make it to my short list by displaying these characteristics:
Embedded Intelligence: This is the actual code base. How smart (algorithms and optimization) and appropriate, (a good fit) for my business model, industry, etc., in the code. What is the plan of the vendor to continue to increase this?
Process Expertise: Many end users get a lonely feeling when the software vendor pulls up stakes. Larger, pure technology firms rely on systems integrators to install their software, but Domain vendors have rich business expertise to offer, and frequently not only provide the technical assistance, but can be counted on for Best Practice advice. Process Expertise, then, can be provided by 3rd parties who operate the process (not just the technology), system integrators, and consultants, as well as the software firm themselves. So, depending on the user’s relationships, this may or may not be a factor for the technology firm.
Of course, a fair amount of process templating is embedded in software. Software workflows and preconfiguring can be part of the solution, but that still does not get the process into the minds and hearts of the users.
Industry Services: Content and data services as a complement to the software. Content is king, as the saying goes. Catalogues, pricing, and other market data can be provided as a service here. Procurement software is frequently partnered with, not only the product catalogue, but may sit on top of consortias of spare parts and market information. So, sometimes it is more about the content than the software. For example, Hoovers provides the content and some software tools; International trade compliance software, as an example, may go beyond just content—rules by trade regulations by country, but also provide guidance on how and when to use what type of documentation, as well as workflow once completed. Additional service can include semantic management/ mapping, translation etc. Users can subscribe to the data service and gain various searches, and alerting can be subscribed to in these models.
So, in my service parts example, if I need expertise in understanding deep optimization issues, potential altering business process logic, I might find MCA more dominant. But possibly, I am looking for pricing analytics and actual content—subscribing to competitive pricing in my market. Servigistics would lead here. You get the point. Knowing what is the business outcome. This allows me to move on to the other aspects of the solution (see Remapping the Supply Chain Universe).
Leading domain knowledge software vendors
Demand Planning is one of those spaces that actually has been pretty hot lately. And there are good reasons
First, demand numbers are the progenitor of good execution, or extremely wasteful spending, depending on whether you get it right—or wrong. The stakes are too high to get it wrong, often. But we knew that!
Second, and what is more currently the reason, is the structural disintegration of the enterprise. If I am a brand company, and OEM or retailer, my very existence hinges on good demand numbers and clarity of communications with my supply network.
Domain Knowledgeable firms continue to sell their solutions with the resultant happy customers to show. Domain Players like Adexa, Demand Solutions, i2, Terra Technologies, etc. have had a resurgence of business, in a very difficult market. And we have had some exceptional case studies examples from most of these guys that are pretty high voltage—CEO level types baring witness to software that turned their company around – Adexa; a retailer taking promotional queues from the apparel firms (who also ups the profitability by sku) from Demand Solutions; and a food company who reduces inventory and reduces transportation costs – Terra Technologies….all through better demand planning.
Why do users continue to buy domain leaders’ software?
Obviously, everyone’s got case studies. So, why do users continue to buy from Domain leaders, rather than ERP providers?
“You look at all the shelf ware and you realize that it wasn’t always all the exotic algorithms that people were after”, said one SCM executive to ChainLink Research (sounds like he was the analyst!). “We needed some better approaches to scale our business, better connectivity with suppliers and customers, and detailed data to ferret the problem areas. We need direction on how to solve them.”
So, Domain leaders don’t win deals on integration. But on Domain knowledge, what they bring to the table can add to process expertise. For example: WMS software is a market which is rich in Domain Knowledge. Ironically, the consultants (big 10) chased APS and ERP and kind of left WMS behind for years. When the market turned, they turned their practices towards this. But the majority of Domain expertise in the consulting arena were small geographically local firms of less than 200 people. This has been great for these firms, now in a good position with RFID, since their Domain included data collection.
Consistently, users want the software firm to play more of an advisory role in the process. Of course many software firms are not set-up with this kind of service. And their eco-systems are populated with consultants to provide that. And they want to leverage those relationships as a sales channel and don’t want to risk losing that relationship. But for the small domain leaders, consultants frequently pass them by, leaving the path open for the technology firm to implement, if they have the bandwidth.
Certainly, many companies feel comfortable with consultants. But many do not. Last year we did a large study (over 2000) of SCM projects, and found that frequently the consultants were not, in many cases, process experts. They were good integrators, but not really good SCM Domain experts. And this was a contributing factor to poor project success.
Obviously, there is much complexity in these decisions. But if your focus is ensuring process transformation, then Domain Knowledge should be a key.