Online Chat

Use the window below to chat with me (if I'm online ...)

Use the edit nick field above to let me see your name.

cazh1: on Business, Information, and Technology

Thoughts and observations on the intersection of technology and business; searching for better understanding of what's relevant, where's the value, and (always) what's the goal ...

Thursday, December 17, 2009

Bootstrap Market Research: Master Data Management (Results)

As previously noted, I've been doing a lot of discussion and data crunching around "Master Data Management" lately - so I've "bootstrapped" a little market research project. It's still a work in process - responses are trickling in - but I thought I might take some time to summarize what I am hearing to date. A document is available for download here ... the super summary follows below.

Survey Methodology

Please note: I am obviously not a professional market research firm, so this is is an understandably limited sample. Still, I am hearing some interesting things that may put your own Master Data work in a bit more context. 
  • I've put together a little survey (download from here) which is intended to take about 15 minutes to complete - that should give you an indication into the amount of rigor and depth I am looking for.
  • Please fill it out and email the result to BMRMDM@cazh1.com
I've received input from ten companies so far - large and small, with all sorts of ERP systems. If you care to add some information, I'll thank you in advance, and add it (sufficiently anonymized) to the summary results document (download from here).

Here are some of the findings / observations from the summary ...

Master Data Domains

The types of Master Data called out included the usual suspects - Customers, Vendors, Finished Goods, Employees. Others mentioned include Metadata, Packaging / Tooling (components), and Indirect customers (like Payors in managed care, or Buying Groups in B2B). The primary systems in scope included SAP, Oracle, JDEdwards, and QAD, joined by an eclectic mix of legacy systems and point solutions. Secondary systems called out included Siebel, JDA/Manugistics, and ADP (payroll) - plus more legacy / home grown / departmental apps.

Master Data initiatives varied, based on where the "current pain" is - R&D / engineering, CRM / Customers / Contracts / Pricing, and Finished Goods / Logistics were named by different companies as their particular focus areas. Other important considerations were things like geography (North America vs. ROW), and business structure (Enterprise vs. business unit vs. local plant).

A significant determinant of how folks thought about this problem was how their ERP is implemented - in a fully integrated "enterprise" (Finance, Order Management, Supply Chain, etc.) - and/or how the instances are divided (all enterprise, by location (geography) or by business unit).

Note, however, that relatively few respondents are concerned with synchronizing data across multiple instances - a popular callout / feature of some MDM solutions. they will speak of "integration", but a focus of the conversations were all around quality and process, not synchronization.

An interesting frustration from some of the respondees; the ERP system(s) do not capture all of the required attributes for an item, so these additional details are kept in a separate, siloed system. Easy examples would be specific attributes (like shipping material specifications), but there were multiple instances where [so-called] Master Data is calculated with complex formulas / rationale, so an Excel component is required (typically in the area of pricing / quoting details).

Note: I believe we should consider computation of pricing as a (potentially) complex process that occurs in it's own transactional / analytical system (aka "the magic gonkulator"). The output is master data - but the calculations don't belong in an MD system.

Size & Scope of Master Data

Predictably, there was a great variation in the responses - 100s to 1000s of customer, vendors, finished goods. However, the interesting trend was the notation that 10s of people (relatively large numbers, based on size of the company), were "responsible" (i.e. "did some of the data entry"). Could this be why there is interest in MDM and an MDM organization? Apparently, Master Data is often managed like a wiki - everybody is an editor.

Note This is not always "out of control" - companies that have reasonably sized groups are the same ones that speak of metrics and controls. However, few report the existence of a centralized data governance organization (see below).

Most organizations have no metrics in place; a few can speak to "data police", folks that actively monitor the data looking for issues. Best examples cited included "Health Check measures" (does data fit set of established guidelines / tolerances); vendor audits, and [results of] scrubbing (ex. Name And Address data against external sources).

When asked about the business benefits of a Master Data Management effort, most companies left this blank or said "none". I generally got the sense that hard benefits are difficult to quantify; notable exceptions seem to come from past pain. Some organizations spoke to inventory reductions and transportation savings - both derived from more accurate supply chain data, which is facilitated by clean, consistent, complete Master Data.

Master Data in the Organization

Many companies keep control / accountability at the functional area. However, companies with "enterprise ERP" implementations (full integration of Finance, Order Management, Supply Chain) typically call out ownership at the Enterprise level. It's not about the size of the company or the recency of their implementation - it's the degree of integration within the primary ERP.

Organizational specifics were tougher to get at - depending on how the company managed their master data. Generally speaking, companies that manage Master Data at a functional level (Customer Service, Purchasing, Finance) have organizational clarity. However, folks that say they manage at the Enterprise level had the wispier definitions for Title and Accountability

Of note: centralized MDM teams rarely manage the bigger projects (implementations, acquisitions, or special projects with large MD components) - but they will (out of necessity) participate. None of the respondents look to these organizations / people for project management skills. However, there were some good callouts for the communication / change management skills required for the role, especially where the group has to review implications of adds / updates [of Master Data items] with multiple groups that will/may be impacted.

Scope of Responsibilities

An interesting, consistent set of answers in this area; "Yes, we take ownership and accountability - but no, we can't measure it". To be fair, not all companies had that clarity of ownership, but the lack of sharp, clear quality metrics is noticeable. Content, Quality, and Governance are consistent in all of these companies … consistently not-well defined, not well measured.

Positives & Challenges

Funny how best practices in one company are challenges in another. There are two recurring themes throughout the responses; Quality and Complexity. The latter is interesting; this was the first point in the survey where the difficulties of Finished Goods Master Data were raised. Many companies call it out as a large challenge; all of them cite the complexity, the multiple facets (manufacturing, packaging, warehousing, transportation, pricing, costing) and the cross-functional nature

Full Results

The summary results document is available for download from here; I will add a version date on the page and keep it up to date as additional surveys come in.

Questions? Comments? Suggestions? Let me know ...

Previously ...

Technorati Tags: , , , , , , , , , ,

Invisible Technorati Tags: , , ,



Labels: , , , , , , , , , , , , ,

Monday, November 30, 2009

Bootstrap Market Research: Master Data Management (What, Who, How)

I've been asked a lot of questions about "Master Data Management" over the past few weeks - what does it mean, who does it, and what are some tools and metrics that organizations are using to reign in this important aspect of ERP and analytics systems. I started reaching out to the folks in my professional network with some results, but I thought I might be able to leverage LinkedIn and Twitter to get input from far and wide. This "bootstrapped" market research might not deliver the depth and reach of the bigger technology research firms, but it will be interesting to see what can be gathered.

Bootstrap Market Research: Ground Rules
  1. I've put together a little survey (download from here) which is intended to take about 15 minutes to complete - that should give you an indication into the amount of rigor and depth I am looking for.
  2. Please fill it out and email the result to BMRMDM@cazh1.com
  3. I'm trying to get input from a number of companies - large and small, with all sorts of ERP systems. So in return for your input, I'll be happy to email you an aggregated, anonymized summary of what folks are telling me. Please note that none of your specific answers will be tied to your company name in any way.
Some Definitions

What do I mean by master data? Compare and contrast to transactions ...

  • Transactional Data – describes “events”
    • Production orders, material movements, and confirmations
    • Customer orders, shipments, and invoices
    • Payments, credits, rebates, and returns
    • Journal entries
  • Master Data – describes “facts”
    • Finished goods, raw materials, and work-in-process
    • Manufacturing routings, warehouse picking strategies
    • Customers, vendors, employees
    • Organizations and hierarchies
    • Chart of accounts
    • (also referred to as Reference Data, Configuration Data)
The Question of Ownership

I've asked this question before – who owns Master Data? – but there may be some different understanding over what “ownership” refers to. Is the "owner" responsible for …

  • Master Data Quality?
    • Data Structure, including requirements and interdependencies
    • Process & Procedure for getting Master Data into the system
    • Access & Training for getting Master Data out of the system
    • Audits & Quality Checks to make sure corporate requirements and standards are met
    • Metrics & Visibility for critical Master Data processes, especially when adding new products
  • Master Data Content? (for example …)
    • Structure of the chart of accounts
    • Bin configuration and capacity
    • Modeling manufacturing processes in a routing
    • Product families, sales org hierarchies
    • Credit ratings
    • Material substitution
Benchmarking Survey Questions

The survey asks some high level questions in these areas:

  • Master Data Definitions
  • Size & Scope of Master Data
  • Organization Structures
  • Scope of Responsibilities
  • Positives
  • Challenges

There is also space at the end to bounce back some questions - let me know what else is on your mind!

AtDhVaAnNkCsE

Thanks (in advance) for your input - and watch this space for the results!

Previously ...

Technorati Tags: , , , , ,

Invisible Technorati Tags: , , ,

Labels: , , , , , , ,

Sunday, April 05, 2009

Practical Applications of Twitter in Manufacturing?

Over the past few weeks I've had a couple of interesting discussions about the introduction of Twitter to Manufacturing. When someone poses a question like this to me, it throws me for a minor loop, because for very basic, practical reasons, it just doesn't seem to apply. More keyboards & data entry on the floor? Not likely.

However, a few months ago I wrote this rather breathless item, expounding on a brainstorm regarding the use of YouTube and Twitter in a manufacturing setting. Back then, my summary point was about the value of alternative mechanisms for capturing and distributing process documentation. I noted that Twitter was less intimidating than other documentation tools - it's all about capturing status or best practices. But after the past few months of heavier use (@jpmacl), I typically explain Twitter as a keyboard-enhanced conversation - a "false path" for Lean aficionados if you are trying to capture knowledge (the Archaeopteryx of Manufacturing KM?)

But Twitter as an alternative communication medium for folks on the floor? I really don't think it's a good fit - and this is based on practical experience as well as a little common sense.

The Tweeter as Information Source

Are you trying to understand how Twitter would work in your environment? Don't think you can get it right without some decent hands-on time. You'll find that it's very intrusive - not something that you want on 100% of the time. For me, it makes sense when I'm catching up on notes for the day, clearing e-mails, scheduling meetings, or other lighter work that doesn't suffer greatly from periodic chirps from my Tweetdeck. It's running on the second monitor; every once in while I will glance over to scan the latest potentially valuable conversations to jump into.

This scenario would never work on the manufacturing floor. There's no way the Environmental Health & Safety folks will allow anything to distract folks from completing the tasks at their workstation.

Besides, hitting the keyboard for status updates is exactly the kind of non-value-adding data entry that Lean mavens are working to eliminate.  Note that when I say "non-value-adding", I am referring to Finished Goods; standard work, training and knowledge retention are important in a Lean world, but not while you're actually getting work done.

The Tweeter as Information Consumer

On the other hand, if there is a Tweetdeck-style application available, running on a screen that is visible to an entire workcenter - well, maybe the folks on the floor can be _consumers_ of Tweets. Then again, it's just another RSS application, nothing Twitter-specific.

Web 2.0 Technology and Manufacturing

Are manufacturing firms using Twitter? I'd say that few are - and it's based on the "personality" of a typical manufacturing company.
  • IT is typically <3% of total revenue - not an environment that fosters experimentation / cutting edge IT work
  • Lean is a growing force in manufacturing, and Lean is decidedly anti-computer - so no one will have a keyboard at the ready to start Tweeting!
Now, to be fair, you could cherry pick high-tech manufacturers; certainly, there are many engineering departments that are sharing information and communicating real time. But when I hear "manufacturing" I'm thinking line managers, shift supervisors ... not typically the keyboard types. They like their push-to-talk phones, and that's really all the instant communication they need.

Aren't there any potential benefits of Twitter for manufacturing? Directly - not much, I'm afraid. However, as with any area of the business that traffics in knowledge capital, the Design Engineering and Manufacturing Engineering folks might find benefit in information-sharing collaborative networks and "real-time" connections.

Note, however, that I am greatly interested in hearing counter-examples of the above. Anyone aware of interesting Twitter-ing on the floor?

Previously ...

Technorati Tags: , , ,
, , , , , , , ,

Invisible Technorati Tags: , , , ,



Labels: , , , , , , , ,

Saturday, November 22, 2008

I Think I'm Learning SAPanese ...

Spent time at an industry conference last week (ain't Boston great!), and heard the term SAPanese - that special language SAP users learn when immersed in worlds of Walldorf and their ubiquitous software. It's not unique to SAP - lots of software companies develop their own vocabulary. Heck, IT "geeks" are famous for it - even the various functional units within the business develop their own shorthand, terms to help speed communication with "those in the know".

Here are some of my favorite snippets of SAPanese ...

Abapit: (verb) To make something better using ABAP. Usage: "This program simply isn't working properly; we should abapit instead!" (source: Mitch Betts)

Bee-Eye: (noun) SAP's data warehousing platform, Business Intelligence. Not intended as an oxymoron ...

BobJay: (noun) SAP's latest growth-by-acquisition play - Business Objects (BOBJ). Usage: "They keep throwing Bobjay at us, but we're still digesting Bee-Eye"

Boppy: (noun) From BAPI - the Business Application Programming Interface. Usage: "Give me the right boppy and I can get the data in there ...". Note: Most programmers are aware of multiple APIs, for a variety of web services, application platforms, etc. - but no one calls them "Oppy's" ...

Firt: (noun) Finished goods. From FERT, SAP's standard abbreviation (in German, fertig is 'finished')

Halb: (noun) Work in Process. From HALB, SAP's standard abbreviation (in German, halbfabrikat is 'semi-finished product')

Heisman: (verb) An accountability dodge. When software support is asked to help with a problem, and you happen to mention we're dealing in an area that's been customized, you are given the Heisman - held at arms length and told it's beyond the scope of support. (image source: Kelly West / Statesman)

Row: (noun) Raw materials. From ROH, SAP's standard abbreviation (in German, rohstoffe is 'raw materials')

I google'd around, but didn't turn up much ... any additions?

Previously ...

Technorati Tags: , , ,
,


Invisible Technorati Tags: , , , ,

Labels: , , , ,

Tuesday, April 22, 2008

No Silver Bullet for Group Collaboration over Distance?

No Silver Bullet for Group Collaboration over Distance?

Lots of organizations have to deal with the challenge of implementing standard work and best practices over physical distances. With sales offices, distribution centers, and manufacturing locations scattered across the country, what's the best way to get people who know their stuff to collaborate on process improvement - and then take that knowledge back to their home office?

While wrestling with this challenge, one executive I know preemptively ruled out videoconferencing. It's a common suggestion, but the general feeling was that it's just not useful, has never proven itself in practice.

I happened to agree with the idea that videoconferencing wouldn't help in this situation. The team was talking about productivity improvements for an assembly process - workstation layout and hands-on participation was required to effectively work out the wasted movements. However, when defending the No Webcams position to some gadget freaks around the table, we came up with a/the fundamental flaw with remote video: it lacks spontaneity.

Historically, videoconferencing was set up in specific rooms that had to be reserved in advance. For higher quality connections, equipment is expensive, and the expense had to be pre-approved. Advances in digital cameras brought devices mounted on desktops, but this tied you to that specific location. Today's nifty notebooks have built-in cameras, but these can be tough to use with a group of people (crowding around).

Yes it's possible to use videoconferencing, but the physical limitations tend to quickly dim the excitement of all but the most diehard tech fans. In practice, local process improvement teams would just walk over to the workstation in question, skull out the best way to do something, and take a break for some coffee by the time we had the webcam hooked up ...

Lack of spontaneity is probably why the vast majority of PowerPoints are delivered with printed decks, and not overhead projectors. It's still more time efficient to quickly print off a few copies than it is to chase down a projector, lug it and your notebook computer into a conference room, get everything hooked together, and try to remember how to switch to the external monitor. (Hmmm, good thing they added all those cool slide transition effects ...)

Truth is, having paper copies isn't all that bad. Some folks like to take notes on their handouts and file them away for future reference. The medium of communication has its own utility, a sort of residual value that most people understand how to use. The same is true for fancy collaborative technology like videoconferencing. The magic is in the actual conversation, but that can get lost in the struggle to get the technology working before you can actually use it.

Does this mean that collaboration technology is doomed to failure? Of course not - knowledge capture and reuse, and differences in physical location and time zones, are still problems for organizations that rely on the "old way of doing things". You just need to pick your tools judiciously, and build up to the fancy stuff over time.

  • Wiki's will not work if people don't already have an interest / desire / skill / method for creating documentation. Wikis solve distribution and access problems, but they don't make people suddenly want to write.
  • Blogs will not work if people don't already have the need to communicate while competing for people's attention. Blogs solve time and distance chanllenges and facilitate simple Q&A, but they don't automagically endow authors with reader empathy.
  • Collaboration Spaces will not work if people don't already have the need to share documents and edit them within a group. Collaboration Spaces solve version control and tracking hassles, but they don't help groups create impactful documents where none existed before.

We needed to see productivity improvements in component assembly within 60 days, so flying a couple of key people around the country was a small price to pay for the quality of work that we got. We took a small step forward - getting process experts to a different location, to put faces to names, and empathize over common challenges, experience the satisfaction of defining a workable solution - and experience the joy of business travel. Maybe next time we could look into videoconferencing, because interpersonal relationships and understanding of the power of shared best practice has already been established.

Previously ...

Technorati Tags: , , , , , , , , ,

Invisible Technorati Tags: , , , , , ,

Labels: , , , , , , ,

Saturday, January 12, 2008

Innovation That Matters - Substance Over Style

Innovation That Matters - Substance Over Style

This the time of year when organizations (companies, departments, and teams) review their performance from the previous year. Breathless presentations are made to upper management and/or the Board of Directors, in late December or early January. Typically, the IT department will go through their projects and talk about how many significant chunks of work got done that helped move the company forward.

I've noticed when some folks talk about accomplishments for the last year, they'll make a point to mention all of the techno-buzzwords in vogue - for 2007, try Web 2.0, wikis, blogs, and collaboration - to illustrate how the company is innovating. Boy, are they missing the point!

If you're firm is not into consumer products or a direct-to-consumer sales, if you don't do professional services, pure research, or other knowledge-intense activities - how much does Web stuff really drive your bottom line? Ever since the Internet boom of the 90s, Web technology has tempted and teased many brick-and-mortar companies (and middle managers) with dreams of explosive stock valuations. But in reality, this technology has only chipped at the edges of how many of these organizations really make their money, and how Wall Street really values them. The block-and-tackle ERP systems, supporting fundamental, value-adding processes like supply chain, order management, sales and marketing, and distribution, is the technology that's relevant and meaningful to the business.

So why not talk about the innovative stuff you've done with ERP? How about the make-to-stock company that wants to get into mass customization - you can configure most systems to handle make-to-order, but can you also change your product data, order management, manufacturing and distribution processes?

What about IT alignment with new management principles? If your company has committed to Lean Manufacturing principles, can you adapt Agile project management and software development techniques, and bring them into your IT organization?

I know - you did deliver on this (and more!) - so don't sell yourself short! That’s real innovation that actually means something.

  • Innovation with new investment (time and money) in tools and delivery mechanisms is "interesting" - maybe you're delivering productivity or cost reductions, delivering incremental benefit that's "appreciated"
  • Innovation that leverages existing investment (established systems) to deliver new business models and streamlined processes is "transformational" - delivering real step change benefits that are desperately needed!

Don't fall into the techno-marketing trap that the only way you can innovate is using the latest and greatest stuff. Words like wikis and blogs are fun to say, but I prefer terms like 30% annualized growth, category killer, lower inventories with higher customer service, and market outperform.

So does my boss … and the BoD …

Previously …

Technorati Tags: , , , , , , , , ,

Labels: , , , , , , , , ,

Friday, March 16, 2007

Buzzword Management ABCs

Buzzword Management ABCs

A bit of Friday fun ... I was at a trade show a few weeks ago, and noticed a repeating pattern on many slides. I've heard this in vendor pitches and internal presentations as well - every piece of software and/or process must be for the management of something. So, as I sat trapped in a droning presentation, waiting for the "vendor showcase" to begin (free dinner!), I wondered how difficult it would be to hit every letter in the alphabet with some type of management offering. No made-up concepts here - must identify an instance of it's use "in the wild".

Not as easy, but not as difficult as one might think - about 45 minutes of googling and my list was complete. I got most of these from ITIL and SAP, with a little bit of SCOR in there for good measure. Nailed 18 of 26 in about 10 minutes of work, but some were surprisingly difficult, especially X - 20+ minutes for that one. In the end - a nice set of possibilities for your next Buzzword Bingo session ...

Application Management

Brand Management

Cash Management

Document Management

Event Management

Financial Management

Group Management

Hardware Management

Inventory Management

Job Management

Knowledge Management

Labor Management

Merchandise Management

Network Management

Order Management

Portfolio Management

Quality Management

Release Management

Security Management

Talent Management

User Management

Vendor Management

Warehouse Management

X-Ray Management

Yard Management

Zero Management

Labels: , ,

Tuesday, December 27, 2005

Build a Framework: Your chart junk is my roadmap / vision statement

Build a Framework: Your chart junk is my roadmap / vision statement

I remember in the late 90's, seeing many examples of the little train of wedgies that folks used to characterize their business processes:

Click on the picture for a full-size image!




I've used them myself (some of the above samples are mine, I'm comfortable in admitting it) - of course, I typically don't make this stuff up, I adapt from other examples, like everyone else. As I searched for a reasonable picture / schematic / "framework" for a "supply chain", I stumbled across what I believe to be the originator of the wedgie charts - the value chain, popularized by Porter in the 80's.

An interesting sense of satisfaction came with this discovery; I always used to wonder where the ubiquitous wedgies originated, as if I wasn't giving the right credit / citing the correct references, or jumping on some meme-hack's visual bandwagon instead of really understanding the pretty pictures I was drawing.

Still, I remain a big fan of this visual "framework" approach. I've used it for business / technical alignment architectures, for laying out a complex program of interdependent projects, and for abstracting a data warehouse architecture so folks could see the pattern(s) in the multiple legacy systems (enough to identify opportunities for compressing into a smaller set of technologies).

Anyway, I also found this site, and with it my latest model for a framework to capture the Supply Chain ...

Click on the picture for a full-size image!

Labels: ,