Brittle Applications

August 31, 2009

In a previous post, I said that MRP was a “brittle” application, and a commenter questioned me. What is a “brittle” application? Is this a technical term? What makes MRP brittle? All good questions.

A brittle application is one that doesn’t work at all unless a lot of disparate conditions are met. MRP, for instance, doesn’t work unless all the data is right, people know how to use the program, the demand for the products is stable, purchasing is also committed to minimizing inventory levels, etc., etc.

The notion applies to a lot of other programs besides MRP, though I’ve rarely heard the term used. But notice that it brittleness isn’t so much a feature of the program as it is the purpose to which the program is put.

Let’s take a simple example: a word processing program. For normal purposes, a word processing program in this day and age is not brittle. A rank novice can use it to type and print. But even today, if you want to use, say Microsoft Word, to put out a 16-page brochure, complete with illustrations, well, good luck, is all I can say. You try to get an illustration and have it float and change the size and put in a table, and–well, just try it, it’s a nightmare. So, to put a 16-page brochure together, Microsoft Word is brittle, but to print out a letter, it’s not.

The point about the MRP program that QAD wrote, which follows the APICS standard religiously, is that it’s brittle relative to the purposes for which it was intended. Pam and Karl and Evan (the founders of QAD) really believed that QAD’s could do supply chain management for manufacturing facilities very effectively. My point was that the program is too brittle. To get things right, you have to get all the data right and keep it right, etc., etc. And if you don’t, what you have is an overwrought and overcomplicated Kanban system, without Kanban’s virtues.

Are there other enterprise application systems that are brittle? Lots and lots of them, I think. Almost all the old, Siebel-style CRM systems were simply too brittle; they depended too much on the good-will of the salespeople, the accuracy of the sales model embedded in the system, the reliability of the sales cycle, etc., etc. You wouldn’t think that financial systems are brittle–after all, they have to work–but they often had components that were overly brittle: cash management systems, for instance, and fixed asset systems and budgeting systems.

What do most companies do when they have an overly brittle system? They use the system for lesser purposes. And they feel REALLY bad about it. So, the Microsoft Word user makes a brochure that is far less fancy, but more manageable, and the QAD MRP user uses the product for tracking inventory. And both of them keep on saying, “Well, one of these days, I’ll get around to really making this product sing.”

They shouldn’t. Brittle applications are brittle for a reason. A lot of the time, it’s because they’re really a special-purpose product, but yours is not that purpose. Some of the time, they’re brittle because they’re badly designed. Some of the time, the model they’re using (MRP is a good example) just doesn’t fit the situation you’re in. In any of the cases, the fact is that they really can sing for the right user, but that doesn’t mean it’s your fault if they don’t sing for you.

What do you do if you have a brittle app that isn’t singing? Give up on it. It won’t work for you. Get another app, one that works. Or change the process. Or just accept the fact that it will never work the way you thought it would.

In any case, good luck.


3 Responses to “Brittle Applications”

  1. I think one of the reasons that ERP systems are becoming brittle is because they are trying to achieve the wrong goal. Too often I hear the phrase “the system should not let the user do X”. I see products being turned into giant employee babysitting services. Task based UIs guide employees down the predefined sequence of steps to accomplish the required task. Users are blocked from using their judgement in edge cases by limits and constraints decided business analysts and accountants.

    It is not surprising that users don’t want to use the system, and that they bypass it when they can, invalidating any statistical analysis because so much stuff happens off the books.

    For a company with high-turnover and one that values low cost workers, I can see the advantage of an ERP product that keeps its users on the rails.

    But that should not be the goal of an ERP product. In my high school math class we were warned about the evils of using a calculator. If you don’t understand the math, then the answer could be completely wrong and you may not know it. But in the hands of a professional a calculator can be a formidable tool.

    ERP software should be about augmenting the capability of your employees. It should provide them with accurate information to allow them to make smart decisions, faster. It should not try and hold their hands, limit their control or obstruct them in any way.

    With this perspective, an ERP system has to be flexible enough to accommodate whatever the user wants to do, and just because the system let them do it does not absolve the user of that responsibility. That would be like telling my math teacher that my calculator came up with the wrong answer.

  2. Greg Jones Says:

    I’m skeptical. I can’t see anything in your post that wasn’t already touched upon by the APICS study material I’ve looked at.

    The points are valid enough, but not particularly new or revolutionary. The core data has to be right. Stable demand works better. And peole are loathe to do the extra work to get there.

    So what other options are there? If MRP systems are middle-aged apps, what newer apps exist? What replaces or reinvigorates MRP systems?

  3. toppundit Says:

    Thanks for the challenging comment.

    I agree, there’s nothing surprising about the fact that it takes a lot to make MRP work. APICS says this. I say this. You say it. We’re all right.

    I am simply asking, “Is all that effort worth it, for most companies, most of the time,” and my tentative answer is, “No.” Why do I say that? Because I’ve been to a lot of companies and looked at their installations, and it’s been clear that that’s what they decided.

    I doubt that APICS comes to the same conclusion; I really do.

    What are alternatives? Nothing very profound. In my experience, Kanban is a simpler and less brittle way replenishment strategy. Flow manufacturing is very powerful for certain kinds of production. In most manufacturing organizations, process improvement and redesign (focused on making replenishment more effective and demand-sensitive) is probably easier and more reliable than putting in a computer system.

    I also think that many companies might well want to use advanced supply chain optimization packages for managing key processes or key inventory items and using more simple-minded, but reliable processes (like Kanban) for everything else.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: