Category Archives: Technology

No Surprises in the 2010 Manufacturing Software State of the Industry Roundtable

About a month or so ago, Software Advice released it’s Manufacturing Software State of the Industry Roundtable where they reported buying activity, spending patterns by business size and industry, and the primary motivations behind current buying activity as well as well as activity in the software as a service (SaaS) market, how vendors are adjusting prices to compensate for the economy, how offshoring influences spending and whether manufacturers are implementing integrated enterprise resource planning (ERP) systems or best-of-breed applications.

The main results are summarized below. Everything is pretty much as you’d expect if you’ve been keeping up with the supply chain space and the economy:

  • Market Activity Up It’s a recession, and most M&A happens during a recession when there are good deals to be had.
  • Small and Medium Enterprise Spending Up Most innovation comes from small and medium size enterprises, who have probably figured out it’s a do-or-die, and do it cost-effectively, economy. Hence, a slight rise in SME spending.
  • Large Enterprise Spending Flat No surprise that the slow behemoths are trying to keep the status quo and wait it out.
  • Food, chemical and consumer packaged goods manufacturers Up People have to eat and meet their basic needs, but they don’t have to buy overpriced products to do so. Hence, the F&B and CPG companies will be investing to cut costs and retain market share.
  • Aerospace, semiconductor and automotive manufacturers Flat Business people still have to travel, old cars still break down, and sales make flights and cars very attractive to vacationers and buyers who have disposable income. Plus, all the bailouts allow the dinosaurs to keep bumbling along at their slow and steady paces. As for semiconductors, we live in the information age where we can’t do without the chips they produce.
  • Software as a Service Up Companies are getting comfortable with the concept, which is becoming very attractive with limited budgets and high-speed internet everywhere.
  • Manufacturing ERP Software Pricing Down The lumbering giants are realizing that people won’t pay seven figures for a solution when they can get an 80% or 90% solution for five figures.
  • Integration Across Plants and Supply Chain Up It’s still slow, but the onslaught of vendors that have hit the space in the last decade are continuing to make progress.
  • Best-of-Breed Applications Flat Nothing has happened to make them more or less attractive as a whole.
  • Integrated ERP Suites Up If you have to buy ERP, you’re at least going to buy one that enables organizational efficiency.

To dig into the details, check out the two part series over on Software Advice which just released it’s Manufacturing Software State of the Industry Roundtable.

Share This on Linked In

What About Risk-Based Development?

I enjoyed the recent article over on Industry Week on “New Models for Product Development” that identified the need for new development processes that will make product development faster, less expensive, and more successful in its outcomes and that covered agile development, knowledge-based development, and spiral development processes as potential processes a company could use to improve product development and associated outcomes. But it made me think about the alternatives not mentioned — namely risk-based development. But first, let’s discuss why new development methodologies are needed.

As noted in the article, a 2008 survey showed that companies met their product launch dates only 45% of the time. Furthermore, a recent survey by Boston Consulting found that only 52% of senior executives were satisfied with their companies’ innovation ROI. That’s clearly a fail. NPD is hard, and not every project will succeed, but these results are equivalent to saying that management is okay with failing half of the time. That’s not acceptable.

However, according to the article, besides making sure that there is a formally defined (and followed) process in place, the only way to see significant improvement is to identify the “next big thing” — the idea, invention, or improvement that will make the product development process faster, less expensive, and more successful. And while I don’t necessarily agree that it has to be “big”, I do agree that, in most cases, improvement is needed. But what kind?

According to the article, the leading contenders are agile development, knowledge-based development, and spiral development processes. Agile development, which started in software, mandates incremental development by teams in short time frames, such as one to four weeks. The frequent inspection and adaption is designed to allow changes to be introduced quickly, and before doing so would be prohibitively expensive. Spiral development, which also started in software, mandates multiple iterations of the entire process, improving and expanding the product in each iteration. For example, in new cell phone development, spiral one would be the base hardware and core OS, spiral two would include the camera and motion centre and API for core apps, etc. Knowledge-based development focusses on the creation of reusable knowledge through learning cycles that use set-based design. Multiple options are created and then refined and eliminated until the winning design is found.

They are all great processes, and they call confer advantages above and beyond the traditional staged development usually employed by manufacturers, but they all miss the point. If the reasons for failure are analyzed, it will quickly become clear that the primary reason most NPD projects miss their deadlines, or outright fail, is because something didn’t go according to plan — a disruption occurred. A risk, known or unknown, materialized and set everything back.

This seems to indicate that what we really need is risk-based development. In risk-based development, after identifying a feature/function list and a few potential high-level designs, the first thing the team would do would be to identify what new innovations are needed to succeed. The team would then rank the innovations on a scale from 1, or incremental renovation of existing technology, to 10, revolutionary invention so that the innovations with the highest score carry the highest risk. Then, the team would attack the highest risk innovations first in a multi-round/multi-stage development process. If the highest risk innovation could not be solved, the project would be suspended until a new idea was identified or terminated if the cost/reward ratio to solve the risk was determined to be too high. This would prevent the situation where the product is taken to 90% completion only to find out that the “killer-app” feature can’t be completed, which makes the product worthless and costs the company millions of dollars and dozens (or hundreds or even thousands) of man years. And this development methodology would work with any stage-based or phase-based process that is already being utilized by the company. It just makes sense.

Share This on Linked In

b-Pack: Packing It In for A Brave New World, Part IV

Three weeks ago, in Part I, we told you how b-pack, hot on the heels of Ivalua, had decided to cross the Atlantic and join in the conquest to bring the bohemian revolution to the world of Procurement and P2P with their extensive solution suite that actually closes the P2P loop. Then, two weeks ago in Part II, and last week in Part III, we expounded on some additional capabilities, relatively unique in the marketplace, that extended the basic value offering beyond basic P2P. Today we’re going to address one of the advanced P2P capabilities, the tightly integrated document management feature, administration, and the supplier portal. But first, a quick recap of the story to date.

Part I described the base b-pack platform that takes you from the start of a traditional sourcing cycle (RFx), through a contract, to a requisition (which may be from a catalog), against a budget, to receipt of the goods (which can include asset tracking information), and the invoice, to payment, reporting, and supplier management. It covered the requisition, approval, receipt, invoice, matching, payment, and reporting cycle in detail as well as the solution delivery options that are available.

Part II detailed some of the integrated applications that build out the core capabilities to also provide the organization with expense and travel management, asset management, dispute resolution, and procurement business intelligence reporting and Part III addressed inventory management and its integration with asset management, budget management, fleet management, and internationalization.

Invoice management, which was initially discussed in Part I, is fairly sophisticated with a built-in invoice viewer (which can handle invoices in e-mail, EDI, and PDF formats, among others), auto-match capability (at the line-item level against original purchase orders), and multi-way match capability between purchase orders, contracts, and/or good receipts. The auto-match can be manually overridden (and maintains a running total of the reconciled amount against the entire invoice amount so the user can track her progress) and an invoice cannot be approved until it is fully matched against one or more purchase orders (at the line item level) and until all disputes against it are resolved. This goes a long way to insuring that incorrect and fraudulent invoices are never paid, which happens way to often when certain commodities, like office supplies, electronics, and storage space, are being purchased regularly and in large volumes.

Like reporting, document management permeates the system and allows each document to be tracked by way of associated meta-data which includes type, creation date, version, author, language, and other information relevant to the document type. In addition, (related) documents can be organized in a tree structure and a new document can be defined as sequential merge of a set of documents organized in a tree. Contract management is then built on top of this capability and allows contracts to be built up from component documents, where each component is a distinct section or clause, with its own meta-data information that aids in searching during contract construction. Through versioning, a user can quickly build a starting contract from standard clauses and then edit them accordingly using the built in word processor. The contract can then be output to PDF or Word, and if edits are made in the Word version (by the supplier), it can be imported back into the system as a successive version.

In addition, the document management system can store e-mail templates which are sent out when an action is triggered in the system, such as the transmission of a purchase order, the formal notification of a dispute, an automatic alert that inventory replenishment is required, and so on. These templates can be stored in multiple languages, and the proper version will be selected according to the language of the recipient. Furthermore, it’s integrated with the auto-translation utility which, although not perfect, gives you a starting template in another language, which can then be quickly reviewed and corrected by a native speaker.

Administration allows the user to define global display properties, procurement specific workflows, batch processes, usage rights by user, help file additions, and log access rights. Global display properties include price display rules, date rules, fonts, and themes. Procurement workflow properties include request limits, default payment modes, templates, and terms. Batch processes include data cache maintenance, undelivered e-mail management, user session management, database optimization, and invoice file management. The buyer can add specific information to the online help files for supplier use and for internal use. Finally, the administrator can also run data integrity checks, performance checks, link and reference checks, and database optimization.

Whereas some vendors build separate supplier portals for suppliers, which can greatly limit the functionality available to the supplier as most of the smaller shops can only devote so many developer cycles to portal maintenance, b-pack chose to build the supplier portal within the core application. The supplier portal is essentially the same application, but with access limited only to what the supplier is allowed to see and do. When a supplier representative logs in, she sees the same task manager that a buyer sees, which shows her to-do list, in-progress tasks, most recent system access, and available applications and allows her to access her reports, search for relevant information, and define the application settings she has control over. If she accesses the purchase order module, she sees the full workflow associated with the purchase order, but she is restricted to altering information related to acceptance and delivery, attaching notes, and initiating or responding to disputes — buyer side information is locked.

In addition, the supplier (vendor) master is tightly integrated with the core platform and allows the buyer to add and deactivate suppliers as required. For each supplier, the buyer can define basic identifying information, contacts, catalogues, currency, a description of the supplier’s product and/or service offerings, and portal access. The administrator can not only grant access to one or more supplier representatives, but choose what authorizations each representative is granted (in terms of invoice management, dispute management, catalog management, packing slip generation, invoicing, etc.).

In summary, the b-pack platform, which has been under development for ten years and which is very well thought out with respect to its goal of optimizing your back office procurement, provides a comprehensive P2P e-Procurement solution that also includes some very useful capabilities above and beyond the basic procurement cycle requirements that can provide significant additional value to many buying organizations, including the invoice management, document management, and supplier management capabilities described in this post.

Share This on Linked In

More Reasons the Cloud is Not a Fluffy Magic Box

Soon after I told you that the cloud is not a fluffy magic box, I found this great post over on an Information Week blog on “3 things that could kill the cloud” which points out some more sobering realities of the cloud, which is just really an abstraction of the multi-tenant SaaS model where one provider provides the software and another provides the infrastructure the software runs on. The article has some good points that should be taken into account before you decide that the cloud is the answer. (Sometimes it is, sometimes it isn’t.)

  1. Scalability is not UnlimitedFirst of all, at any point in time, the infrastructure provider has a limited amount of hardware and bandwith available. When that is reached, you’re out of scalability until the provider ramps up. Furthermore, even if the provider ramps up, there’s still a practical limit dictated by the software. Most databases start to fail miserably when you get to the Terrabyte range. Most analytics applications fail miserably when you ask them to process millions of records in real time. Etc.
  2. Security is not AbsoluteThe cloud does not inherently provide more security as some vendors would have you believe. In fact, it might even provide less. In reality, the security of any platform comes down to the knowledge and vigilance of the provider’s people and how well they are at identifying potential holes, locking them down, and keeping up with patches. If the software vendor assumes a certain port will be locked down and the infrastructure provider leaves it open or if the hardware vendors assumes the software vendor will patch core applications and vice versa, security is weakened.
  3. Prices can be HigherWhile up front prices are quite cheap as you’re primarily paying for energy costs (to run and cool the CPUs) and bandwidth, and while the Cloud will be cheaper for small-scale applications, the reality is that for large scale, high-bandwidth, applications, the total costs can be more expensive than running your own data centre as most providers don’t yet have the scale and expertise to beat in-house costs. You have to do the analysis.
  4. Your application can disappear in a puff of smoke.Thanks to the Patriot act, if a drug dealer happens to be using the same multi-tenant provider, in the US the FBI can sweep in and seize *every* server in the data centre, regardless of what else is on the servers, shutting down the entire operation of the infrastructure provider for an unspecified time — like they did to Core IP Networks in April.

Share This on Linked In