Category Archives: Technology

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

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

Two 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, last week in Part II, we expounded on a few additional capabilities, which are relatively unique in the marketplace, that extended the basic value offering beyond what a standard P2P application delivers. Today, we’re going to dive into a few more value-adds, some of which are also relatively unique in the marketplace. But first, a recap of the story to date.

In Part I we 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. We dove into the basic P2P cycle and covered the requisition, approval, receipt, invoice, matching, payment, and reporting cycle in detail as well as the solution delivery options that are available to you.

Then, in Part II we 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.

Today, we’re going to address inventory management and its integration with asset management, budget management, fleet management, and internationalization. Then, in the fourth and final post of this initial series, we’ll tackle some of the advanced invoice management and viewing capabilities, document management, administration, and the supplier portal.

Inventory management, which is tightly integrated with asset management, allows you to track not only how much product you have at each (warehouse) location, but where the product is stored. The tool can handle multiple locations, which can each belong to a different (management) company, multiple rooms at each location, and assign multiple departments, managers, and clerks to each room. In addition to tracking the products (and counts) in each room, it can also track all of the inventory moves associated with each product into, within, and out of the warehouse. Like any good inventory management system, it allows for the creation of manual and automatic replenishment orders, which generate purchase orders against existing contracts and which are pushed through the appropriate approval channels if desired. The replenishment workflow is detailed and allows for multiple states, including fill, approval, standby, warehouse, in order, received, and shelved (put away) states. Finally, in addition to the basic inventory, asset, budget, and catalogue information, the user can also define custom fields, notes, and documents to track against each item.

Budget management is very powerful and allows the user to define budgets at the invoicing company, department, or user level and assign them to a manager and a chief. Each budget can be assigned a budget code, a group code, and a cost centre for accounting purposes and the administrator can define individual purchase authorizations, monthly purchase authorizations, and / or annual purchase authorizations. Approvals can be against global budget amounts, monthly budget amounts, individual purchase amounts, or always and automatic rejection rules can be defined for requests that are obviously unreasonable against the budget. Finally, budgets can be rolled up for reporting purposes.

Fleet management, their newest module, was built at the request of a customer who wanted a way to track their fleet vehicles in a manner that was tightly integrated with asset management and invoice management (to insure that vehicles were properly tracked, serviced, and that payments were at contracted rates). It lets you quickly retrieve vehicle records, fuel utilization statistics, and maintenance contracts and allows you do define alerts based on (fixed) budget utilization, kilometres, taxes, department utilization, preventative maintenance rules, and suspect expenses (with respect to predefined rules). It comes with a number of built-in reports, including total vehicles by type (gas, diesel, hybrid, electric), owned vs. leased summary, manufacturers and lessors, and make and is integrated into their global reporting engine that allows you to create your own reports. For each vehicle, it tracks the original order information, unique asset ID, VIN, type, category (sedan, SUV, truck, etc.), manufacturer, manufacturing location, make, description, grey card info, kilometrages, financing information, insurance information, fuel consumption, service history, maintenance schedule, trip history, and costs per kilometer as well as the division, department, and manager it is assigned to — and every field is searchable to allow you to quickly find the record(s) of interest. The detail of information that is tracked allows for a very deep analysis which will not only tell you which vehicles are the most expensive to operate, but why (fuel, insurance, service, etc.). This will allow you to make much better fleet decisions in the future.

With respect to internationalization, not only is the product multi-lingual and multi-currency, but the tool includes an integrated translation feature that allows text to be translated, automatically, between English, French, and a few other European languages. The buyer can define which currencies are supported, which countries they are supported for, the display properties, associated tax rates (at the country and state level), the conversion rates, and the (auto) update rules (when and from what data source).

In summary, b-pack 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 inventory management, budget management, and fleet management capabilities described in this post.

Share This on Linked In